Ting
ContentsBlocks and state

Blocks and state

A block is a header and a body. The small header carries the proof of work and, through a few hashes, commits to everything the block contains and everything it changed. The body carries the transactions and their receipts. The state is what the chain holds between blocks: every program's code and storage, in one map whose root hash is in every header. The exact rules are in sections 2 to 6 of the protocol rules.

What a block header commits to A 294-byte header lists thirteen fields. Its parent_id names the parent block by its BlockId, the hash of the parent's header. Three roots commit to the body and the state: transactions_root to the transactions, receipts_root to the receipts and state_root to every record after the block. Its producer_hash commits to the producer data at the start of the body. Parent block named by its BlockId, the hash of its header Header, 294 bytes protocol_version chain_id height parent_id timestamp target transactions_root receipts_root state_root resources_used votes producer_hash nonce Body producer_data transaction_count transactions receipts State after the block every record, committed by the root of one state tree
A header commits to its parent, to its body through two roots and the producer hash, and to the state after the block

The transactions root and the receipts root are each an ordered commitment to a list in the body. The producer hash commits to the bytes the miner chose to include, and the state root is the root of the state tree after the block.

The state is a single map from 32-byte keys to byte values. Its root hash in each header lets two nodes confirm, in 32 bytes, that they hold exactly the same state. With a proof, it also lets a client check one record against a header without trusting whoever served it.

Two properties run through every format in this section:

  • One encoding per value. The same logical data produces the same bytes on every node. Decoders reject anything else instead of guessing what a sender meant.
  • Commitments are checked, not trusted. A node recomputes every commitment from data it validated itself. A matching header is the result of checking, never a reason to skip it.

The pages of this section explain each part: how values become canonical bytes and hashes, what blocks, transactions and receipts contain, how contracts and records are identified, and the state tree behind the state root.

The wire formats and the state model are Ting's own. They use the standard SHA-256 hash function, but are not taken from another project's design.

In this section

Canonical bytes and hashingOne encoding per value, domain-separated SHA-256 and ordered commitments.Blocks, transactions and receiptsThe header, the two transaction kinds and the receipts nodes derive.Contracts and recordsHow contracts and their storage are identified in one flat record map.The state treeThe sparse Merkle tree behind the state root.