Difference between revisions of "Network Architecture"

From xx network wiki
Jump to navigation Jump to search
m (Protected "Network Architecture" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)))
m
Line 11: Line 11:
== xx chain ==
== xx chain ==


The initial version of the xx chain is built on Substrate, which is an open-source framework for creating blockchain networks efficiently and securely. For its consensus algorithm, xx chain uses the most secure {{abbr|Byzantine Fault Tolerance|BFT}} approach offered by Substrate, which 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 initial version of the xx chain is built on Substrate, an open-source framework for efficiently and securely creating blockchain networks. For its consensus algorithm, xx chain uses the most secure {{abbr|Byzantine Fault Tolerance|BFT}} approach offered by Substrate, which 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 secure the network economically. 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 get 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 uses Nominated Proof of Stake (NPoS) to secure the network economically. 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 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 get 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 essential decisions that users can vote on. In addition, any user can run and become a candidate to the Council, and all users of the network can vote on candidates, with a fixed number getting elected each week. Finally, a smaller Technical Committee, appointed by the Council, carries out technical decisions that are of significant importance to a smooth and secure operation of the network. To find out more about this topic, please visit the [[Governance]] page.
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 essential decisions that users can vote on. In addition, any user can run and become a candidate to the Council, and all users of the network can vote on candidates, with a fixed number getting elected each week. Finally, a smaller Technical Committee, appointed by the Council, carries out technical decisions that are of significant importance to a smooth and secure operation of the network. To find out more about this topic, please visit the [[Governance]] page.


== cMix ==
== cMix ==
For cMix, Node and Gateways pair together; every Node has a Gateway. Their relationship is a Scheduler-Worker design. In the initial design, this will be tiered with a Scheduling server orchestrating Nodes, which then orchestrate their Gateways, which then pass schedules onto Clients. The Scheduling server takes its instruction from the blockchain; network participation is defined by staking and consensus. The network will rapidly remove scheduling functions from the scheduling server and move them to adjudication by xx chain.
For cMix, Node and Gateways pair together; every Node has a Gateway. Their relationship is a Scheduler-Worker design. In the initial design, this will be tiered with a Scheduling server orchestrating Nodes that then orchestrate their Gateways, which then pass schedules onto Clients. The Scheduling server takes its instruction from the blockchain; network participation is defined by staking and consensus. The network will rapidly remove scheduling functions from the scheduling server and move them to adjudication by xx chain.


Currently, all components of cMix are controlled either directly or recursively by a central Scheduling 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. Of this data that is communicated, there are two main components: the [[Network Definition File (NDF)]] and the {{inline-code|lang=text|RoundInfo}}.
Currently, all components of cMix are controlled either directly or recursively by a central Scheduling 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. There are two primary components of this data that are communicated: the [[Network Definition File (NDF)]] and the {{inline-code|lang=text|RoundInfo}}.


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. This is because, in the current implementation of Clients, they get the NDF from Permissioning. This is expected to change by their release.
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. This is because, in the current implementation of Clients, they get the NDF from Permissioning. This is expected to change by their release.
Line 32: Line 32:
In a future update, the scheduling server will be eliminated and replaced by an on-chain consensus operation which will work as follows:
In a future update, the scheduling server will be eliminated and replaced by an on-chain consensus operation which will work as follows:
# To be scheduled, a Node will submit a transaction to the network known as a ''waiting bid''. Once accepted into a block, the Node will be written into the “waiting pool” for a maximum number of blocks.
# To be scheduled, a Node will submit a transaction to the network known as a ''waiting bid''. Once accepted into a block, the Node will be written into the “waiting pool” for a maximum number of blocks.
# To ensure appropriate mixing between Nodes in a team, the ''waiting pool'' will not be exhausted below 30% of the total number of online cMix Nodes (in the waiting pool + currently running rounds). Every block producer will use the block randomly to execute a fisher-yates shuffle on the waiting pool, selecting Nodes 1 through 5 as the first team, nodes 6 through 10 as the second team, etcetera until the waiting pool is exhausted.
# The ''waiting pool'' will not be exhausted below 30% of the total number of online cMix Nodes (in the waiting pool + currently running rounds) to ensure proper mixing between Nodes in a team. Every block producer will use the block randomly to execute a fisher-yates shuffle on the waiting pool, selecting Nodes 1 through 5 as the first team, nodes 6 through 10 as the second team, etcetera until the waiting pool is exhausted.
# The teams will see their formation and work together to execute their precomputation. Once completed, they will select a time to execute their realtime based upon network congestion and generate a joint certificate on the round realtime start. This will be passed to the Gateways and gossiped throughout the Gateway network.
# The teams will see their formation and work together to execute their precomputation. Once completed, they will select a time to execute their realtime based upon network congestion and generate a joint certificate on the round realtime start. This will be passed to the Gateways and gossiped throughout the Gateway network.
# Clients, who are polling the Gateways, will see realtime certificates as well as the scheduling of the team within the block and select a round to submit messages to.
# Clients, who are polling the Gateways, will see realtime certificates as well as the scheduling of the team within the block and select a round to submit messages to.

Revision as of 16:43, 26 October 2021

Current network structure.

General Architecture

The MainNet is generally composed of three components: Nodes, Gateways, and clients. Within themselves, all three of these components 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 the xx chain.
  2. Gateways: The public-facing components of Nodes, one exists per Node. They store received messages, provide public access to data, and 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, an open-source framework for efficiently and securely creating blockchain networks. For its consensus algorithm, xx chain uses the most secure BFT approach offered by Substrate, which consists of BABE for block authoring and GRANDPA for block finality.

The xx chain uses Nominated Proof of Stake (NPoS) to secure the network economically. 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 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 get 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 essential decisions that users can vote on. In addition, any user can run and become a candidate to the Council, and all users of the network can vote on candidates, with a fixed number getting elected each week. Finally, a smaller Technical Committee, appointed by the Council, carries out technical decisions that are of significant importance to a smooth and secure operation of the network. To find out more about this topic, please visit the Governance page.

cMix

For cMix, Node and Gateways pair together; every Node has a Gateway. Their relationship is a Scheduler-Worker design. In the initial design, this will be tiered with a Scheduling server orchestrating Nodes that then orchestrate their Gateways, which then pass schedules onto Clients. The Scheduling server takes its instruction from the blockchain; network participation is defined by staking and consensus. The network will rapidly remove scheduling functions from the scheduling server and move them to adjudication by xx chain.

Currently, all components of cMix are controlled either directly or recursively by a central Scheduling 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. There are two primary components of this data that are communicated: the Network Definition File (NDF) and the RoundInfo.

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. This is because, in the current implementation of Clients, they 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 realtime, which can be delayed depending on the number of queued rounds. Finally, a further RoundInfo is issued when a round completes or fails.

Full cMix Decentralization

Future network structure.

In a future update, the scheduling server will be eliminated and replaced by an on-chain consensus operation which will work as follows:

  1. To be scheduled, a Node will submit a transaction to the network known as a waiting bid. Once accepted into a block, the Node will be written into the “waiting pool” for a maximum number of blocks.
  2. The waiting pool will not be exhausted below 30% of the total number of online cMix Nodes (in the waiting pool + currently running rounds) to ensure proper mixing between Nodes in a team. Every block producer will use the block randomly to execute a fisher-yates shuffle on the waiting pool, selecting Nodes 1 through 5 as the first team, nodes 6 through 10 as the second team, etcetera until the waiting pool is exhausted.
  3. The teams will see their formation and work together to execute their precomputation. Once completed, they will select a time to execute their realtime based upon network congestion and generate a joint certificate on the round realtime start. This will be passed to the Gateways and gossiped throughout the Gateway network.
  4. Clients, who are polling the Gateways, will see realtime certificates as well as the scheduling of the team within the block and select a round to submit messages to.
  5. Once a realtime time has been reached, the nodes will begin the realtime, rapidly anonymizing the messages.
  6. Once complete, the mixed messages will be delivered to the Gateway and the team will form a joint certificate stating the completion of the round. This will be submitted as a transaction to the blockchain.
  7. Once the certificate of completion is received from the team, they will be awarded points towards compensation for the era and entered back into the waiting pool automatically. If the certificate does not get received by the blockchain before a predefined number of blocks, the round will be considered failed and the team will not be re-entered back into the waiting pool until they submit another waiting bid.

At any time, any member of the team can submit a failure certificate for the round, canceling it and allowing the team members to bid back into the waiting pool.