Security Session at Devcon2: Building Better Smart Contracts
The second day of Devcon2 was dedicated specifically to smart contract security.
Various leaders within the industry held sessions about different security practices. They focused on new verifications and analysis tools, specific contract functions developers should be cognizant of, and the best practices and security philosophies recommended by industry leaders.
Joseph Chao from BTC relay shared his own philosophy and approach.
- Developers need to prepare for failure. Both developers and alpha users should also be ready for the “unknown unknowns”. Knowing all the possible outcomes of a contract is simply not possible in some cases.
- Developers should prepare a roll out of their product carefully. A good production system takes time, and engineers should not feel pressured to push our products quickly by investors or other monetary considerations. The strongest contracts require significant time to be made, including deployment on testnets and a beta on the mainnet before the launch.
- Developers should aim to keep contracts simple. Not only is this more cost efficient for gas usage, but it could also lead to new surprising results because simplicity breeds creativity.
- Staying up to date on the most recent findings and developments is absolutely crucial in this industry. Specifically, ConsenSys provided an updated bibliography on smart contract best practices, which is a good way to keep up with what’s going on within this ecosystem.
Besides new philosophies, several researchers in the Ethereum community are focusing on building security tools that enable developers to efficiently analyze contracts.
Among them is a new tool that allows developers to visualize security vulnerabilities. Raine Rupert Revere built a tool that allows users to take the source code and create an abstract syntax tree. This is, in essence, is a map of all the functions, which allows developers to explore their code programmatically. It’s code reading code. Her product, Solgraph, takes these abstract syntax trees and colors them. Developers using the tool can spot potential security risks in smart contracts a lot easier with this tool. If it had been used with The DAO, for example, this would have provided a simple way to identify where a reentrancy attack would have been.
A lot of focus was also given to formal verification tools. Dr. Christian Reitwiessner explained, “Formal verification uses a technique to test a program on all possible inputs and states. It asks: is the sum of all balances unchanged by the contract, considering all possible states?”
Several formal verification engineers new to the Ethereum community presented their work and were thrilled to announce “the Ethereum Virtual Machine really is a paradise for us engineers”.
Christoph Jentzsch from slock.it gave the final presentation on the third day and made it clear that future contracts should always contain a cap. Furthermore, current applications would still require elements of centralization to make them safe and add elements of control. However, he added, “Don’t use The DAO as an excuse to build centralized applications. I still fully believe in decentralization.”
Overall, the main points given to developers was to build contracts that have updatable features, to establish known security patterns, and create smart contracts that contain minimal complexity.