The Singapore Law Gazette

Blockchain Records under Singapore Law

The current interest in blockchain technology can be attributed in large part to the immutability of blockchain records. While this is not an essay about how blockchain works, a brief description of how blocks of transactional records are created and chained provides a necessary introduction to its defining feature.

Introduction to Blockchain

Briefly, the uniqueness of blockchain technology lies in how transactional records are organised into blocks and how blocks of records are linked in order to form the blockchain. Put simply, whenever a new block is created, the hash of its preceding block is incorporated as a data element in the new block. When a third block is created, the hash of the second block that is generated will include the hash value of the first block as one of the input data elements. It is therefore possible to picture how blocks are thereby linked together in a chain and imagine how each block contains ever decreasing traces of all preceding blocks.

One important feature of the hash is that it is a probabilistically unique signature that anyone reading the block with the correct cryptographic tool will be able to verify. If there is a change in the content of the preceding block, then its hash cannot be verified, thereby highlighting that records in the preceding block had been altered. Because each new hash will be created using the hash of the preceding block as one of its input, the effect of making changes to one block means that the hash values of all subsequent blocks have to be re-generated. This may be computationally feasible when dealing with a handful of records, but the older the record gets, the more computationally expensive this becomes.

The other important aspect of a blockchain is its distributed nature. Through a complex consensus algorithm, each new block is replicated to every node in the blockchain network. Not all participants in the network can add a new block. Currently, the most commonly known method of adding a new block is the proof of works method, popularised by Bitcoins. The first participant to complete a complex mathematical calculation is entitled to add a new block to the chain. As the number of mining nodes in the network increases, the number of participants working on mathematical problems increases. New blocks can be added to any of the mining nodes and once received, and verified, it will be replicated across the network of nodes.

While the proof of works method is common for public blockchains, this is computationally resource-intensive and slow. The alternative method that is currently gaining ground is proof of stake, which uses the percentage of stake that a miner has in the system to determine the probability that he can validate the addition of a new block: eg if the participant has 2% stake then he has a 2% chance of validating a new block.¹ “Proof of Work vs Proof of Stake: Basic Mining Guide” <https://blockgeeks.com/guides/proof-of-work-vs-proof-of-stake/> (last accessed 9 August 2018). In private blockchains where participation is based on permission and there is a higher degree of trust amongst participants, neither proof of works or proof of stake are necessary.

The Immutability of Blockchain Records

Combine the hashing function and the distributed nature of a blockchain network, one can start to appreciate why it has been said that information in blockchains are technically immutable. This is a theoretical claim about how making changes to information in a blockchain is computationally infeasible, although not impossible. (See https://spectrum.ieee.org/computing/networks/the-future-of-the-web-looks-a-lot-like-bitcoin). There lies the potential to put into perspective, significantly unlikely — that sufficient participants in a public blockchain can collude to replace a past record in a block and recreate subsequent blocks. This is not a trivial task since public blockchain can contain upwards of 10,000 nodes; but this becomes hypothetically possible when one considers the following two risks.

First, not all nodes on the network are mining nodes and it is the mining nodes that matter in a proof of work blockchain network. Second, controls of the mining nodes. The infrastructural and resource investment required for proof of works mining can discourage independent miners such that mining nodes are concentrated into the hands of serious players. The risk that some of these players acting in concert are able to marshal at least 51% of the compute power in the network becomes less remote.² See Basic Primer: Blockchain Consensus Protocol, at #1 Proof of Work, <https://blockgeeks.com/guides/blockchain-consensus/> (last accessed 11 August 2018). Hence the game theory of the tragedy of commons, whereby even though there is a large number of nodes in a public blockchain, the number of active mining nodes can be sufficiently low that a 51% attack is possible.³ See Tragedy of the Commons <https://en.bitcoin.it/wiki/Tragedy_of_the_Commons> (last accessed 30 July 2018). Proof of stake blockchain networks address the risk of a 51% attack by limiting the number of trustworthy validators of new blocks in the network and determining each validator’s chance of validating a new block based on his proportionate stake in the network.

But this is not to say that records in a public blockchain can never be altered. When the collective of participants in a public blockchain agrees to changes, it is possible that records be re-generated. There has been at least one notorious case (ie, Ethereum DAO) when the community agreed to fork the blockchain network — because they could not all agree to change past records — thereby creating two networks after a particular record.

Private (or permissioned) blockchains are limited to a smaller number of participants and are commonly used in commercial deployments of blockchain technology. The risk of unauthorised re-creation of past records arising from collusion increases (ie 51% attack in a proof of work chain), although the likelihood, size and impact is still significantly ameliorated by reason of the distributed nature of the blockchain network. Moreover, the choice between using a public or creating a private chain is often driven by other considerations, for example whether the consortium is a closed one that requires members to agree to its club rules, the nature of the information that is transmitted and the transactions that are recorded, and whether the consortium members wish to keep these away from a more publicly accessible infrastructure.

Focusing on the Ledger Function of Blockchain

While blockchain applications that are commonly featured in popular media have predominantly been in the area of cryptocurrencies and Initial Coin Offerings (ICOs),⁴ Technically, there is a difference between ICOs that create a new blockchain and those that create new cypto-tokens on an existing public blockchain (eg Ethereum). blockchain technology has gained traction as a building block in IT systems for commercial use in a number of areas. The range of proof-of-concepts and pilots that use blockchains have mushroomed in diverse areas like Know-Your-Customer,⁵Consortium of banks, together with IMDA Singapore, completes proof-of-concept for ASEAN’s first industry KYC Blockchain, OpenGov (28 Oct 2017) <https://www.opengovasia.com/articles/8093-consortium-of-banks-together-with-imda-completes-proof-of-concept-for-aseans-first-industry-kyc-blockchain> trade finance,⁶Banks team up with IBM in trade finance blockchain, FT (5 Oct 17) <https://www.ft.com/content/7dc8738c-a922-11e7-93c5-648314d2c72c>; Hong Kong, Singapore to link up trade finance blockchain platforms, Reuters (25 Oct 2017) <https://www.reuters.com/article/us-hongkong-singapore-fintech/hong-kong-singapore-to-link-up-trade-finance-blockchain-platforms-idUSKBN1CU0JY>; and MAS to debut blockchain-based trade network with HK in 2019, BT (15 Nov 2017) <http://www.businesstimes.com.sg/government-economy/singapore-fintech-festival-2017/mas-to-debut-blockchain-based-trade-network-with>. supply chain management,⁷IBM Reveals Blockchain Supply Chain Trial with Singapore Port Operator, coindesk (16 Aug 2017) <https://www.coindesk.com/ibm-reveals-blockchain-supply-chain-trial-singapore-port-operator/>; and New blockchain based proof-of-concept to link digital trading platforms in Japan & Singapore, Supply Chain Asia (1 Mar 2017) <https://www.coindesk.com/ibm-reveals-blockchain-supply-chain-trial-singapore-port-operator/>. service level agreements,⁸IBM and Bank of Tokyo-Mitsubishi UFJ Develop Blockchain-Powered Contract Management System, BitCoin Magazine (22 Sep 2016) <https://bitcoinmagazine.com/articles/ibm-and-bank-of-tokyo-mitsubishi-ufj-develop-blockchain-powered-contract-management-system-1474552533/>. insurance,⁹AIG teams with IBM to use blockchain for ‘smart’ insurance policy, TODAYonline (15 Jun 2017) <http://www.todayonline.com/business/aig-teams-ibm-use-blockchain-smart-insurance-policy>. and interbank settlements.¹⁰Singapore to launch blockchain project for interbank payments, among other fintech initiatives: MAS, BT (16 Nov 2016) <http://www.straitstimes.com/uncategorized/singapore-to-launch-blockchain-pilot-project-for-interbank-payments>; and Ubin Part 2: Singapore Central Bank Publishes Blockchain Project Details, coindesk (14 Nov 2017) <https://www.coindesk.com/ubin-part-2-singapore-central-bank-publishes-blockchain-project-details/>. The focus of this essay is on blockchain as a building block of IT systems and the legal analysis will concentrate on those areas of laws that have horizontal application. Compliance with sectoral regulations will depend very much on the sectors in which the IT system is commercially deployed in.

As the title of this essay expresses, the focus of the legal analysis is the application of Singapore law on blockchain technology when it plays a record-keeping function. The next instalment of this essay will discuss issues relating to the self-executing capability of blockchain platforms that store executable codes in the blockchain, known by the somewhat verisimilitudinous label of “blockchain smart contracts”. The record-keeping function of a blockchain can be analysed from the perspective that it is in essence a type of decentralised database. Indeed, it falls within the supergroup of Distributed Ledger Technologies.¹¹Distributed Ledger Technology (DLT) and Blockchain, World Bank Group (2017) <http://documents.worldbank.org/curated/en/177911513714062215/pdf/122140-WP-PUBLIC-Distributed-Ledger-Technology-and-Blockchain-Fintech-Notes.pdf>. As a database, blockchains should raise no additional issues that our existing laws has not already addressed. However, the immutable nature of records stored in the blockchain network and the network’s decentralised nature raises additional issues that do not usually surface when relational databases are used in a more traditional three-tier architecture for web-based application systems.¹² Ie a presentation tier, application tier and data tier: see “3-Tier Architecture: A Complete Overview” <https://www.jinfonet.com/resources/bi-defined/3-tier-architecture-complete-overview/> (last accessed 9 August 2018) and “Three-Tier Architecture” <https://www.techopedia.com/definition/24649/three-tier-architecture> (last accessed 9 August 2018).

As this is an essay discussing the legal effect of blockchain technology, the present author refrains from wading into the ongoing debate about whether blockchain technology can be an effective option in application systems that require high frequency calls to or creation of records in the blockchain because of the proof of work (and even the proof of stake) requirement; or criticisms that (particularly for public blockchains) there are both technical and commercial limits to how much information can realistically be stored on the blockchain (as opposed to a pointer to an off-chain repository where the data is actually stored).

But before we dive into a more involved legal discussion, we should fix the role and function of blockchain in context. In any commercial application, blockchain technology is deployed as one of its building blocks. Whether the blockchain that is utilised is a public or private one, it is probably not the only sub-system that performs an information-storing function. Invariably, a relational database is still necessary for the application system. The blockchain is used selectively, when the information that is stored on it or linked to it needs to be decentralised and to benefit from its technical immutability. For example, the details of a bill of lading may sit in a database while those data elements that are directly relevant for tracking its movement may be stored in the blockchain or linked to the chain. And these are only the components that deal with data storage and retrieval. In any application system, there are a number of other sub-systems involved: eg communications, and programming logic implementing business rules.

Adducing blockchain records in evidence

With the 2012 amendments to the Evidence Act over a quinquennium ago, positive proof of reliability of electronic records — or computer output — is no longer required. A set of presumptions were introduced under Section 116A of the Evidence Act; and the rules of determination as to whether electronic records are primary or secondary evidence had been changed.

As an aside, one wonders whether the removal of the requirement of positive prove of reliability makes a practical difference when it concerns a developing technology like blockchain. Under the previous regime, a person who is familiar with the operation of the application system that had produced the electronic record would have had to produce a certificate stating the reasons why he believed the computer output to be reliable, and that there was no reason to doubt its reliability by reason of erroneous operation of the said application system. This person would have had — especially in an application system that made use of developing technology — to invest some time to explaining how the technology worked and (should the matter proceed to trial) take the stand to defend the reliability of the computer output. Post the 2012 amendments, should the reliability of the output of an application system that makes use of blockchain technology be the called to question — and one can assume that this will be de riguer when the first cases find their way into the courtroom — it would be necessary for the party relying on the electronic record to produce witnesses to attest to its reliability. Thus, for all intents and purposes, one can expect that the dispensation of positive proof of reliability would not translate to a lighter evidential burden on the party relying on electronic records produced from an application system that makes use of blockchain technology.¹³ See Mitfam International Ltd v Motley Resources Pte Ltd [2014] 1 SLR 1253; [2013] SGHC 270, at [26], et seq for an example of a case where the defendant, who was relying on a printout of an electronic ledger, having failed to call the ledger keeper to give evidence on the accuracy of the ledger and the running account which it purported to reflect, was not able to admit the ledger into evidence.

Blockchain Records are Original Documents that can be Adduced as Primary Evidence

The immutability of blockchain records does provide some legal benefits, in addition to the technical benefits hereinbefore traversed. For one, it makes it easier to rely on the explanations in section 64 of the Evidence Act to prove that a record in a block is primary evidence.¹⁴ See Solomon Alliance Management Pte Ltd v Pang Chee Kuan [2018] SGHC 139 for a case that applied Explanation 3 in section 64 of the Evidence Act to presume that video footages copied from a recording device were accurate and hence primary evidence. In the majority of current use cases, information that is stored on the blockchain is transactional in nature. The information will be tendered as evidence that a transaction took place. As this information exists nowhere else outside the blockchain, the record will be tendered as primary evidence of an original document. The decentralised nature of the blockchain means that a copy of the transactional record may be retrieved from any node. Can each copy be primary evidence?

Explanation 3 is the first of the Section 64 explanations that one usually considers: viz, if an electronic record can be shown to reflect a document accurately, then the electronic record is primary evidence. The primary consideration is whether the information that is in each node of the blockchain are accurate copies of each other. The hashing feature of blockchains and how each block of records is created with a hash that incorporates the hash of the preceding block can be relied on to demonstrate accuracy in this sense. This same analysis can also be applied to determine that blockchain records can be produced as an original document, record or information under Section 10 of the Electronic Transactions Act since the hashing function can provide “reliable assurance”¹⁵ Section 10(1) ETA. that the integrity of the information has “remained complete and unaltered”.¹⁶ Section 10(2) ETA. Hence, blockchain records can be proffered as primary evidence and as original documents.¹⁷ See also Yeong Zee Kin & Paul Chan, “Electronic Evidence in Singapore: Out with the Old, In with the New” Internationa Conference on Electronic Litigation (2012, Lee & Yeong Eds), p 201, at 223 – 226.

It is in this context that we turn to consider the effects of stale or orphaned blocks and soft forks in public blockchains. Stale blocks are blocks that are created but did not get successfully added to the main chain. As the main chain grows, these are left out and effectively bypassed, ie orphaned. The same effect can occur with soft forks, where one fork grows and eventually becomes the main chain.¹⁸ Hard forks are a little different, as these are deliberate decisions taken by participants to essentially split the blockchain. The risk in all of these is not so much the alteration of records that exist in the blockchain, but the loss of information as a result in the orphaned blocks or forked chains.¹⁹ Parenthetically, there is some debate whether the orphaning of blocks do actually result in loss of records. One view is that records that do not make it to the main chain will just be re-scheduled to form another block. The fact that there is concern about a 51% attach gives weight to the possibility that soft forks (and presumably orphaned blocks) are excluded from the chain. There can be rules to deal with these effects, eg the Bitcoin protocol orphans stale blocks while the Ethereum protocol attempts to reward inclusion of stale blocks back into the chain.²⁰ See “Mining Rewards” ethereum wiki <https://github.com/ethereum/wiki/wiki/Mining#mining-rewards>. The same effect can take place in respect to the blocks in an orphaned chain as a result of a soft fork. There is the therefore the practice that a block is not treated as confirmed until it is at least six blocks deep (for Bitcoin) or 15 blocks deep (for Ethereum), when the risk of it becoming orphaned is reduced.²¹ See “How are orphaned blocks dealt with on the blockchain?” Quora <https://www.quora.com/How-are-orphaned-blocks-dealt-with-on-the-blockchain>; see “Confirmation” Bitcoin Wiki <https://en.bitcoin.it/wiki/Confirmation> for a discussion why 6 blocks was chosen.

The implications of this is that the community practice becomes relevant. Older records that are deeper in the chain can probably rely on the plain reading of Explanation 3 to Section 64. For more recent records, the community rules or practices become relevant. If there is a practice that a block has to be at least 6 (or 15) blocks deep before it is confirmed and can be acted upon, then this becomes relevant to show when the community has “manifestly or consistently acted on, relied upon or used the information” recorded on the blockchain in order that it can stand as primary evidence. Thus, the effect of Illustration (a) to Explanation 3 is that the practice of parties relying on the blockchain can also be adduced to meet the evidential burden of proving that it is accurate and therefore primary evidence. Consequently, the net effect of the foregoing discussion is that there is some doubt created over the reliability of new blocks that have not been confirmed. However, this merely means that one may not rely on the evidential presumptions but have to adduce positive proof that the disputed transaction took place, either through expert technical evidence or other evidence extraneous to the blockchain (eg communications or conduct of parties).

Additionally, one may also rely on Explanation 2 as well: viz where multiple documents are made by a uniform process, each is primary evidence of the content of the rest. The distributed nature of blockchains means that once a block has passed the proof of works, it will be replicated to all nodes of the blockchain network. It can therefore be argued that every copy of the same record that is stored in the blockchain of every node in the network is primary evidence by reason that they were all “made by one uniform process”. However, if one were to be particularly pedantic, one could point out that there must have been a scintilla of a moment when the first block was committed to the first node, before this was replicated across the rest of the nodes in the blockchain network. Additionally, not all mining nodes are online all the time. This will therefore mean that that as offline mining nodes come online and they catch up with the blocks that they had missed, there can be successive waves of replication across the network. Viewed from this perspective, as successive mining nodes are updated, they are “all copies of a common original [and therefore] they are not primary evidence of the contents of the original.” The analysis will be different if the information originated outside the blockchain: in this case, each copy on the chain is primary evidence of every other by reason of the uniform process, but secondary evidence of the original.

Proving Accuracy and Authenticity of Blockchain Records

Whilst the preceding discussion focused on how blockchain records can be adduced as primary evidence, this section focuses on the integrity and authenticity issues of electronic records. The Electronic Transactions Act provides a horizontal legal substratum that supports digitisation of documents, electronic commerce, and the digitalisation of public services. It enables the use of electronic documents — referred to as “electronic records” in the ETA — in lieu of documents in printed form; and recognises electronic signatures by treating them as analogous to handwritten signatures.

The application of cryptography to electronic records and electronic signatures can provide a level of technological assurance that their pen-and-paper analogue does not. Indeed, many of the applications of blockchain technology in cryptocurrencies and crypto-tokens today ride on its technical immutability which effectively prevents double-spending. This overcomes the age-old plague of forgery of printed currency notes, negotiable and bearer instruments. Hence, the ETA provides that certain presumptions relating to integrity — viz that there has been no alteration of the content of the document²² Section 19(1) ETA: “the electronic record has not been altered since the specific point in time to which the secure status relates.” — and to authenticity — viz that is was signed by the person that the signature represents and that he had intentionally signed or approved it.²³ Section 19(2) ETA: “the secure electronic signature is the signature of the person to whom it relates; and … was affixed by that person with the intention of signing or approving the electronic record.” The new UNCITRAL Model Law on Electronic Transferable Records (ETR) will introduce new concepts around singularity and exclusive control of an ETR, whereby exclusive control of an ETR can be transferred and the transferee or holder of the ETR will be entitled to claim performance of obligations indicated thereupon, or to make further onward transfers.²⁴ Articles 10 & 11 of the UNCITRAL Model Law on Electronic Transferable Records <http://www.uncitral.org/pdf/english/texts/electcom/MLETR_ebook.pdf> (last accessed 9 August 2018): re: the concepts of singularity and exclusive control, see paras 83 – 85; Whether in a public or private chain, blockchain records that are electronically signed in a secure manner will (depending on implementation) qualify as a secure electronic record under the ETA. As discussed earlier, the technical risk for blockchain records is not so much of alteration but the loss of information through deliberate hard forking or orphaning of stale blocks or chains.

Presumption of Authenticity and Integrity under the Electronic Transactions Act

Records that are stored in a blockchain can be digitally signed using Public Key Infrastructure (PKI). Under Section 18 of the ETA, a secure electronic signature is one that is signed by applying either a specified security procedure or by a commercially reasonable one. Using PKI signatures enables blockchain records to benefit from the presumptions of secure electronic signatures because PKI signatures are “digital signatures” and PKI is a specified security procedure under the ETA.²⁵ See definition of “specified security procedure” in section 2 and read with the 2^nd and 3^rd Schedules of the ETA. Thus, an electronic record that is signed with a digital signature is treated as a secure electronic signature.²⁶ Section 3 of the 3^rd Schedule to the ETA. To fully qualify as a digital signature, the PKI digital certificate has to be issued by a certification authority accredited under the Electronic Transactions (Certification Authority) Regulations, or (presumably) by a CA that an accredited CA has arrangements for cross-recognition of its root certificate. The latter is of especial relevance for blockchain implementations since the nodes in the blockchain network are, more often than not and even for private chains, going to be sited in different jurisdictions.

If the consortium of a private blockchain chooses not to use a public CA, but adopts the same PKI technology in a closed system, then the secure electronic signatures can still benefit from the presumptions in Section 18 of the ETA. In this instance, the PKI infrastructure is a closed one but nonetheless utilises the same underlying technology. This will be a commercially reasonable security procedure and electronic signatures generated from this process can still qualify as secure electronic signatures. Commercial reasonableness of a security procedure is marked against Section 17(2) of the ETA, but this is a discussion that need not delay us since the technological solution is still one that is an implementation of PKI, with a private CA. The only additional hurdle is that parties’ agreement to adopt this must be secured. This can be done through the club rules or bye-laws of the consortium or as part of the participation agreement to join the consortium.²⁷ Hypothetically, it may be possible for a private blockchain to use some other system of cryptography that is not based on PKI. For the electronic signatures that are generated to qualify as secure electronic signatures, (a) the commercial reasonableness of the security procedure will have to meet the criteria under section 17(2), (b) the participants in the blockchain network will have to agree to use this cryptography system and (c) the electronic signature will have to be verified against the standards spelt out in section 18(1).

Additionally, the information that is stored in the block can be encrypted. The analysis whether the record a secure electronic record follows the same logic as for secure electronic signature. In brief, where the cryptography utilises PKI digital certificates that are issued by an accredited CA, then the security procedure will be a specified security procedure; thus by definition, the records that are encrypted through this procedure will be a secure electronic record. If the same cryptography solution is used but the CA is a private one, then the parties will have to agree (eg through the consortium club rules or bye-laws, or through the participation agreements) to adopt this private PKI implementation as a commercially reasonable security procedure.²⁸Ibid, the same hypothetical possibility also exists for the use of some other system of cryptography to encrypt records.

Presumptions of Accuracy and Authenticity under the Evidence Act

One cannot omit a consideration of the presumptions in section 116A in a discussion of the reliability of electronic records under the Evidence Act. The set of presumptions were introduced to create a presumption in favour of admission of electronic records.²⁹ See Telemedia Pacific Group Ltd v Credit Agricole (Suisse) SA (Yeh Mao-Yuan, third party) [2015] 1 SLR 338; [2014] SGHC 235, at [250]. It has been said that “the wording of section 116A is admittedly rather clumsy.”³⁰Ibid, at [248]. A handy way to remember the trio of presumptions under this section is:

• The electronic output of a device or process is presumed to be accurate if it had been properly used;
• An electronic record that originated from a neutral source (ie not a party to the proceedings) who produced it in its ordinary course of business is presumed to be authentic; and
• An electronic record that originated from an adverse party is presumed to be authentic.

A number of observations may be made concerning the practical application of section 116A. First, as has been held in Mitfam International v Motley Resources Pte Ltd,³¹ [2014] 1 SLR 1253; [2013] SGHC 270. the party relying on the presumption is still required to produce some evidence to prove the primary facts before the presumption can be engaged.

This segues to the second observation: where blockchain technology is relied upon as one of the components of an application system, it need not be necessary in every case to produce reams of expert evidence concerning how blockchain technology works and how it had been implemented. This would be an overly technical approach. Very much depends on the issues that are raised in the case. Sometimes, parties agree to authenticity;³² See The “Dream Star” [2017] SGHC 220. at other times, the dispute may pertain to the business processes around data entry.³³ See Mitfam International Ltd v Motley Resources Pte Ltd, supra, n 12. It is when there is a dispute that touches on how blockchain is implemented and the reliability of blockchain records that technical experts have to be called.

This leads to the final observation that these presumptions operate on the entire device or application system, or business process. It will be unnecessarily pedantic – and probably wrong at law – to tease out specific components and to attempt applying the presumptions at the modular level. One would not take this treatment when the application system implements a relational database, thus neither should this treatment be resorted to when it happens to be a distributed ledger. It is only when the issues raised specifically touch on these modules that technical expert evidence need be called upon.

Blockchain records containing personal data

A discussion of the record keeping or logging function of blockchain cannot be complete without also considering the management of such records throughout its life cycle. This section is not intended to be a discussion of full compliance with data protection and privacy laws, but is intended to focus on the record-keeping aspects of the life cycle of personal data that is stored on or linked from blockchain networks.

The former occurs when, for example, the blockchain is used as a decentralised ledger to share specific pieces of information for KYC purposes. As for the latter, data protection laws are engaged whenever personal data is stored on or linked from the blockchain (the latter probably more common than the former) because of two reasons. First, it is the application system as a whole that will be considered when determining whether it processes personal data. Second, the definition of personal data is broad, looking at not only the dataset under consideration but also “other information to which the organisation has or is likely to have access.”³⁴ Section 2 of the Personal Data Protection Act.

It is also useful at this juncture to remind the reader that the following discussion will also be relevant to information stored in the more traditional relational database sub-system of the application system that happened to also contain a sub-system that utilises blockchain. The discussion will focus on the maintenance and purging stages of the information life cycle.³⁵ See, for example, “7 phases of a data life cycle” (14 July 2015) <https://www.bloomberg.com/professional/blog/7-phases-of-a-data-life-cycle/> (last accessed 28 July 2018).

Maintaining and protecting personal data

During the maintenance stage in the information life cycle, the data controller has obligations to ensure accuracy and protection of the personal data. Ensuring the accuracy of information is an area which, if taken seriously, will involved significant investment of resources but can yield exponential benefits in terms of the insights that the organisation can derive and potentially the improvements to products and services that such insights may lead to for a business.

Information can be curated from multiple input channels, eg updates from subsequent interactions with a customer, data cleansing as part of the organisation’s data management programme, or upon request by the data subject to access and correct the personal data that the data controller holds. Under section 22 of the Personal Data Protection Act, it is not the case that every request by a data subject for correction must be automatously carried out. If “the organisation is satisfied on reasonable grounds that a correction should not be made”,³⁶ Section 22(2) PDPA. it need not do so but “shall annotate the personal data … with the correction that was requested but no made.”³⁷ Section 22(4) PDPA. Additionally, there are exceptions to the data subject’s right to request for correction of his personal data: eg opinions,³⁸ Section 22(6) PDPA and section 1(a) of the 6^th Schedule. examination scripts and results, etc.³⁹ See 6^th Schedule to the PDPA.

Depending on the specific implementation and how it makes use of either a public or private chain, the information may be stored either in the block or the block may contain a pointer that references another location where the information is stored (and probably in a relational database). The correction of records could present some challenges that would require careful design and collaboration between computing engineer and legal advisors to address.

The blockchain record could itself be encrypted and signed, and its entire contents further hashed and inserted into the next block. The technical details of this chain effect and technical immutability has been discussed earlier. This makes changing information stored in a block, especially a confirmed block, computationally infeasible. One possible solution to giving effect to valid correction requests of personal data stored on the blockchain is to make use of annotations. This requires a bit of foresight during the design stage by incorporating data protection compliance considerations (ie data protection by design): the application system can be designed to cater for a flag or other more detailed version marker that can be placed against a blockchain record that can be used to determine (probably in conjunction with a separate version history table) whether that specific record is the accurate one from which personal data can be retrieved. Compliance with the correction obligation need not be a deletion of an older and inaccurate record, but it can be effected through treating such older and inaccurate records as obsolete while creating a new record that contains updated information.

The same solution may still be necessary even if the record is stored off-chain. The pointer to an off-chain relational database may contain a hash of that database record to ensure that changes to that record can also be detected. To preserve the integrity of the system, the same approach can also be taken when personal data stored in the relational database has to be corrected: viz annotate that it is obsolete and point to a new record that is inserted into the database which contains the updated information. Thus, for this type of implementation, each correction will result in corresponding new blocks in the chain and a new record in the database.

The other important aspect during the maintenance stage is protection of personal data stored on the chain. This topic can be addressed briefly. If personal data is stored in the blockchain, the encryption of the block using PKI will probably qualify as “reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar tasks.”⁴⁰ Section 24 PDPA.

However, it must be highlighted that the application programming logic plays an important role. It is through programming logic that the organisation controls whether these functions are limited to users who are authorised (or empowered to perform these functions) and the user access control or identity infrastructure performs the role of identifying and authenticating the user attempting to invoke these functions. The same observations are true where the blockchain contains a pointer that references an off-chain relational database in which the personal data is stored. Thus, whilst one can have faith in the security and identity management capabilities of blockchain, one cannot be blind to the fact that blockchain is only one sub-system and that appropriate design considerations have to be taken holistically to ensure that the entire application system is reasonably secure.

Purging personal data from blockchain records

During the purging stage in the information life cycle, the data controller has to ensure proper disposal of the personal data. The purging could be a result of, for example, data subject’s withdrawal of consent and the personal data is expunged because there is no longer any purpose served in its retention; or it could be that the data has reached the end of its life cycle and the personal data is due for destruction in accordance with the organisation’s destruction policy. Disposal of personal data can happen in a couple of ways: first, the anonymisation of the data such it is no longer possible to identify particular individuals while retaining sufficient granularity in individual records for future use; or second, through the deletion of the record. The challenge posed by blockchain records can be traced to the technical immutability: confirmed records are almost impossible to alter, much more delete. Even if the decision is to anonymise the records, this merely creates a new dataset without individually identifying information. The primary records are still in the chain. Thus, a solution is still required for deletion of the primary record.

One possible solution lies in the removal of “the means by which the personal data can be associated with particular individuals.”⁴¹ Section 25 PDPA. In other contexts, this would include anonymisation techniques. In the context of blockchain records, this could involve the disposal of the encryption keys such that it is now impossible to decrypt the information. This presupposes that the cryptography solution employs sufficiently strong encryption that brute force attempts to decrypt the cyphertext is computationally infeasible. This calls for a data protection by design approach at an early stage in selecting the right length of encryption key and encrypting all data elements that may potentially be personal data. Couple this with a well-documented process for destruction of the encryption key that can stand up to scrutiny, and we may have the reasonable means of appropriately removing the association of each blockchain record to particular individuals.⁴² See s 11(1) PDPA, which establishes the standard of reasonableness for compliance.

However, the effectiveness of this approach has to be assessed periodically since it is vulnerable to brute force decryption attempts. What is assessed to be computationally unfeasible today may no longer be the case when computation power benefit from quantum improvements, eg when quantum computing becomes commercially accessible. That day is still some ways off in the future and perhaps, when that day arrives, there could be more durable solutions to this conundrum.⁴³ For example, Accenture has proposed the use of chameleon hashes as way to allow future redaction of blockchain: “Why Accenture’s Plan to ‘Edit’ the Blockchain is a Big Deal” Fortune (20 September 2016) <http://fortune.com/2016/09/20/accenture-blockchain/> (last accessed 28 July 2018).

Distributed nature of blockchain networks and transfer limitation

To round out the PDPA discussion, blockchain networks are also likely to face the same set of compliance issues as cloud services in relation to the limitation of transfers of personal data outside Singapore to countries that provide a comparable standard of protection. Blockchain networks, especially public ones, will have a multi-jurisdictional footprint.

The analysis of the issues must begin with the question of the role that the blockchain plays in the application system and what data is actually stored on the chain. The obligation to limit cross-border transfers to jurisdictions with comparable protection standards arises only if personal data is store on the chain. If the data is stored in the relational database that is the main data sub-system, then this issue may not arise particularly when the database resides within jurisdiction. Should there be a need to transfer personal data, then the current set of solutions that deal with the use of cloud technologies can be applied with equal effect, eg by contract, binding corporate rules or consent.⁴⁴ See regulations 9 & 10 of the Personal Data Protection Regulations 2014.

It is not intended that we detour into a detailed discussion of how these mechanisms for ensuring comparable protection in the destination jurisdiction operate. The function that the blockchain ledger is intended to perform will inform which of these mechanisms will be appropriate. For example, if the blockchain ledger is intended to track the transmission of purchase, delivery and shipping information of goods ordered through an e-commerce site, then the deemed consent may be sufficient as between seller and customer, while binding corporate rules are relied on for intra-group transfers and contractual clauses are relied upon for third party logistics sub-contractors.

Conclusion

If there is one thing that the reader of this essay should depart with, it is the realisation that blockchain is but one of the building blocks of any application system or platform that makes use of distributed ledger technology. There does not appear that there are horizontal legal issues that cannot be solved by carefully planning for and incorporating data protection by design considerations early in the system architecture and design stage. Lawyers should also be aware that blockchain records are not the be all and end all of data storage sub-systems within an application system. Understanding its role and the data that is intended to be stored – and equally important, how and in what form will the data be stored – will permit a more precise articulation of the issues and thence a set of bespoke contractual or other legal solutions to address them, within the context of the supporting legislative infrastructure that is currently available in Singapore. Thus, if there is one decision that the reader can make without remorse, it will be to decide to anchor the blockchain implementation in Singapore law.