EIP-3074 - Matt Garnett aka @lightclient - [Toronto Ethereum Developers Meetup]

Transcript

cool yeah thanks a lot for having me thanks cayman for making the recommendation it's helpful to have someone say things like e3074 might be more helpful than 1559 from people other than me because then i just sound like a shill so i appreciate having other people do the showing for me sometimes let me do this presentation mode okay so i do i want to talk about eip3074 and you might have heard some things about it and there's a lot of nuance for this eip and so hopefully we can try and come out of this with a better understanding of what this actually does and at a high level i just want to say that

eip 3074 is trying to allow eoas to operate like smart contract wallets and there's a lot to unpack and what that necessarily means and that's really what this talk is going to be about is what does it mean for an eoa to sort of act like a smart contract wallet and to actually just motivate why we want eos act like smart contract wallets we can look at some of the ux problems that anyone who's ever interacted with ethereum has probably noticed a major one is that a separate transaction is needed for token approvals i think this is the most egregious thing in the ethereum ecosystem and it hurts me every time i have to interact with some protocol and i have to spend two two transactions

just to begin using tokens there's a more general problem with this where actions tend to correlate with transactions one to one you don't see as many transactions doing multiple things when it's just an end user interacting with the blockchain a lot of times it's very sequential they do one transaction due to one thing they do another transaction to do another thing and they're incurring a lot of complexity and understanding what's happening and they're incurring extra costs by paying for these initial transaction fees that are charged for the and this is frustrating to deal with there's not great defenses if you end up losing your keys if you are using a hardware wallet or using a

metamask account and you lose the keys there's nothing that can be done if you don't have a backup of your of your keys or your mnemonic anywhere you're out of luck and this may be okay for the place that we're in today but i wouldn't want to ask my parents or my grandparents to try and store their financial lives in something that could be lost in a boating accident it's also impossible to perform actions without ether and as ethereum the platform continues to grow more and more people will begin to you know receive stable coins and nfts as their first interactions with the platform and if they need to wait until they are

able to deposit some ether into their accounts just to do things with those assets that they're receiving i think that that's a big issue and the root of all of these problems is sort of around how contracts are developed in ethereum and most contra pretty much all contracts today authenticate actions via message.sender and you can look at just the you know the transfer function in erc20 contract and you can sort of see that this message sender thing is how the transfer is figuring out whose balance is going to be deducted and you can see it right there the balance of the person who sent this or is sitting this call is having the value deducted from them that's added to

the destination and pretty much all contracts on ethereum use this as an authentication mechanism to determine who the owner of an asset is and the problem with that is that if you're an end user and you have a private key and a wallet and you're trying to interact with the chain there's only one time during your transaction where the message.sender is actually equal to your address and if you sort of like look at this kind of call flow where the eoa sends a transaction to contract a contract a is able to authenticate the user because message.sender is equal to the user's address and so they're able to do whatever the action the user asks to do as you try to chain things together you you

lose that property yeah contract a calls contract b now message.cinder and the contract b context is a's address b call c message.center is uh b's address in the c context and so there's no way to use the protocols mechanisms for authenticating things and you have to start try find different solutions to this problem so there's a couple solutions that that people have kind of come up with and meta transactions is something that for a long time we thought was the solution to these ux problems and if you're not familiar with meta transactions or you've forgotten this is sort of an example this is the

permit extension to erc20s and it allows you to post a signature on chain that says i'm going to approve this account to spend some of my tokens and this uh this function will recover the address that signed the message and it will make sure that that address the same one that it's calling that this permit function is is calling is holder and it will update the the allowance of that holder and the spender that's passed in and so it's not required it's not relying on this message.sender id and that's what we're looking for we're looking to not rely on messages but meta transactions have been talked about since at least 2017 and they're not really

materializing as a strong solution and i think the biggest problem with medic transactions is they require explicit support in the target contract you actually have to write code in your contract that says recover the address for the signature and then and verify that this is a you know proper action or you specifically say i will trust any call that comes from this contract because they will recover the signature and so there's no way to actually have better transaction support across every contract on ethereum even contracts that are work that were deployed before meta transaction schemes traction i think this is a negative cycle because there's not enough contracts to sport amount of transactions and so

contracts don't necessarily deploy as many transactions support and tooling may not have great meta transaction support because there's not so many contracts and it's sort of this like negative reinforcing cycle the other solution is smart contract wallets and smart contract wallets absolutely solve these problems but there's a very high cost barriers entry to deploy a smart contract wallet and i think you know there's things that smart contract wallets are going to be able to do that eip 3074 can't do but when you're comparing the difference between something that's free which eip 3074 allows you to solve these problems for free

versus something that may cost something on the order of 10 to 100 to get started then that's uh that's a hard trade-off for a lot of people who want to onboard users and i think smart contracts will always have a place you can't have things like multi-sit wallets with 30-74 these are things that can only be done with smart contract walls and so i don't think they're necessarily going away but i don't think that they are the general purpose solution to these ux problems so this uip that sam wilson wrote back to the end of 2020 does actually solve these problems for free and we've iterated on them over the last six months or so

and this is kind of the core of the eip it's providing these new op codes create this sort of primitive that allow you to arbitrarily set the message.sender and so this first off code off takes a signature and it takes a commit hash and a commit and the commit is a hash of the action that you wish to perform that opcode is very similar to ec recover it will return the address that signed the message the auth message and it will set a new context variable to the uh to the recovered address and this context variable is then used whenever off call is invoked and whenever auth call is invoked instead of setting message.center equal to the contract that called that

used the off call opcode it's set as the authorized address and so these are these create a really powerful primitive that you can use to you know develop very arbitrary flows around how to send transactions and batch things together and allow eoas to act as act as smart contract wallets and so we can sort of look at this high level flow just in a really simplistic model first and then we'll look at a more detailed a model of how everything flows together but at a very high level what happens is the user signs a message the contract verifies the message and then the message is parsed into actions

and executed and this is very similar to meta transactions i think that you can think of if you have a good understanding of eip32 if you have a good understanding of meta transactions you can really just replace the part of meta transactions where the ec recover happens with 3074 and you get all the same benefits and can do all the same cool things but if you're not as familiar you will just say you can say you can sign messages to do things like approve die and trade freeze uh if each drops below a thousand then buy eth and you have recovery effects mechanisms like if my nonce isn't updated for three years then allow some arbitrary address to send transactions on my behalf and these are things that you can sign

in some message format and you can send it on chain and this is where the 30 74 primitives come in and so this verification portion is done by this off opcode it takes the signature that the user created over the message and the commit which is that basically the hash of the message and it computes obviously the address that signed it and it sets the the authorized context variable and then that message is parsed into actions because the first thing is doing two actions it's a proving die and it's trading for you so those are two different things so that message has to be parsed into those actions and then each of those actions

are executed with an auth call and the auth call is using the authorized address context variable and so now whenever it hits the die contract or hits the uniswap contract it looks like it's coming from that user rather than the contract that called off call and the contract that called off call is a really important contract in the 3074 world i think for meta transactions they're generally called like bouncer contracts we call them invoker contracts because they're the contracts that invoke the eip 3074 opcodes and the invoker contracts are really important because the invoker contracts enforce the rules that are encoded into

the commit and this is kind of the really confusing part of 30-74 a lot of the things in blockchains are built so it's a very strong security guarantees you know in the ethereum protocol if you submit a transaction and the non says one greater than your current transaction that's going to be valid with 3074 you can have things like nonces and imbalances and uh targets that you wish your calls to go to but it's up to the invoker to actually enforce that those things happen you could submit a transaction with the hash of applesauce and it could send all of your money to the xero address there's nothing that's that's tying the commit

that you're making to what actually happens on chain it's up to the implementation of the smart contract the invoker contract to do that and that's that i think that's okay that we rely on the implementations of smart contracts all the time if you use a nose is safe you rely on the fact that the no system is implemented correctly and uh you know devops 199 can't come in and you know steal your funds so there's a lot of things about this uh about this idea of signing messages and so this is what the message format actually looks like we're calling it this off message format since the auth opcode is the thing that's sort of building this and parsing it and verifying the address that signs over it

and so it takes there's three elements of it the first is a type byte this is just to avoid collisions with other types of transactions and things like the 712 message format then you have the invoker address and this is a critical part because the invoker is the thing that's enforcing the rules and so you don't want your message to just be replayed by any invoker it might be possible to have a malicious invoker that disregards what your commit is and just does something arbitrary like send tokens from you to an adversary so it's important that you're signing over the invoker because it's like you're saying that you choose this invoker and you trust that invoker to do

the things it's like saying i trust betamax to not send my private key over the internet to someone it's very it's very similar in that sense and then you have the commit which is the hash of the action and you can think of like a really simplistic commit as just one message call that's may have a nonce and a two and a gas and a call data and the invoker would process those values and check to see is that non's valid um does the user have enough balance to pay for that much gas and if so then go ahead and send this call data to this target address and then you can do more complicated things you could have multiple calls and one commit and you can have it in some serialized

format or some tree format it doesn't matter as long as it can be turned into some 32 byte value and then the invoker contract will just loop through all these actions and call out to the contracts that you specify with the data that you specified and do those things so now we have we can actually look at how the whole flow works overall and so there's two there's basically two ways to start a 3074 interaction the first way we call self-sponsoring and this is where you are the person who sends the transaction on chain you're the person who's paying for the gas of the transaction and so in that case you send your transaction directly to the invoker

3074 was really built in mind with having a strong end protocol primitive that allowed for sponsored transactions things where you have people who will pay for the gas for your transaction and maybe be paid back in a token of sorts and so in that case the sponsor transaction route you would just sign some sort of off message and you would send it to a sponsor and the sponsor would check to see is this valid message does this user have enough balance to pay me et cetera and then they'll decide to accept or reject and if they accept then they will wrap your off message in a transaction and submit it to the invoker then once the transaction has reached the invoker

the invoker will decode this auth give the spec the portions to the off opcode and the auth code will recover the address and it will set the context variable as the authorized address and then the invoker will continue to parse each action that the user requested to do and off call outs to the targets as that user and so each of the users targets will see the message.cinder come in as that ela's address and so that will loop through you know as many times as many actions that as that user requested to do and at the end of that it will if it was a sponsored transaction it could transfer the payment to the token

and i after that it you general returns and it's the end of the the transaction and so this is sort of an example of how you could have this interaction with the invoker but the cool thing about eip3074 is it's not specifying exactly how these things happen these are just a demonstration of how it might be implemented but you could have it so you transfer the payment at the beginning of the transaction and then at the end you just refund the amount of the remaining amount of gas that wasn't spent or you could have something that says i want to approve this token and you may not even have to commit necessarily to proven it's just implied by the function you're calling in the and there's a so it creates a lot of

ability for people to be creative and actually innovate without having to worry about uh you know going through the ip process and you know hard works and things and so i think that having that permissionless innovation is going to be really helpful to see how we can improve the ux on leaps and bounds even beyond the problems that i mentioned at the beginning so i went through all the amazing cool things about 3074 there are significant downfalls that are concerning and you know we think that even with these pitfalls that 3074 is incredibly valuable but it's important to mention that there are things there are concerns and one of the biggest concerns that we think

can be resolved relatively easily is that it's possible to create a malicious invoker that steals all of the users funds then the way that might happen is that if if you allow if wallets allow anyone to sign 3074 off messages without you know care or reason for which invoker it goes to you could have some you know run-of-the-mill like latest and greatest uh token launch to say you need to sign this message and then you'll be at the front of the queue or whatever and if that happens then you know once you sign that transaction if you sign over that bad invoker's address it could you know go ahead and it could maliciously

create a bunch of off calls based on the signature that you know may or may not have any relevance to what it's doing and it can all call out and send all of your tokens to some other and so that's why we we've talked with minnie wallace and they are on board with this and the idea is that you would have a white list in your wallet that says these are invokers the community trusts and you can only sign 30-74 transactions to these invokers and this is a little bit similar to how signing actually happens in waltz today generally you don't want to allow you don't want to allow users to sign anything because um you might have a malicious adapt try and say that you're going to sign some 712

message that says i am authorized and use this application but it's actually you know a transaction and that transaction sends your ether to them and so generally you need to be protective of what you're signing so that's a concern but i think it's manageable the other thing is that we can't spend ether in eoas and so there's a lot of like good reasons i won't go into too much detail about why that is but generally you can't deduct balance from an eoa in the middle of the transaction this will break in variance in the mempool and potentially open the door for denial service attacks we think that there might be ways of doing that at great cost you know maybe 30 to 50 000 gas to do something like that but in this initial version of 30 74 it's not possible

self sponsoring breaks a weak form of flash loan protection if you're a big smart contract developer you might know that some people try and try and do this check where they say require that message.sender equals tx.origin and that way they know that that that this call has not come from a flash loan or something that's facilitating a flash loan and that is a concern and that is something that we're looking at in audits right now to see how big of a concern is this it's a very weak form of flashlight protection because if you look at what the miner can do the miner can order flash loans across multiple transactions if they have enough capital so it's not it's not a strong protection the last really concerning thing is that invokers can could make upgrading

ethereum more challenging if you have old invokers that people may not use anymore that potentially rely on some weird aspect of the evm if you upgrade and change that aspect of evm and it might open the door for uh for exploits on the invoker now people anyone who used the invoker in the past could be susceptible to being exploited and this is a concern for 3074 but also a concern for a lot of things that are being built on ethereum right now things that are expected to last for decades uh anything that's expected to last for decades that rely on specific things in they are going to make a theory upgrading ethereum more challenging i think optimism is going to be an interesting example to see because they rely on many specific

