Raiden Protocol Explained

A few weeks ago, we published a video explaining the underlying logic behind Raiden. This article breaks down the video’s content into reading content and infographics.

We will guide you through the basics of a payment channel network, as well as the mechanics of mediated transfers, routing and handling of multiple pending transfers.

Payment Channel Network Basics

Payment channels enable tokens to be exchanged between counterparties off-chain. A payment channel in Raiden is always backed by an on-chain deposit of tokens.

When making a payment, the sender signs a balance proof to the respective receiver. As an analogy, balance proofs can be imagined as a form of digital checks. They cannot exceed the amount of tokens held on-chain by both parties respectively and are therefore guaranteed to be redeemable for tokens.

Payments executed via a payment channel have the potential to be orders of magnitude faster and cheaper than on the blockchain. However, opening payment channels with counterparties costs gas and requires an on-chain deposit preventing the tokens from being used while held as deposit. Luckily, this downside can be mitigated, since in a payment channel network, users do not need to open channels with everyone they want to pay.

A payment channel network lets users pay anyone in the network by using a path of connected payment channels to mediate the payment. Within a token network, many payments can happen concurrently and independently of each other.

In order to ensure that all users behave in a fair way, a set of rules to govern the network is required. The Raiden Network protocol ensures that all nodes follow the exact same rules when sending and receiving payments.

Mediated Transfers

Mediated transfers use several payment channels to finalize a payment, allowing users to make payments with other users they don’t necessarily have a payment channel with.

In the example below, Alice sends a payment to Dave using the channels between herself, Bob, Charlie and Dave. This payment is locked as a pending transfer which means that it requires a secret before it can be claimed for tokens.

Upon receiving the transfer, Dave requests the secret from Alice. Alice sends Dave the secret, which he uses to unlock his pending transfer. Dave sends the secret to Charlie who signs a balance proof reflecting the added value of the unlocked pending transfer and sends it to Dave. The protocol is then followed backwards until the secret is revealed to everyone in the mediated transfer route.

If one of the mediating nodes stops responding (e.g. because it is offline) after the secret has been requested, it will not be possible to unlock all pending transfers before the locks expire.

In such an instance, Dave can instead submit the secret to a smart contract called the secret registry. Upon registering the secret on-chain, the mediating nodes can see the secret, unlock their transfers, and send a signed updated balance proof to their counterparty.

Routing

In order to successfully conduct a mediated transfer, a path of payment channels with sufficient capacity between sender and receiver is needed.

Capacity means that the payment channels used for the payment have sufficient tokens to create pending transfers in all required channels.

In our example, Alice wants to pay Dave 3 tokens, so she needs to find a route of connected channels with a capacity of 3 in the mediating payment channels.

The Raiden Network protocol has a full picture of the network and all initial channel balances. Suppose all users have deposited 5 tokens per channel and have already made some transfers. The protocol then tries different paths until one with enough capacity is found:

1. Since Alice has 5 tokens and Bob has 5, there is sufficient capacity.
2. Bob has 4 tokens allowing the payment to continue.
3. Since Charlie only has 2 whereas Dave has 8, this route is not possible.
4. Charlie initiates a refund transfer that Bob will claim.

The Raiden Network protocol now tries a path via Earl, Frank and Gary which works because there is sufficient capacity in all channels.

Since Dave has received the payment, he now requests the secret from Alice, allowing all participants to unlock their transfers and sign new balance proofs to their counterparty.

In the future, auxiliary services like pathfinding will make it easier to find a route with sufficient capacity to mediate transfers. Pathfinding services will be included in the upcoming Ithaca release.

Handling of Multiple Pending Transfers

In order to manage several pending transfers, nodes keep a local state in the structure of a Merkle tree.

A Merkle tree is a data structure, in which the root of the tree is the hashed value of the data contained in the tree. Merkle trees allow for a concise cryptographic representation of a large number of pending transfers with a single value; the Merkle root. If one data point is removed from the Merkle tree, the root will change.

In the Raiden Network, every node has one Merkle tree per channel per direction.

During a mediated transfer, every mediating node adds the mediated transfer to their Merkle tree. As new pending transfers are created, the mediating node checks if the root of the tree matches their local state.

This design allows the protocol to deal with 160 pending transfers per channel. The limit to 160 is a rounded value that ensures the gas cost of unlocking will be less than 40% of Ethereum’s traditional pi-million (3141592) block gas limit; also see the Raiden docs for more info.

In our example, Bob will mediate several transfers for Alice. To make sure that Alice isn’t cheating, the protocol will construct a Merkle tree of all the pending transfers that Bob expects to claim from Alice:

• Alice wants to pay Charlie using Bob as the mediator.
• Bob has a pending transfer called transfer1 which is locked until the payment is completed. He updates the new lock1 to his view of the Merkle tree.
• Alice sends another transfer to Dave using Bob as the mediator. In this transfer, she also sends the root of her own tree.
• Bob computes the root and sees the same lock1 as before, so he knows that Alice isn’t cheating since transfer1 is still pending.
• The root of Bob’s tree changes and now contains information about both locks: lock1 from the previous transfer to Charlie and lock2 from the transfer to Dave.
• Alice sends a third transfer to Erik, using Bob as the mediator.
• It is sufficient that Alice only sends the Merkle root and the new transfer to Bob. She does not need to send the previous pending transfers because Bob can compute the root and verify that Alice has the same number of pending transfers as he expects. (Here the benefits of using a Merkle tree structure become visible!)
• Alice sends a fourth transfer to Frank using Bob as the mediator.
• The root Bob receives is consistent with his local state and he therefore adds the fourth lock to his Merkle tree.
• Alice consistently sends no more than a new lock and the root from the previous Merkle tree regardless of the amount of transfers sent.

• Dave requests the secret to unlock his pending transfer.
• Dave receives the secret, sends the secret to Bob who proceeds to unlock lock2 containing the payment to Dave.
• Bob then sends the secret to Alice who proceeds and sends a signed balance proof to Bob.
• The Merkle tree no longer contains lock2 and consequently the Merkle root has changed.

Off-chain Unlock of Multiple Pending Transfers

We already learned that nodes can become unresponsive during a pending transfer, which results in the secret being registered on-chain in the secret registry.

Next, we will show how the Raiden Network protocol manages unlocks if there are multiple pending transfers.

In the example, Bob still needs to unlock his pending transfers to Charlie, Erik and Frank, the only problem being that Alice has closed the channel.

• Charlie sends Bob the secret to unlock lock1 so that Bob may claim his pending transfer.
• However, Alice has closed the channel and never sent Bob an updated balance proof. Therefore, Bob has to resolve the locks1, 3 and 4 on-chain.
• Bob starts by registering the secrets which are currently known to him. In this case, the secret of lock1, which he received from Charlie.
• Bob provides the token network contract with the latest balance proof from Alice which unlocked lock2.
• The token network smart contract checks that the signature Bob claims is from Alice, is authentic. This is possible by cryptographically recovering the address and checking if this address belongs to Alice.
• After a settlement window has passed, no further balance proofs may be submitted. Then, Bob submits his local state in form of his Merkle tree which gets checked by the token network smart contract.
• It computes the Merkle tree root from the three submitted locks. If the computed root matches the previously provided Merkle root, it is certain that the locks that were provided to the smart contract, are valid and that they represent the reality of events that happened off-chain.

• The token network smart contract now needs to pay out the pending transfers to the rightful owners.
• The smart contract first checks if any of the secrets are known to the secret registry.
• In this case, lock1’s secret was known and therefore, this transfer belongs to Bob.
• The pending transfers locked up by lock3 and lock4 were never completed and therefore expire and Alice is refunded.

Summarizing the example, the settlement process of pending locks ensures that pre-allocated funds, which had been secured by locks, get unlocked either to the receiver or to the sender of the payment. The direction is determined by whether or not the secret is known. If the secret is revealed off-chain then no on-chain interaction is required. If the counterparty is unresponsive, the blockchain can always be used to guarantee safe transfers.

We hope you enjoyed this little deep dive into the basic principles of the Raiden protocol.

If you’re curious to learn more about the Raiden Network, please feel free to try the software yourself or check out our documentation. For any technical question, shoot us a message in our Gitter chat.

Last but not least, we’re still hosting a bug bounty for the Raiden Red Eyes code. If you are a bounty hunter, you can check the bounty rewards and submission rules here.

The Raiden Team

Make sure to stay up to date by following us on Twitter and Medium and joining the conversations on Reddit and Gitter!

The Raiden project is led by brainbot labs Est.

Disclaimer: The provided content may contain views and opinions, errors and omissions by which the content creator(s) and any represented organizations 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.