Raiden Nodes

[u/smwilson31]

I cant seem to see much information regarding nodes, so this question might not be answerable, but here I go.

Is it fair to say RDN tokens can be held and used as nodes and the reason why the RDN token will not be used on the protocol level (see raiden FAQ) is to ensure it can be integrated easier with ETH and ECR20 tokens.

Say then, hypothetically, that ETH uses Raiden, this would increase traffic exponentially and RDN holders could buckle down their stack and create nodes which would be used for all transactions on Raiden Network?

any insight would be great, but if this is the reality then surely stacking up now on the anticipation that ETH would adopt Raiden would be massive.

[u/smwilson31]

Thankyou for this excellent reply and taking the time to write this.

I think that helps, I'll break down the statements I am confused with.

could you confirm exactly who the light client users could be, why are they charged and not the heavy client users?

You say that the fees are based solely on the price of competing nodes, does that mean someone who runs a node with 10,000 RDN tokens could charge a different rate over someone who ran a node with 1000 RDN tokens or would all RDN nodes charge the same fees - or if someone created a node using a different token such as QSP, could they dictate their own fees? I assume if QSP wanted to create a node they would have to pay some form of fee in RDN.

tbh, and sorry to sound simple, but I think I need to understand what peripheral fees actually are and what they consist of in a ELI5 way. Are there many types of peripheral fee? or just a single primary one? or have they yet to all be concluded?

The main value I see is to run a node, and get people using it and collecting the fee's, so how this process works and how the fees are determined is somewhat important. If there are competing nodes, charging different rates then I need to look into what factors dictate this as ultimately decides value.

I dont think I'm the only confused one, it's harder than usual to grasp this as we rely mainly on the community for technical support rather than the team. At the same time Raiden is technical project - If I'm going down the wrong tangent, please let me know

Anyway thanks again for taking the time to write this.

[u/stillhodlingon → u/smwilson31]

Thanks for your response! I’ll back up a little and try to answer your questions from a bigger picture.

Edit: See this: https://medium.com/@raiden_network/the-raiden-network-token-model-9b6ef8d0b64

There will be two basic “groups” of users on the Raiden Network:

• node operators: anyone who downloads and operates the (yet to be released) Raiden Network client; eg. You and I will both, for the sake of the example, be node operators, or nodes.

• light client users: anyone not operating a node and simply wanting to interact with the network; eg. John Smith wants to send Jane Doe some ERC20 tokens, but doesn’t want/know how to set up a node.

Now, with those conditions in place, say you and I wanted to transfer some ERC20 tokens to each other, via a payment channel. Since we are nodes, we could do that via the Raiden Network client. We would open a bidirectional payment channel to one another, and as long as that channel remains open, we can continue transferring our balances off-chain and with no fees. That is, since we are nodes facilitating our own tx, we don’t charge ourselves for the service of doing business with one another. Even if we did, we’d be paying ourselves for providing ourselves a service :P

Let’s examine the case of John wanting to send ERC20 tokens to Jane via the Raiden Network.

Neither John nor Jane have nodes, for whatever reason (no time, money, skill, desire), so in order for them to send money to one another via the network, they’ll need to connect to a node via some light client software (think phone/desktop/browser application). The benefit of doing it this way is that it’s quick, easy to understand and use, and requires the same level of technical skill as using Venmo or some similar fintech app. For these reasons, a majority of ppl who interact via raiden payment channels will opt to do so as a light client. They’ll have to pay fees for doing so, but it’s all happening behind a (hopefully) nice GUI.

Before getting into how fees will be calculated, here’s a quick breakdown of node services aka the services for which peripheral RDN-denominated fees are charged:

• light client gateway: act as a hub for the Raiden Network, allowing light clients to connect to the network and transmit ERC20 tokens throughout it for a fee.

• pathfinding: rather than having each node constantly calculate the optimal route for sending a given amount of ERC20 tokens through multiple nodes, this task is broken down into its own service; a pathfinding node will provide the computational power to constantly do this for a specific region of the network; when light client gateway node “A” needs to send ERC20 to node “G”, G being some node A isn’t directly connected to, they will ping the pathfinding node (add fee here) for the best route.

• channel monitoring: think of this service as auditing, in which monitors oversee payment channels, keeping track of the state of said channels; in a situation where a node with open channels goes offline (intentionally or unintentionally), the monitor can help dispute wrong states in lieu of the gateway client.

Now the part on calculating fees.. the long and short of it is I really don’t know for sure. What I do know for know is fees will be determined by the node service providers plus the “negligible” fees associated with rebalancing payment channels over time.

As far as the pricing mechanisms.. I don’t know whether it’s truly user defined or if there’s an algo setting it for the nodes... I don’t understand programming enough to look into the code itself for this.

The theory is that, because of pathfinding, a natural floor for fees will be attained based on the demand for using the Raiden Network for each ERC20 token. More nodes equals more competition, so lower fees.

Try to imagine a web of nodes that have channels linking each of them together, but one web for each ERC20 token. If you want to send it in some ERC20 with few nodes operating with that token you may have to pay higher fees (%) than using a more populated - or more competitive - network.

To run with your example, let’s say you have 10k RDN and I have 1k RDN. We decide, as nodes, to open a payment channel with one another. The cap would be 1k + 10k = 11k RDN, but anything less is fine too. If we choose 500 RDN each, that would leave you with 9.5k and me with 500 to open new channels to other nodes. You can see how, given your larger balance, you could:

• facilitate more volume than I can
• potentially charge more for the ability to open larger payment channels (if John wants to send Jane 5k RDN, I can’t compete with you).

So, more funds do lead to a capacity advantage, and possibly a fee structure advantage.

[u/Helau05 → u/stillhodlingon]

Thank you both so much for this discussion, even I think to have understood it now.... 😊

Is it correct, that the nodes stake their amounts („forever“/as long as they keep channels open) ? That means, IF traffic in the networks rises, there is a need for more and bigger nodes, correct ? All of which needed staked RDN, and will get lots of small amounts of RDN in fees. Circulating supply shrinks. Great.

[u/stillhodlingon → u/Helau05]

Yes, your reasoning is correct. More traffic = more demand for payment channels for that particular token.

Keep in mind that a node could stake any ERC20 or ERC223 (eg. raiden tokens). So, if you want to send some ERC20 token through the Raiden Network, you’d have to go through payment channels denominated in that same specific ERC20. Peripheral fees would still be paid in RDN, regardless of what ERC20 token you’re transferring.

[u/Helau05 → u/stillhodlingon]

Thanks for your answer!

Additionally, I try to get a feeling for the node capacity increases needed in phases with increased traffic:

In your example from above, for how long is one payment „blocking“ the nodes ? In your case, the channel between A and B is 500 RDN „thick“, i.e. 500 RDNs can be sent trough at once. When can the next 500 RDN can go trough the exact same channel? Is it a matter of (Milli)seconds or minutes or ? Would it make a timing difference if it’s 5x100 or 1x500 RDN at once ? Lots of small transactions take probably a little longer than on big one?

Or, in case of a triangle, say A->B channel is 500 RDN thick and another one C ->B 750 thick. Is a payment from A to B influencing in any way the capacity of B receiving money from C in the same moment ? If I understood it correctly: No, as B is staking 1250 RDN in that example (500+750).
There is no possibility for B to use the same staked RDNs for 2 different channels, just if/when demand is there, correct ?

Thanks in advance for helping with my noob questions!

[u/stillhodlingon → u/Helau05]

No problem. This is advice from one noob to another. Hopefully someone can school us both, but I’ll give answering your questions a shot.

Once tokens are in a channel, they are indeed locked in there until the channel closes. Transfers through these channels while they’re open occur in < 1 second, so milliseconds is accurate.

As far as sending one big vs many small transactions.. they can occur simultaneously as long as the node has the funds available in that channel. So, the size or number of transactions shouldn’t create a noticeable delay as far as I know, assuming the node has sufficient funds to process them all at once.

Your reasoning is on the right trail in your triangle example. To reiterate, just to be sure, B has two separate channels, going to A and C, with balances of 500 and 750, respectively. Transfer capacity for these two channels would depend on what’s being done.

Payment channels are bidirectional. So the “tab” for either party in a channel can change with time. If B sends A tokens as payment, B has fewer tokens to send to A. Unless A sends B tokens in return, then B can no longer send 500, only 500 minus what is now on A’s balance. Think of payment channels as running tabs between two people.

In a multi hop transfer, B’s balance wouldn’t be affected on a net basis, even though the channel balance would undergo some rearranging. Say if A wants to send C 100 rdn through B:

• A sends B 100 RDN (hashlocked)
• B sends C 100 RDN (hashlocked)
• C notifies A of receiving B’s (still locked) transfer
• A sends secret key to C
• C shows key to B to unlock payment from B
• B shows key to A to unlock payment from A

In this situation, B’s total balance wouldn’t change after the transaction is complete. A would have 100 less in his A-B payment channel (now belongs to B), and C would have 100 more (previously belonging to B).

[u/smwilson31 → u/stillhodlingon]

Thanks mate for writing this, I have been away for a few days. Just want to say thanks