You are on page 1of 18

Unleashing the Blockchain

Executive summary
Todor Bukov <>

Executive summary
The Blockchain is an append-only, cryptographically secured, tamper-proof, distributed and replicated
store of records. It allows the creation and execution of arbitrary rules which interact with these records to
enable the implementation of complex business logic.

Opportunities in the use of this technology are many and key examples amongst them include:

Non-repudiation of pre and post trade workflows.

Secure regulatory surveillance.
Secure data entitlement.
Enablement of Smart Contracts through a Thomson Reuters role as trusted content

Understanding what constitutes a good opportunity via the application of Blockchain technology doesnt
imply comprehension of all the mathematical underpinnings of cryptography, just sufficient familiarity with
the high-level concepts and relative maturity of the technology.

Beyond the below brief summary please see the enclosed paper entitled Unleashing the block chain for
detailed reading on the subject and further exploration of potential opportunities.

Blockchain technology explained

At its core, the Blockchain is an evolution of fundamental cryptography concepts, coalesced in a novel way
to produce an immutable, distributed database.

The building block of the Blockchain is a simple record of data, called a transaction, implemented as a hash
of the record. Many of these hashes are grouped together into larger blocks and these blocks are then
chained together such that each block depends on the content (hash) of the previous block. The resulting
construct is called a ledger. The ledger is then distributed using peer-to-peer technology to multiple
participants who together form a Blockchain.

The act of recording a transaction in the ledger ensures it is irrevocably preserved as the ledger only ever
grows in size, never removes or overwrites an existing transactions and links all of the blocks together in a
way that makes tampering infeasible. This feature is very important for the integrity of the ledger and is
one of the defining characteristics of the Blockchain.

The Blockchain is however much more than just a secure store of records it provides incentives for the
well-behaving participants (also known as peers) to maintain and distribute a valid working copy of the
ledger by rewarding them with the so-called cryptocoins.

To qualify for these cryptocoins, in addition to maintaining a copy of the ledger, the peer must also provide
a proof of work to find a solution to a hard mathematical problem. The problem is designed such that a

solution is hard to find, but easy to verify and every participant has the same chance of solving it within
certain time limit. This process is also called mining and the peers who engage in it are known as
miners. Miners continuously solve, verify, agree on and generate new mathematical problems by using a
consensus algorithm.

The cryptocoins earned by miners can be used to publish a transaction into the Blockchain. Miners can, and
often do, exchange their cryptocoins for real-world currencies with others who want to participate and
interact with the Blockchain.

In addition to storing records, the Blockchain has developed the ability to store computer code, programs
that can interact programmatically with the records and define rules on how these records are
manipulated. These programs, called smart contracts, are run by all peers and require initial capital in the
form of cryptocoins to enable them to use computing resources and to limit the avenues for abuse. This
feature opens possibilities to emulate real-world scenarios and create practical applications.

As smart contracts live within the Blockchain and dont have the ability to source data from the outside
world, the concept of smart oracles (or simply oracles) was developed. The oracles are computer
programs, just like the smart contracts, but they live outside the Blockchain and pump trustworthy data in
the form of transactions into the Blockchain.

Uses cases for the Blockchain

The most obvious use case for Blockchain is as a replacement of databases for historical data. In the
financial context, good candidates for such data stores are trading workflows, news articles, administration
records, credit data etc. Records, which are updated periodically and need to be replicated, are very good
candidates for migrating to a Blockchain solution.

However given the current technology maturity, the Blockchain performance is not suitable for direct
storage of high-volume data flows e.g. market data feeds. This is an area of active research and recent
developments, e.g. the idea of state channels where only snapshots the actual data are stored in the
Blockchain, offer hope for future significant performance improvements.

An area of significant interest in the Blockchain is its ability to execute smart contracts. The flexibility of
smart contracts, while great for implementing business logic, also makes them complex and potentially
risky. Creating solutions for managing this risk and complexity is expected to create significant business

The advent of smart oracles fuels the need for trusted sources of external data. This creates further
opportunities for data providers such as Thomson Reuters, which have a history of sourcing and distributing
high-quality trusted data. The Blockchain is also not only a consumer of such data it will also generate it
as the ledger itself, the transactions and their interaction with smart contracts create troves of valuable
market intelligence, especially as the number of Blockchain participants grows.

The Blockchain is fascinating emerging technology a disruptive intersection between mathematics,
cryptography, computer programming and financial technologies that presents many opportunities.

While it is difficult to predict how the Blockchain technology will evolve, given its disruptive nature, the
strong backing by many financial institutions and the significant investment in the Blockchain-related
projects, analysts predict that within the next ten years it will have a significant impact on the technology
landscape especially within the financial services industry.
In order that an organisation such as Thomson Reuters is capable of leveraging the technology at the
appropriate point of maturity, it is therefore critical to be at the forefront of and to establish ourselves as a
leader in this rapidly evolving technology.

Unleashing the Blockchain
A guide to Blockchain technology and potential opportunities for
Thomson Reuters
Todor Bukov <>
Version 1.6, June 2016

The Blockchain is an append-only, cryptographically secured, tamper-proof, distributed and replicated store
of records. The Blockchain allows the creation and execution of arbitrary rules which interact with the
records to enable the implementation of business logic and other complex rules.

This paper provides both an introduction to Blockchain technology and explores a number of potential
opportunities for Thomson Reuters key examples of which include:

Non-repudiation of pre and post trade workflows.

Secure regulatory surveillance.
Secure data entitlement.
Enablement of Smart Contracts through a Thomson Reuters role as trusted content

The building blocks

The basic building blocks of Blockchain technology are a small number of cryptographic primitives, namely
hash functions and a public key cryptography. Both are essential for implementing the machinery
underpinning the Blockchain and their security and performance play a significant role in providing the
security guarantees promised by the Blockchain-derived technologies.

Normal hash functions, e.g. Cyclic Redundancy Checks (CRC), are one-way functions used to conveniently
reduce large, variable-length input of binary data into a fixed-length output at the cost of significant data
loss. However, since the hash function result depends on all of the individual parts of the input message,
despite the data loss, the hash result can be assumed to be a short representation of the original message.
The only time where this assumptions fails is when two different input messages produce the same hash
result a situation which is referred to as a hash collision. The better the hash function, the less likely it
is to produce a hash collision.

