Block header format

[bobbinth]

It might be a bit premature to define a full format of a block header, but I think we can start thinking about it and add more details as the design solidifies.

As of now, I'm thinking the block header would contain the following fields (this intentionally excludes anything fee or consensus-related):

Field	Description
prev_hash	Hash of the previous block's header (32 bytes).
block_num	Unique sequential number of the block (4 bytes should be enough).
chain_root	A commitment to an MMR of the entire chain where each block is a leaf (32 bytes).
state_root	A combined commitment to Account, Note, and Nullifier databases (32 bytes).
batch_root	A commitment to a set of transaction batches executed as a part of this block (32 bytes).
proof_hash	Hash of a STARK proof attesting to the correct state transition (32 bytes).

I think the purpose of most of the above is self-explanatory, except for maybe chain_root. As described above, chain_root is a root of an MMR which contains all block hashes up to the previous block. It could look something like this:

We need this data structure to verify transaction proofs which were created against some previous blocks.

I think the above is enough to form a set of public inputs for the transition proof. These inputs would be:

• Stack inputs: block_num, prev_hash, batch_root.
• Stack outputs: state_root, chain_root.

All other data would be provided nondeterministically via the advice provider.

[bobbinth]

I wonder if we actually need a separate Note DB or if it could be combined into the chain MMR described above. Specifically, we could modify the block header to look as follows:

Field	Description
prev_hash	Hash of the previous block's header (32 bytes).
block_num	Unique sequential number of the current block (4 bytes should be enough).
chain_root	A commitment to an MMR of the entire chain where each block is a leaf (32 bytes).
state_root	A combined commitment to Account, and Nullifier databases (32 bytes).
note_root	A commitment to all notes created in the current block (32 bytes).
batch_root	A commitment to a set of transaction batches executed as a part of this block (32 bytes).
proof_hash	Hash of a STARK proof attesting to the correct state transition (32 bytes).

In the above, we've added note_root to the block header. Using this structure, we can prove that a specific note was created at some point. For example:

Given note A created in block B, to prove that A exists, we can do the following:

1. Prove that hash(B) is part of the chain. This requires a Merkle proof against chain_root.
2. Provide pre-image of B to prove that it hashes to hash(B). A part of this pre-image would be note_root.
3. Prove that A was created in B. This requires a Merkle proof against note_root.

[hackaugusto]

I think it would make sense to classify the data, for example, the prev_hash is a cache of the rightmost value in chain_root. So we could in theory remove it too. If we classify the values as caching or not, then we can estimate what is the benefit of having the cache, in the case of the prev_hash it should be something like saving log(number_blocks) hashing operations. The same seems to be true for the Note's DB.

I also think it would be useful to classify the data w.r.t. to the consumer types. For instance, the block_num is a cache value, by that I mean the value of block n can be computed from the block_num of the previous block, this should be easy to do by a full-node / sequencer, but that value is super useful for the VM and light clients. Knowing which values we need for which use case would allow us to define at the protocol something that is fast for light clients, and then on the side define a protocol in the warp style, only just the new data is sent to optimize for synchronization speed.

[bobbinth]

Agreed! So far, I have been looking at it through the prism of what we need for proof generation, and not so much from other perspectives.