EIP-4844 Implementers Call #14

Transcript

foreign hi everyone uh call 14 now for 444 um couple spec uh items on the agenda today and then uh probably makes sense to chat about uh devnet4 and um yeah how we how we see things starting to shape up for devnet five I know there's also been some uh updates on uh or some more blob uh or call data sorry large block spam tests uh so it probably makes sense to quickly cover those as well and then we can discuss anything else people want to bring up but maybe to start a movie

uh you had a PR you wanted to uh go over which is basically uh the one which introduces the Nab in the CL specs and uh as for Forest part of that oh we can't hear you Mophie if you're talking you're unmuted but oh is anyone else on the call have a

oh sorry and I posted the wrong one in the chat um is anyone else on the okay no sorry actually that is the right one uh so this is like the beacon API sorry yeah I think clients should already have this implemented because you would need to in order to uh like participate on the devnet for example I think this is more about just like getting the spec getting the spec updated so that we can um work on top of it with some other Beacon API changes that are going to be necessary for block and blob decoupling um and so that would be the blob signing

individual blob signing um which I think generally we have to your side what that looks like cut it anyone like I would say that the lynx PR requires like um more of a rubber stance than anything yeah okay but the like we don't yet have a PR to add block and blob signing I think that would be the next like to do thing and that's something I can work on today um a general like sort of structural

question I would have with that is do we want like sending like submitting signed blobs to the beaconode do we want that to be one blob at a time I'm assuming yes since we can gossip them like we'll gossip them as soon as we get a single sign blob so I'm looking at the pr I assume this is um yeah blob style car so does this have to do with validated client or this is supposedly for end users to retrieve the blobs icon sorry I'm pretty I'm a little lost here yeah

yeah I think the the existing PR to add a get blobs endpoint that's the one that's more like um uh for outside the validator flow blob so like how we have two separate get block and get Block endpoints um so I don't think anything related to the validator flow is in a PR from what I've seen yet okay well we should add that to a PR basically because now they're the coupled so yeah yeah I can I can work on adding validator specific logic to that spec um today over the next couple days

okay build for the signatures and then for the validator uh Behavior that makes sense cool um okay and then Mophie you had oh a second one that you just closed uh which is a duplicate of Roberto's very old PR uh last year or sorry Jimmy's PR from last year um do you want to maybe give

some background on that do you have a mic this is the one that um Terence just referenced oh okay got it got it okay okay so so this one um yeah this is more the user-facing one outside of our data flow got it so it's not it'd be nice to come to some sort of consensus around this one but it's not like it's not a blocker for us uh interrupting or anything I think Crystal has a version implemented it may not be the version specified but it's the version that blobs um scanner is using I think it was like a Pakistan project from um from Defcon and uh yeah and then we

actually launch the blob scanner back in the mf4 so people can see what the blobs look like so yeah it's definitely using some sort of API but I'm not sure if it's this one so yeah we should probably finalize this and then so so the clients can arm it so the clients can um implement it okay and I guess and then does it make sense to just keep iterating on this PR uh to finalize it or do we want something like to reopen a new one I know it's it's fine yeah yeah maybe I can like peanut I'm gonna leave a comment right now just to follow up and see how to firstly for it

for it yeah okay sounds great okay and then last one uh Freedom blobs uh so this is the blob and block decoupling PR by Asic uh that just uh that he just put up um yeah uh Terence you had added this on your agenda so I want to give a bit of context here sure so uh back in the interrupt week we this rock consensus to uh the couple block and blog so for optimization reasons I think they have been brought up a few times last week already so uh

we have been iterating on the design dock so now we're moving from a design dog to the pr itself so this is more like the official way to get this uh merch basically so highly recommend everyone that's interested as implementing to review the pr the sooner we can um come to consensus we can merge the pr the client can begin implementing it then we can move to death at five so this is probably the biggest blocker before definite five so yeah so ideally I think a client can probably need two two to three weeks to implement this so so I think the sooner we can merge this the better so yeah please review okay and then yeah then he says he'll

he'll review this today can I ask you a question about this yes please I just want to do a final gut check that like this is something that must go in this first release of 4844 and like I guess the question I'm thinking through is like what is the incremental cost of uh saying this is something we're gonna land in like the next hard Fork when we increase the number of bugs and we have kind of more justification for needing these efficiencies uh I'm in is the question like does this solution

