Open Consortium “Blockchains” don’t need blocks.

They can just be “block-less” simulators.

What’s a “blockchain?” What we call “blockchains” are distributed simulators of computers, or distributed virtual machines.

Incidentally, the first widely successful distributed virtual machine, which we call the Bitcoin network, happened to periodically produce and broadcast “blocks” of “signed transactions” to all participants. Bitcoin became famous for its “blocks” mainly because producing them was, and still is, worth a lot of actual money.

The “transactions” inside our “blockchain blocks” are known as events in distributed simulation. Since our distributed virtual machine simulators (DVMS) we call “blockchains” simulate financial games within them, we had our DVMSs archive the series of timestamped, ordered and cryptographically-signed events. That archive exists only for public auditing purposes and as a proof that the DVMS is perfectly following the mathematical simulation rules that have been previously published — all other uses for the “blocks” of “blockchain” DVMSs are secondary.

The two most popular DMVSs running financial simulations, Bitcoin and Ethereum, are implemented on top of a “peer-to-peer” (P2P) network. Both have 10,000+ replicas (peers) operated by pseudonymous parties. Like all other P2P DVMSs, they are completely open networks where any pseudonymous party with an IP address is free to join or leave at any time.

In a P2P DVMS, the blocks matter. Since we don’t know who the replicas are, the only way we can be sure that they are following the rules is by downloading the entire “block history,” that is, reconstructing the system state locally from a plausible event history from the beginning of simulation time. To break away from that requirement, we can trust other specific parties (i.e. socially identified — people we know or recognize as trustworthy) to provide us with an up-to-date simulation state that we can trust instead.

Enter the EOS “blockchain” (DVMS). The EOS network is not a traditional “P2P” network, but an open consortium network with a fixed number of replica slots, currently set at 21. What it means is that the EOS DVMS is replicated by only 21 parties as opposed to 10,000, but that those parties are not pseudonymous but actually public and known organizations backed by reputations and by Legal(TM) requirements (i.e. they cannot screw over people or the State(TM) will go after them and terrorize them).

The EOS DVMS also produces blocks. We know its 21 replicas are all in synchrony and that they are following the published mathematical rules. That is, an open consortium (OC) network, like a P2P network, works as a distribution strategy for DVMSs. What unites OC “blockchains” and P2P “blockchains” are the blocks, or the massive and public audit trail.

In fact, if the massive audit trail, the “blockchain” is there, does it matter whether an OC network is run by 1,000, 21 or even just a single organization? I have argued that it doesn’t matter. A clone of the EOS OC network with a single “block producer,” a single organization hosting the entire network “server” simulation, would be as secure, in practice, as the 21-node EOS DVMS.

I am literally saying that a “blockchain” DVMS, that is, one that produces a public trail of cryptographically-signed only needs one simulator node run by a highly-visible public entity that would in reality never attempt to subvert the game rules, and that would be technically capable of keeping the system running on the public Internet. Google, Microsoft or Amazon could easily run that system and people would use it, if only their lawyers would let them do it.

The main contribution of EOS was the inauguration of the open consortium (OC) network for blockchain DVMSs. It shows that requiring nodes to be public entities is what allows a radical reduction in the node set (from 10,000 to 21 or, as I argue, to a single node), if you keep the “blockchain” aspect of it, that is, if you keep the massive audit trail of cryptographically-signed events since the beginning of simulation time.

But what I’m going to propose now is that we don’t need blocks. We can have a DVMS running in an OC network that simulates the same financial games but without ever publishing blocks of signed transactions.

My main argument here is that if we take the actual existing EOS network with its 21 nodes run by highly visible and highly trusted operators and take out the “blocks,” in such a way that the only way to know the state of the distributed virtual machine is to query their public APIs and ask for the current state — that is, there are NO blocks and you cannot reconstruct the simulation state yourself — then the EOS network would continue to work and would continue to be equally safe and trustworthy.

Of course, all of the 21 EOS nodes would eventually witness every signed client transaction. All of the simulation events would have to pass by them so they would be able to properly and securely replicate the DVM state, but once they receive an event and apply to their replica, they would be free to just discard it, without having to deal with the overhead of archiving it for publication. The software would be much simpler and resource requirements would drop drastically, for actually no actual cost in actual security.

What are the odds the 21 highly-invested, highly-public EOS network operators that you already know today would suddenly start cheating the network, just because they don’t have to publish that massive, wasteful, redundant event trail anymore? If you think about it for a few moments, you will realize those odds in practice are zero. It’s impossible. The odds it would happen in the current actually existing world are negligible. And that’s because there is a sufficient number of public, socially-known and socially-vetted nodes replicating the virtual machine simulation. They all verify each other, and in a 100% uptime network such as the Social Network (i.e. “society,” where you and me have the names that show on our “ID documents”), you can finalize any dispute over what is the actual, correct DVMS state with a “>1/2” quorum. If you have 21 nodes, whatever 11 of them socially agree on, you know that’s true.

So, to sum it up:

  • We can have an OC (i.e. EOS-like) “blockchain” (i.e. distributed VM sim) without any blocks at all if there are 21 nodes or so;
  • We can have an OC (i.e. EOS-like) blockchain with blocks that has a single (1) node, because the blocks do all the work of trust;

I do not think we can have a “block-less” OC DVMS with only one node. That’s really just a server, and that would be inadequate for running “financial” games.

Bitcoin people have long joked about the “Wayne Chain,” — an hypothetical “centralized” blockchain with a single server node — but the Wayne Chain is actually possible if Wayne publishes a valid chain of “blocks” in real-time for everyone else to verify, has a powerful and always-on API service, and if there are backup organizations that can take over Wayne’s role if he gets SWAT-raided. The “social layer,” that is, the real world where you and I actually exist, is pretty much all it takes to keep Wayne honest. That is, if Wayne is not an actual scammer but a serious, real public entity.

But the OC network concept inaugurated by EOS gives us yet another evolutionary choice: we can get rid of social replication and keep the blocks, OR we can keep social replication and get rid of the blocks! And so we can see that the Distributed Virtual Machine Simulators (DVMSs) we have been publishing such as Ethereum and EOS are only incidentally “blockchains.” You don’t even need the blocks!

What kinds of engineering optimizations can be made in the EOS software if block archival and publishing is left behind? What are the possible savings? If the OC nodes trust each other enough, they can even collectively avoid checking, or even broadcasting, client signatures at or to more than one server node at a time.

Maybe someone finds that direction interesting.

Like what you read? Give Fabiana Cecin a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.