Avoiding the pointless blockchain project, MultiChain

Avoiding the pointless blockchain project

How to determine if you’ve found a real blockchain use case

Blockchains are overhyped. There, I said it. From Sibos to Money20/20 to cover stories of The Economist and Euromoney, everyone seems to be climbing aboard the blockchain wagon. And no doubt like others in the space, we’re watching a rapidly enlargening number of companies building proofs of concept on our platform and/or asking for our help.

As a youthfull startup, you’d think we’d be over the moon. Surely now is the time to raise a ton of money and build that high spectacle next generation blockchain platform we’ve already designed. What on earth are we waiting for?

I’ll tell you what. We’re waiting to build up a clearer understanding of where blockchains genuinely add value in enterprise IT. You see, a large proportion of these incoming projects have nothing to do with blockchains at all. Here’s how it plays out. Big company hears that blockchains are the next big thing. Big company finds some people internally who are interested in the subject. Big company gives them a budget and tells them to go do something blockchainy. Soon enough they come knocking on our door, flapping dollar bills, asking us to help them think up a use case. Say what now?

As for those who do have a project in mind, what’s the problem? In many cases, the project can be implemented ideally well using a regular relational database. You know, big metal behemoths like Oracle and SQL Server, or for the more open-minded, MySQL and Postgres. So let me begin by setting things straight:

If your requirements are fulfilled by today’s relational databases, you’d be insane to use a blockchain.

Why? Because products like Oracle and MySQL have decades of development behind them. They’ve been deployed on millions of servers running trillions of queries. They contain some of the most accurately tested, debugged and optimized code on the planet, processing thousands of transactions per 2nd without cracking a sweat.

And what about blockchains? Well, our product was one of the very first to market, and has been available for exactly five months, with a few thousand downloads. Actually it’s utterly stable, because we built it off Bitcoin Core, the software which powers bitcoin. But even so, this entire product category is still in its diapers.

So am I telling that blockchains are futile? Absolutely not. But before you embark on that shiny blockchain project, you need to have a very clear idea of why you are using a blockchain. There are a bunch of conditions that need to be fulfilled. And if they’re not, you should go back to the drawing board. Maybe you can define the project better. Or maybe you can save everyone a blast of time and money, because you don’t need a blockchain at all.

1. The database

Here’s the very first rule. Blockchains are a technology for collective databases. So you need to begin by knowing why you are using a database, by which I mean a structured repository of information. This can be a traditional relational database, which contains one or more spreadsheet-like tables. Or it can be the trendier NoSQL diversity, which works more like a file system or dictionary. (On a theoretical level, NoSQL databases are just a subset of relational databases anyway.)

A ledger for financial assets can be naturally voiced as a database table in which each row represents one asset type possessed by one particular entity. Each row has three columns containing: (a) the proprietor’s identifier such as an account number, (b) an identifier for the asset type such as “USD” or “AAPL”, and (c) the quantity of that asset held by that possessor.

Databases are modified via “transactions” which represent a set of switches to the database which must be accepted or rejected as a entire. For example, in the case of an asset ledger, a payment from one user to another is represented by a transaction that deducts the suitable quantity from one row, and adds it to another.

Two. Numerous writers

This one’s effortless. Blockchains are a technology for databases with numerous writers. In other words, there needs to be more than one entity which is generating the transactions that modify the database. Do you know who these writers are?

In most cases the writers will also run “knots” which hold a copy of the database and relay transactions to other knots in a peer-to-peer style. However transactions might also be created by users who are not running a knot themselves. Consider for example a payments system which is collectively maintained by a puny group of banks but has millions of end users on mobile devices, communicating only with their own bank’s systems.

Three. Absence of trust

And now for the third rule. If numerous entities are writing to the database, there also needs to be some degree of mistrust inbetween those entities. In other words, blockchains are a technology for databases with numerous non-trusting writers.

You might think that mistrust only arises inbetween separate organizations, such as the banks trading in a marketplace or the companies involved in a supply chain. But it can also exist within a single large organization, for example inbetween departments or the operations in different countries.

What do I specifically mean by mistrust? I mean that one user is not willing to let another modify database entries which it “wields”. Similarly, when it comes to reading the database’s contents, one user will not accept as gospel the “truth” as reported by another user, because each has different economic or political incentives.

Four. Disintermediation

So the problem, as defined so far, is enabling a database with numerous non-trusting writers. And there’s already a well-known solution to this problem: the trusted intermediary. That is, someone who all the writers trust, even if they don’t fully trust each other. Indeed, the world is packed with databases of this nature, such as the ledger of accounts in a bank. Your bank controls the database and ensures that every transaction is valid and authorized by the customer whose funds it moves. No matter how politely you ask, your bank will never let you modify their database directly.

