Ethereum Cat Herders PEEPanEIP, 12 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: PEEPanEIP #27: EIP-3074: Native Sponsored Transactions with Sam Wilson

Description

Resources
--------------------
- EIP: https://eips.ethereum.org/EIPS/eip-3074
- Discussion to: https://ethereum-magicians.org/t/eip-3074-sponsored-transaction-precompile/4880/40
- Presentation: https://docs.google.com/presentation/d/1deim8zU76BsKbkhLMUmzJB1nmqjPRNTgpGxBQiWLWQs/edit#slide=id.p

Topics
-------------
1:26 - Introduction
1:02 - What are sponsored transactions?
2:19 - Use Cases
3:33 - Current situation
4:50 - Overview EIP-3074
5:33 - EIP-3074 Definitions
6:38 - off to the EIP (specs)
10:14 - EIP-3074 depthLeft
14:39 - EIP-3074 valid vs. success (Sponsor-sponsee attributable faults)
15:57 - Invokers
23:44 - EIP-3074 status
24:37 - Why or why not chainID is important for this proposal?
25:33 - Do we need to get work done on invokers before this becomes useful?
27:13 - Would it create confusion for users of EIP-712?
30:00 - What we the benefits of using EIP-2718 for this proposal?
30:36 - What does the threat model look like for improperly implemented invokers vs. general smart contract uses?
31:17 - Can you expand on the concept of trusting invokers?
33:03 - Do you have any idea how tooling will help people avoid using bad invokers?
34:03 - How is this different from a smart contract?
34:55 - How much work does it take to limit the exposure?
35:10 - Potential risk - couldn't any contract be invoker without telling me?
39:03 - Analogy of invoker
41:40 - How this EIP is different than other native transaction EIPs?
45:25 - DeFi analogy
46:25 - Use case - paying for gas with tokens
47:54 - When thinking about the EIP, AA was the designed thing or inspiration?

Follow
-------------
Sam Wilson @_SamWilsn_ | Matt Garnett @lightclients | Ansgar Detriechs @adietrichs | James Hancock @JHancock | William Schwab @William94029369 | Alita Moore @AlitaMoore85 | Brent Allsop @Brent_Allsop | Pooja Ranjan @poojaranjan19

Berlin EIPs
------------------
EIP-2929 & EIP-2930: https://youtu.be/qQpvkxKso2E
EIP-2718: https://youtu.be/JReJRJ5G_UA
EIP-2565: https://youtu.be/riBALRAw1Mw

Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2

Follow PEEPanEIP earlier episodes at https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F

Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.gg/tzYmDmF
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders/PM
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/

A

Welcome back to another episode of the one and only eip dedicated series where we discuss an ethereum improvement proposal and understand how it is going to make ethereum even better. My name is pooja ranjan and I'm your host for today's episode on eip3074 native sponsored transaction.

A

Before we introduce the author, a quick reminder, the berlin upgrade is announced and we have covered all eips which are going on the robsten testnet on march 10th. So if you have missed watching berlin eips, you may follow the recording available on penny playlist at ethereum categories. Youtube elp3074 is a standard track code proposal.

A

It was proposed in october, 2020 and currently in draft status. This is also proposed for the next scheduled upgrade. That is london to talk about the proposal. We have sam wilson and scar, matt garnett and we are also joined by the cathodes, william schwab, elita, moore and brent elsa.

A

For those who aren't aware sam, uh who is author of this uh proposal, has also co-authored eip2938 account abstraction and has been on our show a couple of times nice to have you again sam for our audiences may. You have a quick intro and then we will proceed with the presentation.

B

Sure- and uh you know I'm happy to be here thanks for having me back there- we go all right, so I'm here, I'm sam wilson, I'm here to talk about native sponsored transactions, um I'm a developer for quilts at consensus ag you can find my twitter and github links in the presentation. Slides um eip3074 is heavily based on the work done by any dot sender, and there have been quite a few people who have been critical in getting eip3074 as far as it is has gotten.

B

um If I've forgotten you I'm sorry, it's absolutely not intentional. um I want to dive right in and talk a little bit about what are sponsored transactions before going into the specification itself. So uh at the core, a sponsored transaction is a transaction where the account paying for gas is not the account performing the action.

B

It's much easier to explain this with use cases, though, so I'm going to jump into those. The first use case, I'd like to consider is paying for gas with tokens. So let's say you have some wrapped eath or some dye, and you want to send a transaction. Well, you can't, because only a native unwrapped ether can be used to pay for gas, so with sponsored transactions you can use. uh You know non-ether assets to pay for gas.

B

Another really popular use case. um This is like inferior transactions or eddy.center is automated gas pricing. So you set a deadline that you want, your transaction to be included on chain buy and the sponsor takes care of resending, the transaction with different gas prices to get the perfect gas price to get your transaction on chain.

B

