Sidebar
This is an old revision of the document!
Table of Contents
Appendix K: DIDO Consensus
Consensus
Consensus, in DIDOs, is when the entire distributed system agrees upon the state of the data within the system. In other words, the data within the entire system can be relied upon and reflects the “truth”. However, although the data within the DIDO is immutable, it does not mean it is static. Every proposed change in state to any data held within the DIDO is allowed when there is Consensus that the new data state is valid and verified.
Notes
There is a difference between a DIDO Consensus and a Community of Interest (CoI) Consensus. The DIDO Consensus concerns the way Consensus for propagating transactions throughout the DIDO Network. DIDO Consensus is generally inherent to the DIDO Platform. When there is a preference for a particular Consensus Mechanism for a particular project, the preference needs to be addressed as part of the functional requirements for the project.
CoI Consensus is concerned with how decisions are made in the CoI. The details of how Consensus is reached within a COI are generally captured in the Community's (i.e., Ecosphere's ) Policies and Procedures (P&P).
Directed Acyclic Graphs (DAG)
Consensus Protocol
Consensus Protocol, in DIDOs, is developed by a specific DIDO platform to implement Consensus Mechanism over their DIDO network to achieve Consensus.
Transaction
All data within the DIDO are immutable with newer values (i.e., data states) being posted using a transaction that provides instructions on how to migrate the original data state to a new data state. Over time, the chain of history of data state changes (i.e., Journal) for one piece of data can become quite long. Given a known data state at a particular time, the current state of the data can be reconstructed using the journaled transactions.
In addition, the new data state also includes references back to the original data state. This allows the navigation of the journal back to the original data state (i.e., Genesis Data).
The following are some examples of Data State change commands. These are not Transactions because they do not include a reference to the original data to be changed (i.e., altered).
CHANGE EmotionState FROM HAPPY TO GLAD CHANGE AccountBalance BY +5.00
- Note: In the example above, to be a transaction, the
GLADdata state also has a reference back toHAPPYdata state.
Why is it important
Consensus Algorithm are essential in establishing confidence in a DIDO.
Thus there are various types of consensus algorithms in blockchain prospect, some of them are explained below1)
| Consensus Alorithym | Description | Platform Examples | Pros | Cons | Type |
|---|---|---|---|---|---|
| Proof of Work (PoW) | Bitcoin, Litecoin, ZCash, Primecoin, Monero, Vertcoin | Less opportunity for 51% attack Better Security | Greater energy consumption Centralization of Miners | Competitive ConsensusWebpage: SAINI |
|
| Proof of Stake (PoS) | Ethereum, Dash, Peercoin, Decred, Reddcoin, PivX |
|
| Competitive Consensus Webpage: SAINI |
|
| Delegated Proof of Stake (DPoS) |
|
|
| Collaborative consensusWebpage: SAINI |
|
| Leased Proof of Stake (LPoS) | Waves | ||||
| Proof of Elapsed Time (PoET) | Hyperledger Sawtooth, Resource-Efficient Mining (REM) | ||||
| Practical Byzantine Fault Tolerance (PBFT) | Stellar, Ripple, Hyperledger FabricWebpage: BHARDWAJ | ||||
| Simplified Byzantine Fault Tolerance (SBFT) | Chain | ||||
| Delegated Byzantine Fault Tolerance (DBFT) | |||||
| Directed Acyclic Graphs (DAG) | Iota, Hedera Hashgraph Webpage: BHARDWAJ | ||||
| Proof of Activity (PoA) |
| Collaborative consensusWebpage: SAINI |
|||
| Proof of Indentity (PoI) | |||||
| Proof of Importance (PoI) | NEM | ||||
| Proof of Capacity (PoC) Proof of Space (PoS) | Burstcoin and SpaceMint Webpage: BHARDWAJ |
| Incentivization can be an issue. | Collaborative consensusWebpage: SAINI |
|
| Proof of Burn (PoB) | Slim Coin Webpage: BHARDWAJ | ||||
| Proof of Weight (PoW) | Algorand, Filecoin, Chia |
|
| Competitive consensus Webpage: SAINI |
