dido:public:ra:xapend:xapend.k_consensus:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:xapend:xapend.k_consensus:start [2021/07/16 21:28] nick |
dido:public:ra:xapend:xapend.k_consensus:start [2022/04/18 21:21] (current) nick |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Appendix K: DIDO Consensus ====== | + | ====== Appendix K: DIDO Consensus Algorithms ====== |
| [[dido:public:ra | Return to Reference Architecture (RA)]] or [[dido:public:ra:xapend | Return to Appendices]] | [[dido:public:ra | Return to Reference Architecture (RA)]] or [[dido:public:ra:xapend | Return to Appendices]] | ||
| - | ===== Consensus ===== | + | [[dido:public:ra:xapend:xapend.a_glossary:c:consensus_algorithm | Consensus Algorithms ]] are essential in establishing confidence in a DIDO. Consensus helps overcome the Two Generals Problem and the [[dido:public:ra:xapend:xapend.a_glossary:b:byzantine_generals_problem|Byzantine Generals problem]]. Two Generals' Problem is about establishing trust between the endpoints to ensure the data has not been tampered with. This is usually accomplished by encrypting the data flows between the two generals where each has a key to access the data. |
| - | [[dido:public:ra:xapend:xapend.k_consensus | Return to Top]] | + | |
| - | **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. | + | The Byzantine Generals problem ensures that everyone gets the same updates (i.e., transactions) and that the transactions are verified. This is generally accomplished by obtaining Consensus among all the generals about any decision (i.e., transaction). There are currently 30+ Consensus mechanisms in use within the DIDO communities (i.e., Blockchain, [[dido:public:ra:xapend:xapend.a_glossary:d:distributed_ledgers|Distributed Ledger]], Directed Acyclical Graphs, etc). See: [[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]]. |
| - | <figure> | ||
| - | {{ :dido:public:ra:xapend:screen_shot_2021-07-13_at_4.39.52_pm.png?400 |}} | ||
| - | <caption>The DIDO Network Nodes have Consensus the data state represents //"truth"//.</caption> | ||
| - | </figure> | ||
| - | ==== Notes ==== | ||
| - | [[dido:public:ra:xapend:xapend.k_consensus | Return to Top]] | ||
| - | |||
| - | There is a difference between a **DIDO Consensus** and a **[[dido:public:ra:xapend:xapend.a_glossary:c: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., [[a_glossary:d:dido_ecosphere_community | Ecosphere's]] ) [[dido:public:ra:xapend:xapend.a_glossary:p:p_p]]. | ||
| - | |||
| - | <figure> | ||
| - | {{ :dido:public:ra:xapend:xapend.k_consensus:screen_shot_2021-07-16_at_2.26.41_pm.png?300 | }} | ||
| - | <caption>The COI Consensus.</caption> | ||
| - | </figure> | ||
| - | |||
| - | * [[dido:public:ra:xapend:xapend.k_consensus:02_mechanism:start]] | ||
| - | |||
| - | |||
| - | ==== Proof of Work (PoW) ===== | ||
| - | [[dido:public:ra:xapend:xapend.k_consensus | Return to Top]] | ||
| - | |||
| - | Developed by Satoshi Nakamoto, Proof of Work is the oldest consensus mechanism used in the Blockchain domain. It is also known as mining where the participating nodes are called miners. | ||
| - | |||
| - | In this mechanism, the miners have to solve complex mathematical puzzles using comprehensive computation power. They use different forms of mining methods, such as GPU mining, CPU mining, ASIC mining, and FPGA mining. And the one that solves the problem at the earliest gets a block as a reward. | ||
| - | |||
| - | However, the process is not that easy. A puzzle can be solved only via the trial and error method. Additionally, the level of complexity of the puzzle increases with the speed at which blocks are mined. So, it becomes mandatory for one to create a new block within a certain time frame to cope up with the difficulty level.[[dido:public:ra:xapend:xapend.k_consensus:09_ref:bhardwaj]] | ||
| - | |||
| - | |||
| - | ==== Proof of Elasped Time (PoET) ===== | ||
| - | [[dido:public:ra:xapend:xapend.k_consensus | Return to Top]] | ||
| - | |||
| - | PoET was introduced by Intel with an intent to take over cryptographic puzzles involved in PoW mechanism by considering the fact that the CPU architecture and the quantity of mining hardware know when and at what frequency does a miner wins the block. | ||
| - | |||
| - | It is based on the idea of fairly distributing and expanding the odds for a bigger fraction of participants. And so, every participating node is asked to wait for a particular time to participate in the next mining process. The member with the shortest hold-up time is asked to offer a block. | ||
| - | |||
| - | At the same time, every node also comes up with their own waiting time, after which they go into sleep mode. | ||
| - | |||
| - | So, as soon as a node gets active and a block is available, that node is considered as the ‘lucky winner’. This node can then spread the information throughout the network while maintaining the property of decentralization and receiving the reward.[[dido:public:ra:xapend:xapend.k_consensus:09_ref:bhardwaj]] | ||
| - | |||
| - | ==== Proof of Capacity (PoC) ===== | ||
| - | [[dido:public:ra:xapend:xapend.k_consensus | Return to Top]] | ||
| - | |||
| - | Proof of Capacity (PoC), also known as Proof of Space (PoS), are solutions for every complex mathematical puzzle is accumulated in digital storage like Hard disks. Users can use these hard disks to produce blocks, in a way that those who are fastest in evaluating the solutions get better chances for creating blocks. | ||
| - | |||
| - | The process it follows is called Plotting.[[dido:public:ra:xapend:xapend.k_consensus:09_ref:bhardwaj]] | ||
| - | |||
| - | |||
| - | |||
| - | |||
| - | ==== Directed Acyclic Graphs (DAG) ===== | ||
| - | [[dido:public:ra:xapend:xapend.k_consensus | Return to Top]] | ||
| - | |||
| - | |||
| - | |||
| - | ===== Consensus Protocol ===== | ||
| - | [[dido:public:ra:xapend:xapend.k_consensus | Return to Top]] | ||
| - | |||
| - | **Consensus Protocol**, in DIDOs, is developed by a specific DIDO platform to implement **Consensus Mechanism** over their DIDO network to achieve **Consensus**. | ||
| - | |||
| - | <figure> | ||
| - | {{ :dido:public:ra:xapend:xapend.k_consensus:screen_shot_2021-07-14_at_5.08.57_pm.png?300 |}} | ||
| - | <caption>The relationship between Consensus, Consenus Mecahnism, and Consensus Protocol.</caption> | ||
| - | </figure> | ||
| - | |||
| - | |||
| - | ===== Transaction ===== | ||
| - | [[dido:public:ra:xapend:xapend.k_consensus | Return to Top]] | ||
| - | |||
| - | 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**). | ||
| - | |||
| - | <figure> | ||
| - | {{ :dido:public:ra:xapend:screen_shot_2021-07-14_at_10.54.56_am.png?400 |}} | ||
| - | <caption>Transaction move the Data from one state to the next and remember the precious data state.</caption> | ||
| - | </figure> | ||
| - | |||
| - | 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 ''GLAD'' data state also has a reference back to ''HAPPY'' data state. | ||
| - | |||
| - | ===== Why is it important ===== | ||
| - | |||
| - | |||
| - | |||
| - | |||
| - | [[dido:public:ra:xapend:xapend.a_glossary:c: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 below(( | Thus there are various types of consensus algorithms in blockchain prospect, some of them are explained below(( | ||
| Line 108: | Line 16: | ||
| )) | )) | ||
| - | * [[dido:public:ra:xapend:xapend.k_consensus:01_definition:start]] | ||
| - | * [[dido:public:ra:xapend:xapend.k_consensus:02_mechanism:start]] | ||
| - | * [[dido:public:ra:xapend:xapend.k_consensus:05_algorithm:start]] | ||
| - | * [[dido:public:ra:xapend:xapend.k_consensus:09_ref:start]] | ||
| - | * [[dido:public:ra:xapend:xapend.k_consensus:platform]] | ||
| - | |||
| - | |||
| - | <table ConsensusAlorithym> | ||
| - | <caption></caption> | ||
| - | |||
| - | ^ Consensus Alorithym ^ Description ^ Platform Examples ^ Pros ^ Cons ^ Type ^ | ||
| - | ^ Proof of Work (PoW) | <WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | Bitcoin, Litecoin, ZCash, Primecoin, Monero, Vertcoin | ||
| - | </WRAP> |<WRAP> | ||
| - | Less opportunity for 51% attack | ||
| - | Better Security | ||
| - | </WRAP> |<WRAP> | ||
| - | Greater energy consumption | ||
| - | Centralization of Miners | ||
| - | </WRAP> |<WRAP> | ||
| - | Competitive Consensus[[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | ||
| - | </WRAP>| | ||
| - | ^ Proof of Stake (PoS) | <WRAP> | ||
| - | |||
| - | </WRAP> |<WRAP> | ||
| - | Ethereum, Dash, Peercoin, Decred, Reddcoin, PivX | ||
| - | </WRAP> |<WRAP> | ||
| - | * Energy efficient [[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | ||
| - | * More expensive to attack for attackers [[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | ||
| - | * Not susceptible to economies of scale [[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | ||
| - | </WRAP> |<WRAP> | ||
| - | * nothing-at-stake problem [[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | ||
| - | </WRAP> |<WRAP> | ||
| - | Competitive Consensus [[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | ||
| - | </WRAP>| | ||
| - | ^ Delegated Proof of Stake (DPoS) | <WRAP> | ||
| - | |||
| - | </WRAP> |<WRAP> | ||
| - | * Steem, EOS, and BitShares [[dido:public:ra:xapend:xapend.k_consensus:09_ref:bhardwaj]] | ||
| - | * BitShares, Steemit, EOS, Lisk, Ark [[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | ||
| - | </WRAP> |<WRAP> | ||
| - | * Energy efficient. [[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | ||
| - | * Fast. Steemit, a high traffic blogging site uses it. EOS has a block-time of 0.5 sec. [[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | ||
| - | </WRAP> |<WRAP> | ||
| - | * A bit centralized.[[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | ||
| - | * Participants with high stakes can vote themselves in to become a validator. Something which is seen recently in EOS.[[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | ||
| - | </WRAP> | <WRAP> | ||
| - | Collaborative consensus[[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | ||
| - | </WRAP> | | ||
| - | ^ Leased Proof of Stake (LPoS) | <WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | Waves | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> | | ||
| - | ^ Proof of Elapsed Time (PoET) | <WRAP> | ||
| - | |||
| - | </WRAP> |<WRAP> | ||
| - | Hyperledger Sawtooth, Resource-Efficient Mining (REM) | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> | | ||
| - | ^ Practical Byzantine Fault Tolerance (PBFT) | <WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | Stellar, Ripple, Hyperledger Fabric[[dido:public:ra:xapend:xapend.k_consensus:09_ref:bhardwaj]] | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> | | ||
| - | ^ Simplified Byzantine Fault Tolerance (SBFT) | <WRAP> | ||
| - | |||
| - | </WRAP> |<WRAP> | ||
| - | Chain | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> | | ||
| - | ^ Delegated Byzantine Fault Tolerance (DBFT) | <WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | NEO [[dido:public:ra:xapend:xapend.k_consensus:09_ref:bhardwaj]] | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> | | ||
| - | ^ Directed Acyclic Graphs (DAG) | <WRAP> | ||
| - | |||
| - | </WRAP> |<WRAP> | ||
| - | Iota, Hedera Hashgraph [[dido:public:ra:xapend:xapend.k_consensus:09_ref:bhardwaj]] | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> | | ||
| - | ^ Proof of Activity (PoA) | <WRAP> | ||
| - | |||
| - | </WRAP> |<WRAP> | ||
| - | * Espers and Decred [[dido:public:ra:xapend:xapend.k_consensus:09_ref:bhardwaj]] | ||
| - | * Decred [[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | Collaborative consensus[[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | ||
| - | </WRAP> | | ||
| - | ^ Proof of Indentity (PoI) | <WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> | | ||
| - | ^ Proof of Importance (PoI) | <WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | NEM | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> |<WRAP> | ||
| - | </WRAP> | | ||
| - | ^ <WRAP> | ||
| - | Proof of Capacity (PoC) | ||
| - | Proof of Space (PoS) | + | <nspages -tree dido:public:ra:xapend:xapend.k_consensus: -exclude -subns -pagesInNs -h1 -textNs=""> |
| - | </WRAP> | <WRAP> | + | |
| - | </WRAP> |<WRAP> | + | |
| - | Burstcoin and SpaceMint [[dido:public:ra:xapend:xapend.k_consensus:09_ref:bhardwaj]] | + | |
| - | </WRAP> |<WRAP> | + | |
| - | * Similar to PoW but uses space instead of computation. Thus much environmental friendly. | + | |
| - | * Can be used for malware detection, by determining whether the L1 cache of a processor is empty (e.g., has enough space to evaluate the PoSpace routine without cache misses) or contains a routine that resisted being evicted. | + | |
| - | * Can be used for anti-spam measures and denial of service attack prevention. | + | |
| - | </WRAP> |<WRAP> | + | |
| - | Incentivization can be an issue. | + | |
| - | </WRAP> |<WRAP> | + | |
| - | Collaborative consensus[[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | + | |
| - | </WRAP> | | + | |
| - | ^ Proof of Burn (PoB) | <WRAP> | + | |
| - | </WRAP> |<WRAP> | + | |
| - | Slim Coin [[dido:public:ra:xapend:xapend.k_consensus:09_ref:bhardwaj]] | + | |
| - | </WRAP> |<WRAP> | + | |
| - | </WRAP> |<WRAP> | + | |
| - | </WRAP> |<WRAP> | + | |
| - | </WRAP> | | + | |
| - | ^ Proof of Weight (PoW) | <WRAP> | + | |
| - | </WRAP> |<WRAP> | + | |
| - | Algorand, Filecoin, Chia | + | |
| - | </WRAP> |<WRAP> | + | |
| - | * Energy efficient.[[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | + | |
| - | * Highly Customisable and scalable.[[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | + | |
| - | </WRAP> |<WRAP> | + | |
| - | * Incentivization can be hard.[[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | + | |
| - | </WRAP> |<WRAP> | + | |
| - | Competitive consensus [[dido:public:ra:xapend:xapend.k_consensus:09_ref:saini]] | + | |
| - | </WRAP> | | + | |
| - | </table> | + | <color blue><todo @char>New Section -- review </todo></color> \\ |
| + | <color blue><todo @char #char:2021-11-09>change the list above to nspages</todo></color> \\ | ||
| + | <color blue><todo @char #char:2021-11-09> Change the subsection page names to K.1, K.2, etc. similar to App F</todo></color> | ||
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||
dido/public/ra/xapend/xapend.k_consensus/start.1626485337.txt.gz · Last modified: 2021/07/16 21:28 by nick
