logos-co/roadmap
1
0
Fork 0
mirror of https://github.com/logos-co/roadmap.git synced 2026-08-27 09:01:07 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(anoncomms): add AnonComms roadmap for Testnet v0.3 (#471)

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

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

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

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

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

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

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

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

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

* docs(anoncomms): add service incentivisation roadmap deliverables and furps

* fix(anoncomms): fix broken/relative links and sync index.md with existing tracks and milestones

* docs(de-mls): adjusting U10

* docs(oracle): adding tengible deliverables for Us

* docs(zerokit): add Zerokit v3 release for v0.3

* docs(fix): remove old issue link

* docs(zerokit): added new FURPS regarding P2 hash

* docs(anoncomms): use testnet-relative deadlines instead of concrete dates for v0.3

* docs(anoncomms): link v0.3 milestones and deliverables to anoncomms-pm issues

* docs(anoncomms): fix FURPS drift — add mix U21, identity F6 punctuation, drop superseded v0.2 identity spec deliverable

* docs: checklist for testnet v0.2

---------

Signed-off-by: haelius <hanno@status.im>
Co-authored-by: seugu <99656002+seugu@users.noreply.github.com>
Co-authored-by: kaiserd <1684595+kaiserd@users.noreply.github.com>
This commit is contained in:
haelius
2026-07-20 16:00:27 +01:00
committed by GitHub
co-authored by seugu kaiserd
parent f6da798e9e
commit b95ca18fea
30 changed files with 815 additions and 159 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/anoncomms/furps/de-mls.md
+7 -3
View File
@@ -9,6 +9,8 @@
5. Messaging groups have a recovery mode to deal with more serious unexpected group states
6. New joiners can properly setup the group state after being accepted into the group
7. Commits can be validated and violations appropriately handled
8. De-MLS obtains the current time through a caller-provided WallClock service instead of hardcoded debug timer values
9. A messaging group can recover from steward liveness failures by triggering a new steward list election
## Usability
@@ -21,10 +23,11 @@
7. The De-MLS API is available in Rust and C
8. De-MLS is included in the Logos Chat protocol stack specification
9. De-MLS is integrated into a working Logos Chat module deployed to Logos Core
10. De-MLS is integrated into libchat using caller-provided services
## Reliability
1.
1. De-MLS operates correctly within libchat
## Performance
@@ -35,9 +38,10 @@
## Supportability
1. Hashgraph-like consensus is separated out into its own library for modularity
2. The WallClock service provides test implementations that simulate time progression without real-time waits
## Miscellaneous dependencies:
1. Dependency on DST for benchmarking of consensus mechanism
1. Dependency on DST for benchmarking of de-MLS integrated protocol
1. Dependency on ChatSDK to clarify requirements for API
2. Dependency on DST for benchmarking of de-MLS integrated protocol
3. Dependency on ChatSDK to clarify requirements for API
content/anoncomms/furps/discovery.md
+34 -14
View File
@@ -1,29 +1,37 @@
# Capability Discovery FURPS
# Service Discovery FURPS
## Functionality
1. Libp2p Kad-DHT nodes can advertise their own addresses and capabilities in a signed record
2. Libp2p Kad-DHT nodes can discover and validate the signed records of random, advertised peers
3. Libp2p Kad-DHT nodes can filter discovered records for specific capabilities
4. Libp2p nodes can use a general capability discovery API to discover peers with specific capabilities
5. The capability discovery protocol adapts DISC-NG for Kad-DHT to ensure efficient capability discovery
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
8. Service discovery correctly discovers peers advertising a sparse service in a topology of several thousand nodes
## Usability
1. The capability discovery protocol is published in a specification
1. The service discovery protocol is published in a specification
2. A PoC implementation accompanies the published protocol
3. The PoC implementation contains instructions to allow open dogfooding
4. A forum post introduces the new protocol, explains privacy tradeoffs, and links to spec and PoC implementation
5. A Kad-DHT discovery protocol is published in a specification
6. The Kad-DHT discovery API is available in Nim
7. The reference Kad-DHT discovery implementation is completed in Nim over the nim-libp2p Kad-DHT implementation
8. The reference capability discovery implementation is completed in Nim over the nim-libp2p Kad-DHT implementation
9. Capability discovery is integrated in Logos Delivery to replace discv5 discovery
10. The capability discovery module is available as a Logos Core module
11. The capability discovery API is published in a specification
8. The reference service discovery implementation is completed in Nim over the nim-libp2p Kad-DHT implementation
9. Service discovery is integrated in Logos Delivery to discover libp2p mix nodes
10. The service discovery module is available as a Logos Core module
11. The service discovery API is published in a specification
12. An extensible peer record library allows application modules to create and maintain discoverable records
13. Capability discovery is integrated into `chat2mix` application for dogfooding
13. Service discovery is integrated into `chat2mix` application for dogfooding
14. Service discovery is built into Logos Delivery as a separate Logos core module
15. Service discovery can be configured in Logos Delivery as alternative ambient peer discovery to discv5
16. A research post introducing the service discovery protocol and its implementation, including DST performance results, is published on the Logos research blog
17. An analysis enumerating privacy-leaking actions in the service discovery protocol is published
18. A survey of anonymisation techniques applicable to DHT-based service discovery, including the Octopus protocol and mix-based approaches, is published
19. A roadmap for introducing anonymity properties into service discovery, including dependencies on the libp2p mix protocol, is published
## Reliability
@@ -31,15 +39,27 @@
## Performance
1. Capability discovery provides comparable performance to discv5 when all nodes support the same service
2. Capability discovery performs better than discv5 to find a sparse service
1. The service discovery module provides comparable performance to discv5 when all nodes support the same service
2. The service discovery module performs better than discv5 to find a sparse service
3. Service discovery integrated in Logos Delivery provides comparable performance to discv5 when all nodes support the same service
4. Service discovery integrated in Logos Delivery performs better than discv5 to find a sparse service
## Supportability
1. Capability discovery can be benchmarked in large scale Delivery module simulations
2. Capability discovery can be benchmarked in a standalone p2p capability discovery module
1. Service discovery can be functionally validated in large-scale standalone DST simulations
2. The service discovery module can be benchmarked in large-scale standalone DST simulations
3. Logos Delivery with integrated service discovery can be validated and benchmarked in large-scale DST simulations
## Miscellaneous dependencies:
1. Dependency on nim-libp2p implementation of Kad-DHT
1. Dependency on DST for benchmarking and iterative improvement
2. Dependency on DST for benchmarking and iterative improvement
<!-- ──────── post-mainnet ──────── -->
## Functionality
XX. Service discovery does not reveal to DHT intermediary nodes the full service lookup intent of a querying node
XX. Service discovery protects a querying node's network identity from correlation with their service lookup patterns by a passive network observer
XX. A node's advertisements of multiple services are not linkable to each other by passive DHT observers
XX. Service discovery request routing can be anonymised through an anonymous transport layer such as the libp2p mix protocol
content/anoncomms/furps/identity.md
+1 -1
View File
@@ -7,7 +7,7 @@
3. An account carries an append-only operation log of credential changes.
4. An account can be created without permission from any third party.
5. An account can hold one or more keys.
6. A new key can be added to an account
6. A new key can be added to an account.
7. A key can be revoked from the account.
8. Given an account address, anyone can query for the associated keys.
9. Single-key compromise must not permit irreversible account takeover.
content/anoncomms/furps/incentivisation.md
+13
View File
@@ -5,6 +5,14 @@
1. Client nodes can pay service nodes for decentralised services
2. The payment protocol is mostly off-chain (no on-chain transaction necessary per service request)
3. The payment protocol protects the privacy of the client by unlinking the payment from the service provision
4. The payment protocol shields the identity of the paying client from the network via LEZ private execution mode
5. The payment protocol shields the identity of the receiving service provider from the network
6. A client can discover service providers that offer a specific service
7. A client can discover the payment policy advertised by a discovered service provider
8. A provider's payment policy can specify which non-native tokens it accepts as payment
9. A payment pool can be shared across multiple service providers rather than being restricted to a single provider
10. The payment protocol prevents double-spending/double-claiming of rewards from a shared payment pool
11. Service providers can claim rewards from a shared payment pool in accordance with the service they provided, using a reputation- or receipt-based method
## Usability
@@ -13,6 +21,11 @@
3. The off-chain protocol is implemented in Nim
4. The on-chain component of the protocol is implemented for Logos Execution Zone
5. A demo Logos core module demonstrates the payment protocol functioning end-to-end for a service protocol
6. The LEZ-private-execution-mode-based client-shielding mechanism is published in a specification
7. A specification investigating how to shield the identity of the receiving service provider is published
8. A specification for discovering service providers and their payment policies via existing service discovery is published
9. A specification investigating support for non-native tokens in provider payment policies is published
10. A specification investigating a shared payment pool model supporting multiple service providers, double-spend prevention, and proportional reward claiming is published
## Reliability
content/anoncomms/furps/mix.md
+15 -2
View File
@@ -15,6 +15,10 @@
11. Providers can anonymously register as a hidden service
12. Clients can discover and anonymously access hidden services
13. The libp2p mix protocol's payload encryption preserves payload integrity
14. A standalone Logos Mix module encapsulates the Logos libp2p module with nim-libp2p-mix, RLN-based DoS protection, and cover traffic for Logos Core services
15. Applications can route libp2p request-response messages over mix via the Logos Mix module API
16. Mix nodes maintain a local reputation record for peers
17. Nodes can use advanced cover traffic patterns to improve anonymity
## Usability
@@ -28,8 +32,17 @@
8. The application-level mechanism to support large messages (requests & responses) is published in a specification
9. Cover traffic generation is published in a specification
10. The protocol allowing hidden service provisioning, discovery and access is published in a specification
11. Basic DHT interactions can be mixified
12. The libp2p mix protocol is integrated into the Logos Chat module
11. A DHT query can be mixified
12. The libp2p mix protocol is integrated into the Logos Mix Demo Chat module
13. The Sphinx payload encryption scheme providing payload integrity is published as a specification
14. The libp2p mix protocol is integrated into the Logos Delivery module with exposure on the Messaging API
15. The Logos Chat module provides a user interface to select mix when publishing messages
16. The Logos Mix module API for routing messages over mix is published as a specification
17. The anonymity limitations of the mix hidden services approach and alternative provider anonymity techniques are evaluated and published
18. Differentiated RLN rate-limiting based on peer reputation metrics is researched and published
19. Non-RLN DoS and Sybil protection approaches are researched and published
20. Advanced cover traffic patterns are researched and published in a specification
21. The opinionated protocol stack composition and configuration for a Logos Mix Network is specified
## Reliability
content/anoncomms/furps/oracle.md
+14 -9
View File
@@ -3,25 +3,30 @@
## Functionality
1. Oracle nodes fetch price data from predefined sources
2. Each oracle node signs its observation and participates in a simple off-chain consensus with a threshold
3. The agreed value is written to the LEZ contract
4. The LEZ contract exposes basic functions to update and read the latest price
2. Indexer performs onchain aggregation of signed node data
3. The LEZ contract exposes basic functions to update and read the latest price
4. Oracle nodes fetch price data from predefined sources according to a defined fetch specification
5. Cross zone TX enables provable atomic cross-zone transactions between oracle zone and LEZ
## Usability
1. The system design is documented in a LIP
2. The oracle nodes are implemented in Rust
2. The oracle nodes and indexer are implemented in Rust
3. The fetch mechanism is specified and documented
4. Atomic cross zone TX is deployed for cross-zone interactions involving the oracle zone
5. Developer documentation for the Oracle Zone is published in a document
6. Benchmark results for the Oracle Zone are published in a research blog
## Reliability
1. Consensus requires agreement from multiple (majority) nodes
2. Basic protection against faulty or inconsistent data via multi-source aggregation.
1. Basic protection against faulty or inconsistent data via multi-source aggregation
## Performance
1. Price updates are completed within a reasonable time bound
1. Price updates are completed within a reasonable time bound
2. Cross-zone transaction latency is benchmarked
## Supportability
1.
1. Oracle node and indexer operations are logged to enable debugging of fetch and aggregation failures
2. PACT cross-zone transaction failures are logged with sufficient detail for diagnosis
content/anoncomms/furps/rln.md
+7
View File
@@ -7,12 +7,19 @@
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
7. The basic RLN membership management module stores and manages RLN keys for a Logos module
8. The basic RLN membership management module can operate as a client in the libp2p RLN membership allocation protocol
9. The full RLN module encapsulates Zerokit proof generation and verification, expanding the basic RLN membership management module
## Usability
1. The RLN membership allocation protocol is published in a specification
2. Logos Delivery and Chat can use the service to obtain RLN memberships
3. The RLN contract is implemented for Logos Execution Zone
4. The basic RLN membership management module API is published as a specification
5. Logos Delivery uses the basic RLN membership management module and LEZ-based RLN for all membership acquisition and management
6. Advanced authentication mechanisms for RLN membership allocation, including device keys, are evaluated and published
## Reliability
content/anoncomms/furps/zerokit.md
+12 -17
View File
@@ -2,35 +2,30 @@
## Functionality
1. The RLN prover module supports gasless L2 operations
2. Multiple RLN prover instances can operate on a shared database
3. An RLN prover can burn multiple message-ids in a single proof
4. The Zerokit module supports big-endian operations
5. The RLN prover module supports proof output streaming to an aggregator node
1. The Zerokit module supports big-endian operations
2. Zerokit supports Poseidon2 as an alternative hash function alongside Poseidon
3. Zerokit supports the automatic generation of round parameters for both Poseidon and Poseidon2
## Usability
1. The Zerokit public API is defined in a specification
2. The Zerokit public API provides an easy-to-use interface for developers in Rust and C
3. The Zerokit FFI, including WASM targets, supports big-endian arguments
4. The RLN prover module has an associated specification
5. A Zerokit release is published introducing partial proof generation and multi-ID burning
6. The Zerokit architecture is changed from compile-time feature flags to runtime configuration based on enums
4. A Zerokit release is published introducing partial proof generation and multi-ID burning
5. The Zerokit architecture is changed from compile-time feature flags to runtime configuration based on enums
6. The hash function selection (Poseidon vs Poseidon2) is exposed via the runtime configuration enum
7. The implementation of the new Poseidon2 circuit has been completed and documented in the circom-rln repo
## Reliability
1. Multiple RLN prover instances operate consistently without database conflicts
2. The aggregator relays RLN proof metadata to decentralized slashers
3. Decentralized slashers extract the secret from double-signaled (spammed) proofs to enable slashing
1. Poseidon2 proofs verify correctly and Poseidon behavior remains unchanged when Poseidon2 is enabled
## Performance
1.
1. Poseidon2 proof generation is benchmarked against Poseidon and demonstrates measurable improvement
## Supportability
1. A gasless L2 whitepaper is written to document the design and trade-offs
## Miscellaneous dependencies:
1. Dependency on Status L2 team for reviewing codebase
1. Outstanding issues and dependency updates are addressed to keep the codebase maintainable
2. Static analysis of the circuits for both Poseidon and Poseidon2 is performed and documented
3. New Poseidon2-related functionality and APIs are fully exposed through the FFI and WASM interfaces
content/anoncomms/roadmap/de-mls.md
+1
View File
@@ -20,6 +20,7 @@ This includes a public API wrapping the functionality.
**Scheduled milestones**:
- [Testnet v0.1](/anoncomms/roadmap/testnet_v0.1/de-mls_v0.1.md)
- [Testnet v0.2](/anoncomms/roadmap/testnet_v0.2/de-mls_v0.2.md)
- [Testnet v0.3](/anoncomms/roadmap/testnet_v0.3/de-mls_v0.3.md)
Future work in this track, include:
1. Longer term benchmarking and testing to improve the efficiency and scalability of the consensus and messaging protocol.
content/anoncomms/roadmap/discovery.md
+6 -5
View File
@@ -1,4 +1,4 @@
# Capability Discovery Track
# Service Discovery Track
A major cornerstone of the Logos Launch Strategy
is the efficient discovery of core services in a fully decentralised manner.
@@ -6,17 +6,18 @@ The current approach to decentralised discovery, random walks over libp2p's Kad-
is not scalable and efficient enough for a diverse ecosystem consisting of multiple services,
facing the [needle-in-a-haystack problem](https://vac.dev/rlog/wakuv2-apd#random-walk-performance-estimation).
In this track, we're building a fully functional, efficient capability discovery module available in Logos Core,
In this track, we're building a fully functional, efficient service discovery module available in Logos Core,
usable by all Logos modules as primary ambient discovery method.
The new capability discovery protocol will be published as a specification adapting [DISC-NG](https://ieeexplore.ieee.org/document/10629017) for libp2p Kad-DHT.
The new service discovery protocol will be published as a specification adapting [DISC-NG](https://ieeexplore.ieee.org/document/10629017) for libp2p Kad-DHT.
## Roadmap
**FURPS**: [Capability Discovery FURPS](/anoncomms/furps/discovery.md)
**FURPS**: [Service Discovery FURPS](/anoncomms/furps/discovery.md)
**Scheduled milestones**:
- [Testnet v0.1](/anoncomms/roadmap/testnet_v0.1/discovery_v0.1.md)
- [Testnet v0.2](/anoncomms/roadmap/testnet_v0.2/discovery_v0.2.md)
- [Testnet v0.3](/anoncomms/roadmap/testnet_v0.3/discovery_v0.3.md)
Future work in this track, include:
1. Anonymising the discovery protocol, including privacy-preserving discovery requests, anonymous DHT participation, etc.
@@ -28,4 +29,4 @@ Future work in this track, include:
| Risk | (Accept, Own, Mitigation) |
|------------------------|------------------------------------------------------------------------------------------------------------------|
| Dependency on nim-libp2p for Kad-DHT implementation | Close collaboration with p2p team; specify API before implementation ready to harden interfaces quickly |
| Dependency on DST team for benchmarking and iterative improvements | Develop test strategy/simulations from the outset in collaboration with DST team |
| Dependency on DST team for benchmarking and iterative improvements | Develop test strategy/simulations from the outset in collaboration with DST team |
content/anoncomms/roadmap/incentivisation.md
+1
View File
@@ -15,6 +15,7 @@ In this track, we specify and implement a privacy-preserving payment protocol fo
**Scheduled milestones**:
- [Testnet v0.1](/anoncomms/roadmap/testnet_v0.1/incentivisation_v0.1.md)
- [Testnet v0.2](/anoncomms/roadmap/testnet_v0.2/incentivisation_v0.2.md)
- [Testnet v0.3](/anoncomms/roadmap/testnet_v0.3/incentivisation_v0.3.md)
## Risks
content/anoncomms/roadmap/index.md
+37 -15
View File
@@ -11,14 +11,14 @@ tags:
The AnonComms team is currently working on the following features, required for mainnet:
1. [Create a basic capability discovery module for Logos Core](/anoncomms/roadmap/discovery.md), by defining an efficient capability discovery protocol over libp2p kad-DHT.
1. [Create a basic service discovery module for Logos Core](/anoncomms/roadmap/discovery.md), by defining an efficient service discovery protocol over libp2p kad-DHT.
2. [Establish a libp2p mixnet for Logos Core](/anoncomms/roadmap/mix.md), with a special focus on DoS/Sybil protection and delivering privacy-preserving file sharing in collaboration with the Logos Storage team.
3. [Deliver de-MLS for p2p group messaging](/anoncomms/roadmap/de-mls.md), with a special focus on integration in the Logos Chat module.
4. [Implement RLN membership allocation service for Logos Core](/anoncomms/roadmap/rln.md), including translating RLN to run in the Logos Execution Zone (LEZ)
5. [Research and develop an LEZ-compatible Decentralised Oracle Network](/anoncomms/roadmap/oracle.md), in support of features such as a stablecoin
Of these, (1) and (2) are the most critical,
as basic capability discovery and routing anonymity
as basic service discovery and routing anonymity
will be foundational to much of the Logos Core infrastructure.
In addition, the team is also working on tracks,
@@ -28,6 +28,7 @@ or are not critical for mainnet launch.
6. [Implement an MVP payment protocol](/anoncomms/roadmap/incentivisation.md) that exploits Logos Blockchain/Nescience to allow privacy-preserving, mostly off-chain payments to service providers.
7. [Maintain and expand the Zerokit library](/anoncomms/roadmap/zerokit.md) that improves usability and add big-endian support.
8. [Support gasless L2 transactions](/anoncomms/roadmap/gasless-l2.md) on Status Network, including publishing a whitepaper.
9. [Develop the λAccount identity primitive](/anoncomms/roadmap/identity.md), a VLAD-based identity anchor developed cross-team with Logos Chat, extending to Blockchain and Storage needs.
## Testnet Milestones
@@ -37,7 +38,7 @@ The work is split into milestones, according to the targeted Logos testnet/relea
Features critical for the testnet:
- [x] [Capability Discovery Testnet v0.1 Deliverables](/anoncomms/roadmap/testnet_v0.1/discovery_v0.1.md)
- [x] [Service Discovery Testnet v0.1 Deliverables](/anoncomms/roadmap/testnet_v0.1/discovery_v0.1.md)
- [x] [Mix Testnet v0.1 Deliverables](/anoncomms/roadmap/testnet_v0.1/mix_v0.1.md)
Non-critical features explored within testnet scope:
@@ -45,23 +46,24 @@ Non-critical features explored within testnet scope:
- [x] [Service Incentivisation Testnet v0.1 Deliverables](/anoncomms/roadmap/testnet_v0.1/incentivisation_v0.1.md)
- [x] [De-MLS Testnet v0.1 Deliverables](/anoncomms/roadmap/testnet_v0.1/de-mls_v0.1.md)
- [x] [Zerokit Testnet v0.1 Deliverables](/anoncomms/roadmap/testnet_v0.1/zerokit_v0.1.md)
- [ ] [Gasless L2 Testnet v0.1 Deliverables](/anoncomms/roadmap/testnet_v0.1/gasless-l2_v0.1.md)
- [ ] [RLN Testnet v0.1 Deliverables](/anoncomms/roadmap/testnet_v0.1/rln_v0.1.md)
- [x] [Gasless L2 Testnet v0.1 Deliverables](/anoncomms/roadmap/testnet_v0.1/gasless-l2_v0.1.md)
- [x] [RLN Testnet v0.1 Deliverables](/anoncomms/roadmap/testnet_v0.1/rln_v0.1.md)
### Testnet v0.2
Features critical for the testnet:
- [ ] [Capability Discovery Testnet v0.2 Deliverables](/anoncomms/roadmap/testnet_v0.2/discovery_v0.2.md)
- [ ] [Mix Testnet v0.2 Deliverables](/anoncomms/roadmap/testnet_v0.2/mix_v0.2.md)
- [ ] [De-MLS Testnet v0.2 Deliverables](/anoncomms/roadmap/testnet_v0.2/de-mls_v0.2.md)
- [x] [Service Discovery Testnet v0.2 Deliverables](/anoncomms/roadmap/testnet_v0.2/discovery_v0.2.md)
- [x] [Mix Testnet v0.2 Deliverables](/anoncomms/roadmap/testnet_v0.2/mix_v0.2.md)
- [x] [De-MLS Testnet v0.2 Deliverables](/anoncomms/roadmap/testnet_v0.2/de-mls_v0.2.md)
- [x] [Identity Track Testnet v0.2 Deliverables](/anoncomms/roadmap/testnet_v0.2/identity_v0.2.md)
Non-critical features explored within testnet scope:
- [ ] [Service Incentivisation Testnet v0.2 Deliverables](/anoncomms/roadmap/testnet_v0.2/incentivisation_v0.2.md)
- [ ] [Zerokit Testnet v0.2 Deliverables](/anoncomms/roadmap/testnet_v0.2/zerokit_v0.2.md)
- [ ] [RLN Testnet v0.2 Deliverables](/anoncomms/roadmap/testnet_v0.2/rln_v0.2.md)
- [ ] [Oracle Testnet v0.2 Deliverables](/anoncomms/roadmap/testnet_v0.2/oracle_v0.2.md)
- [x] [Service Incentivisation Testnet v0.2 Deliverables](/anoncomms/roadmap/testnet_v0.2/incentivisation_v0.2.md)
- [x] [Zerokit Testnet v0.2 Deliverables](/anoncomms/roadmap/testnet_v0.2/zerokit_v0.2.md)
- [x] [RLN Testnet v0.2 Deliverables](/anoncomms/roadmap/testnet_v0.2/rln_v0.2.md)
- [x] [Oracle Testnet v0.2 Deliverables](/anoncomms/roadmap/testnet_v0.2/oracle_v0.2.md)
#### Modules
@@ -71,9 +73,9 @@ For Testnet v0.2, the AnonComms team have responsibilities within the following
- De-MLS backed group chat implementation
- Mix-based publishing _with demo-version pluggable DoS protection based on RLN_
- Basic RLN integration for Mix DoS protection and RLN-Relay publishing
- Basic capability discovery integration
- Basic service discovery integration
- Capability discovery module
- Service discovery module
- Module is provided by P2P team, but supported/red teamed by AnonComms
Although not critical for the testnet,
@@ -81,7 +83,7 @@ the AnonComms team aim to have the following optional features as part of Testne
- Logos Chat module:
- RLN membership allocation for mix (demo client mode)
- _Integration_ of capability discovery module
- _Integration_ of service discovery module
- Demo RLN membership allocation module
- distributes RLN memberships in off-chain protocol based on pluggable authentication
@@ -90,3 +92,23 @@ the AnonComms team aim to have the following optional features as part of Testne
- Demo Store payment module
- demonstrates the payment protocol functioning end-to-end for accessing Waku Store services
### Testnet v0.3
Features critical for the testnet:
- [ ] [Service Discovery Testnet v0.3 Deliverables](/anoncomms/roadmap/testnet_v0.3/discovery_v0.3.md)
- [ ] [Identity Track Testnet v0.3 Deliverables](/anoncomms/roadmap/testnet_v0.3/identity_v0.3.md)
- [ ] [Mix Testnet v0.3 Deliverables](/anoncomms/roadmap/testnet_v0.3/mix_v0.3.md)
- [ ] [Oracle Testnet v0.3 Deliverables](/anoncomms/roadmap/testnet_v0.3/oracle_v0.3.md)
- [ ] [RLN Testnet v0.3 Deliverables](/anoncomms/roadmap/testnet_v0.3/rln_v0.3.md)
- [ ] [De-MLS Testnet v0.3 Deliverables](/anoncomms/roadmap/testnet_v0.3/de-mls_v0.3.md)
Non-critical features explored within testnet scope:
- [ ] [Service Incentivisation Testnet v0.3 Deliverables](/anoncomms/roadmap/testnet_v0.3/incentivisation_v0.3.md)
- [ ] [Zerokit Testnet v0.3 Deliverables](/anoncomms/roadmap/testnet_v0.3/zerokit_v0.3.md)
### Mainnet
- [ ] [Identity Track Mainnet Deliverables](/anoncomms/roadmap/mainnet/identity_mainnet.md)
content/anoncomms/roadmap/mainnet/identity_mainnet.md
+1 -1
View File
@@ -20,7 +20,7 @@ and key revocation.
## Deliverables
### [Mainnet deployment with Logos Blockchain-backed registry](TBD)
### [Mainnet deployment with Logos Blockchain-backed registry](TBD: anoncomms-pm issue)
**Owner**: Messaging Chat (primary), AnonComms Identity (review)
content/anoncomms/roadmap/mix.md
+1
View File
@@ -20,6 +20,7 @@ as pluggable extensions to the libp2p mix specification.
**Scheduled milestones**:
- [Testnet v0.1](/anoncomms/roadmap/testnet_v0.1/mix_v0.1.md)
- [Testnet v0.2](/anoncomms/roadmap/testnet_v0.2/mix_v0.2.md)
- [Testnet v0.3](/anoncomms/roadmap/testnet_v0.3/mix_v0.3.md)
Future work in this track, include:
1. Introducing longer-lived mix circuits
content/anoncomms/roadmap/rln.md
+1
View File
@@ -21,6 +21,7 @@ and maintaining consistent specifications.
**Scheduled milestones**:
- [Testnet v0.1](/anoncomms/roadmap/testnet_v0.1/rln_v0.1.md)
- [Testnet v0.2](/anoncomms/roadmap/testnet_v0.2/rln_v0.2.md)
- [Testnet v0.3](/anoncomms/roadmap/testnet_v0.3/rln_v0.3.md)
Future work in this track, include:
1. Refactoring the RLN specification(s) to a modular stack of RLN features, rather than a confusing array of RLN "versions"
content/anoncomms/roadmap/testnet_v0.1/discovery_v0.1.md
+13 -13
View File
@@ -1,8 +1,8 @@
# [Capability Discovery Track: Testnet v0.1](https://github.com/logos-co/anoncomms-pm/milestone/1)
# [Service Discovery Track: Testnet v0.1](https://github.com/logos-co/anoncomms-pm/milestone/1)
**Track:** [Capability Discovery Track](/anoncomms/roadmap/discovery.md)
**Track:** [Service Discovery Track](/anoncomms/roadmap/discovery.md)
**FURPS:** [Capability Discovery FURPS](/anoncomms/furps/discovery.md)
**FURPS:** [Service Discovery FURPS](/anoncomms/furps/discovery.md)
**Estimated date of completion**: 31 Mar 2026
@@ -11,26 +11,26 @@
## Deliverables
### [Specify basic capability discovery protocol](https://github.com/logos-co/anoncomms-pm/issues/1)
### [Specify basic service discovery protocol](https://github.com/logos-co/anoncomms-pm/issues/1)
**Owner**: AnonComms Discovery
**FURPS**:
- U1. The capability discovery protocol is published in a specification
- U1. The service discovery protocol is published in a specification
- U4. A forum post introduces the new protocol, explains privacy tradeoffs, and links to spec and PoC implementation
**Checklist**:
- [ ] Specs: link to specs and/or API definition
### [Build PoC implementation of capability discovery protocol](https://github.com/logos-co/anoncomms-pm/issues/2)
### [Build PoC implementation of service discovery protocol](https://github.com/logos-co/anoncomms-pm/issues/2)
**Owner**: AnonComms Discovery
**FURPS**:
U2. A PoC implementation accompanies the published protocol
U3. The PoC implementation contains instructions to allow open dogfooding
- U2. A PoC implementation accompanies the published protocol
- U3. The PoC implementation contains instructions to allow open dogfooding
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
@@ -46,7 +46,7 @@ U3. The PoC implementation contains instructions to allow open dogfooding
- F1. Libp2p Kad-DHT nodes can advertise their own addresses and capabilities in a signed record
- F2. Libp2p Kad-DHT nodes can discover and validate the signed records of random, advertised peers
- F3. Libp2p Kad-DHT nodes can filter discovered records for specific capabilities
- F4. Libp2p nodes can use a general capability discovery API to discover peers with specific capabilities
- F4. Libp2p nodes can use a general service discovery API to discover peers with specific capabilities
- U5. A Kad-DHT discovery protocol is published in a specification
- U6. The Kad-DHT discovery API is available in Nim
- U7. The reference Kad-DHT discovery implementation is completed in Nim over the nim-libp2p Kad-DHT implementation
@@ -57,16 +57,16 @@ U3. The PoC implementation contains instructions to allow open dogfooding
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Implement capability discovery protocol](https://github.com/logos-co/anoncomms-pm/issues/13)
### [Implement service discovery protocol](https://github.com/logos-co/anoncomms-pm/issues/13)
**Owner**: AnonComms Discovery
**FURPS**:
- F5. The capability discovery protocol adapts DISC-NG for Kad-DHT to ensure efficient capability discovery
- U8. The reference capability discovery implementation is completed in Nim over the nim-libp2p Kad-DHT implementation
- F5. The service discovery protocol adapts DISC-NG for Kad-DHT to ensure efficient service discovery
- U8. The reference service discovery implementation is completed in Nim over the nim-libp2p Kad-DHT implementation
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
- [ ] Docs: links to README.md or other docs
content/anoncomms/roadmap/testnet_v0.1/gasless-l2_v0.1.md
+1 -1
View File
@@ -1,4 +1,4 @@
# [Gasless L2 Track: Testnet v0.1](ttps://github.com/logos-co/anoncomms-pm/milestone/8)
# [Gasless L2 Track: Testnet v0.1](https://github.com/logos-co/anoncomms-pm/milestone/8)
**Track:** [Gasless L2 Track](/anoncomms/roadmap/gasless-l2.md)
content/anoncomms/roadmap/testnet_v0.2/discovery_v0.2.md
+14 -16
View File
@@ -1,8 +1,8 @@
# [Capability Discovery Track: Testnet v0.2](https://github.com/logos-co/anoncomms-pm/milestone/10)
# [Service Discovery Track: Testnet v0.2](https://github.com/logos-co/anoncomms-pm/milestone/10)
**Track:** [Capability Discovery Track](/anoncomms/roadmap/discovery.md)
**Track:** [Service Discovery Track](/anoncomms/roadmap/discovery.md)
**FURPS:** [Capability Discovery FURPS](/anoncomms/furps/discovery.md)
**FURPS:** [Service Discovery FURPS](/anoncomms/furps/discovery.md)
**Estimated date of completion**: 30 Jun 2026
@@ -13,27 +13,27 @@
## Deliverables
### [Integrate and dogfood capability discovery in Logos Delivery](https://github.com/logos-co/anoncomms-pm/issues/31)
### [Integrate and dogfood service discovery in Logos Delivery](https://github.com/logos-co/anoncomms-pm/issues/31)
**Owner**: AnonComms Discovery
**FURPS**:
- U9. Capability discovery is integrated in Logos Delivery to replace discv5 discovery
- U13. Capability discovery is integrated into `chat2mix` application for dogfooding
- U9. Service discovery is integrated in Logos Delivery to discover libp2p mix nodes
- U13. Service discovery is integrated into `chat2mix` application for dogfooding
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Specify standalone capability discovery API](https://github.com/logos-co/anoncomms-pm/issues/32)
### [Specify standalone service discovery API](https://github.com/logos-co/anoncomms-pm/issues/32)
**Owner**: AnonComms Discovery
**FURPS**:
- U11. The capability discovery API is published in a specification
- U11. The service discovery API is published in a specification
**Checklist**:
- [ ] Specs: link to specs and/or API definition
@@ -65,30 +65,28 @@
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Implement standalone Logos capability discovery module](https://github.com/logos-co/anoncomms-pm/issues/35)
### [Implement standalone Logos service discovery module](https://github.com/logos-co/anoncomms-pm/issues/35)
**Owner**: P2P Team (primary), AnonComms Discovery (support)
**FURPS**:
- U10. The capability discovery module is available as a Logos Core module
- U10. The service discovery module is available as a Logos Core module
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Large scale benchmarking of the capability discovery module](https://github.com/logos-co/anoncomms-pm/issues/36)
### [Validate service discovery protocol correctness in large-scale simulations](https://github.com/logos-co/anoncomms-pm/issues/36)
**Owner**: DST Team (primary), AnonComms Discovery (support)
**FURPS**:
- P1. Capability discovery provides comparable performance to discv5 when all nodes support the same service
- 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
- F8. Service discovery correctly discovers peers advertising a sparse service in a topology of several thousand nodes
- S1. Service discovery can be functionally validated in large-scale standalone DST simulations
**Checklist**:
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
content/anoncomms/roadmap/testnet_v0.2/identity_v0.2.md
-10
View File
@@ -17,16 +17,6 @@ and validates the LEZ-as-Registry approach via a spike.
## Deliverables
### [Specify basic λAccount protocol](TBD: anoncomms-pm issue)
**Owner**: Messaging Chat (primary), AnonComms Identity (review)
**FURPS**:
- U1. The basic identity protocol (accounts, address format, operation log, contact discovery flow) is published in a specification.
**Checklist**:
- [ ] Specs: link to specs and/or API definition
### [Spike: LEZ-as-Registry feasibility](TBD: anoncomms-pm issue)
**Owner**: Messaging Chat
content/anoncomms/roadmap/testnet_v0.2/mix_v0.2.md
+4 -37
View File
@@ -28,23 +28,7 @@
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Add app-layer support for large messages (including large responses)](https://github.com/logos-co/anoncomms-pm/issues/41)
**Owner**: Storage Team (primary), AnonComms Mix (support)
**FURPS**:
- F8. An application-level mechanism exists to segment large messages and mixify over multiple paths
- F9. An application-level mechanism exists to segment large responses and coordinating multiple-SURB response paths
- U8. The application-level mechanism to support large messages (requests & responses) is published in a specification
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Modify Sphinx payload encryption to preserve payload integrity](https://github.com/logos-co/anoncomms-pm/issues/49)
### [Specify Sphinx payload encryption to preserve payload integrity](https://github.com/logos-co/anoncomms-pm/issues/49)
**Owner**: Storage Team (primary), AnonComms Mix (support)
@@ -54,7 +38,6 @@
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Code: link to GitHub issues/PRs/Epic
### [Specify and implement cover traffic generation](https://github.com/logos-co/anoncomms-pm/issues/42)
@@ -71,23 +54,7 @@
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Specify and implement hidden services](https://github.com/logos-co/anoncomms-pm/issues/43)
**Owner**: AnonComms Mix (primary), Storage Team (support)
**FURPS**:
- F11. Providers can anonymously register as a hidden service
- F12. Clients can discover and anonymously access hidden services
- U10. The protocol allowing hidden service provisioning, discovery and access is published in a specification
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Integrate mix into the Logos Chat module](https://github.com/logos-co/anoncomms-pm/issues/44)
### [Integrate mix into the Logos Mix Demo Chat module](https://github.com/logos-co/anoncomms-pm/issues/44)
**Owner**: AnonComms Mix
@@ -100,9 +67,9 @@
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Experiment with mixifying basic DHT interactions](https://github.com/logos-co/anoncomms-pm/issues/45)
### [Mixify a DHT query](https://github.com/logos-co/anoncomms-pm/issues/45)
**Owner**: AnonComms Mix
**Owner**: Storage Team
**FURPS**:
content/anoncomms/roadmap/testnet_v0.2/oracle_v0.2.md
+3 -3
View File
@@ -15,7 +15,7 @@
**Owner**: AnonComms Oracle
**Feature**: [Oracle FURPS](../furps/oracle.md)
**Feature**: [Oracle FURPS](/anoncomms/furps/oracle.md)
**FURPS**:
@@ -30,7 +30,7 @@
**Owner**: AnonComms Oracle
**Feature**: [Oracle FURPS](../furps/oracle.md)
**Feature**: [Oracle FURPS](/anoncomms/furps/oracle.md)
**FURPS**:
@@ -48,7 +48,7 @@
**Owner**: AnonComms Oracle
**Feature**: [Oracle FURPS](../furps/oracle.md)
**Feature**: [Oracle FURPS](/anoncomms/furps/oracle.md)
**FURPS**:
content/anoncomms/roadmap/testnet_v0.2/rln_v0.2.md
+22 -7
View File
@@ -11,31 +11,46 @@
## Deliverables
### [Specify and implement RLN membership allocation service](https://github.com/logos-co/anoncomms-pm/issues/17)
### [Specify RLN membership allocation service](https://github.com/logos-co/anoncomms-pm/issues/17)
**Owner**: AnonComms Zerokit-RLN
**Feature**: [RLN](../furps/rln.md)
**Feature**: [RLN](/anoncomms/furps/rln.md)
**FURPS**:
- F1. An RLN membership allocation service can register ID commitments on behalf of third parties
- F2. The RLN membership allocation service has a pluggable authentication mechanism to determine eligibility for membership
- F3. Logos modules can use the service as client to obtain adequate registered RLN identities without interacting with the contract
- F4. The RLN membership allocation service can run as a standalone module or mounted on existing modules
- U1. The RLN membership allocation protocol is published in a specification
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Integrate RLN membership allocation into Logos Chat module](https://github.com/logos-co/anoncomms-pm/issues/46)
### [Demo integration of RLN membership allocation in Logos Delivery for Mix DoS protection](https://github.com/logos-co/anoncomms-pm/issues/46)
**Owner**: AnonComms Zerokit-RLN
**FURPS**:
- F3. Logos modules can use the service as client to obtain adequate registered RLN identities without interacting with the contract
- U2. Logos Delivery and Chat can use the service to obtain RLN memberships
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Implement RLN contract for Logos Execution Zone](TBD: anoncomms-pm issue)
**Owner**: AnonComms Zerokit-RLN
**FURPS**:
- F5. Logos modules can read the on-chain Merkle root and proofs
- U3. The RLN contract is implemented for Logos Execution Zone
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
content/anoncomms/roadmap/testnet_v0.3/de-mls_v0.3.md
+53
View File
@@ -0,0 +1,53 @@
# [De-MLS Track: Testnet v0.3](https://github.com/logos-co/anoncomms-pm/milestone/19)
**Track:** [De-MLS Track](/anoncomms/roadmap/de-mls.md)
**FURPS:** [De-MLS FURPS](/anoncomms/furps/de-mls.md)
**Estimated date of completion**: Testnet v0.3 launch
**Resources Required**:
- 2 developers for 12 weeks
## Deliverables
### [Implementing a WallClock service for de-MLS timing](https://github.com/logos-co/anoncomms-pm/issues/61)
**Owner**: AnonComms de-MLS
**FURPS**:
- F8. De-MLS obtains the current time through a caller-provided WallClock service instead of hardcoded debug timer values
- S2. The WallClock service provides test implementations that simulate time progression without real-time waits
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Implementing recovery mode](https://github.com/logos-co/anoncomms-pm/issues/62)
**Owner**: AnonComms de-MLS
**FURPS**:
- F9. A messaging group can recover from steward liveness failures by triggering a new steward list election
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Integrating de-MLS into libchat](https://github.com/logos-co/anoncomms-pm/issues/63)
**Owner**: AnonComms de-MLS
**FURPS**:
- U10. De-MLS is integrated into libchat using caller-provided services
- R1. De-MLS operates correctly within libchat
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
content/anoncomms/roadmap/testnet_v0.3/discovery_v0.3.md
+80
View File
@@ -0,0 +1,80 @@
# [Service Discovery Track: Testnet v0.3](https://github.com/logos-co/anoncomms-pm/milestone/20)
**Track:** [Service Discovery Track](/anoncomms/roadmap/discovery.md)
**FURPS:** [Service Discovery FURPS](/anoncomms/furps/discovery.md)
**Estimated date of completion**: Testnet v0.3 launch
**Resources Required**:
- 2 developers for 16 weeks
- DST team ownership of relevant deliverables (see below)
## Deliverables
### [Integrate the standalone service discovery module into Logos Delivery](https://github.com/logos-co/anoncomms-pm/issues/64)
**Owner**: AnonComms Discovery
**FURPS**:
- U14. Service discovery is built into Logos Delivery as a separate Logos core module
- U15. Service discovery can be configured in Logos Delivery as alternative ambient peer discovery to discv5
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Benchmark the service discovery module against discv5](https://github.com/logos-co/anoncomms-pm/issues/65)
**Owner**: DST Team (primary), AnonComms Discovery (support)
**FURPS**:
- P1. The service discovery module provides comparable performance to discv5 when all nodes support the same service
- P2. The service discovery module performs better than discv5 to find a sparse service
- S2. The service discovery module can be benchmarked in large-scale standalone DST simulations
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Docs: links to README.md or other docs
### [Benchmark service discovery performance in Logos Delivery](https://github.com/logos-co/anoncomms-pm/issues/66)
**Owner**: DST Team (primary), AnonComms Discovery (support)
**FURPS**:
- P3. Service discovery integrated in Logos Delivery provides comparable performance to discv5 when all nodes support the same service
- P4. Service discovery integrated in Logos Delivery performs better than discv5 to find a sparse service
- S3. Logos Delivery with integrated service discovery can be validated and benchmarked in large-scale DST simulations
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Docs: links to README.md or other docs
### [Publish a research post on service discovery for the Logos research blog](https://github.com/logos-co/anoncomms-pm/issues/67)
**Owner**: AnonComms Discovery
**FURPS**:
- U16. A research post introducing the service discovery protocol and its implementation, including DST performance results, is published on the Logos research blog
**Checklist**:
- [ ] Docs: links to README.md or other docs
### [Research and publish an anonymity roadmap for service discovery](https://github.com/logos-co/anoncomms-pm/issues/68)
**Owner**: AnonComms Discovery
**FURPS**:
- U17. An analysis enumerating privacy-leaking actions in the service discovery protocol is published
- U18. A survey of anonymisation techniques applicable to DHT-based service discovery, including the Octopus protocol and mix-based approaches, is published
- U19. A roadmap for introducing anonymity properties into service discovery, including dependencies on the libp2p mix protocol, is published
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Docs: links to README.md or other docs
content/anoncomms/roadmap/testnet_v0.3/identity_v0.3.md
+15 -5
View File
@@ -1,10 +1,10 @@
# [Identity Track: Testnet v0.3](TBD: anoncomms-pm milestone)
# [Identity Track: Testnet v0.3](https://github.com/logos-co/anoncomms-pm/milestone/21)
**Track:** [Identity Track](/anoncomms/roadmap/identity.md)
**FURPS:** [Identity FURPS](/anoncomms/furps/identity.md)
**Estimated date of completion**: in line with v0.3 freeze
**Estimated date of completion**: Testnet v0.3 launch
**Resources Required**:
- 1 AnonComms researcher for review
@@ -17,7 +17,17 @@ and a working contact-discovery flow.
## Deliverables
### [Implement basic λAccount library](TBD: logos-messaging/pm issue)
### [Specify basic λAccount protocol](https://github.com/logos-co/anoncomms-pm/issues/69)
**Owner**: Messaging Chat (primary), AnonComms Identity (review)
**FURPS**:
- U1. The basic identity protocol (accounts, address format, operation log, contact discovery flow) is published in a specification.
**Checklist**:
- [ ] Specs: link to specs and/or API definition
### [Implement basic λAccount library](https://github.com/logos-co/anoncomms-pm/issues/70)
**Owner**: Messaging Chat
@@ -39,7 +49,7 @@ and a working contact-discovery flow.
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Investigate dedicated Identity Zone for registry](TBD: anoncomms-pm issue)
### [Investigate dedicated Identity Zone for registry](https://github.com/logos-co/anoncomms-pm/issues/71)
**Owner**: Messaging Chat
@@ -50,7 +60,7 @@ and a working contact-discovery flow.
- [ ] Docs: links to README.md or other docs
- [ ] Specs: link to specs and/or API definition
### [Specify registry interface](TBD: anoncomms-pm issue)
### [Specify registry interface](https://github.com/logos-co/anoncomms-pm/issues/72)
**Owner**: Messaging Chat
content/anoncomms/roadmap/testnet_v0.3/incentivisation_v0.3.md
+78
View File
@@ -0,0 +1,78 @@
# [Service Incentivisation Track: Testnet v0.3](https://github.com/logos-co/anoncomms-pm/milestone/22)
**Track:** [Service Incentivisation Track](/anoncomms/roadmap/incentivisation.md)
**FURPS:** [Service Incentivisation FURPS](/anoncomms/furps/incentivisation.md)
**Estimated date of completion**: Testnet v0.3 launch
**Resources Required**:
- `TBD` developers for `TBD` weeks
## Deliverables
### [Specify and implement client payment shielding via LEZ private execution mode](https://github.com/logos-co/anoncomms-pm/issues/73)
**Owner**: AnonComms Incentivisation
**FURPS**:
- F4. The payment protocol shields the identity of the paying client from the network via LEZ private execution mode
- U6. The LEZ-private-execution-mode-based client-shielding mechanism is published in a specification
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Research shielding the service provider identity in the payment protocol](https://github.com/logos-co/anoncomms-pm/issues/74)
**Owner**: AnonComms Incentivisation
**FURPS**:
- F5. The payment protocol shields the identity of the receiving service provider from the network
- U7. A specification investigating how to shield the identity of the receiving service provider is published
**Checklist**:
- [ ] Specs: link to specs and/or API definition
### [Research service discovery integration for provider payment policy advertisement](https://github.com/logos-co/anoncomms-pm/issues/75)
**Owner**: AnonComms Incentivisation (primary), AnonComms Discovery (support)
**FURPS**:
- F6. A client can discover service providers that offer a specific service
- F7. A client can discover the payment policy advertised by a discovered service provider
- U8. A specification for discovering service providers and their payment policies via existing service discovery is published
**Checklist**:
- [ ] Specs: link to specs and/or API definition
### [Research non-native token support in provider payment policies](https://github.com/logos-co/anoncomms-pm/issues/76)
**Owner**: AnonComms Incentivisation
**FURPS**:
- F8. A provider's payment policy can specify which non-native tokens it accepts as payment
- U9. A specification investigating support for non-native tokens in provider payment policies is published
**Checklist**:
- [ ] Specs: link to specs and/or API definition
### [Research a shared payment pool model for multiple service providers](https://github.com/logos-co/anoncomms-pm/issues/77)
**Owner**: AnonComms Incentivisation
**FURPS**:
- F9. A payment pool can be shared across multiple service providers rather than being restricted to a single provider
- F10. The payment protocol prevents double-spending/double-claiming of rewards from a shared payment pool
- F11. Service providers can claim rewards from a shared payment pool in accordance with the service they provided, using a reputation- or receipt-based method
- U10. A specification investigating a shared payment pool model supporting multiple service providers, double-spend prevention, and proportional reward claiming is published
**Checklist**:
- [ ] Specs: link to specs and/or API definition
content/anoncomms/roadmap/testnet_v0.3/mix_v0.3.md
+132
View File
@@ -0,0 +1,132 @@
# [Mix Track: Testnet v0.3](https://github.com/logos-co/anoncomms-pm/milestone/16)
**Track:** [Mix Track](/anoncomms/roadmap/mix.md)
**FURPS:** [Mix FURPS](/anoncomms/furps/mix.md)
**Estimated date of completion**: Testnet v0.3 launch
**Resources Required**:
- `2` AnonComms Mix developers
- Storage Team ownership of relevant deliverables (see below)
- P2P Team ownership of Logos Mix Module deliverable
## Deliverables
### [Implement LIONESS payload encryption for Sphinx](https://github.com/logos-co/anoncomms-pm/issues/50)
**Owner**: AnonComms Mix (primary), Storage Team (support)
**FURPS**:
- F13. The libp2p mix protocol's payload encryption preserves payload integrity
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Research more advanced cover traffic generation techniques](https://github.com/logos-co/anoncomms-pm/issues/51)
**Owner**: AnonComms Mix (primary)
**FURPS**:
- F17. Nodes can use advanced cover traffic patterns to improve anonymity
- U20. Advanced cover traffic patterns are researched and published in a specification
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Implement local reputation mechanism and research advanced DoS protection](https://github.com/logos-co/anoncomms-pm/issues/52)
**Owner**: AnonComms Mix
**FURPS**:
- F16. Mix nodes maintain a local reputation record for peers
- U18. Differentiated RLN rate-limiting based on peer reputation metrics is researched and published
- U19. Non-RLN DoS and Sybil protection approaches are researched and published
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Add app-layer support for large messages (including large responses)](https://github.com/logos-co/anoncomms-pm/issues/41)
**Owner**: Storage Team (primary), AnonComms Mix (support)
**FURPS**:
- F8. An application-level mechanism exists to segment large messages and mixify over multiple paths
- F9. An application-level mechanism exists to segment large responses and coordinating multiple-SURB response paths
- U8. The application-level mechanism to support large messages (requests & responses) is published in a specification
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Specify and implement hidden services and research provider anonymity techniques](https://github.com/logos-co/anoncomms-pm/issues/43)
**Owner**: Storage Team (primary), AnonComms Mix (support)
**FURPS**:
- F11. Providers can anonymously register as a hidden service
- F12. Clients can discover and anonymously access hidden services
- U10. The protocol allowing hidden service provisioning, discovery and access is published in a specification
- U17. The anonymity limitations of the mix hidden services approach and alternative provider anonymity techniques are evaluated and published
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Integrate mix into the Logos Delivery module](https://github.com/logos-co/anoncomms-pm/issues/53)
**Owner**: Messaging Delivery (primary), AnonComms Mix (support)
**FURPS**:
- U14. The libp2p mix protocol is integrated into the Logos Delivery module with exposure on the Messaging API
- U15. The Logos Chat module provides a user interface to select mix when publishing messages
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Create a standalone Logos Mix Module](https://github.com/logos-co/anoncomms-pm/issues/54)
**Owner**: P2P Team (primary), AnonComms Mix (support)
**FURPS**:
- F14. A standalone Logos Mix module encapsulates the Logos libp2p module with nim-libp2p-mix, RLN-based DoS protection, and cover traffic for Logos Core services
- F15. Applications can route libp2p request-response messages over mix via the Logos Mix module API
- U16. The Logos Mix module API for routing messages over mix is published as a specification
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Specify a Logos Mix Network opinionated configuration](https://github.com/logos-co/anoncomms-pm/issues/55)
**Owner**: AnonComms Mix
**FURPS**:
- U21. The opinionated protocol stack composition and configuration for a Logos Mix Network is specified
**Checklist**:
- [ ] Specs: link to specs and/or API definition
content/anoncomms/roadmap/testnet_v0.3/oracle_v0.3.md
+86
View File
@@ -0,0 +1,86 @@
# [Oracle Track: Testnet v0.3](https://github.com/logos-co/anoncomms-pm/milestone/17)
**Track:** [Oracle Track](/anoncomms/roadmap/oracle.md)
**FURPS:** [Oracle FURPS](/anoncomms/furps/oracle.md)
**Estimated date of completion**: Testnet v0.3 launch
**Resources Required**:
- `2` developers for `12` weeks
## Deliverables
### [Specifying oracle mechanism](https://github.com/logos-co/anoncomms-pm/issues/56)
**Owner**: AnonComms Oracle
**Feature**: [Oracle FURPS](/anoncomms/furps/oracle.md)
**FURPS**:
- U1. The system design is documented in a LIP
- U3. The fetch mechanism is specified and documented
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Docs: links to README.md or other docs
### [Implementing Oracle Zone](https://github.com/logos-co/anoncomms-pm/issues/57)
**Owner**: AnonComms Oracle
**Feature**: [Oracle FURPS](/anoncomms/furps/oracle.md)
**FURPS**:
- F1. Oracle nodes fetch price data from predefined sources
- F2. Indexer performs onchain aggregation of signed node data
- F4. Oracle nodes fetch price data from predefined sources according to a defined fetch specification
- U2. The oracle nodes and indexer are implemented in Rust
- R1. Basic protection against faulty or inconsistent data via multi-source aggregation
- S1. Oracle node and indexer operations are logged to enable debugging of fetch and aggregation failures
- S2. PACT cross-zone transaction failures are logged with sufficient detail for diagnosis
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Bringing Data from Oracle zone to LEZ](https://github.com/logos-co/anoncomms-pm/issues/58)
**Owner**: AnonComms Oracle
**Feature**: [Oracle FURPS](/anoncomms/furps/oracle.md)
**FURPS**:
- F3. The LEZ contract exposes basic functions to update and read the latest price
- F5. Cross zone TX enables provable atomic cross-zone transactions between oracle zone and LEZ
- U4. Atomic cross zone TX is deployed for cross-zone interactions involving the oracle zone
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Oracle Zone Documentation and Benchmarking](https://github.com/logos-co/anoncomms-pm/issues/59)
**Owner**: AnonComms Oracle
**Feature**: [Oracle FURPS](/anoncomms/furps/oracle.md)
**FURPS**:
- U5. Developer documentation for the Oracle Zone is published in a document
- U6. Benchmark results for the Oracle Zone are published in a research blog
- P1. Price updates are completed within a reasonable time bound
- P2. Cross-zone transaction latency is benchmarked
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
content/anoncomms/roadmap/testnet_v0.3/rln_v0.3.md
+94
View File
@@ -0,0 +1,94 @@
# [RLN Track: Testnet v0.3](https://github.com/logos-co/anoncomms-pm/milestone/23)
**Track:** [RLN Track](/anoncomms/roadmap/rln.md)
**FURPS:** [RLN FURPS](/anoncomms/furps/rln.md)
**Estimated date of completion**: Testnet v0.3 launch
**Resources Required**:
- `2` AnonComms Zerokit-RLN developers
## Deliverables
### [Specify basic RLN membership management module API](https://github.com/logos-co/anoncomms-pm/issues/78)
**Owner**: AnonComms Zerokit-RLN
**FURPS**:
- U4. The basic RLN membership management module API is published as a specification
**Checklist**:
- [ ] Specs: link to specs and/or API definition
### [Implement basic RLN membership management module](https://github.com/logos-co/anoncomms-pm/issues/79)
**Owner**: AnonComms Zerokit-RLN
**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
- F8. The basic RLN membership management module can operate as a client in the libp2p RLN membership allocation protocol
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] 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](https://github.com/logos-co/anoncomms-pm/issues/80)
**Owner**: AnonComms Zerokit-RLN (primary), Logos Delivery (support)
**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
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Standalone RLN membership allocation service module](https://github.com/logos-co/anoncomms-pm/issues/81)
**Owner**: AnonComms Zerokit-RLN
**FURPS**:
- F1. An RLN membership allocation service can register ID commitments on behalf of third parties
- F2. The RLN membership allocation service has a pluggable authentication mechanism to determine eligibility for membership
- F4. The RLN membership allocation service can run as a standalone module or mounted on existing modules
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Research advanced authentication techniques for RLN membership allocation](https://github.com/logos-co/anoncomms-pm/issues/82)
**Owner**: AnonComms Zerokit-RLN
**FURPS**:
- U6. Advanced authentication mechanisms for RLN membership allocation, including device keys, are evaluated and published
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Docs: links to README.md or other docs
### [Full RLN module](https://github.com/logos-co/anoncomms-pm/issues/83)
**Owner**: AnonComms Zerokit-RLN
**FURPS**:
- F9. The full RLN module encapsulates Zerokit proof generation and verification, expanding the basic RLN membership management module
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
content/anoncomms/roadmap/testnet_v0.3/zerokit_v0.3.md
+69
View File
@@ -0,0 +1,69 @@
# [Zerokit Track: Testnet v0.3](https://github.com/logos-co/anoncomms-pm/milestone/18)
**Track:** [Zerokit Track](/anoncomms/roadmap/zerokit.md)
**FURPS:** [Zerokit FURPS](/anoncomms/furps/zerokit.md)
**Estimated date of completion**: Testnet v0.3 launch
**Resources Required**:
- 3 developers for 12 weeks
## Deliverables
### [Integrate and benchmark Poseidon2 hash function](https://github.com/logos-co/anoncomms-pm/issues/84)
**Owner**: AnonComms Zerokit
**FURPS**:
- F2. Zerokit supports Poseidon2 as an alternative hash function alongside Poseidon
- F3. Zerokit supports the automatic generation of round parameters for both Poseidon and Poseidon2
- U6. The hash function selection (Poseidon vs Poseidon2) is exposed via the runtime configuration enum
- U7. The implementation of the new Poseidon2 circuit has been completed and documented in the circom-rln repo
- R1. Poseidon2 proofs verify correctly and Poseidon behavior remains unchanged when Poseidon2 is enabled
- P1. Poseidon2 proof generation is benchmarked against Poseidon and demonstrates measurable improvement
- S3. New Poseidon2-related functionality and APIs are fully exposed through the FFI and WASM interfaces
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs
### [Static analysis of Poseidon and Poseidon2 circuits](https://github.com/logos-co/anoncomms-pm/issues/85)
**Owner**: AnonComms Zerokit
**FURPS**:
- S2. Static analysis of the circuits for both Poseidon and Poseidon2 is performed and documented
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Docs: links to README.md or other docs
### [Zerokit maintenance](https://github.com/logos-co/anoncomms-pm/issues/86)
**Owner**: AnonComms Zerokit
**FURPS**:
- S1. Outstanding issues and dependency updates are addressed to keep the codebase maintainable
**Checklist**:
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Docs: links to README.md or other docs
### [Release Zerokit (v3.0.0) with enum-based runtime configuration](https://github.com/logos-co/anoncomms-pm/issues/60)
**Owner**: AnonComms Zerokit
**FURPS**:
- U5. The Zerokit architecture is changed from compile-time feature flags to runtime configuration based on enums
**Checklist**:
- [ ] Specs: link to specs and/or API definition
- [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or other docs