docs(anoncomms): add AnonComms roadmap for Testnet v0.3 by jm-clius · Pull Request #471 · logos-co/roadmap

jm-clius · 2026-06-11T16:17:46Z

Add the Roadmap (FURPS and Deliverables) for AnonComms in Testnet v0.3 scope

tinniaru3005 · 2026-06-17T19:15:03Z

+
+**FURPS**:
+
+- P1. The service discovery module provides comparable performance to discv5 when all nodes support the same service


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"

Thanks! I get your point re overhead when all nodes are running the same service. However, I'm not sure how that affects the subjective behaviour of "how long does it take me to discover up to n peers supporting this service?". I.e. even though nodes will have some overhead with registering, congestion control, etc. we still want to see the discoverer be able to discover new peers in a way that's roughly "comparable" to discv5. Admittedly, "comparable" is a very vague term here, meant to give us the leeway to explain it as either a little faster (because less random) or with some overhead, depending on what we observe.

Agreed, registration/ticketing overhead on the advertiser side doesn't necessarily hurt the discoverer's discovery latency — that's really the metric we care about here. Maybe instead of leaving "comparable" undefined, we scope it to that specifically:

"The service discovery module's time for a discoverer to find N peers is comparable to discv5's when all nodes support the same service"

tinniaru3005 · 2026-06-17T20:22:41Z

+
+**FURPS**:
+
+- P3. Service discovery integrated in Logos Delivery provides comparable performance to discv5 when all nodes support the same service


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.

tinniaru3005 · 2026-06-17T20:24:25Z

Thanks for working on this, @jm-clius . I left a few comments that I think could help clarify some of the deliverables.

… paths

seugu · 2026-06-23T07:00:45Z

 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


on behalf of a Logos module

Should we specify the which Logos module?

Well, in this case the functionality should allow "any" Logos module to call this API to receive a membership. We do specify later on that we will do one such integration into Logos Delivery.

adklempner · 2026-07-01T15:07:24Z

+
+**FURPS**:
+
+- F9. The full RLN module encapsulates Zerokit proof generation and verification, expanding the basic RLN membership management module


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)

adklempner · 2026-07-01T15:09:34Z

+- [ ] 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)


CC @stubbsta

adklempner · 2026-07-01T15:17:56Z

+**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


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

Yes. The persistence is defined as part of the module deliverable. This deliverable just directs Delivery to use the module (including its persistence/keystore)

adklempner · 2026-07-03T16:54:27Z

+**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


Something to consider is whether or not the RLN key should be stored in the accounts module

Good point. I think this we can explore when we get to this deliverable.

(But it will be awesome if it could use it!)

…03' into anoncomms/roadmap-v03

… furps

…ting tracks and milestones

jm-clius · 2026-07-09T10:58:48Z

+
+**FURPS**:
+
+- U10. De-MLS integrates into libchat as a standard module using caller-provided services


@seugu when we say "standard module", do we mean a Logos core module?

Good catch actually. it is vague here. So it must be libchat module, I removed the "module" term since it may confuse everyone. Here.

De-MLS is integrated into libchat using caller-provided services

jm-clius · 2026-07-09T11:01:58Z

+- P1. Price updates are completed within a reasonable time bound
+- P2. Cross-zone transaction latency is benchmarked


@seugu it would be useful to include a U-item here to define exactly what kind of tangible deliverable we are expecting here (e.g. U5. Developer documentation for the Oracle Zone is published in a document & U6. Benchmark results for the Oracle Zone is published in a research blog)

Yes indeed. Added here by adding U5 and U6, as well as oracle_v.0.3.md

jm-clius · 2026-07-09T11:17:51Z

+
+**FURPS**:
+
+- P1. The service discovery module provides comparable performance to discv5 when all nodes support the same service


Thanks! I get your point re overhead when all nodes are running the same service. However, I'm not sure how that affects the subjective behaviour of "how long does it take me to discover up to n peers supporting this service?". I.e. even though nodes will have some overhead with registering, congestion control, etc. we still want to see the discoverer be able to discover new peers in a way that's roughly "comparable" to discv5. Admittedly, "comparable" is a very vague term here, meant to give us the leeway to explain it as either a little faster (because less random) or with some overhead, depending on what we observe.

jm-clius · 2026-07-09T11:19:05Z

 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


Well, in this case the functionality should allow "any" Logos module to call this API to receive a membership. We do specify later on that we will do one such integration into Logos Delivery.

jm-clius · 2026-07-09T11:21:04Z

+**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


Yes. The persistence is defined as part of the module deliverable. This deliverable just directs Delivery to use the module (including its persistence/keystore)

jm-clius · 2026-07-09T11:21:31Z

+**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


Good point. I think this we can explore when we get to this deliverable.

jm-clius · 2026-07-09T11:21:49Z

+**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


(But it will be awesome if it could use it!)

vinhtc27 · 2026-07-09T19:55:32Z

I suggested these changes to the zerokit FURPS to align with the current and upcoming roadmap.

# Zerokit FURPS ## Functionality 1. Zerokit supports the automatic generation of round parameters for Poseidon. 2. Zerokit supports Poseidon2 as an alternative hash function alongside Poseidon. ## Usability 1. The Zerokit public API is defined by a specification. 2. The Zerokit public API provides an easy-to-use interface for Rust developers. 3. The Zerokit FFI provides an easy-to-use interface for developers using C and Nim. 4. Zerokit provides a WebAssembly (WASM) interface for both Node.js and browser environments. 5. Zerokit supports the automatic generation of round parameters for both Poseidon and Poseidon2. 7. Hash function selection (Poseidon vs. Poseidon2) is exposed through a runtime-configurable option. 6. The implementation of the new Poseidon2 circuit has been completed and documented in the circom-rln repo. 8. The Zerokit architecture is changed from compile-time feature flags to runtime configuration based on enums. ## Reliability 1. Poseidon2 proofs verify correctly, and Poseidon behavior remains unchanged when Poseidon2 is enabled. ## Performance 1. Poseidon2 proof generation is benchmarked against Poseidon and demonstrates measurable performance improvements. ## Supportability 1. Static analysis of the circuits for both Poseidon and Poseidon2 is performed and documented. 1. Outstanding issues are resolved, and dependencies are updated to keep the codebase maintainable. 3. New Poseidon2-related functionality and APIs are fully exposed through the FFI and WASM interfaces.

@seugu mind taking a look :)

Thanks @vinhtc27, really appreciate your suggestion.
I noticed your changes drop "F1. The Zerokit module supports big-endian operations" (and the big-endian FFI item in the old U3)
My guess is that these are already implemented in Zerokit, so they no longer need to be tracked here. Is that right? If you don't mind, could you add a line-by-line comment explaining each change (removing and changing)? That would make it much easier for both of us to go through.

@seugu
Yes, big-endian operations are now fully supported in Zerokit across the Rust public API, FFI, and WASM.
Partial proof support and the multi-message ID are now runtime configurable, with full support in Rust, FFI, and WASM.
I think we can remove both of these from the Usability section since they are already completed.

The remaining upcoming features are:
5. Zerokit supports the automatic generation of round parameters for both Poseidon and Poseidon2.
6. The implementation of the new Poseidon2 circuit has been completed and documented in the circom-rln repository.
7. Hash function selection (Poseidon vs. Poseidon2) is exposed through a runtime-configurable option.

Also, the work from U1 to U4 and U8 is something we should keep in mind when developing any new features.

Thank you,

Yes, big-endian operations are now fully supported in Zerokit across the Rust public API, FFI, and WASM.

So, we are keeping F1 (not mention in v0.3 since we already have this) and add new ones for v0.3, and deliver these new items. So you can add the new ones and modification requirements.

vinhtc27 · 2026-07-09T20:14:10Z

+**Resources Required**:
+- 3 developers for 12 weeks
+
+## Deliverables