Blockchains eliminate the need for trusted intermediaries by enabling databases with numerous non-trusting writers to be modified directly. No central gatekeeper is required to verify transactions and authenticate their source. Instead, the definition of a transaction is extended to include a proof of authorization and a proof of validity. Transactions can therefore be independently verified and processed by every knot which maintains a copy of the database.

But the question you need to ask is: Do you want or need this disintermediation? Given your use case, is there anything wrong with having a central party who maintains an authoritative database and acts as the transaction gatekeeper? Good reasons to choose a blockchain-based database over a trusted intermediary might include lower costs, quicker transactions, automatic reconciliation, fresh regulation or a elementary inability to find a suitable intermediary.

Five. Transaction interaction

So blockchains make sense for databases that are collective by numerous writers who don’t entirely trust each other, and who modify that database directly. But that’s still not enough. Blockchains truly shine where there is some interaction inbetween the transactions created by these writers.

What do I mean by interaction? In the fullest sense, this means that transactions created by different writers often depend on one other. For example, let’s say Alice sends some funds to Bob and then Bob sends some on to Charlie. In this case, Bob’s transaction is dependent on Alice’s one, and there’s no way to verify Bob’s transaction without checking Alice’s very first. Because of this dependency, the transactions naturally belong together in a single collective database.

Taking this further, one nice feature of blockchains is that transactions can be created collaboratively by numerous writers, without either party exposing themselves to risk. This is what permits delivery versus payment settlement to be performed securely over a blockchain, without requiring a trusted intermediary.

A good case can also be made for situations where transactions from different writers are cross-correlated with each other, even if they remain independent. One example might be a collective identity database in which numerous entities validate different aspects of consumers’ identities. Albeit each such certification stands alone, the blockchain provides a useful way to bring everything together in a unified way.

6. Set the rules

This isn’t truly a condition, but rather an unpreventable consequence of the previous points. If we have a database modified directly by numerous writers, and those writers don’t fully trust each other, then the database must contain embedded rules restricting the transactions performed.

These rules are fundamentally different from the constraints that emerge in traditional databases, because they relate to the legitimacy of transformations rather than the state of the database at a particular point in time. Every transaction is checked against these rules by every knot in the network, and those that fail are rejected and not relayed on.

Asset ledgers contain a ordinary example of this type of rule, to prevent transactions creating assets out of lean air. The rule states that the total quantity of each asset in the ledger must be the same before and after every transaction.

7. Pick your validators

So far we’ve described a distributed database in which transactions can originate in many places, propagate inbetween knots in a peer-to-peer style, and are verified by every knot independently. So where does a “blockchain” come in? Well, a blockchain’s job is to be the authoritative final transaction log, on whose contents all knots provably agree.

Why do we need this log? Very first, it enables freshly added knots to calculate the database’s contents from scrape, without needing to trust another knot. 2nd, it addresses the possibility that some knots might miss some transactions, due to system downtime or a communications glitch. Without a transaction log, this would cause one knot’s database to diverge from that of the others, undermining the aim of a collective database.

Third, it’s possible for two transactions to be in conflict, so that only one can be accepted. A classic example is a dual spend in which the same asset is sent to two different recipients. In a peer-to-peer database with no central authority, knots might have different opinions regarding which transaction to accept, because there is no objective right reaction. By requiring transactions to be “confirmed” in a blockchain, we ensure that all knots converge on the same decision.

Ultimately, in Ethereum-style blockchains, the precise ordering of transactions plays a crucial role, because every transaction can affect what happens in every subsequent one. In this case the blockchain acts to define the authoritative chronology, without which transactions cannot be processed at all.

A blockchain is literally a chain of blocks, in which each block contains a set of transactions that are confirmed as a group. But who is responsible for choosing the transactions that go into each block? In the kind of “private blockchain” which is suitable for enterprise applications, the response is a closed group of validators (“miners”) who digitally sign the blocks they create. This whitelisting is combined with some form of distributed consensus scheme to prevent a minority of validators from seizing control of the chain. For example, MultiChain uses a scheme called mining diversity, in which the permitted miners work in a round-robin style, with some degree of leniency to permit for non-functioning knots.

