docs(anoncomms): add AnonComms roadmap for Testnet v0.3#471
Conversation
jm-clius
changed the title
| 4. Libp2p nodes can use a general service discovery API to discover peers with specific capabilities | ||
| 5. The service discovery protocol adapts DISC-NG for Kad-DHT to ensure efficient service discovery | ||
| 6. Client nodes can discover addresses of peers with specific capabilities without participating in the Kad-DHT | ||
| 7. Service discovery correctly discovers all advertised peers in a topology of several thousand nodes |
There was a problem hiding this comment.
I think "all advertised peers" contradicts the protocol's early-termination design. It should be "up to F_lookup peers". F_lookup s current default value is 30. The protocol is designed to stop early — finding every single advertiser in the network is not the goal and would break the logarithmic scaling property
May be we can rewrite something like this:
Service discovery correctly discovers up to F_lookup peers for a given service in a topology of several thousand nodes.
| - P2. Capability discovery performs better than discv5 to find a sparse service | ||
| - S1. Capability discovery can be benchmarked in large scale Delivery module simulations | ||
| - S2. Capability discovery can be benchmarked in a standalone p2p capability discovery module | ||
| - F7. Service discovery correctly discovers all advertised peers in a topology of several thousand nodes |
There was a problem hiding this comment.
We can rewrite this part also to something like:
Service discovery correctly discovers up to F_lookup peers for a given service in a topology of several thousand nodes.
to better align with the protocol design
|
|
||
| **FURPS**: | ||
|
|
||
| - P1. The service discovery module provides comparable performance to discv5 when all nodes support the same service |
There was a problem hiding this comment.
When all nodes support the same service is exactly the scenario where service discovery has inherent overhead that discv5 does not — admission control, waiting times, ticket rounds, and K_register × m registration attempts per advertiser. The protocol is designed for the sparse case, not the popular one.
We can reframe as "service discovery performs within an acceptable overhead bound compared to discv5 for popular services"
|
|
||
| **FURPS**: | ||
|
|
||
| - P3. Service discovery integrated in Logos Delivery provides comparable performance to discv5 when all nodes support the same service |
There was a problem hiding this comment.
Similarly here also we can reframe to clarify little on what comparable means as for all nodes participating in same service, ie, a popular service case, service discovery has extra overhead.
|
Thanks for working on this, @jm-clius . I left a few comments that I think could help clarify some of the deliverables. |
| 3. Logos modules can use the service as client to obtain adequate registered RLN identities without interacting with the contract | ||
| 4. The RLN membership allocation service can run as a standalone module or mounted on existing modules | ||
| 5. Logos modules can read the on-chain Merkle root and proofs | ||
| 6. The basic RLN membership management module can register RLN memberships on-chain on behalf of a Logos module |
There was a problem hiding this comment.
on behalf of a Logos module
Should we specify the which Logos module?
|
|
||
| **FURPS**: | ||
|
|
||
| - F9. The full RLN module encapsulates Zerokit proof generation and verification, expanding the basic RLN membership management module |
There was a problem hiding this comment.
I am a big fan of the separation of concerns, but we also need to consider the performance overhead of generating proofs using logos core module cross-calls v.s. generating proofs within the same process (as is currently done in logos-delivery)
| - [ ] Dogfood: link to dogfooding session/artefact | ||
| - [ ] Docs: links to README.md or other docs | ||
|
|
||
| ### [Migrate Logos Delivery to LEZ-based RLN using the RLN membership management module](TBD: anoncomms-pm issue) |
| **FURPS**: | ||
|
|
||
| - U2. Logos Delivery and Chat can use the service to obtain RLN memberships | ||
| - U5. Logos Delivery uses the basic RLN membership management module and LEZ-based RLN for all membership acquisition and management |
There was a problem hiding this comment.
does this include storing the membership? i.e. instead of loading the identity secret from a local keystore to memory, logos-delivery would call the management module to load this value
| **FURPS**: | ||
|
|
||
| - F6. The basic RLN membership management module can register RLN memberships on-chain on behalf of a Logos module | ||
| - F7. The basic RLN membership management module stores and manages RLN keys for a Logos module |
There was a problem hiding this comment.
Something to consider is whether or not the RLN key should be stored in the accounts module
4 participants
Add the Roadmap (FURPS and Deliverables) for AnonComms in Testnet v0.3 scope