Ethereum Watch

This series was titled “Ethereum Competitors,” but that was probably overzealous.

These protocols — EOS, NEO, Cardano, etc. — are often described as “Ethereum Killers,” but numerous platforms can co-exist, as Windows, macOS, and Linux do today. Perhaps the future will see many of these cryptocurrency challengers coexisting as alternatives or as platforms with different strengths and specialties.

DApps might even run on multiple platforms at the same time. Bancor, for example, has announced its plans to run on EOS — the project we’re considering today — in addition to Ethereum.

In any case, I want to know which projects are most likely to dominate the dApp/smart contract platform space.

This article is about

EOS, which bills itself as “the most powerful infrastructure for decentralized applications.”

EOS offers free transactions and high scalability on a Decentralized Proof of Stake (DPoS) system.

I’ve already written about RSK (RootStock), which runs on a Bitcoin sidechain. In future articles, we’ll discuss Cardano, NEO, NEM, Qtum, Ethereum Classic, Lisk, Stratis, Waves, Komodo, and Counterparty.

I’ll review our seven evaluation criteria in a bit — first, we have a couple of concepts to introduce.

Last week, we briefly discussed smart contracts and Turing completeness.

This week, I want to introduce some concepts about consensus, most notably the Byzantine Generals Problem and Delegated Proof of Stake (DPoS). If you know what these are, feel free to skip ahead.

The Byzantine Generals Problem

There’s a lot of discussion these days on tolerating the faults of these poor chaps. Projects abbreviate “Byzantine Fault Tolerance” as BFT and throw it around in exemplars of communicational clarity on Reddit, Twitter, and Bitcointalk:

“TL;DR — TBH, vs. DDoS BFT DPoS (e.g. EOS) beats PoW IMO.”

To understand Byzantine Fault Tolerance, we need to understand a simple problem: the Byzantine Generals Problem.

The Byzantine Generals Problem comes from a 1982 computer paper of the same name. It’s an extension of the Chinese Generals Problem, which involves only two generals. The Byzantine variant works for any number of generals.

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.

Byzantine Fault Tolerance

However they do it, as long as the loyal generals

1. Come to a majority decision and
2. 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:

1. Scalability. Handling all the data Ethereum promises to handle may require millions of transactions per second. It currently handles under 20.
2. Governance. Even if good scalability solutions can be presented, it’s unclear whether they will even be adopted soon.
3. Development Complexity. Ethereum uses its own programming language, and bug fixes and updates cannot be easily implemented.
4. Timeline. Ethereum will likely solve the above issues, but how long will it take for the proposed solutions to be implemented?
5. 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.
6. 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.
7. 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.

Ethereum Challenger #2: EOS

Uses DPoS to offer high speed and scalability. Rapidly growing development ecosystem. Currently in late-stage testnet; mainnet launches June 2018.

Founded by Dan Larimer, creator of the scalable Steemit and BitShares, EOS is growing rapidly as mainnet launch approaches.

EOS’s consensus model is a Delegated Proof of Stake model.

We explained DPoS above, and the potential speed and stability advantages over other consensus systems are considerable. The EOS blockchain reaches 100% finality in about 1 second — much faster than any other decentralized app platform I know of today.

All of this is accomplished with strong asynchronous Byzantine Fault Tolerance (aBFT). In fact, on the EOS network, a malicious attack requires 15 out of 21 of the Block Producers to participate in order to successfully compromise the network.

How does such a fast and final network achieve BFT?

Each Block Producer actually produces six half-second blocks in a row before handing the process off to the next BP. This minimizes orphaned blocks should the latency when handing off to the next BP be greater than expected. 14+ signatures from other BPs are rapidly obtained for each block, enabling block finality (confidence and irreversibility) to be reached within 1 second.

If you’d like to learn more details on how the design pulls this off, check out this explanation from EOS creator and CTO of block.one Dan Larimer:

But DPoS relies on just a relatively small number of nodes to maintain the network. In a movement so focused on decentralization, systems that elect a smaller number of blockchain creators rather than using every node on the network have their critics. “Oligarchy!” they cry. After all, isn’t a system that relies on a small number of Block Producers rule by a few?