No matter which consensus scheme is used, the validating knots have far less power than the proprietor of a traditional centralized database. Validators cannot fake transactions or modify the database in disturbance of its rules. In an asset ledger, that means they cannot spend other people’s money, nor switch the total quantity of assets represented. Nonetheless there are still two ways in which validators can unduly influence a database’s contents:

  • Transaction censorship. If enough of the validators collude maliciously, they can prevent a particular transaction from being confirmed in the blockchain, leaving it permanently in limbo.
  • Biased conflict resolution. If two transactions conflict, the validator who creates the next block determines which transaction is confirmed on the blockchain, causing the other to be rejected. The fair choice would be the transaction that was seen very first, but validators can choose based on other factors without exposing this.

Because of these problems, when deploying a blockchain-based database, you need to have a clear idea of who your validators are and why you trust them, collectively if not alone. Depending on the use case, the validators might be chosen as: (a) one or more knots managed by a single organization, (b) a core group of organizations that maintain the chain, or (c) every knot on the network.

8. Back your assets

If you’ve got this far, you may have noticed that I tend to refer to blockchains as collective databases, rather than the more common “collective ledgers”. Why? Because as a technology, blockchains can be applied to problems far beyond the tracking of asset ownership. Any database which has numerous non-trusting writers can be implemented over a blockchain, without requiring a central intermediary. Examples include collective calendars, wiki-style collaboration and discussion forums.

Having said that, for now it seems that blockchains are mainly of interest to those who track the movement and exchange of financial assets. I can think of two reasons for this: (a) the finance sector is responding to the (in retrospect, minuscule) threat of cryptocurrencies like bitcoin, and (b) an asset ledger is the most plain and natural example of a collective database with interdependent transactions created by numerous non-trusting entities.

If you do want to use a blockchain as an asset ledger, you need to reaction one extra crucial question: What is the nature of the assets being moved around? By this I don’t just mean cash or bonds or bills of lading, however of course that’s significant as well. The question is rather: Who stands behind the assets represented on the blockchain? If the database says that I own ten units of something, who will permit me to claim those ten units in the real world? Who do I sue if I can’t convert what’s written in the blockchain into traditional physical assets? (See this asset agreement for an example.)

The reaction, of course, will vary by the use case. For monetary assets, one can imagine custodial banks accepting cash in traditional form, and then crediting the accounts of depositors in a blockchain-powered distributed ledger. In trade finance, letters of credit and bills of lading would be backed by the importer’s bank and the shipping company respectively. And further in the future, we can imagine a time when the primary issuance of corporate bonds takes place directly on a blockchain by the company seeking to raise funds.

Conclusion

As I mentioned in the introduction, if your project does not fulfill every single one of these conditions, you should not be using a blockchain. In the absence of any of the very first five, you should consider one of: (a) regular file storage, (b) a centralized database, (c) master–slave database replication, or (d) numerous databases to which users can subscribe.

And if you do fulfill the very first five, there’s still work to do. You need to be able to express the rules of your application in terms of the transactions which a database permits. You need to be certain about who you can trust as validators and how you’ll define distributed consensus. And ultimately, if you’re looking at creating a collective ledger, you need to know who will be backing the assets which that ledger represents.

Got all the answers? Congratulations, you have a real blockchain use case. And we’d love to hear from you.

Avoiding the pointless blockchain project, MultiChain

Avoiding the pointless blockchain project

How to determine if you’ve found a real blockchain use case

Blockchains are overhyped. There, I said it. From Sibos to Money20/20 to cover stories of The Economist and Euromoney, everyone seems to be climbing aboard the blockchain wagon. And no doubt like others in the space, we’re watching a rapidly enlargening number of companies building proofs of concept on our platform and/or asking for our help.

As a youthful startup, you’d think we’d be over the moon. Surely now is the time to raise a ton of money and build that high spectacle next generation blockchain platform we’ve already designed. What on earth are we waiting for?

I’ll tell you what. We’re waiting to build up a clearer understanding of where blockchains genuinely add value in enterprise IT. You see, a large proportion of these incoming projects have nothing to do with blockchains at all. Here’s how it plays out. Big company hears that blockchains are the next big thing. Big company finds some people internally who are interested in the subject. Big company gives them a budget and tells them to go do something blockchainy. Soon enough they come knocking on our door, flapping dollar bills, asking us to help them think up a use case. Say what now?

As for those who do have a project in mind, what’s the problem? In many cases, the project can be implemented ideally well using a regular relational database. You know, big metal behemoths like Oracle and SQL Server, or for the more open-minded, MySQL and Postgres. So let me begin by setting things straight:

If your requirements are fulfilled by today’s relational databases, you’d be insane to use a blockchain.

