All Core Devs - Execution #183

Transcript

[Music] than [Applause]

Tim Beiko: and we are live uh for acde number 183 um good job for everyone making it on time with the daylight savings uh change I think next one of these uh the Europeans will have their local times all messed up uh for today uh we'll talk about the fork obviously um and then quick shout out to move all the eips to final if you're an EIP author um we should also quickly touch on Gordy um as we're shutting this down after the fork but it looks like it's already sort of uh falling apart on its own uh then uh tons of stuff around the next Fork

pectra so um uh we have Dan on to talk about the impact of 374 on users uh Alex wanted to talk about uh some changes and tweaks to the BLS recompile uh Mike had some stuff on inclusion lists we have some stuff on call data some and then a bunch of op codes if we make it through this and still have time um Paradigm has been working on some research around uh the impact of State growth and how it's uh distributed both in terms of uh types of contracts and then the the rate of grow over time uh we have this uh these couple retroactively applied eips that we had to follow up on and then uh lastly we had these testing calls that

we've been running uh up to the fork um that gotten shorter and shorter as we got close to the fork and uh we're seeing if we still want them um okay uh I guess to kick this off um the fork went well great work everyone um we saw a little participation drop for a few minutes that seems to have resolved itself um but anyone notice anything interesting or that they wanted to bring up and discuss um as we live

Danny Ryan: even just a quick like perspective on blob usage thus far would be interesting if anyone has

Tim Beiko: yeah Terrence

you've been manually inspecting every blob that came through I think

Terence Tsao: I have two point the first point was that we were kind of worried that the blobs will be ar uh arriving later than the block because of their typically heavier than size and from my first observation for the first 24 hours that hasn't been necessarily the case um I see like 50% of the time blobs are arriving earlier than the block I suspect typically that made I the I suspect what happened was that the relayer from M boost have some building optimization that just costed The Blob right away and then while

packing the block but then I try to confirm that with the flash Bots since their relay is open source they say they don't have an optimization like that so I suspect there may be like some private Source relay or somewhere that has some build in code that does this so yeah and then the second observation is the four choice rate so um I can post a graph after so the first 24 hours um my local note see like an average increase of three to four reworks so yeah I'm curious what everyone's know thinks but yeah C my not is more than uh three to four rewards per day

Danny Ryan: sorry three to four per day and what

was it before the fork

Terence Tsao: uh okay so before the fork is on average 15 rewards per day right now I'm seeing about 17 to 18

okay and these are generally depth one yeah yeah this ex

Tim Beiko: thanks for sharing

Parithosh Jayanthi: um maybe I can go next based on um Le the satle data we have we're seeing pretty much the same in terms of um there are some RS we're seeing that to or or sometimes three but they don't seem to be recurring and neither do they seem to be unique to post f um in terms

of blobs we're also seeing blobs arrive within the 2 second Mark mostly um that's really least what the heat map says and this is for ingesting something like 6,000 7,000 blobs that have come through since the fork um but otherwise I think we're not noticing anything unexpected

Tim Beiko: nice anything else

are we

Danny Ryan: is the base Fe still at the minimum of the block Bas has started ramping up

Lightclient: I think it's mostly a minimum still

the base fees is at minimum but like it's like it's getting close like it's around the point where if there was much more demand the price would

Danny Ryan: got okay yeah it be doing it right now

oh

Tim Beiko: okay any other observations comments okay well again great work everyone this has been a massive massive work uh that we've

worked on for like over two years so um very cool to see go live and be so uneventful um yeah we have the blobs and again if you have there wen't just the blobs that shipped bunch of other eips if you uh are the author of an EIP please move it the final now so we can uh wrap this up spec-wise um I'll start harassing everybody about that next week and then lastly uh Gordy so uh we agreed to deprecate Gordy and shut it down after this Fork uh what we originally agreed to was basically uh at the earliest one month after uh it went

live on mainnet so you know call that April 15th um it seems like the network is is pretty much in a state of of chaos already where there's less and less operators on it I guess does anyone have any objection to just still keeping the date of April 15th as like a heads up for the community letting people know that like in the meantimes it's already not super stable but um yeah at least keeping some nodes from like client teams and devops running until then and um on April 15 they'll being fine shutting you off um yeah Alex you'd be surprised by the things

people do not know um I Heard recently that prism users didn't know they had to upgrade their execution layer so um probably worth another round of announcement if um yeah just to give a heads up okay um sweet then moving on to the next Fork uh Prague and Electra so uh we've been discussing this uh for the past couple calls and um just's kind of a mix today of people who want to provide additional context perspectives on some eips that are being considered and then um I think

2537 is the only one that uh we actually want to like change something that's already been included so maybe I'll SW up the agenda a bit maybe we start with 2537 um just to get through those questions and then we can cover all the other uh potential eips that aren't uh that aren't included quite yet and uh go from there Alex do you want to kick it off with 2537

Alex Stokes: sure thanks um let's see so this is the EIP to add functionality for BLS promiles so I guess just as a refresher there's like kind of two different things here there's like promiles for the cipic curve the BLS 1231 curve they're also

pre- compiles for uh essentially this BLS signature scheme and these are like different bls's which is confusing but good to keep in mind and either way um I've been talking to various people in the community like different cryptographers different rollups um a lot of people and basically there's some things kind of not present in 2537 right now that would be good to have so I wanted to go through these and kind of get a tempature check today to see kind of what we're thinking um let's see yeah basically people want more pre- compiles and I know that's been like pushed back historically that there are already a lot in the

CIP um but yeah maybe we'll just walk through these different points and I'll see if anyone has any thoughts so the first one is adding well yeah this is where it could get wild because it's probably well at least two let's say two promiles for Point decompression so this is actually helpful for rollups um I don't know how much we want to get into it but basically right now there are the abis right now for the promiles take points on this curve that are in this like decompressed form the concern is that if you're at L2 then data is more expensive so you might want to submit the compressed points but then the concern after that is that it's too

expensive to to decompress them sort of natively in evm so we want to add pre- compiles for this um again this is something where it's really helpful for L2 maybe less helpful for L1 but this is an open question

Antonio Sanso: um as an Al Alex as an alternative can just work only with instead compressed point and so we are doing like consensus does so changing the current precompiled to work with compressed points

Alex Stokes: right let's see yeah I mean I guess the concern then is just that you know we

would

Vitalik Buterin: yeah like there would be lots of custom algorithms that call the precompile many times to do lots and lots of additions and if you add a decompression to each addition it becomes quickly nonviable

