Long-term Decentralized Storage for Blobs

Thank you. So, good morning, everyone. Thank you for being here. I'm Leo. I'm a researcher with Codex and also from Megalabs.

And today, I'm going to talk about decentralized structure for blobs. Actually, it's very nice that we have this talk by Yannick taking us through time. And now I'm going to take you through space. So this is, yeah, the timeline of the Ethereum history. So we have the genesis block that occurred in July 30 of 2015.

Then we had the merge about seven years later happening in 2022. During that time, we had something in the order of 15.5 million blocks. And if you put all of those together, that takes about 427 gigabytes of space. Then in March 2024, we had the blobs, the beginning of the blobs, the EIP-4844.

And so between these two dates, we had the blobs, the beginning of the blobs, the EIP-4844. And so between these two dates, we had something in the order of 3 point something million blocks. And then since March until now, so about seven months ago, we have been generating blocks with blobs all the time. And in these last seven months, we have generated more data than in the first seven years of Ethereum. So that's quite a significant amount of data.

And to store the entire history of Ethereum right now, it takes about one terabyte. So basically what I'm trying to say today, if there is something that should remain in your head from this talk, is that storing the entire Ethereum history in every single node of the network is kind of unsustainable. And there are several things that are being developed. So one is the portal network, but there is also other ideas, and I want to show one of those in this talk. So there are some files that have been proposed that are called era files.

An era file is a file that stores about exactly 8,192 blocks, the state, and also some index data. Basically, one era file is about 27 hours, and it takes between 500 and 600 megabytes of space. So this format has been proposed by Jacek from the IFT. And the PandaOps team, specifically Pari, took all that data from the pre-merge, so it's about 15.5 million blocks, and put it on BitTorrent.

So this is the size of the data during those first seven years. Please notice that the blocks are between 50 to 100 kilobytes toward the end of that period. Now, if you look between what happens after the merge, the size of the block starts increasing significantly. We reach almost 200 kilobytes in average for the blocks. So during that time, we have about almost 4 million blocks.

And if you take all those blocks together, that is about 98 gigabytes of data. And there has been this proposal again by the PandaOps team to create like a beacon chain checkpoint sync endpoint where you can actually checkpoint sync your client directly from off-network sources. So you don't need to get all the blocks from the peer-to-peer network. You get all the blocks from a specific off-chain, off-network source. And now if you look at the blocks after the blobs, basically, there is a new proposal now.

It's called the ERB files, which are specifically for storing blobs. And there is no state on those files, but there is a KCG commitment included as well. You can see that during this time the size of the blocks have decreased because now we are going down to almost 50 kilobytes in size. So this is again a proposal by the Nimbus team and I think this is a great idea. And what we are trying to do now in Codex is to store this history from Ethereum in Codex.

So Codex is a decentralized storage that is protected with the ratio coding, with very reliable CK technology, and we are storing the entire history of Ethereum in Code in codec so that's basically all I wanted to present today and if you are interested well you can come to talk to us offline or in the Nimbus booth as well thank you thank you question time I love this part of the session question time so who's going first oh wow no question for Dr. Leonardo? Oh, wow. You're a good teacher. Are you a professor?

Sorry? Are you a professor? I work at the university, yes. Oh, no wonder. So your students are saying no question for you, right?

Oh, one question. Who? Can I see you? Who? Who is good?

Ask. No question? Who? Can I see you? Who?

Who is going to ask? No question? No question. Okay, so, doctor, it seems you gave such an awesome presentation. And what do you tell Dr.

Leonardo? Doctor, thank you. Help me. Welcome, and say thank you to Dr. Leonardo.