Each month at least one new consensus (consensus protocols) is being introduced to community. There are a lot of reviews and analyses, but all of them do use not one methodology. It is difficult to compare consensuses without structured approach. I am proposing my vision (and of course comparison) how to analyze different consensuses.
I have tried to combine the most important aspects. Of course this list could be extended, but will cause difficulty in information perception.
- What is kind of protocol?
- What is maturity of protocol?
- Who should produce the next block of updates to apply to the database?
- When should the next block be produced?
- What transactions should be included in the block?
- How are changes to the protocol applied?
- How should competing transaction histories be resolved?
- How should blockchain forks be resolved?
- Are smart contracts supported?
- How is side-chains inter-operating implemented?
- How is performance changing on growing number of nodes?
- What is limit of nodes in consensus?
- What is block producing interval?
- What is period of irreversibility (99.99%, 10% Adversary)?
- How much is transaction fee?
- Nothing-at-Stake
- incentives for nodes to vote on the correct block
- Failure
- ability to reach consensus
- Sybil attacks
- a single adversary is controlling multiple nodes on a network
| Criteria | Cardano | Casper FFG | Toda | Algorand |
|---|---|---|---|---|
| What is kind of protocol? | Delegation scheme on top of PoS | PoS overlay on top of PoW (Ethereum) | PoAW (Proof of Actual Work) | Scaling Byzantine Agreements |
| What is maturity of protocol? | Proposal | R&D | Expected to be released | Recommendations, Peer reviewed |
| Who should produce the next block of updates to apply to the database? | - Protocol relies on the assumption that nodes in the system have access to the current time - Cardano SL uses Follow the Satoshi (FTS) algorithm to choose slot leaders (shared seed using XOR) -- COMMITMENTS, OPENINGS, SHARES SENDING: time of sending is randomized within a small interval - A number of shares for each stakeholder proportional to their stake. - The same stakeholder can be chosen as a leader for multiple slots within an epoch - Stake Delegation - delegation-by-proxy, heavyweight (in chain, stake threshold) and lightweight |
- Casper’s logic lives inside an Ethereum smart contract - To become a validator in Casper, one must hold ether (ETH) and deposit some ETH to be leveraged as stake into the Casper smart contract - The "size“ of a validator in the active validator pool refers to the amount of ether that they deposited - The block proposal mechanism - Nakamoto PoW (miners create the blocks) -- In order to finalize blocks Casper’s PoS overlay takes control and has its validators vote on blocks trailing the PoW miners |
- The Merkle root of last block is used as a beacon in existing block to generate pseudo-randomness that is deterministic and universal - Utilizing the beacon in a function to pseudorandomly select the Machines/managers of those TodaNotes (Group A) along with the Merkle root prior (Group B). Total of 64 managers (Group A + Group B) can work on building the Merkle proof - If a manager from Group A does not have Merkle proof in subsequent block when it moves to Group B |
- Loosely synchronized clocks across all users - Each step begins with cryptographic sortition (verifiable random functions (VRFs)), where all users check whether they have been selected as members in that step (unforgeable proof that she has been selected) - Every user selected for block proposal also computes a proposed seed for next round - A user is randomly selected, according to her total amount of money in the system, to propose a block - A small committee of users, the verifiers, are similarly selected, and reach Byzantine Agreement on the block proposed by the first user |
| When should the next block be produced? | - The Ouroboros protocol divides the physical time into epochs, and each epoch is divided into slots - Block should be produced within slot by slot leader - One or more slots can remain empty (without generated blocks - The majority of blocks (at least 50% + 1) must be (there is no control) generated during an epoch |
- The purpose of the consensus process is to "finalize" key blocks called "checkpoints“ - Every 100th block is a checkpoint - There are epochs of some specified length (currently, 50 blocks) during which validators "vote" on the chain that they believe to be the canonical one -- When two consecutive epochs achieve >2/3 votes-by-weight, the first epoch of these epochs is "finalized" - ⅔ Vote Block_1 → Justify Block_1 → ⅔ Vote Block_2 → Finalize Block_1 (Block_2 is direct child of Block_1) |
- Race of producers and verifiers - The first to deliver to the new TodaNote owner the Merkle proof |
- Two phases: -- Block proposals are prioritized based on the proposing user’s priority, and users wait for a certain amount of time to receive the block -- Committee members then broadcast a message which includes their proof of selection and vote - Steps are not synchronized across users; each user checks for selection as soon as he observes the previous step had ended - Gossips two kinds of messages: one contains just the priorities and proofs of the chosen block proposers (about 200 Bytes), and the other contains the entire block, which also includes the proposer’s sortition hash, and proof. |
| What transactions should be included in the block? | - Verified transactions -- All unspent outputs called utxo, and this is a part of the special key-value database called Global State - node verify inputs agains it. -- Legitime transactions have proof (witness). Two corresponding versions of the witness: based on public key and based on script. -- Transactions and proofs are stored in two separate places in a block - "segregated witness" |
- Ethereum rules - Based on transaction fee and gas limit - deciding by miner |
- Testified transactions -- the check for authenticity of ownership proofs -- signatures - Given that transaction must be a minimum of 17 TodaNote - No defined what exactly transactions |
- Each user collects a block of pending transactions that they hear about, in case they are chosen to propose the next block - Sequence of transaction not defined (as received) |
| How are changes to the protocol applied? | - On-chain voting and on-chain result fixing (of protocol updates) - There is no central entity responsible for maintaining or distributing updates, any such update is proposed under implicit or explicit agreement -- Explicit agreement: it has positive votes from majority of total stake -- Implicit agreement: it has positive votes from more stake than negative votes and it has been in blockchain for at least U slots. - The software updates is done automatically (Bittorrent-like solution to distribute updates), and updates are announced directly via the blockchain - Single official client at the begging, but a different client developed later |
- Allows validators to pick their fault tolerance (built in client) thresholds while the network maintains the low overhead of Proof-of-Work. - The Ethereum Improvement Proposal -- More strict modified fork-choice rule should be followed by all users, validators, and even the underlying block proposal mechanism |
- NOT DEFINED | - NOT DEFINED |
| How should competing transaction histories be resolved? | - Time sequence (not directly explained) | - Ethereum rules - Valid transactions can be moved from uncle to the next block |
- NOT DEFINED | - NO DEFINED - All decisions are through BA⋆ on proposed block -- reduces the problem to two options -- reaches agreement on proposed block, or agreeing on an empty block. |
| How should blockchain forks be resolved? | - Genesis blocks are generated by each node internally (independently) between epochs – not stored - Each other node (not slot leader) accept only one of concurrent blocks - Takes the longest chain as a main |
- Once a block is finalized "one can never go back“ -- even if 99% of miners start supporting it - Rollback to checkpoint in case of for - There are "slashing conditions" in smart contract -- If two incompatible blocks are finalized - validators did this are been sent into the Casper contract (block with evidence mined) -- The validator's entire deposit will be destroyed (except 4%, which is given to the evidence submitter as a "finder's fee") -- At least ⅓ of the total security deposits staked will be slashed |
- NO FORKS | - Periodically (once an hour) proposes a fork that all users should agree on - Uses BA⋆ to reach consensus on whether all users should, indeed, switch to this fork |
| Are smart contracts supported? | - Simple P2SH only (like in Bitcoin) - Cardano Computation Layer (CCL) (K-framework – reengineering of Ethereum) - NOT IMPLEMENTED |
- Native Ethereum Smart Contracts | - NO | - NO |
| How is side-chains inter-operating implemented? | - proofs of proofs of work (KMZ sidechains) -- sublinear complexity in the blockchain length -- "lite" SPV with overhead info in block (bitcoin) -- proof for “lite” SPV - last K blocks and chain from pointers of M length to the genesis block - NOT IMPLEMENTED |
- NOT SUPPORTED | - NOT DEFINED - All in one Todatree |
- NOT DEFINED |
| How is performance changing on growing number of nodes? | - Sidechains & Shards approach - NOT IMPLEMENTED (planned by end of 2018) |
- NOT DECLARED | - Complexity O(log n), n - number of TreeNotes | - Constant: 20sec for block for 50K users; 80 sec for block for 500K users - Experimentally proofed: 125× the transaction throughput by size of Bitcoin (500 tx/sec) |
| What is limit of nodes in consensus? | - Initial setup of 7 nodes with Cardano SL - NOT VERIFIED |
- Promised to support more than 100 validators - NOT VERIFIED |
- Defined to 64. - Need about 3% of the network if there are no transactions and need over 50% if there are transaction |
- Set to 26 of proposal team, and 10000 for final committee. |
| What is block producing interval? | - 20 sec (slot duration), 12 hours for epoch - not stable yet | - 3 min (3 miners, 4 validators - testnet) | - Merkle Tree is generated every T seconds (initially 30 seconds) - Adjusted dynamically every X blocks |
- A new block is generated essentially as fast as it can be propagated through the network -- 1 Mb block in ∼22 sec for 50K users -- 1 Mb block in ~80 sec for 500K users -- 10 Mb block in ~50 sec for 50K users |
| What is period of irreversibility (99.99%, 10% Adversary)? | - 5 minutes | - 100 blocks (5 hours in testnet) | - Average time for capability to re-spend is less than 2T - It must wait for the block to conclude and stamp transaction with Merkle root and retain Merkle proof for use in subsequent transaction |
- Rely on a new block as soon as it appears, and all transactions contained in it are final - Required 1000 committees |
| How much is transaction fee? | - Minimum transaction cost: 0.155381 ADA 0.155381 ADA + 0.000043946 (ADA/Byte) x Tx size - A portion of every block reward (25%) is placed into a treasury - Nodes are paid once block created |
- NOT DECLARED - Validators are paid once a checkpoint is finalized. |
- One coin in proportion of payer 0.03%, payee 0.03% and new issuance of TodaNotes 0.04% | - NOT DEFINED |
| Nothing-at-Stake resistance | - Initial Endorsers and Incentive Structure are NOT DESCRIBED - Presume honest majority of stakeholders online - Identified trusted block producers - Operating with the longest chain - Should produce to have reward |
- Validators should vote to have reward - Validators are not just punished for double-voting but are penalized for voting on the incorrect fork |
- Economic - deliver Merkle root first - Every Machine when delivering the merkle proof can not win the 0.1% if it doesn’t have the previous one (therefore was online) and if it didn’t pass the entire data it received to Group B |
- Algorand is guaranteed to work securely if the majority of the money in the system is owned by honest users. - FOR FUTURE WORK |
| Failure resistance | - Only one block created and proposed per slot by only one node - No need to agree on block and transactions in it |
- The blockchain would grow every block with the familiar ethash PoW algorithm - Every 50 blocks is a PoS “checkpoint” where finality is assessed via a network of validators |
- NOT DEFINED | - If the adversary is the highest priority proposer in a round, they can propose the empty block, and thus prevent any real transactions from being confirmed. This happens with probability of at most 1−h, by Algorand’s assumption that at least h > 2/3 of the weighted user are honest - Stuck (honest users are split into two groups) - to resolve use random “common coin,” meaning a binary value that is predominantly the same for all users (every user sets the common coin to be the least significant bit of the lowest hash it observed in this step) |
| Sybil attacks resistance | - Economic defense against attack - Have stake greater than threshold - There is no penalty for misbehavior |
- Economic defense against attack - Validators are incentivized to converge on a canonical chain because they are penalized more over time as validators continue to vote on two divergent chains |
- Proof of Actual Work is the distributed computing needed to run the system with replication of 32x | - FOR FUTURE WORK |