Research Summary: DevOps for Ethereum Blockchain Smart Contracts

TLDR

  • A DevOps approach and appropriate tools could remedy the difficulty of developing smart contracts at scale.
  • Before this paper was released, no structured guidance or detailed solutions for applying DevOps to blockchain-based software development existed.
  • The processes and tools of continuous integration (CI) and continuous deployment/delivery (CD) for smart contracts are illustrated with an analysis of the difference between DevOps for general projects versus blockchain-based applications.

Core Research Question

How can DevOps approach improve blockchain-based software development? What DevOps tools are available and how do they relate to blockchains?

Citation

Maximilian Wohrer and Uwe Zdun, “DevOps for Ethereum Blockchain Smart Contracts,” University of Vienna, Faculty of Computer Science, Research Group Software Architecture, Vienna, Austria, 2021. Available: http://eprints.cs.univie.ac.at/7141/1/document.pdf

Background

  • DevOps: Refers to the combination of software development (Dev) and operations (Ops). It focuses on fast-paced product development and delivery. Teams with a DevOps culture cooperate by using technology stacks and tooling to replace manual operations with automatic processes. This helps them independently accomplish tasks that typically require help from other teams. There are several benefits of DevOps, including rapid development and delivery, scalability, and improved collaboration, reliability, and security.
  • Continuous integration (CI): The goal of CI is to optimize the quality of software production by allowing a faster and more automated process of detecting and fixing errors in code.
  • CI flow: The process of continuous integration, which involves developers changing and testing the code with a local copy and then submitting a merge request, followed by a series of automated tests and eventually integration into a shared code repository.
  • Continuous deployment/delivery (CD): CD refers to a DevOps practice where deployment pipelines deliver updated configurations and code to environments. The core concepts of blockchain solutions are the same as non-blockchain solutions, i.e., involving a virtual machine, container, or serverless function, or an infrastructure as code (IaC) approach for provisioning these environments.

Summary

  • Previous works have mentioned that DevOps could be a useful approach to facilitate the process of blockchain-based software development, but there is still a lack of detailed discussion about its breakdown and applications. This is why the authors tried to build the first systematic approach for it in this paper.
  • Considering the topic of this research mainly concerns field applications and there are many practical knowledge reports provided by practitioners, the authors decided to take a pattern derivation approach which is built by applying grounded theory (GT) techniques.
  • CI/CD processes are the main parts of DevOps practice. The authors divide them into stages to discuss their findings, including various tools that support these stages.
  • The CI/CD process starts with CI, which aims to lift the speed and quality of code updating and testing from multiple developers with automatic processes in the build pipeline.
  • This is followed by CD, which allows deploying updated code and configuration to one or several host environments at any time.

Method

  • Using the pattern derivation approach, the authors define a pattern as the conceptual equivalent of best practices, where GT techniques are used to discover and codify the patterns.
  • The authors collect and combine gray literature and typical CI/CD configuration files for smart contracts from Github and the major search engines.
  • To identify candidate patterns, labels and optional memos were used to analyze, explain, and establish conceptual relationships among materials. The authors conducted constant iterative pattern comparisons until they reached theoretical saturation: i.e., until adding new sources no longer revealed new insights.

Results

  • CI stage: Several established CI solutions have provided sufficient tools to build and test smart contracts. They have also been used in practice. CI and tools for blockchain-based applications encompass the phases of Coding, Building, and Testing.

  • Code phase: This phase mainly focuses on conducting core development tasks within integrated development environments (IDEs) supported by proper plugins and frameworks. The general design principle of software coding, simplifying the code, is especially applicable for smart contracts. They should be written to focus on a single task or capability. The number of on-chain transactions also needs to be minimized. For general concerns, production-tested library contracts, or standardized contract implementations should be used. Contracts should be developed and tested by locking pragmas with a fixed compiler version. Also, all public contract interfaces should be fully annotated with specially tagged comments in the NatSpec format.

  • Build phase: This phase mainly focuses on including all steps for generating artifacts for execution from source code. Two compilers, solc, and solc-js (both use the same compiler source code) are used by Solidity to generate the artifacts to interact with the EVM bytecode. To interface with the Solidity compiler, the JSON-input-output interface is recommended. A preprocessor before compilation may be required in some situations. Raw source files are better kept in a separate directory and then the preprocessor is run to output the code to the source directory of the pipeline before compiling the source.

  • An overview of all possible test types, though discussion of them is beyond the scope of this paper. (Fig. 1)

  • Test phase: This phase mainly focuses on automatically deploying the code in a test environment to conduct a series of automated tests. In this phase, it is useful to separate software’s separable components and test purposes. Testing environment, Test Data, Unit and Integration Tests, Static/Dynamic Analysis, and Reports are respectively discussed below.

  • Testing Environment: For testing, smart contracts need to be deployed in a blockchain environment. A (temporary) local (in-memory) blockchain for testing and development purposes that simulates the characteristics of a real blockchain network is preferred.

  • Test Data: The testing blockchain can be equipped in one of three ways. The first is an empty blockchain without any transaction history; the second is a blockchain filled synthetically; the third is a fork of a production blockchain.

  • Unit and Integration Tests: To check the correctness of blockchain software, unit tests are the most common technique, followed by manual code reviews. Unit tests should cover all contract methods. Each test case should be executable in isolation without relying on the state that is imposed by other test cases. Integration tests may involve interactions between complex scenarios with multiple calls between different dependencies of a single contract or across multiple contracts, oracles, and front-end client applications. Solidity and JavaScript/Typescript are two options for writing automated test code. Also, some frameworks resolve the cumbersome mock situation.

  • Figure 2 illustrates the structure for Solidity and JavaScript-based testing. Where an API is used, the logic implementation can be tested externally (including the transmission path) or directly internally.

  • Static/Dynamic Analysis: Static analysis is aimed at uncovering potential vulnerabilities in the code with heuristics, without actually executing it. A linter tool is typically one of the first applied measures. VCS hooks can be used to conduct execution before each commit. Some advanced tools extend the static analysis and are commonly used to detect security vulnerabilities, such as dynamic analysis. There are some special test tools for smart contracts as well, such as fuzz testing and (code) mutation testing.

  • Reports: An important metric is test coverage. There are code coverage tools for Solidity that are run as a separate CI job, as well as gas reporter tools. It is better to combine different analysis tools to uncover as many existing errors as possible. Another important metric is tracking gas consumption. Tools are useful to generate gas reports for smart contracts code iteration.

  • CD stage: CD and tools for blockchain-based applications encompass the phases of Releasing, Deploying, Operating, and monitoring.

  • Release phase: A manual approval process that allows only a few key individuals to authorize a release for production is preferred. For crucial impact smart contracts, at least two independent security audits by at least two organizations should be implemented before the deployment. Provision of shared central archiving that collects and stores all artifacts generated for the deployment is also suggested.

  • Deploy phase: In this phase, updated and tested code pushes release builds into a production environment. Several tools to automatically facilitate the process in various contexts are discussed in the paper. These contexts include IaC, Smart Contract Deployment, Upgradeable Smart Contracts, and Testnet.

  • Operate phase: For blockchain software that is built on permissionless blockchains, there are tools that are useful for automatically conducting public verification of the deployed contract in the CD process.

  • Monitor phase: This phase uses various metrics or events to detect erroneous or suspicious behavior of smart contracts. There are several ways to monitor this behavior, such as Blockchain Explorer, operating one’s own blockchain explorer, running a dedicated blockchain node, and implementing a smart contract activity tracker that sends JSON RPC requests to scan data. Service providers and monitoring solutions also serve these tasks.

  • To demonstrate a holistic DevOps approach, the authors build a smart contract sample project (Maxwoe/sc-devops) based on the Hardhat development framework and implement a GitLab CI/CD pipeline.

Discussion and Key Takeaways

  • Due to the decentralized and immutable nature of blockchains, there are some peculiarities of DevOps for blockchain-based software.
  • In the design of smart contracts, the basic principles include reducing complexity, focusing on a single task or capability, minimizing the number/size of on-chain transactions/writes, and the dependencies required for testing.
  • A greater focus on testing is recommended, particularly for the use of static and dynamic code analysis. When testing is conducted, understanding interfaces and communication points (much like API) is crucial.
  • As the deployment of smart contracts is currently a limited and delicate undertaking in which developers want to have tight control, the most often observed situation is manually triggered deployment. Therefore, CD here refers to continuous delivery rather than continuous deployment. Measures for continuous deployment are not commonly used at the moment.

Implications and Follow-ups

  • This is the first structured approach and breakdown of specifics regarding a DevOps approach to blockchain-based applications.
  • The authors describe DevOps in the context of Ethereum and Solidity, but point out that the concepts and basic practices presented should be easily transferable to other platforms.
  • The biggest challenge is to specify the necessary test and deployment requirements and to select and orchestrate the appropriate tools.
  • Devising testing strategies that combine the various techniques and tools meaningfully to integrate DevOps with blockchain-based applications could be the focus of future works.
  • Other future works could include the implementation of continuous deployment for smart contracts.
  • The authors built a sample project (Maxwoe/sc-devops) to demonstrate a holistic DevOps approach for smart contracts.

Applicability

  • DevOps principles and tools can be applied to blockchain-based applications. Doing so will help the industry improve its development and operations, making the production process faster, more reliable, more collaborative, and more controlled.
3 Likes