Alex Stokes: right so there's this trade-off between like computation and data and yet thinking was like data is more expensive at L2 so maybe have this here versus you know it's flipped on L1

Tim Beiko: and is the argument against doing this just that it's like two more pre-compiled and

two what already I me AR

Alex Stokes: for all of this will just be there's

way too many pre compiles because I think there's already nine or so and then this will just keep bumping it up

Vitalik Buterin: on the uh too many too many precompiled points um this is like a bit of a a bit of a broader topic but I feel like at some point we should uh revisit the topic of uh doing eips that replace existing promiles with existing code implementations and that would be a path to like actually decreasing the number of freak PS that we have to deal with over time and espe now that we have M Copy the most obvious one to start with would probably be the identity

precompile um and others would be like some of the some of the less used hash functions for example and that would and then the idea would be that that could um no not swap them for new OP codes like swap them for pieces of solidity code that do the same thing yeah so from a user point of view it would stay the same except it would realistically cost more gas and then the argument would be that like if SL when in the future we end up doing doing modular Ari arithmetic in the evm then like that would be a path for eventually also swapping out a decompression promile with Sol code

Antonio Sanso: anyway I think that I been thinking

yesterday while writing the the vectors test test the vector sorry it's like if we really want to reduce like number of promiles for this EIP maybe we can uh we can merge the scalar multiplication with the multi multiscalar multiplication at the moment we have two separates but we can do like we do for pairings I mean you can do like multi pairings and this one one precompile so like we can actually remove the scalar the two scalar multiplication and having the multi the MSM that takes as well one as parameter that is allowed at the moment as well

Tim Beiko: I don't remember why but five years ago when we were talking about BLS

I think the precompiled were all there was like much less of them and then after a bunch of arguing we decided that like different pre-compiled for different operations was a better way to go um so happy to open up that can of worms again if people feel strongly about it but um I I don't know that we're bottlenecked by the actual number of addresses used right it's more about the total complexity of the thing or is there a reason why using more addresses is is somehow an issue it's it's not more addresses

it's

Marius van der Wijden: it's just we expose a greater surface for buck basically if we like if we have a like if if we have this the the set of pre-compressed that we have right now we don't we don't care about any bugs and decompression correct yeah yeah inpression so

yeah

Tim Beiko: yeah so so the new functionality itself like yeah yeah that's something we should debate but like whether it's exposed through 11 addresses with individual pre-compiled per operations or like say one huge merged address like that sort of orthogonal to like whether we

um yeah whether we actually want to do the decompression

Alex Stokes: right so yeah another note on that point is I'll be talking to the layer twos on the next roll call um I think they might be next month but my plan is to get more direct input from them because I think this one impacts them a little bit more directly than another one

this is also one of these situations where you could split it like if we're unsure about the decompression if we're still arguing about the decompression promiles when we get to the next hard Fork we could ship BLS in Petra and then like ship the decompression pre-

compiles in the following Fork if it comes to that

Alex Stokes: yeah that's an option so yeah I mean maybe I can just quickly get through the rest of uh these open questions here cuz basically yeah they're just adding more functionality um You probably don't care about the exact details but just to round them out uh there's essentially three groups really with B2 381 we have pre- compiles already for first two groups there's a third group and it'd be really nice for cryptographic applications to have this third group again more complexity um then there was demand to

change how the current pairing precompile works because basically you give it the right inputs and it just tells you if they are equal essentially under this operation but again for different cryptographic applications you actually want to get the value back not just are these two things equal um yeah so ultimately if there are any cryptographers on the call that want to argue for this it'd be great to hear from you uh otherwise it sounds like we have to make this decision around just the general complexity of

CIP

Vitalik Buterin: one um argument against exposing GT elements and I think this is a the key reason why we've so scrupulously avoided it is basically because once you expose

GT elements you start requiring every uh like every implementation to like actually have the same pairing as opposed to requiring every implementation to have a pairing and that is like that that is a thing that increases the complexity of making a new implementation it increases the complexity of this of the specification

Marius van der Wijden: and it also kind of locks Us in for the future to this algorithm

Vitalik Buterin: right like there's at least

three different ways to computer pairing there's different lots of different ways to represent extension fields and um all of these things and there's like some mathematical way in which they're all equivalents to each other but if we make an opinionated choice on on one there just like like there is a lot of stuff that's currently not spec code that becomes spec code

Marius van der Wijden: are there are there any use cases that actually require the GT or is it just purely it would be nice to have this

there

Vitalik Buterin: definitely are like specific

protocol constructions that are like pretty esoteric use cases that I can think of um the uh one that uh comes to mind is uh basically being able to commit to a set of elliptic curve elements in such a way that you can like multiply the commitment by a constant to get a commitment to something that commits to the elliptic cve points multiplied by a constant and there's like some use cases of that but like you have to really really dig down the rabbit hole

to

Antonio Sanso: not n back is as well one of the things GT

Alex Stokes: okay so I think that was helpful I'm going to go back to these different stakeholders and try to understand better how strongly they feel um otherwise I think that's it for now

Tim Beiko: awesome thanks Alex um okay

gu the guas limit changes

Alex Stokes: for 2537 yeah yeah that's on my to-do list um I figured if the you know if we're going to change the either the interfaces or the the actual pre-compile set then we want to do that first but yeah that's on the way

Marius van der Wijden: no just just to say that there might be gas limit sorry gas cost changes to

to the pre

comparts

Alex Stokes: yeah I think there certainly will be

Tim Beiko: got it okay so yeah let's keep discussing that and then worst case if like we haven't made a decision on this um as we start working on dev Nets and stuff we can always uh implement the current version with the current pre- compiles and and go from um okay I think this was the only uh sort of already included the IP we had stuff to discuss on so everything else is stuff that's been considered for the fork

um yeah so I think probably makes sense to go through them one at a time and and and chat about them but first up uh we

have Dan from metamask uh to talk about uh 3074 and specifically the impact it could have on users um them the floor is yours

Dan Finlay: awesome uh thanks a lot Tim yeah I just wanted to make some comments in support of EIP 3074 on behalf of metamask and consensus uh you know some of these will probably be redundant for some of the people here but it's it Bears saying since it sounds like it's getting some pretty favorable support so uh I think we all know that EAS have proven to provide an insufficiently flexible system for authorization for many people and people are suffering millions of dollars in fund losses every day and uh we believe that 3074 is an opportunity for the protocol layer to

