A block is the primary data structure by which information about the state of the CasperLabs system is communicated between nodes of the network. We briefly describe here the format of this data structure.
Messages between nodes are communicated using Google’s protocol buffers. The complete definition of a block in this format can be found on GitHub ; the description here is only meant to provide an overview of the block format; the protobuf definition is authoritative.
A block consists of the following:
a block_hash
block_hash
a header
a body
a signature
Each of these are detailed in the subsequent sections.
The block_hash is the blake2b256 hash of the header (serialized according to the protobuf specification).
blake2b256
The block header contains the following fields:
parent_hashes
a list of block_hashs giving the parents of the block
justifications
a list of block_hashs givin the justifications of the block (see consensus description in part A for more details)
a summary of the global state, including
the root hash of the global state trie prior to executing the deploys in this block (pre_state_hash)
pre_state_hash
the root hash of the global state trie after executing the deploys in this block (post_state_hash)
post_state_hash
the list of currently bonded validators, and their stakes
the blake2b256 hash of the body of the block (serialized according to the protobuf specification)
the time the block was created
the protocol version the block was executed with
the number of deploys in the block
the human-readable name corresponding to this instance of the CasperLabs system (chain_id)
chain_id
the public key of the validator who created this block
an indicator for whether this message is intended as a true block, or merely a ballot (see consensus description in part A for more details)
The block body contains a list of the deploys processed as part of this block. A processed deploy contains the following information:
a copy of the deploy message which was executed (see Execution Semantics for more information about deploys and how they are executed)
the amount of gas spent during its execution
a flag indicating whether the deploy encountered an error
a string for an error message (if applicable)
The block signature cryptographically proves the block was created by the validator who’s public key is contained in the header. The signature is created using a specified algorithm (currently only Ed25519 is supported), and is signed over the block_hash so that it is unique to that block.