consensus
  • README
  • Blockchain Consensus Encyclopedia Infographic
  • CONTRIBUTING
  • Introduction
  • Blockchain Consensus?
  • Glossary
  • Categorizing consensus
  • Chain-based Proof of Work
    • Proof of Work (PoW)
    • Proof of Meaningful Work (PoMW)
    • Hybrid Proof of Work (HPoW)
    • Proof of Work time (PoWT)
    • Delayed Proof of Work (dPoW)
    • Proof of Edit Distance
    • ePoW: equitable chance and energy-saving.
    • Semi-Synchronous Proof of Work (SSPoW)
  • Chain-based Proof of Stake
    • Delegated Proof-of-Contribution (DPoC)
    • Secure Proof of Stake (SPoS)
    • Hybrid PBFT/Aurand
    • Proof of Stake (PoS)
    • Delegated Proof of Stake (DPoS)
    • Proof of Stake Time (PoST)
    • Proof of stake Boo (PoS Boo)
    • High Interest Proof of Stake (HiPoS)
    • Asset PoS (APoS )
    • Traditional Proof of Stake / Tiered Proof Of Stake (TPOS)
    • Casper the Friendly Finality Gadget (FFG)
    • Correct By Construction (CBC) Casper
    • Variable Delayed Proof of Stake (vDPOS)
    • Proof of Stake Velocity
    • Magi's Proof of Stake (mPoS)
    • Leased Proof of Stake (LPoS)
    • Delegated Proof of Importance (DPoI)
    • Leasing Proof of Stake (PoS/LPoS)
  • Chain-based Proof of Capacity/Space
    • Proof of Process
    • Proof of capacity (PoC)
    • Proof of Signature (PoSign)
    • Proof of Retrievability (POR)
    • Proof of Location
    • Proof of Reputation (PoR)
    • Proof of Proof (PoP)
    • Proof of History
    • Proof of Existence
    • Proof of Research (DPoR)
    • Proof of Activity
    • Proof of Weight (PoWeight)
    • Proof of Zero (PoZ)
    • Proof of Importance
    • Proof of Care (PoC)
    • Raft
    • Proof of Value (PoV)
    • Proof of Participation (PoP)
    • Proof of Believability
    • Proof of Stake (POS) / Proof of Presence (PoP)
    • Proof of Ownership
    • Proof of Quality (PoQ)
    • Proof of Space (PoC)
  • Chain-based Hybrid models
    • GRANDPA
    • Proof of authority (PoA)
    • Ethereum Proof of Authority
    • Limited Confidence Proof-of-Activity (LCPoA)
    • Proof of Work (PoW) / Nexus Proof of State (nPoS) or Nexus Proof of Holding (nPOH)
    • Proof of Activity
    • Proof of Work (PoW) / Proof of Stake (PoS) / Proof Of Care (PoC)
    • Proof of work (PoW) / High Interest Proof of Stake (HiPoS)
    • Proof of Work (PoW) / PoM / PoSII
  • Chain-based Proof of Burn
    • Proof of Processed Payments (PoPP)
    • Proof of Burn (PoB)
    • Proof of Time
    • Proof of Stake (PoS) / Proof of Disintegration (PoD)
  • Chain-based Trusted computing algorithms
    • Proof of Elapsed Time (PoET)
  • Chain-based PBFT and BFT-based Proof of Stake
    • leaderless BFT dual ledger architecture
    • Albatross
    • asynchronous BFT protocol
    • BFTree
    • Byzantine Fault Tolerance (BFT)
    • Delegated Byzantine Fault Tolerance
    • Federated Byzantine Agreement
    • HotStuff
    • LibraBFT
    • Modified Federated Byzantine Agreement (mFBA)
    • Ouroboros
    • Practical Byzantine Fault Tolerance
  • Chain-based others
    • Proof of Trust (PoT)
    • Proof of Devotion
    • Snowglobe
    • Avalanche
    • Serialization of Proof-of-work Events (Spectre)
    • Scrypt-adaptive-N (ASIC resistant)
  • Chain-based DAG
    • BlockFlow
    • Direct Acyclic Graph Tangle (DAG)
    • Hashgraph
    • Block-lattice - Directed Acyclic Graphs (DAGs)
  • Magi's proof-of-work (mPoW)
  • Common Attacks
  • Performance indicators
  • ThresholdRelay
  • Holochain
Powered by GitBook
On this page
  • Algorithm
  • Advantages
  • Used in
  • Whitepaper
  1. Chain-based Proof of Stake

Secure Proof of Stake (SPoS)

PreviousDelegated Proof-of-Contribution (DPoC)NextHybrid PBFT/Aurand

Last updated 5 years ago

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

https://elrond.com/technology/
https://elrond.com/assets/files/elrond-whitepaper.pdf