bring some opportunities for user safety um that that can then be implemented at the wallet layer um so 3074 allows EA holders to adopt smart contracts to authorize their transactions and that could eventually mean taking fully authorized oneof one private keys off of hot machines entirely and ensuring far more people are using patterns that we're continuing to refine for safety and usability in the contract account space 374 has had some criticism for involving a dangerous authorization signature and wallet have the ability and duty to ensure that that signature has the same user-facing saliency as exporting a secret recovery phrase uh but once signed the wallet will have the opportunity to permanently adopt saf

patterns including ones where a user never needs to view or export a key and a single signature can never transfer away all of their funds we all know contract accounts have a lot of benefits and 3074 can bring nearly all of them to existing eoa holders batching sponsored transactions appr proven call multisig session Keys delegation you know the the evm is the limit it doesn't bring the ability to to revoke the original signing key and it seems unclear to me at this time whether that's possible even by EIP 70 uh 7377 and others since an outstanding signature is often enforced by a third-party contract that could be unknown to the signer so I'm glad that that goal is beyond the scope

of this EIP the current draft also has added a mechanism that enables the revocation of the authorization so a hot signer could keep a revocation message available in case of emergencies found in uh new contract account even while not keeping the original signing key uh hot so contract accounts have hard problems ahead for how to bring the most safety to their users but at least with 3074 we can bring our existing 100 million or so accounts along for the ride thanks

Tim Beiko: thank you um any reactions thoughts comments I know we've talked about this a bunch uh these past couple weeks but uh hey Jen

yes

Hadrien Croubois: yeah I was wondering what is your vision for user using this authorization scheme do you expect them to only go through relayer contracts that use this authorization or do you expect them to continue using regular type two transactions

Dan Finlay: um yeah there it would probably involve eventually moving to a relayer system um similar to 40 uh to yeah 4337 because if we if we continued using type two transactions then the user would still have to have private keys I guess they could keep a gas key local and you know that's a design space that we'll be continuing to explore but I my impression and suspicion is that we'll be going towards something as similar as

possible to whatever becomes the account abstraction Norm

Hadrien Croubois: because my understanding is that every time a user uses a normal type one or type two or even type three transaction there non increases and they authorization got revoked so they need to resign them every time and you mentioned that this signature is as critical as like exporting your your private key or your seed so I'm are you expecting user to do that more than once

Dan Finlay: oh no if the user was using type one transactions directly I would imagine that they're using those to relay their authorizing transactions for the accounts that signed 3074 transactions because like you say another uh type one

transaction from the same EA would invalidate the authorization signature

Tim Beiko: any other

Alex Forshtat: I want to ask uh if you have any like particular relay uh system implmentation in mind because like I worked on open GSN and 4337 I wanted to hear like how you see uh because like one of the problems that happens is when a transaction like kind of invalidates the following transaction or even itself and like in 4337 we do a lot of like uh bending backwards to make

sure that it's it doesn't happen with all the validation rules

Dan Finlay: yeah I'm a big fan of two-dimensional nonces for that kind of thing um obviously uh you know there's other systems possible too with like you could have like a graph of nonsense or or something but I I expect that contract accounts um need to adopt you know patterns that solve that and 3074 would allow you ways to delegate to uh schemes that solve that for them so so I I suspect two dimensional lances but you know the design space is open

Tim Beiko: uh vitalic

Vitalik Buterin: yeah I mean one other thing to keep in mind and I mean I know that I

think Mike is present more about more about this later but uh you know we uh I I think the ecosystem is moving toward more and more realization that authorization logic does have to be in in some sense kind of explicitly recognized by the protocol um if we want because that's necessary for it to benefit from inclusion lists uh which are becoming a more and more accepted the like most practical solution for uring censorship resistance um especially in the context of uh continuing growing uh Builder Builder separation and or or Builder censorship

um and and Builder centralization um and so like one thing to keep in mind on this is um that like whatever these schemes that we ends up coming up with like it probably ends up making sense in the longer term so like actually make them protocol features in some form or another

Dan Finlay: uh yeah I could see a benefit to including um if a account uses is is a used to make a a call using off call so maybe require including it in the inclusion list

Vitalik Buterin: right yeah basically like like Bas think about like making an like some sort of enshrined and more generalized notion of Val

that is of like it's enough that it covers what can happen in 3074 off calls and general enough to cover what would happen in for in 4337 wallets but you know like this is a you know still one of those ongoing research areas that I think is valuable to highlight

Dan Finlay: yeah that makes sense and it's uh promising to me that it seems like this would work well with inclusion list

Vitalik Buterin: yeah one more thing that I think is uh just also worth highlighting on the 3074 stuff is that I think there is value in making sure that like like while EAS and

smart contract wallets continue to be like separate classes of entities for any of these new and like really important functionalities that we give to them like the uh the path by which EAS get get them and the path by which smart contract wallets that get them are parallel as opposed to being two separate ecosystems and like there's there's precedents that by what in the existing ecosystem that I kind of worry about like for like the even today relatively spotty level of support for ERC 1271 um and uh this is also one of those things that I think would be

good to not neglect um so a like a374 kind of a equivalent for smart contract wallets which me I actually looked at the E and it seems like that would actually be not even that difficult to difficult to set up um but also just a a thing to leg for Relevant for you know fusure medium term stuff

if

Tim Beiko: if we have uh say 3074 if we have like the up codee do is is the is the work to make this smart wallet compatible just like an ERC like it's like a or is there

Vitalik Buterin: yeah I mean so the so the great thing that

3074 has is um that like it doesn't uh like it doesn't derive the address from the signature it requires you to explicitly specify the address and so there's like a natural extensibility path for that to be smart con friendly

Tim Beiko: got it yeah any other thoughts question comments on 3074

Dan Finlay: I see a question in chat um how quickly do we think this could be

adopted by users wallets Etc um it's it's a good question I I supect we could at least have some experiments in metamask this year um because we're working on building an account uh plugin system and so that'll allow us to kind of iterate and validate pretty quickly as soon as this is ready

Tim Beiko: I guess one thing that um that's we thinking about is um the way we we ship this stuff you know we have like usually almost six months if not more of Dev Nets and then we go to test net and then we go to main net um obviously this is something where like the user flows matter significantly in a way that like most rather most

random up codes we add um you know they get exposed through solidity and then through contracts like uh kind of a later part of the pipeline but like if we do whether it's 3074 whether it's something else like how valuable do people think it is to have like invoker contracts or like even like a fork of you know metamask running uh with with some like support for for it like super early on in the process um or like at what stage do people think we'd have to to start seeing that

Vitalik Buterin: one kind of practical path and I think this actually goes even Way Beyond this particular discussion like I advocate doing this for execution

