All Core Devs - Execution #161

Transcript

foreign [Music] [Applause]

thank you

Tim Beiko: morning everyone and welcome to acde161 um So Yesterday um if people have any more thoughts or you know discussions we want to have

around Cancun's scope we can do that first and then it probably makes sense to spend most of the call talking about uh implementation for the current Cancun stuff and specifically for 4844 there's a bunch of open issues that I've listed on the agenda um and at the end we have Zack on who wants to talk about and kind of a funky EIP because it would only apply the L2 and you know whether this should even be part of awkward devs is an open question so we can go through that towards the end yeah I guess to kick us off on the Cancun stuff so um on the last call we sort of agreed to

include a bunch of VIPs so 1153 4844 was obviously included um this SSD optional EIP and then the self-destruct removal um there's also CFI did a couple more so the blsp compiled the beacon block route and um the SSD transaction signature scheme um I guess did any of the clients feel like I have any updated views on that like anything that they think we should be considering or yeah I'll pause here otherwise it's fine to keep it as is and keep going with that okay

um so we'll leave this as is and I assume based on the SSD conversation we might make some changes um if not today uh then maybe in the next few calls or at least I'm changing the actual specs okay so next up uh actually sorry just before we wrap up here I guess I'll assume that by default we sort of keep this scope for Cancun and if anybody wants to change it going forward just put something in the agenda or on the East magician's thread and um I'll I'll pick it up from there but this way we don't have to go over this every call okay yeah

and so next up uh 4844 so there were a couple uh open issues or concerns

um so you can just go through them first Andrew you mentioned uh the difference between uh the input and inputs in the pre-compile being a little Indian versus big Indian and you want to give some context on that

Andrew Ashikhmin: uh yeah sure I think um the little Indian encoding was inherited from Cielo was just taking from Seattle and on the CL side things uh little Indian but uh now there is an inconsistent and um on the outside in the evm most things are big and then there are kind of some consistency I think Blake to pre-compile

might have some inconsistencies but most things are beginning and then now we have this weird situation where um z and y uh like the two inputs I'm not sure about the rest of the inputs but at least two inputs are little and then while the outputs a big engine of the point evaluation pre-compile and I'm just thinking uh we can be okay with it but maybe we should just just explicitly clarify it's in the aips that it is that we do have this inconsistency oh I don't know what other views or we might want to reconsider this

Tim Beiko: does anyone either have strong opinion

on this or like a rationale for why we should keep it this way

Andrew Ashikhmin: I think the output is kind of mostly for information of purposes the output of the compile so it's static it maybe it's not too big a deal uh but so if we if we leave it as this we I think we should just just add an extra clarification to the Eep that we yeah that does highlight in the inconsistency

Tim Beiko: okay and there's some uh comments in the

chat from I think all the other clients saying they don't like little Indian on the El

Marius van der Wijden: so I think we should have a like a really good reason to have the inputs little Indian otherwise we should just make it

bigger

I think if there's any order or transition between little ending and big end it should be as at a high level as possible and what we're talking about is it's way too low level to make that affordance

Tim Beiko: okay so this and and yeah there's like

plus ones from all the El teams on maris's Commons um should we just make this change to the spec then put everything the big Indian and that means everything on the El stays a little Indian oh yeah Ethan has a good question do does this affect some of the underlying crypto libraries if we switched everything to

begin again

Andrew Ashikhmin: I think it can read inputs in both the big engine or little and then you just have to specify which

Etan Kissling: but does it convert twice because usually the libraries have like a native order um that they prefer to operate on

Andrew Ashikhmin: uh even if it converts so it just it will so it will read a the inputs in its native representation so there might be some conversion but it's a very fast operation just it is negligible compared to the main runtime of the pre-compile

Marius van der Wijden: yeah I also think we shouldn't take like the time for the conversion into account when making this decision this is more about like if for some reason all the inputs that are going to be into this pre-compile are already Little Engine then it

would kind still not really much for me wouldn't make that much sense to have a little engine but um I I would see the point I don't think execution speed should be uh like should be a consideration here like the big Indian two little Indian conversion is so fast like that makes no sense um but if if there are like really if there's a really important issue why we need this then I would accept it but um from my point of view I I have no idea what the also thought about so I I

would just go and say let's make it let's make it big engine as everything else

Tim Beiko: okay does anyone disagree with that

uh no disagreements

per se but um we should check whoever with whoever created the spec I mean there must be a reason why it's just because we can't say wise little Indian uh it doesn't mean we there's no reason uh I mean dead cred I believe it's under God I don't think Provo is here but thank God do you have any thoughts on that

Dankrad Feist: uh sorry just joined I I didn't get the context just now

Tim Beiko: um is there a reason why the uh pre-compile in 4844 uses little Indian and would there be a problem if we converted everything to Big Indian to just be consistent with the entire rest of the El

Dankrad Feist: oh I see all right that's a very good question yeah I mean this is like a difficult one because we are like starting to switch uh yeah like the CL everything is Big Indian yeah I don't know honestly I think

I don't know I don't know how much we've thought about this okay so like yeah so there's no reason within 4844 why it's like much better to have the inputs be little Indian it's kind of a default design on this CL that sort of yes I mean I guess like there are two things like uh the Seattle speak Indian but also crypto libraries tend to be big Indians so I guess oh they tend to be bigger and I'm sorry so it's actually the opposite yeah it might actually make more sense than to make it big engine also because the El might do some computations in uh using those integers yeah

Tim Beiko: okay and I don't know if Pro is on the call no so I guess what we can do is at least we can open a PR on the EIP to make it big Indian and leave it up for a few days for you know if prolos the other major author that's not here or if anyone else have like past objections um they can obviously raise it on the PR but assuming that there's no objections we just move it to begin um Mikhail

yeah as

Mikhail Kalinin: far as I can see this back for it for Forest back you refers to verify kcg proof function that is defined in the um on CL which is little Indian I believe so that's that's probably the

reason for that

sorry which function did you say

Mikhail Kalinin: verify kzg proof

it is specified calls to this function and this this function is specified in the incl spec and sales pack is little ending I believe so so that's why it is specified this way I mean like this y inputs should be a little Indian to align the lines with the CL

Tim Beiko: and I guess

wise we would have to do this like conversion in the engine API or something like that

Marius van der Wijden: but what's the what's the output on on the constants layer is it also big

engine

I think this is insertion right is it it just asserts that the verification is

correct

Andrew Ashikhmin: yeah the output is fixed and it is specified in the currently that the output is Big engine so that's why it's it's inconsistent uh at the moment

Dankrad Feist: so I don't think the um the CL directly calls verify case Egypt

right it does the blob um verification but never verified HD proof as far as I know so it's fine to change that function but I mean it is going to be a bit weird because now the kcg library will have both a big Indian and little Indian interfaces

Tim Beiko: right and I guess the question is where should those like if we're using big engine somewhere little Indian somewhere else we're going to need to have both like interfaces somewhere and the question is worse like the least awkward part for that

