First version of Raiden Network successfully deployed on Ethereum

Raiden, a protocol for scaling token transfers on Ethereum today announced that the Raiden Network Red Eyes release is live on the Ethereum mainnet. The Red Eyes release is the first Raiden release on the Ethereum mainnet. Red Eyes is an alpha testing release, not production ready, and is intended only for testing the Raiden Network (RDN) on the mainnet.

The Raiden team says it is “crucial to read the security notes carefully before using the software.” They also stressed to the community that everybody is welcome to test it on the mainnet by doing token transfers and taking part in the bug bounty.” The main goal of this release is to have the smart contracts and the core protocol battle tested on the mainnet.

Features Included In The Red Eyes Release

• Opening, topping up, closing and settling of payment channels
• Single and multi-hop transfers
• Automatically joining a token network and opening channels with peers
• REST API with endpoints for all functionalities
• Redesigned WebUI
• Raiden Explorer, visualizing the live status of the Network
• Rewritten and more gas efficient smart contracts (i.e. only one contract per token network)
• Improved protocol for dealing with edge cases
• Recoverability in case of an irregular shutdown of the Raiden node
• Integration of the Matrix transport protocol for messaging

Safety Measures For The Red Eyes Release

Since the Red Eyes release is an alpha deployment of the Raiden network on the Ethereum mainnet, the team has put in place strong risk mitigation measures to limit the potential damage caused by bugs or misuse of the software and to ensure a responsible testing environment for this nascent technology. Also as noted, the Red Eyes release is not security audited by an external party yet.

Deposit limits are 0.15 ETH per channel / 250 ETH total maximum network value, plus a deprecation switch has been put into place. Additionally, the Red Eyes version of the Raiden Network is limited to one token network, wETH (wrapped Ether).

Limitations Of The Red Eyes Release

Feature limitations in the current release include:

• Monitoring – No support for third-party services to monitor channels on behalf of nodes
• Routing – No support for third-party services which can offer pathfinding services (through knowledge about channel capacities).
• Atomic Swaps – No support for atomic token swaps
• No upgradability of the token network – TheRed Eyes milestone does not include upgradability of the smart contracts. In other words, the only way to upgrade the network would be to redeploy new contracts and release a new client version pointing to the new contracts. All channels in the old network would need to be closed and reopened in the new network. As already outlined above, the team has implemented a one-time deprecation switch in order to be able to deprecate the network, if needed.

The Raiden team aims to tackle some of these functional limitations working towards the Ithaca milestone.

Important Security Notes

• Ethereum node in sync and running reliably – Ensure that layer 1 works reliably. This means that users have to have an Ethereum node, either geth or parity, that is always synced and working reliably. If there are any problems or bugs on the client then Raiden can not work reliably.
• Ethereum client always online – Make sure that your Ethereum client is always online. We recommend running it inside a monitor which will restart it if, for some reason, it crashes.
• Ethereum Client cannot be changed – Swapping the Ethereum client while transactions are not mined is considered unsafe. We recommend avoiding switching Ethereum clients once the Raiden node is running.
• Raiden node always online – Currently all nodes participating in a transfer need to be online in order for a transfer to be carried out. Hence, make sure that your Raiden node is always working, your network connection is stable and that the Raiden node is always online. If it crashes, for whatever reason, you are responsible to restart it and keep it always online. We recommend running it inside a monitor which will restart it if, for some reason, the Raiden node crashes.
• Unique account for Raiden – Raiden requires you to have a specific Ethereum account solely dedicated to Raiden. Creating any manual transaction with the Ethereum account that Raiden uses, while the Raiden client is running, can result in undefined behavior.
• Raiden account has sufficient ETH –  Raiden will try to warn you if there is not enough ETH in your Raiden account in order to maintain your current open channels and allow them to go through their entire cycle. However, it is your job to refill your account with ETH and to make sure it is filled sufficiently once warned.
• Persistency of local DB – Your local state database is located at ~/.raiden. This data should not be deleted by the user or tampered with in any way. Frequent backups are recommended. Deleting this directory can result in a loss of funds.
• Never expose the Raiden REST API to the public – For Raiden’s operation, the client needs to be able to sign transactions at any point in time. Therefore you should never expose the Raiden Rest API to the public. Be very careful when changing the –rpc and –rpccorsdomain values.
• Be patient – Do not mash buttons in the webUI and do not shut down the client while on-chain transactions are on the fly and have not yet been confirmed.

Known Issues

Below are listed is a non-exhaustive list of known issues, which users should be aware of while using the current version of the software. Most of these issues are not Raiden specific, but rather apply to all Ethereum L2 solutions.

• Compromised user system – If the system of the user is compromised and accessed by an attacker or if a malicious application is running, then the WAL could be accessed and valuable information leaked through it, since the WAL is not encrypted as such yet: raiden-network/raiden#579
• Disk Full – The client does not properly handle the cases where the user’s disk may be full. This could lead to a loss of data due to the Raiden node crashing. In the future, we should handle the detection of a full disk and gracefully quit the app: raiden-network/raiden#675
• Blockchain Congestion – If the blockchain is congested and there is no space for the Raiden node to submit transactions on-chain, the client could end up being unable to settle the channel on-chain. The development of a gas slot based settlement timeout definition has been suggested to address blockchain congestion: raiden-network/raiden#383
• Chain reorganizations – The client used to have an issue with edge cases of chain reorganizations. These issues have been hot fixed by only polling events that are confirmed for 5 blocks. Same applies to the processing of transactions, which are assumed to be valid only after a confirmation period of 5 blocks. This results in 15 blocks wait time for opening a channel (three on-chain transactions).

In order to get started, read the documentation and download the latest version of the Raiden Network from GitHub.