Creating a Smart Contract Registry

This post is the first in a series to describe a number of important methods that are needed in creating commercially viable contracts in Bitcoin (BCH).

We will cover:

• How a contract, or structured control condition, can be published and certified on the Blockchain in the form of a token;
• How this token will be able to reference an external repository holding a complete representation of the contract;
• How a contract can be structured in a manner to support wholly or partly automated enforcement;
• How interested parties can enquire as to the current state of the contract;
• How to configure sub-contracts, or sub-conditions, to contracts that can be derived from the parent contract.

In addition, this post series describes one option to provide the following:

• Defining the lifetime for time-bound contracts
• How the contract can be automatically closed or rolled over into a new contract;
• How the contract to be manually closed or fulfilled;

Overview

One of the key problems with modern contract management is that it tends to be massively ad-hoc with local stores and copies of contracts that are manually maintained and managed. In addition, contracts written in natural language are open to interpretation which frequently relies on specialist lawyers to unpick and explain.

This presents a mechanism to hold a secure, public record of contracts in a manner that allows their validity to be determined and the details released to authorised entities.

Key Requirements

The key requirements include the ability to:

• Formally define a contract in a manner that can be formally interpreted and implemented by a machine, as well as converted into natural language;
• Publish a contract to an audience where the details of the contract can be restricted to authorised entities only, but the knowledge of the existence of the contract is publicly available information. In other words, it can be public knowledge that there is a contract between A and B that anyone can verify, but anything other than its existence is restricted to authorised parties (normally A and B only).i.e. encrypted data on the DHTs (e.g. contract definitions etc.)
• Provide a mechanism that allows contracts to be time-bound (i.e. they expire after a certain time or on a given date); condition bound (i.e. they expire once the deliverable specified within the contract has been fulfilled) or open-ended (i.e. they continue to roll on with a notice period to terminate them).
• Provide a mechanism to serve notice to terminate that contract in a public fashion. e.g. Using nLockTime + CLTV in a spend transaction to ‘enact’ the expiration.
• Provide a mechanism to structure a hierarchy of sub-contracts in a deterministic manner to allow control over different aspects of the contract to be partitioned. For example, on a technology programme, the requirements phase may have a different set of control triggers than the development phase. i.e. chain of hash-linked DHTs.

Key Benefits

The process defined within this paper will drastically simplify the ability of contracting parties to manage and maintain their contracts. More importantly, the ability to publicly specify control conditions and triggers means that it is materially simpler — in the event of a dispute — to agree the state of the contract.

Technical Specification

A smart contract enables contract conditions to be either wholly or to a significant degree automatically enforced. A smart contract built into the Blockchain can be enforced through logic built directly into the bitcoin transaction (i.e. within the locking/unlocking scripts) and/or through external agents (‘oracles’ or ‘bots’). In addition, some contractual conditions can be enforced through other bitcoin transaction elements such as the nLockTime field. For example, in this document we describe an embodiment where the contract remains in effect for as long as there is a valid unspent transaction output representing the contract. It will be appreciated that this condition can be enforced by other mechanism described herein, based on the stipulations in the contract itself (e.g. via an oracle).

However, using this simple principle in addition to other features of white papers allows complex scenarios and activities to occur. Effectively, the context around that unsigned transaction output, and the associated metadata within the redeem script that allows it to be spent, allows it to act as a pointer or reference to an off-chain repository of the formal details of the contract.

Using standard Bitcoin features such as CheckLockTimeVerify allows the contract to have a formal expiry at a point in the future that is a matter of secure public record; the same construct plus the deterministic sub-key model detailed in the granted patent “Determining a common secret for the secure exchange of information and hierarchical, deterministic cryptographic keys” would allow the same CLTV model to automatically roll-on the contract unless explicitly cancelled.

Again, using one of the many tokenisation mechanisms available for Bitcoin Cash that we shall cover in a set of followup posts would allow this smart contract to reference the repository where the full details of the contract are held. Using the deterministic sub-key model plus the tokenisation mechanism allows sub-contracts or schedules against contracts to be created. Using a suite of external oracles, as we shall demonstrate in after this and the tokenisation posts have been listed, allows contract conditionality to be built in and modified by trusted third-parties.

Key Terms

This technical specification uses the following terms throughout to define key concepts and components.

Contract Model

Full details of the model are developed in an extensible model. The basic elements of the model are as follows:

