Human-friendly contract interactions with Sourcify verification

Transcript

all right hello everyone um my name is khan and i'm working at the ethereum foundation and today i will be talking about sourcify a project where we verify contracts and which our aim is to enable more human-friendly contract interactions so just a normal day in webtree i guess you guys have all experienced this like what is this what am i doing like am i doing the right thing am i signing the right transaction basically what i'm doing is oop this just like saying them to shut up and take my money because you have no idea what's going on so a typical web 3 interaction today is

still like five years six years ahead still it's a yolo signing signature as we want to call it like yolo signing like you just sign and hope for the best you have no idea what's going on so at the end what we want to have is something like this on the right side instead of non-human readable hex strings or bytes to have more meaningful messages for the user and what can you do to achieve this this is not an easy problem this has like several layers if we break it down you can there are things you can do as a smart contract developer and there are things you can do as a wall developer so let's dive in what can you do as a smart contract developer

first you can use nut spec documentation if you are familiar with nut spec it is a part of the salty specification and it's a rich documentation for functions return variables and more it is called ethereum natural language specification format if you are familiar with jstoc it is similar to really syntactically really similar to that so let's go with an example i think it's more illustrative so you have the function [Music] documentation over the function declaration so you have the developer documentation for instance this function swap owner this explains the developers what it

does the notice field which is the user documentation the important part for your users and you have descriptions of the parameters and the nice thing nutspec also provides is you can dynamically fill the parameters so if you have a documentation like this replaces the owner all owner in the safe with new owner then you can take these and you can actually show something like this fill in the addresses dynamically even better you can actually maybe even show users some ens addresses so this is even already a step forward

in this okay but you have the user doctor where is it like how do you how do you find it where you can get the user documentation uh it is in the salty contract metadata uh does anyone know what contract metadata is okay couple people good that's that's good because the problem is it was introduced in 2016 in zero four seven but it was not really picked up by the community um it is a json file generated by the solidity compiler which has i mean metadata but let's see what it has it has the api user documentation dev documentation

compilation information and source file information if you break this if we group this the first two is concerned with how to interact with the contract and the second two is about how to reproduce a contract compilation so the file looks like this you have the output settings sources and you can find the user doc and dev doc in these fields yeah for example for swap owner function you can see the documentation there okay you found it but where's the metadata where do you find the metadata itself so if you are using solidity compiler cli you can

pass the metadata flag and it will output the metadata probably you're using a framework then if you're using truffle in the output of the contract you can see the metadata entry in the json and if you are using hard hat starting with 0 to a now you have the metadata of all files included by default if you are if you are not using a later version than that you have to manually enable the output also you can find the metadata somewhere else there is a specific special field at the end of the contract byte code

if you are probably you haven't heard about this um and the ipfs hash of this metadata file is encoded and appended to the bytecode of the contract when compiled so this field you're seeing contains actually the metadata's ipfs hash which you can retrieve the file via ipfs and the metadata hash actually acts as a fingerprint of the compilation so it is like a fingerprint.digest of what you have done and all the files on all the settings you have and this enables us to verify the compilation we'll see that

and this also means that if you publish or pin the contracts metadata file anyone can access it through its bytecode so you can fetch the bytecode get the metadata hash from ipfs decode the ipfs hash and you can fetch it from ipfs and to see this in action we also actually built a tool called playground here you can actually see how this decoding and encoding is done really easily and there are also some example contracts that you can play around okay so we did well we used nut spec now the

second part is source code verification but let's dive in what source of code verification is i think i don't have to explain why it's important to see the source code of your files of your of your contract but let's see how it is done and it is actually the green check mark so you see the contract is with a green check mark and you're happy right like this is what you expect on etherscan this is when you're happy this is what it looks like but yeah how do we know actually that a random random code on github is is is corresponding to this contract so we see it in etherscan we know and we trust it

to scan that this is a code but like how do we know this random contract is not is actually the contract of this so let's see how the source code verification is done so let's say you have three files of your contract and you input you have some compilation settings you have the version you have the optimizer settings etc and actually this compilation settings is what we mentioned about metadata so this is where the these two information comes in handy because you have all the information for the compilation so what we do is we feed these source files our code and compilation settings into a compiler

then it gives us a byte code the code of the contract then we fetch the contract from the address from the blockchain and this gives us another bytecode and then we'll see if these code actually match i mean obviously this is a simplified version of how it's done but the basic idea is this if these match if these two match we know that this is actually the source code of the contract so we have actually two types of patches we have partial matches when byte codes match and in sourcify we have perfect matches where byte calls byte code plus the metadata match what do we what do i mean

by that remember i mentioned the bytecode at the end of the contract byte the ipfs hash at the end of the bytecode this is what it's referring to so if you match until the green field it's a partial match this is what you see out in the field like in e3 scan or in other services they usually only match until the ipfs hash or the other data but we also have perfect matches that completely matches the contract yeah and as i said this is a compilation fingerprint so if the fingerprints of the compilations match that means is exactly the same 100 the same thing it even cryptographically guarantees

that the files you see the source code the solidity files you see is byte by byte the same as when it's deployed so even comments variable names not nothing changes it's exactly the same out of the kitchen of the developer um and let's see how this is done really shortly so let's say i change my one of my contracts i have oh um sorry so this is how it's done so it's hashed the you have the source files that are hashed by the compiler and the hashes of these source files are also embedded inside the metadata so for every source code you also have

their hashes embedded in the metadata file then you take the hash of this whole file and you encode it at that special field and if they match it's a full match so what happens when you change something if you for example we have now the contractif we change the variable name command anything or even a space now the hash changes of course the hash and the metadata changes and the hash of the metadata file changes and consequently this field will change and we won't be getting a match this will be this time a partial match not a perfect match

so we know these contracts are functionally the same but some things might have changed they there might be compiler settings or source code that is changed okay so we know how it's done but how do i verify my contracts if i had a contract if i wrote a contract and deployed it how do i verify it we have a ui that you can use to manually verify contracts so you just like drop down the files with the metadata then you just give us the address and the chain id the chain you are your contract is at and we verify it for you we have also an api that you can use it's a public open api

for now um [Music] and you can see the other we also have other endpoints that you can make use of such as like exploring the files and chains you can check out the docs for more information uh we also have some plugins and extensions there's one hardhead plugin [Music] and where you can in this you can just put the network name and just give the command sourcify and it will verify your deployed contracts you also have a remix plugin when you deploy when you compile a contract with remix or and deploy it you can

use the source of i plugin to verify contracts and we also have automatic verification what we call as the monitor so what it does is listens to the blockchains currently we listen to ethereum mainnet and testnets only and we catch the contract creations then it tries to fetch the metadata from the ipfs ipfs hash i mentioned and it tries to automatically compile and verify the contracts so that means actually you don't even have to go and verify your contract you can just publish your metadata and source files on ipfs and we will verify for you as long as you publicly publish your

metadata plus source files we verify it for you just for now only the ethereum mainnet and test nets also you have to uh have these files published around the time when you deploy the contract so like we have kind of a buffer log for five or ten minutes uh but yeah it should be published deploy time uh right now we have a contract repository where we both serve which one which we both serve over http and ipfs it is in repo dot sourcify dev we also have an ipns for the root of the contract repo we update it regularly and you can access the files over here or you can

just go to our website and just click on the contract repo in the footer okay the second step the second part of the problem what can you do as a wallet developer so you have done your job as a smart contract developer you've been a good developer so what can you do as a wallet developer so remember we talked about the second part now it's involving the first part of the information in the metadata file so these were these were the information or fields found in the metadata file and now we are talking about the first two which tells us how to interact with the contract as a wallet developer what you can do is to show the users the user dock

and also decode the api of the contract on contract interactions so what you do is so you get the metadata from sourcify right actually no because you can get it through the contract byte code already and the contract method is already at the end of my contract bytecode so you can fetch the bytecode directly and decode the ipfs hash and fetch the metadata file yourself this also gives you the nice properties of content addressing so you exactly know the file you received is actually the file itself because it is

addressed by its own hash finally you can decode the api the parameters of the function in a human readable way and also populate the nut spec comments for the function and you can even maybe later let users see vf source and source file on ipfs hashes so because they are already published and at the end of the day hopefully instead of something on instead of a thing on the left you have a more human friendly transaction on the right side um i would like to also mention other efforts in this direction

um because this is a really big issue in the community and in the indie ecosystem and there are there's not a silver bullet for this like there are many approaches which have advantages and disadvantages to approach to to arrive at human readable contract interactions so one is sourcify which we talk about and the idea behind sourcify is showing human readable descriptions via nut spec and comments found in the metadata this is one way and how we do this there is also there are two eips from richard moore and nick johnson i think it's they are around one year old

i recently come across those and the idea there is to have a separate function inside the contract when you call the contract which can be named as eip xx describe you will be calling this function and the function the contract itself will decode and return you something human readable and it will just delegate the uh call data to the respective function um it can the advantage is that you can decode things like any ens commit because normally when you're for example committing a hash the it doesn't really help to decode the hash

uh when you're calling the contract it doesn't give you any information but if you add this inside the contract you can actually give the breakdown the user what's happening and show them but the trade-off here is obviously you have to pay inside your contract for this as extra data and the there's also a new eip proposal from dan finley and there the idea is that the first point of contract the first player contact with the contract proposes metadata to the wallet so for example you visit app.uniswap.org then unisov.org gives you the metadata

of the contract which can contain the api and method describers and then you will save this inside your wallet and every time next time you interact with this contract you will have these descriptors instead of a hash byte string the nice thing about this approach is it is backwards compatible and it's flexible uh but it's not bound to contract itself what i mean is it is an external thing outside contract so it's not it's not like inside the contract as in the previous eip or it's not in the contract bytecode or metadata as in our case but i really find this a nice idea and because i think backwards backward

compatibility is a big issue in other cases plus there are a lot of things actually we can do to improve ux there is so much room for improvement i mean you can decode and show contract calls in sourcify you can warn the user if they never interact with this address you can say if it's verified you can block if it's a scam address you can vote for large amounts large fees also you can show the user how many times this contract was interacted with when was this contract deployed because a scammer contract would probably be more recent and it's in a legit contract will have many interactions

um is this contract audited and by whom so there are actually a lot of things that we can show the users for an improved experience but we're still here okay let's just recap what is sourcify technically we are an open source automatic smart contract verification service that's a mouthful sentence so it's a monitor we have a user interface a ui and an api and two links to verify contracts and we also have a public decentralized content addressed storage of verified contracts on ipfs and generally it's a base layer and public good for other tools to build on top of and also an initiative to foster the use

of solidity contract metadata nut spec and full verification or perfect verification and it's a ongoing effort to improve smart contracts ux safety and transparency so thank you for listening and you can reach us out here you can follow us on twitter and we also have a matrix chat we don't use guitar that much anymore we have a matrix chat where you have if you have any questions or want to ask something just reach us out thank you [Applause] are there any questions thank you for the presentation was great

i have a question regarding the ipfs so if i understand correctly as a developer so you write your code you compile then you have to deploy it on ipfs get the ipfs hash add it on this byte code at the right place no the solidity compiler does it already because the hash is a deterministic thing the byte this compiler already has this functionality of adding this automatically unless you tell it explicitly not to do that okay so it's a feature of the compilers to deploy on ipfs not to deploy but you hash it and append it but deploying or publishing is up to you of course you are the contract developer we encourage you to do so and it's actually a really

pain point that we should do this at deploy time otherwise people won't do that but it's up to the contract developer to do that or not okay thank you other questions hi uh i was wondering about legally binding smart contracts so you want the make sure you have a message in the metadata that you want to appear on the wallet so the person approving the transaction knows that this is something legal that they're doing what do you what do you mean by legality

uh that it could be enforced in law and a court so it's like bridging so it's a sort of it's a kind of extension of of not yolo signing yeah so i was thinking you could do something like a custom netspec of law something like that i was going to say that i think naspec is extendable so i think it's something it's actually a really good idea i've never thought about this and that spec then can be extendable to at legal for example then wallets will be required to show this for example and yeah but then on the other side it's a i guess it's a ui problem on the wallets to show something exactly like the

problem here is the data is already here we have a lot of verified contracts i mean not still we have a long way to go but we already have lots of contracts that are verified and some of them documented but wallers are not showing it at the moment so so it's up to the wallets that to implement this approach of improved ui as i show as i've shown there are other ways to do that as well so this is like up to the wallets and i think there's a lot of coordination needed here amongst wallets thanks anyone else last question

okay thanks everyone