tickets for example it would be encourage some leer two um to adopt a change before mainnet and you know the principle there would be that that basically becomes something which is sort of halfway between a tested and a main net in a sense that it has real users and real value but doesn't go all the way up to hundreds of billions of dollars

Dan Finlay: I think the challenge with that approach is that uh it kind of creates a lessen incentive for the signers to do the work up front um you know we care the most about where the users are holding the most value today and so while we might optimistically do that development um we tend to keep our focus

on you know who who's getting hurt today

Vitalik Buterin: right but and I think like the way I think about this is like the safest thing is where you have like a relatively smooth ladder from you know Z dollar depend on it to $500 billion doll depend on it right like you know you don't want to have like a step function where you go all the way from zero to 500 he wants to go from you know first like zero to one and then one to 100 and 100 to 500 so that at each level it's already got secured by the level of effort that naturally comes from the previous level

Tim Beiko: um there's some comments in the chat saying like polygon is is working on this um and then and I guess then the the biggest

risk with those things is like the semantics of the op code right like is polygon doing the exact same version that we're discussing today or are they doing you know the version from a year ago um so yeah I don't know if anyone has context on that

Lightclient: as far as I know they're doing the latest version that is specified in e at this moment

got it um Eric

yeah I just wanted to join what uh Dan basically said agree with everything you mentioned um I do think that prioritization on the wallet space is hard as well so it is important that this kind of thing is applied in the

place where we have the most interest so that we're able to invest in it uh but if it is applied in where the interest is this is definitely going to be a priority so like the adoption in order to provide user value I believe it's it's something that will be invested in on our side as well and to some extent about the risk we also as wallets we also have our own risk mitigation and risk uh like verification processes so it's it's not like we're going to just open it up in the simplest way and everybody do whatever they want uh we're also going to run through a process where we make sure we minimize risk as we introduce any new technology so there's another layer of risk mitigation

that is going to happen uh because we also kind of take the responsibility in this process

oh Jor uh yeah I

Dror Tirosh: I think there's no doubt about the features that 374 can add to a applications the problem is not the features it can add but the the risks because as we know right now the only way to have it securely is to Whit list specific implementation that are known to be good and uh what what we end up is that there is

a list of whitelisted implementation the set of implementation either by the network or by dominant wallets these are the allowed implementation of 3074

Dan Finlay: um I would I would point out that a user choosing any piece of wallet software could then effectively choose the uh implementation they wanted to uh choose so so that that choice it's not like I mean you could put it at the protocol level and make it a small you know plutarchy deciding it but um the default is just that the market would choose users choose wallets wallets choose implementations much the way that contract wallet developers do

today

Dror Tirosh: yeah but but invoca does more than just being a wallet like if you want to have a a pay Master wallet you know you connect with some dap that simply wants to pay for your transaction and you use its invoker you basically reelect your implement of wallet giving your entire value of your account to this application just because it's cool and want to give you a feature like pay for your gas

Dan Finlay: right so so kind of reemphasizing that that it will be the responsibility of wallets to make sure that this election process is is Salient and as safe as possible and I think one of the

strengths of wallet teams making very deliberate choices around which ones they allow list would be in part that they could you know elect uh contract accounts that make it easy to let's say add features like batching without um having to undergo the entire off signature process again um you know I I think that there are lots of off-the-shelf contract accounts today you know no is safe with its modules and and you know now the uh contract account module standard uh that are making it very trivial to have extensible contract accounts and so I I think it's it's very likely that um most uh wallet developers will be able to have a very short approval list that allows users to then

uh you know have the account extensibility they need without having to resort to this pretty dire authorization

Dror Tirosh: yeah I only pointed out that a user actually performs this election of its wallet implementation on each transaction it's not a por you do once I selected implementation now I'm using safe I switch to Argent or whatever that's not correct doing it on each transaction because

Dan Finlay: that's not that's not accurate um the the user signs one authorization signature that authorizes a given invoker as long as that account's Nots doesn't increment and from then on that invoker is able to send messages on behalf of that eoa so as long as the user doesn't sign any

more messages from the original eoa message uh they can now have subscribed to another account authorization logic including two Direct non batching or whatever else

would it be reason oh sorry Peter and Nar

would it be reasonable then to describe um what 3074 does in practice as being a temporary subscription to a Smart contract wallet so you decide you sign this invoker authorization message that invocal authorization message then temporarily turns your wallet into

whatever smart contract wallet that invoke or implements until you sign a new send a new um EA transaction which increments a Nots and then disables that

Dan Finlay: that seems like a good metaphor as long as you don't lose your revocation message and a original uh private key in which case it would be permanent

um Anar

Ansgar Dietrichs: yeah I just wanted to briefly mention that um while indeed on the protocol side and I hope by the way you can understand me some noise um on the protocol side there's basically indeed it's it is this way that that

authorization could authorize an invoker to send an arbitrary amount of of of interactions from your account our original intention and that's kind of where this kind of commit hash um came in was that we expected one of the dominant patterns to be a kind of signature for a single action only so it could imagine basically signing over the hash of the specific transactions actions you you you you you you want to perform or something so that it could only be used once um of course in practice we would have to see which which type of interaction would would actually be used actively whether so maybe the the pattern of basically one time authorization then the invoker always sending in your name could could be possible but I'm I'm just

I don't I don't I don't think it's it's obvious that that in practice that that that would be the dominant pattern so so I think it's very likely that we'll see a one signature only authorizes a single one time action from the invoker that would be the

Dom

Dan Finlay: I think the reason I would suspect that the dominant pattern would be to authorize an account that then performs the messages is that if you don't do that you're keeping the original private key around which is kind of the security Radioactive material that we're really trying to eliminate so as a wallet developer we have a lot of incentive to get the the scary you know radioactive waste out of the user's hands so that you know the things they can do with their hot wallet are more constrained to things they might actually intend to do

um so I yes you're right many implementations could compete but I think there are some major security benefits to getting the main uh key off the hot device

Tim Beiko: Alex

yeah just about the subscription model uh the analogy that you said if I understand correctly a single wallet like address can be subscribed to as many uh invokers as it wants at the same point right as long as you sign and don't revoke the ration is it

I

Dan Finlay: I believe the latest draft of the EIP actually requires that the the authorization includes the latest knots for the EA so only a single invoker can

be authorized at a time

Alex Forshtat: but using this authorization does not increment no right no you're right you're right so like you can sign and sign and sign for as many invokers like a b oh right right yeah I'm sorry yes you're right yeah just like wanted to raise the concerns that it like kind of increases the surface like the potential surface of code that the same address can have as opposed to like having an implementation of a wallet uh one at a time it's that's it

