Ethereum Cat Herders PEEPanEIP, 16 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Peep an EIP #12: EIP-2938 with Ansgar Dietrichs & Sam Wilson

Description

EIP: https://eips.ethereum.org/EIPS/eip-2938
Discussion: https://ethereum-magicians.org/t/eip-2718-typed-transaction-envelope/4355
Slides: https://tinyurl.com/peep-an-eip-2938

Peep an EIP for EIP-2718: https://youtu.be/JReJRJ5G_UA

Follow at Twitter:
Sam Wilson @_SamWilsn_ | Ansgar Dietrichs @adietrichs | James Hancock @JHancock | Lightclient @lightclients | Pooja Ranjan @poojaranjan19 | Alita Moore @alitamoore85

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

Contact Ethereum Cat Herders
Discord: https://discord.gg/sgdnxZe
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 to another episode of an eip focus series where we discuss one ethereum proposal and understand why that is important for the ethereum network. Today we are going to learn about eap, 2938 account, abstraction and our guests are sam, wilson and and scar ditrix. We are also joined by james hancock. Light client that hurt us eap. 2938 is a standard track core eip proposed in april this year and is moving towards consider for inclusion for ethereum future upgrade.

A

According to the summary provided in the eip, account abstraction allows a contract to be the top level account that pays fees and start transaction execution to understand the proposal more. Let me welcome our guests, sam and anskar.

A

Thank you for joining us on the show before we dive into the proposal. Let our audiences know something about you. Your engagement with the ethereum community.

B

My name is anska and together with sam sam, if you want to say hi, hey yeah, so so they told us, we are like um part of the of the quilts team at consensus, we're doing like general ethereum research and different topics and one of the things we did um over the last I would say six months so something like that um was to work on on account, abstraction and that's.

B

Why we're here today to talk a little bit about the eap that basically, this effort resulted in that's eip, 2938 um for like one specific flavor of account of protection, and so the idea for today would be to talk like a little very briefly of on, like a conversation general and then specifically like this favor. What makes this like? What's what's the idea behind this, this specific approach here? Why do we think that this actually is like a feasible way of bringing a kind of abstraction to ethereum so um yeah?

B

Is it just said, like I'm happy to like or or answer and answer any questions or like I I mean we are. I think we just want to basically have it be a little bit of like a conversational setting, so I think I'll just start talking and send off or just feel free, obviously to always um also join in. um So I basically like, I think it makes sense to very briefly start with, like with like a little um motivation uh for for construction in general, and so um uh and this this this.

B

Basically, the idea is that, um obviously, coming from bitcoin, the idea with ethereum was to make uh make blockchains programmable right and in bitcoin, of course, things are not really programmable, but but, interestingly enough, there's some very limited um programmability with like these.

B

These um validation scripts, this that begun scripting language you might be familiar with that and that like programmabilities on bitcoin, is exclusively for determining validity of of transactions right, so you can in your output, you can basically specify some conditions under which you you can then spend these outputs again and the effects of transactions. There's there's nothing you can do about them. That's basically just send money from a to b, there's, there's no programmability and now on ethereum. Of course, we have all these programmable effects.

B

You can have smart contracts that can do whatever you you want them to to do basically, um but today, there's just no way of like, like pro having any like um any variability on the validation side of things. So you always have like you have to. The transaction always has to include like an ecdsa signature that is being checked and only with the signature and the nonce and everything right it matches.

B

Only then are the effects executed, so so that that actually like, in this very narrow senses, a little bit of like functionality, loss as compared to bitcoin, and so the idea with the confirmation is just bring that back to ethereum and and also have the the validity of the transaction already um be be fully programmable and then to to see like what that actually means. So so, basically, um just a very simple example, so let's say there's some contract.

B

uh I would, I always think, like for the simplest aaa use case, I always think of like a smart contract world or something right. So this is my contract. Basically, I, as a user want to want to just maybe the contract holds some funds for me or some tokens or whatever right. It's just a contract, and- and I want to interact like I- want this contract to like send- send some transaction or whatever to to to some target.

B

Maybe I want to send from my smart contract wallet to someone else, some funds, or some something of that of that sort um and in the contract I have defined rules for when my transaction is valid. Basically, what I have to do today is, I basically have to own what is called an eoa externally owned account like an address on ethereum. That also has to have funds, and then I have to like send.

B

I have to basically send a transaction from that account to the contract which I'm calling the outer transaction, and then the contract then can send an inner transaction, but this is obviously like. This is a like one layer of interaction that is um problematic and then, of course, also um uh yeah, and then what I could do what's currently being done is is I could use like something like a relayer but then for relay setting.

B

I have to basically talk to relay and the relay has to have an account on ethereum and then the relay has to send the outer transaction. Then my contract probably also has to do some kind of payments, so it gets even more complex um and so what would aa bring bring bring here?

B

um Basically, this is the the ideal state where there's a contract, like I just directly like create a transaction that starts at that contract and then does whatever I wanted to do, um and so how do how we do we basically just get there um or what would that kind of look like? um So I think sam uh has like this. This great example here to like what what like this could look like in basic in a very basic sense in something like solidity.

C

Yeah, so so this is um a sketch. This isn't something that's been decided yet um of what solidity could look like. This is based off an earlier prototype that quilt had built, but the major points you're going to see here are the account keyword before contract, which signifies that this is an abstract account.

C

You'll note that these signatures are actually embedded in the transfer function. Arguments you'll see here, sig, zero and sig one.

C

So this implements a multi-signature and what's neat about this, is that the validation and the signature validation specifically is completely implemented inside the contract, then you'll note the pay gas call which informs the uh the blockchain how much the contract is willing to spend to pay for the transaction, and then you have the last two lines here which just forwards the transaction on. So this is a two of two multisig that uses account abstraction.

B

Yeah, um which I think is really neat, uh is a very simple example um and then just very briefly, um I think we originally held like a presentation at uh it online and the hackathon and there we we spent some more time on any use cases I think for for this session. It's probably less relevant, so we condense that into like just one one single slide, then we can go back to the actual eip um but yeah. Maybe uh I think sam. That's mainly your part right. So if you want to yeah.

