EIP-4844 Implementers Call #12

Transcript

okay let's get started uh this is now call number 12 uh for 4-H 444 um a couple of things on the spec side today so uh there was an update on the cryptography side um Alex I don't think he's on the call but he spent some time looking at their pre-compiled and shared some thoughts right before um so if anyone wants to discuss that we can if not please share it um then Terence had a bunch of stuff around devnet4 and uh there's some testing updates and I see uh Sean has added something uh related to the engine API so we'll cover

that as well so I guess uh to start uh there was this uh CL spec for uh the crypto side of things another search on the call yes uh yes hello Tim hello hello okay so I can give a very tiny update on this because it's a pretty non-intrusive change but it concerns um perhaps the people who are writing alternative jcg libraries other than cksg uh so I don't know go to ECG or Solus with the rust jcg thing uh basically on the evaluate polynomial in

evaluation form function we used to assert when the input was a root of unity when the input was in the domain we we were not having we were not handling that edge case because it was extremely extremely unlikely it would ever happen given how the function was used in the spec but um now we're exposing that function publicly as well uh in that perhaps you know Roll-Ups might want to use it so in that case uh we decided to uh handle that edge case instead of asserting so the spec has been updated so that it Returns the correct value

even in that case uh it's a pretty trivial change but uh because we want to have the same behavior in all the crypto libraries it might be worth uh checking it out if you're writing your own implementation that's it thanks for for this update uh I just wanted to generally ask as at some point they will decision to to verify or to validate the inputs for example that that something fits into models and it's canonical is it we do

have this as a general um let's say idea or general way or this is for particular case what you mentioned hmm um this is a different question like I mean it's a separate discussion but this the what the the fix that uh George just described is handling one special case that is in the previous way the function was used extremely unlikely and extremely unlikely means like 2 to the minus 250 so like it's it's it really should never happen unless like like it's much less likely than a hash

Collision um but but we now added another way to use this function which is not it is not that unlikely because we're also exposing the API to computer kcg proof and uh especially optimistic rollups will actually intentionally usually want to evaluate in the domain and then it would actually like be useful if a function can handle that so that's why we made the small change um I think the the question of like uh validating inputs is a separate one and I think we are only handing handling it inside the domain if I remember that white George I think we we made that explicit right that all well are you thinking about the

pre-compile or you mean in general for all the functions uh what do you mean yeah I think your channel for the functions right like we only like we like all field elements have to be reduced in order to not like have non-canonical representations right yes yes so the pre-compile has been modded such that uh you need to provide the canonical input and uh yeah that that's for the pre-compile which accepts arbitrary elements basically now for all the other functions for all the other functions that are public we have also like at least for

the library side we have edited the the K the ckg library to accept bytes to make it easier for the client for the for the clients to use it but I'm also I still haven't fully understood your question uh I think the question is whether those whether those pipes have to be reduced whether they always have to represent reduced field elements and I think the answer is probably yes yes I think so but I can double check that might be worth checking but it feels like yeah that's that's uh that like because so what what are we handling where are we handling this one is in the free compile where we said it's better to have this reduced so that there's no like malleability uh kind of

issues going on and the other is uh in the in the blobs right which are also just like basically bytes that represent Fiat limits and also there we want blobs to be canonicals I would my intuition would be that um all inputs should always be canonical field elements correct correct and and and and and the roots of guilty that were concerning the previous discussion are canonical like within the field modulus so they they are indeed very orthogonal discussions yeah yeah this is a completely different issue though yeah um okay thanks so uh what I would like to ask if if it's a if it's possible it would be

really great Whenever there are such uh details changed that there is also some tests that uh covers this so this would be very helpful for uh you know for the other implementations to track her and be compliant with uh with this small uh changes because I think project has added tests for this you know where are those tests because so far I think some of the tests are in bindings and in ckcg bindings but there should be somewhere else I mean it would be really super nice if there is one Institute where everyone who does the changes they make sure that these subtle things are

