mirror of
https://github.com/vacp2p/roadmap.git
synced 2026-01-08 21:27:58 -05:00
Chore/roadmap validator 2 (#323)
This commit is contained in:
fbarbu15
@@ -1,252 +1,252 @@
|
||||
---
|
||||
title: RLN Status L2
|
||||
tags:
|
||||
- "2025q4"
|
||||
- "acz"
|
||||
- "ift"
|
||||
draft: false
|
||||
description: "Deploying and testing the prover module in testnet and devnet,
|
||||
releasing the prover module with shared DB support,
|
||||
as well as maintaining the code quality and performance"
|
||||
|
||||
---
|
||||
|
||||
`vac:acz:ift:2025q4-rln-status-l2`
|
||||
|
||||
## Description
|
||||
This commitment entails testing the deployed RLN prover module for
|
||||
the gasless feature of Status L2 architecture in testnet and devnet.
|
||||
Specificaly, testing that all RLN components such as prover,
|
||||
verifier, deny list and RPC node in monorepo.
|
||||
|
||||
### Background
|
||||
Status L2 is a rollup with Linea and builds a platform with the capacity to support
|
||||
SocialFi and GameFi apps, governance experiments, the Status voting system,
|
||||
and more, all while aiming to keep transaction costs low and throughput high.
|
||||
Status L2 will incorporate a gasless feature, necessitating an effective anti-spam mechanism.
|
||||
Rate-Limiting Nullifier (RLN) is a potential solution that could be deployed on Status L2
|
||||
to prevent spam and support the gasless functionality.
|
||||
|
||||
In 2025q3, we released the RLN prover module with tracking module, tests, optimizations and benchmarks.
|
||||
|
||||
### Narratives
|
||||
By utilizing this commitment, we will reinforce the Conduit of Expertise narrative by:
|
||||
* Continue sharing the RLN knowledge with the Status L2 team.
|
||||
* Testing modified RLN design to make sure all components work seamlessly.
|
||||
|
||||
We will also strengthen the Premier Research Destination narrative by:
|
||||
* Offering an RLN use-case to the ecosystem that can be used for other gasless roll-up projects.
|
||||
|
||||
## Task List
|
||||
|
||||
### Finalizing the RLN deployment spec
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:rln-spec-final`
|
||||
* owner: Sylvain
|
||||
* status: in progress (40%)
|
||||
* start-date: 2025/10/22
|
||||
* end-date: 2025/11/03
|
||||
|
||||
#### Description
|
||||
This task encompasses finalizing the RLN deployment spec with all its edge cases
|
||||
and ready to the final implementation.
|
||||
|
||||
#### Deliverables
|
||||
* [A notion document](https://www.notion.so/RLN-Deployment-Specs-1f98f96fb65c806c8737d94851b4d14d)
|
||||
|
||||
### Prover Module maintaining
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:maintaining`
|
||||
* owner: Sylvain
|
||||
* status: in progress (10%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/02/30
|
||||
|
||||
#### Description
|
||||
This task encompasses all maintenance updates for prover module,
|
||||
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 Tree Support
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:multi-tree`
|
||||
* owner: Sylvain
|
||||
* status: done
|
||||
* 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](https://github.com/vacp2p/status-rln-prover/pull/49) 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: done
|
||||
* start-date: 2025/10/15
|
||||
* end-date: 2025/10/20
|
||||
|
||||
### 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](https://github.com/vacp2p/status-rln-prover/pull/51) 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](https://github.com/vacp2p/status-rln-prover/pull/52) 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: in progress (10%)
|
||||
* start-date: 2025/11/03
|
||||
* end-date: 2025/11/30
|
||||
|
||||
### Description
|
||||
|
||||
This task entails modifying the prover instance to release the multi-prover that each prover module
|
||||
can write to the shared DB for having a prover cluster based on the pre-research in 2025q3.
|
||||
|
||||
### Deliverables
|
||||
|
||||
* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover).
|
||||
|
||||
### Devnet testing
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:devnet-testing`
|
||||
* owner: Sylvain
|
||||
* status: not started (5%)
|
||||
* start-date: 2025/10/15
|
||||
* end-date: 2025/11/15
|
||||
|
||||
### Description
|
||||
|
||||
This task focuses on testing the internal devnet.
|
||||
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)
|
||||
|
||||
### RLN public website
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:rln-public-website`
|
||||
* owner: Ugur
|
||||
* status: in progress (60%)
|
||||
* 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).
|
||||
---
|
||||
title: RLN Status L2
|
||||
tags:
|
||||
- "2025q4"
|
||||
- "acz"
|
||||
- "ift"
|
||||
draft: false
|
||||
description: "Deploying and testing the prover module in testnet and devnet,
|
||||
releasing the prover module with shared DB support,
|
||||
as well as maintaining the code quality and performance"
|
||||
|
||||
---
|
||||
|
||||
`vac:acz:ift:2025q4-rln-status-l2`
|
||||
|
||||
## Description
|
||||
This commitment entails testing the deployed RLN prover module for
|
||||
the gasless feature of Status L2 architecture in testnet and devnet.
|
||||
Specificaly, testing that all RLN components such as prover,
|
||||
verifier, deny list and RPC node in monorepo.
|
||||
|
||||
### Background
|
||||
Status L2 is a rollup with Linea and builds a platform with the capacity to support
|
||||
SocialFi and GameFi apps, governance experiments, the Status voting system,
|
||||
and more, all while aiming to keep transaction costs low and throughput high.
|
||||
Status L2 will incorporate a gasless feature, necessitating an effective anti-spam mechanism.
|
||||
Rate-Limiting Nullifier (RLN) is a potential solution that could be deployed on Status L2
|
||||
to prevent spam and support the gasless functionality.
|
||||
|
||||
In 2025q3, we released the RLN prover module with tracking module, tests, optimizations and benchmarks.
|
||||
|
||||
### Narratives
|
||||
By utilizing this commitment, we will reinforce the Conduit of Expertise narrative by:
|
||||
* Continue sharing the RLN knowledge with the Status L2 team.
|
||||
* Testing modified RLN design to make sure all components work seamlessly.
|
||||
|
||||
We will also strengthen the Premier Research Destination narrative by:
|
||||
* Offering an RLN use-case to the ecosystem that can be used for other gasless roll-up projects.
|
||||
|
||||
## Task List
|
||||
|
||||
### Finalizing the RLN deployment spec
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:rln-spec-final`
|
||||
* owner: Sylvain
|
||||
* status: in progress (40%)
|
||||
* start-date: 2025/10/22
|
||||
* end-date: 2025/11/03
|
||||
|
||||
#### Description
|
||||
This task encompasses finalizing the RLN deployment spec with all its edge cases
|
||||
and ready to the final implementation.
|
||||
|
||||
#### Deliverables
|
||||
* [A notion document](https://www.notion.so/RLN-Deployment-Specs-1f98f96fb65c806c8737d94851b4d14d)
|
||||
|
||||
### Prover Module maintaining
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:maintaining`
|
||||
* owner: Sylvain
|
||||
* status: in progress (10%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/02/30
|
||||
|
||||
#### Description
|
||||
This task encompasses all maintenance updates for prover module,
|
||||
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 Tree Support
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:multi-tree`
|
||||
* owner: Sylvain
|
||||
* status: done
|
||||
* 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](https://github.com/vacp2p/status-rln-prover/pull/49) 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: done
|
||||
* start-date: 2025/10/15
|
||||
* end-date: 2025/10/20
|
||||
|
||||
### 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](https://github.com/vacp2p/status-rln-prover/pull/51) 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](https://github.com/vacp2p/status-rln-prover/pull/52) 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: in progress (10%)
|
||||
* start-date: 2025/11/03
|
||||
* end-date: 2025/11/30
|
||||
|
||||
### Description
|
||||
|
||||
This task entails modifying the prover instance to release the multi-prover that each prover module
|
||||
can write to the shared DB for having a prover cluster based on the pre-research in 2025q3.
|
||||
|
||||
### Deliverables
|
||||
|
||||
* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover).
|
||||
|
||||
### Devnet testing
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:devnet-testing`
|
||||
* owner: Sylvain
|
||||
* status: in progress (5%)
|
||||
* start-date: 2025/10/15
|
||||
* end-date: 2025/11/15
|
||||
|
||||
### Description
|
||||
|
||||
This task focuses on testing the internal devnet.
|
||||
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)
|
||||
|
||||
### RLN public website
|
||||
|
||||
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:rln-public-website`
|
||||
* owner: Ugur
|
||||
* status: in progress (60%)
|
||||
* 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).
|
||||
|
||||
@@ -1,124 +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 (%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
|
||||
---
|
||||
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)
|
||||
@@ -145,7 +145,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known.
|
||||
|
||||
* fully qualified name: `vac:dst:ift:2025q4-dst-tooling:complete-deployment-refactor`
|
||||
* owner: Pearson
|
||||
* status: 70%
|
||||
* status: in progress (70%)
|
||||
* start-date: 2025/10/06
|
||||
* end-date: 2025/10/24
|
||||
|
||||
|
||||
@@ -102,7 +102,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known.
|
||||
|
||||
* fully qualified name: `vac:dst:status:2025q4-status-evaluation:chat-protocol-benchmarks-followup`
|
||||
* owner: Alberto
|
||||
* status: 70%
|
||||
* status: in progress (70%)
|
||||
* start-date: 2025/10/06
|
||||
* end-date: 2025/10/24
|
||||
|
||||
|
||||
@@ -137,7 +137,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known.
|
||||
|
||||
* fully qualified name: `vac:dst:vac:2025q4-libp2p-evaluation:mix-in-nim-libp2p-node`
|
||||
* owner: Farooq
|
||||
* status: 100%
|
||||
* status: done
|
||||
* start-date: 2025/10/06
|
||||
* end-date: 2025/10/17
|
||||
|
||||
@@ -154,7 +154,7 @@ include mix to the configuration options of the node.
|
||||
|
||||
* fully qualified name: `vac:dst:vac:2025q4-libp2p-evaluation:go-libp2p-node`
|
||||
* owner: Farooq
|
||||
* status: 100%
|
||||
* status: done
|
||||
* start-date: 2025/10/06
|
||||
* end-date: 2025/10/24
|
||||
|
||||
@@ -173,7 +173,7 @@ Report results of a single scenario (fixed parameters) using K8s and shadow.
|
||||
|
||||
* fully qualified name: `vac:dst:vac:2025q4-libp2p-evaluation:rust-libp2p-node`
|
||||
* owner: Farooq
|
||||
* status: 0%
|
||||
* status: not started
|
||||
* start-date: 2025/10/27
|
||||
* end-date: 2025/11/07
|
||||
|
||||
|
||||
@@ -70,7 +70,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known.
|
||||
|
||||
* fully qualified name: `vac:dst:waku:2025q4-waku-scaling:optimise-browser-bootstrapping`
|
||||
* owner: Pearson
|
||||
* status: 10%
|
||||
* status: in progress (10%)
|
||||
* start-date: 2025/10/15
|
||||
* end-date: 2025/10/31
|
||||
|
||||
@@ -181,7 +181,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known.
|
||||
|
||||
* fully qualified name: `vac:dst:waku:2025q4-waku-scaling:TWN-supports-RLN-tree`
|
||||
* owner: Alberto
|
||||
* status: 70%
|
||||
* status: in progress (70%)
|
||||
* start-date: 2025/10/06
|
||||
* end-date: 2025/10/24
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ We'll prioritize these enhancements to bring Nimble closer to its 1.0 release, e
|
||||
By the end of this quarter, we aim to have made significant progress on these fronts, setting the stage for Nimble to become the go-to package manager in IFT projects.
|
||||
|
||||
|
||||
## Tasks
|
||||
## Task List
|
||||
|
||||
### Nimble 1.0.0
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ This deliverable continues the work started in 2025q2
|
||||
|
||||
* fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-kad-dht:routing-and-rpc`
|
||||
* owner: gabe/rramos
|
||||
* status: in progress(75%)
|
||||
* status: in progress (75%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/12/31
|
||||
|
||||
@@ -59,7 +59,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known.
|
||||
|
||||
* fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-kad-dht:network-maintenance-node-management`
|
||||
* owner: gabe
|
||||
* status: in progress(50%)
|
||||
* status: in progress (50%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/12/31
|
||||
|
||||
@@ -76,7 +76,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known.
|
||||
|
||||
* fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-kad-dht:data-storage`
|
||||
* owner: gabe
|
||||
* status: in progress(90%)
|
||||
* status: in progress (90%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/12/31
|
||||
|
||||
@@ -96,7 +96,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known.
|
||||
|
||||
* fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-kad-dht:data-retrieval`
|
||||
* owner: gabe
|
||||
* status: in progress(60%)
|
||||
* status: in progress (60%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/12/31
|
||||
|
||||
@@ -113,7 +113,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known.
|
||||
### Discovery
|
||||
* fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-kad-dht:discovery`
|
||||
* owner: gabe
|
||||
* status: in progress(15%)
|
||||
* status: in progress (15%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/12/31
|
||||
|
||||
@@ -135,4 +135,4 @@ PRs
|
||||
Ensure interop is achieved between nim-libp2p's kad-dht implementation and other libp2p implementations
|
||||
|
||||
#### Deliverables
|
||||
PRs
|
||||
PRs
|
||||
|
||||
@@ -44,7 +44,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known.
|
||||
|
||||
* fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-mix:stream-reuse`
|
||||
* owner: rramos
|
||||
* status: completed
|
||||
* status: done
|
||||
* start-date: 2025/10/13
|
||||
* end-date: 2025/10/22
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ In Q3 we discovered critical deficiencies in nim-quic, including runtime instabi
|
||||
|
||||
* fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-quic:stabilization`
|
||||
* owner: vlado/rramos
|
||||
* status: started
|
||||
* status: in progress (10%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/12/31
|
||||
|
||||
@@ -40,7 +40,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known.
|
||||
|
||||
* fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-quic:openssl-replacement`
|
||||
* owner: rramos
|
||||
* status: completed
|
||||
* status: done
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/10/15
|
||||
|
||||
|
||||
@@ -156,7 +156,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known.
|
||||
|
||||
* fully qualified name: `vac:qa:status:2025q4-status-qa-desktop:local-backup`
|
||||
* owner: nastya
|
||||
* status: in progress(75%)
|
||||
* status: in progress (75%)
|
||||
* start-date: 2025/10/07
|
||||
* end-date: 2025/10/20
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ Improve stability by addressing flaky tests and extend coverage for Identify/Pus
|
||||
|
||||
* fully qualified name: `vac:qa:vac:2025q4-nim-libp2p-testing:test-plans`
|
||||
* owner: radek
|
||||
* status: in progress(20%)
|
||||
* status: in progress (20%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/10/20
|
||||
|
||||
@@ -121,7 +121,7 @@ Update GossipSub performance tests based on dev feedback and existing data gathe
|
||||
|
||||
* fully qualified name: `vac:qa:vac:2025q4-nim-libp2p-testing:quic`
|
||||
* owner: radek
|
||||
* status: nin progress (5%)
|
||||
* status: in progress (5%)
|
||||
* start-date: 2025/10/16
|
||||
* end-date: 2025/11/25
|
||||
|
||||
|
||||
@@ -95,7 +95,7 @@ Extend Waku end-to-end tests with network condition scenarios (high latency, low
|
||||
|
||||
* fully qualified name: `vac:qa:waku:2025q4-waku-testing:maintenance`
|
||||
* owner: fbarbu15
|
||||
* status: in progress(20%)
|
||||
* status: in progress (20%)
|
||||
* start-date: 2025/10/01
|
||||
* end-date: 2025/12/30
|
||||
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
title: RFC Iteration
|
||||
tags:
|
||||
- 2025q4
|
||||
- rfc
|
||||
- codex
|
||||
draft: false
|
||||
@@ -41,7 +42,6 @@ editorial work through previous and future RFCs to improve them
|
||||
(identify edge cases for example)
|
||||
|
||||
|
||||
|
||||
**Alignment with VAC Narratives:**
|
||||
|
||||
- The VAC RFC team plans to become a repository
|
||||
@@ -57,93 +57,57 @@ in their projects, similar to [IETF](https://www.ietf.org/).
|
||||
|
||||
### Slot Builder
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:codex:2025q4-rfc-iteration:slot-builder'
|
||||
- Owner: jimstir
|
||||
- Status: 10%
|
||||
- Start date: 2025/10/01
|
||||
- End date: 2025/10/15
|
||||
- fully qualified name: `vac:rfc:codex:2025q4-rfc-iteration:slot-builder'
|
||||
- owner: jimstir
|
||||
- status: in progress (10%)
|
||||
- start-date: 2025/10/01
|
||||
- end-date: 2025/10/15
|
||||
|
||||
#### Description
|
||||
Create the RFC for slot builder, updating design decisions and open questions.
|
||||
|
||||
|
||||
#### Deliverables
|
||||
- PRs/Issues/Docs/Reports
|
||||
|
||||
### Erasure Coding Module
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:codex:2025q4-rfc-iteration:erasure-coding-module`
|
||||
- Owner: cofson
|
||||
- Status: not started
|
||||
- Start date: 2025/10/15
|
||||
- End date: 2025/10/30
|
||||
- fully qualified name: `vac:rfc:codex:2025q4-rfc-iteration:erasure-coding-module`
|
||||
- owner: cofson
|
||||
- status: not started
|
||||
- start-date: 2025/10/15
|
||||
- end-date: 2025/10/30
|
||||
|
||||
#### Description
|
||||
Create the RFC for the erasure coding module that documents data availability behaviour.
|
||||
|
||||
#### Deliverables
|
||||
- PRs/Issues/Docs/Reports
|
||||
|
||||
### Purchase Module
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:codex:2025q4-rfc-iteration:purchase-module`
|
||||
- Owner: cofson
|
||||
- Status: not started
|
||||
- Start date: 2025/10/04
|
||||
- End date: 2025/10/19
|
||||
- fully qualified name: `vac:rfc:codex:2025q4-rfc-iteration:purchase-module`
|
||||
- owner: cofson
|
||||
- status: not started
|
||||
- start-date: 2025/10/04
|
||||
- end-date: 2025/10/19
|
||||
|
||||
#### Description
|
||||
Create the RFC for the purchase module covering pricing, incentives, and settlement flows.
|
||||
|
||||
#### Deliverables
|
||||
- PRs/Issues/Docs/Reports
|
||||
|
||||
### The Block Exchange
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:codex:2025q4-rfc-iteration:the-block-exchange'
|
||||
- Owner: cofson
|
||||
- Status: not started
|
||||
- Start date: 2025/10/04
|
||||
- End date: 2025/10/31
|
||||
- fully qualified name: `vac:rfc:codex:2025q4-rfc-iteration:the-block-exchange'
|
||||
- owner: cofson
|
||||
- status: not started
|
||||
- start-date: 2025/10/04
|
||||
- end-date: 2025/10/31
|
||||
|
||||
<!--
|
||||
#### Description
|
||||
Create the RFC for the block exchange defining peer interactions for trading Codex data.
|
||||
|
||||
### Prover
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:codex:2025q3-rfc-iteration:prover'
|
||||
- Owner: cofson
|
||||
- Status: not started
|
||||
- Start date: 2025/09/20
|
||||
- End date: 2025/09/30
|
||||
|
||||
### Codex
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:codex:2025q3-rfc-iteration:codex`
|
||||
- Owner: cofson
|
||||
- Status: not started
|
||||
- Start date: 2025/09/20
|
||||
- End date: 2025/09/30
|
||||
|
||||
### Sales Module
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:codex:2025q3-rfc-iteration:sales-module`
|
||||
- Owner: cofson
|
||||
- Status: not started
|
||||
- Start date: 2025/09/20
|
||||
- End date: 2025/09/30
|
||||
|
||||
### Store Module
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:codex:2025q3-rfc-iteration:store-module`
|
||||
- Owner: cofson
|
||||
- Status: not started
|
||||
- Start date: 2025/09/20
|
||||
- End date: 2025/09/30
|
||||
|
||||
### Merkle Tree Specification
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:codex:2025q3-rfc-iteration:merkle-tree-specification`
|
||||
- Owner: cofson
|
||||
- Status: not started
|
||||
- Start date: 2025/09/20
|
||||
- End date: 2025/09/30
|
||||
|
||||
### Community History Service
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:codex:2025q3-rfc-iteration:community-history-service`
|
||||
- Owner: cofson
|
||||
- Status: not started
|
||||
- Start date: 2025/09/20
|
||||
- End date: 2025/09/30
|
||||
|
||||
-->
|
||||
#### Deliverables
|
||||
- PRs/Issues/Docs/Reports
|
||||
@@ -1,9 +1,9 @@
|
||||
---
|
||||
title: RFC Culture Establishment
|
||||
tags:
|
||||
- 2025q4
|
||||
- rfc
|
||||
- ift
|
||||
- vac
|
||||
draft: false
|
||||
description: Continuation of RFC Culture establishment through introducing new initiatives.
|
||||
---
|
||||
@@ -41,11 +41,11 @@ similar to [IETF](https://www.ietf.org/).
|
||||
|
||||
### Team Communication
|
||||
|
||||
- Fully qualified name: `vac:rfc:ift:2025q4-culture-establishment-team-communication`
|
||||
- Owner: cofson
|
||||
- Status: not started
|
||||
- Start date: 2025/10/01
|
||||
- End date: 2025/12/31
|
||||
- fully qualified name: `vac:rfc:ift:2025q4-rfc-culture-establishment:team-communication`
|
||||
- owner: cofson
|
||||
- status: not started
|
||||
- start-date: 2025/10/01
|
||||
- end-date: 2025/12/31
|
||||
|
||||
#### Description
|
||||
|
||||
|
||||
@@ -1,8 +1,9 @@
|
||||
---
|
||||
title: rfc-index-maintenance
|
||||
tags:
|
||||
- 2025q4
|
||||
- rfc
|
||||
- vac
|
||||
- ift
|
||||
draft: false
|
||||
description: This commitment revolves around a continuous effort to fix and update across the relevant RFC websites (including the communication).
|
||||
---
|
||||
|
||||
@@ -5,6 +5,26 @@ tags:
|
||||
- vac
|
||||
---
|
||||
|
||||
## 2025q4 `vac:rfc:`
|
||||
|
||||
|
||||
### `ift:`
|
||||
* [[rfc/ift/2025q4-rfc-culture-establishment|rfc-culture-establishment]]
|
||||
* [[rfc/ift/2025q4-rfc-index-maintenance|rfc-index-maintenance]]
|
||||
|
||||
### `waku:`
|
||||
* [[rfc/waku/2025q4-rfc-iteration|rfc-iteration]]
|
||||
|
||||
### `nomos:`
|
||||
* [[rfc/nomos/2025q4-rfc-iteration|rfc-iteration]]
|
||||
|
||||
### `codex:`
|
||||
* [[rfc/codex/2025q4-rfc-iteration|rfc-iteration]]
|
||||
|
||||
### `status:`
|
||||
* [[rfc/status/2025q4-rfc-iteration|rfc-iteration]]
|
||||
|
||||
|
||||
## 2025q3 `vac:rfc:`
|
||||
|
||||
|
||||
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: RFC Iteration
|
||||
tags:
|
||||
- rfc
|
||||
- nomos
|
||||
draft: false
|
||||
description: "Iteration commitments generally comprise: through discussion and curation, support the process of auditing raw, draft, mature selected RFCs."
|
||||
---
|
||||
|
||||
`vac:rfc:nescience:2025q4-rfc-iteration`
|
||||
|
||||
Iteration commitments generally comprise:
|
||||
through discussion and curation,
|
||||
support the process of auditing raw, draft, mature selected RFCs.
|
||||
|
||||
## Description
|
||||
|
||||
This commitment covers the writing of the following mature RFCs
|
||||
according to COSS, based on the Notion documentation:
|
||||
- TBD
|
||||
|
||||
We will also include specification validation -
|
||||
to make sure there are no errors, missing information, inconsistencies
|
||||
and that the specification is up to standards.
|
||||
|
||||
|
||||
|
||||
**Alignment with VAC Narratives:**
|
||||
|
||||
- The VAC RFC team plans to become a repository
|
||||
for RFCs regarding all IFT projects.
|
||||
- By promoting the RFC culture,
|
||||
we hope to incentivize projects to submit their RFCs
|
||||
to the rfc-editors team.
|
||||
- We aim to have the broader web3 community use our RFCs
|
||||
in their projects, similar to [IETF](https://www.ietf.org/).
|
||||
|
||||
## Task List
|
||||
|
||||
TBD
|
||||
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
title: RFC Iteration
|
||||
tags:
|
||||
- 2025q4
|
||||
- rfc
|
||||
- nomos
|
||||
draft: false
|
||||
@@ -46,45 +47,70 @@ in their projects, similar to [IETF](https://www.ietf.org/).
|
||||
|
||||
### Cryptarchia v1 Protocol Specification
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:nomos:2025q4-rfc-iteration:cryptarchia-v1-protocol-specification`
|
||||
- Owner: cofson
|
||||
- Status: not started
|
||||
- Start date: 2025/11/01
|
||||
- End date: 2025/11/15
|
||||
- fully qualified name: `vac:rfc:nomos:2025q4-rfc-iteration:cryptarchia-v1-protocol-specification`
|
||||
- owner: cofson
|
||||
- status: not started
|
||||
- start-date: 2025/11/01
|
||||
- end-date: 2025/11/15
|
||||
|
||||
#### Description
|
||||
Create the RFC for the Cryptarchia v1 protocol covering validators, messages, and consensus flow.
|
||||
|
||||
#### Deliverables
|
||||
- PRs/Issues/Docs/Reports
|
||||
|
||||
### Cryptarchia v1 Bootstrapping & Synchronization
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:nomos:2025q4-rfc-iteration:cryptarchia-v1-bootstrapping-and-synchronization`
|
||||
- Owner: cofson
|
||||
- Status: not started
|
||||
- Start date: 2025/11/01
|
||||
- End date: 2025/11/15
|
||||
- fully qualified name: `vac:rfc:nomos:2025q4-rfc-iteration:cryptarchia-v1-bootstrapping-and-synchronization`
|
||||
- owner: cofson
|
||||
- status: not started
|
||||
- start-date: 2025/11/01
|
||||
- end-date: 2025/11/15
|
||||
|
||||
#### Description
|
||||
Create the RFC for Cryptarchia bootstrapping and synchronization procedures.
|
||||
|
||||
#### Deliverables
|
||||
- PRs/Issues/Docs/Reports
|
||||
|
||||
### Cryptarchia Fork Choice Rule
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:nomos:2025q4-rfc-iteration:cryptarchia-fork-choice-rule`
|
||||
- Owner: cofson
|
||||
- Status: not started
|
||||
- Start date: 2025/12/01
|
||||
- End date: 2025/12/15
|
||||
- fully qualified name: `vac:rfc:nomos:2025q4-rfc-iteration:cryptarchia-fork-choice-rule`
|
||||
- owner: cofson
|
||||
- status: not started
|
||||
- start-date: 2025/12/01
|
||||
- end-date: 2025/12/15
|
||||
|
||||
#### Description
|
||||
Create the RFC for the Cryptarchia fork choice rule logic and safety guarantees.
|
||||
|
||||
#### Deliverables
|
||||
- PRs/Issues/Docs/Reports
|
||||
|
||||
### Total Stake Inference
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:nomos:2025q4-rfc-iteration:total-stake-inference`
|
||||
- Owner: cofson
|
||||
- Status: not started
|
||||
- Start date: 2025/12/01
|
||||
- End date: 2025/12/15
|
||||
- fully qualified name: `vac:rfc:nomos:2025q4-rfc-iteration:total-stake-inference`
|
||||
- owner: cofson
|
||||
- status: not started
|
||||
- start-date: 2025/12/01
|
||||
- end-date: 2025/12/15
|
||||
|
||||
#### Description
|
||||
Create the RFC for total stake inference and state tracking within Cryptarchia.
|
||||
|
||||
#### Deliverables
|
||||
- PRs/Issues/Docs/Reports
|
||||
|
||||
### Proof of Leadership Specification
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:nomos:2025q4-rfc-iteration:proof-of-leadership-specification`
|
||||
- Owner: cofson
|
||||
- Status: not started
|
||||
- Start date: 2025/12/20
|
||||
- End date: 2025/12/31
|
||||
- fully qualified name: `vac:rfc:nomos:2025q4-rfc-iteration:proof-of-leadership-specification`
|
||||
- owner: cofson
|
||||
- status: not started
|
||||
- start-date: 2025/12/20
|
||||
- end-date: 2025/12/31
|
||||
|
||||
#### Description
|
||||
Create the RFC for the proof of leadership mechanism, including leader election and validation criteria.
|
||||
|
||||
#### Deliverables
|
||||
- PRs/Issues/Docs/Reports
|
||||
@@ -1,7 +1,9 @@
|
||||
---
|
||||
title: RFC Iteration
|
||||
tags:
|
||||
- 2025q4
|
||||
- rfc
|
||||
- status
|
||||
draft: false
|
||||
description: "Iteration commitments generally comprise: through discussion and curation, support the process of auditing raw, draft, mature selected Status RFCs."
|
||||
---
|
||||
@@ -42,9 +44,14 @@ in their projects, similar to [IETF](https://www.ietf.org/).
|
||||
|
||||
### Chat Specifications Support
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:status:2025q4-rfc-iteration:chat-specifications-support`
|
||||
- Owner: Filip
|
||||
- Status: not started
|
||||
- Start date: 2025/11/01
|
||||
- End date: 2025/12/31
|
||||
- fully qualified name: `vac:rfc:status:2025q4-rfc-iteration:chat-specifications-support`
|
||||
- owner: Filip
|
||||
- status: not started
|
||||
- start date: 2025/11/01
|
||||
- end date: 2025/12/31
|
||||
|
||||
#### Description
|
||||
Create the RFC for Status chat specifications updates so docs match current client behaviour.
|
||||
|
||||
#### Deliverables
|
||||
- PRs/Issues/Docs/Reports
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
title: RFC Iteration
|
||||
tags:
|
||||
- 2025q4
|
||||
- rfc
|
||||
- waku
|
||||
draft: false
|
||||
@@ -50,9 +51,14 @@ from the point of view of a new developer.
|
||||
|
||||
### Opchan
|
||||
|
||||
- Fully qualified name:
|
||||
`vac:rfc:waku:2025q4-rfc-iteration:opchan`
|
||||
- Owner: jimstir
|
||||
- Status: 30% (paused)
|
||||
- Start date: 2025/11/01
|
||||
- End date: 2025/11/30
|
||||
- fully qualified name: `vac:rfc:waku:2025q4-rfc-iteration:opchan`
|
||||
- owner: jimstir
|
||||
- status: in progress (30%)
|
||||
- start-date: 2025/11/01
|
||||
- end-date: 2025/11/30
|
||||
|
||||
#### Description
|
||||
Create the RFC for Opchan reflecting the latest Waku channel architecture and open questions.
|
||||
|
||||
#### Deliverables
|
||||
- PRs/Issues/Docs/Reports
|
||||
Reference in New Issue
Block a user