Blockchain: background, challenges and legal issues
Blockchain and distributed ledger technology offers significant and scalableprocessing power, high accuracy rates, and apparently unbreakable securityat a significantly reduced cost compared to the traditional systems thetechnology could replace, such as settlement, trading or accountingsystems. Like all new technology however, it poses challenges for suppliersand customers. So what are the key issues in relation to blockchain anddistributed ledger technology?
Background
In its simplest form, blockchain is a decentralisedtechnology or distributed ledger on which transactionsare anonymously recorded. This means the transactionledger is maintained simultaneously across a networkof unrelated computers or servers called “nodes”, likea spreadsheet that is duplicated thousands of timesacross a network of computers. The ledger containsa continuous and complete record (the chain) of alltransactions performed which are grouped into blocks:a block is only added to the chain if the nodes, whichare members in the blockchain network with high levelsof computing power, reach consensus on the next ‘valid’block to be added to the chain. A transaction can onlybe verified and form part of a candidate block if all thenodes on the network confirm that the transactionis valid. And in order to determine the validity of acandidate block, “miner” nodes compete to solve ahighly complex algorithm to verify it (on the BitcoinBlockchain this is known as the ‘Proof of Work’). Thefirst node to solve the algorithm and validate the blockshould be rewarded – on the Bitcoin Blockchain thisreward takes the form of Bitcoins and this is referredto as “mining for Bitcoins.” Please see the diagram onpage 6 for further detail of this process.
A block generally contains four pieces of information:the ‘hash’ of the previous block, a summary of theincluded transaction, a time stamp, and the Proofof Work that went into creating the secure block.Once information is entered on the blockchain, it isextremely difficult to alter: a blockchain networklacks a centralised point of vulnerability for hackersto exploit and each block includes the previous block’s‘hash’ so any attempts to alter any transaction withthe blockchain are easily detectable.
In other words, blockchain is a self-maintainingdatabase which typically has a “functionality wrapper”,or app development platform, on top. Blockchaincan be thought of as an operating systems for whichuseful applications or “smart contracts” can bewritten. Assets and information about transactionscan be stored and tracked without the involvementof a typical intermediary, such as a bank, or a centralauthority or some other trusted third party.
A blockchain network may be public and open(permissionless) like the internet or structuredwithin a private group like an intranet (permissioned).The blockchains that have captured the imaginations ofmany financial institutions are known as “private” or“permissioned” blockchains because only certain preapprovedparticipants may join them. These blockchainsuse a variety of means to ensure the identity of parties toa transaction and to achieve consensus as to the validityof transactions. The entities creating the “private”blockchain agree on rules that govern how entries arerecorded and under what circumstances they can bemodified. Only specific authorised participants are givenaccess and are known within the network.
Challenges
Security comes (only) with simplicity
One of the key attributes of blockchain is that it is said tobe virtually unhackable due to the complex cryptographyand the distributed nature of the ledger: it is understoodthat a hacker intent on corruption or malpractice wouldneed more computing power than at least half thenodes in the blockchain. This is in stark contrast to theweakness of so many existing highly centralised systemswith a single point of failure.
However, as soon as additional coding complexity isadded to meet later specific requirements, this canintroduce vulnerabilities to the blockchain and so reducethe effectiveness of the ledger’s security.
As a consequence, in order to avoid defeating the verypurpose and attraction of the blockchain, customersmay need to resist the temptation to require bespokedevelopments and modifications (or at least understandthe potential consequences of doing so), whilst vendorswill be required to design both the solution, and anynecessary back-up protocols, to avoid introducingsecurity vulnerabilities in the first place and to providesafeguards in the event this is not completely successful.
Performance challenges
Blockchain databases grow rapidly in size as newtransactions are written, and there is a concern thatthe size of database required, and the consequent speedof access, may make it unsuitable for certain forms oftransactions where speed is of the essence.In this regard, the scalability and resilience of a blockchainsolution is clearly of the utmost criticality, particularlywhere the service is used as part of a financial institution’sability to fulfil trading obligations, customer interactionsor regulatory requirements.
Early adoption
At the moment, many blockchain solutions are ina development or low adoption phase and, as aconsequence, the technology and policies offered arerelatively untrusted. Many organisations will thereforebe uncertain of using services in relation to businesscritical activities without a high degree of confidencein the quality and stability of services it will receive.Vendors will need to be prepared to provide a level ofprotection to customers via not just the solution but thecontractual terms themselves. In this regard, we suspectthat, in the same way that cloud providers have had to,Vendors will need to make concessions to accommodateregulated customers. The extent of such movement willdepend, as ever, on finding an appropriate balance ofrisk for the parties. Given blockchain in its purest formis predicated on multiple users contributing to the chain,so the on-going success and viability of blockchain as amarket initiative will depend on the confidence placed init by the various market users.
Legal Issues
Jurisdiction
Blockchain has the ability to cross jurisdictionalboundaries as the nodes on a blockchain can be locatedanywhere in the world. This can pose a number ofcomplex jurisdictional issues which require carefulconsideration in relation to the relevant contractualrelationships.
The principles of contract and title differ acrossjurisdictions and therefore identifying the appropriategoverning law is essential. In a conventional bankingtransaction, for example, if the bank is at fault thenirrespective of the transacting mechanism or location,the bank can be sued and the applicable jurisdiction willmost likely be contractually governed. However, in adecentralised environment, it may be difficult to identifythe appropriate set of rules to apply.
At its simplest level, every transaction could potentiallyfall under the jurisdiction(s) of the location of each andevery node in the network. Clearly, this could result inthe blockchain needing to be compliant with an unwieldynumber of legal and regulatory regimes. In the event afraudulent or erroneous transaction is made, pinpointingits location within the blockchain could be challenging.
The inclusion of an exclusive governing law andjurisdiction clause is therefore essential and shouldensure that a customer has legal certainty as to the lawto be applied to determine the rights and obligationsof the parties to the agreement and which courts willhandle any disputes.
Service levels and performance
The willingness of vendors to commit to performanceassurances is likely to depend on three considerations:(i) their risk/reward profile; (ii) the service deliverymodel and (iii) the “multiplication factor” of acceptingsignificant liability for multiple customers – on a “oneto many” approach – at the same time. This is likelyto mean vendors preferring to offer the technologyand service on an almost “as is” basis, with a limitedavailability service level, and excluding warrantiesregarding performance of the services, leavingcustomers without any assurance that the technologywill function as described or the service be reliableand available. However for users who are utilising theservice as part of their business, this is unlikely to bean acceptable proposal. The balance of performancerisk will therefore be a key issue.
Liability
The risk to customers of a systemic issue with tradingrelated infrastructure such as blockchain could bematerial if trades are not settled or are settledincorrectly. Likewise the risk relating to security andconfidentiality will be towards the top of the risk issuesof any prospective customer.
Blockchain poses different risks as a consequence ofthe technology and manner of operations: one of themain issues affecting public blockchain is the inabilityto control and stop its functioning. In case of a privateblockchain, the lack of control on the functioning of theplatform does not apply but whether or not this wouldbe sufficient to trigger a liability of the company managingthe platform has not yet been tested.
So the allocation and attribution of risk and liability inrelation to a malfunctioning blockchain service mustbe thought through carefully, not just at the vendor-customerlevel, but as between all relevant participants,in particular the parties (perhaps counter-parties for atrade) affected by the issues.
Intellectual property
There is inevitably value in the blockchain, and ownershipof the IP in it will likely form an important considerationalbeit that the limitations on the patentability of softwareand business processes (in the UK at least will erode someof the relevant issues). However, given the amount ofinvestment and the potential financial returns of blockchaintechnology, blockchain vendors will have to determinetheir IP strategy: vendors will likely want to capitalize onany other commercial benefits to be generated from theBlockchain, including commercialization of the underlyingdata 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 whichoverlay the core, developed to meet a customer’s specificrequirements? Possible IP options are no different to anyother software development agreement and are likely tohinge on whether those specific requirements could givea customer a competitive edge and/or can be used bythe blockchain vendor with another customer or by thecustomer with another blockchain vendor. Depending onthe answer to these questions, a customer may insist onownership of such developments, may be willing to ‘merely’license them for the term of the agreement (or perpetually ifusable with other networks) or restrict the vendor’s abilityto use such developments in some way, whether time, useor recipient based or a combination of all three.
An “open innovation” approach is prevalent throughoutfintech. Financial organisations are working towards a viableblockchain proof of concept and are developing a lot of codein-house. Traditionally financial organisations have expectedto own the IP in any software that they develop. Howeverthere appears to be a realisation that technology will have tobe shared in order for value to be gained.
Data privacy
As one of the key USPs of the blockchain is that oncedata is stored it cannot be altered (at least, not easily),this clearly has implications for data privacy, particularlywhere the relevant data is personal data or metadatasufficient to reveal someone’s personal details. Equally theunique transparency of transactions on the blockchainis not easily compatible with the privacy needs of thebanking sector: the use of crypto-addresses for identityis problematic as no bank likes providing its competitorswith precise information about its transactions and thebanking 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 todesign privacy-protecting blockchains. This might includelimiting 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 remainsto be seen how vendors, particularly those targeting thefinancial services industry, tackle the balance of privacyversus transparency.
Decentralised AutonomousOrganisations (DAOs)
DAOs are essentially online, digital entities that operatethrough the implementation of pre-coded rules.These entities often need minimal to zero input intotheir operation and they are used to execute smartcontracts, recording activity on the blockchain.
Modern legal systems are designed to alloworganisations, as well as actual people, to participate.Most legal systems do this by giving organisationssome 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 aDAO? Are they simple corporations, partnerships,legal entities, legal contracts or something else?
Since the DAOs “management” is conductedautomatically, legal systems would have to decide who isresponsible if laws are broken. What, if, any, is the liabilityof DAOs and their creators? Who or what is claimedagainst in the case of a legal dispute?
Courts and regulators are unlikely to allow the wholesaleadoption of technology which bypasses establishedoversight.
The enforceability of smartcontracts
Blockchain makes possible the use of so-called “smartcontracts”. Smart contracts are blockchain basedcontracts which are automatically executed uponcertain specified criteria coded into the contractbeing met. Execution over the blockchain networkeliminates the need for intermediary parties to confirmthe transaction, leading to self-executing contractualprovisions. In addition to the cost and efficiencygains it is hoped this will achieve, this also raisessignificant legal questions in relation to applicableregulation, leaving a sense of uncertainty as to the legalenforceability of smart contracts.
Since smart contracts are prewritten computer codes,their use may present enforceability questions if attemptingto analyse them within the traditional ‘contract’ definition.This is particularly true where smart contracts are builton permissionless blockchains, which do not allow fora central controlling authority. Since the point of suchblockchains is to decentralize authority, they might notprovision for an arbitrator to resolve any disputes thatarise over a contract that is executed automatically.It remains unclear whether the elements of capacity,including the ability to rely on apparent or ostensibleauthority would apply and the questions of offer andacceptance, certainty and consideration would also needto be considered. However, there have been advancesin many countries regarding the level of acceptability ofelectronic contracts so it is realistic to hope this is carriedover to smart contracts. In the meantime, customersshould ensure that smart contracts include a disputeresolution provision to reduce uncertainty and provide fora mechanism in the event of a dispute.
Compliance with financial servicesregulation
Many sourcing arrangements, including the use of certaintechnology solutions, require regulated entities to includein the relevant contracts a series of provisions enablingthem to exert control, and seek to achieve operationalcontinuity in relation to the services to which thecontracts relate. With blockchain (as has been the casewith cloud and certain FinTech agreements) this maywell be more of a challenge. The contracts and overallarrangement will need to be carefully reviewed to ensurecompliance, as required. For in-depth analysis of thecurrent state of the regulatory landscape, please see ourpublication “The Blockchain revolution: an analysisof regulation and technology related to distributedledger technologies.”
Exit
The need for exit assistance will be determined in largepart by the specific solution and the extent to whichthe blockchain vendor holds the customer’s data. If thecustomer does not have its own copy of the data, itwill require data migration assistance to ensure thevendor is obliged to hand over all such data on expiryor termination of the agreement and a complete recordof all transactions stored on the blockchain.
Is data on a blockchain “property”?
At common law as a general principle there is noproperty right in information itself, but that whileindividual items of information do not attract propertyrights, compilations of data – for example in a database– may be protected by intellectual property rights.Where a database of personal information is sold, if abuyer wants to use the personal information for a newpurpose, in order to comply with the Data ProtectionAct they will have to get consent for this from theindividuals concerned.
Due diligence on blockchain
Public companies and private investors have alreadybegun to make significant capital investments inblockchain technology startups. This trend is likely toaccelerate as commercial deployments of blockchaintechnology become a reality. Transactional lawyers whoare tasked with performing due diligence on the buyand/or sell side in connection with these investmentsneed to understand blockchain technology and theemerging business models based on the technology.Traditional due diligence approaches may need tobe adapted. For example, there will be unique issuesconcerning ownership of data residing on decentralisedledgers and intellectual property ownership ofblockchain-as-a-service offerings operating on opensource blockchain technology platforms. These issueswill need to be considered in the context of the businessvalue proposition and competitive barriers to entry.
Conclusion
Blockchain does have the potential to becomean integral part of the operation of many businesses,offering scalability, security and computing power ata lower CAPEX and OPEX. But, of course, as is thecase with most new technology service offerings,there are a number of risk based issues that need tobe carefully considered before business, particularlyheavily-regulated ones, can start to fully realise thepotential 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).