What’s with the Block Producers? Are they an oligarchy?

Along with all EOS users, the 121 Block Producers validating transactions are bound by the EOS constitution, which may be amended. A constitution draft has been proposed and is under discussion here. These 121 Block Producers are continuously voted into their roles by EOS token holders, and unsatisfactory performance can result in them being voted out.

How the 121 BPs produce blocks: In each 63-second round, the top 20 Block Producers take turns contributing blocks — 6 half-second blocks at a time — in a randomly-decided order. For each round, they are joined by a 21st Block Producer pseudorandomly selected from the 101 Standby BPs — the BPs who don’t have enough votes to be in the top 20. The amount of votes each Standby BP has increases the probability they will be voted into the 21st spot.

The Block Producers (BPs) are incentivized and obligated to act honestly, and their identities are public. Violators of the EOS constitution are subject to binding arbitration in a decentralized arbitration system, and BPs in violation may be ejected from their role of BP and/or have other penalties imposed.

In addition, unlike some Delegated Proof of Stake systems such as Lisk and ARK, EOS will likely have a constitutional measure that prevents Block Producers from sharing block rewards with the people who vote for them. In other words, they will be banned from buying votes.

If the voters are dissatisfied with a Block Producer’s activities, they will vote for a different BP instead. Current BP candidates have announced significant plans for supporting major EOS development, EOS security, EOS marketing, etc.

Competition for Block Producer spots will not hinge on how much the BPs and candidates pay their constituents. It will hinge on how much BPs and candidates do to improve the EOS ecosystem.

Other constitutional protections may be implemented, as well. For instance, one article draft stipulates that no single entity can own more than 10% of the EOS token supply. With these constitutional measures, EOS aims to implement fair governance, not an oligarchy.

These protections will likely prove crucial. After all, some other consensus models without such protections may be decentralized in theory but more centralized in practice:

EOS code development activity is high.

EOS GitHub activity is strong, as developers get their dApps ready for the MainNet launch. And that’s beyond the main EOS GitHub repository, which is itself one of the most active in history.

Note: GitHub Commits and Github Lines Added are not perfect metrics, since 1) developers can build on private repositories and only push to public repositories at intervals, and 2) trivial GitHub commits can be spammed to make an account appear active. However, a cursory examination of EOS commits reveals substantial features being added.

Many EOS dApps in development are already funded by venture capital, and many of their tokens will be distributed widely via airdrop to EOS token holders rather than via ICO.

This is in keeping with the EOS model dubbed “token ownership as bandwidth.” Holding EOS is sort of like holding property: EOS token holders have the right to use the network — including all of its features — by holding tokens. They can vote for EOS Block Producers and EOS development initiatives to pursue and support. And they ultimately may rent out their bandwidth to developers and other groups that need it.

Alright, enough with the EOS introduction material. Let’s run the platform through our big questions.

1) Scalability.

DPoS enables thousands, even tens of thousands, of transactions per second right now. Asymmetric communication and parallel processing are planned in order to boost this as high as millions of transactions per second.

Block times are fast, at one-half second per block, and yet the network’s design manages strong Byzantine Fault Tolerance. On BFT DPoS, see these explainer videos by block.one CTO Dan Larimer.

2) Governance.

Delegated Proof of Stake, with 121 Block Producers.

The 20 producers with the most votes are active BPs, participating in block production every round. The other 101 BPs are Standby BPs, and from their number a 21st BP is pseudorandomly selected each round.

The EOS constitution governs the activities of all users, including the elected Block Producers (BPs). BPs who act unsatisfactorily can be voted out. BPs who fail to meet the uptime and performance standards necessary to produce blocks consistently are dropped. EOS users, BPs or otherwise, who violate the constitution can be subjected to decentralized arbitration and penalized.

Upgrades and constitutional amendments may be voted in by the Block Producers, but they must have a large majority (15/21) of their votes for an extended time — 60 days, in the case of amendments. During this time, users can vote Block Producers out if their resistance to the upgrades and/or amendments currently in process is sufficiently strong.