Lightclient: yeah I mean I think it is kind of similar to plugins for smart contract wallets like you have you could have an

implementation of a smart contract wallet that you're using but then you could authorize many different plugins related to that smart contract wallet I don't really see it being terribly different

Tim Beiko: okay and I know there were uh some comments by Anar in the chat as well around like prototyping an endtoend flow for this from like you know a a a client implementation all the way to like an actual uh like wallet using an

invoker um how how blocked is something like that on us like choosing to move forward with 3074 or some other EIP like is this something we can just have like one um like is it something we can just have like one client team looking at and prototyping alongside the wallet and and seeing like okay can we get like a flow that we like or is this something where um actually getting everyone to commit to like 3074 or some other proposal or some changes to it is like the right first step

Dan Finlay: I mean I I definitely understand

vitalik's point that that like easing in um is is almost always a beneficial approach um I do think that most of the accounts that will benefit from this need the the main chain uh to doop so while I I think we're very happy to work on some prototyping with smaller chains like polygon um I think the the big fish is the Big Chain

Tim Beiko: and I guess maybe another way to frame this is like um how much value is there in prototyping even on like a devet and test net relative to like uh a chain with actual money um is you know do you get like 80% of your learnings from like there's actual value at stake here or you know is like

prototyping just the the the sort of user flow like what what brings most of the clarifying value if that makes sense

I

Dan Finlay: I do think that in this ecosystem a lot of lessons come from the actual value that's uh weighed on the designs that we built

Tim Beiko: got it um and I know yeah we've discussed like other proposals in the past um I I think 5806 was the other one um that that came up um and those were pretty much oh actually 5806 and then there was one about like the onetime

operation to make an EA into a smart contract wallet uh I forget what the number is for that one um 7377 thanks like client um but I guess out of those three I'd be curious to hear from just like the different client teams like you know do we still feel like it's worth considering all of them do people T to prefer um like 3074 over them um yeah how the how the teams feel about the different uh different ones

Dan Finlay: I see Hadrian's here and I I owe him a a 5806 review but um having having gone over it I I I think that it follows IT addresses a kind of different issue

it allows you to kind of have a a delegate call from your eoa and execute uh code from your account but it doesn't uh enable external contracts to kind of um add functionality to your account you're still signing with your eoa as far as I'm aware ad can correct me if I'm wrong

no that's correct yeah and then the other ones also um you know using new transaction types require the EA to be continuously signing signatures uh you know so oh well at least the initial one so that means the account has to have ether in it a nice advantage of uh 3074 is that accounts even with no ether are

able to subscribe to contract accounts for additional authorizations

Tim Beiko: got it um I guess um yeah I I'm curious to hear how how client teams feel about this there was a comment as well about like making 3074 CFI might be enough to like you know get people to consider it seriously and and start prototyping and send a signal to the community um that like we're seriously considering this um so yeah is that something different El teams would want to move forward with do we want to like look through the other proposals

um yeah I don't know does anyone on the El side have like a strong opinion or okay okay if there isn't a strong opinion then I think um it probably makes sense to then go through the other uh proposals for pectra and then maybe once we've like discussed the different ones um yeah see if there's there's anything that stands out um as as being higher priority

Lightclient: um yeah any what what should the next steps be 3074

Tim Beiko: so to me there's two questions one

is like do we want 3074 over other potential AA or like eoa Improvement proposals and then do we want 3074 over all the other things we could do in the fork um and yeah I I guess yeah I'm curious to to to understand like how client teams feel about those two questions

Lightclient: uh I you know I I would like other people to answer the first question but I think for the second question I don't really know how important of a question that is to proactively answer I think it's a question more that we should answer when we feel like we are we are either missing the Target that we're searching

for this Fork which hopefully is the end of the year or we feel that the complexity of the fork features is too great I don't think that trying to sort these on priority a priority is the most important I think we should only prioritize it and possibly kick it out if we realize that we're not going to be able to deliver on the timeline we wanted or with like the complexity that we're hoping for and 3074 is a very simple implementation of an e the complexity comes in the reasoning about the security model so I don't think it's like something that is going to cause us to not be able to do other things that we want to do

Tim Beiko: got

it any other teams or people want to speak up okay so yeah I guess if there's no other strong opinions then yeah I would wait until we've reviewed the other proposals and then see if there's anything else we want to CFI or include but I think for now um yeah in terms of next step for 3074 like one making sure people are like generally happy with the spec across the ecosystem So like um and it seems like we we've made progress on there um two like yeah it seems like there probably

is value in prototyping uh in prototyping implementations um to get a feel for the complex flow but that'll only get us so far um but yeah aside from those two things um I think it's just a question of do we want to prioritize um any other thoughts comments okay um we only have half an hour left so I'll move on to uh the next ones but um yeah thanks a lot Dan for coming on and everybody else um appreciate you sharing all your perspectives um okay next big can of

worms inclusion lists

uh Mike camera on camera on yeah

Mike Neuder: hey Tim uh hey everyone yeah I'll try and be pretty brief because I know that that EO discuss or the um 3074 discussion ran a little long so yeah I guess just wanted to to update a few things on the on the iil side of things this is uh EIP 7547 and I thought it would make sense to start with just a couple minutes um discussing the rationale like kind of stepping away from the technical details which I think are better hatched out kind of async and just talking through some of the meta reasons why I think inclusion list in Electro make a lot of sense um kind of first and foremost the the me landscape continues to evolve

super quickly um I think even yesterday after the fork there was kind of some some chaos around Titan Builder not necessarily being able to include blobs so then Beaver Builder started building like 75% of blocks and like kind of this this continual evolution of of Builders um vertically integrating with relays relay sophistic a timing games etc etc um yeah basically trying to make the point that if we commit to not doing inclusion list in Electra we let the me infrastructure continue to evolve for like basically the next year and a half to two years without any kind of changes on our side um I think that's a very active decision in itself like not doing anything is is almost as strong as of a

decision as doing something so that's that's kind of the first point I wanted to make the second is that the scope of the Isle change is generally well contained we've been working on this um proof of concept spec PC spec I'll share the link here um yeah just trying to kind of drisk and show across both the consensus layer execution layer and the the engine API that the changes are pretty small um hopefully to motivate like going for it in this Fork um the third thing I wanted to bring up is these outof protocol Solutions so this is actually something that's um being discussed uh kind of again even though we um we did discuss it before but it's