The third use case is subsidized apps. So this is like. Let's say you have a game or a new, a new application, and you want to pay for some or all of your users transactions.

B

um That's a great use case for sponsor transactions, and, finally, definitely not the last use case, but the last one I'm going to mention is off chain fee payments.

B

If you want to pay for your crypto kitties with a credit card or you want to for some reason, use bitcoin to pay for your ethereum transactions, you can use sponsored transactions to do that, so sponsored transactions are something that sort of exists on mainnet today, but they're emulated and I'll get into what that means a little bit later, but, like I mentioned before inferior transactions, any dot, sender and open gas station network are existing platforms that provide sponsored transactions. Today.

B

The downside to these these current implementations is that you can't actually set message.sender natively. You can't fake it. It always ends up being the sponsor's account uh or some contract downstream from the sponsor. um So every contract that wants to support meta transactions or sponsor transactions needs to implement support for it. So there are a bunch of different eips. Three that I mentioned here are 2612, which adds a permit function based on an ecdsa signature and that's for erc20s eip 3009 lets. You do a transfer with a erc, 721 signature and eip 2771.

B

Has this idea of like a trusted forwarder contract that fakes message.sender, but again it requires support in the the the downstream construct contracts um and, unfortunately, many contracts- just don't have support for this.

B

uh So let's talk about eip3074 a little bit, um so let's say we create an evm instruction named call from and we're going to make it work as closely as we can to the existing call instruction with one important difference that it recovers an address from an ecdsa signature, and it sets message.sender to that address um and that's pretty much it thanks for coming to my eip. um Does anybody have any questions?

B

Unfortunately, it's not really that simple, but I do like making really bad jokes.

B

The details are a little bit messier, but it's not too bad. So first I want to go into a few definitions. There are four key kind of terms that I want to get right. um There are a lot of actors and participants in sponsored transactions and everybody has different names for them. So these are the terms that I'm using for this eip and this this peep and eat session. um If you don't like them, leave a comment, I won't read it. um First, we have the externally owned accounts.

B

We have the sponsor and the sponsy uh the sponsor pays for the gas and submits the transaction, where the sponsee is the person who actually wants to do the interaction on chain. So um if, if uh in itx and pure transactions or any dot sender would be the sponsor, the spawn c would be me or the person using that service, um and then we have two contracts that exist or two contracts that are important.

B

Rather, we have the invoker contract, which is the contract that actually uses the call from instruction and we have the callee contract, which is ultimately who the sponsor wants to talk to, or the contract that the sponsor wants to use.

B

um So now I'm going to flip off to the eip and we'll go through a little bit more of the formal specifications and then I'll flip back and forth a few times.

B

So um here is the actual specification: uh there's we're going to create an op code at f9 and it will function exactly like a call instruction. You know, it'll have a to address. It'll have a value.

B

Important thing to note about value is that in 3074 you can't transfer value from the sponsee. All of the value has to come from the invoker contract and that's because of there's some complicated mempool rules, but that's a little outer scope for the the summary that I'm giving here um you pass gas at gas for execution.

B

um You pass call data and you pass return to uh an area for return data. So that's exactly like the the way a call function works.

B

The the only interesting part here is that you set the caller address the message.sender based on an ecdsa signature.

B

um There are some technical details here that are specified so um call from increases the call depth by one um in exactly the same way as call um it doesn't increase it by two so like if you imagined it as call from first calling into the spawn c and then into the callee. That's not what happens. It increases it calls directly into the colony and increases the call depth by one, um and then we specify one other technical detail here, which is that in a static context.

B

So if you're familiar with like libraries and or sorry with a view and pure functions in solidity, they use the static context.

B

So if you send any value with call from it won't work in a static context and that's kind of intuitive, because if you send value you change state and you're not allowed changing state in a static context and that's exactly the same way as call so we already went over our definitions and I'm sure you don't care about conventions. So let's jump right into uh constants.

B

So there's only one real constant in the eip, which is sponsored type, so we reserve an eip2711 or 2718 sorry transaction type for signature collision resistance. So if we didn't do this, some malicious party could craft a special signature package for you that you sign that then behaves like some other ethereum, primitive. So by prefixing the signature package with a special value, we can reduce the chance of collisions. It's not perfect, but it does reduce the chance of collisions.

B

Now I want to talk a little bit about the actual arguments and how call from looks so. This part here is still a little bit influx. This is one of the um not fully finished parts and there's still some discussion going on, um but as specified here. I think it would work so if we want to stop today and go with this, it's totally possible.

B

um So the first three arguments on the stack here: y parity, r and s- are the signature provided by the spawn c. uh Then we provide the spawn c itself uh and this is a gas optimization.

B

So uh the call from opcode or instruction does an ec recover internally, um and the reason why we provide spawn c here is so that the invoker doesn't also have to to do a second ec recover.

B

Then we have depth left so depth left is a new addition to the eip and I'm not sure if a lot of people have seen it yet, but it's here because of some interesting properties of evm, so depth left.

