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.