covered so so that would be perfect for this particular PR I wrote I wrote tests for the consensus packs for the specs for the spec to validate itself that it's correct I didn't I'm not sure how one adds tests that all the client all the libraries need to be conformed with I'm not sure what's the process to do that but maybe you're right that it would be good to have like formal tests for that maybe Cavs you know uh yeah there's a oh sorry yeah I mean if if you wrote on the consensus layer then eventually uh these uh different uh Library representations

will will notice it is that's right am I thinking correctly or should they replace my question I mean if if there is um if there is test that covers this subtle change in the cryptography Library uh somewhere deep inside but the test is on the consensus layer tests then eventually somebody who will use the southern native kcg Library will find that it's not compliant um I guess that's one way that it's

probably easier to have them separate since they're for the cryptography so just yeah that would be much better yeah yeah if if that's a at the unit level somewhere uh close to the photography Library yeah um yeah I had a repo for the fuzzy test vectors but I haven't updated them because I'm Still A Better Way at the moment um I got yeah aspiratory wrote in the chat I basically was trying to copy what they did what um Antonio did with the BLS 12 381 tests but instead of python it's gonna go okay so so yeah I mean from my side the

message is that if if there is a capacity and if somebody could collect them and they also maintain from there all these cases in one place that would be really perfect right yeah I guess there's um an argument to sort of rewrite those the ghost stuff in Python so that it just copies what Antonio did it's a bit easier to read as well anything else on that front

if that okay uh there is a question in the chat a bit early on about data hash yeah hey this is Andrew from the uh from ethereum JS um I was I was just reviewing my test coverage to realize I hadn't done written any tests for this for the new OP code and the EIP doesn't say whether we're supposed to put the like if you get a version hash because I mean the data has just supposed to pop the you know it's supposed to see if it has the version hash um referenced by the input is it supposed to push that data hash back onto the stack that's what it looks like Geth is doing and I just couldn't I'm not a go expert and so I just want to make sure my understanding was correct because the EIP just says return the data so it doesn't say push it back on

the stack or what have you in so I just want to make sure I'm doing the same thing as pushing back on the stack SD correct answer I'll try to clarify this back thank you yeah I know that's fine I I I return has a very you know just I was just returning the value which wasn't actually doing what it was intended in my care then I realized that and so I I made that change I just wanted to verify that I understood correctly so thank you okay next up uh there was uh okay let's cover the engine API uh PR as well so pull request three five five so uh

okay and so this just got merged um and yeah I can talk about this one yeah please yeah um so I just want to make sure that the El clients four eight four four implementations allow for this but um so White House tries to query the latest available endpoints like when it starts up and through through the whatever works occur um previously we've had some incompatibility issues where like uh you know clients would only serve like the V2 at capella and then B3 at 4844 or something so I just wanted to make sure people

were on the same page but this one um they might already be I'm not totally sure but that's about it um Sean do you know if the current withdrawal I forgot what the testing is but the the current one or the upcoming one will have this as well yeah I think so because we recently recently this was incompatible and then um like we sort of made a fuss about it I think it's now implemented for the capella El implementations okay I think that I actually like them here for Roberto and Ice to find out which commit

um EO is using and using get as an example and then basically and then put that in the coinbase um repo okay cool um and you were originally asking about the El teams I don't know any of them had some thoughts they wanted to share I wouldn't say I want to I just want to write something on that if we are making this

work agnostic then why do we need V3 version I could just reduce the versions and take with yeah I'm not sure about um specific reasonings like but I mean I think we can remove the V3 version later on when we get into a more production stage but I think for that therefore it's probably too soon to remove it because client will have to change the code on that I think he's saying we can can we just remove me too as well

and just change the return type depending on if we're past the Shanghai or not yeah I'm not across the reasoning in the execution API I think it's possible if we're making versions backwards compatible to not have to upgrade the version every time but I don't know I would have to talk to the spec maintainers there I just want to make sure we're on the same page for devnet E4 really right and I think that was basically the next thing on the agenda so if you want we

