CryptoBotWars — Part 2: Conclusions

In my previous blogpost, I described how I built the CryptoBotWars game, and I promised some conclusions and some robot tricks.

If you came for the robot tricks, read on.

Robots & Live Streaming

Want to feel like your life is a silent movie? Let the robot overlords 🤖 occupy your house because they want to play cute while live streaming.

Oh, and sometimes the floor surface and internet connection (robots are controlled by a remote VPS, sending commands to a local robot server with a public IP) play tricks on your very exact robot command timings 🤦‍♀.

You will only feel normal again when the robots need to recharge 😴.

Live Streaming

We need good tools for decentralized streaming & broadcasting.

I really wanted to stick with decentralized solutions and tried out Livepeer . Unfortunately, they don’t currently offer a solution for broadcasting, so you need to handle this yourself and unfortunately again, I did not have the time.

I also tried https://instant-webcam.com , which encodes the video and serves the frames over WebSockets directly from your phone. But the resolution was not great and the delay was considerable. For a good experience, the game required low latency, so we eventually moved on from this solution.

We ended up using a centralized solution and bypassing the initial stream start ads by just muting the stream 😶.

Raiden Network

I also mentioned some of the questions that I had about Raiden Network , that prompted me to build the game in the first place. Note that we are discussing the current state and not a future, more ideal state of Raiden that can be achieved.

Now, we will go through my first two questions and discuss them.

Is it easy to build something on top of Raiden right now? Do we lack anything that is fairly easy to change?

It is fairly easy to build an application on top of Raiden Network — the API is clear enough and well documented.

However, as you can see in the game’s logic sequence diagram , you need more steps than maybe one expects.

• the GameClient needs to send the GameGuardianServer the encrypted move data
• the GameClient needs to receive a paymentIdentifier (uint64) from the GameGuardianServer, after linking it to the encrypted move data
• the GameClient needs to use this paymentIdentifier when sending the Raiden off-chain payment
• the GameClient needs to send the unencrypted move data to the GameGuardianServer

The intent here is to provide a way for the GameGuardianServer to verify the Raiden off-chain payments that it has received and match each transfer’s paymentIdentifier with the ones that are linked to the moves.

While you can provide a paymentIdentifier when initializing a transfer, uint64 (and uint256 for that matter) is too small to contain the metadata hash (in our case, the encrypted move data). Also, decoupling the paymentIdentifier from the metadata hash is good, because the paymentIdentifier also has the scope of identifying in-flight payments and retrying them in case of failure (e.g. one of the chosen routes fails).

How would it look if an additional metadata hash is supported? We could get rid of the first two steps and only do:

• the GameClient triggers the Raiden off-chain payment, attaching the encrypted move data to the transfer
• the GameClient sends the unecrypted move data & paymentIdentifier to the GameGuardianServer

Then, the GameGuardianServer can reconstruct the metadata hash and match each transfer to a user’s game move.

Reducing the number of API requests starts to be important when you want to build apps that require a high throughput, especially when the app is a centralized one — true for many service providers.

There have been discussions regarding this already and you can join if you have a proposal.

How would Raiden work right now for one-to-many & many-to-one payments, cases frequently related to businesses

Let us discuss many-to-one payments first. In our case, we have an infinite number of players that need to send payments to the GameGuardianRaidenNode. The users can just start to play the game and they can quickly determine if they already have a path to the GameGuardian. If they do not, they cannot play.

The easiest thing for them to do, is to open a channel with the GameGuardian and deposit some tokens. This will eventually transform the GameGuardian node into something similar to a Hub, due to the number of channels it will have in the network.

They can also look at the Raiden Explorer and manually find suitable nodes with which to open a channel. Suitable means:

• the node has a connection with the target node (e.g. GameGuardian)
• the node has enough capacity to send payments to the target node
• the node has a reliable availability

Unfortunately, there is no current way to determine what nodes are usually online. Also, the current version of the Explorer does not show the current off-chain capacities, only the current on-chain deposits.

However, the biggest problem the game had was with one-to-many payments: the rewards that the GameGuardianRaidenNode must send to the game winners.

