An introduction to EIP-3074

Transcript

hi everybody my name is matt also known as light client the green pyramid dots on the internet this is my colleague onscar and we're going to tell you about 3074 today i was curious who has a rough idea already of what 3074 is who has a great idea of what 3074 is great who thinks 3074 is a bad idea okay we can talk later so if you can leave this presentation with one thought i would like it to be that 3074 allows eoas to operate like smart contracts

this is something that there have been different ideas throughout the history of ethereum to try and make eoas more powerful 3074 is a new idea to make eoas more powerful there's a lot of ux problems that exist on ethereum and there's a few that have specifically been part of the design of 3074 and so i wanted to go through a couple of them as you saw in the last presentation and anyone who's ever interacted with ethereum having to do separate transactions for token approvals is painful and someone who has a pleb dejan score it's still painful for me so this is a big problem and more generally actions tend to correlate one-to-one with transactions

on ethereum and this is partially due to the way that we've designed contracts on ethereum but partially also just due to how ethereum virtual machine is designed there's no defense against lost keys and it's unfortunate that the people who are most most susceptible to losing keys or the more novice users the new people to ethereum who don't really maybe understand the security models of these things and they're the people who come in with eoa accounts and they just have private keys on their phone and when they lose their phone or you know lose their mnemonic somewhere they're the ones who are losing their funds and i think it's really unfortunate there's not a mechanism without forcing them to deploy a smart

contract to recover those so to me that's a really big ux problem i also think that not being able to perform actions is without ether is a big problem sponsored transactions i think is something that can help bring new people into ethereum much easier and i think that solving that problem at the core layer so that it's interoperable across all smart contracts will really help us bring new people into the space a lot of times people might not even receive ether as their first asset anymore they might get dye or nfts and we want them to be able to use these across ethereum without having to pay ether and we looked at these problems we tried

to figure out why are these problems here how can we solve them and so we found that there's kind of this root problem that contracts tend to authenticate things with this message.sender construct i took a snippet from the ert erc20 implementation this is the transfer function and you can see that there's two parameters this two field and this value field and it kind of goes through there's you don't pass in a from field though the from field is the message.sender this is the person who's actually paying for the transfer and the message.sender it's this implicit authentication based on who called the function and you just assumed that whether it was an eoa

that signed a transaction or a smart contract that called the crc 20 token there's this implicit idea that they authenticated that action and so it's okay to deduct the balance from them and send it to the the account that's listed to the two and if we zoom out and we look in at what is like a normal call graph for an ethereum transaction we see that there's only one time during a call graph where the eoa message.sender is equal to the user address and so if you call contract a and contract a calls another contract and another contract you never again have this property that the message.sender is equal to the eoa and so if you're building a lot of smart

contracts that rely on these things like message.senders use to authenticate it then you have correlated your actions one-to-one with transactions so there's been a couple like solutions that have been proposed to get around these ux problems and the first one is meta transactions and if you're not familiar with a meta what a meta transaction is it's this is like a snippet from the erc20 extension for permit basically what you do is you sign a message this is an eip712 message and you say i want to authorize this specific contract to you know spend some amount of my tokens and then they do an ec recover to figure out who was the person

who signed it to figure out who authenticated it and then they add that approval in the token contract and you can probably tell by this meme that i don't think that this solves this problem but the joke is that i am the clown because i thought this was the solution in 2018 and i was really strong met a transaction person but after a while it just kind of became clear that there's a lot of things that existed on ethereum before meta transactions and meta transactions require that we have explicit support in the contracts and if you don't have explicit support you have to redeploy your contract and this fragmentation is really one of the biggest problems

when you're trying to build interoperable standards on ethereum and it kind of turns into a negative cycle where you you have this standard that works but you need everyone to support it but the tools don't support it because everyone doesn't support it and then everyone again doesn't support it because the tools don't support it and so it creates this negative cycle and so there's another solution smart contract wallets and smart contract wallets are great and they're kind of like a super set of what you can do with 3074. with 3074 there's always kind of this eoa that has like control you can't have good spending limits you can't have great true multi-signature wallets but they're expensive to deploy five to a hundred to two hundred dollars

depending on what the gas prices of the day and there's a really big difference between something that's free and something that costs money and if we're trying to onboard lots of users the activation cost of getting them just to deploy a smart contract wallet even if it's the simplest type of smart contract while it is significant and there is another small issue that smart contract wallets can't instantiate transactions and so if you have a gnosis safe you still need an eoa to actually descend the transaction on chain or you need to find a relayer to relay your transaction and i think there's going to be ways to get around this but at the end of the day like what what we want is we want to solve all of these problems for all users and these last few points are like

really important we want to do it for all users and we want it to be free so now i can like talk about how 3074 actually works and we'll like look at see how do we do it for all users for free um the two op codes that 3074 introduces is auth and off call auth is kind of the magic behind 3074. it takes in a signature and it takes in a commit and we'll look into more exactly what this commit is but you can think of it as a hash of the actions the user wants to perform it returns the address that the auth it returns the address that's signed this auth message and it adds a new context variable into the evm called authorized

once you've called this auth opcode on a valid auth message this context variable is set as the the eoa that signed it and then you can invoke the auth call op code it behaves almost exactly like the call op code does today with the slight caveat that it takes the authorized context variable and it plugs in as message.sender and so this gives us this property now we can arbitrarily set message.sender throughout the execution of a transaction so if we look at the high level flow about how this would work in on mainnet you can think of it as the user might sign a message they send the message on chain through some mechanism the contract would then verify the

message the contract would parse the message into actions and then each of those actions would get executed and a couple examples of 30 74 things you might sign you might sign something that says approve die and then trade for eth or if eath drops below one thousand by one each or if my nonce has been updated for three years then allow x account to make transactions on my behalf and so any of those things are things that you would sign it would become part of the commit and you would send it on chain and this contract would invoke the auth opcode and it would recover that address that is your eoa that signed the message that would then parse all those actions that you had

signed and then execute them one by one with the auth call calling out to your token contract or to your uniswap contract to do the trade and in the 3074 world we call the contract that does these actions the invoker contract and this is a really important part of 3074 because we're basically creating a smart contract wallet that everyone passes through and so the invoker contract is a very important part of the 3074 world we would say that it enforces the rules that are encoded in your commit because the protocol isn't the one enforcing things like replay protection or whether your trade went through or any of these things

you're tr you're basically delegating your trust to a smart contract just like you would delegate your trust to a smart contract wallet if you decided to deploy it in deploy a smart contract wallet instead if we look at what the auth message format actually looks like the thing that you're signing as a user using 3074 it looks something like this there are these three elements the type by the invoker address and the commit and you can think of the type byte as this discriminator that sort of discriminates so it says only only messages that start with the byte byte03 are valid in the 3074 world and so that gets rid of anything that was signed under like 721 or eip191 or transactions none of those

things can be considered 3074 messages and then it further constricts the domain of things that can be signed in the 3074 world and so you bind your message to a specific invoker this is similar to saying i trust nosis safe so i will deploy a gnosis safe it's just the reverse rather than signing a transaction that deploys a gnosis safe you just sign a message that says this is the invoker that i plan to use and then the commit is an arbitrary 32 byte value that commits yourself to some actions that you want to perform and the invoker will then parse that recalculate the commit and make sure that those are the things that are those are done and so what might a commit look like you could have a really simple commit that's

modeled similarly from the transaction it could just be a non-situ a gas a call data you can do more complicated things you can have multi calls and so you would call the auth one time you would you would recover the address that signed that this specific auth message and then you would just loop through the message the actions for each of these calls with auth call and you would send these out so that's kind of like the the idea for 3074. if we looked at like a more full use case of 3074 there's two different types of use cases to consider the first one is a self a self-sponsored transaction and i think that this is this is this top

