Corda Top Ten Facts #8: Pluggable Consensus
Myth: Corda is not “anchored” to a public blockchain so it isn’t “secure”
When you think of most blockchains, the first thing you often think about is consensus: how are transactions confirmed? Who confirms them? How could this be attacked? What assumptions are being made about safety and security?
And this question becomes particularly acute in the context of enterprise blockchains. In the enterprise space, we need things like transaction finality and sometimes need things like near-instant confirmation. And we usually need to be in total control of who provides the confirmation guarantee for particular transaction types.
This leads inevitably to the need for enterprise platforms to support multiple consensus algorithms, including byzantine fault tolerant ones, of course — and I explain more below about how Corda does this.
And it also explains why enterprise blockchains typically don’t use proof of work or proof of stake: the need for transaction finality is almost always non-negotiable. Businesses really don’t like transactions that have a chance of being reversed. Transactions that can go from “confirmed” to “unconfirmed” can cause utter havoc in business.
And as elegant as PoW may be, the one thing it can’t and doesn’t provide is finality within any guaranteed time horizon.
However, a strange myth has recently taken hold that somehow one can make enterprise blockchains “more secure” by “anchoring” them in a proof of work blockchain. This is a somewhat odd belief.
The problem is that it just doesn’t make any sense to use a probabilistically final PoW blockchain as some sort of ‘anchor’ for transactions that need to be final.
- When do you declare the supposedly finalised enterprise transaction actually finalised? When the anchor is six blocks deep? After 24 hours? Never? What are users supposed to do in the meantime?
- What do you do if the ‘anchor’ becomes unanchored after a reorganisation of the public blockchain? Reverse all the supposedly finalised transactions? In which case, in what way were they final?
So if ‘anchoring’ an enterprise chain into a PoW chain is questionable, how do we do things with Corda?
First, in Corda, we believe which consensus mechanism to use should be a decision for those deploying Corda solutions: the needs of a closely-knit trading network in London might be very different to those of a diffuse deeply untrusting network of trading partners in a complex supply chain.
So whenever a new asset or contract is initiated onto the Corda ledger, it is tagged with the consensus service that will govern it. A high value asset might be tagged with a multi-part byzantine fault-tolerant consensus pool. And updates to an ephemeral document being managed by several firms who trust each other might be just fine to be confirmed by a crash-fault tolerant cluster operated by those firms themselves.
This has the really useful side-effect that it allows Corda to support multiple different consensus pools on the same network. Which enables Corda to achieve really high network-level transaction rates.
You can even move assets from one consensus pool to another to enable complex multi-asset transfers in a single transaction.
It’s ridiculously flexible and provides for decentralised consensus equal to any other permissioned, enterprise or consortium blockchain platform.
Now, it so happens that nothing stops people from implementing probabilistic finality notary pools on Corda, of course — proof of work, proof of stake, delegation to the bitcoin blockchain even… take your pick… the notary pluggability design is massively flexible.
We just think it’s a bad idea to use a probabilistic consensus algorithm if your business process requires finality.
So, on Corda, we take a less glamorous approach and rely on proven algorithms (including BFT) to provide finality, and we embed their operation in a legal and regulatory framework that is underpinned by the strong identity layer that defines every Corda network.
It may seem simpler to “anchor” into a “trustless” public blockchain and to avoid these difficult questions. The only problem is: such an approach doesn’t work…