Future of Ethereum Accounts, Layer 1 R&D - Day 1

[Music] so i think in the context of all the other things that we work on in ethereum and what we've seen today the ethereum account models are something that is sort of put in the back burner and i think that we all agree in general that the account model that we have today isn't as good of an account model as we could have and so what i hope that we can take away from the talk is ways that we can improve that account model and sort of get a feel for proposals that have existed for a while and maybe help engage with some of those proposals to push those types of things forward before we talk about the existing proposals i think it's important to talk about what would the perfect account look like if we were able to just start over and create an account from scratch account model from scratch and so i came up with some things that i think are really important for an account model and to me one of the first things and most important things is we should have accounts that support recovery whether it's social recovery or other recovery mechanisms because this is a really painful point of blockchain today is if you lose your private key as a new user your funds are completely lost and so i think this is something that the protocol should be able to support natively in the perfect account model i think we should be able to script arbitrary interactions and some of the reasons that this this comes about is because the way that we've developed some of these standards these token standards in the past we didn't think about the world where it would cost 100 200 way to do multiple transactions and so now we're sort of trying to live with the way that the standards were built in the past and so we do need to script arbitrary interactions but i think going forward interacting with dapps are going to be is going to become more and more uh complicated and it would be valuable to script those within a single account rather than needing to stimulate these individually ideally there's no additional overhead so even with a smart contract today there's a small amount of overhead where you have to verify the signature from your eoa and then you need to verify a signature or a multi signature on chain and so in the ideal world the ideal world under account abstraction maybe is is that that would just be part of the transaction there would be nothing additional beyond that i think we should also allow for gas sponsors because as we go and move forward i think more and more we're going to want to abstract the blockchain from users and part of abstracting the blockchain from users is allowing them to interact with different relay networks or intermediaries to conduct their operations on chain and so allowing for gas sponsors will allow us to do that and i think that it should cost nothing in an ideal world to existing or new users to have this account model today with smart contracts even though it does provide most of these things we have to deploy a contract to the chain which at even 20 or 30 dollars is something that makes it so that many of the users that exist in the world will not be able to use those uh these types of things in the perfect account model so if we review the types of accounts we have today we have externally owned accounts which is just you have a private key and you're able to sign messages with that private key and initiate transactions and then you have the smart contract accounts which is some sort of smart contract that provides the same functionality of authenticating your messages from an eoa and then doing the kinds of operations you're trying to do on chain and if we look at the eoa versus contract wallet in the uh within the design constraints that i had laid out and originally we can see that for the most part uh neither of them do all the things that we want them to do the contract wallet is able to do more of the things that we wanted to do but it still is missing out on the in the idealistic case having free accounts and not having any overhead whereas the eoa is free and no overhead but it doesn't really have any of the functionality that we would really like to have and if we expand on pound that and we think about what are eoas and what our smart contract wallets really doing and like what are these properties that is sort of extending themselves to you know not be good in some cases and good and others we can see that eoas are originating transactions but not executing code and smart contracts are executing code and not originally originating transactions and if we think about these two uh different different properties of these accounts we sort of see that there's two design families of solving these issues and obviously one of them would be to simply let contracts originate transactions that would resolve some of these problems and then we could let eoas execute code that would resolve some of these other problems and before i like dive in some of the existing proposals i wanted to come up with a sort of list of metrics ways that we can compare these different proposals because this is sort of a multi-dimensional problem it's very difficult to see why one proposal is better than another and i've come up with five different metrics and so one the first one is adoptability how effortlessly can we adopt this proposal and by that i mean do you need to manually deploy a smart contract manually move all of your assets from an eoa into a smart contract wallet or are these things done by migrating your eoa to deploy code at that eoa so there's nothing that needs to be done overhead how much extra effort is spent beyond what you would do in the world of account abstraction where the contract just initially starts executing code and you don't have to do any additional signature checks just to bootstrap the operation complexity how complex the change is this wasn't on the list of perfect accounts because in the perfect world we wouldn't care as much about the complexity but in reality the complexity of a protocol change is definitely something that can make or break the protocol change and so we should compare each proposal on that axis alignment i think each proposal should also be considered in the context of how close does it move us towards a world where everybody is using smart contract wallets because i think generally this is the direction that we'd want to go to and there are some proposals that move us closer in the direction and some that are more of side quests on that in that direction and then flexibility how opinionated is this feature is this a powerful primitive that developers can use or is this a very tailored solution to a specific problem that's not able to be used in many different contexts so the first thing we can look at is letting contracts originate transactions this is also known as account abstraction and in the account abstraction design space there's obviously an eip for in protocol accounts abstraction 2938 and what this does is this basically lets you send a transaction to a contract without paying any intrinsic gas without doing any signature checks and that contract is able to actually verify the signature and then decide after checking the signature checking the nods whatever arbitrary operations you want to do it can decide if it's going to pay gas for the rest of the transaction and so that when we think about overhead is the most simplistic way of having arbitrary actions with a contract wallet and then there's a new proposal erc 4337 where you have account abstraction but it's done outside the protocol via a suite of a suite of smart contracts and this method has a little bit more overhead if you think about it in context with the in protocol account abstraction because you need to go through the entry point contract you need to potentially pay other relays you need to call into the user's smart contract wallet and so there's a few additional frames of execution that need to be done and accounts that have to be loaded so if we give both of these proposals a report card with those metrics we can kind of see that account abstraction in the in protocol accounts abstraction is very good in many many metrics but it's very bad in a key metric complexity and this is one of the reasons that for the last six or seven years we've tried to push through account abstraction proposals and we have not been able to get much traction in the protocols again and again we realize there's complexity here or complexity there and so even though it's very good in many different of the metrics that we're looking for having an f in complexity means that maybe that's not a viable solution the 4337 erc trades off by being out of protocol and so the complexity is much better but also loses the advantage that it has in terms of it has a little bit more overhead than pure account abstraction it's slightly less flexible than pure accounts abstraction but maybe these trade-offs are the are what's important and the adoptability aspect of these things could actually be really improved if we add some sort of in protocol features for helping users migrate from eoas into smart contract wallets and so that's what i want to talk about as well is how what are some pros proposals that exist for migrating to smart contract wallets this is a design space that has not been formalized as much as some of the other approaches to accounts and so i want to just sort of create this timeline about different proposals that are harder to implement or sorry harder for users to migrate their assets and then easier for users to migrate their assets some of these have eips some of them are just you know informal conversations amongst developers on the hardest side we have do nothing this is what i said before just manually moving all of your assets from an eoa into a smart contract wallet this is obviously you know why these the account abstraction proposals are getting d's for adoptability it's difficult and expensive to do this slightly farther on the spectrum is eip3074 eip3074 doesn't perfectly move us to the world where users have smart contract wallets but it does give all of these like smart contract wallet functionality to eoa users with the slight caveat that their private key still completely controls the assets so it's not a perfect move to smart contract world but on the spectrum it's something that does give a lot of benefit without without forcing users to spend a lot of money next on the spectrum we could have some sort of transaction type that simply deploys code in an address this is a relatively simple protocol change that we could just do and you could say i own this account because i'm able to sign a transaction from this account please place some code at this address and so now you don't have to go to all of your erc's erc20 tokens your erc721 tokens and move them it's immediately updated just by having code and now you can have complete control over over the account at that address with code that is not as flexible as having an opcode to deploy the ad to deploy code at your address though because with an opcode you could potentially batch deployments so if you're a non-smart contract wallet like metamask or rainbow you could have your users upgrade to smart contract wallets in a batched manner by using an opcode over individual transaction type so having it sponsored for users makes it slightly easier because now they don't have to do this they might even be able to start executing their transactions they expect to execute if you want to make us trade on uniswap and you have an eoa you could just batch together deploying code at your address and then doing your trade on unit swap so to the user it may not even seem like you're upgrading from an eoa to a smart contract and then you might have some sort of transaction or opcode that can set an in protocol proxy because even with deploying code of these addresses most likely what they'll be doing is they'll be deploying some sort of proxy smart contract and this is something that's going to cost 20 or 30 dollars just to have 200 to 300 bytes of code that help instantiate the message that was sent to the account and then send it to the actual implementation of the smart contract wallet so doing this in protocol we might be able to reduce the cost of that to only 10 20 000 gas and then at the very end of the spectrum something that would be very complicated to do but also very easy for users is we could just air drop smart contract walls to all of the users have an irregular state transition within a hard fork this is something that would obviously be incredibly difficult to actually do and you know immense amount of bike shedding about what smart contract wallet to give users but this on the spectrum would be probably the easiest thing to do so that's letting contracts execute code what happens if we let eoas execute sorry that's letting contracts initiate transactions what happens if we let eoas execute code instead so there's a couple proposals these are the two proposals that i hear like most people talking about in terms of letting eos execute code and the first one is rich transactions so the short summary of rich transactions is you have a normal transaction object and instead of having just a data field you also have some sort of script field and the script field would be code that is executed similarly to a nic code where you're executing within the con the context of that account and so you might be able to script together two calls one to approve a token and then one to do a transfer from for a token so that would be one and then 3074 often off call this the auth method basically takes in a signature from an eoa recovers the address that signed the signature and then from there you are able to make auth calls as that as that recovered address and so whenever you're in you call to the next frame the message.sender in the next frame will actually be the address that was recovered from the auth op code so if we give these report cards we can see that on the rich transaction side it's very good for adoptability overhead and complexity but very bad for alignment and flexibility it's very very tailored to a specific thing it doesn't support sponsored transactions it doesn't support um it doesn't support social recovery it's very tailored to batching things together and making more complicated interactions like that and then on the 3074 front we see that it's very flexible it's very adoptable because nobody needs to deploy anything but it's less aligned with the smart contract wall division and it has a bit more overhead and a bit more complexity than things like account abstraction uh and rich transactions so i feel like the takeaway from that is that you know these are things that aren't that don't have to be done separately these are things that there's a lot of different dimensions to compare them and i think that we can actually do some of these in parallel and some there's synergies between the two with 3074 i think that there's proposals to actually integrate with smart contract wallets so that it's not enshrining eoas and ecdsa signatures into the protocol further i think there's some advantages of doing this rather than everybody deploying smart contract wallets it might just integrate the concept of proxy into smart contract wallets but i think the ulti at the end of the day 3074 does lack in the fact that the private key still have complete control over accounts and so we do want to try and get users to use smart contract wallets when possible and so hopefully you know with with this workshop later today we can try and find a way forward where we're able to help as many users in the short term but also achieve the smart contract wallet future that we want to be able to achieve and so for the workshop at one there's a few topics that i think that we should discuss i won't like read all of them out but i i do hope that some people will come so that we can actually go through a lot of these things and figure out the best way forward for accounts on ethereum thanks [Applause] [Music]