Private Network Technical Architecture
Here is a closer look at the components of a Rayls Private Network and how they work together to deliver privacy, scalability, interoperability, governance and auditing, all at the same time within a decentralised network.
Each Rayls Private Network is comprised of a Private Network Hub and many Rayls Sovereign nodes.
For simplicity, the architecture diagram below shows the connection between one Rayls Sovereign node and the Private Network Hub, although the same setup holds for any number of Rayls Sovereign nodes.
📘### Note that the dark line borders are features that have already been developed, while the red dashed borders indicate features that are currently under development.
Three user personas
Within each Private Network, there are three main user personas.
1. A Rayls Sovereign Operator User
This user is a transacting financial institution that installs its Rayls Sovereign operator package within its own environment, securely and privately behind its own firewalls.
Using this infrastructure, the Rayls Sovereign Operator User can interact with Rayls Sovereign in a number of ways: managing customer accounts, querying balances, instructing internal and cross-Private-Network transactions (via Rayls Custody), and viewing those transactions in the Rayls Sovereign ledger transaction (block) explorer.
The Relayer is installed when a Rayls Sovereign node joins a Private Network, and it orchestrates the private teleport of arbitrary messages and tokens with other Rayls Sovereign nodes via the Rayls Protocol across the Private Network Hub.
For more on what a ledger is, how it works and what it gives an institution, see the A warm introduction to Rayls Sovereign page.
2. A Private Network Operator User
This user is the authority of a Rayls Private Network, and it is their responsibility to install and maintain the core infrastructure of the Private Network, including the Private Network Hub, the Rayls Protocol, the registries and the smart contracts, and to define the governance rules that regulate the network.
Rayls provides a number of tools that support a Private Network Operator in performing these tasks and governing effectively, including:
- Rayls Custody, for secure HSM-based key custody. Only the Operator should hold the power to sign governance rules and decisions into effect, using their private key.
- A governance rules engine, for enforcing governance actions using out-of-the-box rules engines and workflows, such as approving a new member to join the Private Network or freezing a member so that they can no longer transact. Rayls continues to release new rules that can be used out of the box, and developers can also write their own custom governance rules as smart contracts.
- A member registry, for maintaining a list of approved Private Network members, their roles and their statuses, with roles such as Participant or Issuer and statuses such as Active or Frozen.
- A token registry, for maintaining a list of registered tokens and their statuses, such as Active or Frozen. Only approved, Active tokens can be transacted across the Private Network, so a transaction involving a token that has not had its registration approved, or that does not carry an Active status, will fail.
For more on the Private Network Operator role, its capabilities and the governance rules available to it, see the Private Network roles page.
3. A Private Network Auditor User
This user is responsible for ensuring the validity, consistency and legitimacy of the Private Network. As a regulator of the Private Network, they receive and validate (Pedersen) state commits and may be given read-only access to "peek" into the encrypted transactions published to the Private Network Hub, both to secure the network and to identify potentially fraudulent transactions.
Rayls provides a number of tools that support the Private Network Auditor, including:
- A Private Network transaction (block) explorer, for viewing encrypted cross-Private-Network transactions recorded to the Private Network Hub. This explorer can also be accessed by all Rayls Sovereign nodes within the Private Network, so that each institution can confirm the status of cross-Private-Network transactions and check that they have been correctly recorded to the ledger, matching them against their own transaction (block) explorer.
- A 'God view decrypter'. Rayls provides a configurable level of decryption that a Private Network Auditor can exercise over encrypted transaction data from the Private Network Hub, as determined by the Private Network Operator. The Operator may give the Auditor no visibility at all, or complete power to decrypt all transaction data. See the Private Network design options page for more.
- Transaction and state validation. The Private Network Auditor continually checks the consistency between net transactions and reported balances via the regular (Pedersen) state commits provided by each Rayls Sovereign ledger. Where the two values diverge, a 'Flagger' tool automatically captures the potentially fraudulent transactions and informs the Auditor.
For more on the Private Network Auditor role, its capabilities and its responsibilities, see the Private Network roles page.
Updated about 1 month ago