can just kind of cover definite D4 now and and yes see uh in terms of what's included that we're on the same page does that make sense sounds good to me okay so I guess starting so Terrence um I'll share your comment in the chat um but you had a a comment about this basically uh saying that uh your impression for V4 is uh we use consensus spec 1.3.rc1 which has uh on the CL side uh the Goya amount for withdrawals through the engine API the historical summaries and the Genesis 4 version for BLS changes

um on the El we have this uh guay uh unit in the engine API as well um this PR that we just discussed um and then um basically the uh all of the eaps that are included in Shanghai so uh withdrawals uh warm coinbase push the real limited init code and the fork ID checks um based on timestamps I guess does anyone disagree that this should be the spec for devnet4 or that uh yeah there's there's something that uh isn't included here um there is one thing since uh

withdrawal uh three has moved from V to V change I have MF so am I correct to assume that uh since uh eip4x4 would have not four will also be the best uh on capella so we'll have that change over there because correct we can't really okay and I think yeah Terence had already listed that at least in the engine API um but uh I assume given it's it's so in the engine API the assumption is like it's also stored on the on the El in yeah the problem is that uh it would get

difficult to cherry pick out the commits and so since all our work is now in unstable our main coding plan so I mean if possible we should make sure that everything that is in withdrawals is definitely and aip4 yeah and just to be clear so yeah this gray chain like this way take away change was part of withdrawals we're gonna have to do it anyway and so we would rebase on kind of the same uh withdrawals code for 444. just does any client team

disagree that this should be the the it means that we do not include any changes in uh withdrawal through calculation I heard Grace wanted to switch to three hash like that mercury oh right because we we haven't decided that yet um for the root is that what you're saying like which yeah we're gonna make this decision on on

Awkward devs Thursday it's I'm not quite sure you know where it's gonna land but it seemed like last time I checked the consensus was that the El route should match the CL route um but I'd rather not like have people kind of do work and and like have to change it because of all core devs um so like I think clearly we're going to use gray the question is then you know how do you calculate the The Roots but um is that something people need to know before Thursday basically are we blocked on this in the next two days um if not I think that's maybe just the

only thing we need to we'd need to uh to confirm for for respect um yep okay so that's um so then just just to summarize so it means basically um we would um oh oh there's a devnet three that's launched yeah for lunch today but uh so this is just to include the very took way so now all the trends have that

implemented already this is not for yeah so does it make sense to just use this as well is there a reason to not use it I did okay right so if you look at the notes that wanna be post thank you for that and then if you look at the spec version needed at the end I think that's just a very new Baseline basically what I said but now it's actually based on Commit so that's even more clear if you want to look at the code yeah okay perfect so I think let's um let's do this and I'll put together a hack MD just so we have it all in one

place basically based on your um your comments but uh we can use the spec versions uh that are that are listed here at the bottom of uh of uh the devnet 3 for withdrawals um and the commit we actually have the commit number that's missing uh on that hack MD because uh the pr got merged yeah cool anything else on devnet4 Tim do you already have go ahead let's go Terence yeah I just want to follow up on like

the timeline for this this is something that we want to do it before that's Monday or viewing or next week when we're there yeah curious to hear what client teams is is think is achievable I mean I think we should shoot to do as much as we can beforehand but it seems likely it'll slip into next week yeah yeah one of the things that like is is is uh uh valuable is like if we have the implementations mostly done in clients and then we spend the time in person you know debugging cross-client issues

that's always more more useful given that like all the folks who uh who aren't uh that given that all the folks who are in part of your team will be there in person so I think um yeah if we can try and have the implementations then um this week and then uh basically early next week we set up uh the devnet in person that would be that would be pretty good the next thing on the agenda so um Alex

from the Epsilon team was reviewing the 4844 pre-compile he shared some thoughts this morning uh he's not on the call um I don't know if anyone has had time to go through this if so uh oh he just texted saying uh he can hop on uh let me just answer that okay so let's see if he can hop on and then the other thing to cover was just uh testing updates let's give him a minute see if he can join

oh small question to discuss is uh we all preparing some configurations and record images for newer dividends and so on uh but I don't know any proper place to uh post it all there I mean we have interrupt repository to start the private Network right uh not a Dev Network configs are there so maybe we could like collaborate and both configurations and some images somewhere so it would be able to start

uh Barnabas do you have any opinions on basically uh or just told me that I would not be responsible for this but it would be rougher than some that are actually going to the event and uh I I will be just working from home okay they are going to be the one responsible for the next section yes I was already trying some local devnets Etc and the idea is that the two of them will be there um to help support them support you guys but that I guess does that and that

doesn't really answer your question like I said like where should the configs be shared to understand correctly um yeah I guess uh hang on I think we might have already made a repo for this uh let me just share yes here the idea was to kind of stick to the same strategies but like we have each Panda Ops we draw the test net and we have four eight four four test net configs that can be shared here if someone needs access to course I mean

Industry pool then let me know and ignite you guys thank you yeah Alex uh you had looked at the pre-compile uh and wrote down your thoughts shared that uh this morning do you want to give people a quick uh summary of your your hack MD yeah sure um maybe let me just also paste the link here oh I got it I just pasted it okay yeah so

I actually looked into the pre-compiler a while ago probably last in September and left a number of questions on eat magicians um but now the reason I looked into it because I was wondering if it could be even implemented with uh eip25 37 the blsp compiles EIP and basically I started to write an implementation in solidity while only looking at the 4844 EIP description and that turned out to be insufficient um in order to understand what exactly the pre-compile is doing so I ended up

looking at the I think the pi iecc um as well as the Kilik or kilich I'm not sure how to pronounce it BLS implementation um so I spent quite a bit of time in digging down to understand the you know all the parts how it can be implemented and um the second deal is my progress and my findings and why doing so and the outcome of this is uh number one I think the number of points which could be clarified in the IP in regards to the pre-compile um point two is

uh it cannot be fully implemented with uh Erp 2537 because there's one feature missing in the um in the pre-compass to deserialize a G1 point and I looked into trying to implement it in the evm itself but I think that would be rather excessive um and then finally sorry I don't understand I can can I um so you try to implement an evm native version of the pre-compile using BLS pickle piles and why why would that not be possible I

mean that should be possible yes the there's one feature which the the precompile set is not uh including is the deserialization feature deserialization it's also called decompression in the in some of the source codes basically the the commitment and the proof if if you want to turn it into actual points and there's a helper for that in most of the implementations and doing that requires um modular arithmetic operations to be implemented on top of the evm which you

could do yeah yes for sure okay so the BLS pre-compiles uh don't uh have Point decompression oh wow that actually feels like something that should be added to them but did you try to try to do that on the native evm is it just too expensive foreign yeah I mean I think you could do it because I mean I looked at um um you know some of the implementations uh had these were accomplished and it definitely could be done

um probably price wise it wouldn't be horrendous um but there is a calculation on the in the heck MD which summarizes the cost of the 2537 pre-compiled um and you know the pieces which are needed for this and if if I only even just sum those up on the custom side at like roughly 210k um okay that's a huge okay yeah and the decompression I think would be natively in the event probably around like 200k interpolating from the pre-compiled cost probably decompression could be done around like 20K 20 30k

um but there's also a number of places uh where bytespatting is needed from little Indian to Big Indian um because the point deviation pre-compile expects little Indian inputs while the plsp compile expects big engine inputs is there rationale for not including decompression the pre-compile is it that uh it's cheaper to just provide decompressed elements in the data is that the reason as forbido isn't right honestly I'm not sure what's the reason um that it was

skipped I mean obviously there was like a lot of debate around even the number of frequent pies the the industry I said contained this would be an extra two but yeah I mean there's a lot of notes um regarding what could be clarified and um um yeah I I actually opened one PR already but I can open a number of other PRS to the EIP just clarifying these um and I also looked at um trying to find some State tests for the execution layer but I couldn't really find it so I'm not sure how well the pregnant file is tested

um but I think some of the um you know the validation rules I collected based on the implementations those would be like a good starting point for uh writing actual State tests and I guess just on the BLS side obviously they're not part of my net yet so like that's something we can modify I guess in terms of next steps here do you think there's anything we should be doing Alex yeah so I think the first step

clarifying uh these um you know the current implementation details in the IP that would be good um and I'm happy to help with that um but also it would be interesting to see where the pricing the current proposed pricing is coming from and um um you know even like this the plsp compiles um whether they have like accurate pricing and I think you know if I mean given the 4844 potentially gonna go live like in six months um based on likely that's like you know you see the discussions I think there may be there may be a possibility to at least discuss

um the potential whether this could be done with the blsp compiles I think at least there's there's time to have the discussion but I'm not focusing at this point that that should be the way got it well there is an argument against using the BLS pre-compiles which is that um the the idea of using the version hash is that in the future when we upgrade to a new commitment scheme um the pre-compile could be upgraded to automatically support that just using just the version cache and so smart contracts would not need to be changed at all like you could have um completely static smart contracts that support and

upgrade for the commitment scheme and you can't do that if you use PLS pick compiles to implement this yeah the way I imagined if this would be using the PLS pre-compasses that um it would be an actual create vdvm code like this implementation it would be placed into the state at the pre-compile address so instead of having um you know which is something for people to implement it there would be a given version which you could upgrade I mean that that's but that can be done transparently right like if we were to go that route then we can do that

independently from yeah I think the only uh exactly but the only blocker uh would be on that is the pricing because there's like a there's a discrepancy you know with the pricing currently well I guess I mean it seems dangerous to not override the pricing when you do because then all kinds of things could affect the price yeah Alex do you know where the rationale is for the current pricing of pairings like

for bn254 because they look pretty overpriced the last time I checked but I couldn't find where they were coming from the the piano or the BLS uh the B and ones because the BN run should be cheaper than the BLS ones in terms of like pairings and stuff yeah I think the piano ones were actually repriced and and not a couple of years back and they were repriced based on uh actual measurements at the time I'm not sure if that was already the the cloudflare implementation but obviously all of this is really tied to the pricing and go ethereum right and um I

think that's what the benchmarks are based around okay sure yeah I I really don't have too much else to say um if there's like a Channel or appropriate location to discuss this further let me know I guess yeah we have the 4844 testing channel on Discord um so that's probably a good spot to you have to have this thank you Alex I appreciate you jumping on I had the last minute

uh okay so I guess uh lastly I want to check it if there's any updates on the testing side um anything people want to bring up if it's useful to anyone I updated zcoi to like parse and transition yeah before for data so it's very up to date with both consent consensus changes for capella then well D nap or photographer nice I've been doing some differential

passing between ckcg and go kcg uh no findings for the past like two weeks but I'll keep going cool thank you um anyone else and if not I know the other thing we talked about last week was to try and have another run of the Gordy spam tests um this didn't really happen is it worth trying to do that this week uh or should we maybe hold off until interrupt I'm curious how are people feeling about that how valuable is it to to get another round then as soon as possible

I mean I I we'd be interested in seeing the information on Gourley like we recently had some monitoring set up like uh Friday so on the lighthouse side we'd be interested okay and and yet our team have thoughts on this okay so let's okay let's try and get something done um in the next couple days just on Gordy um and yeah go from there anything else uh before we wrap up this is Andrew again has there been any

