Awesome
Raiden Service Bundle (RSB)
What is this repository
This repository contains the documentation and configuration necessary to run a Raiden Service Bundle.
Current release: Latest
Table of Contents
Overview
The Raiden Network uses a federation of Matrix servers as its transport layer and a set of services for improved usability. This set of services is called the Raiden Service Bundle. To ensure reliability, availability and neutrality it is desirable that those services are being operated by multiple independent entities.
Therefore we provide this repository which allows easy setup of such a service bundle. It uses docker and docker-compose for easy installation and upgrades.
Currently only this single-server configuration is supported; in the future we may also provide configurations with services split among multiple servers.
Used software
- docker
- docker-compose
- Synapse
- Postgres
- Traefik
- Raiden Services (Pathfinding, Monitoring)
Structure
+-------------------+
| |
| Raiden clients |
| |
+---------+---------+
|https://
==========|==========
|
+---------v---------+ Federation to
| +-+--------------------> other Raiden
| Traefik | | Matrix servers
| |-+---------+----------------------+
+---------+-------+-+ | |
| | | |
+---------v-------v-+ +-----v----------------+ +---v-----------------+
| | | | | |
| Synapse | | Raiden Pathfinding | | Raiden Monitoring |
| | | | | |
+---------+---------+ +-------------------+--+ +-+-------------------+
| | |
+---------v---------+ +-v- - - v -+
| | |
| Postgres | ETH_RPC |
| | |
+-------------------+ + - - - - - +
We use Traefik as a reverse proxy and also utilize its capability of automatically provisioning Let's Encrypt TLS certificates.
The Synapse server is being run in the so-called split worker configuration which increases throughput.
The database stores the message data. Since the transport layer is considered ephemeral in Raiden it is not necessary to arrange for backups of the database data.
Network
After a successful deployment the following ports will be in use:
- 80 - HTTP
- Redirects to HTTPS
- Let's Encrypt HTTP challenge for certificate provisioning
- 443 - HTTPS
- Synapse (on subdomain
transport.$<SERVER_NAME>
)- Client API access
- Server-to-Server federation
- Raiden Pathfinding Server (on subdomain
pfs.$<SERVER_NAME>
) - Metrics export (IP restricted, see below)
- Synapse (on subdomain
Requirements
Hardware
Minimum recommended for a production setup:
- 16 GiB RAM
- 8 Cores
- 50 GiB SSD
Note: The default Postgres configuration assumes 16GiB of system RAM
Software
- Docker >= 17.12
- docker-compose >= 1.21.0
Other
- A domain (or subdomain) for exclusive use by this server
- To ensure acceptable performance the server should be reserved for exclusive use by the RSB.
Installation
Note
Running an RSB provides important infrastructure to users of the Raiden Network and failures potentially affect a lot of users. It is therefore recommended to have devops experience and basic knowledge of the Ethereum ecosystem in order to run an RSB. Also a minimum commitment of a reasonable response time in case of outages is required.
Preparation
-
Provision a server that meets the hardware and software requirements listed above.
-
Ensure a domain (or subdomain) is available
Examples:
- raiden.somedomain.com
- raiden-service-bundle-somecompany.tld
-
Configure
A
(and optionallyAAAA
) DNS records for the domain pointing to the servers IP address(es) -
Configure a
CNAME
DNS record for*.<domain>
pointing back to<domain>
NOTE:
If you intend to use a subdomain it is important to be aware of the security implications. Subdomains share Cookies and Browser LocalStorage with the apex domain. Therefore we strongly suggest that a subdomain is only used below an apex domain that does not host an application that relies on either Cookies or LocalStorage for security relevant purposes (e.g. user authentication).
Installing the RSB
NOTE:
This document will sometimes display release candidate versions, also known as pre-releases in the section below. You
can identify this, if there is an rcX
at the end of the version (E.g. 2019.03.0rc5
). When in doubt, always check against the
latest full release. If the version is
different from what you see below, you should stick to the "full release" and replace the version accordingly.
-
Clone the current release version of this repository to a suitable location on the server:
git clone -b 2022.05.0 https://github.com/raiden-network/raiden-service-bundle.git
-
Copy
.env.template
to.env
and modify the values to fit your setup. Please read Configuring the.env
file for detailed information.- We would appreciate it if you allow us access to the monitoring interfaces
(to do that uncomment the default values of the
CIDR_ALLOW_METRICS
andCIDR_ALLOW_PROXY
settings). - We also recommend that you provide your own monitoring. The setup of which is currently out of scope of this document.
- Please read the disclaimers for the path finding and monitoring services carefully and uncomment the variables
<SERVICE>_ACCEPT_DISCLAIMER
if you agree. Note, that without agreement the services won't start.
- We would appreciate it if you allow us access to the monitoring interfaces
(to do that uncomment the default values of the
-
If you haven't done so before, run
./register-service-provider.sh register
(it uses configuration values from.env
). Please read the information provided Registering as a RSB Provider carefully before executing the script. -
Run
docker-compose up -d
to start all services- The services are configured to automatically restart in case of a crash or reboot
NOTE:
After a new RSB has been registered and added to the
known_servers/known_servers-production-v3.0.0.json
file it can take up to 24
hours for the information to propagate to existing RSB installations.
During this time some services will not yet be able to start successfully and log various error messages. This is expected behaviour and will resolve itself.
After the 24h have elapsed all services should run successfully. See verifying that the RSB is working below.
Configuring the .env
file
After cloning the repository the .env
file needs to be configured. A template named .env.template
is provided. Below you find a detailed list of the parameters to be set and their explanations.
SERVER_NAME
: The host domain without protocol prefixhttps://
respectivelyLETSENCRYPT_EMAIL
: Email address to use when requesting LetsEncrypt certificatesCIDR_ALLOW_METRICS
: Metrics whitelist. IP address/network whitelists for access to non-public parts of the service. Uses CIDR notation. Separate multiple entries with commas. Example values: 10.0.0.0/16,10.1.2.3/32 or 10.1.2.3/32.CIDR_ALLOW_PROXY
: Proxy metrics / management interface whitelistWORKER_COUNT
: Number of worker processes to start, setting this to the number of CPUs is a good starting pointDATA_DIR
: Data dir location. Optional, defaults to ./data in the checkout directoryURL_KNOWN_FEDERATION_SERVERS
: URL to use to fetch federation whitelist - used only for testingKEYSTORE_FILE
: The keystore file which has to be located in ${DATA_DIR}/keystorePASSWORD
: Password to decrypt the keystore fileETH_RPC
: Ethereum RPC URL. This is used to communicate with the Ethereum blockchain. You can either host a node yourself or use a service like Infura. Regardless, the RSB requires a minimum of 200,000 requests per day and potentially more depending on traffic. Please make sure that the chosen service is able to handle this.PFS_ACCEPT_DISCLAIMER
: TRUE or FALSE if you accept the Pathfinding Service disclaimer or not. Read the Disclaimer hereMS_ACCEPT_DISCLAIMER
: TRUE or FALSE if you accept the Monitoring Service disclaimer or not. Read the Disclaimer hereCHAIN_ID
: Chain ID of the connected Ethereum node.PFS_SERVICE_FEE
: The Pathfinding Service Fee to be paid for requestsPFS_OPERATOR
: Official Operator NamePFS_INFO_MESSAGE
: Info message. Will be displayed on info endpoint.LOG_LEVEL
: 'INFO' or 'DEBUG' recommendedSERVICE_REGISTRY
: The address of the ServiceRegistry contract to use. When running on mainnet, use the address of latest deployed contract which can be found here: https://github.com/raiden-network/raiden-contracts/blob/master/raiden_contracts/data_0.50.0/deployment_services_arbitrum-one.json#L6
Registering as a RSB Provider
For your newly deployed Raiden Service Bundle to be used by Raiden nodes it must be registered.
- Registering in the Services Registry On-Chain
- In order to register as a service provider you need to run the script
register-service-provider.sh
register
. - In case you abort the script before finishing the registration process it is possible to continue the process by running the script again.
- Make sure that you have configured a keystore file (
$KEYSTORE_FILE
in.env
). If not, the script will exit with an error and you cannot register as a service provider. - Make sure you have ETH on the above account. An estimate will be shown during the registration process, before any transactions are sent.
- Make sure that the configured account has enough RDN funding to register as a service provider.
You can check the registry contract for the current price of a slot.
You will find the price under
3. currentPrice
. To get the price in RDN divide the value by (10^18). The script will inform you about the price during the registration process as well. - If you do not have sufficient RDN, you can either use an exchange of your choice or an on-chain decentralized exchange like Uniswap to acquire it.
- Extending
known_servers/known_servers-production-v3.0.0.json
- In order to be whitelisted in the Matrix Federation, the list needs to be extended with your server name.
- Create an issue and submit the
domain / URL of the newly deployed server for inclusion in the list of known servers.
Please, state your server name as you have set
$SERVER_NAME
in your.env
file. - It may take up to 24 hours for the federation to accept the server as a new member. Please note, that until this moment, the pathfinding service and monitoring service cannot run properly as they need to use the broadcasting rooms. Once the new server is accepted as part of the federation, all services will restart automatically.
Interacting with the service registry contract
Besides the subcommand register
which can be used to register as a RSB provider, there are several other subcommands to interact with the service registry contract.
Commands:
- extend Extend the duration of a service registration
- info Show information about current registration and deposits
- register Registers the address of a service deployment with the
ServiceRegistry
. - withdraw Withdraw tokens deposited to the ServiceRegistry.
You can call register-service-provider.sh
<command>
to use them.
Verifying that the RSB is working
Check the status of the services by executing docker-compose ps
.
If any services are in a state other than Up
, Up (healthy)
or Exit 0
after the elapse of the 24h waiting period a configuration problem is the most likely cause.
See troubleshooting the RSB installation below in that case.
-
Matrix
- Check that the following endpoints return a successful response (HTTP status 200):
https://transport.<SERVER_NAME>/_matrix/client/versions
- Check that the following endpoints return a successful response (HTTP status 200):
-
PFS
-
Check that the
latest_committed_block
is increasing regularly:docker-compose logs --tail 100 pfs | grep latest_committed_block
-
Check that the following endpoint returns a successful response (HTTP status 200):
https://pfs.<SERVER_NAME>/api/v1/info
-
-
MS
-
Check that the
latest_confirmed_block
is increasing regularly:docker-compose logs --tail 100 ms | grep latest_confirmed_block
-
Troubleshooting the RSB installation
If you experience any unexpected behavior while installing the RSB, please do not hesitate to contact the development team. The fastest way to reach out to us is via the public Raiden Gitter channel. Otherwise, you can also open an issue in this repository with the predefined template for a bug report
Upgrades
To upgrade to a new release please refer to the upgrading document
for any
necessary configuration changes.
Afterwards run the following commands:
git fetch origin --tags
git reset --hard <new-release-tag>
docker-compose pull
docker-compose up -d --remove-orphans
Notes:
- A 'purger' service will run once a day, removing inactive users from global rooms to save disk space and processing performance.
- If necessary it will restart the
synapse
service to fetch an up-to-date whitelist of servers.
Known issues
Protection against Spam / (D)DoS attacks
There is currently only some protection against Spam and / or DDoS attacks. This will be addressed in future updates.
Known servers
The known servers the Raiden clients try to connect to are currently tracked in
the *.yml files in this repository. These lists are used by Raiden clients when
the --matrix-server=auto
(default) option is used, for automatically
selecting a transport server, based on response times. We intend to change this
in the future to use a decentralized scheme (for example an on-chain registry).
Contact / Troubleshooting <a name="contact-troubleshooting" />
To report issues or request help with the setup please open an issue or contact us via email at contact@raiden.nework.
Changelog
See CHANGELOG.md
.
Licenses
The code and documentation in this repository are released under the MIT license.
This repository contains instructions to install third party software. Those are licensed as follows: