User Tools

Site Tools


Sidebar

Welcome to DIDO WIKI

dido:public:ra:xapend:xapend.k_consensus:01_definition:start

This is an old revision of the document!


1.0 Definition of Terms

Return to DIDO Consensus

The following definitions and explanations are provided to help explain DIDO Consensus.

Bizantine General Problem

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.

DIDO Consensus

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 functional requirements for the project. For example, there is a requirement for Proof of Work (PoW) or Proof of State (PoS).

Figure 1: The DIDO Network Nodes have Consensus the data state represents “truth”.

CoI Consensus

Return to Top

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).

Figure 2: The COI Consensus.

Consensus Protocol

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. 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.

  • Note: There can be more evaluation criteria than efficiency.
Figure 3: The relationship between Consensus, Consenus Mecahnism, and Consensus Protocol.

Transaction

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 4: Transaction move the Data from one state to the next and remember the precious data state.

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.

Two Generals Problem

dido/public/ra/xapend/xapend.k_consensus/01_definition/start.1626825111.txt.gz · Last modified: 2021/07/20 19:51 by nick
Translations of this page: