It should be possible to use Swarm on as many types of devices and configurations as possible.
Owner
Swarm: Louis Holbrook @nolash
Stakeholder Point of Contact
Status: Oskar Thorén @oskarth
Felfele: Attila Gazso @agazso
Mainframe: Paul Lecam @PaulLecam
Datafund: Daniel Nickless @significance
Dependencies
The two first subtracks below contain parts that can be run in parallell. Network testing requisites is included as a separate track to specifically highlights test scenarios for proof of acceptance criteria. It may be merged to the two first tracks later on.
The given dependencies are concrete development tasks. Their coloring determine what they are and which main track they belong to.
Legend
PSS SUBTRACK
BZZ SUBTRACK
NETWORK TEST REQUISITES
Optional
ENR integration
Migration from devp2p to libp2p
Description
By resource-restricted we mean devices that have restrictions on one of more of:
bandwidth
network latency
cpu
memory
storage
The node should be capable of any combination of three modes of operation:
supporting PSS
retrieving data from the network
adding data to the network
Context
Some devices and some scenarios come with restriced resources. Simulatenously these devices and scenarios may represent the bulk for end-users for applications building on Swarm. It must be possible to run Swarm with the bare necessities for the application's purpose.
Adaptive and "light" node implementations are strongly in demand by several parties currently working on Swarm integration.
Issues
Acceptance criteria
Need to define:
Resource usage benchmarks and limits
cpu
mem
bandwidth
storage caches
Proof
Swarm MVP network tests
PSS delivery verification tests using 1000 docker nodes on kubernetes cluster with high message traffic load.
Cluster network running n full nodes and m light nodes over t period of time, where m light nodes iterate over the following test steps in sequence:
Focus was shifted strongly in favor of getting the spec's first. @nolash please update the epic accordingly to the new ETA estimation for doing the adaptive node implementation.
Rationale
It should be possible to use Swarm on as many types of devices and configurations as possible.
Owner
Stakeholder Point of Contact
Dependencies
The two first subtracks below contain parts that can be run in parallell. Network testing requisites is included as a separate track to specifically highlights test scenarios for proof of acceptance criteria. It may be merged to the two first tracks later on.
The given dependencies are concrete development tasks. Their coloring determine what they are and which main track they belong to.
Legend
PSS SUBTRACK
BZZ SUBTRACK
NETWORK TEST REQUISITES
Optional
ENR integration Migration from devp2p to libp2p
Description
By resource-restricted we mean devices that have restrictions on one of more of:
The node should be capable of any combination of three modes of operation:
Context
Some devices and some scenarios come with restriced resources. Simulatenously these devices and scenarios may represent the bulk for end-users for applications building on Swarm. It must be possible to run Swarm with the bare necessities for the application's purpose.
Adaptive and "light" node implementations are strongly in demand by several parties currently working on Swarm integration.
Issues
Acceptance criteria
Need to define:
Proof
Swarm MVP network tests
PSS delivery verification tests using 1000 docker nodes on kubernetes cluster with high message traffic load.
Cluster network running
n
full nodes andm
light nodes overt
period of time, wherem
light nodes iterate over the following test steps in sequence: