Announcing Caplin: Erigon Full consensus layer is now live!
Shortly before or after the publication of this article, we are also publishing a new release,v2.43.0 which contains a lot of fixes and improvements and will contain the first iteration of Caplin, Erigon’s embedded complete consensus layer, which is now also a part of our roadmap. On top of this, after this new release, We will completely sunset the Erigon-embedded Consensus Lightclient project.
What is Caplin specifically?
Caplin is the codename for the Consensus Layer client, which will be embedded into Erigon. Caplin will be a full-fledged validating Consensus Client like Prysm, Lighthouse, Teku, Nimbus and Lodestar. Our goal is to make it able to: provide better stability, validation of the chain, stay in sync, keep the execution of blocks on chain tip, provide Beacon API, compact data model, and low CPU and memory usage. The main reason why we are developing a new Consensus Layer is to experiment with the possible benefits that could come with it. We can already envision some significant benefits that could be derived, but we have yet to discover all of them. Some of the most important benefits are that Erigon was not designed around Engine API, the beacon chain archive node is 3 TB, and there is less protocol complexity for Ethereum Mainnet. For example, The Engine API does not work well with Erigon. The Engine API sends data one block at a time, which does not suit how Erigon works. Erigon is designed to handle many blocks simultaneously and needs to sort and process data efficiently. Therefore, it would be better for Erigon to handle the blocks independently instead of relying on the Engine API.
What is Caplin Roadmap?
As of now, we envisioned 4 phases for Caplin development:
Phase 1: Embedded communication through Engine API (Finished)
Phase 2: Embedded communication with Erigon custom protocol
Phase 3: Functioning Beacon API (and support for running validators)
Phase 4: Compact data model using Erigon 4 compaction.
As of now, Phase 1 is finished and will be released in the next release and will replace the Lightclient and will need to be enabled through the --internalcl flag in Erigon CLI (it is not default anymore due to the alpha state of Caplin during this first iteration). We will try to stabilise it as much as possible. Only after we believe it is stable enough, we will move on to Phase 2, where the Protocol simplifications (and most of the benefits) will be able to come to fruition (Noting again that we do not even know the full extent and effects of the benefit that can result from this experiment). Phase 3 and Phase 4 are extras that may or may not be implemented.
What is the current state of the art of Caplin?
Currently, the development of Caplin is at the point where we have a working validating client which implements Ethereum 2.0 fork choice and that can communicate with the Erigon Execution Layer both in separate and embedded modes. Currently, there is no persistent storage in Caplin, and only the last 128 blocks are kept in memory for the sake of chain reorgs, so at the time of writing, the hardware requirement for Caplin are as follows:
It can sync the chain and stay on chain tip through checkpoint sync, nothing more, nothing less; it will behave as the embedded consensus Lightclient which will soon be removed. You can use it right away from the next release with --internalcl if you still want to avoid using a Consensus Layer and want to try it out and help us test it.
More on sunsetting on Consensus Lightclient
Although the Consensus Layer Lightclient embedded into Erigon has proven helpful, it is time to sunset him in favour of Caplin. Despite having better memory requirements than Caplin, the light client network in Ethereum 2.0 is supported by insufficient LightClient servers, which has become a minority in the network as Erigon’s consensus’s Lightclient has started to be used. In other words, finding peers took a lot of time and went from being very helpful to a maintainability nightmare. Additionally, since Caplin and the Erigon embedded lightclient are maintained by only one person, we determined that it was best to focus all our efforts on one thing instead of maintaining both simultaneously.