Don’t use blockchain

Rarely do you find technology with so much hype as blockchain, where the best architectural advice is to avoid using it. Or, said with less hyperbole, to correctly minimize your direct dependency on blockchain.

Why is that?

Imagine software where thousands of processes all need to look at and verify the same state change. And imagine too that they all need to store a copy of the same information to ensure the state change is correct.

While it is good to have a few copies of data, for backup and resiliency, it’s very inefficient to have hundreds or thousands of copies.

This also adds latency, and because all of these processes need to review the same state change, you’ve forced yourself into a single threaded model.

So it’s costly, slow and it doesn’t scale. Great, why do people want to use this?

The key feature of blockchain, as a decentralized system, is that it allows you to remove third-party risk. You no longer need to trust that someone will be running servers for you, and that those servers keep on running the right software, or that the operator don’t abuse their access in any way.

But this doesn’t imply that blockchain is a database, or blockchain is a platform to run software directly on-top of. It’s too limited for this, and there’s also privacy concerns with storing information on it.

Hence, we need to understand how to correctly use it. And this is where minimizing its use, while still enjoying its benefits, is the key challenge.

There has been a long process, still ongoing, among developers, architects and solution designers, to fully understand this. Time and again I see people approaching this technology with old mindsets.

But as we make progress on correctly understanding how we can apply the technology, we also start seeing a few good examples. I’d like to highlight a few which I think take us in the right direction.

Firstly, I’d like to point out the Baseline protocol. This protocol does not try to move business logic to the blockchain with smart contracts. It does not try to use the blockchain as a shared database. It simply allows informed parties to confirm their shared view on something they each keep private. Do we have the same view on this invoice, for example? Correctly hash the invoice, put the hash on the blockchain, and let the two business flows coordinate around this. And it doesn’t try to introduce a new PoA Ethereum network, because why do you need yet another Ethereum network? You only think you need that if you’re afraid of what you’re doing with it, adding third-party risk in the process.

Next, I’d like to mention the Sidetree protocol. While the Baseline protocol is focused on business process, the Sitetree protocol is focus on decentralized identity. Again, we see Ethereum usage being minimized, through the Element DID methods, with again hashes being anchored to the blockchain. A more appropriate protocol, IPFS, is used for data storage. And it does this while still respecting the decentralized nature with minimization / elimination of third-party risk.

Finally, I’d like to mention Polygon’s Matic PoS network, as an example of a layer 2 network leveraging the mainnet as a trust anchor. Through staking contracts on Ethereum mainnet, a layer 2 PoS network can be managed a lot easier than if mainnet didn’t exist. Again, this minimizes the use of mainnet, by moving operations over to a layer 2. And conveniently for developers and users, it is all with the same RPCs and the EVM, allowing for the same tools, wallets and contracts source code.

That’s three examples, and I expect to see many more like this going forward, as people learn to build, or rather avoid building, on blockchain.