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: