Alderaan Mainnet Release Announcement

Raiden Network
Raiden Network Blog
10 min readMay 27, 2020
Photo by Yesuitus2001 / CC BY-SA 3.0

tl;dr

We are excited to announce that the Raiden Network Alderaan release is live on the Ethereum mainnet. The Alderaan release is the first full suite version of Raiden and it introduces a bunch of exciting new features including monitoring services, pathfinding services and mediation fees, compared to the Red Eyes release. As this release still has its limitations and is a beta release, it is crucial to read this post including the security notes carefully before using the software.

Goals of the Alderaan release

Alderaan is the second major release of the Raiden Network on the Ethereum mainnet. The goal of this release is to have a secure and reliable, feature complete version of the Raiden Network that allows other projects to start building on top of and integrating Raiden into their dApps.

We encourage anyone interested in doing fast, cheap and scalable payments on Ethereum to try out the Alderaan release. With this release, we are especially interested in receiving feedback and feature requests by projects looking to integrate Raiden as an underlying payment technology in their dApp. We are also open to collaborating with projects that want to power their payments with Raiden. Please feel free to reach out to us at [contact (at) raiden (dot) network]. Also, if you are building something that you believe would benefit the Raiden ecosystem, take a look at the Raiden Trust’s grant programme. If you discover a critical bug, please don’t hesitate to head over to the bug bounty website and report it.

Features included in the Alderaan release

Below is a list of new features included in Alderaan. Existing features included as part of the Red Eyes release can be found in this blog post.

  • Mediation fees — allow mediating nodes to earn fees and balance the network
  • Channel Monitoring — nodes no longer have to be online all the time
  • Pathfinding Services — nodes no longer need to know the full network topology
  • Partial withdraw — channels don’t have to be closed to withdraw from them
  • Raiden Wizard — setting up a Raiden node made easy and fast
  • Numerous fixes and improvements for making the protocol and transport layer more robust and faster

To learn more about Channel Monitoring and Pathfinding, please see this article and for more information about mediation fees, please see this article.

Getting started with the Alderaan release

In order to get started, read the documentation and download the latest version of the Raiden Client from GitHub. If you encounter any problems during the process, contact us via Gitter or open an issue.

The Raiden Wizard is available for a quick and easy onboarding experience. See the next section for a step-by-step guide on how to quickly and easily set up a Raiden node. Raiden is also available as a one-click install package on DAppNode through the DAppStore.

For a visualization and network statistics of the Raiden Network, check out the Raiden Explorer.

See the Raiden smart contracts on EtherScan:

Steps to get up and running with Raiden

In order to quickly get going with Raiden, the Raiden Wizard has been created. The Raiden Wizard helps users set up and fund a Raiden node with just a few clicks.

To get started you’ll need:

  • An x86 computer running Linux or macOS X.
  • An infura ID (click here for a quick start guide).
  • A web browser with Metamask.
  • An Ethereum account with at least 0.13 ETH in Metamask.

Then head over to the Raiden Wizard releases page and download the latest version. Unpack the downloaded archive and run the executable program named “raiden_wizard”. From here, the Wizard will take you through the steps necessary to set up a Raiden node and by the end of the process you’ll have a running Raiden node on the Ethereum mainnet.

For a more in-depth explanation of how the Wizard works check out the quick start section of the documentation.

Raiden Wizard at work

Safety measures of the Alderaan release

Since the Alderaan release is a beta deployment of the Raiden Network on the Ethereum mainnet, we have taken strong risk mitigation measures to limit the potential damage caused by bugs or misuse of the software and to ensure a responsible experimentation environment for this nascent technology. Please also note, that the Alderaan release is not yet security audited by an external party.

Deposit limits — $1,000 worth of tokens per node per channel / $1,000,000 worth of tokens in total per token network, as well as a deprecation switch have been put into place to limit any potential loss of funds. The deprecation switch prevents new channels from being opened and new deposits to be made. However, users can still make transfers and close and settle channels even if the deprecation switch is triggered. Additionally, this version of the Raiden Network is limited to two token networks, WETH (wrapped Ether) and DAI.

Usage of the Raiden Services

As mentioned above, Alderaan includes optional channel monitoring and pathfinding services in order to increase the safety of user funds as well as mitigating the need for nodes to always be online.

The PFS is set as the ` — routing-mode` by default. This means that whenever a node wants to make a transfer to some other node in the network, it requests the PFS to provide a route through the network to the target node. For this, the PFS takes a small fee as an IOU through the UserDeposit of the requesting node.

Channel monitoring is set to `False` by default through the ` — enable-monitoring` flag. If enabled, the Raiden node in question is able to be offline without having to worry about its counter party closing the channel, and hence not being able to provide the correct latest balance proof. The monitoring service also takes a small fee as an IOU through the UserDeposit upon successfully closing a channel on behalf of a node.

Fees for the Raiden Services (Monitoring and Pathfinding) are paid in RDN and the default values hereof can be seen in the relevant documentation. For a more in-depth explanation of how the Raiden Services work, please see this article.

Please note that the fees related to mediation through a given Token Network are paid in the token of the Token Network in question. Raiden uses a quite complex dynamic fee structure in order to try to balance out the imbalances in channels etc. More information on the fee structure can be found in the blogpost explaining the fees and in the Raiden documentation.

Feature limitations of the Alderaan release

Feature limitations in the current release include:

  • No upgradability of the token network: The Alderaan 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, we have implemented a one-time deprecation switch in order to be able to deprecate the network, if needed.

Deprecating Red Eyes

With Alderaan released, it is highly recommended that users who used the Red Eyes release, check if they still have any open channels. If there are still open channels, please make sure to close and settle them.

This is due to the fact that Red Eyes will no longer be supported after Alderaan is released and brainbot labs, might deprecate the contracts entirely at some point in time after Alderaan is released.

Important security notes for usage

Always keep in mind: Despite the fact that Alderaan is a lot more mature and reliable than Red Eyes, it is still a beta release. Please make sure to follow the below security notes and system requirements to avoid increasing the risk of losing funds. Note that the loss of tokens could happen even if you follow these guidelines.

  • Ethereum node in sync and running reliably: Ensure that layer 1 works reliably. This means that you have to have an Ethereum node, either geth or parity, that is 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 during operation of a Raiden node. As stated above, you can safely go offline if channel monitoring is enabled, but in order to use the Raiden nodes for doing transfers you have to have an online and synced Ethereum node, too. We recommend running it inside a monitor which will restart it if, for some reason, it crashes.
  • Ethereum Client can not 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 online for operations: 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. As mentioned above, if a node has monitoring enabled it is safe to shut it down, but it will not be able to receive, mediate or send transfers while offline.
  • 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 behaviour. It is, however, safe to do manual transactions with the account if Raiden is not running.
  • 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.
  • Raiden account has sufficient UserDeposit: If you are using pathfinding or monitoring service, you will pay for using these with IOUs through the UserDeposit smart contract. This deposit is done in RDN and if the user deposit does not have a sufficient balance, the Raiden services will not kick in, since they are not getting paid.
  • Do not transfer too small amounts for mediated transfers: Currently the Raiden client cancels payments that would require more than 20% of the transferred amount in fee costs. This means that the transferred amount has to be big enough, so that the fees do not surpass 20% of the transferred amount. This results in the following minimum amounts for the token networks when mediation is used: DAI: minimum 0.00001 DAI, WETH: minimum 0.0000001 WETH.
  • 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 you find a non-exhaustive list of known issues, which you 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 write-ahead logging (WAL) could be accessed and valuable information leaked through it, since the WAL is not yet encrypted as such: 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 want to 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 in order 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 processing 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 closing

We are happy to have released Alderaan and we cannot wait to see what cool things that will be built using this technology. If you’re looking to build on Raiden and encounter that a specific feature is missing, please do not hesitate to contact the team on github and request the feature by opening a Github issue. The Raiden team aims to be as developer focussed as possible after the Alderaan release and help build a technology that is as useful as possible to the projects using it.

We are excited to hear your feedback and to jointly push the Raiden Network to the next stage. Thank you for your ongoing support!

A special thanks goes out to Anyblock and DappNode, who are supporting the Alderaan launch of the Raiden Network by running Raiden Service Bundles.

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: 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.

--

--