Imagine the following ancient scenario.

A number of generals have besieged a Byzantine city.

Each night, they all send messages from their camps with their plans for the next morning.

Each general’s task is to announce whether they will attack or wait. A coordinated attack or coordinated wait are the only good options; indecision, where some generals attack and others wait, will lead to a disastrous defeat. The generals must reach a common decision, a consensus, and they must know what the consensus is.

To make matters worse, there might be some traitorous generals among them. And the couriers the generals use to send their messages might not be trustworthy.

So the generals need a consensus system that allows for bad or missing votes. A system that is tolerant of faults.

“Traitor used to be fun, before we started playing with the Arthurian Fault Tolerance expansion.”

Byzantine Fault Tolerance

However they do it, as long as the loyal generals

Come to a majority decision and Know that they have come to that decision regardless of any reasonable number of bad actors,

they have achieved Byzantine Fault Tolerance.

The system the generals need must work despite any faults and any attackers. It must be tolerant of errors, bad actors, delays, missing votes, and more.

Perhaps if any general’s message goes missing, it is understood to be “wait,” the safer option.

But by morning, the generals must have a consensus and know that consensus. They must know for certain whether they are attacking or waiting.

Otherwise, they suffer a Byzantine failure, and their system cannot go on.

If they suffer failure, the generals’ armies will be routed in the ensuing fight, and the generals risk being executed by mobs of people. (Angry Byzantine mobs were not known for their fault tolerance.)

Similarly, to avoid angry mobs of de-monied cryptocurrency users pounding on their front doors, programmers must implement Byzantine Fault Tolerance. A distributed network with Byzantine Fault Tolerance can tolerate bad actors, temporarily disabled nodes, communication mix-ups, and any other consensus-threatening wrenches in the works without the system coming apart.

So Byzantine Fault Tolerance will be an important requirement for any consensus model.

As far as consensus models go, most of these Ethereum challengers rely on variations on Proof of Stake. Today’s platform, EOS, uses Delegated Proof of Stake.

What is Delegated Proof of Stake?

By now, you’ve heard of “Proof of Work” (PoW), the original blockchain consensus model and still the method used to secure Bitcoin, which has proven remarkably resilient.

Many cryptocurrencies still run on PoW, despite rising electricity requirements and the potential for network congestion and fees. After all, Bitcoin’s method is the most time-tested of the various consensus models in existence.

Proof of Stake (PoS) is becoming increasingly popular, however, as an alternative with low energy cost and which places governance decisions squarely in the hands of token holders.

Time for some definitions. Consensus Model: The way a distributed network agrees upon the order and validity of transactions in a blockchain. Proof of Work (PoW): Nodes in a network compete to complete some intensive work first in order to build the blockchain. Proof of the work done provides confidence in the network, since it is impractical for an attacker to have enough computing power to overpower the network. Proof of Stake (PoS): Nodes in a network take turns building the blockchain. They are randomly selected, with nodes holding more coins being selected more often. If a node attempts something illegitimate, it loses its stake. This also provides confidence in the network, since it takes an extraordinary amount of money and risk for a bad actor to buy and use the coins necessary to seize control.

Achieving good Byzantine Fault Tolerance with a PoS protocol is an interesting challenge, and many top protocols are using variations on this theme, such as Cardano’s Ouroboros PoS, NEO’s Proof of Authority, and Lisk’s DPoS, which we will all consider later.

Ethereum itself is PoW but plans to institute a PoW/PoS hybrid system soon, and perhaps move exclusively to PoS down the road.

Delegated Proof of Stake is like a republic to Proof of Stake’s pure democracy. Consensus is still decided by token holders taking turns in a randomized order to write blocks, but not every single node on the network participates directly. Instead, a smaller number of Block Producers are voted in by the token holders, much as government officials are voted in by the general public in most modern states.

These Block Producers are not miners. They are not competing to “solve” a block first as miners do under Proof of Work.

Instead, BPs cooperate to write and audit the blockchain. They are issued block rewards (more tokens) for their contributions. Just as they are continually voted into their offices by the token holders, they can be replaced by the community if their performance is dubious.

Does Delegated Proof of Stake give EOS enough power to be a serious contender among the Ethereum Challengers?

Let’s find out. Here are the questions we’re looking to answer.

The Big Questions

In this series I’m focusing on six problems Ethereum critics (and in some cases the Ethereum Foundation itself) point out, along with a seventh consideration: how each product might challenge Ethereum’s market dominance.

I talked about each problem in part 1, but here’s a quick refresher:

Scalability. Handling all the data Ethereum promises to handle may require millions of transactions per second. It currently handles under 20. Governance. Even if good scalability solutions can be presented, it’s unclear whether they will even be adopted soon. Development Complexity. Ethereum uses its own programming language, and bug fixes and updates cannot be easily implemented. Timeline. Ethereum will likely solve the above issues, but how long will it take for the proposed solutions to be implemented? Adoptability. Like many cryptocurrencies, Ethereum is not grandma-friendly. Users can easily accidentally send to wrong addresses, and losing your private key — or having it stolen — results in the loss of all your funds. Generalized Features. Ethereum, by design, “refuses to build even very common high-level use cases as intrinsic parts of the protocol.” Developers need to build and rebuild basic, commonly-needed components. Market Position. An advantage of Ethereum rather than a disadvantage. Ethereum has a head start, with well over 1,000 ICOs, the Ethereum Foundation and Enterprise Ethereum Alliance, billions of dollars in capital, and a crushing market cap dominance.

Today’s challenger is EOS. Let’s see how it stacks up.