Why? Because products like Oracle and MySQL have decades of development behind them. They’ve been deployed on millions of servers running trillions of queries. They contain some of the most meticulously tested, debugged and optimized code on the planet, processing thousands of transactions per 2nd without violating a sweat.

And what about blockchains? Well, our product was one of the very first to market, and has been available for exactly five months, with a few thousand downloads. Actually it’s enormously stable, because we built it off Bitcoin Core, the software which powers bitcoin. But even so, this entire product category is still in its diapers.

So am I telling that blockchains are futile? Absolutely not. But before you embark on that shiny blockchain project, you need to have a very clear idea of why you are using a blockchain. There are a bunch of conditions that need to be fulfilled. And if they’re not, you should go back to the drawing board. Maybe you can define the project better. Or maybe you can save everyone a explosion of time and money, because you don’t need a blockchain at all.

1. The database

Here’s the very first rule. Blockchains are a technology for collective databases. So you need to embark by knowing why you are using a database, by which I mean a structured repository of information. This can be a traditional relational database, which contains one or more spreadsheet-like tables. Or it can be the trendier NoSQL diversity, which works more like a file system or dictionary. (On a theoretical level, NoSQL databases are just a subset of relational databases anyway.)

A ledger for financial assets can be naturally voiced as a database table in which each row represents one asset type possessed by one particular entity. Each row has three columns containing: (a) the holder’s identifier such as an account number, (b) an identifier for the asset type such as “USD” or “AAPL”, and (c) the quantity of that asset held by that possessor.

Databases are modified via “transactions” which represent a set of switches to the database which must be accepted or rejected as a entire. For example, in the case of an asset ledger, a payment from one user to another is represented by a transaction that deducts the adequate quantity from one row, and adds it to another.

Two. Numerous writers

This one’s effortless. Blockchains are a technology for databases with numerous writers. In other words, there needs to be more than one entity which is generating the transactions that modify the database. Do you know who these writers are?

In most cases the writers will also run “knots” which hold a copy of the database and relay transactions to other knots in a peer-to-peer style. However transactions might also be created by users who are not running a knot themselves. Consider for example a payments system which is collectively maintained by a petite group of banks but has millions of end users on mobile devices, communicating only with their own bank’s systems.

Three. Absence of trust

And now for the third rule. If numerous entities are writing to the database, there also needs to be some degree of mistrust inbetween those entities. In other words, blockchains are a technology for databases with numerous non-trusting writers.

You might think that mistrust only arises inbetween separate organizations, such as the banks trading in a marketplace or the companies involved in a supply chain. But it can also exist within a single large organization, for example inbetween departments or the operations in different countries.

What do I specifically mean by mistrust? I mean that one user is not willing to let another modify database entries which it “possesses”. Similarly, when it comes to reading the database’s contents, one user will not accept as gospel the “truth” as reported by another user, because each has different economic or political incentives.

Four. Disintermediation

So the problem, as defined so far, is enabling a database with numerous non-trusting writers. And there’s already a well-known solution to this problem: the trusted intermediary. That is, someone who all the writers trust, even if they don’t fully trust each other. Indeed, the world is packed with databases of this nature, such as the ledger of accounts in a bank. Your bank controls the database and ensures that every transaction is valid and authorized by the customer whose funds it moves. No matter how politely you ask, your bank will never let you modify their database directly.

Blockchains liquidate the need for trusted intermediaries by enabling databases with numerous non-trusting writers to be modified directly. No central gatekeeper is required to verify transactions and authenticate their source. Instead, the definition of a transaction is extended to include a proof of authorization and a proof of validity. Transactions can therefore be independently verified and processed by every knot which maintains a copy of the database.

But the question you need to ask is: Do you want or need this disintermediation? Given your use case, is there anything wrong with having a central party who maintains an authoritative database and acts as the transaction gatekeeper? Good reasons to choose a blockchain-based database over a trusted intermediary might include lower costs, swifter transactions, automatic reconciliation, fresh regulation or a ordinary inability to find a suitable intermediary.

Five. Transaction interaction

So blockchains make sense for databases that are collective by numerous writers who don’t entirely trust each other, and who modify that database directly. But that’s still not enough. Blockchains truly shine where there is some interaction inbetween the transactions created by these writers.

What do I mean by interaction? In the fullest sense, this means that transactions created by different writers often depend on one other. For example, let’s say Alice sends some funds to Bob and then Bob sends some on to Charlie. In this case, Bob’s transaction is dependent on Alice’s one, and there’s no way to verify Bob’s transaction without checking Alice’s very first. Because of this dependency, the transactions naturally belong together in a single collective database.

Taking this further, one nice feature of blockchains is that transactions can be created collaboratively by numerous writers, without either party exposing themselves to risk. This is what permits delivery versus payment settlement to be performed securely over a blockchain, without requiring a trusted intermediary.

A good case can also be made for situations where transactions from different writers are cross-correlated with each other, even if they remain independent. One example might be a collective identity database in which numerous entities validate different aspects of consumers’ identities. Albeit each such certification stands alone, the blockchain provides a useful way to bring everything together in a unified way.

6. Set the rules

This isn’t truly a condition, but rather an inescapable consequence of the previous points. If we have a database modified directly by numerous writers, and those writers don’t fully trust each other, then the database must contain embedded rules restricting the transactions performed.

These rules are fundamentally different from the constraints that show up in traditional databases, because they relate to the legitimacy of transformations rather than the state of the database at a particular point in time. Every transaction is checked against these rules by every knot in the network, and those that fail are rejected and not relayed on.

Asset ledgers contain a elementary example of this type of rule, to prevent transactions creating assets out of skinny air. The rule states that the total quantity of each asset in the ledger must be the same before and after every transaction.

7. Pick your validators

So far we’ve described a distributed database in which transactions can originate in many places, propagate inbetween knots in a peer-to-peer style, and are verified by every knot independently. So where does a “blockchain” come in? Well, a blockchain’s job is to be the authoritative final transaction log, on whose contents all knots provably agree.

Why do we need this log? Very first, it enables freshly added knots to calculate the database’s contents from scrape, without needing to trust another knot. 2nd, it addresses the possibility that some knots might miss some transactions, due to system downtime or a communications glitch. Without a transaction log, this would cause one knot’s database to diverge from that of the others, undermining the aim of a collective database.

Third, it’s possible for two transactions to be in conflict, so that only one can be accepted. A classic example is a dual spend in which the same asset is sent to two different recipients. In a peer-to-peer database with no central authority, knots might have different opinions regarding which transaction to accept, because there is no objective right reaction. By requiring transactions to be “confirmed” in a blockchain, we ensure that all knots converge on the same decision.

Ultimately, in Ethereum-style blockchains, the precise ordering of transactions plays a crucial role, because every transaction can affect what happens in every subsequent one. In this case the blockchain acts to define the authoritative chronology, without which transactions cannot be processed at all.

A blockchain is literally a chain of blocks, in which each block contains a set of transactions that are confirmed as a group. But who is responsible for choosing the transactions that go into each block? In the kind of “private blockchain” which is suitable for enterprise applications, the response is a closed group of validators (“miners”) who digitally sign the blocks they create. This whitelisting is combined with some form of distributed consensus scheme to prevent a minority of validators from seizing control of the chain. For example, MultiChain uses a scheme called mining diversity, in which the permitted miners work in a round-robin style, with some degree of leniency to permit for non-functioning knots.

No matter which consensus scheme is used, the validating knots have far less power than the possessor of a traditional centralized database. Validators cannot fake transactions or modify the database in disturbance of its rules. In an asset ledger, that means they cannot spend other people’s money, nor switch the total quantity of assets represented. Nonetheless there are still two ways in which validators can unduly influence a database’s contents:

  • Transaction censorship. If enough of the validators collude maliciously, they can prevent a particular transaction from being confirmed in the blockchain, leaving it permanently in limbo.
  • Biased conflict resolution. If two transactions conflict, the validator who creates the next block determines which transaction is confirmed on the blockchain, causing the other to be rejected. The fair choice would be the transaction that was seen very first, but validators can choose based on other factors without exposing this.

Because of these problems, when deploying a blockchain-based database, you need to have a clear idea of who your validators are and why you trust them, collectively if not alone. Depending on the use case, the validators might be chosen as: (a) one or more knots managed by a single organization, (b) a core group of organizations that maintain the chain, or (c) every knot on the network.

8. Back your assets

If you’ve got this far, you may have noticed that I tend to refer to blockchains as collective databases, rather than the more common “collective ledgers”. Why? Because as a technology, blockchains can be applied to problems far beyond the tracking of asset ownership. Any database which has numerous non-trusting writers can be implemented over a blockchain, without requiring a central intermediary. Examples include collective calendars, wiki-style collaboration and discussion forums.

Having said that, for now it seems that blockchains are mainly of interest to those who track the movement and exchange of financial assets. I can think of two reasons for this: (a) the finance sector is responding to the (in retrospect, minuscule) threat of cryptocurrencies like bitcoin, and (b) an asset ledger is the most ordinary and natural example of a collective database with interdependent transactions created by numerous non-trusting entities.