B

If you're not aware the evm limits, the number of nested calls in the evm to about 1024. If I'm not mistaken every time, you do a call, a static call or any other kind of call. The remaining depth is reduced by one, and when you run out of depth, uh you can't make any more calls, and this is only for nested calls. It's not for sequential calls.

B

So call from has this special depth left argument to ensure that the callee will have access to a certain number of uh call slots or called call stack slots rather uh and without specifying depth left a malicious sponsor could call into a bunch of different contracts and waste the the call depth um so that by the time the colleague gets invoked, it doesn't have any depth left and then it'll fail.

B

So that would mean a militia sponsor, could grief uh a sponsee so, like I said this is a recent addition to the eip and- and it hasn't been discussed much, but I think it's an important thing to add, and the big takeaway from depth left is that writing uh unbreakable sponsored transactions, or at least minimally griefable sponsored transactions is really difficult and there are a lot of edge cases.

B

So I'm going to flip back to the eip here and we can keep talking so we have this extra parameter next, so extra is kind of the whole magic of this eip. Everything that the invoker wants to check so replay protection uh and other security concerns which we'll get into later. All of that gets packed into the extra field and then signed over and then we're back to the regular uh call in uh arguments.

B

So we have gas, the gas provided, callee or two the person getting call or the contract getting called value, which is the amount of way or ether to transfer from the invoker to the callee contract, call data and a space for a return value. So this is the rest of the arguments are exactly like a regular call instruction.

B

um Now I should take some time to talk about what the signature is signing over so y parity, r and s are computed from uh the sec p 256k, one of the ketchup 256 of this thing. This thing here is what I've been calling the transaction like package. So first we have this signature or collision.

B

We have a byte for collision resistance. Like I mentioned earlier, then we have the invoker address the chain id and extra, so chain id is still being discussed. We may or may not include it, but the idea remains the same. You sign over this extra field and the address of the invoker, so in other words, what you're doing as the sponsee is you're committing to give a particular invoker control over your eoa and that's what the signature does.

B

um So I've explained all of those. um So let's talk a little bit about what comes out of call from so this is a bit different than a normal call. Instead of pushing one off one stack element, it pushes two, so the first stack element input her stacks are weird, so the top of the stack after call from returns is the valid byte. It is a true or false that determines whether or not the signature and transaction like package was valid and I'll talk about what that means in a second.

B

uh But but valid is false. If you have an invalid signature, the uh recovered address doesn't match the past in spawn c.

B

If there's insufficient balance in the invoker to make the call or if there's insufficient, call depth available to make that many nested calls and then we have the success byte, which is a boolean that is zero or false if it's invalid. So if, if these checks fail, success also fails um or if the uh callee contract reverts halts runs out of gas or if the call depth limit has been reached. Otherwise it's true.

B

So if you want to think about this in a different way, valid is kind of like the uh things that are faults that are attributable to the sponsor, so the environment is set up incorrectly and then success are faults that are attributable to the cauli. So, let's flip over back to the slides and I'll, tell you a little bit more ah well, I missed a slide. Sorry about that, missed a bunch of slides, we're going to go here and then we're going to go back.

B

So uh we have these two things. We have this valid uh output and we have a success output. So excuse me: uh if the recovered address doesn't match spawn c, there's not enough gas or the call deep is call stack, is too full of stuff.

B

That's the sponsor's fault, so the sponsor would not be reimbursed for um any of these checks failing so these things can all be checked off chain.

B

You can pretty much guarantee that, once you have checked them, they won't change, or at least they won't change unless you make them change. um So as long as the sponsor doesn't screw up, this will stay true, and then we have this. The success boolean, which is more like the boolean return by the call up code.

B

So if the callee reverts the cally runs out of gas or the colleague calls more than depth left sub calls, the sponsor is reimbursed because the sponsor didn't make a mistake here. um So as success will be false in the case of like uh you're, doing a uni swap and there's too much slippage, um the sponsor still needs to get paid.

B

So, let's flip back uh so I cover this so the invoker. So what is the invoker? This is definitely an important discussion to have and uh sorry for delaying it, but the invoker is a contract. That's on chain that must be trusted. It is basically enabled it's a contract that can do whatever it wants once it has a signature for your account, so the invoker needs to be audited formally proven like it needs to be incredibly secure and it needs to enforce the rules. um So it'll need to do replay protection.

B

There's no replay protection in the signature itself, so you have to use the extra field to implement it same thing for the gas depth left the value even who you're calling and the call data pass to kali. All of that needs to be enforced by the invoker itself.

B

Kind of a cool side effect of this, though, is that the invoker gets to define all of these things. So if you want to make a batched transaction system where you can have multiple uh sub calls valid with a single signature, you can have an invoker that enables that if you want to have fancy non schemes, multi, nonces or random, nonces or anything, that's not just a simple uh incremental number and that's it.

