Laying the foundation for smart contract development: an integrated engineering process model

Smart contracts are seen as the major building blocks for future autonomous blockchain- and Distributed Ledger Technology (DLT)-based applications. Engineering such contracts for trustless, append-only, and decentralized digital ledgers allows mutually distrustful parties to transform legal requirements into immutable and formalized rules. Previous experience shows this to be a challenging task due to demanding socio-technical ecosystems and the specificities of decentralized ledger technology. In this paper, we therefore develop an integrated process model for engineering DLT-based smart contracts that accounts for the specificities of DLT. This model was iteratively refined with the support of industry experts. The model explicitly accounts for the immutability of the trustless, append-only, and decentralized DLT ecosystem, and thereby overcomes certain limitations of traditional software engineering process models. More specifically, it consists of five successive and closely intertwined phases: conceptualization, implementation, approval, execution, and finalization. For each phase, the respective activities, roles, and artifacts are identified and discussed in detail. Applying such a model when engineering smart contracts will help software engineers and developers to better understand and streamline the engineering process of DLTs in general and blockchain in particular. Furthermore, this model serves as a generic framework which will support application development in all fields in which DLT can be applied.


Introduction
Within the last couple of years, blockchain technology, or, more generally, distributed ledger technology (DLT), has become a highly popular research topic and been recognized as a potential game-changer for the industry. The pseudonymous author (or group of authors) Satoshi Nakamoto, who mentioned neither the term "blockchain" nor "DLT" in his paper, introduced the cryptocurrency Bitcoin as the first use case of this technology (Nakamoto 2008). The years following this seminal paper were characterized by intense discussions in academic communities specialized in cryptography and dedicated online groups, but the full potential of the technology was not yet properly understood within applied academic and business-oriented communities. This situation changed around the year 2014 when the exchange rate of Bitcoin started to soar and several authors highlighted the potential of the technology for countless use cases beyond cryptocurrencies (Swan 2015; Tapscott and Tapscott 2016). Not surprisingly, various academic communities have now started to rigorously investigate the topic and an ever-increasing number of papers is being published in various academic outlets (Johansen 2018).
The immutable, trustless model of decentralized computation and transaction handling which is provided by the blockchain strives to ensure fairness for all participating actors and has led to an ever-increasing market capitalization of cryptocurrencies in recent years. By June 2018, the capitalization of the five leading cryptocurrencies (Bitcoin, Ethereum, Ripple, Bitcoin Cash, and Litecoin) exceeded 193 billion dollars (Coinmarketcap 2018). However, the functionality of blockchain does not stop at cryptocurrencies. One of the most widely discussed features of blockchain technology is the possibility to create decentralized and self-executing programs: so-called smart contracts. Current application scenarios include areas as diverse as supply chain/logistics, finance, tourism, Internet of Things (IoT), project operations, gamification and education (Treiblmaier and Zeinzinger 2018; Tapscott and Tapscott 2016). Numerous organizations are already applying this technology stack to supplement or supplant existing legal and financial transactions (Egelund-Müller et al. 2017;Fanning and Centers2016;Friedlmaier et al. 2016;Clack et al. 2016;Notheisen et al. 2017). The huge monetary values processed through smart contracts and/or represented by cryptocurrencies necessitate structured software development processes and high levels of quality assurance. Incidents such as the DAO attack (Siegel 2016) as well as the King of the Ether incident (King-OfTheEther 2016), aggregating damage in excess of 60 million dollars, illustrate (1) that the current ad-hoc style of engineering is not suitable for such high-value transactions, (2) that existing software engineering approaches do not ensure a sufficient level software quality, and (3) that these approaches are either unsuitable for or misaligned with the specificities of blockchain technology (Atzei et al. 2016). Atzei et al. (2017, p. 182) point out that "a common cause of insecurity of smart contracts is the difficulty of detecting mismatches between their intended behavior and the actual one". Subsequently, Destefanis et al. (2018) encouraged the academic community to further investigate and develop blockchain-oriented software engineering processes; We answer that call.
Traditional software engineering focuses on principles for developing high-quality software systems and maintaining the systems as they evolve in real-world environments (Mens et al. 2010;Edan and Pliskin 2001). Software that does not evolve during its lifetime, however, will not be able to keep up with changing requirements and will become outdated over time. This has profound implications for existing software process models, which must respond to the increasing need for change and evolution by introducing iterative, incremental, and evolutionary approaches (Mens et al. 2010;Boehm and Turner 2005;Beck et al. 2001). In demonstration, software maintenance and evolution have emerged in the last decade as key research fields that explicitly differentiate between the time phases before, during, and after the software is delivered: denoted development time, deployment time, and runtime, respectively (Jacobson et al. 1999). Post-deployment changes are typically realized by returning to regular development activities, which eventually result in a new version of a software product or a patch that is released to replace or enhance the currently running version during scheduled downtimes. This process is structured by change management activities (Stark 2015;Rajlich and Bennett 2000;Bennett and Rajlich 2000). All such changes that occur after the initial development time are impossible, however, in settings where the contracts are published on blockchain and are immutable from that point onward. To clarify, and to counter an often-repeated yet incorrect narrative, DLT systems are only immutable with respect to their specific context and rules. Changes in the execution environment, in the stakeholder agreement (e.g., switching to another technology or invalidating specific entries), or in the usage of specific patterns (e.g., proxy pattern) yield mutability.
In this paper, we systematically develop a smart contract engineering process that clearly outlines its respective elements and artifacts. This process description represents an essential tool for numerous strategic and operational activities since it helps in defining priorities, clarifying risks, and managing expectations and time frames. We further develop a framework that supports stakeholders of smart contract engineering processes in their coordination efforts and which can be used for activities such as project management and legal risk management, complexity and standards management, as well as for security and quality management. This paper is structured as follows: First, we identify research topics related to DLT technology and give a short introduction to trustless, append-only, decentralized digital ledgers, and to related software engineering process models. Second, we describe our methodological approach consisting of expert interviews and qualitative content analysis. Third, we develop an integrated process model for DLT technology in a stepwise process. Finally, a short discussion and a comparison to conventional engineering processes concludes this paper.

Identification of DLT research topics
The immutable nature of smart contracts in trustless, append-only, and decentralized digital ledgers makes the traditional software engineering lifecycle both inappropriate and insufficient (Sillaber and Waltl 2017). Instead, the technical specificities of blockchain technologies demand central consideration as a robust frame of reference that helps in decomposing its overall complexity and accommodating the new requirements of smart contract engineering. In Table 1 we list several research topics and questions pertaining to a variety of different managerial aspects of software development that need to be systematically addressed. In the domain of project and legal risk management, we list topics surrounding the consideration of all relevant issues and requirements prior to the deployment of the smart contract, including cost comparisons, project duration, mitigation of legal and project-related risks, and potential problems arising due to legal requirements related to "anti-money laundering" (AML) and "know your customer" (KYC). When it comes to complexity and standards management, questions arise as to which concepts and elements of smarts contracts need to be standardized, which components of contracts should be individualized: considerations include the decomposition of complexity, the impact of smart contracts on negotiation processes, the integration into legacy systems as well as the portability of existing systems on the blockchain, the identification of the best modeling languages and smart contract patterns, and the handling of contracts that are interrelated. Important issues related to security and quality management include the testing and validation of smart contracts, the mitigation of risks that might arise from bugs and vulnerabilities not known at the time of development, the auditing of smart contracts, and the security of the underlying platform.

Related work
Although the term blockchain is relatively new (Swan 2015; Tapscott and Tapscott 2016), its underlying concepts are not. Some of the foundations of this technology, such as Merkle trees, proof of work algorithms, or smart contracts, were already developed decades ago (Narayanan and Clark 2017). Smart contract engineering, therefore, builds on (1) the conceptual foundation of smart contracts, as well as on (2) state-of-the-art software engineering with a focus on blockchain technology. We briefly outline both topics in the following sections.

Smart contracts in trustless, append-only, decentralized digital ledgers
The term smart contract was introduced by Szabo (1997) when he first described how the computer-based execution of contracts between two parties can be secured without requiring a third party for intermediation or confirmation. His original article provides the first description of decentralized smart contracts as computer programs that are executed by all participants. This allows all participating parties, who do not necessarily know or trust each other, to securely transact with each other. The correct execution of these programs is ensured by a so-called consensus protocol (Luu et al. 2016).
The basic technological properties of trustless, append-only, decentralized digital ledgers (TADDL), which includes blockchain technology, are well-studied and described in the literature (e.g., Tschorsch and Scheuermann 2016). Several separate active research streams focusing on specific technological issues of TADDLs can be identified, including topics such as anonymity versus pseudonymity, transaction rates, and proof-of-X (Tschorsch and Scheuermann 2016; Anderson et al. 2016). A TADDL is a decentralized virtual state and computing machine that enables several parties to share a common state, the integrity of which is ensured and verified by other participating parties or "volunteers", including, for example, miners (Anderson et al. 2016). Various incentives promote participation in the mining process, most  (2017), Bartoletti and Pompianu (2017) Security and quality management How can smart contracts be tested and validated? How can stakeholders efficiently mitigate risks from bugs and vulnerabilities in smart contracts? How can smart contracts be audited? How secure is the underlying platform? notably coin rewards. The use of a so-called consensus protocol that is binding for all participating parties and which forms the mechanism through which consensus is achieved within a peer-to-peer network, implies that the data being stored-cryptocurrency asset balances, for instance-are accepted by all participants. With the components provided by the TADDL, complex digital asset transactions and financial instruments can be created (Buterin 2014;Koulu 2016;Anderson et al. 2016). The use of smart contracts executed in a TADDL can be observed in many different domains, ranging from online gambling to fundraising (e.g., Porru et al. 2017;Egelund-Müller et al. 2017;Xu et al. 2017;Böhme et al. 2015;Klöhn et al. 2018).

Software engineering process models
The IEEE 1074-1995 Standard for Developing Software Lifecycle Processes defines a process as a set of steps that can be executed in a certain predefined, sequential, parallel, or conditional order (IEEE 1995). Software engineering processes are part of the general Software Engineering Body of Knowledge (Bourque and Fairley 2014). Various process models cover the order and frequency of phases in software projects. Those phases typically include planning, analysis, design, implementation, testing, and maintenance. Waterfall models progress sequentially through these phases, whereas iterative models are typified by repeated execution of the waterfall phases, in whole or in part (Braude and Bernstein 2016). Differing from these phase-oriented process models, agile process models are based on the principles of individuals and interaction, working software, customer collaboration, and fast response to change (Beck et al. 2001;Vidgen and Wang 2009;Lee and Xia 2010). A recent trend is to combine phase-oriented with agile process models to obtain hybrid software engineering process models (Kuhrmann et al. 2017). Modern software engineering approaches rely heavily on the (re-)use of software patterns (Kuhrmann et al. 2017). Patterns are collections of abstract best practices of software code that engineers can easily adapt. These best practices are the result of previous software engineering experience and often allow faster, more secure, and more reliable software development. As industry experience with smart contracts grows, it is very likely that a set of smart contract patterns will emerge in order to foster efficiency and effectiveness in the creation of smart contracts.
In their overview on the current status of research and practice regarding software engineering process models, Fuggetta and Di Nitto (2014) highlight several challenges caused by the Internet as a basic development, execution, distribution, and business infrastructure. They list research issues such as the fading distinction between design, development, and operation, but also highlight topics such as security, privacy, and trust. Blockchain-oriented software engineering has also attracted recent interest. Porru et al. (2017), for example, outline new research directions for blockchain-oriented software engineering processes, which include the areas of collaboration, enhancement of testing and debugging, as well as the creation of software tools for smart contract languages. In this paper, we extend previous research by developing an integrated process model for smart contract engineering.

3
Laying the foundation for smart contract development: an…

Methodology
We conducted interviews on smart contracts with eleven industry experts. Table 2 gives an overview of the participants, their organizational roles, qualifications, and previous involvement in blockchain projects, structured by blockchain type and use case. The primary goal of the interviews was to get a better understanding of how the study participants develop smart contracts and which processes, artifacts, and tools they apply. We used a Delphi study approach wherein the findings from the first round (interview partners 1-9) were evaluated and refined in the second round, in which interview partners 8-11 participated (Prusty et al. 2017). Interview partners 8 and 9 were part of both rounds and helped to connect the findings by critically commenting on the feedback from the second round. The experts were identified by contacting the respective leaders of the development teams of the 20 largest blockchain projects, as measured by their token market capitalization listed on ICOAlert (www.icoal ert.com) as at November 2017, as well as through the authors' personal networks. All potential experts were invited via email and eleven of them agreed to participate in our study. The participants were briefly informed by the researchers about the context, goals, and scope of the study, and the interviews were conducted via video conferencing or in person. Each interview was recorded and transcribed. After the interviews, the resulting process model, as well as the changes resulting from the interview, were sent to the interviewees for further feedback, which was then again incorporated by the researchers.
We used the open questions shown in Table 3 to structure the interviews and frequently applied follow-up questions to clarify specific issues (cf., Chau and Tam 1997). In a first step, the experts were informed about the goals and the procedures of this research project. Most notably, we presented various intermediate versions of the process model that included modifications and extensions based on the findings generated from previous interviews. Next, they discussed the different stages of the processes they use in their companies in a stepwise manner and included their findings in the model. Finally, summaries were produced from the interviews in order to derive concepts and constructs for further model development (Mayring 2014;Lacity and Janson 1994).

Process model development
In the following sections we develop the smart contract engineering process in a stepwise manner. First, we discuss the conceptual base and describe the main types of artifacts that emerged from the interviews. Second, we discuss the findings from the qualitative interviews with several software developers. Third, we present various roles, activities, and artifacts and, fourth, we incorporate these components into one integrative model.

Conceptual base
We followed a design science approach to precisely define the respective steps of the process model (Baskerville et al. 2018;Zakarian and Kusiak 2001). The core concept of design science is the artifact: an object that can be instantiated with physical or social properties. Examples of artifacts can be as diverse as software, models, or norms (Hevner et al. 2004). In their proposed research framework for the conceptualization of design science research within information systems (IS) research, Hevner et al. (2004) propose three integrated dimensions: (1) the environment including people, organizations, and technology, (2) IS research pinpointing the creation and justification of artifacts, and (3) the knowledge base bringing forward foundations and methodologies to be used in the creation and evaluation of artifacts. More specifically, March and Smith (1995) differentiate between four types of artifacts: constructs, models, methods, and instantiations. Constructs, which consist of language and vocabulary specifying problems and solutions, form the baseline design science vocabulary. The construct level establishes a common understanding of the involved entities, by identifying those entities, their attributes, and the relationships between them. Furthermore, constructs describe the terms being used and ensure their consistent usage throughout the domain. Models are descriptions and representations of real-world phenomena with a focus on utility, not truth (March and Smith 1995). They can therefore be abstract and may represent nothing more than arbitrary aggregations and groupings of instances. In order to be useful, the entities chosen for the model have to be representative of the underlying information system (Wood 2014). The steps needed to execute a specific process are called methods, which are procedures for solving problems and developing solutions. Methods are built on constructs and models. They are used to transform constructs and models from one representation into another and consequently operate on models and concepts as input and output parameters. Methods also subsume abstract algorithms and procedures (e.g., human activities) which are part of the overall process. Instantiations (i.e., physical assets) are the realizations of artifacts within their respective environments. They constitute the most concrete entities among the four different artifact types and are most suitable for empirical analysis including performance measures in terms of effectiveness and efficiency of the smart contract engineering process. In Table 4 we map the artifacts from Hevner et al. (2004) to the domain of smart contract engineering, with the respective artifacts shown in the left column and their manifestations within the domain in the right column.

Expert evaluation
In order to create an integrated process model that accounts for the specificities of smart contracts, we thoroughly analyzed the previous experiences from our experts following the guidelines for qualitative research (Mayring 2014) and design science research (Hevner et al. 2004). All but one interviewee (#7) were familiar with existing software engineering process models and confirmed that they actually build their 1 3 Laying the foundation for smart contract development: an… own processes on them according to their needs-including modifications that are needed to account for the specifics of TADDL environments. All interviewees concurred that developing smart contracts is different from developing software in traditional ways and more comparable to developing hardware: "… it is much more like developing hardware that is shipped off to customers-without any chance to fix bugs once it has been sent off". Additionally, we found almost all described projects to be a mix of traditional software engineering and TADDL-specific engineering (cf "non-SC specific development" in Fig. 2). Additionally, all interviewees agreed that the submission of the smart contract to the live TADDL constitutes the most criticial part of the whole development process. For example, one interviewee stated that "… we even follow a paper-based approach where the entire team has to sign off before it is submitted. The entire team has to be present-it is very ceremonial". Some interviewees had already perceived problems with existing testing approaches in a blockchain-based environment: "It is not possible to test under realworld conditions-we have a Testnet, but can never be sure to have similar conditions as in the real [TADDL] network". There was a general agreement regarding the importance of the analysis, specification, and validation of the implementation against the requirements: "We have tight feedback loops, where both the backend developers as well as the smart contract developers and our customers discuss the requirements and the implementation". Approval of a smart contract is in general We print out all the relevant documentation and put it into a binder. We have test reports, coverage reports and, most importantly, the signed approval from our clients in there". Another interview partner reported challenges while launching their platform. As demand for the system exceeded expectations, too many server-side transactions were issued in a short period. As transaction costs were not adjusted, thousands of transactions were computed in the wrong order and thus failed. The engineers concluded that the calculation of transactions costs needs access to realtime data. Additionally, a queue for to-be-issued transactions was implemented within the platform. Several major challenges were explicitly mentioned with regards to the availability of testing data from oracles. As some of our interviewees develop smart contracts that are intended (at least in theory) to run forever, they support the idea of a dedicated finalization phase-but were not able to specifically link it to their respective use cases. A comprehensive documentation is therefore important during contract runtime: "We definitely store everything, even after the smart contract is no longer under active development-especially since we do not know when something bad [referring to the DAO hack] might happen". Finally, based on the fact that smart contracts cannot be changed after deployment, a careful monitoring during runtime turns out to be crucial: "We have a dedicated watchdog [i.e., custom piece of software] that tracks the smart contract's spending and alerts us in case something odd happens."

Roles, activities, and artifacts
To formally and constructively describe an engineering process, the Rational Unified Process (RUP) Framework (Kruchten 2004) can be used as a baseline for adaption since it is document-centric and reflects the smart contract development process. More specifically, the RUP is used to differentiate between three distinctive elements: First, roles pertain to individuals or groups performing activities within the process. Such roles, which might include smart contract engineers, software engineers, and legal experts, are responsible for the artifacts that are the outcome of their activities. Second, activities summarize a unit of work that must be performed. The outcome is the creation or update of artifacts. Third, artifacts denote the input and output of activities. Artifacts are created, modified, and used by the roles during the procedure and are either the final product, parts of it, or intermediate results.
Examples of artifacts include concepts, models, source code, smart contract code, or documents such as performance reports. Figure 1 illustrates the lifecycle of a smart contract. Sillaber and Waltl (2017) have shown that smart contract lifecycles start with an implementation phase, during which requirements are transformed into an implementation (Create and Adapt), verified against the requirements, and either approved for release or modified again. Once the smart contract is approved, it is published on the TADDL in the submission stage. In this phase, the smart contract is submitted and distributed within the TADDL network. From that point on, every entity with access to the TADDL can retrieve the contract and share it with other nodes. Once the smart contract has been spread throughout the network and is accepted by general consensus (i.e., it persists on the network), reverting or changing it requires-under ideal circumstances-substantial effort. The contract is now ready to be executed. In a paper contract analogy, this would be the signing of the contract, which is one important step to make the contract valid and enforceable. The execution stage of smart contracts is performed by miners or other participants of the TADDL, since the smart contract code is now accessible for all participants in the form of bytecode. To execute it, the smart contract is retrieved from the TADDL and carried out by the respective node (compute). Based on a given input, the output (e.g., a return value, a state transition, or a set of transactions) of a smart contract is computed, which is then stored and distributed within the network. This is similar to the "closing" of an offline contract. A smart contract can be executed as long as it is active. Its execution is resource-consuming and the nodes contributing computational power for its execution are rewarded according to the distributed ledger's reward scheme. In the finalization stage, the smart contract expires. This can happen either because the parties actively declare the smart contract as invalid (e.g., by withdrawing remaining funds or executing an appropriate function) or because of intrinsic conditions that make further executions impossible (e.g., time expiration; inability to pay the fees required for further execution). In this case, the smart contract remains in the TADDL, but can no longer be executed by the nodes. This means that the smart contract is disabled through a conditional exit that prevents future execution. This is akin to the "final" state of a business process, where specific properties (e.g. successful execution, final state) depend on the specific context.

3
Laying the foundation for smart contract development: an…

An integrated smart contract engineering process
Figure 2 combines and summarizes our findings from the literature as well as the expert interviews into a comprehensive framework for the integrated smart contract engineering process. In the conceptualization phase, the preliminary scope and the goals of the smart contract are defined. The scope informs all involved parties about what will be, and what will not be, part of the smart contract and can be directly derived from traditional contractual requirements. This process is called requirements elicitation. The problem definition should also state the desired economic outcome(s). After reaching an agreement about the scope, the next step is the conceptual modeling: the transformation of the requirements of all involved parties into a smart contract model. In this phase, the conceptual model is created. The conceptual model defines classes of objects (e.g., wallets) and the desired relations between these objects and outcomes (e.g., transactions). The construction of the conceptual model will most likely uncover incomplete and contradictory aspects of the problem definition. Additionally, the modeling process may raise new questions for the involved parties to answer and resolve through negotiation. In either case, the problem definition should be adjusted.
After the conceptual modeling phase, the implementation phase starts. Here, the conceptual model is mapped onto an executable model (e.g., in Ethereum by using Solidity code) as existing smart contract patterns are identified, adapted and combined. It is critical to note that for performance and cost reasons, most business logic to be implemented will be executed outside the smart contract, within a "traditional software" application (termed "non-smart contract code"). The identification of those parts that should be included in the smart contract, and those that should be excluded, requires a thorough analysis of functional requirements as well as non-functional requirements for confidentiality, integrity, availability, scalability or efficiency. This analysis may even be performed as a formal risk analysis. In a banking application, for instance, core-banking functionality may be implemented as a smart contract, whereas data visualization on a traditional software stack.
An executable smart contract is not necessarily immediately correct and has to be reviewed, tested, and verified. Verification and simulation of the smart contract against the scope and stakeholder requirements are necessary to check whether the code contains errors, including programming errors and mal-adjusted parameters. For verification purposes ("Simulation, testing, code review"), various scenariobased executions can be simulated step-by-step in a private blockchain. Apart from verification, validation of the smart contract is also required. During validation, the simulation results of the smart contracts are compared to real-world contract states and stakeholder requirements. New insights may even lead to an adjustment of the problem definition and/or the conceptual model of the smart contract. A simulated Fig. 1 Simplified lifecycle of a smart contract 1 3 smart contract found to be correct after validation is called a validated smart contract after the last round of consolidation.
Starting from the consolidated and validated smart contract, an instance of the smart contract can be frozen and submitted for execution in the live TADDL environment. Finally, in the approval and execution phases, the published smart contract is approved and executed in the TADDL and has to be monitored during runtime. In case the smart contract's behavior deviates from the stakeholders' requirements, appropriate change management mechanisms have to be activated: in extreme cases, the deactivation of the smart contract by depleting its funds and the creation of a new smart contract which better meets the stakeholders' requirements. Modifications of non-smart contract components are possible throughout the entire lifecycle of the smart contract. Although the smart contract becomes immutable after it has been submitted to the TADDL environment, the environment itself often provides opportunities to influence the outcome of smart contracts: for example, by influencing the call graph through a function registry or call delegation. The smart contract's runtime behavior is constantly monitored and managed in a change management process. Once the smart contract has reached the end of its life (e.g., by executing the "self-destruction" operation in the Ethereum blockchain), proper finalization can be confirmed in the finalization phase by validating whether the desired outcomes have been reached. Figure 2 further shows that feedback between phases is possible and frequently necessary. In practice, many phases will overlap. More specifically, specification, implementation, validation, and verification will go hand in hand once the appropriate tools are available to smart contract developers.

Discussion and implications
Smart contracts may well become the backbone of businesses based on blockchain and related technologies (Bailis 2017;Werbach and Cornell 2017). However, prior to the creation of industry-specific solutions, it is prudent to consider the general Fig. 2 Integrated smart contracts engineering process characteristics of smart contracts and the roles they play during their lifecycle. In this paper, we therefore present an integrated process model for smart contracts that was developed and iteratively improved using findings from previous research and the feedback of eleven industry experts. This model highlights the important role of smart contracts during their lifecycle and thus supports quality management in software engineering. This is of utmost importance for the business community striving to use blockchain-based solutions, since immutable bugs in smart contracts with no possibility of rectification have been exploited in previous attacks. For example, the controversial hard-fork of the Ethereum blockchain, which basically nullified the effects of malicious transactions, poses an example of how laborious and far-reaching ex-post changes on blockchain can potentially be (Buterin 2016).
Our proposed smart contract engineering process is generic and is applicable to a wide variety of distributed ledger technologies. It is based on traditional software engineering process models and methodologies, such as the waterfall model as well as iterative models that have been successfully applied in a wide variety of use cases, and can be easily integrated with these existing models. For example, one cycle of the implementation phase can be aligned with a Scrum sprint (Schwaber and Beedle 2002). Traditional phase-oriented software engineering process models like the waterfall model typically progress linearly through an analysis, design, implementation, and testing phase. While the analysis, design and implementation phases align with our proposed conceptualization and implementation phases, special care has to be given to the testing phase of smart contracts, as this must be conducted and concluded prior to publishing the contract. Iterative software engineering process models typically iterate sequentially through the aforementioned four phases. The implementation phase proposed in this paper iterates through a pattern selection and adaption, development, consolidation, review, testing, and simulation phase, aligning these process activities with iterative software engineering process models.
Although further refinement of different aspects of the integrated process model may be necessary for specific applications, the integrated model as presented in this paper can immediately be applied in real-world industry settings. It can help smart contract engineers to better understand the strengths and weaknesses of their engineering processes and support them in further optimizing different process activities and artifacts such as software, models, and norms. Additionally, the process model can advance applied smart contract engineering processes and serve as a basis for critically investigating those processes in great detail, which is of practical value for any industry that needs to react fast while at the same time ensuring supreme software quality. Additionally, there are also implications for academic research. The engineering process model is accompanied by directions concerning the involved artifacts, roles, and interdependencies, and thereby lays the foundation for future research. This may include a detailed specification of the different roles and their required profiles.

Conclusions, limitations and future research
In this paper, we develop an integrative process model for smart contract engineering and describe its activities, roles, and artifacts. This model lays the foundation for further smart contract development, which has the potential to revolutionize many different industries. We argue that conventional software engineering process models do not provide adequate support for the trustless, append-only, and decentralized environment in which smart contracts are executed. Traditional process models do not account for the immutability of smart contracts after they are submitted, because they assume a (mostly) frictionless transition between software releases and that modifications of existing software releases are possible. Our smart contract engineering process accounts for these peculiarities of blockchain-based software development and consists of five sequential phases: (1) conceptualization, (2) implementation, (3) approval, (4) execution, and (5) finalization. These phases are derived from the properties of the underlying blockchain ecosystem. We propose new directions for smart contract engineering that focus on collaboration among domain experts, testing activities, quality assurance, and specialized workflow tools.
Currently, we see two major limitations of this research that deserve further attention. First, there are no validated measurements for the concepts of the process activities. An attempt was made to use existing process model artifacts and to make as few changes as possible. However, the construct validity of these artifacts cannot currently be guaranteed. Second, due to a lack of established best practices in smart contract engineering, an empirical evaluation of the hypothesized artifacts is not currently feasible.
Future research, therefore, needs to investigate if and how the proposed engineering process model can be tailored to and with different software engineering methodologies (e.g., Scrum, V-model). In this context, research could investigate how the development of smart code can be integrated with the development of traditional software code, as well as how risk analysis can support this integration. Furthermore, it is necessary to integrate this framework with existing work on testing and quality assurance in software engineering. An important aspect here is especially the role of simulation for quality assurance. The behavioral aspects of smart contract engineering have not yet received enough attention. While data is sparse, we have seen DevOps and "full-stack" software engineering behavior with many interviewees and many interesting patterns (e.g., randomness patterns or oracle patterns) that have been adapted from these and related disciplines that warrant future research. Furthermore, there is a pending need to cover the increasing demand for inter-TADDL transactions and developing secure applications that rely on more than one TADDL. Combining various approaches will lead to new insights into how best to cope with the challenges of modern blockchain-based software development and how smart contracts can be used to create viable business models.
Laying the foundation for smart contract development: an… are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creat iveco mmons .org/licen ses/by/4.0/.