Transaction Assertions (EIP-7906): The Next Step in Ethereum Security — Mislav Javor | Ethlabs

Hello everyone. It's a pleasure to be back in Bgrade after a while. I think this is my third ETH Belgrade, second one actually giving a talk. I I was supposed to give talk on all three ones, but one year I got late. I got stuck at the border.

So, you know, I was I was like 30 minutes late to my own talk. So, this time I came yesterday. So, I took care of of of business. Um, so this is not a legal topic. Uh I am not a lawyer.

I am an engineer. So this is going to be an engineering topic. It's a very interesting title as you can see. EIP7906 uh transaction assertions via state diff op codes. What does it mean?

What does it do? So um what is the problem currently with security on Ethereum? You get a transaction payload that does something. So your transaction payload might um send 5,000 USDC from your account to I don't know your friend's account. Um you can essentially see that the transaction is sending this funds to uh another u account.

But what you might not be able to see in more complex cases is that there are secondary effects of the transaction. So if it's a trusted contract like USDC and you are only calling the send instruction, yeah, you might be fine. But what if it's a batch execution? What if it's um an interaction with a lending protocol? What if it's an interaction with a complex prop amm decentralized exchange or something like that?

Uh the problem is one transaction can have many many uh outputs, many many state changes that it does. So, one thing that might happen, yeah, you might send 5,000 USDC to your friend, but it also might give an infinite approval to a drainer account uh in the same transaction, right? Because it was a batch and you saw the first part of the batch and it looked fine and the second part of the batch was the dangerous one. Now, how do you solve this? You use Tenderly like the Serbian blockchain company, let's go.

Uh so, you use Tenderly to simulate your transaction, right? That's the that's the current currently accepted way of uh making sure that you are safe and secure when interacting. But what is the problem here? Uh your ledger cannot access tenderly. Your ledger cannot access the internet at all.

It cannot uh interact with your computer. Why? Because your hardware wallet is fully separated from everything uh in a way that it's um it only sees the transaction payload. And that is by design. Why?

because it reduces the attack surface area that uh you might be exposed to if you are interacting with a hardware wallet. So now your security has gone back into a non-airged device. So imagine you are simulating the transaction on a computer that was infected by a Lazarus malware that uh forces the simulations to behave in non-predictable ways and gives you false sense of confidence that everything is fine while everything is not fine. Hm. I wonder if somebody maybe have lost a billion dollars via this exact mechanism.

Uh they have last year. Uh so it's a very very big and very obvious problem. Now um how do we actually solve it? Like how do we know what a transaction will do if we cannot access the state of the blockchain to actually simulate it? That's what EIP7906 does.

So what's what's happening here? Um something is coming to Ethereum called frame transactions. Maybe it's not going to be frames. There's again like a contentious discussion about what AA is actually going to be. But frame transactions are essentially splitting a single Ethereum transaction into multiple distinct phases.

One of the phases is validation. Then there is a phase that's called execution. And now there is a sort of third phase that that can come at the end of the transaction that's called an assertion. What is an assertion? Assertion is essentially saying look let's check what happened and what didn't happen.

So these are two very distinct parts of assertions. What happened for example uh imagine and I will actually have an um have have an example so I'll get on to it a bit later but the core of it is that a hardware wallet should be able to read the transaction payload and guarantee that only certain specific states will change onchain that nothing else no secondary effects will happen uh no lending market indices will be updated no uh approvals will be granted so not only should it be able to guarantee that something will happen. It should guarantee that nothing else will happen beyond the specific effects that we as users saw on our hardware wallet. So an example here is imagine you are swapping 2500 USDC into WH and you say you make a normal assertion that you can do even today without EIP7906. So make sure that I get at least one wet and make sure that my USDC balance reduces by a maximum of 2,500.

uh in this case. So I can do this I can do this even today. This is like something maybe I do a batch that like does a check and re reverts if if this doesn't happen. But um what I can't do right now is say look within this transaction payload make sure that the only specific states that are being changed are the ones that I said. So the only state that is allowed to be changed is my we balance grows by at least one and my USDC balance reduces by a maximum of 2500.

So keep that in mind. This is a very very important distinction. What does this mean? That if I have a very very complex batch transaction that interacts with a hundred different DeFi protocols that loops around etc. I can put the last piece of the transaction to be a specific assertion about the outcome state for this transaction.

