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/07/30 13:17] 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 3: | Line 3: | ||
| [[dido:public:ra:1.2_views:2_tech_views:2-nodenet:start|return to Node Network View ]] | [[dido:public:ra:1.2_views:2_tech_views:2-nodenet:start|return to Node Network View ]] | ||
| - | The DIDO node architecture establishes a component model as a reference for evaluating the functionality or data available within a DIDO implementation. The reference components are conceptual in nature; thus they may or may not represent actual components within a DIDO implementation. However, the functionality of these reference components should be part of the implementations. | + | The DIDO [[dido:public:ra:xapend:xapend.a_glossary:n:node|node]] architecture establishes a component model as a reference for evaluating the functionality or data available within a DIDO implementation. The reference components are conceptual in nature; thus they may or may not represent actual components within a DIDO implementation. However, the functionality of these reference components should be part of the implementations. |
| - | At the most elementary level, reference components provide a common vocabulary for DIDO implementations. For example, [[dido:public:ra:xapend:xapend.a_glossary:b:bitcoin|Bitcoin]] does not have a separate standalone component that performs secure messaging; however, the Bitcoin software //does// provide secure messaging functionality using a protocol built upon [[dido:public:ra:xapend:xapend.a_glossary:c:cryptography|cryptography]]. This binds the secure messaging and protocol together. It is possible to write applications that adhere to this protocol using the cryptographic rules and standards defined by Bitcoin and not use the Bitcoin software; however, the usual approach is to build upon the open source Bitcoin software and use it “as-is.” Another example is where Bitcoin provides an actual component referred to as a Wallet, bearing in mind there are numerous other wallets available that can contain and manage Bitcoins.((A. Hertig, "Does the original Bitcoin Wallet Still Matter?," 16 September 2016. [[https://www.coindesk.com/original-bitcoin-wallet-still-matter/]]. | + | At the most elementary level, reference components provide a common vocabulary for DIDO implementations. For example, [[dido:public:ra:xapend:xapend.a_glossary:b:bitcoin|Bitcoin]] does not have a separate standalone component that performs secure messaging; however, the Bitcoin software //does// provide secure messaging functionality using a protocol built upon [[dido:public:ra:xapend:xapend.a_glossary:c:cryptography|cryptography]]. This binds the secure messaging and protocol together. It is possible to write applications that adhere to this [[dido:public:ra:xapend:xapend.a_glossary:p:protocol|protocol]] using the cryptographic rules and standards defined by Bitcoin and not use the Bitcoin software; however, the usual approach is to build upon the open source Bitcoin software and use it “as-is.” Another example is where Bitcoin provides an actual component referred to as a [[dido:public:ra:xapend:xapend.a_glossary:w:wallet|Wallet]], bearing in mind there are numerous other wallets available that can contain and manage Bitcoins.((A. Hertig, "Does the original Bitcoin Wallet Still Matter?," 16 September 2016. [[https://www.coindesk.com/original-bitcoin-wallet-still-matter/]]. |
| )) | )) | ||
| 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 smart contract node may use the identity, transaction, 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 30: | Line 30: | ||
| </figure> | </figure> | ||
| - | The DIDO network acts as a single system or entity, in which each node performs the operations required of it as a participant. For example, some DIDO networks may only provide a ledger, account numbers, and support transactions on the ledger. These would require each node to have the secure message, distribution software, ledger, identity and transaction components in common. | + | The DIDO network acts as a single system or [[dido:public:ra:xapend:xapend.a_glossary:e:entity|entity]], in which each node performs the operations required of it as a participant. For example, some DIDO networks may only provide a ledger, account numbers, and support transactions on the ledger. These would require each node to have the secure message, distribution software, ledger, identity and transaction components in common. |
| All the components within the network must be interoperable at the core functional level. For example, most of the nodes might run the Common Core version 1, whereas a subset might be running version 1.1. As long as the nodes within the network can interoperate and function together, the network is considered viable as a whole. | All the components within the network must be interoperable at the core functional level. For example, most of the nodes might run the Common Core version 1, whereas a subset might be running version 1.1. As long as the nodes within the network can interoperate and function together, the network is considered viable as a whole. | ||
| - | The interoperability of nodes within the DIDO and overall DIDO network viability become key benefits of DIDO implementations. This means that anything affecting interoperability is critical, and requires that interfaces and interactions (i.e., protocols) between the nodes must be the most conservative of all components. In other words, interfaces and interactions of the nodes are the mission critical aspects of the network and, therefore must be stable from the onset. Interruption or discontinuity in the critical path could result in a fork of the underlying ledger. An example of a fork is the “[[dido:public:ra:xapend:xapend.a_glossary:h:hard_fork|hard fork]]” in Ethereum called Byzantium: | + | The [[dido:public:ra:xapend:xapend.a_glossary:i:interoperability|interoperability]] of nodes within the DIDO and overall DIDO network viability become key benefits of DIDO implementations. This means that anything affecting interoperability is critical, and requires that interfaces and interactions (i.e., protocols) between the nodes must be the most conservative of all components. In other words, interfaces and interactions of the nodes are the mission critical aspects of the network and, therefore must be stable from the onset. Interruption or discontinuity in the critical path could result in a [[dido:public:ra:xapend:xapend.a_glossary:f:fork|fork]] of the underlying ledger. An example of a fork is the “[[dido:public:ra:xapend:xapend.a_glossary:h:hard_fork|hard fork]]” in [[dido:public:ra:xapend:xapend.a_glossary:e:ethereum|Ethereum]] called Byzantium: |
| - | : //The Byzantium hard fork is an update to ethereum’s [[dido:public:ra:xapend:xapend.a_glossary:b:blockchain|blockchain]] that was implemented in October 2017 at block 4,370,000. It consisted of nine Ethereum Improvement Protocols (EIPs) designed to improve ethereum’s privacy, scalability and security attributes.((R. Sharma, "What is the Byzantium Hard Fork in Ethereum?," 7 March 2018. [[https://www.investopedia.com/news/what-byzantium-hard-fork-ethereum/]]))// | + | : //The Byzantium hard fork is an update to ethereum’s [[dido:public:ra:xapend:xapend.a_glossary:b:blockchain|blockchain]] that was implemented in October 2017 at block 4,370,000. It consisted of nine Ethereum Improvement Protocols (EIPs) designed to improve ethereum’s privacy, [[dido:public:ra:xapend:xapend.a_glossary:s:scalable|scalability]] and security attributes.((R. Sharma, "What is the Byzantium Hard Fork in Ethereum?," 7 March 2018. [[https://www.investopedia.com/news/what-byzantium-hard-fork-ethereum/]]))// |
| ===== 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.1627665438.txt.gz · Last modified: 2021/07/30 13:17 by murphy
