EIP-4844 Implementers Call #15

Transcript

foreign implementers call for 444 um a bunch of spec updates to go over quickly today um and then we can discuss uh client statuses and anything else people feel we should bring up I guess yeah to start uh Danny you were saying you want to quickly cover free the blobs the decoupling yeah yeah things are looking good simulation results as discussed on ACDC last week actually looked really good um in terms of delivery times and network load um we're closing in on it I think we

generally have agreement on how everything is going to be structured or just kind of nitpicking the intention would have to have this done on Thursday for any last commentary on acde and then a release on Friday with this and other minor changes so if you haven't taken a look and you intend to now or tomorrow is a good time um so kind of in like definitely in the last little cleanup phases nothing structurally we expect to change so kind of last call check it out cool um should we bring it up on our core devs explicitly Thursday or uh uh yeah do you just think it'll be

merged by then I guess it should be merged by then and just or maybe on Old core devs I'm going to just say we're cutting release tomorrow with this yeah if any anyone has problems with that they should speak yeah and I assume this doesn't change anything on the Yale side right correct it does not yeah so you know it's not perfectly uh synced for the the call but yeah and I don't expect any issue so uh or at least I'm praying cool any other thoughts comments on freedom blobs no I just said great job getting this

wrapped I feel like we're almost exactly on the schedule we set in interop so pretty impressive yeah do any clients have this prototyped or implemented yet prism has started it but I stopped because of like seems like there's a few moving pieces such as like different signing domains much but yeah I can pick you back up this week inside is getting very close so so yeah very very excited nice and we'll have um pop in his simulation framework which takes uh actually runs like a full client I think it generally biases to

running Lighthouse um he's going to take the old version and the new version when they have it and and also run Sims on it to further validate you know every simulation framework has its own caveats or Corners being cut so just to continue to validate that this is the right direction anything else okay um then yeah then you had uh you linked to a bunch of different small spec updates yeah so I'll I'll just sort of go through these but the first one was uh

basically uh the zero like dealing with zero blob transactions and how it relates with 868 uh the announce uh EIP um yeah you want to get some quick context there yeah sure um so right now when we use a type 5 transaction um we always require it to have a blob while it's in the mempool we do not enforce that when someone includes it into consensus with zero blocks that's fine but um we cannot add it to the main pool right

now Type 4 is not used um type 5 is the blob transaction type 2 is the 1559 transaction type 1 is 2930 and type 0 is Legacy so three and four are unused um so so far those transaction types there were always a superset of what was previously possible so I think it would be nice if we could keep that with the type 5 transaction and I made this small proposal for the e68 the fp2p that essentially adds the number of blobs to

this announcement packet and then only if it has blobs it would actually bundle this network wrapper containing the blobs and otherwise it would just go through through like every regular transaction and this essentially avoids us needing separate transaction types for distinguishing these transactions that end up in the exact same way in the consensus execution payload and also going forward if we have the additional axis that we need to support it it avoids us having to double all the transaction type Theory now and then

like so we don't need a blob transaction with additional extra Feature A Blog transaction without extra feature a non-gloth transaction with feature and the non-law of transaction without feature yeah wondering if there were any thoughts on this already or yeah just adding this number of blobs to the announcement uh yes sorry I lost the views button go ahead uh yes it's just like uh technical thing it's like in current

implementation of if 66 it's like and called it like all RI of types then or RI of the same length of sizes and all right of transaction hashes so it would be not possible to to add number of blobs only to the to the ones which has glass blocks so we we just we need to to add all the array with zero zero zero zero one two Etc not sure but that sounds uh that sounds doable as well or I'm not even sure if the transaction type itself is still needed actually or if it's just a number of Pops that would be needed

yeah probably we can just replace transaction type with number of blobs and yeah I think transaction type was needed only to not ask about blob transaction with blobs which is heavy do we want to make a decision on that yeah I guess yeah because do we know any clients have implemented

e68 already and this would have to be undone yes never mind implemented it's 68 already uh eaten does this depend does this change also depend on like the higher level I says Z decision we make like yeah basically on the SSD Breakout um that that call is tomorrow yeah it doesn't really depend on it and it would allow for example to eliminate this

