Developing and maintaining a smart contract application is difficult compared to traditional software application development and maintenance. Blockchains usually incorporate new functionality through hard forks, that typically are scheduled ahead of time to ensure that all the nodes are running the same version of the blockchain software. Due to the difficulty in upgrade, a smart contract needs to be well tested before deployment. Smart contracts run on public blockchains that have thousands of blocks created over a period of years. A smart contract may need to be backward compatible and capable of validating earlier transactions or executing other smart contracts deployed through earlier versions of the blockchain [Bosu 2019]. Steep learning curves to get familiar with a smart contract is another challenge for many developers. The codebase of a smart contract project is not only complex but also requires a sound understanding of cryptography, networking, distributed systems as well as project specific protocols. The lack of supporting tools and documentation has been a challenge for many smart contract developers. Many of the supporting tools found in traditional software application environments are yet to be developed for the blockchain context. Moreover, the tools that are currently available are seen by many developers as immature and unreliable [Bosu 2019].
To understand a complicated smart contract domain, developers are looking for good learning materials and tutorials. Even the documentation that they currently have are not user friendly. [Ayman 2019] studied smart contract related discussion on the Stack Overflow forum which caters to many types of software developers and found that questions posted related to smart contract have increased since 2015. The fraction of posts that contain smart contract questions without answers seems unusually high, and it suggests that the user base still has a lot to learn. A significant percentage of smart contract related questions have no answers at all. Very few posts on Stack Overflow discuss security-related topics in smart contracts. Many of the blockchain projects are run by open source communities. Even when functioning well, open source communities provide only limited support. Commercially supported open source communities have a base of commercial entities with business models providing long term support to those communities – but the tradeoff can be undue influence in the development roadmap. Traditional online developer forums do not seem to be generating adequate support, perhaps due to the newness of the technology.
Smart contract platforms need [Harris 2019] to provide three properties: they need to be deterministic, isolated, and terminable. Determinism is required so that the distributed instances achieve the same result in their independent computations. A smart contract can be uploaded by anyone, which introduces a risk since any single contract may (by design or by accident) contain viruses and bugs. If the contract is not isolated, this could impact the entire blockchain ecosystem. Termination is required so that contracts conclude within a reasonable time and so that excess resources are not consumed. There are at least 28 different blockchain platforms [Yusuf 2018]. Beyond bitcoin and Ethereum, [Bartoletti 2017] identified four blockchain platforms supporting smart contracts that had been launched, were publicly accessible, and had a supporting community of developers. More recently, [Rouhani 2019] identified nine blockchains as also supporting smart contracts. The Ethereum and Bitcoin smart contracts seem to have the bulk of the transaction volume, with the bulk of the smart contracts on Ethereum, though statistics on private (permissioned) implementations are often not available. Bitcoin support for smart contracts is often through the use of side chains [Rouhani 2019]. The number and variety of platform supporting smart contracts seems to be increasing, providing an indication of the popularity of the approach, but also a challenge for developers and users of the technology.
Different blockchain platforms support a diverse set of programming languages to develop smart contracts. Some proposals have been made for higher level domain specific languages for smart contracts (e.g., based on specifications, or declarative logic), or to enforce solutions against particular vulnerabilities (e.g., BAMBOO – proposed to enforce a state machine model to resolve the reentrancy problem underlying the DAO hack). Languages for smart contracts should (1) consider users’ needs as a primary concern; (2) to facilitate safe development by detecting relevant classes of serious bugs at compile time; and (3) as much as possible, be blockchain-agnostic, given the wide variety of different blockchain platforms available [Coblenz 2019]. While there have been many recent proposals for language improvements, in practice, for many developers, the set of smart contract programming languages is constrained by the choice of blockchain platform.
[Bartoletti 2017] identified nine design patterns for smart contracts – token, authorization, oracle, randomness, poll, time constraint, termination (because the blockchain is immutable, there is a need to explicitly end a smart contact that has completed), math, fork check, and about 80% of the smart contracts studied used one or more of these design patterns. Validated design pattern templates of smart contracts increase trust for counterparties. The validation removes the need for costly back-testing and facilitates decentralized business transactions at unprecedented scale [Kaal 2019]. [Knecht 2017] proposes a smart contract deployment and management platform that can execute development tools and code quality tools in a trusted way and uses this to reduce the trust required into the smart contract developer or auditor. [Lu 2019] proposed uniform Blockchain as a service (uBaaS) as a solution to improve the productivity of blockchain application development. Existing BaaS deployment solutions are mostly vendor- locked: they are either bound to a cloud provider or a blockchain platform. In addition to deployment, design and implementation of blockchain-based applications is a hard task requiring deep expertise. The services in uBaaS include deployment as a service, design pattern as a service and auxiliary services. While well-known and time-tested design patterns can help developers, the packaging and portability of smart contracts is still constrained by the blockchain platform selection.
Testing blockchain software is challenging as the software executes on a distributed and potentially hostile environment that currently cannot be adequately simulated on a development machine. Smart contract developers typically use ‘test-nets’ to experiment with heir code before deploying it to the ‘main-net’. The test-net simulators that smart contract developers currently have are typically resource-limited, difficult to configure, and are unable to completely simulate a complex and hostile real-world environment. The scale and complexities of test-nets are typically not representative of main-net execution environments. Formal verification techniques have been proposed to secure smart contract projects, developers, however, find current formal specification languages (e.g., TLA+, VDM, and Z-notation) very complex to learn and use. Static analysis and penetration testing tools (e.g. fuzz testing, linting …) have been useful in other application domains for security testing, but those tools do not work well on the smart contract code-base [Bosu 2019]. Testing frameworks, such as the truffle suite, that automatically handle compilation and deployment of contracts and provide means of interacting with them [Patsonakis 2019] are still evolving.
The Interactive Developer Environments (IDEs), designed for the other application domains, seem to lack adequate support for testing and debugging a smart contract codebase. Smart contract developers use an array of tools for various development activities. Some developers maintain that an IDE designed specifically for smart contract development would help them [Bosu 2019]. Smart-contracts are typically written using smart contract-oriented programming language such as Solidity or Vyper and then compiled into bytecode for a specific platform (e.g., Ethereum). Remix, a commonly used IDE for solidity, currently lacks many features such as: error highlighting and line by line debugging, that many smart contract developers need [Bosu 2019]. Before interacting with a smart-contract, a developer might want to verify its security properties by decompiling its byte code but few solutions exist for this [Bosu 2019]. The other tools requested by smart contract developers include UML/design notations for the smart contract domain, containers for deployment, and automated performance analysis tools [Bosu 2019].
Given the current technology maturity of many of the tools that exist, and the variety of blockchain platforms, the environment for smart contract development does not seem very stable. The tool chain and testing frameworks can be expected to improve over time as developers become engaged with the technology. For other professionals (e.g. lawyers, auditors) with interests in verifying the correctness and completeness of smart contracts, the situation may seem even more confusing. Progress may be more tractable by focusing on a smaller set of well-known contracts, and establishing appropriate processes around those first, before attempting to apply them to a broader range of smart contracts. Focusing on particular types of tokens ay enable the development of standardized test suites for the set of transactions supporting those tokens. Standardized test suites would help enable the further development of other token and transaction types.
References
[Ayman 2019] A. Ayman, et al. “Smart Contract Development in Practice: Trends, Issues, and Discussions on Stack Overflow.” arXiv preprint arXiv:1905.08833 (2019).
[Bartoletti 2017] M. Bartoletti & L. Pompianu. “An empirical analysis of smart contracts: platforms, applications, and design patterns.” International conference on financial cryptography and data security. Springer, Cham, 2017.
[Bosu 2019] A. Bosu, et al. “Understanding the motivations, challenges and needs of blockchain software developers: A survey.” Empirical Software Engineering 24.4 (2019): 2636-2673.
[Coblenz 2019] M. Coblenz, et al. “Smarter Smart Contract Development Tools.” Proceedings of 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB). 2019.
[Harris 2019] C. Harris, “The Risks and Challenges of Implementing Ethereum Smart Contracts.” Int’l Conf. on Blockchain and Cryptocurrency (ICBC). IEEE, 2019.
[Kaal 2019] W. Kaal, “Decentralized Commerce–A Primer on Why Decentralized Reputation Verification Systems Are Needed.” Available at SSRN 3405401 (2019).
[Knecht 2017] M. Knecht, & B. Stiller. “Smartdemap: A smart contract deployment and management platform.” IFIP Int’l Conf. on Autonomous Infrastructure, Management and Security. Springer, Cham, 2017.
[Lu 2019] Q. Lu, et al. “uBaaS: A unified blockchain as a service platform.” Future Generation Computer Systems (2019).
[Patsonakis 2019] C. Patsonakis, et. al., “On the Practicality of Smart Contract PKI.” arXiv preprint arXiv:1902.00878 (2019).
[Rouhani 2019] S. Rouhani, & R. Deters. “Security, Performance, and Applications of Smart Contracts: A Systematic Survey.” IEEE Access 7 (2019): 50759-50779.
[Yusuf 2018] M. Yusuf, “A comprehensive list of blockchain platforms,” 2018.