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
  1. Chain-based Proof of Work

Semi-Synchronous Proof of Work (SSPoW)

PreviousePoW: equitable chance and energy-saving.NextChain-based Proof of Stake

Last updated 6 years ago

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

Used in

Purple

  • Whitepaper -

  • Website -

  • Github -

  • Twitter -

  • Reddit -

  • Facebook -

  • Medium -

  • Discord -

  • Telegram -

https://purpleprotocol.org/whitepaper/
https://purpleprotocol.org/
https://github.com/purpleprotocol
https://twitter.com/purple_protocol
https://www.reddit.com/r/purpleprotocol/
https://www.facebook.com/purpleprotocol/
https://medium.com/purple-protocol
https://discord.gg/5ZVZnKd
https://t.me/purple_protocol
147KB
purple-whitepaper.pdf
pdf
Purple whitepaper