I’ve been hearing a lot about the “Internet of Blockchains”, which will likely be the up-and-coming trend of 2018. It seems like many people in the crypto sphere have become enamored with a foregone conclusion that private and public chains will, some day soon, co-exist in some vast ocean of interoperability. Surprisingly, I have never seen a single mention of using event-sourced databases inside of this wild (and almost certainly inefficient) future, so I’ll throw my hat into the ring and give you my prediction.

Spoiler alert: my version of the future looks very different from what seems to be the collective zeitgeist of the moment. The good news is that everything my future requires already exists — we don’t need to develop any new software. Without further ado, I present Alex’s Internet of Blockchains, which you can start building today!

Underlying public network: Ethereum

The first ingredient is a common network. I know it’s uncool these days to be a “maximalist” and I am somewhat afraid to admit that I am one. I honestly think one blockchain will monopolize >90% of all traffic and value. In physics and in all things, more interfaces == less efficiency. Right now I think the most likely winner is Ethereum, but I keep my ear to the ground listening for new contestants.

Having an underlying public blockchain is crucial to Alex’s Internet of Blockchains — which I’ll abbreviate as AIB from now on — because we need a common protocol across which to communicate. The web has benefited tremendously from HTTP and if you’re not a developer, you won’t appreciate just how many person-hours this standard has saved humanity over the last two decades. Let’s just say it’s a lot.

Federated Pegs, Oh My!

In AIB, Ethereum is used to initiate federated pegs (another blasphemy — I have a lot of unpopular opinions!) with corporate counterparties. As a shout out to our cypherpunk roots, I’ll use EvilCorp as an example of a trusted institution. Here’s what you might do to deposit into EvilCorp’s peg in Solidity:

function EvilCorpDeposit() {

locked[msg.sender] += msg.value;

Deposit(msg.sender, msg.value, now);

}

All we need to do is lock up some funds (ether here, but you could use ERC20 tokens too) and emit an event log.

Each peg would exist on the public Ethereum network and be managed by an admin of some trusted institution (in this case the EvilCorp admin). Only this admin would be able to facilitate a withdrawal back into Ethereum:

function EvilCorpWithdrawal(address user, uint amount) onlyAdmin() {

locked[user] -= amount;

Withdrawal(user, amount, now);

user.send(amount);

}

That’s basically all Ethereum is used for in AIB. Feel let down? I’m sorry. But just, wait — things are about to take a turn. So let’s continue the tour and see what happens when you have money deposited in EvilCorp’s peg.

Trusted Systems

The next ingredient in AIB is a set of event-sourced databases that are controlled by trusted institutions. Each of these databases could be shared by a consortium of entities or belong to one — it doesn’t really matter.

Event Sourcing?

If you aren’t familiar with the database pattern known as event sourcing (don’t worry — it’s relatively new), you should read this excellent article to get caught up. For more technical details, see this one. In a nutshell, event sourcing builds a global state by appending it with events, which represent atomic updates.

Why use event sourcing? From the first article:

Event sourcing provides a lot of benefits besides having a history of events. They include, but not limited to: Audit trail. Events are immutable and store the full history of the state of the system. As such, they can provide a detailed audit trail of what has taken place within the system. Integration with other subsystems. Event store can publish events to notify other interested subsystems of changes to the application’s state. Again, the event store provides a complete record of all the events that it published to other systems. Time Travel. By storing events, you have the ability to determine the state of the system at any previous point in time by querying the events associated with a domain object up to that point in time. This enables you to answer historical questions from the business about the system.

Do these things sound familiar to you? They should. These are the primary goals of most private and consortium blockchains.

Event-sourced databases can accomplish the same goals as private/consortium chains because they update state the same way a blockchain would. Both design patterns leverage a global, programmable state, updated with append-only atomic events (a.k.a. transactions), and which may be audited or snapshotted (saved) by any participant in the network at any time.

From a trust perspective, it makes no difference if your banking cartel is writing to a Quorum, Hyperledger, or Kafka instance. The only real difference is that Kafka is fundamentally more efficient at processing transactions based on the way its core architecture structures its data.

What happened to our blockchains?

Hopefully you will have noticed by now that AIB does not include any private blockchains. In fact, it’s not really an internet of blockchains at all! Plot twist!

But not as surprising as becoming a beetle

The first article linked above mentions Kafka being a great choice for event sourcing, largely due to its native logging features, but event-sourcing can be used in SQL too — here is an implementation in MySQL, which is my personal favorite SQL flavor.

Event sourcing is a clever pattern built on top of extremely powerful database engines that are designed to handle large data throughputs. Blockchains are built for trust, databases for throughput. Event sourcing allows us to achieve a hybrid model with characteristics of both.

If you’re interested in some benchmarking stats, here are a few tests conducted on single machines:

Databases:

Private blockchains:

Note: I tried to find benchmarks with similar-ish machines for the above, please see the respective links for more information. I think these are reasonable numbers, but by no means perfect comparisons.

Wait! What about EEA?

If you’re screaming at me for promoting these uncool databases, hold your horses. One of the core tenants of the Enterprise Ethereum Alliance is to provide a technological upgrade path to the public Ethereum network and to contribute code and standards to the broader ecosystem. If your organization is in the EEA, contributing open source code, and possibly wants to use the public chain in the future, I am not discouraging you from that goal! Keep doing what you’re doing.

I would discourage you from blockchain consortia if your intention is to never use the public chain and if you don’t care about Ethereum. I’m going to put it bluntly: if you’re not looking at the public chain, you’re wasting your time. The benchmarking numbers paint a pretty obvious story — Quorum will never give you the speed of Kafka, especially since blockchains get less efficient as more participants join (because of that pesky “consensus” thing).

The other side of the peg

Anyway, back to AIB. Once your ether or tokens are deposited to EvilCorp’s smart contract, the EvilCorp admin takes the event emitted from Ethereum and plays it on the EvilCorp Kafka database. Since your Ethereum address is your identifier in both systems (because EvilCorp devs know how to design proper systems and have also read my awesome article on the topic), this event triggers a domain event service to increase your current balance in EvilCorp’s system.

This event is, of course, verifiable on the public Ethereum network so EvilCorp doesn’t have to worry about spoofed deposits.

EvilCorp’s Black Box

Here is where things go dark in AIB. We really have no idea what EvilCorp is doing with your money. You may request a withdrawal one day and be greeted by crickets because the EvilCorp admin is on a yacht in the Bahamas. But I must remind you that this risk is still present in private blockchains. Again, the only fundamental difference is in underlying data structures.

If EvilCorp wants to stay in business and design good systems, I would expect them to keep a properly event-sourced database (probably a safer assumption if they are in a consortium). Once you request a withdrawal on the EvilCorp system, an event is played on their state. If the state is successfully updated (i.e. if you’re not double spending), it is forwarded to a cache of successful withdrawal events that need to be played on Ethereum.

At this point, the EvilCorp admin would [hopefully] pop the cache and trigger an EvilCorpWithdrawal on their Ethereum smart contract and you would get your withdrawal on the public chain.

Spending Money at EvilCorp

Of course, if you wanted to actually spend money on EvilCorp’s system, you wouldn’t be able to withdraw your full deposit later on. There needs to be a way to draw down your balance (this could be done asynchronously and events could be combined/batched).

This is played on-chain, so this part will be expensive for bad system designs. It would be useful to collapse events on the EvilCorp side. One approach might be to hold fresh withdrawal requests in a cache which collapses all pending DrawDown events into one and plays it on Ethereum, which then triggers popping of that withdrawal cache and playing of the original withdrawal message. This would mean only one DrawDown is needed per Withdrawal . In any event, I’m sure whatever system EvilCorp designs will be fine so I’ll just abstract this away for now.

function drawDown(address user, uint amount) onlyAdmin() {

locked[user] -= amount;

revenue_addr.send(amount);

DrawDown(user, amount, now);

}

Note that any amount drawn down is sent to the EvilCorp revenue address. This emits another event, which can be played in a different EvilCorp service to appropriately adjust your balance in the EvilCorp state and prevent any erroneous withdrawals.

The Full Peg

Conceptually, the peg I’ve just described is pretty simple. There’s a custodian for each smart contract, which lives on the public Ethereum network. Each peg is with either a single institution or a consortium of institutions.

EvilCorp Peg

Why We Don’t Need an “Internet of Blockchains”

I just described a lean (albeit early-stage), interconnected network that uses nothing but the public Ethereum network and pegs to trusted systems. No meta-networks, no other blockchains. Event-sourcing is a clever way of maintaining an application state that gives participants some trust in the current state of the system. If used correctly, it is tamper-proof, just like the blockchain. It is append-only, just like the blockchain. Unlike the blockchain, it can scale to millions of transactions per second today, which is possible because databases are designed to handle lots of traffic.

Blockchains have their use, which truly is revolutionary. That use is allowing any individual in the world to trust any counterparty. Private blockchains are not revolutionary — they simply are inefficient relative to other options. The utility of a blockchain breaks down in a private or consortium setting and should, in my opinion, be replaced by a more performant engine like Apache Kafka.

So there it is — my vision of the future. I’m sorry if this article offended you, but I think it’s important to be intellectually honest. If you disagree with my opinions, I hope this article at least gave you pause to ask yourself why you think an internet of blockchains is a foregone conclusion.