Hey everyone!

​

Welcome to Weekly Update 51. This week’s update will be covering some topics relating to Ithaca and auxiliary services that the community has expressed interested in understanding more. We’ll look at how /u/BOR4 could potentially be tricked out of funds without a Monitoring Service and also the usual Github development activity of Raiden Network. Let’s dive in!

​

Raiden auxiliary services

Red Eyes, being the first version of the Raiden Network has been successfully deployed on the Ethereum mainnet, includes features of a Raiden client capable of recovering in case of an unexpected shutdown, a robust Raiden protocol, gas efficient smart contracts and a Matrix transport layer. However, neither of the 2 auxiliary services which are essential for Raiden to be production ready were part of the release. These auxiliary services are the Pathfinding service and Monitoring service.

​

Pathfinding service (PFS)

The PFS is envisaged to support users in finding the optimal way to route a payment through the network. As the network grows, finding a path that is capable of routing payments between distant nodes will be a challenging task. Pathfinding services aims to keep track of the capacity of the entire network and will give their best to produce a number of cheap/shortest paths, routing a payment in exchange for a fee.

A very similar real life equivalent that most of you are probably familiar with are mobile apps that help you find cheap indirect flights between any two airports. Finding a flight between New York and London is very simple as flights are common and connection flights are usually unnecessary. However, if you’re traveling from one remote small airport to another remote airport in the other part of the world, you could spend hours finding cheap connecting flights that don’t have a layover delay of 12 hours. The service these mobile apps offer you when you are traveling are the metaphorical equivalent to what pathfinding services will provide in routing payments in Raiden Network. The main difference is that flight apps help route people successfully and quickly between airports to their destination while pathfinding services aim to help route ERC20 tokens between nodes.

​

Monitoring service (MS)

MS will watch a user’s channel when that participant of the channel isn’t online. In the case of the counterpart (channel partner) requesting to close the channel, the monitoring service can properly update and settle a channel on behalf of the offline user with the latest balance proof.

Currently, once a channel close is initiated, both parties that are part of the channel have a certain amount of time to provide proof for what they believe is the correct last state of funds locked inside a channel. The amount of time they have to provide a balance proof is defined as the “settlement period” (default of 500 blocks) while the proof itself is called “balance proof”. When a channel is settled on-chain only the latest balance proof is considered. A new balance proof is produced for every payment occurring inside a channel. Using a made up balance proof to settle a channel is impossible, however using outdated versions of balance proof is possible because the smart contract responsible for settling funds on-chain doesn’t know the latest version of the balance proof.

A monitoring service aims to keep track of the latest version of balance proof and provide it inside the settlement period on the behalf of the offline user thus making sure funds locked in a channel are correctly split on-chain.

​

CookieGate

To help you better understand what can happen if there is no MS to monitor channels of offline users, we will look at this simplified scenario where /u/Mat7ias scams /u/BOR4 out of his cookies.

Let’s say there is an ERC20 token MCT (milk-cookie token) you can use to trade milk and cookies. BOR4, owner of a large cookie company, and Mat7ias, owner of a single cow, use MCT to do business. Doing back and forth payments on-chain is expensive and slow so they decide to join the Raiden Network. They open a channel with 300 block settlement period where they both put in 5 MCT each.

Inside a single channel there are 2 series of balance proofs, one for each participant. Each participant locally keeps balance proofs signed by the other side. Balance proof contains a lot of information, but to demonstrate this example we will only need:

• nonce - represents version of the balance proof. Starts at 1 and is updated on each transfer
• transferred_amount - monotonically increasing sum of all received transfers in the history of the channel

Price of a cookie is 1 MCT while the price of milk is 2 MCT.

​

​

At this point, due to bad stomach ache caused by the expired milk, BOR4 had to go offline. Mat7ias notices that, so he initializes closing of a channel inside the Raiden Network. He submits balance proof (nonce = 2, t_amount = 4) BOR4 signed when he was making payments. Settlement period of 300 blocks goes by and BOR4 failed to submit his balance proof. The smart contract thinks he has no balance proof to submit, it only sees that BOR4 transferred 4 MCT to Mat7ias. Therefore it settles funds on-chain this way:

• Mat7ias => 5 4 - 0 = 9
• BOR4 => 5 0 - 4 = 1

If a MS was present in the network, it would submit (nonce = 1, t_amount = 6) on BOR4 behalf during the settlement period. In that case funds would be settled in the correct way:

• Mat7ias => 5 4 - 6 = 3
• BOR4 => 5 6 - 4 = 7

Algorithm (locked_amount total_received - total_sent) used to calculate amounts that should be settled on-chain in this example is a simplified version of the real algorithm described here. I hope this example helps you better understand what is the role of MS in the Raiden Network.

​

Development progress

Even though Red Eyes is in the bug bounty on the Ethereum mainnet, development of Raiden Network is already progressing towards next milestones. Specifications for Pathfinding Service and Monitoring Service were expanded with additional implementation details. While reading these specifications please take into consideration that they are still works in progress and are subject to change. Implementation of some of the features required for normal functioning of auxiliary services has also begun.

Significant progress towards completely switching from TravisCI to CircleCI as the continuous integration tool of choice for all Raiden repositories was made in the last week. The last couple of months was a transitional period where both TravisCI and CircleCI were used. Running tests and builds on the CircleCI is more reliable as well as a faster solution.

Finishing up, several important tasks in Raiden client repository that were left out the Red Eyes release are worked on. Wrapping them up is a priority as the implementation of some new features relies on them.

​

Conclusion

To conclude Weekly Update 51, Red Eyes has been a vital step in progress and important features that’ll improve potential adoption are in the pipeline. Most notably Monitoring and Pathfinding services but also others that can be found in the Raiden roadmap. Also quickly for anyone in the area, the Raiden team will be presenting at GörliCon in Berlin on January 31st, giving a heads up that Raiden is live on mainnet with Red Eyes, current challenges and possible solutions moving forward. Anyway, as always thank you to to readers of this update and to those contributing to the Raiden project overall. Be sure to put any questions or concerns that you might have in the comments.

​

Cheers!