This is a huge huge improvement to security because I can then on an airgapped device such as a hardware wallet I can statically analyze the specific new state that the blockchain will be in at the end of the transaction without simulating it on a non-airgapped device. So we are moving back a huge amount of security assumptions into the hardware wallet which is an improvement especially when working with like complex DeFi interactions for treasury management for multi-IG management for you know loops and then all these other very interesting things. Um so how does it work within the frame transaction ecosystem? There is a specific frame called a post TX. uh it's a readonly frame.

That is a very important distinction. It cannot modify state. It it cannot like on the blockchain level it is prevented from making any mutations to the state. So this means that the state diff differential that this frame sees is the final state differential that will ever exist in this transaction. Um if the transaction reverts in the post transaction uh frame.

So you know like if the assertion that you have made doesn't go through the transaction stays included but it reverts. So like the the validators get paid the gas you know so you cannot use this as a DDOS vector to attack the the memp pool and the validator chain. And then if you want to have multiple assertions like what I mentioned my W balance increased by at le decreased increased by at least one my USDC balance decreased by at least 2500. I can compose them as multiple post TX frames within the frame transaction. So this is all well and good and it's going to solve all of our problems.

But as is usual in blockchain there are specific edge cases that we need to think about. Um if you are a sophisticated player uh if you're a sophisticated uh transaction exeutor who is executing a transaction uh within a scope where you understand exactly what state needs to be mutated and what state doesn't need to be mutated you are fine. You do not have this open problem. But if you are just a regular user doing some regular stuff onchain, you do not really know that a transaction storage slot number you know 532 within the fluid uh dex market contract lending sub protocol should have been set to a boolean flag of true instead of a boolean track of for false. Right?

So you do not have like you will get this state diff like you will get this like huge list out of all the state diffs and it will be a meaningless meaningless blob of data to you that you have no idea how to interpret. So uh the core of the idea here is that yes the wallet now the hardware wallet is able to show you all the state diffs are you capable of interpreting them properly. Um so what is um solution here? Uh this is something that the Ethereum Foundation trillion dollar security initiative is trying to uh spearhead. Now uh something similar if you know about clear signing which is this new standard that basically says for every transaction there's going to be a human readable way to interpret the transaction from a registry that a wallet can fetch and then show it to you.

So something like this but for storage slots of uh important contracts. So maybe unis swap a you know uh prop paymms uh big erc20 contracts uh defy aggregators all of these things maybe everyone is going to publish their storage slot schemes you know how I don't know I have a mapping this is the kessa cache this is like the the byte size of everything and there's going to be a mapping process from this um from this uh registry into a safe transaction. So you know you might express as a protocol hey within our protocol these types of state mutations are considered to be canonically normal transactions right so if I am doing a swap this is a canonically normal transaction if state at indis you know 75 is changed by this amount to this and that this is considered valid if some other state is changed this is considered maybe not a hack but a dangerous state change that that's unus usual or should not happen and you know warrants additional verification. So your hardware wallet might give you a you know popup that's saying hey you know we have detected an unusual state change within this transaction payload. Are you sure you want to proceed or like this registry might even give you a human readable output you know it says hey your balance you are depositing to a vault now now your balance of the vault will increase by this much and your balance of this will increase by that decrease by that much but this will also update the index of the you know tracker contract that aggregates this uh specific market this is harmless to you right so so it's going to be quite kind of hard to generate these human readable shrinks, but for a lot of use cases, for a huge amount of use cases, it's not going to be as complicated as that, we're going to be able to build like a good interesting registry.

One important thing is like it's immediately going to be useful to the likes of BBIT or whoever who are like sophisticated [clears throat] players executing their transactions because they're get they'll get another tool in their toolbox. for uh regular people there's going to be probably a bit more you know uh back and forth on like how what is the best way to integrate this with hardware wallets uh I think this is one of the initiatives that we'll take on at at Eabs is basically coordinating with wallets with uh hardware wallets with you know everyone to just say you know like how do we build this how do we approach it but um yeah um I'm kind of uh ahead of time so I think it's this is basically all we need to know about this um so If you have any questions, uh, happy to answer those.