more thought given to getting an audit done of the rust version of kzg that Kev is working on because I'm hoping like that we're going to be honest that we're going to switch hopefully from ckzg to the Russ version so we just so we can have the the wasm compiled version of it so available to our browser implementations of our code base is is there any thought there or should or should we really consider trying to figure out a wasm compile the ckcg library for for that because otherwise that limits our code to only running in node.js which is fine but you know we try to support the browser environment as well with our code base so I don't know if there are any thoughts on that so the current audits are scheduled only

for ckcd and go kcg I I'm not sure right now if we can justify having a full audit for rust kcg as well just because it doesn't currently seem like there's there any production clients wanting to use it That Couldn't also use ckcg instead um so I don't know yeah I mean there will definitely be differential fuzzling at all um but I don't know like if if there's really like if there's demand from a production client then I think that might change

okay yeah I mean and our and that's I mean I think that's fine for now I mean our our code is not strictly always used in client I mean we have we we obviously we do have a non-production grade client um our code will allow people to construct blobs and if we want people to build it I don't know if there's a there may not be a use case for really doing it in browsers so that right but I mean do you like do you need an orders in order to construct blocks yeah in some places I mean some people do use our code but that's a different question right well the question is how how like what are the critical failures that could happen I I don't know if I can judge that at this point I don't know all the use

cases for blobs yet to build I think like I mean the the diff yes so I mean so to to me like so the most critical things thing to me is always validation like where we don't definitely don't want things to go wrong it's like verify um blobs as in like the the point evaluation um the the blood verification and then the point of evaluation pre-compile um and those really like if if you're if your software produces incorrect blocks um like the amount of harm that you can do with it um is very small right you just produce an invalid transaction so what

like someone can go and fix it sure okay and that's fine I mean like I said unless Lighthouse was planning to use Rusk azg for some reason which I know that right now they're either not so that would be the other use case I could think of since it's a recipe's implementation but I'm good with that I just wanted to ask um yeah just a note on this was my finger so I'm not sure what uh by the way there is a more than one rskg library and another one which Kell is working but I'm actually not sure what the ECC Library it uses because the thing is that uh if you have

a rust library that uses blst so so in our rest kcg we use we have option to use the different libraries even even the ones that uses that have written in roster so however if you use the rest kcg which uses for example Bill St then you still end up with the same thing that you need to compile blst to basma and I'm not sure what is the state of that is it is it possible to compilable St eroism it is yeah yeah the rust kcg used to use our quarks then it switched to BLS the filecoins blst wrapper and it compiles

to wasn't oh okay okay so yeah so so yeah I mean if if this for some reason by the way did you check that and it actually works yeah yeah yeah I currently use it to oh okay okay that is it's good okay so yeah that's all thanks um it should be fine because if it's just C code you just change the clang Target to like wasn't 32 and then it just works okay okay because if it the small note if for for the ECC libraries that are implemented in the roster uh well it's they're much slower like significant of

this lower but at least you have a rest picture which you know could be safer or easier to paralyze or so right thanks um yeah I think that's mainly because the the library is like blst they have just better algorithms for field arithmetic for example which is just by the usually faster yeah okay anything else okay and I guess yes you're all probably

aware of this but the kcg ceremony is live uh so it's accepting contributions um still a pretty big cue but uh we've already exceeded the biggest uh record for uh the number of participants um so hopefully in the next two months we can grow it out even more um and uh we'll then have a month for like special contributions and I think after that we'll likely just uh reopen it until until we decide to go live on Main Network 4844 um yeah so it's happening 7.3 000 contributions uh as of right now cool do you know what the previous

record was it was like 4.6 K but um and maybe Proto or bankrupt can can talk about this our ceremony previous record was 2600 contributions okay so we're already far exceeded that yeah I thought there was something Trent was saying around like because ours has like less computation like the total amount of like entropy collected or something might not be the record yet but I'm not sure I don't know what the total amount of entropy collected is yeah the number of contributions is already um far exceeded any other ceremony yeah so we'll probably get closer to 50K

than the 5K we were hoping for which is really cool sweet um yeah thanks everyone I'll see you all on according to two days from now bye-bye see you on bye