lfs.md

Last Finalized State

Introduction

This RCHIP specification is to define the process and all dependencies for the feature to enable the node to start participating in a network from the last finalized block, as a validator or read-only node.

Overview of Last Finalized Block (LFB)

Last Finalized Block is the block which is supported by enough validators stake and its content can be viewed as accepted by the entire network. This means, in normal operation of Casper, we always have some number of latest blocks which are not yet confirmed by enough validators and they are potential candidates for finalization (or even to be orphaned).
In simplified version, we can imagine this as a tree where from each block multiple new branches of blocks can grow. These new branches can be seen as different possible futures which, in finalization process, will be scored by validator blocks who are part in each future.

The theorems above guarantee that protocol-following nodes have a common future state if the validators that are equivocating in the union of their states have no more than t weight. Therefore, if Byzantine (and equivocating) validators have no more than t weight, all protocol-following nodes will have a common future state.
Minimal CBC Casper

This theorem from CBC Casper paper is basically the description for LFB as a common future state. In RChain, the state is Rholang (tuple space) state for which the root hash is written in the block as postStateHash. The root state hash uniquely defines the whole state in a similar way how Git commit hash defines the state in a repository.

Overview of Rholang state (tuple space)

The main state in which we are interested in RChain network is the Rholang state, or more precisely its changes. The only way to create a change is to write some Rholang code, package it up in a deploy and send it to a validator. Validator will take its current state and execute the Rholang code from received deploy. As a result it will have a new state (which means new root hash) and a list of changes (inserts and deletes) which describes how to transition from current to new state.

The list of changes, along with the Rholang code is the main content that the validator puts inside the block and it makes consensus values. When the block is finalized, it means that the changes have been validated and accepted by a sufficient number of validators in the consensus protocol.

Dependencies for Last Finalized State

When a node receives LFB it will have the root state hash of the Rholang state. A hash is just a representation which can be used to verify the received state but the whole state for that block must be downloaded from other nodes on the network. For the blocks and Rholang state perspective this gives us conditions for a node before it can start replay or create new blocks.

Blocks dependencies

1. Justifications for LFB
   • blocks referenced as latest messages (blocks) from each validator
2. Deploy lifespan (threshold)
   • number of blocks needed for deploy signature validation
   • currently this is fixed to 50

Download blocks

  previous LFB              LFB    latest blocks
      <==||==================||===========>

Validate blocks

 <-- justification relation        replay (children) -->
      <==||==================||===========>

If LFB has no parents it's the block zero (genesis).

Design

References