line at the very top so the transaction is sent directly from the eoa this means that they're not going through some different service uh to send the transaction and so the way that that works is the user signs their auth message and they directly send the transaction uh with that that encapsulates the signed message on into the invoker on chain if you go through the sponsored route you would send your auth message to the sponsor and they would determine if that's something that they want to relay you know you might say i will pay you like five die to submit this transaction they'll look on their end and it'll determine if that's worth their effort and if it is then they'll wrap the transaction and submit it on chain once the auth message has been submitted on chain it will go to the invoker and

the invoker will run the auth opcode on that signature it will recover the eoa that signed the 3074 message and then it will set the authorized context variable to that ela at that point it will again parse the actions and go through some sort of loop and just run execute each of the actions that were listed in the commit and so it would off call out to the user's target that they specified that would return it would again off call whatever was specified at the end if you went through a sponsored transaction route you might need to pay your relayer and so at the end you could have some sort of payment that goes to a token and then sends the balance to the sponsor and then at the very end you of course have like the return value that goes

back to the user so i painted the super rosy picture for 3074. they're of course pitfalls for 3074. it's important to understand how how significant the care required to develop these things are this is like developing a smart contract wallet except not one that tens of thousands of users will use but one that potentially every user on ethereum might use it's the kind of security that the care of security that went into the development of the contract for the beacon chain deposits it's really really important that everything is done safely and securely this isn't something that you do one audit this is something you do two audits and that you formally verify i think like developing an invoker i

think the cost and the difficulty of developing will mean there are on the order of tens of invokers to really exist it's such a large effort such a public goods effort that i don't expect dap developers to be using these types of opcodes this is really something that's going to be a public good that everybody will be interacting with and will hopefully be developed in the open through community funding a current caveat of this eip is that ether can't be transferred from eoas and the reasons why are probably out of the scope of this talk but we think that we can remove this restriction in the future and we've actually written it into the eip so it's very easy to remove the restriction

if we can if we can show to the other client developers that it's reasonable and if you look in the eip i didn't specifically go over this there's two different value operands for the up or the auth call op code there's value and value ext value actually deducts the balance from the invoker contract and value ext would deduct the balance from the eoa the address that was as that was set as the authorized context variable right now the eip specifies that it's only that a invoke invocation of the off call opcode is only valid if the ext value is zero in the future hopefully we can remove that restriction and allow ether to be spent

self-sponsoring transactions are on great use case but unfortunately they break a weak form of flashlight protection by break a weak form of flashlight protection i mean some contracts have this line where they say require tx.origin equalmessage.sender and this the idea the thinking behind this is that the only time that can be true is in the first frame of execution and if it's true in the first frame of execution then there was no way they could have gone out to a flash loan and brought in a few hundred million dollars i say this is a weak form of flash zone protection because there are people with hundreds of millions of dollars that can come into your contract and break your economic assumptions there's flash bots that could allow multi-transaction flash loans

so it's not really the strongest we've also had an audit done that empirically analyzed mainnet contracts and it doesn't seem like this is going to significantly break many things so i'm going to hand over the mic to onscar he's going to talk about some of these use casing examples and then at the end we'll do some questions just okay right hi hi yeah so matt already kind of explained the the function functioning of the ap and the design philosophy and now i wanted to just go through a couple of very concrete use case examples and the uh the lens through which i want to do this is what i call like the

the spectrum of trust and so what's the spectrum of trust well in 3074 there are generally two parties involved there's the party that signs the message so that is the the eoa that used to sign it and then there's of course the party that ends up putting the transaction on chain and as matt was saying sometimes that can be the same and what we call self-sponsoring could be some external um party so basically the question is like how's the trust relationship between the two and depending on that like the role of the invoker is to mediate that and make sure the the use case can be um done in a secure way and and that's basically the lens i want to talk about then there's like an exception an interesting one that's called synthetic eos which i'll touch on at the very end a quick

