mirror of
https://github.com/vacp2p/roadmap.git
synced 2026-01-09 07:37:59 -05:00
ACZ Updates - 2025-10-06 (#304)
done: - discovery progress update and new tasks - SN RLN progress updated and whitepaper and website tasks are added. - libp2p-mix commitment updated - discovery commitment definition is revised. --------- Co-authored-by: kaiserd <1684595+kaiserd@users.noreply.github.com> Co-authored-by: fbarbu15 <florin@status.im>
This commit is contained in:
seugu
@@ -54,7 +54,7 @@ to promote the project and gain support from the Ethereum ecosystem.
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q3-de-mls-tesnet:multi-steward-rfc`
|
||||
* owner: Ugur
|
||||
* status: started (70%)
|
||||
* status: done
|
||||
* start-date: 2025/07/21
|
||||
* end-date: 2025/08/25
|
||||
|
||||
@@ -65,7 +65,7 @@ The RFC needs to contain concrete flow, and explaination.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* PR to vacp2p/rfc-index repo with related updates.
|
||||
* [PR](https://github.com/vacp2p/rfc-index/pull/193) to vacp2p/rfc-index repo with related updates.
|
||||
|
||||
### Implement consesus layer
|
||||
|
||||
@@ -112,7 +112,7 @@ containing update of message processing
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q3-de-mls-tesnet:de-mls-maintaining`
|
||||
* owner: Ekaterina
|
||||
* status: started (80%)
|
||||
* status: done
|
||||
* start-date: 2025/06/30
|
||||
* end-date: 2025/09/30
|
||||
|
||||
@@ -123,4 +123,21 @@ testing, small issues and the creation of future issues.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
A set of PRs and issues to [de-MLS repository](https://github.com/vacp2p/de-mls)
|
||||
A set of PRs and issues to [de-MLS repository](https://github.com/vacp2p/de-mls)
|
||||
|
||||
### Multi-steward presentation
|
||||
|
||||
* fully qualified name: `ift:2025q3-de-mls-tesnet:multi-steward-presentation`
|
||||
* owner: Uğur
|
||||
* status: done
|
||||
* start-date: 2025/09/15
|
||||
* end-date: 2025/09/30
|
||||
|
||||
#### Description
|
||||
|
||||
Creating slides then presenting latest multi-steward approach in IFT research call.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* [Presentation](https://docs.google.com/presentation/d/1y39-0TzYc8P7gN3qzGbXtwklZY2rByHkdk-j0zvmrC0/edit?usp=drive_web&ouid=118310033212265407204)
|
||||
* [Forum post](https://forum.vac.dev/t/ift-research-call-september-24th-2025-multi-steward-de-mls-details-on-our-decentralized-mls-solution/575)
|
||||
@@ -39,7 +39,7 @@ that show the potential improvement points of the discovery mechanism.
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q3-discovery-exploration:exploring`
|
||||
* owner: Arunima
|
||||
* status: started (80%)
|
||||
* status: done
|
||||
* start-date: 2025/09/01
|
||||
* end-date: 2025/09/15
|
||||
|
||||
@@ -58,7 +58,7 @@ suitability for IFT projects, with documented findings
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q3-discovery-exploration:disc-ng-specs`
|
||||
* owner: Arunima
|
||||
* status: started (0%)
|
||||
* status: done
|
||||
* start-date: 2025/09/15
|
||||
* end-date: 2025/09/30
|
||||
|
||||
|
||||
@@ -28,7 +28,6 @@ and the IFT.
|
||||
|
||||
With this commitment,
|
||||
|
||||
|
||||
we will reinforce the Conduit of Expertise narrative by:
|
||||
* Sync the monthly ZK improvements with all shares in IFT.
|
||||
* Checking there is no collision between the ZK related works.
|
||||
|
||||
@@ -55,7 +55,7 @@ Waku integration.
|
||||
### Updating RFC
|
||||
* fully qualified name: `vac:acz:ift:2025q3-libp2p-mix-testnet:update-rfc`
|
||||
* owner: Akshaya
|
||||
* status: started (75%)
|
||||
* status: done
|
||||
* start-date: 2025/07/01
|
||||
* end-date: 2025/08/18
|
||||
|
||||
@@ -70,9 +70,9 @@ introducing the entry and exit layers and libp2p integrations.
|
||||
* [RFC Refactor: Sphinx Packet Format PR ](https://github.com/vacp2p/rfc-index/pull/173)
|
||||
|
||||
### libp2p-mix Relay RFC
|
||||
* fully qualified name: `vac:acz:ift:2025q?-gossipsub-relay-rfc:relay-rfc`
|
||||
* fully qualified name: `vac:acz:ift:2025q3-gossipsub-relay-rfc:relay-rfc`
|
||||
* owner: Akshaya
|
||||
* status: started (70%)
|
||||
* status: done
|
||||
* start-date: 2025/09/01
|
||||
* end-date: 2025/09/15
|
||||
|
||||
@@ -82,25 +82,25 @@ to inject raw GossipSub messages into a full node’s relay logic.
|
||||
This makes Mix integration cleaner without requiring the exit nodes to participate in mesh or support GossipSub.
|
||||
|
||||
#### Deliverables
|
||||
* A PR to [vacp2p/rfc-index](https://github.com/vacp2p/rfc-index) containing the RFC.
|
||||
* [A PR](https://github.com/vacp2p/rfc-index/pull/178) to [vacp2p/rfc-index](https://github.com/vacp2p/rfc-index) containing the RFC.
|
||||
|
||||
### Investigate Unexpected Mixnet Latency
|
||||
* fully qualified name: `vac:acz:ift:2025q3-libp2p-mix-testnet:unexpected-latency`
|
||||
* owner: Akshaya
|
||||
* status: on-hold (%70)
|
||||
* status: done
|
||||
* start-date: 2025/07/01
|
||||
* end-date: 2025/07/15
|
||||
|
||||
#### Description
|
||||
|
||||
This task is on hold since the solution is waiting to be confirmed.
|
||||
This task was on hold since the solution is waiting to be confirmed.
|
||||
Now, the [issue](https://github.com/vacp2p/mix/issues/88) is identified and the corresponding task is added to Q4.
|
||||
|
||||
This task entails investigating to find root cause of unexpected latency.
|
||||
Observed latency with 3 mix hops and 100ms delays is ~1100–1600ms,
|
||||
far exceeding the expected ~300ms.
|
||||
Prior Lightpush tests showed much lower overhead.
|
||||
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* A PR to [vacp2p/mix](https://github.com/vacp2p/mix)
|
||||
@@ -119,7 +119,6 @@ Likely due to publisher advertising the message via IHAVE
|
||||
from its mcache while the mix path is still active.
|
||||
Requires investigation and fix.
|
||||
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* A PR to [vacp2p/mix](https://github.com/vacp2p/mix)
|
||||
@@ -128,7 +127,7 @@ Requires investigation and fix.
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q3-libp2p-mix-testnet:consulting-waku-mix`
|
||||
* owner: Akshaya
|
||||
* status: started (60%)
|
||||
* status: done
|
||||
* start-date: 2025/07/01
|
||||
* end-date: 2025/09/20
|
||||
|
||||
@@ -143,7 +142,7 @@ Consulting about mixnet to Mixnet integration to the Waku.
|
||||
### Multi SURB Design
|
||||
* fully qualified name: `vac:acz:ift:2025q3-libp2p-mix-testnet:multi-surb-design`
|
||||
* owner: Akshaya
|
||||
* status: started (85%)
|
||||
* status: done
|
||||
* start-date: 2025/07/01
|
||||
* end-date: 2025/08/17
|
||||
|
||||
@@ -195,7 +194,7 @@ This task focuses on integration the mix into the [vacp2p/nim-libp2p repo](https
|
||||
|
||||
- fully qualified name: `vac:acz:ift:2025q3-libp2p-mix-testnet:libp2p-mix-repo`
|
||||
- owner: Akshaya
|
||||
- status: started (60%)
|
||||
- status: done
|
||||
- start-date: 2025/07/01
|
||||
- end-date: 2025/09/30
|
||||
|
||||
|
||||
@@ -48,7 +48,7 @@ We will also strengthen the Premier Research Destination narrative by:
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q3-rln-status-l2:rln-spec-maintain`
|
||||
* owner: Ugur
|
||||
* status: started (70%)
|
||||
* status: done
|
||||
* start-date: 2025/07/01
|
||||
* end-date: 2025/08/28
|
||||
|
||||
@@ -59,7 +59,7 @@ based in the feedbacks and changes during testnet.
|
||||
|
||||
### Deliverables
|
||||
|
||||
* A Notion doc document that has implementation details.
|
||||
* [A Notion doc](https://www.notion.so/RLN-Deployment-Spec-1f98f96fb65c806c8737d94851b4d14d) document that has implementation details.
|
||||
|
||||
### Smart Contract Testing
|
||||
|
||||
@@ -124,7 +124,7 @@ and tested (using for example: Jaeger) in order to ensure that everything is cor
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q3-rln-status-l2:research-decentralized`
|
||||
* owner: Ugur
|
||||
* status: started (50%)
|
||||
* status: done
|
||||
* start-date: 2025/08/15
|
||||
* end-date: 2025/09/25
|
||||
|
||||
@@ -135,7 +135,7 @@ by minimize the prover and RLN centralization.
|
||||
|
||||
### Deliverables
|
||||
|
||||
* A Notion doc document that has implementation details.
|
||||
* [A Notion doc](https://www.notion.so/RLN-Deployment-Spec-1f98f96fb65c806c8737d94851b4d14d) document that has implementation details.
|
||||
|
||||
### E2E Prover module testing
|
||||
|
||||
@@ -162,7 +162,7 @@ The findings and feedbacks will be reflected to the RLN specification.
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q3-rln-status-l2:stress-test`
|
||||
* owner: Sylvain
|
||||
* status: started (85%)
|
||||
* status: done
|
||||
* start-date: 2025/08/18
|
||||
* end-date: 2025/09/15
|
||||
|
||||
@@ -202,7 +202,7 @@ The findings and feedbacks will be reflected to the RLN specification.
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q3-rln-status-l2:optimization`
|
||||
* owner: Sylvain
|
||||
* status: not started
|
||||
* status: done
|
||||
* start-date: 2025/09/08
|
||||
* end-date: 2025/09/30
|
||||
|
||||
@@ -213,17 +213,22 @@ This task entails to optimize the single prover module.
|
||||
### Deliverables
|
||||
|
||||
* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover).
|
||||
* [PR 39](https://github.com/vacp2p/status-rln-prover/pull/39)
|
||||
* [PR 38](https://github.com/vacp2p/status-rln-prover/pull/38)
|
||||
* [PR 37](https://github.com/vacp2p/status-rln-prover/pull/37)
|
||||
|
||||
### Multi-prover
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q3-rln-status-l2:multi-prover`
|
||||
* owner: Sylvain
|
||||
* status: started (15%)
|
||||
* status: on-hold
|
||||
* start-date: 2025/09/08
|
||||
* end-date: 2025/09/30
|
||||
|
||||
### Description
|
||||
|
||||
This task is on-hold since it requires more research, and it will be delivered in Q4.
|
||||
|
||||
This task entails to modify the prover instance to release multi-prover that each prover module
|
||||
can write to the shared DB for hacving prover cluster.
|
||||
|
||||
@@ -235,7 +240,7 @@ can write to the shared DB for hacving prover cluster.
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q3-rln-status-l2:monorepo-review`
|
||||
* owner: Sylvain
|
||||
* status: started (15%)
|
||||
* status: done
|
||||
* start-date: 2025/09/08
|
||||
* end-date: 2025/09/30
|
||||
|
||||
@@ -252,7 +257,7 @@ This task entails to get familiar with the monorepo for prover integration.
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q3-rln-status-l2:maintaining`
|
||||
* owner: Sylvain
|
||||
* status: started (80%)
|
||||
* status: done
|
||||
* start-date: 2025/07/07
|
||||
* end-date: 2025/09/25
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ looking to integrate RLN into their projects.
|
||||
|
||||
- fully qualified name: `vac:acz:ift:2025q3-zerokit:big-endian-support`
|
||||
- owner: Sylvain
|
||||
- status: started (70%)
|
||||
- status: done
|
||||
- start-date: 2025/06/20
|
||||
- end-date: 2025/09/20
|
||||
|
||||
@@ -57,7 +57,7 @@ hash functions within Zerokit correctly handle Big Endian data.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
- A Pull Request to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/) that includes new functions
|
||||
- A PR to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/) that includes new functions
|
||||
for working with Big Endian data and updates the public API to expose this functionality.
|
||||
|
||||
### CI and Feature Revising
|
||||
@@ -170,7 +170,7 @@ if necessary, update the `rln-wasm` module based on the resolution.
|
||||
|
||||
- fully qualified name: `vac:acz:ift:2025q3-zerokit:zerokit-maintaining`
|
||||
- owner: Ekaterina
|
||||
- status: started (80%)
|
||||
- status: done
|
||||
- start-date: 2025/07/01
|
||||
- end-date: 2025/09/30
|
||||
|
||||
@@ -186,7 +186,7 @@ A set of PRs and issues to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/).
|
||||
|
||||
- fully qualified name: `vac:acz:ift:2025q3-zerokit:release`
|
||||
- owner: Ekaterina
|
||||
- status: not started
|
||||
- status: done
|
||||
- start-date: 2025/09/01
|
||||
- end-date: 2025/09/30
|
||||
|
||||
@@ -196,4 +196,4 @@ The new version of the Zerokit v0.9.0
|
||||
|
||||
### Deliverables
|
||||
|
||||
A set of PRs to vacp2p/zerokit repository with [tag v0.9.0](https://github.com/vacp2p/zerokit/releases/tag/v0.9.0)
|
||||
* [A PR](https://github.com/vacp2p/zerokit/pull/345) to vacp2p/zerokit repository with [tag v0.9.0](https://github.com/vacp2p/zerokit/releases/tag/v0.9.0)
|
||||
@@ -58,7 +58,7 @@ The RFC needs to contain a concrete flow and explanation.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* PR to vacp2p/rfc-index repo with related updates.
|
||||
* A PR to vacp2p/rfc-index repo with related updates.
|
||||
|
||||
### Multi-steward integration
|
||||
|
||||
@@ -70,6 +70,8 @@ The RFC needs to contain a concrete flow and explanation.
|
||||
|
||||
#### Description
|
||||
|
||||
This task is postponed to the Q4 due to the multi stewards specification.
|
||||
|
||||
The multi-steward settings allow de-MLS that multiple stewards to manage the group
|
||||
changes to protect a single point of failure, better availability, and decentralization.
|
||||
|
||||
|
||||
@@ -11,20 +11,22 @@ description: "Specifying disc-NG and releasing a document that collects the requ
|
||||
|
||||
`vac:acz:ift:2025q4-discovery`
|
||||
|
||||
Specifying disc-NG and releasing a document that collects the requirements of discovery
|
||||
Specifying a KAD-DHT–based, disc-NG–like Logos discovery capability
|
||||
and releasing a document that collects the requirements of discovery
|
||||
## Description
|
||||
This commitment entails specifying disc-NG, as proposed in
|
||||
[the paper](https://sonnino.com/papers/disc-ng.pdf), with a focus on implementability.
|
||||
We also aim to collect requirements, and the exploration includes assessing their suitability for IFT projects.
|
||||
|
||||
This commitment entails specifying a KAD-DHT–based, disc-NG–like Logos discovery capability
|
||||
specification with a focus on implementability (see [the paper](https://sonnino.com/papers/disc-ng.pdf));
|
||||
we will also collect requirements and assess their suitability for IFT projects.
|
||||
|
||||
### Narratives
|
||||
|
||||
By utilizing discovery exploration commitment,
|
||||
We will reinforce the Conduit of Expertise narrative by:
|
||||
* Providing the disc-NG RFC that will be tailored for many IFT teams, such as Waku, Nomos, and Codex.
|
||||
* Providing the KAD-DHT–based disc-NG-like RFC that will be tailored for Logos applications.
|
||||
|
||||
We will also strengthen the Premier Research Destination narrative by:
|
||||
* Provides open-source disc-NG RFC information to the community.
|
||||
* Provides open-source KAD-DHT–based disc-NG-like RFC information to the community.
|
||||
|
||||
## Task List
|
||||
|
||||
@@ -32,24 +34,120 @@ We will also strengthen the Premier Research Destination narrative by:
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-discovery:draft-RFC`
|
||||
* owner: Arunima
|
||||
* status: not started
|
||||
* status: started (%5)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/10/30
|
||||
|
||||
#### Description
|
||||
|
||||
This task involves specifying the disc-NG proposal from [the paper](https://sonnino.com/papers/disc-ng.pdf)
|
||||
in an implementable way, extracting the key points such as registor and advisor and drafting them into an RFC.
|
||||
Once the draft RFC is collected in a document, the task also includes preparing the final RFC as a PR
|
||||
by incorporating feedback from the review.
|
||||
This task involves specifying disc-NG-like LOGOS discovery capabilities on top of KAD-DHT
|
||||
(see [the paper](https://sonnino.com/papers/disc-ng.pdf)) in an implementable way,
|
||||
extracting key components such as the registrar and advisor and drafting them into an RFC;
|
||||
once the draft RFC is assembled, the task also includes preparing the final RFC
|
||||
as a pull request by incorporating review feedback.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* A notion document contains a draft RFC with its feedback.
|
||||
|
||||
### Disc-NG Specs
|
||||
### Registrar Module
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-discovery:disc-ng-specs`
|
||||
* fully qualified name: `vac:acz:ift:2025q4-discovery:registrar-module`
|
||||
* owner: Arunima
|
||||
* status: started
|
||||
* start-date: 2025/10/20
|
||||
* end-date: 2025/10/27
|
||||
|
||||
#### Description
|
||||
|
||||
In this task, the modular registrar module will be implemented in Golang to handle node registration,
|
||||
admission policies, and identity management.
|
||||
The module will manage how new participants join the network,
|
||||
enforce admission control rules derived from the RFC, and maintain metadata about registered nodes.
|
||||
The implementation will include validation logic, registration lifecycle handling,
|
||||
and interactions with the core routing layer.
|
||||
The goal is to ensure controlled participation and maintain the stability and trust of the system.
|
||||
The task is complete when nodes can register, be validated, and interact
|
||||
with the network under enforced admission control rules.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* A PR to the [vacp2p/disc-NG](https://github.com/vacp2p/disc-ng/) repo.
|
||||
|
||||
### Advertiser Module
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-discovery:advertiser-module`
|
||||
* owner: Arunima
|
||||
* status: started
|
||||
* start-date: 2025/10/27
|
||||
* end-date: 2025/11/03
|
||||
|
||||
#### Description
|
||||
|
||||
This task involves developing the advertiser component, which is responsible for broadcasting
|
||||
and maintaining service or capability advertisements across the network.
|
||||
The module will manage how nodes announce their presence and update their advertised information over time.
|
||||
It will interact closely with both the registrar and routing infrastructure to ensure
|
||||
that advertisements are discoverable and correctly propagated.
|
||||
Emphasis will be placed on efficient dissemination, freshness of information, and resilience to network churn.
|
||||
The task is complete when advertisements can be created,
|
||||
updated, and distributed correctly through the routing layer.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* A PR to the [vacp2p/disc-NG](https://github.com/vacp2p/disc-ng/) repo.
|
||||
|
||||
### Discoverer Module
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-discovery:discoverer-module`
|
||||
* owner: Arunima
|
||||
* status: started
|
||||
* start-date: 2025/11/03
|
||||
* end-date: 2025/11/10
|
||||
|
||||
#### Description
|
||||
|
||||
Here, the discoverer module will be implemented to enable nodes
|
||||
to search for and locate advertised services or peers in the network.
|
||||
It will interpret discovery queries, match them against active advertisements,
|
||||
and handle query routing through the established infrastructure.
|
||||
The module should also implement caching and fallback mechanisms to optimize performance.
|
||||
The focus will be on correctness, minimal latency in lookups,
|
||||
and adherence to the discovery semantics outlined in the RFC.
|
||||
The task is complete when discovery queries consistently
|
||||
return accurate and timely results for active advertisements.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* A PR to the [vacp2p/disc-NG](https://github.com/vacp2p/disc-ng/) repo.
|
||||
|
||||
### Integration and Validation
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-discovery:integration-validation`
|
||||
* owner: Arunima
|
||||
* status: started
|
||||
* start-date: 2025/11/10
|
||||
* end-date: 2025/11/24
|
||||
|
||||
#### Description
|
||||
|
||||
This final phase integrates all core modules into a cohesive system
|
||||
and validates their behavior through simulations.
|
||||
The components (registrar, advertiser, discoverer, and routing layer)
|
||||
will be connected and tested together under various scenarios.
|
||||
Simulations will cover registration, advertisement propagation,
|
||||
discovery requests, and network dynamics.
|
||||
Validation will focus on functional correctness, protocol compliance, and performance metrics.
|
||||
The task is complete when all modules operate together seamlessly
|
||||
and the integrated system passes functional and performance validation tests.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* A PR to the [vacp2p/disc-NG](https://github.com/vacp2p/disc-ng/) repo.
|
||||
|
||||
### Logos Discovery Capability Spec
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-discovery:logos-disc-specs`
|
||||
* owner: Arunima
|
||||
* status: not started
|
||||
* start-date: 2025/10/30
|
||||
|
||||
@@ -55,7 +55,7 @@ Preparing the agenda and possible speakers for the ZK call on 7nd October.
|
||||
|
||||
### IFT ZK Call 2
|
||||
* fully qualified name: `vac:acz:ift:2025q4-ift-zk-calls:ift-zk-call-2`
|
||||
* owner: Marvin
|
||||
* owner: Ugur
|
||||
* status: not started
|
||||
* start-date: 2025/11/01
|
||||
* end-date: 2025/11/10
|
||||
|
||||
@@ -42,48 +42,17 @@ to promote the mixnet PoC and gain support from the Ethereum ecosystem.
|
||||
|
||||
## Task List
|
||||
|
||||
### Updating RFC
|
||||
### Maintaining RFC
|
||||
* fully qualified name: `vac:acz:ift:2025q4-libp2p-mix-testnet:update-rfc`
|
||||
* owner: Akshaya
|
||||
* status: not started
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/11/10
|
||||
|
||||
#### Description
|
||||
This task entails completing updating the [mixnet RFC](https://rfc.vac.dev/vac/raw/mix)
|
||||
With the latest findings, such as clarifications on exit =! destination, SURB design and addressing feedback.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* A PR to [vacp2p/rfc-index](https://github.com/vacp2p/rfc-index)
|
||||
|
||||
### EF Application
|
||||
* fully qualified name: `vac:acz:ift:2025q4-libp2p-mix-testnet:ef-application`
|
||||
* owner: Ugur
|
||||
* status: not started
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/11/10
|
||||
* start-date: 2025/10/15
|
||||
* end-date: 2025/11/15
|
||||
|
||||
#### Description
|
||||
This task entails having the final version of [existing EF application](https://www.notion.so/Mixnet-EF-Proposal-10b8f96fb65c80e69fb9d78242c3af71)
|
||||
that introduces sender anonymity for Ethereum nodes, also maintaining the application process.
|
||||
This task entails maintaining [mixnet RFC](https://rfc.vac.dev/vac/raw/mix)
|
||||
with the latest findings, such as clarifications on exit =! destination, SURB design and solving current issues.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* A PR to [vacp2p/rfc-index](https://github.com/vacp2p/rfc-index)
|
||||
|
||||
### Consulting Waku-mix
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-libp2p-mix-testnet:consulting-waku-mix`
|
||||
* owner: Akshaya
|
||||
* status: not started
|
||||
* start-date: 22025/10/01
|
||||
* end-date: 2025/11/10
|
||||
|
||||
#### Description
|
||||
|
||||
Consulting about libp2p-mix to Mixnet integration to the Waku.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* PR to [vacp2p/mix](https://github.com/vacp2p/mix) or [waku-org/nwaku](https://github.com/waku-org/nwaku/) repo.
|
||||
@@ -54,13 +54,114 @@ including CI updates and the creation of future issues.
|
||||
#### Deliverables
|
||||
* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover).
|
||||
|
||||
### Multi-prover
|
||||
### Multi Tree Support
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:multi-prover`
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:multi-tree`
|
||||
* owner: Sylvain
|
||||
* status: started (15%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/10/15
|
||||
|
||||
### Description
|
||||
|
||||
This task entails extending the Prover module to scale from supporting a single tree
|
||||
with up to 1M users to a multi-tree architecture capable of handling
|
||||
up to 32M users without compromising performance.
|
||||
The current design, limited to a single tree, cannot efficiently manage larger user sets.
|
||||
While an initial approach based on consistent hashing was considered,
|
||||
it was ultimately discarded due to performance drawbacks.
|
||||
The new approach introduces a dual-identifier database structure
|
||||
using both tree_id and rln_identifier_id to efficiently
|
||||
distribute and manage user commitments across multiple trees.
|
||||
When one tree reaches its capacity, the system will automatically allocate
|
||||
new users to the next available tree, ensuring seamless scalability and high performance.
|
||||
This task is complete when the Prover module can reliably
|
||||
handle up to 32M users across multiple trees with proper data management and performance validation.
|
||||
|
||||
### Deliverables
|
||||
|
||||
* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover).
|
||||
|
||||
### Gas checking support
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:gascheck`
|
||||
* owner: Sylvain
|
||||
* status: not started
|
||||
* start-date: 2025/09/08
|
||||
* end-date: 2025/09/30
|
||||
* start-date:
|
||||
* end-date:
|
||||
|
||||
### Description
|
||||
|
||||
This task entails updating the Prover module to handle cases where
|
||||
a single transaction exceeds the maximum quota and therefore requires burning multiple message IDs.
|
||||
Currently, the module generates one RLN proof per transaction,
|
||||
without accounting for transactions that surpass the allowed quota.
|
||||
|
||||
The updated implementation must ensure that the gas information associated
|
||||
with each incoming transaction is received alongside the transaction data.
|
||||
Using both the max quota value and the transaction’s gas amount,
|
||||
the module should calculate the exact number of message IDs to be burned
|
||||
and deduct them from the user’s remaining tier limit accordingly.
|
||||
This task is complete when the Prover module computes and applies
|
||||
the required number of message ID burns based on transaction gas
|
||||
and quota values, ensuring accurate user limit tracking.
|
||||
|
||||
### Deliverables
|
||||
|
||||
* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover).
|
||||
|
||||
### Monorepo Review
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q3-rln-status-l2:monorepo-review`
|
||||
* owner: Sylvain
|
||||
* status: done
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/11/01
|
||||
|
||||
### Description
|
||||
|
||||
This task entails getting familiar with and testing the
|
||||
[monorepo](https://github.com/status-im/status-network-monorepo)in preparation for the prover integration.
|
||||
In addition to basic exploration and setup, it includes a brief review of the implementation
|
||||
of the sequencer, prover, and smart contracts, as well as a review of the deployment process
|
||||
to identify and fix existing platform-specific bugs.
|
||||
The task also involves testing newly added features to ensure
|
||||
compatibility, stability, and readiness for prover integration.
|
||||
This task is complete when the monorepo environment is fully reviewed,
|
||||
deployment issues are resolved, and new features have been successfully tested and validated.
|
||||
|
||||
### Deliverables
|
||||
|
||||
* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover).
|
||||
|
||||
### Decentralized slashing
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q3-rln-status-l2:monorepo-review`
|
||||
* owner: Sylvain
|
||||
* status: done
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/11/01
|
||||
|
||||
### Description
|
||||
|
||||
This task entails updating the Prover module to listen for slashing events emitted by the `karma.sol` smart contract
|
||||
and to handle the corresponding user data accordingly.
|
||||
When a slashing occurs, the Prover must identify the affected user through the event data and remove
|
||||
that user’s commitment from the local database to maintain consistency between on-chain and off-chain states.
|
||||
This task is complete when the Prover module successfully detects slashing events from `karma.sol`,
|
||||
correctly identifies the corresponding user, and reliably removes their commitment from the local database.
|
||||
|
||||
### Deliverables
|
||||
|
||||
* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover).
|
||||
|
||||
### Multi-prover with shared Database
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:shared-db`
|
||||
* owner: Sylvain
|
||||
* status: not started
|
||||
* start-date:
|
||||
* end-date:
|
||||
|
||||
### Description
|
||||
|
||||
@@ -86,4 +187,51 @@ The findings and feedback will be reflected in the RLN specification.
|
||||
|
||||
### Deliverables
|
||||
|
||||
* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover)
|
||||
* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover)
|
||||
|
||||
### RLN public website
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:rln-public-website`
|
||||
* owner: Ugur
|
||||
* status: not started
|
||||
* start-date: 2025/10/13
|
||||
* end-date: 2025/11/03
|
||||
|
||||
### Description
|
||||
|
||||
This task entails preparing a comprehensive and publicly shareable Notion document
|
||||
that consolidates the latest and most accurate notes on RLN (Rate Limiting Nullifier).
|
||||
The document should explain in technical detail how RLN enables the gasless feature in the Gasless L2,
|
||||
including the underlying cryptographic mechanisms that make gasless operations possible.
|
||||
This task is complete when the Notion document accurately compiles the most recent RLN insights,
|
||||
clearly articulates the technical reasoning behind the Gasless L2’s gasless functionality,
|
||||
and is structured in a manner suitable for public presentation.
|
||||
|
||||
### Deliverables
|
||||
|
||||
* A doc on [Status Notion](https://www.notion.so/Status-Program-f6eef7b91ad94539babf66c26ea1cf02).
|
||||
|
||||
|
||||
### SN RLN whitepaper
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:whitepaper`
|
||||
* owner: Ugur
|
||||
* status: not started
|
||||
* start-date: 2025/11/03
|
||||
* end-date: 2025/12/03
|
||||
|
||||
### Description
|
||||
|
||||
This task entails writing the Prover module section of the IEEE-format whitepaper,
|
||||
providing a detailed and technically rigorous explanation of RLN as implemented in the system.
|
||||
The section should build upon the existing RLN specification,
|
||||
expanding it with clear descriptions of the Prover’s responsibilities,
|
||||
data flow, and interactions with other components.
|
||||
It should also illustrate the key mechanisms and cryptographic processes that enable
|
||||
the Prover to function correctly within the RLN framework.
|
||||
This task is complete when the whitepaper section presents a comprehensive,
|
||||
technically accurate, and publication-ready explanation of the Prover module and its integration with RLN.
|
||||
|
||||
### Deliverables
|
||||
|
||||
* A doc on [Status Notion](https://www.notion.so/Status-Program-f6eef7b91ad94539babf66c26ea1cf02).
|
||||
|
||||
@@ -52,6 +52,38 @@ This task encompasses all maintenance updates for Zerokit, including CI updates
|
||||
#### Deliverables
|
||||
A set of PRs and issues to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/).
|
||||
|
||||
### FFI re-work
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-zerokit:ffi-rework`
|
||||
* owner: Vinh
|
||||
* status: started
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/10/13
|
||||
|
||||
#### Description
|
||||
This task entails reworking Zerokit’s FFI (Foreign Function Interface) to support passing data in Big Endian format,
|
||||
and to transition from a manual byte-based serialization approach to a safer and more maintainable opaque-struct model.
|
||||
Currently, FFI functions require developers to manually allocate buffers, serialize arguments,
|
||||
and handle deserialization within Rust, which introduces overhead, performance loss, fragile data handling
|
||||
and complex documentation requirements.
|
||||
Additionally, maintaining separate implementations for different endianness formats
|
||||
and managing numerous byte-to-struct conversions adds unnecessary complexity.
|
||||
|
||||
The proposed solution is to adopt an opaque struct pattern managed by Rust,
|
||||
allowing C code to manipulate only pointers through a defined API, leveraging the safer_ffi crate
|
||||
to automatically generate C headers, ensure memory safety, and remove unsafe code,
|
||||
as in planned in [this zerokit/discussion](https://github.com/vacp2p/zerokit/discussions/336).
|
||||
|
||||
This change aims to simplify the FFI layer, improve performance, reduce maintenance effort,
|
||||
and make the system more resilient to data format changes while easing integration with languages like C and Nim.
|
||||
|
||||
This task is complete when a proof of concept demonstrating RLN proof generation
|
||||
and verification through the new FFI model is implemented and validated
|
||||
for memory safety and Big Endian compatibility.
|
||||
|
||||
#### Deliverables
|
||||
A set of PRs and issues to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/).
|
||||
|
||||
### Release v1
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-zerokit:release`
|
||||
|
||||
@@ -98,7 +98,7 @@ In this task, we will examine the requirements for running NSSA as a L2 on Cosmo
|
||||
### Privacy Projects Analysis
|
||||
* fully qualified name: `vac:acz:nes:2025q3-nescience-consulting:privacy-projects-analysis`
|
||||
* owner: Marvin
|
||||
* status: started (90%)
|
||||
* status: done
|
||||
* start-date: 2025/08/25
|
||||
* end-date: 2025/08/08
|
||||
|
||||
@@ -111,7 +111,7 @@ Basically analyse:
|
||||
- Techniques used (e.g., consensus, snarks, etc)
|
||||
|
||||
### Deliverables
|
||||
* A notion doc to the Nescience notion workspace
|
||||
* [A notion doc](https://www.notion.so/Draft-WIP-2538f96fb65c80ff83afcad4fd3ca2f9) to the Nescience notion workspace
|
||||
|
||||
### Specs for Key Protocols
|
||||
* fully qualified name: `vac:acz:nes:2025q3-nescience-consulting:key-protocol-spec`
|
||||
@@ -154,7 +154,7 @@ workload depending on the findings.
|
||||
### DEX Research
|
||||
* fully qualified name: `vac:acz:nes:2025q3-nescience-consulting:dex-research`
|
||||
* owner: Marvin
|
||||
* status: started (50%)
|
||||
* status: done
|
||||
* start-date:
|
||||
* end-date:
|
||||
|
||||
@@ -170,7 +170,7 @@ By the end of this task, we should have a clear understanding
|
||||
of how Nescience compares to other projects from a user perspective.
|
||||
|
||||
### Deliverables
|
||||
* A notion doc to the Nescience notion workspace that summarizes existing projects
|
||||
* [A notion doc](https://www.notion.so/DEX-on-NSSA-25a8f96fb65c807496c0c0aadd16d56e) to the Nescience notion workspace that summarizes existing projects
|
||||
from a user perspective, notes their roadmap progress, and compares each to NSSA.
|
||||
|
||||
### Regulatory Positioning
|
||||
@@ -195,7 +195,7 @@ for how NSSA avoids classification under certain regulatory categories.
|
||||
### Nomos Deep Dive
|
||||
* fully qualified name: `vac:acz:nes:2025q3-nescience-consulting:nomos-deep-dive`
|
||||
* owner: Marvin
|
||||
* status: started (90%)
|
||||
* status: done
|
||||
* start-date: 2025/07/31
|
||||
* end-date: 2025/08/08
|
||||
|
||||
@@ -203,7 +203,7 @@ for how NSSA avoids classification under certain regulatory categories.
|
||||
Nescience’s architecture is designed to function as a L1 and as a L2. Nomos’ infrastructure is designed to allow a network in blockchains to exist in a single ecosystem sharing the same storage (and in some instances, the same consensus). Nomos supports application-specific blockchains in two ways: zones and sovereign rollups. In this task, we deep dive into Nomos’ infrastructure to determine the best fit and potential changes for NSSA’s deployment in Nomos.
|
||||
|
||||
### Deliverables:
|
||||
A document that:
|
||||
[A document ](https://www.notion.so/Nescience-in-Nomos-2488f96fb65c801c8d10ef6d6f3d87ed)that:
|
||||
* provides an overview of Nomos infrastructure
|
||||
* provides an overview of Zone and sovereign rollup requirements
|
||||
* Conclusion on the best fit for NSSA in Nomos
|
||||
@@ -211,7 +211,7 @@ A document that:
|
||||
### Specs compatibility
|
||||
* fully qualified name: `vac:acz:nes:2025q3-nescience-consulting:specs-compat`
|
||||
* owner: Marvin
|
||||
* status: not started
|
||||
* status: done
|
||||
* start-date:
|
||||
* end-date:
|
||||
|
||||
@@ -220,7 +220,7 @@ Nescience's architecture has been specified for NSSAv.01 and portions implemente
|
||||
of the specifications and implementation. Additionally, will audit the specifications and implementations for any potential vulnerabilities.
|
||||
|
||||
### Deliverables:
|
||||
A document that:
|
||||
[A document](https://www.notion.so/NSSAv0-1-compatibility-and-security-2658f96fb65c80fb997fcb60be80d19a) that:
|
||||
* provides a brief security analysis of specifications
|
||||
* notes on any differences between code and specifications
|
||||
* examination of theoretical attack models against specifications
|
||||
|
||||
Reference in New Issue
Block a user