Let's take a deeper look at the components of a Rayls Private Subnet and how they work together to enable privacy, scalability, interoperability, governance and auditing, all at the same time within a decentralised network.

Each Rayls Private Subnet is comprised of a Subnet Hub and many Subnet Rayls Privacy Nodes.

For simplicity, the architecture diagram below only shows the connection between one Rayls Privacy Node and the Subnet Hub, but the same setup would be true for any number of Rayls Privacy Nodes.

Let's take a look 👀

📘

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 Subnet, there are three main user personas:

1. A Rayls Privacy Node Operator User

This user is a transacting financial institution that installs their Rayls Privacy Node Operator Package within their own environment, securely and privately behind their own firewalls.

Using this infrastructure, the Rayls Privacy Node Operator User can interact with their Rayls Privacy Node in different ways to manage their customer accounts, query balances, instruct internal and cross-Subnet transactions (via Rayls Custody), and view those transactions within their Rayls Privacy Node Ledger transaction (block) explorer.

The Relayer is installed when a Rayls Privacy Node joins a Private Subnet to orchestrate the private teleport of arbitrary messages and tokens with other Rayls Privacy Nodes via the Rayls Protocol across the Subnet Hub.

For more information about what a Ledger is, how it works, and its benefits, check out the A warm introduction to Rayls Privacy Node page.

2. A Subnet Governor User

This user is the authority of a Rayls Private Subnet and it is their responsibility to install and maintain the core infrastructure of the Private Subnet, including the Subnet Hub, Rayls Protocol, Registries, and Smart Contracts, and to define the governance rules that regulate the network.

Rayls provides a number of tools to support a Subnet Governor to perform these tasks and govern effectively, including:

1. Rayls Custody For secure, HSM-based key custody, only the Governor should have the power to sign governance rules and decisions into effect, using their private key.
2. Governance rules engine to easily enforce governance actions using out-of-the-box rules engines and workflows, such as approving a new member to join the Subnet or freezing a member from being able to transact. The Rayls team continues to release new rules that can be used out of the box, alternatively, developers can create their own custom governance rules using smart contracts.
3. Member registry to easily maintain a list of approved Subnet members, their roles, and statuses - roles like Participant or Issuer and statuses like Active or Frozen.
4. Token registry to easily maintain a list of registered tokens and their statuses (like Active or Frozen) - note that only approved, Active tokens are able to be transacted across the Subnet. If a token has not had its registration approved or does not have an Active status, the transaction will fail.

For more information about the Subnet Governor user role, capabilities, and available governance rules, take a look at the Private Subnet roles page.

2. A Subnet Auditor User

This user is responsible for ensuring the validity, consistency, and legitimacy of the Private Subnet. As a regulator of the Subnet, they receive and validate (Pedersen) state commits and may be given read-only access to "peek" into the encrypted transactions published to the Subnet Hub to secure the network and identify potentially fraudulent transactions.

Rayls provides a number of tools to support the Subnet Auditor, including:

1. Subnet transaction (block) explorer - to view encrypted cross-Subnet transactions recorded to the Subnet hub. This Subnet transaction block explorer can also be accessed by all Rayls Privacy Nodes within the Private Subnet to confirm the status of cross-Subnet transactions and that they have been correctly recorded to the ledger, matching transactions with their own Ledger transaction (block) explorer.
2. 'God view decrypter' - Rayls provides a configurable level of decryption that a Subnet Auditor can exercise to decrypt the encrypted transaction data from the Subnet Hub, as determined by the Subnet Governor. The Governor may give the Auditor no visibility at all, or complete power to decrypt all transaction data. See the Private Subnet Design Options page for more information.
3. Transaction and state validation - The Subnet Auditor continually checks the consistency between net transactions and reported Rayls Privacy Node Ledger balances via the regular (Pedersen) state commits provided by each Rayls Privacy Node Ledger. If there are discrepancies between these values, a 'Flagger' tool automatically captures potentially fraudulent transactions and informs the Subnet Auditor.

For more information about the Subnet Auditor user role, capabilities, and responsibilities, have a read of the Private Subnet roles page.