Atomic State Definition for Suzuka Syncing

[musitdev]

State

Definition

Ledger: Content of all account created by Movement blockchain.
History: History of all Tx / block executed since the beginning.
Db: all ledger, history data stored locally at one moment.
State: a set of data that update the ledger or history.

Needs

The goal of the state definition is to define the minimum atomic state that can be applied to a node local db that allow:

• to update the db with the data that are equivalent to the TX/block execution that generate the state change
• Updated data can be Ledger, History or both. Each state type can be applied individually.
• Each state update always let the Db consistent after application.
• Each state update can be reverted at any moment, or do we only transfer state that are finalized when created.
• State must be applied in the right order.
• If a state is applied in the wrong order, the update is cancelled.
• If a state is applied on a db that doesn't have the right initial state to apply, the update is cancelled.
• Before been applied, a state can be verified for:
  • correspond to current db version
  • the state of the local db is compatible with the state to apply.
  • the state contains a proof that allow to verify it has been generated by one or several trusted Suzuka node.

State content

History state

TBD

Ledger state

TBD

Node state use

Light node: use ledger state to update its ledger. Allow executing Tx and get account info.
Bootstrap node: use ledger and history state to generate DB snapshot.
Full node: use ledger and history state to get synchronized from a snapshot or its current state.
RPC node: same as full node.

[l-monninger]

Light node: use ledger state to update its ledger. Allow executing Tx and get account info.

This is unclear. I think we should refer to the Ethereum definitions for their light nodes: https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/

Generally, there are two possibilities for lightness: (1) execution and (2) consensus. Light execution modes are further underspecified; there are number of possibilities for what light execution can be. An running mode that verifies state derived from execution via EIP-1186 is a light running mode, as is a running mode that fetches some state and executes to derive other state.

[l-monninger]

Bootstrap node: use ledger and history state to generate DB snapshot.

Essentially, yes. You could also say the bootstrap node is responsible for coordinating any other operations that need be performed when a node joins a network. For example, enabling peer discovery is usually a function of a bootstrap node.

[l-monninger]

The goal of the state definition is to define the minimum atomic state that can be applied to a node local db that allow:

This needs to be defined per software unit and running mode.

For the Suzuka Full Node, the atomic state, i.e., the state without any consistent substates, is actually the block and state derived from its execution. This is because each full node has the responsibility of generating and persisting some block metadata with each execution, and execution must be consistent with these persisted values.

For the M1 DA Light Node, for fairness, the atomic state is the transaction (persisted in Memseq). However, neither transactions nor the blocks they produce are regarded as needing to be consistent currently. The DA Light Node is treated as client for the underlying DA. There is no requirement for the M1 DA Light Node to persist and share the blocks it generates. If we add the data dissemination described in #339 , then this changes.

[musitdev]

To be more precise, we should define all trusted atomic state. Currently, the only atomic state that can be verified is the block state. For the Light node (submit Tx) and the Sequencer if it verifies Tx, we need to define a trusted accounts state.
For the M1 DA Light Node that work on Tx, the PR #339 goal is to define a way to have trusted transaction state.
I'll update the with this trusted state notion and which node need which state and for what purpose.