cool that like people are coming to the same conclusion but um at a different time the the thing I wanted to say about the out of protocol stuff is that um and and I'll link a doc here this is kind of the censorship resistance in me boost doc that that I wrote a while ago but the thing I want to bring up here is that the outof protocol Solutions are actually pretty different in character than the in protocol one and the main difference here is that in the out of protocol version you can't do this next slot inclusion thing so basically um yeah there's it's not really the situation where we can do something in me boost and collect data on it and then that like dr- risks the thing we're going to do in protocol because the

thing we're doing in protocol is this next slot um inclusion list and the thing we'd be doing out of protocol would be same slot inclusion list so that's my biggest beef with it um but I do think there is value in potentially like looking at some of the out of protocol Solutions and potentially doing them in parallel just because um you know I think this is like a defense in depth thing which is potentially really valuable um and the last thing I wanted to bring up is just that the the current inclusion list spec in the design is super compatible with the with the endgame road map like whether that includes epbs execution tickets um there's kind of more recent discussions around these committee forced ILS that was a post from um from Tas and then

there's also like this idea of maybe multiple inclusion list proposes at the same time I think all of these fit really nicely with the simple framework laid out with um 7547 so doing doing like the first step along the path of of building an in protocol solution to the Mev markets I think is is super valuable so that's kind of the pitch I'm writing a a short Doc kind of based on this set of arguments and few more so that'll come out on I'm hoping to get that published by Monday and then um yeah hopefully we can continue the discussion both both async and and maybe on the Forum um yeah I also just wanted to shout out quickly the um allc devs or the the cevs working

in the the eth R&D channel the inclusion list Channel um poto and Terrence Dustin puan Daniel sha vinder enrio Marius Dan Roman Franchesco vitalic Tony Shia and Pinel just like this has been really awesome collaboration over the past few weeks and there's a ton of activity in there so if you want to learn more if this feels important to you like definitely jump in there's there's lots to be um lots to be discussed and the last thing I wanted to bring up is that um we discussed in the last allore dev's consensus call potentially doing another breakout room for inclusion lists I originally proposed um for tomorrow but I think given that I didn't open a um

issue in the PM repo and kind of haven't been broadcasting it maybe it makes sense for early next week um but yeah just wanted to get a temperature check maybe we can kind of that in in the zoom chat about scheduling it I I proposed Monday um next Monday 3 uh the 18th of March at the regular time I'll just copy that in here so we have a reference to it but yeah thanks Tim for for giving me the floor and definitely if any other folks who've been working on inclusion lists want to want to jump in and and say their piece then would love to hear that otherwise we'll just give the mic back to Tim thanks

Tim Beiko: thank you Mike um yeah I'll start

to see if there's any comments questions on what you just said and then we can talk about the breakout uh but um yeah any thoughts or responses to m um I guess anyone from on the client teams either strongly in favor or strongly against considering inclusion list for the next Fork

um uh R

would like to Signal support for including it because not as Mike said

not doing anything is is also a choice

Tim Beiko: got it thanks any other teams

Dror Tirosh: yes one small one small thing about inclusion list while they are great I'm not sure they are compatible with the end game because they're not strictly compatible with the account obstruction requires some further work

Tim Beiko: why are they not compatible with account

instraction

Dror Tirosh: uh because if a transaction may become invalid and you add it to an

inclusion list then it can't be included but it's forc to the way inclusion list work is that they check the basic features of an account like nons and balance but with account obstruction they need check on chain validation which might change

Tim Beiko: um Mike can any thoughts on this

I'm

Mike Neuder: I'm not as familiar with this I'm pretty sure vitalic U was uh saying that it wouldn't be an issue but um maybe can I reply this

Potuz: I think this this this statement was false part of the validation of the inclusion list is

actually checking that the the transaction can be executed in the current block and the next block so it might be true that you you this is not going to solve for uh intents uh but this are but this will solve for censorship of actual transactions

Mike Neuder: yeah I guess I was curious if it it changes it all under account abstraction like a user op versus a transaction I guess being censored

us

Dror Tirosh: a user operation right now is a transaction that can revert which can be included you can force a user operation

by adding an handle op it will be forced it will be rever on chain for example if some state will

Chang

Tim Beiko: but isn't that true I mean any transaction in an inclusion list could potentially revert based on the updated state of the chain before it gets included right

Dror Tirosh: no I'm saying that with 4337 as an ERC yes it will force inclusion of a reverted transaction which is not such a big problem but small one the problem with Native account obstruction where transaction is no longer valid which means it can't be included because it depends on the

state lot of work with account obstruction how to handle such cases but uh Force inclusion might

uh um yeah like

Lightclient: yeah I had a question on using ILS with any kind of account abstraction mechanism is it not that case that a any bunder that's using a permission permissionless bundling Network could submit their bundle as an i like why does the ilil need to specifically be concerned with account abstraction

Dror Tirosh: again depends on the model

with es 47 there's no problem you can force an inclusion of a bundle and the worst thing is that it's going to revert on chain because the validation doesn't prevent it from being included on chain and here see once validation becomes a part of the validation of the transaction you can't include a transaction that fails validation

Lightclient: but I mean how this is also true for EAS like you could have an I can you not have an iil that says you need to include this transaction from EA during the block it becomes invalidated and then the next block the EA

transaction is no longer valid

Mike Neuder: so that that's why the design only commits to the address of the transaction rather than the full transaction itself like that's the whole point of the um the no free lunch design

Dror Tirosh: um okay need to look the latest inclusion list logic

um Anar

Ansgar Dietrichs: yeah I just wanted to say as The Meta Point given that any form of native account obstruction on layer one is still several years out even optimistically um and that thereby I

would not include 374 that's not that's separate um I think even I mean I think the understanding is general that this kind of inclusion list design might not be one that will be the final design forever but at some point might need adjustment anyway so I personally don't see an issue with shipping something that then you know ver basically say once we ship native obstruction might might might or might not require um updating

Tim Beiko: okay and then I guess um it seems like there's like General

support for inclusion list and it's more a question of how and when rather than if um I don't know I don't know that we necessarily have time to flesh out exactly the next steps on this call um with like 20 minutes left and a bunch of other stuff to go uh over but um I do think it might be worth uh yeah it might be worth a break a breakout for this so that we can look a bit more deeply at like the different designs what's the incl what's the implementation uh overhead of of them um you know and whether like they're realistic to ship this year and uh you know whether like in protocol designs or

starting uh at the Mev boost level first or doing both in parallel is the right approach um yeah um and then yeah Mike is proposing Monday at 14 UTC that seems reasonable to me anyone have an objection with That Way Forward um okay let's do that then um let's do um okay let's do a breakout next Monday um go over all of the inclusion list stuff in more detail and then hopefully by either ACDC next week or ACD the week after um we can have like one or maybe

two specific proposals that uh we can we can make a call on and whatever we want to move forward with um yeah we'll set up the breakout um but Monday 14 UTC people can uh can pencil that in anything else

Danny Ryan: supect will'll have a proof of Concepts the coming week or the week after because one of the other things I just designed was like a better understanding of complexity coming from that

Tim Beiko: and yeah maybe that's actually a good thing to focus the breakout on is like yeah what is the actual engineering overhead of in protocol inclusion lists

um what does it look like to do it in MF boost

um and yeah see I

Potuz: do you want a proof of concept for implementation for a specification

Danny Ryan: I thought there was an intent to do a procept implementation uh but that certainly could not be the case

Potuz: but just like in like a four days the breakup room is being scheduled like next week

I'm

Danny Ryan: I'm basing this off of a conversation three weeks ago in ACDC yeah but that doesn't necessarily mean that a proof concept was working

Mike Neuder: I think there's different client teams working on different uh branches

but maybe we can use this this breakout room to kind of like to see where everyone's at do a pulse check and then also coordinate on maybe a more like cohesive proof of concept like end to end in both uh a consensus client and an execution client or multiple

Tim Beiko: yeah and and I and I I I don't think obviously we can get like a full implementation done in three days um or maybe marus scan in the chat um but then the the thing we can maybe get in like 3 to 10 days is at least an understanding of like where we think the complexity would lie and like like you know having having people looked at the spec and then you know understanding their client

code and you know trying to figure out what what the issues will be um but yeah maybe we'll have a GU load STAR test net by ACDC as well uh looking at the chat um okay yeah this feels like an good place to end this uh and this far as the conversation um oh sorry just dropped something um we'll have the we'll have the breakout on Monday day um we'll set up something on the PM repo to detail all of that but 14 UTC we'll see you there thanks Mike for the update um okay another uh large not necessarily large change but one with uh big implications

uh Tony's been uh looking at repricing call data to better uh discriminate between uh um large users of call data like l2s and people who use just a bit of call data in the process of of doing more regular transactions um and has put up a bunch of uh impact analyses data and charts on this uh Tony do you want to give some background

Toni Wahrstätter: yeah sure thank you um yeah to give you some background it's about EIP 7623 increase call data cost and the main goal of the EIP was to reduce the maximum possible block size by

increasing the cost for um nonzero BTE call data and it is doing that by introducing a flaw price for call data that is currently set to 68 gas per non-zero cold data bite so increasing it from 16 to 68 and over the past week I've got gathered some some feedback and the main feedback the main concern was just to do more analysis on the on the impact of the EAP um in the agenda you can also see the a post that already analyzes the impact of the EAP and it the result was like 4% uh 4 4.5% of all transactions would be affected and only

1% of the users and I did some more analyzis that I post in the chat here it's basically a table with um the most used um methods and their median and um total gas consumption split it in evm gas and C data gas and in the table you can already see which methods would be affected by the EAP and which not and one thing that is currently still under consideration is the exact cost of the cold data after increasing it so should it be at 68 gas per cold data bite or maybe maybe lower maybe setting it to 48 something um yeah so basically thinking

about the um 16 * 4 Series here but yeah open for feedback especially on that number um the goal is to not affect regular users and um existing applications while still reducing the maximum possible block size

Tim Beiko: thanks um any questions comments thoughts on this

Marius van der Wijden: um did you decide now whether the um the deployment cost should go into

the calculation or not

Toni Wahrstätter: yeah so as of now the deployment cost is inside the conditional formula

Marius van der Wijden: have you looked like have you did the analysis with both or like do you know what the difference would be for people deploying contracts

Toni Wahrstätter: um I guess by including the deployment costs within the conditional formula that this helps people deploying contracts so it would mean that um if you deploy contract with a lot of call data you might still be able to um yeah not hit the floor and still get the 16

gas C data price um if you take it out outside of the conditional formula I guess then this would get harder but I think it's only a very very small number that should be affected

Marius van der Wijden: makes sense

Tim Beiko: how um I guess have you reached out the like l2s like the basically the big users of call data today which extensively have like shifted their usage to blobs but like is anyone going to be really mad at this when it goes live

um yeah

Toni Wahrstätter: yeah so I had contact with um a few l2s so far I'm also planning to

introduce the EAP in the in the rollup call I think that's the perfect place to get more feedback on that but so far the only concern was raised by teams that that cannot really escape to blobs because they need their call data inside the evm and you can think about um Stark Stark proving onchain um proofs but also Merkle proofs or um L2 withdrawals that sometimes take a lot of um yeah Big Miracle um that uses big big Merle proofs that might be affected um and cannot escape to plops so this this is

the only concern but um yeah I guess I'll still need to to analyze how 4844 plays out now and then also um how much the the final increase in gas would be for those teams that cannot move to blobs

Tim Beiko: got and and and and as I remember like the the implementation for this is quite quite simple right it's a pretty trivial uh change in the evm

Marius van der Wijden: yes

Tim Beiko: yeah okay um so I guess here it

probably makes sense as the next step to just um one bring this up on roll call like Tony was saying two obviously see uh sort of how call data and blob usage uh continues to evolve in the next couple weeks um but if we want to like add this to the for can you know one two calls or even after that um it feels like the type of thing that's just like easy to quickly add um and then add the dev netes as we're working on them um yeah does anyone have any other thoughts or or suggestions about how to move this forward okay um yeah so yeah uh Tony I

guess yeah let us know what L2 say on roll call and um yeah we'll talk about this in a in a couple weeks thanks for thanks for sharing all this

thanks okay um there was one uh I a new EIP I don't know that we've talked about this on aord before uh that was discussed in the agenda 7645 elas sing origin the sander um I know uh I believe Cirus Cyrus hope I'm getting your name right um s oh can you hear me your mic is is is really really bad bad yeah uh extrem yeah uh you you sound like a

robot if I can switch to a different quickly how about now oh wow I might end there um yes um yeah do you want to give a bit of context on thep can you hear me now yes we can can you can you hear me now yes I don't think you can hear us anymore oh can you hear us oh

oh Tes how about now uh we still hear you can you hear us all right um well I'm just going to keep going can you hear me I I can't hear you guys yes how about now we can we can hear you just go for it okay can hear you now let's do it sorry about that guys

Cyrus Adkisson: all good um my name is Cyrus adinon I've been around ethereum since 2014 uh when the network went live in 2015 I wrote some early documentation stack Overflow Q&A uh some instructional

videos uh and I presented my project at Devcon one um all that said I am definitely the dumbest person on this call when it comes to the evm so please uh bear with me um 7 645 so origin is an OP code um that is sort of a relic um it represents the the account that originated the action and paid for the TR gas for the transaction which is and until we get true AA always the same thing in mid 2016 it became generally acknowledged that TX origin for anything was bad news for a variety of reasons there's an epic Peter Bora thread in the solidity repo that goes over these issues one origin can be used used in a

sort of cross-site scripting way to steal assets or misuse Authority if that Authority is delineated in uh TX origin terms uh origin breaks compatibility since your contract can't be used by other contracts and origin is almost never useful um it's still an outstanding question is are there any legitimate cases of TX origin so since then um documentation audits compilers everything has warned against using TX origin um and it it should it has been considered deprecated since mid 2016 I guess uh note that for those searching that Peter bore thread removing TX origin from solidity is a completely different thing than adjusting the evm

uh assembly for one thing so keep that in mind if you're reading the replies um since uh people still used TX origin one of the common illeg illegitimate uses of origin is a lazy hack smart contracts used to determine if the has code and can do bad things uh if origin equals a Coller is supposed to ensure that the CER is an eoa but an in an AA future that might not be the case so um AA seeks to separate the pair of the gas and the originator of a transaction into two identities one of which um is uh so then the question is which one is origin either way you go it creates problems so in 3074 for instance

an EA can trigger a smart contract to do an off call is that smart contract the origin or is TX origin or sorry is the EA that initiated the transaction origin um for another in some AA proposals eoas can have code thus origin can have code thus these origin equal collar checks break so bottom line origin is a tech R delic TCH Tech Deb Relic that no legitimate use cases uh and it's standing the way of uh robust account abstraction so one solution and this is 7645 first floated by Micah though he can speak for himself on his views of it now is to Simply Alias origin to Cinder that is everywhere origin appears would

be treated as s Cinder this would seamlessly fix some misuses of origin because the alignment of eoas to Smart contracts um and breaks the alignment of EAS the smart contracts and nullifies origin as an impediment to account abstraction the downside is it breaks backwards compatibility from for some other misuses of origin somewhat AR that these patterns were already broken and that we have no obligation to protect them especially if it's holding back evm Evolution uh and future capabilities so 7645 is a straightforward proposal to do this aliasing um if 7645 proves too harsh for the community to adopt immediately I Flo a precursor plan no EIP yet uh to Simply ban any new

appearances of the origin up code in new smart contracts as a pectra uh which I guess is a consensus layer thing I guess the idea is to put a full stop to all uses of origin tease out misuses of origin that have been going on and educate the community and then eventually do the aing of 7645 later yesterday Dano uh Fen said that this pre-deployment check for origin is not possible until we get eof but I'm not knowledgeable enough to know to be able to confirm or deny that myself so that's the pitch and I was hoping to get feedback

Tim Beiko: thanks thanks for sharing um and yeah we have Dan with his ends up so uh please

Dan

Danno Ferrin: yeah so the the problem with the predeployment check is there's multiple uses for the code not just evm code um people are using it for whether they think it's legitimate or not they're using the code just as data contracts that's one use and the second because of the way solidity compiles evm it puts signature data after the code and even some cases without the signature data there's just some code data that exists in the evm there is no reliable way to different differentiate the codee from the data um and that's part of the problem that that eof is meant to solve is to separate the code from the data so if if banning origin is something that's valuable that something that can very easily be added to the eof spec I had considered it frozen to this point but

that's a very small addition and a very small change to the reference tests um I guess I didn't put my uh request in to speak about it on this call in the agenda um but you know quick update on on eof um it's you know the specs Frozen we're doing final implementations reference tests are being written so that's that's a quick update there but I don't think that banning an OP code in Legacy EV eof Legacy evm is is it in any way possible increase in the gas cost is one way to make it unprofitable that's that's the tricks we would have to do

Tim Beiko: thanks uh Peter

Peter Davies: um yeah firstly I'd like to say I thought you um explained ISS be well there um I think that the um trying to

ban it as Dan has explained is just really complicated whereas turning it into sender is like pretty much the most trivial change you could make like it's hard to imagine a more trivial change to evm so I would be tempted to do that and the main question is like to what extent have you investigated the patterns that are going to be broken because the challenge you're going to have is someone's going to say well potentially there might be some contract somewhere that is broken if origin always equal sender um and I wondered how much he'd investigated that

Cyrus Adkisson: the auditing firm doob did a um study on this when it was investigating 3074 uh so you can probably Google

search that pretty quickly D was the company um although I think there's been some disagreement about the conclusions they reached on that and and honestly that gets beyond my knowledge to be able to um defend or whatever

Tim Beiko: okay thank you um we only have two oh Charles yeah last

Charles Cooper: oh I was to say that um I think generally it's um changing semantics of op codes is uh pretty dangerous because you know people could be relying on it for some particularly important thing and um something else

like just increasing the cost so that people know that it's like quote unquote deprecated output is like a maybe a Slicker change from a from a compatibility standpoint

Tim Beiko: right okay uh we have two minutes left uh I think it's probably worth pushing back the state growth analysis at the next call so that we have time to properly go over it um so I have a link the agenda I can put it here I I strongly recommend everyone have a read at this it's it's really good work by the Paradigm team um and I think it

probably makes sense to uh have this high in the agenda next call so that we can go over any questions or comments on the on the research um but with one minute left before we close I guess the one last thing I want to cover is we've had these uh Fork testing calls happening every two weeks that have sort of petered out as we got closer to the fork uh does it make sense to keep doing them now would we rather cancel them and and um start them up again when uh we're we're sort of farther in the fork process um any thoughts there I'd rather cancel okay perfect cancel confirmed in the chat um we'll do that then so um on Monday There's the

there's the I breakout but we won't have the uh interrupt testing call um I'll delete that after uh this is over and everything else on the agenda that we couldn't quite get to today I'll just bump to the next uh the next call so again State growth research uh couple eips um for evm changes and then uh this discussion of like they retroactively applied eips and hopefully yeah by the next acde um we have a good feel for um what inclusion lists are looking like maybe a better uh sense of like the community is ready yes around 3074 or something like that and then um I think it probably makes sense to make decisions about additions to Petra on the El side then

uh rather than uh in overtime today and we'll see we might even get a experimental devet by then looking at the chat um yeah thanks everyone for coming on again uh congrats on the fork ethereum still running smoothly um yeah excited for this and talk to you all on the breakout Monday

thanks everyone thank you thank you thanks team thanks thanks thanks everyone bye Rec

he Jesus

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