EIP-4844 Implementers Call #10

Transcript

foreign [Music] stuff that was mentioned last time to just make sure we're all on the same page here then we can cover uh anything else people might want to discuss um but to start okay oh to start Roberto you had this

update to the EIP on the El side um you want to take a minute or two and walk us through that yeah absolutely um so this is something I encountered when I'm when I was doing the implementation of Aragon I noticed in the implication in the implementation of guests um we are using the same hash for the transaction ID as we are for signing which I believe is a bug um so I wanted to clarify that in the EIP what is actually the correct Behavior there and I guess that just sort of opened up a little more of a discussion on what is the right way of handling this anyway so um right now when we compute the signing hash we're using the hash tree root which I guess is a standard way of doing things of the

SSE encoding which I guess is a standard way of doing things in the consensus layer um so the question is what do you do then for the the ID hash typically what goes on in the uh execution layer and please people who know more about this correct me if I'm wrong um is you basically take the raw serializing coding and that that appears in the block and you just attach that um so I decided to implement that um and submit a PR I'll clarify that in the spec um so that's one potential solution we can we can move forward with that um but it also just made me wonder why are we using hash tree root at all um in the execution layer perhaps we should change that to also just use hash

the raw serialized encoding um Proto commented on the pr is like well maybe we should just use rlp um or should we use hashtree root for the both uh so these are kind of all the options and they're sort of laid out that that issue um and you know I I sort of put out my favorite approach which is just to use the raw serializing coding stick with SSD and continue to Hash those raw bites that will make things easier to implement in things like Aragon where uh otherwise I'd have to have a much more involved SSC uh understanding in in the transaction tool for example um so I don't know if I'm summarizing this well enough there's a lot of there's a lot of a lot of details balled up there

um but I I don't have a strong opinion on either way but um that was just my my feeling on how we should go with that uh but Roberto I kind of lost you in the beginning I think I dropped out but my understanding is that um we're using like we're using SSD in the execution layer which is not a standard way to do things but is there a problem with what is the problem with this again can you just describe I think I dropped when you explained the problem yeah there's no not a problem per se the only thing is we we have not specified how to compute the um transaction ID hash and I EIP um should we use hash tree root for that

actually um but that deviates a little bit from how we do it in the execution layer typically which is where we just hash the raw bytes that appear in the block of the serialized form um and so we can do that too right so um we just sort of open up and and that's the only instance where we're using SSD in the execution layer in dcip or is this the only problematic instance this is the only instance where we're using it um proto-pry has more context too he may he can probably describe this better than I can he's got his hand raised so um let's learn to ask to this that there's a really latest problem about which contents exactly we do includes in the signing hash in which we

do include in the fill transaction hash right now that's the message for both cases which breaks some assumptions and exclusion there where otherwise the signature will be included in the hash and online like combines these type of problems so it's like do we do the organization or not and bench constants contents we include I think we should just try to be like create less surprises for developers and stick to things that have been tried and that's muscle forever relies on now with the

emp2718 I think the one with the transaction typing and envelope I do think we have the freedom to use a different serialization formats but we should probably stick to just making the transaction hashing predictable by just hashing the serialized formats yeah and that that's my same position as well yes it's indeed will simplify things a lot on execution uh client side uh well and this for LLP I I saw that um this encoding was removed for uh

version of transactions right uh could you guys tell about that where it was discussed and uh or Define it um I missed that I have to get some contexts the transaction was always signs over the transaction has already has three roots and then the transaction in implementation was being the construction hash was being computed based on the serialized message in the transaction without the signature

and so this was already inconsistent and SSC was there since the very starts and thus clear up some trouble then the contents of the transaction are being read in the consensus layer specifically the data hashes so I would stick to SSD but there's no need for all the history root complexity in the execution there yeah actually we're not the the death implementation was never hashing the serialized form even in the ID hash it was using hashtri root of just the message which again I I already I think

is a bug which is sort of what opened all this up interesting I was in the repression of those the serialized form for the fill ID but not for deciding that yeah that I think there are inconsistencies I you have convinced me there so we at ethereum JS don't have any strong opinion but we are also using hashtra root for generating the transaction hash sounds good to me um I'm curious do we have an option just like covering our bases here do we have an option to even change the

the hash how we like hash the transaction in the first place I'm thinking of like a theoretical future where like all new transactions are SSE encoded and we deprecate using Tech hack for like the hashing and just use the hashtri root instead if that would make sense I'm guessing no one knows Mophie yeah

