From the earliest days of blockchain technology, the main proposed use case has been a peer-to-peer version of digital cash. This system allows for online payments to be sent directly from one person to another, without the need to involve a financial institution.

Unfortunately, as we have discussed in many previous articles, blockchains in the current form do not scale well. This inability to process a high transaction volume per second is the main hindrance to wider spread adoption of the technology.

Blockchains require a global consensus of the order and outcome of all transactions. In order to avoid the double spending issue, every node needs to learn about all updates to the shared ledger. In this setup, hardware and bandwidth constraints set a limit on the number of updates per second that can be shared in a decentralized peer-to-peer network.

What is the Ethereum Raiden Network?

The Ethereum Raiden Network aims to provide fast, cheap, scalable token transfers for the Ethereum blockchain. This article will discuss and illustrate the basic functionalities of the Raiden Network.

The basic idea behind the Raiden network is to avoid the bottleneck that can occur during blockchain consensus. This is accomplished using a network of Payment Channels, these channels have the ability to make secure value transfers Off-Chain. The Raiden Network has a lot of the same functionality of Bitcoin’s Lightning Network. If you are interested to learn more about the Lightning Network, this article provides a deep dive into the capabilities.

What is a Payment Channel?

A payment channel enables a sender to make off chain payments to a receiver and is always backed by on an on-chain deposit of tokens.

When making a payment the sender signs a Balance Proof to the receiver. A balance proof is the equivalent of a digital check. A balance proof cannot exceed the number of tokens held on-chain by both parties.

The advantages of using a payment channel are that transactions are much faster and cheaper than transactions that happen on the main blockchain.

Opening a payment channel with everyone that you know can become costly, as each channel requires an on-chain deposit. This obstacle lends perfectly to the need for a network, the Raiden Network, a network of payment channels.

What is a Payment Channel Network?

A Payment Channel Network allows users to pay anyone in the network utilizing a path of connected payment channels to route the payment. Even if 2 users do not have a direct payment channel with one another, they can still send funds to anyone within the network. This is done by routing the funds through connected intermediaries within the network.

What is the Raiden Network Protocol?

Payment channels introduce the concept of connecting nodes together in a network of trust to allow payment facilitation from one person to another. The Raiden Network Protocol is the set of rules that are in place to govern transactions on the network.

The main function of the protocol is ensuring that all nodes follow the same set of rules when sending and receiving payments.

Mediated Transfers

First, we will look at how the Raiden Network Protocol handles a mediated transfer. A mediated transfer can be thought of as a non-direct transfer. The network utilizes different payment channels to establish the most efficient route from sender to receiver. This functionality allows users to send money to everyone without having to tie up funds in many different payment channels.

For this example, Alex will send a payment to Dennis. He will execute this mediated transfer using payment channels set up between Alex, Becky, Carmen, and finally Dennis. The payment is sent across payment channels from Alex to Dennis, and the transaction is locked as a pending transfer. This means that it will require a secret passcode before it can be claimed for tokens.

When Dennis receives the payment transfer, he requests the passcode from Alex. Alex receives the requests and sends the passcode to Dennis, and he uses it to unlock his pending transfer.

Dennis then sends the passcode to Carmen. She signs a Balance Proof reflecting the added value of the unlocked pending transfer. The balance proof is then sent back to Dave. The protocol is then followed backward until the secret passcode is revealed to everyone involved with the mediated transfer.

What About When it Fails?

Mediated transfers are great when they work, but what happens when they fail? If one of the mediating nodes stops responding after the secret passcode has been requested, it would not be possible to unlock all pending transfers before the locks expire.

In this case, Dennis would submit the secret passcode to a smart contract located on the Main Chain known as the Secret Registry.

Once the secret passcode is registered on-chain, the mediating nodes can access the secret. This allows them to unlock their pending transfers and send back the signed and updated balance proof to their counterparty. We will discuss the role of the Secret Registry later in this article.

Sending Multiple Pending Transfers

To keep track of pending transfers, nodes on the network utilize Merkel Trees. A Merkel tree is a data structure where the root of the tree is the hashed value of all the data contained within the tree. This structure allows for the root, sometimes called the root hash, to be a representation of all the data contained in the Merkel tree.

A Merkel tree is structured in such a way that if one piece of data is altered in any way, it will also change the Root hash.

During a mediated transfer all mediating nodes add the mediated transfer to their Merkel tree. As new pending transfers are created, each mediating node checks that the root hash of the tree matches what they have stored locally.

In this example, Becky will mediate several transfers for Alex. To make sure that Alex is not cheating the system, Becky will construct a Merkel tree of all the pending transfer that she expects to claim from Alex.

Transfer 1