The cryptography hash functions adhere to more stringent criteria than normal hash functions. All hash
functions are usually relatively easy to compute, but reversing the process i.e. restoring the original input
from the hash, is impossible due to the data loss. In addition to these properties, cryptography hashes must
also ensure it is sufficiently hard to generate a given hash (creating hash collision) and that even a small
change in the input data produces a large change in the resulting hash, which is important to avoid certain
class of cryptanalytic attacks.

The only way to generate a given cryptographic hash is to either provide the same input, if it's known, or to
exhaustively test every single combination as input data until the output hash matches, a method also
referred to as brute force. The former property is used to verify integrity of some known data and the
latter is used as a proof of work [1] due to its significant computational overhead. As we'll see later, both
of these properties are heavily leveraged in the Blockchain implementations.
The other cryptographic primitive public key cryptography, also known as asymmetric cryptography, is
a cryptographic system that uses a pair of keys, one of which is disseminated widely and is referred to as a
public key and the other is kept secure and is called a private key. The two keys are linked together by
an algorithm which is constructed such that when performing encryption with either one of the keys, the
result can only be decrypted with the other key. The keys are also unique i.e. it is very unlikely that
someone else may have generated exactly the same pair of keys. An additional security property of a good
public key cryptography system is that even when a third party has one of the keys (the public key), it
cannot derive the other within any reasonable time frame (hundreds of thousands or even millions of
years) and without significant computational resources. The security of the public key cryptography method
is guaranteed only as long as the private key is kept in a secure and reliable possession by its owner and is
never shared. This requirement can be hard to satisfy, because the private key is just a list of numbers
written in a file which can be copied just as any other file. Anyone with the possession of the private key
can represent its owner and effectively steals their identity. Because of that, private keys are often stored
in dedicated hardware devices e.g. smart cards or Trusted Platform Modules (TPM) which, combined with
some additional means e.g. PIN key, password or biometric reader e.g. retina or fingerprint scanner, can
guard against ex-filtrating the information stored on them.

Public key cryptography is different from the typical symmetric encryption scheme where the same key
(referred to simply as an encryption key) must be used by two parties who want to securely exchange a
message by encrypting and then decrypting with the encryption key. The challenge in such a scheme is that
the two parties must have obtained the key prior to the start of their communication, a requirement which
become too onerous for large number of participants who want to communicate securely with each others.

The way public key cryptography is most often used is to provide authentication or confidentiality. For
example Alice can use her private key to encrypt a message which then everyone can decode with her
public key. Because Alice, as the author of the message, is assumed to be the only one who has access to
the private key, no one else could have produced the encrypted message, therefore its authenticity is

Here is an example on how to use public key cryptography system to provide confidentiality, i.e. the
guarantee that no one else, but only the recipient of the message can read it: Alice takes Bob's public key
and encrypts a message with it. Since only Bob has the associated private key, he is the only one who can
successfully decrypt the message, so the message confidentiality is guaranteed.

Combining authentication and confidentiality with hash functions allows the constructions of higher-level
operations like the generation and verification of digital signatures. Digital signatures are simply the result
of hashing some data (a message) then using a private key to encrypt the hash. For example when Alice
wants to send a message to Bob, she computes the message hash, then encrypts the hash with her private
key. The result, called digital signature, is then added to the original message and sent to Bob. When he
receives the message, Bob first decrypts the hash using Alice's public key, then independently computes
the hash of the message and compares it with the decrypted hash value. If both hashes match, then Bob
can be assured that the message does indeed is authored by Alice and has not been altered in transit. This
is the digital signature verification step. If confidentiality is also needed, Alice can use Bob's public key to
encrypt the message before sending it. Bob needs to reverse the operation and decrypt the message
content with his own private key before computing the hash.

In cryptography, to avoid certain types of attacks e.g. replaying older messages with the intention to cause
some action to be executed multiple times, a random number called nonce (a number which is used only
once) is added to each message. The nonce is separate from the main message, but when the hash or
digital signature are computed, it is also included as part of the content being hashed. This guarantees that
resulting hash (or digital signature) will be unique even if the message remains the same. Nonces are often
combined with timestamps to provide unique, time-dependent hashes or digital signatures.

Digital signatures are often used to implement signing of public keys by a third party trusted by all
participants (sometimes it is also called counter-signing). This technology is underpinning the mechanism
behind the widely popular web-server certificates used to provide secure access to websites. While not as
important to some Blockchain implementations, the concept of signing a public key bears resemblance to
the way of constructing the Blockchain ledger and chaining the transactions, as well see later. In the
signing process, all parties have acquired by some means (e.g. from their operating system provider or from
well-known web site) the public key of an organization they all trust. Anyone can submit their own public
key to the trusted organization asking for the creation of digital signature created with this organization's
private key. The organization has a vetting process in place such that it can verify the identity of the
requester using some process which doesn't rely on public cryptography alone. Once the requester passes
the validation and their public key is signed by the trusted organization, the requester can publish the
public key along with the signature in an X.509 certificate (the format of such public key is standardized in a
suite of protocols called X.500, hence the name). This certificate can then be passed to other participants
who can use the trusted organization public key (which they already have obtained and trust) to validate
the signature and then have the assurance that the public key does indeed belong to someone whose
identity has been verified.

A related concept to signing is the multi-signature [2](often abbreviated as multi-sig) or secret sharing [3].
This is a scheme where multiple parties receive only a part of a common (shared) secret phrase such that
the whole phrase can be reconstructed by a combining some, but most importantly not necessary all, of
these parts. The algorithms for creating shared secrets allow adjusting the minimum number of participants
required to successfully recover the whole secret phrase. For example, three out of five participants can be
required for successful secret phrase recovery the secret is distributed to five people, but any(!) three of
them are sufficient to recover the secret phrase in full. This mechanism is usually combined with public key
signatures to ensure that the parts of the secret phrase sent to each participant are encrypted with their
public key (to protect from eavesdropping), so to recover the phrase, they need to use their private key
(thus providing authenticity).

Nonces are also essential in challenge-response protocols where one of the participants (Alice) wants to
receives an authenticated response from another participant (Bob). Alice sends a confidential message
containing a nonce to Bob and if Bob returns an authenticated (signed) response back with the same nonce,
then Alice can be assured Bob is who he claims he is based on the identity of his public key. This scheme
can be generalized to provide zero-knowledge proof where Bob can prove to Alice some statement is true
without conveying any other information about the statement. The statement must depend on some secret
information that only Bob knows (like his private key) and which Alice can query in different ways e.g. by
issuing challenges with different nonces. If Bob can always (every single time without a mistake) produce a
valid answer, then Alice can safely assume Bob is indeed in possession of the secret information (the
private key corresponding to his public key).

Another important concept in the Blockchain technology, although not directly related to the cryptography,
is the ledger this is the book of records or the place where all messages sent between participants get
recorded. Depending on how it's used, it could also be referred to as public ledger denoting the fact that
it is accessible by all participants in a particular Blockchain.

Chaining it all together

The Blockchain technology promises to enable various parties to communicate securely with each other
while preserving their privacy and while minimizing the trust they put into the system they use to
communicate through. It aims to deliver this promise without relying on any central authorities. The
authentication requirements for individual participants go only as far as to provide the guarantee they did
indeed send a particular message or that they can reliably decode confidential message. This is by no
means taken to guarantee that a participants' identity in the Blockchain can be uniquely or unambiguously
related to any real-world identity. Quite the opposite many Blockchain implementation make it a design
goal to anonymize and make it intentionally difficult to reveal a participants' true identity. This is achieved
by assigning disposable random identifiers called addresses. Some popular Blockchain implementations
for convenience use the hashed public key of the Blockchain participants as an address. However, this hash
may be used to reveal details about the identity of the said participants, so this method is not universally

Publishing a message with a digital signature to a specific address and recording it into the Blockchain
ledger is referred to as a transaction. For efficiency, instead of recording individual transactions, many of
them are bundled together and published as a block into the ledger. A sequence of such blocks, linked
together in a way that can prove their provenance and integrity is referred to as the Blockchain. Linking
(or chaining) between the block is done by adding the hash of the previous block to the newly created one.
All new blocks, just as the individual transactions, get signed before being added to the Blockchain. To
ensure that no one can manipulate the Blockchain transactions, the Blockchain transactions never get
deleted or replaced, but only added to the Blockchain only ever grows, but it never shrinks.

An ever-growing Blockchain presents some practical challenges, so significant research has gone into
optimizing the Blockchain data structures. One of the most often utilized approaches is to organize the
transactions in a structure called a Merkle tree. In the Merkle tree, each leaf node is a transaction and their
parent (non-leaf node) is a hash of all of its children. Therefore, the root of the tree is a hash function of all
transactions, but stored in a way that allows for very efficient and quick way to verify specific transaction.
Adding a new leaf node causes all branches up to the root of the Merkles tree to get their hashes updated,
so even a small change in the data causes a ripple effect throughout the whole tree. In addition, if a
transaction is corrupted during transit, the Merkle tree structure enables the receiver to quickly identify
which transaction was affected and then only request that transaction instead of asking for the whole block
to be retransmitted. In the Blockchain, only the root of the Merkle tree is recorded, so a single hash
represent all transactions in the block thus saving a significant amount of space. Also, because the size of
the hash is fixed, it allows the Blockchain to grow at more predictable rate.

Each transaction recorded in the Blockchain takes up some resources in terms of storage and CPU cycles. To
prevent abuse, the Blockchain are usually designed to accept and record transactions which are
accompanied by a transaction fee. The fee is typically a just a small portion of some fictitious resource
(referred to as cryptocurrency, coins, ether or even gas[4]) which cannot be obtained easily and
whose use is recorded within the Blockchain itself. The nature of this fictitious resource and the different
strategies to acquire and distribute it are discussed below. It is worth pointing out that the transaction fee
is not required for the construction of a functional Blockchain, but in this case other strategies must be
adopted to avoid abuse by malevolent participants.

As we'll see later, the maintenance of the Blockchain is a distributed process. This is by design and is at the
core of the value proposition for the technologies built on top of the Blockchain. Every one of the
participants in the Blockchain can look up the transactions' history in the Blockchain and verify their
integrity. This means that the whole Blockchain is available at all times to all participants. However, since
the Blockchain only grows in size, at certain point it becomes costly to provide for free. To offset this cost
and create an incentive for sufficient number of Blockchain participants (also known as nodes or peers)
to provide and maintain a copy of the ledger, the Blockchain implementation awards the transaction fees
to the participants who do the job of validating the transactions and creating the next block in the ledger.
This mechanism ensures there will be multiple competing peers all trying to create the next block in the

All nodes on the Blockchain need to connect to each other to exchange blocks. They achieve that by
forming a peer-to-peer network between themselves. Each node maintains a list of active peers it can
communicate with and keeps this list updated as the peers come and go. When a new node comes online,
the first thing it does is to obtain a copy of a list with active peers from a well known location like a web
page or via DNS (Domain Name System) lookup of a pre-defined host name. Once the node receives a list
and successfully establishes a connection with other nodes, its Internet Protocol (IP) address is added to
the list of available peers on the well-known location. This process is referring to as seeding and is essential
in bootstrapping and maintaining the peer-to-peer network.

To actually add a block to the ledger requires a proof of work. As explained earlier, this is usually a hard
computational problem like finding an input message that matches a certain pseudo-random created hash.
As the Blockchain participants' total computational resources can vary with time, it is therefore important
to make the proof of work algorithm adjustable and bounded in time (i.e. given the available computational
capacity, it is guaranteed to finish within a certain amount of time). A new proof-of-work problem is
published with each transaction block and whichever peer solves it first receives the privilege to add the
next block to the Blockchain. This peer then receives the transactions fees as well as an additional reward
for its efforts. It records them in a new transaction, which then gets added to the block. The new block is
signed and published to the Blockchain where the rest of the peers can verify the solution, update their
copy of the Blockchain and start looking for a solution for the next proof-of-work problem. It is important
to note here that every peer in the Blockchain does the verification independently and makes its own
decision on whether to add the new block to its own copy of the Blockchain. Therefore, to ensure all peers
have the exact same version of the Blockchain, they should reach consensus that the blocks they have
received are all valid and have valid predecessors. The time by which all peers validated the latest block and
reached consensus is sometimes referred to as convergence time.