B

You can implement that in the invoker, but a poorly written or malicious invoker can do almost anything with an eoa, so users have to trust these things and they have to be incredibly scrutinized.

B

Okay, so let's finish up the um the eip itself, so the gas fees are a little bit different than other op codes, they're somewhat dynamic. So if the preconditions fail, the fee will be 3200 gas. If the preconditions pass, the fee will be 3200 gas, plus the cost of a normal call.

B

Excuse me so uh some rationale here, so we leave out the chain id and invoker address in the arguments, because you can calculate them inside the op code. um Why do we have two return values? So a really common question that came up in the development of this eip is: why do I return valid in success and not just smush them together into one return value like call, and the reason is, an invoker needs to be able to tell the difference between a sponsor attributable fault and a spawn c attributable fault.

B

uh If a sponsor does something bad that they don't get reimbursed. If a sponsee does something bad, the sponsor still needs to get paid, and that's why there's two bools? There are other ways you can encode it. You can use a special revert reason. You can use different numbers in the same stack element and if you want more information about why, I don't think those are a good idea. The eip has that, but basically you need to be able to differentiate between swansea and sponsor attributable faults so going into why spun c.

B

I think I covered that already earlier uh and why I reserve a 2017-18 transaction type. Collision resistance, ah here's a here's, a big one. So why are we? Why did I propose another sponsored transactions? Eip, there's a 27-11 that already exists. uh Matt has one which is uh transaction packages, which I don't remember the idea number four and I'm sorry so why this particular approach?

B

So originally, I found any dot sender's approach which is very similar to this because of account abstraction, which is another eip. I worked on earlier in this year and last year.

B

Other approaches to sponsored transactions introduce a new transaction type, real transaction type, so that it would only be signable or creatable by an eoa account. Abstraction contracts are not eoas, so they cannot sign typed transactions.

B

3074 is a much simpler, much more focused, it does one thing eip and it's compatible with account abstraction and that's why I think this is the right eip to go with for sponsored transactions.

B

Another kind of quick explanation I want to give is is why are we only signing over uh invoker and extra and why do we give so much power to the invoker? um So earlier versions of this eip implemented replay protection and had all this other junk in it and really what it comes down to is, if you have to trust the invoker for replay protection, why not trust the invoker for everything and that kind of came into this really elegant system?

B

Where all you sign is this hash, and then you trust the invoker to do the right thing with that hash, and that gives you all the security you need as long as your invoker is secure.

B

um And finally, I just want to talk about security considerations, because there are a lot of things you need to pay attention to with this eip.

B

The big one, at least in my opinion, is that if a contract requires that message.sender equals tx.origin.

B

And I don't know of many contracts that do this and I don't think it's ever been recommended as a good thing to do, but I'm sure some people do it. It's it's ethereum everybody does whatever they want, um so this no longer prevents reentrancy, um which me so. If, if I sponsor myself, I can create a sponsored transaction where message.sender equals tx.origin, even though I'm not in the top of the call stack and this might break some contracts, um the other, the the next security consideration is.

B

If you have a bug in signature verification you can impersonate eoas and that's that's a big deal, but um on the other hand, we do a lot of ec dsa signature checks already. So I think the risk of a bug here is is relatively low.

B

um I'm going to skip over this big block and come back to it. So front running is a bit of a concern. So if you have a general purpose, invoker sponsors can be front run. So if uh I'm running a front running bot- and I notice that I can extract more value from someone's transaction like package, then than the original sponsor- I can take that package and resend it and I can front run the sponsor the sponsees transaction.

B

It still goes through. Just the sponsor is different and you can write invokers that you know deal with this and make it safe, but that that's still there, but the big. The big list of security considerations are how to write a safe invoker, and this is going to be difficult and I don't want to have any part of it, but I want to I want to let smarter people than me write good invokers.

B

So this is a list of the security considerations that I've thought of, or we've thought of. First of all, replay protection. If your invoker doesn't implement replay protection, your signature can be used over and over and over again to repeat the transaction: that's not good!

B

Next, you can. You can adjust value uh so if you're deploying a contract or or buying an nft or doing anything. That requires a specific amount of value to be sent with the transaction.

B

um A malicious sponsor could adjust that and completely screw up your transaction um next, a malicious sponsor could adjust the amount of gas sent with your transaction.

B

um If you don't sign over gas or include gas in extra, which is then signed, um a malicious sponsor could cause your your transaction to fail, costing you money, even though you specified it correctly similar thing with depth left. If, if you manipulate the stack to cause your transaction to fail, the sponsor could extract fees without actually committing your transaction and, finally, calling call data should be included in extra because without them a malicious sponsor can just call anybody and do anything.

B

So obviously those things need to be protected. um Yeah, let's go back here, so I just want to talk quickly about the status of eip3074.

B

3074 is almost ready to go to the review state. I don't think there's any large outstanding changes uh you know cross. My fingers and it'll definitely be ready for the next all-core devs call on march 19th.

B

Now I'm actually done and if anybody have any questions, I'd be happy to answer them.

A

Thank you for the wonderful presentation, sam um and I would like to congratulate on the latest version that I believe was pushed yesterday uh where most of the questions like the concerns have been uh addressed.

A

So uh I'm curious to understand the importance of chain id like there has been some discussion on this field particular field to be added and to be removed. So my question is why: why are why not do you think chain id is so significant for this proposal.

B

So, uh specifically, the chain id is included in the uh signa, the data you sign over um and why? I think it's important is because I don't think it's going to be very likely for an invoker not to check chain id, uh and I think we should optimize at least a little bit for the common case.

B

But that said it's possible to implement without including chain id, so the the invoker can check chain id and make sure that it matches correctly. So I'm leaning towards removing it from the eip. At this time.

A

Okay, that makes sense.

C

I I had a question: that's all right. Puja.

A

Good night, james.

C

The also I it's awesome to see double thumbs up if I had my camera on on getting to the review state and like actually using those statuses. Thank you, um the I'm imagining so this eip gets done. Is it do? Would we need to have the work done on invokers before this becomes useful or used.

B

So, no, um I think it's pretty trivial to write a an invoker for a trusted sponsor. So if you have you know inferior transactions or any dot sender, um they could write a very simple single, sponsor uh invoker. That would only work with their their tools, and that would be easy enough and and quick enough to get started.

C

And then the general one you're saying would be a lot harder to write. That's probably like an erc or something like that. You imagine written after the fact.

B

Exactly so so anskar, and I think it was patrick- have actually put together some sample invoker contracts, that kind of show what it would look like, but they don't deal with all of the general problems and edge cases that you would get in a multi-sponsor invoker.

C

Wow, that's awesome. This is something that's come up. A lot on different core dev calls on the last the last couple years of like how to make this possible because it's been something a lot of people have wished. So it's it's cool to see these working out.

B

Yeah, I'm really happy about it. I I yeah.

A

So one of the comment that I found on the magician thread was about the eip 712, like the relationship of this eip, with that it states that it's incompatible with eip-712 and mapping selected could be used to confuse existing wallets into signing an unintended message. What are your thoughts uh like on this comment like? Would it uh would it actually uh create confusion to existing users of eip 712.

B

um So I don't think it would create confusion with users of erp 712., like I think this is going to require some small amount of wallet work anyways. um So I'll talk about that in two parts. The first part is going to be why I didn't use eip712 712 and the second part is signature collisions.

B

So uh the first part is why didn't use the ip712 7112 is still draft. uh It's gone through at least three revisions that have been implemented in wallets. If you try to sign an eip, 712, transaction uh or or package, it's it's difficult, um and in this case I don't think it adds too much benefit. So um one of the things eip712 tries to do is kind of segregate signatures into particular domains based on the contract, the signature of the method being called so a lot of those things don't even apply here.

B

There's no signature of a method being called it's always just these three values um and eip712 adds an extra ketchup, 256 call, which would add extra gas usage. So that's those are the two reasons why I don't use it. It's just not final, and I don't think it adds a lot and the second part is signature, collisions and that's definitely a real concern.

B

That's part of the reason why, like, if you've ever tried to sign a message in a wallet, it adds the special magic bytes at the beginning, like zero ethereum signed message.

B

So there's a whole lot of problems with signature collisions this particular scheme can't ever conflict with a normal legacy transaction like a non-type transaction, because type transactions always begin with a value over c7, or something like that. um I don't know the exact number and this transaction begins with, or this package begins with zero three, so it can't conflict with legacy transactions and further. It can't conflict with typed transactions, because we're actually reserving a type transaction value for this package um and that that reduces the chances of signature collisions, that's not to say, they're impossible.

B

It's just fairly unlikely.

A

Thank you. I mean you have partially answered my follow-up question. It was about the type transaction, so I was wondering like this type transaction. Is it because this proposal is expected after berlin upgrade in which the eip2718 is already getting included or like? We see an additional advantage of that.

B

Yeah, so definitely after 2018, although not required right. This doesn't actually use any of the machinery associated with 2718. It just reserves the 2718 type for collision resistance.

A

Okay, we have got one question in chat: uh it is by lifeline. What does that? Threat model? Look like for improperly implemented, invokers versus general smart contract uses.

B

Sure so an improperly implemented invoker can do almost anything it wants with an eoa. So if you sign a transaction like package to a poorly implemented invoker, you basically just lost control of your eoa. The invoker can do whatever it wants, with your account, except send each from it.

B

So yeah don't sign messages to invokers. You don't fully trust.

D

Can you expand more on this, like concept of trusting an invoker, because I think it's like kind of nuanced, but is it um the fact that it's a smart contract, that's a different type of trust than if you were to trust an.

B

D

Or a person or a sponsor.

