#HowToBUIDL (4/n) Series — Verifying your Smart Contract Code

When you deploy code to the public, open, global censorship-resistant Ethereum Blockchain, you are expecting that the functions and services that your Smart Contract provides will be used by participants all over the world. Therefore, it is important to be a good steward of the blockchain community and help the users of your contract be able to trust that the code will do what you claim it will do.

Auditors and critics play an important role in the Blockchain world to ensure the code works as intended.

We’ll be using the project referenced in the #HowToBUIDL :: Deploy article.

There are two major ways to be a good steward of Blockchain principles:

1. Use Open Source Repositories — New development can be tracked & shared

2. Verify Smart Contract Code — Allow people to verify the code before usage

Do not trust, but verify. That’s the Mantra.

When you expect a person to use a Smart Contract that you have written, either for money transfer or data storage, you are expecting them to digitally sign a transaction that could have significant consequences. Before you force that expectation on the users of your contracts, you should upload the identical source code to Etherscan so that you at least give the users an opportunity to audit the code to independently verify that the code that will execute actually does what you said it will do.

Verified code should be an expectation, not an aspiration.

For example, if there is an expectation that a user sending a specific amount of Ether to a contract will be assigned a corresponding value of tokens or tickets for a given exchange rate, they should be able to see that the author of the contract is not lying by visually inspecting the logic in the code. In addition, independent audits of the code could spot critical vulnerabilities that would cause people to lose funds, or the business to suffer a severe loss of funds, which would render any investment or purchase of any utility token/ticket useless for every other participant of the Smart Contract.

The act of deploying a Smart Contract merely uploads the byteCode of the contract, which is all that the Ethereum Virtual Machine (EVM) needs, but this is not the human readable code. Verified code is the flattened Solidity code for your smart contract. That means, if your contract inherited from another contract or used something like SafeMath as a library, then that code should be included in the uploaded code as well.

Steps for Verifying and Publishing your Solidity Source Code

Enter your Contract Source Code. If the Bytecode generated matches the existing Creation Address Bytecode, the contract is then Verified. Contract Source Code is published and publicably verifiable by anyone.

Immediately after deploying your Smart Contract, as we did for GreatestShow in the ComeOneComeAll project, you could go to Etherscan and view the contract at its deployed address. As you can see, the Code tab showed a bunch of random looking hex digits starting with 0x60806… which is the actual byteCode for the deployed GreatestShow as well as the constructor arguments that went into the creation of the contract. Once again, that’s fine for the EVM, but we need to help out humans that want to see the code.

Click the Verify And Publish link.

Tip: Check out the new Beta Source Code Contract Verifier which supports the ‘run’ option for verifying Truffle deployed contracts. If your contract uses libraries and fails to verify, you can also try using the beta source code verifier.

You should be on the Verify Contract Code (version 2.0) *New screen.

Type in the Contract Name, and in our case GreatestShow as well as the version of the compiler that was used when we deployed. Leave Optimization to ‘No’. If you don’t remember what version you used, type truffle version at the command line in your project. Output looks like:

Truffle v4.1.7 (core: 4.1.7)

Solidity v0.4.23 (solc-js)

So we would choose the v0.4.23+commit version for the Compiler

Contract Name, Compiler version and flattened Solidity Contract code are required.

We’re going to install a tool that will help us generate flattened Solidity code.

This tool helps you to verify contracts developed with Truffle on Etherscan, or debugging them on Remix, by merging your files and their dependencies in the right order.

npm install --save-dev truffle-flattener

Next, we’ll use the truffle-flattener tool to build a single file of text.

truffle-flattener ./contracts/GreatestShow.sol > ./GreatestShowFlattened.sol

On a mac you can use the pbcopy tool to copy the text to clipboard.

pbcopy < GreatestShowFlattened.sol

Then, go back to the Etherscan verification window and paste it. Click the “I’m not a robot.” reCaptcha. Next you will see an animated gif of a gear spinning.

Etherscan Verification of Solidity Source Code is considered a Smart Contract Best Practice.

Tada! After a successful verification, you’re done. You’ll know that your Contract Source Code Verified (Exact Match) as long as the byteCode compiled and tested in this verifcation step matceh the byteCode that was previously uploaded. If it doesn’t match, it will not verify. Changing even one line of the code to try to trick a user would be easily detected. Now you can proudly send users and potential new customers over to your Published & Verified code and Github project for their perusal.

Kudos. You just scored points in the Open Source and Crypto Communities.

Dan Emmons is owner of Emmonspired LLC, a Certified Bitcoin Professional, Certified Ethereum Developer, Full Stack Developer and Advisor on Cryptocurrency projects. He is also the creator of a Youtube Channel and iTunes Podcast called #ByteSizeBlockchain.