complexity of having a rlp transaction without blobs and an SSC transaction without blobs currently in vitalik's proposal there is an additional transaction type for an SSC transaction without blobs and if the 4844 type 5 transaction would already supported this extra type is not needed but um I mean it can be accommodated anyway it doesn't matter Lucas so I somewhat don't like it because now this number of blobs is uh creeping out everywhere right it's creeping out in networking it creeps out in transaction pool

uh it wasn't the size be a better like limit how to handle things and base that on the size of transaction because blobs would be counted in the size right so yeah and by size there's two things we can do right like we can look in kilobytes and we can also look at like gas or data gas right true true uh so if we have a transaction type of blob transaction and its size is bigger than something we know it has blobs probably like we could be sure right can we be sure it has blobs uh that's my question here

um because yeah I'm I'm not sure that you know creeping out this blobs which is something special for this transaction type everywhere is like that good design I'm I'm hesitate hesitant of that again would be good to cons uh consult someone who also wrote 8868 that would be I don't know Marius okay so does it make sense to follow up with Marius offline about this yeah I I just feel like this whole

the transaction pool and and the transaction types are like hard to get everyone on the same page about yeah I'm not quite sure what's the what's like the dependency basically yeah the dependency lists between those things and and how we get to a decision that people are are happy with yeah I agree this is starting to seem like the highest risk domain in our best um I mean the transaction types they they are used in in a much bigger scope than just a mempool

um I mean they determine how to serialize the transaction how to sign a transaction and how to create a transaction ID um so it's entirely different aspect of transaction processing um so having anything separate would already solve this it can be like what Alex has said in the chat it can be a flag that says this transaction should be actively requested instead of concept it could be number of blogs it could be something based on size I'm not sure if you can do it based on gas because the gas cost is only known after you execute the transaction

and it may change dynamically depending on the order of transactions how they are bundled into the block um but there are multiple approaches and I think anything that is not based on transaction type can be used like okay Mophie yeah um I think um this point of using the size is brought up at a Bogota and I think if I recall the conversation the decision for using the transaction type was that we could more accurately capture the full cost of um

validating like doing some quick validation of the transactions particularly in the mempool I don't like the mental discussion is like going taking a different direction but assuming like we're still using the regular men pull then you want to use the transaction type because he fully captures not just the cost of like transmitting these transactions over the network but also like verifying them where she could have like a large but if it's not a block transaction then the cost would be much less than transmitting like a bob transaction even if it's like smaller than a regular that kind of makes sense yes I mean if if you if you think about

the transaction of type 5 as only having blobs that's true because then you can use the transaction type to determine if it has blobs but if you want to make the transaction type generic like to be to allow it to support zero blobs then the transaction type doesn't tell you whether it has blobs anymore that's the problem but yeah so probably not the size them but instead some extra flag or number of blobs um didn't you use daily gas so the decide oh yeah please go ahead

no no sorry yeah yeah so I guess the size doesn't work if you can have zero blobs in the transactions is that right because you can't but you could still use that to determine for any transactions whether it has a Blog but we don't want to like that's okay I don't understand isn't that exactly what we want that zero bug transactions are handled exactly like normal transactions all right so you say if a type you know type five what's my sorry yeah I was thinking about like five is larger than but like yeah you can do the opposite and say like yeah if the size is smarter

than this you know there's no blobs or actually I don't know that that's true because you can I think yeah actually I think this is not true at all because you can have huge call data transactions right um so you can have a transaction with call data uh you just won't be gossiping yet but you can have like a big transaction for the call data and so I don't think size yeah and then and then maybe that transaction should be considered just like a block transaction right but I guess that this is a different mempool design than like say what Peter proposed right like um but it makes more sense sure I think that might be worth bringing up on like the the ACD call this week because like yeah you could

say that the big call data transactions get treated the same and then you know maybe the proxy can be something like whichever transaction is too big for you to gossip for which there's already a a check in the mempool um you know you treat somewhat differently than the transaction that you you can gossip no I don't know for the El folks here does anyone see like a an issue with using size versus like type or data gas or something because if you want to do just blob

transactions and and blob transactions can have zero blobs you can also do something like you know if the data gas is bigger than zero basically well yeah it also depends you know if we're just being informed by about hashers or they're actually being transmitted this is unrelated topic like I did different message right so we cannot it's hard to infer that information from this information and start getting confusing and ambiguous so what do you think would be the cleanest way to make the distinction based on like how it's created you don't

have the answer currently sorry what is ambiguous about it if you simply make a size cutoff uh well uh the biggest thing is uh because we have a broadcast transaction right which broadcaster transactions and right now all the transactions are broadcasted now you're saying some might not be broadcasted and the criteria here is would be size potentially which might be fine but then it's like yeah we would have to guarantee that this is in stack right that the size or do we want it inspect don't we want it in Spec it starts gets ambiguous for me a bit

I sorry I don't see that it seems very clear to me but for me it isn't why not like what's the problem of just defining your size okay it's more difficult than defining something else like will we Define it in in protocol as a protocol rule that we don't broadcast the transactions above the size or will be I mean that's that's already a rule like that right right now transactions over 128 kilobytes are not broadcast already is it is that well get does that I don't know that other clients yeah it doesn't matter so this can be the same as this rule that Geth has

so I don't see what's Difficult about it all right actually the not broadcasting blob type transaction is defined in a spec of if 68 so it's just when we're using f60i it means that we are not broadcasting block type transactions yeah but I think that here is we are going back to blob transactions are zero block transactions are uh the same as normal transaction and some we should broadcast some we should not and again it's becoming a mess in my opinion why is it becoming a mess you still

haven't clarified that yeah if you have these two like some sort of statement that doesn't make any sense to me it's very clear to me but is it it's more like you now have these two rules like is it do we need two rules about what you broadcast basically right like why are there two rules it's a single rule well right now it's like better than x bytes you don't broadcast right but like right now we have this at the rule in each 68 that is any uh type five transactions we don't broadcast and that might be fine like and so basically it would probably be cleaner if either we just keep that as is but that leaves you with the problem of like zero blob

transactions which you could maybe drink more uh effective yeah and I'm simply saying simply change that rule to it instead of being type transaction being transactions greater than 128 kilobytes oh Marius uh yeah I think we should disallow zero block transactions I know I'm quite late to this conversation um and I think so yeah like we can disallow broadcasting of transactions over 128k or whatever but the the thing that like not having zero blob transactions allows us is to have them

really separate from uh from normal transactions and um this comes with a lot of advantages in the code not having uh these these kind of transactions yeah just just having these distinct types that don't like all do the same thing and that's like this kind of the problem that we have in the engine API right now is we have we have like a new version but it supports all of the old stuff as well and um it's it's a it's a real mess because we have to filter out

we have to like special case a lot of things and Marius does that Advantage still exists if we also want SSC yes how like I mean you know like what is the big difference between a normal transaction and a type 5 type five if you mean block translation yeah yes well like the only major one I can see is that that it has that it is SSC no we we have to verify the blobs we

have to um sure if there are zero blobs then there's nothing to verify yes but like we have to either we have to allow the zero plop strength plops transaction in the normal transaction pool uh which would why not yeah that would mean we have to we have to filter out all of the blob transactions that we get broadcasted and um like we have to allow them to be broadcasted to us to then filter out uh uh which transaction type they actually are and then why do you have to filter the

transaction type like sorry because we because we have to put the blob transaction into a different transaction pool uh than the the other well I'm I'm suggesting that the difference would be by size rather than by whether they are blob transactions um no you cannot do that like yes yes uh you you can do that the problem is that one transaction is verifiable in like nanoseconds and one transaction type takes uh at least milliseconds you say so the blob transactions are much longer yeah but only five with that

large call data transactions right uh sorry that is but Mario's a zero block transaction can also be verified in the same time as a normal transaction yes I'm I'm just saying it's it's way easier and cleaner to uh to have these transaction types in a different pool it makes the implementation way easier and we don't have to have to like um have these these special checks for everything what does that still hold true if and and this this is not the case if you