The issue: the GameGuardian needs a path with enough capacity, for each winner. Even if a User -> GameGuardian path already exists (otherwise, the game cannot be played), there is no certainty that a GameGuardian -> User path with enough capacity exists. Often, the GameGuardian needs to make a deposit in the channel that he has with the User.

So, the additional obstacle here is that the User needs to make sure a reward path exists, because the service provider is unaware of the who plays the game.

A minimal solution for this issue has been put in place:

• the game has chat support, for users to ask for help when setting up the channels and ask the GameGuardian to deposit some tokens in these channels.
• I am open to lock up funds as channel deposits from the GameGuardian, so winners can receive their rewards.

I could also add a feature for a 1-click verification that a reward path exists, by trying to send a very small payment GameGuardian -> User, as long as a previous successful transfer has not happened in a given amount of time.

Keep in mind that a more mature network, with denser connections will always have less issues when routing payments. The question is: how do we get to a homogeneous, fault tolerant network?

Some ideas are:

• Enforce a network topology when we onboard users.
• Path Suggestion service support for proposing channel creation & deposits in order to fill in the network gaps or efficiently connect nodes (e.g. connect a user’s Raiden node to multiple Raiden nodes belonging to various service providers)

1.Enforce a network topology

This has been previously researched in Raiden Network, when trying to find a good decentralized routing algorithm. However, the decision was to have a simpler approach for the moment: https://github.com/raiden-network/raiden-services

2. Path Suggestion Service Support

This is something that can be done now and I have started to write the proposal here: https://github.com/raiden-network/spec/issues/179

To summarize, the components are:

• Path Suggestion Service
• a way for the Raiden Client to process the path suggestion

2.1. Path Suggestion Service

This can be a standalone service. However, it should ideally be incorporated in the Path Finding Service (PFS), in order to provide a more accurate suggestion, based on current off-chain channel capacities in the network.

If a user needs connections with several services or other users, the PFS should provide a service to find the most efficient way to connect him, at a given point in time.

Given an Ethereum address A2 of a target Raiden node and an amount of tokens T, it should suggest a list of actions that need to be taken by nodes (A1 + other nodes) in order to have path A1->A2 or A1<-A2 or A1<->A2:

• list of users with whom A1 needs to open a channel +/- deposit
• list of users who need to deposit tokens into the above channels & the minimum amount of tokens that would be needed at that point in time

The above can be extended to A1 asking for connections with multiple Raiden nodes at the same time, decreasing the amount of locked funds by efficient connections.

2.2. Raiden Client Features

Both or either:

• have a special endpoint for receiving user-targeted notifications, that should be displayed in the Raiden WebUI. The user can then see the suggestions and decide if he follows them.
• specifically process the path suggestion endpoint itself and even automate the channel creation & deposits, based on some predefined user limits (gas, number or tokens to be locked in deposits) and some additional protocol messages used for negotiating actions that need to be taken by other users, such as deposit requests (as in our rewards example) and ensure availability of nodes.

2.2.1. Raiden Notifications API & UI

• allow 3rd party services (e.g. PFS, MS) to send notifications to the user through a dedicated Raiden Client endpoint
• notifications should be shown in the WebUI. These will be the steps that the user needs to take: open channel with 0x…, make a deposit of X tokens in your channel with 0x…, make a deposit of X tokens in your channel with 0x… because the channel may be used for frequent transfers and you get mediation fees
• ideally, you could have an action button that does all the suggestions for the user automatically, if the user clicks on it

2.2.2. Raiden Messages

I am proposing to add additional protocol messages. Note that this is a work-in-progress suggestion, that needs a more detailed spec.

• sending a ChannelDepositRequest from Raiden node A1 to another Raiden node Ax
• sending a ChannelDepositAnswer from Ax, with the fee that Ax expects in return for locking up funds
• sending a conditional payment from A1 to Ax that will be unlocked after Ax makes his deposit

Things become more complicated if A1 needs to both open & deposit, based on Ax’s answer, because he may end up with a useless channel & locked up funds. Incentives need to be well aligned.

Last but not least

I hope this also gives some insight on the current status of Raiden Network and gives an idea about some of the improvements that can be made. Try it out, contribute to the technical discussions and help make Raiden awesome.

I know you were promised robot tricks, but I am still working on them 😜