Consensus Compare: Tendermint BFT vs. EOS dPoS

This technical deep dive is written by Chjango Unchained. Enjoy.

Intro

This article compares the different consensus systems powering EOS and Tendermint about each of their underlying technologies and how they uniquely approach Proof-of-Stake (PoS).

In conventional distributed systems run by a single organization trust is provided by firewalls, infosec teams and hardware roots of trust to ensure that malicious actors can’t undermine the consistency of distributed databases.

Blockchain systems demand a different architecture where trust is distributed among many organizations but we have to tolerate adversarial actors in the system. The design of blockchain systems is a tradeoff between security models, game theory, computer science and institutional reputation.

Bitcoin’s Nakamoto consensus abandons the traditional distributed system guarantees of finality in traditional Byzantine fault-tolerant (BFT) design in exchange for an open admission security model. This comes with costs. If a malicious actor can control 50.1% of the hashpower, the system offers no guarantees at all. At 25%, the game theoretic mechanism starts to destabilize due to selfish mining and probabilistic convergence becomes unstable. Each of these attacks fundamentally change the assumptions needed for light client proofs that enable internet of blockchain approaches to scale.

Cosmos and EOS are studies in further tradeoffs. Cosmos relies on strict guarantees for formal Byzantine fault-tolerance to build both a robust punishment for equivocation and build up a set of guarantees that extend to Internet of Blockchains as a whole. EOS relies mostly on institutional reputation for a kind proforma consensus that sits between Nakamoto consensus and what computer science research indicates is possible. Let’s take a closer look.

Tendermint

“The Tendermint open-source project was born in 2014 to address the speed, scalability, and environmental issues of Bitcoin’s Proof-of-Work consensus algorithm. By using and improving upon proven BFT algorithms developed at MIT in 1988, the Tendermint team was the first to conceptually demonstrate a proof-of-stake cryptocurrency that addresses the nothing-at-stake problem suffered by first-generation proof-of-stake cryptocurrencies such as NXT and BitShares1.0.” — Tendermint

Tendermint Core is a Byzantine fault-tolerant (BFT) consensus engine which is robust against double-spend attacks and is tolerant against a set of up to ⅓ (~33%) Byzantine actors in the network. The Tendermint Application Blockchain Interface (ABCI) platform is a toolkit catering to blockchain application developers. Compatible with any programming language, the toolkit allows higher level development for decentralized applications running just the business logic without lower level tinkering on the consensus layer. Platforms such as Ethermint are built on top of the Tendermint ABCI platform.

Another project built on top of Tendermint ABCI is the Cosmos Network, which is designed to be the “Internet of Blockchains.” Cosmos envisions an interoperable multi-chain network which provides the means for trustless exchange of cryptographic assets across independent blockchains, called zones, through a master hub chain known as the Cosmos Hub. In order to make it as easy as possible for blockchain developers, Cosmos also comes with a toolkit called the Cosmos-SDK, which makes it easy for developers to create custom blockchains using plug-and-play modules.

EOS

EOS markets itself as an operating system intended for enterprise distributed application solutions built for consumers.

Like Ethereum, EOS is a smart contract enabled hosting platform for open-source projects and consumer-facing decentralized applications. Comparing itself to Ethereum, EOS promises a better, more scalable system by trading off decentralization. Its consensus system, called Delegated-Proof-of-Stake, or dPoS, is a consortium blockchain that is validated by a set of master nodes known as ranked delegates. Unlike Ethereum’s virtual machine which acts as a distributed global supercomputer, EOS promises to build a “distributed operating system.”

Key Features At a Glance

The blockchain, as a synchronization mechanism, must solve the problem of the lack of a universal “now.” As such, Tendermint — like all fault-tolerant systems — assumes a partially synchronous network. This is an important distinction from EOS, which is only fault-tolerant within a fully synchronous machine. EOS and Tendermint both run on individual variations of Delegated-Proof-of-Stake. However, each protocol defines “delegate” very differently.

EOS dPoS (democracy-as-proof-of-stake)

EOS defines “delegators” as the democratically elected block validators of the blockchain; the term is used interchangeably with “block validators.” There is a small set of 21 “delegates” who act as the master nodes in the network. The “job” of a delegate is to sign and validate transactions in addition to extending the chain. These delegates are voted into “office” by the stakeholders of EOS tokens. The reason Daniel Larimer chose to appoint just 21 delegates in EOS is because any more would be detrimental to stakeholder attention, thereby causing voters to make poor decisions.

“You require a ⅔ majority to have an honest system. Originally BitShares started with 100. There’s not enough oversight of who those 100 people are because there’s not enough bandwidth of voters’ attention to decide. Bringing it down to 21 reduces the cost of the system. The network has to pay each person that runs a full node.” — Daniel Larimer

Vitalik Buterin describes EOS as a consortium chain that removes “Merkle proofs and any other protections that would allow regular users to audit any part of the system’s execution unless they want to personally run a full node themselves.” This is impractical because relying on users to run full nodes in order to be capable of auditing Byzantine (or simply negligent) delegators without built-in client-side validation mechanisms like Merkle proofs makes coordination problems difficult to resolve.

Without said built-in mechanisms, heavy reliance on extra-protocol means is necessary, and it even becomes a consensus problem. EOS dPoS depends on its stakeholders extrinsically to accurately evaluate delegator performance to make (hopefully) sound decisions about hiring and firing its delegates (it’s a democracy after all). Additionally, significant protocol changes, like in Cosmos, are made through governance.

EOS uses coin voting to achieve decentralization, and the more EOS tokens a stakeholder owns, the greater their voting power. EOS tokens can additionally be used as staking vehicles in lieu of transaction fees for enterprises and businesses to run their decentralized applications (dApps). This alternative fee structure bears additional problems for usability but the context is beyond the scope of this post.

Last Irreversible Block (LIB)

According to Daniel Larimer in his Steemit post, the LIB “is a block which has been confirmed by ⅔ or more of the elected block producers. No node will automatically switch to a fork that isn’t built on top of the LIB.”

An edge case that disrupts liveness where the network grinds to a halt is theoretically possibly with this LIB detail.

Cosmos Consensus

Cosmos also uses a “delegated” Proof-of-Stake consensus mechanism. However, the term “delegate” is used differently in Cosmos’ context. Unlike in EOS, a “validator” is in charge of validating transactions and committing new blocks to the blockchain. Validators participate in the consensus protocol by broadcasting cryptographic signatures which act as votes in order to extend the blockchain. A “delegator” is someone who wants to delegate, as in stake, some token (such as ATOM in the case of the Cosmos Hub) in order to contribute voting power to a validator of their choice so that they may earn a portion of the block reward.

In order to become a validator and have some positive amount of voting power, you must lock up a predetermined number of tokens. This can either be self-funded or voting power can be acquired from other staking token holders by having them “delegate” stake to you. Delegators are putting their staking tokens (ATOMs) at stake with a validator of their choice. They may lose these tokens depending on whether or not the validator behaves as prescribed by the protocol.

During a block validation interval, known as a round, a validator set is defined as the set of validators signing transactions that agree to commit the next block. This validator set is dynamic and changes as validators join or leave the consensus process. A minimum of 4 validators is required but there is no upper limit to the number of validators that a consensus protocol running Tendermint can have. The Cosmos Hub will have 100, but over time this will increase to 300 validators automatically according to a predetermined schedule. This parameter may be changed through governance as well.

Instant Block Finality

Every block is final. Depending on the number of validators, block finality in Tendermint can be achieved in 1 second. Generally, block finality is about 3 seconds.

The Nothing-at-Stake Problem

The nothing-at-stake problem is dreaded in Proof-of-Stake consensus systems because leaving it unsolved allows Byzantine actors to steal within the network at no cost, penalty, or consequence.

Bonded Transactions in Tendermint

Tendermint solves the nothing-at-stake problem by utilizing security deposit-based collateral called “bond deposits.” In order to unlock those bond deposits, users must first unlock them, allowing them to “thaw” during some amount of time, expected to be between two and three months, in what’s called an unbonding period.

This allows all the light clients — the mobile phones and users that are not syncing with the blockchain at a constant rate — to get a heads up about how the validator set is about to change. Without this unbonding period, they are vulnerable to attacks where the blockchain appears to have done something from the previous validator set but in reality that validator set was long gone and they had already sold their tokens.

Collateral in EOS

In EOS, there is no such financial penalty intrinsic to the protocol. Instead, as “collateral,” ranked delegates would lose their reputation in the event they’re found guilty of wrongdoing; hardly a strong financial incentive confronted by a Byzantine actor. DPoS assumes the combination of the opportunity cost of forfeiting the ranked delegate “job” plus the sunk cost of campaigning (to getting elected) are greater than the money gained from performing a double spend attack. Glaringly, a lack of a well-defined in-protocol penalty leaves the EOS network vulnerable, as the nothing-at-stake problem remains unsolved.

Fork Accountability

