EIP4844 from CL client's perspective by Terrence Tsao

Hello everyone. Uh happy 420. Thank you for um coming to my talk. I am uh Terren from um arbitron. I work on prism.

It's a consensus layer client and um written in go. So today I want to talk to you guys about the next scalability upgrade EIP44. I'm sure most of you guys have heard at this point. So let's get started. So um outline so you can't really talk about scalability without like talking about the ROP century road map right and then after we talk about the rob map we're going to talk about EIP 444 like a quick overview very high level what is EIP 4844 then um at three and four I'm going to be a little bit more technical and hopefully it doesn't become too boring so I hope to spend more time on one and two and on three and four I can quickly just like um just like s through it and yeah if you have any questions feel free come find me after.

So refresher what is this row of central road map. So triangle you guys have all seen this triangle before. Essentially the triangle basically says that we have three points. We have scalability, we have decentralization, we have security and it's impossible to hit all three points, right? So you have to make trade-off and the trade-off that Ethereum makes today is that we are decentralized and we're secure but we are quite slow, right?

And this is part of our DNA. We don't want to sacrifice security and decentralization with speed. So this is where we operate at the bottom. And this is Ethereum today. We process about 25 ERC transactions per second.

15 50 50 transfers per second. And then there's a you can do a few like very fancy transactions here and there. So average about 10 10 transactions per second. So now the question is how do we increase the TPS? How do we increase the block space?

How do we compete with this like global internet of value, right? And um if you look at Visa today, Visa process $3.9 billion dollars um of cards worldwide, he process about like $80 million 80 mill transactions and then like $255 uh billion dollars of total transactions blah blah blah, right? So this is visa and then how do we essentially um compete with this like internet global of value and unfortunately so the hard truth is that you can't right because like we are not willing to sacrifice decentralization with scalability so what do we do here right so we cannot increase the block space we cannot increase the gas limit and um we and then given the decentralization is in our DNA and um so here comes comes the rob central road map. So um a good analogy that um Ben Agent was um said the other day I think it's re it's really relevant is if you look at Manhattan right it's some of the most expensive real estate out there but because of like economic force right you you make people start making taller and taller buildings you are packing more stuff on top of it and um and then the land is still very expensive but you afford to pack more stuff in there and um I think the similar um analogy could be also translate in in into our road map.

So today with layer two you have your 10 transactions per second on layer one and then you have layer two which is use layer one as code data and then layer two are able to process more transactions because of with different security trade-offs and then it's optimized for throughput and UX right and then but layer two and layer one still shares the same same security layer two cannot rock you for example and then on the other side of the spectrum you still have like apps that are willing to settle on layer one they because they still want the security of of layer one and then they're just paying a little bit more. So this is what the row of central road map is and then um with EIP 444 instead of using code data previously we are giving a new type of data that's called blob data and blob data can enable um people to um process more transactions because it's cheaper and which I will get into more why why but then if there's one thing to remember is EIP44 uses blob data and then blob data enables layer 2 to process more transactions per second. So how do we go with code data to blob data without sacrificing decentralization right so that goes back to my earlier point that we do not want to sacrifice decentralization but here we're actually processing more transactions so what do we do here right so that's so this is where I'm going to go a little bit overview on EIP 444 what so what is EIP 444 how does it enable you to process more transactions without sacrificing decentralization ation. So this is the image. This only thing to remember just remember this image.

The EIP44 bolts blobs onto the block. Right? So blobs are not part of the block. Blobs are not inside the block. So blobs are bolted in the block.

Remember this mental image. And then so how does this work? Right? So this requires you to um be computationally binding to a block. Meaning that if you commit something from the blob into the block, you cannot change it later.

Right? So you have this like computational binding scheme for example like shy 256 m root polomial commitment. So it uses some um binding scheme to ensure that once you um bolt the blob onto the blob that cannot be changed later. So what are commitments right? So commitments like shy 256 um micro tree kcg so for um yeah before we're using kcg commitment.

So we're using kg commitment. So we take the blob we run through some U KZG hashing functions we get a commitment we put that in the block and then we run another hashing function and put it in the payload which is used on the execution layer and then um we want to use the hash because it's 32 by we want to be EVM friendly and then also one nice property of this is that it it basically enable us to verify um the blob's interiority later through EBM very easily. We just we basically call that just to open a polomial at any point. So here are some comparison of block versus blob right. So block are seen by all the nodes.

So is blob blob are seen by all the nodes. So you have this like so they're both like they all they all basically have to pay this net net network bandwidth to to get the both objects. So the block are one metabit theoretical limit today and then blob are 128 target 256 KB max. So EIP59 style. The blob are stored on the execution client.

So like G, nethermind and then the blob are actually stored on the consensus client for example like lighthouse like tagu nimbus and then so the last three are the main differences and the differences are the reason why the blob is so much cheaper right because the blob has has EVM access so that means that you have to pay compute power to access through EVM and then it's also store forever right so for example if you pull some you put a code data out there all the nodes have to store it. So you have this like longevity cost for basically for all the nodes and then right now it's 16 guests per bite for blob. So this is a blob you don't have EVM access. So blob actually cannot access the EVM but blob can actually access the proof of of of the blob's integrity and then you only need to store for 18 days. So this is mainly used for the ro challenge period.

So given that it's 18 days and then it can be DD later that's why we're able to price it relatively cheap right so on the block you have this EVM and gas and on the blob side you have this um cheap uh uh data gas so what is a blob transaction so the blob transaction is essentially a transaction with all the um data or opet data it's submitted to the existution layer meu and then it's gossip among all the exist transition layer clients and then he has new transaction type 0x05. It has all the usual data field like nons value code data and then it has this new field it's called block version hashes which allow you to verify the commitment scheme and then it's encoded as SSC instead of RLP. This is the new u pashing algorithm that consensus layer client has been using. So this is how end to end will look like with layer 2. So EIP 444 like I feel like that's something that you and I probably will not use this type of thing because the data will be deleted later and the EVM cannot access it.

But turns out this is very useful for layer two to to basically post data on chain right. So as a layer two you have your sequencer you have your batch poster you you basic essentially you gather all the transitions data and then you you compress it you batch it you submit it to the layer one execution layer client manu and then execution layer client um gossip those data together and then on the right hand side you have your consensus layer you have a validator so validator wants to propose a blog it gets a blob bundle it signs it and then it propagates it among all the consensus layer peers right and then consensus peers also verify the blob is integrity with their own exition layer client and then on the layer two side you have also your layer two validators and then your layer two validators are actually the ones that's reading the blobs verifying so therefore you have layer two coming to consensus with each other verify that no one's cheating and on the right hand side you have your layer one coming coming to consensus with each other so yeah it's it is quite beautiful so I have about seven minutes so I'm going run through um some of the consensus layer notes. So it this might get more like nitty-gritty and stuff like that. So just bear with me. So what are the changes here, right?

The changes here are the blobs are store for 18 days. Okay? And there's like not that many economic incentive for you to store data for 18 days, right? For example, like today I can just be like, okay, I'm supposed to store for 18 days. I'm going to delete it like one day later.

I I don't care. So um there's no way to really enforce that to like slash you to make you lose money, right? The only thing we can do is like as a peer I can ask whether you have a blob and you say no I don't have it. Then I was like, "Okay, well, you are a shady peer. I'm gonna drop you from the network."

Right? So like something to think about is like is there a better better like incentive alignment there? Like can we do something better there versus just like this honesty assumption that we trust like those will store 18 days of blobs all the time. Maybe we can have some like data retention policing something like that. Also right now for the consensus client we're syncing from which subjectivity checkpoint.

So if we do that we also have the back filling all the blob. So those are some of like the some of the storage nodes I have and then you have your new for choice rule right. So for now if you import the block the block can be valid or not but if the block is valid you're safe and the block should be safe in the DB but in order to do that you have to make sure that block must have like blobs on the side as well. So that means that you should not be importing the block unless you have the blobs. So uh there's some implementation complexity here where you have to like kill the blob until the blob arrive or you have to kill the blob until the block arrive.

So you have to kind of wait for each other. So you have this like state machines basically you you have to play and then for blob syncing as well to sync to the head of the chain. So the blobs are sync alongside the blocks. So there's two ways to sync. You can do syncing by range meaning this is more like longrange syncing or you can do syncing by root which is more recent meaning that I'm just syncing each blob individually versus syncing by range means that I'm syncing the blob like through like 512 times at once and then the peer will also reply uh resource unavailable if the they don't have the blob but doing that they would get discord and then you would just drop the pier.

So it's important to care for the like what to care for basically what you request. So you don't want to request data that's outside the 18 days window and then so you also gossip the blob as well. Yeah. Just say if you're the head of the chain you propose a blob you propose a blobs then you have the gossip among your peers and then all the blobs are propagated in parallel. So you have different matches of blobs and then once the blobs gets verified you you basically rebroadcast them.

So there are very like fun like engineering traits that you can do to optimize bandwidth and um yeah I'm really looking forward to working on that and then blob storage. So each blob is stored for 18 days. So the upper bond is that as if you're running a node today, it's gonna you're gonna um have an extra 67 gigabyte assuming the blob is always filled. That is very unlikely. That means that Ethereum gas will be through off the roof and then we'll be burning tons of EV.

So 67 GB is the worst case scenario and that we likely will not get there. And then the block and blob separation also enable better persistent storage design meaning that you can store your block in SSD because that's something that needs to be fast and then you can store your blobs in hard drive because that's something that you probably will not read very often. So lots of client implementation details here and then blob retrieval. So you want to get a blob, how do you get it? So there's so there's an API for that.

So you can get you so you can get a blob whenever you want. And then there's uh utilities written by um uh written by MPI on blob utils. And then there's a blob scanner as well. So you can actually view the blobs online. So blob signing.

So validator signs the blob. So validator will get a blob from the API. You will sign with this new domain domain blobscar. So um one thing that's interesting is there's no slashing for equivocation. So um if you sign double blobs you will not get slashed but you are at risk of missing the blog because say today someone requests your double blobs because you can only have one blob per block right so you cannot have duplic duplicated blobs per block.

So if you today you double sign then wherever if the node gets the faulty one first then then then the note will not process your block. So it's more like a economic enforcement to make sure people don't double sign versus like a slashing condition and blob publishing. So as a validator you publish the blob you go through the beacon API and then stop you submit it to the consistenc client and then consistency client will broadcast it for you. And then uh with me boost yes about 95% of the validators today uses MV boost. So that's something that we're still trying to figure out.

So definitely watch for the PR on that. One open question is that should we um have blind blob sign or should we have full blob sign? I guess it depends um whether like you think the blob can be front run and then also latency matters here. So the earlier we can design this so test is the better but this is still like a open question right now. So okay EIP 441 now.

So where are we today? So we have the spec. The spec is getting ready to be finalized. We have the execution EIP spec. We have the APIs.

We have five consensus layer client implementation. We have four execution. Um we have four execution client implementation. So I would say most of the clients are ready to further testing. We have launched four dev nets.

So devet 5 is coming in two to three weeks. We have some tooling. We have blob scan and then we have kcg ceremony which is ongoing. So you haven't participated in the kg ceremony please um yeah please do it. And then some devet history.

So here are the deathnets. So we started from defet one which is a prism get only and then we started devet two we added this data gas and then we started defet three which we based on top of shanghai withdraw and then net 4 was the latest one which we have this blob syncing like so all the clients were able to sync blobs and devet 5 where you essentially it's a new approach we decouple blobs and blobs ts and ts me hardening. So blob v4 will come in uh blob v5 sorry will come in a few weeks. Okay, so last slide. So how can you help?

Right, so if you want to help, if you're interested, you can follow client progresses. There's weekly implementation code, EIP4844 weekly implementation code and then we have uh follow the R&D sort channels. You can run client test softwares, find BS, open issues and then or just write bloss um education materials people are usually uh very appreciate when you do that and then look out for bunties, grants and everything. So yeah, that's it from me. I will um this is the last slide.

So this is blobfish. So blotfish is the official m blotfish is is the official animal for 444 because of blob because of blob space. So yeah, thank you for listening to me talk.