• A codification scheme that allows a complete description of any type of contract. The scheme may be a new construct or may use an existing facility such as XBRL, XML, JSON (etc.);
• A DFA (Deterministic Finite Automaton) to implement the Contract that can be fully defined within the codification scheme. This will be made up of:

o A set of parameters, and where to source those parameters;

o A set of state definitions

o A set of transitions between the states, including the trigger for the transition and the rules followed during the transition.

o Rules definition table

• Definitions of the specific parameters for this instance of the Contract;
• Mechanisms to secure and protect the Contract;
• A ‘browser’ to enable the contact to be made human-readable in formal legal language; and
• A ‘compiler’ to convert the codification scheme into Oracle code and / or Bitcoin script.

Implementing the Contract

When the Contract is registered in a repository, the associated URI and hash can be used in accordance with using metadata within a Blockchain transaction to associate the transaction on the chain with the controlling contract itself.

There are a number of different methods as to how the DFA contained within the contract definition is implemented:

• As a Blockchain transaction (or sequence of transactions). There are a number of separate white papers that cover how to implement various forms of DFA directly within the Bitcoin scripting language;
• As an Oracle process (or sequence of Oracle processes). We will cover the basic process for defining and running an Oracle to monitor the Blockchain (and other external sources) in later posts.
• As a set of instructions for a smart Wallet. In this content, a smart wallet is effectively simply a local Oracle process which can handle certain contract conditions (such as assignment of transaction inputs to a Blockchain transaction).

Note that a given contract definition can be implemented as a mixture of the above three mechanisms, where each contract state transition is effectively a separate implementation.

There are a number of methods of creating the implementation from a contract definition, including hand-crafting the relevant transactions / code.

It is possible to define a compiler process that will automatically generate the relevant code outputs from the contract definition itself.

It is also important that a human-readable version of the contract can be rendered upon demand, and we have completed research into developing a mechanism to auto-generate a readable document (in a format such as PDF etc.) from the smart contract itself.

Publishing the Contract’s Existence

In order to publish the existence of a contract (or defined element within a contract) a transaction is published to the Blockchain using a pay-to-script-hash address where the pay-to-script-hash can be readily determined from:

• The issuer of the contract; and
• The metadata of the contract.

Whilst this output remains within the UTXO list, this indicates the validity of the contract contained within the metadata itself. As soon as this output is spent, then the contract is considered complete.

Sub-contracts / Conditions

A sub-contract is a contract that it directly related to an existing contract. A condition is a clause within an existing contract that must be publicly fulfilled to meet the terms of that contract.

Both sub-contracts and conditions are implemented in the same manner as Contracts as an UTXO with a deterministic redeem script address. In both cases, the entity is considered complete when the UTXO is spent (in the case of the condition this indicates that the condition has been satisfied).

There are a number of mechanism’s to create the deterministic address for a condition or sub-contract:

• Creating and publishing the sub-contract, with a reference to the master contract, within the repository and using this as the metadata reference; and
• Adding the condition / sub-contract reference to the metadata of the existing contract.

Securing the Contract

The formal representation of the Contract can be secured in multiple manners, depending on the formal needs of that specific contract, although in all cases a public record of the existence of the contract will be published on the Blockchain contained within the metadata record (there re multiple ways to develop the specific metadata structure).

From this Blockchain record, authorised entities will be able to learn the location of the formal representation, together with the hash to determine that the formal representation has not been modified since the transaction was published.

However, it is possible to further secure the formal representation itself through a number of methods:

• The document repository itself can present access control mechanisms; and
• The Contract itself can be secured through standard encryption techniques limiting access to those entities with access to the relevant decryption keys.

In many cases, the Contract itself will have partial protection on it. For example, some sections within the file are protected but the overall content is public. For example, the details of how to implement a fixed rate loan are published but the knowledge of who took out the loan, for how much and at what rate is known only to the contracting parties.

This partial protection applies to both the encryption of the information within the contract as well as the hash detecting changes to its content. For a number of contracts, the details of the contract can be amended over its life and this should not require the re-issuance of the contract itself. This can be achieved by determining the scope of the hash over a sub-set of the contract. An example where this might be useful is on the implementation of a unit trust. The contract underpinning the unit trust may not change, but beneficiary for the unit can be amended through on-sell of the contract.

Terminating the Contract

As the Blockchain provides a permanent, unalterable record of transactions, a contract cannot be terminated by simply removing the associated Contract document. This means that the secure contract repository must have the same storage and retention rules as the Blockchain itself which is supported through a number of standard mechanisms.

This means that the solution must present a mechanism for detecting the expiry of a contract through the Blockchain record directly.

This is handled through the spending of the UTXO that represents the contract.

For a number of contract types, the expiry of the contract can be published simultaneously with the publication of the Contract itself. Effectively two transactions are created, one to publish the contract and get the transaction output representing the contract and a second one to spend that output. This second transaction has a CheckLockTimeVerify set on it to spend the output on a given future date (representing the end of the contract).

This auto-spending can be extended to support the rolling-on of a contract (for example contracts that automatically extend for a further twelve months if they aren’t cancelled). In this situation, the UTXO is spent sending it to the ‘new’ rolled-on contract. However, it is possible to cancel the old one by spending the output before the lock time and thus cancelling the whole contract.

Use Case Model

The following use case model demonstrates how straight-forward Bitcoin transactions can be used to implement elements of the DFA directly within Bitcoin scripts. More complicated implementations of the DFA or Oracle are covered separately and thorough related research at nChain.

Key Use Cases

Create the Contract

Description

As a Contract Issuer I wish to publish a contract onto the Blockchain for public visibility.

Primary Actor

Contract Issuer

Main Success Scenario

Extensions

There are two key extensions to this scenario, which are explicitly documented within the subsequent section:

• 150 — Create a sub-contract from an existing contract,
• 175 — Rollover an existing contract into a new one

Create Sub-contract

Description

As a Contract Issuer I wish to create a sub-contract from an existing contract.

Primary Actor

Contract Issuer

Main Success Scenario

[1] This example is written assuming that this would be the Contract Issuer’s public key, but in practice there is nothing to prevent this being the derived sub-key (i.e. a sub-contract of a sub-contract).

[2] Effectively this is a document that basically says that this sub-contract covers section <a>, <c> and <e> of this other document rather than duplicating the original information.

Variations

There is a single extension to this Use Case where the sub-contract is independently monitored (for example consider a sign-off from a surveyor in the case of a property build contract) and the contract states ‘subject to sign-off by <x>’. To implement this, step 150.60 is created and circulated to <x> to sign, and the repay script is not time locked but created as a m of n multi-signature element where the required signatory is <x>. (In practice this transaction here is likely to have two outputs; the fee to <x> plus the payment of the UTXO generated in step 150.50).

[175] Rollover Existing Contract

Description

As a Contract Issuer I wish to rollover an existing contract into a new one.

Primary Actor

Contract Issuer

Main Success Scenario

[1] This example is written assuming that this would be the Contract Issuer’s public key, but in practice there is nothing to prevent this being the derived sub-key (i.e. a sub-contract of a sub-contract).

[200] Check Contract

Description

As an Interested Party, I wish to confirm that there is a contract in existence to cover the activity that I am enquiring about

Primary Actor

Interested party

Main Success Scenario

Variants

The main variable above assumes that the Interested Party is aware of the transaction that governs the contract through some other route (in general that is that they are either the Contract Issuer or the Contract Counter-party.

However, any entity that has access to the Contract Document and knowledge of the Contract Issuer will be able to check by:

• Deriving the redeem script for the UTXO transaction; and
• Scanning the Blockchain to find a UTXO with that matching redeem script hash.

[300] Close Contract

Description

As a Contract Issuer or Contract Counterparty, I wish to close an existing contract.

Primary Actor

Contract Issuer / Contract Counterparty

Main Success Scenario

Variants

Contract Conditions

The same mechanism described above can be used to monitor conditions within a given contract such as checkpoints.

For example, if a contract is determined to be worth 100 BCH, with 20 BCH to be paid at checkpoint 1 through 5, then the sub-contract model can derive a master contract, plus five sub-contracts. Each of these sub-contracts can be marked as complete using the same, or different, signatories (such as notaries or similar). In this manner, a public record that the conditions attached to the contract have been met can be maintained.

Added with an Oracle process (this shall be described more fully in a later post), then this Oracle process can trigger the 20 BCH payments once the contract has been marked as complete.

Control Contracts

Whilst the above process is modelled on a smart contract, the smart contract doesn’t have to be a contract in the traditional sense of the word. The smart contract itself can simply be a control condition that is publicly fulfilled.

This mechanism can then be used to turn any UTXO into a smart contract, such as for digital access. So, assume that a consumer pays a merchant for access to a service for a period of time. If the merchant’s payment address is a smart contract, then the access control mechanism for the service can check that the money has been paid with an Oracle process sweeping the value at the end of the period to the merchant’s primary account.