This is an old revision of the document!
The following definitions and explanations are provided to help explain DIDO Consensus.
TBD
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 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 functional requirements for the project. For example, there is a requirement for Proof of Work (PoW) or Proof of State (PoS).
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).
Consensus Protocol, in DIDOs, is developed by a specific DIDO platform to implement Consensus Mechanism over their DIDO network to achieve Consensus. This means that two DIDO Platforms can use the same Consensus Mechanism but have different implementations. The differences in the implementation makes a difference in the efficiency of the DIDO Platform and can be used as a selection criterion between different Platforms. For example, there are two DIDO platforms (A and B) that both use Proof of Work(PoW). A is more efficient the B, therefore, the efficiency requirements will favor A.
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
GLAD data state also has a reference back to HAPPY data state.TBD