Ethereum smart contract planning & specification
One of the blockchain’s characteristics is immutability. Transactions and state are immutable as well as smart contract code. That implies that smart contract, once deployed on the chain, can’t be changed. Late change of requirements due to many reasons can have consequences, which is similar to hardware design. Of course there are mitigation techniques such as redeployment, but it also has downfalls (it costs time, gas and even reputation because of contract address change, thus, it can lead to misunderstandings). General concern regarding smart contracts is security and bug prevention through audits, but potential future improvements are usually neglected.
Sometimes it’s hard to predict future business needs and shifts. Also, building generic or upgradeable smart contracts can be tricky, but that doesn’t mean planning should be done in a sloppy way. Moreover, developers have
urge to start coding immediately, aka Cowboy coding. Notwithstanding, smart contract development methodology usually fits team’s methodology (for example, Agile), where user stories should be broken into tasks and planned in a proper way. With all mentioned, it’s obvious that process of planning is as important as smart contract audit. The output from the process of planning should be some kind of written/drawn specification which can be used as an input to development as well as guidance for future use and integration.
Every smart contract development process regardless of the team’s general development process should have several steps which roughly look like this:
1. requirements gathering and planning — includes collecting input facts from multiple sources while taking care of requirements traceability
2. specification writing — it’s a (non)standardized way of techically specifying the gathered requirements
3. coding — writing of program code that fits the specified needs
4. testing — manually testing the functionality and writing of automatic unit/integration tests later, usually with 90% code coverage for smart contracts
5. audit — first review code internally and later submission for external security audit with all the preconditions covered
6. deployment process — manual/automatic process of “pushing to production”
As it can be seen, the described process quite looks like waterfall. Of course it can fit into agile’s iteration or increment when done in a proper way. Or it can be done in increments, which would look like water-scrum-fall. The downside of it is, actually, testing which should be done through entire process, because smart contracts are safety critical. So, V and W models would fit fine. Anyway, it usually depends on team’s preference or on project management decisions.
Writing of specification in a way that would be helpful, not just for development, but also for later tasks is crucial. There are several aspects to think about. First of all, security, which should always be a high-level requirement and it boils down to testing of known attacks and maintaining the safe coding principles. That includes access restrictions to different
roles which can be identified from the very first requirements. UML use case diagrams can be used for that, where actors/roles are easily identified as well as their access to certain use cases/options. If there are many of them, RBAC modelcan be presented with access control matrix. Later on, during development, it boils down to writing of function access modifiers.
Sometimes it’s needed to deploy multiple (in)dependent contracts in order to complete the specified requirements. For specification of contract dependencies, dependency diagram would be the best option to use while specifying. But other options are UML communication diagram and N2 chart, if complexity is higher. But, smart contract isn’t an isolated island. It has connections and interactions with other parts of the product being built. Some of them are just reading the state, and others can execute transactions. Nevertheless, DApps usually use ABI as an interface towards the contract. For communication sequences, UML sequence diagram would be the best solution. If there are more parties involved along with contracts, Data flow diagram is also an option. Additionally, deployment and post-deployment maintenance actions should be foreseen and written in specification.
Coding style is usually a developer’s preference, but clean code should always be stated as high-level requirement. Antoine de Saint-Exupery once said “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” That principle should always be emphasized while writing code. It implies clear understanding of requirements and usage of patterns. Moreover, it is a necessity to think about performance of calls regarding smart contracts, which boils down to gas cost minimization.
To sum up, smart contracts have certain differences than standard coding. They should be simple and straight so proper planning is the crucial activity before actually developing them. As a first step, proper requirements gathering and analysis should be done in order to write the specification in a satisfying manner. Afterwards, adequate coding principles lead to quality code which acts as an input for testing and audit phases. Finally, the deployment process is the last step after which there is no going back. So, ensuring that planning and audit are done in a best way is crucially important.
References:
https://www.iotcoresoft.com/iot-knowlegde-center/what-is-the-best-blockchain-software-development-methodology
https://arxiv.org/ftp/arxiv/papers/1702/1702.05146.pdf
http://agilebusinessmanifesto.com/agilebusiness/blockchain-agile-organisation/
https://blog.indorse.io/ethereum-upgradeable-smart-contract-strategies-456350d0557c
https://consensys.github.io/smart-contract-best-practices/