C

So there's there's five main use cases that we were considering when we were designing the um eip. There are four that we think are really good. Examples are a smart contract wallet which landscape already described a mixer like tornado cache, which anonymizes funds by mixing them together into a pool uh in-app tokens, which is the idea where um say like an on-chain game or um adapt that provides fees for its users tracks those with in-app tokens.

C

So you can build that with account abstraction- and I forgot to read in the last one, but that's supposed to be arbitrage, which is uh profiting off of price differences between markets and all of these use cases are significantly improved with the introduction of aaa.

B

Yeah, so um maybe before we uh so so, I think the next slide um on the sims taken should be actually start uh due to look at into the actual details of the earpiece. So just um briefly uh wondering if there are already like any any specific questions for like the more the kind of motivation or goal side of things or otherwise I'll just go ahead and start with the um with the earp itself, which is probably the main focus here. So, okay.

B

um So then, uh just just one slide for like the motivational.

D

Thing sorry I was I was I was on mute, otherwise um this is like from a from the perspective of a developer. I'm like this kind of lays it out. Well, could you maybe like, as like a user of ethereum, where this becomes like easier or better for them.

B

Sure so, basically um I mean, I think one one example uh would definitely be just something like a smart contract wallet, where I think. Of course, the question is uh um like how many people are actually using smart contract wallets, there's always right. A lot of people don't actually have like something like hypnosis, safe or something, but if you like, for users that actually do have smart contact, wallets um using them would just become way easier.

B

So, for example, I don't know if you kind of like I I don't know one of the one of the ones that I'm using a little bit. It's like the argent wallet, yeah.

D

A lot of people use argent wallet so.

B

Yeah exactly but but of course, what they do is they usually they relay the transaction for you. Basically, they do under the hood everything, and that comes with the disadvantages as well so like and um like doing the like guest guest price peaks. um They initially, I think they they they still kind of paid for all, if every time I'm mistaken at least paid for all user transactions.

B

But then at some point there is this, stop doing that and something- and it's basically this this always adds this one additional layer of indirection, where you kind of right it. What what if they set the wrong guest price, then you you, don't just you can't just go and like change that you kind of need need in ua what, if you don't have one right um so for it?

B

It's basically just that it usually just simplifies things um similar like, for example, with this kind of in-app token example where you could already have something where you you just rely on the dev developer, to like send the transaction for you or something, but like it's just so much cleaner.

B

If you can basically just go to the contract and like send a transaction there directly, where you don't ever like you, don't even have to own any eth you just you only maybe like you're, a new user, you only own some fancy depth, token or whatever, and then one transaction cost like they charge. You one fancy debt token for that, and you can just go directly on chain yourself.

B

You send the transaction, you pay with one fancy debt token and they under the hood, do all the guests, whatever thingy pay for it with some ether whatever. But you can do it directly on the chain. You don't have to go to like their server and then they you try to trust that whatever you want.

C

B

Do they actually do.

C

I think that's that that's probably the most important user facing change is that you don't need to rely on any infrastructure other than the ethereum clients. You don't need relayers, you don't need any any anything that might become abandoned over time or requires off chain support it. It just works all on chain.

D

Okay, so so like, if right now, if I use arjun- and I send a transaction- I'm kind of they decide how much gas they're going to be paying for something, even if I'm kind of indirectly paying for it, but maybe I really want it through. So I don't care about paying a lot, but maybe someone else does doesn't care so they'd want to pay cheap, but we both have to rely on argent to figure out either of those cases rather than like me as an individual. I can just decide.

D

Oh yeah, I want to pay more now or I want to pay less exactly.

B

And I mean I'm sure like they could make that also work today, where they they could basically offer some functionality where you can, I'm not sure, maybe that you can do. I I'm not that familiar with the exact setup. So so maybe you can already like technically, like directly send a transaction initiate a transaction from your own eoa right. You can maybe have like an address on ethereum. You can immediately interact with. I would even assume that's the case and you can like call into your argent uh wallet, but but that's of course right.

B

This is that that that's.

D

Really complicated it's way more complicated. If it was really in a game, then it would be even less likely that all this would happen.

B

Exactly yeah so for me personally like for me, this in-app token example really is like the was the most motivating example of like new users that never have to own any ether right. They only own the game, token or whatever, and they pay the developer with the game token, and but they can still do it like directly on the chain.

B

They don't have to drop right if, if they want to or if they don't want to, they can always obviously go to the through the interface of the game or something, but they can always basically fall back to the chain directly if they want to which I I I just think it's like a very clean, clean design pattern.

E

So I have a good question uh one of the major well so first off, are you guys done sorry? I mean interrupts.

B

I'm not sure yeah, I think so. I got this.

E

uh uh Sorry, one of the major things about the eip that I'm seeing um is that it sort of eliminates the gas limit and it replaces it with the block gas limit, um and I have a question regarding that: um yeah, oh yeah,.

B

So no go ahead so.

E

C

Think we'll get.

B

E

C

We get to that part of the specification. Okay.

E

Well then, you can just come back to it. That's fine.

B

That's what I was going to say, but yeah um I I think that makes more sense. Yes, um because that's actually the next thing we we are going to look at um after this. We will be like we have basically this one slide here and then after I was going to shift over to the actual uh ef document and just go through it and talk about the individual things and so for any like individual. I think erp specific questions yeah. I think I think it's just probably best to talk about then.

E

Sure we can just come back to it. Thank you. Okay,.

B

Yeah but uh sounded like an interesting question, uh so so yeah that but then so let me then briefly go through this just so we can get going then there, um unless there were any any other open. No, I.

D

B

Thank you awesome thanks um yeah, so so so for the specification itself just like this. This is just supposed to get like a little bit of background and motivation of why we did the erp the way we we did it um and to give for credit. That was not our initial approach. We initially just uh went ahead and had like a somewhat simple approach, and then we went to vitalik for feedback, and then he was like listen to us for five minutes like well.

B

Why don't you just do it like this, and now now we have. We are like we. We arrived at this, this uh um kind of kind of design. So so the idea is, of course, uh counter-production has been around for like a long time uh already, and so so like I, I found this the cip 86 from vitalik in in february 2017, and the question of course is: why has it never been like actually implemented? Why is it not on chain yet?

B

And the answer is that it's just like relatively complicated, I think even our eip, as it as it stands, is still like relatively complicated and for the longest time most of the proposals actually had like a lot of consensus, changes and like a lot of consensus, changes obviously reduced the chance of anything ever making it to chain, and so so.

B

What we kind of figured out here was to try and come up with a design where the actual protocol changes are really small, and I I I hope at least like we, we can convince you like, when we look at the actual ap, that the actual protocol changes that all clients have to like implement that have to really be identical, and otherwise we have the same issue we had earlier today.

B

um If you um notice that with like and so on right, you really don't want to have a chain split, so so this is obviously the critical part that you really don't don't want too much of in any forks, and so the idea of this was really keep the consensus. Part.

F

Minimal and then uh question here so consensus, you're talking about human consensus, you don't want to cause a fork. That's what the kind of consensus you're not talking about either blockchain consensus. uh Well,.

B

Human, I mean what I was thinking of mainly was basically protocol rules, so something like a trend like a transaction that looks like this has the following effects right and then they, oh in every single client, it has to have the exact same effects. Otherwise of, of course, we we come to split. I wasn't thinking of like forks in the sense of some people like a some don't, and so there will be like an ethereum classic classic.

C

Thunderbolts, this is about minimizing code like consensus code change, not governance, consensus, no.

F

C

F

B

Yeah, I mean maybe actually now that you're saying that that might not have been the best way to use actual consensus, because you're right there's definitely this double meaning there um yeah that's actually like a good point, um but but yeah. The idea was really like to keep keep like the keep the code changes minimal.

B

That could lead to to like severe problems, because there are other parts of client code that are less critical right if you kind of drop it like drop a transaction after it has been in your mempool for an hour or an hour and 20 minutes that doesn't matter right like every client can just do that. However, they want um that's, not something that can can lead to like uh protocol issues, and so so the idea was the the part of the code, the actual evm changes right.

B

The virtual machine changes keep those to a minimum um and then um have a have a look at like what. What are the issues with that with with that? That introduces and then just find additional ways to to mitigate those um with manpro rules and memory. Rules really are these things that, like every client, does somewhat differently anyway, and it's it's very simple to like basically um to to um to to to to do these kinds of change and it'll become more clear once once we talk about it, but basically the this.

B

This kind of gives us like these. This, like this um property, that it's like relatively easy to to to to reason about then, um and then we can always.

B

The idea is, you could always just just like make them more more complex or something at a later point, and and we'll we'll see a lot of that, but I think um yeah, maybe that wasn't explained the best way, but I think it just makes sense to now go ahead and actually look at the ap, because then I think a lot of things will actually come become really clear and I think.

E

Quickly, go back for a second, I have one clarification question and that's. uh Why is a consensus? Protocol change uh like really difficult.

B

um So difficult just in the sense that.

C

um It's it's designed.

B

C

Every client needs to implement, implement it exactly the same way as opposed to a like a mempool rule, where it's fine for them to be somewhat different as long as they're compatible. So that's probably why um why we make this distinction.

B

Exactly so so, basically like, if you, if you talk to the guest team or something every time, a new erp is being discussed on the all codes calls and and all of these these these forms, then usually they are like very skeptical um if, if they are like more than a very very small amount of rule, changes right because then they have to to spend like a lot of time of actually like double checking, comparing it with other client implementations.

B

Writing all these edge case tests just to make it like absolutely sure that there's not even like some very weird edge case in which the implementation in different clients behave even just minimally differently.

D

B

So yeah, that's basically.

D

And and part of it is the consequence of things going wrong is high, so it's even if the change in the code is easy to make, because there's this, if any of the clients do it slightly differently, you get a chain split like that that the consequences of things going wrong being high. What makes it harder to do.

B

And again, change split in the like accidental way, not the yes.

D

E

B

Way, but like accidental, yes, you really don't want that to happen.

E

That makes sense um and then one more question and that's what exactly is a mempool.

B

Oh yeah, that would be probably I.

E

F

Explain that later on, but.

B

C

Yeah, so it's a set of transactions that clients maintain um that haven't been uh included in a block. Yet so it's your pending transaction.

B

Yeah, so if you kind of send a transaction to the network with, like, I don't know, either your own node or with metamask or whatever, it's just basically sent to some initial node where it starts, and then the node sends it to all other nodes that it knows and then those send it to the other nodes and then at some point.

B

Hopefully it reaches a minor and then when they create a new block, they look at like all these kind of pending transactions that want to get in and then they pick a subset and include it into new blocks, but this kind of the set of transactions that like all want to get in, but aren't yet in the uh aren't yet included in any blocks. Those are kind of like the pending transactions and those are often called like the memory pools of the um of the clients.

B

Great explanation, thank you, yeah awesome, yeah. So then um yeah then I think it makes sense um to actually go ahead and look at the efp itself. So so here we here we are. This is like the ap and again there's the first part just like this, because it's basically similar to what we just did like talks a little bit about the motivation. So then, then the specification part, that's the actual.

B

The main part of the ap, and so I think, plan would would be to just go: go ahead, just maybe line by line or something or, of course, they're more important, less important parts, and just talk a little bit about why? Why we do what we're doing here and just just like again to like briefly write this, because we talked about it here, uh the different side, protocol changes and these additional safety rules for now like what? What and the specification for now like all of this, this is actually like the protocol changes.

B

These are like the really critical changes that everyone has to do the same, and then um a little bit further below is like the section with these kind of additional safety rules and I'll make that extremely clear once we want to reach here. So this is, these are all actual consensus, changes um and so basically um right there there will be some fork in which a counter section would be included if it, if it ever will be, um and at that point we introduce a new transaction type.

B

These constants they'll only be useful in a second, so so we'll come back to them um transaction types. What, but is that even based less um another um erp, which I think is currently still um in in a position to be included in the berlin fork, if I'm, if I'm mistaken, so this is erp 2718 and.

D

B

Yes, that they are awesome and- and that is um typed transactions, I'm not sure- maybe it makes sense to briefly open that and then close it again, but uh basically um type type transactions. um It's really awesome until now, um there's only one one kind of ethereum transaction right. It always has like a from a two, the signature.

B

It's like all all transactions, look the exact same. Of course, then the the contents are different, but but the structures is always the exact same, and what this proposal um adds is the opportunity to basically create different kinds of like transaction transactions right.

B

So, for example, you could have a new transaction type for for erp 1559 right that that of course needs different fields, because it doesn't just set one one one one fee, but it sets like uh the base and then the kind of the tip I think right are the other two fields and that kind of then then, transactions for erp 1559 look a little bit different right, and so so this this erp is basically just introducing the possibility of having like new kinds of transactions, and so account obstruction would be one of these new kinds of transactions.

B

So um we don't actually add any new types of accounts. There will only. There will still only be like these eoa externally owned accounts that only have like a balance and announce and and there will be contracts which, of course, also can have code in in in storage.

B

um So we don't add any new type of like account. We only add a new type of transaction and and this new purpose transaction is an account abstraction transaction. Basically, um and as you can see, this is basically here this. This defines what this kind of transaction will look like, and you can see it only has three fields, so normal transactions have, I think, like six or seven fields.

B

um So this this transaction is really like way smaller, because again, most of this, most of like the logic, will be kind of outsourced now to the actual contract, um because the the target, the target, is basically the contract that this is like the account obstruction contract, but it's just like a normal, a a normal ethereum contract. That's supposed to supposed to like pay for this transaction and then the other only other things you actually specify is like enough and we'll talk about in a second about why you still need the nouns in the like.

B

Why can't you just like also leave that up to the contract and the the the main issue here is like a transaction hash uniqueness right now in ethereum, you never have two transactions with the same hash and we still want to keep this, and so there has to be something in a transaction that always changes from one to the next, and so this is like the non. So the nonstill is kept, but then everything else like the signature, the kind of who all of these things are just moved to to the data field.

B

So the data is just like call data, that's just arbitrary bytes and you just send the contract. Whatever the contract expects you to to send it to send it to enable to in order to decide if it wants to pay for the transaction or not right, you can put a signature in there. You can put basically whatever whatever you want. Just it all go you you can like. If the contract lets you decide how much like what the fee should be, what the gas limit should be. You put all of that into the data field.

B

If you want to um there's no there's nothing like a gas limit and I think right there will be the question um in a second but we're not there yet at the right location, but but like things like guest limit or all you want to communicate to the contract you just put in in the in the in the data um and then uh because there's no not not not that much pre-processing anymore right. You don't have to check a signature, anything that the base cost of the transaction goes down.

B

So you don't have to pay 21 000 at minimum for transaction anymore, but it's only like 15 000. Of course, this value could be that's just like our proposal could could be whatever, but but I think that sounds about right um and then um and then basically you're off you, you have to go so so like then, that the the that's, how you like kind of create a transaction and then how? How does the transaction actually like?

B

How is that being processed so again, months check just the exact same, so the announce is just is being checked as it would be for any transaction.

B

You check the nonsense: if it, if it's the right nonce, then you kind of process, the transaction and if, if, if that, if it doesn't and and then basically at the end, once it's included on chain, you always increase the nonce um by one, that's just as it is before, and then uh this is important, and I think this is like where, where where the question will come into play, but but I like, let me maybe try and kind of preempt that by by by pointing out something important here, um there is no.

B

There is no intrinsic gas limit on the transaction anymore, but that does not mean like that. This is somewhat misleading. I think the guest limit is simply set to the remaining gas in the block that only kind of refers to the beginning of a transaction, because the like, like if you started when you started transaction, you kind of you start. You have to already give the evm some guest limit right, like you always have to have some guest limit.

B

Otherwise, you right, you just execute forever, and so you give it whatever is left in a block, but um the contract. Of course, if it wants, if it decides to pay for the transaction, it has to pay for what, however long the transaction takes and so the contract once it makes, the payment decision has like the has, the option to kind of set its own gas limit, and so this this kind of this is just like the kind of placeholder gas limit.

B

So as long as you don't know how much gas the contractor is like will kind of choose to use, you start with the whole like remaining block gas limit, but as soon as the contract decides, if it wants to pay or not, then it kind of sets the gas limit actually wants to to pay for so like this kind of full full block guest limit, that's not actually right, otherwise, the contract might have to pay for 10 million, yes, even if it doesn't want to so, and that's just the when you once you start executing a transaction initially, you set it to the the whatever guess is left in.

B

In a block- and I don't.

F

Know maybe at this point now does it what's the law go ahead, yeah, I'm just curious. What is the worst case scenario that block dot gas limit? What could that be just? Do you have any idea about that.

B

Yes, so basically, I'm not sure that if anyone knows what the exact count gas limit on the theorem is, I think it's maybe something like 12 million 10 million. I don't know I'm terrible with these things, so so something of that.

C

Sort of 2.5.

B

Million 12 12.5 million that makes sense.

D

It is important.

B

uh It is important to note, though, like nodes that like kind of get receive a new incoming transaction and we'll talk about that later in a second as well and want to validate if it's, if, if, if the transaction is even valid, meaning that the contract is willing to actually pay for it, they wouldn't actually execute 12 million. Guess I mean unless they choose to but normal nodes that like right, if you just get the default gather or whatever they won't just run for 12 million guests without like before they know.

B

If you even want to pay for it, they they will set their own like more and more strict guest limit, something like 100 000 or something, and then they like, if you, if the contract didn't decide to pay by that time, then they'll just like basically come to a hard stop right, because they want to spend limited resources on validating transactions, but like from the cons yeah from the consensus point of view right.

B

If you get, if you receive a new block and you you kind of validate the block and you get to an a transaction, you always start with setting the gas limit to whatever space would potentially be in the rest of the block. If that makes sense,.

E

um um Okay, sorry that one question: um let's start it off with: why does ethereum currently have a gas limit.

B

For a for the transaction for the for the block itself,.

E

uh For a transaction.

B

C

B

C

Oh, uh it's so that so, since it takes a certain amount of gas to complete a transaction, and you have to pay for that gas setting a gas limit caps, how much gas a user is willing to spend on a particular transaction.

E

But isn't it set like or are you able or is the gas limit um for a given transaction like flexible, currently in transactions.

C

uh It's flexible, you can set it yourself when you create a transaction. uh Most wallets, hide that and they estimate the gas for you, um but you can definitely set it yourself if you want. Oh.

E

Okay, so then nothing's changed here in that now.

C

E

C

Who sets the gas limit changes.

E

C

Normally the the end user, like a human sets the gas limit, but now the contract gets to to decide that.

E

B

Cool so yeah, but but you're right, like the intention, is to just replicate how it is currently just that, like the ins like the the other, the instance making, that decision is not the human anymore, but it's the the one paying for the transaction, which is in this case the the contract itself.

B

um But, of course, how does it does it going to actually decide that, like that's, that's what we get to next and that's like what's mentioned here. That's this: hey guest op code. So um this is basically like a new op code like a new um machine up code that that's that's added to the to the ethereum virtual machine and so the contract a contract can can can basically call this opcode.

B

And if you, if you do so, then um basically calling this up code signals to to to the protocol that you as a contract are willing to willing to pay for the transaction. So if you kind of if the contract, for example, if you want to write your own in account, obstruction, contract or like a context, abstraction enabled contract, because it's still a normal contract, then you kind of you would you would have like some some initial code. That's always run once a new transaction comes in. That does some kind of validity check.

B

So, for example, you want to implement a multi-sig, then you would do some signature checks and once those are those those go through and you kind of you're convinced that that you actually want to pay for that transaction. Then you, the contract, you use the contract, you call this up code pay gas and that kind of signals. Okay, I'm actually willing to pay for this transaction.

B

If you don't call pay gas or you don't call it in time or something um or like, even if you, if you never call that right, then the transaction is considered invalid, like an aaa transaction that that never has like the contract that it starts at copay gas. That's considered invalid right, because the contract has to to actually decide to pay actively. Otherwise, the transaction is invalid.

C

And just to clarify invalid in this case means unable to be included in a block at all, which is different than a transaction that reverts, because a transaction that reverts still has to pay for gas, whereas an invalid transaction doesn't.

B

Yes, it is more analogous to like a transaction, a normal transaction with an invalid signature. You couldn't put that in a block right, because no one can pay for that, because it's an invalid signature and similar.

D

To this, that knows, could just reject that not right away and like it doesn't need to be in then pool anymore kind of thing.

B

Exactly exactly so, so if you, if you receive a transaction, it nev, you you execute it for whatever guest. You want to basically maximally give it in the beginning and it never calls pay gas. You just drop it because yeah, it's basically invalid um yeah, that's that's that's exactly right um and that so they can't it will worse. And this is important now and we, I think, we're like maybe a little bit ahead, but we can just maybe, if I just scroll down here, because this is like this.

B

This section goes into the the functionality of like the functioning of this page, as I put in more detail and interestingly, and this again tries to replicate one to one normal.

C

B

C

On my on my screen, I'm seeing the slide. Still I don't know if that's true for everybody.

B

A

And we can see the proposal here.

F

Yeah, I'm seeing I'm not seeing the slides.

B

F

Okay, maybe it's on your.

C

End, it's just me, then,.

B

Most likely I'll open the recording, also that that comes through but yeah, um and then I just operate on the assumption that in recording it's fine and so uh again like another aspect that was just brought up. So that's perfect. Actually that also tries to replicate how normal transactions work when a human makes the decisions is once the signature is actually valid in a normal transaction and then later on the contract like reverts. Basically like you, the execution in the in a contract or so runs into an error.

B

Basically, then you still have to pay for the transaction. It's still included in a block right, it's just that it doesn't have any any effects, and so, in our case here once the contract pays pay gas. That kind of locks locks looks like the decision into place. So if afterwards, this contract- or maybe like some child contract, that you call into or something. If that then hits like an error and reverts, then you still kind of you can only basically it only reverts up to pay gas.

B

So at the moment of pay guys, you first make the payment basically and then you kind of freeze, all state and then any other further changes. They can basically be reverted and then those don't actually get applied if the transaction fails, but everything that happened before pay gas that basically is frozen in place that that can't be changed anymore.

B

So, even if you do like some state changes right, if the contract to make through storage or something before pay gas and then after pegas it reverts these changes, don't revert, so you can kind of do some accounting. You can kind of you can stall locally, like this user, I already paid for a transaction from this user, and so, even even if that, if the transaction from the user then fails, then the next time they send a transaction. You you still. Basically in your storage, you still have like little remark.

B

You did where it says, like the transaction you already paid for one from the user and then the contract can say well, I don't want to pay for another one or something. So that's why all? Basically, this pay pay guess of code has like this checkpoint behavior, where all changes before it are frozen in place, but afterwards like drawbacks and everything work just as before.

B

If that makes sense, um which I'm not sure, actually, if that that's probably um detailed somewhat here- that that's that's detailed in the section at the bottom here, but um I think the rest is it's. uh We mainly already talked about it.

B

So like um what kind of what what arguments right, upcodes usually take some arguments from this from the stack in the the virtual machine and so pegas specifically, um is- is to in order to be maximally flexible because we don't know, maybe in the future, you have different payment schemes with like erp 159 or so on. So it's like very flexible.

B

It only takes in like a version number and like some chunk of like some pointer to it to area in memory and then, depending on the on the like version number you just interpret whatever is in memory in in the way it's supposed to be so, like the version number zero in the first.

B

Like version number zero you just in memory, you only expect like a gas limit and a guess price, and so so basically, two values in memory, and then you just basically that that just means you, you pay for a transaction with a specific guest price and a specific guest limit. Just as like a normal user transaction, but like later on, you could have a version number one that is compatible with eip159 or version number two that might be compatible with whatever future changes there will be.

B

If that makes sense, and like just subjectively speaking, I would say the only like somewhat tricky aspect of this opcode. I think this is all pretty straightforward and, like there shouldn't be any issues like for clients, implementations and we actually did already like. uh We did do like a test implementation of a counter abstraction in go ethereum, um but that was of like an earlier version. So that's not not up to date with the current spec of the erp.

B

um We might do that at some future point, um but we're kind of already just like as a demonstration in the early process of our work. We already implemented something fully so so we do have a little bit of experience there as well, and so this this part really should be like relatively straightforward.

B

The one thing that is like a little bit tricky is like this checkpointing behavior to make sure any any state changes you did before pay gas stay in place even after rebirths, but as it happens at least in death, and I think in the other clients we looked at as well. These things are actually also the way they actually implement. Databases and storage happen to fit this really well, where you can basically just uh just give just briefly signal. Please never roll back further than this, and then you can.

B

Basically you get this baby almost for free. So this looks a little bit more complicated, but it's also relatively easy to implement in clients.

B

um So I think I think we are kind of starting to reach the end of the kind of main, um I'm not sure. Maybe I'm we're running a little bit over time already.

B

um I I'll try to like maybe speed that up a little bit, but, but you know also feel free to kind of signal to me if we kind of have to have a heart stop or anything, um but basically like, I think we are kind of reaching the end of the kind of the actual consensus or protocol, I would say, should say: protocol changes, uh there's two small ones um missing that didn't talk yet we we do need to also add a new non-sub code, because um the nonce is already verified like in the in the protocol, but you also want to make sure that the non is part of like if you kind of sent the contract, the signature, you want to make sure that the nuns was one of the fields that the signature signs over and that should, depending on how familiar you are with fitness's schemes, if that makes sense.

B

But basically uh you you want to prevent that. Like someone could just take the transaction change the nonsense, the signature is still valid right unless, of course, the contract, for some reason wants to have that behavior we talk about later, but but you kind of you need to expose the information what nonce was used for the transaction and you you need to have a way for the contract to access that information that wasn't in the evm so far.

B

So we also have to have to add, like a of course, like a very trivial new up code that just gives you the the transaction nonce um yeah, then what what else uh repair protection? I think you talked about it so basically, because we have the nons there's still no issue. Some slight technicality here that we actually only figured out uh recently is with self-destruct.

B

Is this one up code that everyone hates- and it also makes this a little bit complicated, because I'm not sure if you know that but like basically contracts can call self-destruct that deletes all their code and all their storage and resets their nonspec to zero? um And then you get like some guests back so so you can.

B

Basically, it kind of it's supposed to incentivize cleanup of unused contracts, but the issue here is: if you have like an aaa contract deployed and then the a contract self-destructs um and then the nonce is reset and then later on, someone re-deploys the contract at the same location.

B

Again, then, you might like kind of be able to to to send a new transaction that has the same nonce as as one that was already included in the in the distant past with the old instantiation, and then you might end up with two transactions, with the exact same hash on in in the blockchain, and that's exactly what we kind of want to prevent, and so we have to kind of have find out some way to kind of mitigate that, so our preferred way would actually be to modify self-destruct so that it doesn't reset nonsense anymore.

B

It kind of just keeps the nonsense whatever it was when it, when you call zebra stock, it only clears code and storage, but in case that is in some way, like kind of um a problem with like backwards compatibility, we haven't really discussed that with core developers. Yet then we all have this kind of throwback plan where we shouldn't talk about it too much it's, but it's basically just like introducing a way where you can just say this contract can never be self-destructive right and then you you you get rid of this.

E

Question about nonsense um so just to clarify um uh our nonce is just like the number of transactions for a given uh account and then the idea being that with each transaction, it's included in the hash calculation. So then the hash would always be unique.

B

Yes, that's exactly this, yes, and what, if you want to be really technical, then there's like the slight nuance that nonsense for contracts also track how many, um how many child con contracts they deployed. So if a contract calls create or create two op codes, that also increases the loans of the contract, so.

D

If a contract has announced.

B

15 then it means it basically had 15 interactions either like transactions right right, transaction aa transactions or contract deployments. But that's like a technicality.

B

um Okay, so uh this miscellaneous section is the last one of the protocol changes that afterwards we come to the memphis rules and and probably should recess like timing at the time time. But but just briefly here, I think those are not not really irrelevant, though, like um there's the technical question like if the aaa contract, if they, if, if they look at who sent the the message, the transaction, there is not really someone who sent the transaction right, it just comes out of not nothing. It just starts there.

B

So we create this new um special entry point, which is just like an address. If we, if we go back where we defined it up here, it's just a new like a special address. That's all all f's so like the highest address that they could be, and so we just basically say canonically.

B

All a transactions are like basically technically sent from this address just for backwards compatibility, so such that opcodes. That kind of ask for the sender of a transaction that they kind of understand what's happening, um but this is like this is really something.

E

On that account just out of curiosity, what's that? Do you own that, like top level account or um like just it, will never like? No one will ever own it.

B

This this one know what no one will ever own it, because it's it's like uh the way ethereum addresses space is kind of structured is this. There are so many addresses that if you just pick one at random um the chance of ever finding like a private key that potentially could could kind of unlock it uh like in in like infinitesimally small. So so it's not not feasible to ever find like a private key.

E

But I guess what I'm so? What what was this one like? Is this one owned by ethereum, like is my point like? Is this one not able to be generated during account creation, so, theoretically,.

C

You could generate it, but to intentionally find it would probably take longer than the heat death of the universe. So.

B

Yeah not not probably, but very, very probably exactly, and it's actually that's similar to how precompiles work so precompiles um also technically, basically have an address associated with them. It's the other way around. They are like very low numbers, so all zeros and then one or two or three or something and there's also like basically same situation. It's like just the hope that no one will ever find like an actual uh private key for them, but hope like a very real, very um realistic and responsible hope. So it's not so this. This will never happen.

B

Basically that we can. We be very sad about that, but there's no technical reason right. It's not it's not like a projected address or something I mean. I guess we could make it that fast. So.

C

The only reason why it's all apps, if anybody's curious, is to show that this isn't an address that somebody has generated like we could put any value here, but because it's all apps, it's very unlikely that somebody has generated that particular address.

B

Yeah, it's like nothing up my sleeves number, if that makes sense. um Okay, so so how we time wise? Is there still so it's a little bit time to like talk about the more advanced aspects of the erp, probably like a few more minutes uh just because this, like this aspect, that's coming now, that's also it's important to at least get the idea across and yeah. It just happens that account obstruction is this. I mean it kind of illustrates my point from earlier right.

B

It's just like this complicated um issue that like has all these different aspects to it, and so, um but at least right at least now we kind of we are the close of what the protocol changes are. So so I hope at least that, like looking back at this, it kind of makes sense that this is something where you you. You could see that like, of course, you might be of the opinion. You don't want it to ever. Get you made it. That's fine.

B

That's definitely is still an open question, but it's definitely something that could could be implemented. It's it's very much feasible! It's it's! Not that big of a change and now the one thing that's still left to to basically demonstrate is: is this safe right? Do these new transactions? Do they work?

B

Are there issues associated and that's basically, all that's left for now so like, and maybe I think we have a slide there as well um and again trying to basically keep it high level now for in for time issues, but basically um the the issue why? Why is? Why uh is a conversation, so complex is that it introduces new mempool challenges we kind of already talked about them.

B

This is kind of a way that I really like of like categorizing it and if we just briefly want to work through it, so basically what if in your transaction, arrives at a node and it's just completely malformed right- it just doesn't follow the specs that that, like that's, not an issue right, you can immediately check that it takes very little effort. You can immediately just throw the transaction away for normal transactions, but also for a transactions. It is like a very low impact of these kinds of transactions.

B

What about transactions that look like valid right? They have all the bytes in the right places. It's just that the they're like they they actually the signatures invalid or on the a case right. The contract never pays, calls pay gas well. This is a little bit more tricky already. um uh Normally, that's not not that big, an issue, because clients are very optimized for like checking ecdsa signatures. That's very quick! You can do a lot of those you just throw it away. That's fine for aaa transactions!

B

You might actually want to give it right if, if like part of the validation, is actually taking like, let's say, zero knowledge proof, which is usually the example of like the most like load on on the system um that might take 100, 200 300, 400, 000 guests right, so you might, they might actually takes take a while.

B

So if a transaction comes in and you kind of spend a bunch of time on validating it, but then it turns out it's invalid and you have to throw it away right if a lot of those come in at the same time, you can kind of imagine that it's somewhat of an issue. It's not that big and importantly, it's only for your individual node right, you don't transmit the transaction or something it's only like a local issue, but it's already something we have to address somehow and then the big one and that's basically the main.

B

The main idea I want to be. I want you to to take away here uh for, for with regards to what a has to solve is that uh what about transactions that are valid right? You receive them and they are perfectly valid. They want to pay.

B

But then, while you keep them in this memphis right where they they're like they want to get in, but they're not yet on on the chain and while they're in there something in the net in the network, changes right, some state somewhere changes or some balance somewhere changes and now all of a sudden they're not valid anymore and for normal transactions.

B

That the only way that can ever happen is if the balance of the cut of the account uh goes down that once you send it or the nonce of the account goes up, but that can only happen if another transaction from the same account is sent. So every time a new blog comes in you just basically look at what accounts send transactions in the block, and then you only have to kind of kind of go back to transactions for them and throw out some of those right.

B

But it's like a very clear subset of of issues and circumstances under which you have to kind of clean out transactions with account abstraction. If you only have like implemented the version, I just showed you the issue is: any transaction could like any contract could kind of access any global state like it could call out. It could do whatever um and depend on like some very specific state on the other side of the ethereum, basically for validity, and otherwise it's not willing to pay anymore.

B

So you you, you basically process in your block and then you just don't know any of your a transactions in your mempool that are like they want to get in, but they're not yet in. You know that at some point they were valid, but maybe all of them are invalid. Now, right, potentially every single one could be invalid. Now and you just don't know, you have no way of really telling, and so basically this is usually why a is so complicated right.

B

How do you make sure, like these transactions, don't just arbitrarily get invalidated all the time? This is. This is like the key issue, and so I'm going to skip over like basically this. This is like about invalid transaction. That's fine! We! We have actually.

D

A writer just a little note on why that challenge translates into a challenge is if, if the mempool is too full, then you can't include new transactions. So if it was full of stuff that was trash quote unquote, then real transactions aren't getting into the network and they're not being propagated, and so you you exactly every computer. Every node is a computer that has memory and if it gets full, then you can't do anything unless.

B

And also yeah, and what you would also imagine is like say, there's like a whole bunch of a transactions that all signal they want to pay like a lot of money like a lot of gas for for them they have like a higher gas price and then only your whole memphial is full of with those, and then a block comes in that changes, some state and all of them are invalid right and then all of a sudden. Basically, your mempool is empty.

B

There's just nothing in there anymore right and so then everything else has to be resent and so on. So so it can also crowd out uh illegitimate.

B

Yeah exactly so, this is like this one again this we actually um the next slide talks about it, but I'll skip over this. We do have like a write-up on this on each research we link in the erp. If you go to the very bottom and security considerations, this is very short here, because we have an own our own write-up on e3 search, and this is like really big, and it's it's not fully. If you read it, you might be a little bit confused because we already wrote this in september, so it doesn't like it.

B

It uses somewhat different language to refer to things, because it was before we finalized the ap draft, but it kind of basically addresses uh these concerns very clearly that this our verdict basically is. This is not an issue, and then last thing for for today, I want to just very like, like give you like, very high level overview. What is our idea, at least here? How do we? How do we want to solve this? One? Because that's that's the big one right, and so this is.

B

This is the medium one, this one where we are confident that we solved it, and this is like this is the big one. Other transactions turn invalid and so um mitigations here is, uh let's say, you're the manpool. I mean you're, like you, you're, on note, you're, on a client that that has a mempool that keeps transactions.

B

um There are two strategies you could do the first one is you kind of kind of basically only allow a transactions to even exist, that kind of are safe that have like these properties that you know about and whatever, and that that was the route we initially went on. They kind of you have to complicate the protocol behavior and all of this that's what we kind of decided against now.

B

The second idea: it's fine, if, like these kind of problematic a transactions are technically valid, you just never let them into your memphis so like we only need a way of like identifying a safe subset of a transactions right, a transactions that you can look at, and you immediately know ah this specific transaction. It's it remains valid. Unless this this, this very specific thing happens- and this can only happen like only that many times in a block and all these things right.

B

So we only need like a basically a way of identifying like a safe subset of a transactions and then what happens is the other ones are still technically allowable, but they'll just never make it through the network. Because nodes will there will be like a standard standardized like way of identifying, say transactions. All clients will implement roughly the same one, but again it's not.

B

They don't have to implement exactly the same one and then, basically, all a contract would be implemented in a way such that they kind of adhere to these safe rules and unfortunately, I think we are kind of out of time to actually go through what these rules are. But basically it's like it's two, it's two parts, first part is make sure your a transaction doesn't rely on external state.

B

So, like your contract, that kind of checks, if it wants to pay for it, it's not allowed to like go out in the world and read some external state and decide. Based on that, because again they could change at any time, so you're only allowed to decide looking at your own state as a contract and then also these contracts. They kind of are protected that other ones can just go in and change their state at any time.

B

So they kind of also have to have this kind of what we call a prefix, which says like which, basically very simply states like other contracts, are not allowed to just call in and change our state at any time, because then this could also change and if you just put those together- and we probably we have to talk about this some other time but like this- gives you basically the property that it's very similar to normal transactions.

B

Then like these kinds of subset of the a transactions, if you only keep them in mempool, they will remain valid forever. Basically, until at some point, like any other transactions from the same address or from the same contract is included in a block and then only basically, if your book comes in, you only look at the a transactions you go at this contract that send them, and you just basically only have to throw out those that were affected, and so it's like a very like mirrored behavior again of of what what is allowed and whatnot.

B

And so I think that kind of concludes. Let me let me see just briefly but um and yeah and then what we also do in the thing, but this uh I won't talk about. It is basically talk about. How can we kind of uh um kind of what? What limitations does that put on a a and how can we kind of step by step kind of relax these restrictions a little bit to allow for use cases that are also like vary so, for example, before before you decide?

B

If you want to pay, you want to at least be able to use libraries right because libraries on ethereum they're, technically also external thingies, but they don't access external state they're. Just external code, and so one relaxation would be to allow those and- and things like that, so like the second part of this of the erp deals with these things. But if we want to talk about them, we have to do that another time, because I think.

C

That's probably, this is a good starting point. Yeah.

B

It for it for today yeah I mean unless, if they're like any specific questions now for for these parts,.

D

They would it'd be great to have a follow-up on, like specifically the like the the addressing that last challenge: yeah yeah, like a follow-up episode, or something about that because I know in the from the core dev stuff: that's what usually comes up and then we kind of get to this point, and then it takes a long time to get there. And then we don't actually get to talk about it. So it'd be it'd, be super great to have another one of these.

A

So the good news here is, we are already planning another call, a community call which is going to invite a wider audience so that we can take up some more calls questions from the community, and that would be. I believe that would be super helpful for people uh to understand that, although.

B

Just briefly, I do think there's a point, though, that um it is.

B

You just said that, like uh we always like, this is the like one of the complicated aspects, and then we always take a lot of time to get there, and then we never really talk about this part and just want to make sure, because maybe the community call might be also similar, where a lot of the people joining there might not be familiar with like these like more introductionary parts, and so we might also not just not get get to these more complicated technical questions in the community called.

B

So it might make sense to keep this separate and maybe at some points it doesn't have to be like very immediate or something, but at some point schedule like a follow-up session specifically like for the second part in in more like a smaller group as well. I think that might actually make sense.

D

Yeah yeah, I would, I would totally agree with that, and the community call will likely come up with some more questions that, if weren't addressed in this call, we could have also be addressed. Something like that.

A

Yeah sure we'll be happy to arrange one more call. I mean, like the part two of this uh proposal. Thank you for the overview, but before we go, uh I have one last question about that. A playground thing does it still hold good like people can go and use that uh give it a try.

B

um So this that's a good point. Actually that was the implementation like this kind of implementation. We did earlier with like a very early version of account abstraction, I would say anyone who just want to kind of get a feeling of how they could feel like in solidity and how it could feel like interacting with these things. Could that would be very helpful, and that was actually like a really nice thing, so you can actually write a contract, an a contract today and kind of deploy it and play with it.

B

But you shouldn't like go if you're interested in like this specific version. um That's not that not helpful, because it's it's not this, this exact version, but if you just want to get a general feeling, um then I would definitely encourage that. Yes, that's a good point.

A

Great to know that, thank you, so this proposal has a lot of resources available out there right. Some of them are. We are going to add in the description section below, and I hope this episode today will help people to understand the proposal, and some of them can also go ahead and try this cool project, because this has a lot of interesting use cases.

A

If you want to participate in active discussion, you may want to join the rda discord channel for account. Abstraction and people can also follow the proposal on at magician. I believe this proposal is also getting into cfi. They consider for inclusion, and my hope with this proposal is that it will help ethereum adoption if considered in the future upgrades. So uh we would be organizing another call, as we mentioned earlier, the community calls soon and will have artists again to take more questions.

A

Thank you very much, sam and scared, james matt and other people who joined us today for people watching us on youtube. You may find twitter handle for today's guest and rest of the participants of this meeting in the description section below, and we will also share the slide, a link that was shared in the meeting today. If you have any questions, comments or suggestions about this or any other proposal, feel free to leave a comment. You are welcome to drop by to the cathedral's discord and say hello to us.

A

The invite can be found in the description section below next week. We will be having uh the first informational eip on the show and the guest will be danny ryan to talk about eip2982, serenity, phase zero. So if you like, this eip focus series share it with other community members. Let them know about p penny to hit like share and subscribe to the ethereum cat. Headers channel, see you next week till then keep sharing your love with cathartis.

A

This is your host pooja randhan, signing off.

B

Thanks, thank you. Thank you. So much for making this happen.

B