If you do want to use a blockchain as an asset ledger, you need to response one extra crucial question: What is the nature of the assets being moved around? By this I don’t just mean cash or bonds or bills of lading, tho’ of course that’s significant as well. The question is rather: Who stands behind the assets represented on the blockchain? If the database says that I own ten units of something, who will permit me to claim those ten units in the real world? Who do I sue if I can’t convert what’s written in the blockchain into traditional physical assets? (See this asset agreement for an example.)

The response, of course, will vary by the use case. For monetary assets, one can imagine custodial banks accepting cash in traditional form, and then crediting the accounts of depositors in a blockchain-powered distributed ledger. In trade finance, letters of credit and bills of lading would be backed by the importer’s bank and the shipping company respectively. And further in the future, we can imagine a time when the primary issuance of corporate bonds takes place directly on a blockchain by the company seeking to raise funds.

Conclusion

As I mentioned in the introduction, if your project does not fulfill every single one of these conditions, you should not be using a blockchain. In the absence of any of the very first five, you should consider one of: (a) regular file storage, (b) a centralized database, (c) master–slave database replication, or (d) numerous databases to which users can subscribe.

And if you do fulfill the very first five, there’s still work to do. You need to be able to express the rules of your application in terms of the transactions which a database permits. You need to be certain about who you can trust as validators and how you’ll define distributed consensus. And ultimately, if you’re looking at creating a collective ledger, you need to know who will be backing the assets which that ledger represents.

Got all the answers? Congratulations, you have a real blockchain use case. And we’d love to hear from you.

Avoiding the pointless blockchain project, MultiChain

Avoiding the pointless blockchain project

How to determine if you’ve found a real blockchain use case

Blockchains are overhyped. There, I said it. From Sibos to Money20/20 to cover stories of The Economist and Euromoney, everyone seems to be climbing aboard the blockchain wagon. And no doubt like others in the space, we’re watching a rapidly enlargening number of companies building proofs of concept on our platform and/or asking for our help.

As a youthful startup, you’d think we’d be over the moon. Surely now is the time to raise a ton of money and build that high spectacle next generation blockchain platform we’ve already designed. What on earth are we waiting for?

I’ll tell you what. We’re waiting to build up a clearer understanding of where blockchains genuinely add value in enterprise IT. You see, a large proportion of these incoming projects have nothing to do with blockchains at all. Here’s how it plays out. Big company hears that blockchains are the next big thing. Big company finds some people internally who are interested in the subject. Big company gives them a budget and tells them to go do something blockchainy. Soon enough they come knocking on our door, swinging dollar bills, asking us to help them think up a use case. Say what now?

As for those who do have a project in mind, what’s the problem? In many cases, the project can be implemented ideally well using a regular relational database. You know, big metal behemoths like Oracle and SQL Server, or for the more open-minded, MySQL and Postgres. So let me embark by setting things straight:

If your requirements are fulfilled by today’s relational databases, you’d be insane to use a blockchain.

Why? Because products like Oracle and MySQL have decades of development behind them. They’ve been deployed on millions of servers running trillions of queries. They contain some of the most accurately tested, debugged and optimized code on the planet, processing thousands of transactions per 2nd without cracking a sweat.

And what about blockchains? Well, our product was one of the very first to market, and has been available for exactly five months, with a few thousand downloads. Actually it’s enormously stable, because we built it off Bitcoin Core, the software which powers bitcoin. But even so, this entire product category is still in its diapers.

So am I telling that blockchains are futile? Absolutely not. But before you embark on that shiny blockchain project, you need to have a very clear idea of why you are using a blockchain. There are a bunch of conditions that need to be fulfilled. And if they’re not, you should go back to the drawing board. Maybe you can define the project better. Or maybe you can save everyone a fountain of time and money, because you don’t need a blockchain at all.

1. The database

Here’s the very first rule. Blockchains are a technology for collective databases. So you need to embark by knowing why you are using a database, by which I mean a structured repository of information. This can be a traditional relational database, which contains one or more spreadsheet-like tables. Or it can be the trendier NoSQL multitude, which works more like a file system or dictionary. (On a theoretical level, NoSQL databases are just a subset of relational databases anyway.)

A ledger for financial assets can be naturally voiced as a database table in which each row represents one asset type possessed by one particular entity. Each row has three columns containing: (a) the holder’s identifier such as an account number, (b) an identifier for the asset type such as “USD” or “AAPL”, and (c) the quantity of that asset held by that proprietor.

Databases are modified via “transactions” which represent a set of switches to the database which must be accepted or rejected as a entire. For example, in the case of an asset ledger, a payment from one user to another is represented by a transaction that deducts the adequate quantity from one row, and adds it to another.

