Goodbye YOLO Signing

Transcript

[music] [music] Hello. One, two, three. Hello. Uh, hi everyone. Um, my name is Khan and as introduced today we will be talking about how to get rid of hexadimals once once and for all hopefully and say goodbye to what we call yolo signing. So this is just a normal day in web three. I guess everyone has seen this once in their lives and this is what we have when we want to sign a transaction. This is just hexadimals bytes gibberish. We don't know what's happening and you're just wondering like what am I doing? Is this going to am I going to lose my life

savings? What's going to happen? You have no idea. You just sign whatever is offered to you like Tom does here and just hope for the best. But why is this like why does it have to be like this? It's been 10 years since we started Ethereum. Why couldn't we find a solution to this? And I thought about it and there are a couple reasons. Uh there are of course many reasons to it, but I think the biggest reasons are that the action space is unbounded. So like we have EVM contracts. EVM is a complete virtual machine. It can do anything unlike simple bank transfers or anything that is well defined. it there's so many things you can do and

it's impossible to have a one size fitting solution for everything right so you don't see any blind signing problem in e transfers or arc token arc 20 token transfers and what I would say is that technical problems are in general easier to solve like you can eventually solve them but the coordination problems are the more difficult ones and here the problem is so a lot of people claim they've solved clear signing and they have different standards but the problem is that like some something has to work and something has to work for everyone and once and for all.

Yeah, there is no ecosystem wide solution and everyone is basically trying to solve the problem for themselves and in basically someone just needs to step up and get the work done needed here and we also tried this at sourceify. So this is a screenshot from 2022 earlier days of Sourcify when we wanted to and hoped to have human readable smart contract interactions through solidity smart contract verification and we wanted to use notspec comments and and the metadata JSON to solve this problem. Uh of course we weren't able to do that because it's a huge problem and we just focused on what we do best and we focused on uh source code verification. But I think uh and also I've wrote wrote about this

like uh how we tried to do this and what we learned. But I think the time now is has come to be able to solve this uh in an ecosystemwide way. And today we have this new ERC uh ERC7730 about clear signing uh which was initially written by ledger but now the there is a working group formed around this whole standard and we are basically moving the standard and the implementation forward all together. So it's an open and evolving spec. Um it's an EIP and now the so there's an EIP and there's a there are JSON files which I will show in detail

and the registry of those files are now on under Ethereum Foundation. Previously it was because under Ledger of course no other wallet wants to depend on another competitor wallet's implementation. So now this is a fully open neutral solution and why the most important thing why I think this is going to solve this time is the spec this time has a critical mass of stakeholders. So we have ledger we have treasure source cifin zama and also the ethereum foundation's trillion dollar security team is helping us. So I think we can do it this time. So now I'll walk through how the spec works and how everything

works in general. As I said, this is an EIP. So it's a very long EIP. I would encourage you to read it, but it's a very long EIP. So if you want to read and understand, please read it with an agent. Just tell your agent to summarize it. Ask ask your agent questions and it's much more easier to understand. Um it has very detailed specs about how to do things. And besides the EIP as I said there is so the IP the EIP defines a JSON file. The JSON file defines how to describe a contract and the the JSON file the EIP defines uh is a JSON schema. A JSON schema is a way to define [sighs] how a

JSON file looks like. And the schema is also in part of the EIP. So it's not in inside the IP of course but it's evolving with the spec. So this is for example version one version two and this is the what the schema looks like and the schema defines the files inside the registry. So this is the file system of the GitHub registry and above you have the spec and the schema and as I said the schema tells how these files look like. So these files are for example the unis swap contracts and the the the descriptor for the unis swap v3 router and [snorts] inside this file you define

like how each individual function how to decode these functions right we have unis swap we have a we can also decode EIP712 signatures and we also have a bunch of tests to make sure it works and these files live in the GitHub registry. So as you can see the GitHub registry is under the Ethereum name under the Ethereum foundation. Uh we have a bunch of CI checks like right now sourcify team is mostly maintaining this and we are gathering everything here as a as as a as single place.

So let's now look into a single descriptor. So this is one file that defines a contract like this explains okay how do I decode this unis swap contract [snorts] and for that of course we need to know which contracts we're talking about right so these are the deployments of this contract and in this case this is not unis swap this is a so these are a deployments on different chains so on mainet we have this on base we have this and so on so this is the top of the file now top of the file now we are scrolling down and we have an individual function. This would this is what you would call as a user user typically and the fields below will describe how we do the decoding. So

before that let's look at an example in AI encoding. So this is what a typical function call look like as a user. If you want to borrow on a you would just sign this call data and it will execute. And uh typically a call data typically a call data starts with a function name in this case this function borrow. And if we do just the AI decoding you would get these fields. So it's still relatively uh readable. It's surprising how still how many wallets don't even do AI decoding. I'm just going to note this here, but still this is still a bit readable, but it's not still fully

understandable. So, you have the amount which has decimals. You don't know what that actually means. Interest rate mode two. What is two? I have no idea. So, we can even get a get a even better result uh better than the AI decoding. So, let's walk through how this works. So, again, you have the function. This is this is the borrow function and your intent is to borrow. So this is the action like this is the main thing what you want to do like this is my intent and these fields are for each parameter. So we say okay the label of this next parameter is the

amount to borrow like what is this? This is the amount to borrow and then this is this is going to be formatted in a token amount. So there are different standard formats like a date, I don't know like token amounts that are already defined in the spec. So we have these formats and a token amount is typically what is what consists of a decimal and the ticker, right? [snorts] And this says okay this is a token format and the variable is the amount. So this is the variable we take from the function but also so we know the amount of the token but we don't know which token this is right. So there's an extra parameter of the formatter says like

which is the token path which is the asset and the decoder will take the ticker and the decimals from this to be able to decode it. So it has also a parameter and then the second one is the interest rate mode. So we can define constants within the JSON saying okay like interest rate one is fixed interest rate interest rate two is variable interest rate so that we can show the user a meaningful message and on behalf of is the one that is doing the borrowing right so this is the this is an address we say this is a address name format and we say okay this can be any and you can decode this from your local address book or you you can

reverse reverse resolve the ENS name if you know the ENS name and in this case for example the ref referral code parameter is not really relevant so we don't want to show it to the user it's not helping us that much and in the end instead of this hex you hopefully will be able to show this message right um what's this what's the status of the registry so we have these numbers like above 700 descript descriptors more than 80 teams and protocols like unis swap a and so on uh 2,000 contract deployments that are bound to descriptors and this many chain ids and I've also wipe coded this dashboard

uh to see where we are at and I wish I could tell you we have 78% clear signing I can technically can but this includes the ET transfers and ERC20 transfers which are trivial so let's exclude these numbers and two weeks ago if we excluded these numbers we were at 4%. Unfortunately, like only 4% of the transactions going through Ethereum main mainet in the last 24 hours would be able to clear signs. But the last couple weeks we worked quite hard and we generated a lot of descriptors with AI of course and a shout out to port for helping us with that and we merged a

bunch of descriptors and now we are around these numbers. So the nice thing here is there's a power law at play of course like most of the transactions just go to a few contracts right so that means if I remember correctly if we are able to clear sign maybe 400 contracts then we are at 80 90% something like that so that's for our advantage but we still have a long way to go um yeah and also this is you can by the way scan the QR code to see the dashboard and this is the top uh contracts in the last 24 hours. And if you want to try this out individually, you can also go to Sourceify's website and you can just click one of these transactions here

below clear sign transactions or just paste your transactions and try to uh see if they are clear signable or not. And in the end hopefully they will look like this like instead of the left side you see something on the right side. uh we also have an SDK we developed a reference implementation but in my experience most of the wallets wants to have their own implementation they don't want to have an extra dependency but we still have this reference typescript implementation to easily clear sign and it's very easy to use of course it's just an npm install give the chain ID give the address and give the call data and it will handle the rest of the things uh of course you can also decode

EIP712 signature with this library. But the question is, can I trust this? Like I've been telling you and I'm like I I'm telling you like okay we've solved this we now we can decode but again this is another trust question. How can you trust this? So of course we have basic checks on the on the registry like we have a linting we check if this contract [snorts] is verified if the API actually matches the functions you are describing and um if all the functions are in the API and so on and also we have multiple runners multiple implementations that need to agree. But then we also have an extra AI review step that we recently

added that helps us a lot because uh we don't want to miss very obvious um yeah implementation mistakes and so on. So we also have an AI review on each PR that will do a basic sanity check but still this is not the main trust anchor like it's the attestations that we want on our descriptors that will bring us trust. So what is this? So we have auditors or anyone that can be a reviewer that will attest on descriptors saying okay like this descriptor is good and this descriptor describes well a function and in your wallet you will say okay like I trust

ledgers uh a tester I trust cifins a tester and they are ethereum addresses because they are based on ethereum attestation service and your wallets or your implementation will only show those descriptors from the trusted testers. Um, but what are the other challenges? Of course, the biggest challenge here is the hardware device limitations. They are uh intentionally constrained devices. So, most of them don't have a big screen. So, we have to bear in mind when we are um solving this problem. The device communication is also not straightforward right now. uh every hardware world has a different way to get data into the device but uh we have

Nicolola's work Nicolola working on it um to bring a standard format to bring the uh descriptors into the device [snorts] and I would say the biggest challenge could have been could be the creating part right because first of all what is even a good descriptor like how do you even describe one big function call like is this even a good way to describe it? Are you missing something? But at the same time, you don't want to overwhelm the user. So it's a very this is the art part of it and doing this at scale is the difficult part like so we have thousands of contracts that we need to clear sign and this is non-trivial.

Um then of course someone creates it and someone needs to review it. So we have this of course the AI review but it's not complete. So then we have the testers then the testers have to review as well. So it's it's a lot of work to so we have a lot to do here. Um and of course the coordination part is as I said in the beginning of the talk is I would say the most difficult part on the technical side. Revocations are I find having revocations a bit an unclean solution.

So we have the attestations of course and we have the onchain revocations. So you would have to check the revocations but then your hardware device should not be online like how your how does your hardware device check the revocation that's another problem the proxies are always tricky everyone probably knows uh some contracts like unis swap safe have nonabi encoded call data so we need like custom encoding a custom spec for that for each and every contract and I don't even want to get into internationalization at this stage [snorts] um what does the future look like so as you probably have seen and I would expect a question regarding this as well is uh is this permissionlessness is this uh I don't know can I is this

open because it's a GitHub registry right are you gatekeeping so of course right now we're kind of gatekeeping if you want to say say it but the goal is to eventually have an onchain registry kind of an onchain contract that will host multiple registries so you would say okay like our registry can be one of the registries and you you will be asking okay I want the descriptors for this contract give me where they are which registries and give me who attested them onchain so you would ask you would be asking this and then the registry will respond to you that's the future goal um but also what I conceive like what I'm thinking about is to have something like anspec++ in

the contract in within the contracts in part of the part of the contract development And basically to have something like this inside the solidity files or wiper files to be directly part of the contract development process, right? You don't want to have an extra step to um write descriptors separately. You it should be just part of the process and similar to now how we expect a verification like expect open source from contracts. this should be also expected and we also have a even uh proof of concept for that. So I'm hoping we can get this very soon.

Uh but again a reminder like the clear signing is not a silver bullet like it's just part of the big puzzle of contract uh transaction safety. Of course, ERC7730 helps you describe the instruction but then simulations part play a part like because some people say okay like why aren't simulations enough? No like these are like complimentary things like this is the intent simulation is the outcome so we you need both um we should have transaction assertion so that we the things that we don't want does not happen and so on. So we have labels, we have blacklists, there are so many layers of transactions and this is just part of the puzzle.

Uh and to kind of help with this, we just started a proof of concept project called onai as a transaction helper. Uh this is a browser extension that pops up and helps you understand what you're signing in a human readable way and just a read only way. It doesn't have any keys and so on. It will just because what we think is it's very easy to verify but no one does a second or third check on the transaction. So we want to just streamline this and make this very easy. So what should you do? If you are a wallet, please integrate 7730 either yourself or just use our libraries. If you are an Ethereum app, please write descriptors or reach out and we will

