All Core Devs - Execution #152

Transcript

[Music] foreign [Applause]

Tim Beiko: good morning everyone welcome to the first uh awkward Dev execution now um so 152nd of these calls um yeah most of the stuff today is around Shanghai so getting some updates on the status of withdrawal testing and devnets um there was a spec change proposal for uh The Limited meter initcod EIP and I'll go over and then um following up on eof seeing both where clients are at uh based on kind of the conversation from the last call and um also going over like the the different proposals that have come up uh since

then then I can go over some testing stuff and uh finally um there's eap4844 a proposal on the CL specs and two new VIPs to discuss if we can get to those um I guess to kick it off uh does anyone from either the testing your client teams want to give a quick update on where just uh withdrawal testing is at uh where the different implementations are and and what things look like in terms of

devnets

Barnabas Busa: regarding the internet I could give an update yes

so we currently have a devnet one for running and we started it uh just before Christmas currently we have all the different client combinations uh running on it and some combinations uh work well others are not really uh I have the link uh posted in the chat here so here we can see that we are on block uh 94 000. and most of the most of the nodes are able to follow

the head

Tim Beiko: nice um and what's included in the in the implementation so I assume it's withdrawals and then these uh other

small eips but not eof is that correct

Barnabas Busa: that is correct

Tim Beiko: okay sweet any other client team uh anyone have have thoughts on this or anything else you want to share oh okay and then Perry yeah posted the spec versions uh we're targeting in the chat uh so that's the CL spec at one 3.0 Alpha two and then on the El side uh the withdrawal uh EIP we're using commit zero fa adec great anything else just on withdrawals

or devnets for Shanghai

Barnabas Busa: we would like to begin a new one with uof included but that is really up to the El teams too be ready

Tim Beiko: got it yeah well yeah uh thank you um I guess before we get into eof I just wanted to quickly cover this change uh Powell had proposed uh for eip3860 that changes one of the failures and it seems like uh some get folks have uh approved this I didn't want to give a quick overview of what this is Marius I will pick on you because you're

the first one who approved it and I can't find power on the

car God damn it

Marius van der Wijden: so basically uh we have uh different uh failure modes um either uh uh out of out of gas or just uh or just return a0 so either like either we like uh terminate the uh the the transaction context or we return a zero address and if you look into the linked ethereum magicians uh thread you can see that there are uh these checks uh like they were like

intervolved so we had some out of gas gas checks before uh and then within a zero address return and then some other out of gas checks and it would makes it just makes more sense to have them in one block and then have the other and um the one that basically right now the uh the way it was specified the init code size limit check would return address zero um but uh it also conceptually makes more sense to return around there because it means you like you're running up against the the init code size

limit and that's clearly an error to me so yeah

Martin Holst Swende: yeah it can also be seen semantically as if I mean you can deploy deploy any code size but if you do it larger than c000 bytes it costs the infinite amount of gas

Tim Beiko: great okay any other I saw like yeah get folks approved this Pro uh Aragon as well any client team disagree with this um so perfect I guess we can go ahead

and merge this in the next week or so and then um update the test and the next step that uh should also include this this change okay oh uh Power yes

Paweł Bylica: sorry for being late um I wonder if there's like any comments from like the other side I mean the the contract on contract developers to uh if they if they see that as a kind of issue to handle

Tim Beiko: does anyone on the car

have an opinion about this contract side do you want to block merging this until we figure that out or is it better to just

I'm

Paweł Bylica: I'm also slightly in the in the favor of the proposed change so to as as I think the the client that's agreed on um but I think the the main reason it was the other way around was that um I think the most of the comments usually are on this generic level to I have to return us

as like user-friendly errors as possible so that I think what was the the reason for the original design um yeah I'm not sure like how much this applies here uh but I I wouldn't block it but if there are some concerns yeah you know

Tim Beiko: yeah I guess just because we want to uh look forward to withdrawals and and it's all kind of intertwined I would move forward with the change if like no client teams has

an objection um I think if we learn in like the next few days or weeks that like there is a big uh pushback by by contract devs we could um we could always revert it back um it's not doesn't seem like a huge um but yeah I would try and go forward and merge it for now anyone disagree with that

I agree

Tim Beiko: um and I'll try and uh give a shout for contract devs to look at it um so maybe we can wait like you know until like late Friday or Monday to merge it in so it gives people at least a couple days but assume it's going in sweet

okay and next thing is eos um so I think there's like two things to like unpack here so first is like the current status of the eofv1 implementations and it makes sense to go over that and then we can discuss kind of the different proposals that have come out uh since then uh so specifically vitalik had a proposal about banning a code introspection on youth magicians and then uh this morning Alex just shared kind of a view of uh how that could all fit in in a broader eof roadmap um but maybe yeah just to start um do any of the client teams want to share kind of where they're at with their EOS implementations

Lightclient: maybe I can just give a really quick

update also from what you did over the holidays yeah yeah so we did two breakout rooms over the holiday period and there were two main spec outcomes from that mostly from the first meeting the first one was that we removed the jump F op code it was something that we felt we just needed to spend more time have solidity uh complete their implementation and make sure that this was the right the perfect type of uh instruction that that we were looking for and so we removed it for now so reduce the scope of eof slightly by that and then we also made the data section mandatory previously it was optional but

making it mandatory it made the parsing uh marginally simpler so those were the two main spec changes a handful of things where other other things were discussed but those those were the things that did make it into the spec the Epsilon team spent a lot of time and I helped a bit with making getting into this spec into a more finalized place I think we've like merged all of the outstanding PR's to the eof Eeps there's still a handful of like small things that you know small errors in the spec it's some conflicting things between the four or five Eeps but more or less like the eaps are in a good place now with respect to the implementations and tests I think you know about a week and a half ago a week ago Martin started

doing differential fuzzing across all the clients and that uncovered quite a few things initially I think every client had at least like three four bugs and uh a lot of those things have been resolved and if Martin wants to talk more about the findings there yeah that would be great but we also have two sets of reference tests I don't think either of them have been officially released yet but the Epsilon team has been working on a set of tests in ethereum tests and Mario and I have been working on some tests and execution spec tests Mario and I decided to not release them until we were able to integrate the like Shanghai by time logic but those tests are in this PR I put a tarball up before

