What You Sign Is What You Get: Ending Blind Signing with ERC-8009

Transcript

[music] [music] >> I'd like to add by the way that if you have any questions during this session, please use the QR codes on the side of the screen to send in your questions and we can answer them. Mark can answer them at the end of his talk. >> Thank you. Okay, thank you so much. So, let's talk about clear signing. I would think everyone has heard about Bybit hack. Bybit hack was a very drain of 1.5 billion dollars. So, people blame various reasons including organizational ones. I don't blame Bybit at all because they couldn't have done anything

given that they had no other option than to sign the message they were signing. So, the issue with the signing process today is that on hardware wallets, you can't know all the ABIs of all the smart contracts out there. So, you have to just essentially guess what you're signing. We have a solution. It's an open source solution that helps you do clear signing which helps you sign the transactions properly.

So, what is blind signing? Let's recap. Let's say you want to do a transfer or a swap and on your hardware wallets, the hardware wallet doesn't really know what the swap does because it's disconnected from the internet. It doesn't know all the smart contracts out there. It has limited memory. So, all that's left to do is to display the zeros and ones on the screen. So, that's called blind signing.

You kind of know what you're trying to do. You're trying to do a swap, lending, and whatnot. But, your hardware wallet cannot confirm that. So, you can't really confirm that it's the intended transaction on your hardware wallet. And you're only left to sign zeros and ones. And I I think an obvious question, somewhat naive though, would be to ask if why can't we just decode these transactions? Like zeros and ones, we can just decode them, right? Well, no, because hardware wallets, they are disconnected from the internet for security reasons.

And they have limited storage. So, if I launch a new smart contract today, then that smart contract would have to somehow be recognized by the hardware wallet. And it's impossible to do so without the ABI of the hardware of the smart contract uh recorded in the hardware wallets. So, you need the ABIs to know the function name, the contract state, I mean, the the functions, the fields that the contract has. And if you don't know the ABIs, you don't know the function name, you can't decode that.

So, hardware wallets actually do know a few of the ABIs, like transfer, approve, so the most common ones. But, if you launch a new smart contract today, chances are it will not know its ABI in a hardware wallet. So, the rest of the smart contracts, they just stay blind and impossible to decode. So, how this solution works that I'm showing you. It's ABI agnostic clear signing.

Um you don't really even need ABI to perform clear signing here. You're just running the differences of the balances. You see, okay, this is the difference of the balances after the transaction has executed, and you're displaying that on a smart on the hardware wallet screen. You can do so by changing the transaction to revert in case um the balance checks fail, in case the balances turn out to be different than the ones you expected them to be. So, in this case, we don't really need even to know ABIs because no matter the ABIs, the balance differences stay the same.

So, this is essentially ABI agnostic clear signing. So, before you were to sign like zeros and ones, uh, hex data, essentially blind signing. Now, you can sign looking at your balance differences. I'm going to add three USDC, but I'm going to lose like one ether. That's already useful information because you can see, "Okay, that's exactly what I intended to do in my transaction. I intended to swap, and this swap is going to produce the following differences in my balances."

There are two kinds of constraints we have in this solution. Uh, the absolute balances. Okay, I have like five ether in total after this transaction. Or deltas. So, I get minus one ether plus five USDC and whatnot. So, uh, two options users can choose. And by the way, here is the Sepolia link. You can scan it right now and see the real transaction that utilizes this standard. Um, and it allowed the hardware wallets to execute the transaction with a clear signing manner.

In this transaction, we, uh, sent the transfer send the transaction to the balance proxy contract. Um, and inside that balance proxy contract we made the calls that the user intended to make initially. Balance proxy contract checked that the outcomes matched with the ones user intended to make, like minus 0.001 ether plus five USDC. Yes, they matched. And so, the transaction got executed. So, what is covered right now by this standard? We cover ether balance differences, ERC-20 balance differences.

Um actually it says NFTs are not covered. Actually, they are covered because NFTs are tokens. Um this is like just a mistake on the presentation, but NFTs are tokens, so they're also covered. They're all They also have balances, so we can check against them as well. >> [snorts] >> Uh what isn't covered is arbitrary state because the state that we cover has to be standardized in order for us to be able to add it to the balance proxy contract that checks against uh this state. There are other standards also, of course, available for clear signing.

