Page Comparison

https://casperlabs.atlassian.net/browse/NDRS-485

(This is document is intended as a skeleton around which to have the discussion and planning for future work to the block life-cycle and specifically the DeployBuffer and it’s responsibilities. To this end the doc is a series of sequence diagrams roughly dissecting the path that events take in the node.)

Joiner

In the joiner state, blocks are received from peers, and their deploys are stored until shifting into the validator state. Blocks and deploys received while in this state are considered to be already finalized, and they are added to lmdb storage. The api_server component is not yet started.

...

Validator

Deploys can be received from the api_server (client or web) or from the small_network (peers) components. After reaching the DeployBuffer, they are cached for retrieval when the consensus component needs to propose a new block.

...

Block creation

consensus will ask to “create a new block” through the era_supervisor, which in turn will read from the state set up in the DeployBuffer to “propose” a series of deploys to be included in a block.

...

Caching

The DeployBuffer (perhaps more aptly renamed DeployProposer?) is responsible for keeping track of deploys that have been added to the system but are not yet included in a block.

Additionally, DeployBuffer will periodically pulse a timer and prune itself. https://casperlabs.atlassian.net/browse/NDRS-163

...

This document’s purpose is to outline the life-cycle of a block through the components of casper-node.

Components:

• api_server HTTP server receiving and responding to the requests sent to a node.

• Consensus - Responsible for synchronization between nodes.

• DeployBuffer (perhaps better though of as -and renamed to- BlockProposer).

• BlockExecutor - Responsible for executing the deploys in a block’s chain and reporting that to the ContractRuntime.

• ContractRuntime -Responsible for marshalling global state and applying effects from the execution of deploys.

• Storage - Responsible for persisting things (like deploys) to disk.

...

Deploys are used to construct “proposed” blocks once they appear at a node. Consensus asks the DeployBuffer for a list of remaining_deploys, in other words, what blocks should be considered for inclusion in a block.

A “finalized” block is proposed and announced, at which point the BlockExecutor loads the related deploys from the Storage component, and walks through them to find the last deploy in the chain. When the last deploy in the chain is found, it is executed and the ContractRuntime is asked to commit it’s effects to global state.