dido:public:ra:1.2_views:2_tech_views:2-nodenet:3_nodearch
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:1.2_views:2_tech_views:2-nodenet:3_nodearch [2021/08/18 11:15] murphy |
dido:public:ra:1.2_views:2_tech_views:2-nodenet:3_nodearch [2022/02/03 20:35] (current) 52.45.51.99 ↷ Links adapted because of a move operation |
||
|---|---|---|---|
| Line 14: | Line 14: | ||
| </figure> | </figure> | ||
| - | The DIDO node component model presented in this diagram (Figure {{ref>NCModel}}) may look like a traditional stack or layered architecture as described in centralized or decentralized models; however, a very important difference is that the components or a subset of the components of this architecture are usually repeated at every DIDO node that participates in the DIDO network. At a minimum, the secure message and the distribution software components must exist at each node in order for the network to remain distributed and operational. In addition to providing for the core components required to securely communicate, a DIDO node can take on different roles or functions (refer to Figure {{ref>DIDONodes}}). Some nodes may use all the components within the DIDO node component model while others may only use a subset of these components. For example, a [[dido:public:ra:xapend:xapend.a_glossary:s:smart_contracts|smart contract]] node may use the identity, transaction, [[dido:public:ra:xapend:xapend.a_glossary:l:ledger|ledger]], distributed app, and ancillary data components. In contrast, a Wallet node may just use wallet and identity components. | + | The DIDO node component model presented in this diagram (Figure {{ref>NCModel}}) may look like a traditional stack or layered architecture as described in centralized or decentralized models; however, a very important difference is that the components or a subset of the components of this architecture are usually repeated at every DIDO node that participates in the DIDO network. At a minimum, the secure message and the distribution software components must exist at each node in order for the network to remain distributed and operational. In addition to providing for the core components required to securely communicate, a DIDO node can take on different roles or functions (refer to Figure {{ref>DIDONodes}}). Some nodes may use all the components within the DIDO node component model while others may only use a subset of these components. For example, a [[dido:public:ra:xapend:xapend.a_glossary:s:smart_contract|smart contract]] node may use the identity, transaction, [[dido:public:ra:xapend:xapend.a_glossary:l:ledger|ledger]], distributed app, and ancillary data components. In contrast, a Wallet node may just use wallet and identity components. |
| <figure DIDONodes> | <figure DIDONodes> | ||
| Line 39: | Line 39: | ||
| ===== Common Core ===== | ===== Common Core ===== | ||
| - | The Common Core contains components that are used by both the [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:1_ledger|ledger]] and [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:2_ancillary| ancillary data]] subset of components, as well as characteristics and attributes that apply to all components within the DIDO network. There are three classes of common components: tools and interfaces, distribution software, and secure messaging. Common components can be used exclusively by one kind of DIDO node as defined in [[dido:public:ra:1.2_views:2_tech_views:2-nodenet:3_nodearch| node architecture]] but can also span across the components within a node. For example, the transaction [[dido:public:ra:xapend:xapend.a_glossary:a:api]] is available to both the ledger and the ancillary data node and potentially by some of the tools. However, the transaction API may or may not be used as part of the ancillary data stack. | + | The Common Core contains components that are used by both the [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:03_digi_taxonomy:1_ledger|ledger]] and [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:03_digi_taxonomy:2_ancillary| ancillary data]] subset of components, as well as characteristics and attributes that apply to all components within the DIDO network. There are three classes of common components: tools and interfaces, distribution software, and secure messaging. Common components can be used exclusively by one kind of DIDO node as defined in [[dido:public:ra:1.2_views:2_tech_views:2-nodenet:3_nodearch| node architecture]] but can also span across the components within a node. For example, the transaction [[dido:public:ra:xapend:xapend.a_glossary:a:api]] is available to both the ledger and the ancillary data node and potentially by some of the tools. However, the transaction API may or may not be used as part of the ancillary data stack. |
| By definition, a ledger operation node must rely on the transaction API to access the ledger; however, a smart contract node may also require access to the ledger. In that case, its access is made exclusively through the transaction API. It is up to the implementation of a particular DIDO whether to access its ancillary data through a transaction API or a transform API. Conversely, a transaction might require ancillary data (i.e., monetary exchange rate, stock quotes, interest rates, market cap, or Beta, etc.) in order to complete. The Common Core contains an [[dido:public:ra:xapend:xapend.a_glossary:a:api|API]] that defines and allows for this access, sometimes referred to as an [[dido:public:ra:xapend:xapend.a_glossary:o:oracle|oracle]]. | By definition, a ledger operation node must rely on the transaction API to access the ledger; however, a smart contract node may also require access to the ledger. In that case, its access is made exclusively through the transaction API. It is up to the implementation of a particular DIDO whether to access its ancillary data through a transaction API or a transform API. Conversely, a transaction might require ancillary data (i.e., monetary exchange rate, stock quotes, interest rates, market cap, or Beta, etc.) in order to complete. The Common Core contains an [[dido:public:ra:xapend:xapend.a_glossary:a:api|API]] that defines and allows for this access, sometimes referred to as an [[dido:public:ra:xapend:xapend.a_glossary:o:oracle|oracle]]. | ||
dido/public/ra/1.2_views/2_tech_views/2-nodenet/3_nodearch.1629299742.txt.gz · Last modified: 2021/08/18 11:15 by murphy
