All Core Devs - Execution #179

Transcript

[Music] e

Tim Beiko: and we are live uh welcome everyone to

acde 179 we have a lot of stuff today hopefully we can get through it um but first we'll talk about Denon uh obviously go back on how Gordy went um and then there's a couple small um changes so um are at these items to discuss so some things around uh Jason RPC uh some uh things around 4788 uh Shia linked the new CL release PR and then uh making sure we're still on the same page about timing for next test Nets uh once we have that done uh then there's a bunch

of discussion around the next Fork Prague Electra uh there were a couple specific eips that people wanted to discuss so we can cover those and then I think it makes sense to hear from all the different teams uh what they think about the upgrade as a whole and what uh uh people's like priorities are um and then lastly on the next upgrade uh the veral folks want to do kind of a deep dive uh on the next acde and one thing that would be helpful is collecting feedback today on like what people want to see and discuss so that they can best prepare for it um and then at the end hopefully we have time for this but there was a Basu uh main net incident uh that uh we'd like

to discuss briefly um so I guess to get us started I don't know uh Perry or Barnabas do we do have you want to start with like a high level Gordy recap and then if any client teams want to chime in we can do that as well

Parithosh Jayanthi: yeah I can go um so we had the girly four yesterday around 6:30 UTC and immediately after the fork we saw that there were uh there was a drop in participation I think we went down all the way to about 40% and on triing uh we narrow it down to uh one client being offline due to a failed upgrade and one uh client issue itself the client issue was hot fixed

soon and I think someone from the prison team can talk more about um that and once the hot was applied the network did exceed 70 is% um participation rates and then we were seeing finality uh during the non-f finalizing period we did submit some blobs they made it through perfectly fine and post finality we started blob spamming as well that went on for about sevenish hours and based on that we've written an initial analysis um that should showcase how um how the blobs FedEd in terms of uh propagation time and what what uh effect they had on blocks themselves uh besides that overnight we didn't run any other

block blob tests uh but we started the spammer again today morning

I

Tim Beiko: thanks um yeah is anyone from Prism on

Terence Tsao: yeah hello hi yeah I can give a um brief outd on what we're run yeah so what happened was that like from prison upgrade from capella to D State we kept the historical route empty instead of carrying it over so this issue was like fairly easy to fund we we basically patched it the first few hours and then we released a high image and then I

believe um the capella State sorry I believe the denet was finalized about at 2 amm Pacific time so about like four hours after so just give a little background right so he's tal rout is this lery field it's essentially Frozen at capella it was used before capella so it was the old field and then what you didn't get like surface before the previous death net or Shadow for was that we need to run enough um before we essentially need to run enough at the previous for to essentially have it as nonzero and then this is only updated for every like 24 hours so say today if you start from bellat trips and you hard

for to Capella less than 24 hour if the time is less than 24 hour this is going be zero so that's essentially what happen before that's why we didn't catch it and then spat has also didn't catch it so we immediately surface that to shway and Sh and the things for shway there's a PR on that so entally SP test will cover that so this is just one of those very rare as cases uh thank for for prority um otherwise we probably wouldn't have C until later

Tim Beiko: got it thanks and yeah I guess this is also something we can uh not only catch in the spec test but when we run Dev Nets we could um explicitly have like a fork happen you know once the uh sort of

far enough from the previous one to to allow

Danny Ryan: um yeah or or or the Genesis State can just have a value in that field because always will have values in that field and so Genesis States on our Deb Nets just might as well um but yeah it it was a failure this should be caught way Upstream um and just kind of the the weirdness of the deprecation of that and not thinking through the fork boundary test um all the way we didn't have one in the consensus spec test so um that is there as of the release that'll go live right after this call um and we can spend some time making sure there's nothing else funky on Fork

boundary tests although gorle probably would have anything else like that

Tim Beiko: got it um I think this was the only sort of uh major client issue that we saw on Gordy but do any other client team want to share anything notable or interesting that they saw uh during the fork

Terence Tsao: I had one issue that I surfed it's also minor that like pris are um seen client team so this is consensus so so like kind of apologize bringing here so

like PR I seeing client team requesting um blocks sorry blobs for every index no matter what so say today if you have a block that doesn't have any Cas commitment we're getting requests for the block and it's slightly wasteful I would say so yeah I've service I think like I think it was um I don't want to point name but I think it was a te or something like that that was doing that so yeah so I think te team is aware of that

Enrico Del Fante: yeah so we do in some cases uh request blobs um uh but it should not happen in in in in that case specifically so I'm just double

checking later today but I think in in in in the case of the block has zero commitment we should not do that so I suspect there should be something some other Pier or something running over the network that does that but I'll double check any case because we do something similar

Tim Beiko: awesome thanks and I suspect this would be an easy fix once you identify it and to discriminate based on the commitment yeah um any other comments Thoughts by client team

Parithosh Jayanthi: seems one thing I did want to ask was right now we're um artificially spamming gly with blobs and

everything's kind of being submitted to the same set of noes so the propagation statistics will also look as if they've been submitted to the same set of nodes uh we tried stopping for a bit this is not much Native blob traffic on girly um it would be really nice to know when l tool start a plan using it and when we should stop spamming it

Danny Ryan: do we expect l2s to use uh the Gorly blobs um given the deprecation or are they going to focus on another

test net

Terence Tsao: I don't want to speak for arit strong but um but I work fairly close to

them I don't think they will um use Cory so the likely test n the most likely one will be supposedly after them

Tim Beiko: and if not l2's um yeah I don't know if there's another group that we could get to like spam Gordy and and hit a different set of nodes um I guess if you're listening to this and looking for something oh

proo

Protolambda: yeah so we are looking at uh t gery starting with U layer two death nut once we go past like

internal death Network only then we can go to like more production test Nets and then you know like towards the devopment of uh you know final stretch for man testing now spamming blobs yes we can generate some traffic on a death n without argue that not to get real testing we want to update the public layer to test Nots and may take some time

Tim Beiko: do you have a feel for like how long um it would take you

Protolambda: so we consider our test Nets as a

more production environment where users deps rely on ability of these networks and it's the choice to go and update the death net first yeah this means that we aim for one or two weeks of testing on death nut before we go and try any uh updates on

dut

Tim Beiko: got it so it's like at the earliest it would probably take another month uh for Gordy to be updated

Protolambda: it's at least a few wecks away yeah yeah like the other timeline that's

interesting here is how much a layer two should um should take for the public Tes nuts and how much the layer one here accommodates since a stable air on target here is important for there are to um governance and for upgrades that you know do do not rush a a proof change or a a change that you know affects the ler two security so the longer running the roll out period is of ler to the more

important is to have sufficient L on test time to PR be for a

minute gr