Uh intent-based uh clear signing is a different clear signing approach that attempts to whitelist the functions beforehand, and then if it sees a matching ABI matching contract address, it is then able to check against of the whitelist and infer the function name and what's happening in this transaction in text. So, that's not ABI agnostic. Um but it does have its own benefits as well because not everything can be expressed in balances.

Also, here is the QR codes on the Eth Magicians thread. This is the thread where we discuss this standard and request feedback. So, you're welcome to join the discussion. And these are just pictures from the real hardware. Uh this is me holding Ledger on the left and Trezor on the right. Um as you can see the Ledger and the Trezor they display you've got plus two USDC on the Trezor device plus point 13 USDC on the Ledger side.

So on these hardware devices I'm able to see exactly the outcomes of the transactions. And if I like these outcomes, then I'm going to confirm these transactions. Otherwise, I'm going to reject them. This is the link for our main website. So please go ahead and scan it and try it yourself. Uh you will be able to find all the documentation there, the proposal uh on GitHub and as well as the thread on EthMagicians as well as the video demos and as well as the application that allows you to execute these

transactions. Okay, thank you so much. I think it's time for the questions, right? >> Looking at the audience here. Uh if you have any questions, then please raise your hand and we'll come to you with the microphone. And if not, then thank you, Mark. Thank you. >> No questions?

>> Uh we have one. Yes, we do. Okay, I'll come to you so it's also on the recording. >> Check. >> Mic isn't working. >> Okay, now it's working finally. All right, so you know, you said Eth balance is covered, ERC-20 balances, NFTs of course, they are tokens, hence they are also covered. So like what do you exactly say? Like what are we going to use ERC-8009 for exactly? I mean, like that is the question which I have.

>> I'm not going to lie. I could not hear the question very well, honestly. >> So the question is basically this that what is the exact usage for the this ERC 809? >> Use case? >> Yeah. >> Yeah, okay. So the transactions that you're signing with your hardware wallets, they cannot always be readable. And as I mentioned in the beginning of the talk, that's how Bybit gets hacked. People blame many reasons.

People doing wrong work, like organizational issues. I don't blame none of that. If you see zeros and ones on your screen, little chances are that you can recognize something. So this is the entire problem of blind signing today in the industry. And people are coming up with various solutions to clear signing, which is the opposite of blind signing, which allows them to you know, see what's going on on the transaction on the hardware screen.

So the problem with clear signing solutions today is that they tend to try to get all the contracts out there, all the functions out there white-listed, right? But it's not always possible because you deploy like people deploy thousands of contracts every single day, right? So in order for a solution to cover all of them at once, forever, it has to be deployment agnostic, ABI agnostic.

This is the use case of our solution. It's ABI agnostic. It doesn't depend on any ABI, on any deployment of a contract. It just sees, "Okay, after this transaction, you will have these balances." And if you like it, please accept the transaction. So, that's the use case of this standard. It's when you don't have ABI for a contract available on your hardware wallet, and the transaction can be very well displayed in the form of balance differences. So yeah.

Great question. >> And we have another one at the front here. Yeah. >> Uh so, uh this is more of a comment. Actually, I'm a co-author of the standard. So uh when you say that state changes are not covered, the decision not to cover any other state changes beyond balances is because we wanted to have the thing out of the door as fast as possible with the minimum surface of auditable uh like minimum auditable attack surface.

But, in principle, the same kind of proxy verification is possible for other state, which is important. And the first thing that comes to mind is ownership. So, there's a standardized state, just like balances, of contract ownership. And whether there's a change in ownership, it can be verified the same manner. It's not part of this standard, but it can, and I argue that it should be standardized the same way. So, that's one comment. And the other, a little bit expanding on the answer to the previous question, is that transferring funds out of a smart contract, be it a multi-sig or a

you know, a a DAO that collects funds from various sources and then disburses it towards some goals, this is a real-life use case where this functionality, I would argue, must be used. It's simply imprudent to do blind signing transactions on that those kinds of things. And uh this whole standardization and implementation process was directly motivated by the by bit hack.

>> Thank you. Thank you, Daniel, for your input. Both Daniel and Mark will be available uh during Devcon. Uh they'll be around, I assume, uh for the questions. >> Yeah, sure. >> Awesome. Thank you so much. Let's give him a welcome. >> [music]