Source Verifier Article

# Source Verifier Article ## Comments Franzi Storyline: - you don't know the dev, so how can you trust his smart contracts / his code? how do you know it is doing what it's supposed to be doing and not something else (possibly even something malicious)/misusing your funds? - YOLO signing = signing random hex strings e.g. via MetaMask - informed decisions, but how? maybe via the source verifier !!! doesn't make sense, how does source verify help with signing random hex string in MM / logical jump? - what does the source verifier do (Listens for the deployment of smart contracts, Checks to see if their metadata and source code is published on IPFS or Swarm, Re-compiles the code, checks that it is the same as the deployed code, Stores contracts on IPFS) - Why does the source verify help devs? They can also read and analyze code that is open source in any repo on Github, can't they? I don't get that argument - How does it work in more detail - Why would I want to store anything locally? or who is storing that info locally, unclear - Who's the target group of the article? Switches between "it's useful for devs" and "easy explanations"? - Why would I want to verify anything for myself? Sounds complicated - Now bytecode metadata gets introduced? - What are the benefits of source verification? - "it is now possible that a wallet can check if the contract has been verified" what should that mean? what is verified? - in the end again switch to the dev side: how do I use this weird changes of perspective throughout the doc, I'd suggest the following logical flow: - **Too long, didn't read**: After writing the article, we put a 2-3 sentence long summary of the essential points here! - **1.PROBLEM** - From a user perspective: What is wrong with the current situation? Why is source verificaiton needed? (**this is the most important aspect**, if there's no good reason we can save us the time to work on this); IMO the link between YOLO signing and source verification is **not** clear; source verification doesn't lead to "human readable" data in MM transactions, does it? - **2.SOLUTION** Is there a solution to the problem? - What is the solution - How does it work? - Who needs to act in order to make it work? (dev side) - How can devs use this? (go from high level to deeper with each step) - **3.CLOSING THOUGHTS** Takeaways? What should I do now? Future outlook, thoughts on how this can improve UX further (i.e. in the frist iteration it will only do XYZ but one could imagine that moving forward it could also do...) ## Original post by Edi You don’t know me. So you don’t know if I’m a scoundrelous grifter or an upstanding mensch. And if you want to use my Dapp —and it asks you to sign something like this: You Only Live Once (YOLO) — confirm at your peril You’ll have no idea what you are agreeing to — but You Only Live Once! And if you go ahead and sign you are YOLO Signing. But what choice do you have in this example? I’m forcing you to take a leap of faith. We need to give our users more information, so they can make informed decisions. To wit, if I verify my code — which is to say that I publish my Dapp’s source code and prove that the compiled code is derived from this source, then at least you understand that I am being transparent and that this code can be audited. One of the most important pieces here is the natspec specification that can be found in metadata, which helps you understand the source code without actually having to read it. It’s rich documentation written in Ethereum Natural Language Specification Format which describes functions, return values etc. in a friendly way. More on natspec. This process is called Source Verification. Source Verifier is a Source Verification project on the Ethereum blockchain that: Listens for the deployment of smart contracts. Checks to see if their metadata and source code is published on IPFS or Swarm. Re-compiles the code. Checks that it is the same as the deployed code. Stores contracts on IPFS But Source Verification is more than just a hedge against malicious software. Blockchain smart contracts are like pottery — they may break — but they will be around forever (or at least a portion of forever). A verified contract allows future devs the opportunity to read the code, to learn from the code, to extend the code, and to troubleshoot the code. It can be the difference between unused unintelligible abandoned mess and a smart contract that has longevity. Let’s dive into Source Verifier Demystifying Source Verify Source verification flow Source Verification’s first step is a monitoring service that checks for new blocks in an Ethereum blockchain (currently it is monitoring mainnet, rinkeby, & goerli). It then takes the transactions and bytecode metadata from those transactions and tries to find any links in there that could link to either IPFS or Swarm for actual contract and metadata files. It then tries to fetch them. If that was successful all those files are delegated to verification service. After verification receives all the files it tries to verify everything. Only then if everything went properly and recompiled metadata and code are a match all of it gets stored to the local file system. So to recap, we’ve managed to get the files from blockchain and ipfs/swarm, managed to verify them, and store them locally. We can also access them via https. Okay — but isn’t it still centralized? How do I know I can trust it? Verify, don’t trust! Luckily there is no need to trust us! All the files that were indexed and stored locally are then pinned by the pinning service on ipfs.komputing.org and anybody can access them. What then needs to be done is verify specific/all files that are of interest at your own machine/environment and that way see if they are actually a match. This way you don’t trust us, but you verify yourself! How ipfs, ipns, ens etc. works is out of scope for this article and a more in-depth explanation can be found in the links. So much new stuff, let’s explain some of them Wow! Wait a second, there are a lot of steps in there and some unknown words… What actually is bytecode metadata? Bytecode metadata is a feature of solidity from version 0.4.7 (released on 2016–12–15). CBOR Ah, nice! But all this flow is happening on your servers, right? Yes, that is why we publish all data to ipfs and encourage anyone to take that data and run local recompilations on their own machines to verify it and not to trust us! Sure, all this seems nice but what we actually get by this? From an end user’s perspective — it is now possible that a wallet can check if the contract has been verified. OK — so they may not be auditing the code but at least the code is public. And if the code has not been verified, the wallet could display a warning. Denizens of this world of digital currency & Dapps should understand that interacting with unverified contracts is dangerous. Source Verify — Remix plugin Remix IDE now has a Source Verify plugin allowing devs to pull in verified contracts and to easily publish the metadata with their contracts at deployment. For testing this inside of Remix you will need to activate 3 plugins: Solidity compiler Deploy & run transactions Source Verifier Compiling code As with any other contract, the first thing is to compile a code. After that, we deploy the code, in this example via metamask to rinkeby (you can also choose any other testnet or mainnet) and activate checkbox PUBLISH TO IPFS. That is important as our monitor service will automatically find it, recompile it and save it to the repository. See the image below. Then copy the address of the deployed contract so that we can verify it. In the Source Verifier there are 2 sections. The top one is for verifying contracts and metadata. The bottom section is for fetching a contract by its address. The thing to note here is that using the verifier makes sense only if we didn’t publish metadata and contract to ipfs but want to do it manually. The second option will be used a lot more. On the below picture you can see that we have two files in the verification (top) part of the plugin. Those files were generated by the compiler and have automatically been fetched and saved in the plugin so you can verify them by just inputting an address and choosing the network. Just a note here: if you used deploy & run plugin from Remix, chain will be the one you choose there. If you want to use this as a standalone plugin so that you can choose a local network you can, but you need on deploy & run transactions choose Javascript VM and then chain from the dropdown will be used. If you just want to fetch code and save it locally in Remix without verifying it you can do in the lower part of the plugin, in the contract fetcher. If you’ve used UPLOAD TO IPFS checkbox you should be able to get the message “Contract successfully fetched!” and the file will be opened in your Remix browser. — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — Note: plugin is in the beta version so some difficulties can occur. Please free to open an issue on GitHub if you encounter one or let us know on gitter chat. This plugin was made possible by a joint effort from solidity and remix teams.