Erigon Embedded ConsenSUS Module.
amogus.
As many of you already know, Ethereum transitioned to Proof-of-Stake, energy consumption cut by 98% and we have modularized consensus which allow us to develop stuff faster, etc… However, there is an issue now, system requirements are higher as people need 2 softwares to sync the chain and the UX got trashed. For example, I am too lazy to run an extra client to sync and test Verkle Trees on Erigon. And because of this laziness and my contempt to such complicated UX, I decided to embed a CL into Erigon. so I took Enrique (one of our Juniors), advertised the Idea on twitter, got a bunch of external contributors from my shitposting and got to work… After all, there is no way that I will spend my core-dev career worrying about getting to know how to run Consensus Layers and coordinating annoying jwt secrets.
What are we building exactly
The main objective is to make Erigon independent from the Consensus Layer, at least for the average users, so when you run Erigon by default, no Engine API is exposed and we run with our own Consensus module which you do not know anything about. As of now, this special capability is achieved by adopting the flag: —experimental.lightclient and not by default. Our first objective is to build two things: a modular networking layer and an “Optimistic Lightclient Consensus Module” (we will talk about why it is optimistic later on), which implement the Altair Lightclient specs with an extra optimistic assumption. Regarding the Networking Module, we are fixing it up and refactoring it since we already laid the foundation on top of which we can implement all of the stuff we will need in the future, while the lightclient module has not been started yet and I am still looking at the specs. After these two components are done, we can start refactoring stuff further and write some tests after we get a clear idea of what is to come.
Modular Archittecture
The embedded Consensus Layer within Erigon will have a modular Archittecture, It will be separated in 3 components: Sentinel, Consensus Module(Either Ligthclient or Fullclient) and Erigon itself, all of these components will communicate with each other with GRPC and will be allowed to be ran separately on different machines, but by default they will be all internalized in a single executable. the flow will look like this:
Network gossip will be sent to sentinel which is listening to the network, then the gossip will be sent to EITHER a ConsenSUS Full Client or ConsenSUS Light Client, depending which one for specified (at the beggining only lightclient) and then after Lightclient finishes up with processing the specs we send it to Erigon and from there on, Erigon can execute and do Erigon stuff. We can swap Lightclient with Fullclient if we want a full beacon node, but that has to be thought later on. as of now, The plan is to just have a somewhat basic validation.
Optimistic Lightclient Archittecture
The Erigon Lightclient will implement the same specs as the Altair Lightclient, except that the head will not be fully validated but still imported. Altair Lightclient spec do not import blocks at the head because lightclient validation lags 1 slot behind (so it validates up to N-1). For Example, what Nimbus does is “do not import until proven valid”, which means that the nimbus lightclient implementation will never be on chain tip. What I will do is listen to the regular gossip as well and “Import until proven invalid” so, I will optimistically assume that block N is valid, as long as I know that block N-1 is valid, if I see that in the future that the validity of block N is disproven, I mark that fork as invalid and ban the peers who are promoting that fork. so it is slightly different than a regular lightclient. As of now the lightclient do not validate anything and just yolo the blocks inside the EL with no validation. thus very risky to run, but handy for me, because I hate the EL-CL UX and I only need it for testing anyway so no money involved.
Sentinel
Sentinel is the name of the P2P Consensus Component, it is inspired by sentry which manages the P2P Execution Network Layer in Erigon. The state of the art of Sentinel is:
Implemented gossip for beacon_block.
Implemented ping, status and metadata handlers for p2p calls.
Listening to lightclient gossip (it is in a unmerged PR).
Penalization of peer system.
Protobuffers to interact with lightclient.
Propagating gossip.
Sending requests.
Fork id stuff implemented (kindly inspired by the Prysm codebase ;-) )
What we have
As I said before, The only thing we got working is the P2P Layer and a basic interface with Erigon, which means that Erigon can sync without a Consensus Layer even if very unsafely. You can experiment this with —experimental.lightclient but do not use if serious money is involved as it is not too difficult to end up on the wrong fork with the current level of validation node. If you run your personal node, for chain analysis and testing, and safety is not your first concern then go ahead and use it as you wish, it is unlikely you are going to have any problems with it.