Consensus

A breif journey

presented by:

[Hamid Salehian]

What is Consensus

The process by which we reach agreement over system state between unreliable machines connected by asynchronous networks

"We have proposed a system for electronic transaction without relying on trust." ​
Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008

FAILURE MODES

▸ Fail-stop = a node dies
▸ Fail-recover = a node dies and comes back later (Jesus/
Zombie)
▸ Byzantine = a node that misbehaves, or communicates incorrect, or false oral messages in the system

▸ Performance = where the communicated mes-
sage is not delivered at correct destination, or in a timely
manner to intended recipient

▸ Omission  = where the server replies late to client requests.

BYZANTINE GENERAL’S PROBLEM

▸ One of the first impossibility proof in computer communications
▸ Impossible to solve in a perfect manner
▸ Originated from the Two General’s Problem (1975)
▸ Explored in detail in Leslie Lamport, Robert Shostak, Marshall Pease paper: The Byzantine General Problem
(1982)

BYZANTINE FAULT TOLERANCE

▸ Byzantine Fault
▸ Any fault that presents different symptoms to different observers (some general attack, some general retreat)
▸ Byzantine Failure
▸ The loss of a system service reliant on consensus due to Byzantine Fault
▸ Byzantine Fault Tolerance
▸ A system that is resilient/tolerant of a Byzantine Fault

The Byzantine General

• “attack” message is passed on by a messenger visiting each General in turn.
• Any General may be a traitor and in league with the baddies in the Castle.

A provably unsolvable ComSci problem

proof of X

proof of WORK

• Miners (participants of the blockchain) solve hard, useless problems to create blocks.
• PoW runs on a system of “the longest chain wins.”
  • So assuming most miners are working on the same chain, that one will grow fastest will be the longest and most trustworthy.
• ​The difficulty of the problem can be changed in runtime, to ensure the constant block time
• Incentivized by dynamic transaction fees

• hard computer math
  this ain't free.

• Solving/"mining" is basically a guessing game

  Checking guesses for correctness is fast/easy

  speed/power measured as "hashrate"

  "Miners" aren’t able to cheat because it takes real-world resources to check guesses

proof of WORK

- is safe as long as more than 50% of the work being put in by miners is honest

- 51 attack

vulnerability:

used by:

- Bitcoin

- Ethereum

- Litcoin

- Dogecoin

pros:

cons:

- we know it works

- slow throughput

- killing the planet

DELAYED proof of WORK

• once a block has been completed, its hash is added to a Bitcoin transaction signed by 33 of the notary nodes
• creating a record of dPoW block hashes on the Bitcoin blockchain that have been notarized by a majority of the network’s notary nodes

pros:

cons:

- only blockchains using PoW or PoS can be a part of this consensus.

-  it can lead to high differences between the hashrate of notary miners and the normal miners

- under “Notaries Active” mode the hashrate for different nodes  have to be calibrated, otherwise, the difference between the hashrates can explode

vulnerability:

used by:

- Komodo

DELAYED proof of WORK

proof of STAKE

• the blocks aren’t created by miners doing work, but by minters staking their tokens to “bet” on which blocks are valid
• In the case of a fork, minters spend their tokens voting on which fork to support
• Assuming most people vote on the correct fork, validators who voted on the wrong fork would “lose their stake” in the correct one.​

pros:

cons:

- noting at stake

proof of STAKE

- nothing at stake

- You don't lose anything from behaving badly, you lose nothing by signing each and every fork

- long range attack

- draws from the right that users have to withdraw their security deposits

- it means an attacker can build up a fork from an arbitrarily long range without fear of being slashed

- In other words, when more than ⅔ of the validators have unbonded, they could maliciously create a second chain which included the past validator set, which could result in arbitrary alternative transactions.

vulnerability:

used by:

- Decred

- Ethereum (soon)

- Peercoin

used by:

- Cardano

OUROBOROS

• there is no race between stakeholders to produce a block
• Instead, a slot leader is randomly selected, proportionally to the amount of tokens he owns (the stake), to get the opportunity to produce a new block
• To generate a block you have to be online, but asking everyone to be online at every moment is impractical and unrealistic
• Ouroboros does not incentivize stakeholders to invest computational resources to issue blocks. Rather, availability and transaction verification are prefered

DELEGATED proof of STAKE

• token hodlers don’t vote on the validity of the blocks themselves, but vote to elect delegates to do the validation on their behalf
• there are generally between 21–100 elected delegates in a DPoS system
• the delegates are shuffled periodically and given an order to deliver their blocks in
• having few delegates allows them to organize themselves efficiently and create designated time slots for each delegate to publish their block
• if delegates continually miss their blocks or publish invalid transactions, the stakers vote them out and replace them with a better delegate

pros:

cons:

- partially centralized

- nothing

vulnerability:

used by:

- Steemit

- EOS

- BitShares

DELEGATED proof of STAKE

proof of STAKE VELOCITY

• PoSV is designed to encourage both ownership (Stake) and activity (Velocity)
• an alternative to Proof of Work (PoW) and Proof of Stake (PoS)
• store of value and medium of exchange

pros:

cons:

- noting at stake

- nothing at stake

- You don't lose anything from behaving badly, you lose nothing by signing each and every fork

vulnerability:

used by:

- Reddcoin

proof of STAKE VELOCITY

proof of AUTHORITY

• transactions are validated by approved accounts, kind of like the “admins” of the system
• these accounts are the authority that other nodes receive their truth from
• identity must be formally verified on-chain, with a possibility to cross-check the information in a publicly available domain
• eligibility must be difficult to obtain, to make the right to validate the blocks earned and valued.
• there must be complete uniformity in the checks and procedures for establishing an authority

pros:

cons:

- centralized system

- you’re unlikely to see PoA running on a public chain due to its centralized nature

vulnerability:

used by:

- POA.Network

- Ethereum Kovan testnet

proof of AUTHORITY

proof of REPUTATION

• Collaborative consensus
• depends on the reputation of the participants to keep the network secure
• participant (a block signer) must have a reputation important enough that they would face significant financial and brand consequences
• eligibility must be difficult to obtain, to make the right to validate the blocks earned and valued.
• it operates like a Proof of Authority network (PoA), where only authoritative nodes can sign and validate blocks

pros:

cons:

- Only used in private, permissioned blockchains.

- you’re unlikely to see PoA running on a public chain due to its centralized nature

vulnerability:

used by:

- POA.Network

- Ethereum Kovan testnet

proof of REPUTATION

proof of WEIGHT

• broad classification of consensus algorithms based around the Algorand consensus model
• the general idea is that where in PoS, your percentage of tokens owned in the network represents your probability of “discovering” the next block
• some other relatively weighted value is used

pros:

cons:

- Incentivization can be a challenge

- Concrete example: Filecoin’s Proof-of-Spacetime is weighted on how much IPFS data you’re storing. Other systems could include weights for things like Proof-of-Reputation.

vulnerability:

used by:

- Algorand

- Filecoin

- Chia

proof of WEIGHT

proof of BURN

• the miners of the PoB coins will send coins to an unspendable address — otherwise known as an “eater address” — thus taking them forever out of circulation or burning them
• these transactions are recorded on the blockchain, ensuring that there’s a necessary proof that the coins cannot be spent again, and the user who burned the coins is issued a reward
•  the user burning the cryptocurrency is showing long-term commitment to the coin by burning it
•  taking a short-term loss in exchange for a long-term gain
• if a user burns more coins, they’ll have a greater chance of successfully mining the next block

pros:

cons:

-  resource waste in as much as the resources used to generate the burnt coins is wasted.

-  there is also a problem similar to that seen in proof-of-stake consensus, where those who have a lot of coins continue to amass an even greater number of coins. It’s the rich get richer problem.

- high risk protocol, as there is no guarantee that a user will ever recover the full value of the coin being burned

vulnerability:

used by:

- Counterparty (XCP)

- Slimcoin (SLM)

-  Triggers (TRIG)

proof of BURN

proof of BURN

• when a node submits a block to the network, it must provide a valid proof of capacity
• without the corresponding storage size, it is difficult for a node to generate an effective proof of capacity
• Assuming most people vote on the correct fork, validators who voted on the wrong fork would “lose their stake” in the correct one.​

pros:

cons:

- noting at stake

proof of CAPACITY aka proof of SPACE

-  The process of providing a proof is as follows. In the initialization phase, a series of hash data is generated according to the protocol and stored in the storage capacity. When a new block is being generated, data will be searched in the storage capacity based on the value of a randomly generated number. This data will then be used to generate a certificate and participate in the competition to generate the next block. The entire process includes five stages: initialization, block construction, block reception, main chain selection and penalty mechanism.

vulnerability:

used by:

- Burstcoin

- Chia

- SpaceMint

proof of CAPACITY

proof of CAPACITY aka proof of SPACE

proof of ELAPSED TIME

• mechanism is based on spreading the chances of a winning fairly across the largest possible number of network participants.
• Each participating node in the network is required to wait for a randomly chosen time period, and the first one to complete the designated waiting time wins the new block
• The one to wake up first — that is, the one with the shortest wait time — wakes up and commits a new block to the blockchain

pros:

cons:

- Even though it’s cheap, you have to use specialized hardware. Thus cannot be mass-adopted.
- Not suited for public blockchains.

proof of ELAPSED TIME

• The PoET concept was invented during early 2016 by Intel
• It offers a readymade high tech tool to solve the computing problem of “random leader election".
• PoET controls the cost of the consensus process and keeps it nimble so that the cost remains proportional to the value derived from the process

used by:

- HyperLedger Sawtooth

used by:

type:

- Collaborative Consensus

proof of HISTORY

• The basic idea here is that instead of trusting the timestamp on the transaction, you could prove that the transaction occurred sometime before and after an event
• With Proof of History, you can create a historical record that proves that an event has occurred at a specific moment in time
• is a high frequency Verifiable Delay Function
• requires a specific number of sequential steps to evaluate, yet produces a unique output that can be efficiently and publicly verified
• This specific implementation uses a sequential pre-image resistant hash that runs over itself continuously with the previous output used as the next input.
• Periodically the count and the current output are recorded
• For a SHA256 hash function, this process is impossible to parallelize without a brute force attack using 2¹²⁸ cores.

- nothing at stake

vulnerability:

used by:

- Solona

pros:

cons:

- noting at stake

proof of HISTORY

proof of IMPORTANCE

• proof of importance is not proof of stake
• depends not only the number of coins but on the possibility that productive system action ought to be remunerated
• including notoriety (controlled by a different purpose-designed framework), balance, and the number of transactions made to and from that position
• importance calculation
•  

pros:

cons:

- noting at stake

fault tolerance

BYZANTINE

Byzantine Fault Tolerance (BFT)

• If some generals attack without the others, their siege will end in tragedy.
• The generals are usually separated by distance and have to pass messages to communicate.

• The problem is that several Byzantine generals and their respective portions of the Byzantine army and have surrounded a city.
• They must decide in unison whether or not to attack.

practical Byzantine Fault Tolerance (PBFT)

• Nodes in a pBFT enabled distributed system are sequentially ordered with one node being the primary(or the leader node) and others referred to as secondary(or the backup nodes)
• The goal is that all honest nodes help in reaching a consensus regarding the state of the system using the majority rule.
• Can function on the condition that the maximum number of malicious nodes must not be greater than or equal to one-third of all the nodes in the system.
• As the number of nodes increase, the system becomes more secure.
• Number of multicast messages needed in each phase of the three phase protocol multiplied by each replica in our set

practical Byzantine Fault Tolerance (PBFT)

used by:

- Hyperledger Fabric

- Zilliqa – pBFT + PoW
- Tendermint – pBFT + DPoS

pros:

cons:

-  exponentially increasing message count as nodes are added to the set

- centralized

- permissioned

-  does not scale well

- high transaction throughput

- Sybil attacks

vulnerability:

federated Byzantine agreement (FBA)

• every Byzantine general, responsible for their own chain, sorts messages as they come in to establish the truth (like Stellar and Ripple)
• in Ripple: generals (validators) are pre-selected by the Ripple foundation
• in Stellar: anyone can be a validator so you choose which validators to trust.
• As the number of nodes increase, the system becomes more secure.

used by:

- Stellar

- Ripple

pros:

cons:

- incredible throughput

- low transaction cost

- network scalability

- evеrуоnе is fіghtіng to be root chain

- there саn be ѕеvеrаl rооt chains

Stellar Consensus Protocol

• reach consensus without relying on a closed system to accurately record financial transactions
• rovable safety properties that optimize for safety over liveness
• in the event of partition or misbehaving nodes, it halts progress of the network until consensus can be reached

pros:

-decentralized control
- low latency
- flexible trust
- asymptotic security

delegated Byzantine Fault Tolerance (dBFT)

• enables large-scale participation in consensus through proxy voting
• The holder of the NEO token can, by voting
  • pick the bookkeeper it supports.
  • The selected group of bookkeepers, through BFT algorithm, reach a consensus and generate new blocks.
• Voting in the NEO network continues in real time, rather than in accordance with a fixed term.

used by:

- NEO

pros:

cons:

- fast

- scalable

- evеrуоnе is fіghtіng to be root chain

- there саn be ѕеvеrаl rооt chains

PAXOS

RAFT

       further information​

easter eggs

PAXOS

- Lamport’s consensus algorithm [The Part-Time Parliament - Leslie Lamport ACM Transactions on Computer Systems May 1998]

- generally used to implement strongly-consistent replication in distributed systems that run on asynchronous environments

- a protocol for state machine replication in an asynchronous environment that admits crash failures.

used by:

- Apache Cassandra

- Neo4j

- Apache ZooKeeper

- Ceph

pros:

cons:

- difficult to understand

- scaleble

- rubost

- Raft offers a generic way to distribute a state machine across a cluster of computing systems

- ensuring that each node in the cluster agrees upon the same series of state transitions.

Raft achieves consensus via an elected leader. A server in a raft cluster is either a leader or a follower, and can be a candidate in the precise case of an election (leader unavailable). The leader is responsible for log replication to the followers. It regularly informs the followers of its existence by sending a heartbeat message. Each follower has a timeout (typically between 150 and 300 ms) in which it expects the heartbeat from the leader. The timeout is reset on receiving the heartbeat. If no heartbeat is received the follower changes its status to candidate and starts a leader election.

RAFT

used by:

- CouchroachDB

- etcd

- NATS

- IPFS

- Quorum

pros:

cons:

- used in private

- permissioned networks

- Simpler model than Paxos, but offers same safety.
- implementation available in many languages.

RAFT

http://thesecretlivesofdata.com/raft/

RAFT: ONLINE SIMULATOR