Giters

raiden-network / raiden

Raiden Network

Home Page:https://developer.raiden.network

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Show linear scaling with an example

fredo opened this issue · comments

commented

The Raiden Protocol is promised to scale linearly with the number of agents. That means the more agents are active in the Raiden Network the more concurrent transfers can be facilitated by all agents together. It will be possible to develop a Raiden client which will enable 1,000 - 1,000,000 transfers per second in the Raiden Network.

Fulfilment criteria:
In order to assess whether BBLE has adhered to this obligation the following steps shall be undertaken:
the Raiden protocol has been reviewed and a confirmation is provided that the Raiden protocol allows linear scaling <of what?> with the number of agents.
the Raiden protocol has been reviewed and a confirmation is provided that the Raiden protocol allows scaling in a way such that a Raiden client facilitating 1,000 - 1,000,000 tps is possible.
the supporting documentation of the Deliverables confirms the first and second point and the limitations thereof

Suggestion

  • Create a Hub on a powerful machine (M)
  • Create Client pairs for payments (I(n), T(n))
  • Create channels like I(n) - M - T(n)
  • Repeat the process n times until M does not scale linearly anymore

Open question

  • Are the Raiden nodes on equal machines?
  • If yes, how can we realistically measure the throuhgput factoring out local connections
commented

Multiple options for running the nodes:

  1. Run everything on one (or a few) very powerful machines (e.g. AWS 96 core instances)
    • Pros:
      • Can use scenario player (if a single machine)
      • Easy setup
    • Cons:
      • Skews results because of missing network latency
      • Possible bottleneck on other resources (local disk, network stack, etc.)
  2. Modify SP to be able to run nodes on (many) remote machines
    • Pros:
      • Allows to to use scenario definition for orchestration
      • Close to "real life"
    • Cons:
      • Requires changes to SP and additional infrastructure
  3. Use some existing cloud deployment solution e.g. docker swarm
    • Pros:
      • Easy deployment of many nodes
      • Close to "real life"
    • Cons:
      • Can't use SP / Needs external orchestration of transfers

If we don't want to / can't use option 1. (due to the cons listed) I'd argue that option 3. is probably the best candidate.

Recording of the „raiddit“ example which was similar in some regards: https://youtu.be/402U0CVrjyE