EIP-4844 Implementers Call #13

Transcript

this meeting is being recorded okay um so welcome everyone eip44 call number 13 um like I was just saying before recorded uh basically we had an interrupt meeting last week where all the client teams some researchers and other folks were there in person um pretty sure most people on this call were there uh at least the vast majority um and um we've made a lot of good progress on 4844 um and actually maybe it makes sense to start uh to start with with that um and then we also identified a lot of

uh open issues or things we need to work on in the coming months um and I think we should spend most of the call today just like making sure there's people who are sort of on on top of those different issues um and then we can wrap up if uh client teams testing folks or researchers have updates uh that we don't cover uh we can we can close with those um but yeah maybe to start um yeah so we had this uh week last week we had most of the client teams in person uh working on devnet4 I believe we got all the client teams except uh perhaps Nimbus uh to join a devnet and interop together um yeah does anyone want to share a bit

more cutter on that perhaps uh yeah uh my Audible yes Coco yeah so we like had the uh devnet 4 had like full client participation except like you mentioned nimbus there was um so everything we got client interop with like all sorts of combinations like death prism um Geth lighthouse um even ethereum JS and lodestar gmj asteku Etc and that was all working fine um we ran into like a couple issues um

doing syncing which um eventually client ads are able to like get that working um there's like also a couple standing issues but so far it looks like all clients except in this are able to like sync through the devnet and uh yeah becoming uh everything in consensus um one note um this stuff that was like excuse me hopefully it's not Edelweiss flu um this devnet was like pretty like the goal of it was just to get clients like up to spec and ensure that they're able to sync the tip so we didn't test things like um um big like transaction spam like create a lot of blobs in the chain or do any of

the bad blocks testing that was done for withdrawals but so just keep in mind those goals we probably would need to iterate on like more stressful environment and future test Nets but for this one it was like pretty good to see full participation yeah I just wanted to add on top of that uh I did try to spam it but now I intend to me I I had this generator too with the Blobby PLT blob util um utility and then I tried spamming it for like two hours it seems fine but of course this is nothing but this is this is just like this is just like an appetizer thing but yeah I did try to play around with it yeah that was really great it actually

helped us um um highlighted bug in several client implementations um several execution clients assume that um there's like a maximum of two blobs per transaction whereas that was like only applies to the black validity so that was actually great um the spamming that on Terence did nice anyone else have anything they want to add on on the devnet um so we had a couple sync related bugs in my house um and we made some fixes for those uh I was wondering if we could push like some Docker images with the latest from the

444 Branch so we can test those out yeah we can definitely do that um just uh we can sync offline the details yeah cool uh Fabio yes uh bezel here so we are connected externally to the devnet for uh we are progressing we have some problem with some blocks that we are addressing right now uh with the hope to be fully uh to fully join

the devnet in the next days uh an update from Deku too yeah um yeah actually we managed to join the devnet4 um and the very last day on Friday um actually we were following the chain correctly but we spotted a bug and we were actually deleting the blobs that are being finalized so the bug is now fixed and uh with with deploy fix uh very soon sweet

any other updates never mind still wants to synchronize with a lighthouse it's our nearest uh aim and let's see thank you anyone else um in that case then uh yeah so we got pretty much everyone on under the four um obviously still some bugs uh we can

keep working on those um there were a couple other things uh actually quite a list of other things that we discussed in person so um I'll just sort of go through them um the first one was uh the kcg ceremony output um and finding kind of an optimal format uh to feed this into clients so that uh they can they can uh use it as as uh as as input um I don't know if anyone uh I Know Carl uh sort of let the discussion on this but I don't know if anyone wants to give a quick out there of um sort of what we agreed to with regards to just the output of the ceremony and how clients would would use it

okay um yeah we can come back to that um I think the other thing as well uh I I can give a quick update my recollection is that uh the output is going to be uh just like hacks encoded with new lines right I think that's where we landed uh we talked about doing um some like pre-processed uh or the pre-pre-processing uh data but I think that's where we landed was to I forget exactly I think it's like hex and code it would be lines right I think that's the same format that ckcg 444 already uses the way you're going to

