Blocks
In this section, we will examine the Block data structure. In contrast to the design choice of the TimestampVM state (which was mostly in control of the implementers), blocks in TimestampVM must adhere to the SnowmanVM Block Interface.
SnowmanVM.Block Interface
TimestampVM is designed to be used in tandem with the Snowman Consensus Engine. In particular, this relationship is defined by the usage of blocks - TimestampVM will produce blocks which the Snowman Consensus Engine will use and eventually mark as accepted or rejected. Therefore, the Snowman Consensus Engine requires for all blocks to have the following interface:
Implementing the Block Data Structure
With the above in mind, we now examine the block data structure:
Notice above that many of the fields of the Block struct store the information required to implement the Snowman.Block interface we saw previously. Tying the concept of Blocks back to the VM State, notice the last field state within the Block struct. This is where the Block struct stores a copy of the State struct from the previous section (and since each field of the State struct is wrapped in an Arc pointer, this implies that Block is really just storing a reference to both the db and verified_blocks data structures).
Block Functions
In this section, we examine some of the functions associated with the Block struct:
verify
This function verifies that a block is valid and stores it in memory. Note that a verified block does not mean that it has been accepted - rather, a verified block is eligible to be accepted.
reject
When called by the Snowman Consensus Engine, this tells the VM that the particular block has been rejected.
accept
When called by the Snowman Consensus Engine, this tells the VM that the particular block has been rejected.
Is this guide helpful?