A fork in Proof-of-Stake protocols is only possible when at least ⅓ of the validators within a validator set in a given state collude. To stymie the risk of malicious forks, some in-protocol protections must be in place.

Tendermint

Fork accountability in Tendermint holds its validators accountable by identifying those who caused a malicious fork in the chain. Those found guilty are slapped with a heavy fine by having their bond deposits destroyed. This amounts to a significant penalty to pay, where ⅓ of all staked coins in the network during a given state are forfeit. In the event of a hard fork, the party responsible for causing it are “slashed.”

Recovering from a hardfork that resulted from ⅓ malicious actors, extra-protocol means are necessary. Stakeholder coordination off-chain allows them to make reorganization proposals, giving them the ability to fork the blockchain when a significant number of validators agree that a minority set of bad actors have co-opted the chain at a certain height.

EOS (TaPos)

EOS handles forks somewhat differently. It utilizes a concept called Transactions-as-Proof-of-Stake, or TaPoS. It requires that every transaction has a corresponding hash of a recent block header. The hash does two things: it prevents replay attacks because a transaction on a fork with a missing hash assumes the fork is counterfeit, and it signals to the network that a particular user and their staked tokens are on a specific chain.

TaPoS unfortunately only accounts for long-range attacks — an attack which the EOS network is able to recover from. Importantly, however, it ignores near-term block finality, which leaves the network vulnerable to partition when, say, not all transactions have been seen. Valid transactions that have not been witnessed by delegates and therefore are without their corresponding hashes would lead to those transactions to become orphaned in this near-term situation.

CAP Theorem

Otherwise called ‘Brewer’s Theorem,’ CAP theorem states the impossibility of simultaneously satisfying more than 2 out of 3 guarantees in a distributed system: consistency, availability, and partition tolerance.

Facing DDoS, Tendermint stops. EOS keeps running but forks and forks, making inconsistent states, which is exploitable by an attacker. Tendermint prioritizes consistency over availability; in EOS, the reverse is true.

In Closing

Since Byzantine fault-tolerance is required to maintain an open, permissionless and decentralized system, it’s mission critical to guarantee the network is censorship-resistant. We want decentralized protocols and their respective blockchains to be secure enough that a state agent cannot manipulate the data, even if they are able to temporarily DDoS it. If state agents (or malicious actors in general) decide to prohibit access to those open systems, we want reliable security, not hand-wavy technology.

The claim that no one has hacked a live network yet is far from saying that it is hack-proof. This is why there is such emphasis on employing mathematical proofs to verify that a network is secure when it is claimed to be secure. Given the amount of capital flowing into each of the top-ranked-by-market-cap cryptocurrencies, dedicated attackers are sure to sniff out and exploit vulnerabilities in the edge cases. In light of this, even a 0.0001% edge case in dPoS (Democracy-as-Proof-of-Stake) means it is not hack-proof.

We had Tendermint Core audited through Jepsen.io, a distributed systems security analysis tool, and the results objectively verify that Tendermint BFT does not violate its stated guarantees: https://jepsen.io/analyses/tendermint-0-10-2.

Finally, as researchers building the protocols moving the Web 3.0 space upward and forward, we acknowledge some weaknesses of current approaches to Proof-of-Stake.

Pitfalls of Proof-of-Stake:

• Voter apathy: Reliance on coin voting makes it a consensus problem. Historically, decentralized institutions employing manual voting mechanisms for governance all have had <10% participation. [See: the DAO carbonvote, the EIP186 carbonvote, the DAO proposal votes, and Bitshares dPoS votes in 2014.]
• Bias toward voting centralization: Buterin attributes the breakdown of the game theory due to the tragedy of the commons. “Because each voter only has a tiny chance of influencing the result, their incentive to vote correctly is thousands of times lower than the socially optimal incentive. This means that situations like everyone putting their coins on exchanges and exchanges voting on users’ behalf, with users not really caring how exchanges vote with their money, are likely to happen.”
• Incentive misalignment: Coin holders and users of a network are two different categories of people. Coin holders are incentivized to drive up coin prices, and oftentimes, those high stakers can cause unstable price growth without necessarily driving robust utility in the system for its users.

Updated on 9/30 with a newer introduction by Zaki Manian.

Thanks to Tendermint researchers Sunny Aggarwal, Adrian Brink & Ethan Frey for the technical review.

Social Channels

• Telegram: t.me/CosmosProject
• Reddit: reddit.com/r/CosmosNetwork
• YouTube: youtu.be/CosmosNetwork
• Twitter: twitter.com/cosmos
• Discord: forum.cosmos.network
• Riot: riot.cosmos.network