EIP-4844 Implementers Call #22

Transcript

okay we can probably get started um so this is our 22nd 4844 call um so yeah I guess it makes sense to go over uh all of the spec changes that we discussed in uh awkward as last week I know there's been some new PRS uh about that and um yeah then at the end if we have pumpkin cover the state of devnets and um if we want to get a target for devnet6 but I guess to start uh Matt has uh draft uh PR basically um that removes rlp or sorry that removes SSD from 4844 on the El side

it's been open for a couple weeks uh but he asked on Awkward devs If people could review it to see that um yeah there weren't any issues with it before we we merged it in so I don't know if anyone has thoughts on the PRS or anything they wanted to discuss about it okay uh so everyone happy if we go ahead and merge this as it is okay I'll take that as a yes um rpmat uh after the call and let him

know um yeah so we can go ahead with this uh Mikhail you had um you had a PR to add uh the or to validate The Blob version hashes in the NG API do you want to give a bit of context on that I saw you just opened the pr oh is Miguel here he is not so okay so this is a PR I see uh gajinder and Terence have both uh plus one that I do either of you want to give a bit of context sure so last week we discussed on

pushing the rlp validation from the CO2 El that means that on the consensus side when you receive a Blog you will convert the kcg commitment to the version hash and then send it to the El via the new engine API call so it's the same as the new uh validate payroll code except now you have a perimeter that includes the version hash so yeah so that's what we discussed and on the co side luckily we don't need to add a new version hash to the block field because we have the key to G commitments we can do the conversion instead but we do need a minor update on the spec they just basically say that hey now we have to use this new new API call so that should

be a very simple CL change I'm not sure if anyone's working on it though but yeah yeah I don't think anyone's working on it shall we and I should chat about it hey shall we um and one of us should pick it up it's really the removal of a function and then the change of the interface to notify of notify payload which is kind of our abstraction for the engine API to pass those fields and that's very minimal and it's really kind of a subtraction rather than addition on the consensus layer and I'm sorry I just joined and I can pick up the changes after that and so while when I was cooking I did one minor

issue is that the place we handle the version hash in SEO code is a little bit far from the process Extrusion payload so I just I wouldn't have to move the sequence of State transition but that that should be not the should not be a big issue I mean just trying to reject for the validity of the payload and

I I can sort of make the corresponding chain controls the specs to reflectors okay anything else on that PR and the upcoming chain three to make to the sales specs um oh and I saw Proto just had a comment okay so he's basically saying he's fine with updating everything there's a z

later uh date and next up uh so the other thing we discussed on operatives last week was the Indian nests for from the El side I know there's been um some more discussions on the Discord and specifically about like the scope of the change didn't necessarily seem clear to everyone so yeah sorry and I'm trying to pull it up right here but um yeah I guess does anyone have thoughts about just this transition of using

um big engine completely on the El um okay yes and I have your PR Vision there oh and Matt I saw you just said that uh Blake too uses little Indian on the execution layer but I think it's the only exception like uh everything else all the other pre-compiles and the evm it's began the Black 2 is the only exception did we look through all the other pre-compiles I'm not super familiar with the inputs on them

I mean it doesn't really matter that much to me I just know that we're kind of saying this is an argument that everything else is Big Indian and I realized that Blake too was not and so there is precedent of having some little Indian maybe it was just an oversight we should do whatever the best thing to do is and I just am not the person who's going to be interfacing with this or writing the software that interfaces this so whatever those people think is the right indian-ness is what we should do in my opinion it seemed pretty clear on Awkward deaths

it's like people wanted to do big Indian from the El side and then the question is just if we do that does it impact the libraries to like too large of an extent I know then Grant and Kev had some like spreads about that from the Discord so I mean basically so if we make the pre-compiled um big engines then it basically it would also make sense to then make the blobs themselves big Indian because otherwise you will have the same data potentially when you when you use the pre-compile on uh in range you'll have the same data once in

bikini and one little onion and that seems really confusing so if we do that it feels like the right choice is just to make everything bigger so the periods include making blocks being Indian foreign yeah doesn't that mean that the cl then needs to deal with the big engine and which I'll have the mirror problems yep which is probably why it was a terrible

idea to start with to have the clb in this Landing means to just verify the blobs using kcg libraries I don't understand where the CL would actually be interpreting the content of the blobs and now we also have version azures that CID Supply which even will check so CN does not actually has to check whether the transaction and a version has used match so basically transactions the commitments match because cm is creating a virtual issues for email to check whether the transactions

