Smart contracts (Szabo, 1997) are pieces of software which regulate the exchange of resources (assets—including money—and services) between participants. The execution of smart contracts can take advantage of blockchain technologies, which allow mutually untrusted participants to agree on a global state, without the intermediation of a trusted authority. Smart contracts have been redefined and popularized by Ethereum, a public permissionless blockchain through which users can exchange a cryptocurrency, and tokens representing a multitude of other crypto-assets. Ethereum features a Turing-equivalent programming language for writing code that is stored on the blockchain, and which is called smart contract in Ethereum's terminology. Once a smart contract is published, its code cannot be changed, and anyone can interact with it. Hence, adversaries may try to exploit security vulnerabilities in the contract to steal crypto-assets, or cause other harm. The history of Ethereum is studded with attacks to its smart contracts, which overall have caused money losses in the order of hundreds of millions of dollars.

Could these attacks have been avoided? To answer this question, we must consider the vulnerabilities that have made them possible. These vulnerabilities are mainly attributable to design issues in the programming language used to write smart contracts (Luu et al., 2016; Atzei et al., 2017). One of the tools that have been used by software engineers to address similar issues is that of software contracts. Intuitively, a software contract is a formal specification of the behavior of a software component, which describes the duties that must be fulfilled by the users of the component, as well as the obligations of the component to its callers.

The main similarity between software contracts and smart contracts is that both are a form of commitment between a piece of software and its callers. For software contracts, the commitment is that the piece of software respects some properties, provided that the caller feeds it with correct inputs. For smart contracts, the commitment is somehow weaker: it just requires that all the executions of the piece of software are coherent with its semantics (i.e., code cannot be changed).

This difference is due to the diverse assumptions on the execution environment. In software contracts, the caller is typically assumed to control the environment where the piece of software is run: so, coherence with the semantics can be taken for granted. Instead, in smart contracts, the piece of software is concurrently executed by a network of mutually untrusted nodes, which may have economic incentives to cheat. In this setting, guaranteeing coherence with the semantics is not trivial: complex network protocols are in order to ensure that the only rational behavior for a node is not to cheat. The most significant outcome of the Bitcoin protocol was indeed to show that trusted executions in trustless environments were possible.

Other remarkable differences between software contracts and smart contracts emerge. While software contracts may describe arbitrary properties of a software component, smart contracts typically define the rules through which participants exchange resources (crypto-currencies or other crypto-assets). This is why the participants of a smart contract can be considered as adversaries, as they may try to steal or freeze the resources controlled by the contract. Instead, in most incarnations of software contracts (with the exceptions discussed below), participants are assumed to behave honestly.

Given the above differences, which ideas from software contracts can be applied to make smart contracts more reliable? In this paper, we discuss some possible research directions to answer this question. We start by providing a brief overview of software contracts, and then we discuss a few research perspectives.

The idea of software contract dates back at least to Hoare's seminal paper (Hoare, 1969), that introduced the axiomatic approach to computer programming. Since then, software contracts have been developed over the past three decades both in the academy and in the industry. In Hoare's approach, the semantics of a programming language is formalized as a set of axioms, and the behavior of a program is given in terms of a precondition and a postcondition. These are logical assertions which describe, respectively, the properties that must hold before and after executing the program. Assertions can be interpreted as contracts: the precondition establishes the obligations that the caller must fulfill before running the program, while the postcondition dictates the obligations of the program. For instance, for a program which merges two arrays, the precondition requires that the values of two input arrays are sorted, while the postcondition is that the output array contains, sorted, the elements of the two arrays in input.

Although the original goal of the axiomatic approach was to prove the correctness of programs, in software development practice the use of assertions as contracts has become widespread for a weaker goal, that is to make program testing more rigorous. Assertions are spread over large programs, dynamically checked in massive tests, and possibly removed before the actual deployment. In particular, the design by contract principle fostered by Meyer since the late eighties (Meyer, 1986, 1992) requires that the interfaces between modules of safety-critical software systems should be governed by contracts. These contracts are decoupled from the rest of the program logic, so that they can be easily discharged after the testing phase. Another landmark feature of contracts is that they enable to assign blame in case of contract violations. Assume that a program module has a precondition P and a postcondition Q. During the execution of the program, if P is violated then the blame is assigned to the caller; instead, if P is respected but Q is violated, then the blame is assigned to the callee. The first programming language with native support for design by contract was Eiffel, in the object-oriented paradigm (Meyer, 1991). Since then, almost all mainstream programming languages offer some support for contracts, either natively (e.g., Scala and Clojure), or through external libraries (e.g., JML for Java, Code contracts for C#).

In the functional paradigm, where program modules can be higher-order functions, contract checking and blame assignment are more complex than in the procedural and object-oriented paradigms. For instance, assume that a function g takes as input a function f from integers to integers, and produces an integer as output. While the postcondition of g can be a first-order predicate R on integers, its precondition cannot: rather, it should consist of a predicate P restricting the acceptable arguments passed to f, and a predicate Q restricting its possible outputs. So, the contract of f can be rendered as a function P → Q, and that of g as a higher-order function (P → Q) → R. By decidability issues it is not possible, in general, to determine whether f respects its contract or not when g is applied. A possible way to tackle this problem, first explored in Findler and Felleisen (2002), is to check f's contract when f is applied. At that moment it is possible to know if the argument passed to f respects P, and if the value produced by the application of f respects Q, and to assign the blame accordingly. Findler and Felleisen's seminal work has given rise to a proliferation of studies on higher-order contracts, leading to a wide variety of languages and analysis techniques. The most notable functional language supporting the design by contract approach is Racket (Flatt and PLT, 2010), a dialect of Scheme with higher-order assertions.

Going beyond the incarnation of contracts as pre- and post-conditions on program modules, Beugnard et al. (1999) proposed a taxonomy of software contracts consisting of four kinds of contracts:

In the setting of concurrent programming models, contracts are used to describe the possible sequences of messages that can be processed by concurrent components (Hüttel et al., 2016). For instance, the contract of a payment service may require that the service first receives a cardDetails message, then either a proceed or an abort message; in case of proceed, the service sends back to the client either a message paymentOk or a message paymentError. Using a syntax inspired to that of Web Service contracts (Castagna et al., 2009), we can express this contract as follows:

where ? denotes a received message, ! a sent message, . sequencing, + a choice made by the client, and ⊕ a choice made by the service. In this setting, a typical goal is to determine if two contracts are compliant: intuitively, compliance between contracts guarantees the absence of certain kinds of communication errors in any execution of services which respect their contracts. Many different notions of compliance can be used for this purpose, based e.g., on deadlock-freedom, on may- and must-testing relations, etc. (Bordeaux et al., 2004; Bartoletti et al., 2015b).

Starting from Honda's seminal paper on dyadic session types (Honda, 1993), many works address the problem of statically verifying if a service (formally specified in some calculus for concurrency) respects its contract. The overall result is that if two services are statically verified to respect their contracts, and these contracts are compliant, then no communication errors can happen at runtime. Extensions of this kind of results to the multi-party setting have been studied by Honda et al. (2008) and many subsequent works.

The work (Bocchi et al., 2010) nicely integrates assertion-based contracts with concurrency contracts. The idea is to project a service choreography decorated with assertions to a set of local assertions: services abiding these local assertions are guaranteed to have correct interactions at run time. A dual approach is to start from an arbitrary set of services, and to dynamically compose those with compliant contracts (Bartoletti et al., 2012). A remarkable difference between this approach and the other approaches to concurrency contracts discussed before is that the latter assume that all services are trusted, in that they will not change their code after deployment (as this would invalidate their static verification). Instead, in Bartoletti et al. (2012) this assumption can be limited to a subset of services, while all the others are considered as adversaries. Under this weaker hypotheses it is no longer possible to ensure the absence of contract breaches, as an adversary could diverge from the declared contract, or just stop cooperating at any time. Rather, the goal of the static analysis is to guarantee that the trusted services always respect their contracts, whatever the behavior of the adversaries. This property, called honesty, becomes relevant when services interact through communication middlewares which sanction those not abiding to their contracts (Bartoletti et al., 2015a). In this setting, honest services are guaranteed to never be sanctioned.

We now discuss some possible research directions on connecting software contracts with smart contracts.

Current designs of smart contract languages seem to have been influenced more by marketing principles like “time-to-market,” than by technical principles like reliability and security. This paper discusses some research directions to incorporate design by contract principles in the development of smart contracts.

To conclude, I would like to quote C.A.R. Hoare from his Turing Award Lecture (Hoare, 1981). In this lecture, Hoare was criticizing the design of the programming language PL/I, but I believe that his warning against a poor software design is always appropriate, also in the setting of smart contracts:

The author confirms being the sole contributor of this work and has approved it for publication.

The author declares that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.