What is Proof-of-Work?


A proof-of-work protocol (PoW) generally involves proving that some resource has been expended (typically processing time by a computer). It is a method to deter an abuse of service (i.e. denial of service attacks, spam, double spending) by requiring some form of “work”.

For example, in order to prevent email spam, a PoW system may require the sender’s computer to perform 1-2 seconds of work before sending an email. While this is easy to do for a single email, it would require huge computational resources for mass spam emailers. Another example of a PoW is the requirement to type in numbers / letters when ordering concert tickets online. This is a PoW in that it requires the user to prove that he/she is indeed a human being and not a machine buying a mass quantity of tickets.

In the Bitcoin network, PoW is used as a part of generating new valid blocks. In order for a new block to be accepted into the network, other network participants must demonstrate PoW*. For Bitcoin, the difficulty (related to the amount of work needed to be done before a valid block is created) limits the speed of creation of new valid blocks to roughly one every 10 minutes, irrespective of how many computers are competing to create new blocks.

In a public blockchain, such as Bitcoin, PoW removes the need for trust amongst anonymous actors by reducing the likelihood of an attack by a single malicious actor. In this case, PoW aims to prevent one party from holding a majority of computational resources at one given time, though this is not impossible. While it is often thought that PoW is a technological innovation, it is actually an economic innovation that reduces the likelihood of system abuse – it is possible for a PoW-based system to be circumvented given enough economic resources, time and effort.

Though PoW is a key component of Bitcoin and other public blockchains comprised of a network of anonymous actors, the need for PoW is absent in a private network where participants are known and the relationship between entities is governed by legal contracts.

*Bitcoin mining uses SHA-256 as the PoW algorithm (SHA stands for Secure Hash Algorithm). 

What is Fault Tolerance?


Fault tolerance is the characteristic that enables a system to continue to function and operate sufficiently in the presence of component failures. When a component of a system fails, fault-tolerant design enables a system to continue to operate as intended – though potentially at a reduced level – rather than fail completely*. A fault may present itself technically – a node stops working, there is a hardware failure, a software bug – but can also be the result of a malicious actor attacking a system.

While fault tolerance can be a property of individual machines, it can also characterize the way in which machines interact in a network. In distributed computing systems, for example, attacks and software errors are becoming more common and can cause faulty behavior of nodes, resulting in the need for fault-tolerant design, especially for financial institutions that operate many sensitive production systems.

This fault-tolerant design allows a system to maintain functionality, though sometimes at a reduced quality**. In a fault-tolerant distributed computing system, for example, a system-component failure could result in a reduced throughput or longer response time – the entire system, however, is not stopped after a partial failure.

Recovery from failures in fault-tolerant systems can be classified as either “roll-forward” or “roll-back” depending on the type of error in a system.  Roll-forward recovery involves correcting the system state so that it may advance, while roll-back requires reverting the system to an earlier, correct version so that it can then continue to advance.

There are specific types of fault tolerance that are aimed at unique failure scenarios. For example, Practical Byzantine Fault Tolerance targets the Two Generals’ Problem, which applies to any type of two party communication where failures of communication are possible.

*For this reason, fault tolerance is particularly important in systems that are life-critical or high-availability, as the ability to maintain functionality in these systems is imperative.

**The ability of a system to maintain functionality when components of a system break down is referred to as “graceful degradation”.

What is a UTXO?


A UTXO is an unspent transaction output. In an accepted transaction in a valid blockchain payment system (such as Bitcoin), only unspent outputs can be used as inputs to a transaction. When a transaction takes place, inputs are deleted and outputs are created as new UTXOs that may then be consumed in future transactions.

In the Bitcoin network, which uses this model, a UTXO is the amount that is transferred to a Bitcoin address (along with information required to unlock the output amount*) during a transaction. Received amounts (UTXOs) are used individually during a transaction and new outputs are created – one for the receiver and, if applicable, one for the amount that is left over (change output). The amount sent to the recipient becomes a new UTXO in the recipient’s address while the change output becomes a new UTXO in the sender’s address that may be used in a future transaction.

