ACZ Updates - 2025-11-17 (#337)

progresses updated
New de-mls task is added
This commit is contained in:
seugu
2025-11-18 17:27:16 +03:00
committed by GitHub
parent cea728964a
commit 8f44f6d461
5 changed files with 90 additions and 18 deletions

View File

@@ -33,7 +33,7 @@ version with Ethereum authentication factor by operating across the Waku network
* fully qualified name: `vac:acz:ift:2025q4-de-mls-tesnet:multi-steward-rfc`
* owner: Ugur
* status: in progress (60%)
* status: in progress (70%)
* start-date: 2025/10/25
* end-date: 2025/11/25
@@ -46,11 +46,50 @@ The RFC needs to contain a concrete flow and explanation.
* A [PR](https://github.com/vacp2p/rfc-index/pull/193) to vacp2p/rfc-index repo with related updates.
### Extract `hashgraph-like-consensus` into a standalone Rust library
* fully qualified name: `vac:acz:ift:2025q4-de-mls-testnet:extract-hashgraph-lib`
* owner: Ekaterina
* status: started (10%)
* start-date: 11/10/2025
* end-date: 12/10/2025
#### Description
The current hashgraph-like consensus implementation lives inside the `de-mls` codebase
and is tightly coupled to application-specific logic (Waku integration, MLS message handling, actor interfaces, UI-specific types).
This task aims to extract that logic into a clean, reusable Rust library (`hashgraph-like-consensus`),
exposing a well-defined public API and isolating the consensus engine from application concerns.
This enables:
* independent development, testing, and versioning of the consensus algorithm,
* support for reuse in other prototypes or benchmarking tools,
* cleaner integration in `de-mls`,
* better architectural separation between “consensus core” and “application layer.”
The new library should contain only the consensus logic and generic traits for persistence and callbacks,
with no dependency on Waku, Dioxus, or MLS-specific types.
#### Deliverables
* New Rust crate: https://github.com/vacp2p/hashgraph-like-consensus
* Migration of core logic from `de-mls` into the new crate:
* Public API definition & documentation:
* rustdoc for all public types/traits,
* `README.md` with architecture overview and simple usage example.
* Unit tests for core components,
* Integration in `de-mls`:
* replace internal module usage with the new crate,
* implement required traits (storage, observer) inside `de-mls`,
* ensure the app compiles and existing tests pass.
### Multi-steward integration
* fully qualified name: `vac:acz:ift:2025q4-de-mls-tesnet:multi-steward-integration`
* owner: Ekaterina
* status: in progress (5%)
* status: in progress (15%)
* start-date: 2025/10/01
* end-date: 2025/11/01

View File

@@ -25,7 +25,7 @@ we will also collect requirements and assess their suitability for IFT projects.
* fully qualified name: `vac:acz:ift:2025q4-discovery:draft-RFC`
* owner: Arunima
* status: in progress (70%)
* status: in progress (80%)
* start-date: 2025/10/01
* end-date: 2025/10/30
@@ -37,15 +37,15 @@ extracting key components such as the registrar and advisor and drafting them in
once the draft RFC is assembled, the task also includes preparing the final RFC
as a pull request by incorporating review feedback.
#### Deliverables
- [Draft RFC for Logos discovery capability](https://www.notion.so/RFC-Logos-Discovery-Capability-28a8f96fb65c80888df7fc0de13f1e22)
- [Logos discovery capability POC](https://github.com/vacp2p/logos-capability-discovery-poc/pull/1)
#### Deliverables
- [Draft RFC for Logos discovery capability](https://www.notion.so/RFC-Logos-Discovery-Capability-28a8f96fb65c80888df7fc0de13f1e22)
- [Logos discovery capability POC](https://github.com/vacp2p/logos-capability-discovery-poc/pull/1)
### Registrar Module
* fully qualified name: `vac:acz:ift:2025q4-discovery:registrar-module`
* owner: Arunima
* status: in progress (0%)
* status: in progress (20%)
* start-date: 2025/10/20
* end-date: 2025/10/27
@@ -69,7 +69,7 @@ with the network under enforced admission control rules.
* fully qualified name: `vac:acz:ift:2025q4-discovery:advertiser-module`
* owner: Arunima
* status: not started
* status: in progress (20%)
* start-date: 2025/10/27
* end-date: 2025/11/03
@@ -154,4 +154,4 @@ The task concludes with the merge of the PR.
#### Deliverables
* A PR to the [vacp2p/rfc-index](https://github.com/vacp2p/rfc-index/) repo.
* A PR to the [vacp2p/rfc-index](https://github.com/vacp2p/rfc-index/) repo.

View File

@@ -30,7 +30,7 @@ and the IFT.
* fully qualified name: `vac:acz:ift:2025q4-ift-zk-calls:ift-zk-call-1`
* owner: Marvin
* status: not started
* status: done
* start-date: 2025/10/01
* end-date: 2025/10/10
@@ -39,13 +39,15 @@ and the IFT.
Preparing the agenda and possible speakers for the ZK call on 7nd October.
#### Deliverables
* A document of a summary of the ZK call 1 meeting to a Notion page.
* A document of a summary of the ZK call 1 meeting to a [Notion page](https://www.notion.so/Past-Meeting-Notes-1198f96fb65c80e6a51afa9a507aa64e?source=copy_link#14d8f96fb65c80718ffed64f8d452732).
* [A recorded video. ](https://www.youtube.com/watch?v=W9TAODmAn-A)
* [A forum post.](https://forum.vac.dev/t/discussion-on-zk-verification/578)
### IFT ZK Call 2
* fully qualified name: `vac:acz:ift:2025q4-ift-zk-calls:ift-zk-call-2`
* owner: Ugur
* status: not started
* status: done
* start-date: 2025/11/01
* end-date: 2025/11/10
@@ -53,7 +55,7 @@ Preparing the agenda and possible speakers for the ZK call on 7nd October.
Preparing the agenda and possible speakers for the ZK call on 4th November.
#### Deliverables
* A document of a summary of the ZK call 2 meeting to a Notion page.
* A document of a summary of the ZK call 2 meeting to a [Notion page.](https://www.notion.so/Past-Meeting-Notes-1198f96fb65c80e6a51afa9a507aa64e?source=copy_link#2af8f96fb65c800cb1e2c0fc2eb2ea82)
### IFT ZK Call 3
* fully qualified name: `vac:acz:ift:2025q4-ift-zk-calls:ift-zk-call-3`

View File

@@ -35,7 +35,7 @@ In 2025q3, we released the RLN prover module with tracking module, tests, optimi
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:rln-spec-final`
* owner: Sylvain
* status: in progress (40%)
* status: in progress (60%)
* start-date: 2025/10/22
* end-date: 2025/11/03
@@ -50,7 +50,7 @@ and ready to the final implementation.
* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:maintaining`
* owner: Sylvain
* status: in progress (10%)
* status: in progress (40%)
* start-date: 2025/10/01
* end-date: 2025/02/30
@@ -201,7 +201,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 (60%)
* status: done
* start-date: 2025/10/13
* end-date: 2025/11/03
@@ -218,6 +218,7 @@ and is structured in a manner suitable for public presentation.
### Deliverables
* A doc on [Status Notion](https://www.notion.so/Status-Program-f6eef7b91ad94539babf66c26ea1cf02).
* [vac/rln Website](https://vac.dev/rln)
### SN RLN whitepaper

View File

@@ -31,7 +31,7 @@ In 2025q3, we released Zerokit v0.9.0, which supports improved CI, optimized, pa
* fully qualified name: `vac:acz:ift:2025q4-zerokit:zerokit-maintaining`
* owner: Ekaterina
* status: in progress (30%)
* status: in progress (40%)
* start-date: 2025/10/01
* end-date: 2025/12/30
@@ -45,7 +45,7 @@ A set of PRs and issues to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/).
* fully qualified name: `vac:acz:ift:2025q4-zerokit:wasm-ffi-rework`
* owner: Vinh
* status: in progress (30%)
* status: in progress (80%)
* start-date: 2025/11/03
* end-date: 2025/11/10
@@ -99,6 +99,36 @@ for memory safety and Big Endian compatibility.
- [Remove legacy FFI implementation in favor of safer opaque structs](https://github.com/vacp2p/zerokit/pull/337)
- A set of PRs and issues to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/).
### Public API Rework
* fully qualified name: `vac:acz:ift:2025q4-zerokit:public-api-rework`
* owner: Vinh
* status: in progress (50%)
* start-date: 2025/11/10
* end-date: 2025/11/24
#### Description
Right now the public Rust API exposes a lot of internal fields directly
and mixes stateless vs. non-stateless behavior in a confusing way.
There are also inconsistencies around how inputs are validated and how endianness works.
This makes mistakes easy and integration harder than it should be.
This task will clean up the API so that:
- The types are safe and self-consistent
- Stateless vs. non-stateless flows are clearly separated
- Endianness is explicit and correct
- Users get clear, simple functions for generating and verifying proofs
Overall goal: a clean, user-friendly public API with strong validation.
#### Deliverables
A PR to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/) that covers:
- Updated public API with constructors, fewer foot-guns
- Correct and explicit endianness support everywhere
- Working tests: Unit + integration, Stateless and non-stateless proof generation and verification
- Updated documentation & examples: show the intended workflows clearly
- Make all inner fields in structure private and add builder with sanity checks
### Release v1
* fully qualified name: `vac:acz:ift:2025q4-zerokit:release`