All Core Devs - Execution #116

Transcript

[Music] [Applause] [Music] [Applause] [Music] [Music]

[Music] so so [Music] so

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

so [Music] [Music] [Music] [Music]

[Music] [Music]

[Applause] [Music] [Applause] [Music] [Music]

so [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Applause] [Music] [Applause] [Music] [Music]

[Music] sorry i'm still muted okay take two

Tim Beiko: hi everyone uh welcome to awkward devs 116. um a couple things on the agenda today uh the first of which is just going over the robston fork that happened two days ago now um i don't know if anyone wants to give a quick update

um i guess yeah i i can give some general one and then i'll just paint people who i know did a bit more so um high level i think it went uh okay we had uh we had the fork uh it took a couple minutes to find the block on uh robson after because i think a lot of the old mining power didn't switch over um luckily at least base you had a miner and they mined the first block a few minutes after um everyone was on the same chain after that i think there was one bad block mine on the old chain and that was it um there was a small bug in the forkman software which made the hashes shown on forkman uh although they were all consistent on

forkman they differed from everywhere else um which was also all consistent and we found that that was a bug with one of the underlying libraries or not a bug but just one of the underlying libraries that calculated the block hash on forkman did not have london support so it got to a different hash um but that aside um everything seemed to work well um i know the basu team ran a pretty big spam test on the network yesterday they ran the spammer for like 12 15 hours uh we got the base fee up to uh thousands of way and then they shut it down and it went back down to its minimum value where i think it's sitting now um we had people send 1559 a non-1559 style transaction

um i had somebody uh kind of deploy a smart contract add some storage slots to it clear those storage slots and then self-destruct the smart contract and that seems to have gone well and the network hasn't split so uh 3529 seems like it's implemented correctly across the clients um the only kind of odd thing i've seen or i guess there were two odd things uh one was vitalik uh mentioned that the kind of distribution of the block gas usage was a bit odd uh where there were a lot of blocks that were like 80 percent full and i think somebody looked into that then it seemed due to how the transactions from the spammer were batched

um and like the gas cost used by those transactions um and then finally somebody posted like yesterday some transaction that they said worked before and doesn't work anymore um i don't think anyone's quite looked into that yet um yeah that's kind of all i've seen i guess over the past two days i don't know if anyone wanted to add anything else

that's a pretty great synopsis thanks um yeah and i guess yeah so the the thing i had on the agenda uh and i kind of discussed i think with people before was stress testing roxton

Tim Beiko: i feel like we've kind of did

that pretty extensively already um i know marius you also wanted to do it uh with your tool which is different from from the one from basu and do you have any updates or just thoughts on that

Marius van der Wijden: i already sent some transactions um today but i didn't push it the way bisou did yet okay i don't know if it would make sense to do it together so we have like a huge chunk of transactions uh but in general i think it's i don't know we've pushed the network to way more than

main head is going to be probably

so i don't know if it makes makes that much sense um to push it yeah yeah i mean

Tim Beiko: i guess we could probably run it for like you know at least an hour with the two of them together

but i agree we've seen just to make sure that transactions from like a lot of transactions from two different sources work but i think yeah in terms of handling the load it seems like it's worked well um hey tim hey trent uh was there any

Trent Van Epps: i remember you pointed out that there was a it looked like the base fee was updating outside of the 12.5 percent did you look into that

or was it just uh yeah i think it was

peter

Tim Beiko: yeah it was peter who pointed this out um i think yesterday peter on on on the get discord you shared like some base fee i think had gone from like uh 240 to 370. i i don't know if you have more thoughts on that i looked at like several blocks and yeah i couldn't find something like that

but uh yeah

Péter Szilágyi: um i only saw it on that on that washer burn website two subsequent blocks but uh i don't know whether it could be for example above so i don't know what happens if uh if there's a reorg of say one or two blocks and that could explain that if one one side fork pushes the base key up

whereas the other side pushes it down i don't know how these rears are handled by that website so it could be just a fluke of the website

got it

Marius van der Wijden: um the website should calculate it correctly i think so it it calculates the base fee or it takes the base fee directly from per block from from the block itself

Péter Szilágyi: yeah but what i mean is that if you report the basis for blocked hand as a certain number and then there's a rear which pushes it in the other direction

and the block n plus one you will have so block n won't be the parent of block and plus one

and i don't know what it does the website fix the already reported numbers or does it only report for no yeah you're right yeah so uh if if a reorg happens the old block will just be in the ui so we don't update every block if a real happens or something like this also that also the total base fee is slightly incorrect because it cannot compute reorgs at the total amount of uh stuff so i guess with all that

Tim Beiko: i'm curious how

the different clients are feeling about you know deploying this on on mainnet um do people want to potentially set a block now do we want to wait

basically if we wait two weeks we can see the two other test nets uh fork um one thing i've been doing uh i did earn the past week along with uh tj rush from from trueblocks is kind of recalculating the difficulty bomb stuff um there i it seems like we're gonna start seeing the impact roughly after block 1.3 million or 13 million sorry um so i had so basically that would be any time after like the first week of august um

it won't be as high as as it was in your glacier um and i kind of had the charts on on github showing the difference but um you know if if we feel confident in in london um there's probably you know some value in picking a block before uh 13 million um because then we just kind of save one update from the difficulty bomb um if we feel like you know we want to see more of the network's fork and and we're willing to wait a bit later um then you know the the impact is we'll see something between like you know 20 to maybe 50 000 blocks um in the new period of the difficulty bomb before it gets reset

um yeah so i'm curious what are people's thoughts about that how confident do they feel about london and and you know do we want to see more before we pick a block basically or are we are we comfortable doing that right now so i guess i can go first

Péter Szilágyi: one of the catches with um testing 1559 on test nuts is that essentially if you look at robstone the base is zero or operator around zero because the blocks are simply empty and if you do a quick skim over girly or rinka big blocks you will kind of see the same thing that they are less than 50 percent full

which means that if we even if we add so if we ask miners to double um to get the block limits and they will be a quarter full so essentially in both test networks we kind of expect the base fee to drop to seven so none of the testaments will be a realistic scenario

from mainnet even when we see the effects of spamming sorry so even

Gary Schulte: do you think that was not uh a successful test uh even in the context of the spamming that's going on in this still plan plan i mean they're we're definitely

going to see blocks over 50 percent full it would be contrived but we'll see that

a case yeah of course i um i just meant that you won't really see organic traffic pushing the base limit up and down so i'm not sure if that's an argument i guess you know one way to interpret this is like we're not going to learn that much more from the robston and the rink and b or sorry the gordy and rinkeby fork um i don't know if that's the case then there's probably value in just setting your blocks sooner rather than later and obviously continuing to kind of manually test things in the meantime um yeah i don't know how do other teams

feel about this so my point wasn't really an argument for it i guess it was just a data point yeah yeah um that makes sense does the

Gary Schulte: does the call have to be made on an all-court devs call like um what about an off cycle like uh next next friday instead

so basically we see gordia we pick right is what you're yeah yeah it seems like the the you know the the rollout on robson was a little bumpy in terms of um coordination with the miners and so forth so it might be might be good to um see if we can have a smoother roll out

with gurley um just to see what that looks like yeah

Tim Beiko: i think if we do like so if we do do that um you know we'll probably have to reconfirm the block anyways on all core devs um i think it's kind of the main way that everybody hears about it

um we can agree to one off cycle um [Music] yeah but yeah i suspect we don't like gay like you know we're basically at best get in your week right like gordy's gonna fork next wednesday um and then you know if everything goes well then maybe next like friday or monday we can we can pick a block um yeah i don't know from the client

teams does that make a difference to like know it four days in advance next week if everything goes well or honestly i don't think so as long as the fourth block is give or take a month ahead

Péter Szilágyi: it doesn't really matter if it's a week

Yuga Cohler: um one question i had was are the clients um planning on doing one more release uh before

main network

Tim Beiko: they have to oh right of course yeah yeah that's true but i guess is your question more about

features

like

Yuga Cohler: yeah there were a couple of things like there was a there's a bug in open ethereum with the eth call method and then um marius and i were talking about there may have been a regression and yes for uh contract inter tracing contract internal transactions um so there were just a couple of things uh it would be nice to get in before the fork

Artem Vorotnikov: don't use open ethereum move to

erico sorry what don't use open ethereum move to arrogal opening theorem is deprecated i believe it still plans on being london

compatible right say again open ethereum

Micah Zoltu: plans on being london compatible though right

Artem Vorotnikov: yes but it will be the last hard work basically it's just to support the transition

anyway we are planning to have at least one more release for some of their rpc changes and bug fixes similar never mind

Łukasz Rozmej: we don't have everything yet implemented for the rpc uh for london there are some some things

still being revised and uh there are also new some other non-related features that we'll be releasing

so i guess in that case given all the teams have like at least some tweaks to do um if we picked a block kind of after you know the gordy fork assuming uh it goes well um would would clients be able to have a release ready by the next awkward devs um because then it i think that can also be really valuable it's like if we can get to uh the call two weeks from now and have releases by our clients we can we can kind of share those and and um whereas if we get to the call

two weeks from now and then uh none of the clients are releasing we have to wait another week for like the release to go out uh we probably still want like a sort of three four week gap between the between when the releases are out and when the fork happens um so would like two weeks be a realistic amount of time for like the different teams to um both you know fix like any bugs or add any like missing json rpc calls um and then also have that release contain a main network block i see a plus one from basu yes it seems doable for open ethereum also

yeah so that currently is pretty stable we i'm not aware of any huge bug there's uh mars is investigating one slight performance regression in the tracer but i'm a bit skeptical about that so um i guess can release whatever there's also i think

Tim Beiko: the fee history api i saw like basu had merged that i think geth still had an open pr i'm not sure about the other clients so that seems like the one big kind of feature that's maybe not merged in most clients

yes that's a funny thing yeah

Tim Beiko: is that something that's realistic to get done in the next two weeks as well

okay

Tim Beiko: um so i guess yeah this is kind of what i would propose is like we wait and see how

gorty goes assuming it goes smoothly and then end of next week early the week after we pick a block for magnet um i'll be gone out of next week so if nobody has done it on monday i'll propose something um and then basically clients can release before the next awkward devs uh with the main net block included and that'll kind of shorten the time uh that uh yeah short in the time that we need uh to have uh the announcement and

everything um does that make sense for everybody or any objections i guess would it

Trent Van Epps: be a month from now or a month from next monday

uh so i think we probably want like um wait let me just look at the dates and it's not next it's not monday in three days right it would be like monday in 10 days um so i suspect you know like a month from then would be um early august uh so we could probably you know if we wanted to be right before the difficulty uh bomb hits again uh we could do august

4th or something like that and that's basically the middle of the week of the last week before there's another difficulty increase and that gives us roughly a month yeah um yeah

Gary Schulte: that sounds like really good timing

okay okay great so um yeah uh let's see how how gorty goes um yeah if any i i had a blog suggestions in my spreadsheet but if anybody wants to suggest another one or something after the fork uh we can use that as well and then um yeah

Tim Beiko: when i'm back on monday the the fifth i'll make sure that we we settle on something

um cool anything else on london okay uh so we had one kind of i guess midi topic um so i i shared this in the agenda uh but we've discussed eip 3074 uh a few times in the past and

Tim Beiko: yoav made a very uh i guess elaborate thread highlighting some potential issues they saw with it as well as some potential alternatives

and i saw the 3074 team responded uh after that so maybe it makes sense uh yo do you want to take like

a couple minutes to just kind of walk through the gist of your thread um obviously you know if people have read it that's ideal but just yeah give some background there and and we can start from here yes of course so um so i'm not going to repeat the whole long thread i don't think i don't think going through all the individual issues would make sense on a call but uh in general what it was the way i was looking at it i i was looking at the eap 3074 and one and seeing what it aims to achieve because it seemed to me that it's a quite powerful it's quite powerful which also translates to risky in this case

and wanted to see if we can uh if we could achieve the same in a in with less risk so the things that it aims to achieve seem to be batching and an account obstruction uh or gas sponsorship if you will so um so the eap does achieve them but it also seems like an overkill and there may be less risky way to achieve them so what i posted in the thread was a couple of attack vectors that it opens and so the primary the primary issue is that the oauth is essentially a blank check to the invoker to the invoker contract to do anything on behalf of the user

now and in the future and the the logic for restricting first for restricting operations or for replay protection or anything else is entirely up to the invoker the protocol is unopinionated about it now i demonstrated uh demonstrated a couple of ways uh in which it can be abused okay one of them was a cross-chain across chain attack because the chain id is not covered by uh is not covered by the signature only by the commit so i demonstrated i demonstrated a case where a a perfectly secure a perfectly secure invoker runs on a one chain and the user

transacts there and then and then later when the user moves assets to the other chain and through a bridge later someone deploys using the same key deploys another invoker and this one doesn't bother looking at the commit so it can do whatever it wants and then it can do anything on behalf of the user like a robot the assets and the other case i demonstrated was um um was like a governance hijacking because from the user's perspective if there's an invoker that gives the value to the user for example batching transactions and maybe paying for gas for a

pay for gas during trading so a user will use it to trade the elc 20 tokens but as long as the tokens are not stolen or anything the user doesn't care but then due to it due to a malicious bug in the invoker the invoker can and the invoker can vote on behalf of the user so the invoker sits quietly collects these these signatures and at some point it can be used to hijack the governance of the governance of some april or some other project using the are using the user's tokens but um so any of any of these any of these vectors can be mitigated for example we could add the

chain id to the signature but uh what i what i wanted to argue is it's safer to um it's safer to tightly couple the user operation with the actual call by signing the actual call data the tool and everything else instead of just a commit so um so so all of these uh so all of these vectors and any others that we're not thinking of will be uh uh we will be covered now uh with this uh with this change we still achieve all the goals that eap 3074 attempts to achieve because anything that can be done with the current ap will also be will also still be possible it just means that the wallet will have

to sign a list of calls instead of a commit so um that was my that was my main thing and uh another thing that i uh that i tried to uh that i tried to explain in the thread is that uh i think since uh we all seem to agree that the eap adds basically set your id capability to avm so this is not uh this is not sudo unlike what some people say but it is set uid and in operating systems set your id has been the culprit for a more for a for most privileged escalation attacks over the past few decades and different models were

invented to fix it so i wanted to suggest that we don't that we don't learn it the hard way by going through the same disasters that linux did and instead we can just use some time proven uh models instead so that was my purpose with this with this thread i don't have a clear design for her for how it should be solved just a general idea but i wanted to i wanted time to to explore alternative instead of just committing to something like so high risk in my opinion

Tim Beiko: thanks a lot for for sharing um yeah like client or sam i know the two of you have responded to the thread

do you want to take a couple minutes as well to just

share kind of your thoughts on this yeah i can go ahead really quick and then sam you can jump in if you want i think there's a lot of things to unpack and so this is a pretty difficult discussion to have uh just like with voice because there's many nuances to these arguments for and against 3074. i think generally like yolab's points are um i mean they're fair but i think that you know he's focusing a lot on um he's focusing a lot on things that we've already said are considered unsafe there's a lot of ways to write unsafe invokers and things like allowing a invoker to be deployed from

create this is unsafe way of deploying an invoker an invoker has to be something that's not malleable in any way and he found a really neat way of doing that with the chain id checks being in the invoker and then deploying from create and then deploying a totally different one on a different chain so if we can ensure that the invoker is not malleable then we can formally verify the invoker to be safe and i don't understand these arguments about oh we'll just do it at the client level because it's just code and so if we're going to be writing code to do these checks i would rather it be something that's open and permissionless for other people to try and develop and something that doesn't have to go through all core devs if we take he gave several poses but we

take one of his proposals he suggested well there's things like replay protection that's really hard to do uh in a safe way and the court development team should be the ones who are checking that these are valid proposals and those things should be whitelisted via eips and go through the all core depths process and i think this is just like the wrong approach philosophically for ethereum i think we should be giving tools to developers even if some of those tools may be unsafe but show them how to use them safely and then let them build really strong applications and i think a good strawman of how this can be some can be a safe uh yeah key is if eip 3074 goes live tomorrow and no wallets support signing eip3074

messages with this zero three prefix then no one is at any risk of 3074 uh of malicious 3784 invokers and no one can be tricked into signing a malicious 3074 invoker because no wallet support i think that's like just a different way of thinking about smart contracts that we're not used to generally thinking of these application layer things where we shouldn't be restricting things that people want to do but walls are already doing some restriction to protect their users they're generally restricting users from signing arbitrary payloads and so if you try and sign a message they're trying to prepend the eip191 prefix to it that way you can't be tricked to signing a transaction that might be malicious

and 3074 can be thought of in a similar way it's not it's not a smart contract it's a new domain that wallets should be taking advantage of and it should be the wallets that you're trusting to do this white listing and ensure that your that your transactions are safe the things you're signing are safe and if we can't trust wallets to to do these checks for us and to keep our private key safe and i think we have a lot bigger problems thanks uh sam do you have anything to add sure so i think what it really comes down to is there's a philosophical difference between you know the people who are pro 3074 and

the people who aren't um one of the big like concerns that like you have is brought up is that you delegate control of your entire account to this invoker um and it's an irrevocable delegation it's it's kind of like a very dangerous thing to do and then uh dan actually brought up a really good kind of comparison here is that um you know we have we don't currently have any tools in ethereum to delegate control at all right so sorry um so we don't have any controls in ethereum right now to delegate control so if we want to delegate control we have to build those parameters right and there's different ways of

building them um 3074 give like gives you uh the ability to delegate your entire control into an invoker and then that invoker can then figure out like what kind of system it wants to restrict control when it passes it on so like uh dan brought up this idea of ethereum object capabilities which is you know a similar kind of idea to what unix does from what i understand or linux does but uh i i guess my point is um we just differ fundamentally in how we think the the delegation of uh control over your account should happen um you know we think that we delegation should be complete and that like you delegate complete control to an invoker then the invoker decides what to do with it

and then the other way of doing it is letting core devs decide how to delegate control and letting client and protocol developers so actually i didn't mean for code devs to decide on how to delegate i meant that the the wallet would do it but they wanted to delegate they were they wanted to delegate things by actually signing actually signing the operation so um so this is by actually uh signing the by signing the operation and as long as the user or the wallet on behalf of the user is willing to sign a certain operation then the delegation is uh the delegation

is successful the only uh so the thing i suggested with the oracle devs is only it was only a small in one of the suggestions it was a small part of the of the replay protection so i don't know if we should get into the specifics of that but the general the general idea is uh that is that you are is that the user will have to sign each to sign each operation so

Sam Wilson: um and by operation you mean like a specific call right

yeah a specific call i suggested that it would actually be that instead of uh signing a commit that is interpreted by the uh that is interpreted uh by the contract and then the contract the invoker can do

it can do anything the contract will only be able to do to perform auth calls signed by the user so the delegation is not for the future it's only for the current transaction in order for certain operations the reason i'm so there's i'm so concerned about it i'm not sure i'm not sure i'm explaining it well enough is that um we haven't we have no precedent in ethereum for delegating uh for delegating all the power for like now and in the future and um and i think that the delegations i mean we have delegations for things like voting or an approval in erc20 so different we have different models of delegation but each of

them gives a limited power like if you are if you approve an elc 20 you prove it up to a certain amount and you approve it for uh you put up to a certain amount and only uh and only for certain token so by delegating it by delegating it entirely just the then the the damage is uncut is unlimited and uh and i'm worried that i can a buggy invoker i know that invokers will be audited but we know that auditing sometimes doesn't catch all the bugs especially an intentional bug that someone tries to hide and they and people will have incentives for doing that so i think that the disaster that we'll see in the

if if someone manages to sneak in a malicious invoker that is widely used it can it can be something in the order of the dao if not worse so like uh so that's what worried me so much about this open check approach

Tim Beiko: uh vitalik you've had your hand up for a while

um yeah i just um wanted to also quickly summarize the the issue that i get brought up yesterday in my own youth magicians thread which is a forward compatibility with account abstraction um so basically the idea there is that like i think long term we're going to have to switch to account

abstraction at some point and i mean i think there's a lot of reasons for this like one of them is just the big gains from having smart contract wallets and uh for things like multisigs and other kinds of wallets where you can actually like not just what the what you can do from your wallet but also how your transactions are authorized it can be done using arbitrary cryptographic algorithms um another and another kind of longer term one is quantum resistance right like once we wants to make ethereum quantum resistant like eoas as they currently exist just are going to be dead right and so if there is going to be a future and like regardless of how mediums are more

long-term it is where eoas get phased out and uh everyone is using a smart contract wallet of some kind it makes sense for things done before that to be future compatible with uh um with that world and like my my concern was that the off call mechanism in its current form doesn't really like it feels like you know it goes in the opposite direction of future compatibility a little bit um basically because like what auth is is it's this uh transaction like it's a call it's a call scoped variable um that basically like introduces a new

mechanism um a new way of uh getting the permission to send something from another account now if you know in the future we end up actually having uh smart contract wallets then auth would have to be replaced with some kind of mechanism that calls the wallet and then calls some kind of some kind of authorized function of it and or some kind of or some kind of delegate function but then even that delegate function is not going to have the same functionality because like there is it's really an evm way to do like do delegating that's called scoped and so it's just like basically it it feels to me like a real world

that has off and off call as opcodes and um that eventually move replaces these eoas with upgradeable smart construct wallets is one that's going to have a lot of technical debt that's going to look fairly awkward five years from now and i suggested a couple of alternatives so one of them is uh like i think yoav's alternative uh eiba 374 where you just sign over a series of messages it actually performs much better on that metric uh another idea was replacing off an auth call with pre-compiles um just because like pre-compiles can be replaced with code and they don't just kind of dangle in the evm forever and a third was just explicitly putting a

finite lifetime on the mechanism so developers know that eventually they're going to have to move to something else

Sam Wilson: so i have a couple follow-up questions on that so how do you feel about the um proposal that matt and i sketched out in your thread where instead of putting the signature on the stack you kind of put it into memory a variable sized space and then currently that would just get verified as an ecdsa signature but in the future it would get sent to the smart contract wallet to do whatever verification wants to do on that on that blob of bytes that way today it'll be a um ecd signature and then in the future it can

be upgraded to whatever smart contract wallet system they want

yup that's uh that

Vitalik Buterin: that's definitely an improvement um i think even with that improvement there's still the aspects that like you are or this year like the vip is sort of permanently complicating the call structure in the sense that like you have we already have an op code that does a call and now we have this other op code that does a special kind of call

um or at least at present it does one thing but then in the future it'll just be an alias for a special kind of call um so like i i i guess i do feel like some like that long-term tactical debt still remains and like if for example if it

was a pre-compile then it would be even lower still um but like that that was actually my next question so why is this is probably just my my uh experience with evm but

Sam Wilson: why is a pre-compiled technical debt better than an opcode technical debt

Vitalik Buterin: uh because you can just hot swap the pre-compile for a piece of evm code like in the case where uh like in our specific case what would happen is that the pre-compile would just be hot swapped for a but for a couple of evm code bytes that just directly call the uh like some the delegate function of uh whatever this whatever the target account is

and so you can't implement like an opcode in terms of other op codes right now or right well the problem is that like you

would it would be part of the like inside of the evm you would you would have to have code in that specific op code right like you would have to like it would be a permanent feature of uh whatever whatever file in the in the code that processes the vm op codes whereas if it's a pre-compile then you'd said like for now it would be the same code except it would be in the pre-compile section instead of in the upcode section but then in the future like there would be there would not needs to be any ethereum code for that case at all um or any ethereum client code for that case at all because it would just be entirely bytecode of the contract okay well are we moving in a direction where

we want to be able to get to a place where we can just sink to a certain point and we don't have to verify all the blocks because we can just use the weak subject subjectivity of these two committees and then we can drop yesterdays exactly so to me it's like those are yeah i i agree with that um so theoretically like any feature can be dropped right so that's why idea three for example was just to give this whole mechanism a finite lifetime um but with making it a precompile like basically the benefit is that eventually we can forget like we can drop the code from clients and so client complexity goes down but at the same time like there's there's no disruption to a developer

experience so developers who start relying on that mechanism tomorrow like that'll still keep working 20 years from now so it's sort of a best of all worlds um oh enzgar i see you have your hand up and then uh yeah alex if you want to go after yeah so i just briefly want to ask um a bit of like a more process question or something because to me it feels like it's a little bit of an unfortunate situation that we only have this kind of single track awkwardest call where all kind of the whole spectrum of proposed changes is is being discussed and i think specifically with 30 74

this is like a really good kind of example where we as a team kind of went out and talked with a lot of the more kind of um application focused teams that actually would want to use it and there was a lot of excitement a lot of kind of different input and we kind of tried to to formulate that into an erp then it kind of took six months or something or something like four months for for people to to look at it to get to get feedback now i think actually like a lot of this feedback is really kind of helpful and i'm i'm very much encouraged to kind of there's the version of the ap as is today i still think like it's some of the criticism was unfair but in any case like that definitely opens to changes but like it just seems really inefficient to

which basically always goes through this awkward um [Music] venue basically and then it'll it'll take some more months to add to the next uh proposal and then it'll take them some more months to get feedback on it so by the time then yeah i'm just wondering is there like some like some process change or something that would make it easier to to kind of to to basically separate the kind of the protocol discussion and changes more clearly from the featured discussion in some way i don't i don't know maybe this is nonsensical but that's just yeah yeah i think

Tim Beiko: i see what you mean i think so first of all i think that you know the conversation on

each magicians is obviously like very valuable um i i think the best we can kind of do in awkwardness is like summarize it and point people there to actually like resolve the issue there

i i don't think we can't like we can solve these like you know like clients at the beginning there's there's a lot of subtleties and whatnot um i'm not sure like what's the best like i know there's already like a discord room to discuss this um what do you feel would be like the best kind of i don't know process um yeah do you think we just need like specific calls for 3074 where we can hash this out um yeah and and yeah i guess yeah i'll leave it

at that um i i i don't know specifically like i think you can definitely find this solution for 30 74 to kind of try and be more efficient in discussing it or something i'm just wondering maybe like if the next thing comes around that like it's a bit more on the feature side um if if we basically have to then find a kind of custom solution for it again if they i i don't even know like maybe they could i don't want to propose just in another call or something but it just feels like basically it's it's a little bit inefficient that like the quarter process is this kind of single track um thing where we're all kind of all different kinds of um

of changes are being discussed or something um but yeah i think for 30 74 is like specifically um we can definitely kind of find a solution um yeah i i agree especially i think you know the part where it is hard to separate is the fact that it obviously touches consensus right so it's like

Tim Beiko: at the end of the day you will need clients to implement it um but i i feel like a big part of the conversation maybe does not involve like all the client teams and that's something we can kind of take out right like iterating towards a proposal you know and and having something um yeah i don't know that that say

addresses like the you know the the stuff we just discussed um doesn't have to happen in all core devs um but at the end of the day it's like because all the client teams have to implement it we're gonna need to like bring it up and discuss it here um yeah we we can talk about this offline i'll try to think about it as well like i i agree sometimes this feels like a a bottleneck and um yeah if we can make that flight or if we can make that better

uh yeah we should uh vitalik you still have your end up is that yeah no i just still wanted to kind of

Vitalik Buterin: add on to that that like it's definitely a problem i feel as well like i have some uh proposals that i've been promoting

state expiry is one of them um banning self-destruct uh at uh make uh the the virgo tree um implementation considerably simpler is another one and like these ideas where i personally would want them to be whacked sooner rather than later um just and it's definitely like ideal to have a like a format where you know if people have either have concerns or people wants to and investigate to figure out whether or not what kinds of issues they have and then actually incorporate more people's feedback without it being stuck as part of a a 90-minute call every two weeks

as uh like

it it's definitely something that's that would be really valuable to keep improving yeah and this is i know what we did for 1559 and what uh you know stuff like the portal network is doing is they just have their own kind of different set of calls right like on their own schedule and whatever frequency makes sense for them um the challenge is like as you add more calls you lose the number of attendees and so some of the complaints that like people said is like you know like if you know you do a call for like state expiry and like nobody shows up um that's not great and and i know like we've had calls about state expiry specifically right like the past couple weeks um so i don't know if it's uh if it's like every one of those efforts trying to

like set up their own schedule which makes sense um i'm happy to help facilitate that uh it does feel like when we do things just async at some point the discussion kind of stalls um and maybe that's like the right cue that we need some sort of synchronous call um yeah i think it would be useful for brief discussion on what things people want to see or know about 3074 to feel safer about it because you know i think there are like concerns raised it's really difficult to you know get these things resolved whenever

we're just discussing them in all court depths and there's like less engagement outside of it and it's like a hard problem because i don't want to enforce that people are being engaged in these things especially with the dissenting opinion because that can get messy but it's also how you know how can we work together to get something that is very valuable to the community the community is really desiring to have functionality that's similar to 3074. we've put in a lot of work to bring an eip that we think is good and safe and reasonable to fund mainnet and so i'm curious what things do we need to do still to have it potentially be scheduled for a hard fork

think of a better security model than what you are proposing i mean i'm i'm willing to engage that's not it's not useful i'm willing to engage with you if you want to like actually discuss these things but i feel like your tone is just really disrespectful when we discuss these things and it doesn't i tried to engage with you on twitter after your last awkward device and you need to stop responding so i'm happy to like talk on a call and like try and figure out a better model if you want to do that but i think that just like one-off comments like this is just not really helping us get to where we want to go i'm just stating how it is right now i mean it literally is set your id this isn't linux though this is a very different platform

yeah and user response will get swept away or we will get a permission blockchain in effect i would like to i'd like to kindly erase that i also consider our time stone very often but offensive yeah artem if you could just try and be respectful in your criticism uh i think yeah people would appreciate that um i've i think that the way that 3074 is proposed is actually the least permissioned way of doing something like this i think that the way that that pro yo his proposals is sort of creating this new pipeline of

new things new type of things that need to go through the all cortez process and i understand that like your white listing of replay protection is one specific thing but what you propose is not as powerful as 3074 because you are in training certain things you can't have synthetic eoas if you want to have replay protection that's other than like maybe sequential nonsense or something that's not already built in these are things that you also have to have go to the all quick depth process so what we've presented is something where anybody can write something it's up to the wallets to make sure that it's safe just like wallets have to already make sure that the code that touches your private key is safe and so this is just further enshrining like what wallets are doing to keep you safe and if you don't like what walt's

doing you can fork the wallet this is much simpler than trying to fork ethereum if you don't like what the core does and you really want to do something that 3074 isn't letting you do that core devs aren't letting you do um so i never i never said that uh that all innovation would have to go through the all-core dev and even and only one of the three options i presented actually involved the involved or codes and only for the replay protection so i don't think it's the most it's the most uh the most permissions way to to achieve this because even even if the client needs to sign even if the the wallet needs to sign the entire message

you can still achieve everything you can still deploy any invoker you like and you don't need to uh but you can't you can't you can't deploy any invoker you like because if you're signing over a nonce then the protocol has has to define how that nonsense is interpreted and if you do the way that normal eoas are where it's sequentially validated nods that is the one way that nonstop done if you want to do something different where you have parallel nonsense or you have one off balances these are things that you would have to go and have a proposal to change right so that's that's exactly the that's that's exactly the one exception i mentioned and i suggested deploying a separate contracts for replay protection because there aren't that many methods but even if we completely disregard that

and we say we don't protect the nons let's say that we leave the nonce to the invoker although i'm not a fan of that but still if we get we end up with something much more secure than the current version because the at worst under under attack of a malicious invoker the user the use of the the user's message can be replayed but the user's message can never be modified so if the user never signed they never signed a certain operation nobody can nobody can can trigger this operation in the current version they can sure but then there are other things we might want to do where we have malleability and the call and i think a really great example of this is having social recovery

where you can sign over a list of people never put it on chain and now if you lose your eoa you can use you can go to those people and have them sign some sort of multi-signature and recover your funds and that's not possible anything you propose that's something that again we would have to add as a new feature actually why not why not you can give them a you can give them such signed messages but these messages are specific yeah that you don't give them power to do anything you give them the way you give them a signed message allowing them to make a very specific call to help you recover yeah but you don't know all the assets you'll have at the point of time when you lose your key so you can't foresee everything that you need to

send over uh no it would be that i it would be a call to replace the uh to replace a key that can a key that can sign any message on behalf of this wallet but you can't recover the private key because you were saying that we have to assert all of these all these things like call data and gas and nods are part of this commit in the protocol so then you can't change who can sign over those things no but you can have to recover yeah yeah you would have to you want to together together they would be able to enable a recovery mode

and uh we don't we don't have to dive into the specifics of how this recovery mode works but you can give them transactions that uh that they have to sign that you have to sign in advance and change the state of the uh of the wallet in a way that makes recovery possible but again these are things that we're not part of a proposal that needs to be added through the core devs process this is my point oh why why do you why do you need them in the code as you can so just sorry it seems like we're kind of hitting diminishing returns here um and you know there's a lot of conversation in the chat about having like a separate venue to discuss this uh in in more detail i think that's something we can come up with but one of the things i just want to

make sure we cover is uh alex uh you had some comments with regards to how this impacts uh address space extension so maybe it's sort of just taking like two minutes to go over those we don't necessarily have to discuss them in detail but just so everybody's kind of aware of it and the issue um yes some some background so address space extension basically is the the aim to extend the addresses from being 20 bytes to maybe 32 bytes um and this is driven by two reasons one to increase collision resistance and two um larger addresses could have reserved bits or bytes which can be

used for other use cases and one such use case would be state expiry where the epoch or or period number would be stored there now we have as a team looked into the impact of address space extension on the the current evm and we just released today a longer document with like 15 points explaining the the different kind of issues or at least the impact you have found but i want to mention only two different things here one um with address space extension and even with state expiry with multiple periods

that would mean that a single private key could correspond to multiple multiple addresses it could correspond to like a current short address where it could correspond to a long address or it could correspond to multiple long addresses in different periods and if you have this then i think we really have to look into how the um signature recovery works in the alt op code under eip3074 because you need to make a decision you know which of these addresses you want to to recover i don't have any suggestion i just wanted to raise this as a discussion point for the future

because i guess the main question here is the timing of uh all of these discussions and features if um 3074 is is deemed to be um really important maybe over any of the state expiry and maybe i use the wrong word it's not the importance but rather you know um how ready these proposals are and if you say that 3074 is more ready and it is ready to go in maybe in the next two hard forks um and maybe the state expiry and other space extension is is less ready and it may take like uh three four hard forks from today um in that case um i guess the these concerns

have to be addressed post 3074 but if you think that these two proposals are kind of maybe at the you know similar level of readiness um then then we probably should decide you know which um which we we prefer uh more and adjusts the other one uh so if you say that uh address space extension is something which is really important then we have to to make sure that 3074 works with it correctly and covers all these cases if 3074 would go in earlier then all of these differences have to be handled afterwards um i'm not sure if all of this made too much sense probably

it did to those who are familiar with the topic but yeah please read the document i shared and it may help to to make sense of what i said so can i have just one thought so with this whole address space extension i think we would be opening up quite a big can of worms and if we make addresses exactly the same length as hashes then we are opening up a gigantic kind of worms because all of a sudden you cannot differentiate anymore in code whether something is an address or is hash and i think a lot of things can go horribly wrong in that case

so um i don't really want to talk for or against uh extending the address space but i would really think i really think it's a bad idea to to make the addresses the same length as hashes would 31 bytes be fine in your view anything that doesn't conflict with me okay um i mean if we were to do that we could even do i don't know 34 bytes with some checksums or whatever so okay um yeah thanks a lot for sharing

alex um and yeah one thing uh so micah you mentioned this in the chat i just want to make sure people are aware there is a 3074 discord channel so if people want to continue that conversation there um yeah please do um we only had two other things on the agenda under mortgages kind of for people to be aware uh but first of all um rick added a transaction type list to the eth1 specs repo i'll share the pr here just to try and list basically all the transaction types that we already have reserved and some that are potentially being reserved uh to avoid

uh potential collisions um so for example you know in the case of 3074 their eip uses type three um so just listing it there um so if people want to just review that um yeah i i know like client you've reviewed it already in mica as well um but just yeah this way we can kind of keep a list and it makes it helpful for libraries and and anyone kind of using this uh type transactions to know what are the types that exist and what are the types that are potentially reserved for for future use um yeah i don't know rick do you want to add anything to that um no i think that's it's pretty

straightforward um yeah cool i guess um yeah i'll i'll leave it at that um and we can merge it uh sometime next week if uh if uh yeah there's no objections on it um and then yeah last thing uh also on the eth1 specs repo um like client and and i think the quilt team more generally have been working on a python executable spec for eth1 um yeah like client you want to give some some background there and and kind of share where you're at sure so we've been really impressed with

how the theorem 2 development has gone with their pi spec and there's like many other reasons why uh maybe writing a pie spec for ethereum one is useful but you know the way that ethereum two has been able to use it as this mechanism to discuss changes about the protocol i think has been really valuable if you look at how 1559 it has been described in vip basically we had to you know someone wrote a broken ethereum implementation in python just to describe all the changes so as we're adding new things to ethereum i think it's really valuable i also think that it's valuable just to have a full specification of ethereum and a little bit more readable language

some concern that a lot of people have is that the yellow paper is more difficult to read especially if you don't necessarily have a background in more formal mathematics if you're just a developer it's can be unwieldy to go through so we've it's been taking some time to implement ethereum one and python and this is different than how uh the snake charmers have done this in the past because there have been python clients before what we want to do here is we want to focus on readability not to do the engineering that clients need to do to be performant and keep up with mainnet and all these things these things we want to avoid using any python specific

language functionality we want to just do the most simple way that people who are just tangibly familiar with python can come in and understand how ethereum works and then hopefully one day in the future we can use it to discuss core changes to ethereum rather than rewriting half of ethereum and an eip to kind of set the scene for the change so that's what we've been doing sam and somo on our the cool team have been working really hard to build that stuff out and i think we're having a good place where we're very open to more external contributors there's been one person who's helped contribute who is not part of any of the the core teams that i'm aware of but yeah we've got a lot of issues on on the github and hopefully we can move

it into the ethereum one the official upstream of three and one specs repo and then have a lot of issues that anyone interested can can jump in and help out or if people want to just like keep an eye on what's happening to review those things that would be that would be great another thing the 20 spec 3 post been really used for useful for is um test writing which is to accompany any changes like actually writing tests but then actually using the not very efficient uh but at least somewhat readable python implementation to generate test vectors and i know i think that we still use like a stripped-down version of alice to do that today so maybe in the long term

you could uh consider moving test generation to something like that um and then the e2 specs repo which is kind of like the same consensus layer come the merge um is being written in a pretty modular way that if um an execution layer has certain a certain interface we can kind of plug it in and even do and test generation um which may or may not be useful we'll see cool um yeah thanks for sharing guys anyone have thoughts comments okay um yeah

Tim Beiko: marius uh go ahead update on 36.07

um

this was the issue of interpreting like having the private key to an already deployed contract right yes so

Marius van der Wijden: uh rejecting transactions where the sender has some deployed code basically someone requested us to have a full sync of mainnet with the new rules to see that this has hasn't happened yet it hasn't there's one outstanding issue that we would need to discuss because right now this is checked this clause is checked by by verifying

or by taking the code size and checking that the code size is zero but it might make sense to check if the code hash is the empty code hash

so if anyone has any preferences in in either way i think it should be basically the same but it should be consistent across the spec and across the implementations alex you have your hand up yeah that's that's an interesting point regarding pre-compiles

uh because pre-compiles have zero code and you don't want to impersonate them um and the the code hash i think the erp for the xcode instruction at least specifies you know what should happen in empty accounts or accounts without code etc so maybe that's something to something useful to look look into because you don't you don't want to impersonate pre-compiled either i mean it's even less potentially possible but it would be nice to at least have have it clarified i think red

oh yeah i mean like i don't think because i mean the the difficulty of finding a pre-image of a pre-compiler is like 2 to the 160 so i don't think that that is an issue like you can just ignore that so i wouldn't worry about that like it's a completely different i think the one one is potentially possible the other one we can consider cryptographically impossible finding pre-images of pre-compiled because the pre-compiles are already deployed right exactly like it would have someone would have to have deployed them at and the addresses are like zero one two three right so you can't redo that for these addresses they would have to be

deployed by at a random address and like some developer in this call would have to have influenced that address got it i guess

Tim Beiko: does anyone have any objections about using the code hash rather than the code size okay then i guess we can go with that um that's all we had on the agenda was there anything else anybody wanted to bring up okay well yeah thanks everybody uh so

let's see how gory goes for london

uh next week and um assuming everything goes well uh we'll post a blog for mainnet and uh try and get client releases out for the next awkward devs where we can then share the release numbers to everyone um yeah thank you [Music] thanks [Music] [Music]

so [Music] [Music] [Music]

[Applause] [Music] [Music] [Music]

[Music] [Music] so [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

so [Music] [Music] [Music]

[Music] [Music]

[Applause] [Music] [Music] so

[Music] [Music] so [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

so [Music] [Music] [Music] so

[Music] so [Music] [Music]

[Applause] [Music] [Music] [Music]

[Music] [Music] you

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