allow zero blog transactions right because then if you have zero block transactions you sort of have this small transaction slipping in your big transaction pool is that is that right it kind of no but why it doesn't because the small transactions would be treated just the same as a normal transaction and there's also no special check to do because it has zero blocks yeah like we can what we could do is have them in the big transaction pool but the big transaction pool will have no difference I'm saying I'm saying they should be in a small transaction that's that's not good check it's not it's not expensive

I'm answering Tim's question it's not expensive it's just like I think it's very unclean to have what what what's the advantage of having zero blob transactions the advantage is that with every future transaction type we won't have to Define two of them like one with plug and one without and they are allowed on consensus so anyone who wants to do a regular SSC transaction without clubs can just use the same type as anyone with a box right also they would immediately give us SSC transactions for everything yeah but

like we can have SSC transactions that's not a problem just right but why Why doesn't an SSD transaction have to be anything different than a block transaction with zero blobs like that seems to be the natural thing to introduce them I yeah I think it's just uh I don't see a point in having uh in having zero block transactions it it makes everything more complicated and I mean if this is just something that's also done in the gossip and networking level we can change it pretty easily after the fork right like so I think

like I don't know I would lean no like depends on depends on whether we verify is it like that these transaction rules and consensus like if we get a block do we verify that uh that that the block is for transactions is correct but we like it's very easy to change after the fact yeah so I feel I don't know going with like the simplest one now where and either probably you have this comment about the list um I that's another can of worms but at the very least it seems like the value of zero blog

transactions might not be worth like the implementation complexity and if the transaction pool is like one of the big things we're we're worried about I don't know it feels like just not having them like yeah at least batting them from the transaction pool and you know potentially letting block Builders use zero blog transactions if they want um might make sense um yeah I guess does anyone feel strongly we should have zero blob transactions and like what's the As I understood the best argument is like if a roll-up just wants to use you

know one address to do sort of everything and they're not going to publish blobs with every transaction or actually you know that's not even true so it's like if they if they they need to use only one transaction type they could still use one address but then sign a type 2 transaction if there's zero blocks right yeah so uh regarding the the argument that it's consensus doesn't verify that blobs uh are not zero we can just make that rule right like there's nothing prohibiting consensus from doing this Okay so

anyone yeah anyone disagree that we should not have the zero block transactions in the pool okay and then I think that we should not have and disagree uh what what is the result there so what I'm saying is like okay I would like to propose we ban zero block transactions from the transaction pools if you have an objection that was like the time um like it's not a till I want to die on I just I still don't understand any like real reason for it but well we get Simplicity in the at least I I just

can't see it personally how it gives us Simplicity but yeah fine if that's what people think like what I would like to understand is if this announcement instead of the transaction type just says just contains a bit I contain blocks or I don't contain blobs wouldn't I just like allow the zero block transactions without any complexity like if I think we already sent the size of the transaction with a in is 68.

yeah sure I mean but the size some people don't like because it mixes up the call data transactions From the Block transactions right but um if if you just instead of the transaction tab if you include a bit there that says disk transaction contains the blob wrapper or it doesn't then you don't really care about the transaction type anymore I think yeah anyhow I mean yeah I guess yeah you should have added some complexity yes

I'm I'm I'm and weakly against the transaction pool rule without having it in consensus I think it makes most sense to have this rule because otherwise like no one like like someone can just modify their guest version and send these transactions so if we um if we have this rule in the transaction pool it should in my opinion also be part of the consensus rules okay uh Lucas so I'm I'm against adding another like flag if there are

transaction blobs in the transaction or not the so the idea of transaction type was to give you information about transaction right so it can give you this information and potentially be forward compatible with even more information about future transaction types that we don't even think about now right so that's the advantage of having the transaction type and this is what you're saying that transaction type is kind of irrelevant for gossip right now oh I don't like this idea as an idea I'm not saying we should ban totally zero block transactions I'm inclining to it but I'm not not 100 convinced but this was that what transaction type gave us right at this funnel metadata about transaction

that we can actually Define a lot of rules against on and with celebrate transactions we kind of like break this encapsulation of information let's say I don't know not not good not what I word I want to use but not sure if you know what I mean is it okay if we postpone this decision um till next week

