Deep Dive: Block Fields & Root Commitments

Three layers (read every table with this in mind)

• Consensus — Did we agree on this block (ordering + header package)? Tools: BlockVote → QuorumCertificate → block commit.
• Execution — Did we agree on how txs ran and what state resulted? Tools: execution votes → EC (execution certificate) → FinalizedWave in body.certificates.
• Cross-shard — Do we have signed proof from other shards? Tools: ProvisionCoordinator, body.provisions, provision roots in the header.

Commitments vs signatures (two different jobs)

Header *_root fields are commitments in the blockchain sense: one hash that binds the header to a specific collection (tx list, wave receipts, state trie, …). They answer “What is inside this package?” — not “Who approved it?” (that is digital signatures on votes). This is narrower than a ZK commitment scheme (hide-then-reveal); here the body is usually public and peers recompute the root.

• Binding — change one leaf (tx, receipt, state update) → root changes; a mismatched body fails verify.
• Verifiable — anyone with the data recomputes (full replay for state_root; Merkle proofs for single leaves).
• Compact — one hash in the header instead of shipping the whole history every gossip round.

How verify works (BlockVote): rebuild the canonical signing bytes (DOMAIN_BLOCK_VOTE + network + shard + height + round + block_hash), look up the voter’s BLS public key from ValidatorId, run verify_bls(message, pubkey, signature) → accept or reject. The block_hash already digests the header (including all commitment roots), so the stamp is on this exact proposal package, not on each tx individually.

Core four (most confused)

Who attests what (don’t collapse the layers)

Three different “yes” messages — each with its own signed payload and aggregation story:

certificate_root sharp edge: leaves are each wave’s receipt_hash (outcome + event root), not wave ids or raw tx hashes. The header root is a summary; body.certificates carries the full FinalizedWave objects used to recompute state_root.

Teaching name vs code: course copy still says transaction certificate for “execution proof in the body.” In Rust that role is FinalizedWave (wraps WaveCertificate + receipts) — wave-granularity, not one cert per tx.

How each *_root is computed

Most Merkle roots share one recipe: pad leaves to the next power of two with Hash::ZERO, pair siblings, parent = Blake3(left_bytes || right_bytes) via Hash::from_parts, repeat until one hash remains. Order matters — swap leaves, different root.

transaction_root

Leaves = tx hashes in hash-ascending block order
  (sorted by TxHash value — NOT submit time)

0 txs  →  ZERO
1 tx   →  root = that tx_hash
2 txs  →  root = Blake3(hash1_bytes || hash2_bytes)
3 txs  →  pad [h1,h2,h3,ZERO] → pair → pair → root

Hash-ascending = strict increasing TxHash order so every validator builds the same leaf list. Proposer sorts before packaging; peers reject unsorted bodies.

state_root — JMT replay

state_root = JMT(parent_state_root, apply(body.certificates)). Replay each FinalizedWave’s receipts against the state trie — not a Merkle over txs. Worked example (block 40 → 41).

Other roots — same tree, different leaves

state_root example — block 40 → block 41

Walkthrough on one shard: what raw material goes in, how many hashes run, and how JMT differs from transaction_root. Toy key paths use 4 bits for drawing; production JMT uses ~256 levels.

Timeline

Raw material for block 41

parent_state_root  = 0xaaa…   (from committed block 40 header)
parent_block_hash  = hash(block 40)
parent_qc          = QC₄₀

body.transactions  = [ TxC, TxD ]              ← NEW inputs (transaction_root)
body.certificates  = [ FinalizedWave₁ ]        ← execution DONE for block 40
  WaveCertificate  (quorum ECs for wave ∅)
  receipts:
    StoredReceipt(TxA) → Succeeded + database_updates
    StoredReceipt(TxB) → Failed (no writes)

Code path: build_proposal → prepare_block_commit(parent_state_root, certificates)

State deltas from certificates

Merge database_updates from each receipt in body.certificates (simplified toy keys):

k = 2 substate keys change. Real keys are (partition, sort_key) mapped into the JMT; same idea — sparse updates along key paths only.

transaction_root on block 41 (Merkle — same propose pass)

leaves (hash-ascending): [ hash(TxC), hash(TxD) ]

        ROOT_tx  (= transaction_root for block 41)
       /        \
  hash(TxC)    hash(TxD)

Blake3 hash ops: 1 pairing

JMT replay (toy 4-bit keys)

K_alice = 1010          K_bob = 1101

Before (parent_state_root = 0xaaa…):

              R₀ (0xaaa…)
             /   \
      (sparse — only occupied paths stored; rest = ∅ default hashes)

After apply FinalizedWave₁ (only Alice & Bob paths touched):

              R₁ (= state_root for block 41)
             /   \
           ...   ...
         path to 1010 → Alice = 70
         path to 1101 → Bob   = 80

You never materialize all leaf slots in a full tree. In this 4-bit toy, depth = 4 → only 2⁴ = 16 possible leaf positions — still only paths to 1010 and 1101 are stored. In production (~256-bit keys), depth ≈ 256 → 2²⁵⁶ possible paths — same sparse rule: touch only changed keys, ∅ elsewhere.

How many computations?

Dominated by JMT replay, not tx Merkle — scales with # of writes × tree depth, not total accounts in the world.

Header package peers vote on

BlockHeader {
  height: 41
  parent_block_hash, parent_qc  (from block 40)

  transaction_root  = Merkle( hash(TxC), hash(TxD) )     ← inputs on THIS page
  state_root        = JMT(0xaaa…, apply FinalizedWave₁)  ← ledger AFTER certs
  certificate_root  = Merkle( receipt_hash(FinalizedWave₁) )
  waves             = [ … ]   ← wave ids for TxC/TxD run AFTER block 41 commits
}

Verify before BlockVote:
  1. Recompute transaction_root from body.transactions
  2. prepare_block_commit(parent_state_root, body.certificates) → state_root
  3. Match → sign block_hash

Pipeline (one picture)

Block 40 committed [TxA, TxB] → execute → FinalizedWave₁ ready

Block 41 proposal
  parent_state_root + body.certificates ──► prepare_block_commit ──► state_root
  body.transactions ──────────────────────► TransactionRoot::compute ──► transaction_root
                              │
                              ▼
                    BlockHeader → block_hash → BlockVote → QC

Per-block roots & lifecycle

Every *_root fingerprints this block only. History chains via parent_block_hash + parent_qc — not one global tx Merkle over mempool + proposals + finalized history.

Tx hash vs transaction_root

• Tx hash — identity of one signed transaction (content-addressed).
• transaction_root — Merkle root over the tx hashes listed in this block only, in block order (hash-ascending in hyperscale-rs).
• Wall-clock submit time (T₁, T₂, …) is not the Merkle order; consensus block order is.

Three buckets (what lands in which root)

Proposed but not committed

Leader packages body.transactions, computes roots, gossips proposal. Peers recompute roots before BlockVote. Until commit, not canonical — view change can swap tx set and transaction_root at the same height/round. Incremental packaging: when provisions or finalized waves land mid-height, the proposal latch can trigger a new proposal with updated provision_root / certs — not “one proposal forever.”

One transaction’s passport (single-shard path)

Follow one tx through layers — wall-clock submit time is irrelevant; block order is.

Mempool
  tx hash exists; no header root yet

Block H proposed & committed
  transaction_root(H) = Merkle(…, hash(tx), …)
  BlockVote → QC → commit
  state_root(H) usually unchanged for this tx (certs describe OLDER work)

After commit on H
  wave runs tx → Radix → execution votes → EC

Block H+k (later)
  body.certificates includes FinalizedWave for that wave
  certificate_root(H+k) = Merkle(receipt_hash, …)
  state_root(H+k) updates ledger — tx outcome now on the whiteboard

Cross-shard: same tx may need provisions from remote shards first; finalization can span more than one block (source commit → provisions → execute → cert on a later page). Explorer “one logical tx” ≠ always one block height on every shard.

BlockHeader fields & roots

Hover dotted terms for glossary cards. Block anatomy cards in Phases 2–4 use the same block-field-* entries.

Block body (full objects behind the roots)

Votes → certificates (who signs what)

Not one central issuer: every node collects votes and can build QC/EC locally; QCs mostly propagate via parent_qc on the next block. Per-shard height: each shard group advances its own height on commit — there is no single global “blockchain height” across all shards.

Cross-shard bookkeeping (not one HashMap)

ProvisionCoordinator is a per-validator pipeline of cooperating sub-machines — not a single “provision map”:

• Verified remote headers — QC-checked committed headers from other shards (anchor state_root for proofs).
• Provision pipeline — pending → verified inbound StateProvision batches.
• Expected tracker — what should arrive after a remote commit; drives fallback fetch on timeout.
• Proposal queue — verified batches eligible for next block (dwell window so gossip can catch up).
• Committed tombstones — prevent re-proposing batches already committed (avoids spurious view changes).

Header provision_tx_roots is the static obligation map on a proposed page (“which txs on this block still need shard X’s proof”). provision_root is the Merkle over actual provision batches included in body.provisions once satisfied. No 2PC coordinator — each shard runs BFT + provisions independently.

End-to-end flow (one shard)

Block proposed
  transaction_root  → commits to txs IN this block
  state_root        → claims state AFTER applying certs IN this block (from PRIOR execution)

BlockVote → QC → commit
  parent_qc on next block → proof this block was quorum-agreed

After commit
  txs → waves → Radix → execution votes → EC → FinalizedWave
  later block: body.certificates + certificate_root + updated state_root

Cross-shard extra
  provision_tx_roots → which txs need remote proof
  provisions → verify → body.provisions + provision_root
  then wave can dispatch & finalize

Common mix-ups

Where to go deeper

• Phase 2 — BlockVote, QC, commit, parent_qc
• Phase 3 — waves, EC, finalize_wave, certificate_root
• Phase 4 — provisions, provision_root, cross-shard finalization
• JMT & shard state storage — keys, RocksDB vs tree, insert/update walkthrough
• Timers & chain time
• Tx-flow map
• Glossary — Block header & body