#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.
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
We’re going to install a tool that will help us generate flattened Solidity code.
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.
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.