# README ## Blockchain Consensus Encyclopedia ### More than 84 Blockchain Consensus described. ![Consensus by Nick Youngson CC BY-SA 3.0 ImageCreator](/files/-LLoN7IjDbSP8oBsi4kp) By and Visit the book at ### Donations * Ethereum [0xC23473B911e86dc614412b3341d1C206aBac6996](https://etherscan.io/address/0xC23473B911e86dc614412b3341d1C206aBac6996#) * Bitcoin [3ERPPUFLLjmRAookiCTN7rqKkQjDwS8YPe](https://www.blocktrail.com/BTC/address/3ERPPUFLLjmRAookiCTN7rqKkQjDwS8YPe) # Blockchain Consensus Encyclopedia Infographic ![Infographic 4528 x 2894 px, 2.5MB ](/files/-L_i_KAsL6qzKH4BNQe5) {% file src="/files/-L\_i\_PrHd-A9vJofHt2F" %} Same infographic as above but as PDF with links {% endfile %} # CONTRIBUTING ## Thanks you in advance for contributing! To add new content: * Make sure it doesn't already exist. * Most of the consensus are created and developed by projects themselves, and require to copy or explain some part of their White-paper. But there is no copyright infringement intended from my side. Just a try to list all consensus algorithms. * Link to PDF is required. Open knowledge is mandatory. Papers where the PDF is not publicly and openly available for free will not be accepted. * Don't add deck of slides, or document lacking an abstract, not a blog post, not a bitcoin forum post. * Conference or journal and year must be stated if available. Please stay on topic! You can open PR on Github ### Contact You can contact me using Twitter [@CedricWalter](https://twitter.com/CedricWalter?lang=en) or [@TokensEconomy](https://twitter.com/tokenseconomy) # Introduction ![Consensus by Nick Youngson CC BY-SA 3.0 ImageCreator](/files/-LLoN7IjDbSP8oBsi4kp) ### CÉDRIC WALTER [LinkedIn](https://www.linkedin.com/in/cedricwalter/) / [Twitter](http://www.twitter.com/cedricwalter) 16 years java Full-Stack and now Blockchain Software Engineer working in the heart of the [CryptoValley](https://cryptovalley.swiss/) Zug in a Blockchain Team. His interests include AI and promoting test driven development and agile methods to deliver clean code that works. Cédric worked with many different Insurances companies across Switzerland on billion premium volume online applications, and love to sparks its creativity in many different and challenging open sources projects. He believes strongly that the future of work is unbundled; the future of knowledge work will be driven by decentralization, community, and emergent collaboration. [tokens-economy.com](https://www.tokens-economy.com/) is a blog / digital playground where Cédric keep track of new developments in the distributed ledger technology space and present all his experimentation and tools. # Blockchain Consensus? At the core of the Blockchain disruption are consensus algorithm: > Consensus algorithms enable network participants to agree on the contents of a blockchain in a distributed and trust-less manner. > > “Consensus decision-making is a group decision-making process in which group members develop, and agree to support a decision in the best interest of the whole. Consensus may be defined professionally as an acceptable resolution, one that can be supported, even if not the “favourite” of each individual. Consensus is defined by Merriam-Webster as, first, general agreement, and second, group solidarity of belief or sentiment.” Wikipedia And the consensus algorithm plays a crucial role in maintaining the safety and efficiency of blockchain. Using the right algorithm may bring a significant increase to the performance of blockchain application. The trilemma claims that blockchain systems can only at most have two of the following three properties: 1. Decentralization (defined as the system being able to run in a scenario where each participant only has access to O(c) resources, i.e. a regular laptop or small VPS) 2. Scalability (defined as being able to process O(n) > O(c) transactions) 3. Security (defined as being secure against attackers with up to O(n) resources) Each consensus algorithm has its own application scenario. There is no absolute good or bad. The choice of which consensus to use for implementing the blockchain depends on the type of network and data. For a transaction to be valid on most cryptocurrency networks, the transaction needs to collect a certain number of confirmations (often equals to an inclusion in a block of a blockchain) from the network. E.g 10 confirmations means to see a specific transaction in one block and 9 consecutive blocks. # Glossary ### Adversary model The fraction of malicious or faulty nodes that the consensus protocol can tolerate (i.e., it will operate correctly despite the presence of such nodes). ### Code available Whether the code implementing the system is publicly available. ### Committee How the participants work together to participate in the consensus protocol; either they all work together (single committee), or they are divided in multiple subgroups (multiple committees). ### Committee Formation How the members of the committee are chosen, for example via proof-of-work, proof-of stake, trusted hardware etc. ### Consistency The likelihood that the system will reach consensus on a proposed value; it can be either strong or weak. ### DoS resistance Resilience of the node(s) involved in consensus to denial-of-service (DoS) attacks. If the participants of the consensus protocol are known in advance, an adversary may launch a DoS attack against them. ### Incentives The mechanisms that keep nodes motivated to participate in the system and follow its rules. • Inter-committee Configuration: How the members are assigned to the committee in a single committee setting; either members serve on the committee permanently (static), or they are changed at regular intervals (rolling, or full swap). ### Latency The time it takes from when a transaction is proposed until consensus has been reached on it. ### Leader The leader of the consensus protocol, which can be either elected among the current committee (internally), externally, or flexibly (e.g., through arbitrary smart contracts). ### Participants The nodes that participate in the consensus protocol. ### Permissioned blockchain Only participants selected by the appropriate authorities can participate in the consensus protocol. ### Permissionless blockchain Anyone can join the system and participate in the consensus protocol. ### Scalability The system’s ability to achieve greater throughput when consensus involves a larger number of nodes. ### Sharding Sharding aims to split (shard) state information across nodes, without requiring any node to have a full picture of the network. Therefore no validator will validate all shards. ### Throughput The maximum rate at which transactions can be agreed upon by the consensus protocol (transactions per second/hour). ### Transaction censorship resistance The system’s resilience to proposed transactions being suppressed (i.e., censored) by malicious node(s) involved in consensus. ### Zero Knowledge Proofs A Zero Knowledge Proof (ZKP) is a method by which one party (the prover) can prove to another party (the verifier) that she knows a value X, without revealing the value itself. # Categorizing consensus We propose the following consensus categories * Proof of Work * Chain-based Proof of Stake (includes LPoS, Proof of Importance) * PBFT and BFT-based Proof of Stake (includes DPoS, Ouroboros, Byteball, and PBFT) * Hybrid models: Proof of Activity and hybrid PoW/PoS * Proof of Burn (shares some characteristics with chain-based Proof of Stake) * Proof of Capacity/Space (shares some characteristics with PoW but also suffers from a \[lighter] Nothing-at-stake problem) * Trusted computing algorithms (e.g. PoET) * DAGs are mostly using a DPoS-like algorithm, (except IOTA, which uses PoW) # Chain-based Proof of Work # Proof of Work (PoW) PoW was originally invented as a means to combat spam (see [hashcash](https://en.wikipedia.org/wiki/Hashcash))if you make it computationally expensive to send email then spamming would be cost prohibitive while still being almost free for a normal user to send email. Bitcoin, which made the blockchain technology popular, developed the so-called Proof of Work (PoW) algorithm. In principle, each participant on the Bitcoin network can participate in the block generation. In order to confirm the transaction and enter a block into the blockchain, a miner has to provide an answer, or a proof, to a specific challenge. Miners use PoW to validate transactions and mining new coins, but its main goal is to block potential cyber-attacks or suspicious activities within the network. #### Miners In cryptocurrency networks, “miners” are special nodes that perform the PoW calculation on a set of transactions plus the hash of the previous block to generate the next block in the blockchain. Since the block contains the hash of the previous block, changing a historical block would require regenerating all of the subsequent blocks. Regenerating all the hashes would be computationally intensive and would require a lot of energy – and energy isn’t free. It would also be time consuming. The process of proving work and generating blocks is called ”mining”. Miners are rewarded for this work with newly minted coins adding to the total supply. **Nodes** Nakamoto consensus to determine the next head block; that is, at its core: "Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one." #### algorithm 1. Transactions are bundled together in form of blocks. 2. Miners verify the transactions within the blocks as legitimate. 3. Miners then solve a mathematical problem known as the proof-of-work problem. 4. A reward is then given to the first person to solve the problem. 5. Verified transactions are stored in the public blockchain. #### attacks * With a PoW coin the miners don't need to own an investment in the coin that they are attacking, so there might be an incentive for them to run a 51% attack. #### Pros * Oldest and safest * Transaction fees not mandatory * Easy to verify solutions * Hard to find solutions * Difficulty of finding solutions can be precisely quantified * Provably inseparable from the block it secures #### Cons * Poor performance * PoW uses an enormous amount of computing power, which, in itself lowers incentive * It is also vulnerable to attack, as a potential attacker would only need to have 51% of the mining resources (hashrate) to control a network, although this is not easy to do. * Reducing block rewards * Proof of Work restricts the inputs to the structure of given blockchains mining algorithm. In Bitcoin’s case this would have to be a nonce, and in Ethereum’s case the input must be a random integer, a nonce, and a seed hash of the block. **Read more** * * "Proof-of-work": [Pricing via processing or combatting junk mail](https://web.cs.dal.ca/~abrodsky/7301/readings/DwNa93.pdf). Dwork C, Naor M. '92. * [Hashcash - A Denial of Service Counter-Measure](http://www.hashcash.org/papers/hashcash.pdf). Back A. '02. * [Cuckoo Cycle: a memory bound graph-theoretic proof-of-work](http://fc15.ifca.ai/preproceedings/bitcoin/paper_12.pdf). Tromp J. FC '15. * [PieceWork: Generalized Outsourcing Control for Proofs of Work](http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final24.pdf). Daian P, Eyal I, Juels A, Sirer EG. FC '17. * [Permacoin: Repurposing bitcoin work for data preservation](http://ieeexplore.ieee.org/iel7/6954656/6956545/06956582.pdf). Miller A, Juels A, Shi E, Parno B, Katz J. Permacoin. S\&P '14. # Proof of Meaningful Work (PoMW) While the basic idea, to protect the Blockchain by proving that a certain amount of computation was invested to create every single block, is worth being preserved, the current implementation, using purely artificial computational tasks (hashing), with the sole goal of burning “enough” energy, is much too wasteful to be used productively1 and scales very badly. Proof of Meaningful Work keep the good idea, but implement it using meaningful computation tasks, so that the energy invested in the proof of the miners’ computational strength is used for calculations that support public scientific research projects (e.g. medical research for cures, chemical research, astrophysical simulations). Here below combined with PoS so the ratio of PoS to PoMW can be adjusted continuously according to the momentary load situation. ![ProofOfMeaningfulWorkWithPoS.png](https://raw.githubusercontent.com/cedricwalter/blockchain-consensus/master/images/ProofOfMeaningfulWorkWithPoS.png) ## Pros * Decrease wasted energy. The needed energy will be used for socially responsible projects in the fields of healthcare, science, ecological protection and more. ## Cons * attack of more than 50% of the total computing power ## Read more * [Vrenelium](https://github.com/cedricwalter/blockchain-consensus/tree/8ffd7692a60ac9707f399aec3f04b150169c6c8d/www.vrenelium.ch) # Hybrid Proof of Work (HPoW) HPoW still uses PoW but modifies it so it isn’t profitable and, as a result, creates an entire cryptocurrency network that can run on energy efficient, easy to set-up, low-cost computers or cloud services. HPoW removes the profit incentive for miners because the mining reward is so low. In fact, mining farms would actually lose money if they tried to mine Lynx, meaning they will leave Lynx to the individuals who want to solve the sustainability problem. This takes control away from mining farms and pools and puts it squarely into the hands of individuals (solo miners) who want to build upon and use Lynx. HPoW supports network maintenance by incentivizing and empowering those who want to use Lynx. With every new solo miner that connects, the network becomes more secure by reducing the risks associated with a centralized and hierarchical cryptocurrency network. This security is achieved through redundancy: the more individual nodes on the network, the stronger the network becomes. If an individual node or miner fails, or if an entire region of nodes fail due to widespread power outages or war, the network is still secure because mining rigs are plentiful. Taken together, the three business rules result in “Hybrid Proof of Work” (HPoW) 1. A single miner can’t win a block more than once every 30 minutes. 2. The miner’s reward address balance must be greater than or equal to a required fluctuating minimum amount of Lynx to win a block. 3. By using random selection, the fastest miners are not always guaranteed to win the block reward. ## Used in [Lynx](https://getlynx.io/) ## Pros * mining unprofitable ## Cons ## Read more # Proof of Work time (PoWT) Proof-of-Work-Time (PoWT) is a novel approach to forming a consensus by introducing a variable blocktime that scales with mining power, where the blockchain speeds up with power increases. This better scales the blockchain, increases transaction speed with power and allows for auto-adjusting more profitable mining. Difficulty dependent blocktime (Max \~6.2 minutes, minimum 15 seconds). Blocktime dependent rewards (\~Reward halving every minute decrease in blocktime till 10x VRC supply parity, then variable \~3% disinflation). Algo: scrypt² (N of 1024² or 128MB per thread) Block 1: 564,705 VRM minted for ICO participants who purchased VRM using VRC. Minimum Transaction Fee: 0.2 VRM (high commodity transaction fee paid to miners). RPC Port: 33987, P2Port: 36988 Confirmations: 30, Maturity: 100. #### Used in * Vericoin * Verium #### Read more * [whitepaper](https://wiki.vericoin.info) # Delayed Proof of Work (dPoW) Delayed Proof of Work (dPoW) is a hybrid consensus method that allows one blockchain to take advantage of the security provided through the hashing power of a secondary blockchain. This is achieved through a group of notary nodes that add data from the first blockchain onto the second, which would then require both blockchains to be compromised to undermine the security of the first. Delayed Proof of Work (dPoW) is a hybrid consensus method that allows one blockchain to take advantage of the security provided through the hashing power of a secondary blockchain. This is achieved through a group of notary nodes that add data from the first blockchain onto the second, which would then require both blockchains to be compromised to undermine the security of the first. The first to make use of this consensus method is Komodo, which is attached to the Bitcoin blockchain. #### Used in * [Komodo](https://komodoplatform.com) end-to-end blockchain solutions. DPoW consensus mechanism does not recognize The Longest Chain Rule to resolve a conflict in the network, instead the dPoW looks to backups it inserted previously into the chosen PoW blockchain. The process of inserting backups of Komodo transactions into a secure PoW is “notarization.” Notarisation is performed by the elected notary nodes. Roughly every ten minutes, the notary nodes perform a special block hash mined on the Komodo blockchain and take note of the overall Komodo blockchain “height”. The notary nodes process this specifc block so that their signatures are cryptographically included within the content of the notarized data. There are sixty-four “notary nodes” elected by a stake-weighted vote, where ownership of KMD represents stake in the election. They are a special type of blockchain miner, having certain features in their underlying code that enable them to maintain an effective and cost-efcient blockchain and they periodically receives the privilege to mine a block on “easy difculty.” [Whitepaper](https://komodoplatform.com/en/whitepaper/2018-02-14-Komodo-White-Paper-Full.pdf) #### pros * Energy efficient * Increased security **Cons** * Limited to blockchain using PoW or PoS # Proof of Edit Distance ## Algorithm Edit distances are a class of algorithms that score how close two strings are to each other. For instance the *an Edit Distance* for “ETH” and “ETC” is “0.8222” where two identical strings would score a “1”. There are many algorithms also in the string similarity space including the *Levenshtein Distance*, *Smith-Waterman Gotoh* *Distance,* and the *Ratcliff-Obershelp Distance.* ### Using Proof of Edit distance for forging new blocks Miners compete to find a string that when hashed in a normalization process is above a minimum distance threshold. This string could then be the hash of an intermediary-blockchain and the header hash for the next block. Let Minimum Distance Threshold by “t”, String to find “B”, and Edit Distance Function “ED”. Such that for each blockchain header hash “h” satisfies: > ED( H(h), H(B) ) < t Or in the case of merging two blockchains: > ED(H(h1),H(B)) < t && ED(H(h2),H(B)) < t === true To find the new block in an intermediary-blockchain, the miner would iterate through a random charset or number, hashing strings until it finds a hash that is above the threshold for all of the blocks. ## Pros **Proof of Edit Distance is mining algorithm agnostic.** Any hash or string structure can be provided as an input which means that as long as the blockchain has unique hashes it can be easily added to the Proof of Edit challenge. ## Cons ## Used in * [Block Collider](https://www.blockcollider.org/) ## Links * [Block collider whitepaper](https://s3.amazonaws.com/blockcollider/blockcollider_wp.pdf) * [Medium](https://blog.blockcollider.org/building-a-blockchain-singularity-with-proof-of-edit-distance-1d60c328de7a) # ePoW: equitable chance and energy-saving. PoW based on equitable chance and energy-saving. Hdac uses ePoW as a consensus algorithm for creating new blocks and connecting them to the blockchain. ePoW refers to “PoW based on equitable chance and energy-saving.” The Hdac algorithm considers these two as its basic philosophy. The ePoW consensus algorithm can reduce the number of nodes participating in PoW and motivates the participation of multiple mining nodes. As a result, we intend to prevent energy waste due to excessive hashing power for mining competition and distribute equitable mining opportunities.
![Image Credit – HDAC Whitepaper - ePoW consensus algorithm](/files/-LXEwNn1yEkhyYunEvbr) Hdac ePoW is a consensus algorithm that reduces the mining monopoly by applying the block window concept. It reduces the wasteful energy consumed in the hash calculation by avoiding spontaneous mining attempts during the block window application period once the mining is successful. If a node succeeds in mining, no new block can be mined during the block window application period. Even if a greedy node neglects this mechanism and succeeds in mining a new block, it will not be recognized as a valid block in the entire Hdac blockchain network, thus eliminating the need to try to find an invalid block. The block hash must satisfy the data specification according to the degree of difficulty and should not be within a given block window (time spacing). This block window size can be expressed in the form of a time function, Ws = f(t). “F(t)” is a function that increases in proportion to time, and therefore the window size gradually increases with time. This means that there is a great opportunity for early participants, and over time, it becomes increasingly difficult for certain mining nodes to monopolize mining and more equitable distribution can be achieved. ![Image Credit – HDAC Whitepaper ](/files/-LXEwa75rHvtiieIcuUB) The ePoW block window is a system that gives certain constraints on mining attempts after succeeding in mining in a certain PoW cycle. The block window size (Ws) is defined as, f(t) = \[(N\*0.7) x (cumulative number of blocks currently (t))] / (cumulative block number for 10 years (tm)), and the node factor (N) is calculated from the list of recent successful mining nodes. The reason for the arrival time of the maximum block window size (Wm) being 10 years is because it is set to reach the point of more than 80% of the total block generation by that time. ### Pros * Reduce the number of nodes participating in PoW, * Motivates the participation of multiple mining nodes which get equitable mining opportunities, ### Used in * HDAC * HDAC WhitePaper # Semi-Synchronous Proof of Work (SSPoW) from Purple Whitepaper: > The consensus algorithm of Purple is called Semi-Synchronous Proof of Work, or SSPoW for short. It is a variation of Satoshi’s original Proof of Work model of consensus\[2]. It’s design is to remove the bottleneck that the Proof of Work algorithm imposes on the transaction throughput of the network. This is done by decoupling the choosing of validator nodes, which is done via Proof of Work from the actual transaction validation process. When a node finds a valid Proof of Work, it is advanced into the validator pool where it has an allocated period in which it can validate transactions. This is done asynchronously while > > the choice of validator nodes (PoW) is synchronous. In this way, the consensus mechanism becomes semi- synchronous, greatly increasing the throughput of the network while providing a safety control mechanism > > which can be adjusted based on the current network conditions. The algorithm works by establishing a byzantine partial causal ordering on the network events that are sent between the validator nodes and by transforming it into a total order which is assured to be consistent as long as less than a third of the validators are either byzantine or unresponsive. However, the Total Ordering Algorithms assume that the communication medium between the nodes is reliable so it falls on the CA side of the CAP spectrum. Another step must be included in the algorithm in order to provide partition tolerance. If a network partition happens and this step is not provided, each partition will consider that the nodes from the other partition have crashed and will remove them from their configuration producing a fork of the ledger state. 3.1. Validator pool Transactions are validated by nodes that are in the validator pool. In order to participate in the validation process, nodes have to issue network events, in a deterministic order. A network event issued by a node contains pending transactions which the node wishes to include in the ledger. When nodes join the pool, they are placed on a circle which is represented by the interval \[0, 1). Each validator in the pool owns a share of this circle which is represented by a sub-interval of \[0, 1). The order in which the nodes are placed on the circle determines the order in which they are required to issue events. The node owning the lowest share of the interval is always required to be the first to issue an event. When a node joins the pool, the node with the largest share must give half of their share to the joining node. If a node leaves the pool, a node is deterministically chosen to receive the leaver’s share. Pending transactions are deterministically partitioned among all curent validators in order to prevent two nodes from validating the same transaction. A validator node receives the transaction fees of all the transactions that it has processed as reward if it isn’t found to be byzantine or crashed. read more in Purple whitepaper {% file src="/files/-LXKGlmVbBC\_NCMOfv2H" %} Purple whitepaper {% endfile %} ### Used in Purple * Whitepaper - * Website - * Github - * Twitter - * Reddit - * Facebook - * Medium - * Discord - * Telegram - # Chain-based Proof of Stake # Delegated Proof-of-Contribution (DPoC) a variant of Delegated Proof-of-Stake (DPoS) Bong An Ha of the ICON Foundation: > *“DPoC is not consensus protocol. ICON is based on the DPoS consensus protocol. Delegated Proof-of-Contribution (DPoC) is a decentralized and democratized incentive and governance protocol whereby token holders (ICONists) exercise their right to governance through delegating their stake to those that contribute directly to network growth. By delegating their stake, ICONists elect proven contributors to receive rewards from the network, while at the same time reaping rewards themselves by contributing through stake delegation”.* > *“An effective incentive mechanism can greatly expedite the growth and ultimate success of a decentralized ecosystem. The ICON Network utilizes the Delegated Proof-of-Contribution protocol to quantify ecosystem contributions, which allows for a more precise and decentralized distribution of economic incentives. Without an effective system like Delegated Proof-of-Contribution, valuable network resources could be allocated to entities with misaligned or apathetic interests, thus hindering the growth of the network and diluting the token holdings of ICONists that have made valuable contributions to the network. For this reason, the ICON Network focuses on selecting proven contributors through a delegation process”.* > > The central philosophy of the ICON Network reward distribution is fair compensation based on relative contribution. Each participant can demonstrate their contribution through the ICON Network’s unique contribution evaluation system. In the end, contribution is the most important value shared within the ICON Network, and therefore will be the sole standard in the network. Delegated Proof of Contribution (DPoC), as described herein, is the sole justification for electing representatives.” ### *Used In* * *ICON* ### *Read more* * [*https://medium.com/@ricky\_96150/delegated-proof-of-contribution-40bfac995c1*](https://medium.com/@ricky_96150/delegated-proof-of-contribution-40bfac995c1) * [*https://reactcrypto.net/icons-delegated-proof-of-contribution-model/*](https://reactcrypto.net/icons-delegated-proof-of-contribution-model/) ### Whitepaper * # Secure Proof of Stake (SPoS) Elrond has proposed a novel approach to consensus called “**Secure Proof of Stake**” which eliminates PoW computational waste, and combines eligibility through **stake** and rating with random validator selection, and an optimal dimension for the consensus group. Elrond’s approach to consensus is made by combining random validators’ selection, eligibility through stake and rating, with an optimal dimension for the consensus group. ### Algorithm 1. Each node ni is defined as a tuple of public key (P k), rating (default is 0) and the locked stake. If ni wishes to participate in the consensus, it has to first register through a smart contract, by sending a transaction that contains an amount equal to the minimum required stake and other information (P ks, a public key derived from P k and nodeid that will be used for the signing process in order not to use a real wallet address). 2. The node ni joins the node pool and waits for the shard assignment at the end of the current epoch e. The shard assignment mechanism creates a new set of nodes containing all the nodes that joined in epoch e and all the nodes that need to be reshuffled (less than 1 3 of every shard). All nodes in this set will be reassigned to the waiting lists of shards. Wj represents j’s shard waiting list and Nsh represents the number of shards. A node also has a secret key sk that by nature is not to be made public. 3. At the end of the epoch in which it has joined, the node will be moved to the list of eligible nodes (Ej ) of a shard j, where e is the current epoch. 4. Each node from the list Ej can be selected as part of an optimally dimensioned consensus group (in terms of security and communication), by a deterministic function, based on the randomness source added to the previous block, the round r and a set of variation parameters. The random number, known to all shard nodes through gossip, cannot be predicted before the block is actually signed by the previous consensus group. This property makes it a good source of randomness and prevents highly adaptive malicious attacks. We define a selection function to return the set of chosen nodes (consensus group) Nchosen with the first being the block proposer, that takes following parameters: E, r and sigr−1 - the previous block signature 5. The block will be created by the block proposer and the validators will co-sign it based on a modified practical Byzantine Fault Tolerance (pBFT). 6. If, for any reason, the block proposer did not create a block during its allocated time slot (malicious, offline, etc.), round r will be used together with the randomness source from the last block to select a new consensus group. ### Advantages * Effectively partitioning the blockchain and account state into multiple shards, handled in parallel by different participating validators * An improved variation of Proof of Stake (PoS) ### Used in * ### Whitepaper * # Hybrid PBFT/Aurand Polkadot uses a hybrid PBFT / Aurand consensus mechanism that has two degrees of finality. This consensus mechanism allows for relatively low latency state transitions while mitigating certain attacks to the network. ![](/files/-LQBKnP6Ig8nCwKiXcoz) The PBFT derivative provides absolute finality. Aurand, a derivative of Aura, provides fast, simple, and intermediate finality. Every so many blocks there is a PBFT check-point that guarantees finality, while the Aurand sets up the intermediary states of finality. With Aurand one randomly chosen validator may propose a block, which \*may be reverted\* (faster). They are punished (slashed) for proposing invalid blocks or for going offline. With PBFT > 2/3 of staked validators must sign-off to \*guarantee finality\* (slower). PBFT finality happens every \~30 seconds while Aurand blocks are proposed every \~4-5 seconds, potentially faster. POC-4 will introudce Aura v2, a progressive-consensus with milestone finalisation ([https://github.com/paritytech/polkadot/milestone/4 …](https://t.co/vX5a2Z0lL5)). [@**web3foundation**](https://twitter.com/web3foundation) researcher Alistair Stewart is working on this alongside Polkadot core devs [@**gavofyork**](https://twitter.com/gavofyork) and [@**rphmeier**](https://twitter.com/rphmeier). Become an expert on Polkadot's consensus mechanism (through POC-3) by watching [@**gavofyork**](https://twitter.com/gavofyork) present [@**ParityTech**](https://twitter.com/ParityTech)'s [#**Substrate**](https://twitter.com/hashtag/Substrate?src=hash) at Event Horizon, starting at minute 17:30. ### used in * Polkadot {% embed url="" %} source # Proof of Stake (PoS) The proof-of-stake (PoS) mechanism works using an algorithm that selects participants with the highest stakes as validators, assuming that the highest stakeholders are incentivized to ensure a transaction is processed. The idea is that those with the most coins in circulation have the most to lose so they are positioned to work in the interest of the network. The amount of coins that a network may require changes just like the difficulty in PoW. In PoS, 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.\ The common argument against proof-of-stake is the Nothing at Stake problem. The concern is that since it costs validators almost no computational power to support a fork unlike PoW, validators could vote for both sides of every fork that happens. Forks in PoS could then be much more common than in PoW, which some people worry could harm the credibility of the currency.
## Coin age To distinguish between users who have just obtained their coins and users who have been holding their coins for a period of time, proof-of-stake algorithms use the idea of coin age. Coin age is used in the calculation for both stake weight AND the staking reward. Staking reward is set by the coin's APR. The effect is a stable, consistent interest for all staking wallets, regardless of input size or reasonable downtime. The longer a user holds the coins, the higher the changes of winning the right to create a block of the network blockchain and get a reward. ## Incentivizing to stay connected In order to keep most user active, the reward for the creation of a block increase if there is too many users offline, so there is more benefits to go online. ## Penalizing offline users Most if not all PoS algorithm penalize Holders which can stay offline for long periods of time. Otherwise they could get control by connecting back to it and having over 50% of voting power because of the size of their holdings. ## Pseudo anonymous users Validators within the PoS network are anonymous users who are identified only by their wallet address. This pro-vides no additional accountability over PoW for bad actors who can amass significant wealth on the network. ## Security The security model is an economic one, based on the “game-theory” assumption that the cost of acquiring the tokens necessary to become a block producer is more than an attacker is willing to bear, that couples the network’s security to the value of its token, ie: the higher the value of the token, the more secure the network becomes. ## nothing-at-stake attack Without economic penalties for attackers, the chain can suffer nothing-at-stake attacks where stakers are incentivised to validate all proposed forks to maximise their returns. ![pos-nothing-stake](https://raw.githubusercontent.com/cedricwalter/blockchain-consensus/master/images/pos-nothing-stake.png) ## Algorithm ![Cosmos.network.pos](https://raw.githubusercontent.com/cedricwalter/blockchain-consensus/master/images/pos-cosmos.network.png) 1. The validators will have to lock up some of their coins as stake. 2. After that, they will start validating the blocks. Meaning, when they discover a block which they think can be added to the chain, they will validate it by placing a bet on it. 3. If the block gets appended, then the validators will get a reward proportional to their bets. ## BlackCoin / Qtum specifics TODO ## Used in * Decred, * Ethereum (soon), * Peercoin * Ada * EOS.IO * Gridcoin * Nxt * Waves * BlackCoin * Qtum * In Future with Casper in Ethereum * [Tezos](https://www.tezos.com) * At the beginning of each cycle (2048 blocks), a random seed is derived from numbers that block miners chose and committed to in the penultimate cycle, and revealed in the last. * Using this random seed, a follow the coin strategy (similar to follow-the-satoshi) is used to allocate mining rights and signing rights to stakeholders for the next cycle (the more coins (rolls) you have - the more your chance to be a miner/signer). * Blocks are mined by a random stakeholder (the miner) and includes multiple signatures of the previous block provided by random stakeholders (the signers). * Mining and signing both offer a small reward but also require making a one cycle safety deposit to be forfeited in the event of a double mining or double signing. * [Whitepaper](https://www.tezos.com/static/papers/white_paper.pdf) ## **Pros** * Cost efficient: speed, energy, hardware * The more people use the network and have coins, the more secure the network. * More decentralized ## Cons * Economic inequality, rich get richer. * Attackers can calculate the probability of winning the reward to create a block of the blockchain based on who has how many coins. * Initial targets for Ethereum’s Casper implementation are only 100 TPS * **Nothing at Stake** attacks ## Read more * [Wikipedia](https://en.wikipedia.org/wiki/Proof-of-stake) # Delegated Proof of Stake (DPoS) DPoS is a twist on Proof of Stake consensus that relies upon a group of delegates to validate blocks on behalf of all nodes in the network. Works using witnesses, who generate blocks. Witnesses are elected by stakeholders at a rate of one vote per share per witness. However, with PoA, the appointment of an authority is automatic, meaning that there can be no bias or uneven process caused by unequal stakes. Coin age is irrelevant. All coins that are mature will add the same staking weight (usually 1 in the wallet hover display). Results in stable, consistent interest only for active wallets and only with small inputs. Downtime and large inputs will significantly impact your interest with DPOS. On the plus side, no age means that moving coins is less costly because lost coin age is not detrimental. With DPoS blockchain consensus protocols, coin holders use their coin balances to elect delegates, called witnesses. These witnesses have the opportunity to stake blocks of new transactions and add them to the blockchain. Voting power is determined by cyberwealth. Those who have more coins or tokens will have a greater impact on the network that those with fewer. DPoS is the brain-child of Daniel Larimer, and is actually very different from PoS. In DPoS, 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.\ In DPoS, miners can collaborate to make blocks instead of competing like in PoW and PoS. By partially centralizing the creation of blocks, DPoS is able to run orders of magnitude faster than most other consensus algorithms. ## Used in * [Steemit](https://steemit.com/@zanewithspoon) * [EOS](https://eos.io) * Users who hold tokens on a blockchain adopting the EOS.IO software may select block producers (the more EOS tokens a stakeholder owns, the greater their voting power) * through a continuous approval voting system and anyone may choose to participate in block production and will be given an opportunity to produce blocks proportional to the total votes they have received relative to all other producers. * At the start of each round 21 unique block producers are chosen. * The top 20 by total approval are automatically chosen every round and the last producer is chosen proportional to their number of votes relative to other producers. * Block should be confirmed by 2/3 or more of elected Block producers. * Block Producer rewarded with Block rewards. * EOS is set to be the first blockchain with block times < 1 second! * [whitepaper](https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md#transaction-confirmation) * [BitShares](https://bitshares.org) ## Pros * Cheap transactions * Scalable * Energy efficient * Coin age is irrelevant: no age means that moving coins is less costly because lost coin age is not detrimental. * All coins that are mature will add the same staking weight (usually 1 in the wallet hover display). * Results in stable, consistent interest only for active wallets and only with small inputs. * Downtime and large inputs will significantly impact your interest with DPOS. **Cons** * Nothing at Stake * Partially centralized ## Read more * [Wikipedia](https://en.wikipedia.org/wiki/Delegated_proof-of-stake) # Proof of Stake Time (PoST) A time-accepted periodic proof factor in a nonlinear distributed consensus. Stake-Time as “The coin-age of a transaction or set of transactions in which the Stake-Time is the product of the total coins (C) and the fraction (f) of acceptable age(a) introducing a nonlinear proof function that defines a fraction of time active and idle, at a given block. Idle-time is defined as the fraction of age that no longer supports the distribution of consensus and instead begins to degrade it. This quantified idle-time is unique to each stake, as It decreases the probability to meet the proof and impacts the fraction of earnable matured interest via consensus. Where the fraction of accepted age (f) is equal to the squared cosine of the product of π and that transactions consensus power (p), defined as the fraction coin-age (g) of the average network wide stake-time weight (n) over 60 blocks (1 hour) \[figure 1]. If the consensus-power (p) is greater than 0.45 all age is lost and the Time-active fraction is equal to the minimum stake time (m) of 8 hours ## Used in * PostCoin * Vericoin ## Pros * maintains the efficiencies of Proof-of-Stake ## Read more * [Vericoin](https://vericoin.info) # Proof of stake Boo (PoS Boo) PoS Boo is a PoS scheme based on PoS Casper.Th Casper scheme improves the most on “POSv3” with the introduction of a risk factor for malicious stakers. The system is progressive in a way that makes it considerably difficult to execute attacks like the 51% attack; you would need a majority of all minted coins, and you will also face the potential to lose them all when launching such an attack. The finality is mainly determined by stake and risk factors, ## Pros * hard to execute a attack successfully even with 51% of circulation, * solves transaction censoring. With PoW, a block miner can “choose” not to mine a block containing certain addresses, thereby censoring that address from the network. Since block creators are chosen at random and validators are global with this PoS scheme, it is really hard to censor addresses from the network (with the added bonus that if you try to force the network, you will most likely lose your stake). ## Used in * [SHIELD](http://www.shieldx.sh) # High Interest Proof of Stake (HiPoS) Coin age is used in the calculation for stake weight, but not staking reward. Staking reward is fixed per a schedule. Results in stable, consistent interest for staking wallets as long as down time is minimal and inputs are small. Large input size is harshly punished by HiPOS. hiPOS is High Interest Proof of Stake. Essentially; a POS system that is a fixed reward rather than a percentage yield; which is awarded out based on luck/coin age/coin weight. hiPOS can be viewed as an extension of POW. Where hiPOS blocks equal the output in terms of coin count as POW blocks - in a short period of time. So a hiPOS coin would say have a total 10M coins; 5M of which are POW over a timespan of 60 Days; and the other 5M are hiPOS minted as POS over an additional 60 Days. ### Used in * Positron(2015) * BitBean (2015) * EdgeCoin (EDGE) * GRAVITYBITS ### Pros * Great for incentivizing people to hold as developers release more info on their projects * allow people with smaller holdings to benefit greatly by simply finding a few blocks at the right time. ## Proof of Identity (PoI) Proof of Identity (PoI) is a cryptographic evidence (piece of data) which tells that any user knows a private key that compares to an authorized identity and cryptographically attached to a specific transaction. Every individual from some group can create a PoF (only a block of data) and present it to anyone for instance to the processing node. ### Used in NEM ### Read more [Reddit](https://www.reddit.com/r/CryptoUBI/comments/2v2gi6/proof_of_identityproof_of_person_the_elephant_in) # Asset PoS (APoS ) Used in MarcoPolo Protocol (MAP) In the whitepaper of MarcoPolo Protocol (MAP), an improved PoS consensus called Asset PoS a.k.a APoS was proposed. References * # Traditional Proof of Stake / Tiered Proof Of Stake (TPOS) TPOS or Traditional Proof of stake is a form of the algorithm through which a cryptocurrency Social Network Blockchain aims to realize distributed agreement. In TPOS-derived currencies, the originator of the next block is selected through different combinations of random collection and the stake. ## Used in XSN ## Pros * Payments through processing dealings counts mainly on coin holders instead of on miners. # Casper the Friendly Finality Gadget (FFG) Friendly Finality Gadget (FFG), hybrid PoW/PoS. FFG is a Proof of Stake algorithm implementing stake slashing for bad behavior like chain halts and censorship. Foreseen for Ethereum 2.0 ## Algorithm * validators stake a portion of their Ethers as stake. * validators start validating the blocks. when they discover a block which they think can be added to the chain, they will validate it by placing a bet on it. * If the block gets appended, he validators will get a reward proportionate to their bets. * Malicious validator acts trying to do a “nothing at stake”, the will immediately be punished, and all of their stake is going to get slashed. ## Pros * all Pros of Proof of stake * punish validator trying to do a “nothing at stake” attack, * punishing miners who go offline, unintentionally or not, ## Used in * Casper the Friendly Finality Gadget (FFG), hybrid PoW/PoS that will be implmented first and ease transtion to full PoS. blocks are mined using POW, every 50th block a POS checkpoint where finality is assessed by a network of validators will be used. Read [Vitalik’s note on hybrid PoW/FFG](https://vitalik.ca/files/casper_note.html), his [medium post on minimal slashing conditions](https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c) and the [FFG paper](https://arxiv.org/abs/1710.09437). * Casper the Friendly GHOST: Correct-by-Construction (CBC): full PoS ### Resources * # Correct By Construction (CBC) Casper CBC Casper is a family of consensus algorithms developed by Vlad Zamfir. Foreseen in “Ethereum 3.0” ### Resources # Variable Delayed Proof of Stake (vDPOS) Ongoing, but you can help me with links, contact me #### Used in * CryptoCircuits [>> Go to Index <<](https://app.gitbook.com/s/-LLG7gr0ydPNrSJQ43vf/chain-based-proof-of-stake/#index) # Proof of Stake Velocity Proof of Stake Velocity (PoSV) is proposed as an alternative to Proof of Work (PoW) and Proof of Stake (PoS) to secure the peer-to-peer network and confirm transactions of Reddcoin, a cryptocurrency created specifically to facilitate social interactions in the digital age. PoSV is designed to encourage both ownership (Stake) and activity (Velocity) which directly correspond to the two main functions of Reddcoin as a real currency: store of value and medium of exchange. Reddcoin can also function as the unit of account in heterogeneous social context. ## Used in * [Reddcoin](https://www.reddcoin.com) * Not linear coin-aging function (new coins gain weight quickly, and old coins gain weight increasingly slowly) to encourage Nodes Activity. * Node with most coin age weight have a bigger chance to create block. * To create block Node should calculate right hash. Block reward * Interest on the weighted age of coins/ 5% annual interest in PoSV phase. * [whitepaper](https://www.reddcoin.com/papers/PoSV.pdf) ## Read more # Magi's Proof of Stake (mPoS) Aims to achieve distributed consensus through operations in addition to mPoW. mPoS is designed such that it rejects potential attacks through accumulating a large amount of coins or offline staking time, either of which leads to security concerns. Similar to mPoW's operation, mPoS is constructed in accordance with the concept of the attraction-repulsion model. Magi hybridizes mPoW with mPoS, and integrate both consensus approaches in order to acquire benefits from the two mechanisms and create a more robust payment system. #### Used in * [MAGI](https://www.m-core.org) **Read more** * [Bitcointalk](https://bitcointalk.org/index.php?topic=735170.msg9991269#msg9991269) # Leased Proof of Stake (LPoS) Your chances to find a new block only depend on how many Token you have ( i.e. your stake). ## Used in * NXT * Waves ## Pros you don’t need a lot of computing power to forge a new block ## Read more * [Medium1](https://medium.com/@wavesgo/explaining-waves-lpos-3a9f838cf167) * [Medium2](https://blog.wavesplatform.com/waves-launches-balance-leasing-in-lite-client-14db9eac0377) # Delegated Proof of Importance (DPoI) DPoI consensus algorithm integrates the concepts of EOSIO DPoS with the idea that social interactions naturally generate economic activity between individuals or organizations. The consensus is achieved with the help of delegates. Delegates are elected by the network participants based on the Importance of each voter The major goal of U◦OS project is to design a consensus algorithm with an individual influence score metric, that facilitates effcient score redistribution, motivates users to participate actively in the network development and prevents centralization. Modern blockchain solutions have problems with scalability, security and effciency, and to solve those problems, U◦OS protocol introduces the DPoI (Delegated Proof of Importance) Consensus Algorithm. This consensus algorithm combines the advantages of DPoS and PoI, and delegates validation rights to a limited number of accounts, based not only on the stake value of the protocol members, but also on the their transactional activity, in order to achieve high levels of effciency and scalability within the network. The U◦OS consensus algorithm (Delegated Proof-of-Importance, DPoI) is based on the DPoS consensus algorithm \[13]. In addition to the individual stake amount, our algorithm also considers incoming financial and social transactions of the user. In the U◦OS Protocol participants have the option of delegating the right to validate blocks to a limited number of accounts through voting, using their personal importance scores, analogous to DPoS. Unlike DPoS, however, DPoI importance score formula is calculated from three components, namely, the stake amount, financial transfer activity and social activity. This framework is highly flexible since the network can collectively choose not only the weight of contribution of each term in the final importance score, but also decide on how to calculate the transfer and social activity scores, given the structure of economic and social interactions in the system. A more detailed explanation of the Importance° calculation can be found in section 2.1 of U°OS Yellow Paper. ### Advantages * unlike PoW, PoS and DPoS approaches, DPoI ensures a bigger influence over the network to those who have earned approval by the community. ### Used in * U ◦OS ### Whitepaper * # Leasing Proof of Stake (PoS/LPoS) LPoS is an enhanced version of Proof-of-Stake. In a regular Proof-of-Stake system, each node that holds a certain amount of cryptocurrency is eligible to add the next block to the blockchain but in the LPoS system, on the Waves Platform, users can lease their balance to full nodes. WithLPoS, the user will have the ability to Lease WAVES form the wallet to different contractors which can pay a percentage as a reward. The larger the amount that is leased to a full node, the higher the chances of that full node being selected to produce the next block. If that full node is selected to produce the next block, the leaser will then receive a percentage of the transaction fee that is collected by the full node. In a LeasedProof-of-Stake environment, users can choose between running a full node or leasing their stake to a full node with receiving rewards. This system allows anyone to participate in the Waves network maintenance. User can leas his waves through leasing on any computer or mobile device that has an internet browser since Waves provides a lite client solution that does not require Miners, that are leasing their balance to store the whole Blockchain or to have the wallet running #### Used in * Nxt * Waves # Chain-based Proof of Capacity/Space shares some characteristics with PoW but also suffers from a \[lighter] Nothing-at-stake problem # Proof of Process Proof of Process is a protocol that allows participants to trust a common process by decoupling the proof of data from the actual source data in a way that yields a single proof that represents all steps of the process. A process is any sequence of steps in time. Whenever there is a movement of information, ideas, conversations, goods or products, there is a process. Traditionally, when institutions want to share their set of processes with one other, they must create common bridges to share their data. Those bridges usually consist of APIs, firewalls, and access management systems. A process is a sequence of steps in which actors perform specific actions at specific times relative to prior steps or introduce new factual elements and process actors in the sequence. All steps need not include the same set of actors, and the interaction between actors can be asynchronous as long as the interactions can be grouped together into sequential steps. Additionally, any step can fork into multiple branches without any need to reconcile them into a single branch. There can be parallel steps in different branches if they are performed at the same time. As time always moves one direction, there can never be circular steps within the same branch. Examples of processes can be found in almost every human to human and human to machine interaction. Just a handful of examples from this ocean include: * Trade and settlement processes * Software as a Service (SaaS) * Online multi-player games * Board games like chess and Battleship ## Algorithm 1. Extract trust by deriving proofs of the four key factual elements to address the four information security concerns for each step of the process: * What: data integrity through cryptographic hashing * Who: actor non-repudiation through digital signatures * When: proof of anteriority through trusted time-stamping or common time * Where: proof of context through cumulative proof via hash chain 2. Generate a single proof for each step 3. Publish the final proof in a distributed fashion through a network in which truth is established through a consensus mechanism ## Used in [Stratum](https://stratumn.com/technology/) ## Links * * # Proof of capacity (PoC) Miners use computer storage instead of the more common energy-expensive method proof-of-work (PoW) which involves permanent computational operations. Signum mining style solves all these problems (and is also ASIC-resistant) by allowing HDD mining – miners secure the network with their disk space. It can be seen as a “condensed Proof-of-Work”: you compute once (a process called plotting) and cache the results of your work on hard disk space. Then mining only requires to read through your cache – your HDD is idle most of the time and reads through the plot files only for a few seconds for each block. The term plotting is a name for dedicating storage space to be used for calculations in the Signum network. A Plot is a file containing pre-computed hashes that can be used to forge blocks for the Signum blockchain. The plots are later used by mining software and can be thought of as the miner’s hash rate. ## Algorithm 1. **Plotting:** Miners pre-generate chunks of data ([*plots*](https://signum.community/signum-plotting-technical-information)), containing all the computations necessary to forge blocks. 2. **Reward assignment:** Miners join a pool by defining it as beneficiary who will get the SIGNA reward should they find a block. 3. **Mining:** The mining software automatically reads through the plots and tries to [forge each block](https://signum.community/signum-mining). ## Terms * **Shabal** is the name of the crypto/hash function used in Burstcoin. Shabal is a rather heavy and slow crypto in relation to many other like i.e. SHA256. Because of this it makes it a good crypto for Proof of capacity coins like Burstcoin. This is because we store the precomputed hashes while it is still fast enough to do smaller live verifications. Signum uses the 256bit version of Shabal also known as Shabal256. * **Hash / Digest** A hash or digest in this context is a 32Byte (256bit) long result of the Shabal256 Crypto. * **Nonce** When generating a plot file, you generate something that is called nonces. Each nonce contains 256 Kilobyte of data that can be used by miners to calculate Deadlines. Each nonce will have its own individual number. This number can range between 0-18446744073709551615. the number is also used as a seed when creating the nonce. Because of this each nonce has its own unique set of data. One plot file can contain many nonces. * **Scoop** Each nonce is sorted into 4096 different places of data. These places are called scoop numbers. Each scoop contains 64byte of data which holds 2 hashes. Each of these hashes are xored with a final hash (we get to final hash in generating a nonce chapter). * **Account ID** When you create your plot file it will be bound to a specific Signum account. The numeric account ID is used when you create your nonces. Because of this all miners have different plot files even if they use the same nonce numbers. ## Used in * **Signum** * The Signum mining system relies on the existing free space on your hard drive, instead of energy hungry CPUs and GPUs. * Anyone can mine with the same chances since hard disks are easily available at low cost. * **SpaceMint** employs a consensus protocol based on a non-interactive variant of proof-ofcapacity (called proof-of-space), where participants generate and commit to a unique hard-to-pebble graph. * **Permacoin** repurposes Bitcoin’s PoW with a more broadly useful task: providing a robust, distributed storage. In PermaCoin, eligibility for the leader election requires participants to also store segments of a large file. The file is distributed by an authoritative ‘dealer’ who signs file blocks. To provides censorship-resistant file storage, the file is fully recoverable from the participants in the event of a dealer failure or shutdown. ## **Pros** * Livial energy consumption. * Fairer than PoS, since disks are cheap and available = lower barrier entry * Fast low cost blockchain transactions ## **Cons** ## Attacks and Mitigation # Proof of Signature (PoSign) PROOF-OF-SIGNATURE is a new consensus method (developed by Borzalom) that utilizes a network of registered STATIC nodes. STATIC nodes must be registered and active in order to participate in consensus. STATIC node registration status is verified using Proof-of-Signature, as all node are registered and known PoSIGN consensus is achieved through the interactions between a system of real and virtual node networks in constant communication, ensuring precise, rapid, signature-verified transactions. Additional benefits achieved by the ZOLT algorithm include substantially decreased energy consumption, as the consensus algorithm does not require nodes to solve computationally difficult problems to earn transaction fees or create new tokens. The STATIC (Services Transactions and Trusted in Control) node network is the bedrock upon which the XTRABYTES platform is built. STATIC nodes provide security, ensure consensus, and play a large and developing future role in XTRABYTES governance. The virtual VITALS network of nodes utilizes a proprietary network protocol in order to create an enclosed, private network by which online STATIC nodes can directly communicate. Lastly, to ensure STATIC nodes are indeed verifying the correct block as the VITALS network maintains consensus, the PULSE network functions as the central communication transmission system, providing time stamps in order to make block verification simpler across the entire STATIC network. Transactions are verified by a network of what are called STATIC nodes—importantly, each of these nodes must sign off on a transaction before the associated block can be appended to the chain. Should a malicious node repeatedly attempt to compromise the chain, it will be blacklisted automatically. ## Used in * XBY ## Read more * [Reddit](https://www.reddit.com/r/CryptoCurrency/comments/7ifzer/understanding_xbys_proofofsignature_posign) * [Wikipedia](https://xtrabytes.global/build/files/whitepaper.pdf) # Proof of Retrievability (POR) A proof of Retrievability (POR) is a compact proof by a file system (prover) to a client (verifier) that a target file F is intact, in the sense that the client can fully recover it. As PORs incur lower communication complexity than transmission of F itself, they are an attractive building block for high-assurance remote storage systems. It can be really useful as a consensus algorithm for Cloud computing systems. Permacoin proposed a modification to Bitcoin that repurposes its mining resources to achieve a more broadly useful goal: distributed storage of archival data. Unlike Bitcoin and its proposed alternatives, Permacoin requires clients to invest not just computational resources, but also storage. This scheme involves an alternative scratch-off puzzle for Bitcoin based on Proofs-of-Retrievability (PORs). Successfully minting money with this SOP requires local, random access to a copy of a file. Given the competition among mining clients in Bitcoin, this modified SOP gives rise to highly decentralized file storage, thus reducing the overall waste of Bitcoin. ## Used in * Microsoft * [PermaCoin](https://www.cs.umd.edu/~elaine/docs/permacoin.pdf) ## Read more * [Wikipedia](https://eprint.iacr.org/2008/175.pdf) # Proof of Location Proof of Location is a technology that enables a device's physical location coordinates to be broadcast to the blockchain in a way that other devices can rely on the location data without having to trust the broadcasting device. Position-dependent applications include supply chain, parametric insurance, KYC/AML verification, or even consumer transactions. E.g, an online store might need to prove that an item has been delivered to you so that the smart contract can automatically trigger a payment from your wallet. Today’s geo-location tools are great for determining the location of a device, but cannot offer reliable and trusted location verification services. They are uni-directional and un-encrypted, which makes it problematic to rely on GPS for smart contracts that need to execute when spatial parameters are met. Dynamic Proof of Location empowers a permission-less and autonomous network of radio beacons that can offer secure location verification services through time synchronization in a decentralized manner. ### Challenges * Difficult to implements ## Used in * The [FOAM](https://www.foam.space/) Proof of Location protocol empowers a permission-less and autonomous network of radio beacons that can offer secure location services independent of external centralized sources such as GPS through time synchronization. The will deliver a hardware-based solution and have miners, Foam nodes provide geo-triangulation combined with a verified timestamp. * XY Findables sold more than 100K devices and [XYO]() plan to roll out a firmware upgrade to enable all the owners of these devices to become nodes/‘sentinels’ in a ‘Proof of Origin’ consensus. * [Platin](https://platin.io/) is using a Proof of Location protocol on their own blockchain, called the Plexus™, [Platin](https://platin.io/) makes it simple to verify a location claim. * [http://animist.io](http://animist.io/) is an open source Bluetooth server/beacon that lets Ethereum micro-computer clients proximity-detect mobile devices and write information about their location to a smart contract. ## Pros * Trustless: Byzantine fault tolerant clock synchronization * Independent: Does not rely on GPS * Open: Anyone can utilize the network or offer utility services * Accountable: Economics structured to ensure honest behavior, verified with fraud proofs * Incentivized: Service providers remunerated for extending localization and verification zones ## read more * [Using Blockchain for Peer-to-Peer Proof-of-Location (research whitepaper)](https://arxiv.org/pdf/1607.00174v2.pdf) * [FOAM blog](https://blog.foam.space/introduction-to-proof-of-location-6b4c77928022) * [FOAM](https://foam.space/) * [Medium Foam vs Platin (sponsored)](https://hackernoon.com/meet-platins-proof-of-location-a-secure-and-verifiable-location-consensus-protocol-336528626e7e) # Proof of Reputation (PoR) POR is an upgraded, stronger, and more secure form of Proof of Authority (POA). In POA the transactions and blocks are validated by approved accounts known as validators. POA has typically been used in private networks and most recently a few companies that have adopted it to use individuals as the validators whose identities are publicly disclosed and at stake. Proof of Reputation (PoR) consensus model depends on the reputation of the participants to keep the network secure. A participant (a block signer) must have a reputation important enough that they would face significant financial and brand consequences if they were to attempt to cheat the system. POR uses companies as validators not individuals. Once a company proves reputation and passes verification, they may be voted into the network as an authoritative node and at this point, it operates like a Proof of Authority network (PoA), where only authoritative nodes can sign and validate blocks. A company caught cheating would not only be risking its reputation. It would be risking its entire market cap and the reputation of the officers and shareholders of the company. It would have significantly more to lose than any one individual. **Authorized Signers** Authorized signers are trusted nodes that create blocks, sign them, and distribute them to other nodes. A list of authorized signers will be maintained on the blockchain. Only authorized nodes can sign blocks and all blocks are verified that this is true by checking the signer is in the authorized list. The signing algorithm is essentially the same signature algorithm as PoW but with a different set of headers. PoW-specific headers will be removed and additional headers added to enable voting. Given N authorized signers, a signer may only sign a block every (N/2) + 1. This ensures that someone would need to control > 50% of signers to perform a malicious attack. Authorized signers will be rewarded in Coins per block signed. The consensus protocol ensures fairness and liveness by incentivizing the assigned signer of a block to perform the signing but also allowing other blocks to sign if the assigned signer is unavailable. The assigned signer for a block is determined by a round-robin lookup of the authorized signer list. If the assigned signer doesn’t respond then then other signers can sign at a lower block difficulty level. ## Pros * For private, permissioned blockchains. * Fast since no PoW needed ## Cons * Only for private, permissioned blockchains. * Subject to 51% attack like PoW, but more unlikely that so many entities in the network colludes. ## Used by * [GoChain](https://gochain.io/) that support smart contracts ## Read more [Medium](https://medium.com/gochain/proof-of-reputation-e37432420712) # Proof of Proof (PoP) The Proof of Proof™ consensus protocol enables blockchains to inherit proof-of-work security from other blockchains, creating an ecosystem wherein security originates on established blockchains like Bitcoin and extends to other blockchains. The PoP protocol introduces a new type of miner who performs periodic publications of one blockchain’s current state to another blockchain. These publications are referenced in the event of a potential blockchain reorganization. PoP requires a blockchain has some means of creating blocks, such as low-hashrate local PoW, PoS, etc. ## Used in * [VeriBlock](https://www.veriblock.org) ## Read more * [WhitePaper](https://raw.githubusercontent.com/cedricwalter/blockchain-consensus/master/whitepaper/PoP-Whitepaper.pdf) # Proof of History Instead of trusting the timestamp on the transaction, you could prove that the transaction occurred sometime before and after an event. The Proof of History is a high frequency Verifiable Delay Function. A Verifiable Delay Function requires a specific number of sequential steps to evaluate, yet produces a unique output that can be efficiently and publicly verified. Proof of History is a sequence of computation that can provide a way to cryptographically verify passage of time between two events. It uses a cryptographically secure function written so that output cannot be predicted from the input, and must be completely executed to generate the output. The function is run in a sequence on a single core, its previous output as the current input, periodically recording the current output, and how many times its been called. The output can then be re-computed and verified by external computers in parallel by checking each sequence segment on a separate core. Data can be timestamped into this sequence by appending the data (or a hash of some data) into the state of the function. The recording of the state, index and data as it was appended into the sequences provides a timestamp that can guarantee that the data was created sometime before the next hash was generated in the sequence. This design also supports horizontal scaling as multiple generators can synchronize amongst each other by mixing their state into each others sequences. ## Description The system is designed to work as follows. With a cryptographic hash function, whose output cannot be predicted without running the function (e.g. sha256, ripemd, etc.), run the function from some random starting value and take its output and pass it as the input into the same function again. Record the number of times the function has been called and the output at each call. The starting random value chosen could be any string, like the headline of the New York times for the day. For example: PoH Sequence Index Operation Output Hash 1 sha256(”any random starting value”) hash1 2 sha256(hash1) hash2 3 sha256(hash2) hash3 Where hashN represents the actual hash output. It is only necessary to publish a subset of the hashes and indices at an interval. Index Operation Output Hash 1 sha256(”any random starting value”) hash1 200 sha256(hash199) hash200 300 sha256(hash299) hash300 As long as the hash function chosen is collision resistant, this set of hashes can only be computed in sequence by a single computer thread. This follows from the fact that there is no way to predict what the hash value at index 300 is going to be without actually running the algorithm from the starting value 300 times. Thus we can thus infer from the data structure that real time has passed between index 0 and index 300. In the example in Figure 2, hash 62f51643c1 was produced on count 510144806912 and hash c43d862d88 was produced on count 510146904064. Following the previously discussed properties of the PoH algorithm, we can trust that real time passed between count 510144806912 and count 510146904064. ![PoH sequence](https://raw.githubusercontent.com/cedricwalter/blockchain-consensus/master/images/poh-sequence.png) Check solana-whitepaper.pdf for more details how PoH is implemented and how it scale ## Used in * Solana **Read more** * [whitepaper](https://solana.com/solana-whitepaper.pdf) # Proof of Existence Proof of Existence is an online service that verifies the existence of computer files as of a specific time via timestamped transactions in the bitcoin blockchain. ## Used in * Poex.io * HeroNode * DragonChain ## Read more * [Wikipedia](https://en.wikipedia.org/wiki/Proof_of_Existence) # Proof of Research (DPoR) Each participant helps performing research by computations in Gridcoins network. The network average is similar to difficulty in PoW mining. As the network average rises it becomes harder to get the same magnitude so if you want to keep getting the same reward you would have to add more compute power if we have an environment of a rising network average. If the price rose significantly more compute power would come on board, raising the network average, making it harder to get the same reward, just like difficulty in PoW. ## Used in * [Gridcoin](https://wiki.gridcoin.us/Proof-of-Research) ## Read more * [Gridcoin](https://wiki.gridcoin.us/Proof-of-Research) # Proof of Activity Combine Proof of Work component with a Proof of Stake. ## algorithm * Mining first begins in the traditional manner, with miners vying to be the first to solve a puzzle and claim their reward. * The difference is that the blocks being mined do not contain transactions. * They are simply templates with header information and the mining reward address. * Once this nearly blank block is mined, the system switches to a proof of stake protocol. * The header information is used to select a random group of validators to sign the block. * These are coin holders (stakeholders) and the larger the stake a validator holds, the greater the chance they will be selected to sign the new block. * Once all the chosen validators sign the block it becomes an actual part of the blockchain. * If the block remains unsigned by some of the chosen validators after a given time, it is discarded as incomplete and the next winning block is used. * Validators are once again chosen and this continues until a winning block is signed by all the chosen validators. * The network fees are split between the winning miner and the validators who signed the block. ## Used in ## Pros * Criticisms are the same as for both proof of work and proof of stake. ## Read more # Proof of Weight (PoWeight) Proof-of-Weight is a 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, in a PoWeight system, some other relatively weighted value is used. 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. ## Used in * [Algorand](https://people.csail.mit.edu/nickolai/papers/gilad-algorand-eprint.pdf) * [Filecoin](https://filecoin.io) * [Chia](https://chia.network) ## Pros * Customizable; scalable **Cons** * Incentivization can be a challenge **Read more** * [ALGORAND: The Efficient and Democratic Ledger](https://arxiv.org/pdf/1607.01341.pdf). Micali S. '16. # Proof of Zero (PoZ) PoZ is an evolution of actual PoS, with the main difference that is capable of Zero-Knowledge transactions. PoZ gives every users the chance of earning interest over their owned coins, just as standard Proof of Stake. Last but not least PoZ is far away more cheap than PoW, in term of power & processor consumption. Zcrypt is an anoymouc cryptocurrency that uses zero knowledge proofs. It uses a Proof of Work/Proof of Stake protocol with a new algorithm, LyraZ. ## Used in * ZCrypt # Proof of Importance NEM’s consensus network depends not only the number of coins but on the possibility that productive system action ought to be remunerated. The chances of staking a block are a component of various factors, including notoriety (controlled by a different purpose-designed framework), balance, and the number of transactions made to and from that position. Productive network activity, not just the number of coins accumulated, should be rewarded. Participants who frequently send and receive transactions are more likely to find blocks. ## Used in * New Economy Movement (NEM) Only accounts that have min 10k vested coins are eligible to harvest (create a block). Accounts with higher importance scores have higher probabilities of harvesting a block. The higher amount of vested coins, the higher the account’s Importance score. And the higher amount of transactions that satisfy following conditions: * transactions sum min 1k coins, * transactions made within last 30 days, * recipient have 10k vested coins too, * the higher account’s Important score. Harvester is rewarded with fees for the transactions in the block. * A new block is created approx. every 65 sec. [whitepaper](https://nem.io/wp-content/themes/nem/files/NEM_techRef.pdf) - [link1](https://nem.io/investors/harvesting-and-poi/#proof-of-importance) ## Pros You can still be a priority (over miner) if you perform frequent transactions and connections that are good for the ecosystem. ## Read more # Proof of Care (PoC) Rather than distributing presale tokens based on, say, how much users are contributing, companies can distribute token based on the quality of your proof-of-care for the project. On top of that, it's not even about social proof (i.e., how many Twitter followers you have), it's about the genuineness of your proof-of-care. It's a great way to essentially crowd-market your blockchain project by encouraging others to get the word out about it. it's about producing interesting, fun, informative content. #### Used in * Quantstamp * TomoCoin #### Pros * Implementing individual caps is very good step and can restrict whales from entering the public sale * Attract long term investors * Help spread the word by individuals **Cons** * Content creators have an advantage as they will have more influence and better chances to make it through. * Other people will just copy content from other's post just to complete their Proof of Care = lot of spam. **Read more** Whitepaper # Raft Raft is a consensus algorithm designed as an alternative to Paxos. It was meant to be more understandable than Paxos by means of separation of logic, but it is also formally proven safe and offers some additional features. 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. You can see how Raft work by visiting this [guided and less interactive visualization](http://thesecretlivesofdata.com/raft/) and [Raft Visualization](https://raft.github.io/) ## Used in * IPFS Private Cluster * Quorum see # Proof of Value (PoV) Earn token when user publish work to audience. #### Used in * [whitepaper](https://docs.google.com/document/d/1VogMc11WOeWB_OrcsIGD_J7F02KZ0I5zlDYTma7FJkA/edit) #### Read more * LTBcoin # Proof of Participation (PoP) If you read or listen to podcasts on the Let's Talk Bitcoin website, you have just participated in PoP ## Read more [whitepaper](https://docs.google.com/document/d/1L7HmE8IupFiSrfqk9BgNa4Zg9XogqtScyQjTw0k2xCc/edit) # Proof of Believability IOST introduced Servi as both a measurement of users’ contribution to the community and a way to encourage members to contribute to the continued development of the IOSChain. #### Used in * IOST **Read more** * [whitepaper](https://github.com/iost-official/Documents/blob/master/Technical_White_Paper/EN/Tech_white_paper_EN.md#consensus-mechanism) # Proof of Stake (POS) / Proof of Presence (PoP) 1. Reward for generating blocks (Proof-of-Stake, POS). This involves running a full node, unlocked and with the user's stake applied to generate blocks. Users who run a block generating node generally need to have at least a moderate amount of token on their account 2. Reward for storing the blockchain (Proof-of-Presence, POP). Only the most recent blocks file is distributed amongst all p2p nodes, previous blocks files are not needed for normal p2p operations. Token incentives users to store and make available previously archived block files. #### Used in HEAT #### Read more * [whitepaper](https://heatledger.com/HEATWhitepaper.pdf) # Proof of Ownership This technique can be used by artists or businesses to certify the integrity, date of publication and ownership of their creations or contracts. A Proof of Ownership is always attached to a piece of data using cryptographic functions. This makes it impossible to alter the data after certification. If the content is modified, even by a single bit, then the whole certificate becomes invalid. Only the people with the private key associated with the signature can prove they are the owner. # Proof of Quality (PoQ) E.g after PoV a month later when the performance of any work is compared against all the other work published during that week, user get an additional reward #### Used in * [whitepaper](https://docs.google.com/document/d/1HBbuN8rmrH22kXSYiDZaRv9aR7MVrI4FB8fSrSQ37tc/edit) **Read more** * LTBcoin # Proof of Space (PoC) (PoSpace), also called proof-of-capacity (PoC) is a means of showing that one has a legitimate interest in a service (such as sending an email) by allocating a non-trivial amount of memory or disk space to solve a challenge presented by the service provider. ## Used in * [Burstcoin](https://hackernoon.com/burst-part-3-proof-of-capacity-the-green-alternative-8e2651211671) * Chia * SpaceMint ## Pros * Efficient , cheap, distributed ## Cons ## Read more [Wikipedia](https://en.wikipedia.org/wiki/Proof-of-space) # Chain-based Hybrid models Proof of Activity and hybrid PoW/PoS # GRANDPA GHOST-based Recursive ANcestor Deriving Prefix Agreement GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement), also previously known as [SHAFT](https://hackmd.io/Jd0byWX0RiqFiXUVC78Bdw?view#SHAFT) (SHared Ancestry Finality Tool), and originally known as [AfG](https://hackmd.io/Jd0byWX0RiqFiXUVC78Bdw?view#AFG), is a finality gadget for blockchains, implemented in Rust. [**GRANDPA Block Finality in Polkadot: An Introduction (Part 1)**](https://medium.com/polkadot-network/grandpa-block-finality-in-polkadot-an-introduction-part-1-d08a24a021b5) ### Used in * *Polkadot is a blockchain for scalable decentralized computation and interoperability.* ### Whitepaper * The formal specification is published at ### Resources The first implementation is underway in Rust at # Proof of authority (PoA) In PoA-based networks, transactions and blocks are validated by approved accounts, known as validators. alidators run software allowing them to put transactions in blocks. The process is automated and does not require validators to be constantly monitoring their computers. It, however, does require maintaining the computer (the authority node) uncompromised. With PoA individuals earn the right to become validators, so there is an incentive to retain the position that they have gained. By attaching a reputation to identity, validators are incentivized to uphold the transaction process, as they do not wish to have their identities attached to a negative reputation. This is considered more robust than PoS, as: * In PoS, while a stake between two parties may be even, it does not take into account each party’s total holdings. This means that incentives can be unbalanced. * PoW uses an enormous amount of computing power, which, in itself lowers incentive ## Establishing authority The three main conditions that must be fulfilled for a validator to be established are: 1. Identity must be formally verified on-chain, with a possibility to cross-check the information in a publicly available domain 2. Eligibility must be difficult to obtain, to make the right to validate the blocks earned and valued. (Example: potential validators are required to obtain public notary license) 3. There must be complete uniformity in the checks and procedures for establishing an authority ## Used in * [POA.Network](https://poa.network) * [Ethereum Kovan](https://kovan.etherscan.io) * [testnet Rinkeby](https://gist.github.com/cryptogoth/10a98e8078cfd69f7ca892ddbdcf26bc) ## Pros * High throughput; scalable * No mining mechanism like in PoW, PoA uses identity as the sole verification of the authority to validate, * PoA is suited for both private networks and public networks * PoA only allows non-consecutive block approval from any one validator, meaning that the risk of serious damage is minimized. ## **Cons** * By identifying validators it is a centralized system ## Read more [Wikipedia](https://en.wikipedia.org/wiki/Proof-of-authority) # Ethereum Proof of Authority Ethereum Proof-of-Authority on Azure allows enterprises to build applications on an Ethereum blockchain that is not secured by a Proof-of-Work (PoW) consensus algorithm and consequently does not require mining. Since all participants on an enterprise blockchain network are known and reputable, governance can be separated from network operation. Azure features a built-in decentralized application (DApp or dApp) called the “Governance DApp” that provides consortium members with the authority to govern the network or delegate their voting power to others. Network participants can also delegate other nodes to vote on their behalf in the event that their primary nodes go offline, ensuring that all members maintain continual consensus participation. Network administrators, in turn, can use on-chain voting to vote on and alter network authorities in a transparent and auditable manner. ### Used in * [Ethereum on Azure](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/microsoft-azure-blockchain.azure-blockchain-ethereum?tab=Overview) [>> Go to Index <<](/consensus#index) ## Proof of Ambassador (PoA) The Proof of Ambassador protocol, introduced by the Bitcoin Origin project, builds on Proof of Authority by combining it with Proof of Stake elements. It works by assigning a reputation score to validators who are publicly identifiable, known as Ambassadors. Ambassadors are chosen each month by users who stake their coins to cast votes. The consensus is based on pre-approved authoritative Ambassadors with a Proof of Authority approach. Reputation is assigned to Ambassadors based on several criteria including continual predetermined set of activities like promotion and campaigning of the Bitcoin Origin project. ### Used in * [Bitcoin Origin](https://www.bitcoinorigin.io) # Limited Confidence Proof-of-Activity (LCPoA) Limited Confidence Proof-of-Activity (LCPoA) - a method for blockchain protection, based on the modification of the Proof-of-Work algorithm, in the direction of reducing the consumption of computational resources for the block generating. When using this method, the algorithm for block generating does not depend on the computing power. As a proof of work (or activity) the algorithm checks the time spent on the solution. #### Used in * izzz.io * BitCoen #### Read more * Wiki * Medium # Proof of Work (PoW) / Nexus Proof of State (nPoS) or Nexus Proof of Holding (nPOH) Nexus uses 3 consensus channels to maximize decentralization and provide fast, secure transactions. Each channel has an independent difficulty algorithm, amongst other checks and balances, to prevent a single channel from monopolizing block production and compromising the security of the network. Nexus channels include a Prime channel (CPU Mining), a Hashing channel (GPU Mining), and Nexus Proof of Holding (nPOH). Nexus takes the proof-of-stake system developed by Peercoin, and combines it with a Trust-based weighting system to create the Proof-of-Holding consensus mechanism. Nodes receive a Trust rating that is established by their contributions to the network, which increases over time. Nodes with greater Trust are granted an increased minting rate, which increases from 0.5% to 3% within one year, the longer you build Trust on the network. 3 consensus channels: Prime (CPU), Hashing (GPU), and Nexus Proof of Holding (nPOH) #### Used in * [Nexus](https://nexusearth.com) #### Pros * Key signature scheme to keep an account’s public keys obscured even when making transactions (This is made possible by moving away from addresses based on public key hashes, and implementing a new system called Signature Chains). * quantum resistance (Nexus uses a combination of SHA3 hashing algorithms combined with 571 bit private keys and 512/1024 bit proof of work) * multiple consensus channels greatly reduces the risk of a 51% attack (attacker would need to control all 3 channels) * OnChain scalability Transaction processing is distributed across multiple channels working synergistically to increase transaction throughput as resources increase. Individual channels verify transactions, consolidate verified transactions into Merkle trees, and add finished blocks onto the blockchain. The Unified Time protocol enables transaction processing, trust locks, and block locks to be consistent throughout time. The potential of Nexus 3DC is limited only by node count and represents the most energy-efficient consensus system to date. #### Read more * [whitepaper](https://nexusearth.com/nexus-white-paper) # Proof of Activity Combine Proof of Work component with a Proof of Stake. mining first begins in the traditional manner, with miners vying to be the first to solve a puzzle and claim their reward. The difference is that the blocks being mined do not contain transactions. They are simply templates with header information and the mining reward address. Once this nearly blank block is mined, the system switches to a proof of stake protocol. The header information is used to select a random group of validators to sign the block. These are coin holders (stakeholders) and the larger the stake a validator holds, the greater the chance they will be selected to sign the new block. Once all the chosen validators sign the block it becomes an actual part of the blockchain. If the block remains unsigned by some of the chosen validators after a given time, it is discarded as incomplete and the next winning block is used. Validators are once again chosen and this continues until a winning block is signed by all the chosen validators. The network fees are split between the winning miner and the validators who signed the block. ## Used in * [Decred](https://www.decred.org) * Blocks are created about every 5 minutes. * Nodes in the network looking for a solution with a known difficulty to create a block (PoW). * Once the solution is found it is broadcast to the network. * The network then verifies the solution. * Stakeholders who have locked some DCR in return for a ticket (1 ticket = ability to cast 1 vote. Stakeholders must wait an average of 28 days (8,192 blocks) to vote their tickets) now have the chance to vote on the block (PoS). * 5 tickets are chosen pseudo-randomly from the ticket pool and if at least 3 of 5 vote ‘yes’ the block is permanently added to the blockchain. * Both miners and voters are compensated with DCR : PoS - 30% and PoW - 60% of about 30 new Decred issued with a block. * Espers * [Coinbureau](https://www.coinbureau.com/blockchain/proof-of-activity-explained-hybrid-consensus-algorithm) ## Read more * [Research Paper](https://eprint.iacr.org/2014/452.pdf) # Proof of Work (PoW) / Proof of Stake (PoS) / Proof Of Care (PoC) Coin combining PoW and PoS and PoC #### Used in * TamaGucci # Proof of work (PoW) / High Interest Proof of Stake (HiPoS) Coin combining PoW and HiPoS #### Used in * EdgeCoin (EDGE) # Proof of Work (PoW) / PoM / PoSII Coin combining PoW and PoM and PoSII #### Used in * NOBL * Magi Coin #### Read more * [Github](https://github.com/magi-project/m-Noblecoin) # Chain-based Proof of Burn shares some characteristics with chain-based Proof of Stake # Proof of Processed Payments (PoPP) Proof-of-Processed-Payments (PoPP) is how Metal aims to distribute MTL to the masses. Think of it as a human-powered Proof-of-Work (POW), as opposed to a computational-powered PoW, such as the one Bitcoin uses. PoPP acts as a provable way of identifying users and distributing new currency into the system. At the same time, it rewards users who convert fiat currency into cryptocurrency. When a payment is settled, a portion of the gross amount of the payment is returned in MTL. The amount received is up to 5% of the volume of the transaction at trading value for MTL in either direction (sender/receiver). Consider as an example that Alice sends Bob $100 using the Metal Pay app and at the time MTL is trading at $1 per MTL. Following confirmation of a successful transaction, both Alice and Bob would receive $5 in MTL, which in this case would be 5 MTL. ## Used in metalpay ## Read more * [MetalPay](https://support.metalpay.com/hc/en-us/articles/115000369474-What-is-PoPP-) # Proof of Burn (PoB) With proof of burn, instead of pouring money into expensive computer equipment, you ‘burn’ coins by sending them to an address where they are irretrievable. By committinge your coins to never-never land, you earn a lifetime privilege to mine on the system based on a random selection process. A user who gives up short term wealth proves that they are following the consensus mechanism and is rewarded with a lifetime privilege to mine the next block on the blockchain. Coins are sent to unspendable address ## Used in * [Slimcoin](http://slimco.in) to get the right to write blocks Node should “burn” amount of coins. The more coins Node “burns” more chances it has to create blocks (for long period) -> Nodes address gets a score called Effective Burnt Coins that determines chance to find blocks. Block creator rewarded with block rewards. * TGCoin (Third Generation Coin) ## Pros * Keeping coins is not rewarded like in PoS ## Cons * Burning coins doesnt guarantee that you’re selected to mine future blocks, whales are favored * security get better with huge market capital (attack costs increase) * As with PoS, the principle is not suitable for distributing the first coins. ## Research > Proof-of-burn has been used as a mechanism to destroy cryptocurrency in a verifiable manner. Despite its well known use, the mechanism has not been previously formally studied as a primitive. In this paper, we put forth the first cryptographic definition of what a proofof-burn protocol is. It consists of two functions: First, a function which generates a cryptocurrency address. When a user sends money to this address, the money is irrevocably destroyed. Second, a verification function which checks that an address is really unspendable. We propose the following properties for burn protocols. Unspendability, which mandates that an address which verifies correctly as a burn address cannot be used for spending; binding, which allows associating metadata with a particular burn; and uncensorability, which mandates that a burn address is indistinguishable from a regular cryptocurrency address. Our definition captures all previously known proof-of-burn protocols. Next, we design a novel construction for burning which is simple and flexible, making it compatible with all existing popular cryptocurrencies. We prove our scheme is secure in the Random Oracle model. We explore the application of destroying value in a legacy cryptocurrency to bootstrap a new one. The user burns coins in the source blockchain and subsequently creates a proof-of-burn, a short string proving that the burn took place, which she then submits to the destination blockchain to be rewarded with a corresponding amount. The user can use a standard wallet to conduct the burn without requiring specialized software, making our scheme user friendly. We propose burn verification mechanisms with different security guarantees, noting that the target blockchain miners do not necessarily need to monitor the source blockchain. Finally, we implement the verification of Bitcoin burns as an Ethereum smart contract and experimentally measure that the gas costs needed for verification are as low as standard Bitcoin transaction fees, illustrating that our scheme is practical.\ > by [Kostis Karantias,](https://iohk.io/en/research/library/authors/kostis-karantias/)[Aggelos Kiayias,](https://iohk.io/en/research/library/authors/aggelos-kiayias/)[Dionysis Zindros](https://iohk.io/en/research/library/authors/dionysis-zindros/) September/2019, Financial Cryptography 2020\ > ## Read more * [HackerNoon](https://hackernoon.com/consensuspedia-an-encyclopedia-of-29-consensus-algorithms-e9c4b4b7d08f) * [bitcointalk.org](https://bitcointalk.org/index.php?topic=704213.0) * [**2 BTC BURNED IN 2018**](https://bitcoinwhoswho.com/blog/2018/12/29/2-btc-burned-in-2018/) # Proof of Time ChronoLogic considers time as value. Rather than proof-of-work or proof-of-stake mechanisms, ChronoLogicworks on proof-of-time. In its first use-case ChronoLogic pegs time to a store of value token named DAY based on the Ethereum blockchain. This cryptocurrency enables future value to be independent of third party assets that can be harvested such as electricity & processing power in the case of traditional cryptocurrency mining. The only way additional DAY can be produced is via the passage of time. The DAY smart contract has advanced minting capabilities and a halving mechanism to limit the total supply of DAY in the future. Every contributor in any phase of the token contribution period will receive a minting address called a TimeMint with a specific minting power called ChronoPower. ChronoPower ranges from 1% to 0.5% minting additional DAY in the respective TimeMint based on the TimeMint’s current balance of DAY. ChronoPower decays linearly among contributors based on their contribution order. The first contributor receives TimeMint0001 with the highest ChronoPower of 1% & the last TimeMint receives the lowest ChronoPower of 0.5%. ## Used in * [Chronologic](https://chronologic.network) ## Read more [Wikipedia](https://chronologic.network/uploads/Chronologic_Whitepaper.pdf) # Proof of Stake (PoS) / Proof of Disintegration (PoD) B3 is the first coin to develop and implement Fundamental Nodes (FN). A Fundamental Node is similar to a regular masternode in terms of the service it provides to the network but the coins used to purchase a Fundamental Node are destroyed. This reduces the overall supply of the coin over time as more Fundamental Nodes are added to the network. Fundamental Nodes receive 60% of the block reward while those staking receive 40%. #### Used in * [b3coin](https://b3coin.io) **Read more** * [whitepaper](https://b3coin.io) # Chain-based Trusted computing algorithms # Proof of Elapsed Time (PoET) PoET is a consensus mechanism algorithm that is often used on the permissioned blockchain networks to decide the mining rights or the block winners on the network. Permissioned blockchain networks are those which require any prospective participant to identify themselves before they are allowed to join. Based on the principle of a fair lottery system where every single node is equally likely to be a winner, the PoET mechanism is based on spreading the chances of a winning fairly across the largest possible number of network participants. The timer is different for each node. Every participant in the network is assigned a random amount of time to wait, and the first participant to finish waiting gets to commit the next block to the blockchain. Similar to pulling straws, but this time, the shortest stem in the stack wins the lottery. ## Used in * **Resource-Efficient Mining** (REM) provides an economic analysis to show that a miner’s revenue source originates from useful work, and not farming chips. * [Hyperledger Sawtooth](https://sawtooth.hyperledger.org) Solve BFT Validating Nodes limitation and required intel’s SGX. PoET uses a random leader election model or a lottery based election model based on SGX, where the protocol randomly selects the next leader to finalize the block. Every validator requests a wait time from an enclave (a trusted function). * The validator with the shortest wait time for a particular transaction block is elected the leader. * The BlockPublisher is responsible for creating candidate blocks to extend the current chain. He takes direction from the consensus algorithm for when to create a block and when to publish a block. He creates, Finalizes, Signs Block and broadcast it * Block Validators check block * Block is created on top of blockchain. ## Pros * Node will rest, so more energy efficient **Cons** * Trust Intel, require dedicated hardware **Read more** ## Attacks and Mitigation Breaking a single piece of trusted hardware enables the attacker to always win the lottery. Both Sawtooth and REM argue that a statistical analysis of newly minted blocks suffices to detect whether a chip can be compromised. Second, the stale chip problem highlights that it is advantageous to collect chips as this increases the probability of minting a new block (i.e., every new chips is an additional lottery ticket). # Chain-based PBFT and BFT-based Proof of Stake Byzantine Fault Tolerance (BFT) consensus ### Pros * BFT provide strong finality guarantees in that either all honest nodes will adopt a block or none will (thus eliminating the possibility of forks and rollbacks found in Bitcoin) ### Cons * Existing BFT algorithms normally do not scale well. # leaderless BFT dual ledger architecture a decentralized ledger system that features a leaderless, fully-local and scalable consensus algorithm based on virtual voting coupled with proof of work and proof of stake anti-sybil \[6] mechanisms that reaches eventual consensus with probability one. The concept of virtual voting was known long before in the literature, starting with the pioneering paper ”ByzantineResistant Total Ordering Algorithms” \[5] by Moser and Melliar-Smith where they formulated four algorithms to establish a total ordering from network events. The peculiar concept of virtual voting that later reappeared in other papers such as Hashgraph \[8], PARSEC \[9] or Blockmania \[51], was the ability to execute a virtual agreement protocol, as authors Moser and Melliar-Smith cleverly observed long before and exploited the fact that votes weren’t explicitly contained in the messages, but were deducted from the causal relationships between them. ### Used in Zenon network # Albatross An optimistic consensus algorithm > The area of distributed ledgers is a vast and quickly developing landscape. At the heart of most distributed ledgers is their consensus protocol. The consensus protocol describes the way participants in a distributed network interact with each other to obtain and agree on a shared state. While classical consensus Byzantine fault tolerant (BFT) algorithms are designed to work in closed, size-limited networks only, modern distributed ledgers -- and blockchains in particular -- often focus on open, permissionless networks. In this paper, we present a novel blockchain consensus algorithm, called \textit{Albatross}, inspired by speculative BFT algorithms. Transactions in Albatross benefit from a strong confirmation, and instant confirmations can be achieved as well. We describe the technical specification of Albatross in detail and analyse its security and performance. We conclude that the protocol is secure under regular PBFT security assumptions and has a performance close to the theoretical maximum for single-chain Proof-of-Stake consensus algorithms. from ### Whitepaper # asynchronous BFT protocol The surprising success of cryptocurrencies has led to a surge of interest in deploying large scale, highly robust, Byzantine fault tolerant (BFT) protocols for mission-critical applications, such as financial transactions. Although the conventional wisdom is to build atop a (weakly) synchronous protocol such as PBFT (or a variation thereof), such protocols rely critically on network timing assumptions, and only guarantee liveness when the network behaves as expected. We argue these protocols are ill-suited for this deployment scenario. We present an alternative, HoneyBadgerBFT, the first practical asynchronous BFT protocol, which guarantees liveness without making any timing assumptions. We base our solution on a novel atomic broadcast protocol that achieves optimal asymptotic efficiency. We present an implementation and experimental results to show our system can achieve throughput of tens of thousands of transactions per second, and scales to over a hundred nodes on a wide area network. We even conduct BFT experiments over Tor, without needing to tune any parameters. Unlike the alternatives, HoneyBadgerBFT simply does not care about the underlying network. ### Used in * HoneyBadgerBFT #### Read more * [link1](https://dl.acm.org/citation.cfm?id=2978399) * [link2](https://infoscience.epfl.ch/record/222858/files/199.pdf) # BFTree Allows an honest and reliable quorum of validators to quickly aggregate the required number of signatures in a distributed manner, allowing the algorithm to scale to large numbers of validators. > (BFtreee) ... enable a more decentralized proof-of-stake protocol by eliminating the need for two classes of nodes and delegation to a small number of validators. We view the goal of scaling to millions of validators as a forcing function to create a more scalable consensus\ > algorithm where BFT is no longer the bottleneck in terms of\ > making cryptocurrencies more decentralized. In practice, other bottlenecks, such as block sizes, may make the ideal number of validators be tens or hundreds of thousands of nodes for large cryptocurrencies. > > BFTree arranges validators into a virtual tree, to parallelize signature aggregation between non-byzantine nodes working to achieve consensus. When byzantine nodes interfere with the aggregation, the roots of all subtrees that were able to achieve agreement perform BFT consensus to finish the round, frequently with fewer messages than if all validators participated. By thoughtfully reorganizing the tree such that nodes that have historically been reliable are paired with other reliable nodes, BFTree limits the impact that a byzantine node can have. Source: ![A step by step example of how BFTree achieves consensus in the presence of faulty validators.](/files/-LhkoWTPUuhE2jypXHQ6) ### Whitepaper * [CELO Whitepaper](https://storage.googleapis.com/celo_whitepapers/BFTree%20-%20Scaling%20HotStuff%20to%20Millions%20of%20Validators.pdf) ### Used in * [Celo](https://celo.org/) # Byzantine Fault Tolerance (BFT) The classical problem in distributed computing that is usually explained with Byzantine generals. #### Used in * [Hyperledger](https://www.hyperledger.org) * [Dispatch](https://t.me/dispatchlabs) * [Ripple](https://ripple.com) **Pros** * High throughput; low cost; scalable **COns** * Semi-trusted **Read more** * [whitepaper](https://web.archive.org/web/20170205142845) * [whitepaper](http://lamport.azurewebsites.net/pubs/byz.pdf) # Delegated Byzantine Fault Tolerance The dBFT is called the Delegated Byzantine Fault Tolerant, a Byzantine fault-tolerant consensus mechanism that 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. #### sed in * Neo * ByteBall only verified nodes are allowed to be Validation nodes ([list of requirements](https://github.com/byteball/byteball-witness)). Users choose in transaction set of 12 Validating nodes. Validating nodes(Witnesses) receive transaction fees. [Whitepaper](https://byteball.org/Byteball.pdf) #### Read more * [Neo implementation](https://github.com/neo-project/docs/blob/master/en-us/index.md#neo-technology-implementation) # Federated Byzantine Agreement The general idea is that every Byzantine general, responsible for their own chain, sorts messages as they come in to establish truth. In Ripple the generals (validators) are pre-selected by the Ripple foundation. In Stellar, anyone can be a validator so you choose which validators to trust. #### Used in * Stellar - similar to Ripple but with key difference - quorum slice. [link1](https://www.stellar.org/papers/stellar-consensus-protocol.pdf) - [link2](https://www.stellar.org/stories/adventures-in-galactic-consensus-chapter-1/) - [link3](https://medium.com/a-stellar-journey/on-worldwide-consensus-359e9eb3e949) * Ripple * Each node receives transaction from external applications * Each Node forms public list of all valid (not included into last ledger (=block)) transactions aka (Candidate Set) * Nodes merge its candidate set with UNLs(Unique Node List) candidate sets and vote on the veracity of all transactions (1st round of consensus) * all transactions that received at least 50% votes are passed on the next round (many rounds may take place) * final round of consensus requires that min 80% of Nodes UNL agreeing on transactions. It means that at least 80% of Validating nodes should have same Candidate SET of transactions * after that each Validating node computes a new ledger (=block) with all transactions (with 80% UNL agreement) and calculate ledger hash, signs and broadcasts * All Validating nodes compare their ledgers hash * Nodes of the network recognize a ledger instance as validated when a 80% of the peers have signed and broadcast the same validation hash. * Process repeats. Ledger creation process lasts 5 sec(?). Each transaction includes transaction fee (min 0,00001 XRP) which is destroyed. No block rewards. [whitepaper](https://ripple.com/files/ripple_consensus_whitepaper.pdf) #### pros * High throughput, * low transaction cost, * network scalability **Read more** Stellar Whitepaper # HotStuff Hot-Stuff the Linear, Optimal-Resilience, One-Message BFT Devil ### Algorithm > HotStuff, a leader-based Byzantine fault-tolerant replication protocol for the partially synchronous model. Once network communication becomes synchronous, HotStuff enables a correct leader to drive the protocol to consensus at the pace of actual (vs. maximum) network delay--a property called responsiveness--and with communication complexity that is linear in the number of replicas. To our knowledge, HotStuff is the first partially synchronous BFT replication protocol exhibiting these combined properties. HotStuff is built around a novel framework that forms a bridge between classical BFT foundations and blockchains. It allows the expression of other known protocols (DLS, PBFT, Tendermint, Casper), and ours, in a common framework. Our deployment of HotStuff over a network with over 100 replicas achieves throughput and latency comparable to that of BFT-SMaRt, while enjoying linear communication footprint during leader failover (vs. quadratic with BFT-SMaRt). Authors researchers [Maofan Yin](https://arxiv.org/search/cs?searchtype=author\&query=Yin%2C+M), [Dahlia Malkhi](https://arxiv.org/search/cs?searchtype=author\&query=Malkhi%2C+D), [Michael K. Reiter](https://arxiv.org/search/cs?searchtype=author\&query=Reiter%2C+M+K), [Guy Golan Gueta](https://arxiv.org/search/cs?searchtype=author\&query=Gueta%2C+G+G), [Ittai Abraham](https://arxiv.org/search/cs?searchtype=author\&query=Abraham%2C+I) ### Whitepaper * ### Pros * HotStuff use a single message type for proposing, a single message type for voting, and simple Commit and Preferred Branch Rules. > HotStuff makes BFT more scalable by an order of magnitude, as the algorithm’s view-change complexity is made quadratically faster — a function of simply the number of nodes in the network, as opposed to a function of the number of nodes squared, as is the case in PBFT. () ### Used in * [Cypherium](https://cypherium.io/) ### Read more * * * # LibraBFT LibraBFT is based on HotStuff, a recent protocol that leverages several decades of scientific advances in Byzantine fault tolerance (BFT) and achieves the strong scalability and security properties. ![Libra logo](/files/-LhkhmcpOZSzBWAalBCK) ### Algorithm > Validators take turns driving the process of accepting transactions. When a validator acts as a leader, it proposes transactions, both those directly submitted to it by clients and those indirectly submitted through other validators, to the other validators. All validators execute the transactions and form an authenticated data structure that contains the new ledger history. The validators vote on the authenticator for this data structure as part of the consensus protocol ... > As part of committing a transaction Ti at version i, the consensus protocol outputs a signature on the full state of the database at version i — including its entire history — to authenticate responses to queries from clients." ... "The Libra protocol uses an account-based data model to encode the ledger state. ... > "Executing a transaction T i produces a new ledger state S i as well as the execution status code, gas usage, and event list. ### Pros * Because of the signature on the full state of the database, in every transactions, new validators should be able to join the network and sync quickly without having to replay the entire history of the blockchain, assuming that they trust the existing validators. * pseudonimity: \ "The Libra protocol does not link accounts to a real-world identity. A user is free to create multiple accounts by generating multiple key-pairs. Accounts controlled by the same user have no inherent link to each other. This scheme follows the example of Bitcoin and Ethereum in that it provides pseudonymity for users." ### Cons * You have to trust validators. * POS have to show that is still working when transitioning to permission-less network ### Used In * LibraBFT which is a variant of the HotStuff consensus protocol. ### Whitepaper * * ### Read More * # Modified Federated Byzantine Agreement (mFBA) FBA organises nodes into groups call quorums whereby overall consensus is met by: Quorum consensus among a certain amount of nodes (within a specific quorum); then Consensus among a certain number of quorums to finally determine the final consensus. ![mFBA](https://raw.githubusercontent.com/cedricwalter/blockchain-consensus/master/images/mFBA.png) #### pros * Decentralized control * Low latency * Flexible trust * Asymptotic security **Read more** * [Medium](https://medium.com/@boscoin/dpos-mfba-c84bae2e21ae) # Ouroboros A variation of Proof-of-stake(with rigorous security guarantees) used by Cardano. ## Used in * Cardano ## Read more * [Wikipedia](https://eprint.iacr.org/2016/889.pdf) * [Ouroboros: A provably secure proof-of-stake blockchain protocol](https://pdfs.semanticscholar.org/1c14/549f7ba7d6a000d79a7d12255eb11113e6fa.pdf). Kiayias A, Russell A, David B, Oliynykov R. '16. # Practical Byzantine Fault Tolerance PBFT works in asynchronous environments like the Internet and incorporates several important optimizations that improve the response time of previous algorithms by more than an order of magnitude. #### Used in Hyperledger Fabric #### pros * High transaction throughput **Cons** Centralized/permissioned **Read more** * [whitepaper](http://pmg.csail.mit.edu/papers/osdi99.pdf) # Chain-based others # Proof of Trust (PoT) A Proof-of-Trust Consensus Protocol for Enhancing Accountability in Crowdsourcing Services Incorporating accountability mechanisms in online services requires effective trust management and immutable, traceable source of truth for transaction evidence. The emergence of the blockchain technology brings in high hopes for fulfilling most of those requirements. However, a major challenge is to find a proper consensus protocol that is applicable to the crowdsourcing services in particular and online services in general. Building upon the idea of using blockchain as the underlying technology to enable tracing transactions for service contracts and dispute arbitration, this paper proposes a novel consensus protocol that is suitable for the crowdsourcing as well as the general online service industry. The new consensus protocol is called “Proof-of-Trust” (PoT) consensus; it selects transaction validators based on the service participants’ trust values while leveraging RAFT leader election and Shamir's secret sharing algorithms. The PoT protocol avoids the low throughput and resource intensive pitfalls associated with Bitcoin’s “Proof-of-Work” (PoW) mining, while addressing the scalability issue associated with the traditional Paxos-based and Byzantine Fault Tolerance (BFT)-based algorithms. In addition, it addresses the unfaithful behaviors that cannot be dealt with in the traditional BFT algorithms. The paper demonstrates that our approach can provide a viable accountability solution for the online service industry. **Authors** [Jun Zou](https://www.computer.org/csdl/search/default?type=author\&givenName=Jun\&surname=Zou), Department of Computing, Macquarie University, Sydney, NSW, Australia \ [Bin Ye](https://www.computer.org/csdl/search/default?type=author\&givenName=Bin\&surname=Ye), Department of Computing, Macquarie University, Sydney, NSW, Australia \ [Lie Qu](https://www.computer.org/csdl/search/default?type=author\&givenName=Lie\&surname=Qu), Department of Computing, Macquarie University, Sydney, NSW, Australia \ [Yan Wang](https://www.computer.org/csdl/search/default?type=author\&givenName=Yan\&surname=Wang), Department of Computing, Macquarie University, Sydney, NSW, Australia \ [Mehmet A. Orgun](https://www.computer.org/csdl/search/default?type=author\&givenName=Mehmet%20A.\&surname=Orgun), Department of Computing, Macquarie University, Sydney, NSW, Australia \ [Lei Li](https://www.computer.org/csdl/search/default?type=author\&givenName=Lei\&surname=Li), Hefei University of Technology, Hefei, China **A Proof-of-Trust consensus protocol for enhancing acceountability in crowdsourcing services**. In: IEEE Transactions on Services Computing. 2019 ; Vol. 12, No. 3. pp. 429-445. ### Used in ### Whitepaper # Proof of Devotion Similar to POI, the PoD selects the accounts with high influence. All accounts are ranked according to their liquidity and propagation (Nebulas Rank). #### Algorithm * Top-ranked accounts are selected * Chosen accounts pay deposit and are qualified as the blocks Validators (Validators Set is dynamic, changes in Set may occur after Epoch change.) * Algorithm pseudo-randomly chooses block Proposer * After a new block is proposed, Validators Set (each Validator is charged a deposit) participate in a round of BFT-Style voting to verify block (1. Prepare stage -> 2. Commit Stage. Validators should have > 2/3 of total deposits to validate Block) * Block is added. Block rewards : each Validator rewarded with 1 NAS. #### Used in * Nebula * [whitepaper](https://nebulas.io/docs/NebulasTechnicalWhitepaper.pdf) * [Github](https://github.com/nebulasio/wiki/wiki) # Snowglobe Used as a pre consensus algorithm in the future of BCH The pre-consensus Snowglobe protocol would run parallel with the original proof-of-work consensus mechanism and it has a variety of different benefits. Software developer Tyler Smith recently published specifications to a new concept he has created called Snowglobe. From the documentation: “This document specifies a propagation protocol for nodes of a Nakamoto Consensus network in which participants actively work to reconcile their local states against each other,” the Snowglobe specs state. “It enables nodes to sample each others’ state in order to determine which item in a conflict set is currently chosen by the most nodes, and to work toward a super majority of nodes choosing the same set of items.” "An Avalanche-based consensus algorithm is used for this process affording the protocol asynchrony, metastability, and quiescent finality." “Using Avalanche in Bitcoin Cash for miner coordination provides a very elegant, decentralized coordination mechanism that can potentially prevent miners from accepting double spend bribes and when combined with double spend notifications, make \[zero-confirmation] transactions very secure,” Pacia said at the time. In February 2019, Pacia and fellow BCHD developers [revealed](https://twitter.com/ChrisPacia/status/1093722089234853889) that an “Avalanche proof of concept is officially running on mainnet.” *The whitepaper describe* four different protocols called Slush, Snowflake, Snowball, and Avalanche. ### Whitepaper [*https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYwrRVGV*](https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYwrRVGV) ### *Tags* 0 conf transactions, Avalanche, Avalanche-based consensus, Bchd, Chris Pacia, Double-spend proofs, Electron Cash wallet, Jonald Fyookball, Nakamoto consensus, nodes, Openbazaar Developer, Pre-Consensus, Slush, Snowball, Snowflake, Snowglobe, Team Rocket, technology, Tyler Smith, zero confirmation # Avalanche The core idea of Avalanche is metastability. #### Pros * Quick finality and low latency * Higher throughput: 1000–10,000 transactions per second. * Robust: The network does not need to agree on who the participants are to achieve undeniable consensus. * No miners #### Cons **Read more** * [Snowflake to Avalanche: A Novel Metastable Consensus Protocol Family for Cryptocurrencies](https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYwrRVGV) * [demystifying-snowflake-to-avalanche](https://medium.com/zkcapital/demystifying-snowflake-to-avalanche-966f56c33fd7) # Serialization of Proof-of-work Events (Spectre) Spectre Utilizes a combination of PoW and DAGs to reach scalable consensus. In SPECTRE, the blocks are mined pointing to multiple parents, not just one, so the network could potentially handle multiple blocks per second. Mining a block pointing to some parent blocks supports those blocks validity. Compared to PoW’s “longest chain wins”, SPECTRE uses something like “blocks with the most childen win.” SPECTRE hasn’t been battle-tested in the wild yet, and new attack vectors are likely to emerge, but it feels like a very clever potential way to fix Bitcoin. #### Used in * Proposal for Bitcoin # Scrypt-adaptive-N (ASIC resistant) The idea behind the algorithm is that even if the memory requirements of the Scrypt algorithm used by Litecoin were adjusted, there would always come a time when it would not be high enough to render ASIC development impossible. Since this issue must be dealt with from the start, Scrypt-N is a perfect solution. Scrypt-N relies on the “Adaptive N-Factor” in which N is the memory required to complete new hashing functions. The idea is that N (memory requirement) will always increase over time, rendering ASIC development unfeasible. A coin with an adaptive 'n' factor usually starts at '11' , and stating it is adaptive that means that over time usually specific to a future unix time stamp it will become '12' , '13'... As it increases the amount of memory necessary to 'mine' the coin increases....quickly. ## Used in * [Vertcoin](https://vertcoin.org) * ExeCoin (EXE) * GPUcoin (GPUC) * ParallaxCoin (PLX) * SiliconValleyCoin (XSV) # Chain-based DAG ## Chain-based DAG A significant limitation of a single-chain topology is its ability to accept only one block at a time. But what if the network could accept multiple blocks simultaneously? This would not only increase the number of transactions processed but also reduce the waste incurred when the network discards all branches except one. | ![image](https://github.com/cedricwalter/blockchain-consensus/assets/71234183/0c424468-4d28-430d-93bb-387f090e8210) | | :-----------------------------------------------------------------------------------------------------------------: | | *A directed acyclic graph (DAG)* | Instead of constructing a linear chain, we can represent this more inclusive approach by building a graph. Many people think of a blockchain as a linear chain, but classic single chains like bitocoin and ethereum actually consist of branches and resemble a tree more than a linear chain. This tree-like structure is a type of graph, specifically a directed acyclic graph (DAG). A DAG might sound complex, but it simply means: * Blocks (vertices in mathematical terms) in this graph are connected. * These connections (edges in mathematical terms) have directions — e.g., block A points to block B * Following these directed connections from any block, you cannot end up at the same block no matter what path you take — i.e., there are no cycles in this graph ## Chanllenges of DAG-based ledger implementation Let’s investigate some of the problems we face into while making these design decisions. ### 1. Ordering In a single chain, the relative order of blocks is clear, as each block is linearly ordered with a defined parent. In a block DAG, only a subset of blocks has a clear relative order, while others do not. This is called partial ordering, which is unacceptable in blockchain. | ![image](https://github.com/cedricwalter/blockchain-consensus/assets/71234183/c7dfd061-43ef-4e78-9c95-b286171493ff) | | :-----------------------------------------------------------------------------------------------------------------: | | *Blue: clear relative ordering; Orange: ambiguous relative ordering* | In the illustration above, blue blocks have a clear relative order since they are directly or indirectly connected. If block A points to block B, block A knows about block B at its construction, indicating block B came before block A. However, orange blocks have ambiguous relative ordering, as there are no direct or indirect connections between them. Thus, some blocks have a clear order, while others do not. Ordering is crucial because different transaction orders can produce very different outcomes. For example, if A has 1 coin, and we have these transactions: 1. A sends B 1 coin 2. A sends C 1 coin 3. D sends A 1 coin Processing these in different orders results in different outcomes: * Order (1, 2, 3): transaction 1 succeeds, 2 fails since A now has no more money, 3 succeeds * Order (2, 3, 1): transaction 2 succeeds, 3 succeeds, 1 succeeds In blockchain, ordering is a critical attribute for network consensus; thus, partial ordering is unacceptable. ### 2. Randomness and Delay **Randomness** involves randomly selecting the next node to produce a block. There is no central entity "selecting" the node; it’s a matter of luck which node solves the puzzle first, given comparable hashing power. Randomness is vital to prevent targeted attacks, bribery, and other malicious activities. If block producers were known ahead of time, they could be incentivized to cheat or collude—e.g., prioritizing their own trades or attempting double-spends. Randomness ensures the network remains fair and honest. **Delay** refers to the time taken to create a new block in DLT, controlling the block creation frequency. Every block DAG must incorporate a delay. But why do we need a delay at all? No network can handle infinitely many blocks; each node would eventually run out of bandwidth, storage, memory, or CPU. There aren’t infinite transactions to fill infinite blocks. The block production rate and the number of transactions per block should adjust dynamically to network conditions, but zero delay is never feasible. ### 3. Block Efficiency When a node is producing a block, it is deciding which transactions the network will process next. At any given time, each node on the network maintains a list of pending transactions which were sent to the network for processing but haven’t made it into a block yet. When a new block is being produced, a node looks at this pending transaction queue and selects a subset to place into the block. | ![image](https://github.com/cedricwalter/blockchain-consensus/assets/71234183/799b3d39-3902-4856-aeb0-f65298db0ac6) | | :-----------------------------------------------------------------------------------------------------------------: | | *Packing a block efficiently* | Different networks have developed various conventions for transaction selection, mostly driven by economic incentives. If there are no severe network issues, each full node should have similar pending transaction queues, as critical information circulates quickly in a peer-to-peer (P2P) network. Nodes generally have heard about the same set of transactions, building similar pending transaction queues. If every node sees nearly the same set of pending transactions, they will produce blocks containing similar sets of transactions. This redundancy is undesirable, as redundant transactions represent wasted work, which is inefficient. # BlockFlow a DAG with Sharding consensus A novel sharding algorithm that supports cross-shard transactions natively without using locks or other synchronization mechanisms. ## Used In * # Direct Acyclic Graph Tangle (DAG) Tangle is the DAG consensus algorithm used by Iota. In order to send an Iota transaction, you need to validate two previous transactions you’re received. The two-for-one, pay-it-forward consensus strengthens the validity of transactions the more transactions are added to the Tangle. Because the consensus is established by the transactions, theoretically, if someone can generate 1/3 of the transactions they could convince the rest of the network their invalid transactions are valid. Until there’s enough transaction volume that creating 1/3rd of the volume becomes unfeasible, Iota is sort-of “double-checking” all of the network’s transactions on a centralized node called “The Coordinator”. Iota says The Coordinator works like training wheels for the system, and will be removed once the Tangle is big enough. ![What is Tangle](https://raw.githubusercontent.com/cedricwalter/blockchain-consensus/master/images/tangle1.png) This is directed, asynchronous graph (DAG) representing each individual transaction. You’ll notice that each transaction references exactly two other transactions to the left. #### Used in * IOTA **Pros** * Low transaction fees (PoW on 2 other Tx), fee-less payments * Extremely small transactions * Encrypted transaction payload * Scalability * Lightweight * Public/private message chains * Quantum-secure (Use trinary, or balanced ternary computations instead of the standard binary computations performed by classical computers) #### Cons * No Smart Contracts yet but ability [to bridge to Hyperledger fabric](https://blog.iota.org/integrate-hyperledger-fabric-with-the-iota-tangle-9bc3ac873e82) .see [github code example](https://github.com/iotaledger/HyperledgerFabric-IOTA-Connector) * Vulnerable (only 34% of the total hashing power required) #### Read more * [iota1\_4\_3.pdf](https://assets.ctfassets.net/r1dr6vzfxhev/2t4uxvsIqk0EUau6g2sw0g/45eae33637ca92f85dd9f4a3a218e1ec/iota1_4_3.pdf) * [The Coordinator](https://domschiener.gitbooks.io/iota-guide/content/chapter1/current-role-of-the-coordinator.html) # Hashgraph Hashgraph is a gossip-protocol consensus developed by Leemon Baird. Nodes share their known transactions with other nodes at random so eventually, all the transactions are gossiped around to all of the nodes. Hashgraph is really fast (250,000+ transactions per second) but isn’t resistant to Sybil attacks. So Hashgraph is a great option for private networks, but you’re not going to see it implemented in a public network like Ethereum or Dispatch anytime soon. "The Swirlds hashgraph consensus algorithm is explained through a series of examples on a hashgraph. Each page shows the hashgraph with annotations explaining a step of the algorithm. This covers the core algorithm, from creating transactions, through finding their consensus order and timestamps." see ## Read more * [HASHGRAPH SDK](http://www.swirlds.com/download/) * [How It Works (Graphically)](http://www.swirlds.com/downloads/SWIRLDS-TR-2016-02.pdf) * [Use case#1](https://youtu.be/rhHfjOqlUv4) (USING HASHGRAPH FOR IDENTITY) * [Use case#2](https://youtu.be/95fZqVCBvxQ) (USING HASHGRAPH FOR IOT) * [Forum](https://hashgraphboard.com/) ### Used in * Hedera Hashgraph --- [Next Page](/consensus/llms-full.txt/1)