Block Structure

Introduction

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.

Protobuf definition

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.

Data fields

A block consists of the following:

• a block_hash

• a header

• a body

• a signature

Each of these are detailed in the subsequent sections.

block_hash

The block_hash is the blake2b256 hash of the header (serialized according to the protobuf specification).

Header

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)

  • the root hash of the global state trie after executing the deploys in this block (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)

• 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)

Body

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)

Signature

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.

Accounts Serialization standard