Addressing Redress: Trust Pathways
In the first part of this two-part series we argued that in spite of its many advantages, contractual relationships built upon blockchain technology will suffer from some of the same trust issues that occur in off-blockchain contracts. At the heart of these issues is the trade-off between implementing a trust infrastructure on the one hand, and preserving the efficiency gains presented by blockchain on the other.
This trade-off (or balance) must be carefully selected to minimize the chance that one of the contracting parties will enter into a dispute and seek redress. In order to do this it’s useful to think of trust as something which flows through the contracting relationship, via pathways that are chosen to maintain this balance.
Broadly defined, we can think of three pathways that need to exist in order for trust to be enabled on the blockchain:
- a Validation pathway,
- a Verification pathway, and
- an Auditing pathway.
Let’s examine each of these in turn.
Validation: It Is What It Says It Is
Validating a contractual relationship just means that the contract needs to be in a standardized format that everyone can agree upon, i.e. that is common knowledge between and among all parties. This is a minimal requirement so that disputes cannot focus on the form of the contract.
On the blockchain, contracts can be written in a variety of ways. The easiest way is to have an implicit contract defined by a transaction–when Bob, say, transfers bitcoin to Alice, the transaction act is an implicit contract between Bob and Alice. But more complicated contracts can exist, such as “smart contracts”. Smart contracts are programmed (and live) on the blockchain. These contracts are compiled, i.e. are made machine-readable and then executed as a running piece of code.
Minimal Requirements for a Validated Contract
How is such a contract validated, i.e. placed into a standardized format so that all parties agree upon its structure?
First,
This is pretty straightforward–if the contract cannot compile in the first place, it cannot be valid.
Similarly,
Again, this is a reasonable requirement–although code with runtime errors will compile, they will not successfully complete (they will “crash”).
Third,
This is an important requirement, and we’ll discuss it briefly below.
Fourth and finally,
This requirement ensures that code performs as expected–if you feed it specific input criteria (e.g. for car insurance, the make, model and year of the car, the driver’s driving record, average distance travelled per year, accident date and time, police report, and a particular kind of damage) then you should get a specific outcome (e.g. the acceptance or refusal of a claim).
Side Effects
In the above it’s important for all contracting parties to agree upon what is meant by ‘side effects’. Ideally, a contract should have as many tests as there are possible use cases, while at the same time making sure that nothing unintended can happen. In practice, this is usually impossible. The best one can do is to make the series of tests (also called a “test suite”) as comprehensive as possible, i.e. as far as time and resources permit. Doing this effectively relies upon having the creator of a test suite leverage their own expert knowledge in test creation, and can often be more art than science.
The First Trust Pathway
Validating a contract is the first trust pathway that needs to be present and is perhaps the most logical application of trust tools to a blockchain contract. As shown in the example above, validation allows the creation of insurance contracts on the blockchain, where an insurance (smart) contract can transparently indicate when claims are filed, approved and paid, improving the efficiency of the claims process while reducing the scope of fraud. In general, the blockchain acts as a decentralized repository for a contract’s details, fiduciary responsibilities, and transactions structure which, once registered on the blockchain, is immutable.
Verification: It Does What It Says It Does
Actually executing a smart contract leads to verification of the outcome. A validated contract will execute under the conditions it has been defined to wait for. These conditions can be explicitly generated by the user (e.g. when a user files an insurance claim) or can be automatically triggered (e.g. when an external data provider–or ‘oracle’1–provides data, such as stock price information).
Blockchain Verification: Easy
Verifying the execution of a contract can be performed by the blockchain itself, since the blockchain is a ledger that records both the user-generated and externally-generated conditions and the transactions that result. There is no scope for tampering with the condition-to-transaction causality because such a recording is immutable. While this cannot control for the existence of fraud ‘off-chain’, i.e. before the blockchain has been accessed, it does minimize the scope of such fraud because of the validation step performed earlier–recall that in that step all contract participants and contract stipulations were vetted and included in the blockchain.
Oracle Verification: Not So Easy?
On the other hand, the inclusion of an oracle complicates matters. There must be consensus among users that the oracle is truthfully revealing external information, so that data cannot be manipulated to the benefit of a contracting party. Defining, implementing and maintaining oracles thus occupies the intersection of decentralized and trusted third-party verification of external conditions, and it appears to be an open question whether smart contracts that rely upon oracles will always contain some form of centralized (i.e. third party authority) dependence as a result.
Uncovering The Cover-Up
Finally, if off-chain fraud is suspected, the immutable nature of the recording of user
and external conditions serves to provide the factual basis for further investigation–the
blockchain records the actual sequence of events and thus eliminates the risk of a fraudulent
party obfuscating the link between conditions and transactions (by e.g. a ‘cover-up’
of the path from, say, false data fed to the smart contract, and the resulting transaction).
The Second Trust Pathway
Verification is the second trust pathway and requires as a prerequisite validation to be present (so that the contract can be specified properly in the first place). In each of the described verification steps–on-chain verification using the immutability of the blockchain as a ledger, oracle inclusion, and using the blockchain to verify claimed off-chain external conditions–trust tools must be developed and implemented in a way that all sides of a contract agree are transparent and perform as intended.
Auditing: It Did What It Says It Did
Once a contract has been validated and verified, contracting parties or external arbiters can use the blockchain to faithfully “replay” the events that took place when the contract executed. This is an audit of the contract, mapping out the chain of events from the contract
inception to its outcome (or set of outcomes).
Auditing is important for a few reasons. First, it ensures that every step conforms to the accepted best practices and legal requirements for the type of contract under consideration. Second, for those contract steps that require payment or transfer of assets, auditing confirms that double-spending along the (potentially long) sequence of transactions is not performed. Finally, auditing allows contracting parties to collectively agree that the contract was implemented and executed according to the intent and expectation of each party. This serves as an important signal of trust for repeated interaction between the parties.
A smart contract on the blockchain simplifies the auditing process because transactions are recorded transparently and immutably on the blockchain itself. Moreover, the high degree of automation a smart contract entails allows for a kind of ‘pre-auditing’ during the validation pathway step. Finally, the design of the blockchain itself prevents double-spending from occurring.2
The Third Trust Pathway
Auditing is the third trust pathway. Although it takes place after the validation and verification of a contract, and hence after contract execution, requiring a trustworthy auditing process strengthens the credibility of the contract before its implementation and hence the faith in the contract by the participants. Auditing is a technology that contracting parties can depend upon, to provide clear event causality, transparent contract terms (as encoded on the blockchain) and unambiguous tracing of the flow of goods and services the contract may provide. This forms the basis for consensus between contracting parties, which in turn reduces the chance of dispute and hence lowers the cost of dispute resolution as a result of (or during) an auditing process.
Moving Forward: Trust Tools Are Not A Given
Blockchain is a tremendously efficient decentralized database that will likely live up to its hype as the most important disruptive database innovation since the inception of the Internet. That said, its capacity for building trustworthy relationships between parties who have no prior history is limited by the trust tools that are built into (and onto) its infrastructure. This series of posts has argued that since “Blockchain Does Contracts”, it faces most of the same trust issues that off-blockchain contracts have always faced. As a consequence, we can leverage existing knowledge of how to build trustworthy relationships via trust pathways, with the challenge being that we need to know how best to apply these pathways to this new technology.
Once this has been accomplished, though, the sky’s the limit–blockchain’s efficiency gains can be fully exploited to build contracts with unprecedented transparency on the one hand, and secure trustworthy relationships on the other.
Part one of this series is here.
Read more in the white paper: “Enabling Trust on the Blockchain”
References
- See e.g. Eric Larchevêque, “Hardware Pythias: bridging the Real World to the Blockchain“, Ledger (blog post), August 31, 2016.
- There are attacks on blockchain technology, such as the 51% attack under the Proof-of-Work mining paradigm, which could subvert blockchain’s prevention of double-spending. See the white paper for a more in-depth discussion of this point.