Node types implementations

[musitdev]

Node types implementations

Node type

Light node

DA light node

See rfc https://github.com/movementlabsxyz/rfcs/blob/main/0012-m2-da-light-node/rfc-m2-da-light-node.md.
It mostly use the Celestia Light node to verify blob sent by the sequencer and validated by celestia network.

Light Mode

See rfc: https://github.com/movementlabsxyz/rfcs/blob/main/0017-m2-light-modes/rfc-m2-light-modes.md
Mostly to get chain state in a trusted way and validate / execute a Tx.
Use state sync to get the state.

Full node

Get block from Celestia DA, execute them, update its state and send a commitment on chain to get block finality.

Current implementation integrate the Sequencer role and aggregate Tx in a blob to send it to Celestia DA. Should the Sequencer role be removed from the Full node to have an independent Sequencer node?

RPC node

Provide Aptos Rest API to query the blockchain. 2 possibilities:

• Run like a full node and provide the Aptos API on top.
• Get state update from state propagation, update its internal state and provide the Aptos API on top.

State Sync

See rfc: https://github.com/movementlabsxyz/rfcs/blob/main/0024-m2-state-gossip/rfc-m2-state-gossip.md

State sync is use by Light Mode to get state in a trusted way.

State sync provide 2 modes:

• get a specific state in a trusted way.
• get a bulk state snapshot from the beginning to a specific height.

-> Inclusion Proofs mechanism is not defined for single state or snapshot.
-> State content is not defined

Libp2p usage is clear.

State proof

It's a proof that allow to trust a state. Can be applied to a state or a snapshot.
To Be Defined.

Bootstrap process

Bootstrap process is mostly the way to generate snapshot of the blockchain needed to get all the data from the beginning until a specific point.
Do we define a specific node that generate snapshot or all full / RPC node generate a snapshot from time to time?
The state sync process uses the bootstrap process to get snapshot.

Implementation steps

1. Define implement State
2. Define implement State proof
3. Implement state propagation between nodes (p2p)
4. Get a state with its proof.
5. Define and implements state snapshot.
6. Implement Light mode: get state and validate Tx.
7. Add state propagation to Full node
8. Implements bootstrap with snapshot
9. Implement RPC node + connected to state propagation.

[mzabaluev]

Light node

DA light node

See rfc https://github.com/movementlabsxyz/rfcs/blob/main/0012-m2-da-light-node/rfc-m2-da-light-node.md. It mostly use the Celestia Light node to verify blob sent by the sequencer and validated by celestia network.

Light Mode

I think we need to have some distinct names here to avoid confusion.

[l-monninger]

This is a common concept in this space though and naming it synonymously would probably add confusion.

Maybe it's better referred to under a fun or project name?

[l-monninger]

But, yes, the DA Light Node here is a separate software unit.

[l-monninger]

State proof

Thankfully, we do have JMT storage already.

[l-monninger]

@musitdev I think we should already pull out state syncing and bootstrapping as its own discussion. It's IMO the top priority of in your domain--even without exact node types and composition clearly defined.

I think if we define the requirements of syncing and bootstrapping first we can both (a) have an path to progressive implementation and (b) be better equipped to discuss the ideal here.

This may be best for said other thread, but here's how I would begin to prioritize:

1. Continue improving the safety and usability of the basic state syncing API here: Public Syncador #359
   • This will transition from myself to @musitdev. But, currently I am shepherding it, as @bhenhsi gathers requirements and we have initial engagements with partners.
2. Lay into bootstrapping performance, determine whether we ought to adopt checkpoints.
3. Implement p2p syncing and bootstrapping protocols.

[l-monninger]

Ultimately, I do think we can target the compositional pattern we discussed here.

[l-monninger]

"Light" Components of Node

Function: sync some members state, provides p2p APIs for doing so. Minimizes syncing trust.
Use: building dApps that require off-chain services with minimal trust assumptions.

That being said, a lot of "light" nodes for other chains are more feature rich. Some chains even propose doing partial execution, though I don't know of any that actually do so.

[l-monninger]

"Bootstrap" Components of Node

Function: syncs state for new nodes, provides high performance syncing mode for doing so.
Use: when a new node comes online, it needs to store and/or compute state quickly. This improves overall network availability.

[l-monninger]

"RPC" Components of Node

Function: serve application APIs, i.e., what are needed for developers.
Use: domain logic and horizontal scaling.

[l-monninger]

"Full" Components of Node

Function: actually runs execution, settlement, and whatever else.
Use: the backbone of the network.

[musitdev]

Ok I break the state / proof / sync and bootstrap in separate discussions.
For the light node, as I understand,, it's refer to the Ethereum light node concept that propose less function with less CPU/mem requirement. We don't provide a DA light node.