and the created version so I don't see where the serial actually at the blog sorry I I really didn't follow could you repeat that so the only point the CL was interpreting the blog as of now he was checking wherever that kcg commitments and that transaction uh version has hashes match

so as of now if there is a change that CL will send the version hashes computed version hatches to um to match so basically CL only has to do kitak of their commitments and so CL value does not need to interpret what the Globes are so it does not actually need to with the content whatever the containers doesn't the CL um have to interpret it whenever it computes the kcg commitment it verifies the kcg Commandment so that is happening through kcg Library

which image sort of transparent to it's operate to the CL and as far as I can remember that ckg Z guys I think I have told me that the TCG library is very automatically check whether the business field management so they are basically under DLS modulus so the

same signal doesn't need to do any check we just need to pass verify blobs match or whatever and everything else will be handled by the kcg library right so light five has a comments saying like it seems like based on what you just said we can use uh big Indian in the El and little Indian in the CL is correct sounds like that's the case library library [Music]

deals with SSD types of the blobs to sync them and essentially I mean I don't see how it has any impact on how to interval development related interpretation as of now is happening on CL side yeah it seems like I don't see a reason to make a big Indian on the co what do you mean Matt blobs by Kenya yeah yeah I mean it should probably the things should probably just be the like

normal SSE values and if they're stored a little Indian then that's how the libraries are called it doesn't seem like that's an issue wow so I think I think they should be encoded as big Indian if we make the frequent part again now you you can say that the that from the CL point of view it's just Blobs of data rather than being an integer so that's probably a fair argument you can argue that um but uh but I guess I'm not completely sure how this and this uh how this abstraction will stand up with

future upgrades say proof of custody and data available something probably fine for today there will be something not social but proof custody to be um just like it does like yes theoretically like at this point when it's just blobs you can probably say oh no it's just data so like yes in in actual CL code outside of the libraries you will never have to actually Implement anything began yet yeah I agree CL doesn't need to do anything we can win because uh I mean I mean but it's just blobs and it's a new Twitter for cl but I'm saying this is now

yeah I think you're not like seeing what's like the future upgrades might bring but um I mean I still agree it's our best option but I think like future upgrades might make it necessary that the cl will actually have to deal with this asset address and then it will become again computations

um on this data I mean again you we will see how much we can put them into libraries um but it will be more complicated because it also involves the private key um of the office on the outside so okay I'm not quite sure what take it from

here like it's it seems like I don't know people have a bit of a different view on what's possible and where like whether we can actually not have the you know begin the tendency leak into the CL but yeah I well I mean it's like everything is possible right I mean you can't do it with deal with any Indian it's like it's just an engineering problem the question is like how how annoying it will be in the future and I mean I I agree that right now it seems just making everything big engine is the right thing and that like yes

right now the CL will can contain all that in the cryptography Library um which is good I'm just saying as a warning like um there is like at least an approved custody I see a future upgrade where that abstraction May might break down like that's just something to be aware of now that we're introducing now basically down the line I think this might cause us to having to deal with 26-bit big Indian integers in this year okay and so okay so I guess just to move on on this call does it make sense to um agree to this year probably want to

mention it on the CL call later this week uh when we have all the teams there um but yeah basically yeah have begin proposed having big Indian on the CL and it would probably be good if we can have like a PR showing this by the by the Thursday's call okay no objections uh so okay let's do that then um so yeah we can bring it up on the agenda for Thursday and hope for you I guess does anyone want to volunteer to write that PR on this CL side

what is this sorry what exactly is this PR sorry I won't get that so using big Indian like what would require a big Indian on the CL which is what I said that is already in I feared that so it's just basically introducing a new uh constraint and DNS underscore 2G and that is basically being used and all the polynomial commitments yeah is that

uh that seems like it's is that the one uh one that Andrew just shared in the chat no that's the one okay cool so let's just make sure to like briefly touch on that on the CL called the uh yeah at least make all the CL teams aware okay and next up uh Jimmy Chen had an update to the um Builder spec uh he can't make the call but he wanted to share this here I don't know if anyone had any feedback I know I guess in there you left oh no sorry this is from January oh you left some feedback is all three to three days

ago um but I don't know if anyone else had anything they wanted to mention or concerns about this but everything else seems good um great and then yeah people can comment on the pr directly if there's anything else but um yeah just like this like that then next up uh Maps you had a renaming uh to call data hash blob hash instead if you want to give context on that

um yeah so on eof there is this notion of having data sections within the contract so you have your executable code and then you have data that's not executable and so there's some op codes that you'd expect to interact with that data things like data copy and the data hash sort of conflicts with that naming scheme from eof and it's not really clear is it the data hash of The Blob call data or is it the data hash of the data section so I think the blob hash is just a little bit more aligned with Howard talking and thinking about the that blob data

I don't like it [Laughter] no actually I also like it it makes sense to me it's like you're disagreeing with yourself there right clients I have severe multiple multiple personality disorder um does anyone dislike blog hash I really like it okay I guess no objections let's yeah let's merge it can have 4844 author approve it do those exist here

uh decred is a fortune for author I think right yes okay so thank God if you can approve mats to PR's that would six nine eight five and seven thousand one uh just so yeah she doesn't enforcement yeah once I get back to a computer I can try to do that yes awesome thank you okay anything else on this spec okay if not um yeah anyone want to give an update on uh devnets before we do that there was a PR showed

in the Mario shared up here in the in the slack oh in the channel sorry yeah yes I just wanted to chime in just because it also needs Auto approval so and this is the one we discussed on all core devs right yeah yeah exactly okay I guess math can approve this one I think the the point with math is just because he's an author he doesn't want to approve his own PR like force merge his own PR but um yeah if it's okay if this pier is okay I can approve it yeah yeah I think on Awkward actually we're all uh in agreements that we should move forward with this um yeah definite five anyone want to

give a quick update on where things are at yeah I can give a quick update um I guess I haven't checked on it this weekend but um uh last uh state was we were running into some issues with um prism being able to sync um and I believe the only remaining uh CL that was still healthy was this Lighthouse um so on the execution layer we had some issues with Aragon as well those I tracked down the issues and fixed but which is when we turned up the issue with being able to sync from scratch uh and things started to get stuck so last I checked um we still had a prism um death client that was running successfully because it had been going since Genesis and hadn't been restarted

any of the ones that were restarted have have since died um but the lighthouse Aragon Lighthouse prism clients were still going um I think maybe Lighthouse ethereum JS as well um so yeah we I think lodestar was having issues as well I don't know because you can give an update on that whether that's been fixed or not slot um basically need a lot of star or any

other CL that were noticed was not able to find a period to sync uh the blocks from and uh I of this I couldn't unders I couldn't see I didn't see any issues with regard to request response I mean that was not getting successful so it was you know that the level of any of the request response blood methods uh I I'm not sure why I like where my White House was not able to serve the peers so it seems to me and as of now that when it is spelled because situation

no that's right there was some concern that um Lighthouse may be um blocking non-lighthouse peers um and I guess um someone provided with us with a flag to disable that I don't believe we've turned it on yet so that's probably the next step to try I mean vision I'd be happy to like look into this with you um if you want to like catch up after the call um but yeah I think we are still like we're finding bugs locally with um Lighthouse peering and with like

serving by Roots requests for example so I wouldn't be surprised if there are issues with serving other peers yeah I don't know Terence are you on the call or is there any update with prism do you think this is the same issue um I'm not so sure I haven't looked at it I think last so prism is stuck at the issue where remember we talked about that uh so blobs by range um uses the slots as the Gap but right now there's also uh the number of Commandments in the middle too so sometimes like it's weird if it's all

about because you're supposed to multiply the slots by the number of the commitments so there depends on how the responder appear does sometimes they may serve you too many sometimes they may serve you too little but when they serve you too little then and then and then in prison's case we just couldn't sink so I'm not sure I followed that entirely um is this what's returning too few um commitments oh yeah so it's it's the blobs here so blobs by range if in the event that City day there's like four Commandments in a

slot and then we get the cases where the only like one is being returned instead of the four because it's because it's not multiplying the commitment number by the slot so I guess the question what is doing that that sounds like a it sounds like you're describing a bug or where is this coming from right this is like a bug on the um some clients have this book I'm not sure if it's fixed that's what we talk about on Discord like a week ago so there's some disagreements there between uh blocks by range and blobs by range but yeah we can just easily show up

did this show up in hive yes it could show up in the hype right so I so so say today if you do blocks by range and then you do blobs by range right after you should get the blobs that reflect in those blocks but then we were not getting that and uh yeah I think Hive is a very good test Target for this a resulting about returning the blobs from the execution client or is this some other one this the uh this uh this is P2P so it's not the yeah yeah okay okay yeah yeah the only test we have right now in high is for um returning the plus from the execution

um execution clients to the CL inside to get payloads but I think this is something else right okay yeah I need to check on that because we don't have this yet for that okay do we have any tests against the independent just CLP to P messages we have only for the engine API right now yeah yeah basically the intermediate might be a good thing to open up I think there are a couple tests in the uh 4844 interop like Docker compose repo

is there a spec ambiguity here there shouldn't be we I'd be weep but like other clients just maybe interpreted wrong but yeah I think the spec is fairly clear here okay so but we're not aware of which clients are interpreting it this way but perhaps it sounds like it's probably a lighthouse since that's the one that can't see I don't know I forgot I think I have to look at this quick conversation but we talked about that a few weeks ago but I guess like people hasn't haven't people were busy with something else we haven't gotten into fixing the blood yet lighthouses incorrect here

yeah I uh I remember the conversation last week and I thought we interpreted it correctly apart from we just had like a maximum response that was too big but I might be wrong I'll double check imagineers there's we can something we can check on a load star site as well thank you are you you're on it

oh yes uh I have two mute buttons one next on the software and one is the real button sorry so yes I will check on the roadside but I think we also take it as slabs the count to Via slots and then potentially adding some Hive

tests or somewhere else to to catch it yeah yeah it might be a lighthouse issue and we haven't been testing against Hive yet so we can work on that in the next like week or so just to give a little bit more context about height uh I don't think at the moment we have any similar tests from peer-to-peer in the beacon client so um we need to write a new test suite for this but um yeah it's just it's just it's gonna take a little bit longer than you should to raise the test because there's no

um there's no tests with that specifically does this kind of test yet um yeah that's it basically yeah I mean it would be high value to at somewhere in a deterministic place before we get the test that's test some of this stuff obviously we've we don't really have a systemic systematic way to test the clpdp and have it since fave zero but um if we can move in a direction it'd be a good idea yeah definitely definitely I think I think there's a lot of this is specifically what I did for it's just that we haven't used it for that yet but definitely I I will I will start to

work on on it and I need some help from you guys I will let you know awesome thanks is there anything else on devnet5 that we're seeing that we feel like we should take time and uh address or I think that's the main thing right it's it's pretty an unhealthy state right now because of this issue I think you get that resolved um and that's the only one that I'm aware of that that but still holding things back um you know other than that we just have to get implementing these the new changes that came in and all core depths around dssa

yeah and RL yeah rlp application um right so I don't think we want to put too much into this devnet it would be good to resolve this issue and confirm at least that everything's healthy when this is taken care of but at that point I think it's probably worth shutting it down and going on to the next one yeah I think I think that makes sense and then also you know uh writing some if we can write some test Suites in parallel to fixing the devnet so that like when we have people joining the next one we um we also have better static tests that uh we can run the the clients against that would be amazing so does it seem realistic that like in the next basically a week or two we

resolve these issues um and get the implementations done for like the rlp changes and the indian-ness and uh in our call two weeks from now we can we can spend most of the time discussing devnet6 and trying to get set up and obviously we have the two awkward Dev calls before that if if we're quicker than that but um at the latest yeah we can chat about that two weeks from now um sweet anything else anyone wanted to discuss today yes I'm sorry okay go ahead oh thanks uh a small the small issue

which is too much result is about uh Library uh for old abuse I mean we need to know will be a list Library be updated or we just uh need to implement that's which uh by ourselves as the execution there Developers Library Developers and additionally we could try to test this case by adding some um some notes they have not maybe next

devnet with this old CPUs to confirm uh block verification is the performant enough and the Box on every side there's two wishes this is the compile time detection of I mean runtime detection of CPU capabilities yeah yeah should we do that in Secure or realistic will be updated consider such case uh I don't know how you would do that in

ckcg I think it has to be done in Blast okay but shall we wait for this week so let's decide or or not because so this is problem but uh not sure if it will be resulting is there a bit at any time in the future because yeah I get what you're saying uh they don't seem very interested in fixing it from my perspective

it would be great if we could as a community I'm not even sure that they would accept a PR that fixes that yeah I thought PR at PR I thought Peter had suggested right in your PR but I haven't checked the thread yeah he did uh once again I don't know how complicated or simple would be to do that I'm leaning towards like I think it'd be pretty complicated unfortunately like the the this is like

the there's this Pro script which generates the assembly so it is like kind of annoyingly complicated to make changes to this if you don't know and there is a discussion a few comments in This Time background we've we've basically lost you

I think she said they're going to have a call with supernational Maybe I did reach out to someone at Supernatural privately and they did see the comments they just haven't made a comment back yet and they were going to discuss it internally sometime this week okay that's good until the second question was is it real to help her Association um like seems a good test case in terms of Step business and performance

yeah well is there something else we can do you mean something else for this runtime detection oh yeah yeah okay so yeah so we can add with the runtime detection this is a change we want supernational to do yeah don't you don't want to work around I know is on this issue number 10 where you can basically work around this problem by loading two instances of blst libraries and then in your app change in your client change now check the CPU and and call the corresponding copy of blsd

this is something you can probably do if you need as soon as possible but if supernation is is considering I mean if they see in this these comments and are willing to do something then probably best to wait a bit and then see what to do but there is a ugly workaround for this problem well we can try and in the meantime yeah

easy to work around okay any anything else I know there was a second I think Mario was you who also had something you wanted to share yeah basically um Okay so first of all I want to share the link the test that I will be referring to so um this is the one so yeah basically this is the evm test vectors in the form of blockchain class and they do contain a lot of foreign Focus tests so I wanted to propose that before the next devnet um we make the running of this uh

execution inspectors mandatory yeah for the for the next letter because I think most of the execution layer issues that we found in the previous run could have been caught if we had run this this test on our plans so yeah basically I think if we clear our decision before the devnet we will save a lot of debugging time and we will find more productive issues more relevant issues um that will be definitely more interesting so right now there's uh some spect changes that are not getting tests but I will make sure that um all of these pack changes are in these tests and we will make another release um before the next devnet so I don't know if that sounds good

with everyone yeah I I agree that would be that would be really useful okay cool yes sir we will be releasing another another bunch of uh another newer test with this spec updates for everyone to run before Before The Next Step awesome right in the chat there was another mention of the removing contract creation from The Blob transaction I

assume that's still not controversial and uh added that to our list of PRS to get merged uh which PR was that sorry uh Matt had we discussed it I believe it was last week um to disable contract operation the optional to feel remember right right yeah you know there's anyone here have thoughts about this and I assume it wouldn't be it would be sorry possible to add this in another hard Fork if if we wanted to right like we could launch would it disabled and then six

months after um enable it now that it's ROP I don't know I don't know enough about our LPA optional handling who's our ROP expert here is that an encoding format change if we decide to make it optional later on uh it's just that we don't allow um contract creation transactions so the two address has to be present it would like yeah it would change the RP encoding um and uh like the prop like one thing I'm thinking about it would add another

thing that we need to check we need to make sure that it doesn't do the contract creation but that's one check versus like a bunch of checks around different things like does it work whenever you create a contract with a blob does it work when you create with four blobs like there's a lot of little things that you end up having to check does it work when you return code does it work when you don't return code I don't know if it's you that's typing not their various double checking with

the okay okay Olivia needs to change like the rlp encoding spec in the EIP but we would need to add a add something to say the uh to address has to be present the 4844 transaction type does not allow contract creation which I can update the pr if people are still okay with with this it's not I guess it would if people are

okay with this can you voice support I don't know if people are okay with this or have not thought about it and I don't understand the implications or something so one thing was we added this when we were going to have to deal with SSC optionals right so now that we're not right I don't think it's as important and then we have to ask do we want this like non-standard or like you know non-uniform property compared to other transactions yeah I mean I think that I I and some other people that I've spoken to in the past have wanted to move away from having contract Creation in transactions in general just because it adds a lot of

complexity when we add transactions and we have the ability to do it from the evm so this may look like it's lopsided right now but I think that going forward we should consider just not allowing new transaction types to create sure but so this is like SSD in general like if we have this like discontinuity when do we actually make the change right now uh I I think we should um I'm I'm uh I'm leaning towards this um but I think we should have like one more week to discuss it with like the RP experts in in the guest

team yeah so I'm I'm weakly in favor of like moving this along but also having the option to say no at some point this week next week okay yeah let's do that then let's try to uh discuss it I think this week if for whatever reason we can't get agreements this week I think let's bring it up on all Courthouse next week um but hopefully we can do that um yeah I'll update that PR and post Uncharted data okay thank you very much um anything else anyone wanted to cover

okay well yeah thanks everyone um can wrap up here and talk to you all on the Discord thanks thank you bye-bye bye thanks everyone see you guys