#DappCon22 : Day 2 - Human-Friendly Contract Interactions With Sourcify Verification, Kaan Uzdogan

Transcript

okay so next up we've got Ken ustogen from the ethereum foundation who works on the solsify project and he's going to tell us about human friendly contract interactions with sourceify verification let's welcome him on stage [Applause] so hello everyone my name is Khan I'll be talking about how we can enable human-friendly contract interactions today so I'll start with something um that we are all familiar with so just a normal day in web tree and this is

something a typical webview user see every day and it is this so every day you are greeted with these byte codes byte strings you have no idea what's going on like am I doing the right thing am I talking to the right contract what am I doing and this is just equal to saying just shut up and take my money I don't care what you're doing just I'll sign this whatever you say say to me and this is what we like to call YOLO signing so still a typical web free interaction is a YOLO signing nightmare they just give us things to sign and we just sign them so ideally what we want to have is from something on the left that machines can

read to something on the right that humans can read and understand and how do we do this there are several components several building blocks to this one of them is the source code and metadata availability we will walk through all of these the second thing is the perfect verification source code verification next there is the nutspec documentation of contracts and we also need most importantly wallet and block Explorer Integrations so first of all this whole thing is built on top of solidity contract metadata and who knows what solidity contract metadata is here maybe can I see some hands okay

a decent amount of people more than I expected but still not the majority but that's why I'm here so the metadata is the output of the compiler it was actually introduced in zero four seven quite a long time ago but it was not really picked up by the community and it's a Json file generated by the compiler which contains metadata but what does metadata mean it has the ABI the user doc which these two are concerned with how to interact with the contract and the next two is compilation information and source file info and these are about how to reproduce a contract compilation and the file looks like this it's just

it's a Json file as usual you have the language you have the output the compiler settings and additional information about source files we will dive into those shortly um and the next step is the source code verification so if you have been in the space for a while I actually don't need to explain why you should verify your contracts and why your contracts should be publicly available and transparent and auditable Etc that's something already we know but let's have a look how this is done actually and how the source fiber verification Works differently than the usual the common one let's say so the problem is here that machines understand bytecode they don't

understand the code we have written in natural language and the problem is here how do we make sure just a random code you see on GitHub or somewhere else is actually the contract that is running on the blockchain right that is I'm talking to and this is how it's done in a really high level so you have the source code you have the solidity files and you also have a compiler you have a compiler and it's settings such as optimizers or there are many settings on the compiler um and we feed them into a solid into the compiler the version that we have and we recompile it so the contract is already deployed we have these files

that we want to verify and we feed them into a compiler then the compiler gives us a byte code to byte code of the contract then we have the contract that we want to verify say at this address then we get the contract byte code and and then we compare these two bytecodes if they're they match then we say okay this source code is actually the original source code of this contract I mean there are more details to this but on a high level this works like this uh but the verifiers are actually leaving out some of the byte code so the common way we verify contracts today is not is leaving out some of the

information deployed on on on chain and they are specifically leaving out what we what I call aux data and aux data is this field at the end of the byte code so you might not be familiar with this as well but the solidity compiler by default appends some additional data to the to the contract byte code like apart from the functional part you have some additional information that comes in handy when we are verifying contracts and this is well defined in the uh docs you can check it out there um but so what we call partial match is the match without this information it's when

bytecode match and the perfect match is when bytecode Clock Plus the aux data match and the perfect verification with the aux data cryptographically guarantees that the whole compilation is exactly the same as deployed like even the commands variable names everything is the same as the original even even if we add a comments at the space at a DOT the perfect verification will break so here we can say aux data is more or less a compilation fingerprint added at the end of the bytecode and how does this work so again when you are compiling your contracts you have say these files the compiler

itself hashes these files it takes the inputs and gets a hash of these all files and we talked about the metadata file the hashes of the source files are embedded here in the metadata file as well as the other ones then we take the hash of the whole file in this case an ipfs hash by default and then this ipfs hash is embedded encoded here in this in this file in this uh appended data then if we when comparing bytecodes if these match we say it's a format or a perfect match

so let's see what happens when we make a difference when we change when we tweak a little when we make a little change in the contracts or in the compilation settings or in this case the contracts so let's say I added a line of comment in my code and now I have the my contract Dash diff now the hash changes obviously the hash and the metadata will change then this hash will change and when the hash of the metadata will change this field will be different and then when we are comparing this won't be a perfect match but this time it will only be a partial match so this is the way that is commonly done today in in the

ecosystem like on the etherscan these and this field is left out and what we have isn't completely partial matches in the ecosystem now and let's take a look what's inside this aux data so this green field when we decode this section it's actually cboard encoded and when we decode it it has the ipfs and solid version so again if we further decode them the solid compiler version in this case is zero eight one and the ipfs hash is as follows like this one is in HEX encoded this one is ipfs quoted and if you are more Curious and see want

to see this action we have a playground at playground.sourcify Dev and here we also have provided some example contracts that you can check and even if there's a contract that is deployed you can get the address and see how the aux data of this contract is working okay so we saw how we how we can verify but if you as a user want to verify your contract how can you do this so we have the sourceify UI you can in this UI provide us the source files plus the metadata of the contract then give us the address and the network the contract is deployed in then we can try verifying the contract and we also

have many networks not just ethereum networks I think right now close to 30 different networks so if you have an evm Network you can also have sourcify verification but we actually highly encourage you to run your own sourceify instance because the sourceify is a open source project and we don't want to be the only source of Truth and we highly encourage projects to run their own source defy instances instead of relying us uh we also have an API so you can programmatically use the sourceify API and this you can also find in docs documentation docs.sourcify Dev uh yeah we have several different API

endpoints for verification or as well as fetching contracts or getting the file trees then we also have some tooling we also have a heart attack plugin so it's called hard deploy and if you have deployed a contract using this plugin you can just say heartthat Network mainnet or in a network and sourcify and the plugin will verify for you we also have a remix plugin if you um deploy your contracts using remix then you can go to sourcify plugin select your contract give us the chain and the address

then the plugin will verify for you now we also recently have Foundry support So using these commands this using these commands you can also by changing the verifier verification provider you can also verify your contracts on sourcify we also have something called monitoring monitor which does automatic verification so what this does is actually the monitor listens to the blockchains at this at the moment we are listening to ethereum blockchains like the mainnet the test Nets as well as some roll ups and we this catches the contract

creation so whenever we find a contract creation we again look at the metadata hash and it tries to fetch it tries to fetch the metadata file from ipfs if it can then it will try to fetch the source files from ipfs then it auto tries to automatically compile and verify everything so that means if you publish your metadata and your source files then we verify for you so you don't even have to come to us and manually verify your contract we'll just listen to the blockchain and just verify it for you the only thing here is you have to publish I think in five minutes

or so so either deploy time or just right after deploying um you also have a contract repository where we have all these verified contracts we serve this over repo.sourcify Dev on HTTP as well as on ipfs um and we have this under an ipns that we update regularly so you can go to ipns reposource file and it is structured as so like contracts full match partial match then you can give the chain ID and the address of the contract this is the same structure in the repo source file type as well so there is one more piece in the puzzle

until we get to the human friendly contract interactions and that is uh what we saw here so I actually didn't speak much about the user documentation and devdoc and this is the documentation that is coming from the nuts pack when you so let's let's go actually so nuts fact is a specification and the solid documentation and it's the rich documentation for functions return variables and it's named ethereum natural language specification format so if you are familiar with JS talk it is similar to that and it has several

different fields that you can use as well as custom tags and if we look at a function in this example it sits on top of the function so in this case the swap owner function is our function then we have the developer documentation here then we have at the notice field we have the user documentation then we have the documentation for the parameters so where does it come Sandy so let's take this user documentation of this function so this is a swap owner function and it says it replaces the owner all the owner in the save with new owner so this is what your users users are going to see and the nut spec has this handy specification called Dynamic expression

so if you have these backticks and a variable name then you can take the variable names and fill them dynamically so if your if your function is called for example with these addresses the old owner this one new owner this one so you can dynamically show the users actually the whole addresses okay then we didn't not that spec and finally to get to the users to get to the end we need a wallets and block explorers and their integration so what can a wallet do when your users are talking to a contract you would get a byte code and fetch the metadata fetch the ipfs hash fix the metadators ipfs hash

then in the metadata as you recall we have the ABI and the nut spec and using those hopefully you can show users something more meaningful instead of the story the argument section you can decode with the API from the parameters of the function and if there is a nut spec well documented not spec then you can show the users what this actually does for example this would register the domain for one year but we this is not only the way not not the only way to human friendliness this is one approach we are taking a sourceify and it's worth mentioning the different text I think so there is also so the idea behind sourcify is using the

nutspack and the metadata the other approach is eip4430 and eip3224 um this the idea behind this is to have a describer function inside the contract so if you call for example the EIP describe function decoding will be done inside the contract and it will be returned to the user as well the nice thing about this is it can decode things like ens commit because we can't decode DNS commits as it's a hash that it commit that is committed but the information is also already inside the contract so it can decode things like this but obviously you need extra gas for the contract uh the second one is the EIP draft

recently by Dan Finley and here the idea is to approach the user at the first point of contact so whenever they use they have um they have an interaction you just tell give the user the information so this is backwards compatible and it's more flexible but this there is no verifying thing so it's not either in the contract or it's not hashed that we can verify and we can do better like there are many more ways for better ux like we can uh warn the users when there's a large amount we can one for large fees we can show the user how many times the contract is interacted with because a scam contract would be less used or we can say when it's all when it's deployed

because a scam contract would be more recent and importantly we can solve this if this is audited or by whom so there are many ways to do this and as a recap let's let's say technically sourceify is an open source automatic smart contract verification service it has a user interface it has a API we have different tooling to verify contracts manually we also have a public decentralized content other storage of verified contracts which is our repo and more generally we are a base lead and public good for other tools to build top built on top of also we are initiative to use more solidity metadata and nut spec and we

are an ongoing effort to improve smart contracts ux and safety and transparency so thank you and if there are any questions I would like to answer those [Applause] any questions so if the contract verification fails do you provide some meaningful errors about why it failed or is it just like that no didn't fail uh

depends like if it's failing because your file is missing we say that um usually I think when there's something that we can say from the compiler we forward this to the user but obviously that's something technical but yeah it's usually the case that it's very failed because a file is missing or we can't for example get the bytecode so we try to do that but not I can't say we do it all the time okay thank you is there any way to decentralize the admin rights like so that it's not in control of just a single Dev but

maybe a Dao the admin rights of the application the sourcify you mean um at the moment we are welcoming contributions uh but so far it's mostly the people working on the project that is developing I hope actually it evolves in that way so that we can actually decentralize this whole thing but at the moment it's mostly built by a bunch of people um I I think this is all really great work uh I was wondering maybe you have any ideas on why as you said these

standards the metadata hash and the ipfs and so on and so forth and then not spec they've been there for a very long time uh but they haven't got massive adoption from what it providers Etc I was wondering if you maybe know what the reasons might be or what we might do to change that yeah I mean it's a chicken and egg problem the less it's like the more it's used then the more people will get aware of it and it gets more used right and I think the problem like the bottleneck is here at the tooling developer tooling so etherscan has been and the partial verification has been the first Comer and that's the de facto standard right now and it's really difficult to change people's habits to how they do things

and we really need to make this more seamless and raise more awareness to do that um yeah getting people to understand what they sign is of course very important but you mentioned like showing variable names that's something that can easily be abused to try to actually trick people rather than being you know set them signing something binary which they don't understand they can actually be deliberately misled by you know falsely named variables which is what would happen do you have any thoughts about how to you know not just show names that actually tell people what the contract does is there's that kind of a level to this I mean obviously the

Assumption we are making is the contract is benign so we actually trust we assume we trust the contract author and if the contract author the uh documents the contract well then we can show actually the correct messages and good variable names Etc but as I said that's why we need the expanded the other things we need the audits we need the other information that can users can inform themselves better but at the end of the day the Anchor Point is the developer whatever developer says besides okay what you say is this okay we still have the time for one or two questions how can projects integrate sourcify um we have an API so we have the

documentation of the API uh obviously you can check that uh I'm also like we can also just approach us we have a public chat or just find me find us on Twitter maybe I'll go to this slide yeah and you'll find us on Twitter just approach us we are happy to help help you guys [Applause]