Goodbye YOLO Signing

Transcript

Hello. So, welcome everyone. Um I will be talking about blind signing, but that also has things to do with verification, but today's talk will be mostly about uh blind signing, and I chose the title goodbye YOLO signing because this was the title of the talk that was held by Franci around 4 or 5 years ago when we were working on Sourceify, and we were trying to tackle this problem of blind signing.

Um I also gave this talk in Devcon, actually, 4 years ago when we were trying to solve this problem, which we couldn't We we couldn't solve it ourselves, and we ended up focusing on what we do it best. We focused on smart uh source source code verification, which I will be also mentioning, but um in the end, we couldn't solve the problem, but the same slides I used will be here in the next four one four slides. So, I started with this. I said, "Just a normal day in Web3." And this is something we see every day. You get a contract call, you need to sign it, and you actually have no idea what's

going on. You're like, "What is this? What am I signing? Is this even right? Am I going to lose all of my money?" And in the end, like, if you sign this, this is the same as doing just like shut up and take my money. Like, I have no idea what I'm doing, and you can just take all of my money. But at the end of the day, what we want to have is something similar to on the right instead of the view on the left. So, much more human readable. At least I I can see and make sense of what I'm doing.

Even 4 or 5 years later, we haven't achieved this, and the things haven't been so nice. We have been through many hacks, and many people lost their money, but um the tunnel You can see the light at the end of the tunnel. But as I said, we couldn't sign we couldn't solve this problem on our own as Sourceify and it's a huge challenge. It's a bigger dragon that we can slay as ourselves as a small team and we needed everyone to team up and start working on this. And this actually recently started happening.

We if you've seen this initiative we started a working group to solve the problem of blind signing and bring the clear signing. We teamed up with Ledger, WalletConnect, Trezor, other and other projects also stewarded by the Ethereum Foundation's $1 trillion security team and we came up with the potential solution. So the working group has a website. It's at clearsigning.org. You can already check that.

And then it is consisting of these projects that I think has a critical mass of stakeholders. So once of course we want to have more players, but initially we have these projects that can give us the escape velocity to bring the solution and also stewarded stewarded by the EF. And initially we kicked off the working group by moving the registry from the Ledger registry because it was started by Ledger into the Ethereum clear signing registry. So under the Ethereum Foundation's GitHub organization and the QR code will link to that registry.

And this is the basis of the solution. So ERC-7730, it was authored by Ledger initially. It's already around 2 years old. Over time we gathered more contributors and it's a very detailed spec and I will be walking over that with an example. And before before the examples like how how is how does it work in general? Uh so, can contribute to that, see how it works. Uh the registry is open. Right now, it is on GitHub. It's under the Ethereum namespace, as I said.

But, over time, we want to decentralize this more, put it on on put it on chain, and maybe put it on IPFS. So, we are um considering these options. But, to kick things off very quickly, and to be able to come up with a solution, finally, we are just taking a shortcut and using GitHub. And GitHub is GitHub is useful for PRs, and it's a already established uh collaboration platform. So, it is helping us right now but we are well aware that this is not the end goal. And the next improvement would be on attestation. So, right now, the descriptors on GitHub are kind of trusted. But, over time, we want to have

independent auditors or attesters to be able to attest these descriptors. Okay, like saying, "This JSON file, this descriptor, correctly explains the contract." So, you can say, "Okay, I'm trusting So, I'm Ledger. I have my attesters. I only trust this key." So, you just trust that one. Or, you can say, "Okay, like I trust the security firm X, and they have attested these descriptors." So, you just accept those those descriptors. Uh and this will be based on Ethereum attestation service, and there is an ongoing EIP ERC for that.

And why does it work? Uh because I think one of the important features of this, by being an external registry, is that the ERC is a backwards compatible. That means we can already be solve this problem for existing contracts, because if we had something on chain, that would be only for future contracts. And by having an external registry, we can make it work for existing contracts. And it's expressive that it's much it can you can show and tell much more compared to ABI and NatSpec. And it also comes with special formatting for different types of input such as tokens, dates, and you can also refer to the contents of a transaction such as the address you're sending to, the amount of

ETH you're sending, and so on. These will be much more clear once we go over an example. And the other feature is that it's actually restricted. So, we don't actually want something that is too powerful both in our wallets, like in our software wallets, and also the hardware wallets that are quite limited in computation. So, they're intentionally limited devices. So, something that is Turing complete wouldn't work for our case. So, first, I'll walk over an example. This is a Aave contract on on sorry, on the ClearSign registry.

This says, "Okay, like this Aave LPv2 contract is deployed on the the these chains and these addresses." So, on mainnet, it's on this address. On different chains, on different addresses, so that once your wallet hits or tries to call this contract, it will know which descriptor to call. And second, we have a metadata section that has metadata information, and we can also like declare some variables here, like enums. This will be useful in one of the next examples. And then, of course, the contract name.

And then, in this example, we will take the borrow function. So, imagine we are trying to borrow using Aave. And these will be the high-level descriptor of that. So, let's walk one by one. So, imagine this is our call data. Again, this is the four-byte signature that will call this function. The the signature, and then the rest of the call data that we can't read is looking like this. And this is the function signature in the descriptor so that we can by taking this, we can calculate the four-byte data.

And then there's the intent. So, what we are trying to express here is the intent of the user. So, what does the user want to do? And it is borrow. So, typically you will show this at the beginning of your transaction view. So, you want to say borrow, and then next come the fields. Okay, the next one is the amount to borrow. So, you will you show your user borrow and the amount to borrow is this. So, in this case, this is a token amount because I mentioned we have different formatting options, right? One common one is the token amount. We have ERC-20 tokens on Ethereum.

And then this tells us to decode the amount information in a as a as a token. So, this will say, "Okay, like format this as a token amount." And we have these formatters already described in the ERC. So, this is a screenshot from the ERC, and this explains how to uh decode or format the token amount. And then it says, "Okay, which variable is the amount?" The amount is the amount. So, this will take the amount as the the amount of tokens we want to take.

And then it will set it will take some parameters. So, one of the parameters here is the token path, which means like what is the contract address of this token? And this will let us go to that token, take the decimals, take the um the shorthand of the token such as USDT or DAI. And then this will show us the amount plus the name. And then next we have, for example, the interest rate mode. So, Aave has three different interest rates, and we already defined it here in the metadata section.

Here exactly what those correspond to. So, for example, if you see an zero, it's none. The one is deprecated, and the second, if you see a two, it's a variable interest rate. So, we can say, "Okay, in the interest rate mode, use the metadata we declared there." And then, next one is the debtor. So, the label is the debtor. I'm highlighting the other part, but the label is the debtor. So, it will show the value inside the on behalf of. So, on behalf of is the path, and on behalf of is the last variable in the function definition.

Uh and its format is, for example, here, an address name. So, this says, "Okay, like, the value you are seeing is an address." And it says, "Okay, what are the parameters?" In the second box, it says the type. This will be an EOA, uh external account. And you can look look up this address from your local address book or from ENS. So, you can also reverse resolve the ENS name of this address. So, this will be give you a much more uh readable information. And then, we can also omit fields. For example, the referral code is not too relevant to this step, right? So, we can say, "Okay, like, this will be not visible."

And at the end, using and plugging everything together, we can go from this raw transaction into something this the something that looks like this. So, this is much more uh relieving and understandable. Uh we also have other types of formats. So, we can say, "Okay, like, the the the the the the data is a call data, so you can decode nested calls inside a for inside a multi-call." And then, we also have an interpolated intent to show longer strings. Uh if you want to have something longer instead of labels one by one.

And you can also already try these uh in the playground we built at clearsigning.sourcify.dev. We have some examples here and you can also put your own transaction hashes to see how this works at the moment. Uh the playground, for example, is using the SDK we built. So, we are at Sourcify, we're also building an SDK to make it very easy to integrate the whole clear signing experience into wallets and also applications and block explorers. And it works as simple as installing it, uh giving in the format function giving the chain ID and the address of the contract, and then just passing the call

data, and it will show you the intent, the fields, and the interpolated intent if you want. It also works for EIP-712 type data. So, if you want to sign only uh the descriptors are typically both for can be both for call data and can be also for signed data, EIP-712 signed data. Uh the library also handles batch calls for EIP-5792. And of course you need to have your contract verified. So, as as I said, Sourcify is a source code verification tool. In case you don't know what source code verification is, it is the When you

go to block explorer, you go to contract page and you see the green check mark and you can read the code, right? That's the whole process. But Sourcify is doing it in a more and open in a more open and decentralized way. And right now we have almost 32 million contracts and over 260 chains. So, we have a quite decent amount of coverage. And more importantly, Sourcify is open source compared to the current other verifiers. And it's the data is completely open. So, you can basically download all of the contract and the whole database and do whatever you want to do. You want to do data analysis, you want to do you want to find a pattern over all

contracts deployed, you can do that. And I think this allows a lot of innovation to happen in the EVM security. We also host the biggest 4-byte database. So, we took over OpenChain, if you already know that. Um that means most of the EVM tooling is using Sourcify database to get function signatures. Uh yeah, you this is a playground for that. We also have an API, so you can look up contracts, you can verify contracts, and we don't have API keys, so you can freely access that and verify contracts.

Uh it's supported on Foundry uh sorry, it's supported on Hardhat, it's supported on Foundry. And besides that, the clear signing thing is already live. So, I want to emphasize that this is this is something that you can already integrate and it's already live on Ledger, it's live on Ambire, it's live on WalletConnect. So, we want to see more wallets integrate clear signing and this to become a real thing. What are the challenges for clear signing? Um the main bottleneck is actually the writing of descriptors, so it's very it's a manual process, as well as reviewing those descriptors is a quite manual process. So, this will take a lot

of time, but uh nice thing is that if we have a few hundred descriptors, we can already cover maybe 90 to 95% of ongoing transactions. So, there's a strong power law in play there here. And LLMs can help a lot. Um and in the future, what I imagine is instead of writing descriptors manually, we will have something like NatSpec plus plus. So, you can say, "Okay, like write these fields when you're writing a contract in the comments." And then it will give out the either the compiler or the frameworks can give out the descriptor JSON.

Uh but also we need to get projects to write descriptors and handling proxies is also not as straightforward, but we are working on solutions for that. So, what should you do? Uh what is the call to action? If you're a wallet developer, if you have a block explorer, please integrate ERC-7730. You can use our library, but also you can build it out on your own because yeah, if you want to don't if you don't want to have an external dependency, that's also fairly understandable. And you can reach us out anytime if you have any questions about this. Uh if you're an Ethereum app, please submit your descriptor to the registry.

And if you're a user, please demand it from your wallet and raise your voice and share it and give us feedback. So, thank you for listening and you can follow Sourceify here and visit clear signing and reach out if you have any questions through these channels. Thank you.