Raiden Transport Explained
The Raiden Network relies heavily on nodes being able to exchange messages in a timely manner in order to facilitate token transfers. Hence, the transport of these messages is a crucial component of the Raiden Network.
In this blog post, we have a closer look at how the message transport currently works in the Raiden Network and which criteria need to be taken into account when choosing the right communication protocol for a payment channel network.
Transport in Raiden - The Basics
Token transfers in the Raiden Network are performed via multiple messages which are sent between the nodes. The information contained in a transfer comprises the recipient, the amount and several other pieces of information e.g. the token network, the blockchain and the smart contracts used. Importantly, these messages are signed, such that they can be used to prove balances on the blockchain.
Desirable properties of a transport layer
The following non-functional requirements are most important while choosing a communication protocol for Raiden:
- Accessibility: The protocol should be usable from a wide range of devices and network setups,e.g. being behind a NAT.
- Scalability: not every node should need to see every message.
- Speed: latency should be in sub-seconds.
- Distributed setup: no single point of failure or censorship.
The efficiency/privacy dilemma
Currently, a tradeoff between efficiency and privacy (nobody is watching who is receiving and who is sending) in communication protocols is mostly inevitable.
This dilemma can be described looking at passive protocols: Passive protocols (like @Whisper) feature high privacy by sending all messages encrypted to all nodes without stating who the receiver is. Every node then tries to decrypt the message using its private key. Only the recipient node’s private key will be able decrypt the message. This solution ensures high privacy, however it is not very scalable and has high latency.
Comparing our initial handcrafted UDP based protocol vs. Matrix protocol
Up to and including the testnet v0.3.0 release, Raiden used a UDP (User Datagram Protocol) based P2P protocol. With the testnet v0.4.0 Icalo release, we switched to Matrix instead.
We initially chose UDP because of two big benefits: speed and simplicity. It’s biggest downside, however, is accessibility (NAT traversal issues) and reliability as well as the lack of a discovery protocol which preserves endpoint privacy.
Due to the above mentioned difficulties, we started to look for alternative communication protocols and for the time being decided for Matrix.
Introducing Matrix
What is Matrix?
“Matrix is an open standard for interoperable, decentralised, real-time communication over IP. It can be used to power Instant Messaging, VoIP/WebRTC signalling, Internet of Things communication — or anywhere you need a standard HTTP API for publishing and subscribing to data whilst tracking the conversation history.” [from matrix.org]
If you want to know more about Matrix, have a look at their FAQs or learn how to get started with Matrix.
Why did we choose Matrix?
Amongst the wide range of features and functionalities Matrix offers, we especially value the following:
- Reliability of the transport compared with the former UDP based hotfix: The reliability of transport in Matrix is comparable to TCP. There are no issues with lost messages or retransmissions.
- Out-of-the-box support for end-to-end encryption.
- Communication is always initiated from the client to the server (HTTP long polling), which guarantees not running into NAT traversal issues.
- Federated server set up: Matrix runs on a set of federated servers which allows for a decentralized setup if there are sufficient homeservers participating.
- Message history: The Matrix server keeps a history of messages sent between peers. Making use of this feature could in theory allow offline messaging as well as other optimizations. This feature is currently not used by the Raiden Network, but could be helpful in the future.
- Last but not least: Matrix is an open source project, just like we are! :-)
What changed moving from UDP to Matrix?
With the UDP transport we used to send binary messages, with Matrix we transitioned to a JSON encoded message format. The JSON format is easier to read and simplifies the debugging of message flows. Communication happens in dedicated channels between the nodes that can reside on multiple Matrix homeservers. This means that a participant’s endpoint is known to his selected homeserver, but kept secret from all other participants of the network.
Matrix relies on a distributed server infrastructure. Who is running the Matrix servers for the Raiden Network?
Currently, anyone can run a Matrix server for the Raiden Network. The specifications on how to configure and install the software and host a matrix homeserver can be found in the raiden-transport repository.
A growing number of community members, projects and companies power the Raiden Network by providing Raiden Matrix homeservers.
A special thanks goes out to DigitalVirtues, ExchangeUnion, KI decentralized and MyCrypto, who will support the Red Eyes launch of the Raiden Network by running Matrix homeservers for the Raiden Transport.
How secure is Matrix?
The communication between the Raiden nodes and the Matrix servers is protected via TLS. Chat rooms in Matrix are by default private and their contents are only visible to users invited to the respective room. Even server operators can’t join rooms they aren’t invited to. Of course a malicious server operator could employ other means to get access to message data. This can be mitigated by end-to-end encryption.
Matrix supports secure end-to-end encryption using the Olm protocol. Supporting E2E encryption and Onion Routing could be future improvement possibilities which help to increase privacy.
The future of P2P transports
As mentioned earlier, there are some tradeoffs to be made when choosing a transport protocol. While Matrix might not be perfect, it’s our choice until P2P transports with better privacy and decentralization properties emerge, which don’t sacrifice our required scalability and latency properties. We will keep on investigating other options, e.g. we are curious how libp2p will evolve.
With that being said, our transport layer is well decoupled from the core Raiden client so that Raiden might be based on a different transport in future. Currently, we see Matrix being the most viable solution for our needs.
Special thanks to @ulope and @heikoheiko who have been interviewed for this blog post and
for the support and open conversations!We hope you liked this short insight into how the transport layer works in the Raiden Network and are looking forward to sharing more of these deep dives with you in the coming blog posts.
Which other components of the Raiden Network would you like to learn more about? Let us know by leaving a comment below and we’ll take your topic into account for one of our next blog posts.
The Raiden Team
