mirror of
https://github.com/vacp2p/roadmap.git
synced 2026-01-08 21:27:58 -05:00
ACZ Updates - 2025-10-27 (#319)
progresses updated --------- Co-authored-by: fbarbu15 <florin@status.im>
This commit is contained in:
seugu
@@ -1,96 +1,96 @@
|
||||
---
|
||||
title: de-MLS testnet
|
||||
tags:
|
||||
- "2025q4"
|
||||
- "acz"
|
||||
- "ift"
|
||||
draft: false
|
||||
description: "Releasing de-MLS with the multi-steward support and Ethereum authentication mechanism."
|
||||
|
||||
---
|
||||
|
||||
`vac:acz:ift:2025q4-de-mls-tesnet`
|
||||
|
||||
## Description
|
||||
This commitment involves releasing the de-MLS poc with the multi-steward configurations.
|
||||
The process includes presenting the findings, such as MLS over Waku and benchmarking,
|
||||
and then achieving better iteration for the EF grant.
|
||||
|
||||
### Background
|
||||
de-MLS is a decentralized, scalable, end-to-end encrypted (E2EE)
|
||||
group messaging application with Ethereum-based authentication.
|
||||
The primary goal of this project is to develop a comprehensive
|
||||
and a mature RFC that outlines decentralized, secure, and scalable group key generation,
|
||||
designed to accommodate large numbers of users within a single group.
|
||||
|
||||
During 2025q3, we released the multi-steward de-MLS RFC, including consensus implementation.
|
||||
The implementation plan for this quarter is to release multi-steward with a single consensus
|
||||
version with Ethereum authentication factor by operating across the Waku network.
|
||||
|
||||
### Narratives
|
||||
We will reinforce the Conduit of Expertise narrative by:
|
||||
* Develop the foundational framework for a decentralized, scalable messaging application
|
||||
* Research and implement the scalable and decentralized consensus mechanism.
|
||||
|
||||
We will also strengthen the Premier Research Destination narrative by:
|
||||
* Develop a standardized decentralized messaging application over the Waku network,
|
||||
by providing a well-structured RFC and a proof of concept (PoC) that demonstrates
|
||||
It's a base functionality within the ecosystem.
|
||||
This will allow teams and organizations to build their own messaging applications
|
||||
while benefiting from these features.
|
||||
* Maintain the proposal by having the next iteration for the Ethereum Foundation (EF)
|
||||
to apply for EF grants to promote the project and gain support from the Ethereum ecosystem.
|
||||
|
||||
## Task List
|
||||
|
||||
### Maintain de-MLS RFC with multi stewards
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-de-mls-tesnet:multi-steward-rfc`
|
||||
* owner: Ugur
|
||||
* status: in progress (15%)
|
||||
* start-date: 2025/10/25
|
||||
* end-date: 2025/11/25
|
||||
|
||||
#### Description
|
||||
|
||||
Maintain and develop the decentralized MLS RFC by addressing feedback.
|
||||
The RFC needs to contain a concrete flow and explanation.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* A PR to vacp2p/rfc-index repo with related updates.
|
||||
|
||||
### Multi-steward integration
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-de-mls-tesnet:multi-steward-integration`
|
||||
* owner: Ekaterina
|
||||
* status: in progress (5%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/11/01
|
||||
|
||||
#### Description
|
||||
|
||||
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.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* A PR to the [de-MLS repository](https://github.com/vacp2p/de-mls)
|
||||
containing an update of message processing
|
||||
|
||||
### de-mls maintenance
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-de-mls-tesnet:de-mls-maintaining`
|
||||
* owner: Ekaterina
|
||||
* status: not started
|
||||
* start-date: 2025/06/30
|
||||
* end-date: 2025/09/30
|
||||
|
||||
#### Description
|
||||
|
||||
This task encompasses all maintenance updates for de-mls, including CI updates,
|
||||
testing, small issues, and the creation of future issues.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
---
|
||||
title: de-MLS testnet
|
||||
tags:
|
||||
- "2025q4"
|
||||
- "acz"
|
||||
- "ift"
|
||||
draft: false
|
||||
description: "Releasing de-MLS with the multi-steward support and Ethereum authentication mechanism."
|
||||
|
||||
---
|
||||
|
||||
`vac:acz:ift:2025q4-de-mls-tesnet`
|
||||
|
||||
## Description
|
||||
This commitment involves releasing the de-MLS poc with the multi-steward configurations.
|
||||
The process includes presenting the findings, such as MLS over Waku and benchmarking,
|
||||
and then achieving better iteration for the EF grant.
|
||||
|
||||
### Background
|
||||
de-MLS is a decentralized, scalable, end-to-end encrypted (E2EE)
|
||||
group messaging application with Ethereum-based authentication.
|
||||
The primary goal of this project is to develop a comprehensive
|
||||
and a mature RFC that outlines decentralized, secure, and scalable group key generation,
|
||||
designed to accommodate large numbers of users within a single group.
|
||||
|
||||
During 2025q3, we released the multi-steward de-MLS RFC, including consensus implementation.
|
||||
The implementation plan for this quarter is to release multi-steward with a single consensus
|
||||
version with Ethereum authentication factor by operating across the Waku network.
|
||||
|
||||
### Narratives
|
||||
We will reinforce the Conduit of Expertise narrative by:
|
||||
* Develop the foundational framework for a decentralized, scalable messaging application
|
||||
* Research and implement the scalable and decentralized consensus mechanism.
|
||||
|
||||
We will also strengthen the Premier Research Destination narrative by:
|
||||
* Develop a standardized decentralized messaging application over the Waku network,
|
||||
by providing a well-structured RFC and a proof of concept (PoC) that demonstrates
|
||||
It's a base functionality within the ecosystem.
|
||||
This will allow teams and organizations to build their own messaging applications
|
||||
while benefiting from these features.
|
||||
* Maintain the proposal by having the next iteration for the Ethereum Foundation (EF)
|
||||
to apply for EF grants to promote the project and gain support from the Ethereum ecosystem.
|
||||
|
||||
## Task List
|
||||
|
||||
### Maintain de-MLS RFC with multi stewards
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-de-mls-tesnet:multi-steward-rfc`
|
||||
* owner: Ugur
|
||||
* status: in progress (60%)
|
||||
* start-date: 2025/10/25
|
||||
* end-date: 2025/11/25
|
||||
|
||||
#### Description
|
||||
|
||||
Maintain and develop the decentralized MLS RFC by addressing feedback.
|
||||
The RFC needs to contain a concrete flow and explanation.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* A [PR](https://github.com/vacp2p/rfc-index/pull/193) to vacp2p/rfc-index repo with related updates.
|
||||
|
||||
### Multi-steward integration
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-de-mls-tesnet:multi-steward-integration`
|
||||
* owner: Ekaterina
|
||||
* status: in progress (5%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/11/01
|
||||
|
||||
#### Description
|
||||
|
||||
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.
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* A PR to the [de-MLS repository](https://github.com/vacp2p/de-mls)
|
||||
containing an update of message processing
|
||||
|
||||
### de-mls maintenance
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-de-mls-tesnet:de-mls-maintaining`
|
||||
* owner: Ekaterina
|
||||
* status: not started
|
||||
* start-date: 2025/06/30
|
||||
* end-date: 2025/09/30
|
||||
|
||||
#### Description
|
||||
|
||||
This task encompasses all maintenance updates for de-mls, including CI updates,
|
||||
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)
|
||||
@@ -1,166 +1,166 @@
|
||||
---
|
||||
title: Discovery
|
||||
tags:
|
||||
- "2025q4"
|
||||
- "acz"
|
||||
- "ift"
|
||||
draft: false
|
||||
description: "Specifying disc-NG and releasing a document that collects the requirements of discovery"
|
||||
|
||||
---
|
||||
|
||||
`vac:acz:ift:2025q4-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 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 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 KAD-DHT–based disc-NG-like RFC information to the community.
|
||||
|
||||
## Task List
|
||||
|
||||
### Draft RFC
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-discovery:draft-RFC`
|
||||
* owner: Arunima
|
||||
* status: in progress (10%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/10/30
|
||||
|
||||
#### Description
|
||||
|
||||
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.
|
||||
|
||||
### Registrar Module
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-discovery:registrar-module`
|
||||
* owner: Arunima
|
||||
* status: in progress (0%)
|
||||
* 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: not 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: not 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: not 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
|
||||
* end-date: 2025/11/30
|
||||
|
||||
#### Description
|
||||
|
||||
This task involves addressing the feedback from the draft RFC task,
|
||||
organizing it into a draft PR, and then going through another review phase.
|
||||
It also includes discussing and addressing any newly identified or initiative-requiring topics.
|
||||
The task concludes with the merge of the PR.
|
||||
|
||||
|
||||
#### Deliverables
|
||||
|
||||
---
|
||||
title: Discovery
|
||||
tags:
|
||||
- "2025q4"
|
||||
- "acz"
|
||||
- "ift"
|
||||
draft: false
|
||||
description: "Specifying disc-NG and releasing a document that collects the requirements of discovery"
|
||||
|
||||
---
|
||||
|
||||
`vac:acz:ift:2025q4-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 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 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 KAD-DHT–based disc-NG-like RFC information to the community.
|
||||
|
||||
## Task List
|
||||
|
||||
### Draft RFC
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-discovery:draft-RFC`
|
||||
* owner: Arunima
|
||||
* status: in progress (70%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/10/30
|
||||
|
||||
#### Description
|
||||
|
||||
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.
|
||||
|
||||
### Registrar Module
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-discovery:registrar-module`
|
||||
* owner: Arunima
|
||||
* status: in progress (0%)
|
||||
* 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: not 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: not 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: not 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
|
||||
* end-date: 2025/11/30
|
||||
|
||||
#### Description
|
||||
|
||||
This task involves addressing the feedback from the draft RFC task,
|
||||
organizing it into a draft PR, and then going through another review phase.
|
||||
It also includes discussing and addressing any newly identified or initiative-requiring topics.
|
||||
The task concludes with the merge of the PR.
|
||||
|
||||
|
||||
#### Deliverables
|
||||
|
||||
* A PR to the [vacp2p/rfc-index](https://github.com/vacp2p/rfc-index/) repo.
|
||||
@@ -43,7 +43,7 @@ We will also strengthen the Premier Research Destination narrative by:
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:rln-spec-final`
|
||||
* owner: Sylvain
|
||||
* status: in progress (0%)
|
||||
* status: in progress (40%)
|
||||
* start-date: 2025/10/22
|
||||
* end-date: 2025/11/03
|
||||
|
||||
@@ -52,7 +52,7 @@ This task encompasses finalizing the RLN deployment spec with all its edge cases
|
||||
and ready to the final implementation.
|
||||
|
||||
#### Deliverables
|
||||
* A notion doc.
|
||||
* [A notion document](https://www.notion.so/RLN-Deployment-Specs-1f98f96fb65c806c8737d94851b4d14d)
|
||||
|
||||
### Prover Module maintaining
|
||||
|
||||
@@ -174,7 +174,7 @@ correctly identifies the corresponding user, and reliably removes their commitme
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:shared-db`
|
||||
* owner: Sylvain
|
||||
* status: in progress (%0)
|
||||
* status: in progress (10%)
|
||||
* start-date: 2025/11/03
|
||||
* end-date: 2025/11/30
|
||||
|
||||
@@ -208,7 +208,7 @@ The findings and feedback will be reflected in the RLN specification.
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:rln-public-website`
|
||||
* owner: Ugur
|
||||
* status: in progress (50%)
|
||||
* status: in progress (60%)
|
||||
* start-date: 2025/10/13
|
||||
* end-date: 2025/11/03
|
||||
|
||||
|
||||
@@ -1,101 +1,124 @@
|
||||
---
|
||||
title: Zerokit
|
||||
tags:
|
||||
- "2025q4"
|
||||
- "acz"
|
||||
- "ift"
|
||||
draft: false
|
||||
description: "Maintaining and improving Zerokit, including the release of version v1.0.0,
|
||||
which supports BE and improved FFI, lastly researching new ZK proof techniques"
|
||||
|
||||
---
|
||||
|
||||
`vac:acz:ift:2025q4-zerokit`
|
||||
## Description
|
||||
|
||||
This commitment entails developing and maintaining Zerokit
|
||||
including Zerokit v1 release by advancing the next version, such as
|
||||
big-endian support, research on faster proving methods,
|
||||
lastly improved FFI feature and new ZK proofs research.
|
||||
|
||||
### Background
|
||||
|
||||
[Zerokit](https://github.com/vacp2p/zerokit) is a collection of Zero Knowledge modules
|
||||
that focus on RLN, developed in Rust, is intended for integration with various system programming environments.
|
||||
|
||||
In 2025q3, we released Zerokit v0.9.0, which supports improved CI, optimized, partially BE support and research on FFI improvements.
|
||||
|
||||
### Narratives
|
||||
|
||||
By utilizing the zerokit commitment, we will reinforce the Conduit of Expertise narrative by:
|
||||
* Delivers an optimized version for IFT projects utilizing Zerokit,
|
||||
including [nwaku](https://github.com/waku-org/nwaku)and [js-rln](https://github.com/waku-org/js-rln)
|
||||
and [Status L2](https://docs.status.network/).
|
||||
|
||||
We will also strengthen the Premier Research Destination narrative by:
|
||||
* Offers a Rust crate that serves as a more efficient open-source development tool for users looking to integrate RLN into their projects.
|
||||
* Verifying the existing ZK framework by integrating zerokit.
|
||||
|
||||
## Task List
|
||||
|
||||
### Zerokit maintaining
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-zerokit:zerokit-maintaining`
|
||||
* owner: Ekaterina
|
||||
* status: in progress (%0)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/12/30
|
||||
|
||||
#### Description
|
||||
This task encompasses all maintenance updates for Zerokit, including CI updates and the creation of future issues.
|
||||
|
||||
#### 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: in progress (60%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/11/01
|
||||
|
||||
#### Description
|
||||
The due date of this task is expanded to 11/01 due to the bugs and test requirements.
|
||||
|
||||
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`
|
||||
* owner: Ekaterina
|
||||
* status: not started
|
||||
* start-date: 2025/12/15
|
||||
* end-date: 2025/12/30
|
||||
|
||||
#### Description
|
||||
The new version of the Zerokit v1.0.0.
|
||||
|
||||
#### Deliverables
|
||||
---
|
||||
title: Zerokit
|
||||
tags:
|
||||
- "2025q4"
|
||||
- "acz"
|
||||
- "ift"
|
||||
draft: false
|
||||
description: "Maintaining and improving Zerokit, including the release of version v1.0.0,
|
||||
which supports BE and improved FFI, lastly researching new ZK proof techniques"
|
||||
|
||||
---
|
||||
|
||||
`vac:acz:ift:2025q4-zerokit`
|
||||
## Description
|
||||
|
||||
This commitment entails developing and maintaining Zerokit
|
||||
including Zerokit v1 release by advancing the next version, such as
|
||||
big-endian support, research on faster proving methods,
|
||||
lastly improved FFI feature and new ZK proofs research.
|
||||
|
||||
### Background
|
||||
|
||||
[Zerokit](https://github.com/vacp2p/zerokit) is a collection of Zero Knowledge modules
|
||||
that focus on RLN, developed in Rust, is intended for integration with various system programming environments.
|
||||
|
||||
In 2025q3, we released Zerokit v0.9.0, which supports improved CI, optimized, partially BE support and research on FFI improvements.
|
||||
|
||||
### Narratives
|
||||
|
||||
By utilizing the zerokit commitment, we will reinforce the Conduit of Expertise narrative by:
|
||||
* Delivers an optimized version for IFT projects utilizing Zerokit,
|
||||
including [nwaku](https://github.com/waku-org/nwaku)and [js-rln](https://github.com/waku-org/js-rln)
|
||||
and [Status L2](https://docs.status.network/).
|
||||
|
||||
We will also strengthen the Premier Research Destination narrative by:
|
||||
* Offers a Rust crate that serves as a more efficient open-source development tool for users looking to integrate RLN into their projects.
|
||||
* Verifying the existing ZK framework by integrating zerokit.
|
||||
|
||||
## Task List
|
||||
|
||||
### Zerokit maintaining
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-zerokit:zerokit-maintaining`
|
||||
* owner: Ekaterina
|
||||
* status: in progress (%30)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/12/30
|
||||
|
||||
#### Description
|
||||
This task encompasses all maintenance updates for Zerokit, including CI updates and the creation of future issues.
|
||||
|
||||
#### Deliverables
|
||||
A set of PRs and issues to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/).
|
||||
|
||||
### Wasm FFI Rework
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-zerokit:wasm-ffi-rework`
|
||||
* owner: Vinh
|
||||
* status: not started
|
||||
* start-date: 2025/11/03
|
||||
* end-date: 2025/11/10
|
||||
|
||||
#### Description
|
||||
This task aims to rework the current rln-wasm module to replace its serialization/deserialization-based
|
||||
FFI interface with opaque Rust structures exposed directly to JavaScript via wasm-bindgen.
|
||||
Instead of converting data to and from serialized formats when crossing the Rust–JS boundary,
|
||||
we will define types like `WasmFr` (a wrapper around `ark_bn254::Fr`) and `WasmRLNProofValues` that can be used natively in JavaScript.
|
||||
For discussion and context, see: [Zerokit Discussion](https://github.com/vacp2p/zerokit/discussions/336)
|
||||
|
||||
#### Deliverables
|
||||
* A PR to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/) that covers:
|
||||
* Refactor: Replace serialization-based argument passing with opaque structs (WasmFr, WasmRLNProofValues, etc.).
|
||||
|
||||
* Bindings Update: Regenerate JS/TS bindings and verify correct usage in Node.js test and Browser headless test.
|
||||
|
||||
* Documentation & Examples: Add usage examples, note wasm-bindgen constructor support, and document known limitations (e.g., tuple returns not supported)
|
||||
|
||||
### FFI re-work
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-zerokit:ffi-rework`
|
||||
* owner: Vinh
|
||||
* status: in progress (80%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/11/01
|
||||
|
||||
#### Description
|
||||
The due date of this task is expanded to 11/01 due to the bugs and test requirements.
|
||||
|
||||
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`
|
||||
* owner: Ekaterina
|
||||
* status: not started
|
||||
* start-date: 2025/12/15
|
||||
* end-date: 2025/12/30
|
||||
|
||||
#### Description
|
||||
The new version of the Zerokit v1.0.0.
|
||||
|
||||
#### Deliverables
|
||||
A set of PRs to vacp2p/zerokit repository with [tag v1.0.0](https://github.com/vacp2p/zerokit/releases/tag/v1.0.0)
|
||||
@@ -37,7 +37,7 @@ and introduced into the ecosystem.
|
||||
### Zk Consulting Nomos 1
|
||||
* fully qualified name: `vac:acz:nomos:2025q4-nomos-consulting:zk-consulting-nomos-1`
|
||||
* owner: Marvin
|
||||
* status: in progress (10%)
|
||||
* status: done
|
||||
* start-date: 2025/10/13
|
||||
* end-date: 2025/10/27
|
||||
|
||||
|
||||
Reference in New Issue
Block a user