be following that yeah I think yeah I think so okay sweet um yeah and then obviously you know we can uh like yeah have current teams uh work with the the kcg folks to to make sure this is this is good um and then in terms of the libraries themselves uh I think we did a fair amount of bug finding uh during interrupt um and uh of hardening of the libraries uh George do you want to maybe give a quick update there um yes I guess I can give one uh you caught me a bit of guard so I'm not I

don't really have a okay so let's see uh since Alexei I see you're here but I think we're you are not that the interrupt or if you were within get to meet anyhow so one of the big updates from the things we did at the interrupt is that we switched the entire public API interface of the kcg library to accept bytes for everything including field elements including groups everything so client clients just passing bytes to the kcg library and the kcg library takes care of everything this would this seem to be the most foolproof approach um at the same time another decision was

to um switch go kcg to use ignark the gnark library for the back end it seemed a more prudent Choice over kill it or whatever given that genark has been audited so I think Kev who I'm not sure if he's here but if he anyhow I think he's working on changing lowercase it due to use ignark this is a big departure from the previous uh situation and um it also has to do with the fact that we're getting an audit in like one month

and a half so things should be stabilizing at some point so this is like a bit of a of a thing that's happening right now um at the same time we did lots of work at improving the code base of ckcg we added a unit test framework we started doing more tests we found some bugs all that stuff so yeah I guess that's it from the library side I mean I have some more cryptography things in terms of the decoupling blobs potential change but that has nothing to do with the library so I will let that for later sounds good

um yeah thanks for thanks for the overview anyone else have an update on the libraries okay another big thing that we we talked about uh interop was uh the transaction pool for the blobs uh so Peter uh from the get team uh spent a bunch of time uh sorry I posted the wrong link this is the right link uh in GitHub so Peter from The get team spent a bunch of time uh looking into this and uh coming up with a design that uh he thinks uh would be would be optimal uh and there was a lot of conversations about this uh thank God you had some comments on on the p on the proposal there as well

yeah my feeling is like all the El client themes are sort of looking into uh an implementation for this um I don't know if anyone wants to give a a more detailed update um yeah in that case yeah I do recommend anyone who who's interested in this just have a look at the doc uh or the gist that I I posted there and I can go oh Lucas yeah so yeah so I remember having some conversations around it and yeah there are a few like question marks how it should work it those can be considered implementation details so different clients can work here in

different ways as long as they um have all the security concerns covered um and by security concerns I mean like being able to not blow up the uh the storage for example if they are stored on disk or in memory right so things like that but yeah there are those question marks about should we uh should we handle replayability right after work and as well as how should we treat multiple um like nonsense between transactions

that are blob transactions of blood transactions and how we should so for example we have the transactions that are blobs and not blondes with the same nouns who wins and why and can you like replace one with another or is it restricted um yeah and also should we potentially have uh how should we track multiple transactions from some same address multiple blob transactions from saying those are like multiple questions on on the details of implementation and I'm not sure how much of that should be in as like a spec and how much should we just implementation detail and what the

exact rules then should be on the on the spec side so they're like multiple questions here that it would be good to like iron out and and have some like um tests that would be kind of like attack vectors on this uh just to be like sure right that's actually a good point like I don't know that we have specs for any transaction pool things in the for any previous eips um but then it's like yeah maybe the better approach here is to have a test Suite that spams the transaction bills or at the very least you know on the devnets we can spam uh the networks with a bunch of transactions and see how clients handle that then we can uh potentially like

trigger reorgs yeah so I I'm I feel like for the transaction pools implementations themselves you know we can keep tracking them here and I suspect it'll also be discussed on our Courthouse but maybe one yeah one thing we should we should look into it in addition to that is what's the best way to test it and and um whether it's a it's a devnet or like a static test Suite then um yeah so I'm just pointing out this is quite complex uh problem and there can be like multiple Solutions and the question mark is like where is the protocol level where is the implementation level right and one only

one thing that we I think agreed on was that definitely we have a separate that blob transactions um cannot have like zero blobs yeah so it's a separate type and that's that's really helpful for like even reasoning about yeah and I think there's a PR about that already in the EIP right uh I think Matt put a PR for this let me check so I don't I don't think we agree don't you I know that some people were that but I think we agreed that the transaction pool would not contain their blood oh so that right so this is like a

client validation thing not a consensus rule is that right well I mean there were some people who were pushing for it to be consensus through but I don't think there is consensus on that okay uh okay I I got the feeling that from the session when we like uh discussed how to SSG all the transactions having this SSD we kind of established that we will introduced another type that would be none blob but I'm not sure that's what the concerns will tell right and where does that say that in consensus you can't have

uh zero block transactions okay but then it makes it awkward right because of those rules there's a transaction is not a special case at all at work I love um explain to users why there are two different blob transactions behave differently so does it make sense to maybe bring this specific issue up of the zero blob transactions on our cordoves so we get

all the client teams there to chime in okay yeah so let's let's do that and I think yes okay and I think with regards to testing like uh uh as even even in the world where like uh zero blob like regardless of whether zero blob transactions are are valid or not um it probably makes sense to have some way to test you know all of the boundary conditions um and even if it's not like part of a spec right like the clients might handle reorgs differently or whatnot but they should not like crash uh over over a

reorg yeah so I think just like generally thinking about like how we test even the non-consensus parts of uh 444 is also something we should we should discuss on on our Courthouse anything else on the transaction pool testing you other big topic that came up uh was uh actually one more question on the transaction poster is there like a do we have a clear Next Step besides the

zero transaction thing on on like writing this into some kind of specific like do clients need anything else to make progress on this I'm nervous that it's a little ambiguous right now so historically we haven't had specs for Tran like clients are free to implement the transaction pool or how they want given that um you know it you don't come to consensus on it um it makes sense to have probably some reference docs or some like high level design things but it's it is also fine if like Aragon does this differently than Geth than Basu um as long as you know ideally they you know they none of them none of their different implementation has has like

issues and I think this is the thing I'd want to discuss at all Cortez is like what's the right what's the right way to test this in a way like what is the thing where we want to ensure our clients behave the same way and that doesn't mean there's like a full spec right like but for example um you know should they like uh should they reject this type of transaction or should we expect them to include this type of transaction if there's a reorgan whatnot yeah I think that's the most challenging issue that I'm seeing that needs to be resolved is you know is replaying blob required because that's where you have to introduce some significant new complexity and code paths into most transaction pool implementations right

okay and then there's a comment I guess just before we does that make sense to you Jesse then I'll go to the comment in the chat yeah okay and then okay there's another comment in the chat uh adding data gas consumed to the transaction receipt format yeah can you do you want to give it some background on this yeah sure I mean this this came up this is Andrew this came up here in um testing in devnet for when we were trying to triage a bug in our ethereum Jazz code um and I know Robert you and I talked about this on the on R D on the 4844 testing Channel a little bit but just adding that field for date the total data gas consumes from Fireball transactions to the once the transaction is mined putting that field in the um transaction receipt that's returned over

Json RPC um for like forget transaction receipt um I wasn't sure like if we that needed to go in the EIP or if it's like where like how that how if we were going to agree to that where would we document that it wasn't Augustine if that's something that goes in the EIP itself or we just update the RPC like any concerns about that because it feels like a useful data point since that's not reflected in the transaction receipt so you won't be able to easily derive the full kind of state transition for an account balance between blocks for the sending account without that yeah and a little more background I mean there was some debate in the Discord regarding well it can be computed so is it really needed there um but I think the the I mean putting the burden on all

clients to be able to recompute that appropriately again the computation might change in the future to me seems a little onerous um so so my feeling is it should be a return by the receipt it doesn't need to be part of the consensus um hash um but it should be returned right so if we're not changing basically the the consensus uh like the consensus objects then the way to propose this would be to open a PR on the Json RPC spec um and maybe just put it on the awkwardness agenda to get people's thoughts there cool all right yeah I just want to make sure because I think it I think it would be useful for you know Downstream to CL ick related stuff so um thanks cool

um and yeah just in case people are not aware the Json RPC specs is now in the execution API as it used to be in eip's um that changed a while back and so that would be the repo where you open the pr okay cool thanks okay and then the other big thing we discussed was uh decoupling blobs and blocks for sync um I know this is something we've gone kind of back and forth on but it seems like we're we've landed on uh decoupled approach does anyone want to give a quick recap of like yeah what changed and and why we're going this way

uh yeah I'm sorry go ahead go ahead um yeah so we decided to split up uh blocks and blobs in Gossip sub and one of the main reasons for this well generally it's for just propagating the blobs as efficiently as we can um one of the reasons was we're seeing some evidence in the Big Bob's experiments or Big Blocks experiments on um Gourley that message size is like really like court correlates with the network propagation um so by splitting up the blob message

sizes we can uh operate more efficiently in gossip and there's room for some optimizations that could also reduce bandwidth um generally it just gives us more optionality um I think that's the main the main advantage um so yasik's been working on the spec for it so I think it'd be good if consensus client teams gave it a look um this is like no it's related to the spec I just sent in the chat um I think he's gonna raise a PR for it relatively soon um and yeah the implications of decoupling blobs and blocks on uh Gossip

or that we probably want to do the same in the buy Rich requests um and our buy range uh sync requests are already decoupled so I don't think we'll have to touch that logic um but yeah it's about it thanks for the summary so all the presents I I have begun implementing um the changes I know it's still very early that there's a lot more to do but I'm trying to make the implementation follow very closely to the design dogs so that I can totally give like better feedback just from the implementations point of view um I also left the first round of review

on the design dog I don't think yasik has made any progress I think like since last week but but that's okay I think he'll probably come back to it very soon so yeah that's that's the update from my end any other updates on this okay and we sort of touched on this uh a little bit but um basically another big part of of uh for photo discuss is everything around bandwidth and networking uh requirements and and how The Blob sort of affect us on the network

um so splitting out blobs and blocks can help us make some optimizations there a bit I thought it was also uh a lot of uh updates on the big block chat um I don't know if anyone wants to give an update on that okay so we can follow up on on that uh later but uh just from skimming the chat it doesn't seem like uh you know we're still running uh some we're still setting some Big Blocks on Gordy um and and looking into how they affect uh propagation of at the stations and other things on on the network

another topic that came up I was sorry just two sorry sorry team just to go a bit on the decoupling topic again before we depart too far away from it um just maybe that was clear but it was not clear to me I I don't fully understand how uh certain we are we're that we're going with this because uh it it it affects quite deeply the cryptography layer um especially depending of How It's implemented if we want like the individual decoupled blocks to be verifiable on the networking layer it it will affect the cryptography layer quite a

bit so I'm I'm I'm not fully sure if we have like decided we're going for it because if we are we need to start doing changes you know have them ready before the audit and all that stuff so what's the can someone give a bit more insight on how final this decision is I think we've reached consensus um at interop but does anyone here have like opposing views and maybe okay

if it does have like these big Ripple effects on oh please Democrat yeah yeah I mean uh so I I personally still believe that the benefits are probably overstated and there's probably like and nice to have but the benefits are probably more like 20 rather than 2x um so I I was always against this but um I I have started working on it and I'm willing to implement it if it's uh if that's what everyone wants yeah I think I kind of feel the same way I mean it feels a little unnecessary at this stage but I haven't been involved in the big block tests so I may be

missing some of the data I was just gonna say I don't feel hugely strongly about it and just to be clear we also don't have any data this is currently all based on people's intuitions um so I'm a bit great Judas on this like because um so I don't have yeah I also don't have precise data on how good this changes in terms of networking performance but like apart from that I guess it will

make the networking layer a bit more complicated but that's not my domain in terms of cryptography uh we will need to first of all switch the specs for for the new model of cryptography which is you know probably we want to do one kcg proof per block so that the kdg proofs travel with the blobs now since the blobs will be sent isolated and then so we need to get that PM I just change the interface of the kcg library change the kcg libraries inside um change this this the test for the case like there is a bit of of of logistics and and bureaucracy that needs

to happen with this change that's why um and and we're also one month and a half or even less before the audit so um like I'm just saying let's just make sure that this is um a worthwhile change uh and not just based on intuition that's uh I mean or if it's based on intuition it should be a strong one yeah so I guess like when we have this session we had this session last week in person and we didn't really consider the effect of kcg Library I think everyone just look at it from the buying implementations point of view and we did come up to like okay with this change

the delay will be one month and people seem to be okay with it but now with the KCC Library changes that we just brought up the so it delayed may seem more significantly so I think like I don't think we have the right party in this club for example yes it is not here Danny is not here so maybe the best thing we can do is just to talk about it on Thursdays call when we have all the relevant parties just right I don't think we can make a decision right now yeah we can yeah and we can get we can yeah let me talk about it on the call Thursday but uh we should make sure that like folks like yasec and cl devs know to show up because uh it's not a

CEO call but yeah uh so I just wanted to add hello can you hear me yeah Dan crowded and Alex yeah yeah I I wanted to say so I'm I'm pretty confident we can make this change it is like um late in the development but I'm confident that we can get the libraries ready but yeah we just want to be sure and if so we won't really want to do it with an at most one or two weeks and be certain about it foreign uh yeah I was just going to bring up

because I believe uh when we were talking about this there was an intermediate solution where we just have the proposer sign over the you know fragments of the bobs and then I don't see how that would require changing the kcg apis it's thousands um so yes we could theoretically use the exact same cryptography as we are doing now um it just would feel a bit out of place uh because basically if we changed it now and make this block change it will give us much more flexibility in the future it basically allows clients to process blocks in any order that they want and verify that their commitments are

correct it allows the proposal to copy the proof directly from transactions then having to compute their own uh it would allow future additions like Erasure coding The Blob so that you could like say have double the number of blocks but only need half of them so there are some strong reasons that if we do this change that we also change the cryptography um so so that we have all these like nice nice to have in the future but yes theoretically we could also just not change the cryptography at all right right so so there's like

um kind of like three different options like either we don't do the decoupling at all or we do the decoupling and we change the crypto or we do the decoupling and we don't change the crypto and just to kind of make this more concrete even if we change the crypto the crypto is not gonna get from what I understand more complicated like the complexity may be even decreases in total so yeah I agree with dankra that it's probably not gonna delay us because crypto and the rest of the work is kind of parallelizable but uh yeah we should start kind of soon to do stuff yeah the main constraint he has to

ordered yeah I'm not sure if you can hear me um audio code is good but um basically um I think my uh my purpose to be that kind of under straight up space um I think it would be important to to basically get the choice right because if we say we would not touch the cryptography then that would mean that the individual blocks cannot be handled individually anyway and not like nowhere in the network so then in that case I think it would be a mistake to have special Case Logic for splitting like right at the blob sizes then I think we should just keep like treat the entire blob section as one opaque stream of data and just have some like size based

chunking and because High space setting would be much easier to lay to an extent to the full block um so basically the the the point is just that I feel like um we are a little bit at risk here right now to just go basically just make very quick choices because we have time pressure but kind of not get get this right in terms of kind of the principal approach so okay so we can definitely discuss it more on on the call of Thursday um what's the best place I guess we can use the should we use the kzg Discord channel to discuss this until then or doesn't feel

or maybe shot I don't know shattered data might be more yeah that works okay okay so let's I've put it on the call already for Thursday and I'll yeah I'll make sure to Grant besides it let's use the sharded data channel to discuss until then um and hopefully we have just like more context when we when we make the decision then I mean like sorry just to since the audit is suddenly becoming a huge like deadline I'm not sure like perhaps it's even considered to that we could push it forward like I don't know like I agree with hanskar we should take the right decision and

I mean let's not just put deadlines that we could perhaps push if we if we could I don't know yeah how does anyone have a feel for how flexible the other dates are I I I'm not I'm not sure like but then maybe an overlap in this fall um I have no idea if it's a flexible do you can you reach out to them uh Dan crowd before Thursday so we at least know by then um yeah if that would be a possibility uh sure yes anything else just on blog blog coupling

kcg libraries okay uh the other thing that we started to bring up at the workshop was a multi-client sync um so I guess as I understood it now clients can sort of think uh from like the the similar uh from similar uh peers but uh we don't necessarily have full all cross-client uh coverage um does anyone have more context there I think so I can talk about Lighthouse um yeah so we were trying to sync with

taku but um because they had the issue where they were pruning blobs past finalization um we would ban them if they didn't have blobs within the database availability periods um then at the prison we're still trying to figure that out it seems like we're rate limiting them um but yeah I'm still still trying to dig through that any other client uh some updates to share there okay uh then another topic that we we

started to discuss was um how do we hash The Blob transactions um what is uh the right interplay between SSD and rlp there um and I know that this is like bubbled and also like a much broader discussion around SSD on on the El um does anyone want to give a quick recap of this it's not oh uh Roberto did you just go off I mean I don't know if I have the full context but there is broader discussion going on around moving the El over to SSD entirely

um and I think that's pretty coupled with this decision right um but yeah there's some on there's some discussions and some proposals that have popped up very recently on the Discord um that it's probably worth everyone involved in 4844 taking a look yeah so I mean I think the The Proposal is the proposals are around moving all the transactions within a block uh whether they're Legacy or blob transactions to an SSC encoding um which of course means you'll have to then translate the Legacy ones back and forth between rlp and SSC in order to uh have backwards compatibility of the hashes but once you do have everything in SSC then it it makes sense to stick with the hash tree root

um to be consistent with a consensus layer and so it makes things kind of nicer in that regard but it does it is you know scope creep um it is enlarging the amount of work that we need to do for capella um so I think that's the that's the big downside I mean sorry for um Cancun got it um yeah and so we've I've added basically the SSD agenda items the larger ones on Awkward as uh this Thursday um so yeah is there anything before this decision that on the fourth or Forefront we should figure out um yeah I don't know I think we just

need to wait and see what what folks want to do there because I think like like I said if they decide to go full yeah full SSC and El that decides the hashing the shoe for us okay the decision is obvious and okay it's interesting uh that question about unions in FCC it is uh about the entire format of SSG and not about especially will we use it or not probably it should be decided yeah there's some other that's one there's another proposal that doesn't use unions but introduces like

an optional like I said there's a lot of uh kind of ongoing discussion let me um I can link to one of the more recent ones um I have it here somewhere I'll paste it in the chat okay yeah okay so yeah both of those uh yeah I've already put on the agenda for awkward Dev so yeah I folks want to review that before they call yeah and then next week on this call we can figure out uh how to go based on on

the decision um okay next up we sort of covered this a little bit already but basically uh spamming uh the devnet I think uh Marius wanted to update his uh TX fuzz uh repo the the better support blob transactions um obviously this is a good way we can test uh any transaction pool yeah anything else just on devnet spamming that anyone wanted to bring up um and then last uh last thing uh was uh basically uh breaking spec changes and

um and devnet 5 um so uh from the interrupt uh my my feeling was the conclusion was over the next two weeks so call it you know until until mid-February we want to make sure to get um any uh breaking spec changes in the um so that then we can hopefully launch a public uh devnet 5 you know in the couple weeks after that I mean get that live by the end of March or sorry end of February beginning of March yeah so obviously we covered a couple of these things today on the call already um but does that generally make sense to

people we have you know say we have a call exactly two weeks from today uh we try and get all of the um breaking spec changes in by then use that as uh use the spec as it is on the 14th as a base for devnet 5 and then um yeah we'll have a devnet with hopefully a stable spec uh two weeks after that anything else so that was everything we had on the list uh we did Cover sort of client updates throughout but if there's

any other updates uh either from clients Testing Research that people want to bring up um yeah that's the that's the chance okay well thanks a lot everyone um yeah I appreciate all the work in the past uh past couple weeks to to get the interrupt and everything we did there um yeah see you all uh on this call next week thank you all right everyone bye-bye