B

Yeah so trusting the invoker is kind of like saying I have validated that the invoker enforces the cons, the security uh properties that I want for this transaction. So if you trusting the invoker means you don't need to trust your sponsor. You don't need to trust anybody else in the ecosystem. You can verify this smart contract and you can say my transaction will be included properly or the sponsor will pay like the fee for the transaction.

B

um So some examples of this like replay protection. So if you have a an invoker that properly implements replay protection, your signature can't be reused once it's put on chain, but if you have an invoker that doesn't properly implement replay protection, your signature could be reused a whole bunch. So you have to trust that the invoker correctly implements replay protection, and the same is true for all of the other security concerns that I mentioned down here.

E

And it's basically the kind of trust that you put into. Let's say the easter deposit contract right exactly.

B

That's a perfect example.

D

Yeah I mean, I think it's you know. I think it makes a lot of sense, because you know we use things every day that we haven't validated ourselves, but we trust because it's commonly used and experts have reviewed it. I mean we use these cryptography schemes and you know the number of people who have actually gone through and say: oh yeah, this is easy. The sa thing actually does work is very small compared to the number of people who used and trusted. So I think, like that, makes sense.

D

Do you have any ideas on how downstream tooling will help people avoid using bad invokers.

B

Sure so I think I think that's a pretty easy thing to answer.

B

I think there's going to be a very small number of general purpose invokers and I think that they are going to be audited and agreed upon by the community the same way that the deposit contract was um and then wallets will warn you with big giant red, bold letters and make you type your password if you want to use any invoker that isn't one of those verified invokers and then for on the other hand, you have these these sponsor specific invokers, so inferior transactions will write a an invoker, any dot sender will write, invoker opengsn will write an invoker and those are going to be specific to their project and instead of trusting the invoker, you trust the sponsor.

B

So you say I trust that inferior transactions will not replay my my signature, and you know that's a different kind of assumption you can make, but it means you have a simpler contract on chain. um How is this.

F

Different from a smart contract- because um you know like I mean right now, if I want to do- um execute some sort of trade, I'm using a smart contract, I have to trust the smart contract to um not steal my money and so like. How is this particularly different or more risky or less risky.

B

Right, so, let's assume that you have, you, know a million dollars and die um in your smart contract wallet, and then you approve a 100 die, spend to a smart contract, and then you that 100, the that smart contract does something with 100.

B

They can only uh use the hundred die that you approved for them, but if you were to do the same thing with an invoker contract and you signed it saying that they're allowed using your account well now they can take your your million die, but also they can take all your crypto kitties. They can take all of your. uh You know a fancy nft artwork. They can take anything that your account has ever interact like anything owned by your account. It's not limited to just what you've sent to the invoker.

B

They can do anything as if they were you except to eat that or your account.

F

And how much work extra work would it take to say, for example, limit the exposure there by? I don't know like creating a separate account like? Is that an option, because it seems kind of crazy to me that we're basically giving people like um the ability to?

F

I don't know, like my my my recovery phrase, for my wallet or whatever, um if that makes sense,.

B

Yeah, I mean that's actually kind of a decent way to think about it. Signing a transaction to an invoker is like sharing your private key with that invoker. It's not exactly the same, but you should treat it with the same kind of security concerns.

B

But since the invoker is a contract, you can make sure that it doesn't do bad things.

E

But also just to maybe put put it into perspective a little bit because sam is like a very security minded person, and I mean that's great and ep author. Of course you you want that, but, like um I I would say it's like the security level is maybe somewhat comparable to say. um Maybe like deep. I think, d5 defect contracts are a good example, because people do put a lot of money into those right.

E

Those are smart contracts and you don't only trust them with like 100 die, but you actually, like people, send millions into those and similar to how, like the level of audit auditing that goes into the latest other contract or the latest uniform contract. That's the level of auditing we're talking about you, you yeah like for invokers, so it's not about like literally this once in a lifetime thing like the e2 deposit contract. But it's also not right.

E

Just like a lot of people are hesitant to put a lot of money into new, defy contracts until they're, like proven, and a lot of audits, have happened and so on. So I think, like as a mental model, basically like thinking of it as the similar security level as like a d5 project where you would want it would put like a significant amount of money into. I think I think that's actually a fair comparison.

F

So my primary like um concern, not I mean, like the thing that just kind of confuses me, a little bit is like, um I feel like there's a little bit of a realized risk differential there in the sense that, like um I mean couldn't any contract potentially be like an invoker without telling me um and then more so, like you know like if I'm sending ten dollars to an invoker um like I don't know, I just feel like it's not gonna, feel very um scary compared to.

B

F

A million, so I feel like.

B

F

Of a differential that can happen or bias.

B

So I think the the thing that tooling can really help here is when, like so, you actually have to provide a signature when you're doing anything with an invoker. So you can't hide an invoker like, like you, can't hide this opcode in a random contract and it can take control of your account that contract needs to get a signature from you so tooling, like metamask or or wallets. Can you know explicitly list the risks? Tell you like what is happening when you sign that particular package.

F

But they don't have to do they. The.

B

F

Tools, yeah, I mean obviously you should but like they don't so.

B

None of the tools right now will let you sign one of these packages they'll. They just won't.

F

B

So, like they'll have to add support to sign these packages and in adding support for that they can add the warnings and and the proper messaging. I.

F

Guess that the thing that I'm trying to say is like we're basically giving somebody a gun and we're saying: hey you should you should really teach people how to how to use this um and then just trusting that they will and um I'm not like saying that this isn't well thought out or anything, and I don't know enough- I'm just learning about this. Now, I'm just saying um it's an it's a little bit scary to think about.

F

um If it's not implemented properly, that I am going to be signing off or if it's implemented maliciously that I could potentially be pressing a button to then sign off my entire account.

D

Yeah, so that analogy is smart contract wallets, though, because the smart contract wallet has a lot of dissimilar. um You know, threat models that you have with this.

D

You know you're you're, choosing a smart contract wallet that you're going to put all of your funds in that's like choosing an invoker you're going to use, and you should choose one that you trust and that this is you know it's vetted and if you know something goes wrong, if you sign like one wrong thing, your smart contract wallet, you know you can lose all the funds out of that, and this op code is, like you know: strictly opt-in, you're not going to accidentally sign something that goes through that op code and the main advantage of it is you, don't have to actually uh deploy a smart contract well to get all these functionalities that smart contract wallets have.

D

So I think that's the power- and I kind of just thought about this. Just now, as you guys were talking, um but I think the smart contract wallet analogy is is a pretty good way to think about it.

B

Yeah, that's pretty decent, so like by signing one of these packages for an invoker. You are saying that invoker is allowed to act as a smart contract wallet for you um and kind of.

C

A less technical.

B

Analogy is like this: eip is building the firing pin for a gun and absolutely somebody can build a foot gun. They can build something that when you use it will shoot you in the foot, um but that doesn't mean you can't build a a safe gun with it. But it's a building block that can be used either way.

G

I mean for the same price.

D

G

Talk about the blockchain platform in general, I mean if our goal is to actually give people sovereignty with value. That means they absolutely have the ability, even with an eoa like outside of a smart contract wallet, to lose their funds in ways that have not generally been available for them to totally lose their funds. With till now I mean the the way that the legacy finance system works.

G

It's more centralized, there's more recovery, I mean you lose your keys and everything's gone because I mean in order to give that level of sovereignty in order to be able to give that level of flexibility. So it's true. There has to be some kind of counterbalance on the other side of the scale for it, but from the flip side I mean we see the the restrictions that happen across the ecosystem because of people not being able to get their gas fees sponsored.

G

So again it opens up a world of flexibility, but flexibility always comes with more responsibility, so to speak.

D

Okay, this is like a little bit different, but it's still kind of a similar idea. I was wondering if you can expand on um the you know how this eip is different than the other native sponsor transaction eips, because I think that it's a again a very nuanced difference about how this is an op code and how the validity is. You know determined in the evm versus determining the validity in the mempool.

B

Sure so, there's there's a couple like major differences here, so so one this doesn't require a new transaction type. So um that means it's more compatible with aaa like I mentioned earlier, but that's not really a huge selling point. So let's talk about a little bit more about the actual differences between introducing an op code versus introducing a transaction type.

B

So introducing a transaction type means new mempool rules new so like for those who are aware, the mempool is where uh transactions go before they're included on chain and it's a huge avenue and opportunity for denial of service attacks, so rules in the mempool or transaction pool are very strict. So adding new transaction type types need to be very concerned with. Are they a denial of service vector? um You know, can this hurt nodes? Can this cause additional processing?

B

And that's one thing the cip doesn't do any of it. It doesn't change the mempool rules at all, but on the flip side it doesn't change the mempool rules at all. So you don't get any uh additional flexibility there. um If, like you, can't do expiring, so uh eip2711 has more than just sponsor transactions. It also has expiring transactions and batch transactions, so an expiring transaction is a transaction that you submit and past a certain block or a certain date. It is no longer valid to be included on chain.

B

So that's not something you get with this eip this eip. While you can expire a transaction so that it doesn't run after a certain date, the sponsor would still be charged fees for it and that's kind of less than ideal, but there's no added complexity. The all of the complexity in this is in the evm and there's no networking no mempool none of those changes. So this is a much more contained kind of change. I hope that kind of answers. Your question, man.

D

Yeah yeah, it does another thing I think is like interesting about that is that usually we're thinking of these relayers? As for you know, commercialized entities and if they're paying fees for something that ends up not being valid, they have this. You know business incentive to build better systems. That avoid that. I think a good example is like it's kind of you can build an evoker, that's potentially griefable.

D

