Skip to content

History / Ledger implementation

Revisions

  • Say how a node without a running ledger answers a sync A node that offers the ledger protocol but has no ledger running answers a request for blocks with an empty batch at once, so a peer that syncs moves on to another node instead of waiting for its timeout.

    @adam-waldenberg adam-waldenberg committed Oct 18, 2026
  • Say that the authority keeps the decoded mint entries The authority decodes the entries of the mint spork once for each version of the spork and finds a mint by its reference, since the ledger asks about every due mint at every tick. The pages said that nothing was cached and that every entry was decoded on every call.

    @adam-waldenberg adam-waldenberg committed Oct 18, 2026
  • Say that waiting transactions survive a promotion A node that replaces another in the same process, as a signing node replaces the observer it started as, takes over the transactions that waited for a block. Before, a promotion dropped what the node had taken in. A restart of the process still loses them, which the pages now say in those words.

    @adam-waldenberg adam-waldenberg committed Oct 18, 2026
  • Describe the send queue that puts votes ahead of bulk Each peer has a queue of two lanes. Ballots, heartbeats and statuses are written before proposals, decisions and transactions, so a big block that fills the stream no longer holds up the votes. Each lane is bounded in bytes. The old text said that a message the stream could not take was dropped quietly.

    @adam-waldenberg adam-waldenberg committed Oct 18, 2026
  • Describe the cap on what a spork mints to one address A node refuses a spork mint once the mints made to its address would pass the sum that the mint spork grants that address. This keeps a later version of the spork from paying an address twice by giving the same grant a new number. The total is derived from the blocks and a claimed legacy address keeps counting under its own address.

    @adam-waldenberg adam-waldenberg committed Oct 18, 2026
  • Name the folder of each chain in the ledger pages The block log and the sign state of a chain sit in a folder of their own below ledger, named by the start of the chain id, and the node logs that folder at start. A node given another genesis opens another folder and leaves the old ones. The pages said the folder was the same for every genesis and had to be moved away by hand.

    @adam-waldenberg adam-waldenberg committed Oct 18, 2026
  • Say that the ledger can be read and used from outside The ledger pages said that no REST endpoint or command existed and that nothing read the status of the service. Remove those statements and point to the endpoints and the command line. List the new classes, the reads the ledger gives the outside, the report fields for unset and lagging sporks, and the tests of the resource and the commands.

    @adam-waldenberg adam-waldenberg committed Oct 18, 2026
  • Split the ledger pages and document the ledger in the daemon The implementation page is now a hub with six pages under it, and two new pages explain how to run a ledger node and which sporks the ledger reads. They cover the genesis file, the validator key, the snapshot check, the spork authority, the blacklist and fee sporks, and the service that runs the ledger in the daemon. The sidebar nests the ledger pages under the Ledger page.

    @adam-waldenberg adam-waldenberg committed Oct 16, 2026
  • Bring the ledger pages up to date with the node branch Describe claims, transfers and fees, the authority the node answers, the view-based consensus engine, the durable sign state, the driver and the transport in the application. List what is not wired yet. Follow the source-list convention of the other pages.

    @adam-waldenberg adam-waldenberg committed Oct 16, 2026
  • Document how the ledger is implemented Add a page on the ledger classes, byte layouts, checks and block log, linked from the ledger page and the sidebar.

    @adam-waldenberg adam-waldenberg committed Oct 14, 2026