Nano block lattice: one chain per account, explained

Picture a bank statement for every single account, kept by the account holder alone. That is the block lattice, and it is the reason a Nano transfer never queues behind anyone else’s.

What the lattice is

The block lattice is the data structure Nano’s ledger is built on. Every account, meaning one private and public key pair, has its own blockchain, called an account-chain. Only the holder of the private key can sign and publish blocks to their own account-chain, and each block represents one transaction.

The whole ledger is the global set of accounts, each with its own chain of transactions. An account is the public-key half of a digital signature key pair, and one user may control many accounts. Send and receive blocks stitch those separate chains together, as the section on linking chains shows.

Why one chain per account is fast

In a single-blockchain currency a miner or staker extends the one shared chain, so everyone waits for the next leader. Nano nodes skip the wait: each node decides for itself whether to add a valid transaction to its local ledger. The ledger design page calls this replacing a run-time agreement with a design-time agreement. Everyone agrees in advance, through signature checking, that only an account owner can change the balance and representative on their own chain.

A global blockchain becomes a set of non-shared account-chains. Each user can update their own chain immediately and asynchronously to the rest of the lattice, which the whitepaper credits for quick transactions. And if account A attempts a double spend that the network must resolve, account B can still make transactions as normal.

Nothing in the design caps throughput. Nano has no block sizes or block times that limit how many transactions can be processed. Blocks are also tiny: a Nano block is a single transaction of about 200 bytes, while a Bitcoin block groups transactions into roughly 1 megabyte, which makes a Nano block almost 5000 times smaller. The whitepaper designed each transaction to fit within a single UDP packet. That detail is historical now, because UDP is fully removed from the node and TCP is all that port 7075 needs since V21.

Editor's takeIs that size comparison fair? Only roughly. A Bitcoin block groups many payments, so compare the size of one payment, not block against block. Read it as "small enough to send around quickly", not as a score.

Send and receive: two blocks per transfer

A Nano block holds the details of one transaction, never a group. Moving funds needs a send and a receive. The RPC calls send, receive, change representative and epoch the “subtypes” of a state block. Think of writing a cashier’s check and cashing it.

Keep three words apart. A block is the digital encoding of the transaction details. A transaction is creating and publishing a block to the network. A transfer is a send plus the matching receive, after which the recipient can send the funds again.

The receive block earns its place in three ways. Funds can be sent while the receiver is offline, only account owners can modify the balance and representative on their accounts, and owners can ignore transactions, which stops someone sending tiny amounts again and again to block use of the account. A send stays receivable indefinitely until the receiver publishes a receive block. Once funds are sent, the sender cannot revoke them.

What is inside a block

Every block records the account’s entire state, including the balance after each transaction. An amount is therefore the difference in balance between two consecutive blocks: a falling balance marks a send and a rising balance marks a receive. Every new block has the type state, and send, receive, change and epoch are subtypes of it. As of v15.0 the node supports only state blocks, though earlier versions used separate block types for each kind of transaction. Older ledger history may still contain those legacy types, but every new block is a state block.

Serialized, the fields come to 216 bytes: 32 each for account, previous, representative and link, 16 for balance, 64 for the signature and 8 for work. That is the exact figure behind the “about 200 bytes” quoted for a block.

Balances are held as 128-bit integers. The first block on an account must receive funds, and that block is often called “opening the account”. Any transaction may also change the representative at the same time.

How the chains link into a lattice

All block types use the previous field to extend their own account-chain upward. Send and receive blocks also use the link field to connect across account-chains, and those cross-links are what tie the separate chains into one lattice.

Who settles a fork

Only an account owner can sign blocks into their own chain, so every fork must come from poor programming or from a double spend by that owner. Representative nodes vote on each transaction, and every node, representative or not, cements a transaction after seeing enough representative votes to reach quorum. By default a node treats a transaction as confirmed once more than 67% of online vote weight has voted for it. The consensus design has the voting rules. How fast that confirms, and what the speed figures measure, is covered in how Nano works.

An account’s representative has no bearing on its own transactions, and an account can change it at any time, inside any transaction or with a block that only changes the representative. Delegating voting weight is not staking, since the delegating account can still spend all its funds at any time. Nodes pass blocks around using a modified gossip protocol, which spreads the load across many nodes instead of having each one answer every other. The vote itself has its own page: open representative voting.

Supply and ledger size

The ledger started from a genesis account with a fixed balance that can never be increased. That balance was divided among other accounts through send transactions on the genesis account-chain. The sum of all account balances never exceeds the initial genesis balance, so the supply has an upper bound and no way to grow. How much ended up in circulation is on Nano units and raw.

Since every block carries the account’s current state, the ledger can be pruned a long way. It could shrink to one block per account plus pending blocks, however many transactions an account has made. Pruning has since shipped in the node as an experimental setting. The V28.2 release notes call it experimental and not recommended for important production services, and warn that bootstrapping from scratch with pruning enabled crashes the node. A pruned ledger shrinks automatically on the RocksDB backend. Read how to run a Nano node before you turn it on. The whitepaper adds that a node may keep the entire ledger or only the last few blocks of each account’s chain. Nano units and raw covers how balances are counted.

Where the design came from

The original Nano paper, written under the name RaiBlocks, and its first beta implementation appeared in December 2014. Development began under the name RaiBlocks in 2014 and Nano launched in October 2015. The goal is a digital payment protocol that is accessible and lightweight, with no network fee at any amount. How Nano works is the full tour, and the Basics hub has the rest of this section.