help you help you write descriptors so that we can have a better coverage. Your users will be happy. If you're a security company or an individual, we really need people to attest. So, we are not trying to give you even more burden. Please don't get it wrong. Just let's figure out how to make this scalable, make this easy for you and us. Let's do this. And if you're a user, uh please demand this from your wallet and hopefully in the near future when we see a transaction like this, we will say no, like I'm not going to sign this because right now we're just accepting everything. And yeah, uh if you if you're interested, if you want to contribute, just find me on these contacts. We have a telegram group. We have bi-weekly calls. So just help us

build this together. Thank you. [applause] Thank you very much. So with this ERC accepted, the blind signing will go finally away, right? >> Hopefully. That's the question. >> Cool. So let's see if we have any questions from the audience. and we have so let's start with the first one uh how is it possible to validate that the clear signing definition is correct >> yeah as I said this is the art part of it right there is no single definition I think so the similar to the power law playing in the contract coverage we also have an advantage here what is the alternative the alternative is just bytes so let's have something that

describes it but of course like let's have a good enough description that doesn't cause any loss funds but then that's enough. So um yeah so there's no single way but a good way is enough. >> All right the next one uh the EIP was written in 2024. Uh what is preventing the EIP from more widespread adoption? >> I would say it was that it was only Ledger that was trying to push this. Now we have the neutral host we have the working group and it's just getting the work done and the help of the ecosystem to get this adopted.

Okay, let's get to next one. Uh this if a hacker manages to upgrade the contract, wouldn't wallet displaying clear sign transaction trick user into signing malicious transaction? Are you tracking proxy versus or implementation versus two? >> Yes, and this is also something we're considering uh which is not a easy solution. So we want to track. So we have an extra new spec feature to track proxy implementation. So you in the descriptor you would also define the implementation address so that in case something changes your wallet should say okay like the implementation addresses are not matching please don't sign. But

then this is also non-trivial in hardware wallet. So we are actually struggling to find a solution here. The best solution we can find right now is having an external monitoring service for any descriptor that defines such an embedding like what we call is intent mutability. So if the the intent somehow changes the external monitor would um alert but ideally the hardware wallet does it but hardware walls are isolated devices so like this is a again non-trivial problem.

Okay, we can still do a few more. So, let's uh select this one. Uh, can the descriptions be automatically generated as a new source C output? >> Yes, as I've shown the Natspec++ example, we can do that and hopefully this will be part of the um contract pipeline, contract development pipeline, but doesn't have to be soulc it can be also part of the frameworks. >> All right. And the next one um let me see which we can do this one. Uh how does clear signing war with newer L2s and newer D5 protocols with different uh architectures wearing architectures?

>> Uh so as long as your call data is API encoded, it's no problem. But if it even if it's not API encoded, we have a custom encoding uh feature coming on. Uh but otherwise anything EVM we can do. There's no I don't see a problem how we cannot do it. >> Okay. And a few more. So how does the AIP work with unverified contracts? >> It does not it does not make sense to clear sign an unverified contract. Your contract has to be verified first.

>> Very nice. And uh do revocations add another point of trust? Yeah, I'm assuming here is both meant attestations and revocations. Yes. And we have to have a point of trust. Um, and I think you should be able to choose who you trust. If you have time and if you have the expertise, please look at the descriptors yourself, but I don't think anyone has time to look at each contract and each descriptor. So, you have to trust someone. Yeah. Thank you very much for great answer, great questions and great answers. Uh we have space for the last one. So let's do this one. Is it something that is mostly on

what is responsibility or do the apps also need to actively support it? >> Yeah, it's a chicken and egg problem here, right? So you need to start seeing clear signing to expect clear signing as a user. Um and for DAPs to start doing it, they need to see it in action. So that's why we started doing these descriptors with AI like even though they are imperfect so that we can kick things off and people and [music]