things about the evm so upgrading the evm we have to take into account how things like optimism are utilizing it so those are the pitfalls this the ux problems that we talked about the beginning i think these are sort of all solved you don't need a separate transaction for token approvals you just sign a message that says do those two things and the auth calls will take care of it that's the same in the generalized case where you know one you have one transaction that does n actions if you lose your keys you can preemptively if you preemptively say uh something like if my account has no activity for one year then allow this account to take over or you can do social recovery schemes that say i trust these 10 people and these 10

people could send transactions on my behalf if they work together and if you want to perform actions without ether of course you could do the sponsored route that's really the thing that motivated eip3074 in the beginning so this is my last slide where eip3074 is today we're targeting the next hard fork after london which is shanghai the current thinking is it will happen in october but these are things that still need to be agreed upon in the all court devs calls it's uh sort of pending on the outcome of these two audits that we have which are going reasonably well but it's this is a really big change and it

is going to open up interesting uh interesting new things that could happen to users and so we want to make sure that's as safe as we can we're working to find people to write these invokers this is obviously a difficult task because writing invoker is almost like writing a smart contract walls and there's not a lot of people who are doing that and we're looking at funding for people who want to do that and for doing audits on those things because these are going to be really expensive efforts the last thing is is that we've got a test net running it's the the pushy test net and the information is here on our github if you want to join and try and write in invokers and play around with it all the information is there any questions that's like a lot of stuff

amazing thank you thank you matt that was uh that was a really interesting talk and yeah really excited to see um all the innovations i guess that 3074 um brings um antoine had a question um antoine i don't know if you want to ask yourself or um or sure well matt so is that going to require you to report your contract i'm guessing yes did you imagine people would redeploy or would it be possible for them to do you mean are you saying this is the goal of this is to not have to redeploy anything the goal of this is that

immediately as this hardwork launches every eoa is going to be able to utilize this and they can begin batching transactions and no one has to support it this is the like idea behind not doing the meta transaction route where you would have to redeploy to support meta transactions okay yeah i started in your presentation it felt like maybe you had to okay that's great that's the huge improvement i have a question go ahead weatherham so in like the meta transaction world generally the people who will be running like the i mean i forgot the terminology but like the relayers i guess um are generally like uh people who are like the the the i guess the uh the

company or somebody who's like running the dap right um who do you envision being like these invokers in the uh 30-74 world so there's two worlds that we see the invoker sort of go with kai's kind of three worlds the first world is wallets might just say you know metamouse might say this is going to be so much better than what exists and if we could be the first one to write a safe invoker then this is going to be amazing it's going to give us a head start the thing is that it's a smart contract and so generally anybody could use it so as soon as metamask does it maybe rainbow wall can adopt that's what we don't necessarily want to do what we'd really like to have happen is we would like you know for the first time this is

truly like a community good a public good contract and so we're trying to have it be built in the open with open source with governance protocols helping to fund these sorts of things and so that would be the ideal world is to say you know there's only three to five invoker contracts in the world and these governance protocols help to build them and fund them and audit them and opens up one help do some things or you know whatever and then everybody can just use them all the wallets can use them their standards for interacting with them and stuff and so that's the ideal world then the third world is that you know you just sort of have one-offs being built for sort of every application and i think that's unlikely because the cost of developing an invoker will be so high it's why it's like similar to the reason

why are there not thousands of smart contract wallets it's really really expensive to build them safely i think that's what we're going to see with invokers i mean i'm not talking about um who's going to be building them but like the people who are going to be running them because like the the the invokers are gonna be the people who end up paying for the gas fees and everything oh you're talking about the sponsor so the invoker is a smart contract right okay so yeah so the people who are gonna be the sponsors or you know this is there's a lot of different ways of going about this and it's like there's like kind of two main classes there's like the centralized providers i guess three classes there's adapts if you're adapt you might want to try and relay your

transactions generally that was more common with meta transactions because the meta transactions require that the dap support them and so it made sense if you had to support it you might as well have like your own custom integration for a relayer what's more likely with better with the eip3074 transactions is that your wallets will sponsor them and so metamask will likely have some sort of sponsoring mechanism or rainbow wall will have some sponsoring mechanism and that will be you know not a lot probably not a huge engineering effort for them to just send their users transactions and take you know whatever is cut out of that and then the third is something like gas station network having a more decentralized way of of um submitting a transaction to this

like network and having them decide who's going to submit it and that's like obviously the ideal world we want to get to that point but in the beginning it's likely that the wallets will you know shepherd the transactions on chain but maybe i just have one maybe silly question but is there not a world where a dapp is sponsoring the invoker for their own users and only their users like i understand that's not an ideal world but is that a possibility it's i mean it's definitely a possibility um you know it's it's definitely a possibility if you're willing to pay if

you're trying to pay for the gas or subsidize the gas costs that's definitely when that would happen because even if you're not building your own invoker you're just deploying your own yeah yeah so that's a good point if you're a dab and you're trying to you know focus on onboarding users i don't know if that's so much as a thing these days with gas prices the way they are but yeah if you're just trying to like help and get people onto your platform you would definitely do that if you're not thinking in those terms you're just thinking like this is a service and i will pay fair market value then i don't really see a value of being adapted to do that other than you know i think that would fall into the walls hands more and then one last question you didn't mention uh governance and stuff like

similarly to gsn do you have stuff written about that i'm just curious how you imagine that that working governance is um as in how these three or four or five whatever um kind of public good invokers could be governed this is a i mean this is a really challenging question that's also something that roll-ups are tackling at the moment if you think about how like a lot of these roll-ups are they're always going to have to be upgrading to keep up to date with what's happening with the ethereum especially optimism optimism is going to have to upgrade with mainnet upgrades and so invokers could go somewhere around like if they can find a

good solution that's decentralized you know upgrade uh the invokers could have a similar mechanism that says like let's just redeploy at this address or proxy or whatever and as long as they this group that's that was somehow created agree then we'll upgrade it um i was talking more about governance in the sense that we would really like to have these you know these d5 protocols with these massive governance treasuries help fund something that significantly improves the core protocol and but also themselves like i did a i did some analysis on how much do people spend on erc 20 token and in march to mid-march to mid april

they spent like 25 million dollars on year saturday token approvals and unit swap users were using something like 15 million dollars of token approvals and so 30 74 will save at least 30 on that if not you know much greater so that's a million dollars a month these d5 projects would save awesome thanks for your talk man yeah definitely thanks a lot for having me i appreciate getting a chance to talk about 3074. yeah i really appreciate it ryan were did you raise your hands there were were you just about to ask a question or um no i was mostly exclaiming at how cool this is but i did have one idea that i wanted to ask not that it

probably has any real world answer but since you have been looking at uh what d5 projects might benefit from this in terms of like uh cost savings or incentives for why their treasuries might want to be involved in the sponsorship of of these invokers um if this were to roll out and like i mean i know the target is october but if this were to roll out tomorrow where what would you expect like the the would it be like el peoples that get the most involved would just be like typical tokens like what would be the first uh major change you would expect in like

the d5 ecosystem to have to be yeah i mean if this rolled out tomorrow everybody would be scrambling to figure out how to ride an invoker and that's concerned i mean that's great but it's also concerning because invoker's not something you would want to scramble to write because you know this is truly a test of we have to write code that is safe a lot of times it's okay to um to have an upgradeable mechanism i just i saw that ens just removed their ability to uh upgrade the ens the ether the dot domain and so it took them two years to be

comfortable to do that and so you know a lot of people are okay with having those rails where they have this like hatch this trapdoor hatch to fix things invokers it's a lot it's quite a bit different it's very concerning to have that sort of the trap door because in your ecosystem your defy ecosystem if you think about like uniswap you can you can you know conceptualize everything that is in uniswap and you can say this is the total value locked in unit swap and this is the worst thing that the uniswap governance people could do if they changed the contract and ran away with your money but with a 3074 invoker because there's nothing at the consensus layer that's enforcing that what you committed to is what is happening

you know what is actually happening on chain if someone if someone upgraded the invoker in a bad way you could steal every single person's funds who interacted with that invoker and so that's why it's something that really needs to be truly permissionless like it's it is a concerning thing and it's you know when we first came up with this idea it was a lot like you know we're handing every developer a gun and they're got it all aimed at their foot and we're just telling them exactly how to not shoot themselves and it's just a matter of them not shooting themselves like it's such a powerful weapon but it has to be wielded correctly so how many months before we get a really big broken foot i mean we're trying to the lead time is

significant to build something that's really safe and so that's why we're starting the pr meme campaign now to try and find people develop and you know we talked with trail of bits and i think that they're people who would be interested in helping audit something like this and so it's just going to take a long time and a lot of people being involved to do it do it right all right well um matt again thank you so much this was a very very interesting um appreciate it thanks for having me i'm back on at some point um yeah sounds good