3) Development Complexity.

EOS runs on WebAssembly (Wasm), a growing browser-based language which is faster than Javascript and can be compiled from a number of languages, most notably C++. Developers will be able to write in any of a number of languages.

In addition, EOS allows for projects to implement bug fixes and updates more easily. Freezes can even be implemented, if necessary. Any Block Producer abusing this power in any instance can be clearly observed doing so and is subject to being voted out and punished by decentralized arbitration.

4) Timeline.

The EOS mainnet launches in June 2018.

Interestingly enough, while block.one has written the bulk of the code for EOS, they will not be starting it up — the launch is the community’s job. block.one, including Dan Larimer, will move on to supporting and developing dApps for the EOS platform, and the community will fully take over EOS development and governance going forward.

5) Adoptability.

In my opinion, this is one of the areas where EOS really shines. First, it introduces human-readable addresses. Jack Black can grab the name @jackblack or @kungfupo or @stillinthewilderness.

So when your friend asks you for money, you won’t need to enter A92utrYS02isbS0m245lCCl72uXZX9flbDDs2eFFY67B1plww1mxZAQ0. You can just enter @friendsname.

EOS introduces many more user-friendly features than that. How about private key recovery? Countless bitcoins and ether have been lost forever by private keys being misplaced or destroyed. With EOS, you can set a recovery partner who can use their private key to help you recover your private key after your address has shown no activity for a period of time.

Additional theft resistance features can prevent hackers from stealing your funds even if they get your private key. After all, someone grabbing your house key off your desk doesn’t entitle them to everything in your house. Perhaps thieves of private keys controlling large accounts shouldn’t immediately have full ownership of all your funds. EOS includes measures to mathematically mitigate that kind of takeover.

Check out the EOS whitepaper v2 for more user-friendly features.

6) Generalized Features.

EOS provides a large number of generalized features for developers, and some of them — in particular authentication — are managed separately from the execution of dApps in order to improve security and speed.

User identity, authentication, account recovery, upgrade and bug fix functionality, IPFS file storage, and inter-blockchain communication are all examples of generalized features that EOS has made or plans to make available to dApp developers.

7) Market Position.

How does EOS challenge Ethereum’s market share?

EOS has garnered significant publicity through its founder’s former successful projects (BitShares and Steemit), which have continued on their own steam since Larimer left them to their own decentralized governance.

VC investment and participation, including backing by Mike Novogratz and Tomorrow BC, have boosted the publicity of EOS even more, and the EOS ERC20 token has the highest market cap of all the solutions we’re considering — with the exception of Ethereum, of course.

I know we’re considering platforms here, not specific applications looking to run on them, but platforms’ success will ultimately depend on the applications that run on them.

One significant application for EOS is Everipedia, cofounded by Wikipedia’s own Larry Sanger. Read more about this “new Wikipedia” project in Larry’s fascinating 8,000-word essay, or in the much shorter version at Quartz.

A number of Ethereum-based dApps, such as Bancor, have announced plans to migrate to or include EOS. The EOS GitHub and related projects are among the most active GitHub communities in history.

Finally, the EOS ICO has been running for nearly a year now and has used a variety of measures to ensure wide distribution.

Will these advantages be enough for EOS to challenge Ethereum?

I don’t know, of course. But each one — successful track record, VC backing, major applications, unique model, the world’s largest token sale — is an impressive point. Taken as a whole, they are hard to ignore.

Multicoin Capital today released a bullish “EOS Analysis and Valuation” report that includes much more discussion on various EOS and market features than we’ve had time to do here. Check it out if you want more details and analysis on EOS’s plans and prospects.

Yet — and here the Multicoin report agrees — other platforms also aim to hit us with volleys of impressive facts and features, and some will likely have a place in the coming economy even if EOS exceeds its wildest aspirations. Next week we’ll consider Cardano, and then NEO the week following.

Until then, may your life have high fault tolerance.