Corda uses a UTXO model – an entry is either historic (sometimes referred to as “spent” or “consumed”) or current (sometimes referred to as “unspent” or “unconsumed”), but it cannot be changed. Corda assumes that data being processed represents financial agreements between identifiable parties and that these institutions require a significant number of such agreements to be managed by the platform. Therefore, Corda must be able to support parallel execution, while also ensuring correct transaction ordering when two transactions seek to act on the same piece of shared state. A UTXO model provides this, allowing transactions to be processed independently and in parallel, even for high traffic legal entities.

* Each UTXO has a signature associated with it belonging to the owner. In Bitcoin, this signature must be present during a given transaction in order for the transaction to be considered valid.

What is a Smart Contract?


The term “smart contract” is used often when discussing distributed ledger technology; however, its definition tends to be broad, unclear and often controversial.

The term “smart contract” itself can be misleading, as the notion of “smartness” and the extent to which something is truly a “contract” is questionable in many instances. Smart contracts have become so closely associated with distributed ledger technology and referred to so often, that in many cases the meaning has strayed from its original intent and has been generalized to the point of inaccuracy.

The phrase and concept of a smart contract was originally developed in 1994 by Nick Szabo, a legal scholar, computer scientist and cryptographer. Szabo’s background reveals the original intent and requirements of a true smart contract: a confluence of both legal and computer code. In fact, Szabo’s entire methodology is centered around the improvement of contract law and practice through electronic protocols.

It is critical to distinguish between the technically accurate concept of a “smart contract” and today’s buzzword. There are often situations where a simple piece of code is claimed to be a smart contract when, in reality, it is neither “smart” nor technically a “contract”. A smart contract is not simply any piece of self-executing computer code, but is rather an agreement whose execution is both automated and enforceable.

A smart contract is automated in the sense that the core business terms (the actual “transaction” among parties) is expressed through, and independently executed by, computer code and which no party can block or otherwise tamper with. It is enforceable in the sense that it constitutes legally binding rights and obligations of the involved parties.

Currently, most smart contracts consist of a combination of both computer code – a programmable transaction protocol that defines the business terms of the contract – and legal prose that reflects that the computer code constitutes part of the binding legal agreement between the parties, and is therefore also legally binding.

Smart contracts are critical aspects of distributed ledger technology for financial institutions. They allow parties involved in an agreement to conclude with certainty that they are in consensus at all times as to the existence, nature and evolution of the facts shared among them, which are governed by the program. Additionally, they can be used to satisfy common contractual conditions, lower transaction costs and risk, and eliminate the need for trusted intermediaries.

What is a Golden Copy?


A golden copy – or golden record –  typically serves as the official, master version of a record of data. It is an authoritative single source, sometimes referred to as the “single version of the truth”, where “truth” is understood as that which users can ensure is the single correct piece of information which can then be actioned upon.

What constitutes a golden copy varies based on the particular use of that data. For example, a passport or social security number may constitute a golden copy in the case of customer KYC information, while a driver’s license can be thought of as golden copy of a form of identity at the DMV.

For financial institutions, there is a reliance on a single source of data that is untainted, “true” and represents something that is actionable. In trading, for example, this means that the initial booking of a trade and agreement of the attributes of that trade between counter parties forms a representation that can be used for some action. In other words, the initial construct of a golden copy consists of the data attributes (of a trade contract information that is both common like reference data and counter party specific, like a trader ID) that define the data and confirmation / validation that makes this golden copy reliable and, ultimately, actionable.

While existing processes – like reconciliation – currently carry out this validation process in a bank, distributed ledger technology (DLT) may ultimately be able to carry out these actions far more efficiently. DLT enhances the notion of a golden copy in that it enables a group of participants to confirm that data is true, lowering the cost of reconciliation and relieving the burden of having a single institution validate or act as a golden copy. DLT allows for multiple, distributed confirmations, strengthening the claim of factuality.

A golden copy is considered the original, incepting transaction – any amendments or changes to the data must be confirmed and validated by participants in the distributed ledger network that have the authority to make and validate those changes. In this sense, a golden copy is a living piece of data that is continuously validated.