disclaimer i'm not so great with like graphics and memes and so on so you have to like bear with me here um not quite as shiny as the first part uh okay let's go so the simplest example um and might have of course already kind of touched on that is just batching transactions so because usually you can only have one top level um execution so the nice thing now is that with uh 3074 basically uh you can just sign multiple actions and that means i don't know uniswob you approve and then you transfer token and um and all that is now part of one kind of outer transaction um the interesting thing here regarding this trust aspect is that if you if you have an invoker that already um ensures that basically it requires that

the sender that calls into the invoker is the same as the sign of the message then then you don't have to actually use the commit for any further restrictions because then there's already perfect trust right it's the same person so there's there's no kind of like implicit trust assumption so you don't need to actually use the commit and the nice thing is you don't need to build in any like replay protection or anything um and that makes this kind of invoker super efficient so basically right because like even a single um store and like s load they are really really expensive so bundling that way not only do you have great ux improvements but you also have really kind of significant guest savings i think might you looked into that right late even like at least in high gas situations just uniform users alone would save multiple

million dollars per month um just on this and so uh yeah so we don't need reaper protection we don't need uh revocation mechanisms there's like a full stress in in this specific scenario uh let's now look at the second one and this one is conceptually i find even more interesting um and i think that you only had like at the very first slide you said like one of the things you guys currently can't do is like protection against lost keys and and i wanted to basically get back to this and explain how 3074 changes this because this is really interesting usually like when you create a like a new account metamask or something it gives you the seat phrase and you write that down and then you hide the piece of paper right but there's always this implicit tension between being very safe that you never lose the

information so you might want to have it at multiple in multiplications or whatever but you also want to keep it secure right so you don't want like that anyone i don't know robbing your place easily can just find find that piece of paper and so there's always this kind of implicit tension um whereas in the um users might just be lazy right like i don't know i have definitely for like throw away accounts in the past i've not bothered writing the thing down but just copied it over when it takes edit or something it's not idea and and so uh for smart contact wallets on the other hand we have this very sophisticated world of recovery options where you can have social recovery where your friends can basically come in and recover access to your account or you could have just multiple other accounts set that like in a multi-sig

fashion can recover your account and you can have additional restrictions say only if you haven't used the account in a certain amount of time or if they want to try and recover it you have some period in which you can intervene all of this and basically with 30 74 now you just you can put all this into an invoker so you just you use the commit field to specify the exact recovery um conditions and you sign the message once you create the account you put it somewhere where you can't forget about it you don't have to keep it safe because no one else can use it um so you can even if you really want you can even put it on chain um and then if you ever lose access to your private key no problem you can still use the account so of course i mean ideally

you'd want to move out of it but at least you don't have any stuck funds any lost funds so this is really nice and now if you basically go through these trust categories again so we um uh we still don't need repair protection because like once once you're authorized it's like you specifically like the whole point here is indeed you can't even have replay protection because you want this one signature to be used to like take over full control of your account that's by design but in this case it's actually really useful to have revocation abilities built in so basically if at some point you you had social recovery but um uh either you don't you like your friends end up not being your friends anymore or uh maybe just like their their machines were compromised or something you can always like just

um go to the invoker contract and they just have some in storage revocation mechanisms and so in this case you could say the trust is kind of partial you have like more restrictions in place with the commitment and everything but it's still you kind of you still have some trust assumptions that once they are authorized you fully trust them and they get control over your account and then um and maybe like just briefly and i think we have time for that just briefly uh take that as an opportunity to like just for a minute talk about you the the philosophy because of course key recovery again is something that you you already get with um smart contract wallets and batching you also get with smart contract wallets and so this so basically like what we want to do

um is not we don't want to kind of like um replace smart contact while it's quite the opposite actually so ethereum like in the future has these plans that we want to move away from eoas and we want to move to the smart contract world but right now there are multiple challenges with it it's expensive only power users can use it but also things like just because it's such a small user base that uses smart contract wallets a lot of the things just aren't supported by depth so like for example bundling uh many of these smart contact worlds have bundling ability abilities but because the uniform interface does not allow for you to bundle the approve and the transfer you still even even as someone with a smart contact wallet you basically still have to do them separately and that's just because the user base is

