Blockchain and distributed ledger technology offers significant and scalable
processing power, high accuracy rates, and apparently unbreakable security
at a significantly reduced cost compared to the traditional systems the
technology could replace, such as settlement, trading or accounting
systems. Like all new technology however, it poses challenges for suppliers
and customers. So what are the key issues in relation to blockchain and
distributed ledger technology?
Background
In its simplest form, blockchain is a decentralised
technology or distributed ledger on which transactions
are anonymously recorded. This means the transaction
ledger is maintained simultaneously across a network
of unrelated computers or servers called “nodes”, like
a spreadsheet that is duplicated thousands of times
across a network of computers. The ledger contains
a continuous and complete record (the chain) of all
transactions performed which are grouped into blocks:
a block is only added to the chain if the nodes, which
are members in the blockchain network with high levels
of computing power, reach consensus on the next ‘valid’
block to be added to the chain. A transaction can only
be verified and form part of a candidate block if all the
nodes on the network confirm that the transaction
is valid. And in order to determine the validity of a
candidate block, “miner” nodes compete to solve a
highly complex algorithm to verify it (on the Bitcoin
Blockchain this is known as the ‘Proof of Work’). The
first node to solve the algorithm and validate the block
should be rewarded – on the Bitcoin Blockchain this
reward takes the form of Bitcoins and this is referred
to as “mining for Bitcoins.” Please see the diagram on
page 6 for further detail of this process.
A block generally contains four pieces of information:
the ‘hash’ of the previous block, a summary of the
included transaction, a time stamp, and the Proof
of Work that went into creating the secure block.
Once information is entered on the blockchain, it is
extremely difficult to alter: a blockchain network
lacks a centralised point of vulnerability for hackers
to exploit and each block includes the previous block’s
‘hash’ so any attempts to alter any transaction with
the blockchain are easily detectable.
In other words, blockchain is a self-maintaining
database which typically has a “functionality wrapper”,
or app development platform, on top. Blockchain
can be thought of as an operating systems for which
useful applications or “smart contracts” can be
written. Assets and information about transactions
can be stored and tracked without the involvement
of a typical intermediary, such as a bank, or a central
authority or some other trusted third party.
A blockchain network may be public and open
(permissionless) like the internet or structured
within a private group like an intranet (permissioned).
The blockchains that have captured the imaginations of
many financial institutions are known as “private” or
“permissioned” blockchains because only certain preapproved
participants may join them. These blockchains
use a variety of means to ensure the identity of parties to
a transaction and to achieve consensus as to the validity
of transactions. The entities creating the “private”
blockchain agree on rules that govern how entries are
recorded and under what circumstances they can be
modified. Only specific authorised participants are given
access and are known within the network.

Challenges
Security comes (only) with simplicity
One of the key attributes of blockchain is that it is said to
be virtually unhackable due to the complex cryptography
and the distributed nature of the ledger: it is understood
that a hacker intent on corruption or malpractice would
need more computing power than at least half the
nodes in the blockchain. This is in stark contrast to the
weakness of so many existing highly centralised systems
with a single point of failure.
However, as soon as additional coding complexity is
added to meet later specific requirements, this can
introduce vulnerabilities to the blockchain and so reduce
the effectiveness of the ledger’s security.
As a consequence, in order to avoid defeating the very
purpose and attraction of the blockchain, customers
may need to resist the temptation to require bespoke
developments and modifications (or at least understand
the potential consequences of doing so), whilst vendors
will be required to design both the solution, and any
necessary back-up protocols, to avoid introducing
security vulnerabilities in the first place and to provide
safeguards in the event this is not completely successful.
Performance challenges
Blockchain databases grow rapidly in size as new
transactions are written, and there is a concern that
the size of database required, and the consequent speed
of access, may make it unsuitable for certain forms of
transactions where speed is of the essence.
In this regard, the scalability and resilience of a blockchain
solution is clearly of the utmost criticality, particularly
where the service is used as part of a financial institution’s
ability to fulfil trading obligations, customer interactions
or regulatory requirements.
Early adoption
At the moment, many blockchain solutions are in
a development or low adoption phase and, as a
consequence, the technology and policies offered are
relatively untrusted. Many organisations will therefore
be uncertain of using services in relation to business
critical activities without a high degree of confidence
in the quality and stability of services it will receive.
Vendors will need to be prepared to provide a level of
protection to customers via not just the solution but the
contractual terms themselves. In this regard, we suspect
that, in the same way that cloud providers have had to,
Vendors will need to make concessions to accommodate
regulated customers. The extent of such movement will
depend, as ever, on finding an appropriate balance of
risk for the parties. Given blockchain in its purest form
is predicated on multiple users contributing to the chain,
so the on-going success and viability of blockchain as a
market initiative will depend on the confidence placed in
it by the various market users.
Legal Issues
Jurisdiction
Blockchain has the ability to cross jurisdictional
boundaries as the nodes on a blockchain can be located
anywhere in the world. This can pose a number of
complex jurisdictional issues which require careful
consideration in relation to the relevant contractual
relationships.
The principles of contract and title differ across
jurisdictions and therefore identifying the appropriate
governing law is essential. In a conventional banking
transaction, for example, if the bank is at fault then
irrespective of the transacting mechanism or location,
the bank can be sued and the applicable jurisdiction will
most likely be contractually governed. However, in a
decentralised environment, it may be difficult to identify
the appropriate set of rules to apply.
At its simplest level, every transaction could potentially
fall under the jurisdiction(s) of the location of each and
every node in the network. Clearly, this could result in
the blockchain needing to be compliant with an unwieldy
number of legal and regulatory regimes. In the event a
fraudulent or erroneous transaction is made, pinpointing
its location within the blockchain could be challenging.
The inclusion of an exclusive governing law and
jurisdiction clause is therefore essential and should
ensure that a customer has legal certainty as to the law
to be applied to determine the rights and obligations
of the parties to the agreement and which courts will
handle any disputes.
Service levels and performance
The willingness of vendors to commit to performance
assurances is likely to depend on three considerations:
(i) their risk/reward profile; (ii) the service delivery
model and (iii) the “multiplication factor” of accepting
significant liability for multiple customers – on a “one
to many” approach – at the same time. This is likely
to mean vendors preferring to offer the technology
and service on an almost “as is” basis, with a limited
availability service level, and excluding warranties
regarding performance of the services, leaving
customers without any assurance that the technology
will function as described or the service be reliable
and available. However for users who are utilising the
service as part of their business, this is unlikely to be
an acceptable proposal. The balance of performance
risk will therefore be a key issue.
Liability
The risk to customers of a systemic issue with trading
related infrastructure such as blockchain could be
material if trades are not settled or are settled
incorrectly. Likewise the risk relating to security and
confidentiality will be towards the top of the risk issues
of any prospective customer.
Blockchain poses different risks as a consequence of
the technology and manner of operations: one of the
main issues affecting public blockchain is the inability
to control and stop its functioning. In case of a private
blockchain, the lack of control on the functioning of the
platform does not apply but whether or not this would
be sufficient to trigger a liability of the company managing
the platform has not yet been tested.
So the allocation and attribution of risk and liability in
relation to a malfunctioning blockchain service must
be thought through carefully, not just at the vendorcustomer
level, but as between all relevant participants,
in particular the parties (perhaps counter-parties for a
trade) affected by the issues.
Intellectual property
There is inevitably value in the blockchain, and ownership
of the IP in it will likely form an important consideration
albeit that the limitations on the patentability of software
and business processes (in the UK at least will erode some
of the relevant issues). However, given the amount of
investment and the potential financial returns of blockchain
technology, blockchain vendors will have to determine
their IP strategy: vendors will likely want to capitalize on
any other commercial benefits to be generated from the
Blockchain, including commercialization of the underlying
data set. To the extent the data set relates to the users,
this is likely to be a carefully negotiated area.
Likewise, what of specific developments or solutions which
overlay the core, developed to meet a customer’s specific
requirements? Possible IP options are no different to any
other software development agreement and are likely to
hinge on whether those specific requirements could give
a customer a competitive edge and/or can be used by
the blockchain vendor with another customer or by the
customer with another blockchain vendor. Depending on
the answer to these questions, a customer may insist on
ownership of such developments, may be willing to ‘merely’
license them for the term of the agreement (or perpetually if
usable with other networks) or restrict the vendor’s ability
to use such developments in some way, whether time, use
or recipient based or a combination of all three.
An “open innovation” approach is prevalent throughout
fintech. Financial organisations are working towards a viable
blockchain proof of concept and are developing a lot of code
in-house. Traditionally financial organisations have expected
to own the IP in any software that they develop. However
there appears to be a realisation that technology will have to
be shared in order for value to be gained.
Data privacy
As one of the key USPs of the blockchain is that once
data is stored it cannot be altered (at least, not easily),
this clearly has implications for data privacy, particularly
where the relevant data is personal data or metadata
sufficient to reveal someone’s personal details. Equally the
unique transparency of transactions on the blockchain
is not easily compatible with the privacy needs of the
banking sector: the use of crypto-addresses for identity
is problematic as no bank likes providing its competitors
with precise information about its transactions and the
banking secrecy must be kept by law.
In order to prevent this becoming a barrier to take-up,
technology-based solutions will need to be found to
design privacy-protecting blockchains. This might include
limiting who can join the blockchain network to “trusted”
nodes and encrypting the data on the blockchain,
although this is not without its challenges, and it remains
to be seen how vendors, particularly those targeting the
financial services industry, tackle the balance of privacy
versus transparency.
Decentralised Autonomous
Organisations (dAOs)
DAOs are essentially online, digital entities that operate
through the implementation of pre-coded rules.
These entities often need minimal to zero input into
their operation and they are used to execute smart
contracts, recording activity on the blockchain.
Modern legal systems are designed to allow
organisations, as well as actual people, to participate.
Most legal systems do this by giving organisations
some of the legal powers that real people have –
e.g. the power to enter into legal contracts, to sue,
and to be sued. But what legal status will attach to a
DAO? Are they simple corporations, partnerships,
legal entities, legal contracts or something else?
Since the DAOs “management” is conducted
automatically, legal systems would have to decide who is
responsible if laws are broken. What, if, any, is the liability
of DAOs and their creators? Who or what is claimed
against in the case of a legal dispute?
Courts and regulators are unlikely to allow the wholesale
adoption of technology which bypasses established
oversight.
The enforceability of smart
contracts
Blockchain makes possible the use of so-called “smart
contracts”. Smart contracts are blockchain based
contracts which are automatically executed upon
certain specified criteria coded into the contract
being met. Execution over the blockchain network
eliminates the need for intermediary parties to confirm
the transaction, leading to self-executing contractual
provisions. In addition to the cost and efficiency
gains it is hoped this will achieve, this also raises
significant legal questions in relation to applicable
regulation, leaving a sense of uncertainty as to the legal
enforceability of smart contracts.
Since smart contracts are prewritten computer codes,
their use may present enforceability questions if attempting
to analyse them within the traditional ‘contract’ definition.
This is particularly true where smart contracts are built
on permissionless blockchains, which do not allow for
a central controlling authority. Since the point of such
blockchains is to decentralize authority, they might not
provision for an arbitrator to resolve any disputes that
arise over a contract that is executed automatically.
It remains unclear whether the elements of capacity,
including the ability to rely on apparent or ostensible
authority would apply and the questions of offer and
acceptance, certainty and consideration would also need
to be considered. However, there have been advances
in many countries regarding the level of acceptability of
electronic contracts so it is realistic to hope this is carried
over to smart contracts. In the meantime, customers
should ensure that smart contracts include a dispute
resolution provision to reduce uncertainty and provide for
a mechanism in the event of a dispute.
Compliance with financial services
regulation
Many sourcing arrangements, including the use of certain
technology solutions, require regulated entities to include
in the relevant contracts a series of provisions enabling
them to exert control, and seek to achieve operational
continuity in relation to the services to which the
contracts relate. With blockchain (as has been the case
with cloud and certain FinTech agreements) this may
well be more of a challenge. The contracts and overall
arrangement will need to be carefully reviewed to ensure
compliance, as required. For in-depth analysis of the
current state of the regulatory landscape, please see our
publication “The Blockchain revolution: an analysis
of regulation and technology related to distributed
ledger technologies.”
Exit
The need for exit assistance will be determined in large
part by the specific solution and the extent to which
the blockchain vendor holds the customer’s data. If the
customer does not have its own copy of the data, it
will require data migration assistance to ensure the
vendor is obliged to hand over all such data on expiry
or termination of the agreement and a complete record
of all transactions stored on the blockchain.
Is data on a blockchain “property”?
At common law as a general principle there is no
property right in information itself, but that while
individual items of information do not attract property
rights, compilations of data – for example in a database
– may be protected by intellectual property rights.
Where a database of personal information is sold, if a
buyer wants to use the personal information for a new
purpose, in order to comply with the Data Protection
Act they will have to get consent for this from the
individuals concerned.
Due diligence on blockchain
Public companies and private investors have already
begun to make significant capital investments in
blockchain technology startups. This trend is likely to
accelerate as commercial deployments of blockchain
technology become a reality. Transactional lawyers who
are tasked with performing due diligence on the buy
and/or sell side in connection with these investments
need to understand blockchain technology and the
emerging business models based on the technology.
Traditional due diligence approaches may need to
be adapted. For example, there will be unique issues
concerning ownership of data residing on decentralised
ledgers and intellectual property ownership of
blockchain-as-a-service offerings operating on open
source blockchain technology platforms. These issues
will need to be considered in the context of the business
value proposition and competitive barriers to entry.
Conclusion
Blockchain does have the potential to become
an integral part of the operation of many businesses,
offering scalability, security and computing power at
a lower CAPEX and OPEX. But, of course, as is the
case with most new technology service offerings,
there are a number of risk based issues that need to
be carefully considered before business, particularly
heavily-regulated ones, can start to fully realise the
potential benefit.
If you would like to discuss the issues arising out of this publication, please get in touch with your usual DLA Piper contact, or email Jessica Sanders or John D. McGonagle (Senior Associates in DLA Piper’s UK Intellectual Property and Technology practice).