Tim Beiko: and I guess do we see a risk that um 4844 is somehow inadequate for l2s like obviously you can imagine it being on Main net for like months before you know and L2 chooses to use it there's that's probably fine but um like I guess yeah what's like the minimum amount of confirmation we want um that this is quote unquote usable and uh do we sort of already have that um

because I know there were some

Protolambda: uh in terms of capacity I think very very close what I'm more concerned with is tooling infrastructure around blocks many RPC providers for example they serve the Json RPC but not the beacon layer RPC and so a lot of infrastructure that has been built around layer twos um realize on the jrpc but not on this new HTTP and it serves the actual block data so there's there's more in to to updates on the outside of the

layb right

Tim Beiko: and I guess you know that's uh I would definitely not block L1

unlike the ecosystem adopting um because they can add support for it whenever but I guess my question is more like is there something about the consensus change itself um where we feel like we'd need additional validation from l2s or some other like stakeholder before moving to main net or should we try and keep moving towards main net as you know quickly or efficiently as we can and then it's I guess yeah it's better I think to be in a spot where like it's on Main net and people just have to adopt it in a spot where like it's not live because we're waiting on some external dependency um but yeah I want to be sure that's

like a reasonable assumption and there's not something on the L2 side that's like we may be missing um yeah um and Ansgar has a comment in the chat uh that there's an 4844 L2 Readiness roll call next Wednesday um so that they'll bring that up there as well and they can report back on Thursday's ACDC uh so we should probably discuss that uh further there but yeah I guess for now does anyone see like we should get l2s to test this uh as as quickly as possible and so if

optimism can do it on gordi in the next couple weeks that's great great um once the defet has been done uh if for arbitrum we're waiting on sepolia then we should probably get sepolia uh upgraded and then if there's other l2s uh now on this call listening um yeah if someone wants to start G testing gordi sooner um that's probably just some valuable data for us to to obtain

Parithosh Jayanthi: okay so my takeaway from that would be that we continue spamming but rather than a target of six we'll just have a target of three so that if someone else wants to join in then they're not priced

out

Tim Beiko: yeah that makes sense

Parithosh Jayanthi: okay and uh just one more thing I do want to mention um these are alpha numbers and we kind of want to know what client teams are looking for so that we can start customizing these sort of analysis like every week or something from the data from the last week um right now it looks like in the average case blobs are proper ated on network under the 2C Mark um there are some P95 values at the 4 5 Second mark But in general attestation deadlines seem to be hit and um it doesn't matter how many blobs we have it looks like block propagation not affected which is good news and yeah in general all the numbers

look quite good so far so yeah I guess the question is what what else do we want to collect from here is something missing there's a question just so P's message the builders being used regularly on girly as well we have M boost enabled in at least all of our validators uh we haven't tried sending blobs directly through them but they have been gossiped bya um bya our notes but we can try sending

it directly to the

Tim Beiko: oh okay and there's a comment saying flash Bots has delivered uh some payloads with blobs nice okay any other thoughts from client teams or others about gordi specifically

Barnabas Busa: very very quickly after the

non-f finality was over

Tim Beiko: oh nice um anything else okay uh so next up uh we had this uh Json RPC discussion a few weeks ago on the testing call about adding BL adding blob gas prices to uh the a few Json RPC methods um we were hoping to have more discussion on it but it does seem pretty stale I guess uh yeah I I like Cent your last person

who's commented um do you think we should go ahead and merge this does this need more input um this feels like something that would be nice to have obviously before main net and potentially um before one of the next test Nets uh so that we can expose The Blob based

F jrpc

Lightclient: yeah um I think for one thing we had this PR to 44 four one and a half weeks ago trying to rename uh gas price to base fee with respect to blobs and I think we probably want to move forward with that and so if we do that that's

going to change the name of the RPC method from blob gas price to blob base fee so that needs to be updated but in general this seems like something that we need to be doing I'm just flying a little blind because I'm not sure who the consumers of these things are and they're not really stipping up to say like this is what we would like this to look like so I'm kind of just following what has existed in the past and moving in the same direction um with the The Blob fees but you know for instance I don't remember if this was the testing call or the last call but Roberto was saying for them they're just calculated the blob Bas fee using the previous header so people are kind of getting around it so

the question is like if people are getting arounded do we need to expose this RPC method I'm not sure it seems like the right thing to do but I'm I'm just waiting for someone to say like I this what we want

so

Tim Beiko: so assuming we go ahead and and merge that PR with a name change on 4844 then like we we change those names um maybe like somebody to ask I know Ryan from infer has been in the Discord uh following a lot of these Dev Nets so like infura might be a good uh basically consumer of this um if anybody else has thoughts uh it's PR 486 in the execution

API repo um is there anyone who like yes sorry go

ahead

Lightclient: oh sorry I was just going to agree with you and I was wanting to know if anyone was opposed to 8095 the changing the name from gas price to base fee cuz I'll just merge that in the next hour if not great

Tim Beiko: okay so um yeah let's uh merge the pr to 444 and then maybe like do one last p on the Discord and explicitly tag ran about uh the Json RPC one and assuming there's

no objection we merge that one um as soon as it's updated with the new the new names sweet and then um okay next up

uh so there was a comment by Andrew about deploying the 4788 contract uh on all the other networks um so we deployed it on hosy and sepolia this week and we weren't sure if it makes sense to deploy the 4788 contract on mainnet now or if

we'd rather wait uh to uh see the other test Nets Fork uh before we do that um I don't know if anyone has thoughts about this

Danny Ryan: given deploy address is a function of the code um I think it's fine to deploy now now and might as well deploy now meaning in the event that there is some last minute change to that code um due to functionality change or bug or something it would deploy to a different address so we don't like shoot ourselves in the foot by already having something there so given the manual deploy I'd say well top of mine just do

it

Tim Beiko: okay um does anyone want to volunteer to deploy um I will refund your gas cost if you do uh so I guess if first person who goes ahead and deploys it uh can post in the aord dev's channel um the transaction hash um but yeah let's try um yes Mario uh I'll I'll send back the gas cost of the first transaction someone who deploys it um and posts it in awward

devs um I will not double it though

um sweet uh next up uh Shia posted this uh in the chat but there is a new CL release being cut that I don't know if Shia or is on the call or otherwise Danny any thoughts comments on that

Danny Ryan: this was expected to go out Monday um it did not and then the the issue on gorle came out so we got in additional test vectors and now it is immediately ready to go out after this call um it

has the fork Choice filter change it has um a number of other minor things which are not really substantive with respect to this and it has the additional test um the intention would be that this is the target going forward um with the fork Choice filter change being the main thing to have to accomplish um but also knowing that if on the next test net you don't have that done uh except in pretty crazy exceptional scenarios you won't diverge this has been discussed quite a bit on call so I don't think there's any