Two. Numerous writers

This one’s effortless. Blockchains are a technology for databases with numerous writers. In other words, there needs to be more than one entity which is generating the transactions that modify the database. Do you know who these writers are?

In most cases the writers will also run “knots” which hold a copy of the database and relay transactions to other knots in a peer-to-peer style. However transactions might also be created by users who are not running a knot themselves. Consider for example a payments system which is collectively maintained by a petite group of banks but has millions of end users on mobile devices, communicating only with their own bank’s systems.

Trio. Absence of trust

And now for the third rule. If numerous entities are writing to the database, there also needs to be some degree of mistrust inbetween those entities. In other words, blockchains are a technology for databases with numerous non-trusting writers.

You might think that mistrust only arises inbetween separate organizations, such as the banks trading in a marketplace or the companies involved in a supply chain. But it can also exist within a single large organization, for example inbetween departments or the operations in different countries.

What do I specifically mean by mistrust? I mean that one user is not willing to let another modify database entries which it “possesses”. Similarly, when it comes to reading the database’s contents, one user will not accept as gospel the “truth” as reported by another user, because each has different economic or political incentives.

Four. Disintermediation

So the problem, as defined so far, is enabling a database with numerous non-trusting writers. And there’s already a well-known solution to this problem: the trusted intermediary. That is, someone who all the writers trust, even if they don’t fully trust each other. Indeed, the world is packed with databases of this nature, such as the ledger of accounts in a bank. Your bank controls the database and ensures that every transaction is valid and authorized by the customer whose funds it moves. No matter how politely you ask, your bank will never let you modify their database directly.

Blockchains liquidate the need for trusted intermediaries by enabling databases with numerous non-trusting writers to be modified directly. No central gatekeeper is required to verify transactions and authenticate their source. Instead, the definition of a transaction is extended to include a proof of authorization and a proof of validity. Transactions can therefore be independently verified and processed by every knot which maintains a copy of the database.

But the question you need to ask is: Do you want or need this disintermediation? Given your use case, is there anything wrong with having a central party who maintains an authoritative database and acts as the transaction gatekeeper? Good reasons to choose a blockchain-based database over a trusted intermediary might include lower costs, quicker transactions, automatic reconciliation, fresh regulation or a ordinary inability to find a suitable intermediary.

Five. Transaction interaction

So blockchains make sense for databases that are collective by numerous writers who don’t entirely trust each other, and who modify that database directly. But that’s still not enough. Blockchains truly shine where there is some interaction inbetween the transactions created by these writers.

What do I mean by interaction? In the fullest sense, this means that transactions created by different writers often depend on one other. For example, let’s say Alice sends some funds to Bob and then Bob sends some on to Charlie. In this case, Bob’s transaction is dependent on Alice’s one, and there’s no way to verify Bob’s transaction without checking Alice’s very first. Because of this dependency, the transactions naturally belong together in a single collective database.

Taking this further, one nice feature of blockchains is that transactions can be created collaboratively by numerous writers, without either party exposing themselves to risk. This is what permits delivery versus payment settlement to be performed securely over a blockchain, without requiring a trusted intermediary.

A good case can also be made for situations where transactions from different writers are cross-correlated with each other, even if they remain independent. One example might be a collective identity database in which numerous entities validate different aspects of consumers’ identities. Albeit each such certification stands alone, the blockchain provides a useful way to bring everything together in a unified way.

6. Set the rules

This isn’t truly a condition, but rather an unpreventable consequence of the previous points. If we have a database modified directly by numerous writers, and those writers don’t fully trust each other, then the database must contain embedded rules restricting the transactions performed.

These rules are fundamentally different from the constraints that emerge in traditional databases, because they relate to the legitimacy of transformations rather than the state of the database at a particular point in time. Every transaction is checked against these rules by every knot in the network, and those that fail are rejected and not relayed on.

Asset ledgers contain a plain example of this type of rule, to prevent transactions creating assets out of skinny air. The rule states that the total quantity of each asset in the ledger must be the same before and after every transaction.

7. Pick your validators

So far we’ve described a distributed database in which transactions can originate in many places, propagate inbetween knots in a peer-to-peer style, and are verified by every knot independently. So where does a “blockchain” come in? Well, a blockchain’s job is to be the authoritative final transaction log, on whose contents all knots provably agree.

Why do we need this log? Very first, it enables freshly added knots to calculate the database’s contents from scrape, without needing to trust another knot. 2nd, it addresses the possibility that some knots might miss some transactions, due to system downtime or a communications glitch. Without a transaction log, this would cause one knot’s database to diverge from that of the others, undermining the aim of a collective database.

