Nishant Das: What to expect from the consensus layer |14th Oct 2023 | Sunway University | ETHKL 2023

all right ladies and gentlemen we're going to learning about the consensus layer in ethereum and our speaker is Mr Nishan Das let's give our speaker a warm welcome all right the stage is yours Nishan take it away thank you hello everyone uh today I'll be talking about uh what we can expect from the consensus layer in the next hot Fork so some background um I've been in ethereum C Dev for many years so I've been working on the beacon chain since I guess 2018 uh the merge and now uh 4844 so I hope by the end of presentation you guys will have an idea of what I expect uh on the consensus layer and also what rollups can expect going forward so this is a small history of hard Forks in the contens layer so in December 2020 uh we had phase zero which is the beacon chain Genesis so that is when the deposit contract was deployed um you had uh all the validated deposits go in and the bacon chain finally launched in October 2021 you had Al Tire which is the next hard pork so this actually brought in light client support uh for ethereum so what what this means is that you had a new construction on chain called sync committees so sync committees allowed a subset of validators to ATT test to a particular uh beacon block route and using that you can build light client proofs so light clim proofs can be used by many applications some would be you know cross chain Bridges or uh you know people trying to build trustless taking pools um September 2022 was the big one which was belrix or better known as a merge by everyone else um the merge was uh in progress for nearly one and a half year I think uh we were testing it for the last 7 months of it to the launch on 2022 and and the last hard Fork that we had was on April 2023 called capella so capella was a hard Fork that enabled uh withdrawals and allowed validators to actually access their funds on the execution layer so uh today I'm going to be going through all the eips that are going into the neb so I'll just like uh go through them uh so EIP 4788 is bleam uh block route in the evm uh IP 7044 is a perpetually valid sign of voluntary exits EIP 7045 is increasing the max eation inclusion slot and EIP 7514 is adding the max Epoch turn limit and finally uh for the start of the show EIP 4844 which introduces Shard blob transactions uh onto ethereum Main so starting with EIP 4788 so uh what this does is that it this allows the beacon block route to be accessible by uh in the evm so any contracts on the execution layer can actually access this value so what what this is is basically commits to the has root of the beacon chain and you can use a corresponding uh execution payload header to you know know what was the past beacon block route so what is the main motivation is so that applications have access to consensus layer state so if you're an application and you're building a staking pool uh you would need to know the beacon chain header uh sorry Beacon chain route so that you can actually derive stuff like validor balances Val status updates and also um if you're building a cross Chain Bridge uh you know having knowledge of what actually is the finalization checkpoint is very important because using that you can you know choose to Min burn or redeem fund on either side of the chain so yeah um you know what I described so yeah uh moving on to the next one is EIP 7044 so perpetually signed uh validator exits so this allows a validator exit to be perpetually valid uh from capella onwards currently Val exits are only valid for two hard Forks so um if you're a validator and you want to exit participating from the chain you can't just uh you know stop ATT testing you basically would have to uh sign a voluntary exit you order to exit from the chain so um the main reason that we are trying to uh actually introduce this EIP is so that it improves the ux of actually creating a voluntary exit so right now staking pools have uh separation of hot keys and withdrawal keys so what could happen is that if you have two hot frogs on the line and the uh the individual that actually possesses the hot key they can actually grief the individual possessing the withdrawal Key by not signing a new voluntary exit so you could have you know fund stuck uh perpetually in the contensous layer so you know to prevent this ux degradation we allow uh perpetually signed uh voluntary exits to be valid for all future Forks so yeah um like I mentioned earlier uh you have staking operations where one party holds the withdrawal key the other holds the hot key so U you'll only now need to generate signed voluntary exits once and yeah okay we can move on okay so uh this is the next EIP EIP 7045 so what this does is that this increases the max attestation inclusion slot so right now um if you're a validator and you produce an attestation on chain you basically can only have your attestation included in um one Epoch or 32 slots so while this was fine when the chain had 16,000 validators currently right now on Main net we are running close to 900,000 so there is a lot of activity on mainnet and if your attestation is slightly late there's a good chance it'll be completely missed on chain so if um you basically can extend this uh what happens is that you can have uh late attests have their attestation included on chain so instead of being penalized you get a slight reward and um one main reason reason uh that we we're actually adding this is that for lmd ghost which is the fork Choice um protocol that you know uh ethereum uses uh having uh a rolling window of two Epoch uh for attestation inclusion uh it is pretty important uh in order to generate a security proof for it also uh uh consensus researchers have been working on a confirmation rule for the beacon chain so what this means is that instead of waiting for a finalized checkpoint to determine whether you know you can uh regard the state as completely finalized you can use a confirmation rule which tells you that in for slots under assumptions of on certain amount of hon a stake or network synchrony that uh the chain will not be reared so for that you we do need a increased Max eation inclusion slot so yeah uh like I I mentioned uh earlier if you're missing a lat sitations uh now uh you have a larger window for it to be included so the average validator would have a higher profitability because uh with these missing stations included uh you would have a high reward and yeah this is EIP 7514 so this adds a Max EPO turn limit so um what is a turn limit so in every Epoch there's a certain amount of uh limit that are validator uh number of validators that can be active on the beacon chain so this is dynamically computed by the number of active validators in the state so as a uh as an valid validator registry grows bigger from you know 16,000 to 800,000 uh the amount of values can be activated each par also grows uh proportional however um having this number too high puts stress on contensous layer clients so to uh prevent that uh we have uh proposed this EIP to cap this value to eight so by having eight there's a linear increase in the number of active validators on chain yeah so for the ecosystem uh what this means is that um you would have to wait longer uh if you put your deposit in for your valid data to be activated and uh finally moving on to start of the show which is the big EIP EIP 4844 so EIP 4844 introduces a concept of Shard blob transactions on ethereum Main so this is a completely new transaction type uh it is not a standard transaction so it will not be executed in the evm instead uh anyone one who wants to propose um a blob transaction we just to sign arbitrary data and submit it to the execution client so that would be a separate mle for blob transactions due to the fact that they're much larger than regular transactions so on ethereum Main a single blob would be 128 kilobytes which is much much higher than what is a you know normal ethereum transfer transaction so the main benefit of having Shard blob transaction is that this provides a cheap uh space for rollups to you know post the data in so um why have we decided to use blob transactions so uh very simply we need blob transactions in order to have it ready for full DK sharding so rollups before they aify they will need to upgrade once to you know instead of using call data you use blob data so is is it is better to set the stage earlier than rather than later on in you know a few years down the line when it'll be much more difficult for rollup to change the internal mechanics to use blob data so another advantage of having it now is that all execution layer logic uh required for full data shotting will already be in in ethereum main net in 4844 also uh another big reason is that it allows a separate fee Market for blobs So currently um rollups when they post data on chain they post uh in ethereum call data this actually competes with normal transactions which you know going to call contracts um if you want to do a swap transaction and stuff uh you're actually competing with all these big rollups who are actually trying to post the data on chain so by having a separate fee Market uh you can basically have a market uh solely focused on posting blob data on chain so yeah this is a summary of block Space versus blob space so in in both cases uh you know blocks are also seen by all nodes blobs also seen by all nodes uh theoretical limit um the highest uh uh the limit of a ethereum block is actually 1 Megabyte while the highest limit of uh the number of blobs in a block which would be six right now would be about 750 kilobytes um the big difference with 4844 is that blobs instead being stored in the execution client will now be stored in the contentus client um call data can be accessed via the evm while blob data cannot be uh one big difference is that um block data is stored forever while blob data has a window of 18 days so for that reason you know uh call data is expensive while blob data is uh much cheaper so yeah uh you know you guys can take a look at this diagram so this from brto Lambda so he he works with optimism now but uh this can tell you how exactly uh you know the rollup Centric road map will actually work after 444 so you would have you know all these separate uh rollups they'll be posting blobs and these blobs would actually be in uh individual blocks rather than you know as part of a normal transactions so um how do we attach blob into blocks so we use U what we call kcg commitments which is a pol nomial commitment scheme so why do we use polinomial commitments rather than something you know that is very standard like shat to 56 um the reason is that you know an arbitrary blob can be thought as a vector of 496 field elements so what this means is that any arbitrary blob can be can be represented as a polinomial so having it represented as a PO polinomial actually enables recovery using certain encoding schemes like read Solomon so this is a necessity for full dang sharding you know for D data availability sampling uh you will not have all the field elements available and you would need to be able to recover it for sha 256 uh it since it's a non-arithmetic commitment you cannot use it to recover these uh Missing data uh chunks so um one interesting thing in the consensus layer is that blobs are decoupled from blocks so when a proposer creates a block uh it'll broadcast it to the network and uh this block uh will not actually contain blobs it will instead contain the k kg commitment of these blobs so blobs and their resultant kcg proofs are kept uh you know in separate uh construction or struct you could call it uh is a blob side car so the blob side car contains three things The Blob data the kzg commitment and the kzg proof so uh initially uh the side card just consisted of um uh the kg commitment and the blob but because uh verification of kg commitments uh on a normal Noe take 40 milliseconds we needed to add a kg proof which brings it down to uh 3.5 milliseconds so also uh one restriction of having these decouple uh blocks and blobs is that uh blocks can only be processed when um um the respective blobs have also been processed by the node so the block will have to wait for the node to see all all the blobs before can continue processing it so uh one important question you guys might have is why have we decided to decouple uh you know blobs from blocks so um we probably can't see it from this PR but um this is uh the title of the pr is called free the blobs so uh the reason we want to free the blobs is because blobs are very large and uh a normal beacon block with six blobs would actually uh take about one megabyte in size so this would actually saturate band in the network and have negative effects on latency and band bandwidth consumption for all nodes so when you actually have blobs uh separated out into different subnets what happens is that you have separate meshes that these blobs can be gossiped in so but what happens is that you could have high bandwidth nodes in a certain mesh propagating these blobs and basically the blobs would um go along the path of lease resistance whereas if these blobs were coupled to blocks um basically almost every node would have to gossip them and you know certain nodes on the network are band with constraint so if you have a 1 megabit megabyte blob being translated um and you have someone with a 10 megabit up and down line um it'll take literally one second to just download the block so you know to prevent this sort of congestion on the n work uh we've decided to decouple them so uh having a smaller message size in the case of decoupled blobs actually allows for bandwidth reduction techniques so this is a implemented in the gosip player so with band mid uh reduction techniques uh they're much more effective If the message size is small rather than larger so yeah uh like like I mentioned generally you know um bandwidth can be used much more efficiently um you have independent meshes on all these blobs can be transferred on so yeah um this is um a nice chart from Anton from THX RX so this is a simulation that was done on decoupled and coupled blobs so on the left you can actually see the latency is much slower for decoupled or this coupled there is a largest Spike but that is because you know um the higher traffic uh nodes with which have a large amount of bandwidth uh this is true which all the blobs are being propagated on so yeah um you know this is a chart so you can see on how it works on uh wearing bandwidth capacities of different peers so so now uh we move on to what uh these sh sh blob transactions mean for the uh ecosystem so L2 is right now A bottleneck on posting data onchain for almost all l2s um the main cost that they pass on to uses is actually the cost of data that they post on ethereum mainnet uh call data is expensive it is kept forever and uh due to do concerns that is why its price is so expensive with chart blob transactions l2s have an Al ative route to post data which is through these blobs so these blobs are much cheaper um estimates have put it about 10 times cheaper than you know current call data um so for the Securities of l2s especially optimistic rollups you basically need uh the data to be available for at least 7 Days uh well currently for 4844 will be for 18 days so this actually allows um you know in the event there's a invalid state uh trans assertion you can actually challenge it effectively so 4844 provides you know cheap data storage um that you know all l2s can utilize um there might also be you know non L2 use cases for 444 um you know maybe some nft project needs a cheap and a you know less permanent place to keep uh the jpeg metadata or something so yeah um you this is a small chart uh from my colleague Terren um basically this is how um batch posting will work post for 44 you know so you know you would have the L2 batch poster they post the data batch to the execution client you know so the execution client will package it into a blob transaction then uh D when it's time to propose uh the contensous layer client will take this blob transaction and build up block with it using that you know you broadcast to the network um and you broadcast it separately to the network the blocks will be uh broadcasted as one set of peers while the blobs be broadcasted to another set peers and yeah I think that is all right thank you very much Nishan for that explanation about blobs I like the phrase free The Blob uh the only joke for the entire day uh all right let's open up for questions anybody got questions about the consensus layer CCE you got a question I we will pass you the mic he's just here second row you can raise your hand yeah there we go yeah quick question uh so uh is the data sampling Challenge and the uh data recovery implemented in uh 444 oh so no it it isn't so it is a big Todo so basically 444 is actually setting the stage for data recovery and data availability sampling but um it will not be implemented in Ford 44 but what for for does is that it builds like all the requirements for rollups to know use a cheaper form of storage so in the future when we do have full dank sharding um rollups won't have to change anything so so the execution uh layer client uh logic will be unchanged the only thing that might be changed will be on the consensus layer okay thank you okay thank you for the question thank you for the answer anyone else uh over this side oh I'm so sorry I didn't see behind me can pass not him he ah him he was pointing to him yeah the guy in the black at the end please introduce your name as well as your question thank you hey thanks for the talk um lib I got a question regarding for 44 like why do you think that it should be a h for why is it like a EIP why isn't it like a side car that is an optional add-on CU it seems like cuz like the history of a theum is that you let the protocol layer be as flexible as possible but this seems like a very application specific thing for like blob transactions for l2s why don't you keep the layer light and have this side car optional side car just like PBS and then enshrine it in the event that it does become popular I mean um if you do the ladder you have issues like Lio popping up so but uh one reason we want to do it now is that uh we do understand that you know ethereum is being used for rollups a lot lot more than it was two years ago there's a definite need to have you know cheap rollup transactions you know even though it's a bare Market um so at least having this set right now would actually allow uh rollups to you know upgrade using uh this blob space rather than you know uh the cheap call data I cheap but call data that they use right now also um a lot of things uh that rollups require uh do need a hard fog so you can't actually have it optionally so like they need some evm op codes to be implemented so that they can actually determine what is the gas price of blobs and stuff like that so I don't think it can be optional gotcha thanks thank you for the question anyone else raise your hand oh we got one got two over here yeah go ahead and then we'll pass it to the bank yeah regarding 444s well how much of a performance degration does um 444 has on the contested clients um so there there was significant uh bandwidth issues with the old design where uh blobs and blocks were coupled so after decoupling it there might be a slight increase in bandwidth but due to blobs you know being broadcasted separate meses uh it is a lot less than what it was before so in terms of block processing times the only uh gotcha is that U because blobs and blocks are decoupled uh all clients will have to wait to see all the blobs before they can process it so there are certain edge cases where you know a malicious proposer could just uh broadcast this block with these kg commitments and it will not broadcast the resultant block blobs for those you know so you could just have you know the client waiting to see the blobs but um yeah that is you know one possible uh downside I could say thank you uh sorry one more question uh regarding 4788 um is the contract going to be introduced as a PR contract or is someone going to deploy that contract and make it trusted yeah so from what I understand it'll be a pre-compiled contract it's still being audited but uh yeah that's what I understand thank you for the question I can pass to the gentleman at the back do ethereum developers ever laugh when they say can I see your blobs uh just it sounds very funny okay please go ahead sir thank you I think you touch a little bit of the in your previous answers uh so my question is uh you you mentioned that the block and the block will be detached and propagated separately right yeah and then um and you also mentioned that the block cannot be finalized if you don't receive the block right so does it mean as a consequence we won't be having two Epoch finalization oh no no um so there a separate thing um basically if let's say a malitia proposer broadcasts the block without the blobs it will not be inserted into like the client's Fork choice so the fork choice is like you can think of like the internal like linear chain internal chain that a node uses to determine what is the head so you know the blob doesn't come in it's not processed at all just that there's a there's a weird case where it waits for the blob in order to be processed so there's a timeout I think that's implemented all clients you know if after X amount of seconds um you don't see the blobs you just drop the block yeah thank you anyone else want to ask a question about blobs oh yes in the front yes come come ah we have one in the front here if you don't see the blobs drop the block yeah I'm going to remember that write it down on my Instagram it's not about blobs um so you've been as um like corab for a long time and you probably realize there aren't many corn ABS in Southeast Asia um for those who want to be a corn da um in the ethereum space do you have any suggestions yeah so um ethereum has this really cool uh fellowship program so a lot of I think new people who join development they have actually come to the program so we have actually hired a few people who have participated in the fellowship program and using that they're not part of prison so you know if there's anyone in this room who's actually interested do definitely do check it out uh we have a lot of cool projects that you know maybe core developers can't focus on but uh they have been picked up by you know all the fellowship uh participants and they've done a great job with it so you know if you're cev and this is something that interests you you can definitely try that great thanks anyone here interested to be a Cod for ethereum oh we are oh some yeah join the fellowship program you have a fellow he's a fellow oh he's already a fellow that that's fine any last questions before we wrap things up anyone else want to ask something yes okay Y come come come when he ask question it sounds like interview but it's okay it's okay questions are good sorry that it sounds like don't don't don't don't apologize we still got 5 minutes please go ahead okay I wanted to ask what's after dun so on the execution side there has been talk on EF and voal tries um specifically more interested in the voal tri site um if let's say voal tries were to be implemented what are the changes that the consensus site should take note of yeah so uh for work tries um I don't think the contous layer has to do many changes um probably due to how you know V Tre be bootstrapped uh that' be one concern but I don't think off the top of my head there something we have to worry about I think there has been talk on including proofs in blocks itself so I'm not sure if if if I if I still remember correctly um do do you have that on that yeah there might have been conversations but uh I'm not too sure about that okay cool yeah okay thank you very much anyone else going once going twice three times let's give our speaker Mr Nisha Round of Applause