Lodestar light (PoS) node spec & impl plan

[g11tech]

(this write is still WIP and needs discussion with @dapplion to freeze out and subsequent confirmation with @dadepo for implementation to plug any gaps and provide clarifications)

Background

Mostly people interacting with Ethereum are concerned about what's known as "execution land". In-fact before merge, they could just run light sync protocol on the execution client like Geth, which would be able to validate chain building via PoW/PoA rule-set while giving a "read" capability to the blockchain.

Post Merge Setup

Since the PoW/PoA rule-set can't be used to validate chain building post-merge, the execution client now necessarily need a CL to drive them. This is an extra headache for those who are just concerned about having access to the current ethereum account state (full or light).
Or now that Ethereum consensus is on PoS rails, how to best utilize the protocol to move to a less-trust-verify-more nirvana where doesn't need to run after centralized services and can be more p2p which really gels with the ethos of a blockchain world.

The answer is a light node for PoS consensus which can drive full or light execution node.

Lodestar already allows one to access its light-client api on the current full node and has a light-client module to subscribe and validate and process light client protocol to follow head. Recently a p2p version of this api has been published, but the light-client module is not yet capable to consume it.

Goal

The aim of this effort is to have a p2p light node implementation which will connect to the peers supporting light PoS capability i.e. nodes hosting p2p version of light-client api and drive a full execution node (also coordinate/help execution client support light execution nodes)

High Level Specs

Full PoS node

Allow connecting light PoS capable nodes and manage them separately than full nodes

• not bother them with beacon block requests
• extend status to include capability? (like how execution clients have hello requests telling them capabilities like eth6/snap1/les.. to process/advertise the light node capability
• keep a separate target/max peer allocation for them

Light PoS node

• Allow user to startup with a checkpoint root of any post-altair epoch to download the boostrap
  • weak subjectivity checks on the checkpoint post downloading bootstrap
• connect to the bootnodes/full nodes having the light p2p capability, allow other peers to connect with light p2p capability
• do req/resp with the nodes to sync up (and store) the update period become "synced" and subscribe to gossip
• listen and process/validate/store the gossip header update/finalized update/sync committee update / forward the gossip stay/log
• maintain/log sync/peer status
• host an execution rpc proxy (take input the execution rpc)
• optionally signal head to execution client via execution api
  • download beacon block by root to extract and call payload to call newPayloadV1
  • followup with an fcU call
  • maintain/log execution status of the fcU head

Target

• Light PoS can sync from a checkpoint root via p2p and get synced to current period and stay Synced and track latest/finalized
• Can successfully sync an execution client from blank state to synced valid state and log it
• Can maintain and support its own network of light nodes and seed lightclient data into the network

Implementation

Peering/Networking full nodes

Primarily being more "implementation research" oriented, this will be supported by @g11tech / @dapplion and will be seeded as a separate module that can be independently used by the consumer as well to connect to the full node

Implementing the light consumer

Minus the networking support, the rest of the implementation of the consumer to sync, gossiping, serving req/resp, and optionally driving the execution fcU falls in this category. This is primarily driven by @dadepo with @g11tech guiding the effort (with help from @dapplion )

To reduce networking scope and allowing access to the current modules and api (like block by root, execution engine api), the light consumer will currently piggy back on the full node networking and use to to light-sync.

What does the piggyback entails (--piggybackLight)

Setup:

1. A full lodestar dev node running in single node mode. This should avoid lodestar looking for any information from peers (and hence not banning/removing/ejecting them) while allowing itself to be peered with the light node.

2. A light lodestar dev node with no validators assigned just running to light-sync from full node

• Build/maintain its own db and store snapshot/updates
• Have its own chain and maintain its sync
• can hookup to the same node of the full
• can use same networking/bootnodes to connect to the full peer and use same req/resp
• use light-client to drive sync process (replace api calls by req/resp, and hook onSSE to the gossip listeners)
• use execution engine to newPayloadV1 and fcU and maintain/log status
• host/service both light-client api, req/resp and gossip for light client routes

3. A third light lodestar dev node connecting with above (2.) light node

• using the same checkpoint root to sync (download snapshot/bootstrap and req/resp to sync and start processing the gossip. Node (2) should not host libp2p udp so that the full node is not discovered.
• host/service http/req/resp/gossip

Final Integration

• Integrate the standalone networking module to support light-peers in the full node to avoid piggybacking
• Re-package the code as a standalone mono-repo package with its own options and cmd handler

Tests

TBD

Next Level

This is outside current scope/research task

1. Current Slot: The above light bn node will always stay 1 slot behind the current, however if a light node is connected to a full node it can listen to the gossip on to get the current slot as well as its sync aggregate and can display the current slot info
2. The forkchoice: The updates the light client gets are the previous head, so it doesn't really need to have a forkchoice and its simplest forkchoice state can be latest update (which also has finalized). however it will be worthwhile to track the branch in order to provide functionality to resolve the execution block number => execution block hash for serving as proxy for execution jsonrpc

[g11tech]

not relevant/in focus