like yeah like I I kinda like came into this call like way too late half half an hour too late um only because there was no one from Guess here and um I also like I would like to think a bit more about all of this from our perspective and talk to to to the guys about it okay and do you think it makes sense to decide this on this call next week or should we try and maybe bring it up on like uh the execution layer called Thursday so that we have more photos yeah we can we can talk about it on the execution layer Corner yeah okay so I

added to the agenda yeah and I guess the trade-off is like you know if you allow zero blobs or not if you don't allow them do you want them in consensus blocked in consensus or at the mempool and if you do allow them how do you discriminate uh between either blob and blob list transactions are big in small transactions and you know where that lives in terms of the in terms of e68 and transaction Port rules those seem like the three things to sort of figure out um but yeah I can yeah I'll add that to the uh awkward apps agenda and we can discuss

it there okay I suspect this was probably the longest one uh we have a couple more uh spec uh things that Ethan you had on the agenda so um the SSD list uh for eip6495 um do you want to give maybe a quick update here yeah right now in 4844 uh blob transaction there is a field for the destination it's a address field and right now it's specified as a union that can either be none or it can be an address the problem is that SSC unions

are not um standardized yet fully like they are still being discussed how they want to be serialized or miraculized or whether they are actually something that's even needed so my proposal there was to use a list with up to one address instead like if it's either it can be there or it can be an empty list or um I also made this new SSC optional type that can be implemented in like two hours that is fully tested that could also be used just so we don't accidentally introduce um this Union discussion and get blocked on that

I'm really against introducing a new type in order to save one byte no no you could also do the list with one that also Saves The Bite it's not about the byte it's just about the union um not being standardized yet the least how is it not sanitized yet I think like it's been in the SSC spec for two years I don't think it has changed it is unused and there is no test we are currently discussing it for vitalik's proposal about SSC transactions whether we want to change how unions get miracleized um so the hash tree root stuff may still change

yeah it's not about the product like if if it's if it's about to buy it you could just use the list as well it also saves the bind uh so we have implemented what's currently in the SSC spec so I feel like I'd be in favor of just using that even if it's not necessarily um agreed upon it seems like as likely to change as doing something else does anyone else have thoughts on this

because I know we have the whole SSD card is it tomorrow yeah literally tomorrow this I guess I'm trying to understand if there's other parts of like the design space that are worth considering here yeah I mean it's a detail we don't need to spend too much time on it yeah

okay so and I guess there's a PR that people can can discuss on as well is there a decision we make on this or do we want to just leave it open and say we'll get to a decision by next week so do people have the um uh Union type that's in the spec implemented right now my name was we don't fully implement it we only have the case where it's abused as an optional but we don't have the mercurialization for the full Union type yet um I think for prison last year there was like a renaton uh Pakistan post by um Proto using um for the just for the

um initial part of the merge they always Union type we have the implemented I think the problem was it's more like there is no speed test so we're not sure if argumentation of lines with other clients so yeah yeah the theme is from for Tech who has been is that is in our code base because of the initial uh merge uh um merge implementations that has been left out but is still in the in our Z libraries but it's never tested and how is it now yes I mean if people think that um just using a list of size one is less likely

to cause headaches and like that's okay with me I mean adding the testing should be easy right I mean I don't feel like that should be a major obstacle like if we have all the infrastructure right like just adding a test for the union should be quite easy yeah I mean uh one more thing is tomorrow in the SSC call there is another discussion about unions so maybe the information from there um like if we see that unions as a whole as a concept are actually used not just

for an optional and I agree that we don't need a separate type for optionals um but uh yeah maybe postpone this one as well I mean it's a really quick change anyway okay yeah let's let's uh see on the SSD call tomorrow what comes out and how we can get back to this one next week okay 16 million blob capacity I'm not sure what this is about but also you eaten yeah there is a like currently in the same block transaction type we support up to 16 million blobs per transaction I just wonder if this is just a random number or or if there is

an actual design space why why this is supported like more of an understanding question so where's that this is basically in the transaction in transaction type fives as they currently are described the like max number of blobs is set to constants that's like 16 million is that right yeah let me look it up real quick how it's looking so this is the list type I mean I think generally we don't want to use the the list Max um as the actual maximum for things it should be rather like a theoretical upper limit

