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/11/09 17:06] char [DIDO Consensus] |
dido:public:ra:xapend:xapend.k_consensus:01_definition:start [2022/03/20 23:20] (current) char [Conclusion] |
||
|---|---|---|---|
| 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 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.1636495592.txt.gz · Last modified: 2021/11/09 17:06 by char
