Blockchain: To Implement, or Not to Implement?

Creative blockchain solutions are available to almost every business, and have the potential to enhance almost every business model in some way. But the value of a particular blockchain technology and whether it would be appropriate to implement exists, as many things do, on a spectrum. Blockchain technology is one of the tools by which discussion could move significantly on from more generalized questions like “how do we make our company’s data private and secure” to more specific questions like “what are the best ways to protect our data’s privacy and security,” “in which ways are our data private or secure,” or “what is the value of protecting the privacy and ensuring the security of our company’s data in a particular arena,” but a working knowledge of what blockchain technology is and is not good for is required to make the move. A short discussion of precisely this follows. This article is not meant to be exhaustive; it is for use as thought-provoking material as well as a source of very general guidelines regarding the implementation of blockchain solutions in an actual business.

PART I: WHEN TO IMPLEMENT

A. If the business intends on putting sensitive, security-intensive, or otherwise valuable information on the blockchain.

First, blockchain isn’t completely invulnerable. It’s vulnerable to a number of attacks, actually, although attacks on blockchains are typically by far not as easy to pull off as attacks on a number of (poorly-maintained, as is commonly the case) traditional databases. Things like 51% attacks or flood attacks prey on the structural weaknesses of blockchains that, respectively, don’t have a leader node to approve forks, or don’t have enough computing power to approve transactions as fast as a hacker can create them.[1] Even if a business does protect its blockchain against massive attacks like those, some blockchain professionals still maintain that ultimately, every blockchain is not completely private or secure. Although they may be considered statistically so for now, they are still fallible, if not merely because blockchain systems are still vulnerable to theft and hacks in the usual way — aka, by virtue of human error or gullibility.[2]

All this is to say that, at least in this stage of the technology’s development, valuable information, including personally-identifiable information (or “PII”), and even hashed PII (hashing mechanisms are the base cryptography by which new blocks are added to the blockchain), should not be stored on a blockchain. While valuable information like PII or hashed PII would be best stored on a private blockchain, comprised of only trustworthy nodes, the blockchain will still remain vulnerable in ways that are, as mentioned above, difficult to minimize and possibly impossible to gain full control over.[3]

B. If the business desires to make the information transparent and more immutable.

On the other hand, it may not be necessary to protect all blockchains this way. In fact, some blockchains — such as those required for transparent, efficient, and immutable records — could derive greater strength, here meaning resistance to surreptitious meddling, by having a lot of bare data on a public blockchain. If it doesn’t matter much whether the data is seen, but it matters a great deal whether the data is changed, a company might consider implementing one in its business. The trade-off here is that it would be easy for an attacker to gain access to the blockchain in order to possibly force a fork, but that the existence of a lot of nodes in the blockchain network would make it harder for an attacker to gain the necessary control; further, a non-approved fork could be dishonored for at least the base reason that more nodes have already agreed on and distributed copies of a previous version of the correct ledger.

PART II: WHEN NOT TO IMPLEMENT

A. If the business could be tripped up by changing regulations or rapid expansion.

i) Storing any “personal data” or “probabalistic identifiers” in the EU or a U.S. state that recognizes a “right of deletion” or a “right to be forgotten.”

Again, blockchains are supposed to be immutable — once a record gets added to the chain, it’s not supposed to be able to be changed by anyone. This is at odds with some conceptions of privacy ideology. For example, the General Data Protection Regulation (or “GDPR”), effective in the EU, mandates that a data processor must change or remove the personal data of a data subject if the data subject so requests. California as well adopts this in part, and provides in the California Consumer Protection Act (CCPA) that consumers have the right to have their personal information deleted pursuant to Cal. Civil Code §1798.105.[4]

ii) If the business would rely too heavily on smart contracts.

This guideline is, admittedly, somewhat counter-intuitive. Smart contracts, or the if-then lines of automatically-executing code that can be applied to the blockchain and run only once certain conditions are met, have the potential to revolutionize business agreements. While they are generally regraded as transparent, automatically-executing (no wiggle room), and secure, there has been significant debate over whether they are legally enforceable, or, if they’re enforceable generally, what sorts of things might render them unenforceable. Several states including Arizona, Tennessee and Vermont have enacted statutes that explicitly state what kinds of smart contracts are enforceable within their states, but until the issue is further explored, there could be some that are found to be unenforceable or void.[5] The best advice until more states catch up with legislation like this is to keep smart contracts exceedingly simple and in use just enough to optimize some business processes, while leaving the large, expensive, ambiguous, or complex promises that a human-executable contract would more likely embody to your lawyer.

[1] James Risberg, Yes, the Blockchain Can Be Hacked, Coin Central (May 7, 2018), https://coincentral.com/blockchain-hacks/.

[2] Kaliya Young, Is Putting Hashed PII on Any Immutable Leger (Blockchain) is a Bad Idea, Identity Woman (Feb. 3, 2018), https://identitywoman.net/putting-hashed-pii-immutable-ledgerblockchain-bad-idea/.

[3] Joe Coburn, Public vs. Private Blockchains: Understanding the Differences, Blocks Decoded (Sep. 17, 2018), https://blocksdecoded.com/public-private-blockchains/.

[4] Tom Kulik, Why Blockchain and the GDPR Collide Over Your Personal Data, Above the Law (Oct. 8, 2018) https://abovethelaw.com/2018/10/why-blockchain-and-the-gdpr-collide-over-your-personal-data/?rf=1.

[5]Aaron Stanley, Can Code Really Be Law? New Report Clarifies Smart Contract Misconceptions, Forbes (Sep. 27, 2018), https://www.forbes.com/sites/astanley/2018/09/27/can-code-really-be-law-new-report-clarifies-smart-contract-misconceptions/#3f1b53c034e2.