Blockchain networks (sometimes referred to as Distributed Ledgers) significantly improve certain aspects of data security over traditional centralized databases. Several characteristics core to a blockchain contribute to its security, including, decentralized coordination of independent hardware, append only functions, and built in permissioning. Critics of blockchain technology often claim that many of the use cases could more simply and easily be accomplished by using the existing server client model combined with modern databases. While this may be true, it overlooks many of the advantages that come baked-in to a blockchain. We should also recognize that blockchain databases are still maturing as a technology and will grow to incorporate the best characteristics of traditional databases. My friend Shahan Khatchadourian wrote an inspiring blog post earlier this year expressing his thoughts on how the lines between traditional databases and blockchains will begin to blur. https://media.consensys.net/blockchains-and-databases-arent-the-same-thing-yet-5d5eb7df099e
This figure from Shahan’s post highlights how database technology is more of a continuum where the respective spheres of traditional and blockchain based databases will grow to merge the two completely.
Decentralization
Just about every conversation about blockchain technology begins with an explanation of why decentralization is superior to centralization. But we should recognize that this is not an axiom for all circumstances. As with all things, there are trade offs depending on the desired outcome. Here we argue that decentralization provides specific advantages with regard to building a data commons such as a global genealogical database.
Probably the most significant advantage that comes from a decentralized blockchain is the redundant way that the data is stored. How many times have we been told to back up our data. Yet, it is not as easy as it sounds. Each back up requires independent hardware, and if the hardware is geographically distributed it can become difficult to keep all the back ups in sync and reconciled to the most up to date state of the database. The blockchain solves this problem. Every full node on the network holds the entire state of the database and is continually updated by the latest block. Public blockchains are secured by tens of thousands of nodes which all verify the authenticity of the data.
Just imagine if you were super paranoid about losing an extremely valuable dataset. So much so that you were willing to invest heavily in creating the world’s most secure bunker to house your data center. Would you trust that a single bunker could protect the data against all threats? The alternative would be, what if you could inject this data into the DNA of every person on earth and have it forever be passed down through the generations of humankind. Which option would you choose? Decentralization wins.
The Castle vs The Swarm
When describing blockchain security I often draw the analogy that traditional databases are like castles and blockchains are like swarms. In today’s world, control over data is extremely valuable, in fact, you can think of it as protecting a treasury of digital gold. And we have constructed castles in the digital space to hold and protect that gold. Big thick fire walls, turrets with automated bot soldiers at the ready holding their bows, large pots of boiling oil ready to be poured down on viruses, all these defenses confront the would be attackers coming to sack the castle and steal the gold buried deep inside. And yet time after time we hear of ingenious hackers who slip into these castles undetected through sewer vents or the moat and escape with control over some or all the gold without a scratch. To make matters worse, the castles encourage this concentrated effort from hackers because they continue to stockpile more and more gold into a single location, making it a juicy target.
Now compare this to a Swarm. What if little flecks of gold were carried on the back of innumerable birds whose flock was coordinated into a swarm. If the swarm was large enough, the quantity of gold would rival even that which was stored in the castle. However, to the hacker, the swarm presents an unattractive target. Because even after the hacker has compromised the security of one of the birds, the prize is miniscule. The agents of the swarm work together according to a simple ruleset, but each individual acts independently of the others and therefore is not vulnerable to the same attack. As long as the ruleset is not compromised, the swarm will continue undaunted by the loss of an individual or small group of members. In this way, blockchains are much less vulnerable than centralized databases to hackers. But this begs the question…who sets the rules?
Everyone Agrees to the Rules
In today’s world of tech giants which rule the internet cloud and Web2.0, if you want to participate you must play by their rules. You accept these rules in the beginning but have no influence as to the initial parameters nor any future alterations implemented in the future. Blockchain technology changes this paradigm. The initial participants in the blockchain establish the ruleset and transparently follow it. Down the line, if/when the protocol is changed, all participants choose to accept these changes. If a group of participants opt out of the changes, they can continue running the old protocol and disregard events made by new ruleset. In this way, they are protected from being bullied onto a platform that no longer serves their interests. The old protocol will continue to function with all the previous data and capabilities as before. There can be some security tradeoffs in this scenario, but the important point is that each participant makes their own choice and can exert influence on other participants about what upgrades to the network best serve the community.
Save vs Save As
Another beneficial aspect of blockchain database construction is that it is designed using an append only structure. This means that data can only be added on, not erased. The name “block-chain” actually describes the way state changes to the database are processed. All new transactions (state changes) are bundled together and processed in batches, aka blocks. These blocks are cryptographically linked in a way to alert all participants should someone try to falsify data that has previously been recorded in a block.
This greatly simplifies a problem we have all experienced, which I like to call the “Save vs Save As” problem. How many times have you opened a document in Microsoft Office that needed to be preserved as a master copy, and after making some changes you inadvertently clicked the “Disk Save Icon”? That master copy is now forever changed and can no longer be reverted once you close the program. What you wanted to do is a “Save As” and change the file name so that it created a separate file and thus preserved the original.
The problem is rooted in the four data functions of a traditional database: Create, Read, Update, and Delete (collectively known as the CRUD commands). This gives all permissioned clients the ability to forever alter the data. Contrast this with a blockchain where there are only two sets of operations: Read (these query and retrieve data from the blockchain), and Write (these add more data onto the blockchain, but cannot overwrite any prior data). Basically, it’s as if the blockchain defaults to Save As for all updates and saves all previous versions of the data to make sure that everyone is being honest.
Permissions Baked In
Part of what makes blockchain platforms so special is that they were originally designed to satisfy all requirements needed to support a new type of internet money. As you can imagine, money requires the utmost in security. Nobody wants to have their money messed with and accidentally taken away from them. So blockchains have account permissions already built in as part of the base layer. This means that from the start all users have cryptographic identities (keys) which have set permissions associated with them.
This is important because it can guarantee data custodians certain rights to the data and prevent other users from tampering with their records. This is a significant concern within the traditional client-server database model and causes all companies to require their own unique record which must be correlated and reconciled with everyone else. Needless to say, this results in the duplication of effort and a tremendous amount of friction. For this reason alone the idea of a “data commons” has been all but impossible (with few exceptions) until now.
Conclusion
As we build the Prosapia genealogy data commons, it is clear to us that the blockchain offers significant benefits over traditional databases in regards to data security. We believe that having the database duplicated all over the earth as a distributed database is far superior to trying to build an impenetrable fortress of a data center. The decentralized structure of the network provides a natural immunity to some of the dangers presented by hackers, attacks and accidents. And the core level permissioning provided by blockchains gives strong guarantees to the participating organizations that their data will be guarded against any unwanted alterations. We feel confident that this new model will be of great benefit to the world and allow organizations which have never been able to successfully work together to now find common ground on which to build.