additional context or discussion needed

Tim Beiko: got it okay um so I think those were all the sort of outstanding items around

um Denon um in terms of timing so on the last acde last year we'd set the schedule for all three test Nets uh Gordy's are already done sepolia is currently scheduled for January 30th and then hsky is scheduled a week after that for February 7th um our plan was to have a single client release for both those test Nets um so that users can just

download it once and be ready on both chains and we only have to have like one sort of recycle one announcement and so on if we uh want to stick to that um and give people at least a week to upgrade on sepolia it means we'd have to have client releases and the announcement out sometime around like Tuesday next week um does this feel realistic for all client teams um does anyone have a problem with that schedule or should we yeah keep moving forward and uh announce sepolia and hos key around Tuesday of next week okay take who saying it's

okay yeah and no one objecting so I'll take that as a as a sign that we're good as some plus one from nether mine um okay last call otherwise uh yeah otherwise we'll move forward and obviously if we see something go terribly wrong on sepolia we can always cancel the whole ski Fork um but yeah I think for this will simplify things a bit for users to have both um so great okay let's stick to it uh all the numbers are in EIP 7569 um so the epac on sepolia is 13268 Epoch on host SK is

29696 and then the corresponding time stamps are linked in that table um anything else on denune at all okay um sweet

Tim Beiko: then moving on to the next Fork prag Electra um so I I compiled all the proposals um earlier this week that at least had been uh put up so far um there's three of them that specifically or three people that asked to talk about four things specifically today so I think it probably makes sense to go

through those uh first and then hear from all the client teams uh what they're thinking in terms of uh prioritization um both in terms of specific eips but also this uh higher level conversation around uh where veral fits in and and you know how we potentially want to approach the next two forks rather than just the next e Fork um so yeah to kick it off we have I I don't know if Fubar is uh on the call um hey yeah am yes yes okay so I'll post your uh upgrade your update in the chat but yeah take it away about 374 awesome um does screen share work for presentation or okay let me

get that going okay perfect yeah we see can you see this awesome and I'll here I'll send the I'll just dive into it um so yeah hey great to great to meet you everyone I'm hubar may have seen me on Twitter first time kind of touching the core core Dev stuff so appreciate you bearing with me um have done a lot of sorry your presentation is like stuck at loading so I don't know if you maybe it's like in another screen or something on your yeah I'll just let me um I'll just share entire screen and see if that

works um all right how's that uh it's loading on my end let's see if it loads um still still nothing no okay okay I'll just does this work uh still loading let me yeah let me try to kick you off and see if I can uh that's okay I can also just shoot the link here and things not as okay some people are seeing it so yeah maybe just shoot the link in the chat in parallel and uh it might uploading on

mine okay I think yeah I think we're getting there so awesome all right we'll we'll we'll share and can all right we got the links perfect so yeah key key high level thing is I think there's I think there's a massive opportunity for um a core ux level upgrade that both increases evm dominance relevance and um saves literal hundreds of millions of dollars for users at the same time um I wrote up a more in-depth article here that you can dive into but the the key idea is that batch transactions for eoas add a whole swwa of benefits um they fix stale approval attacks which have taken

100 million plus from retail including three separate attacks in the last month um they reduced a lot of developer overheads speaking from personal experience of people not having to embed quirky native multic calls within their protocols also reduces it's a bit of free lunch on the state grow side of things currently you've got all this overhead for mempool propagation signature verification for sequential transactions when really you just want kind of one one signature across the whole thing um so able able to get more more actions more chain usage without any additional client node burdens and also able to remove some of the

assumptions we've got on trusted intermediary like private relays and whatnot um so yeah the key most of this is just focused on the on the user and Dev experience side but do have a bit at the end where we can dive into the specific eips although I think there are people more skilled than me to to discuss that um so quick example on on stale approvals and how that goes that goes bad I think that the approval pattern in ethereum is good for some things but has been overused and gotten a lot of people wrecked as the result so for something like a long-standing openc ask I want to sell this NFD for one e that's a good usage of approvals for

something like I just want to put my asset into a protocol like I want to swap tether for East on Unis swap then it's not actually desirable on the app side or the user side to have to constantly be having to do this this this approval um for to be stale left open a lot of apps have this dangerous infinite approval pattern and we've seen this get exploited time and time again uh just last 30 days for example you had the nft trader exploit two-year-old contract several million dollars worth of assets drained um because not because they were actively participating in the exploit just because they had done an action two years ago and forgotten slash

didn't have the bandwidth to revoke same thing with floor protocol um and then just yesterday or two days ago uh Bridge you had a lot of people get their assets drained from stale approvals on a bridge and these are I picked recent relevant ones but these are things that happen over and over again um and so these These are frankly all fixed with a bat transaction pattern so I think that there's a lot of user leakage and like ethereum experience Improvement that can happen from that um huge on on protocol ux side I know that natively enshrining multic call is something that can be done most people don't know how to do it

in my work on audits you kind of have to manually push people to get it there I think coalescing around A single standard for the entire space makes a much better devx um yeah state state growth as we said you've got fewer transactions floating around than the men pool um for for the same level of actions L less overhead from sequential transactions that really do want to be next to each other um and I think uh something that's not maybe well understood as without diving into this is you actually get better 1559 esque like gas volatility spreading because if a user is trying to do multiple actions

in a row like approve swap Deposit they can't leave their computer until that final transaction is going out into the the world um so they often have to overpay on the first ones they overpay on approve they overpay on Swap just so they can um Express their actual gas preference on that last bit so I think there's I think there's a bit of spreading if you could batch three-ish transactions send it at the men pool for a couple hours and sit it there um then you get better better better queuing on that front and better State growth so and then of course there's the risk of intermediaries private relays unbundling

things either maliciously or accidentally I think this makes the relaying space a lot more open and permissionless because there's less need to rely on reputation as collateral um so and trying batch transactions there removes it basically so my my strong opinion is that batch transactions for eoas in some form need to ship in the next hard for work massive massive upgrade on security on ux on state growth on demand limiting on kind of obscure even obscure things like private relay trust vectors and seems like the two key two key eips are 3074 from light clients who's been amazingly helpful in

talking through a lot of this and also a Slimmer simpler but less less fleshed out 5806 um two approaches here I think I think most people on the call are are familiar with O and off call you essentially provide an ecdsa signature to a trusted invoker much like a 4337 um Singleton entry point and and then that invoker can execute code on your behalf the E we is done a lot of great work on this and thought through how to thought through thought through how to mitigate some of the security vectors by signing each each specific call I think that's also an interesting