The process of solving the proof-of-work problem and then claiming the reward with units from the
fictitious resource in use by the Blockchain is called mining. The peers who participate in the process of
mining are called miners. To make it hard to cheat, every new proof-of-work problem depends on
properties of the previous blocks (and by extension previous transactions) as well as the current
transactions and not only on the results published by the miners themselves. The miners thus do benefit
the whole ecosystem by not only providing resilience and availability of the whole ledger, but also by
validating all transactions before they get recorded in the Blockchain.

If a non-mining node wants to participate (transact) in the Blockchain, it must first acquire some of the
fictitious resource (cryptocurrency) to pay for the transaction fees. Acquiring the cryptocurrency means
exchanging it for fiat currencies (government-issued currencies) which is how the miners monetize their
rewards. The exchange rate between the cryptocurrency and the fiat currencies depends on the popularity
of the Blockchain, therefore there is a strong incentive to make the Blockchain platform versatile and
catering for as many use cases as possible.

Since miners benefit significantly from being participants in the Blockchain, there is a strong incentive for
malicious parties to subvert the mining mechanism and claim the miner's rewards without actually
providing any value-added service. The easiest way to achieve this is to fork the Blockchain by creating
new blocks, manipulated such that the mining reward and the transaction fees are attributed to the
attacker. However, this means that the said attacker must have had solved the proof-of-work problem
before the rest of the miners and had it published first. This should only be possible if the attacker has
access to significant computational power or controls the majority (more than 51%) of all mining peers. In
true decentralized and distributed Blockchain implementation, such a situation is considered to be unlikely
although there have been examples of real-life Blockchain implementations where this assumption has
been proven not to hold true [5].

To reduce the opportunity window during which a malicious party can interfere with the mining process,
the difficulty of the proof-of-work is adjusted such that a new block is added to the Blockchain periodically.
Typical intervals are usually selected to be around 10 minutes. If this interval is increased too much, then
the time to record the transactions into the Blockchain also increases which delays the confirmation of
transaction completion. If the interval is made too low, then the number of messages required to just keep
the Blockchain synchronized can consume significant amount of the available bandwidth.

In situations where the connectivity between mining nodes is disrupted either by accident or due to a
malicious act, it is possible that a Blockchain fork occurs. When that happens, the miners in each fork
continue with the block mining and transaction recording. After the connectivity is restored, the miners will
have to agree on which version of the Blockchain is the true one. The decision is to select the longest
Blockchain fork that still chains to the version of the Blockchain prior to the fork. The reason behind this
decision is that no single malicious party is thought to own the majority of computational resources to solve
the proof-of-work challenges and because each correct block corresponds to a solved proof-of-work, then
the longest fork must be the one created by the majority of the trustworthy miners. The rest of the
(shorter) forks get discarded which means that the transactions they recorded are no longer valid. This
enables some forms of abuse like double spending [6], i.e. making two transactions in parallel forks of the
Blockchain using the same cryptocurrency. Obviously the recipient of the transaction in the fork which got
discarded will incur losses and is likely to stop trusting the Blockchain. This is is why developers of
Blockchain implementation go to great lengths to detect and minimize the impact of Blockchain forks.

While most of the discussions about Blockchains assume peer-to-peer network with equal nodes providing
unfettered access to the ledger to anyone who asks, it is also possible to create a Blockchain where certain
restrictions are applied to the Blockchain participants. One of the most notable examples is the creation of
private Blockchain where the majority of the peers are controlled by a single authority either single
organization or consortium of organizations with a common vision on how to run the Blockchain. The
control of the authority is enforced by applying restrictions on which peers are allowed to join. For
example, only peers with correctly signed X.509 certificates can join the Blockchain. However, the
Blockchain can still provide services to other, non-trusted peers, like providing read-only access to allow
them to verify transactions, but not to submit them. Some implementations employ finer-grained
authentication methods where non-trusted peers can be allowed temporarily to commit a block to the
ledger if the Blockchain authority allows them. Such schemes, where submitting a transaction to the
Blockchain requires a separate approval process, are often referred to as permissioned Blockchain in
contrast to the traditional (sometimes called permission-less) Blockchain. It could be argued that
permissioned implementation are no different from a centralized database, but organizations opting to use
the Blockchain instead can still reap the benefits of having a common, standardized mechanism for
recording, validating and distributing transactions.

The Blockchain gets smarter

At a high-level, each transaction in the Blockchain can be seen as requiring some data manipulation i.e.
passing a number of messages as input (e.g. transfer Z amount of cryptocurrency units from account X to
account Y) and producing one or more messages as output (e.g. The new balance of account X is ABC and
the balance of Y is DEF). It was realized by the early Blockchain implementers that instead of hard-coding
the data manipulation procedure (also known as a script) into the Blockchain software, it can be recorded
in a transactions of its own, managed and modified along with the data it manipulates. This led to the
definition of smart contracts [7] which are very powerful extension of the original concept of of the
Blockchain as a simple, distributed book of record.

The smart contract is essentially a program code, written in a computer language every participant in the
Blockchain understands which is stored as a transaction in the Blockchain and which can be executed by a
virtual machine. A virtual machine (often abbreviated as VM) is simply an emulated version of a computer
which has the ability to accept input messages, then run the code and produce output messages. Each node
in the Blockchain runs a copy of the same virtual machine and can execute a script submitted as a
transaction in the Blockchain by any other node.

As executing random code from untrusted party can have serious security implications, some restrictions
are imposed on what a script can do. The permitted operations (also referred to as operation codes or
simply opcodes) only allow a small set of interactions with the Blockchain. For example a script can only
read a transaction from the Blockchain, validate it, modify some of the transaction parameters and submit
it back into the Blockchain as a new transaction. Depending on how complex the actual opcodes are, the
virtual machines can be either Turing-complete or not. In simplified terms, Turing completeness refer to
the fact that the script logic can contain branches (based on certain conditions, different portions of code
are executed) and loops (some portion of the code is repeated a number of times until a condition
evaluates to true).