um I guess do the short term costs lead us to a quicker I guess step two as far as blob decoupling and I think the answer that's yes I think it's it would be a lot easier to do this decoupling stuff now before we have like production implementations of all this stuff um then it would be to like fully productionize a couple design and then move to something like this when we want to increase the number of blobs we're handling um generally my two cents is like the decoupled design is uh more flexible too which

helps us with the fact that it's really difficult to gather information about like what this type of stuff looks like on minute like um I think that's one of the things we're having trouble with is it's really tough to model exactly what like uh such a dynamic and diverse Network looks like when we're making like radical changes to it and Jesse so I think the answer is at the current blob targets the sizes like we could probably Ship Without this but given the complexities of once you ship something changing it isn't just

changing it it's like very carefully manipulating and modifying it through a fork boundary that you know there's a probably a major com if if that's where we're going anyway there's probably a major complexity saving and doing it right now um I think is the core of the argument but we don't have incredibly good network data at this point so um the the the must or should here is not even that clear yeah I think that makes sense I mean all that makes sense to me I think the thing that I'm just wary of is between this and the SSD migration it seems like we're adding in a lot of kind of like now is a good time to do a significant engineering investment in the future scope which I

think is totally reasonable and I just want to be like given our other goals around kind of like urgency and getting this out to scale I I want to just be like a pressure test on do we need to do it all right now are there ways we can chunk it up into like multiple releases that can make sure we're balancing kind of the speed with the long-term kind of foundation Investments well one thing I'll say about that is um The Blob decoupling is a lot of consensus layer work and the SSC migration is a lot of execution layer work so they're not like directly stacking on each other um it generally seems like it'd be

better to make these changes sooner um yeah I think it's also what mentioned in the El CL plants are also working on the blobs TS man pool so they will take a little bit time there so we can also use this time for for uh for um for um the coupling all right and I guess I don't know does any one on a client team or feel strongly that we shouldn't decouple yeah I mean I think this is mainly a

consensus comparing team issue yeah because this client teams are comfortable with it it sounds like we can land it um but I think some of the some of the SSC related changes will percolate up to the consensus layer a little bit it does sort of change the execution payload format for example but but admittedly it's it shouldn't be a giant burden on the consensus layer but it is looking pretty messy on the execution layer I have to say yeah Dan crab yeah I mean like I'm I'm I still want to like highlight that I still think the decoupling is I don't know like uh we're discussing this it is a

complication and so far we don't even have any data that says it actually improves things on the networking layer it's just like some people think it is and from what I hear the first simulation actually don't agree with the situation um not that I trust any of them just yet but um yeah so and I know yeah talking about the simulations we said we would uh kind of discuss them on the CL call this week um and and and kind of use that as a way to inform this decision in terms of like the next two days beyond that does it make sense to just review the decoupling spec make sure

that like assuming this is the way we would want to go you know people are happy with the pr um and then we can discuss it on on Thursday's call uh hopefully with like a bit more data and and see from there if if we think it's it's worth going there it does seem like most of the client teams want to go that way but um yeah I don't think we need to make this decision today but it would be good for people to come to Thursday's call at least like fully understanding the spec that's being proposed yep that's how I'm thinking about it okay um can I give one more question yeah so so I see in the comments that there was

discussion on the on this aggregate proof uh uh I mean in hack MD but I don't see that there was decision what to do with uh with um with aggregate because in this new proposal there is no more uh place to put uh segregate is it was there a discussion about that so is this sorry is this the uh how we verify the validity of each blob and if we verify a blobs individually versus like an aggregate is that what you're asking about

uh well there was let me use so so in this so I'm talking about this full request that is called to free the blobs yeah it's three two four four and uh it suggests to remove blobs Sidecar container that previously contained at kcg aggregated proof again in the new proposal there is no more this container and automatically that means there is no more the Aggregate and you have left the comment the suggested to to basically drop this kcg aggregated proof entirely and just

stick to to individual ruling of each blob and in hack MB notes I see that that there was actual discussion about that but it seems there is no decision uh I mean one question is is there a particular solution for that or was discussed and another thing that it seems that this poor request not I mean it will take a bit of time to fully complete it uh there are some missing parts so okay so we we had a bit of a discussion on this um I think the current not finalized

plan is to switch to individual proofs uh in general and also provide a function that does an aggregated verification but without using an aggregate proof so we don't do aggregate proofs anymore but we do provide a method that gives faster verification if you have a bunch of blobs at hand uh and the the reason we it's not final yet is because we're kind of sort of like benchmarking this technique there is also a PR opened by dank red on the consensus specs so we want to Benchmark

it see if the verification costs are reasonable and if they are then I think that's indeed the plan to move forward with individual proofs for each blob so that they travel nicely and isolated um okay yep I think that's I'll need to check this uh they said there is a separate uh pull request in the in the consensus spec uh wrapper correct for this yes yes okay I mean it it kind of removes the aggregated kcg proof thing and it changes the verification function to work with individual blobs

and it also exposes a multi-verify function that amortizes the verification of this individual proofs okay I'll check it because I was thinking about categorizing this aggregated proof function and it wasn't very friendly for that but yeah let's let's see I'll check this another request thanks it's still slightly rough like it's not yet ready for marriage it's just a proof of concept I would call it but uh it can give you an idea of how the verification works now okay okay thanks uh there's a question in the chat George

about does this mean any changes to the El side proof is that the uh you mean the transaction is it about the transaction yeah yeah yeah yes yes it does yeah so the transaction would also change to individual groups in that case so instead of having one proof uh for other blocks you would have what one per block but there's a function to verify all these tools together questions Murphy you would think that we don't need to do this and you're right that we don't need but I guess the idea is that we don't want to have two different approaches one is on the yell we do aggregate proof and on vcl we do individual proofs so for the sake of

keeping just one code path for everything I think it makes sense to unify both approaches anything else on this front I think from our side we are gonna do some benchmarking this week and I think by next week we should have uh more more data on the verification costs and uh whether we can go forward with this I think we can but we just want to make

sure sounds good uh any others oh sorry uh Mophie has a comment uh Mophie do you have a Miker still no um I see what you mean Murphy uh you're saying that we were using the aggregated proof on the El side to do Express verification on the mempool and with this new approach we will not have this Avenue yeah I guess that's again a part of the

we need to Benchmark it and see if we can if we can have it fast enough to to Warrant this change that that's a good point and so sorry actually I thought I thought we only want single block transactions on the mempool and uh that's one common and second comment is that uh I think the difference between the two is very minor like that will be like hundreds of microseconds but we still need to uh pass blobs from yield side to seal side and verify it

somehow before right sorry proofs from El side to CL side why blobs uh I mean pass blobs to from your side to Shield side right and when we're constructing blocks or when when would you ever do that only if you're building a block right serious site requires it to [Music] um in the request we get blobs bundle right and this bundle should not contain any incorrect

blobs and we verifying them on your side using commitments and proofs right yes what is your question it seems like uh we're changing schema not to have any proof like that am I correct no we have proofs it's just one proof that blob rather than one proof for other plops but they can still be verified efficiently but what is this um one block per transaction thing I I didn't know about

this this change I thought we have multiple blocks per transaction blobs per transaction in the mempool in the member yes well I mean my suggestion is to make the mempool as simple as possible and to only support exactly one block per transaction in the mempool and all other things have to go through and to get into blobs in some Works into some other way is there yeah what is the argument to have like multiple blobs especially in like this release to have multiple blobs per transaction because there's only two Macs per block anyways well in the in the Block in the

blocks we support them it's just for the mempool I think we want to like minimize the dose factors and everything and one way to do that is to like not allow multiple blobs for example otherwise I can do things like cancel one transaction with four blobs with a transaction that only has one block and only pay for the one block like stuff like that yeah yeah so yeah I agree with you yeah so I guess I've tried to understand what's the reason why you would want multi-blob transactions in the mem4 given that the most you could ever get in one block is like two like obviously there might be some small games I I am hoping that we'll have more than two you know but

the max is not too right anyway okay got it and also also we want to change that right we probably won't try to present but yeah but I I don't understand what you mean you mean that like there can be transactions on the blockchain with more than one blobs but on the mempool they have they are decoupled or you're saying that we also decrease the max blocks per transaction to one no only on the mempool you cannot post transactions with more than one that's all no consensus changed this thing is in the aspects like that's how the El is implemented right now or this is a change that comes with the