that's a good quick peek at the Erp about the transaction and flop thing it does not State anything about the transaction hashing so there is a typing if the prefix for both receipts and the transaction itself that's correct me if I'm wrong I cannot find anything about the specific yeah I didn't see it had the IP either but yeah yeah just gonna say it doesn't say it specifically but it's kind of implied at least my reading of it was kind of implied in the part about Computing the transaction um hash root true the transaction hash root in there um maybe I'm reading too

much in between the lines though so something else about the transaction hashing is that it's dos produce SD hash that takes the value and converts it to 32 bytes when you put it into the miracle Patricia try of the execution layer block that's the part I was referring to yeah but it doesn't really Define what the hash should be right correct correct

okay either way I I think um everyone here has made good points um we could just keep the example and um normalize the way hashing Works um we'll cross that bridge if we have to so if everyone could um who has an opinion on this can can click on that issue and just either act or or you know disagree and we can take it from there sounds like we're all in agreement though so so just thoughts no just trying to understand so you guys want to remove the medicalization thing the trustri root does but you still want to use the SSD hashing logic or whatever it is right because we don't use any

Miracle properties anywhere so it's useless is that what you want to do if you want to use the serialization properties of SSC but not the history right right yeah because we're not using sorry yeah I'm just gonna say not just because it's not useful but also just because that's the way the execution layer is hashing existing transactions right right okay okay that makes sense to me thanks for that clarification and combines into the same discussion we have this part where we includes the center values in the commitments to the field which is important for some assumptions that may have been made in transaction

pools in the execution there where you want to attribute the signature Foundation to one transaction by hash Alberta does your issue captured this as well or should we combine it uh yeah yeah the signature details are in there as well if if it's uh let me know I'm pretty sure that's addressed so just to confirm that it says we're making here it's to move forward with using the ssc.serialize in the kickback yeah for both transaction types and

including the signature values in the transaction ID version of it last chance if anyone disagrees with this do you think uh Roberto it's possible to have a PR for this before all core devs just so we can like already done already done oh the PRS is that okay oh there's there's PRS for the eips in in that issue and then I have one for gases I mean it's like a two-line change so it's that also that's awesome I was just waiting until we agreed on the EIP before I submitted the code change okay

yeah sounds good on this okay um next up uh was uh CL spec issue uh 3170 yeah it seemed like everyone wanted to move forward with this uh on the last yell call but Mophie um you just had a comment like this with an hour ago on this so uh well maybe take it yeah

um I I just became recently became aware of the CIP sorry for the late comments basically I'm trying to understand um how this decision avoids the case of peers likes tending the entire reason why we call pulled like Beacon blocks in the first well one of the big reasons was so that we can easily decide on the spot if it'd become it blobside car is invalid and vice versa if we move is data available to Fork Choice rather than during block processing then that validation is

deferred and it makes it I guess it generates some sort of like an incentive for peers to provide coupled Beacon blocks with valid blocks but invalid like blobside car or the other way around and I'm just I'm not quite I don't quite understand how this proposal resolves that or if that is it is even a concern um I know like Terence already mentioned that um that's quite okay but I could you explain why that's not a concern here right um so I think we have like similar issues here with my attestation as well

because some pH injury and attestations but the block is never available right so the design is really there basically to enable you to query like um blog they are like they so basically we have paintings here set up like you said but um in terms of like deferred execution that is a concern for that I need to probably think of it a little bit more to be honest with you bye-bye on top of my head I know I mean I think this concerns could be both sides it could be like on the on the on the um it could be on the um implementation side

or you could be on the spec side right and um so yeah that I often think of it more so I had to get back to your dad yeah I do agree that it is possible to resolve this in the implementation side it will be quite gnarly to do so um which is why I was hoping what we have right now makes things super simple for implementers to um attribute fault to any invalid messages and with regards to attestation I think that case is a bit different because you can attribute on the messages that are being propagated the attestations themselves to I guess their origin but you can't quite do the same thing here

with um blob sidecar we don't sign the blob sidecar for example right so um I don't know if I think there's um a concern here that some peers may be able to degrade the network particularly giving how large these blobs are um in some fashion if you defer their processing to your for choice yeah I think like we can perhaps continue on the pr or the issue here and um yeah um and I know Danny had a comment about

like wanting to get in get this into the spec release uh on Friday either either way so um yeah if we can just try to continue this in the next couple days so that um yeah it gets resolved pretty quickly that would be good so I I just say about this for the implementation uh we're treating The Blob validation check um similar to how we treat signature checks um so like we're sort of using them as these are conditions for validity for inputs into block processing

