Hello everyone, this is Giulio. I finished all of my university exams 2 days ago and now, I have more time to work on the Ethereum protocol again… In the midst of all of this, I may have not been able to post as much as I wanted to, however, I was able to still commit some code and have been working on Database footprint improvements and Beacon state transition for Erigon’s internal ETH2 Consensus. In this post, I will just post a bunch of updates on the above.
Beacon State Transition.
So far, I implemented all processing for single-slot transition for the Altair and Bellatrix forks. Unfortunately, Phase0 has this weird epoch storing mechanism which caused me to back down from working on it for the time being. What this mean is that we can a working full client very soon which will only work for intra-epoch blocks as full FFG has not been implemented (Although there are some pieces of it scattered around the codebase). In other words, now I implemented functional ETH1 Deposits, Slashings, Attestations verification and proper participation tracking. As of now, the prototype is probably far from being efficient as I have nearly 0 caching going on, but hey, I am working on it so hold tight :). Also I implemented a bunch more methods in my BLS go library to handle single signature verification and message signing. In terms of Algorithmic complexity, I think I can improve the state transition function as described by the specs so that it is not too computationally expensive (although I doubt that it will prove to be a bottleneck aspect. In conclusion, I almost have a partially function Beacon state transition function, or at least all of the puzzle pieces are done, I just need to make the puzzle itself now :). I think that for the time being, It will be a light full node that will die every time it has to process an epoch transition.
Thanks for reading Giulio’s Swamp! Subscribe for free to receive new posts and support my work.
Database Improvements
As you may recall from a previous article, I was able to store the whole block history of the Beacon chain in 70 GB… well… I improved on that :
Previous footprint
And now after optimizing Aggregation bits storage, I was able to bring the whole thing down to 63 GB, while still avoiding the use of any data compression algorithm.
On top of this, this is hot database data, I estimate that if I used Erigon snapshots or a static data model I can reach 55-57 GB as that is the footprint of the plain text dump of all the database buckets concatenated of the current data model. Overall, I think I am competitive enough with Beacon block storage. I think the real beast will be figuring out historical states storage.
Das ist alles.
original post: https://giulioswamp.substack.com/p/03022023-erigon-cl-beacon-state-transition