freedom Lobster so this would be yeah sorry that's nothing nothing to do with the free the blobs thing no this these have full Focus transaction tool design and whether that is a like reasonable ux restriction to achieve anti-dos in a simple way I understand you're right you're saying Builders can still build blocks with more than one blob but for the mempoolers we don't allow it and how did these okay let me ask a stupid question how does this transaction reach the block if they don't go through the mempool

through a private member right like something like a like Med boost basically I see okay yeah yeah uh Lucas I have a question because if we are having different roles consensus rules and different mampum roles aren't we discouraging people from using mempool like in the first place is that a well we already have yeah we already do this right like we already have restrictions on the max transaction size will gossip so this is basically the same thing right but so the short answer is yes but it's something we've already done and I guess there are implications here though

I mean if you if you do have that as a restriction on the mempool then at a certain point given certain demand and usage of blobs like local blocks will never be built because they're just missing an entire like dimensionality of the fee Market um exactly so you're like pushing people more and more towards uh Mev and the builders and stuff which you know there's uh I would argue that there's some health penis in the network if if local building local blocks is at least you know comparable to that and can compete in some way it will lose most of the

time but at least can compete and here it can compete even less and less with time and I guess then the question is like how how big of a use case is it to have multiple blobs per single transactions right like if that's the default use case for whatever reason then most blob transactions don't make it through the mempool if the default use case is one blob one transaction um then most of the the blog transactions would go through the public mempool um so I don't know if anyone has a intuition for like yeah I mean that's that's very unclear if that's going to be the equilibrium it just depends on demand across different

Roll-Ups how they choose to use it how things are being bundled um you know one roll up is dominated dominates the activity then you know you would not see one blob transactions building I mean if the Dos is the worry can't we also just introduce a replacement role that suggests you need to pay at least as much data gas as you did for the replace transaction so that was uh Peter idea to allow replacement of blob transactions with 100 gas increase right a fees increase instead of standard like 10 yeah it's related but it just I think that we also need to

capture the case where you replace for example a four blob transaction with a one block transaction or a zero blob transaction so I think Temple wouldn't allow zero block transactions that was the the point but you could replace you could basically replace your um blob transaction with another transaction type from the same account to the same nonce um it's not a zero Bob transaction but it is a H well uh what Peter was suggesting is like do not allow that right yeah yeah yeah I guess I guess that's basically

what I'm saying let's just not allow replacement with it with a transaction that dramatically kind of reduces right um it seems like this restriction of only allowing one blob is a little Overkill yeah and Peter was proposing to allow such replacement only if transaction is exactly the same only the price is different so it wouldn't be possible to to change anything inside this transaction except of price so my point would be um because I'm not sure how if there is anyone outside of the mind okay I see people from Basu but also people from um from guests should be involved in this conversation I'm not sure if anyone

is here working on transaction pool so uh yeah that's kind of a bit pointless to to have a yeah to have decided something without their input right yeah and um yeah trying to like bubble back up uh so this is the reason we sort of ended up in a surrounded Hall is mophie's question about uh the aggregated proofs and and if it's even uh like if if the performance of like always assuming there's Max one block per transaction is sufficient is that right I mean like um we originally introduced

the aggregated proof uh technique just for the mempool to be faster so yeah if we're switching to one blob per transaction on the mempool which I don't know if it's a good idea or bad it makes even more sense to switch to individual kcg proofs because we don't need the aggregate one for the mempool anyway yes okay so again I'll follow up with Geth uh about this offline and um yeah see if we can either discuss this on next week's call here or uh either all core devs uh next week yeah

um sorry just to understand this this whole discussion about the blob one blob per transaction man cool thing is there a PR or something or is this something that I don't know yeah so uh there's Peter's like transaction pool doc from Austria but um there is no spec for uh for the transaction pool right it's not something that's under consensus so there's not actually a spec of it anywhere um and different clients obviously and you know this is the other thing is different clients can choose to do different things um obviously like for something like this you know it'd be good to have a overall design um but yeah yeah we don't have like a

