Mostly nice stuff.
Hello, It has been awhile, this is Giulio. Unfortunately, I have not been able to post in the past 3 weeks. Due to exams, refactoring of the codebase(boring stuff) and secret Illuminati meetings. In any case, in this article I am not going to go into the details of Erigon-CL improvements that I achieved while I was too busy with my own stuff but explaining the new element in Erigon codebase: The Real Merge, a way to decrease tech debt and protocol complexity caused by “The Merge” in the Ethereum protocol. Now if you follow my blog articles you may already know what It is. Additionally, during my Illuminati travels I found out that this idea of real merge is also appreciated by other developers outside of Erigon so… hey, that is nice. But first let’s iterate what the current Ethereum merge looks like.
Current Ethereum Merge
So in the picture above is how the Current Ethereum Merge works in Erigon. Now other than the fact it is very complicated it also have unnecessary complexity. For example, the system below, stores Execution Blocks twice and it basically does 3 different syncs: Consensus Layer Sync, Execution Layer Sync and Consensus-Execution Sync. Where the Consensus Sync is the Beacon node syncing, the Execution Sync is the Execution Layer syncing after receiving input from the Beacon node and the Consensus-Execution Sync, where the two chains synchronize with each other. However, these 3 syncs are basically a subset of the Consensus Sync as the Consensus Sync is basically Execution Sync + More stuff, so these 3 syncs are unnecessary and there can be only one if things are done right. On top of this, the current Ethereum Merge is not a real merge because the two systems are not merged funnily enough. They work together but they are not merged.
Erigon Real Ethereum Merge
Now thanks to me that is building the Erigon Consensus Client (I am very humble), we can decrease the protocol complexity of the Ethereum Merge within Erigon, which will be still complex but less than it used to be. But how can we do it? With the Erigon “RealMerge”. Thanks to the Erigon Consensus Client I(and only me) was able to show that with a proper interface it is possible to completely disconnect the Execution Layer from DevP2P (apart from txpool) and have the Consensus Layer do all the work for history retrivial. As a matter of fact, there are two prototypes in the Erigon codebases: erigon-el and erigon-cl, erigon-el is a copy cat of Erigon but with EL downloaders disabled, while erigon-cl is the CL Erigon prototype. In this case the Erigon-CL takes care of the sync and as it receives blocks it will send them to Erigon-EL for sync-up. In other words we have only one sync: The Consensus sync. Just with this the protocol is already less complex because we do not have to keep track for 2 different network protocols and also to coordinate the two components, instead we can keep the protocol in a synchronous pipeline state where the Consensus “part” drives the Execution which is, instead, offline and does not need to give a care in the world about its peers and stuff like that. This is how the diagram will be updated by the way:
And it is not OVER.
YOU FOOL THIS IS NOT EVEN MY FINAL FORM.
As a matter of fact, now that the system is one we can just do fetching of blocks without using slow json rpc and we do not have to store block twice. EVERYTHING AND I MEAN… EVERYTHING IS NOW COMING TOGETHER. We can turn the Ethereum protocol in a pipeline, we can have good Execution Payloads fetching… you… are… too… weak… to… comprehend… my power.
I am going to sleep now, gn.
original post: https://giulioswamp.substack.com/p/2722023-ethereum-real-merge-in-erigon
