dido:public:ra:xapend:xapend.k_consensus:01_definition: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:01_definition:start [2021/10/03 16:31] 157.90.182.28 ↷ Links adapted because of a move operation |
dido:public:ra:xapend:xapend.k_consensus:01_definition:start [2022/03/20 23:20] (current) char [Conclusion] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== 1.0 Definition of Terms ====== | + | ====== K.1 Definition of Terms ====== |
| [[dido:public:ra:xapend:xapend.k_consensus:start| Return to DIDO Consensus ]] | [[dido:public:ra:xapend:xapend.k_consensus:start| Return to DIDO Consensus ]] | ||
| The following definitions and explanations are provided to help explain DIDO **Consensus**. | The following definitions and explanations are provided to help explain DIDO **Consensus**. | ||
| - | ===== Bizantine General Problem ===== | + | ===== Byzantine General Problem ===== |
| [[dido:public:ra:xapend:xapend.k_consensus:start| Return to Top]] | [[dido:public:ra:xapend:xapend.k_consensus:start| Return to Top]] | ||
| Line 12: | Line 12: | ||
| * [[dido:public:ra:xapend:xapend.a_glossary:b:byzantine_fault_tolerance]] | * [[dido:public:ra:xapend:xapend.a_glossary:b:byzantine_fault_tolerance]] | ||
| * [[dido:public:ra:xapend:xapend.a_glossary:b:byzantine_generals_problem]] | * [[dido:public:ra:xapend:xapend.a_glossary:b:byzantine_generals_problem]] | ||
| - | * | ||
| ===== Consensus ===== | ===== Consensus ===== | ||
| [[dido:public:ra:xapend:xapend.k_consensus:start| Return to Top]] | [[dido:public:ra:xapend:xapend.k_consensus:start| 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. | **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. | ||
| Line 23: | Line 23: | ||
| [[dido:public:ra:xapend:xapend.k_consensus:start| Return to Top]] | [[dido:public:ra:xapend:xapend.k_consensus:start| Return to Top]] | ||
| - | The **DIDO Consensus** is concerned with the way Consensus occurs to support the propagation of transactions throughout the DIDO Network. DIDO Consensus is generally inherent to the DIDO Platform. Any preference for a particular **Consensus Mechanism** on a particular project needs to be addressed as part of the [[dido:public:ra:xapend:xapend.a_glossary:f:funcreq|functional requirements]] for the project. For example, there is a requirement for Proof of Work (PoW) or Proof of State (PoS). | + | **DIDO Consensus** is concerned with the way Consensus occurs to support the propagation of transactions throughout the DIDO Network. DIDO Consensus is generally inherent to the DIDO Platform. Any preference for a particular **Consensus Mechanism** on a particular project needs to be addressed as part of the [[dido:public:ra:xapend:xapend.a_glossary:f:funcreq|functional requirements]] for the project. For example, there is a requirement for Proof of Work (PoW) or Proof of State (PoS). |
| <figure> | <figure> | ||
| Line 114: | Line 114: | ||
| As a side effect, if the message contains a command that needs to be executed immediately, then submitting the message multiple times can cause duplicate commands. One way around this dilemma is using [[dido:public:ra:xapend:xapend.a_glossary:i:idempotence]] which adds a unique number with the sending of each message. Every command message is checked when received for a previous command with the same unique number. If it was already received and process, then the duplicate command is ignored. | As a side effect, if the message contains a command that needs to be executed immediately, then submitting the message multiple times can cause duplicate commands. One way around this dilemma is using [[dido:public:ra:xapend:xapend.a_glossary:i:idempotence]] which adds a unique number with the sending of each message. Every command message is checked when received for a previous command with the same unique number. If it was already received and process, then the duplicate command is ignored. | ||
| + | <color darkblue><todo @nick>Above there is a reference to "Proof of State" along with "Proof of Work". The glossary contains a def for Proof of Work (PoW). Does not contain a def for "Proof of **State**" -- but it does contain a def for "Proof of **Stake**" -- is this merely a typo? Did you mean Proof of **Stake**? Can add the cross reference back to the Glossary for PoW but will wait on what to do with PoS .. </todo></color> | ||
| + | |||
| + | <color blue><todo @char>need to review with Nick's input </todo></color> | ||
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||
dido/public/ra/xapend/xapend.k_consensus/01_definition/start.1633293073.txt.gz · Last modified: 2021/10/03 16:31 by 157.90.182.28
