Difference between revisions of "Network Architecture"

From xx network wiki
Jump to navigation Jump to search
m
Line 3: Line 3:
== General Architecture ==
== General Architecture ==


The initial BetaNet is made up of three main entities:
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.


# '''Nodes:''' The core operators of the network; they execute the cMix protocol.
# '''Nodes:''' The core operators of the network; they execute the cMix protocol and act as validators within xx chain.
# '''Gateways:''' The public facing components of Nodes, one exists per Node. They store received messages and provide public access to data.
# '''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:''' Users use Clients to communicate on the network and are generally deployed on mobile devices.<br />{{Note|inline=1|small=1|The [https://gitlab.com/elixxir/client Client repository] is now public and community testing of the xx messenger is ongoing.}}
# '''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.


== Hierarchy ==
== Hierarchy ==

Revision as of 00:48, 16 July 2021

Currently, the Permissioning server is used to define the network and orchestrate its activities. This allows the engineering team to tune the network and bring the highly decentralized variant of cMix protocol to a workable state for MainNet. As the BetaNet software matures, xx consensus will take over roles currently held by the Permissioning server.

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.

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.