Developing Smart Contracts

Tools of trade and Guidelines

photo by Grant Bishop

Blockchain applications may impact the way that individuals and organizations interact. For this to happen, we need way more people developing these applications and for this they need to learn about creating smart contracts which are in a way blockchain powered apps.

This blog post is a brief overview of the tools of trade and guidelines to develop blockchain applications.

Smart Contracts

Blockchain software is similar to hardware in the sense that once it is produced it cannot be changed. Imagine getting hold of a defective iPhone. The experience is not pleasant. The same is for smart contracts as once it is deployed it immutable. Deploying smart contracts generally means that you are dealing with the company’s or other people’s money so in order to create a smart contract, you got to make sure it works. And for that we use smart contract tools such as Truffle.

Truffle Framework

It is true that Ethereum development experience and tools are not on par with the reality in other programming languages such as JavaScript or Python. But gradually it is getting there. The Truffle framework is an example of a great tool that help us in our smart contract development needs. It is the swiss army knife of the Ethereum smart contract community and it allows devs for ease of contract deployment on the blockchain as well as unit testing our smart contract code. It is the bedrock tool for our deployment workflow which goes as following:

1. Build tests on Truffle and interact with contract using TestRpc.
2. Create the interface and test.
3. Deploy to testnet.
4. Internally and publicly test the interface on the testnet.
5. Deploy to mainnet as ‘beta’ and test the heck out of it on the mainnet.
6. Deploy to mainnet as production release.

Testing

We have on average a 1:20 ratio of smart contract code to unit testing lines. It is paramount that the smart contract code is well tested. As mentioned earlier, contracts on the blockchain world cannot be changed. Granted that there are upgradeable techniques for contracts but a best practice around it has not been established yet and even if it was here already, you would still want to spend time testing obsessively any contract code of yours. The basic guideline for testing is to not write untested code, ask at least a different engineer to review recently produced code, and not to reinvent the wheel for solutions that are proven and thoroughly tested.

Speaking Things Into Being

This guideline is based around “speaking things into being”, that is to say, not creating things and then describing them later.

This approach has a variety of benefits.

• If we can’t clearly describe something, we probably don’t actually understand what we’re trying to do. This will be reflected in the contract. Exploration and experimentation are encouraged — just not in commits.
• By putting documentation and testing first, we ensure that we always have an up-to-date specification for the system. This helps us stay focused on what we’re doing rather than how we’re doing it. How will always change quickly. What will change as well, but less often.
• By creating a common language together, our mental map of the system will remain more accurate. When changes need to be made, it is easier to see and discuss how concepts relate rather than how cogs of a complex machine relate. Our understanding should drive our structure, not vice versa.

This is the high level vision of the tools and guidelines to create smart contracts.

Godspeed!