speculative transaction pool yeah uh Lucas if clients will have uh vastly incompatible transaction pool rules it won't make sense because the transactions won't be propagated properly right yeah but it's yeah but it's like we yeah so I guess the EIP itself is something we could add some some stuff there but we sort of had this problem as well like with I guess 1559 was a bit different it was about like better sorting of transactions to build a block and not as much about gossip but like that was another case where the you know we sort of introduced another degree or like dimension in the transaction pool

and sort of proposed a way forward but you know we can't force clients to do like that yeah it's not part of the consensus rules you know whether or not clients follow that but yes it does impact then how things get get propagated on on the network so okay I'll try and follow up with Geth on that uh we can and I think just generally like the transaction boss design is something we should kind of keep chatting about as as um yeah in the coming weeks on that point

if not um just the final thing so I mean when I was removing most of these suggestions including the dunkrats that he just mentioned the one thing that that I just wanted to note is that in many cases especially in in this case where we have now blobs per block that is maximum at four and and this number is actually smaller than or equal than most of the modern CPUs the number of the cores in the important CPUs so in many cases it would be just easier to to spin in the middle or

verification checks of individual blobs uh on on different cores and that will be faster than any other trick that involves uh you know various combinations with challenges and and so on so uh I don't know I mean the general idea seems that it's never to do parallel thing in the at the spec level but I'm not sure maybe it would be better to consider that the maybe somebody has comment on that or I didn't express myself clearly enough

so I yeah I'm not sure personally how much how much the the spec like how much those sort of optimizations are part of the spec or not um okay then let's leave I'll put the comment in the in the pr and yeah maybe somebody will have some something to comment I think it's uh like multi-threading and doing the verification in many cores is certainly a huge speed up but libraries should do and uh we we do see the speed up occurring so I I don't think it should be part of the spec but I do

think that uh if you can if the libraries can multi-thread something they should now how this multi-threading should be arranged on the single proof thing that's that's something a bit more complicated I agree no I mean the the note here is that the majority of these suggestions uh that it was multiple things like multiple blocks for instance they they do not consider that uh that it's possible to do things fast and parallel and and the algorithms proposed are not uh I mean not parallelizable by Design or something like that you know

because they are optimized to uh to to be fast for a single thread performance I mean if if somebody is is going to optimize it then they will do completely different algorithm comparing to the suggested one because the suggested one is is optimized for single thread maybe I mean I don't know msms can also be multi-threaded I I don't know let's I I would say we take this off of offline um okay speed it up okay okay thanks okay anything else on the specs

I guess it probably makes sense to go over devnet4 and how clients are tracking yeah anyone have an update or anything they wanted to bring up there you can give an update for better soon yep so we are now following devnet for chain correctly locally we are also able to build block without training block transaction because we still have an issue uh validating blob transaction that we are working on

and this should be the last issue before we could join that net for uh as a standard clients supported client thank you uh so for Lighthouse we just merged the fix for serving finalized blocks that have blob transactions so previously like you couldn't sync from a lighthouse node by range um so if we're able to deploy that as well as um

uh there is a get change needed we're able to deploy the latest Lighthouse EIP 4844 Branch plus Geth with that PR I just linked marriage um then other nodes should hopefully be able to sync from lighthouse on the devnet and then other than that uh Diva's been working on an outbound rate limiter that's configurable in Lighthouse so I'm hoping that will help us with any rate limiting issues we've been running into thank you update from taku yep

um yeah we were working this week to move from the uh 4844 branch and having everything back to to master as we used to do and we also have some sync issues that we discovered but uh not yet in the 4844 branch hopefully we have we'll have those effects on on master and then we will then ask for a refresh of our nodes building from Master this time um update from prison so um we have been we actually haven't been paying so much

attention to that level four we're actually uh just pushed me ahead of that five so we are working on the coupling block and blog what we're reviewing this back and beginning our initial implementation sweet anyone else never mind so there's a quite complete the net for implementation and just synchronized with Lighthouse which was the last sealed site or client on the list we were trying to synchronize uh that's it probably

anything else on the bed for okay and yeah obviously like I'm I think we're done at five we'll want to just wrap up these spec conversations we had earlier um last thing I had on the agenda so I know there's been a bunch of uh large blocks sent uh over Gordy um I don't think Dan is on the call but I don't know if anyone else uh who's looked at the the numbers uh is here okay so I don't think so um but yeah