approach and then 5806 is a just kind of very simple no invokers just a new transaction type that lets EA's delegate call any contract directly and execute that delegate call code within its own context so um obviously these are all exclusive but I think that one I I think that one of them needs to get shipped and upgrade the whole EA experience um so that's a very yeah that's those are those are my thoughts from both an from a user perspective massive security upgrade from a from an app developer

perspective massive ux upgrade and I think it adds some benefits to the core chain the core chain consensus mechanism as well so those are my thoughts thanks for sharing um any questions on the presentations or write up from anyone on the call

uh ancar

Ansgar Dietrichs: yeah I mean first of all of course great great presentation um I just wanted to say that from my point of view kind of looking at specifically the those those three kind of potential e

paths proposed um two comments I would have first of all I think those three specifically are all relatively heavy-handed um I think um first of all like the the the the alternative proposal by by Yu is is an alternative to 3074 I think that that just has has been underere explored I don't I don't personally think that that makes a lot of sense um and then the other one the HIDs while well I think it's interesting also to think that like the like people have talked a lot about delegate call you accounts directly and it runs into similar issues so I think out of those three probably 3074 is the most realistic but as we talked about for the last two years already regarding the AP

it's very heavy-handed so I'm not sure if if it's a good good good fit for main so I think the most realistic if if there is a strong need for for B banding I would say the most realistic here would be to have a more new EIP or reuse one of the the older ones that was very limited in scope just to to B to the banding use case specifically um so that's comment one we I think a narrow e here would make more sense and then comment two would be that I personally philosophically think that for a lot of these more user focused improvements to the evm we should try and more and more kind of leave this initial experimentation with new features like this two layer twos that are more Nimble and shipping anyway and now that we we're starting to see with roll call

kind of like a standardization process around eips or EIP um equivalents on on the layer two side I think person personally philosophically I would much rather see these kind of things shipped on layer twos um and then later brought to mainnet but those are my two comments yeah that's that's helpful I guess to to to respond to the first definitely my my desire is some form of thing get Shi so if there's a way to to to slim things down use the learnings of the past two years it all sounds very interesting on the second comment uh push all the Innovation out to the l2s I think that's a good long-term plan um and works works quite well on things

like new cryptography pre-compile but for things where there's a high coordination cost um good good batch transactions require three actors to all coordinate you need the core consent you need the core chain to support it you also need the wallets to support it you also need the apps to be able to push this I'm not sure that the fragmented approach apprach gets the job done um and I do think that in terms of how do you how do how do you how do you spread the evm how do you make this a good default experience there is some room for real winning pushes still from the coral one itself

Qui

Justin Florentine: question follow on ansar's

point though so you said that the three actors that you kind of need to coordinate one of them being the L1 why would the L2 sequencing their own transaction serve as a substitute um so yeah if you if you rely on centralized sequencer then you can you you get some of the benefits of like unlikely unlikely to unbundle for example but the user still has to sign multiple sequential transactions and so on you kind of you train people to click click click instead of carefully inspecting things and you just you replaced the role of the trusted private relay bundler with the trusted centralized sequencer um and it's not super

robust

Tim Beiko: uh William

William Morriss: uh yes I just wanted to comment that I don't think layer 2 should be treated like a feature test net the developers making layer twos care a lot about compatibility with main net and if they deployed a feature that had a tentative specification then when it finally comes to main net even if it has the same op code number there might be differences in behavior and those would be technical debt for them so they aren't especially interested in doing that role for us usually that's all

Tim Beiko: right um okay so

I yeah I I think we can probably discuss that on like the L2 call whether or not you know we'd want this um in its current form um yeah like you know this in its current form or potentially a tweak of it to be deployed on l2s versus l1s um and yeah okay I'm just reading George's comment um yeah is there like a clear next step or uh yeah that people would yeah would would want to provide here I mean this is this is an Outsiders

perspective but it seems like it it seems like maybe some of the confusion comes from two separate questions being jumbled the first question being like are eoa batch transactions desirable and then the second one being what's what's what's the right implementation for that and you you've got I think a lot of fragmented views on the second bit but less less Clarity on the first one so it maybe that's the key thing to answer first yeah and I don't know if anyone has yeah an answer right now at the top of your head um oh

yeah

Amad

Ahmad Bitar: yeah um so looking at the other solution that Fubar uh uh talked about seems to be harder to secure than the current implementation of 3074 as uh you can't really uh uh parse a delegate call uh uh easily uh when it comes inside the uh wallet uh whereas with 3074 you can parse the C data the address the amount of gas being used the ethereum you're going to pay Etc so it's it's easier to uh reason about for a wallet to implement something for the user to

actually look at when uh when they're signing this transaction um uh then give uh now looking into the L2 perspective my personal opinion uh is that uh I agree with uh William uh l2s are not going to introduce uh uh this uh EIP unless there is some kind of commitment that uh this EIP will uh eventually land in on on in main net as as as it is uh spec without uh uh any changes uh uh and and that that's just my personal

opinion

Tim Beiko: thanks uh Andrew

Andrew Ashikhmin: um so I think we like there was a concern uh from Aragon team members about the original if 3074 that the uh authorization is not revocable so we are opposed to the the that version of 3074 but the other ver question by of why Vice where the permission are revocable or like EP 586 seem to be more reasonable

Lightclient: to be clear 3074 is now revocable as of about one month ago we

added the nons to the authorization message so when that non is passed the um the authorization is no longer uh eligible to be

offall

Andrew Ashikhmin: oh I see

Danno Ferrin: I would call that expirable not revocable because you said an expiration revocable is like I changed my mind and nothing changes but it's revoked

so it is improv

Lightclient: we don't have to nitpick the exact definition here

Danno Ferrin: I would not call it revocable however

Lightclient: okay I I disagree

Tim Beiko: and Ben

you have

Ben Adams: uh in answer to F Bar's first question on whether batch transactions from the users are desirable I'd say um definitely because

it's not having them means we have some pretty weird uh ux patterns um that generally end up being quite unsafe and as he mentioned um you then end up where you know if you've got to do three four transactions for just to do one action you're sort of training users to blindly go yep yep yep yep in the wallet and then they go to a fishing site and they got multiple uh transactions coming through and they go yep yep you know and they fall into this bad pattern and also I think it's important

to note that there's um in in the absence of batch transactions apps have developed even more unsafe approaches I'd say the status quo today is something like a cport order that can um it's not even a transaction it's an EIP 712 typed arbitrarily nested array that gets people wiped 50 Apes at a time and it's it's not even simulatable you've got the same issues with things like a single malicious permit 2 signature can then take all the assets you've approved in Unis swap so what what enshrining batch transactions and the protocol does it doesn't introduce new security risks