the meeting uh I think like the reference tests are not as comprehensive as we like ultimately will want them to be but they're at a place that we can start getting an idea of like where clients are unfortunately I don't think that any clients other than um you know the guest client has brought in all the tests I ran the Epsilon tests a couple days ago passed all of them except for two or three and obviously I filled the execution spec test so we are passing all of those so still need to get some clients to run to run those things uh yeah I think that's mostly the update uh Curious to hear what other client teams have to say about the progress of their implementations

um maybe Dano uh yeah

um basically uh we started running

Danno Ferrin: reference tests um we haven't uh there was a spec change initially you could go eof1 to Legacy willy-nilly so I need to update that so you can only create ef1 out of eof1 um those are most of the tests that are failing um trying to hold off on doing too many merges until we to reduce the number of PRS that go into the actual main line so I'm stacking most of these into an eof-5 breakout branch that I have um but yeah it's we're basically in the you know checking all the boxes Pages making sure that it's all ready to go so we got the major work all done

Tim Beiko: got it thanks uh anyone from nethermine or

Aragon

Ahmad Bitar: um so we are we already have a complete

implementations for eof uh uh tests uh are still not finalized we're not sure which we are to pull and to run against we have ran against a couple of them uh sensed that they're still not ready and uh does not cohere to the specs so we we are we just want uh we we would like the test to be finalized uh so we before we start with the devnet because if we start with the devnet before the before running the tests and and resolving the

issues probably what will happen is that during the devnet we'll have a lot of consensus issues and it will take so much time to debug where these issues are um yeah basically that's that's the status but for implementation wise we have done all of the implementations for all Eeps and uh we are already passing the buzzer that live client was talking about

got it thank you um anyone from Aragon um yeah for Eragon it's easy we are going to piggyback on the gas implementation by lifeline

Tim Beiko: got it

um thanks Powell I see you have your hand up uh is that related to this

yes

Paweł Bylica: yes I so actually I wanted to to give update about the tests uh a bit more specifically so um the test cases I mean the the state test the execution test uh from from ethereum slash tests so the test cases are still divided into five groups coming from original eips um because that way kind of the defined most of them previously um but um what is

the the implementation is actually has all of the heaps enabled so so the the the test case is kind of uh like focused on like specific aspect of eof but uh you should expect all of them all of other features also being enabled and the current status is that uh this is like recent uh we updated the the first pack of that and this is already in the the main branch of tests this is eip35 3540 um so this we consider already uh although uh evm1 and GAP implementation

I think doesn't agree on one of the tests so this is one one one thing that we need to take a look on but uh I think it's almost almost done this part uh and and the next Parts uh so that the the the second the second set of tests are ready but not merged and two others are in in being being in progress and the final one is it's not started yet so that's more or less the the um yeah the the summary of of the status uh that's kind of trying to also answer the one of the comments from from one minute ago that

uh I think as of as of as of today you can you can take a look on this first pack of tests that's already in the main branch

Tim Beiko: got it I thank you any other thoughts on the current status of just the implementations or the tests I don't know if Martin you wanted to give a quick update on the fuzzing work you did

Martin Holst Swende: well um not Montreal I'm trying to make um the cluster a bit more advanced now but essentially it's uh four different clients that are not five different kinds of being tested

and four sorry um and we have a pretty good uh you know it it turned out that the implementation of the container format and the validation is obviously fairly complex uh judging by how many different types of implementation flaws were made uh but also the validation turn out to be very easy to test and we Define this test format which just we can show bytes as input and we can compare the outputs so we could get very good coverage of this and I'm fairly confident of this type of testing will

uh be proved to be very efficient efficient in the long term and what we have not tested is this actual semantics of running the code so my passing has done the the validation of the code but not the actual execution of the of course so that's for for a later stage with status and stuff yeah it doesn't matter to me

call

Tim Beiko: it thank you any okay anything else on the current testing and implementations

Mario Vega: yeah I I would like to share the

perspective on the execution test so I've been working alongside Lifeline with the other uh test suite for reference tests and one thing that I really found is that um there it's not so easy to create an effective best case for eof so and the problem is that there are a lot of pitfalls for example um if you want something to fail in a certain way in EOS you have to be very specific and you have to make sure that the test doesn't fail somewhere else before reaching what you really want to test I think that it will be really valuable

that we summarize the errors somehow so we can verify that our tests are actually tested what we are expecting them to test um like I had uh uh draft of the errors but um I don't know if if you want to share that that now or maybe something later but I I really think that it would be really valuable to have that standardized over all the clients that are improved in

the U.S

Tim Beiko: thanks um okay and yeah like sign just shared

uh his notes in the in the test with all okay with all of the different error codes there anything else to add on this

Danno Ferrin: I'd rather have the errors as readable strings so you can figure out what's going on rather than having to cross reference a table gotta be one request but standardizing the strings I think is fine

Tim Beiko: I and I guess so it's like two other things to talk about so one is

um you know on the last call we we said we might remove eof if it wasn't quite ready today and and and uh same thing for the next call um I think before we have that conversation it's worth um talking about like the new eof proposals that came out just so we kind of have that in context um when we when we make that decision um so I don't know maybe it makes sense uh vitalik you you kind of posted this first one on these magicians about code introspection and then Alex you just posted this morning kind of the your plan based on that but uh maybe vitalik if you want to go first then we can do Alex

Vitalik Buterin: sure um are you guys hearing me okay

Tim Beiko: yeah it's pretty good

Vitalik Buterin: okay great um so I think what I wanted

to start with is just a bit of a kind of philosophical backgrounds behind so where some of the things I was saying they were coming from right so the yeah concern like I think the difference between Evolution and ongoing improvements of any kinds to the evm um at least as it's done so far uh versus um ongoing improvements to the rest of the ethereum protocol is that in the evm it's much harder to remove things than it is to remove other features right so like last year we managed to successfully remove a huge module you know the entire proof of work uh get sentence system and that only led to like very limited about like backwards

compatibility issues for uh users and for applications um but uh on the other hand with the evm like we yeah so we have added a couple of op codes but when we have tried to actually change things or even remove um it's uh generally yeah it has happened a couple of times but there have been very high costs right so like for example removing the self-destruct op code is you know well on its way but it's uh definitely something that all together is I probably taking five or ten times longer than a comparable change outside of the evm will take um or even the gas cost increases from

two or three years ago Canada but it ended up taking quite a bit of time right and so the reason for that is basically you know kind of obvious right it's that that the yeah you have applications that are written in evm code and and if the evm changes then those applications can't change whereas if you're touching a part of the system that interacts with something on the outside that like for example if we eventually get rid of our op transaction formats then like that deals with something that's on the outside where and that and that something can change right um and one of the things that I think would be again or one of my big worries

with improvements to the evm and particular is basically that because it's much harder to deprecate and actually remove stuff a yeah a philosophy of the of uh kind of evm developments that allows for a larger or basically a large amounts of ongoing improvements it doesn't uh commit to like something really really close philosophically and fairly soon would risk us basically creating a V2 and then creating a V3 and then creating a V4 and require but still requiring like V1 V2 and V3 to still be part of the consensus code because we don't have good ways of removing them because there are applications that are written that depend on them right and

like we kind of see this already with like call code is probably a good example we add a delegate call which is obviously better but uh call code is uh is still around and the yeah General path that Isaiah wanted to suggest as a way of getting around this issue and as a way of getting to the basically letting us make some improvicity evm over at the um over time but at the same time actually achieving the objective of uh making the EDM similar and making the evm cleaner and make like actually you know making the protocol more simple and More Beautiful

over time instead of just having this kind of glob of uh ever increasing uh technical debt that we fans get rid of is that if we're going to make a new AVM version that new EDM version should be designed with the idea in lines that it's the of being very forward compatible to all kinds of upgrades that we want to do in the future right and the current evm is totally not that in a whole bunch of ways basically because the current evm can like just has way too much introspection right so like you know you have code reading up codes and code reading op codes to let you read

specific bytes of your code you have the jump up code and the job code you can take as arguments a byte value that gets created by evm execution and so the job destinations like you can't actually yeah rearrange them you have to keep the same byte in the exact same fight I mean you have you know things like uh contracts create creation and uh you know every Everything having to do with code being kind of closely referred to by its code hash there's like a whole bunch of evm properties say the gas is also is also another one right where the facts that all of these EDM internals get exposed means that it's like in any attempts to

change a whole bunch of things how just inevitably becomes a very backwards and compatible right and so the idea is that if we make a V2 of the EDM we're that D2 has the property that it has much less introspection then what we gained the ability to do is we gained the ability to forcibly upgrade old contracts right so if we upgrade let's say evm V2 to at some points in the future you know V2 to V3 then we could have a protocol rule that says oh when a contract that is still V2 gets touched then you can apply a transformation that converts V2 code into these three code that has equivalent behavior and because you there isn't all of this crazy

introspection that it becomes actually possible to do that right so like for just to give a a quick concrete example let's say in V3 we decide it's you know having shot three or catch hack asset op code was a mistake from day one so let's get rid of acid upgraded let's move it over and make it a pre-compile well the problem with doing that is that you've replaced something which has one byte with something which has like 10 to 20 bytes and you know also you're going to need a memory slice for it somewhere and so you're replacing a single byte with a byte sequence that's more complicated and so that ends up changing the code copy output and that ends up changing the positions of all the code and like you could write out the transformation and do it but only if all of this sub

introspection doesn't exist right but if the introspection doesn't exist then what you could do is like actually write the transformation potentially even formally prove that the transforms code has the exact same behavior under the new version of the pre-transforms code housing through the old version and then after you would have a transition period where evmv2 and EDM V3 are both available and eventually like actually let me to like make sure that all V2 contracts get poked and moved over into V3 and then once that happens then it would be possible to eventually look upgrade again and do a Z4 or something like that right and so that would mean is that the number of evm versions that clients at any point in time would have to actually support is uh

is kind of upper bounded at it too right like as uh once you go past three then like you know version uh the third oldest version could just be fully deprecated and one of the nice things about EV eof as it is is that it has features that go in that direction right so particularly if they're getting rid of dynamic jumps getting rid of dynamic jumps is like a great move in that direction because it enables these code Transformations right like if you can if you have to make a bow transformation that replaces one bite with five bytes then you can do that and you can translate all the coordinates and you know that like the reason why you you can translate coordinates is because there no longer is a way to jump that where you pass and

a v chord that you're jumping to as an evm generated variable right and the inability to do that makes it makes that kind of code transforming actually possible um so my suggestion is basically well you know we could take the eof route uh but extend it a little bit ban introspection and like basically push it to the point where it goes um all the way it actually makes code um much more transformable so so I guess the the things that I you know look that I would love to hear feedback on are like one just the general direction and uh the concept of moving toward this uh evm approach where basically we're committing that the API

the first goal of the of uh upgrades is to upgrade to some kind of code which is uh much more walks down and not introspectionable with the specific uh goal of being upgradable more over time and then eventually like actually saying like you know we are going to only need to have two versions supported by the Yeah like actual ECM clients at any one time unless they really care about uh you know X verifying the Channel all the way from history and so that way we can keep upgrading and having things to be sustainable um and the second thing is uh specific Pathways for doing this right so my

proposal basically you know like what it would in practice involve delaying eof uh to the and adding some significant stuff to eof to make it uh to make eof itself be to like be this but you know another path might be to have the kind of current proposed dlf V2 and then have a V3 and I think the V2 would still be transformable into V3 that like you would have to pay some costs like doubling code size but that would be fine um and then you know maybe there might be some other Pathways as well um so you know there we go

Alex Beregszaszi: yeah I do

I'm not sure if I if I should actually go through the The Proposal um in depth um probably not because it's also like quite lengthy but I wanted to start yeah I mean I wanted to start with uh seeing that we actually wanted to have a lot of these features generally which were mentioned you know going back um particularly last year we did hope that some point to reduce student

introspection options um which also means like getting rid of of anything gas related um we wanted to also revise maybe memory handling at some point we kind of felt like they're doing all of these in the same time is extremely ambitious and that was the reason we started to split up all of these changes into steps um one interesting point vitalik mentioned regarding static jumps um and code modification there was actually one of the the driving forces behind the the relative jumps we have proposed in eof

um the inspiration there was optimism's code transformation where they were inserting uh code for external calls they were replacing that and with some kind of a guarded call um and basically that was the inspiration of how the the jumps uh are designed in UF um which basically allow code notification um very easily I think the main the main disagreement may be in around the the sheer size of these changes um I think last year we never imagined

that the we would get to this point that you have all of these changes are considered at the same time um because that many changes were never actually at least it feels like this many changes were never applied in the same upgrade to the evm and in the past basically during December um I think the understanding is that we are probably at the the limit of uh the number of changes we can safely make it's it's not really just about you know testing time but rather having confidence that we can cover all these um and I think the the changes we have

in the current version are less related to how opcodes operate and they're more related into just a general container format and validation you know as a lot of this was already mentioned by by Martin and others on this this call uh regarding the updates um and so if we would um consider splitting um the kind of changes in the two parts and the first part would be what we have currently under eofv1 which mostly considers the the container format and validation but doesn't actually change um you know a large number of codes um it seems like we can you know with more confidence test these set of

and then Implement and test the second set of changes which revamp um I think a significant number of up codes in in the document I shared um I took it actually further than um just account code introspection um because we had a number of features on the wish list um which are kind of related um the reason code introspection is needed in in contracts today it's basically twofold most of the time they want to read um data in the contract and the data can

be um you know just predefined data but it can be also something called immutables in solidity which in practice are data fields which are populated during the creation time so during runtime the ACT is constant Fields but they're still fields which are right ones during creation um and the other case where there is some kind of an introspection happening is is creation itself um because we have we don't really have a specific transaction format or specific separation of of how code and Constructor arguments are handled and the way this works today is

um it is just a practice by solidity by the solid compiler that it depends to Constructor arguments at the end of the um the code um so the basically the code has like three sections today during creation you have the dnit code which is ran in the the content creation context then there's like the runtime code concatenated after it and and finally it ends with any potential Constructor arguments um if this was already on the wish list to to maybe we should revamp this um and I think this this kind of ties into um I can't go and introspection um but this requires potentially a new transaction format changes to the

creative codes and if we do this kind of changes then I would propose that we actually go one step further and we also try to eliminate you know gas introspection uh which which then boils down to redesigning how the the call up codes operate um I give some rough ideas uh regarding direction for all these changes in the document but of course by no means these are um you know few feel immature um yeah I just want to conclude that um I think I see like three different paths we could go

uh One path obviously is um you know just going with the UF V1 as it is without any changes and then uh working on ufv2 which may mean that there there may be you know a few number of up codes um uh which uh would have to be supported in V1 and would be Bend IN B2 there is a second kind of path where we could decide that we disallow some optodes like creation in B1 but we make a strong commitment that we want to make a decision on of how creation should work

buy the next upgrade um or you know soon after and then we can choose two paths uh you know we may end up thinking that the creation as it is is good enough so we just enable uh the create up codes SDR or we could decide that we actually want to do this new version which was proposed in the document and work on that instead um and the last path um what has been mentioned is yeah practically delaying and and delaying V1 and thinking about how uh whether we could integrate the two changes into a single rollout or if not then it has to be two roll

lights again I personally don't think there's any potential way to roll all of these changes out at once as I explained earlier so that would mean that uh you know this would be delayed for two three um upgrades from today I think that's my long explainer of the document

Tim Beiko: thank you yeah I'd be curious to hear people's thoughts about kind of this whole spilling of the the road map like with just any reactions the vitalik and Alex's proposals

Micah Zoltu: um yeah I think unless we have a solution to the current evm and making it go away which I do not see a path for that we are always going to have to deal with at least this version of evm even if we can make this we only have feel this version of the evm and then the latest but not everything between we still have to deal with this version of the ebn which is like the worst of all of the possible epms we could come up with right it was the first one didn't get it perfect on the first try and as long as we have that problem I feel like we have the general problem that we need to solve a multiple version of the VM and if we've solved the general problem of multiple versions of the evm in production then

it's not that big of a leap to just support all of the intermediate ones as well like I don't feel like we're gaining that much unless we can get rid of the currents first EPM which which again I don't I don't see a path to that

Vitalik Buterin: I mean inversions is a lot more than two though like especially over assignment especially over the

20-year long-term

Micah Zoltu: sure so and versions is definitely worse than two versions but I think that the difference between one and two is you know massive the difference between two and three is very marginal and difference between three and twenty is a

little bit more than marginal but still nowhere near that first massive jump from one to two and so the question then becomes okay so if we're not getting that big massive gain we're only getting like a series of intermediate kind of marginal gains that maybe they do add up to some amount uh is it worth all the effort like there's a lot of effort that goes in into this like every single time we want to upgrade the evm we have to think about okay how do we transform everything like we have to actually solve that transformation problem for every evm change which is not trivial whereas if we just accept you know we have all these EVMS then we don't have to deal with that problem and so I'm just questioning is it worth the effort which is pretty significant if we can't get that big gain from going from two to one

which I don't think we can get

Tim Beiko: oh not sure if you have a mic

yeah

Dankrad Feist: yeah I uh so I have a very I mean like I think it's very different I think like every like we should like clearly already there's jump from having to support uh two to having to support three versions is like uh yeah 50 jump in effort right so I would I would say it is uh yeah I mean I I can see um X6 arguments on like it is very hard to make such a big uh version jump at

once so I agree that that is definitely a problem worth speaking about but it's also uh it's also really worth thinking about this uh this continuous effort that's 50 more having to support one extra version of the

ebm fvs now

Vitalik Buterin: yeah I just wanted to kind of also again uh reiterate that I like I think this is a big this whole thing is a big decision and this whole thing involves irreversible decisions and I think it's like we should all remember that making

the right decision for the 20-year or you know 40 year long term is much more important than not delaying things by six by six months or even what uh or even one or two years right um so it's look this this is definitely something that I think uh whichever decision is the right one that really yeah should be a thought carefully about and uh if we had before making a irreversible commitments of any kind we'll exact commitment should I think have in Minds the idea of uh like what the actual passions uh going forward from there is going to be I see again like I said in the message is the right decision for 20 to 40 years

is ossification I think uh you know if that's true then like that what might even be an argument that's the right that the right decision today is to actually get osify and basically say the evm's not going to change going like even starting tomorrow right but like whatever the decision is the long term should be yeah I think really uh thought about as the the primary issue right

because uh um Andrew um yeah

Andrew Ashikhmin: uh I think I'm just afraid if we delay eof until it's perfect then we lose so none the opportunity to get

actual feedback because uh trying to make we we can't get something theoretically possible or perfect before actually putting it to test and to real use uh to my mind UF E1 is on one side is big enough and on the other it delivers good good improvements uh for especially especially it eliminates uh Dynamic jumps so yeah if we if we try to make it perfect then it will be uh like a never-ending super project uh especially without without feedback from from real

contracts I I would I would deliver it in steps

yeah so

Ansgar Dietrichs: um it seems to me that maybe one good path here would be given that we we are kind of shooting for a four eight four four walk um I don't know under three four months timeline after Shanghai that maybe it seems like enough people here have concerns about making a good decision that locks Us in for the next 20 years on such a rush timeline like like for Shanghai would basically have to make that decision today um that may be the best course of action would be to pull it out of Shanghai but kind of commit on kind of actively discussing this over the next few weeks and then basically

making a decision on if we want to go ahead with V1 as is basically then bundle it with 4844 make the decisions basically quickly enough so we can bundle it with that would have to mean decision in within the next three months or so um and if we within that timeline basically are not comfortable with moving ahead then we can delay it further but basically shooting for the yes

Tim Beiko: yeah I will emphasize that I think if we don't want to delay withdrawal over this kind of like we decided like whether or not V1 goes into Shanghai as a decision we basically have to make today I think if we don't commit to that then

um it won't um and then we can figure out like what's the next step if we don't do that I guess I'd be curious to hear just like from the other client teams how you all feel about this I think uh GIF I'm not quite sure get uh Mario she had some comments in the chats that might as well I sort of stopped following but um yeah

Marius van der Wijden: so I think the guest team is kind of split on this uh I can only speak to my personal opinion um I feel kind of rushed um I think uh uh and I feel kind of pressured into making a decision on eof now and I don't think that's good

um so from what I've like I have also not been following the process as closely as I maybe should have um but uh from what I seen and heard there were like the spec was still changing or is still changing um and um the the testing is not there where we would like to have it and uh especially uh the fuzzing has found issues in in multiple different clients and usually we only find issues in like one or two and then it's yeah adjust the amount of issues and the

severity of issues uh are kind of a concern to me generally I think the splitting into eof1 and UF V2 is kind of a good idea but I I don't feel comfortable putting euf uh we want into Shanghai right now that's just my personal opinion and I think some people within the guest team might disagree

Tim Beiko: does anyone in Geth want to take the posing point of view

I

Lightclient: I don't think I like fully oppose that point of view I think that the reality is is that the timeline that we won for

Shanghai is going to have to be extended a bit to support getting eof testing into a place where people are comfortable making the upgrade how long that is I don't know I don't think it's like more than maybe one month's time but that still like brushes away the fact that we have these questions about code introspection and you know other small things that are irreversible and people generally feel rushed and I felt maybe one one and a half months ago that we by doing eof in Shanghai we were pushing ourselves a bit as like a Development Group but it was something that was like very much within our capacity

and now I feel like like we're kind of like reaching like what our capacity is to do so if the timeline for Shanghai is not extended then I don't think that eof is like that we can like responsibly ship this elf upgrade um it's yeah a question of whether it's important enough to talk about extending the Shanghai deadline a few weeks a month but if we're trying to do mainnet testnet upgrades in the beginning of February I don't think that we're going to be ready by then

anyone from nethermine or basically want to share oh God no

Danno Ferrin: so for me um the part where I thought is probably gonna slip is when we um worked with solidity and discuss the needs of them being able to attend their constructive parameters to the blobs um eof was designed to be sealed it's not designed to be extended at deploy time um so there are d2b design changes to support that we could do a hack and say that it can be extended for netcode only maybe we could enshrine that but I think that's going to take more testing and that that Discovery came fairly late in December so that's you know uh this whole issue of introspection um may or may not it did come up kind of late um I'm not sure if it's you know what's what's the harm of making the entire initial deploy block the data

block for it I think there's ways around it that don't involve necessarily introspecting it and shutting down the copy but as far as an actual practical usability the whole inability to append constructive parameters especially array types I think um is for me what warrants pushing it out to Cancun

okay

Tim Beiko: got it thank you uh Andrew

Andrew Ashikhmin: uh yeah I think that verifies my initial concern that we do need a kind of a production ready so that it's a compiler into eof so that we actually are sure that it's it works fine with uh with the list validity so

I'm currently thinking might be a good idea to delay eof to Cancun and make like proper solidity compilation a requirement

Tim Beiko: okay and then thank you and then uh Eamon from uh nevermind has also said uh you'd rather not have EOS uh included now and would rather push at the Cancun a thumbs up from Lucas so I think it's pretty clear that uh yeah not like not included in UF and Shanghai it seems to be the consensus uh so anyone like strongly disagree with that

so I think it seems like because there's all these proposals that are kind of floating around it's probably a bit early to make a decision about like if and what we include in Cancun I'd rather we at least wait like a call or two before deciding and also just like I think part of the the the kind of issue that arose with eof is like we made the decision to include it partially in Shanghai super early in the merge work and then people were kind of caught off guard that this had been sort of included really early on um so I think it would be good to like not make the same mistakes here so um yeah I you know we've got the next call we can decide to put it in Cancun but I

think it's good to have at least two more weeks for people to discuss all of this um and whether or not they should be coupled with with 4844 or uh yeah or or a separate Fork um I kind of saw you came off mute

Lightclient: yeah I mean I was just gonna say that if we already had pretty good agreement to try and do eof for Shanghai I think it would be okay to just try and you know still have pretty good agreement that we're going to try and do it for Cancun and of course like we can like make a call later on once we get closer and we realize like what the situation is but I would be curious if anyone like feels

strongly that they don't want to make a commitment that we're trying to do eof for Cancun because I don't want to get into the situation where we had with the eof I don't think that we would have been able to like realize these things about eof without having all of the clients teams implementing things and having as much momentum around eof having solidity like working on this implementation and if we don't commit to it again in the future then we're going to end up again the situation where we have just the Epsilon team working on it and then client teams look at it two months before they want to have it finalized and we like realize these things and solidity starts working on too much for and we realize these things

Tim Beiko: right uh mirrors that's how you had your hand up

Marius van der Wijden: uh

um yes I I really don't like to do this because I think uh uh Eunice will pass like kind of been pushing this EAP too hard um but with uof out of Shanghai I think we should uh consider 1153 to move to Shanghai it's uh it's kind of a small change and it might be possible to be add it to Shanghai

Tim Beiko: let's wait okay we can discuss that in like five ten minutes I just want to

make sure we wrap up eof property before um but sure we can discard yeah let's discuss that right after um I think just to come back on what Matt said um I I think I agree that's like the momentum and the client Focus has been really valuable and um we should keep like working on it as much as possible um I just would not like uh I I just would not want to like commit it to the like Fork schedule uh like right now but if I don't know if all the client teams feel strongly that we should get we can go ahead yeah I don't know if there's any more

thoughts on that

Lightclient: I feel relatively strongly that we should make the commitment but I'm I don't know I thought there's feel the opposite

Andrew Ashikhmin: um I think that uh we should uh um well my preference is still to split uh like not to try to reach athletic state of erf we can try it but I'm just afraid that too big a change would be good so it's been in my opinion it's better to move into into smaller steps but I I would I would commit erf to Cancun uh but with the requirement that

like we have a fully working solidity compiler into eof and that the solidity team is happy with it and everything works fine and if that's not ready by Cancun then well delay it even more

uh Ansgar

Ansgar Dietrichs: yeah just to say basically I do think it is important that we still kind of keep an open mind as to this whole kind of B1 V2 split and whether or not we would even want to do this I think I don't know I I thought executed good points on why it might be a good idea but like I think basically what we should commit on was just we should make sure that for Cancun us does not not get in because we are

not ready again like we should at least if we if we end up not including it it should be just because we decided that actually bundling everything into a combined B2 um is the sensible thing to do like um there's enough time between now and Cancun I think that that we should be able to fully explore and make that decision so I think that's the commitment we should make

Tim Beiko: okay uh and media so you have your hand up as well yeah I just wanted to have that I think it would be good to do some real world gas testing for eof um just to actually measure the benefits before forcing out V1 just to make sure that there's an actual reason to use V1 um and people won't just continue to use

Legacy code um and I'm actually working with Daniel from solidity to do that for V3 um so hopefully we have some numbers there got it

Alex Beregszaszi: uh and yeah Alex yeah I mean Daniel from solidity actually implemented the all of the eofvips and Grand benchmarks regarding gas and even without having optimization steps um which means you know deduplicating and optimizing everything even without that I was using less gas

Tim Beiko: okay I I feel like okay just to not also

spend the entire rest of the call on I think if you ever want to remove eof from Shanghai I don't think waiting an extra two weeks to make a specific decision for Cancun will like change anything or slow down the progress massively um I think you know it's clear that like client teams are working on this now and we should continue that um so I feel like we should kind of continue this conversation about like Cancun and V1 versus V2 on the next call but kind of leave it at that for today unless anyone feels there's anything else we didn't cover that's like really important that we should go over now um so I'll do that I'll do the change uh

in in the uh the spec uh right after this call the next thing okay so Marius what you brought up so if we do remove eof from Shanghai do we have the bandwidth to add anything else and if so what should we add um so after your comment mirrors there were a couple comments in the chat about we should probably just be removing stuff at this point um yeah so I guess I'd be just curious to hear from client teams like how they feel like does any client team feel strongly that we should add things or is everyone does everyone prefer only removing things uh at this point to keep the scope kind of in check

Danno Ferrin: uh Daniel

so the reason for for cutting it is we don't delay things for withdrawals and my concern is if we add anything that's something else that might delay withdrawals withdrawals is the driver of Shanghai so whatever decision we make should be done with the point of getting withdrawals out as soon as possible so based on that adding themes only adds risk

Tim Beiko: okay so if there's more basic supports for cutting only some get support for cutting only I don't know another mine are gone any strong opinions so this is about I think 1153 or yeah potentially 1153 but just generally

adding things at all

Łukasz Rozmej: yeah so if we want to add something we should have a fairly minimal impact 1153 might be in that minimal impact if every team like reviewed the code and the tests then it might be a minimal impact thing uh but otherwise probably we want we don't want to add it if it's not so it depends if like every team can spend a bit of time reviewing it

Tim Beiko: got it and air gun no strong opinion on 1153 fine either way

so it's okay it seems like 1163 is like the only one that could be considered is this something that we need to make a decision about today or would people be more comfortable like thinking about this in the next two weeks and potentially making the decision then

Lightclient: I feel like if we're targeting early February public test us we should make a decision now

Danno Ferrin: early February test that is aggressive any new ads I mean taking a eof is going to be enough risk um warranted risk but I think adding something else that has been part of previous test and answer structures um even if something as good as 11 53 is

is unnecessary risk in my opinion willing to be overridden but I still think it's unnecessary risk

Tim Beiko: okay and there's more comments from the other mind and uh in the chat as well so I think okay then let's just focus on removing eof from Shanghai keeping the scope uh tight so um yeah so we don't delay withdrawals I think uh I think that's pretty much it for Shanghai anything else on the fork that people wanted to discuss a couple other agenda items

um eap4844 I know there's been a couple Community calls I don't know if there's any updates that people wanted to to discuss okay nothing on uh 444 there'll be another call uh next week is where we can where we can discuss um there was a proposal uh by Eaton on the status team and to add extra retry routes uh in the execution payload header um I don't know if Ethan is on the call

Etan Kissling: yes I am

okay awesome

Etan Kissling: so the problem there is uh sort of related to Shanghai because it also affects withdrawals but um it's not strictly necessary to solve it with the work as well so it is about light clients they currently can follow a gossip topic to stay up to date with respect to the latest beacon block header from the consensus layer and we would like to extend that to also include the El block header so that you can follow that passive stream and then when you detect the block contains for example some logs that are relevant to

your wallet you can then request a proof hey give me the token transfer that it's related to that I have prepared a little graphic here that I shared in the chat and this PDF file um right now the issue is that to get that El block header the CL block does not contain all the data there are two fields in the El block header namely the transactions route and the withdrawals route that are hexary dry roots in the El block header but in the CL execution payload those hexary dry Roots they are just missing

because in the CL blocks ah thank you yes or sharing that um so yeah in the CL there is like the full transactions list and the full withdrawals list the transactions the individual transactions are still rlp while on withdrawals the actual withdrawals objects are actually also SSC that also means that they are stored in little Indian integers and in gigaway while in the El with trials route it's named the same but it's totally different it's big Indian and in way and it's a rlp encoding and then a hexary try route so

it's it's not the same data that we have here and when we want to do a proof for a transaction or a withdrawal this then leads to a problem that where the like client it only has the CL execution payload header from that gossip stream but when it wants to request a transactions proof from a yell then the El cannot give it that proof um yeah and the other problem is that there is no way to validate that the block cache within the execution payload header is correct right now as it's used not really a problem because we sort of

trust the sync committee to only sign valid execution payload headers but um you know if you just have the headers want to validate them uh this feels like a bug to me if it's possible to fix in Shanghai sure for the transactions like this is the first approach um can we sort of make it so that um that we use the same format everywhere so for the transactions and the withdrawals that are currently stored on the CL as well can we just use the same route on the El side that would mean adding support for the SSC format to the El I'm not sure how

the problem that is right now the wrist is nice wall where everything on the El side is rlp and hexary and everything on the CL side is SSC um but yeah like if we can get it done to add this SSC library to the El then this would essentially eliminate everything just single format for the C for the same data um if we can do that then we essentially need to find a way to get those additional hex routes from the CL servers to the clients and the way that I have here is

essentially that the cl could recompute them from the CL block because it knows all the transactions and withdrawals but that would mean like adding all that Legacy code for rlp hexary tries and the ksr cache to the CLS which is kinda backwards in where we want to go as far as I know the ssce format is considered to be more modern um if there is a implementation that absolutely cannot do that it could also request the El block header via the engine API or the execution API it's the same bus but that would then compete with the bus that is

also used for validator duties so it may interfere with actual real critical operations I'm not sure how well that could be supported the next slide basically avoids having to compute those on the CL by just extending the execution payload that we get from the engine API to also include those hexary routes um SSC history route of the transactions is just a simple binary tree yes it is just a simple binary tree and also as far as I know um those hexary dry Roots they are not

exposed to the evm so there is nothing in the evm unless like someone re-implements it like has their own transaction proof system um but I think right now there is no way to extract the transactions route from from a smart contract but anyhow um yeah this like this slide here basically extends extends the execution payload the execution payload header it's an additional storage of 160 megabytes per year maybe not that big of a problem anymore with the 4444 history pruning that avoids adding libraries to the CL

and this final slide says that we just ignore those two values at all like the like instead of trying to get those transactions hex root and withdrawals hex root we just have those four minimal items the parent hash State root block number and block hash we give it to the El and the El then issues another Network request to obtain the El block header based on then if it needs it and then this this this sort of solves the problem of having this mismatch but it also means that to operate on the transactions and withdrawals you need to request actively

those additional fields from the server again so it adds load to the server and it also means that you can no longer passively just follow the gossip to keep track of the latest text and El block so yeah I mean this this this uh is probably the quickest to do without too much changes actually no changes at all but it also just um is the least flexible and there is this eip4788 that will add the consensus layer state route to the El

block header so in theory be possible to just uh paste transactions and withdrawal proofs on that one but they would need to be served by ACL and no longer a Neo so you have this situation where for some data you need to ask an ear for a proof and for some other data you need to ask ACL for a proof because the El doesn't know the entire Beacon state it cannot create such a proof for a transaction there may also be split block storage where the transaction is simply no longer there on the CL yeah and also this this same issue reappears every time we add a new array so transactions and withdrawals are the

current two arrays that have this problem but every time we add a new array we have the same problem again so yeah that's what I wanted to bring up and I mean the main question is can we just transition those arrays to a SSC root in the El like is that something where there is like a risk or a pushback or

Micah Zoltu: I think the risk and pushback you're gonna get from that is that external tooling might depend on that so I need any tools that actually try to validate

a block for example that aren't clients will all have to be fixed and changed to deal with it and that includes on-chain contracts that do block validation will break yes

Etan Kissling: I mean that's true for the transactions but um I mean the transactions they could be sort of solved as a one-off work around by just adding it to the payload as well but um I mean this is more about the new stuff the withdrawals anything in the future that could be an array and enter receipts route actually it is a MPT like it is a hex retry in both the

CL and DL so that one is already consistent the reciprocute would still be worth changing to our street roots I need layer 2 that wants to like access messages from a layer one which these receipts um so making it easier to verify would be a big win also like messaging between different layer twos any evm chain really that emits an event the defense could be ingested by another evm chain if the proof was just simple to verify yeah so there is this spectrum of only

changing the new stuff like only the withdrawals and the new arrays or also the transactions route because then we have all the fields covered where there is the inconsistency or even more than or also just nothing at all so there is this entire scope and I'm not sure which of the approaches we should follow on

Tim Beiko: um just because we're almost at time and we have other things does it make sense to just move the conversation um to just move the conversation for this uh on the issue uh Marist we can go

over you and then yeah wrap up on this

Marius van der Wijden: yeah so I think we need some more time with the eldest to to discuss this offline but uh yeah so I don't think we can make a decision on it now um and it's also not that important I think to make a decision on it now we can change it in next two weeks maybe yeah

doesn't that

Micah Zoltu: kind of go go against the previous statement we made which is we need to make decisions for what's in Shanghai today because by next week we're too late to make decision for

chiangai

Marius van der Wijden: yeah but that change doesn't really make like it only changes the the block format it doesn't change anything within the evm or anything

Micah Zoltu: not not our clients correct them wrong not all clients have X not all execution clients have SSD capabilities yet do they

Marius van der Wijden: we don't

Micah Zoltu: so right that feels like a potentially a significant delay

I don't know how much so

Łukasz Rozmej: for another mind uh we don't have uh so we didn't have a z implementation but Alexis is working on something on EAP 4844 so that might be reasonable

but generally there isn't an ssd.net

implementation I don't know

Andrew Ashikhmin: I feel like it is an important question and we shouldn't delay it we will I mean we can discuss it offline but um because it pertains to Shanghai it's and it is it is a design decision it's quite urgent to my mind

Tim Beiko: so how about um like yes I think it makes sense your client teams to think about this offline and we can use the issue to discuss we can put it on the agenda also for the CL call next week because it's also kind of relevant to them um and at the very latest have a decision uh on the next cell cordells for this does that make sense

Andrew Ashikhmin: um yeah yeah but uh like to my mind it's like because um it is a design problem uh I would uh prioritize it and try to fix it properly rather than uh be left with uh some technical

debts right with the rolls-root yeah one a note for has it done execution layered apps you don't really need to implement a generic SSD if you only Implement for these types it's much easier

Etan Kissling: okay yeah like you need to withdrawal

object and then you need those um list of byte data basically that is the only support that you need the transactions they they are still rlp it's just the actual tree of transactions and the full withdrawals and their tree that needs yeah that that would need to change

dapplion: and the AP code is 4 already includes uh manual SSD manipulation anyway

Tim Beiko: okay so yeah let's um let's discuss let's like El teams if you

can look at this like pretty soon and then uh we'll make sure to add it on the agenda for next week's CL call and and hopefully have a decision before the next awkward as put up the latest make make a call then okay we have six minutes left and like two eips that people wanted to briefly introduce so um let's try and take like three or four minutes on each of those and then we'll wrap up um first uh Jared you had eip5843 you want to chat about are you here Jared okay if not then Abdel you had an EIP uh

EIP at 5988 are you still here

yes yes okay so let's do a 5988. yeah I will be short um so basically the idea of the gis VIP is to introduce a new free compile um which is a Jose Poseidon pre-compile so Poseidon is a ZK friendly hash function

um so basically uh it is it works with a set of permutation overall point field and it makes it a very uh well efficient for in uh in ZK context and it would enable basically a bunch of interesting uh music use cases uh obviously for for

Layer Two and specifically ZK and validity Roll-Ups but not only um what kind of use cases can enable so first you can use it as a an efficient and cheap ways of doing some kind of data availability solution with using Poseidon hash commitments uh so obviously it's not as efficient of as a but still it is an alternative solution for a cheaper data availability using this new search function can use it as a as a the main function for the state commitment of their uh of

the the state of their Roll-Ups uh it can also be used for uh escape hatch uh basically each time we want to prove a storage proof like American proof it's very uh expensive on ethereum because we don't have any uh ZK friendly hash function so let's say for example you want to implement an SK patch system where if the system is frozen and you want to let the possibility to users to to restore their phones on the layer one then you can use the system to implement an escape hatch system this is what we plan to do for startnet and scroll is also planning to to use it for their exit Game mechanism

and also maybe in the long term we can use it uh for ethereum itself like having the ability to prove ethereum history inside ethereum so this would be particularly uh useful for storage proofs and and like clients and also a lot of use cases so this is for the potential use cases are also uh some some interesting use cases on the top layer on on the top level but uh mainly this is interesting for a roll-up operators uh one important design concern is about how generic can be this is the main problem of the pre-compile

because it is possible you can use it with a multiple parameters and many different actors that are using different parameters so we we have multiple options so either we can Implement only a set of known instances and add new instances with hard Forks or we can try to make something generic anyway this is a one thing to consider another important aspect is the security because those arithmetic hash functions are pretty new so this is also something to consider so Vitality describe a bit this thing in the kcg alternative article reward a month ago or something

like that in terms of implementation we already have a c assembly implementation for x86 architecture we also started the rest implementation so there are already some implementation that exists like for example the ficon one and others but there are not generic enough to fit for with all the possible instances um so yes there is a genericity aspect a security aspect and yeah that's pretty much it to be short so we have only one minute left so I will stop there

Tim Beiko: thank you um yeah Dan Craig you've had your hand up I think we could do your comment and wrap up

Dankrad Feist: yeah

make sure to comments so I would generally say as Sophia it's a bit early to enshrine any arithmetic hash function in the evm because of you what you mentioned by the security concerns and we just don't know enough about them yet um so I I would generally feel this premature at this point

Tim Beiko: um and then there's the East magicians thread linked to the EIP for people to discuss this further yep anything else before we wrap up okay and I guess yeah people want to check out uh Jared's EIP async uh it has to do with evm modular arithmetics

um uh which was proposed a while back uh as evm 384 um so I just posted the link for that uh in in the chat as well um yeah I guess that's it uh thanks everyone for coming on and see you all on this week's CL

call thank you bye thank you very much thank you thanks bye bye bye thank you bye have a great one right

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