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 😴.
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 😶.
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.
GameClientneeds to send the
GameGuardianServerthe encrypted move data
GameClientneeds to receive a
uint64) from the
GameGuardianServer, after linking it to the encrypted move data
GameClientneeds to use this
paymentIdentifierwhen sending the Raiden off-chain payment
GameClientneeds to send the unencrypted move data to the
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,
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:
GameClienttriggers the Raiden off-chain payment, attaching the encrypted move data to the transfer
GameClientsends the unecrypted move data &
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.
- 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
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
GameGuardianto 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
- list of users with whom
A1needs 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.
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
ChannelDepositRequestfrom Raiden node
A1to another Raiden node
- sending a
Ax, with the fee that
Axexpects in return for locking up funds
- sending a conditional payment from
Axthat will be unlocked after
Axmakes 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 😜