it moves it from these opaque 712 non non simulatable messages into actual simulation core um into things that wallets can simulate so batch transactions are already here in an unsafe way the question is can you improve them and inine them so that we're not stuck in a blur SL permit 2 world forever yeah follow up on that the way you do an offchain signature which was sort of like a an intermediary solution um that that's like a very dangerous pattern and it's offchain and

it lives there forever and somebody could just insert the your signature um at a later dat that they're choosing which has caused a bunch of hacks as well

Tim Beiko: um just uh yeah to be mindful of time um um so I think yeah this definitely provides context to a lot of the L1 teams um and also I think shows that uh maybe some of them aren't uh up to speed on like the latest designs for this stuff um so obviously there's like the three IPS that people can review um I think in terms of next steps uh one like now you know L1 teams can figure

out uh how they feel about 3074 or one of the uh other Alternatives um and you know whether we want to move forward with something like that in the next Fork uh two I think there is a discussion to be had on the L2 side about whether or not we'd want to implement 374 or again some uh version of it first there um and you know Anar has a comment around how they are trying to figure out the right framework to do that um I guess if people have questions or concerns like we can use is the like e magicians threat about 3074 still the best place to do to do that um as people sort of review

it

Lightclient: yeah that's a good place okay also one of the um channels on Discord any of the transaction batching ux channels just feel free to tag me I'll respond

Tim Beiko: got it um oh I'm not saying we're necessarily looking for extra feedback GEOS but just if some L1 teams like review this more deeply like in the next week or so or whatever and they have questions uh then yeah we can use both the channel on the R&D Discord or eat magicians as the the place to discuss those

um yeah I I yeah I think it probably makes sense to move on to the next ones uh at this point though and yeah thanks again uh Fubar for coming on and uh sharing both the write up and the slides

um yeah thank you

sweet okay next one oh sorry please

Lightclient: I just want to say one last thing on this like there is a lot of demand from the user space for something to improve the ux on L1 so if 3074 isn't the path forward it would be great for client teams to think a bit about this over the next couple weeks so we can try and come up with a proposal that we can put into the next Fork

Tim Beiko: yeah that makes

sense um okay next up uh set code uh we had another uh I guess design overview uh William okay

William Morriss: uh yeah can everyone hear me can everyone see the presentation yes all right cool I hope this goes fast so the common basis for all the design of set code uh we're just modifying the code at the address uh that's executing uh so code copy and code size still refer to the executing code uh EXT code copy EXT code size EXT code hash

refer to the stored code it's similar to delegate call in that regard uh so new call Scopes will execute the storage code uh so the storage effectively happens immediately uh and storages can be reverted like sore uh and uh it fails inside of create context and it doesn't clear storage these are the basic uh parameters of set code uh but there's a few alternative designs that have come up in the process of uh designing set code uh the most basic set code would have no restrictions uh it's a simple design uh it would work the same way as estor

estor also has only the static call restriction uh and so uh it would be difficult however to identify immutable code and uh someone identified that it could have an issue with uh C 4337 uh because if the uh if a library that all of the validator step we using for the alt men poool uh were to be uh toggled then it could thrash uh that me poool and be a Dos Vector uh so with his help uh developed a newer design that adds a restriction uh the Restriction is

that you can only modify the currently executing code if it's your code uh and so uh this uh allows it to be easy to prove that a contract is immutable it' be easy for a wallet to know if it is approving a mutable contract it would be easy for ether scan to flag mutable code uh also uh immutability uh it can't be faked during execution so you wouldn't be able to pretend during the scope of a transaction that you're immutable get validated for some registry and then change to mutable uh so that's a nice property too uh and then also it would

prevent set code inside a delegate call uh which would address the alt M Pool dos vector and so uh this may be a more secure design uh and it's probably a good restriction uh that could be removed if it was determined say safe to do so uh but probably a good way to launch and the last parameter for the design uh of set code was is that we could instead of setting the code at the account uh instead we could have uh the code be an immutable blob per account and then have the accounts have a new field the code address that would allow them to indirect uh The Blob that is

their code and then there'd be op codes to set the code address to read the codee address uh and then uh so this is some other way to to implement it that I'm interested in knowing how good you think this is and how compatible the code address spec is with veral uh because when you do veral trees you're likely going to cement this field in uh and so either the code address would be mutable or the code would be mutable uh it either would be satisfactory for my purposes uh the current specification is uh the uh belongs to

specification where you can only change your code and then uh it's uh a nice spec because it implicitly captures the delegate call and create uh scenarios and it's pretty easy to know whether you're allowed to set code uh other designs were slightly more complicated um again the reason we need to do this is that uh account abstraction can't delegate call if it wants to be competitive for Dex protocols uh because of priority gas auctions so if you have a proxy behind delegate call and SL load uh then you're not going to be able to

uh compete for unit swap V before you're going to be super late to any trade and you're going to have a systematic disadvantage and so if you're trading on dexes uh things like 4337 aren't really viable uh whereas uh that's why Meb Bots are using the create to self-destruct pattern for their upgrades uh it's because it's a really good user experience and I would like to preserve that user experience so that I don't have to move all of my assets to a new account every time I want to support a new callback uh that's all for this presentation I defer back to you

Tim Beiko: thanks William any questions uh Marios I see you have a comment uh in

chat around uh breaking gas estimation um so I don't know William if you maybe want to answer that first and then if there's other questions people can raise their hands

William Morriss: um gas estimation is already broken by eStore uh for the same reason uh you can Branch according to code just the way same way you can branch Branch according to uh storage and so any change at all actually impacts gas estimation and this is one of the main uses of alt men pools and relays such as flash Bots

Tim Beiko: got it any other questions comments oh

gim

Guillaume Ballet: uh yeah so there was a question asked about the feasibility in vertical of the third option I mean I see no reason why uh this this would not work uh however I mean on a personal note I uh don't really see how this whole set Co set Cod story could end well there's so many uh potential hacks with this um yeah I I would not consider that in the viral spe for sure but I I don't think we should consider that period

Tim Beiko: got it um um and okay there's a specific

question by uh light clients around uh if we can do this with delegate call already why do we need

set code

William Morriss: yes uh so Del call is unviable if you're trading on dexes because of priority gas auctions so your ability to trade on a DEX if you're competing with them for storage uh as you're currently saying this is a Dos Vector for nodes it's the same uh if you're trying to trade and some only one of those trades can win uh the one that uses the least gas is going to be the one with a huge advantage that's because they're going to be able to bid higher uh and get the trade

Tim Beiko: got it okay and there's the last question

sorry

William Morriss: uh Marius has a question says so this is only about the gas usage of delegate call um no I don't think that's all it is uh it's uh having used the self-destruct upgrade pattern even when you have to wait a whole transaction I see it super priority it was so good uh if you don't need to uh use storage you've been using this already and dozens of power users have been upgrading this way uh