and I guess the argument from this yell folks was that it is really weird to have this as part of a single pre-compile input and output on I guess yeah if we can at least put up the pr um to propose the change and you know move the discussion there in the next couple days that would be good there's a 4844 call on Monday if we want to talk about this in more detail or if there's any sort of objections that come up in the next couple days where it seems reasonable to at least draft this specum take it from there

and I guess if there's no strong objections just merge it in the merge it in the EIP does anyone want to volunteer to write that PR

um just to understand this one if we do if the pr gets marriage then then we definitely need to change the kcg libraries but does anything else change what the exchanges to

to do this thing why would

Mikhail Kalinin: you need to change the

libraries

because my understanding is that we're talking about the input output of verified kcg proof which is what the library does or or am I off topic what is it

yeah I

Mikhail Kalinin: I think that it can respect in in a way that okay so we do a conversion from beginning to little end in yeah but that that will be a bit of an overhead but it can be specked out in this way um to emphasize that verify kcg function is little endian I mean like accepts

little Indian inputs so I don't know that's one of the ways not necessarily change the libraries but just change this back it depends on how do we want to handle this

oh Andrew

Andrew Ashikhmin: uh yeah I was just thinking so we can add a parameter to the that function that passes the inputs or or what whatever like verify so basically Paramus rise that will

parameterize the function whether it's a big engine or little Indian and then explicitly is uh on the outside and I was thinking about the blast Library so blast Library can do both so just but but maybe in a like on top of blast the libraries might have to be we might need to change the intermediate libraries it has blast like kinky kkz G libraries

Tim Beiko: and I guess yeah so even if we need to

modify the libraries a bit do we still think it's a worthwhile change

Andrew Ashikhmin: uh well I think it just adds adds uh Clarity uh because so if if you have that like a little engine parameter as an extra explicit parameter to the function uh then it's it's there is no ambiguity you you you see it okay uh in my definition of the pre-compile everything was beginning then and it and it's it's explicit because right now it's as a specified um there is it's not immediately obvious that there is an inconsistency because that function is defined on the CL side

and without it like that extra knowledge that everything is still is Little Engine then you don't just reading the EIP you don't see it you don't see the inconsistency with the with the explicit engine argument you everything is just more explicit

Tim Beiko: okay any other thoughts

Marius van der Wijden: I think the important part is actually like how are contracts going to use this and if the smart contracts are going to use big engine in in everything else and

they now need to do the big engine to Little Engine conversion in the contract to call the pre-compile that does this conversion in reverse and then that's kind of bad I think so we should make sure that whatever we choose we choose it into accordance to to the people that call the

precomposer

Dankrad Feist: I do agree with that um I think it hasn't been given that much thought uh one thing that is going to be interesting here is that um obviously the um the group elements are

also in theory like I mean they're large integers I guess like there every day they are kind of a con like compressed according to the BLS on that but it's also potentially possible that in the future someone would want to do computations with these especially once we have um BLS pre-compiles but yeah I agree that for the for the um for the theater elements um yeah it does seem to make much more sense to have them be big

in the end

Tim Beiko: yeah I think it's worth at least making the the suggestion in the EIP so legender said he can do that um and kind of moving the discussion offline um and getting more feedback on it before we merge it in yeah does that make sense everyone

okay next up then uh so the big thing we discussed over the past two weeks was what to do with SSD on the El as well um uh there was a bunch of issues uh

trying to get the libraries uh working and some quirks of SSD on the El and then Matt put up a PR uh to show what it would look like if we just use rlp instead of SSD uh for 444 and xiaoi put up uh uh a PR on the CL side as well to kind of show the impact this would have on the CL specs and there was some recent conversation on that second PR um so I guess I'd be curious to hear yeah from teams um what do people feel is the best path forward at this point should we uh move the El transactions to use rlp if so uh what can we do on the El or on the CL

specs to like minimize the uh pain of bringing it in um yeah and I know like Ryan protes Danny you were all chatting about that on the issue in the past few days if any of you want to share your thoughts um yeah that'd be it

Danny Ryan: yeah um so there's definitely a desire not to have rlpas and explicit dependency only expenses there um for more than one reason but the so I think if we did go this path of rlp as the blob transaction encoding we would

want to do something like maths proposal but I think Matt's proposal mentioned that to put these version hashes in the blob sidecars uh instead I think that what we think makes sense is that they would be you know some sort of adjunct list inside of the actual block body we want to have the requirement that the block can be executed on the consensus layer and the execution layer without having the blob sidecars on hand um and so we would shut them into the block body uh I think that's that's kind of in line with the proposal it is a bit more of a

breaking change but this is a breaking change so I don't think that's a showstopper does that make sense

Tim Beiko: yes uh Andrew

Andrew Ashikhmin: um yeah I was just thinking like the thinking again and uh to my mind uh the current situation is not too bad because like like the main the main concern with the current uh spec is that uh the we are going to have a different um SSD format for transactions so you you we will have to change the car like the block transactions into something else but on the other hand we are going

to do the same if now we revert back to using ROP for Block transactions then I think Mario's told that with that like block transactions will be temporary and when when we figure out how to do SSG properly we kind of introduce a new type for Block transactions like which is proper assistant see but then again if we are doing that then like having this temper SSD transaction type for Block transactions again it's it's it's on an intermediate solution and on the upside we don't have to introduce ROP into ECR and so on so I kind of currently my

thinking is that the current solution is not too bad the current spec

yeah I

Danny Ryan: I hear you on that the the main question is okay if we're going to have to change it do we want to introduce a very limited additional SSD dependency on the execution layer that might Ripple outward into um you know potentially how L2 wallets and other things um utilize this so it's it's the question of if we're not going to do it right should we limit the dependency Edition um through this other mechanism the nice thing about the uh the method on the consensus layer that was proposed by by client is that it actually makes

whatever the encoding is of these transactions whether they change in the future it's kind of transparent to the the execution the consensus layer like the consensus layer right now can't really read transactions and this is like a we have this exceptional way to try to read a component of these blob transactions and by going down this path it makes it so that the consensus layer doesn't have to read these transactions and that the validations that have to happen occur on the execution layer regardless of the encoding so it's it's a it's a nice generic way to do it regardless as well

Lightclient: I also just want to be very wary of introducing changes that we think are intermediary we don't really know when we'll be able

to make the full change we don't know what the full change is going to end up looking like and I think we've seen in past Forks where we try to do something that's forward compatible and it ends up not being as forward compatible as we want it to be so that's kind of why I feel like if if we're not going to go for SSE and like find the right solution now it's probably best to just stick with what we know which is these ROP type transactions and continue thinking about how to do SSD later

Tim Beiko: um there's a question in the chat around like why don't we think the Cur like Ethan's realest EIP is doing SSD well

Lightclient: um which one

Tim Beiko: yeah I don't know Eaton or

Roberto do either if you wanna give context on that

right because

Etan Kissling: he's talking about 64.93 for the signature scheme or 6404 um overall I'm not sure which one

Lightclient: yeah I think 6404 is definitely approaching you know what we want to do with soz but it doesn't really seem like there's appetite from the other developers to try and pursue this for Cancun I generally think that like that's what we want to be looking at doing for SSD but like what is in the proposal right now is not rare and like specifically I think taking the hash of a serialized SSD value is not the idiomatic way of hashing us as the objects and it just

doesn't make any sense

64.93 which I think is compatible with 6404

Lightclient: yeah but it's just for the signature scheme and so it really provides no value to users the only value it provides is maybe not having to change the signature scheme in the future which helps us avoid you know potentially breaking or making like Hardware wallets change how they compute the Hat the signature hash of the transaction so it doesn't give us any of the benefits that we like are looking for in

SSD uh and

Etan Kissling: uh one benefit that it gives you is

um right now if you use this flat hash function that just takes the serialization and then hashes that one and you sign that you don't get any benefits from SSC for this transaction type but if you use idiomatic approach of the hash tree root what you gain from it is that the hardware wallet can for example display certain Fields like you can send just a part of the transaction to the hardware wallet and it can verify that those parts are actually included in the hashtag designing that is not possible with the flat hash for that you need

a tree structure right

Lightclient: why would you not send the full transaction to the hardware wallet

Etan Kissling: if you are sending the full transaction then why use SSC for the transaction

Lightclient: that's what I'm saying I don't I don't think it really matters that much for the signature hash because for you to verify the signature hash is like what you expect you need all the elements anyways

Etan Kissling: can you send the full transaction um isn't it like

Lightclient: I think that's how all Hardware wallets are implemented like if you just sit in the hash and you don't actually know what is behind the hash

Etan Kissling: uh no I mean like the hash plus Miracle proof of individual fields in the transaction so that you can for example check the

destination but you don't have to send all the blob contents I'm not sure if that's useful or not but it's possible with

SSC

Danny Ryan: the blob's not hash though the blob is a kg commitment so likely the transaction going into a hardware wallet would just be the fields plus the kids okay yeah

not

Etan Kissling: then it makes sense to just send a full thing and I agree that I mean it depends on the overall thing of this Union thing or the normalized transaction the speaker thing right but right now the cx404 has this conversion step where it just takes the main pool

transactions in whatever format they are on and then it converts them to a normalized representation when it is building a new block right so for that the IP doesn't matter if how it looks before we could even add like CK commitments to this part of the conversion um but yeah

Gajinder Singh: also it was argued before that Hardware wallets won't actually be doing SS SSG block transactions because this is mostly we gonna use by L2 sequencers

Lightclient: still think L2 sequencers probably would

want some sort of Hardware solution for Stein transactions even if it doesn't exist yet

agreed

Lightclient: and I think the code ends up being pretty similar whether it requires manual input like a ledger or if it's some sort of like uh you know other Hardware like key mechanism where the key is just stored there and you're sending requests to it online

Danny Ryan: yeah I still want to make the case that uh going down the path of what like clients just does make this much more future compatible such that when the if

and when the transaction type changes on the uh execution layer the consensus layer doesn't really have to know about that but just changes the validation of um these version hashes that come in through the the engine API and if we're gonna go that path which I think is more generically future compatible doing the least invasive thing on the execution there would be my suggestion um which I think you can make a strong case that rlp is that but potentially you can make the other case uh given that at least SZ exists today in the test

Etan Kissling: okay share the link to this proposal on

the CL side or is it is it in the agenda

Tim Beiko: yes it's like basically a comment though let me yeah it's like the first comment on xiaoway's PR basically and then Danny and basically

we have to yeah

Danny Ryan: we have to pull out like the the version hashes from the transactions which are otherwise opaque to the consensus layer um and so we were doing that by using offsets for this z um if it's rlp we would have to integrate an ROP library to do the recursive lookup um and then we have to make sure that those version hashes uh are actually the

com the the hashes and the commitments that we expect instead we could make those version hashes an explicit component of the block and when we pass them into the engine API such the execution layer does the uh check that those version hashes are actually the ones that are inside of the transactions and then we can higher level check with the consensus layer and not have to worry about the encoding of the otherwise opaque transactions it sounds convoluted it's moderately straightforward and prevents having to do any sort of like peering into the

user transactions

there

Tim Beiko: uh Andrew is your hand newly

Andrew Ashikhmin: uh yeah I'm just thinking aloud here like would it be to to march to him to just do um six four or four in uh in Cancun because it seems to me that it's yeah that there actually we want to go so maybe we should just buy the bullet and like Implement proper SSD with Bob transactions

Tim Beiko: across all the all those transaction types right

Andrew Ashikhmin: Maybe

Lightclient: 6404 is changing all the transactions to SSC and removing the miracle prescription tree root for the transactions and making an

SSD rune

Andrew Ashikhmin: what about Legacy transactions because yeah like plenty of Hardware wallets like that will never change

right

Lightclient: it just changes the formatting that goes into the Merkel Patricia try all right no sorry like is it goes into the SSC route and the signature scheme the signature hash the Legacy transaction stays the same so the hardware wallet still signed the Legacy signature hash

Andrew Ashikhmin: right I see oh okay so it seems to me it's the direction we want to go right I think so

um Alexa

uh it's kind of um your idea but probably it is possible to separate uh old transactions and new transactions so we do not need to invent something new for all transactions to be to become a part of uh Merkel tree instead we could have them separated and Mark it as deprecated so we will have clean SSD solution and uh LLP part which is a Mark is deprecated and

then we will not allow this Legacy transactions in the future but after some time and we will not mix these parts somehow

Andrew Ashikhmin: because Hardware wallets like we cannot make them Obsolete and just it takes it into account it's compacted it just introduces a backwards compatibility layer which is nice

but we will have a little p all the time after that

Andrew Ashikhmin: uh that's not the problem it's always the

problem that we have different transaction route between Co and Rio I don't think that like having ROP on the outside is a problem

Lightclient: also having two lists of transactions seems to complicate block production Affair but you start to get to a point where you know if you're a Mev Builder you're trying to extract value from transactions that are at the end of the Legacy transaction list and you know maybe you want to put your transaction at the beginning of the non-legacy list it just doesn't really seem ideal to have two ordering mechanisms now

uh well uh you may have okay we have a

order transaction listing block right we just can put one with them into root another into another one and uh it will be like two local orders but we will still have it uh as a global order aren't we

yeah

Lightclient: I'm not sure I mean maybe we can have a global ordering still but we talked about this a bit in Austria and it didn't seem like people wanted to have two transaction routes maybe I'm forgetting other reasons why

not just a

Potuz: question to have two transaction routes one for the transactions at the other one for the Legacy transactions

I think yeah basically but not just for blob transactions for SSD transactions which happen to only be blocked right now right so I I was watching

Potuz: this for a different reason uh which I would love if there's the discussion at some point this sort of conjunction to what is here but the point is that it would allow to have separate MAV uh PBS separations so that you can still propose a Blog look built locally and use the Builder for blob production and I think this is something that we we

may want to have

uh we can

we can at least um find some okay well well it's uh well uh we cannot deprecate right uh it doesn't seem um okay that we can like have this Legacy what's the time maybe uh maybe we could at some point and get rid of all transactions

Lightclient: yeah I mean maybe like have a pre-compile that

accepts a legacy Transit action ROP and signature and instantiate hit transaction there like that's kind of been what has been thought about for totally getting rid of these Legacy transactions but then you start introducing a concept of sort of initiating a transaction with an evm execution and there's just like things that haven't really been thought fully through yet

Tim Beiko: and I guess if we were to do like a full SSD transition in Cancun these are all the things we need to figure out before that correct like especially if we if if we're saying that the value we get from doing the full SSD

transaction now is like we don't have to change it again um whereas right now with 4844 we just have a single um single transaction which we might end up changing

Lightclient: yeah that's kind of what I would hope for in a quote-unquote before SSE transition it's not to say that we have to solve this like transaction in a bottle situation like I think that having the Legacy signatures is generally okay that's something that I don't think really comes into play as an issue until we start doing you know zking of all the transactions in the block and you might not want to have any ROP but for today as long as they're representative SSD and the

transaction route that is the main thing we're looking for but I guess there's still questions about should we have separate transactions uh tree for the blog transaction so that you can produce things locally I don't think that this is necessarily relies on SSD it's just like another another Arc to go down

yeah and

Tim Beiko: I'm curious like did people feel like it is reasonable to potentially figure all that out for Cancun without basically massively delaying

4844 or everything else

Danny Ryan: I feel like we had this conversation and we keep saying it would massively delay and there are a lot of uncertainties and there's like a can of worms that will likely take months potentially that is less than months now because people have been thinking about it for a while but I don't know I I do think that we keep asking the same question even though we presumably made a decision on

Tim Beiko: right and I guess the the point we're at

is like now the it seems like the alternative is we moved to rlp on 4844 that's also a non-trivial amount of work but at least it seems like work that we like have a really good understanding of

Lightclient: yeah I feel like we're kind of at the point where we need to say we're going to go with rlp or it's going to say okay let's just sit down and be a little bit more serious and comb36404 and figure out what needs to be changed and you know what the exact world of like SSC transaction is going to look like

because I don't think a lot of el teams have gone through it deeply

and

Tim Beiko: yeah I guess I'm curious like I'd love to hear from other El teams like do you feel like it is something you have the bandwidth to like go through deeply in the next I don't know two weeks to a month and I think if not then it probably makes sense to either keep what we have now but that seems like the worst of all worlds or use the rlp scheme so that at least all the transactions are consistent

Marek Moraczyński: we have capacity to go through it

um anyone from Basu

um it doesn't seem like too much of a challenge for us frankly

Tim Beiko: okay and so I'm sorry say again

Péter Szilágyi: which part isn't a particular challenge converting everything to

SSD I'm sorry the r no the rlp adoption okay

let me rephrase taking the existing SSD implementation as it exists today in 4844 and reverting it to use rlp would not be terribly

difficult for us

Tim Beiko: right yeah to be careful the question though was do you have the bandwidth in like the next month or so to think about a wholesale move to SSD like if we were to go down that road I feel like we need to you know hash out the design in like the next month is that like realistic

um I think a month is a little less realistic but six weeks to eight weeks is more realistic

Tim Beiko: uh yeah Danny

and

Danny Ryan: just to contextualize if it's six to

eight weeks then it becomes implementation which then probably Services additional details that weren't previously discovered and has at least a few test Nets or at least a couple um to kind of like go through those iterations just to it's okay if that's the decision being made I just want to contextualize that that's that's yeah

so to elaborate

doesn't mean and then it's done

yeah right so I'm I'm actually considering two things going on here one the actual research and you know um thinking through that like client is suggesting but also our implementation of SSD right now is very very thin and very very specific to a lot of the things that the cl has already adopted and there are a

number of gaps there that need to be Revisited and implemented um things like you know new data types like optionals um the way that Collections and lists are nested Etc so there there will be some some Upstream work that needs to happen on the libraries that we use for

SSD

I thought we already had this discussion around whether we tried to do a more thorough

SSC convert from the Yale and dismissed it as pretty impractical was odd we're revisiting that it was a little crazy to me to be honest

Tim Beiko: so I yeah but I think I guess my point is if yeah welcome to

awkwardness if we if we are not willing to revisit that then to me that's like a pretty strong signal we should just do rlp and properly take the time to revisit SSE it seems like the current spec is like the worst of Both Worlds and I'm I'm fine with that but it seemed from the discussion five ten minutes ago um yeah others

I wouldn't call this current spec the words to post rules I think the issue is say we did a 64.93 and we want to and I think the concern is that we missed something and we just have to introduce you know a new format anyway and so all the all the work we

put in SSC might not be as valuable

Lightclient: um I think the biggest concern is it introducing a little bit of SSE and then never being able to introduce the rest of it and then Forever on the El we have this one strange transaction format with strange signature scheme that's totally different than everything else that to me is like the biggest concern

I guess I don't see why introducing one z type now would make it harder to get into full SSC in the future

Lightclient: oh I think it would make it harder I'm just saying that there's always a large risk of doing any kind of change to the protocol and I don't want to try it and you know Implement something with the expectation of changing in the future

if you

Péter Szilágyi: now so in order to introduce SSD we need to introduce the signatures team for for the block transactions and if we and for example we need to figure out optionals and a few other stuff we've missed something or some of this work will not be fully compatible with the work needed to basically switch everything out and all of a sudden we might need to swap out the SSD signature of block transactions to once again and then it's going to be super messy I mean yeah everything's doable but

Tim Beiko: Andrew

Andrew Ashikhmin: uh yeah I think uh the current spec um it's okayish because uh the signature what we assign in Block transactions say to like how passes The Works that the first field is this chain ID which will always be uh zero one or like like one in the in the little engine forms of zero one and all zero bytes so he it doesn't clash with ROP so it's okay because of that particularity I don't think that we need to even going forward I don't see a reason to introduce kind of any complications to

signing transactions because presumably SSD all this is the transactions will start with the chain ID so there will be no Clash but even if we do change that that signature it will be only for blob transactions just no Hardware wallets not a big deal so I kind of think yeah it's it's okay

Tim Beiko: I don't know anyone have I guess yeah

it's does anyone still think we should do the full

SSD investigation now um let's start there so basically consider

Tim Beiko: yeah consider 6404 like yeah yeah consider 6404 for Cancun um which will probably be like a relatively big exploration and you know likely we'll we'll delay things uh a bit so yeah I guess I'm curious if anyone