Alex wants to send payment to Carmen, he will use Becky as the mediator. Becky now has a pending transfer called Transfer 1 which will remain locked until the payment is completed. Becky updates her Merkel tree to contain the locked pending payment, Transfer 1.

Transfer 2

Alex now needs to send a payment to Dennis, and he will again use Becky as the mediator. With this transfer, Alex also sends the root hash of his own Merkel tree, Becky runs a computation on the root hash provided by Alex and sees the same lock from the previous transaction. This ensures to Becky that Alex is not trying to get out of paying for the 1st transaction because it still shows as pending. Becky now updates her Merkel tree to include the locked pending Transfer 2. This update also changes the Root Hash of Becky’s Merkel tree, as it now contains 2 transactions.

Transfer 3

Alex now sends a 3rd payment, Transfer 3, this time sending payment to Elaine. Again Alex uses Becky to mediate the transfer of funds between him and Elaine. This is where the benefits of the Merkel tree become apparent. It is sufficient for Alex to send just his Root hash along with the new transfer to Becky. Alex does not need to send a list of all the pending transfers, because Becky can do the calculation herself by matching the root hashes to ensure Alex is not cheating.

Transfer 4

Now a 4th payment is sent from Alex to Fred, again Becky serves as the mediator for Transfer 4. The root hash that Becky receives matches what she has stored locally on her Merkel tree. She then adds the 4th pending transfer to her tree. At this point, all Alex is doing is sending a new lock that represents the new transfer, and the root hash from the previous Merkel tree. This can go on indefinitely as long as there are sufficient funds within the payment channel to back up the payments.

Settling Pending Transfers Off-Chain

The protocol continues, and Dennis now requests the code from Alex to unlock his pending transfer. Dennis receives the code and proceeds to send it to Becky, she can now unlock Lock 2 which contains the payment sent to Dennis. Becky then sends the secret back to Alex who in turn pays Dennis. Once this is complete Becky’s Merkel tree will also update to no longer contain the Locked Payment associated with Transfer 2, this also updates the Root hash of the tree.

Merkel Trees

All nodes within the network have one Merkel tree per channel direction. Merkel trees allow a cryptographic representation of a large number of transactions using a single value known as the Merkel Root. This value allows the Raiden Network Protocol to deal with a large number of pending transactions simultaneously.

Settling Multiple Pending Transfers

Now we will learn how the Raiden Network manages settlements when there are multiple pending transfers.

We will revisit the previous scenario; Becky still needs to unlock pending transfers for Carmen, Elaine, and Fred. There is just one problem, Alex has stepped away and is now offline.

Token Network Smart Contract

Carmen sends Becky the code to unlock Transfer 1 so that she can claim the pending transfer. However, Alex has closed the payment channel prior to sending the updated balance proof back to Becky. Due to this, Becky has to resolve the locks for Transfers 1, 3, and 4 On-Chain.

Becky starts by registering the secret codes that she knows already in the Secret Registry on-chain. In this example, Becky will register the Secret Code from Lock 1 that she received from Carmen. Next, Becky provides the Token Network Contract with the latest balance proof from Alex (the same information that unlocked Transfer 2).

The Token Network Smart Contract checks that the signed Balance Proof that Becky claims is from Alex is authentic. This is done by cryptographically recovering the address used to sign the balance proof, and verifying that it belongs to Alex.

Settlement Window

After the settlement window has passed, no additional balance proofs can be submitted. Next Becky submits her locally stored Merkel tree which is checked by the Token Network Smart Contract. The system computes the root based on the 3 locked transfers that have been submitted. If the computed Root matches the previously submitted Merkel root from Becky, we can safely conclude that the locks submitted to the smart contract are valid off-chain transactions.

The Token Network Smart Contract now needs to payout the pending transfers to their rightful owners. The smart contract first checks to see if any of the locked secret passcodes are known by the Secret Registry. In this case, Carmen provided the secret to Becky, making the secret to Transfer 1 known by the registry which unlocks it for Becky allowing her to pay Carmen.

Transfers 3 and 4 still remain locked, as they were never completed, and the secret code was never released. After the time duration elapses, the transactions expire and the funds are returned back to Alex.

Conclusion

The Raiden Network aims to address issues associated with the scalability of the Ethereum blockchain. What sets the Raiden Network apart is the ability to execute off-chain smart contracts.

Cryptocurrency Prices:



ALL Prices listed as of the time of publishing this Article

Bitcoin: $4,058

Ethereum: $156.75 (Note this is 7 days before Constantinople Hard Fork. Up 15% last day, and 55% last 30 days)

XRP: $0.37

Bitcoin Dominance: 51.6%



References:

https://raiden.network/

https://raiden.network/101.html

https://github.com/raiden-network/raiden