Definition

There is no consensus on a standard definition of smart contracts. It is essential to define what a smart contract is, and the following is my attempt to provide a generalized definition of a smart contract:

A smart contract is a secure and unstoppable computer program representing an agreement that is automatically executable and enforceable.

Dissecting this definition further reveals that a smart contract is, in fact, a computer program that is written in a language that a computer or target machine can understand. Also, it encompasses agreements between parties in the form of business logic. Another fundamental idea is that smart contracts are automatically executed when certain conditions are met. They are enforceable, which means that all contractual terms are executed as defined and expected, even in the presence of adversaries.

Enforcement is a broader term that encompasses traditional enforcement in the form of law, along with the implementation of specific measures and controls that make it possible to execute contract terms without requiring any mediation. It should be noted that true smart contracts should not rely on traditional methods of enforcement. Instead, they should work on the principle that code is law, meaning that there is no need for an arbitrator or a third party to control or influence the execution of the smart contract. Smart contracts are self-enforcing as opposed to legally enforceable. This idea might be regarded as a libertarian's dream, but it is entirely possible and is in line with the true spirit of smart contracts.

Moreover, they are secure and unstoppable, which means that these computer programs are required to be designed in such a fashion that they are fault-tolerant and executable in a reasonable amount of time. These programs should be able to execute and maintain a healthy internal state, even if external factors are unfavorable. For example, imagine a typical computer program that is encoded with some logic and executes according to the instruction coded within it. However, if the environment it is running in or external factors it relies on deviate from the normal or expected state, the program may react arbitrarily or simply abort. It is essential that smart contracts be immune to this type of issue.

Secure and unstoppable may well be considered requirements or desirable features but it will provide more significant benefits in the long run if security and unstoppable properties are included in the smart contract definition from the beginning. This will allow researchers to focus on these aspects from the start and will help to build strong foundations on which further research can then be based. There is also a suggestion by some researchers that smart contracts need not be automatically executable; instead, they can be what's called automatable, due to manual human input required in some scenarios. For example, a manual verification of a medical record might be required by a qualified medical professional. In such cases fully automated approaches may not work best. While it is true that in some cases human input and control is desirable, it is not necessary; and, for a contract to be truly smart, in the author's opinion, it has to be fully automated. Some inputs that need to be provided by people can and should also be automated via the use of Oracles. Oracles will be discussed later in this chapter in greater detail.

Smart contracts usually operate by managing their internal state using a state machine model. This allows development of an effective framework for programming smart contracts, where the state of a contract is advanced further based on some predefined criteria and conditions.

There is also on-going debate on the question of whether the code is acceptable as a contract in a court of law. A smart contract is different in presentation from traditional legal prose, albeit they do represent and enforce all contractual clauses but a court of law does not understand the code. This dilemma raises several questions about how a smart contract can be legally binding: can it be developed in such a way that it is readily acceptable and understandable in a court of law? How can dispute resolution be implemented within the code, and is it possible? Moreover, regulatory and compliance requirements is another topic that needs to be addressed before smart contracts can be used as efficiently as traditional legal documents.

Even though smart contracts are named smart, they in fact only do what they have been programmed to do, and that is fine because this very property of smart contracts ensures that smart contracts produce same output every time they are executed. This deterministic nature of smart contracts is highly desirable in blockchain platforms due to consistent consensus requirements. This means that smart contracts are not really smart, they are simply doing what they are programmed to do.

Now this gives rise to a problem whereby a large gap between real world and blockchain world emerges. In this situation, natural language is not understandable by the smart contract, and similarly, the code is not comprehensible to the natural world. So, a few questions arise, how real-life contracts can be deployed on a blockchain? How can this bridge between the real world and smart contract world be built?

The preceding questions open up various possibilities, such as making a smart contract code readable not only by machines but also by people. If humans and machines can both understand the code written in a smart contract it might be more acceptable in legal situations, as opposed to just a piece of code that no-one understands except for programmers. This desirable property is an area ripe for research, and a large research effort has been expended in this area to answer questions around semantics, meaning, and interpretation of a contract.

Some work has already been done to describe natural language contracts formally by combining both smart contract code and natural language contract through linking contract terms with machine understandable elements. This is achieved using a markup language. An example of this type of markup language is called Legal Knowledge Interchange Format (LKIF), which is an XML schema for representing theories and proofs. It was developed under the ESTRELLA Project in 2008.

Smart contracts are inherently required to be deterministic. This property will allow a smart contract to be run by any node on a network and achieve the same result. If the result differs even slightly between nodes, then consensus cannot be achieved, and a whole paradigm of distributed consensus on blockchain can fail. Moreover, it is also desirable that the contract language itself is deterministic, thus ensuring integrity and stability of the smart contracts. Deterministic in the sense that there are no non-deterministic functions used in the language, which can produce different results on various nodes.

Let's take, for example, various floating-point operations calculated by various functions in a variety of programming languages can produce different results in different runtime environments. Another example is some math functions in JavaScript, which can produce different results for the same input on different browsers, and which can, in turn, lead to various bugs. This is highly undesirable in smart contracts because if results are inconsistent between nodes, then consensus will never be achieved.

A deterministic feature ensures that smart contracts always produce the same output for a specific input. In other words, programs, when executed, produce a reliable and accurate business logic that is entirely in line with the requirements programmed in the high-level code.

In summary, a smart contract has the following four properties:

• Automatically executable
• Enforceable
• Semantically sound
• Secure and unstoppable

The first two properties are required as a minimum, whereas the latter two may not be required or implementable in some scenarios and can be relaxed. For example, a financial derivatives contract does not perhaps need to be semantically sound and unstoppable but should at least be automatically executable and enforceable at a fundamental level. On the other hand, a title deed needs to be semantically sound and complete, therefore, for it to be implemented as a smart contract, the language must be understood by both computers and people. Ian Grigg addressed this issue of interpretation with his invention of Ricardian contracts, which we will look at in more detail in the next section.