still thinks that's like the best path forward I it seems to me like no but it's hard to gauge and then if not is it better to keep the spec as is even though it's a bit hacky in a way or should we just do the work to get at the rlp so it's a bit more upfront work but at least we have something that's kind of compatible or aligned with everything else on the El right now and it's I guess it's also fine if we

don't make that decision today but it does feel like we're kind of bottlenecked on this for a lot of 4844 progress so if we if we are gonna decide to switch everything to rlp I think it would be slightly better if we made that call today and people get an extra two weeks to work on it but another option is as well like um sort of fully speccing out what a light client has in the comments and and and uh with the changes proposed by Danny um and maybe we can like make a call on that on the on the CL call next week and POTUS has a comment about uh this

might be this might be received differently uh on the CL call next week as well

Lightclient: though right like we were talking about the comment that Danny and I mentioned

Danny Ryan: so that so yeah just to be clear if we went down this path almost certainly the consensus layer would want to do this uh path where there's the additional data in the block that's passed into the execution layer payload is an additional validation rather than peeking into the opaque transactions um and that I think that's what you were saying Tim I just want to make that clear

since later

so

Marius van der Wijden: so what you're saying is if we go to with with the RFP Road there will be no

RFP in

Tim Beiko: yes it's what he was saying yes

uh POTUS

Potuz: yeah but just Danny just went to talk to the doctor but I had concerns about that coming too and I left it in the in the eib uh the the latency of getting the blob uh even though I'm not following the adjustments and it hasn't been tested I guess at the level of Maintenance the latency of getting the blobs is much larger than the block and if we're gonna have to wait for the uh for the full side car to validate us

that common says that we need to validate the kcg commitment against the this extra field in the sidecar the person using the engine to send it to to the El then that means that uh we're gonna be processing blocks much much uh later we currently can just send to the El the block as soon as it arrives even if we don't have the blocks and we're going to lose that ability it seems to me

Lightclient: yeah I think the Danny said in the comments I think Danny said in the comment that it would probably be in the block peer-to-peer object and that's what I missed whenever I said sidecar not realizing that you have this timing issue

Potuz: if you have my whole complaint is not a problem so if you just add this extra pill to the block I think I'm fine with

Lightclient: okay

Danny Ryan: so we definitely want the design and variant of that a block can be executed without blobside cars

Potuz: so then then we're gonna go back to this thing of like being optimistic like later on with the sidecar appears then we could just uh so if the El said that it's all right uh and we process the thing we still need to wait for

this full side guard before putting it in Fortress Yeah

Danny Ryan: for any design like that and that's a very important design

I mean yeah that's fine all right and I'm

Danny Ryan: sorry for the misunderstanding when we were talking on

the issue

Tim Beiko: okay so assuming that there's not massive opposition on the CL side uh to this proposal if we we modify it to put it in the block I guess does it make sense to fully expect that out and then in the next week decide between either doing that and so using rlp on the El SSE on the CL and and having the the hash in as part of the block um it gets passed around

or we keep the spec as is um but there's no world where we do sort of default SSD transition uh right now and we give people basically until the CL call to just review that so that a week from now we have the decision or do people feel strongly enough that like we should make the decision on this

the sooner we can get a decision the better um okay

I don't feel strongly either way I'm I'm lightly in favor of um you know what we

have with SSD perhaps extended with the signing wrapper from 6943 but I think it's more important just to commit

um any

Tim Beiko: yeah any of the client teams have a strong opinion on

I think we've heard strong opinions in favor of rlp as well yeah I don't want to dismiss that

I think sooner rather than later is um I'm also in agreement I think with Roberto I feel 4844 devnet six looming

Tim Beiko: okay and Marius is saying

showing strong support for ROP in the chat I guess yeah considering this discussion sort of bubbled out of people not being too happy with the current spec there's like does anyone oppose if we make the decision to move the rlp now and we can discuss the specifics of you know how the hash is sent on the CL call um but that we could start working on the El clients with rlp support basically this week rather than waiting an extra week and potentially get deafness six a bit quicker um with

with this in

I would never say about that

Tim Beiko: you would what

I would be in favor of anyone not into safe we're gonna

Danny Ryan: go this path we're going to add the field of the block um to avoid the dependency creeping up in the

extensive player

Tim Beiko: yeah

Danny Ryan: um and so I'm okay with committing to that but committing that with the additional field

Tim Beiko: okay anyone opposed

were there open concerns around adding it to the block just wanted to not rightfully understand the implications for that

I

Danny Ryan: I don't think so I mean it it adds a

list to the block that the execution layer makes sure that that list is in accordance with the type 3 transactions um which is a an additional validation but acceptable validation

Tim Beiko: um last chance for objections okay uh so yeah let's do it then um move 4844 to use rlp

um add the hashtri route to the blocks not blobs on the CL um and we use this for devnet6 um we can get some PR stood up for all of um for all of uh oh sorry version blah hash uh to the block not the history root my bad um so add that to the block move the El to rlp um not uh introducing rlp on the CL and use all of this for devnet6 yeah uh like client you'd already started some of these PR so if you can kind of make your draft PR into a proper

PR that would be great than if someone on the CL side can extend xiaoi's PR that would be um that'd be good as

all

Lightclient: so I can't quite make it a full PR until we get more people to review it because it once I make it a PR because I'm an author it'll Auto merge so I want to make sure that

Tim Beiko: okay fair enough

Lightclient: like it is a draft right now but it's like ready for people to review

Tim Beiko: okay good to know cool and whenever there's enough reviews we'll we'll merge it yeah and I guess if if possible if people could review it in the next couple days and we can like discuss it on Mondays four four call that would be great um even if like if there's no objections

by then maybe we merge it um but if there are objections at least we can discuss those on the call Monday and Terence asked the question is anyone working on the CL side so xiaoi is the one who opened the pr that like kind commented on but I don't how final or like production quality that PR was

Danny Ryan: that PR is not is no longer valid because that PR importance in rlp library to do the decoding rather than the version that we're talking about um it's very relatively simple probably myself or show where you can handle it

all Pinger and we can chat about it

Tim Beiko: awesome uh so yeah we're doing your rlp uh for 444 um and save ourselves another two plus week of discussions on this so bye anything else on this

okay uh next up Mario uh you wanted to chat about uh an issue that you opened in uh the EAP I did not have time to read it before the call unfortunately uh

do you want to give some context on it

yeah it's a very simple issue it's related to the version of hashes on the 40 before basically there's a discrepancy between the interpretation of the implementations um so in the in the EA it mentions that the only reason to consider a block in ballet block execution is that the blog version crashes I mean the amount of blobs is zero but some implementations are also checking the block commitment version of the of the glove transactions

um so basically what what I would like to do here to here is just to add a clarification in the AP because my understanding is that the execution can perceive and is valid even when we have a incorrect commandment version in any of the block transactions but most of the implementations right now are we rejecting these blocks so so yeah basically it's just uh uh I I wanna I I would like to enter the refrigeration of this in the in the AIP for us to yeah um to to get the the correct version I mean to get the correct ivn tests basically and to have a little bit more context um

I'm implementing um the the the goate room current implementation does not check the the version the device of the commitment version um never mind does check this and ethernet yes does check this too if I'm if I understand correctly and the tests right now do not care about this byte on the execution plan on the execution payloads so um so yeah basically that's that's about it um I don't know if if anybody has the time to review the issue and we can just come to an agreement whether this is regarded or not it's it will be it will be great

Tim Beiko: anyone have thoughts or comments uh gizinder has a oh actually engaging there and Alexa I have a plus one and always requiring the version byte in the

Marius van der Wijden: one thing that I like about requiring the conversion part is that no one can update the version because without what's up there to your client and that means that updating the version by it would be a hard book which it should be in my

opinion so I'm awful requiring

Tim Beiko: cool anyone against requiring it um so I guess we can do that does this I assume this requires a change to this spec uh to like basically the 4844 and then we can write some tests for it

yes I can open up here just to make the

small change that's okay

awesome yeah thanks sweet

Marius van der Wijden: this might actually issue like one of the issues that we saw on the on the Death Note so uh my father most likely sent transactions that did not have the version but it's correctly set um and and so that's probably some of the breakage that we've seen

Tim Beiko: got it

anything else um okay if not okay so this next one uh Peter I saw you posting about uh the kcg libraries uh a lot on the Discord in the past a week or two um I just wanted to check in on that and see is there anything on the library side that like we should be doing or working on yeah to make sure that uh they're in a good spot for us too uh use in production if there's like nothing new or anything nothing you you want to bring up we can go over it but I just wanted to make

sure we have the chance to check it

on it

Péter Szilágyi: so essentially when the case of your libraries um there are certain quirks that are kind of unexpected the ckcg library specifically the blst sub Library of it um has some has an interesting aspect it has some optimizations baked in that require failed in other CPUs and it will pretty much crash on an older CPU older CPU basically any CI server will crash so um

not all the by older CPU I'm not I don't need ancient CPU I mean just on the new S10 greatest and the problem with them is that um they have a built flag through which you can control but it enables its optimization or disable it but the author refuses to implement a runtime detection I mean it could probably it would be probably trivial to do it but for whatever philosophical reason the author just doesn't want to do it and uh this makes it particularly hard to integrate into other class I mean pretty much every consensus client had already issues with it as far as I know and they

had to I mean even if you look at Lighthouse they have a modern build and affordable build which is basically boils down to the cblsd library so screwy details now um the problem there the other annoying problem is that since you require an environment variable set during build time it doesn't really play nice with uh with using it as a dependency and for example because in go the code built it I mean the global system is very simple you just type go build and then all of a sudden if you want to um have an if you want to control the C

library and make it portable then there's no you cannot do that with the default go commands you have to set an environment variable which means that anybody building Gap all of a sudden has to know about this lame environment variable and if and if they don't know about it then there's really high chance that their build will crash at some point so this is one of the really annoying issues with the ckg library with the go kcg Library again not go kdg software the Upstream one of the concerns crypto libraries it makes some strange optimizations it does a lot of

stuff concurrently and this concurrency cannot really be controlled which is a bit of a strange decision for library because it's um I mean for example it can verify a blob concurrently on many threads and on default it will verify it on all your threads um I mean for sure it's three times as faster verifying it on 20 threads but then the question is that feels a bit of a wonky trade-off to be three three times faster on 20.

Reddit loads and there's really no way to control this threading and I would much rather have a crypto Library be single threaded and dumb and let me use the concurrency by verifying multiple blobs on different threads rather than the crypto Library internally deciding on on what to do I did look into it and it's a fairly oddly internal design decision so yeah I guess again with some Flags you could maybe end with some modifications completely nuke it out somehow it's um it's a bit wonky anyway so these were the two mic two main concerns with the two crypto

libraries on top of which the kcg stuff is built now just for the record with gas what we did is uh we integrated both libraries both go kcg and ckcg we default to go kcg and with regard to ckcg what happens is that if you build Geth via make or the docker images or our own internal build scripts or pretty much almost anything except the go the classical go build command then get will add the flag to enable ckcg and also add a flag to make

it portable what our official builds uh will be will support both kc2go kcg and ckcj you can switch between between them with a flag but anyone building get by a simple go build or go install command will not have ckcg available so that was kind of our best idea on how to solve it and for us it was in all honesty we have a fairly low level of trust in both the both kcg libraries and the underlying of the libraries because it's kind of uh new and um and we have an

equally low trust in ourselves to fix any issues if they happen and that's why that's why we went with this approach of including both of them and making it suitable by a flag because for sure we prefer the Go version but if there is let's say an issue a consensus issue between them then you want to be able to have users switch immediately without having to figure out okay how do we swap out the library how do we enable it how do we integrate it Etc so yeah that's kind of the tldr of the kcg Saga that we had on the gut side

Tim Beiko: thanks for sharing um I noticed there was a couple comments in the chats

during this but anyone have thoughts or yeah anything with like to add there

uh yeah we uh we can solve it by runtime selection of the library but it would be better if for uh there's a library equal to us approach to the runtime flag instead inside so we need to know whether we need to invest in this uh additional build and run time check or how we could wait uh for a solution in

the

USD parties yeah so uh as

Potuz: one of the ones that complained about runtime selection on blst um the problem is the way this is coded is not that you have one routine that uses adx and Molex and another routine that doesn't uh there just bits and pieces that are added or Not by uh by pre-processor insert instructions uh so I think the only feasible way of changing this without big changes in within the library is what the people of

nimbus were going to do which is just disassembling with the flat disassembly without the flag have the full binary ones and just choose uh at the beginning so have a much larger library with two copies of the full routines with one uh flag and the other flag and then choose some runtime that would be their fork and I don't see any other easy way of doing this chain making this change in blst so I don't expect the author to actually accept the a change towards this anytime soon and this is really annoying this is so this is something that really annoys me because it's something that the the engineering Foundation paid for this library and every single client complained before

the launch of the beacon chain and this was installed and now that the execution clients are also complaining that he's getting some traction again um yeah so so this is this is something that is is incredibly annoying uh on on the CL side at the point that prism is shipping this uh this binary by default which is portable because we did see some crashes a lot of validators are being run on AWS currently and they would they do crash because they run some old uh old Xeon CPUs uh the other comment I wanted to make which is something that makes me uncomfortable with the status of the crypto libraries is that they are still

changing quite a bit and I mean things that are kind of non-trivial uh on ckcg I saw Mario's that was complaining about the way of loading the trusted setup and On The Go kcg side it's something similar like the the version that we were trying uh did not accept the trusted setup that is posted already in the consensus layer uh uh spec rep repo and the change that fixed this is not long ago uh which means that if you update the crypto library to use that change then you need to update get and get hasn't updated to this so so it's becoming very problematic with all of the relations of

the different clients with the crypto libraries to even start testing this so I think it's it's we're still at a prototyping stage I would say that we're very far away from developing production code in that area

Tim Beiko: thanks uh so this was your hand up about this as well

Saulius Grigaitis: um yes so so a few notes on on this so on on the on this extension thing where you need to compile the the thing with basically with either either for new CPU signed up all the CPUs I think we also discussed internally interesting

approach but it's probably similar with an inbus one where we just in the runtime we essentially compile both versions of the Library which enabled extension and we disabled the extension and then on their runtime we check what CPU is it running and if it's a new CPU we use one one version and I mean bit enabled extension and if if it's not running and if it's running with all CPU then we are taking the old library I think this is ugly approach but at least you would not need to you know to have a separate

builds of your clients so but this is probably similar with what Nimbus was thinking isn't it uh the approach that photos was talking before anyway so so this is one question then I'll add another question on the under patronization so so for rest case you'll be we have even much more let's say not much more but more but otherwise the version where where we make verification faster

but the problem actually is not about using a lot of cores because if it's available you know then why not to use it but the problem is that if if I start to compete with with something else that client is doing something else important that client is doing so my question is for original and person who read the discussion uh like how do you deal with this uh elsewhere you know you you should have some hard computation that you're already paralyzed and how do you prioritize it you know and uh like if

you could tell some examples of that that would help to to make a solution that you know some hopeful some button a solution in the crypto library that helps essentially that solves this competing problem uh the so one way of we are thinking about is just to lower to lower the thread priority uh essentially so the US operating system scheduler will just make it as competing with other things that that client is doing so I mean if you could tell how do you solve that currently

because you you talked about um that you don't have a control in this in this approach with crypto library but if you had control how do you do that

Péter Szilágyi: well I think one of the problems is that this is not solvable at the crypto Library level specifically because for example if I'm doing a block processing then I don't want it to be uh uh lower priorities and for example if a new block arrived I want it to actually have the highest priority during processing now if on the other hand the blob is being verified in the transaction pool then for example I would like to have it a lower priority

so these are and this is something that you from the library from within you cannot really guess which which blob is important now and which blob is not important

and

Saulius Grigaitis: so yeah I think a pretty easy approach will be I mean not ideal but something that would be easy to achieve is is just to set the threat priority whenever you call the verification function you know so if if you need that you know as fast as possible then you say that the crypto Library should spin threads for this particular verification

with the normal or high priority and if you otherwise if that's not important you just say for crypto library that this is not important verification and it just spins threads with lower priority so it doesn't compete with uh with things that uh with everything else that runs on on the default priority at your client I guess this makes sense

yeah sure it doesn't make sense but um but

Saulius Grigaitis: I mean there is no easy solution for that but there are some solutions that probably should work most of the time and and the one I I just described it it could be the solution for this problem

just to make sure I understood you want to have a like a specific uh scheduling threat scheduling policy uh for for every use case and it will have because it's dependent on what OS you're running on you will have to have error NOS like specific library for every yeah every

platform you want to support basically

Saulius Grigaitis: I mean we checked on the like a three main platforms which is like Linux windows and R6 and the usual there is a way please for these three operating systems there is a way to change the priority of the thread uh so desperate much is enough to implement this idea maybe for for other platforms which we we were not interested in maybe it's even not possible to change the priority so then yeah this doesn't work on their platforms

Péter Szilágyi: so I don't think that will work for example in go because go doesn't have real threats go uses very

few real threats and the multiplexes all the girl routines on top and I don't think you will have a way to lower the priority of a threat of a go routine

Saulius Grigaitis: but if you so I don't know actually how it works like if that's only gone environment then yes but if if that's something external you know something like if you call C kgd or kg from Goa then it definitely should be able to uh to uh to use system threads because it's like you know C extension or something outside of the thing

Péter Szilágyi: that would be super expensive because

spinning up threads is uh at least on some windows uh sorry on Linux it's a bit faster speeding up fast but for example on Windows it is extremely slow on the order of milliseconds so if your crypto Library will spend 10 milliseconds or 50 milliseconds spinning up threads to do the half a millisecond work then that doesn't really fly so essentially these are these are kind of also this highlight issue that once the crypto library is a very very low level stuff and it tries to do threading which is a very very high level stuff and then you hit all these kind of strange issues with uh with how to solve so anyway it just feels that should not

touch threading

Tim Beiko: so we're

Saulius Grigaitis: well I think yeah just last note I think we just didn't to think do we need like a top performance or if he can go on a single thread and everyone is happy with that

Dankrad Feist: so I mean I just want to chime in here I've been trying to get in for a while um I think like the only thing where threading even makes sense is for blob Construction and I think we're getting way ahead ourselves by trying to optimize the semester like I think it's perfectly fine right now to just completely ignore this because the kind of like Roll-Ups

who are going to do blob construction it's still first it's not a lot of time it's still talking tens of milliseconds here and uh and second like they can start optimizing that they don't even have to use a standard build for that so I feel like trying to optimize this now is just like I I would I would just say like we don't need threading at the moment you can just ignore it and maybe can have it somewhere in the code and they can have a special code or something

Saulius Grigaitis: do we have like is there a decision pretty close to formality or how much of uh blobs they will be in blog on demanded

I mean is it like four or sixteen

Dankrad Feist: what does that have to do with it do with it well like on CL side for verification it's for verification why do we need parallelism like this is like we're talking about like a few milliseconds

no

Saulius Grigaitis: but you know there are there are a few things there are slow computers uh so like slow nodes where every millisecond just multiplies by by the slowness of the computer this is one thing and there are some use cases where block verification is important like every millisecond is important you know like in MA or whatever else I mean so I

I actually don't agree that you know that you can just ignore the fact that those milliseconds are up together and if you have a

16

Dankrad Feist: I mean this is on sale right it can be done in parallel to execution layer verification anyway so how much

we should actually add

Dankrad Feist: this is in parallel to execution there like this is a CL thing so it would be in parallel to what the execution layer does anyway so does it actually to block verification any faster if you parallelize

it NCL

Saulius Grigaitis: sure and why why it shouldn't be faster

if it's

because I would I would assume that El is the bottleneck anyway so if you add a few minutes okay

Saulius Grigaitis: so you're saying okay so your point is that that CL will always be significantly faster than El so so it doesn't matter that if it's lower on the seal side

yeah

Dankrad Feist: I mean this would be my guess right now again I also feel they're getting ahead of ourselves optimizing this for someone who's doing mov extraction like okay so I mean I I'm still with my opinion that we should do as as fast as

possible but yeah I get your point that if El is much slower than CL then technically we shouldn't have the problem here because you know CL will be able to complete even on a single thread verification because El is taking much more time also like um I mean the CL can paralyze other tasks in parallel to this so like I would assume that signature verification is much more work but you can easily like the CL can simply thread this the plot verification the signature verification again this feels

like absolutely optimizing uh The Blob verification to like 16 threads just seems crazy to me like I mean I don't know like that's that that seems like an insane premature optimization that's like just makes things more complicated

well I think the the key thing on CEO is that the the blobs will come asynchronously not at once you know so naturally I mean naturally like the proper implementation is just to to do a verification whenever you get the blob immediately

Dankrad Feist: so that would be an even stronger reason not to parallelize it no I think but if you have a lot so why

have you been discussing this it's just

it feels like yeah so I guess yeah yeah but yeah yeah that's the that was the

Saulius Grigaitis: a bit of topic to to the original commissioner traditional original person so we're already like five minutes over time I don't know I know there's a telegram Channel discussing the libraries is that the best place to just actually the telegram channel is like for ckcg but is there somewhere that we should continue this conversation I mean we can use the like we have a bunch of 4844 channels so

we can use those I don't know if there's any final comments before we if we move this offline okay yeah so that's um yeah let's continue uh do you mean Alexa do you mean SSG chat or kzg chat

no no it plays the way you know always wanted to have access this bridge shutting Discord okay

Tim Beiko: we have a transaction type Channel which I think we can probably reuse for that yeah we have a type transaction Channel

which we used for that in the past um so you can just keep using that

yeah um okay so we're already a bit over time um I know we had Zach and Charles who wanted to like give a bit of context under eip's um we can take you know two-ish minutes on each of them if folks can stick around um if either of you Zach or Charles preferred to do this on the other call or on the next call with a bit more time we can do that as well um but if not uh Zach do you want to go first and give some context for the next call

um uh but is this the best Forum to discuss it assuming that this EIP Target specifically L2 implementation um with that in mind there's a caveat that it does involve additional State transitions um and may have implications on Supply since it's a modification of uh 1559

Tim Beiko: so yeah we we haven't Danno had some comments about this on the chat but like l2s could do things without awkward devs you know permission or priority or away um if people have like technical feedback on the EIP probably makes sense to share it and I know there's already a

bit on youth magicians yeah anyone else have thoughts on either the EIP or whatever we should even be discussing it with that

no

Danno Ferrin: so to add on to that um about the jurisdiction I mean if we say something and the altitude is ignore us there's like no side effect versus if something for me that something's just said on this call and say Geth decides not to do it or you know they're not mine decides not to do it while they're out of sync with mainnet so there's a bit of jurisdiction because we Define what's standard but l2s can do what they want I mean I mean it's true you know so that's that's my concern is that there's no stick just carrot

yeah

Tim Beiko: I think maybe one difference is um

and this is maybe not the best EIP for this but you could imagine l2's wanting to do something before mainnet and wanting like some sort of Sanity check of like you know if this goes well on an L2 does L1 want to do this um so that might be a case where I can make sense to get the feedback earlier rather than later

Danno Ferrin: and I do see that this IP might have that along the other ones like 4337 and maybe in the future evm changes so that is a question we need to resolve you know beyond just this

eeip uh well

Tim Beiko: you have your hand up is

off

William Schwab: um I wanted to add a point somewhere to

the one you just made to him so I mean full disclosure I work at polygon um a lot of times there's a certain level of uh coordination that I feel the ACD should be open to though I mean there's an opinion definitely open to debate I understand your point Dano and I think that it does like there needs to be some kind of resolution to that but looking at an EIP like 3074 or other ones that involve actual evm State changes I think that there's a lot of value in a certain level of coordination effort going through ACD even if it's not necessarily going to land on ethereum's evm right now um it is the best rallying point around evm engineering and like Tim mentioned

also just being able to get some level of sanity check that things potentially make sense or also to be able to send signal I think is valuable I think there's also a value to that for ethereum itself which is that l2s have much more of a potential or all tell ones for experimenting with things that ethereum probably should not be be experimenting with but if are successful on l2s can kind of trickle back up to uh to ethereum so I think also kind of in that cycle there's at least some value there but that's just my side of things

Tim Beiko: thanks for sharing uh and score last

comment on this and then we'll move on to Charles

Charles Cooper: yeah I just wanted a better briefly say because I've talked to some people about similar ideas in the past and and I but I do think it makes sense to have some sort of coordination between old BBM chains including reactus I'm not so sure that at least in the long run ACD would be a good forum because we can never actually um promise to bring things on on Main Network it could always be that even if we think we might do it then we like don't decide not to do it and and so then I I think in the long run it makes sense to have these kind of processes be separate although I wouldn't be necessarily opposed to like use a CD in some form for like bootstrapping a

process like that once there's professional interest but yeah but this should continue this

instruction for them yeah

Tim Beiko: um yeah and so I guess for the specific EIP we can use either magicians um and and for just like meta discussion um I agree this is probably something we need to figure out I'm not quite sure what's the best way to have the conversation but it's it's been on my mind as well um I would definitely want to avoid a new permanent call if we can for as long as possible yeah but let's see

um okay yeah please act yeah

Zak Cole: I'm sorry uh just one more thing uh is there any way that

we could just get this uh EIP merge so we can alleviate any bottlenecks from the active working group um sorry if that's not the best place to ask

Tim Beiko: so I know there was some issue with the numbering I think it's probably easier to resolve those on GitHub or Discord uh and not open that can of worms here

Zak Cole: Yes sounds fair thank you yeah

uh yeah and

Tim Beiko: sorry for the delay in sort of jamming this right at the end of okay no problem Charles

Charles Cooper: hey um I know we're really over time now I wanted to bring up again uh M Copy and secondary pay which brought up last time

and I think at the time Tim said that you know um to give everybody a bit of time to review it and I was wondering I'm happy to punch next week but you know I want to keep asking if we can include at least M Copy and also pay in in Cancun

Tim Beiko: so I guess we we definitely shouldn't be making this decision 15 minutes over time um it seems so there was some like support for M Copy last time uh seems like there is in the chat still um maybe and then payoff codes a bit more controversial it seems

what we can do is like put M Copy on the agenda for and we could put pay as well but like uh put it on the agenda to make a decision about on the next call so like two weeks from now we um we have an idea and generally as well try to figure out if there's other smaller eips um that people want to see in because I know like 4788 or the BLS pre-compiles were also um we're also kind of wanted um so if client teams can have like an idea of which small eips are important and and would want to be included in Cancun by the next call we can we can have that

conversation

Charles Cooper: okay great I I do want to point out that uh evm1 it's merge support for M Copy I think they're also working on uh State tests and there is also an open pull request on gas for M Copy all right I have already uh reviewed but if one of the maintainers wants to at least you know not necessarily do a full review but at least take a look at it so they they can get an idea of how how nice M Copy is and how useful it is and it's not too hard so I think that might help a little bit

Tim Beiko: awesome

but

Charles Cooper: anyway yeah uh yeah we can continue next call

Tim Beiko: um I think this is a good spot the L we're already 15 minutes over um any thing final anyone wants to bring up before we wrap up okay well thanks everyone talk to you all uh on the CL call next week

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.