definitely been more movement there and we can try and provide an update uh on on the next one of these calls yeah anything else that anyone wanted to bring up we could discuss the SSE execution layer stuff itan is here he's been working um any updates yeah I mean Hello so it's not entirely for it for for specific in general but um I'm still working on this eip6404 to transition the transaction root received root and withdrawals root

in the El block header to SSC so one issue like for uh for eight for four is that on the network it requires these special casings about how the mempool works about how the transaction propagates question came up whether it is possible to somehow support zero blob type 5 transactions um so that going forward we can um we don't have to maintain both the width blob and no blob transaction every

time that a new transaction feature is added so for example if we right now want a type um want a SSC transaction without blobs you would have to define a transaction type for for example and then four would be no blobs and five would be with blobs so let's say we add a new magic feature to the transactions and we want it to be available in both kinds then we need type 6 for no blob with magic feature and type 7 for um with blob with magic feature and essentially doubling all the transaction types going forward so yeah I was wondering whether it's possible to

somehow support zero blobs without introducing transaction types does anyone have thoughts on this okay if not I guess we can continue this conversation I think it's in types transactions right transactions in execution r d okay yeah so let's uh let's continue chatting there about it then yeah I mean I think the reason I want to

discuss because I think it does kind of impact 4844 if we're going to be introducing a new transaction type it seems like the the time to get this correct is right now um before like the next devnet right is that what you say uh ideally but certainly before the next Fork right yes yeah uh and it's yeah it's just it's it's it's a little messier than I'd hoped I guess so like having more eyes on this now I think would be helpful yeah overall um vitalik also mentioned that he would like to discuss the um Union versus normalized transaction encoding for SSC so I would really appreciate if someone could schedule a

call for just SSC and transactions where all of these topics okay um yeah let me try and do that so we have um there's an eof called tomorrow at 4 15 UTC um so maybe next week at that time because it's every two weeks maybe that's a good time to schedule it so it's like uh basically a week from now or a bit more but um so it gives people time to kind of read up on it and it'll be before the next awkward Dev so if um so whatever comes out of that call we can kind of bring it up on all Courthouse as well does that make sense makes sense for me I mean for me anytime works this is priorities

okay so I and I'll share this with the get folks um but yeah okay so I'll organize it for next uh next Wednesday 15 uh UTC okay thanks a lot anything else people want to discuss um anyway uh if we will have a two or one SSD transactions types new types right uh we would most likely uh try to use SSD root hashes for them probably and we could try to start this

transition uh before the net file making it a part of its scope what do you think I'm sorry I'm not sure I I quite understood uh the question uh we uh let me rephrase uh I my the idea is to uh

use SSG root hash for a transaction hashing instead of the current approach because most likely we will do it in the future to do it now I'm bringing it says winner condition dependency to our projects so so right now we're using the rlp route for hashing and you're saying we should switch to the ssz1 because we're going to switch anyways right yeah yeah is there so I I personally would like us to have the broader SSD conversation

next week before we make a decision on that is there a reason we have to make the decision quicker than that no probably okay so yeah so that's yeah I I I think it probably makes sense that then just okay let's have the SSD call next Wednesday and um and get back to that after just uh yeah I wouldn't want to like make a decision and then have people work on it then realize we want to go the other way because of something that came out on the SSD column so generally there is a Vitality appear about this right

I have proposals there's one from vitalik and the the one that etan is working on which is a unified transaction version um I can I can put the link it's in 6404 if you go to the ethereum matricians link there is a link to vitalik's post um who made the proposal based on unions and in 6404 I tried the same with the normalized transactions that we have both strategies and we still need to decide which one of those will will go forward yeah okay so um

yeah let's discuss all of that next week um I'll also check with vitalik to see if he can make it uh at that time so that uh we basically have everyone who has a strong opinion ideally on the call okay well thanks everyone um talk to you all Thursday on the CL call uh let's look at the blob blog coupling thing before then and um I'll post an update on the SSD call uh as soon as uh I yeah I just want to confirm the time with a couple people

um yeah that's awesome uh thanks everyone thank you bye