Raiden Service Bundle Explained
The introduction of Raiden Services, namely monitoring and pathfinding services, aims to enhance the overall user experience of the Raiden Network by
a) finding short or cheap routes through the network and
b) allowing users to go offline safely by watching open payment channels.
In this context, the Raiden Service Bundle (RSB) registry is planned to list all service providers, which are offering monitoring and/or pathfinding services.
This blog post gives an update on the first set of Raiden Service implementations, elaborates on the envisaged design and function of the RSB Registry and explains how the Raiden Services will interact with the RSB Registry.
Development update on the Raiden Services
Monitoring Service (MS)
Monitoring services can watch open payment channels when the user is not online. In case one channel partner closes a channel while the counterparty is offline (or doesn’t react for 80% of the settlement timeout after close has been called), the monitoring service sends the latest balance proof to the channel smart contract and thus ensures correct settlement of the channel.
How does the first implementation of an MS work step-by-step?
- Whenever Alice wants to have one of her channels monitored, Alice deposits RDN tokens to the UserDeposit contract.
- She then starts sending balance proofs (including the token network, channel ID, nonce and hashed balance value, as well as reward for the monitoring service) to a public chat room, where the MS can read them.
- Updates should be sent to the MS whenever the state of the channel changes, while the sent balance proof does not expose the actual balance values, as it is hashed.
- The MS picks up the messages and listens to on-chain events regarding this particular channel. The MS can choose to only pick up requests above a certain minimum reward.
- Whenever the channel is closed, the MS gives the channel participants time to update the channel state on their own, before calling the updateNonClosingBalanceProof function with the provided balance proof.
- Then, the settleChannel function can be called to calculate the correct token distribution between the two channel partners.
- Alice or Bob can call settleChannel and initiate the token distribution at any time. It can only be executed by submitting the corresponding balance values of the hashed balances provided before.
- This will result in a correct distribution of tokens, in accordance with the netted balances of the conducted off-chain transfers.
- After a successful submission of the hashed balance by the MS, the MS can claim an on-chain payment from the respective smart contract where Alice deposited RDN tokens (see claimReward function).
To minimize the probability of collisions between different MSs watching the same channel, the settlement period gets divided into three sections:
- First, only the non-closing participant is allowed to update the channel details.
- In the next section, each MS gets a pseudo-random block, from when it can update the channel on behalf of a user (see firstBlockAllowedToMonitor). This order is unique for each channel, so that in the long term, each MS has the same probability to react first.
- In the last section, all MSs are allowed to update, if this hasn’t been done already.
The decreased probability of collisions between the different MSs has a positive influence on efficiency and hence leads to an overall price reduction of monitoring services for the user.
For a more detailed description and Q&A about the MS please also see this issue.
Pathfinding Service (PFS)
Pathfinding services can support users in finding e.g. the cheapest or shortest path to route a payment through the network. A pathfinding service relies on data about the network, from the respective smart contract as well as on information provided voluntarily by mediating nodes, such as the mediation fees charged and the available channel capacities. In the current design, the user will be able to select the shortest or cheapest route. The quality of the pathfinding service will improve with the number of mediating nodes sharing their updates.
How does the first implementation of a PFS work step-by-step?
- In order to reduce friction, the Raiden client aims to know a possible path before initiating the process of sending a payment.
- Therefore, an overview of the current state of the network graph, that is the current capacities of the channels and the presence of the nodes, is required. Comparing this to finding your way in a traffic situation, one could say that you need to know the street map and current traffic from home to your destination.
- The smart contract only has information about the existence of channels, deposits as well as withdrawals. That means nodes don’t know the current capacity of any channel other than their own. In our comparison, the nodes would just know that there is a street, but they’d have no knowledge about whether the street is wide enough for the car to go through.
- Therefore, the first implementation of the PFS keeps track of the current state (capacity changes and presence) of the network and provides paths in exchange for a small fee paid in RDN.
- Nodes can send capacity updates to a public matrix room informing the PFSs about the current state and advertising their channel for mediation. Currently, this is the default option.
- The PFS will only consider a channel and reflect the reported capacity in its routing algorithm if both channel partners send the above mentioned capacity updates to the public matrix room.
- In case a node prefers to stay private and doesn’t want to mediate payments, it can opt out of sending capacity updates. Consequently, it will not be considered for mediation and the node’s capacity will be assumed 0.
- In the current setup, nodes can choose a PFS provider themselves out of a number of registered service operators, which are listed in the Raiden Service Bundle registry.
- For a client to request a path from a PFS, the PFS provides an API via HTTP. Together with the path request, the Raiden node sends a signed IOU that references to a deposit of RDN tokens in the UserDeposit contract.
- For any subsequent request of the same node, the IOU simply increases such that the PFS can wait as long as it wants before cashing out the growing IOU balance from a particular client.
Regarding the continuum between privacy and efficiency, this implementation of the PFS can be categorized to be efficiency-oriented. Nodes can opt-out and stay anonymous at the cost of not being preferred as mediating nodes.
For a more detailed description please also have a look at the Raiden Pathfinding Service specification.
Who can operate Raiden Services?
Technically, anybody can operate Raiden Services. In order to run a Raiden Service, a server with high uptime is needed. Furthermore, operators require an Ethereum Address to receive the fees and an Ethereum RPC endpoint. Running your own full Ethereum node is not technically required, but highly recommended.
Additionally, service operators will be required to stake RDN in the RSB registry. More details about the staking process will be published soon in a separate post.
What is the role of the RSB registry?
The RSB registry lists all addresses that are eligible to operate services on the Raiden Network. Staking is used as a means to avoid spam and preventing service operators from providing multiple faulty or bad services at once at no cost.
Closing Remarks
Please note that for both the MS and PFS, the above described models represent just one possible implementation, which can be used by service providers out of the box. The use of other strategies, fee models and algorithms is by all means thinkable and we are looking forward to seeing different implementations by various contributors over time.
The Raiden Team
Disclaimer: Please note, that even though we do our best to ensure the quality and accuracy of the information provided, this publication may contain views and opinions, errors and omissions for which the content creator(s) and any represented organization cannot be held liable.
The wording and concepts regarding financial terminology (e.g. “payments”, “checks”, “currency”, “transfer” [of value]) are exclusively used in an exemplary way to describe technological principles and do not necessarily conform to the real world or legal equivalents of these terms and concepts.
