Private Network design options

A Rayls Private Network is multiple Rayls Sovereign chains connected together via a central Hyperledger Besu chain, the Private Network Hub. Each participant runs its own Rayls Sovereign chain (Privacy Node in the code). Every network has that shape, but the operator and the participants make a number of choices when they set one up. This page lists the choices the code supports, then shows two example designs.

The choices

How many participants

There is no fixed limit on participants in the Hub's registry. If the network will use Enygma for private payments, the number matters for privacy: each Enygma transaction hides its receiver among up to six participants (k = min(participants, 6)).

With two participants, each knows the other is the only possible receiver. Amounts stay hidden.
With three, a participant that is in a transaction and receives nothing learns who did.
With four or more, the anonymity set works as intended.

See The anonymity set and small networks.

Who can issue tokens

Each participant is registered as an issuer or a participant. Only an active issuer can register a token on the Hub; participants can hold, send and receive tokens that issuers have registered. Make only the institutions that should create assets issuers: a central bank in a CBDC (central bank digital currency) network, or every bank in a network where each bank issues its own assets. The operator can change a participant's role later.

Who can broadcast

Each participant has a broadcast permission. With it, the participant can send one message to every other participant at once. Without it, it can only send messages to named chains.

How governance powers are split

The account that deploys the Hub contracts holds ADMIN on the Hub and can do everything. To separate duties, grant the Hub's business roles to different accounts, departments or organisations:

PRIVATE_NETWORK_OPERATOR adds participants and changes their role and status, approves tokens and approves contract templates;
COMPLIANCE_OFFICER freezes and unfreezes tokens for chosen participants.

Any role grant can carry an execution delay, so that the holder must schedule each action and wait before it takes effect, and a guardian role can cancel it in the meantime. Each participant makes the same choices for its own chain. See Private Network roles.

Who can read cross-chain traffic

There is one view key pair per network. Each participant's view private key is encrypted to its public half when the participant registers, so whoever holds the secret half can decrypt every cross-chain message and every Enygma transfer in the network. In the code, the operator's governance services hold it.

There are no scoped or configurable levels of decryption, and no separate auditor key. A regulator that needs visibility can be given access to the Auditor Explorer, which shows the whole network. Choose the operator, and the people with access to its tools, accordingly. See Who sees what.

Which token types to use

Enygma tokens for private payments between chains: amounts and receivers are hidden from the other participants.
DvP (delivery-versus-payment) tokens, ERC-721 and ERC-1155, for assets exchanged against Enygma tokens in a private, atomic swap on the Hub.
Standard ERC-20, ERC-721 and ERC-1155 tokens, and a stablecoin variant of ERC-20, registered on a participant's chain. An Enygma transfer can mint or burn them on arrival, as a program step.

See Supported token standards.

Which contracts transfers may call

An Enygma transfer can call contracts on the receiving chain when it arrives, but only contract code and functions approved in the Hub's template registry. The standard Rayls token templates are seeded at set-up. Anyone can propose another template; the operator approves or revokes it. See Programmable transfers.

Example 1: a CBDC network

A central bank wants commercial banks to settle in a wholesale CBDC, privately from each other.

The central bank is the operator. It runs the Hub, the governance services and the Auditor Explorer, and deploys the Hub contracts. It grants PRIVATE_NETWORK_OPERATOR to its network operations team and COMPLIANCE_OFFICER to its compliance team, with an execution delay on the compliance role if it wants a waiting period before freezes take effect.
The central bank also runs a Rayls Sovereign chain as the issuer. It registers its own chain with the ISSUER role. The CBDC is an Enygma token, deployed on that chain, then submitted to the Hub and approved. See Running Rayls Enygma.
Commercial banks join as participants. Each runs its own Rayls Sovereign chain, private relayer and key service, and is registered with the PARTICIPANT role, so it can't register tokens of its own. With four or more banks, Enygma hides which bank received each payment from the other banks.
Banks pay each other with Enygma. Amounts and receivers are hidden from the other banks. The central bank, as operator, can read every transfer. Mints and burns, which change the money supply, are public on the Hub.
Oversight. If a separate regulator needs visibility, the central bank gives it access to the Auditor Explorer. To act on a problem, the compliance team freezes the CBDC for a bank, or the operations team freezes the bank itself.

Example 2: a tokenised asset network

A registrar runs a network in which banks issue bonds and trade them against a tokenised cash leg.

The registrar is the operator. It runs the Hub and the governance services and approves every token before it can move between chains. The Hub rejects a second token with the same name.
Banks join as issuers. Each issues its bonds on its own Rayls Sovereign chain as DvP tokens (ERC-721, or ERC-1155 with fungible token IDs), and submits them to the Hub for approval.
A cash token issuer joins. A stablecoin provider joins as an issuer and issues an Enygma token, which the banks hold on their own chains.
Banks trade bonds against cash with private DvP. Both legs settle in one transaction on the Hub, or neither does, and the terms are encrypted for the counterparty. Deposits and withdrawals of ERC-721 bonds are visible on the Hub. See Private DvP with Enygma.
Oversight. The registrar sees every transfer and swap in the Auditor Explorer, and the flagger flags any bank whose chain stops reporting block headers to the Hub. Any action, such as freezing a token for a bank, is a separate transaction by an authorised account.

Not in the production release

These options aren't part of the production release today. Some can be developed for a client's own deployment; don't design around them otherwise:

configurable or scoped decryption levels, a separate auditor key, or an auditor that can see only proofs and not data;
an auditor that can decrypt only after fraud is detected;
automatic actions, such as freezing, triggered by a flag. The flagger only records flags, and no contract that acts on them is provided;
governance by a DAO (decentralised autonomous organisation) or by token-holder votes, and automatic approval of participants or tokens;
a Private Network secured, or audited, by Rayls Public Chain validators;
participants publishing Pedersen commitments of their balances to the Hub for an auditor to check. Only Enygma balances are held as commitments on the Hub.