Difference between revisions of "Network Architecture"

From xx network wiki
Jump to navigation Jump to search
m
Line 6: Line 6:
# '''Gateways:''' The public facing components of Nodes, one exists per Node. They store received messages and provide public access to data and also run a light node for public access.
# '''Gateways:''' The public facing components of Nodes, one exists per Node. They store received messages and provide public access to data and also run a light node for public access.
# '''Clients:''' Clients come in two versions, cMix clients and xx chain clients. cMix clients access the communications layer and can send and receive private communications. xx chain clients are currently limited to block explorers and other interactions with the blockchain.
# '''Clients:''' Clients come in two versions, cMix clients and xx chain clients. cMix clients access the communications layer and can send and receive private communications. xx chain clients are currently limited to block explorers and other interactions with the blockchain.
== xx chain ==
The initial version of the xx chain is built on Substrate, which is an open source framework for creating blockchain networks in an efficient and secure manner. For its consensus algorithm, xx chain uses the most secure {{abbr|Byzantine Fault Tolerance|BFT}} approach offered by Substrate. This consists of [https://substrate.dev/docs/en/knowledgebase/advanced/consensus#babe BABE] for block authoring and [https://substrate.dev/docs/en/knowledgebase/advanced/consensus#grandpa GRANDPA] for block finality.
The xx chain uses Nominated Proof of Stake (NPoS) to economically secure the network. Anyone wishing to become a validator must '''stake''' coins, with a network governed minimum, expected to start at 5000 coins. Users of the network that do not want to become validators can still contribute by staking their coins and '''nominating''' validators. Each '''era''' (a period of time currently defined as 24 hours) an '''election''' determines which validators get selected based on their staked amounts, the nominations they have received, and the size of the validator set. Once elected, every validator is '''equal''', i.e., rewards are not proportional to the validator’s stake. Instead, a point-based system measures general blockchain '''performance''': uptime, block production, and each validator gets a percentage of the total reward based on their point total for each era. To find out more about these topics, please visit the [[Network Economics]] and [[Staking]] pages.
The xx chain has decentralized governance that allows every coin holder to propose, second and vote in referendums. There is also a Council with a limited number of seats, that can propose motions and other important decisions that users can vote on. Any user can run lock funds and become a candidate to council, and all users of the network can vote on candidates, with a fixed number getting elected each week. Finally, there is a smaller Technical Committee, appointed by the Council, that carries out technical decisions that are of major importance to a smooth and secure operation of the network. To find out more about this topic, please visit the [[Governance]] page.


== Hierarchy ==
== Hierarchy ==

Revision as of 00:52, 16 July 2021

General Architecture

The MainNet is generally composed of three components: Nodes, Gateways, and clients. All three of these components within themselves handle two functions: interacting with cMix, the private communications layer, and the xx chain.

  1. Nodes: The core operators of the network; they execute the cMix protocol and act as validators within xx chain.
  2. Gateways: The public facing components of Nodes, one exists per Node. They store received messages and provide public access to data and also run a light node for public access.
  3. Clients: Clients come in two versions, cMix clients and xx chain clients. cMix clients access the communications layer and can send and receive private communications. xx chain clients are currently limited to block explorers and other interactions with the blockchain.

xx chain

The initial version of the xx chain is built on Substrate, which is an open source framework for creating blockchain networks in an efficient and secure manner. For its consensus algorithm, xx chain uses the most secure BFT approach offered by Substrate. This consists of BABE for block authoring and GRANDPA for block finality.

The xx chain uses Nominated Proof of Stake (NPoS) to economically secure the network. Anyone wishing to become a validator must stake coins, with a network governed minimum, expected to start at 5000 coins. Users of the network that do not want to become validators can still contribute by staking their coins and nominating validators. Each era (a period of time currently defined as 24 hours) an election determines which validators get selected based on their staked amounts, the nominations they have received, and the size of the validator set. Once elected, every validator is equal, i.e., rewards are not proportional to the validator’s stake. Instead, a point-based system measures general blockchain performance: uptime, block production, and each validator gets a percentage of the total reward based on their point total for each era. To find out more about these topics, please visit the Network Economics and Staking pages.

The xx chain has decentralized governance that allows every coin holder to propose, second and vote in referendums. There is also a Council with a limited number of seats, that can propose motions and other important decisions that users can vote on. Any user can run lock funds and become a candidate to council, and all users of the network can vote on candidates, with a fixed number getting elected each week. Finally, there is a smaller Technical Committee, appointed by the Council, that carries out technical decisions that are of major importance to a smooth and secure operation of the network. To find out more about this topic, please visit the Governance page.

Hierarchy

Structure of the network.
Structure of the network.

BetaNet was built with a tiered Scheduler-Worker design, with all components controlled either directly or recursively by a central Permissioning server. Each member polls the entity above them in the hierarchy for information, as shown in the figure. Bi-directional communication only exists within the same level.

The Network Definition File (NDF) contains all the connection information for the entities in the network and is provided by the Permissioning server through the hierarchy shown. The Nodes provide the hash of their current NDF to Permissioning; if they differ then the updated NDF is provided to the Node. The Gateways poll the Nodes and Clients poll Gateways for the new NDF in the same fashion. However, the NDF provided to the Clients is stripped of Node IP addresses. In the current implementation of Clients, they currently get the NDF from Permissioning. This is expected to change by their release.

Nodes, Gateways, and Clients also receive scheduling instructions from the Permissioning server. These instructions are contained within RoundInfo structures, which are both prescriptive and descriptive of changes to rounds, which groups a set of Nodes to anonymize communications. A round is created when RoundInfo is issued to start a round’s precomputation. When the Nodes finish the precomputation, Permissioning issues a new RoundInfo that schedules it for real time, which can be delayed depending on the number of queued rounds. A further RoundInfo is issued when a round completes or fails.

Network Membership

In the network, all trust is derived from the Permissioning server. Currently, Permissioning is an information collator, but it will be replaced by the xx network consensus mechanism in the near future.

Identities in the network are defined by an asymmetric keypair. Most entities will hold this keypair within a TLS certificate, but some entities will just have a keypair. Nodes and Gateways prove their membership to the network by the inclusion of membership information in a signed NDF.

Initial Run

When first started, a Node will require two TLS certificates and a unique 256-bit randomly generated registration code provided by xx network to join the network. The certificates must be generated using RSA keys and the registration code will be provided in Base64 string format.

On first run, the Node will generate a cryptographic ID and register it with the network, via the Permissioning server. Most of the initial files and generated files are critical and must be preserved by the Node operator. For more information, refer to Cryptographic and Network Primitives.