All Core Devs - Execution #187

Transcript

[Music] e for in

okay take two now we are live with audio for me as well um welcome to acde number 187 uh basically the only thing on the agenda today is stuff related uh to pectra um we'll talk about devet zero progress from teams then there was a breakout around e374 and the broader account abstraction road map that happened earlier this week that will'll cover uh continuing the conversation from last call uh after that Ethan had a bunch of comments around uh basically the the messaging around uh EIP 6110 and the generalized message bus we

introduced recently so we'll go into that and then um yeah a couple more um eips to discuss if we have time I guess first um devet zero I Barnabas or Perry or either of you on the call yeah I'm

Barnabas Busa: uh so we are preparing some D zero configuration files in cryto and trying to test them uh we still had some hot fixes coming in this morning and uh probably we can be fully up and running by Monday with like a somewhat stailish configuration nice but uh we were missing some config files from the

uh chain pack but that should be fixed now and we made a new uh Genesis generator image so we are testing that right now

Tim Beiko: awesome um and last I checked I believe every single client team obviously has has their work in progress it seems like G and ethereum JS are the two clients with everything implemented um anyone on the client teams want to share updates or concerns oh nethermind has everything implemented as well it seems nice

Basu

Justin Florentine: has everything in flight at the moment they're all being tested and

about to be merged so I would say that we're development complete but they're still being debugged and need to be merged in the main got it

any other team have updates

Andrew Ashikhmin: um yeah in in Aragon we have most of the things um as work in progress except for 702 um yeah so it's still maybe a week or two away

Tim Beiko: got it um and then yeah R still uh also working on it and shared the tracker in the chat

and I guess yeah on the CL side scanning the devet zero spec it looks like everyone is still in various stages of in progress but any CL have everything implemented

Saulius Grigaitis: so Grand thinks that that it has everything and we started to to do interrupt uh I think yesterday nice uh yeah yeah and well none of uh of e that we tested works so so we tested NE mind ethereum

J and and G so we were not able to essentially we are not able to finalize it so uh and I in this I reported a few issues and we we keep working on on that with some e teams

Tim Beiko: got it thanks any other CL teams have updates or have everything implemented

Sean Anderson: uh so on lighthouse we don't have everything yet but everything's um pretty close we're hoping to pull it together tomorrow ni um one thing we ran

into was uh I think the get payload body endpoint and the execution engine apis needs an update and I don't think that's speced out yet I'm not sure if eels have made changes there but yeah we ran into that yesterday

Tim Beiko: anyone uh on the E side look up that call uh yeah

M

Marek Moraczyński: what changes do you mean in uh get payload adding deposits and withdraw request or something else

yeah

Sean Anderson: yeah just those two

Marek Moraczyński: yeah so we added them on our side uh so not sure if Barnabas finish the CIS

config we can try

Tim Beiko: okay

Sean Anderson: yeah we just didn't see changes in the spec but we haven't tested against Neel yet

Marek Moraczyński: so I think in the spec it is mentioned in execution payload and get get payload returns execution payload and in this way it was mentioned

Sean Anderson: okay awesome thanks

Tim Beiko: um and Mel said in the chat that uh they're updating uh get Block bodies in the spec uh which should be done soon any other comments questions

concerns from the CL side okay um and then uh yeah I don't know if on the on the testing uh Team on the El any updates there I know last week uh we had all the tests ready except 3074 is that still the state we're in

Mario Vega: hey yes um we still have we we do have a PR for 374 tests but it's not uh filled yet um I'll try to get an update in the coming days but so far yesterday the testware updated to include mortas

for 29 um 2925

Tim Beiko: got it thank you anything else on devet zero before we move on okay um next up uh so we had an AA breakout uh to sort of continue the conversation around uh 3074 and potential other eips earlier this week um I don't know light client I believe you were on do you maybe want to start

with a quick recap and then we can we can take it from there

Lightclient: yeah I can try and take a stab about it uh I know lot of people on this call we're on the call Tuesday so feel free to jump in after and add some things I might have missed basically the call was separated into two two parts the first part I wanted to try and have a conversation with all of the relevant parties about what are we building towards what are what do we think is a realistic timeline for what we're building towards and given that like how what should we be prioritizing on L1 right now and I don't think that we walked away with a perfect picture for every single party but I think one thing that we did agree on is native

accounts abstraction on L1 is still a few years away and so there's definitely a reason to do something on L1 in the next hard Fork if we can come up with something and we talked a little bit about what those things could be should we be focusing on improving EAS should we be focusing on trying to let eoas migrate to Smart contract wallets and there was some proponents for both sides it felt like the louder side was the side to just improve EAS today because there are some things that we still need to think about and figure out how to resolve with respect to actually migrating EAS and part of this might be due to this proposal that vitalic had had published just a bit before the call and so people were very excited about

improving EAS so that was the main thing we we wanted to like get a picture from all the different sides where are we trying to go and it felt like we came away from the call and people were okay with improving EAS if it made sense in the longer term road map and then we went to the next part of the call which was supposed to be really focused on talking about 3074 and some answering some of the questions that have been bubbling up about 3074 the past few weeks but we ended up mostly talking about a new proposal 7702 which I think italic will talk more about on this call but basically it's a different uh proposal for how to improve eoas and overall all it seems like there's a lot

of nice benefits of it over 3074 it fits into the 4337 accounts abstraction World very cleanly and you know for me most importantly it lets us reason about how it lets us reason about more statically about what types of accounts might be drained in the transaction pool so I think that that was like a big question mark with 3074 that we had to answer during defit zero so we talked about 7702 generally felt positive on on that and afterwards we talked about some more generic questions about the authorization of 3074 or 772 from the perspective of the user

like should the user be signing a message with nons should they be signing with a chain ID just some like arguments that we had had in the past few months but we now with many more participants who've actually been developing smart contracts that would work under the 3374 7702 world and I don't think that we necessarily made too much progress there uh it's just an ongoing discussion uh but yeah I think yeah that's pretty much the recap if anyone else has something that I might have missed I think we came out of the call pretty happy with the Direction with 7702 but I think we should open that discussion up here at some point

Tim Beiko: I guess yeah before we go oh yeah I okay metallic you want to cover

7 102

Vitalik Buterin: yeah yeah um so the the basic idea behind 7702 is that it's an EIP that basically allows a trans an eoa owner to sign over a piece of code and if that piece of code and that signature gets included in a new transaction type then the EA basically turns into a smart contract that has that pip code for the duration of that transaction and the reason why this is interesting is because it satisfies um a lot of uh use cases in a way that's very similar to how 374 satisfies them in the sense that you have some outer transaction

which could be called by the owner themselves or it could just be called by some other actor like a pay master or a sponsor and then it does some author it calls into the user account it does some authorization logic and then it does some execution logic and the the users like the EA gets activated and it starts doing things from from the inside of the transaction and so there's a very natural way to convert any 3074 workflow into a 7702 workflow the big benefits that it has are that it removes the the need to introduce new OP codes so in

instead of doing an A and cost call you would basically just do a call into the account it's uh as like I mentioned it's very static analysis friendly because the accounts that are affected just get statically declared in the transaction and it's uh very forward compatible with uh not just 4337 but also potentially get any kind of smart contract wallet based active structure strategy we might in the future basically because uh the the code that a user needs to sign over just is a smart contract wallet and so you can literally use Smart contract wallets that exist today um and so

workflows in this scheme just very naturally carry over into workflows that would also make sense in a full full smart contract wallet world and so that's the core idea right basically yeah what you can think of it as being 30 74 esque from the perspective of uh how some like application developers might interact with it today but then at the same time kind of borrowing a lot of elements of style from some of the other and more more conservative account abstraction proposals and uh so we brought that up yesterday and uh we discussed both the EIP itself as well as

some ongoing Corner cases that are being discussed on the M magician's thread um and uh in and in other places like basically figs around how do you uh like what what's what are the specific bits do you sign over like what particular features do you add for safety reasons what particular codes do you disable and there's a lot of like a lot of similar considerations to what's been debated within 3074 in that sense a couple of new ons as well and and so there's definitely yeah a lot of you know discussion on those points happening in uh both on on the pr and uh on ethereum

magicians so highly encour encourage people to look at those and uh participate and uh you know if they're interested I'm start you know like figuring out how this might make sense for like they are piece of infrastructure their use case

Tim Beiko: thank you um anyone else have yeah comments questions Andrew I do oh sorry uh yeah Andrew first if yeah I guess if if if you do please raise your hand and zoom in I'll I'll go in order

yeah

Andrew Ashikhmin: I think I like the uh idea of

770 too I think it's more elegant than 3074 but my big concern is revocability because right now it doesn't specify revocability in any like at at all and that's a big security concern

Vitalik Buterin: yeah very valid revocability is one of the items that's uh being discussed right now so there's a couple of strategies that have to do with either signing over the nons or signing over the nons divided by some number that are being talked about at the

comment got it Nim

yeah so uh I have a I think I have like a a few questions and and thoughts

the first one I just wanted to um emphasize that uh in some in many use cases uh gas costs are probably going to be can you guys hear me I have like someone literally just destroy the apartment right awesome um so yeah I I think that the on the gasa side I would love to to hear a little bit more there because like 374 themed I need to I need to run some modeling I this is like 7702 is just very new need to do some modeling um that's my first question in terms of actual gas cost per transaction how did we think about uh that versus uh having a transaction uh where the costs

actually scale out with the size of the contract uh that we approve um and with that generally the contract is you know the more features and the more uh safety features uh the more expensive the transaction is going to be sorry whereas uh signing over for example an address uh that you may have checked you know as a user verified the code uh independently and and and and separately

Vitalik Buterin: yeah also a very good point um I think a couple of um answers there so one is that even if we do assign over code one option that is always available is you get the code that you sign over

can be a delegate call forwarder and delegate call forwarders can be only 44 bytes and so that's uh so that's one approach for making it very affordable even for very large contracts and then again I like I personally am totally okay with both the like code in the transaction version and the the code address in the transaction version um and one of the considerations that sometimes gets uh talked about in the other direction is basically cross chain uh support like if you want to sign over something and have it work on multiple chains then

uh yeah a hash gives you somewhat stronger guarantee though obviously those guarantees go away if you if you end up using a delegate so there's a couple of different ways of handling that but this is uh again this is like one of those uh finer points that's still being

um Ben um I

Ben Adams: I originally thought um signing over the code address would be better but I've come around the idea of putting inet code in instead because there's two separate signatures so you've got the

signature where you're approving um you know here's the contract I want you to use and then there's a separate signature outside which is here's the data I'm passing in if you want that inner signature to also approve some data then you need you need extra so you could do here's my protic contract press some data um and then the outer contract could sorry the outer signature which could be you know sponsor um could add extra data which isn't dependent on your signature so it's more flexible

Tim Beiko: got it um there's okay so

there's a couple questions in the chat uh or comments anyways that that sort of go at the same idea of like implementation work around this um and whether you know we could reuse some or part of the 374 work or how much more work it would be to implement this from scratch and then also uh Justin had a comment around should we consider running both on like the same devet um so that we can actually test them uh in production but yeah I guess I'd be curious to hear from some of the El folks like and I I don't know how many are have reviewed the EIP but just in terms of the scope of to work like how big of a change is 7702 relative to 3074 um yeah uh Amad I don't know

Ahmad Bitar: my personal opinion I've read both

and I've uh we've already worked on 3074 on another mind my personal opinion is that the work will not be the same um most of the work needs uh needs re like other implementation for 77 O2 um not sure about the idea of running them both and how then that interaction could be because like I don't I'm not sure how they would interact with each other but um 7702 is is definitely different in implementation wise in my opinion

got

it

Tim Beiko: um got it and I guess yeah um generally I think it probably makes sense to give people a bit of time to review this before we make a decision about whether to include it uh in like the next Dev Nets and also given teams are still not like done implementing Dev at zero we we do have a bit of time um so and and yeah SK scaming through e magicians um scaming through e magicians you know does seem like there's a bunch of conversation happening around 7702 but um yeah does anyone feel like there's something we we should sort of decide today about it or or like a an issue we

should resolve or does it make sense to continue discussion Ayn and then um on the next call make a decision about whether we want effectively devet one to have both uh only 7702 or um yeah potentially something else um Charles you say you have a new draft thep is this related to 3074

7702 no I dropped it in the chat so that can people can look at it okay okay um interrup

Tim Beiko: okay so definitely okay so there's definitely some concerns about having both in the devet but um yeah

given we're already you know pretty much done with defet zero it's probably more work to change the spec now and say you know remove 374 or anything like that so I think it probably makes sense to move forward with devet zero and then make a decision about 7702 on the next call does anyone have an objection to that okay um so yeah definitely encourage everyone on the El side to review the eat magicians thread and then it would be great if in the next two weeks we can flush out uh these issues around just revocability gas costs and um yeah all these other uh smaller details and um if people still if people

still think this is you know the best proposal to move forward then maybe we can add it in defit one and remove 374 um but yeah going to make that decision in a couple weeks um anything else uh on

AA 374 okay uh next up Ean oh yeah please

sorry Tim I just wanted to to emphasize that um you know I want to kind of take a pragmatic approach for um I know that it's not the case of everyone in this call but like a lot of uh uh companies have been kind of like you know wild

providers and so one have been building pretty large scale um uh uh 277 in1 um you know bundler sorry meta transaction forwarders and just wanted to emphasize that 3074 for us I mean like we're included in in this category um you know is a lot easier as kind of like a Next Step um and so I just wanted to to emphasize the need for um kind of either some kind of considering uh 3074 as kind of an incremental step for everyone who has right now uh 2771 um you know infrastructure to uh sponsor gas cost for all the smart

contracts that do support kind of what is their forwarders or having some form of joint efforts from everyone to standardize uh an implementation of uh you know a 4337 bundler that would really help every single wallet provider essentially uh offer table Stakes uh table Stakes features because I the end of the day 99.9% of of our user base which is pretty pretty large now uh is really just asking for gas sponsorship and transaction batching um on every single contract and both satisfy that but one of them is a lot easier because of the infrastructure that we already

have in place definitely understand kind of the concerns on on all sides but just wanted to to throw that out there

Tim Beiko: thanks uh Jor are you looking to respond to this

Dror Tirosh: uh yes just one clarification we are still looking into 7702 it seems like uh there is some accounts that using it will be almost like standard accounts using the eoa and with minimal change to the bundlers and no change to the entry point but uh again this is very plary we didn't it's a still hand waving but it looks PR and quite easy to get with

Tim Beiko: got it and just sorry I'm not super

familiar with the details here but the 2771 EIP or ERC is this effectively what can be like is this the 4337 bundler are they like the same interface or are they two different things

Dror Tirosh: no it's a different thing it's way to put code inside an account to make it look like it is a smart contract and it can be used with the onchain contract the entry point contract of 4337 you do need a slight modification to the bundler okay in order to use this transaction type

Tim Beiko: okay got

it okay um yeah this definitely feels some like something that you know we should figure out in the next few weeks at least even though we we may not have like a full and final implementation um if if we can at least sanity check that there is no sort of blocking concern here um yeah that'd be really good um anything else on uh the EIP okay great um yeah thanks everyone for sharing um moving Ean you had posted uh a fair bit around uh 6110 and and the whole messaging

scheme there are is Ethan on the call

I am yeah

oh

Tim Beiko: nice do you want to give a bit of context um yeah

sure so for um the deposits the withdrawals and the consolidations there is this new scheme I think it's 76 85 EIP and there is a problem with that with the optimistic sync that I noticed um right now in Nimbus what we do is to accelerate the syn that we um only send every X blocks to the El like we we do like um breakes in between during sync

so that we don't continuously interrupt the Y while syncing and we can do that because the CL can um check that the chain is consistent with regard to the block hash like when there is a new payload FCU the El does at the very least it does this block hash check and we sort of integrated this into the CL so that we don't have to send all the payloads so one problem here is that with 7685 it seems that this is no longer possible because there are now fields in the El block header that are not in the CL execution payload anymore namely this

7685 requests tree so it it like it is no longer possible to compute the block hash from CL payload um so which

Lightclient: part is not available

uh this requests tree but

Lightclient: you can compute you can compute the request tree like you have all of the requests in the execution payload head header and body all it is is a matter of if you're going to implement the optimistic sync you need to understand 7685 because 7685 only comes into play when you're Computing the execution layer block cash so once you know that you can compute the request Header by doing the typed

rlp encoding

so um in the like for the conso they are not even in there but um for deposits and um and withdrawals they are there as separate lists and it would be possible to reconstruct um maybe I'm not even sure like they could be interleaved like I'm not sure how they

Lightclient: can't 7685 defines the ordering so the ordering is based on type so if you have a type 0 7685 request it would be the first thing and then within the type zero request whatever type zero is can Define its ordering like int type then

you'd have type one type two Etc

so why do we have separate lists in the payload then and not like why do we combine them in the El but not in the CL

Lightclient: I propose 7685 because on the El it feels a lot more cumbersome to continuously extend the header and the body and if we're going to be adding 3 four five six plus types of elcl requests it feels much simpler on our side to do it this way any El that don't agree with that feel free to like mention this but that was like how I felt and what the feedback I was getting while we were implementing 6110 and 70002 was I didn't specify to use

requests on the CL because I got a little bit different feedback that the cl would prefer to have the list flat within the payload and that's fine I don't think that there's a reason to enforce the exact same format across the layers we can do it and something to discuss but that's why 7685 was created

okay that that at least explains the motivation thanks for that so is there like uh is this still the preferred design overall or is there um a way to explore like just to keep it separate lists or like how much of how

far down are we in here

on the E or C on the EO

Lightclient: I think most people prefer the single requests I'm like open to removing 7685 but it seems on the E we're we we're not really built as well to continue extending our header and body each time we do this like we have to Plum a lot of code through and for us this makes the request much simpler

okay I'm not sure if that's only gu or also the others but uh another proposal that could simplify it is if we

just align them completely and do the SSC transition of the block header to match the payload header then it's one data structure for both of them like we have discussed this when withdrawals came up and I think SSC is still like a long-term goal to do as a transition and I think it would be a good timing to use like this three new trees that are being added as well as the 7702 transac ction type

to like it it's it's all additional stuff that would benefit from SSC in simplification less data conversion no more endian back and forth we could also switch to engine API to SSC like it would unlock a lot of things and I think getting it away before verle is a good timing um I I know that you have mentioned that in gu that there is no good SS Library yet for go so that's indeed a bit of a work that would be required but I think it's better than having to redo

all the Plumping over and over again because in s it's trivial to add a new list to a to a container like we do this with every Fork it's it's no problem

to

Tim Beiko: to be clear these I guess these are like two different concerns right the first is um the the information you get in the payload does not sort of easily allow you to to skip blocks dur an optimistic sync um and then the second is you know if we're going to add all this information maybe we should add it using ssz the is okay um I guess just maybe just to finish on the first one before we discuss ssz my sense just skiing through the chat is like most of the El's if not all of them

do like S6 85 a lot and um it does seem like based on what like client was saying that you would be able to reconstruct the tree on the CL side uh even though the information is on like the block header um do like yeah I I guess is there a reason why this is not a a viable solution for for Nimbus

I mean I would have to check how much it would be like um in in the CL right now we have um separate lists for the deposits and the withdrawals there is no list for the consolidations but maybe they can be extracted from the

state transition function or something um well right

Lightclient: now consolidations are not in the El requests because right now we don't have El triggered consolidations

okay I I I mean I don't know the details there but I saw this type two request somewhere but if they are not there then even better um so what we would have to do is to convert the deposit receipt and the withdrawal request um back to rlp to Little Engine right rlp and then create mpts in that 7685 to reobtain the root hash of the tree

right and then we can continue to compute the block hash is that what you're suggesting or

yeah

Lightclient: and this is about the same work you would have needed to do if we were extending the list like we were still going to encode it with big Indian we're still going to npt it now it's just instead of having in mpts we just have one and when you encode you put the type prefix on it

sure yeah it's it's uh the same amount of compute but it's conceptually still a Divergence between the two um layers right so yeah I think this first

um request to like that it's not possible anymore like that it struggled with the optimistic sync I think with that conversion it's no longer a primary concern um I still think it's a bit ugly to diverge there but that's more like for the other um point with moving to SSC but that's no longer a blocker for optimistic

s okay um okay so let's

Tim Beiko: Okay so I guess yeah for for this specific sying issue um if

let's assume that this works and if it's not the case uh obviously um obviously we can discuss on a future call for ssz itself um this is obviously like a fairly substantial change so I I guess I'd be curious to hear from you know El teams like given all the other stuff that is being considered right now um you know there's like eof there's a 7623 that we were going to talk about a bit later um and then uh there's this bunch of other eips as well you know do any El teams feel like converting some of the objects to ssz is it's like a something they would like to

prioritize in this

work okay so weak no by bre

I mean the the the question is also has anyone actually looked into it

Tim Beiko: because I mean I think people have generally looked into ssz over the years in like different context so obviously yeah like obviously the the specifics of the implementation matter but I think

yeah my my sense is we probably have a a general feel of like what it implies to to do s and also what it implies to maintain both ssz and rlp on on the

e

um rlp is fine it's about the miracle Patricia tries right

Tim Beiko: right sorry okay so yeah red seems to have it would like to avoid Basu as well um anyone feel strongly in favor of doing it

um I'd rather do it now than do it in

oaka

Tim Beiko: right

like one thing that we have as well is there is this EIP 4788 that put the beacon route into the state and now with Electro there are a couple containers that already start to break like um if you have something that consumes a proof based on EIP 4788 after Electra that verifier stops working because the shape of the proof changes and now with Electro when we break them anyway it's another opportunity to like just do the timing I know that it's

a lot of work it's it's a lot of mechanical work that does not primarily benefit us developers but um there are two questions like one is do we ever want to do it and if we ever want to do it then do we gain anything from delaying like right now the new Fork it adds another MPT to the yel like this 7685 requests tree it adds a new transaction type with 7702 and it breaks all the generalized indexes in Beacon State and I think also execution payload

header so it like every Fork adds more work that needs to be converted

Tim Beiko: right I guess yeah the trade-off there is the more we wait the more stuff there is to convert the ssz when we finally do it and then if we delay doing it it means we get to do everything else slightly quicker because um yeah or or we get to do more things in the same amount of time um yeah my sense is yeah there's not really any support from the El side to do this in this Fork um obviously if this changes we can reconsider it but um yeah I it really doesn't seem like uh

any of the El teams want to include this Within pectra I don't know if anyone else

there

like how are we on the state of s libraries is it only go that doesn't have one or is it the same problem for the other um teams

on the Basu side we have um a moderate a moderately complete SS implementation but we really only uh exercise a subset of it so um it would we' probably need some more work and attention but I don't think we have the same level of uh blocking as G does currently

Marek Moraczyński: so on another mind side we uh

written our own s Library which is not uh used uh on production so uh we will see on devet how it works Etc

got it

Tim Beiko: um any other comments questions from anyone else on ssz

Piper Merriam: yeah if we don't do this now aren't we going to just run into the same problem next time when this comes around and the work hasn't been prioritized to

get everybody to have good ssse libraries like isn't this just the same problem later as it is now

Tim Beiko: yes and it's a question of what our priorities are now versus later

Piper Merriam: and and if doing now makes us faster later doesn't that make a pretty strong case for doing it now even though we're not ready

Tim Beiko: well you know it depends on like what's what's the value of getting it done what's the value of getting everything else done like have you know say that this took three six months extra do we think it's more valuable to do this now or to do you know veral or

44s or eof and yeah that's effectively the tradeoff yeah I guess yeah uh just because we have other stuff on the agenda any other questions concerns about ssz otherwise I think yeah it probably makes sense to continue the discussion I think but it seems unlikely we would we would consider it for this spk okay um then moving on I guess Ethan

yeah I were is the two the two issues was the syncing and then um changing stuff to ssz while we are doing it

um did that cover like the main

yeah um I had some 6110 related specifics as well regarding ordering of deposits like there are two parallel deposit mechanisms and deposits may get reordered but we don't have to discuss that with everyone and the third one in the um GitHub comment was consensus related regarding at the station type so it's not relevant to this call

either um yeah so I think that covers it for me um I will personally try and get SSC onto a devet um with Nimbus I guess and maybe that could ex um that could help gauge the exact scope that's needed because I don't think it's a six month thing that

Tim Beiko: yeah I think that would actually be it would be useful to see like what the implementation was like what you know what things were harder than you thought they would be what things were easier than you thought um so yeah there's definitely value in that um Mikel you have your hand

up

Mikhail Kalinin: I just wanted to add on the 6110 stuff and um not the um order the processing uh deposit order not in the order they had been submitted to the contract uh this is really a fair concern um I think we need to do more investigation and talk to um rocket pool and probably other Sten pool is if it breaks anything on their side uh but basically U the situation can be as follows during the transition period the e one data poll will um will be in board in will be filling the gap between like uh the um last processed uh um deposit before the fork

activation and the first deposit that had been processed according to the new 6110 logic um and uh those Gap is like deposits that were submitted to the deposit contract before the new ones obviously um and yeah the old deposit can be finalized already and then uh someone can submit a new deposit that will uh create a validator with different withdrawal credentials and then the when e one dat poll fills the Gap um the one that had been submitted before the Elder one uh will be a top up to a new withdrawal credentials so probably the breaks some um some some Stak in some Stak in

pool design breaks the security so yeah that's fair concern just wanted to highlight that and yeah

Tim Beiko: thanks we be investigate thank you anything else on this before we move on okay uh next up um so two uh eips that we had CFI uh guess sets of eips we cied for fork um have some updates so uh first eof then um there were some potential issues around 7623 so we'll do

eof first um I know there's been a couple breakouts uh since our last since our last call but yeah any notable updates to share um not too many the first breakout we had on May 1st it wasn't too well attended because of a major European holiday um if anyone wants to learn about more about eof they're always welcome to show up and um maybe not necessarily during the meeting if we got a large agenda but you could ping me or any of the other people involved in eof you're trying to you know get tighter grasp on it um but as far as yesterday's meeting we're just um sewing up the very final um states of the spec um there as opposed to the uh evm channel in the Discord we uh the big the big thing that's been uh working out for the past

month is we're formally removing the TX create and the init code transaction from the first revision of eof um is not essential to it and we're going to rely on the existing create transactions and there's a specification there for how we're going to um handle eof without requiring a new transaction type or an regular State change those are no longer required for eof V1 um but you know just cutting up the corner cases that everyone um discovers as they do the final uh pieces of implementations in their clients um as far as testing I'm writing a lot of the uh execution spec tests for it um using the various clients to guide where I get the appropriate coverage to make sure I cover all the pieces in in the LS that I'm I'm available to see um so yeah that's that's an update from my

perspective Alex probably has more to add

Alex Beregszaszi: yes please Alex I also posted the links um but three updates so there's a meta EIP which has been merged um and which list the all the relevant theps um that's 7692 uh Danel mentioned the removal of TX create uh for those unaware the TX create was the the way to create contracts and that uh relied on a um Creator contract basically which needs to exist in the state um instead of this we came up with a more simplified approach it doesn't require new transaction type doesn't require the

special contract uh it uses the existing uh creation process uh used in Legacy um but the design is forward compatible so we could introduce TX create in the future um but there definitely removes um the transaction changing aspect of implementation and testing um so basically testing uh really has to deal with um the evm level and it doesn't need any new special rules for transactions um and this new transaction EIP or like this new contract creation AIP is 7698 um and the last update I wanted to highlight is uh we always had or at least for the past couple of months we

had an implementation Matrix um which lists U the eips the tests as well as um the client implementations and language uh solidity and Viper implementations this has been updated uh this week and if you take a look at it it seems that there is an EF implementation in almost every single uh client with the exception of argon um but in some of them it's kind of a stale imp implementation um so in ethereum Gs it is definitely a still older version of EF um and the wiper implementation is also old um but the implementation in solidity is being

worked on uh as of um the past two weeks um and I think go and Ne mine those are listed as work in progress uh it seems there's active work going on in both of those um and those are using the the latest pack so those are not really stale uh pieces of work um I think that that's my addition

Tim Beiko: awesome thanks for the update um we've been waiting on the M for a couple weeks I know there was some delays in getting it merged um but given eof is CFI does anyone object to cying the Mela EIP um which lists all of the sort of individuals eips just so it's

easier for people to reference um and if we do that does make sense to also include uh the creation transaction EIP 7698 I guess any objections to this otherwise um I'll I'll do it so at least it's up to date with the latest spec okay um any other questions comments concerns about e okay well yeah thanks Dan and axic for the update next up uh for EIP

7623 um I believe we have William on the call who had some concerns that he wanted to raise um so yeah William you want to take a couple minutes and uh yeah walk through those oh oh William are you on the call we can't hear you yeah I had some issue uhing uh I'm trying to present this uh slides yeah we can see everything

good

all

right uh so I'm trying to discourage a pattern of uh metering gas so I have some examples uh first consider a taco stand that charged the maximum of $3 for taco and $5 for or salads people that want to buy tacos and people that want to buy salads can work together to save money uh similarly if the there was a discount where we charged less for combining tacos and salads uh there'd be a way to make money Again by combining where one person buys the discount and sells their unwanted uh components to the people that need them

uh and so uh this brings us to eiip 7623 uh which charges uh gas according to call data so there's a maximum function in the gas used to try to uh uh split out the call data gas so that it's worse for some people and the same for everyone else uh this has some a problem called gas Sheltering which I call it because it's similar to tax Sheltering uh in that you can offset uh the costs by uh combining for example gains and losses and tax Sheltering and call data and execution in gas

Sheltering so uh because uh the gas is no longer marginally priced which means that each incremental units of computation uh doesn't cost additional gas it causes some economic problems with the way uh with the market and incentivizes some Strange Behaviors uh first consider the case where the call data gas is greater for a transaction so a user's gas would be determined by call data referring back to this formula uh this means that they would pay 12 gas per token uh and so uh such a user they can add execution gas to their

transaction and it would not increase their gas use and therefore they can sell that gas uh to someone else that would like to buy it uh and so there's no price at which that uh cost is uh ineffective that it's always always a profit a sale uh and so uh this combination has some uh dangers to it which I'll discuss later uh but there's another kind of combination the kind of combination when the execution gas is greater in this case you would like to pair up with someone who is using a lot of call data so this would allow you to save 2third of your call data

cost uh so effectively you're arbitraging uh to save gas uh and this results in a lower effective gas price for users that combine then users that don't combine uh because you can consider the gas that they would have paid without unlocking the gas uh in the world of me uh me is execution dominance so Searchers would want to batch with call data users uh so they would be looking to increase the number of call data users and centralize them so that they can win the gas auction uh another topic is that l2s who post large amounts of call data uh would want to batch with searer transactions and this can cause

centralization in the gas market uh and other kinds of problems as that's a rather monopolistic power that they would have uh the free gas uh so I also compare this to gas tokens uh for gas tokens there was an efficiency of 1 half which is also possible in the first case I discussed uh there's in in uh incentives for creating and destroying uh accounts for gas tokens but uh for gas Sheltering the incentive is for additional call data this means larger blocks than would have happened in The Organic Market uh just due to the incentives of attracting the call data users uh into the Sheltering scheme uh so uh this means higher gas prices uh

for people that aren't participating in gas Sheltering and uh a lower block gas limit therefore because of the possibility of 2x one difference from gas tokens is that gas tokens uh gas can be used on anything whereas unlocked gas must be complimentary uh vitalic released a blog post discussing this today uh and uh so I reiterate that the reason the 50% gas REM frund was removed is that uh it allowed larger blocks uh than should be possible um and so uh I recommend inste a much simpler solution to just increase the cated gas for everybody I've written this is EIP 7703 uh so it keeps the regular gas use

formula thereby not introducing gas Sheltering uh the largest potential block size is reduced by the same amount so the worst case is the same but everyone pays the same rate uh regardless of how much execution gas they're using uh so as vidik mentioned in his blog post uh a better scheme in the long term would be to separate these different components uh into different gas markets similar to blob gas and that would preserve marginal pricing uh that's all for my presentation uh thank you

Tim Beiko: thanks William um yeah vitalic you want to go next

Vitalik Buterin: um yeah no so thank you very much for that William um so I think um a

couple of points in response right so one is that uh all of these downsides do need to as usual be weighed against the upsides and the upside here is the pretty large upside of being able to decrease the theoretical maximum data size of a block from 1.9 megab all the way down to 0.6 megabytes uh all not including blobs while keeping almost all applications the same price as they are today with extremely few exceptions so it's uh important like there are basically you know we we keep in mind cost it's also importantance to always

keep in mind what the benefits are in the background I think uh more specifically uh with regard to these secondary Market concerns I mean I actually fully agree that this uh is a a valid problem in theory and that if secondary markets like that happen that would be a a bad con quence but I think the M reason why I'm not concerned in practice is that basically the total addressable market for this uh kind of Coincidence of wants is extremely tiny right and the reason why I'm confident about this is because Tony and I or actually just Tony in this case did some

analysis of uh which transactions actually are called Data dominant and by how much and the answer turned out to be like especially with the 1248 pricing as opposed to the earlier 1768 version very few right so starkware proofs Stark proofs increased by I believe around 1.3x and then um Layer Two protocols that have not moved over to blobs so things like inscriptions and scroll uh go up by like 2X or uh sub somewhere between 2 and 3X though I think uh as a very recently scroll has switched to blobs and uh basically I think all of these call data use dominant use cases

are switching to blobs and uh the number of Remia exceptions is like basically darket and a couple of mle proof users and like it is totally true that they could uh make some profit by auctioning off a tiny amount of extra execution space that they have in theory but in practice um just like if you actually look at the numbers if you actually like divide the by the the total amount of gas that's happening like the market is just not large right and that's not something that was through with the uh gas token Market because gas token markets were just un like they did not require this kind of two-sided Coincidence of whatting right they just

the required people who are willing to save up gas when gas prices are high whereas in this case like you actually need to have this uh two-way agreement between an execution dominant user inequality dominant user and the constants in this EIP were chosen such that the number of uh call data dominant users is like actually extremely small um so that's the reason why like I'm actually not particularly worried for the short term but like I do I do accept that this is a valid downside of this EIP and like I do uh definitely favor moving to a multi-dimensional model eventually I think the reason why

we ended up moving away from just like a raw 4X bu in called prices which actually was Tony's in mine uh idea like about a month or two ago is basically because uh that would like that actually would be extremely punitive for both starkware and a lot of like ler one layer two to layer one bridging Merkel proof verification use cases and a lot of other things it would like it would bump up stuff that's like pretty critical layer Layer Two ecosystems ongoing decentralization by a factor of four and so that could actually be

Tim Beiko: okay I think Zoom

crashed for everyone okay are we back okay yeah I think Zoom crashed sorry about that uh oh uh okay so vitalic you were talking when uh when it crashed but um I'm not quite sure exactly where for for