Third, it’s possible for two transactions to be in conflict, so that only one can be accepted. A classic example is a dual spend in which the same asset is sent to two different recipients. In a peer-to-peer database with no central authority, knots might have different opinions regarding which transaction to accept, because there is no objective right reaction. By requiring transactions to be “confirmed” in a blockchain, we ensure that all knots converge on the same decision.

Ultimately, in Ethereum-style blockchains, the precise ordering of transactions plays a crucial role, because every transaction can affect what happens in every subsequent one. In this case the blockchain acts to define the authoritative chronology, without which transactions cannot be processed at all.

A blockchain is literally a chain of blocks, in which each block contains a set of transactions that are confirmed as a group. But who is responsible for choosing the transactions that go into each block? In the kind of “private blockchain” which is suitable for enterprise applications, the response is a closed group of validators (“miners”) who digitally sign the blocks they create. This whitelisting is combined with some form of distributed consensus scheme to prevent a minority of validators from seizing control of the chain. For example, MultiChain uses a scheme called mining diversity, in which the permitted miners work in a round-robin style, with some degree of leniency to permit for non-functioning knots.

No matter which consensus scheme is used, the validating knots have far less power than the holder of a traditional centralized database. Validators cannot fake transactions or modify the database in disturbance of its rules. In an asset ledger, that means they cannot spend other people’s money, nor switch the total quantity of assets represented. Nonetheless there are still two ways in which validators can unduly influence a database’s contents:

  • Transaction censorship. If enough of the validators collude maliciously, they can prevent a particular transaction from being confirmed in the blockchain, leaving it permanently in limbo.
  • Biased conflict resolution. If two transactions conflict, the validator who creates the next block determines which transaction is confirmed on the blockchain, causing the other to be rejected. The fair choice would be the transaction that was seen very first, but validators can choose based on other factors without exposing this.

Because of these problems, when deploying a blockchain-based database, you need to have a clear idea of who your validators are and why you trust them, collectively if not alone. Depending on the use case, the validators might be chosen as: (a) one or more knots managed by a single organization, (b) a core group of organizations that maintain the chain, or (c) every knot on the network.

8. Back your assets

If you’ve got this far, you may have noticed that I tend to refer to blockchains as collective databases, rather than the more common “collective ledgers”. Why? Because as a technology, blockchains can be applied to problems far beyond the tracking of asset ownership. Any database which has numerous non-trusting writers can be implemented over a blockchain, without requiring a central intermediary. Examples include collective calendars, wiki-style collaboration and discussion forums.

Having said that, for now it seems that blockchains are mainly of interest to those who track the movement and exchange of financial assets. I can think of two reasons for this: (a) the finance sector is responding to the (in retrospect, minuscule) threat of cryptocurrencies like bitcoin, and (b) an asset ledger is the most elementary and natural example of a collective database with interdependent transactions created by numerous non-trusting entities.

If you do want to use a blockchain as an asset ledger, you need to response one extra crucial question: What is the nature of the assets being moved around? By this I don’t just mean cash or bonds or bills of lading, tho’ of course that’s significant as well. The question is rather: Who stands behind the assets represented on the blockchain? If the database says that I own ten units of something, who will permit me to claim those ten units in the real world? Who do I sue if I can’t convert what’s written in the blockchain into traditional physical assets? (See this asset agreement for an example.)

The response, of course, will vary by the use case. For monetary assets, one can imagine custodial banks accepting cash in traditional form, and then crediting the accounts of depositors in a blockchain-powered distributed ledger. In trade finance, letters of credit and bills of lading would be backed by the importer’s bank and the shipping company respectively. And further in the future, we can imagine a time when the primary issuance of corporate bonds takes place directly on a blockchain by the company seeking to raise funds.

Conclusion

As I mentioned in the introduction, if your project does not fulfill every single one of these conditions, you should not be using a blockchain. In the absence of any of the very first five, you should consider one of: (a) regular file storage, (b) a centralized database, (c) master–slave database replication, or (d) numerous databases to which users can subscribe.

And if you do fulfill the very first five, there’s still work to do. You need to be able to express the rules of your application in terms of the transactions which a database permits. You need to be certain about who you can trust as validators and how you’ll define distributed consensus. And eventually, if you’re looking at creating a collective ledger, you need to know who will be backing the assets which that ledger represents.

Got all the answers? Congratulations, you have a real blockchain use case. And we’d love to hear from you.

Related video:

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *