EIP-3074 and the role of the EVM in a L2 world - Ansgar Dietrichs aka @adietrichs at @ETHDubaiConf

Transcript

hey everyone uh good morning um yeah so as eric was saying um i'm a member of the coil team what we do is mostly ethereum co-development so it's a little bit of a collaboration between consensus and the theorem foundation and this is the talk that i'm going to give and i wanted to start by just giving a little bit of like a motivation for why these two somewhat separate topics and so this erp 3074 that i want to talk about um this is just the the header of the erp um as you can see uh it's basically um in ep that the the team and i we basically created roughly one and a half years ago already

and um since then we've been giving a lot of talks about it just basically trying to create some some um momentum for it and educate people and all these kind of things but more recently people have been come have been coming up to us and have been asking things like will the eap ever reach the ethereum right we've been talking about it for over a year now um can we expect this to have actually become reality and then also and that was what really kind of was the most interesting question to me mo like in the last few months people have started also asking could it maybe be introduced to one of these roll-ups first and then maybe later on come to ethereum itself and that got me thinking and so instead of just repeating the same talk that i've

been giving for a year now i wanted to basically split up the talk a little bit and i will still talk first about the ep so if you have never heard of it before don't worry like i'll explain it but then in the second part of the talk i also want to talk a little bit like zoom out a bit and give some some context and talk about why is ethereum moving to roll-ups again and what are the implications and what does it mean for things like the cip and for the governance of the evm in general um so yeah that's the plan so let's start with the eop itself um so basically the the one line summary that i would give is that with this erp we are trying to allow eoas eos is just accounts that have a

private key so like your metamask accounts are all eoas um to operate like smart contract wallets so you might have heard of noza safe or these kind of things and they these these smart controls really have a lot of really nice advanced features and we would basically the idea was how can we bring at least some of these features um to to the to these accounts as well um and specifically we want to address a couple ux problems so if you've ever interacted with anything really defy related you're probably very familiar with this with this flow where you first have to present an approval transaction and then you send a separate transaction to actually do the thing you wanted to do and sometimes that might even be three four or five separate transactions you have to send and more generally

basically actions on ethereum tend to be like really why is there no ah okay press strong but i think it might be entire latency whatever so um and more generally basically uh actions on ethereum tend to be one-to-one correlated with um with transactions underlying and to some extent that's just a problem with uh contract design but it is also in like a non-insignificant part just a consequence of how the evm is designed today um i hope that this doesn't keep happening let's see okay anyway so some other ux problems we wanted to address are that um

today there is not really good defense against losing access to your ua right if you lose your seat phrase and then your device gets stolen or whatever you might not not be able to recover your ua or you won't be able to recover your eoa um and then also wow um right now it you basically always need ether and that's really not great for onboarding new users so let's just a mixture of different things that we all wanted to address um and by making ua specifically more powerful um and the root problem and this might be technical but if you've ever like looked at a smart contract you might be familiar with this is that the way contracts usually authenticate the user interacting with it is just by looking at this message.sender value and to

explain that a little bit so here's um just like to give an example this is the erc20 standard transfer function and in there you can see that the just to determine which account actually send the transfer so which account do i reduce take the balance out of the contract just looks at this message that sender value and more generally basically whenever you have some sort of smart contract interaction so you you see like the transaction starts at this gray box and then it calls into contract and then calls into another contract and all these things so at every step the message sender is basically set to the the um for the entity calling it and this if you look here only in the very first step is the message sender actually the account

controlled by the user right and so only in the very first step can you do something like send tokens or prove them all these kind of things so basically whenever you have to do you there are multiple things you want to do from your account you basically have to um create a new transactions every transaction every single time um so how do we fix this there have been a couple solutions in the past um the the first one that you might have heard of were meta transactions meta transactions basically is the idea of um doing like indirect transaction routing where the user basically signs the the action instead of directly sending a transaction and then the contracts they interact with know how to handle

these signatures and um as you can see already this is going to be a little bit of a meme i've stolen that from my colleague who's been given this presentation a lot and so this is like the implementation you can already see it adds a lot of complexity that's basically the equivalent of a transfer just in this meta transaction style and then the question is do they actually solve the problem and the answer is unfortunately not really i'm a big fan of the idea of meta transactions but the problem is that every contract has to explicitly add support for them and a lot of contracts don't and so there's not a lot of interest in building up good tooling for it because most contracts don't support it and because there's not good tooling most contract developers don't bother

integrating with it so it's basically like this vicious cycle where it was a really nice attempt i think at solving this problem but it basically got stuck and didn't really go anywhere then the other approach um and that's basically coming right from the motivation of making your ace more like smart contract well it's why not just use my contact wallets directly right it's my contract well it solves this the problem here is that while that's true smart contract wallets are also really really expensive right so basically whenever you want to deploy you know the safe that's easily like a hundred dollars and then every time you use the the wallet it's much more expensive than just sending a normal transaction so it's just really it's a great solution but

just not feasible for most users right and also and that's a little bit of a teaser for the next talk so stick around but right now at least smart controls can't directly initiate trans transactions so you always have to go through some other account first so then if all of these solutions don't don't like fully address the problem how do we want to address the problem well that's where the erp comes in eip3074 and the important thing is that like we don't only want to solve this problem these problems we want to solve it just for free just adding features to the existing accounts that all users already have and mostly love or at least tolerate i don't know um so how how do we do this well we do this by introducing these new two new

up codes these two new basically elemental operating um steps to the ethereum virtual machine and basically conceptually don't bother reading all the details unless you're one of these people interested in all that stuff but the the conceptually basically the idea is the user basically signs over an action they want to perform or multiple actions right like if they want to perform five actions or whatnot or sign over whatever other things they want to allow their account to be used for so that could also be something for for social recovery they could sign over this other person is allowed to send in my name right so all these kind of things you can just put that into a signature and then a contract on

ethereum can use this magic auth functionality to verify that signature and then basically gain the right to impersonate your account and send transactions in your name and then they can use this auth call function to send one to send like a basically like a sub transaction but they can importantly just use that like five times in a row right to do five different things all within one transaction so this is kind of the underlying magic that would make this erp work um and just to look at what how this actually looks like right so the user again is signing the message for whatever kind of use case they have in mind the contract verifies that with the auth and then the then it's actually executed right and this contract that does these

things that would be like a special type of contract you can think of it somewhat similar to like your nose is safe today right and we are calling these contracts the invoker contract because they invoke these special op codes um importantly basically as i was saying when you sign sign a message you kind of you only want to allow the contract to do specific things right you don't want a contract to just take all your nfts and run with them right you only wanted to do whatever you you authorized did you do and the invoker here has the special role of actually enforcing these rules um and that's somewhat of like a problematic security um implication as well that we'll talk about in a second but just to look at how that whether it

works in practice so say this would be like one of these messages you sign and importantly you basically the the type by it doesn't really matter um the invoker address so that's basically you're only granting access to your account to this one specific contract and that contract could be a invoker that's specialized for a bundling transaction or it could be some like a contract for some for a key recovery or for whatever type of addiction you want to use basically and then in the commit that's basically where you where you tell this invoker contract what you intend the the authorization to be used for and so in the commit you could put like a hash that references a transaction right like a nonce to guess

call data and then it would take that and it would actually perform that action or you could in case of like a bundling um a version you could put multiple transactions in there right so basically the commit is your way of communicating with um with the invoker and basically telling it what it is supposed to to to do with with your with your authorization but importantly with the authorization you technically give full control over your account to the smart contract but because it's a smart contract there's no no one can manipulate it or anything you can read it in advance you can see what it what's what it's able to do with your signature so this is kind of the vip at a glance so

what's what's the status of it why why is that on ethereum yet well for that to understand that we have to kind of talk now a little bit about like how do things actually get onto ethereum how how are they included in practice and so just to basically uh give some context so the timeline here we created the ep in october of 2020 um we then picked the first hard fork that we wanted that we hoped the ep could be included in that was the london hard fork last year so in march we proposed the ep for for london technically there was this berlin heart fork before that but there was way too way too short notice basically so so we didn't try to get in there um but then uh

people had some security issues so we also commissioned some audit reports that came back very positive for the ap but then unfortunately august came along and people decided london erp 1559 that is like already a big change we just don't have room for non-topical eips so the erp was not included after all then in september we were like okay no big deal we'll just give it a new try so the next hard fork that will have room for earpiece again will be shanghai so let's just propose it again for shanghai um shanghai will be the hard work after the merge but then unfortunately now basically people looked into what do we want to do for shanghai it turned out there was already a

or a long list of other earpiece a lot of them are really important for example beacon chain withdrawals right you all if you're running validators you want to be able to if you for some reason want to stop validating you want to be able to withdraw your ether out of the beacon chain so that was the important features there were a bunch of other really important ones all lined up and so people again said basically there's no room and so in well at the earliest q4 of this year maybe a little bit later we'll have this next hard fork and again the fp will not be in there right and you can already see it's basically just one opportunity a year if you miss it you're kind of out of luck but then also maybe to to take a little bit of a closer look at what's actually happening

in the governance process um actually the government's process is um consists of two different steps so the first part is the erp process where you basically just make sure that you the proposal you have the idea you have for changing the virtual machine or changing whatever part of the protocol you can think of that it's well specified right so you create one of these earpiece and if you follow the rules that are outlined in this erp-1 which is basically like explaining uh what exactly you have to do and then the ep process just makes sure that your proposal is well specified right that people could just take it and implement it if they wanted to and that there are no open questions no things you might have forgotten about these kind of things but there's no judgment yet in that in that step of the process right or if like

whether it makes sense to to do that or not that's just a formal step and then the second part and that's i think that's where it's really interesting that's the core developer um process and that's where actually all the decisions are made so this is just a screenshot from the bi-weekly uh quarter of calls i can very much recommend like before i actually became like a co-developer myself i i love i i basically watched every single one of these for for several years um they're really interesting but that's basically where all the um client developers research researchers like like our team all people basically involved with the base layer come together and look at okay there's a new for coming up what earpiece basically are are there that we could include and

do we want to include them and and for that basically there is this list of criteria that it's a bit of an unformalist i try to just formulate it here but the idea is basically a a proposed change has to be worth it right it has to be valuable and importantly it has to be valuable enough to justify adding complexity to ethereum right um the second question then is is the change safe there's basically like a very uncompromising um spirit to to to to this step where if there's any question about whether something could potentially break ethereum we will not do it so this is like a very important requirement and then the third one though and that's actually where most of the ap ends up end up stalling this is like do we

actually have the required attention to go through the erp right and the attention that's actually quite a bit of uh of commitment so that's you need to review the erp make sure that there are no no edge cases left out you have to implement the ap you have to do the test all the testing so this is really where most of the work is right and so um then thinking about our erp right first first maybe just let me briefly shout out if you are at all interested in the in this these uh this code of process but you might not want to to actually watch all these calls because they can be a little bit technical i very much recommend following tim baiko on twitter he's the the the guy in charge of the calls and uh he has these amazing summaries every

time after the call so uh do do give him a follow if you if you if you don't already um but like now let's let's come back to our erp so what how basically how did it play out in the in the in the governance process so first off we were on a lot of calls there this is just like a list of all the calls that we were on the agenda for we weren't actually like present like this it wasn't discussed on every one of those but on the majority so there was a lot of discussion about it and then the verdict was basically generally it would be valuable right it's an amazing erp i mean that's my possibly bias take but it's a nice effect let's put it that way a lot of users really like it it would be very nice but importantly

people had security concerns right as i was saying with the invoker contract it can basically take full control over your eoa and then there's this this commit functionality to to limit it and we spend a lot of time making sure that actually we think it's safe but the problem is we spent all that time the rest of the core developers didn't spend the time yet right so they trust us that it's safe and that's of course not enough right they have to actually work through all these these these ideas themselves and that's there's just not enough time for that yet right and so basically what we right now this the situation is that we're in is basically we're waiting that there's enough of a gap in ethereum progress that people just have the free time to go look at our aip and really talk with us about exactly why is it

safe and why basically can we bring it to ethereum without breaking everything that's that's kind of the the position we're in and also there were some some other smaller concerns but we i think we were more confident being able to address those quickly so but that's that's basically a little bit of a of an overview of where where this is basically at in the in the governance process and then um to now briefly go to the second part and talk a little bit about what about roll-ups can they maybe help so um i'll have to glance over some of the details that also like i think proto already talked about very well in his talk just now but basically why did we choose a

roll-up century roadmap in the first place so basically the idea was the early insight like a monolithic blockchain just doesn't scale right you can't have every person in the entire world validate every single transaction so we came up with this idea like we people in the very early days of ethereum came up with with the idea of like let's just let's find a way of splitting up um the activity on the on on the chain so that everyone only has to look at the parts that they're interested in and so the first first approach that people went with was just to say how about we we take a thousand copies of ethereum and we just call them shots and they all run in parallel and that way we get some scaling um

then after that people were like yeah but if we're already creating new chains why not improve them why just copy them we could make them better we could have these e-wasm ethereum web assembly we could have execution environments that basically the idea was to make them more more kind of um customizable and again this is this is not all that important the the the takeaway here is just that um it all this this approach was just not efficient enough right so basically people wanted to add more and more functionality but we needed a way to basically to make this really efficient and this is basically where rollups came in so roll ups how do how do they how they work well and they they basically have a long history of other layer 2 research

before that if you were around in the days of plasma you might still be traumatized from how we spend years in that direction but oh well the key idea that we then finally had with rollups was we can separately trade to treat the the problems of scaling the execution and scaling the data of a chain and if you do that basically the idea is that for execution we actually came up with this these marvelous marvelous techniques of using fraud or validity proofs like vility zk proofs and to compress what the base chain has to do to like a very very minimal amount so execution was all of a sudden basically solved and so the only thing i mean solved but at least

deferred to the layer two teams to figure out let's put this way and uh proto is smiling very brightly right now so um this is very much not a solved problem but at least now basically we have a lot of teams looking at this separately and then for data this is basically now what the scaling effort on ethereum really came down to how do we scale data on ethereum right and and we have all these ideas of how we can actually um do this um and and and this is literally basically now what what we can focus on so how did this play into our our sharding design first we just basically realized we don't need that many uh shots and maybe some of them we only need for data then we looked at the existing ethereum chain

and we were like yeah but we already have an ethereum chain so why don't we just use that as the execution chain why do we even have to create these all these new execution chains at all so this is kind of where the merge idea came from and then most recently people looked at the data part of the equation and were like why do we even need charting at all for for data scaling can't we do more efficient ways and this is where if you if you've heard this on twitter recently this new approach dunk sharding comes from that that makes sharing really efficient basically um and just as a quick aside i think we should call stop calling it charting it's really shouting in name only we now do this more efficient way of data scaling um we should we should find a better name but um yeah i i assume

that's probably like a lost course but i want to put it out there anyway so what's the transition plan here of course next up is the merge that's just like a preparatory step in terms of scaling of course there's a lot of other um nice benefits then as i was saying at the earliest at the end of the year we will have the shanghai fork and ideally there's this uh effort of the erp that porter talked about uh there's this proto-dunk sharding basically they're 484 that would already give us a lot of the benefits of sharing just not the full throughput yet and then we have this fallback erp that like vitalik and i proposed last year they would just make the existing data type the call data cheaper so in case the other one turns out to be too too ambitious for

that timeline we have the fallback plan and then after that is done next year hopefully or whenever we are ready we'll do the full charting and then basically data will be endless and everything will be beautiful um so the so this is kind of the the plan and so now let's let me take the last two three minutes that i have and just talk about the implications and then come back to erp 30 74 and and how that ties in so first off i think this is like you might have heard this term thrown around like the modular blockchain right and i think this is really one of the key advantages of this roll-up centric approach that it's important i think for people to fully internalize right with this move to rollups

we we have be physically unopinionated on how to scale ethereum right we only provide the tools and then all these projects can choose what to do and i don't want to go through this entire list but there's a billion different choices that robs can make and that will lead to really really interesting different trade-offs and alternatives in the scaling space and in that way basically we are replicating all the the benefits that we could get we that we get with um with layer one diversity today but we now all get that on top of ethereum so you have the same shared security the same native interoperability and the same currency on all of them so this is really i think this slide is basically i think what rollups are all about in terms of the value they create

but in terms of the implications and i think this is something that people haven't really talked about much so this is mostly just like a list of open questions but um ethereum was really designed to be a user-facing um platform first right like the evm slid declines tooling all of these kind of features um and now all of a sudden it's mostly a roller management layer right so what exactly does that mean what will the implications be will it continue to be like will they choose copy some of these tools will they use do their own thing it's it's i think very much an open question for now and specifically they are like a lot of open questions for the clients for solidity for research like

how how does this new world work where basically users don't just use the theorem themselves but they use the roll-ups and then on the vm and that's kind of where we're tied back to the ep3074 um basically the question is what how will roll-ups treat the evm will they just copy it or will they modify it and if they modify it how will we achieve standardization right or do you basically have to install separate metamask and separate tools for every single rollup you use and then if they end up using the same virtual machine right [Music] how how how does it work with the governance process right now the governance process that's all

only layer one teams coming together deciding about new features but how do we basically integrate layer two um teams into this process right and so um again there are no answers yet but uh just to leave you basically with like looking at the first the two questions we started with um will the erp ever reach ethereum i think hopefully but we will have to see and then could it be introduced first to some of the roll-ups and then i think basically that my motivation was just to give you a bit of a framework to how to think about this right so i think in order to answer this we first have to just figure out how will virtual machines in roll-ups even look like and what's the path to be taken there and this is this is

basically um what i wanted to to to come to get across and um with that thanks and if you want to find the slides you can find me on twitter and i think i unfortunately don't have time for questions so do find me after the talk outside i think there's a break now anyway but yeah we do have a break and that's fine if you don't have time for questions um i was just gonna say that my my boss dan finlay this is one of his favorite uh eips so just wanted to throw that out there and i have him on slack saying so nice i did have a quick question like so you can have a contract between wallet a and wallet b and uh enable like delegation and key rotation

um [Music] wait can you repeat that like you have a wallet a and a wallet b and the contract could be um enable like delegation and key rotation right yeah i think that that that that would be one of these examples so basically you can you can give control over your account to accept a different account that would then basically you're delegating and then you can at any time revoke that control right so the nice thing is because these invoker contracts are full smart full smart contracts it's no longer just an ecdsa signature you can program in whatever functionality you'd like so this would actually be a amazing use case that i never thought about before and this is the point right we don't want to be opinionated we want to

give you tools and then you build all the use cases you could think of i was going to preface that with this is a silly question but thank you oh it's it's all right well everyone give it up for onscar dietrich and yes we do have you