Smart Contract Templates: Foundations, Design and Research - Smart Contract Designs

Authors: (1) Christopher D. Clack, Centre for Blockchain Technologies, Department of Computer Science, University College London; (2) Vikram A. Bakshi, Investment Bank CTO Office, Barclays; (3) Lee Braine, Investment Bank CTO Office, Barclays. Table of Links Abstract and 1 Introduction 2 Foundations and 2.1 Terminology — “smart contracts” 2.2 Automation 2.3 Enforceability 2.4 The semantics of contracts 3 Smart Contract Templates 3.1 Templates and Parameters 3.2 The design landscape for Smart Contract Templates 4 Summary and Further Work and References 3.2 The design landscape for Smart Contract Templates In this section, we consider the possible areas for future development of Smart Contract Templates. We do this by considering three areas of development relating to: (i) the sophistication of parameters, (ii) the standardisation of code, and (iii) long-term research. 3.2.1 Increasing the sophistication of parameters Most parameters in existing templates have simple types, such as date, number, etc. These are “base” or “primitive” types[4] and, as an example, Figure 3 illustrates the identification of a date in a master agreement; once highlighted and annotated, the name (“Agreement Date”), type (“Date”) and value (“16-Mar-2016”) of this parameter will be passed to the code. It is not necessary for parameters to be restricted to base types. It is very likely that values of more complex types, such as lists, will also need to be transferred to the code. The passing of parameters to the code is necessary because of the desire to use standardised code. The number of parameters, and the complexity of the types of those parameters, will typically increase as the code becomes more generic. Beyond parameters with base types and more complex types such as lists, parameters can also be expressions containing references to other parameter names. Unless those other parameter names are defined within the expression, the expression is effectively a function. Where a function is passed as a parameter, this is known as a “higher-order” parameter and the receiving code is known as a “higher-order” function.[5] An example of a higher-order parameter is illustrated in Figure 4 where some business logic in the legal prose has been highlighted and annotated to be a parameter with name “DailyInterestAmount” of type “Expression”[6] and with a value that is an encoding of the business logic in a format that is easily understandable by a computer. This business logic refers to three things whose values are unknown. The first two are simple: “the amount of cash in such currency on that day” (in the expression this is called CashAmount), and “the relevant Interest Rate in effect for that day” (in the expression this is called InterestRate). The third occurs in the phrase “in the case of pounds sterling”, which requires some analysis to determine that it is referring to the prevailing currency (hence the name Currency used in the expression) and that the normal abbreviation for pounds sterling is “GBP”. Since this expression contains three parameter names whose values are unknown, it will be stored in the set of code parameters as a function taking three arguments (CashAmount, InterestRate, and Currency) and returning a numeric value that is the result of the expression. When business logic is converted into an expression this may involve the creation of new parameter names (e.g. a new name for the expression itself, and for unknown quantities). Sometimes the business logic may refer to a name that is already defined as a parameter, and sometimes it may refer to a value provided by an “oracle” — i.e. a value, such as an interest rate, that is provided from a trusted source of data and is available to the code while it is running. The use of parameters may not only support greater standardisation of code. In the far future, we may see an increasing use of a formally structured style of expression embedded in legal prose; if all business logic in legal prose could be replaced with arithmetical or logical expressions, such as the higher-order parameters discussed in the previous paragraph, this should lead to reduced ambiguity in legal prose and fewer errors. The adoption of formal logic into legal prose would require such formal constructs to gain acceptance in the courts and to be admissible as evidence of the intentions of the parties. Figure 5 illustrates how the sophistication of parameters and their role in Smart Contract Templates may evolve in the future. 3.2.2 Increasing the use of common standardised code In the previous subsection, we observed that the passing of parameters to smart contract code is necessary because of the desire to use standardised code. This is important for efficiency reasons as different smart contract code would otherwise have to be built, tested, certified and deployed for every different trade. The effort is reduced if such code can be standardised with parameters being passed to each invocation of that code. This drives a desire for greater genericity of code, which can be enabled by passing more parameters, and/or more sophisticated parameters (with more complex types). Yet there remains the problem that each bank currently manages its own distinct codebases. If smart contract code could be common (i.e. shared) then it could be built, tested and certified once — and then utilised by every counterparty. We envisage that the potential economic benefits of using common (shared) code will drive greater adoption in the future. One possible evolutionary route could build upon the use of common utility functions — programs that are already very nearly identical in all counterparties. As the potential economic benefits become clearer and the supporting technologies mature, the size and importance of such common code could increase until, eventually, common business logic may become standardised smart contract code. Figure 6 illustrates how the sharing of code may evolve in the future. 3.2.3 Long-term research challenges Several research challenges concerning smart contracts, shared ledgers, and blockchains are currently being explored in academia. Financial institutions are providing input and inspiration by highlighting relevant business challenges in technology and operations. A good example is the potential to increase straight-through processing. Currently, lawyers draft legal contracts, which are then negotiated and changed by possibly other teams of lawyers, and then operations staff inspect the contract documents and/or other materials[7] to identify the parameters that are then passed to code that may have been written some time ago. This raises several issues: • Can we be absolutely certain of the meaning of the contract? Are all parties truly agreed on the meaning of the contract, or do they instead each have a subtly different understanding of what the contract means? • Can we be certain that all code parameters have been identified, and that each is operationally relevant? And can we be certain that their names, types and values have been faithfully transcribed? • After the parameters have been passed to the code, and the code runs, can we be certain that the code will be faithful to the semantics of the operational aspects of the contract? And will it do so under all conditions? A possible solution would be to develop a formal language in which to write legal documents — i.e. contract documents — such that the semantics would be clear and the code parameters could automatically be identified and passed to standardised code (alternatively, new code could be generated). This formal language would: derive a number of important qualities from well-designed computer programming languages, such as a lack of ambiguity, and a compositional approach where the meaning of any clause can be clearly deduced without reading the rest of the document; and be simple and natural to use, to such an extent that a lawyer could draft contracts using this formalism instead of using traditional legal language. The former aspect has already received considerable attention in academia (see survey in [10]) and beyond (e.g. the open-source Legalese project). In contrast, the latter aspect is likely to be by far the greater challenge. Another challenge is whether such a contract, written in a computer-like language, would be admissible in court as a true and faithful representation of the intentions of the parties. Issues of signature and tamper-evident documents are easily solved, yet whether a court would accept the definitions of the meanings of phrases in such a contract is not immediately clear. As illustrated in Figure 7, this problem could be solved in two ways: Initially, the language could generate a document version of the contract in a more “natural” legal style, with the expectation that this document would be admissible in court. Eventually, further research in domain-specific languages and law could result in a new formalism itself being admissible in court. 3.2.4 Future developments and initial requirements The areas of future development described in the preceding sections are brought together in Figure 8, illustrating the potential evolution of aspects of legally-enforceable smart contracts. This complexity motivated us to sketch the following initial set of requirements for the design landscape of storage, processing and transmission of smart legal contracts: • support both legal prose and parameters; • support structured data formats such as XML, FpML, etc.; • support the instantiation of multiple agreements from a single template; • permit parameters to be defined in one document, given a value in a second document, and used in a third document; • support contracts that comprise multiple documents; • support a wide range of parameter types, including higher-order parameters in future; • support the extraction of code parameters for transmission to the smart contract code; • support increasing standardisation and sharing of common code; • support increasing automation of, and interaction between, legal prose and code; • support multiple execution platforms; • support Ricardian Contracts (and therefore, for example, support digital signing of contracts and the construction of a cryptographic hash of the contract). We aim to report on progress in a subsequent paper, including essential requirements and design options of potential formats for the storage and transmission of smart legal contracts. This paper is available on arxiv under CC BY 4.0 DEED license. [4] https://en.wikipedia.org/wiki/Data_type [5] https://en.wikipedia.org/wiki/Higher-order_function [6] In a conventional type system this expression would have an associated function type such as: (Decimal, Decimal, Currency) -> Decimal [7] Other supporting materials may include confirmations, emails, facsimiles, telephone recordings etc. Authors: (1) Christopher D. Clack, Centre for Blockchain Technologies, Department of Computer Science, University College London; (2) Vikram A. Bakshi, Investment Bank CTO Office, Barclays; (3) Lee Braine, Investment Bank CTO Office, Barclays. Authors: Authors: (1) Christopher D. Clack, Centre for Blockchain Technologies, Department of Computer Science, University College London; (2) Vikram A. Bakshi, Investment Bank CTO Office, Barclays; (3) Lee Braine, Investment Bank CTO Office, Barclays. Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2 Foundations and 2.1 Terminology — “smart contracts” 2 Foundations and 2.1 Terminology — “smart contracts” 2.2 Automation 2.2 Automation 2.3 Enforceability 2.3 Enforceability 2.4 The semantics of contracts 2.4 The semantics of contracts 3 Smart Contract Templates 3 Smart Contract Templates 3.1 Templates and Parameters 3.1 Templates and Parameters 3.2 The design landscape for Smart Contract Templates 3.2 The design landscape for Smart Contract Templates 4 Summary and Further Work and References 4 Summary and Further Work and References 3.2 The design landscape for Smart Contract Templates In this section, we consider the possible areas for future development of Smart Contract Templates. We do this by considering three areas of development relating to: (i) the sophistication of parameters, (ii) the standardisation of code, and (iii) long-term research. 3.2.1 Increasing the sophistication of parameters Most parameters in existing templates have simple types, such as date, number, etc. These are “base” or “primitive” types[4] and, as an example, Figure 3 illustrates the identification of a date in a master agreement; once highlighted and annotated, the name (“Agreement Date”), type (“Date”) and value (“16-Mar-2016”) of this parameter will be passed to the code. It is not necessary for parameters to be restricted to base types. It is very likely that values of more complex types, such as lists, will also need to be transferred to the code. The passing of parameters to the code is necessary because of the desire to use standardised code. The number of parameters, and the complexity of the types of those parameters, will typically increase as the code becomes more generic. Beyond parameters with base types and more complex types such as lists, parameters can also be expressions containing references to other parameter names. Unless those other parameter names are defined within the expression, the expression is effectively a function. Where a function is passed as a parameter, this is known as a “higher-order” parameter and the receiving code is known as a “higher-order” function.[5] An example of a higher-order parameter is illustrated in Figure 4 where some business logic in the legal prose has been highlighted and annotated to be a parameter with name “DailyInterestAmount” of type “Expression”[6] and with a value that is an encoding of the business logic in a format that is easily understandable by a computer. This business logic refers to three things whose values are unknown. The first two are simple: “the amount of cash in such currency on that day” (in the expression this is called CashAmount), and “the relevant Interest Rate in effect for that day” (in the expression this is called InterestRate). The third occurs in the phrase “in the case of pounds sterling”, which requires some analysis to determine that it is referring to the prevailing currency (hence the name Currency used in the expression) and that the normal abbreviation for pounds sterling is “GBP”. Since this expression contains three parameter names whose values are unknown, it will be stored in the set of code parameters as a function taking three arguments (CashAmount, InterestRate, and Currency) and returning a numeric value that is the result of the expression. When business logic is converted into an expression this may involve the creation of new parameter names (e.g. a new name for the expression itself, and for unknown quantities). Sometimes the business logic may refer to a name that is already defined as a parameter, and sometimes it may refer to a value provided by an “oracle” — i.e. a value, such as an interest rate, that is provided from a trusted source of data and is available to the code while it is running. The use of parameters may not only support greater standardisation of code. In the far future, we may see an increasing use of a formally structured style of expression embedded in legal prose; if all business logic in legal prose could be replaced with arithmetical or logical expressions, such as the higher-order parameters discussed in the previous paragraph, this should lead to reduced ambiguity in legal prose and fewer errors. The adoption of formal logic into legal prose would require such formal constructs to gain acceptance in the courts and to be admissible as evidence of the intentions of the parties. Figure 5 illustrates how the sophistication of parameters and their role in Smart Contract Templates may evolve in the future. 3.2.2 Increasing the use of common standardised code In the previous subsection, we observed that the passing of parameters to smart contract code is necessary because of the desire to use standardised code. This is important for efficiency reasons as different smart contract code would otherwise have to be built, tested, certified and deployed for every different trade. The effort is reduced if such code can be standardised with parameters being passed to each invocation of that code. This drives a desire for greater genericity of code, which can be enabled by passing more parameters, and/or more sophisticated parameters (with more complex types). Yet there remains the problem that each bank currently manages its own distinct codebases. If smart contract code could be common (i.e. shared) then it could be built, tested and certified once — and then utilised by every counterparty. We envisage that the potential economic benefits of using common (shared) code will drive greater adoption in the future. One possible evolutionary route could build upon the use of common utility functions — programs that are already very nearly identical in all counterparties. As the potential economic benefits become clearer and the supporting technologies mature, the size and importance of such common code could increase until, eventually, common business logic may become standardised smart contract code. Figure 6 illustrates how the sharing of code may evolve in the future. 3.2.3 Long-term research challenges Several research challenges concerning smart contracts, shared ledgers, and blockchains are currently being explored in academia. Financial institutions are providing input and inspiration by highlighting relevant business challenges in technology and operations. A good example is the potential to increase straight-through processing. Currently, lawyers draft legal contracts, which are then negotiated and changed by possibly other teams of lawyers, and then operations staff inspect the contract documents and/or other materials[7] to identify the parameters that are then passed to code that may have been written some time ago. This raises several issues: • Can we be absolutely certain of the meaning of the contract? Are all parties truly agreed on the meaning of the contract, or do they instead each have a subtly different understanding of what the contract means? • Can we be certain that all code parameters have been identified, and that each is operationally relevant? And can we be certain that their names, types and values have been faithfully transcribed? • After the parameters have been passed to the code, and the code runs, can we be certain that the code will be faithful to the semantics of the operational aspects of the contract? And will it do so under all conditions? A possible solution would be to develop a formal language in which to write legal documents — i.e. contract documents — such that the semantics would be clear and the code parameters could automatically be identified and passed to standardised code (alternatively, new code could be generated). This formal language would: derive a number of important qualities from well-designed computer programming languages, such as a lack of ambiguity, and a compositional approach where the meaning of any clause can be clearly deduced without reading the rest of the document; and be simple and natural to use, to such an extent that a lawyer could draft contracts using this formalism instead of using traditional legal language. derive a number of important qualities from well-designed computer programming languages, such as a lack of ambiguity, and a compositional approach where the meaning of any clause can be clearly deduced without reading the rest of the document; and derive a number of important qualities from well-designed computer programming languages, such as a lack of ambiguity, and a compositional approach where the meaning of any clause can be clearly deduced without reading the rest of the document; and be simple and natural to use, to such an extent that a lawyer could draft contracts using this formalism instead of using traditional legal language. be simple and natural to use, to such an extent that a lawyer could draft contracts using this formalism instead of using traditional legal language. The former aspect has already received considerable attention in academia (see survey in [10]) and beyond (e.g. the open-source Legalese project). In contrast, the latter aspect is likely to be by far the greater challenge. Another challenge is whether such a contract, written in a computer-like language, would be admissible in court as a true and faithful representation of the intentions of the parties. Issues of signature and tamper-evident documents are easily solved, yet whether a court would accept the definitions of the meanings of phrases in such a contract is not immediately clear. As illustrated in Figure 7, this problem could be solved in two ways: Initially, the language could generate a document version of the contract in a more “natural” legal style, with the expectation that this document would be admissible in court. Eventually, further research in domain-specific languages and law could result in a new formalism itself being admissible in court. Initially, the language could generate a document version of the contract in a more “natural” legal style, with the expectation that this document would be admissible in court. Initially, the language could generate a document version of the contract in a more “natural” legal style, with the expectation that this document would be admissible in court. Eventually, further research in domain-specific languages and law could result in a new formalism itself being admissible in court. Eventually, further research in domain-specific languages and law could result in a new formalism itself being admissible in court. 3.2.4 Future developments and initial requirements The areas of future development described in the preceding sections are brought together in Figure 8, illustrating the potential evolution of aspects of legally-enforceable smart contracts. This complexity motivated us to sketch the following initial set of requirements for the design landscape of storage, processing and transmission of smart legal contracts: • support both legal prose and parameters; • support structured data formats such as XML, FpML, etc.; • support the instantiation of multiple agreements from a single template; • permit parameters to be defined in one document, given a value in a second document, and used in a third document; • support contracts that comprise multiple documents; • support a wide range of parameter types, including higher-order parameters in future; • support the extraction of code parameters for transmission to the smart contract code; • support increasing standardisation and sharing of common code; • support increasing automation of, and interaction between, legal prose and code; • support multiple execution platforms; • support Ricardian Contracts (and therefore, for example, support digital signing of contracts and the construction of a cryptographic hash of the contract). We aim to report on progress in a subsequent paper, including essential requirements and design options of potential formats for the storage and transmission of smart legal contracts. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv [4] https://en.wikipedia.org/wiki/Data_type [5] https://en.wikipedia.org/wiki/Higher-order_function [6] In a conventional type system this expression would have an associated function type such as: (Decimal, Decimal, Currency) -> Decimal [7] Other supporting materials may include confirmations, emails, facsimiles, telephone recordings etc.