Technicalarchitecture

The RLN

The RLN is a global network that will store a sequenced set of state changes in order to create an unambiguous distributed ledger of token balances. The state changes and balances will be made immutable through a hash chained log of all transaction hashes. Every user of the RLN will only have access to the transactions and the part of the global state that they are privy to. The global state will be split into different views and stored with the stakeholders of that data. The resulting virtual global state is stored in a highly distributed and flexible manner and will contain additional objects to assist in the operation of the network, including the network map and other necessary information such as instrument identifiers.

The RLN will implement the following process for transactions submitted for settlement:

1. Propose: A proposal is a desired change to global state comprising changes to one or more partitions. The RLN will then determine all the required state changes to complete the proposal.
2. Authorize: A proposal cannot change state until it is authorized by every partition that it impacts. Once all required authorizations have been collected, the finalization of the transaction is communicated to all relevant parties. This step defines the finality of the transaction and triggers the effective settlement.
3. Persist: Authorized proposals are made persistant by the individual participants’ ledgers – be it a classical backend implementation, a different DLT, or a ledger on the RLN network itself.

Technical Architecture Diagram

The RLN passes messages and state updates between participants.

The above illustration of the RLN shows the various ways users can interact with the RLN and the components involved in a transaction. Users interacting with the RLN can utilise proprietary or traditional ISO Messaging

• ISO Messaging participant accesses the the RLN using ISO20022 messages (pacs.008) and receives requests for approval and confirmations from the RLN allowing them to screen transactions and to maintain their ledger/store data. Messages are sent and received via a secure Kafka message queue.

ISO Messaging allows participants to interact via a pacs.008 message. This is an ISO Standard 20022 message (Financial Institution to Financial Institution Customer Credit Transfer) designed to capture the data required for our most common type of transaction (please note other message types can be incorporated). The below provides a view of additional components as part of the RLN.

Components

Scheduler

The scheduler constructs the settlement chain for this transaction to take place, it does this by using a network map to define all the intermediaries who are parties to the transaction.

Assembler

The assembler is responsible for collecting and verifying the signatures of all partitions required for the proposal to be accepted.

Synchroniser

The Synchroniser keeps the different components in sync. and can be effectively seen as a synchronisation ledger, maintaining synchronicity between different ledgers.

The Synchroniser also ensures the data is only shared with entities that are allowed and supposed to the see the data. This is different to a public blockchain where everyone who has a node can see what is happening on the blockchain.

The Network Map

The network map is not a component, rather it is data that documents settlement connections between partitions for each instrument. Each partition that issues a liability denominated in a particular asset will register a single settlement destination (partition) for that asset. Partition owners will be able to change their settlement partition for any of its instruments at any time but can only have one settlement partition for each instrument at a time.

Process Flow

Below diagrams provide a more granular view of the steps required from initiation to finalisation. This is divided into 4 stages: Transfer Initialization, Request for Approval, Approvals and Finalisation.

• 1) User initiates transfer, submits to the local participant node.
• 2) The local participant node submits the transfer to the Network.
• 3) The Network transmits the transfer request to the Scheduler.
• 4) The Scheduler recieves and validates the transfer request.

• 1) The Scheduler determines the settlement chain and sends the scheduled request to the Network.
• 2) The Assembler receives the settlement manifest and awaits Approvals.
• 3) The Participant recieves a transfer proposal to which it will respond.
• 4) The UI is updated to reflect the pending Approval.

• 1) The UI Instructs Approval.
• 2) The Participant submits the Approval to the network.
• 3) The Assembler aggregates Approvals until consensus is established - The protocol required unanimous acceptance form all parties involved in a transfer for Approval. Any rejection is final.

• 1) Once Consensus is reached, either Acceptance or Rejection, the Assembler submits a finalisation message to the network.
• 2) The Participant receives the Finalisation message and updates the local ledger as appropriate.
• 3) The Participant updates the local UI.