and like valid outputs of block processing or inputs to four Choice um so this wouldn't really change the implementation for us and I think the only reason would be to make it so that the state transition function doesn't like have a different uh I guess uh output based on like a Time component which would be when the data availability check expires that's why I think like keeping it just in four Choice it's meant to like uh uh I guess like have the time component um bottled to for choice but

yeah it's my two cents yeah I I think yeah you just for that point in this point that Danny already mentioned it is worth it to move it to four Choice I'm just not quite 100 sure if we may need to make some tweaks to the messaging itself to accommodate that yeah we'll discuss more okay all right so let's keep that conversation on uh on the issue there and then

last as last uh spec uh change was 3174 um yeah how do we uh deal with a sidecar when there's no blobs or range requests Terence you open that then uh some conversation with Mophie on this um and again Mophie you're the last oh yeah Terence already gave a quick recap and then both yes that you're also the last comment throughout this yeah for sure yeah I can give a quick intro on this so um so the issues around how do we treat blob that's not missing but zero right when you have zero blob

sidecar it's about 100 bytes and then so we Define what the respawn Behavior should be so currently it's that if you're up here you must respond to it but not worry so this PR updated to okay you you basically May respond to it so um so so based on the issue there's few points that's followed up the first one is the implementation capacity I don't think there's much implementation complexity between the must and the may just because like you can always check if there if there's a kcg commitment on the Block itself right and then the second point about is that how do we actually the rate limiter because okay

if there's a hundred bytes of the blobside card I don't think we should um incur much cost to it and then I know every clients treat the rate they make her um differently as well so that's definitely something to discuss and then the data and then the third point is brought up it's just that it is like simpler from the spec perspective because like this flopside card does use the data I guess as one so so and those and then you also does this at the cost of time so it doesn't make it nicer from this batch perspective just basically put them a smart yeah that's a quick intro mostly if you're free to add on or anyone else

to add on if I miss something so yeah so moving forward I don't think we can come to a conclusion here just because damage now here but um Danny has a few group points and multiple points so I think I would just keep continue on the issue itself okay sounds good and is this something we need to resolve for like this spec release on Friday as well no because this is no I don't think so this isn't not like a consensus great thing changed just you can always write okay address the behavior on the

Fly and it turns out this has become a default behavior for definite three but for the follow-up devnet we can yeah we we can't just keep an eye on it okay sounds great okay and there was actually One More Story spec issue that I missed uh from xiaoway uh she left uh or actually the issues uh originally from yasik but uh shower you had a comment on the agenda today that um if we disable this there's something else in the spec that we need to revert do you want to give a quick uh summary there uh yes so in this new acapella change

we will update the process ePub function um by we will replace the process historical Roots update function with another new function called process historical summaries update so if boys vocal impacters want to disable this change then we have to I mean lend the to rewrite the process epath function in void44 as well so and in and if you can see the pr that this

function is actually just a lines of simple code in my opinion and so I would like to check if for example open this really want to disable it or we can just include it to the Whiteboard for definite Pro as well so I think there's two parts to it I think the first part is the beacon State itself so the beacon state has to change meaning that if today we stop it out it still consensus breaking because we need to figure out whether to like whether to include this object in the patient's day or not the second part is

okay at the process Epoch do we stop it I'll just return now or do we actually process it right I think for the first part yeah we can I I think it would be nice to follow whatever the behavior withdraws for example withdraw we actually have it in the business day so if we draw us in a different state then yes my hope is yes to have this inhibition State and the second part is that whatever withdraw is doing just currently we draw skinning stuff out so we can also stop this out as well but if we were to improve withdrawal we also should include this as well so that's my thing I'm not sure if people agree with me

yeah it makes sense it's really the last part what I I don't quite understand is this is regarding withdrawals with capella um shouldn't this only be shouldn't this only come into effect the historical uh summaries update if and only if um there's a non-zero amount of withdrawals to be processed so the historical um batch or summary update will happen in every epath process automatically I see um so it does seem unrelated ish to withdrawals even though it's occurring

in Capella uh yes it seems simple enough like the function change so I'm fine with not stubbing this and just including this um for the next devnet the id44 testing I guess my concern is just like we need better tracking otherwise it's just like it's like it becomes pretty confusing on just like what is enabled and what is disabled so like like my preference is just like either enable everything in Capella or disable everything capella

but if we have a better attacking then it's fun with me as well but yeah my main concern is just that I don't there's there's six other clients and then the and then the last variable the better yeah that makes sense I think this is probably also a segue to um there's like another issue you might have opened Terence in um enabling withdrawals in the ip44 yeah yeah perhaps we can discuss both um what to do basically both of them right so I open the issue right now the issues that I'm seeing or I see like we're seeing it's just like um so for the last month we draw has

been making great progress and some of the progress happened after some consensus breaking changes right so uh so the currently for definite three we are using the withdrawals back that's a few weeks old and since then there has been few capella changes they are consistent breaking for example um they added a cueless approach and they added bondability discount as well so um it becomes harder for us to replace code on top of capella because ideally I want to use the latest capella code and um so right now withdraw it's from from my point of view it's in a pretty good State I think um if we look

at a Discord conversation there has been few successful interrupt tests net and I think they're getting pretty serious right now so given the withdrawals back it's in a pretty good State I um I added a proposal to um to rebase Capella um sorry can we base 4844 on the latest capella and Danny um I did a few viewpoints in the PM discussion as well basically um they are releasing a release on Friday and then another Friday release will be used uh on the subsequent test net um thanks team and then so therefore for the next four four tests then we can perhaps

um Target that as well or we can Target that for the compelling functionality yeah so that's basically it yeah I am I think we might be getting to the point where enabling the functionality entirely is just simpler than like whatever difficulty we might have with a uh withdrawals change which like there might not even be any I don't know but yeah especially with um what shall we brought up I think um Terence is right that we should

either enable everything including that component or disable that component as well so I think generally I'd be in favor of just enabling everything all right the implementers have spoken let's do it okay oh I should we also talk about the block value um that Terence brought up I think um whether we want to include that in the next death pen as well yeah I think my vote is yes for that it's because that makes no sense to to to basically base the latest capella but doesn't have block value I'm curious if

there's more thoughts uh I'm on the same page right and again I think there's like two different conversations also happening in the chat just for the we're basing on capella obviously this is like on the on the CL side on the El this would mean we're based in Shanghai like where we want to have all of Shanghai basically I I don't think there's as much interactions Beyond withdrawals but yeah I think that would be the the equivalent right as well from the execution point of view

yeah I believe uh there isn't really much change because uh if withdrawals are not provided then nothing is basically added to the state so it's very simple site uh withdrawals same uh important for um the AP 344 because it introduces the term stem based books working and everything else is not so connected to this European right so if we could include uh just withdrawals uh as a base layer for 4844 it could be enough

probably eof and other stuff uh where looks like we came with that but uh it doesn't look like very needed for the ccip Tim I should say that it's for the awkward offs uh call to get eof stupidity information yeah yeah we can also yes I don't include any of the eof erps for now functionality yeah and I think it'd be good to yeah see from all the time teams like Alma cordevs where eof is that before before

making a call on that yeah but on the CL side it seems like yeah rebasing doing it for Me based on capella and having that for basically the next step that is what what we're going for and the next step that I guess being the one that interrupt and like uh in in about uh three weeks now just to clarify is the next definite going to have uh block summaries yeah that sounds about right

cool so for capella on Friday release did you say four or four sorry oh I mean every every thing in capital will be included to the forever fall in the next release okay and do we think we can do that change on Friday because I know ontarence is PR uh you and Danny yeah I mean it will need some updates in the test so I can make it

before Friday I think okay awesome that would be great um and we should tell Danny about this um I'll send him a message after anything else on the specs okay and then the next point was like about definite three um I think it's sort of getting an update from the client teams but um the the other points I wanted to talk about was like how to rebates on capella and Terence your

um your cable that you have there but I think based on this conversation basically all of those features uh that are not in devnet 3 would be for devnet4 and we aim to have debit for kind of on the Master capella is that everyone's understanding yep and then yeah I guess for them that three occurs to hear about the different client teams where we're at and if there's any any issues that uh We've run into hmm I can give a quick summary so on the prison side uh there's definitely I um overall I'm very pleased with the

with the with the devnet um because of its successful I mean it's mostly because just like we have been finding many issues we've been fixing it mostly on the PVP side so I want to give a special shout out to like more people setting up and then keeping it alive so um we fixed a few issues regarding just like um how do we handle p2ps p2ps trimming and stuff like that and then um we also we're currently fixing the very limiter So currently even for blobs they are zero um we don't really like score the period correctly I think just because like a lot of a lot of them are getting dropped

during thinking so we're fixing that but overall um I'm very happy because like I'm happy with this before New Year just because I would actually get to spend more time on it for Lighthouse we were able to sink to wherever the um test note was stopped sounds good that means like uh where like validating the blocks however prism is producing them um but I'd still be interested in if we could I guess we can on this test next I don't think deposits are enabled but I'd be interested in testing out

like like house proposals if other clients validate them they're about it Lighthouse blocks and then also just like um yeah I don't know I guess that's the the main component as an update load star has been able uh to successfully swing the devnet 3 uh but what remains untested as right how Lighthouse has mentioned his proposals and the gossip so I think that is something we need to address in external so that we can do multi-client uh definite hopefully um as for another mind we

tested mostly with prism uh try to synchronize and look quite uh High numbers of books we placed some Forks looks like on the internet 3.2 uh yeah uh but it looks like its usual state for now and uh we are trying to integrate with cluster to run with them and we'll try with Lighthouse this week uh so that's the state and I can continue to hack on Aragon um

got a little blocked by that uh hashing issue that we discussed earlier but now that that's resolved I can continue making progress I'll also to update for ethereum JS also has been able to successfully seek that I've met any I think that's everyone anyone we missed um and yeah I guess it probably makes

sense to just keep working on devnet3 for the next couple weeks and then yeah start moving to devnet4 as we as we get closer to uh interrupt does that make sense for two people yeah makes sense sweet last thing I had on the agenda there were a couple of testing uh PRS that uh were discussed on the last call I I was just wondering if people had any updates on those so I know Mario Vega had a PR The Hive uh Proto you also had a PR a hive and uh actually yeah yeah Mario and Proto basically yeah the

testing front um any updates there or anything uh to share well not directly for for it for far but for capella the tooling that's used in Hive and outside of Hive as well as the East to test net Genesis 2 have been updated with capella supports not to have to change that's coming up Friday however I will updated as well and then this week I'm working on Friday before support so we can start 44 does not at the forage for first it's rather than going through the first um related to that

um I know maybe Terence you can answer um is prism able to Fork um sorry Start directly from capella use capella a capella like State as it's Genesis yeah sorry it took so long but I think we gotta working before the holiday and um I think that's what they have been using for the withdrawal test now as of today so yeah yeah that's what we're using for the withdrawal test Nets on all plants that is good news awesome thank you anything else on testing

I don't know that there's been any other updates on the large block uh spam tests either I know JoJo's uh posted in the chat wondering if we if we wanted to do another round of these um any updates okay if not I'll follow up async uh and and see what the best next step is there um on the pre-compile benchmarking I know on the last call there were some updates saying that like uh it seemed like never mind I believe was also sort of converging around the 50k gas cost has been being reasonable um any any other changes on that front

since uh the last call uh another man tested on some different machines and well it it is different but it is near 50 000. um I guess and probably we need more like five or ten thousand or less um so I think yeah in that case that's way a bit more maybe like let's continue the adventures

but is there still work happening on the libraries themselves or are they pretty stable it looks stable uh so sort of stable I think there is like one or two PRS that need to be done but I think there's Stables okay so stable enough that like we don't expect some big optimization because I know like when we talk about this uh a month or two or maybe like more like six weeks now with the holidays we're going to talk about this like six weeks ago um there was a lot of um there was a lot to talk about like we might want to optimize the libraries before doing too much benchmarking and so does it feel like

we're in a good spot now with regards to the library and um it actually makes sense to maybe get like the four El clients Benchmark um and and make sure we have a yeah a rough Target for the gas price yeah I don't know if any uh pre-compile optimization efforts going on right now I mean there are potentially Avenues to doing that but I don't think there is anything a shorter term that uh yeah and I guess uh I assume Aragon will be pretty sooner to get in terms of the implementation um base two where are things at uh would

you guys with regards to the pre-compile are you in a spot where like having some folks benchmarking it would be it would be helpful or uh not quite uh not quite the pr is open we're waiting on it to be merged but that should be done shortly and then after that we would be able to uh benchmark okay nice so let's maybe yeah in the next week or two um as these get kind of finalize the merge um we can we can then run some benchmarks I think comparing at least get bases never mind you know if possible Aragon and um yeah then we'll have a good idea of what the target for the the gas price um but at least it seems like it shouldn't be like a massive change like

we go from 50 to 60k that's not the end of the world anything else anyone wanted to chat about okay well yeah I guess uh that's it so um yeah thanks everyone I see you all along and we'll have another one of these calls next week bye uh thanks