it's just uh it saves so much gas per transaction uh it I don't think there's a way to price delegate call that would fix this I think that not having a delegate call at all is just a huge advantage

Marius van der Wijden: I'm so I think this proposal will backfire quite badly for most users um and because people will create gotcha contracts um where they will be able to set the code and then and then uh break it um so I think it's a net negative for most people and maybe there's an

advantage for the 15 or the handful of power users um that use this but I don't think we should um we should do this for for for for for these people um and potentially bring normal user um at risk with this

William Morriss: I don't see it as that demographic uh rather that only a handful will be able to keep trading on dexes if we don't allow everyone to do it this way uh currently it's there's a huge cost to migrating all of your stuff and you're only able to do that if you're a high frequency Trader otherwise you're just going to suffer or go back to just using the one by one transaction method uh described uh I do agree with

some of the sympathies in the comments uh regarding how we just need better account abstraction uh that is true

Tim Beiko: okay this is probably a good place to wrap this one up and again I think if this is something client teams want to see in the fork uh they can definitely signal uh for it um yeah thanks a lot William for for coming in um okay last one uh before we get into uh what client teams want into the forks um Mike wanted to talk about two CL eips that would have implications on the El side and so to have people be

aware of those and um what it would mean uh I guess you know first the value it would bring and then second what it would mean uh in terms of work on the elel side if these were to happen um yeah EIP 7251 7547 Mike uh do you want to give an overview

Mike Neuder: yeah hey thanks Tim um and I'll try and be super quick I know there's still some left on the agenda so I guess I'll give a quick overview for the two aips talk about how they relate to the exec layer and then you know if there's time to to field a few questions happy to do those otherwise you know please reach out offline um I should be pretty easy to to connect to so yeah I guess both the eips um I just sent in the chat

the first one is EIP 7251 which um we've kind of been talking about for a while but it's this idea of increasing the max effective balance so just super tldr the current max effective balance is 32 eth which means both the minimum balance to become a validator is 32 eth and the maximum balance that a validator can have is 32 eth um this is a few implications on the on the big staking pool side of things it means that they have to essentially spin up many many validators to to account for all the stake that they want to put into the consensus layer um so just for an example coinbase has like 120,000 or or more validators currently that are kind of controlled by the

single entity so they're almost redundant in that regard um on the small Staker side this means that any stake you have above 32 eth automatically gets withdrawn and doesn't like earn compounding rewards until you have enough to deploy another validator so a whole new 32 eth um so generally speaking increasing the the maximum you can have while also keeping the minimum at 32 both benefits the the large stakers because it allows them to consolidate and this this has like overall Network Health implications and it also helps the small stakers in so far as they can have balance that's above 32 eth but not 64 eth and they can get access to this automatic um compounding so yeah that's that's kind

of where I'll leave it in terms of the summary there's a lot more written on this here there's a kind of related work section in this gist um in terms of the execution layer the way this relates is through EIP 702 which asks that the execution layer withdrawal credential which is kind of different than the signing key that's used for the consensus layer can initiate an exit so beyond this um the one one important feature of of 7251 would be to allow custom withdrawals um that aren't necessarily full exits also triggered from the execution layer so the kind of use case here is if you have a validator with 100 eth you want to withdraw two eth to pay your taxes or whatever then you can do

so without withdrawing the whole 100 eth validator and that that request for that withdraw could come from the from the withdraw credential rather than from the um validator signing key and cool I'll just run quickly into 7547 um the the tldr here is that this EIP aims to enshrine inclusion lists in the protocol the motivation for this can be seen um on Tony's awesome dashboard censorship. piix um which basically shows that because of the world we live in in terms of uh Mev boost and and block building a huge number of blocks on e main net are built by a very small number of entities and those entities usually choose to exclude some set of

transactions so the EIP itself is is this kind of forced inclusion mechanism where validators even if they aren't building the block for their slot they can ensure that some set of transactions will get included um there's a extensive research on this uh mostly done by vitalic and Franchesco over the past like three years um the latest design is is this no free lunch thing so this has like a related work section and and all the details you could want um but yeah the the implication on the execution layer side is that the block verification would now depend on this inclusion list so the block would only be valid if it included the transactions

that were specified by the inclusion list otherwise it should be ignored and um and considered invalid so yeah those are this is my highle pitch again these are mostly on the consensus layer side but just wanted to kind of make sure that that this audience was aware of of these and kind of make sure that the any questions that that people have have like you know a way to get in touch with me and and there's a venue for that so yeah thanks thanks for giving me the time Tim happy to take some questions now or if if we should move on to the client team discussion happy to do that as well

Tim Beiko: we can take a couple of questions now if uh there's time and if there are

questions

uh Aman

Ahmad Bitar: so one question about uh increasing the mass effective max effective balance is how does increasing it affect the inactivity leak uh in case there is a non-f finalization in the network uh since uh the increase in uh the the balance of the validator will uh mean mean that uh it will be able to attest for or not attest for longer and still be um still affect the network in a higher

um yeah so the

Mike Neuder: yeah so the leak would still be

proportional to the balance that you have so if if you're like a 32 e validator you leak at some percentage per year and if if you're a 2048 or sorry 248 eth validator you leak at that same rate

Ahmad Bitar: that's right that's right right I just remembered the equation never mind uh that's that's actually valid what you're saying thank you

Tim Beiko: cool thanks any other questions

Mike Neuder: I'm just looking at like clients how complete is the is spec last time I looked um which will only be so effective because of stake consolidation um how does ST consolidation affect this

Lightclient: I just mean if you're coinbase and you're building four blocks in a row you're only going to use non-empty ILS um whenever it's not you you building the next block if for some reason you're not allowed to include transactions in your blocks that are considered something that should be censored

right

Mike Neuder: right so I guess this is a little speculative because we're not sure exactly how the how both the validator side decision process would be and also the Builder side decision process right so um yeah I I don't want to speculate on what they would do I guess in general there's Tony wrote a piece um I don't have it on the top but

Tony wrote a piece called cumulative non-expiring inclusion lists which kind of addresses this and it makes it so that you could kind of specify how far in the future this thing could be enforced um I'm not sure about the necess like the necessity of that versus the complexity it adds but it's definitely part of the discussion

Lightclient: yeah that makes sense um I think this is something we should be looking pretty closely at um you know if not for this Fork then hopefully for fork soon um so yeah that's generally my thoughts

Mike Neuder: yeah and we're kind of in this slightly delicate situation where a

number of the large builders have started censoring a subset of transactions there is a few builders that are not um if those Builders decide to start censoring then it could quickly turn into both like a kind of bad look mimetically if if 90 plus percent of blocks are censored and also like legit degradation in ux in terms of getting those transactions in so right now I would say with with you know the situation is is very um unstable and the the more I hear from from Builders and validators the more I think that getting some enshrined inclusion mechanism feels very important especially as regulatory stuff continues

to be uncertain

Lightclient: yeah it would be better to be proactive with this than reactive in the event of censorship like seriously impacting users

Mike Neuder: absolutely yeah

Tim Beiko: okay um I think yeah we could probably wrap up here unless there's any uh urgent questions okay thanks Tim yeah thank you Mike for sharing all that um okay so I think yeah the next big chunk um and this might consume the rest of the call is I guess given all this context and uh what we've discussed on what we've

discussed on the previous ACD and just like the general setup for proposals um it'd be good to hear from uh client teams you know what they think should be prioritized in the next Fork where they have the strongest opinions and I think as part of that probably the biggest question is um how we feel about veral um we'll focus more of the next call going deep into veral um but uh I think yeah from a high level perspective figuring out do we want to do veral right now do we potentially want to do another fork with another set of VIPs prior to verola um and if so which eips are most urgent to include there um that seems like the biggest question uh to

answer so um yeah if any uh yeah if any team wants to kick it off uh georgos just shared uh I guess yeah maybe georgos you know you you had this write up already uh do you want to give a quick overview of that and then uh yeah others can chime in after

Georgios Konstantopoulos: um yeah thank you Tim um so we I shared it WR up in the chat the tldr that I think is that momentum is very important and uh we have a good Jive right now of shipping things um so I think and there the rest team view that we should be

able to ship something in 20124 um I think we should optimize for shipping something in 2024 um and to that extent I think that the most important IPS to ship are the staging related ones uh that Mike mentioned in particular 7002 um and beyond that I think we should be shooting for isolated one person jobs on the evm side so eof I know it's a painful topic for some we took a close look we think it's doable in you know by one person in a couple months um other ideas that we are interested in are increasing the max

blobes post Cancun but I think we need to do a lot of data work before we can see this so we don't really want to push for anything like that um so our strongman would be 7,02 um there was another EIP about uh introducing deposits uh in the El state which was good for the CL the BLS curve EIP I think everybody knows how to use bls2 381 by now it's literally everywhere I don't see any argument against um a let's discuss on scope and commit on something and yeah um that's where we're at and uh given that we have it written

down I think worth giving time for other teams to speak more I'm happy to discuss as think

Tim Beiko: thank you yeah that's a really good starting point um any other team have thoughts or perspective you want to share

Andrew Ashikhmin: yeah um I can talk about Aragon's perspective uh um I think that we should uh definitely deliver big uh serious um fundamental improvements that require a lot of engineering uh because I believe that ethereum has the strongest engineering um talentful among all blockchains uh and if we don't do

um difficult things then maybe nobody will so uh I think we we should deliver vle and EF the and the the main question which we how we shedule whether we shedule vle first and then eof or the the other way around uh I think Gom has a point that vle is is already very is an epic upgrade and um EF can potentially complicate it further so perhaps it makes sense to deliver vericle first and then UF um and then like once we agree on on that that order we can maybe bolt on some relatively isolated uh things uh um

on on on say on if we deliver V on the first upgrade maybe say potential I I think that that uh tackling bad badge transactions is important so say we decide that we are happy with the 5806 so then we can take can potentially B on 58 on 06 on on the first upgrade say

say vle

Tim Beiko: got it thank you any other team

Marek Moraczyński: so uh never mind we would like to see small fork with eips such as execution layer exit BLS

precompile Supply validator deposits uh yeah and after small Fork we would like to focus on verical trees and additionally uh we would slightly prefer to focus on EIP for Force the youf if all teams have a capacity to do it uh and also we would be happy to implement any account abstraction e if there's clear decision uh what uh eips we want to implement for account abstraction

Tim Beiko: got it thank you

um so for GU

Marius van der Wijden: um I cannot really speak for the team

but uh from from what I uh would like to see is I I would love to see verle first but I um don't don't think that realistically don't think that um the majority is for verle first so I would also go with the with the nethermind approach of doing a smaller hard for um first uh and then while working on verle and the smaller hard fog in my opinion should contain uh 7702 6110

2537 and another one that I don't remember but um like basically the the the validator deposits and exits El deposits and exits and um BLS precompiled oh uh the SEC p 256k uh R1 um as well I think that would be a a small set for a small fork and uh we will have time for building

verle

Guillaume Ballet: uh just to add to this I think actually there was some push back on 6110 but yeah I think everybody else in the team that I'm aware of at least is

for a small Fork before

veral

Tim Beiko: got it

Matt Nelson: yeah the the Bas Su team here has very similar thoughts as Marius SLG and the nethermind team focusing first on a smaller Fork um with a lot of the same eips like the BLS precompile uh the SEC 256 R1 precompile uh the 6110 you know 70 70002 focusing on some El related deposit stuff um and then you know between a driver of vof or as nethermind stated something like 44s uh it's kind of loosely um you know kind of a toss up

there I would kind of defer to others on this I know some on the Basu maintainers have strong opinions about e so I'm speaking mostly for subset of maintainers here

Danno Ferrin: yeah I'll speak for eof um sorry for not being on last week's call it's on a vacation so um I guess the voice wasn't loud enough there um but as far as eof and all these other um El deposit level ones it's important to note that the engineering commitment is fairly orthagonal um the engineers that know the most about eof on the client teams are not necessarily ones that know the most about the uh the the consensus layer changes so you know one of the concerns that we're going to be splitting engineering effort I don't think is quite the same because as as as

George Yos pointed out um it's it's very few engineer times because we already had this mostly functioning with NE mind Basu and gu in January of last year and they're mostly iterative changes so the hard work's been done for eof so that's that's my opinion on the o and the other changes proposed for I'm in favor of the of the of the fork before veral and the other scoping sounds reasonable to me

Tim Beiko: I think that was all the El teams but um did I miss anyone oh

uh Lucas

Łukasz Rozmej: so I would add quickly uh so our concerns for eof are mostly on the testing side because this is very consensus uh

issue problematic uh like easy to make a consensus issue so um I would really love to hear from uh the for example Hive testing team what they think about

EF

Mario Vega: hey yes I think we can make um I have some well we have some pretty good ideas on how to do e and also veral um which is just to introduce more testing uh fixture formats uh for UF specifically so what we can do is uh now we have the ex execution spectus we can generate um a definition of how the eof can fail for example and do this testing across all the all the teams by doing the fixture

format for this specifically so we that I think that can alleviate a lot of the testing um testing burden on on on on EF and also on Burl we we're planning doing some the the same thing for for for this complex upgrades on the Y side

um yeah

Tim Beiko: yeah and there's a couple comments uh on eof in the chat around uh a finalized spec so I don't know if anyone who's familiar with just like the latest uh spec work um that can give an update

Danno Ferrin: so the spec as it's written today could be closed um we're just mostly um arguing over smaller you know maybe one

more up code here you know how are we going to do the final um nibble integration of the exchange app code um there is a a push to move everything to variable width but I think that's come a little too late in the process um you know because that would basically be restarting the spec um and doing large things so what we have written in the UF repository um you know modulo stuff found in testing could ship a zof um if we get the if you know we would want to do a final discussion with the solidity and Viper Engineers are on the call but it doesn't seem like it's a very long list at all so it could be done in a week or three

G

Guillaume Ballet: yeah so just maybe a reminder the the problem in this deciding which one goes

first is really about the complexity of veral and the fact that the more we wait the longer the transition is going to take so um yeah if you start adding E before veral well first it's going to complexify veral because now you have two types of contracts to handle and Now with veral uh the co the code itself ends up in the tree and is going to be treated differently right so you're going to make uh like increase the complexity of veral unnecessarily and on top of that you're going to make the the conversion much low much slower and much more risky because it will be pushed

back by as much time as you need to deliver eof which is not a simple change this this being said um we in verle have to go through the the state and convert everything so if uh and Pavo is supposed to get back to us on that if um it would be possible to convert all the Legacy code um what during the veral conversion then I would say let's do e first because then we can turn everything to eof and forget about Legacy code it's not guaranteed that it's possible in fact it's very unlikely to be possible but if it's possible then it's totally worth waiting but otherwise there's no

good reason to do to do e first because yeah like I said the state is growing we have a very um yeah difficult problem ahead of us we need to tackle it first eof is really nice but it's just that it's nice to have it's not like a catastrophic problem that we're going to face sooner or later

Danno Ferrin: so once specific problem that eof solves with its structure and validation is the whole notion of uncapping code size there's a lot of push on Twitter to increase code size from 24K and that cannot safely be done in Legacy code where whereas it can be done safely in eof code and another problem is some of the goals of eof code are to explicitly break things that Legacy does that we

don't want in the future um such as code visibility we don't want to be able to look at the executing code as part of the execution modify and manipulate it we want to separate that that code inspection out and also we're taking the opportunity to remove some of the gas observability issues that are observed in Prior versions of of the Legacy code so one of the points of e is to break these things that have caused problems and get rid of them so that in eof World it can't be done so because of that you can't translate all Legacy code into eof code could probably do most of it but there's some explicit places where they're you know depending upon these features um and those we just can't translate there now the longer that we wait to to put eof in there the longer that we have to deal with more Legacy

code coming in in fractured forms such as the diamond pattern versus looking in the safer ways to uncap code size and get you know these these app developers are begging for just not as loudly as the defi people for things like um getting rid of you know revocations um but there's a lot of desire to get to increase the 24K limit and we need a better validation system before we can do that safely

Tim Beiko: um okay so we're we're basically at time um so I guess maybe summarize a couple things uh that uh we've heard so far one it seems like everyone um everyone except potentially Aragon would want to see like a small Fork

before veral and then Aragon's view is like if uh we do a fork before veral it should include something substantial not just um uh a bunch of small things so we should do hard engineering work um I think in that context the three IPS that everybody seemed on the same page about were uh 6110 7002 so the two um validator related uh eips and then uh the BLS pre-compiled um and then whether we move forward with veral or uh eof or potentially something like four fours even though it's not quite a consensus

change but have that you know be like the quote unquote hard engineering thing we do in parallel to uh to this the small eips that seems a bit more consensus um so would it make sense to move forward with um those three eips so 6110 7002 and then the BLS precompiled as like the basis for our small Fork that's targeted for sometime next year on the next call spend most of the call discussing the big big three uh proposals so eof veral and uh 44s and then figure out you know which

um which uh Fork they would sort of fall into um so you know agree that like there will be a small thing likely before veral um and then the sort of minimum set that we have consensus on so far is like uh 6110 7002 and 2 537 um and then discuss the three big things on the next call um and see how they they can fit in does that make sense to people I guess any objections this

Andrew Ashikhmin: well uh I I have one question so I

think um like like uh um there is some opposition to e in principle so maybe uh okay maybe we can decide on the next SC but I I would like to hear whether people agree that EF is a good idea in principle or not

Tim Beiko: right yeah and I think okay it's probably worth Galen to that on the next call and I think in the case where we did not want to move forward with eof um and we wanted to have a separate Fork before veral the other thing we could spend extra engineering resources on is um for fours like history expiry

right which doesn't actually require a hard Fork but it does require a hard work by client teams um does that seem reasonable I guess yeah and maybe the thing I'm trying to say is it seems like everybody's like in favor of the three small eips there's still some questions around what the big big ones are but at least we can you know set those three and then discuss the big ones more thoroughly on the next call um oh P this oh po as we can't hear

you oh okay we're already a couple minutes over time so I'll open just like a draft PR for um for that uh and again we can continue the discussion next call um and I think uh we didn't quite have time to get to the the point about veral but one thing that would be valuable is if people can share any questions concerns uh that they'd like to discuss around either eof uh veral or for fours um either on award devs or on the agenda for the next call so that um the folks who are championing those can can take them into account um yeah and we can discuss later and I know we also didn't

quite get to the Basu incident uh Matt would you be okay if we move that to the start of the next call so that we're sure we actually cover it yeah not a problem cool okay so let's do that um yeah any final closing thoughts or comments before we wrap up

Potuz: can I just say something quickly yes oh please yes good uh so just two two unrelated comments one of them is uh my only objection to your your statement was that to ship to next year and the reason being that many teams may have waited in their decisions to have a small Fork the idea that this Fork will

actually be small and will not delay work if we knew that we would be shipping for 2025 then perhaps teams would have decided in a different way so I would commit to targeting at least by the end of this year and the second comment is a quick shout out to the W team uh I think they set out a president that I hadn't seen before perhaps once from the GU team which is put out a detailed before the meeting a detailed reasoning for all the eips that they want to be included and which ones they don't want to be included and which ones they're to be discussed uh this was late for us we're planning to reach that internal consensus on prism and actually have this ready for the next uh meeting this

would be very good if everyone uh does the same in the next time so this is just a quick shout out for them

Tim Beiko: yeah I agreed uh is extremely valuable um and also yeah I didn't mention the C called but I assume you'll all have a similar discussion next week um on on your side of things um yeah I think this is a good place to end um so yeah I'll put the pr up uh for those three small eips we can uh discuss the three big ones on the next call and yeah talk to you all soon thanks everyone

thank you bye everyone thank you thank you thanks Tim bye

time

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