I’ve been writing smart contracts for fun since 2017 and have been given the opportunity to write them in a professional setting. This post is an overview of my experiences writing smart contracts for the past year and a half.
- Writing an ERC20 token is not like the examples found online
Most ERC20 token examples are like this:
This is your typical example where the token is initialized and all of your tokens are assigned to the contract creator. This example is pretty straightforward, but in most business use cases this will not work. You won’t want to be sitting at your computer issuing tokens to your end users manually.
In most business requirements I’ve encountered the process for issuing tokens had to be automated which leads me to my next point
- The Agent Pattern
At least I’m calling it the Agent Pattern, but it is akin to the Service Pattern in SOA, where a contract B is the RPC interface for another contract A. Let’s look at an example:
In this example the MyToken contract has a modifier on the transfer function onlyAgent that restricts the sender of the method call to be the agent with the correct address. Our agent is only settable by the owner of the contract.
Now this is a trivial example and the security flaw is that ANYONE can call the agent contract to transfer tokens. One secure approach might be to have a whitelist of valid addresses in the token or separate contract that are allowed to have tokens issued to.
Now we are able to apply business logic and evolve the contract as requirements change. But what if we want to have multiple agents?
The example above has been shortened for brevity, but you see now that we have a mapping or dictionary of agent address to boolean that denotes if they are authorized or not to execute method calls on our smart contract. We can enable and disable agents as needed!
- Use Open Zeppelin
Please use Open Zeppelin smart contracts, they help to take the guesswork out of security issues with solidity and ensure that you are deploying a safe smart contract. It is not a silver bullet, but it will help you to develop more secure code.
- Write tests, write more tests, write more tests after that
I can’t stress this enough the more unit tests the better, also if you do use Open Zeppelin, then import their tests into your code base for verification.
- Use the Truffle framework
Truffle is pretty much the standard starter kit for writing smart contracts, paired with Ganache makes for a pretty sweet development experience. YMMV with Ganache, in the past I've had issues with it, but recently its been quite pleasant. Ganache also does a better job of giving more explicit error output in the console when running unit tests or interacting with contracts through truffle.
- ALWAYS deploy to a testnet first
I've made the mistake of deploying a smart contract to the mainnet once and found a minor bug in it. If I had deployed to a testnet first this could have been avoided. Ropsten is my testnet of choice as I've found it easy to get test ether from their faucet. The faucet has an api that can be used to greylist your wallet address for a short period of time to receive ether.
- Deployments
So far my deployment tools of choice are Remix and Metamask. The deployment process to either test or main nets have been quite painfree. I'll save the details for how I do that in another post.
Alternatives would be to use your own Ethereum lite node or Infura.io. However setting up a lite node just to deploy contracts can involve a lot of friction before your pushing contracts to an Ethereum network and I didn't have the best of luck with Infura when it first emerged. However things may have gotten better and could be worth exploring again.
- Read other peoples code
Most Google searches will only bring up ERC20 tokens and probably Cryptokitties, but those are still good sources of information for understanding how to write better smart contracts.
- Architecting smart contracts
Start out with a single solidity file and work from there. The interfaces will reveal themselves as you write the code. Assuming your interfaces from the get go will only cause you pain as it takes more work to orchestrate and deploy smart contracts than it does with your typical software codebase.
Thanks for reading!
Top comments (0)