exactly right so for serialization it doesn't matter at all the the max list length it only matters for localization correct and it's so that uh that all the other leaves are at the same depth exactly and it also affects the length of the miracle proof I mean that one is not relevant but um we also have I mean if there is a design space that we actually want a lot of blocks in the future then there is another limit that an SSC object that you see realize it cannot be more than four gigabytes so 16 million gets it to multiple multiples of gigabytes so even the

theoretical limit is very unlikely to do that 16 million does seem like a lot it's uh I I wouldn't argue that we have to I mean we definitely should make it like a large number but like something in in the thousands is probably enough for any time until we have to change it fundamentally again anyway yeah thank God do you want to just do a quick change to the spec to like whatever like some generous upper bound beyond what full thing chardonia would give you and we could just lower that constant by a couple orders with

magnitude probably okay and then uh next one uh so you have this hashtri route uh based signature but a comment saying it might be better for the SSD breakout do you want to maybe give some quick yeah that one was uh opened by light client and the italic is also behind it um essentially right now in 4844 we are using the ketchup of the SS Z encoding to determine the hash that is being signed

and also the transaction ID and the idea there is that we want to go to a world where we don't need to catch our cache anymore there and we also um can be based on hash tree root to be more in line with how it works on consensus um so there are some troubles there especially for the signature hash because that one needs to be protected against malleability if there is a future transaction type that encode similarly that it doesn't end up with the same hash um but besides that it's mostly a discussion for tomorrow how we can optimize this transaction ID at least to

be part of the actual SSC tree so unless anyone has like really strong opinions now I would probably say this for tomorrow just because we only have 10 minutes left but anything people feel is really important to bring up right now um and then Sean uh you had a spec item about uh the beacon apis um do you want to give some quick uh yeah so it's just um a proposal for how we want to support signing over individual blobs in the validator client

um via the standard apis so I guess the notable features are one that blobs will just be like blinded by default because it seems like there's no real point to send large clumps of data to the validator that aren't interpretable by the validator um and then in addition to that the like the get request by the validator is a combined block and blob to avoid like a race between the head of the beacon chain changing between requests um and then the posts back to the beacon node by the validator our individual blob requests and then the existing

block request so yeah just generally looking for like feedback people can take a look that's it cool any comments on this now or uh just a question um so you're coupling the um block and blobs in the beacon API we also going to have the old just blobs endpoint um so yeah right now with blocks we have a separate block endpoint for just like tying the beacon node to create a block for me to

sign and propose versus like get a beacon node in the OR sorry get a block from the beacon notes database so I think we'll have the same sort of um separation with blobs where like the end point that Jimmy has a PR for will still exist to get like the full unbinded Bob okay then um any client team have some uh updates they want to share

yeah from Basu yes we are now feature complete and we are asking to join the devnet for testnet uh yes so pending for join the test net um then work into refine our implementation and merging it to main piece by piece anyone else uh certain Lighthouse Point's been

working on the um decoupling work in Gossip um and then we're also just working on um things like blob pruning and then the ability to like separate your blobs database from your blocks database stuff like that um for prison we're also working on decoupling and making our DBS more reasonable basically watching instead so yeah and from Taco we lost week on Friday released the new image for devnet 4 with some fixes around the

sync logic plus lobs handling on DB so so far so good we're synced from Genesis we are okay and we were rating for the confirmation to actually starting decoupling and yeah we are starting working on that sweet um anything else anyone wanted to bring

up before we wrap up I guess Kim going back to your comment around the transaction pool it seems like we have a clear next step on the like zero blob transaction question do we want to set a clear next step on the like transaction pool design Etc well I guess this sort of related right like if we allow if we don't allow zero block transactions then we can we can you know have a design that's based on that so I yeah I feel like we need to make the zero block transaction decision first and then from there yeah we can also discuss the transaction pool more broadly on on our core devs cool all right and I've added I've added

it already yeah I've already already did the agenda um and yeah we'll have the SSD call as well tomorrow uh so I can post the agenda uh in the chat here if anyone wants to join that yeah otherwise I think we we can wrap up um yeah thanks everyone thank you guys thank you thank you bye guys