We should add another deliverable to support the automatic generation of Poseidon round parameters.
This corresponds to FURPS: F1, U5, and R1 from the changes I proposed in zerokit.md file.

Since we will be doing substantial work related to the Poseidon hash in Testnet v0.3, this is a good opportunity to address this longstanding TODO in the zerokit codebase.

@seugu mind taking a look :)

tinniaru3005

LGTM for the discovery deliverables.

docs(anoncomms): add discovery FURPS and deliverables for v0.3

edfb357

jm-clius changed the title ~~docs(anoncomms): add discovery FURPS and deliverables for v0.3~~ docs(anoncomms): add AnonComms roadmap for Testnet v0.3 Jun 11, 2026

tinniaru3005 reviewed Jun 17, 2026

View reviewed changes

Comment thread content/anoncomms/furps/discovery.md

tinniaru3005 reviewed Jun 17, 2026

View reviewed changes

Comment thread content/anoncomms/roadmap/testnet_v0.2/discovery_v0.2.md

tinniaru3005 reviewed Jun 17, 2026

View reviewed changes

seugu and others added 6 commits June 18, 2026 16:21

docs(anoncomms): add oracle FURPS and deliverables for v0.3

c87ac85

docs(anoncomms): add mix v0.3 milestone, update FURPS, narrow v0.2 scope

4e41910

docs(anoncomms): fix duplicate v0.3 section in index, add oracle entry

c508ff5

docs(rln): add v0.3 milestone, update FURPS, rescope v0.2 deliverables

e565961

docs(anoncomms): v0.3 consistency pass — date, title format, absolute…

1acf0bd

… paths

docs(anoncomms): add zerokit FURPS and deliverables for v0.3

2fef01e

seugu reviewed Jun 23, 2026

View reviewed changes

adklempner reviewed Jul 1, 2026

View reviewed changes

jm-clius mentioned this pull request Jul 3, 2026

[Deliverable] Specify and implement extended DoS and exit node abuse protection for libp2p mix logos-co/anoncomms-pm#40

Closed

4 tasks

adklempner reviewed Jul 3, 2026

View reviewed changes

seugu and others added 6 commits July 7, 2026 09:03

docs(anoncomms): add de-mls FURPS and deliverables for v0.3

b82c79d

docs(anoncomms): added more mix deliverables for v0.3

488317f

Merge remote-tracking branch 'refs/remotes/origin/anoncomms/roadmap-v…

0a43e78

…03' into anoncomms/roadmap-v03

Merge branch 'v4' into anoncomms/roadmap-v03

4549c61

docs(anoncomms): add service incentivisation roadmap deliverables and…

6b3b36b

… furps

fix(anoncomms): fix broken/relative links and sync index.md with exis…

76214d4

…ting tracks and milestones

jm-clius commented Jul 9, 2026

View reviewed changes

vinhtc27 requested changes Jul 9, 2026

View reviewed changes

seugu added 2 commits July 10, 2026 14:34

docs(de-mls): adjusting U10

99889b1

docs(oracle): adding tengible deliverables for Us

b5e4d89

tinniaru3005 approved these changes Jul 10, 2026

View reviewed changes


		FURPS:

		- P1. The service discovery module provides comparable performance to discv5 when all nodes support the same service


		FURPS:

		- P3. Service discovery integrated in Logos Delivery provides comparable performance to discv5 when all nodes support the same service


		FURPS:

		- F9. The full RLN module encapsulates Zerokit proof generation and verification, expanding the basic RLN membership management module


		FURPS:

		- U10. De-MLS integrates into libchat as a standard module using caller-provided services

		- P1. Price updates are completed within a reasonable time bound
		- P2. Cross-zone transaction latency is benchmarked

Uh oh!

Uh oh!

Conversation

jm-clius commented Jun 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tinniaru3005 commented Jun 17, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

seugu Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vinhtc27 Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tinniaru3005 left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

jm-clius commented Jun 11, 2026 •

edited

Loading

seugu Jul 10, 2026 •

edited

Loading

vinhtc27 Jul 9, 2026 •

edited

Loading