Turing-complete virtual machines are more flexible, but they have are inherently more difficult to
implement and secure properly due to the fact there is no easy way to determine when a program will
terminate. This issue is referred to as the halting problem given some code and inputs, it is impossible to
determine for certain if the code will ever finish or will continue to run forever. However, the ability to
express scripts in brief and concise form using loops and branches has led to the development of
Blockchain implementations which do support Turing-complete virtual machines.

To avoid abuse from malicious participants (who may craft a script with an infinite loop or other
computationally heavy transactions), each opcode has an attached cost. The node submitting a smart
contract (transaction with embedded script) needs to add sufficient balance in the Blockchain
cryptocurrency to the transaction to cover all computational costs incurred by executing the script. When a
miner runs the script, it deducts a small, pre-determined amount from the transaction balance for each
executed opcode. If the balance runs out before the script execution completes, the whole transaction
balance is claimed by the miner as a transaction fee and the transaction is marked as closed. If the script
execution completes and there are some remaining funds, the transaction is left open with the balance
adjusted to account for the spent computation cycles used by the script. The difference is again claimed by
the miners as a fee to reward them for executing the transaction.

This charge-for-computation model significantly reduces the potential for abuse, because an attacker
must acquire large amount of cryptocurrency to keep the smart contract open for a long time. Even then,
there is a finite (and easily determined) amount of balance allocated for the smart contract, so each miner
can make a decision at the beginning of the transaction whether it is worth executing it. Miners with small
amount of computational resources may opt out from executing the smart contract at the cost of losing the
fees it generates.

Advanced applications
Smart contracts open the door for the creation of complex multilateral transactions that could be used to
closely model real-world contracts, but with minimal trust between the participants. The most common
use for smart contracts is to use them to create virtual locker (an account) to hold some amount of
cryptocurrency, which will be released when certain conditions are met. When a third party is involved in
such contract, they are also referred to as an escrow contract.

One possible way to construct such a smart contract is to create a transaction for holding cryptocurrency
until a certain number of the participants in the contract agree on who will receive the balance. All parties
in the contract have their public keys and addresses recorded in the transaction. The actual number of
participants who must be in agreement to fulfil the contract is also recorded in the transaction. When the
time comes to use the cryptocurrency locked in the transaction, one of the contract participant sends a
message to the smart contract. The smart contract then issues a challenge (e.g. a nonce) which must be
signed by the majority of the participants. Each contract participant publishes the signed response along
with preference who should receive the balance. The smart contract verifies the signed responses using the
public keys recorded in the transaction and only when it confirms they are valid and the required number
of them agree on the recipient, it then transfers the balance to that recipient's address and closes the

To restrict the options for abuse, additional requirements can be applied to the contract e.g. each party can
only request a limited number of challenges and it also gets to vote only once per challenge. Also, if the
contract expires and no agreement is achieved, there could be a default action, like sending the balance to
specific address or return the remaining funds to the original sender. All that logic is encoded within the
smart contract and the current state of the transaction is recorded in the Blockchain. Each state transition
is recorded as a new transaction that is linked to the previous one by its identifier in the Blockchain. With
some minimal changes, this method can also be applied to implement electronic voting.

Variants of this scheme, where the value stored in the transaction is replaced or augmented with
alternatives (like tokens representing some assets, reputation rank, credit score etc.) can be adapted to
implement even more complex contracts. There is also the option to use proof-of-stake where participants
must prove they own certain amount of cryptocurrency before they can produce the next block in the
Blockchain or influence the outcome of a smart contract.

As the complexity of the Blockchain contract grows, the need for recording the transitional states leads to
increased demand on the Blockchain resources. This has led to the development of state channels. They
are generalization of the method to record transaction's state transitions off the Blockchain as many
times as needed by the contract participants. Each state transition is, by itself, a valid transaction in the
Blockchain, but no intermediate state is submitted back to the Blockchain. Once the participants agree to
finalize the transaction, the last intermediate state is made final and only that state is send to the
Blockchain (recorded on the Blockchain). There are some implementation challenges with this method
[8], but it reduces the pressure on the Blockchain while providing the flexibility and speed required by
certain use cases.

An interesting concept, closely related to that of smart contracts, is smart property [9] which is an asset
that can be represented in the Blockchain and whose ownership is controlled via a smart contract. Smart
properties allow the definition within the Blockchain of complex contracts like loans secured against the
ownership of a property, shared ownership, secure lending etc. Some smart property implementations rely
upon physical world devices using public key cryptography (like car immobilizers, Trusted Platform Modules
in computers' motherboards or smart phones' secure boot loaders), but in general, smart property may
also be implemented without such devices.

To enhance the areas of utility of the Blockchain, oracles (or smart oracles) are often employed.
Oracles are nodes which communicate with data sources external to that Blockchain. The idea is to enable
smart contracts, which by definition are limited to interactions only with the Blockchain records, to take
into account data from the outside world. Oracles enable the implementation of complex smart contracts
whose decisions and state depends not only on the state of the Blockchain transactions, but also on
external factors. There are inherent challenges in trusting the data from oracles, so the Blockchain
implementations employ various schemes to incentivize honest behaviour.

One of the more exciting application of the ability to run code within the Blockchain is the creation of
agents. Agents [10] are smart contracts constructed as autonomous programs providing services for which
they charge fees. These services may include providing computing resources like storage, processor cycles
or bandwidth or they could be higher-lever services like providing escrow accounts. As long as the charged
fees exceed the cost of the consumed opcodes, the agents will be able to sustain themselves.

A useful ability of the Blockchain agents is that they can be made capable of modifying their own code
(included in the smart contract which defined the agent) to adapt to a changing environment. The only
allowed changes to the code are typically limited to auxiliary functions, like algorithms providing the agent
services, which the main code must validate before adopting. Agents can also spawn other agents (as
children) and provide them with initial funding. These two features make for an interesting case where
evolution-like process takes place as selective pressure exerted on the Blockchain agents forces them to
optimize their performance and efficiency in terms of increasing the value of the services provided while
minimizing the number of opcodes consumed. The outcome of such process is hard to predict and will be
interesting to observe.

On the implementation side, there are some open problems with the agents like how to secure their
private keys, how to make them interact with external providers to rent computing capacity or how to
protect them against malicious participants looking at draining the agents funds. The prospects of having
code which looks after its own interests and competes with humans in a level-playing field creates many
technical and ethical questions and is one of the most challenging areas of research in the Blockchain

Blockchain use cases for Thomson Reuters

The financial crisis of 2007 and the markets turmoil in the follow up years caused increased government
scrutiny and increasing regulatory burden for the participants in the financial markets. There is significant
pressure on the financial institutions to be more transparent, more efficient and more collaborative. This is
why there is so much excitement in the financial industry around the Blockchain technology as it promises
to solve these problems in addition of having the potential to provide standardization, improved data
integrity and much better data replication. However, the main obstacles of realizing these benefits do not
appear to be technical in nature the Blockchain, despite its relative youth, is underpinned by mature and
well understood cryptographic principles. The challenge is how to map the existing financial processes and
workflows to fit the Blockchain and how to exploit the unique features of the Blockchain to create new
business opportunities.

For organization like Thomson Reuters, which operates in diverse markets in the financial, legal and media
spheres with significant breadth and depth of data being ingested, processed, stored and distributed, there
are some well-suited use cases for adopting the Blockchain. The author recommends further research in
this area, which requires close collaboration between subject matter experts in both the technology and
the companys target markets. A number of potential applications are outlined below.

Perhaps the most obvious use case for the Blockchain can be made for business reporting pre- trade and
post-trade. These reports are a result of trading activity and are immutable from audit perspective once a
transaction is completed, it can be amended, but the amendments are registered as new transactions. The
reports are also required to be associated with other records previous transactions or credit lines for
example, and must be traceable and properly attributed, properties which map cleanly to the Blockchain
concepts of transactions, chained blocks and participants' identity. By taking advantage of Blockchains
peer-to-peer replication, the storage and distribution requirements of a typical post-trade solution can be
made significantly simpler and lighter. For example, if government institution requires access to the trade
reports, it can simply join as a peer to the Blockchain the replication and data validation are provided by
the Blockchain software and will happen essentially for free. The reports are usually public and can be
published in clear text, but if there is a requirement to keep them confidential, then the reports can be
encrypted with multi-signature allowing either the creator of the report or a trusted intermediary to
decrypt it.
While this post-trade example utilizes the Blockchain as a dumb storage database, one can construct
smart contract which counts the number of reports submitted by the clients and then compute the fees
they need to be charged. An alternate scheme is to provide a credit line to a client, where they have to
provide funds to the smart contract's account which then will be used to deduct the chargeable fees for
each submitted report as it gets added to the ledger. Once the funds are depleted, the smart contract will
revoke the clients credentials thus preventing them from publishing new reports until additional funds are
added to the account. Of course, a generalization of this model can be applied to any charge-able kind of
transaction e.g. for matching or executing an order.

By allowing the clients to create their own smart contracts on the Blockchain, even more elaborate models
can be implemented, like multi-party credit lines, where the clients set a limit on the funds they use to
trade between themselves, or hedging, where a change on one asset in the Blockchain leads to the smart
contract automatically adjusting the holdings in another asset (assuming the both assets are tracked and
trade-able on the Blockchain). The costs incurred by running the smart contracts will be paid to the venue
which runs the Blockchain (assuming a private Blockchain implementation) similar to the current model
where trading venues collect fees from participants. For public Blockchain implementation, the revenue
model would be different i.e. the fees would be collected from value-added services like data feeds.

As described previously, due to the Blockchain security model, smart contracts can only interact with the
transactions in the Blockchain and accept external stimuli (transaction messages). This has proven to be
serious limitation on their usability when it comes to integration with and manipulation of real-world
assets. The information on the Blockchain contains only references to past transactions, so there is no way
to construct a smart contract transaction for take the current exchange rate between fiat currencies X and
Y or take the current market price of stock Z. To realize the benefits of the smart contracts, such
information should be made available within the Blockchain itself. However, recording the relationships
between all possible assets into a single Blockchain is infeasible, so the alternative is to provide the
information of interest as a data feed [11].

The challenge here is that the smart contract has no way to judge the trustworthiness of the data feed
provider and cannot easily determine if the data feed from random participant bears any resemblance to
the actual real-world data. To work around this issue, the smart contract can utilize two mechanisms to
increase the chances of getting the best and most trusted data feed looking up previous transactions
including data from the feed providers and setting up a mini-auction to source the data from multiple

By referring to previous activity, the smart contract can determine the relative market share and how long
the data feed providers have been operating and use them as a proxy of the trustworthiness of the feed
providers. Of course, this might skew the results to favour incumbents or incentivize dishonest behaviour
for creating large number of transactions, but in a way, this is not much different from how the real world
operates. The other option the creation of mini auction depends on the fact that in a free market the
majority of participants must agree on the fair value of an asset, because only then they can be rewarded
with a successful trade. Thus, when questioned about the price of an asset, the closer to the real price their
answer is, the more likely is for a trade to occur. Smart contracts take advantage of this and offer feed
providers the ability to submit valuation of real-world assets. Once the smart contract receives multiple
valuations, it can take the median and reward the providers who had given prices closest to this median.
Again, this method can be abused by colluding participants, but this is again no different from the real-
world markets. Both of these methods looking up transaction history and mini auctions, do have real
costs (in terms of computational, storage and cryptocurrency fees) associated with them, which means
smart contracts utilizing them will have higher costs for the clients who set them up. One way to minimize
this cost is to avoid the need to do these checks and instead depend on a trusted data feed provider.

Trusted data feed is just a data feed whose provider has accumulated trust in the form of proven number
of successfully executed transactions in the Blockchain. Each time a Blockchain participant (client or smart
contract) needs to publish a transaction using specific data record from the data feed, it can request from
the trusted feed provider to publish that data record as a transaction in the Blockchain and then refer to it
in their own transaction. The feed provider then accumulates trust coins in the form successfully executed
transactions using data from their feed. They can optionally charge a cryptocurrency fee for publishing data
records. The sum of all trust coins over a period of time is the feed provider's trust score. To ensure
fairness, each trust coin has expiration date or depreciate over time, so only providers whose services are
continuously used will get to maintain their high trust score.

Taking this concept further, it can be applied to data contributors (participants who contribute to an
aggregated data feed) as well just as in the feed provider example above, data contributors accumulate
trust score based on how their data end up in the Blockchain. Their trust score is then used to determine
individual contributor's financial rewards. Because there is a direct link between the trust score of the
aggregated data feed with the trust scores attributed to the individual contributors, the feed provider will
have valuable intelligence on how the data is used and adjust its strategy and focus to better serve its

One special case of a data feed is time series where the records are values of single dimension data points
taken at periodic intervals. Just like the trade records, time series are natural fit for storing in the
Blockchain as they form discrete, but linked together chain of events. Certain time series generate
significant amount of data (e.g. full tick market data) which may not be very well suited for one-to-one
mapping of data record and Blockchain transaction due to the overhead added by the public cryptography
and Blockchain storage format. But by using previously described state channels, it is possible to reduce
this overhead while still taking advantage of the benefits from the data integrity, error-detection, tamper-
proofing and the ease of replication afforded by the Blockchain. It will also open the possibilities for
treating time series as smart property and make them available to smart contracts for pay-as-you-go
charging model that can be enforced by following similar approach to that described for data feed

Another example where a Blockchain can be put to good use is the user administration and data
entitlement. User administration is concerned with enforcing permissions and authorization of the users of
particular system as well as recording their access for audit purposes. Data entitlement refers to a set of
rules describing which users and under what conditions they are allowed to access the data in question.
Maintaining fine grained administration and entitlement across a whole ecosystem of products and services
is a major challenge for many organizations and is a problem the Blockchain might be well positioned to
tackle successfully.

As described previously, in the Blockchain users' identity depends upon public key cryptography which
provides strong confidentiality and authentication guarantees. Smart contracts can use these guarantees to
enforce very fine grained rules about the data access thus catering for the entitlement requirements. As an
example, it is trivial to implement in the Blockchain the mechanism used by paid satellite and cable
providers to sell TV channels where the video data is encrypted with cryptographic keys which are changed
(rolled) periodically. As long as the subscribers had paid and acquired the encryption key for the part of the
video data stream they want, they will be able to decrypt it. Acquiring the rolling key can be easily
automated in the Blockchain by using cryptocurrency and a smart contract to manage the subscription
renewals. Additional logic can be added to the smart contract such that it offers discounts for loyal
customers or for new subscribers. The entitlement process is then reduced to ensuring that the different
categories of data are encrypted with unique cryptographic keys which are then distributed only to users
who have the correct entitlements. Using state channels and multi-signatures can enable even more
flexible schemes whereby once the user proves thier entitlement, a state channel is opened and actual data
transfer happens off-the-blockhain until the entitlement expires. When that happens, the data encryption
key is rolled and the state channel is closed. Exactly the same mechanism can be employed for low-latency
transactions where the time for recording and publishing the blocks (Blockchain convergence time) is
considered to be unacceptably long.

In the media world, embargoed news (often for market-moving events) cannot be published until a specific
moment of time in the future. They are often used for quarterly financial reports, product announcements
or interest rates updates. The content of the embargo news is known to the publisher and a small number
of news distributors (but no one else) in advance and it may vary in size, it is just the publishing that needs
to be postponed. This problem can be solved very neatly by the Blockchain. The embargoed news is signed
and encrypted with a new, randomly-generated symmetric key and then submitted as a transaction to the
Blockchain in advance of the publication time. As the symmetric key is kept secret, everyone can see
something has been published, but without actually being able to read the news content. Once the
embargo expires, the publisher creates a new signed transaction, includes the symmetric key as plain text,
publishes it to the Blockchain and links it with the previous transaction. This allows other participants to
successfully decrypt the content of the embargo news as well as confirm it originates from the publisher.

In the legal business, maintaining accurate records of cases and precedents is very important. Just as
important is the ability to identify them correctly among all other such records and to create a link between
them which can be used by legal teams to trace the history and development of laws and cases. Once
again, the Blockchain's ability to store records and provide strong guarantees for their integrity means it is
well suited to cater for the requirements of the legal business. But it can also offer a lot more for example
one can setup a smart contract (or even a Blockchain agent) which automatically collects references for
specific cases or looks for links between them. If the result is encrypted with a provider's public key, then
this provider can build up a database of case relations which can then be monetized.

When it comes to legal contracts and their intersection with the Blockchain, one particular problem is that
the smart contracts, as expressed by code, do not cleanly map to legal concepts. To make the matter more
complex, in Turing-complete Blockchain, the outcome of smart contracts can be very difficult to predict.
Thus, writing a smart contract requires significant cross-domain knowledge and experience which, as with
every emergent technology, are scarce and difficult to acquire and retain. Since the smart contracts is an
area anticipated to grow significantly with the adoption of the Blockchain technology, the lack of
standardized, template smart contracts becomes a significant impediment. Therefore, the idea of smart
contract repositories (or contract libraries as they are sometimes called) which are repositories of well-
understood, verified and trusted smart contracts, becomes an appealing business prospect. There are
efforts to integrate solutions for formal verification of smart contracts where specifically written
algorithms attempt to prove correctness (in the mathematical sense) of a smart contract by trying to find
counter examples (examples which break the assumptions made in the smart contract). These efforts are
still in the proof-of-concept phase and even if successfully realized, they will complement the contract
repositories rather than making them redundant.

When the Blockchain is used to represent real-world assets, the problem with taxonomy (how to name and
refer to these assets) often arises. The simplest solution is to just reuse the real-world terms, but this can
lead to ambiguity because the terms are often region-specific, depend on the local legal jurisdiction, are
not unique or are open for interpretation and thus might be used incorrectly. This is why a single, stable
and well defined taxonomy is important, especially for situations where federated data (data originating
from multiple sources, but treated as a single pool of information) is going to be used. PermIDs can fill the
role of providing unique identifiers representing a variety of companies, assets, financial instruments and
other pieces of information needed by financial, governmental and corporate institutions to communicate
effectively through the Blockchain. Incorporating a common taxonomy will also enable synergy the ability
of different Blockchain implementations to interact with each other via standardized protocols. It will also
open up some new commercial opportunities like an automated way to create entity profiles, trace assets,
overview product life cycle or inspect supply chain for users operating in the Blockchain. These attributes
are also an essential for Know Your Customer (KYC) solutions and thus are of interest to KYC providers.

Blockchain implementations and challenges

By now, the Blockchain is well-established concept. However, the way it has been implemented may differ
in some significant aspects. There are currently multiple competing Blockchain implementation, each with
focus on a set of properties targeting the need of specific users. Here is a brief summary of some of the
leading Blockchain implementations.

Bitcoin [12] [13] is perhaps the best well-known and most-widely used implementation of the public
Blockchain. Many of the concepts of the Blockchain were first implemented and proven to work with it.
Bitcoin's cryptocurrency is mined using proof-of-work which is based around finding a value of a hash less
than a specific value derived from the previous blocks. The implementation of smart contracts is done with
non-Turing complete language which is very low-level, similar to machine (assembly) language. Transaction
fees are optional and transactions with attached fees are given priority when processed and adding to the
Blockchain. The algorithm for the amount of coins collected by the miners is designed as such that the
newly mined coins are steadily decreasing until no more coins can be mined. At that point, it is hoped that
the miners will be solely relying on transaction fees to sustain the peer to peer Bitcoin network.

Etherium [14] [15] is public Blockchain platform which aims to become the universal Blockchain platform. It
has its own cryptocurrency called Ether and features Turing-complete language for implementing flexible
smart contracts. It incorporates many of the lessons learnt from Bitcoin like proof-of-work and transaction
fees, but provides more options for creating advanced applications relying on decentralized Blockchain.
Unlike Bitcoin though, the currency is deflationary i.e. cryptocoins are created continuously. The
justification behind this decision is that it discourages coin hoarding and provides incentives for transacting
and creation of advanced schemes to serve the need for saving accounts.

Hyperledger [16] is one of the newest entrants in the Blockchain technology. It was founded by a
consortium of companies from the technology and financial sectors. The aim is to produce fully modular
Blockchain where the mining algorithm, the consensus, the cryptocurrency and the smart contract virtual
machine can be easily replaced. One of the stated goals is to enable the creation of private Blockchains. At
the time of writing (June 2016) it has not yet produced a code release.

Despite all of its benefits, the Blockchain is not without its problems. A significant challenge with the
current state of play is providing sufficient performance. Most of the available public Blockchain
implementation can only process a maximum of tens to hundreds of transactions per second, far less that
what the markets requires (thousands to tens of thousands of transactions per second). The constantly
growing size of the Blockchain presents difficulties with scaling. Managing large number of private keys in a
secure, yet highly available manner requires careful planning. Losing the private key leads to loss of all
holdings in the cryptocurrencies stored in Blockchain addresses protected by this private key, which will
have a massive impact on the owner of these holdings.

Another challenge that needs to be dealt with is the impact of 51% attack, where a majority of peers
collude to fork or otherwise abuse the Blockchain. There are also some open questions around the security
of the cryptography primitives and certain assumption made by the Blockchain implementations,
compromise of which will cause irreparable harm to the whole Blockchain concept. Another issue, already
mentioned above, is the difficulty writing smart contracts just like in software, a contract may have bugs
which will allow a malicious party to take advantage of them to steal the resources protected by the
contract [17][18]. The mining process, by its nature, is computationally expensive, which means it is also
quite energy-hungry and with very low power efficiency. Finding a way to improve the efficiency of the
mining e.g. by utilizing quantum computers, will open avenues for abuse (e.g. forking the Blockchain), so
getting the right balance is hard problem.

There is active ongoing research on all of these areas and although it will take time to explore and find the
best way to handle the challenges, at the moment there is no reason to assume they cannot be adequately

Blockchain technology is often hailed as a cure for all of the financial industry's ailments. While this view is
perhaps too optimistic, there are certainly plenty of use cases for the technology where it can be applied to
bring more transparency, security and efficiency to current processes. It can be employed to create new
business opportunities, disrupt existing markets or just improve the way the financial services industry

However, just as with any new technology, it does come with uncertainty and cost in learning new skills and
for retooling. While it will always be difficult to predict whether these costs will be justified, given the
disruptive nature of the Blockchain, the strong backing by many financial institutions and the significant
investment in the Blockchain-related projects, for Thomson Reuters it is crucial to be at the forefront and
establishes itself as a leader in this rapidly evolving technology. It will enable the company not only to move
quickly to protect revenue streams which may be impacted by wider Blockchain deployment, but also to
create the relevant intellectual property, acquire the know-how and develop new revenue streams.

The Blockchain is fascinating subject a disruptive intersection between mathematics, cryptography,

computer programming and financial technologies. This paper aims to help jump-start the exploratory
process and to provide the reader with a guide to navigate with confidence through the terminology and
the various concepts of Blockchain technology.

Draft versions of this paper were reviewed by James Shepherd, Craig Hellon and Malcolm Melville. The
author would like to express his gratitude for their feedback and suggestions for improvements.

[1] : Bitcoin Wiki, "Proof of work", 2016,
[2] : Ben Davenport, "What is Multi-Sig, and What Can It Do?", 2015,
[3] : Wikipedia, "Secret sharing", 2016,
[4] : CryptoBond, "What is the Gas in Ethereum?", 2016,
[5] : Mike Hearn, "The resolution of the Bitcoin experiment", ,
[6] : Bitcoin Wiki, "Double spending", 2016,
[7] : Bitcoin Wiki, "Distributed contract", 2016,
[8] : Jeff coleman, "State Channels", 2015, State Channels
[9] : Nick Szabo, "The Idea of Smart Contracts", 1997,
[10] : Bitcoin Wiki, "Agent", 2016,
[11] : Vitalik Buterin, "SchellingCoin: A Minimal-Trust Universal Data Feed", 2014,
[12] : Satoshi Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", 2009,

[13] : Bitcoin, "Bitcoin Developer Guide", 2016,
[14] : Etherium, "Etherium whitepaper", 2016,
[15] : Vitalik Buterin, "Ethereum: Platform Review - Opportunities and Challenges for Private and
Consortium Blockchains", 2016,
[16] : Hyperledger Working Group, "Hyperledger Whitepaper", 2016,
[17] : Joseph Adinolfi, "Digital currency Ethereum nose-dives after $50 million hack", 2016,
[18] : Nathaniel Popper, "A Hacking of More Than $50 Million Dashes Hopes in the World of Virtual
Currency", 2016,