just not big enough that they make sense for them in this world where now all of a sudden all accounts get these this kind of what i would consider a minimal version of a smart contract for free basically now all of a sudden of course all that developers have a user user base that all want to you be able to use bundling and so so in this world we will basically much sooner start moving into these more smart contracts focused um capabilities and we have this much more gradual ramp up where basically new users get this the smart contract wallet lite and then you're already used to how to up how to use all these smart contract functions and so if you ever then move to a full smart contract wallet these things like social recovery and everything they come very natural to you and once we then move the whole ethereum

network to that basically hopefully with this erp we have already um kind of taught users how to use all of these capabilities so in in that that's the kind of way because people came came to us and were a little bit like confused like how does it fit in with the vision of smart contact worlds that's kind of just what i wanted to briefly kind of um yeah um to talk about and then to come back to the actual examples uh a third one now for the trust assumptions right we had like full trust we had partial trust now to have like a like a example with no trust um i met you already i also um talked about this one that's a transaction sponsoring so i don't know you most of you might be aware of like for example the gas station network so

there's these kind of systems where um you have someone else pay for the transaction and uh this is just like a really nice nice nice way of doing this 30-74 which does not require this opt-in by every single app and so it's just basically it just works and basically and if we just briefly look through the categories again so this time because of course you don't trust the sponsor right i mean you want them to only do the things in your name that you actually want to be done so this time you'd actually have to fully restrict all the operations in the commit so you'd have to put all the like nones too guys call it or whatever whatever you you want to the action to be restricted to you won't you have to put all of this into the commit um you also uh that that of course also

includes replay protection and importantly also because there's this attack where you sign a message and then they never put it on chain and maybe it's a unit swap trade and then a month later they could execute it when the price is at a very kind of unfortunate other level and then they could front run you these kind of things so in order to also protect against that you'd also want to have like revocation capabilities but all of this you can do very like natively with invokers so so all of this just works out of the box and in this case there's no trust between the signer and the party putting it on chain and those were kind of like the three main examples and then last thing i wanted to briefly talk about is just uh what i mentioned earlier what we call synthetic ease and this is like a really

interesting kind of fringe use case that turned out to also be really useful for 3074. um and to explain this just uh so so the idea is basically in all the other use cases i talked talked about so far um the account that signed the transaction was a real proper eoa right so you you have an actual account and you sign these messages but the way these uh ecds just happen to work it's like a cryptographic quirk if you want to um you can also just come up with signatures that look valid and you can like recover an address from them but but it's basically like an artificial signature so there's no real account you don't need a private key it just gives you an address that's empty so on chain there's nothing there but it gives you control over that empty

address right and that's a good thing because the address wasn't used by anything because it doesn't have it's not a contract it also doesn't have a private key attached to just sitting there on chain but now you can basically take control over this with these synthetic signatures and so like a very simple example that's why i put it first is just like centralized exchanges if they want to have deposits right now they basically have to give every user a different address and then they have to go on chain and do all these collect actions and it's really expensive and what they could do instead is just they give you just one of these synthetic addresses and then they don't actually have to have ether in these addresses or whatever they can just like have one central invoker that then just iterates through them and it's basically

one withdrawal transfer in a transaction instead of a thousand for four thousand users so this is like a really nice um application and the interesting thing is here trust is just not a thing right because there is no actual account signing the messages so we don't basically don't have to worry in that sense about trust and like just two two quick other examples of that use case as well because it's again it happens to also be like a really huge thing with 3074 and also illustrates the general point here we want to make the op code or the the earpiece as like flexible as possible to allow all of these different use cases it's really super charging ua capabilities so the second to last example here is also really interesting actually so um it's one of these things that met uh listed as like

things we can't really get with 3574 it turns out we can kind of get them that is alternative authentic authentication methods for accounts so say i want to have an account that is that i can control with a bls signature right what i would do is i would basically create one of these synthetic accounts and then i would have an invoker that would only let me control that specific account if i successfully pass in like a valid bi signature and so that way basically all of a sudden there is an account on chain that can only be controlled within bli signature so even this this is kind of possible although i mean i wouldn't necessarily recommend it but it's definitely one of these things that just 3074 made possible that wasn't possible before and last example in this uh category and

just test um basically presentation was already finished without this but then like we just had to talk to people and it's just so so exciting to me at least this example that like i really wanted to put it in that's state channels where i'm not sure how familiar most of you are with like how stations work but basically it's just two parties that exchange off chain messages and then at the end they basically close the channel on chain one on one time it's basically a way of having high frequent frequency communication but you only have to touch the chain once to open the channel once you close it it's really efficient but for many of these stage channel use cases you you want to basically uh you have some some control over tokens or whatever where maybe i don't know you have micro payments and you you just

you you stream some money or whatever and at some point you want to stop and now you want to redeem the tokens and what uh many of these systems used to do is that they would then once you actually want to close the channel they'd have to do really expensive on-chain operations where they basically deploy a contract at a new address that then is basically in charge this is what you might have heard of these counter factual contracts in in in the context of of state channels it's really expensive and with 3074 you basically get like a much cheaper way of closing your channels because and and uh also a way that is is more robust against things like um address collisions where basically um you just send your tokens at the beginning when you open the channel to one of these synthetic addresses and

then when you close the channel you do that via an invoker and then the invoker can just give you access to that specific synthetic era so basically again probably not too relevant for most of you here but the kind of the takeaway here should just be this is like a single erp that allows like a whole host of different um of different use cases and so it really really super charges what uas are today on the network while at the same time hopefully just being the first step in the transition to full smart contact wallets and not kind of contacting them and with that matt you want to do the final few slides for us so just going back through these ux

problems that we looked at at the very beginning onscar showed us how we don't need to have a separate transaction now for token approvals we don't have actions correlating one to one with transactions anymore we can bundle them all in one transaction and submit them through an invoker we have a great defense now against lost keys immediately as you sign up as a brand new user to ethereum or to metamask or whatever wallet you can immediately figure out some social recovery mechanism and we showed how you can natively have sponsor transactions supported without adding support to any explicitly to any target contracts so we solved all those problems the

problems that we set out to solve with 3074. so where is 3074 today we've proposed it for the shanghai fork the shanghai fork is scheduled for some time in november december depending on when the the ice age goes off we've done two audits of the spec we had an audit of the spec by least authority they analyzed the specification itself looked for security concerns that existed in it we had an audit done by this firm called ddob and they did static analysis of some of the contracts that exist on mainnet trying to see how are these things like self-sponsoring potentially going to break them and we had pretty good results for both of these and you should be able to find these online pretty easily if you go to

the eip and then go to the ethereum magicians link that's in the eip that's kind of the place where you can see all the running information that's going on about this eep we do have a grant available for an invoker integration prototype we just got some funding from molok dao so if there are some full stack front end devs who are really good with some defy applications i don't want to make a little bit of money we would really like to have someone just try and implement this and maybe uniswap so that we can show people like how much better the ux is going to be whenever we have these things so our twitters are on the next slide and or come up to me after if you want to ask about that and then last we do have a test now running if you want to play with these

things it's the pushy test net you can access it on github there's also a lot of resources on that github page if you're interested so these are our twitter handles feel free to dm us with questions if you're here or live online and then we're open for questions in person hey guys um well so first of all i think we talked about this on twitter but i thought i'd bring up the question again um i know i saw some developers that were talking about using basically um

these off opcodes in their contracts so instead of doing like a batch transfer from uh that they would just use the auth directly to like transfer from the user tokens from a user's address and i think we kind of talked about why there's a number of reasons why that's a bad idea for for security for breaking composability but um so i think kind of one of the challenges is like how do we ensure that um that this opcode is only used by like the few list of trusted invokers and that developers aren't like putting this basically giving like root access to eoas in in arbitrary contracts yeah that's a really good question and yeah thanks for bringing that up on twitter as well um the one of the like really interesting things about 3074 is is that it's this sort of honey pot

