Ethereum Foundation DevCon 6 - Developer Infrastructure Track, 12 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Human-Friendly Contract Interactions by Kaan | Devcon Bogotá

Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/human-friendly-contract-interactions/

Web3 users often sign transactions without knowing what they are doing. How can we let them take more informed decisions? Contracts verified on Sourcify (https://sourcify.dev) can be presented with human-friendly information via the ABI and the NatSpec documentation

The talk will explain how it's made possible with "Solidity contract metadata" and how Sourcify's "full verification" works. We'll also touch upon alternative approaches to how to display human-readable tx information to the users

Speaker(s): Kaan
Skill level: Intermediate
Track: Developer Infrastructure
Keywords: sourcify,contract verification,contract metadata

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

A

A

Foundation on the project sourcify and today, I will be talking about how we can enable more human friendly contract interactions using source5 verification. I'll start with uh showing you guys something you're all familiar with I would say if you're a web 3 user for a while um just a normal day in webtree and I guess this will. This will be like something you see every day and you see every day in webg. You see things like this and you basically have no idea you're, not a machine. You don't understand.

A

What's going on you're like trying to make sense of it am I doing the right thing am I talking to the right contract. Is this doing? Actually what I want to do and basically what you do is telling them to like shut up and take your money like you have no idea. What's going on you're, just giving out your money- and we say today a typical web pre-interaction is still a yellow signing nightmare. What we call Yellow signing it's just they give you things to sign and you just like sign and hope for the best.

A

So, at the end of the day, what we want to have is more to do something on the right hand, side from left hand, side to right hand, side so I know this has changed actually for many wallets, so many wallets actually started to decode things like metamask, using truffle um and decoding API, but still we have a long way to go and we have a lot of things that we can improve the human, the the user experience. So what can you do to achieve this?

A

There are two sides of of this coin, so you can. There are things you can do as the wallet developer, and there are things you can do as the um as the smart contract developer. So, let's dive in what you can do as a smart contract developer.

A

The first thing you can do is using a nutspec documentation and as well as doing the source code, verification on sourceify. So what is not spec documentation, not spec documentation is what is called ethereum natural language specification format. It's actually part of the solidity spec, and probably you have seen this if you have seen a contract before this is how it looks like you put the comment, the documentation above the function, and you have the developer documentation. You have the user documentation with the at notice field and you have the documentation for the parameters.

A

uh So another nice thing about nutspec is it has the specification for dynamic expression, so the field you see here, the old owner and new owner parameters in back quotes these actually can be filled dynamically with the value they are being called. So this replaces the owner, the address gets filled can get filled and the new one can also get filled in in the parameters.

A

Okay, so you you did you did your job, you made the user documentation developer documentation. So where do you find it, then why can I can find it? It is uh in the solid contract metadata so who actually knows what solidity contract metadata? Is anyone just a few people cool? That's why I'm here um so contract metadata is actually something introduced early on in 2016 in the earlier versions, but it was actually not really picked up by the community.

A

It is actually a Json file uh generated by the compiler itself and it contains the metadata okay. But what is metadata? It has the ABI, the user talk, Dev doc, as well as compilation info and source file info, so the first two.

A

It feels actually is concerned with how to interact with the contract so how to interface with the contract and then the second two is about how to reproduce a contract compilation. So it's uh embed the information during the contract compilation so that can be reproduced.

A

The file looks like this: it's a Json file, it has a set, it says: compiler, language, settings, source file, information and here, for example, in the output. You can see the user Doc and Dev Dock, and if we open that field those fields again, you have the methods and with the methods for each method, you have the notice field or the dev doc field. If there's a devdoc and you have the for example. In this case, the replaces the new owner with the old owner with new owner.

A

The comment we have seen before uh you can get the con the metadata with the metadata flag on the compiler itself, uh on with the Frameworks, you can find it inside the build files, so travel, for example, put this inside the build contracts, the contract name Json under that you can find the metadata fields and the the metadata is there hard hat also started to Output metadata for inside the build file. Again, you can find the metadata here, yeah yeah.

A

You can also find the traces of the metadata in inside the bytecode, so the bytecode- this is an example contract byte code and the bytecode has actually a special field at the end of the bytecode. It is appended by the compiler again a question who knows what this is: okay, again just a few people and again. What's that's? Why I'm here so this field?

A

uh The compiler actually takes the ipfs hash of the metadata file, the file we saw and it encodes the ipfs hash of that file here, alongside some other information, maybe I'll pull this as well. Alongside some other information and yeah, you can see how this works in our playground, playground, Source, Phi Dev. We basically show how the encoding is done, what the encoding contains, and we also try to metadata from ipfs it's already there. So it's a nice tool.

A

There are some example contracts you can click on or you can just provide us with the contract address or just paste the contract bytecode, and we will try to visualize how this thing works.

A

All right, let's, let's go down to the second thing: source code, verification on source5, but before what is source code verification, so this is for all of you know. This is like you probably have seen this. If you have seen a contract before and you see a green check mark you're happy. You know the contract right, um okay, but how does this work?

A

um Maybe before that like? It is uh the reason we need why we need source code. Verification is that the contracts actually live on blockchain as byte codes like they are. We write the humans write code in human language, but the machines really didn't bite, so the code gets compiled and deployed to the blockchain, and this information is lost in the process.

A

So we need to somehow make sure uh just a random code, you see is actually the same: the code behind the contract, so that's the process of knowing this course is actually the one that is running the contract is source code verification. So how does this work? uh You have the contracts, solidity files. In this case you have a Target contract.

A

You also have compilation settings like the version, the optimizer settings, the other things and we feed those into a compiler and we recompile the contract and remember this is actually when the second part of the Meta Meta data information comes in handy. So we use this compilation info to reproduce the compilation of the contract again.

A

So we feed this into the compiler and the compiler gives us a byte code and we also have the contract that we want to verify. So we get the code of the contract from the blockchain. This will give us a bytecode, then we'll see if these actually match and in source5 you also have two types of matches. We have the partial match when bytecode match and we have the full match when both the byte code and the metadata field field match so in right.

A

Now, today, when you are verifying on YouTube scan or any other verifier, they actually ignore this field, like they don't make use of this field. They just trim it out and actually that there have been cases that this was um exploited. So it wasn't a serious thing, but this could this wasn't really doing was being done properly, but yeah with the full match. You have a complete match of the bytecode, uh and here the metadata actually acts as a compilation fingerprint.

A

So if you match the metadata as well, the compilation is exactly the same as the original or as when the contract was deployed so and the full matches actually cryptographically guarantee that the whole compilation is exactly the same, including the solidity files comments, spaces variable names, anything like you, even if you change a space, a variable name, it will break the match. So how does this work?

A

Let's see how this actually works again, when you are compiling your contract, the compiler takes the hash of each file each each solidity file than the hashes of these files are actually embedded inside the metadata file or the the metadata file that we saw as well as the other sources, not just one then, as said, the compiler takes the ipfs hash of this whole file, and then this ipfs hash is embedded at the end of the bytecode, and then we see if these match, if it's say full match it's a match.

A

It's a full match if they match and let's see what happens when you change something. When you make a slight change change the space change, your variable name any comments, so we have it my contract diff this time, so the hash of the file will change.

A

Then the hash inside the metadata will change and in in turn, the hash of the metadata file itself will change. So this field will be different this time, and that means this will not be a full match, and but this will be a partial match. Assuming you didn't make a change that will change the functionality of the contract, just a comment or variable okay, but then how to verify so you can use the source file UI. You can give us the source code and the metadata file.

A

We need the metadata file to be able to verify either from your computer or etherscan remote GitHub. However, you like, then you give us the contract address contract chain. We try to wait file, you can use the API. We have an endpoint and other several API endpoints as well. You can check them out in docs.ify Dev. uh We have some detailed talks about this and we also have the tooling.

A

So if you are using hard hat, there's a hard hat deploy plugin and with the plugin when, after you deploy your contract, you can just pass the network and then say sourcify and use the verify your contract. We have the remix plugin. If you are using remix, you can provide the contract address the chain. When we will verify. We recently have a Foundry support, so using Foundry.

A

You can also easily verify your contracts and we also have some automatic verification, so what we call monitor, so we have a monitor running that is listening on on several chains. We are right now listening to ethereum main net test Nets, as well as some Roll-Ups out as far as remember so the monitor, what it does it catches, contract creations and then, when it finds a contract creation, it will fetch the metadata.

A

As you remember, it's like ipfs hash is over there, so it will get the ipfs try to fetch it from ipfs and also the metadata file has the source hashes source, ipfs hashes. It will try to get the source files from ipfs as well. If it finds them, then it will automatically compile and try to verify the contract.

A

So that means actually the Second Step here the source code, verification on Source Phi has become publishing your metadata, so you don't even have to take the extra step and go to sourcify and verify your contract. If you just publish it and pin it on ipfs, we'll just do it for you yeah.

A

um So we have this contract. Repo of all verified contracts, it is served over HTTP and ipfs under report.sourceify Dev, um so we pin the verified, Source, verified, contract source file and the metadata so that they will be accessible by decoding the bytecode. So here remember there is the ipfs high here and anyone. If it's verified on source5, we will be pinning it and there are other people uh pinning our repo as well, so you they will be accessible by their ipfs hash and yeah. We also served repo under an ipns name.

A

So you can also see the contract repo and see the files access all of them download the whole repo. If you want so yeah uh okay, so we have seen what you can do as a smart contract Dev, let's see what you can do as a wallet developer, so maybe a short recap what we are trying to do again. So we have a contract call. We are talking to a contract and instead of showing instead of this byte string, we want to show something more user friendly.

A

So one thing to do is obviously to decode this call the despite string call via the API Json. You can show the function name, the variable names Etc and then you want to show some human readable description of what the user is trying to do. If you have documented your code. Well, um so what you, what you can do as a vault developer, you go to sourcify your report.sourcify Dev, you get a chain ID the code track and the metadata.

A

No, please don't do that. You don't come to us because it's already in ipfs- and it is the neat thing- is it- is content content address. So you know the file you're getting is actually the right file, so you just your wallet. Just gets the byte code of the contract decodes the ipfs hash here at the end of the bytecode fetched metadata, that we pinned it for you and the metadata file has, as we have seen, the API and the documentation yeah.

A

This is where the first two Fields come in handy how to interface with the contract and then decode the API and populate the not spec comments of the track. So hopefully, at the end of today, we will have something more on the right rather than something on the left.

A

But source file is actually not the only way for human friendliness. The idea behind sourceify is to have human, readable descriptions via nut spec comments found in the metadata. There are other ways to achieve this as well, so one is, for example, these two eips by Richard, Moore and Nick Johnson. So the idea there is to have an extra function, name, an extra function, a described function so to say that will return the user something unreadable. So it can be anything any custom.

A

Any custom string and uh the contract will return the string to the user and continue executing the executing the actual function. And here the nice thing is it can decode things like ens commit that is normally uh like. It's it's a hash commit and it doesn't have a meaning to the user, but you can add actually some more custom strings, custom messages to the user that they can make sense of it. But hopefully this discuss extra gas. uh The other one is the other MP proposal by Dan Finley, the there.

A

The idea is uh to give the user this information at the first point of contact so say you want to do an exchange for the first time in at uniswap. Uniswap app.uniswap will give you the contract metadata, your Vault will store it and then you, your wallet, will have the API and the describers so that it can show you some something more human readable. uh The advantage here is it's backwards compatible.

A

So we don't need to change change the contracts right now, most of the contracts don't have any documentation or anything and or they are not actually documented, with the human friendliness in mind, so this will be backwards compatible, but at the same time this means it's mutable. So it's like it can be changed. So it's a trade-off but yeah and also there are many ways to better ux. So we can actually show the users many things. So is it you can decode the contract. Call you can warn if the user has never been talked to.

A

This contract uh show the user if the contract is verified uh block, if it's a scam address many things as well as other types of things, such as how many times this contract was interacted with. When was it deployed because a scam, the contract would be like likely more recent and less interacted with.

A

um Is this contract audited and is it by audit by whom? So there are actually many ways we can do better. So, as I recap, what is sourceify technically, it is an open source, automatic, smart contract verification service. Our monitor it's a user interface, server, API and tooling to verify contracts manually.

A

It's a public, decentralized content, address, storage of verified contracts, our repo and, more generally, we are a base layer and a public good for other tools to build on top of us, and we are an initiative to Foster the use of solidity, metadata, nut, spec and full verification, and as well as we are an ongoing effort to improve smart contracts, UI safety and transparency.

A

So thank you for listening. uh If you have, if you're interested you can find us in Twitter, join our Matrix chats, our code is also at here. It's your terms. Sourcify visit our website and yeah I'll be happy to take any other questions. If you have thank you, I'm.

B

Wondering how well these Solutions can handle translation and internationalizations to provide descriptions in multiple.

A

Languages, yeah, uh that's also one consideration there. uh We have the idea of maybe having a custom, not spec field for translations, and in that field you can actually link to another translations file, so that would be inside the metadata, for example the translations file, and that will be another ipfs hash so that you can fetch it and you can have other languages and translations are.

C

You thinking about ux regression, testing, automation. Somehow, sorry, um are you thinking about end-to-end regression, testing automation with sourceify, so being able to include um the depths in the whole cycle of testing? How things look like like what can dabs do to make things easier for end users to.

A

So having I'm sorry is it having the sourceify at the whole development pipeline you mean or I'm not sure if I get customers.

C

Correct um like currently in order for a developer to somehow test the end-to-end user experience, it's nearly impossible to include the web app and the wallet, interaction and the onshine interactions.

A

I'm not sure if I get the question correctly, but we are more like a um well. So we're not we just say people here it is here are the tools here? Are the files just please make use of it? So we don't actively get involved in the ux contract interactions or that's not not in your complete pipeline. I would say for.

D

User protection am I right in thinking that the reputational and statistical characteristics you mentioned are really important.

A

um Who's talking.

D

Right here, because I'm just thinking and correct me if I'm wrong but I'm malicious deployer, could create a malicious contract. This uh describe it in a malicious way, with Matt Speck and then yeah take advantage of the user.

A

Yeah um I mean obviously we have the assumption that the contract deployer is uh nine, it's not malicious, so it's uh we verify the content of the uh the contract, but there are, as I said, there are other ways to do that, for example, audits, scam, lists. So this is another aspect, so we have like this neutral eye to what's inside the contract and it's up to the community and the other types of methods to actually see it's, not a malicious contract.

B

uh Thanks for the talk so question I had was for contract coverage like what is it like? Is it limited to what's verified on ether, scan or um like like yeah, in terms of like abis? That might not be fully complete, like what is sourceify fully covered.

A

What what do you mean by cover in.

B

Terms of like contract coverage like if someone deploys a new contract, it's not verified on either scan then do you guys still provide the human readable aspect or.

A

Yes, I mean source5 is a completely different thing than eaterscan. If.

B

A

Scan is both a verification service and a block Explorer, but source file is not a block Explorer. We just we are just a contract, verification service and I would say we have different contract sets than it can, so you can actually import, but it's a different contract set. So.

B

Even for like new contracts, you guys instantly get into the pipeline verify and then make it readable. Yeah.

A

Exactly gotcha and any contract that is deployed, we can just verify okay.

B

A

Even also different chains like we don't, we have I think like 30, something evm chains right now, so you can even verify contracts on other chains, but at the end of the day, actually we we have support for different chains, but we actually want everyone at some point to run their own source file for their own chains. Cool.

B

Okay, thank you.

A

Maybe last question.

E

um Is it in the scope of sortsify to like maintain reputation of the commands or maybe even validate, the comments actually reflect the code.

A

Like sound here is not so good.

E

uh Is it in the scope of source, if I, to uh maintain like a reputation scope for the comments or to validate? If the comments reflect the code, the.

A

Application commits you say: yeah.

E

A

Comments um I mean no, we just as I said we are a tool to achieve this and, at the end of the day, the developers have to document and comment their code. So they have to keep in mind that this will. This might be a user-facing method and properly document. It.

E

A

um I think we're out of time uh just find me after the talk or also you can yeah find sourceify and reach us out there. Thank you.