If you send your transaction to multiple, you know relayers, um you know your transaction might be included in one relayer before it's included in a different relay, and so, if that second relayer, where your transaction's no longer valid, still submits it they're going to pay for your call data, even though they're not going to get the fee for that, and so that just incentivizes them to you know, pay really close attention to the mempool and what transactions are coming into blocks and you know resubmit their their transaction bundles.

D

um You know, after it sees that your transaction is no longer valid, to uh include a different set of transactions.

B

Yeah, so I think I think what you're saying the the commercial entities that would be relayers have the resources to do that kind of complex analysis.

D

Yeah, it's kind of taking like something that could have been done in the protocol and pushing it to the people who are incentivized to do it in the best way possible.

B

Yeah, I would agree with that.

A

um uh James, do you have any questions.

C

uh Yeah, I just wanted to see if I check understanding on like a possible analogy using the d5 contract stuff so like when I'm farming there's a few trusted contracts, if you're gonna deposit money into a farm to farm x token, if they're using the synthetics contracts, you can look at it and like if there's been three changes and the token ids are different, then you know okay, this is safe or, like people talk about it's the sushi stuff contract, so yeah that's been like looked at a lot, so I guess, like invokers, will probably have that same kind of relationship of oh.

C

We know this type has been looked at a ton. Then it's pretty easy to see if it if it was changed enough or tools could see that kind of stuff.

B

Oh yeah yeah, so so, if you're deploying like open zeppelin, for example, could have an invoker template that people could implement. And then you would just check to see if it matches the template and if it does you're good to use that invoker yeah cool.

A

I have one last question on the use cases. I believe you briefly mentioned about paying for gas with tokens. So if you could a little bit elaborate on how people can make it useful and like not using it.

B

Sure so um the the kind of simplest way that this would work is uh a sponsor would announce you know like or advertise or have a website or an app or whatever that says you know I will uh take dye and I will pay for your transactions, so you would sign, uh I believe, in the current kind of sketch.

B

We have that you would sign two, I guess actually in the newest version of the ip, you would only sign one package and then your invoker would do, um would first transfer die to the sponsor's account and then it's the second step in a second call from instruction would perform your your transaction, so in effect, you're exchanging die for gas.

A

That's going to be one of the most usable application, because many times people are using erc's and they do not have actual heater in their wallet to make the transaction yeah.

B

A

um I think we have a little over time, but if people have any final question.

C

I have a one, I hope is kind of small the when you were. You mentioned that it works with aaa. When you were thinking about the eip. Was that, like a design thing you went for, or is that just something that kind of happened.

B

It's so when we were working on aaa, we know well, I noticed that the leading um eip for sponsored transactions was not compatible with aaa and that's actually.

C

B

Got me to start working on on this eip.

E

Cool, it's a you would say it's more like an inspiration that started it right, because yeah.

B

And like obviously, it's been a goal to keep it in mind, but it hasn't been the driving force behind the specification.

A

So um like this is my final final question: it's about the eip status, as you already mentioned, that uh it is almost the review ready. I think that's a very good point for this proposal to be. You know getting proposed for any further upgrade because we are trying to uh like encourage authors to propose only if their proposal is ready for review.

A

So thank you very much for that.

B

uh So yeah it's been a flurry of editing. Lately, it's it's. I feel like it's almost there, so hopefully we can get it in.

A

Yeah, it was really great talking to you, sam. I really appreciate you taking out time and providing an overview of this proposal. uh I think this was interesting. Considering this was the first time this proposal was ever discussed.

A

I was expecting it earlier to you know in all code meeting, but unfortunately we did not get time, but I think this, this episode is going to be helpful for many people, because uh this gives us enough time to go in like in depth um in less than six months, or this proposal has attracted client developers, infrastructure providers and researchers may be because of the explosions of tokens that are being built on ethereum, especially the stable coins.

A

So, as explained in the motivation section also, uh it has become more common for eu is to hold valuable assets without holding an ether at all this eip that specifies a method of implementation of a sponsored transaction that allows both the eoa I mean externally owned account and the 2938, as you mentioned, the account abstraction contract as per sponsor. So I'm really looking forward to see implementation in different clients uh if and when approved by the client tasks.

A

Hopefully, as you mentioned in the next algorithm meeting best wishes for that.

B

A

On this note, for all our youtube viewers, if you have any question that couldn't be answered today, you may leave your comment to ask the quartus his twitter handle and github handle is provided in the description as well as the presentation that was shared next week. We are going to talk about uh eip 1474, that is remote procedure, called specification with eric marx and morris so stay tuned. Your feedback is important to us. Do let us know which eip would you like to see?

A

In future episode, join ech discard invite link is provided in the description for our new viewers, so subscribe to ethereumchat headers youtube channel hit the bell icon for updates, don't forget to like and share with people of similar interest, keep watching and keep sharing your love with ethereum catered. This is all of us signing out.

A