okay Ansgar you had your hand up

Ansgar Dietrichs: how could to people and that of course is not a very principal way of handling these things but that there's actually like a like a principle behind this that and that that's it's like a common misconception that that pricing on ethereum is basically trying to account for the like proportional cost and that that that any compute causes

for for noes in the network but that's not actually the case and that's you can you can kind of realize that by in two ways right one those notes don't actually get any of the money that you pay right like you don't that's not distributed across all the nodes that actually need to executeaction but also it doesn't depend on the gas price if there's only one G gas price then then all the the the the cost you cost for the nodes and network is basically free and if it if it's like 100 G all of a sudden it's really expensive it doesn't there's no relationship you're not actually paying for the for the effort you cost it is a purely a congestion pricing mechanism meaning we have fixed resources on the network we are just saying hey this amount of compute this amount of data this amount of bandwidth

we we are willing to give to the network per per amount of time and so congestion pricing is just a mechanism to allocate that to the the person that values it the most at any given moment of time right so that's why people pay and so actually this like this onedimensional way of doing this that we do in ethereum right now or I guess now with for for two dimensional but onedimensional in the normal evbm side of things it it is really inefficient in that most of the time we are only using a fraction of of the available resource right we always have to to plan for the worst case so we have to make it price thing so that if if someone only uses compute that the block doesn't explode too much or if someone only uses data in an entire block it doesn't it it does um blow up

too much but most of the time people actually use some sort of mix of the two and so we are way underutilizing the resource of the network so this is just dead weight loss it's just an inefficiency in a network and so this basically is just a very like a small example of a class of mechanisms that start to make this more broadly available so now basically we incent specifically incentivized behavior and so this is why this funding in general is not a bad phenomenon that's actually good thing like we incentivizing behavior that tries to push the usage of each individual research closer to its to theoretical limit and so indeed of course Details Matter and so I I do agree actually that these concerns to some extent apply because of course it's a more pratic mechanism it's not like a theoretically completely a sound way of approaching

this but but I agree with ralic assessment that it's good enough and again it's not just a pragmatic fix but it actually has like a deep underlying principle that there there's this huge inefficiency right now in ethereum and we are basically removing this to some extent

here

Tim Beiko: thank you um Tony

Toni Wahrstätter: yeah um I just wanted to add that um I do agree with William so there is this theoretical threat but I also agree with ancan vitalic that it's um not very practically viable especially thinking of such markets would require trust among the participants and also a high

degree of coordination and imagine you as a as a l do you want to post your data down down to L1 and you don't know which address will post the data or where the data will eventually be um from a practicality from practicality standpoint you would need custom indexes and all that so I don't think it's very viable and regarding the multi multi-dimensional fee Market I also agree that this might be um more close to endgame solution than um 7623 but I think the main goal so the main goal um 7623 was to kind of diffuse this dos Vector of Big Blocks um especially thinking of increasing the

blob count or in increasing the gas limit and at least until Petra I think it's the most viable thing that we can do

I'm

Tim Beiko: Ben

Ben Adams: um could do something simpler which is the zero byte discount is only applied in the first n say uh 1,24 byes of C data after which it reverts to normal um which also has an advantage that when the El is trying to work out the gas price of the coold data

it doesn't have to recount all the zeros in the megabyte if it's a megabyte one just has to do a th bytes and then use the length for the rest

Tim Beiko: yeah and there's a couple comments in the chat around uh some of the El devs you had um expressed some concerns about it so on the get side um and then on nether mind as well um anyone else have just comments or questions about

7623

Charles Cooper: um I have a question which is um has uh in shining call data

compression been considered like if you have like run length and coding or maybe some very simple algorithms you could also reduce call data by a lot but without uh needing to change pricing

um it inflates it inflates in Json yeah

Vitalik Buterin: yeah I mean I think everything is wrapped in Snappy at protocol layer already right

Charles Cooper: yeah but is it like cheaper if it compresses well with Snappy I meant from a pricing perspective

Vitalik Buterin: right c um currently it is not at least at at oan I'm not sure if any elers have started properly

accounting for that I mean ultimately I guess any like cont s are always able to individually de compress stuff the question is like does it make sense to like basically make Snappy yeah can brush a breaking pile I mean instinctively that feels like a pretty complicated thing to do and like trying to enshrine that might uh prove to be something that we regret if we discover other congression algorithms but I'm not against exploring it

Charles Cooper: yeah because everybody's compressing it anyways so why should you um kind of punish people who are making call data that

compresses well

Vitalik Buterin: right yeah that's fair and I mean I think like the zero disc part intended precisely for that reason right because lots of zero bytes are by far the most uh common case of data that is big in terms of raw bite count but that does compress very well

I'm georgeos yeah your hand up

Georgios Konstantopoulos: yes um I wonder how does the group think about cold data changes in relation to blob count increase or decrease and I I joined late in the call so maybe this was discussed already but

I recall that there was a blocker item that said we cannot adjust blobs if we don't do some data analysis over the impact on the network and it seems like an increase in the call data would need to be accompanied by something like that so I wonder how do people think about that

Toni Wahrstätter: yeah I have looked a bit into that and I think it's it's hard to tell so if if for example a blob increase would already be doable or not but what you can definitely see already is that blocks that are bigger and with bigger it just mean three times the average so not even getting close to the max um they are much more likely to be reared

or you can also see that weak validators um cannot attest to those blocks or don't attest or don't see the blocks Etc and you can also see that Builders are already discriminating against um yeah certain blocks that are just too big because they might want to deliver the Block in the last millisecond so in the last milliseconds they would throw out a lot of other transactions um right

Georgios Konstantopoulos: so so I'm in agreement that like these are all issues I wonder does the group think that cold data increase comes with a blob count increase and if so is anybody doing the research required to get very clear data driven numbers for whether we

can do that because just doing the C data increase in the vacuum honestly doesn't seem you know like it it seems like it doesn't like solve much of a problem in

aring

Tim Beiko: I think um Perry from the EF devops team had like a stub EIP about this and was planning to you know help with some of this research in the coming months um but yeah I I don't know to yeah to to what extent like it's it's been started or anything like that

um than R

Dankrad Feist: uh yeah I think I just wanted to say um I feel like at least we can consider increasing so that the max stays the same if we had this

EAP um because that shouldn't make things any worse than they are

Georgios Konstantopoulos: well that's also my strowman view right but I wonder like just so that we can have a good process about going about these things I I do Wonder like if we should be coupling the two conversations and if so if we should assign someone a dedicated individual that goes and does that research because otherwise it seemed like we could have we could be having this conversation 3 months from now and being like hey has anybody done the the work and if we think the work is important then we should prioritize it and pick a person to go and do it

Tim Beiko: does anyone want to volunteer for this and yes I guess the work would be

benchmarking clients using your larger blob count potentially you know ideally doing multiple different counts so that can get a sense

Georgios Konstantopoulos: basically basically it will be a lot of work it might not be glorious work somebody has to do it like maybe we will have capacity to do it but like I'm pointing out that like this work must be done and uh I think having conversations around these kinds of VIPs while we don't have any person doing the work is kind of like a a weird use of our time on allore devs I feel like we are aligned on the general like type thing but like to move the ball forward it seems like there's a clear block and I feel like we need to

like align that somebody needs to go and own it

I'm Anar

Ansgar Dietrichs: yeah I just wanted to say that this is this CP is not only about making room for blob increases but it in a way patches an existing vulnerability of the network just because we've already seen from the the from the tests block tests from from last year that as we reach the current maximum um maximum possible box size the network does get more like less stable and so actually just getting having a better upper Bound for the C block sizes even if we don't use that room for blob increases is already I think very desirable for a security and and and stability of the network point of view

Georgios Konstantopoulos: right but then you going to think who who whose gas prices do they

make more expensive as a result of that and so on so there's a bunch of like stakeholder analysis that should be done that uh we should take into account

Tim Beiko: I think that has been done though like Tony I guess yeah

Toni Wahrstätter: yeah I just wanted to add I will send you the link after but we have actually done a lot of analysis on not only which accounts are affected but also which functions are most affected so what functions are the people calling that would be affected um by 7623 so I can I can send you a table and it's so we have already done some analysis on who is affected and who not and I can already tell you I think it

was 98% of all transactions are unaffected so if you're doing token transfers bridging reaking I don't know it's all unaffected so the only the only accounts that were affected are basically those that are still using eum for data availability then the largest part that is affected are users that are doing Simple e transfers and putting um some messages in the call data but this is very negligible and apart from that there were big mercel proofs and Starks that are still affected but by reducing um the the token cost to 12 it's uh yeah the this um increasing cost would be

manageable for for all those affected parties

gotta

Tim Beiko: thanks any other comments questions on the CIP uh we only have five minutes left um okay um if not uh Charles had an EIP uh that he wanted to present um non-reentrant and re-entrant op codes um Charles are you still on

Charles Cooper: yeah

hey uh so you can see here I drafted an EIP for um an OP code to prevent reentry see um I checked this morning and I was surprised to find out such a thing does not exist like even existing IP um this kind of like a reaction to um EIP 7609 not being included in pectra because that seems like the logical way to for to give application developers the ability to like prevent reeny cheaply um but anyways this is the alternative um you know you know it's pretty simple we have two op codes and it uh sets the Rey flag for a contract I

mean it basically looks like what you would expect if you've thought about how to pres prevent re-entrancy in the VM you have a flag for the contract and it basically lasts for the lifetime of the transaction it gets cleared um and it um you know rolls back when you get a reversion or something um anyways so if you compare this to 7609 um I think EIP 7609 is a lot more elegant it also solves um you know kind of the basic problem which is that um engent storage is way way overpriced um and I'm not sure why um it was not really considered and I didn't really get any feedback or

anything so anyways if we don't want to do that then like please give me another way to prevent re-entrancy cheaply um and I'm happy to take questions about either this or EIP 7609 or the payoff code EIP because those are all extremely important to helping users prevent reentrancy

CH

Georgios Konstantopoulos: Charles who are the ideal people that you would love to get feedback from because the room is quite diverse and honestly I don't think everybody has full context on what the right thing to do here is so if you were to point at like a category of skill set in the room what would that be

um cevs who are

Charles Cooper: familiar with

um pricing for op codes or like uh re-entrancy prevention mechanisms

Tim Beiko: I guess there's two questions in the chat one is proposing just using op Zeppelin's re-entrancy guard and then like client is asking did we not ask T store to address this

Charles Cooper: we did add T store to address it but it's too expensive and that's what EIP 7609 is intended to also address but um I didn't get any feedback on it re-entrancy guard same thing it's too expensive re-entrancy guard is a it's an

abstraction you you can use any implementation you can use transient storage you can use this non- rann op code if it exists you can use storage um it just depends uh what makes sense from an implementation perspective right now tload and t- store are basically too expensive for people to opt into using it by default and it's priced the same as um warm storage which doesn't make any sense because it doesn't interact with access lists and it has um kind of simpler semantics

and

Tim Beiko: I guess yeah we have two minutes left anyone on the client teams have feedback or questions concerns

this

um iume

Ben Adams: the only worry on it would be um increasing the maximum memory that you could allocate in one transaction on 769 or uh for lowering the cost of

t

Charles Cooper: uh that's address in EIP 7609 uh which I'm begging everybody to please read because it actually improves maximum memory consumption uh it lowers the limit by Design so it's uh cheaper in the average use case in the most common use cases and it's more effective at preventing dos than the existing pricing schedule

Tim Beiko: okay any other questions

comments um we have only a minute otherwise I guess people can continue this on the eth magician thread for the EIP okay um anything else before we wrap up okay if not well thanks everyone um talk to you all soon and I'll post a quick recap of the call on Discord uh in a few minutes have a good

run thank you thank you to thank you byebye thanks bye thanks time m

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