for scammers to try and get you to sign one bad message and try and get you to use a malicious invoker and if that ends up happening it's kind of like you've just given your private key away to someone on the internet and so we think that the way that this is going to roll out and be used by users is this is really like giving wallets teams a lot more power in the world like right now their wallet teams don't eoa wall teams don't really have much they can do they can store your private key safely and have really nice uis but with this they're going to be able to do batch transactions and support lots of interesting things and so to keep their users safe what they'll likely do is have a white list of allowed invokers and that white list would

keep dapps from just deciding to integrate 3074 opcodes in it because the um the difficulty of the wall of team auditing those things is very high they're going to expect several audits formal verification and dap teams are not going to generally be you know able to expense those types of things and also like that's a good point on the the composability aspect you don't want to have you know midway through a call graph expecting eoa signatures that kind of like breaks the composability of things like smart contract wallets that may not have things that we understand as eoa signatures and so that's like a community standard that we need to just say if you're if you're adapt you shouldn't really be using this this is something

that we need to think of as like a different level of smart contracts something that's a community good like a community smart contract wallet just to briefly add to this uh so it's one it's really important to say basically your wallet wouldn't even allow anyone to request such a signature right if it's for an invoker that's not on their list they just don't even ask you you want to sign this they just reject this outright so there's really like no no risk there and like the the more broadly like the security um model is really actually the same as it is to today already for smart contract wallets right so similar to how you trust the gnosis gnosis team that they wrote safe code basically and it's heavily audited but then they can like write in all of these extra

functionalities that they want as long as it's it's safe and this is basically the same assumption just with the benefit that you would have these erc standards like you have an esc 5000 invoker or something so it's not only audited specifically for the gnosis or for the argent or for whatever the wallet team right but it is audited for the community as a whole so you can have even like more thorough um audits and so in a way i i personally would even say it's it's it's safer than the standard um small contact wallet trust assumption thanks guys thank you so for the record i'm the one that raised his hand and you asked if it was a bad idea i saw so what you are describing both i mean

and everybody is open that's very nice it's it sounds like a ticking bomb and there are very good use cases and it's also very dangerous and you're starting to discuss about potentially restricting usage or reasonable usage to white lists or invokers and personally i think that's not the philosophy of ethereum but again that can be discussed it sounds like the main use case to me is we having someone else sponsor the transaction and batching transaction and obviously there might be additional very good corner case when you can do nice tricks but this sounds like the two main use cases and since the the berlin hardware we now have transaction envelopes and there has been a proposal arc aip

2711 if i remember correctly that proposed to support with that transaction natively at the core protocol layer and it sounds it feels to me like it would achieve almost the same goal uh with not as many downside and the there is maybe you can do a bit more with 3074 but you have to be very very careful in invoker and i think this is potentially dangerous so i'd like your opinion on 27-11 against 30-74 that's a good question um so it's it's funny because 30-74 as it is today has come down a very long path i did a lot of work on 2711 and 2017-18 back last year when they were kind of being proposed

and i wrote another eip 2733 that's actually exactly like what you're describing it expands on 27 11 builds out more functionality and i felt like it was very fully specified and then i presented it to my co-worker onscar and sam and they kind of shot it down because i was like oh you know we'll just do all of these things in the mempool and it was a very brittle design that solved just those two problems these like batch transactions sponsored transaction in a very brittle way and the cost of implementing in the clients i just didn't think we could convince core developers that just those two use cases in this one exact way that we think today is good was enough to bring that much complexity to the protocol

so they kind of convinced me that this like new mechanism this 3074 style mechanism that's very expandable you can design arbitrary functionality around this primitive and i guess that's like where the philosophy that i have of ethereum comes from i as doing core development want to give developers like powerful tools where they can do really exciting things and it's a bit of a balance we don't want to give them tools that it's easy for them to shoot themselves in their feet but if things can be used safely and the evm you can do anything you want you could design a token standard that's unsafe and we still give people the ability to develop these kinds of standards and so for 30 74 i feel like

if we help developers understand like what is required of developing safe invokers we do the auditing and the formal analysis we can have code that's safe but it's it's a balance of you know how how hard is it to make it safe how likely is it for people to do bad things this is the thing that wallets this is the deal that wallets are going to come in and they're going to say these are the invokers that we trust this is giving wallets more power to try and have more functionality for their users and this isn't really a different security model than already exists like your wallet has your private key and they can do anything that they want

they could deploy a new update that sends your their your private key to their servers or tricks you into signing something badly and so we already have full trust in our wallet providers and so i don't think that it's outrageous to expect to trust them to only allow only whitelist things that are safe and maybe maybe one last thing yeah one like a broader protocol development philosophy point i personally am very strongly of the opinion that it is not ideal to kind of like try and enshrine more more specific use cases into the protocol so like meta transactions now we create a new transaction type of meta transactions now maybe we create a new transaction type for social key recovery now we maybe create a new transaction type 4 right

and like ethereum historically specifically was was founded even to kind of like move away from this special purpose blockchain paradigm as like the first truly general purpose blockchain and i person and of course that comes with trade-offs right if you can do everything you can do everything but i personally very much like this model and um especially like if with this very clear understanding that like we just move through this to a similar security model as we have in smart contact wallets but now also mediated by uh like ua wallets um to me that makes a lot of sense and importantly instead of having the core developers that have to be honest relatively little contact with everyday users like like every use cases basically um instead of having them enshrined centrally like one use case and then two

years later it reaches protocol and then you can basically if you ever want to change something it takes two more years giving the authority to like the user base and the wallets to kind of to build these standards because once we have that in the protocol you can have a lively conversation what exactly invokers do we want how should they work uh if we wanted to add another one we can just do that without ever having to touch the orgodevs process again so it's it's it's trying to really unbundle these paths of innovation and iteration and i personally i i think the the criticism is definitely legitimate and it's just like a hard call to make but i personally am really convinced of this this design philosophy if that makes sense i think that's probably time i was wondering if you could say

something about the thought process of white the only thing that's checked in protocol is the invoker address like is there a specific reason why there's kind of nothing else that you thought was worth just not having in the commit but having tracking protocol sure this is this this uh presentation i made a couple months ago it's possible that we're going to add the chain id as part of the commit because we haven't had anyone come up with a good example to not do it and there are a couple of foot guns that exist if you don't include it in the commit the main reason that we don't include anything in the commit is because whenever this eip was originally written last fall the original author sam wilson decided that he would have a pre-compile that you would submit your calls to the pre-compile would have its own

storage tree and it would do replay protection and we felt that having a pre compiled with storage was too strange it's a different paradigm for pre-compiles and so we couldn't do that and so then we made it op codes but we couldn't figure out you can't update an eoas nouns for the same reason you can't deduct their balance you don't we don't know where to put the announce in the state tree if you do choose a specific mechanism for a non it's like a sequential nonsense it's always incrementing then you can't do like parallelized nonces you can't do um just storing the hash of something you can't do things like social key recovery and so we want you know we tried to find a way to have a very abstract mechanism that could

allow for many different things and it turned out that not having replay protection um you know we couldn't figure out a good way of having like the ability to do lots of things you know without and also just if you saw the six use case i walk through like there's only one of the six that actually would need repair protection so it's really like by making it as abstract as possible it it is compatible with as many use cases and again same design philosophy we don't want to be opinionated this erp only for this use case by keeping it and again you need the invoker in there because you have to be able to look at the invoker in the code to understand what's happening we might need the chain id but besides that leave it up to the individual use cases this was our id at

least it's probably time thanks a lot for coming we'll be outside if you guys have any more questions