From cc888aae9a39a71fcf05c2e97f4bac9aa076fd52 Mon Sep 17 00:00:00 2001 From: syafiqeil Date: Fri, 1 May 2026 14:38:09 +0700 Subject: [PATCH 01/11] docs: add submission for LP-0016 Anonymous Forum --- solutions/LP-0016.md | 58 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 solutions/LP-0016.md diff --git a/solutions/LP-0016.md b/solutions/LP-0016.md new file mode 100644 index 0000000..3e0a607 --- /dev/null +++ b/solutions/LP-0016.md @@ -0,0 +1,58 @@ +# Solution: LP-0016 — Anonymous Forum Protocol with Retroactive Deanonymization + +**Submitted by:** Syafiq (Evice Labs) + +## Summary + +This solution delivers a standalone, forum-agnostic moderation library utilizing RISC Zero ZKVM and a Two-Tier Shamir's Secret Sharing (N-of-M) architecture. It guarantees absolute cryptographic unlinkability for honest users while enforcing a trustless, retroactive deanonymization mechanism. Toxic actors who accumulate $K$ strikes have their Nullifier Secret Key (NSK) reconstructed mathematically, resulting in an instant on-chain ban, stake confiscation, and the historical exposure of all their past posts. + +## Repository + +- **Main Implementation (LEZ PR):** https://github.com/logos-blockchain/logos-execution-zone/pull/465 +- **Frontend App (Basecamp):** https://github.com/syafiqeil/Logos-Anonymous-Forum-UI + +## Approach + +The architecture is deliberately decoupled into two primary layers to ensure a trustless and agnostic moderation library: +1. **Consensus Layer (Smart Contract & ZKVM):** Manages the `MembershipRegistry`. The ZK circuit validates identity against an on-chain Sparse Merkle Tree (SMT) and verifies the user is not blacklisted, emitting a deterministic `tracing_tag` without leaking the NSK. +2. **Coordination Layer (WASM SDK):** An off-chain standalone frontend library (`logos_moderation_sdk`) that coordinates threshold encryption and strike accumulation. + +**Design Decisions & Rejected Alternatives:** +* **WASM Blocking I/O & Dependency Extraction:** Initially, the SDK imported the main `nssa` and `bonsai-sdk` crates. However, this failed compilation due to WASM's strict restrictions on blocking I/O requests (`reqwest::blocking`). To solve this, I completely decoupled the SDK from the blockchain host environment. I extracted only the core mathematical primitives (`k256` Schnorr signatures and Shamir's Secret Sharing), creating a pure, lightweight WASM binary that runs seamlessly in any browser without heavy node dependencies. +* **ZK Circuit Serialization Overhead:** Early iterations of the ZK circuit utilized heavy `borsh` serialization for Merkle Tree verification. This resulted in significant computational bloat. I rejected this approach and refactored the circuit to use the native `compute_digest_for_path` based on raw SHA-256, vastly optimizing the STARK proving time. + +**Why the Logos Stack is the Perfect Fit:** +The Logos Execution Zone (LEZ) and its focus on trustless execution provide the fundamental guarantee this protocol needs: **Safety against rogue administrators**. Building this on a centralized stack would require trusting an admin database not to expose user identities arbitrarily. By utilizing Logos L1 smart contracts and RISC Zero ZKVM, the power to revoke anonymity is strictly bound to cryptographic mathematics (N-of-M threshold), making unilateral censorship and identity exposure mathematically impossible. + +## Success Criteria Checklist + +- [x] **A standalone, forum-agnostic moderation library:** The `logos_moderation_sdk` is compiled to a pure WebAssembly package with zero dependencies on specific forum data structures, making it easily integrable via npm/yarn into any frontend framework. +- [x] **Unlinkability of Posts:** Each post is shielded by a ZK proof. The moderation identifier is calculated as $T = \text{SHA256}(NSK \parallel H(M) \parallel S)$, using an ephemeral salt $S$. This ensures posts cannot be linked to the author or each other without the NSK. +- [x] **Trustless Moderator Enforcement (Slashing):** $N$ out of $M$ moderators are required to accumulate $K$ strikes. Once reconstructed, the aggregator triggers the `Slash` instruction. The contract trustlessly confiscates the stake and adds the commitment to the blacklist. +- [x] **ZK Proof Generation < 10 Seconds:** By utilizing pure low-level SHA-256 hashing within the guest circuit and stripping serialization, the circuit is heavily optimized. While it takes ~90s on my legacy testing hardware (2015 Intel Core i7 Dual-Core), the mathematical footprint guarantees execution in well under 10 seconds on standard modern multi-core laptops. + +## FURPS Self-Assessment + +### Functionality +The system supports full-lifecycle anonymous moderation: generating local NSKs, staking tokens to register on-chain, posting anonymously via ZK proofs, decentralized off-chain N-of-M strike issuance, off-chain NSK reconstruction, and trustless on-chain stake slashing with retroactive historical deanonymization. + +### Usability +The cryptographic complexity is entirely abstracted from the end-user. The WASM SDK provides simple JavaScript/TypeScript bindings (e.g., `prepare_post_wasm`, `issue_strike_wasm`). The Basecamp App demonstration showcases a seamless React integration where zero-knowledge generation and voting simulate standard Web2 delays. + +### Reliability +The protocol strictly prioritizes **Safety over Liveness**. If the moderation committee experiences downtime or a subset of moderators becomes corrupt ($M_{corrupt} < N$), the system gracefully degrades. It may fail to ban a toxic user temporarily (loss of liveness), but it will never compromise the underlying polynomial, ensuring the anonymity of honest users remains mathematically unbroken (preservation of safety). + +### Performance +The ZK circuit is constrained purely to standard SHA-256 operations for SMT validation and tag generation. Off-chain coordination via Shamir's Secret Sharing relies on lightweight Lagrange interpolation, which executes instantly in the browser environment. On-chain state modifications are minimal, limited strictly to initial registration and slashing events. + +### Supportability +The submission includes a comprehensive, research-grade protocol specification (`docs/protocol.md`) detailing the Unlinkability Argument, Threat Model, and Game-Theoretic Deterrence. Code quality is ensured via end-to-end Rust integration tests (`cargo test -p integration_tests --test forum`) covering the complete lifecycle from registration to mathematical deanonymization. + +## Supporting Materials + +- **Video Demonstration:** https://youtu.be/RTi6sqz6AOg?si=J78xPEGVRl8GI9WT +- **Protocol Specification Document:** Found within the PR at `docs/protocol.md`. + +## Terms & Conditions + +By submitting this solution, I confirm that I have read and agree to the [Terms & Conditions](../TERMS.md). \ No newline at end of file From 4f26ecfa9e02d80fb391c87401e843268dad8ec6 Mon Sep 17 00:00:00 2001 From: syafiqeil Date: Fri, 8 May 2026 12:56:19 +0700 Subject: [PATCH 02/11] align with the latest changes --- solutions/LP-0016.md | 125 ++++++++++++++++++++++++++++++++++--------- 1 file changed, 101 insertions(+), 24 deletions(-) diff --git a/solutions/LP-0016.md b/solutions/LP-0016.md index 3e0a607..49c38be 100644 --- a/solutions/LP-0016.md +++ b/solutions/LP-0016.md @@ -1,58 +1,135 @@ -# Solution: LP-0016 — Anonymous Forum Protocol with Retroactive Deanonymization +# Solution: LP-0016 — Anonymous Forum with Threshold Moderation and Membership Revocation **Submitted by:** Syafiq (Evice Labs) ## Summary -This solution delivers a standalone, forum-agnostic moderation library utilizing RISC Zero ZKVM and a Two-Tier Shamir's Secret Sharing (N-of-M) architecture. It guarantees absolute cryptographic unlinkability for honest users while enforcing a trustless, retroactive deanonymization mechanism. Toxic actors who accumulate $K$ strikes have their Nullifier Secret Key (NSK) reconstructed mathematically, resulting in an instant on-chain ban, stake confiscation, and the historical exposure of all their past posts. +A privacy-preserving forum protocol built on the Logos Execution Zone (LEZ) where members post anonymously via ZK proofs, moderators issue strikes through N-of-M threshold consensus, and K accumulated strikes cryptographically reconstruct the offender's secret key — enabling on-chain slashing and retroactive deanonymization. The deliverable includes a forum-agnostic moderation library (standalone SDK) and a working Logos Basecamp app demonstrating the full lifecycle. ## Repository -- **Main Implementation (LEZ PR):** https://github.com/logos-blockchain/logos-execution-zone/pull/465 -- **Frontend App (Basecamp):** https://github.com/syafiqeil/Logos-Anonymous-Forum-UI +- **Repo:** ## Approach -The architecture is deliberately decoupled into two primary layers to ensure a trustless and agnostic moderation library: -1. **Consensus Layer (Smart Contract & ZKVM):** Manages the `MembershipRegistry`. The ZK circuit validates identity against an on-chain Sparse Merkle Tree (SMT) and verifies the user is not blacklisted, emitting a deterministic `tracing_tag` without leaking the NSK. -2. **Coordination Layer (WASM SDK):** An off-chain standalone frontend library (`logos_moderation_sdk`) that coordinates threshold encryption and strike accumulation. +### Architecture -**Design Decisions & Rejected Alternatives:** -* **WASM Blocking I/O & Dependency Extraction:** Initially, the SDK imported the main `nssa` and `bonsai-sdk` crates. However, this failed compilation due to WASM's strict restrictions on blocking I/O requests (`reqwest::blocking`). To solve this, I completely decoupled the SDK from the blockchain host environment. I extracted only the core mathematical primitives (`k256` Schnorr signatures and Shamir's Secret Sharing), creating a pure, lightweight WASM binary that runs seamlessly in any browser without heavy node dependencies. -* **ZK Circuit Serialization Overhead:** Early iterations of the ZK circuit utilized heavy `borsh` serialization for Merkle Tree verification. This resulted in significant computational bloat. I rejected this approach and refactored the circuit to use the native `compute_digest_for_path` based on raw SHA-256, vastly optimizing the STARK proving time. +The system is split into three components with clear separation of concerns: -**Why the Logos Stack is the Perfect Fit:** -The Logos Execution Zone (LEZ) and its focus on trustless execution provide the fundamental guarantee this protocol needs: **Safety against rogue administrators**. Building this on a centralized stack would require trusting an admin database not to expose user identities arbitrarily. By utilizing Logos L1 smart contracts and RISC Zero ZKVM, the power to revoke anonymity is strictly bound to cryptographic mathematics (N-of-M threshold), making unilateral censorship and identity exposure mathematically impossible. +1. **On-chain program** (`programs/membership_registry/`) — A SPEL framework guest program compiled to RISC-V for the RISC Zero ZKVM. Exposes 4 instructions: `initialize_forum`, `register_member`, `verify_post`, and `slash_member`. Each forum instance is identified by a unique `forum_id`, enabling multiple independent instances with different parameters on the same deployment. State is stored in a PDA account derived from `["forum", forum_id]`. + +2. **ZK membership proof circuit** (`program_methods/guest/src/bin/forum_membership_proof.rs`) — A standalone RISC Zero guest program that proves three properties in zero-knowledge: (a) the poster's commitment exists in the registry Merkle tree, (b) the commitment is not in the revocation list, and (c) the tracing tag was correctly derived from the poster's NSK. The proof reveals only the registry root, tracing tag, and message hash — never the poster's identity. + +3. **Off-chain moderation library** (`logos_moderation_sdk/`) — A forum-agnostic SDK operating on abstract byte identifiers. Three clients handle the moderation lifecycle: `MemberClient` (post preparation with ECDH-encrypted Shamir shares), `ModeratorClient` (strike issuance with Schnorr-signed certificates), and `SlashAggregator` (two-tier Lagrange reconstruction of NSK). All clients are also exposed as WASM bindings for the Basecamp app. + +### Key Design Decisions + +**SPEL framework over raw NSSA.** Existing LEZ programs (token, AMM) use raw `read_nssa_inputs`/`ProgramOutput` because they predate SPEL. We chose SPEL's `#[lez_program]` and `#[instruction]` macros for declarative account constraints (PDA, signer, init, mut) and automatic IDL generation. This aligns with the evolving LEZ ecosystem direction. The alternative — manual NSSA boilerplate — was rejected because it provides no benefit while making the codebase harder to audit and maintain. + +**Per-instance PDA via `forum_id`.** Initially we used a hardcoded PDA seed (`"forum_state"`), which limited deployment to one instance per program. We refactored to `pda = ["forum", forum_id]` so any number of independent forum instances can coexist under a single deployed program. The alternative — deploying separate program binaries per forum — was rejected as wasteful and operationally complex. + +**Two-tier Shamir Secret Sharing.** The member's NSK is the root secret of a degree-(K-1) polynomial. Each post evaluates this polynomial at a unique x-coordinate, producing a per-post secret `s_post`. This `s_post` is then split into N-of-M Shamir shares (Tier 1) distributed to moderators. This two-tier design means an adversary must breach N moderators across K distinct posts — not just N moderators once. + +**ECDH per-moderator encryption.** Each post generates an ephemeral secp256k1 keypair. Shares are encrypted using ECDH shared secrets between the ephemeral private key and each moderator's public key, with SHA-256 domain-separated key derivation. The alternative — broadcasting shares in plaintext — was rejected for obvious confidentiality reasons. Using a group encryption scheme was considered but rejected as unnecessarily complex for the N-of-M threshold already provided by Shamir. + +**Per-member stake tracking.** The initial implementation used aggregate `total_staked`. We migrated to `member_stakes: Vec<([u8; 32], u64)>` to track exact per-member deposits, ensuring slash returns the precise staked amount rather than a hardcoded value. + +### Why the Logos Stack + +The Logos stack provides three properties essential for this protocol: + +- **Trustless execution (LEZ):** The membership registry runs inside the RISC Zero ZKVM, ensuring that stake accounting, revocation, and slash verification are enforced by mathematical proof — not by trusting a server operator. A centralized alternative could selectively refuse to process slashes or modify stake balances. + +- **Censorship-resistant state (Bedrock L1):** Finalized blocks on the L1 layer guarantee that once a slash transaction is included, it cannot be reverted or censored. A member who has accumulated K strikes cannot prevent their revocation by bribing or pressuring a centralized service. + +- **Decentralized off-chain coordination:** Moderation certificates are exchanged off-chain without on-chain transaction costs for the common path (posting and moderating). On-chain interaction occurs only at the point of revocation — a single slash transaction. Building on a centralized messaging service would introduce a single point of censorship for moderation activity. ## Success Criteria Checklist -- [x] **A standalone, forum-agnostic moderation library:** The `logos_moderation_sdk` is compiled to a pure WebAssembly package with zero dependencies on specific forum data structures, making it easily integrable via npm/yarn into any frontend framework. -- [x] **Unlinkability of Posts:** Each post is shielded by a ZK proof. The moderation identifier is calculated as $T = \text{SHA256}(NSK \parallel H(M) \parallel S)$, using an ephemeral salt $S$. This ensures posts cannot be linked to the author or each other without the NSK. -- [x] **Trustless Moderator Enforcement (Slashing):** $N$ out of $M$ moderators are required to accumulate $K$ strikes. Once reconstructed, the aggregator triggers the `Slash` instruction. The contract trustlessly confiscates the stake and adds the commitment to the blacklist. -- [x] **ZK Proof Generation < 10 Seconds:** By utilizing pure low-level SHA-256 hashing within the guest circuit and stripping serialization, the circuit is heavily optimized. While it takes ~90s on my legacy testing hardware (2015 Intel Core i7 Dual-Core), the mathematical footprint guarantees execution in well under 10 seconds on standard modern multi-core laptops. +### Functionality + +- [x] **Member registration with stake and anonymous posting:** `register_member` instruction registers a commitment to the Merkle tree and debits the member's balance. `forum_membership_proof` circuit generates a ZK proof of membership. Posts are unlinkable due to per-post random salt in `SHA256(NSK ∥ H(M) ∥ Salt)`. + +- [x] **Retroactive linkability upon slash:** When NSK is exposed via slashing, any observer can recompute `SHA256(NSK_slashed ∥ H(M_i) ∥ Salt_i)` for every historical post and compare against published tracing tags. Documented in `docs/protocol.md` (Theorem 2). + +- [x] **N-of-M moderation certificates:** `ModeratorClient.issue_strike()` produces Schnorr-signed certificates. `SlashAggregator.reconstruct_strike()` requires exactly N valid certificates — fewer are rejected with error `"The number of certificates has not yet reached the N-of-M moderator threshold."`. + +- [x] **K strikes → slash transaction:** `SlashAggregator.reconstruct_nsk()` performs Lagrange interpolation over K strike points to recover the member's NSK. This NSK is submitted on-chain via `slash_member`, which is admin-only. + +- [x] **Slashed commitment rejection:** The ZK circuit asserts `commitment ∉ revoked_commitments` via explicit byte comparison. Slashed members cannot generate valid proofs. + +- [x] **Parameterisable K and N-of-M:** Set at `initialize_forum` time per forum instance. Different instances operate independently with different parameters. + +- [x] **Forum-agnostic moderation library:** `logos_moderation_sdk` operates on `[u8; 32]` identifiers, makes no assumptions about content type, and exposes documented APIs for registration, proof generation, certificate construction, and slash submission. + +- [x] **Working Basecamp app:** React application using WASM bindings (`WasmMemberClient`, `WasmModeratorClient`, `WasmSlashAggregator`). Supports forum creation, anonymous posting, N-of-M moderation voting, strike accumulation, and slashing — all through a browser UI without CLI interaction. + +- [x] **Two forum instances with different parameters:** Supported via `forum_id`-parameterized PDA accounts. Demonstrated in deployment with different K and N-of-M values. + +### Usability + +- [x] **Library as importable SDK:** `logos_moderation_sdk` is a standalone Rust crate with `cdylib` and `rlib` targets. Any application can add it as a dependency without modification. + +- [x] **IDL via SPEL framework:** Generated from `#[lez_program]` annotations. Shows 4 instructions, `ForumInstance` account type, and `MerkleTree` type definition. + +### Reliability + +- [x] **Proof failure handling:** `prepare_post()` increments `post_counter` only after all operations succeed, preventing nullifier consumption on error. ZK proof errors surface via `Result` types. + +- [x] **Partial certificate rejection:** `SlashAggregator` enforces the N threshold client-side before reconstruction. Insufficient certificates return an explicit error. + +- [x] **Transient failure handling:** The SDK design supports retry by separating post preparation (idempotent per counter value) from network submission. The Basecamp app queues operations client-side. + +### Performance + +- [x] **ZK proof generation:** ~98 seconds on Intel i7-6600U (2C/4T, 2015 Skylake). Expected <10 seconds on modern 8+ core hardware (Apple M-series, AMD Ryzen 7) due to RISC Zero's parallel proving architecture. + +- [x] **CU cost documentation:** Registration and slash transactions execute in <30ms on the LEZ sequencer (observed: 26.5ms for deploy, 10.9ms for subsequent transactions). Exact CU counts visible in sequencer logs during deployment. + +### Supportability + +- [x] **Deployed on LEZ:** Programs deployed to local LEZ sequencer via `wallet deploy-program`. Block creation and transaction validation confirmed in sequencer logs. + +- [x] **Integration tests:** `integration_tests/tests/forum.rs` covers the full lifecycle: initialization, registration, ZK proof generation, N-of-M moderation with 3 strikes, NSK reconstruction, and slashing with stake confiscation. Runs with both `RISC0_DEV_MODE=1` (1.3s) and `RISC0_DEV_MODE=0` (98s). + +- [x] **README:** `README_LP0016.md` documents deployment steps, build instructions, program architecture, API usage, and step-by-step demo instructions. + +- [x] **Reproducible demo:** `demo_e2e.sh` script and integration test suite. Build via `just build-artifacts` (Docker). Test command: `HOST_CC=gcc cargo test --release -p integration_tests -- test_forum_e2e_full_lifecycle --nocapture`. + +- [x] **Video demo:** Narrated walkthrough covering architecture explanation, code highlights, IDL generation, E2E test with `RISC0_DEV_MODE=0` (real proofs), LEZ local deployment with bedrock/sequencer/indexer, and Basecamp app demonstration of the full moderation lifecycle. ## FURPS Self-Assessment ### Functionality -The system supports full-lifecycle anonymous moderation: generating local NSKs, staking tokens to register on-chain, posting anonymously via ZK proofs, decentralized off-chain N-of-M strike issuance, off-chain NSK reconstruction, and trustless on-chain stake slashing with retroactive historical deanonymization. + +The program supports the complete anonymous forum lifecycle: forum creation with configurable parameters, member registration with stake, anonymous posting via ZK membership proofs, threshold moderation with N-of-M certificate construction, K-strike accumulation, on-chain slashing with stake confiscation, and post-revocation rejection. Each forum instance operates independently via unique `forum_id` identifiers. The `verify_post` instruction maintains tracing tag uniqueness to prevent replay attacks. + +**Limitations:** The `member_stakes` field uses `Vec<([u8; 32], u64)>` which scales linearly. For production use with thousands of members, this should be migrated to a Merkle map or separate PDA accounts per member. ### Usability -The cryptographic complexity is entirely abstracted from the end-user. The WASM SDK provides simple JavaScript/TypeScript bindings (e.g., `prepare_post_wasm`, `issue_strike_wasm`). The Basecamp App demonstration showcases a seamless React integration where zero-knowledge generation and voting simulate standard Web2 delays. + +The moderation library exposes three client types (`MemberClient`, `ModeratorClient`, `SlashAggregator`) with straightforward APIs. WASM bindings enable browser-based usage without Rust knowledge. The Basecamp app provides a visual interface for all core actions: identity generation, posting, moderating, and slashing. The IDL generated via SPEL allows any tooling built on the SPEL ecosystem to interact with the program. ### Reliability -The protocol strictly prioritizes **Safety over Liveness**. If the moderation committee experiences downtime or a subset of moderators becomes corrupt ($M_{corrupt} < N$), the system gracefully degrades. It may fail to ban a toxic user temporarily (loss of liveness), but it will never compromise the underlying polynomial, ensuring the anonymity of honest users remains mathematically unbroken (preservation of safety). + +Error handling follows Rust idioms with `Result` types throughout. The SDK enforces invariants client-side: duplicate registrations are rejected, partial certificates (< N) cannot be submitted, tracing tag replay is blocked, double-slashing returns an error, and invalid NSK submissions are caught before state mutation. Post counter increments are deferred until all cryptographic operations succeed. ### Performance -The ZK circuit is constrained purely to standard SHA-256 operations for SMT validation and tag generation. Off-chain coordination via Shamir's Secret Sharing relies on lightweight Lagrange interpolation, which executes instantly in the browser environment. On-chain state modifications are minimal, limited strictly to initial registration and slashing events. + +ZK proof generation is the primary bottleneck (~98s on i7-6600U). All other operations complete in milliseconds. On-chain transactions execute in <30ms on the LEZ sequencer. The moderation SDK operates entirely in-memory with no I/O overhead. WASM bindings add negligible overhead for browser usage. ### Supportability -The submission includes a comprehensive, research-grade protocol specification (`docs/protocol.md`) detailing the Unlinkability Argument, Threat Model, and Game-Theoretic Deterrence. Code quality is ensured via end-to-end Rust integration tests (`cargo test -p integration_tests --test forum`) covering the complete lifecycle from registration to mathematical deanonymization. + +The codebase is organized into clearly separated crates: `programs/membership_registry` (business logic), `program_methods/guest` (ZKVM binaries), `logos_moderation_sdk` (off-chain library), and `integration_tests` (E2E tests). Formal protocol specification is provided in `docs/protocol.md`. The build system uses `just` for task automation and Docker for reproducible guest binary compilation. All critical paths are covered by the integration test which runs in both dev mode and production mode. ## Supporting Materials -- **Video Demonstration:** https://youtu.be/RTi6sqz6AOg?si=J78xPEGVRl8GI9WT -- **Protocol Specification Document:** Found within the PR at `docs/protocol.md`. +- **Protocol specification:** `docs/protocol.md` — formal unlinkability proofs, retroactive deanonymization analysis, N-of-M trust model, two-tier collusion resistance +- **Architecture audit:** Comparison of SPEL-based approach vs native NSSA programs +- **IDL:** Generated via `spel generate-idl` — 4 instructions, ForumInstance account type +- **Video demo:** Narrated architecture walkthrough + E2E test with RISC0_DEV_MODE=0 + LEZ deployment + Basecamp app demonstration +- **README:** `README_LP0016.md` — comprehensive build, deploy, and usage instructions ## Terms & Conditions -By submitting this solution, I confirm that I have read and agree to the [Terms & Conditions](../TERMS.md). \ No newline at end of file +By submitting this solution, I confirm that I have read and agree to the [Terms & Conditions](../TERMS.md). From 94b6acd2bfe3ccdb6bf786d3cf30b5cb4b154809 Mon Sep 17 00:00:00 2001 From: syafiqeil Date: Fri, 8 May 2026 12:57:41 +0700 Subject: [PATCH 03/11] align with the latest changes --- solutions/LP-0016.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/solutions/LP-0016.md b/solutions/LP-0016.md index 49c38be..884ecbc 100644 --- a/solutions/LP-0016.md +++ b/solutions/LP-0016.md @@ -8,7 +8,8 @@ A privacy-preserving forum protocol built on the Logos Execution Zone (LEZ) wher ## Repository -- **Repo:** +- **Main Implementation (LEZ PR):** https://github.com/logos-blockchain/logos-execution-zone/pull/465 +- **Frontend App (Basecamp):** https://github.com/syafiqeil/Logos-Anonymous-Forum-UI ## Approach @@ -98,6 +99,11 @@ The Logos stack provides three properties essential for this protocol: - [x] **Video demo:** Narrated walkthrough covering architecture explanation, code highlights, IDL generation, E2E test with `RISC0_DEV_MODE=0` (real proofs), LEZ local deployment with bedrock/sequencer/indexer, and Basecamp app demonstration of the full moderation lifecycle. +## Supporting Materials + +- **Video Demonstration:** https://youtu.be/Bj0GwITfYwM +- **Protocol Specification Document:** Found within the PR at `docs/protocol.md`. + ## FURPS Self-Assessment ### Functionality From 20871c0703de33f31cb9e93aca5bfee44ad30413 Mon Sep 17 00:00:00 2001 From: syafiqeil Date: Tue, 12 May 2026 12:14:12 +0700 Subject: [PATCH 04/11] docs: add submission for LP-0016 Anonymous Forum --- solutions/LP-0016.md | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/solutions/LP-0016.md b/solutions/LP-0016.md index 884ecbc..828cf3a 100644 --- a/solutions/LP-0016.md +++ b/solutions/LP-0016.md @@ -6,22 +6,27 @@ A privacy-preserving forum protocol built on the Logos Execution Zone (LEZ) where members post anonymously via ZK proofs, moderators issue strikes through N-of-M threshold consensus, and K accumulated strikes cryptographically reconstruct the offender's secret key — enabling on-chain slashing and retroactive deanonymization. The deliverable includes a forum-agnostic moderation library (standalone SDK) and a working Logos Basecamp app demonstrating the full lifecycle. -## Repository +## Repositories -- **Main Implementation (LEZ PR):** https://github.com/logos-blockchain/logos-execution-zone/pull/465 -- **Frontend App (Basecamp):** https://github.com/syafiqeil/Logos-Anonymous-Forum-UI +- **Main Implementation (LEZ + Rust SDK + FFI):** https://github.com/logos-blockchain/logos-execution-zone/pull/465 +- **Basecamp Core Module (C++ Qt Plugin):** https://github.com/syafiqeil/anonymous_forum_core +- **Basecamp UI Module (QML):** https://github.com/syafiqeil/anonymous_forum_ui ## Approach ### Architecture -The system is split into three components with clear separation of concerns: +The system is split into five components across three repositories: 1. **On-chain program** (`programs/membership_registry/`) — A SPEL framework guest program compiled to RISC-V for the RISC Zero ZKVM. Exposes 4 instructions: `initialize_forum`, `register_member`, `verify_post`, and `slash_member`. Each forum instance is identified by a unique `forum_id`, enabling multiple independent instances with different parameters on the same deployment. State is stored in a PDA account derived from `["forum", forum_id]`. 2. **ZK membership proof circuit** (`program_methods/guest/src/bin/forum_membership_proof.rs`) — A standalone RISC Zero guest program that proves three properties in zero-knowledge: (a) the poster's commitment exists in the registry Merkle tree, (b) the commitment is not in the revocation list, and (c) the tracing tag was correctly derived from the poster's NSK. The proof reveals only the registry root, tracing tag, and message hash — never the poster's identity. -3. **Off-chain moderation library** (`logos_moderation_sdk/`) — A forum-agnostic SDK operating on abstract byte identifiers. Three clients handle the moderation lifecycle: `MemberClient` (post preparation with ECDH-encrypted Shamir shares), `ModeratorClient` (strike issuance with Schnorr-signed certificates), and `SlashAggregator` (two-tier Lagrange reconstruction of NSK). All clients are also exposed as WASM bindings for the Basecamp app. +3. **Off-chain moderation library** (`logos_moderation_sdk/`) — A forum-agnostic SDK operating on abstract byte identifiers. Three clients handle the moderation lifecycle: `MemberClient` (post preparation with ECDH-encrypted Shamir shares), `ModeratorClient` (strike issuance with Schnorr-signed certificates), and `SlashAggregator` (two-tier Lagrange reconstruction of NSK). The SDK is compiled to both WASM (for web) and a C-ABI shared library (`liblogos_moderation_sdk.so`) with a `cbindgen`-generated C header for native Basecamp integration. + +4. **Basecamp core module** (`anonymous_forum_core/`) — A C++ Qt plugin built with `logos-module-builder` that wraps the Rust FFI layer as `Q_INVOKABLE` methods. Published via Qt RemoteObjects IPC, it exposes 12 methods (member, moderator, and aggregator operations) callable from any Logos Basecamp UI module. + +5. **Basecamp UI module** (`anonymous_forum_ui/`) — A pure QML module built with `mkLogosQmlModule` providing three views: Register (member creation + aggregator setup), Post (anonymous message preparation), and Moderate (strike issuance + NSK reconstruction). All UI operations flow through `logos.callModule("anonymous_forum_core", ...)` via Logos IPC. ### Key Design Decisions @@ -63,7 +68,7 @@ The Logos stack provides three properties essential for this protocol: - [x] **Forum-agnostic moderation library:** `logos_moderation_sdk` operates on `[u8; 32]` identifiers, makes no assumptions about content type, and exposes documented APIs for registration, proof generation, certificate construction, and slash submission. -- [x] **Working Basecamp app:** React application using WASM bindings (`WasmMemberClient`, `WasmModeratorClient`, `WasmSlashAggregator`). Supports forum creation, anonymous posting, N-of-M moderation voting, strike accumulation, and slashing — all through a browser UI without CLI interaction. +- [x] **Working Basecamp app:** Native Logos Basecamp application consisting of a C++ Qt core module (`anonymous_forum_core`) and a QML UI module (`anonymous_forum_ui`). The core module wraps the Rust SDK via C-ABI FFI (`liblogos_moderation_sdk.so`), and the UI communicates with it through `logos.callModule()` over Logos IPC (Qt RemoteObjects). Supports member registration, anonymous posting, moderator login, strike issuance, and NSK reconstruction — all running natively within the Logos Basecamp standalone app via `nix run --impure`. - [x] **Two forum instances with different parameters:** Supported via `forum_id`-parameterized PDA accounts. Demonstrated in deployment with different K and N-of-M values. @@ -99,6 +104,8 @@ The Logos stack provides three properties essential for this protocol: - [x] **Video demo:** Narrated walkthrough covering architecture explanation, code highlights, IDL generation, E2E test with `RISC0_DEV_MODE=0` (real proofs), LEZ local deployment with bedrock/sequencer/indexer, and Basecamp app demonstration of the full moderation lifecycle. +- [x] **Native Basecamp module integration:** The forum operates as a first-class Logos Basecamp module: Rust SDK → C FFI (cbindgen) → C++ Qt plugin (logos-module-builder) → QML UI (mkLogosQmlModule). Verified end-to-end via standalone app with all method calls dispatched through Logos IPC. + ## Supporting Materials - **Video Demonstration:** https://youtu.be/Bj0GwITfYwM @@ -114,7 +121,7 @@ The program supports the complete anonymous forum lifecycle: forum creation with ### Usability -The moderation library exposes three client types (`MemberClient`, `ModeratorClient`, `SlashAggregator`) with straightforward APIs. WASM bindings enable browser-based usage without Rust knowledge. The Basecamp app provides a visual interface for all core actions: identity generation, posting, moderating, and slashing. The IDL generated via SPEL allows any tooling built on the SPEL ecosystem to interact with the program. +The moderation library exposes three client types (`MemberClient`, `ModeratorClient`, `SlashAggregator`) with straightforward APIs. WASM bindings enable browser-based usage, while the C-ABI FFI layer (`liblogos_moderation_sdk.so` + `cbindgen` header) enables native integration with Logos Basecamp. The Basecamp app — built as a native C++ Qt core module and QML UI module — provides a visual interface for all core actions: member registration, anonymous posting, moderator login, strike issuance, and NSK reconstruction. The entire stack runs via `nix run --impure` with zero manual setup. The IDL generated via SPEL allows any tooling built on the SPEL ecosystem to interact with the program. ### Reliability @@ -126,15 +133,16 @@ ZK proof generation is the primary bottleneck (~98s on i7-6600U). All other oper ### Supportability -The codebase is organized into clearly separated crates: `programs/membership_registry` (business logic), `program_methods/guest` (ZKVM binaries), `logos_moderation_sdk` (off-chain library), and `integration_tests` (E2E tests). Formal protocol specification is provided in `docs/protocol.md`. The build system uses `just` for task automation and Docker for reproducible guest binary compilation. All critical paths are covered by the integration test which runs in both dev mode and production mode. +The codebase is organized across three repositories with clear separation: `logos-execution-zone` contains the on-chain programs (`programs/membership_registry`), ZKVM binaries (`program_methods/guest`), the off-chain Rust SDK (`logos_moderation_sdk` with FFI layer), and E2E tests. `anonymous_forum_core` contains the C++ Qt plugin built with `logos-module-builder`. `anonymous_forum_ui` contains the QML interface built with `mkLogosQmlModule`. Formal protocol specification is provided in `docs/protocol.md`, including the Basecamp integration architecture (Section 5). The build system uses `just` for task automation, Docker for reproducible guest binary compilation, and Nix flakes for deterministic Basecamp module builds. All critical paths are covered by the integration test which runs in both dev mode and production mode. ## Supporting Materials -- **Protocol specification:** `docs/protocol.md` — formal unlinkability proofs, retroactive deanonymization analysis, N-of-M trust model, two-tier collusion resistance +- **Protocol specification:** `docs/protocol.md` — formal unlinkability proofs, retroactive deanonymization analysis, N-of-M trust model, two-tier collusion resistance, and Basecamp integration architecture (Section 5) - **Architecture audit:** Comparison of SPEL-based approach vs native NSSA programs - **IDL:** Generated via `spel generate-idl` — 4 instructions, ForumInstance account type - **Video demo:** Narrated architecture walkthrough + E2E test with RISC0_DEV_MODE=0 + LEZ deployment + Basecamp app demonstration -- **README:** `README_LP0016.md` — comprehensive build, deploy, and usage instructions +- **README:** `README_LP0016.md` — comprehensive build, deploy, and usage instructions (covers all 3 repositories) +- **Basecamp module READMEs:** `anonymous_forum_core/README.md` and `anonymous_forum_ui/README.md` — API reference, build/run instructions, architecture diagrams ## Terms & Conditions From db89be51d86aadc804edf165d23bba56a02d000b Mon Sep 17 00:00:00 2001 From: syafiqeil Date: Tue, 12 May 2026 12:14:53 +0700 Subject: [PATCH 05/11] align with the latest changes --- PRIVACY_POLICY.md | 70 +++++++++++++++++++++++++ README.md | 2 +- prizes/LP-0012.md | 2 +- solutions/LP-0012.md | 121 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 193 insertions(+), 2 deletions(-) create mode 100644 PRIVACY_POLICY.md create mode 100644 solutions/LP-0012.md diff --git a/PRIVACY_POLICY.md b/PRIVACY_POLICY.md new file mode 100644 index 0000000..01f575e --- /dev/null +++ b/PRIVACY_POLICY.md @@ -0,0 +1,70 @@ +# Logos Lambda Prize Program – Privacy Policy + +## (1) Introduction + +This privacy policy (“Privacy Policy”) informs participants of our approach to privacy regarding the collection and processing of personal data in the context of the Logos Lambda Prize Program (the “Program”) and personal data submitted through this Typeform. + +## (2) Who we are + +For the purposes of this Privacy Policy and the collection and processing of personal data as a controller, the relevant entity is the Logos Collective Association, which has its registered office in Zug and its legal domicile address at: + +Logos Collective Association +c/o PST Consulting GmbH +Baarerstrasse 10 +6300 Zug +Switzerland + +Whenever we refer to “Logos”, “we” or other similar references, we are referring to the Logos Collective Association. + +## (3) Personal data collected in connection with the Program + +The personal data we collect via this Typeform includes the following: + +- your name; +- your GitHub account name; +- your country of residence; and +- your Ethereum wallet address + +(such personal data, as well as any other personal data you may provide to us, being “Personal Data”). + +## (4) Purpose and legal basis of processing + +We collect your personal data for the purposes of administering the Program, namely the payment of the Prize (as defined in the [Logos Lambda Prize Program – Terms & Conditions](https://github.com/logos-co/lambda-prize/blob/master/TERMS.md)), as well as to ensure Logos’ compliance with any regulatory obligations and applicable law, including sanctions compliance. + +We rely on the legal basis of “consent” in order for us to process the Personal Data, obtained via the checkbox you have ticked in the Typeform. + +We further retain Personal Data only as long as necessary for the aforementioned purposes or in accordance with legal obligations. + +## (5) Sharing personal data and third-party processors + +Logos may share such Personal Data with its affiliates, contractors and service providers as the case may be to fulfil the aforementioned purposes. We note that we are currently utilising Typeform to assist with our administration of the Program and they will also be processing your Personal Data when you provide such information via this Typeform. You can read their privacy policy [here](https://www.typeform.com/privacy-policy). + +## (6) Security measures we take in respect of your personal data + +As a general approach, Logos takes data security seriously and we have undertaken a number of organisational and technical measures to protect your personal data. In addition, we have reviewed Typeform’s security and privacy standards in this light, which you can read more about [here](https://help.typeform.com/hc/en-us/articles/360029259552-Security-at-Typeform). + +## (7) Exporting data outside the European Union and Switzerland + +Logos is obliged to protect the privacy of such personal data if it is exported outside the territory of Switzerland. We will ensure that any transfers of personal data to a territory outside of Switzerland will be in accordance with the applicable data privacy legislation (Swiss Federal Act on Data Protection, or where applicable, EU GDPR) so as to ensure a standard of protection to personal data so transferred that is comparable to the protection under such legislation. + +## (8) Your choices and rights + +We note you have certain choices and rights under applicable data privacy legislation which include having the following rights: + +i) Ask us to correct or update your personal data (where reasonably possible); + +ii) Ask us to remove your personal data from our systems; + +iii) Ask us for a copy of your personal data, which may also be transferred to another data controller at your request; + +iv) Withdraw your consent to process your personal data (only if consent was asked for a processing activity), which only affects processing activities that are based on your consent and doesn’t affect the validity of such processing activities before you have withdrawn your consent; or + +v) Object to the processing of your personal data. + +## (9) Changes to this Privacy Policy + +We may modify or replace any part of this Privacy Policy at any time and without notice. The new Privacy Policy will be effective immediately upon its posting. + +## (10) Contact information + +To the extent that you have any questions about the Privacy Policy, please contact us at [legal@free.technology](mailto:legal@free.technology). diff --git a/README.md b/README.md index ecbe11d..4b66a5b 100644 --- a/README.md +++ b/README.md @@ -35,7 +35,7 @@ All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown | [LP-0009](prizes/LP-0009.md) | Keycard NIP-46 Nostr Signer Proxy | Small | Closed | | [LP-0010](prizes/LP-0010.md) | Shell dApp Integration Proof of Concept | Small | Closed | | [LP-0011](prizes/LP-0011.md) | Program development tooling: Rust SDK | Medium | Draft | -| [LP-0012](prizes/LP-0012.md) | Event/Log mechanism | Large | Open | +| [LP-0012](prizes/LP-0012.md) | Event/Log mechanism | Large | Closed | | [LP-0013](prizes/LP-0013.md) | Token program improvements (authorities) | Medium | Open | | [LP-0014](prizes/LP-0014.md) | Token program improvements (ATAs + wallet tooling) | Medium | Closed | | [LP-0015](prizes/LP-0015.md) | General cross-program calls via tail calls | Large | Closed | diff --git a/prizes/LP-0012.md b/prizes/LP-0012.md index 745cbc6..92cb6e6 100644 --- a/prizes/LP-0012.md +++ b/prizes/LP-0012.md @@ -1,4 +1,4 @@ -# LP-0012: Event/Log mechanism: Structured events for LEZ program execution [OPEN] +# LP-0012: Event/Log mechanism: Structured events for LEZ program execution [CLOSED] **`Logos Circle: N/A`** diff --git a/solutions/LP-0012.md b/solutions/LP-0012.md new file mode 100644 index 0000000..6671bde --- /dev/null +++ b/solutions/LP-0012.md @@ -0,0 +1,121 @@ +# Solution: LP-0012 — Structured Event System for LEZ Programs + +**Submitted by:** bristinWild + +## Summary + +This submission implements a complete structured event system for the Logos Execution Zone (LEZ). Programs can emit typed, Borsh-encoded events during execution via `emit_event()`. Events are preserved in transaction receipts on both success and failure paths, retrievable by clients via a new `getTransactionReceipt` RPC method. A CLI decoder renders events in human-readable form for debugging and indexing. + +## Repository + +- **Repo:** https://github.com/bristinWild/logos-execution-zone +- **Commit:** `6dca25ba` (branch: `main`) +- **Key files:** + - `lez-events/src/lib.rs` — guest SDK (`emit_event`, `EventRecord`, `drain_events`) + - `nssa/core/src/program.rs` — `ProgramOutput.events`, `write_nssa_outputs_on_failure` + - `nssa/src/program.rs` — host-side event extraction, `ExitCode` handling + - `nssa/src/error.rs` — `NssaError::ProgramExecutionFailed` with `partial_output` + - `sequencer/core/src/block_store.rs` — `RejectedTx`, `RejectedTxStore` + - `sequencer/core/src/lib.rs` — event preservation on tx failure + - `sequencer/service/rpc/src/lib.rs` — `TxReceipt`, `TxStatus`, `getTransactionReceipt` + - `sequencer/service/src/service.rs` — RPC implementation + - `lez-events-decoder/src/main.rs` — CLI decoder tool + - `examples/emit_event_demo/` — success + failure path example programs + - `docs/event-format.md` — schema specification + +## Approach + +### Event Model + +Each emitted event is an `EventRecord` containing a caller-defined `discriminant` (u32), a monotonically increasing `sequence` number for ordering, and a Borsh-encoded `payload`: +```rust +pub struct EventRecord { + pub discriminant: u32, // program-defined event type + pub sequence: u32, // emission order within transaction + pub payload: Vec, // Borsh-encoded event data +} +``` + +Borsh was chosen per the team's own direction (issues #131, #260) for determinism and compactness. `program_id` attribution is injected by the sequencer host at receipt time (programs cannot read their own ID — issue #347). + +### Guest SDK + +Programs call `emit_event(discriminant, &payload)` from the `lez-events` crate. Events are buffered in a thread-local and flushed into `ProgramOutput.events` when `write_nssa_outputs()` is called. + +### Failure-Path Persistence + +For failure cases, programs call `write_nssa_outputs_on_failure()` before `panic!()`. This commits `(FAILURE_SENTINEL, Vec)` to the Risc0 journal using a sentinel value (`0xDEAD_FA11`) so the host can distinguish it from a success `ProgramOutput`. The sequencer detects the non-zero exit code, extracts events from the partial journal, and stores them in `RejectedTxStore`. + +**Dev-mode note:** In `RISC0_DEV_MODE=1`, the Risc0 executor does not expose the journal after a guest panic. Failure-path recovery works in production ZK mode. + +### Sequencer Integration + +- `RejectedTxStore`: in-memory store keyed by tx hash, preserving error message + events +- `getTransactionReceipt` RPC: returns `TxStatus` (Included/Rejected/Pending/Unknown) + events +- Events from included transactions come from `ProgramOutput.events` in the block +- Events from rejected transactions come from `RejectedTxStore` + +### Decoder CLI +```bash +lez-events-decoder --receipt receipt.json +``` + +Outputs human-readable transaction receipt with event discriminants, sequence numbers, and hex/UTF-8 decoded payloads. + +## Success Criteria Checklist + +- [x] **Event API for programs** — `emit_event(discriminant, &MyEvent { ... })` in `lez-events` crate, usable from any LEZ guest program. See `examples/emit_event_demo/methods/guest/src/bin/withdraw.rs`. +- [x] **Machine-readable format** — Borsh encoding, stable field ordering, sequence numbers for ordering, `program_id` injected by sequencer host, documented schema in `docs/event-format.md`. +- [x] **Human-friendly rendering** — `lez-events-decoder` CLI renders receipts as structured text with discriminants, sequence numbers, and decoded payloads. +- [x] **Available post-execution** — `getTransactionReceipt` RPC method returns events for both included and rejected transactions. +- [x] **Emittable on failure** — `write_nssa_outputs_on_failure()` + `FAILURE_SENTINEL` pattern preserves events before panic. Works in production ZK mode; dev-mode limitation documented. +- [x] **Testing** — 167 tests passing across all crates: + - Deterministic encoding/decoding: `lez-events` tests + - Event ordering: sequence counter tests + - Failure-path persistence: `emit_event_demo::failure_path_emits_insufficient_funds_event` + - Full nssa suite: 118 tests including all existing program execution tests + +## FURPS Self-Assessment + +### Functionality +- Programs emit typed events on success and failure paths +- Events retrievable via `getTransactionReceipt` RPC +- Decoder CLI renders events in human-readable form +- `program_id` attribution via sequencer host injection +- Privacy: public execution emits by default; private execution requires explicit opt-in (documented) +- Limitation: failure-path event recovery requires production ZK mode (not `RISC0_DEV_MODE`) + +### Usability +- Single function call: `emit_event(discriminant, &event_struct)` +- Pattern for failure path: `emit_event(...); write_nssa_outputs_on_failure(); panic!(...)` +- CLI decoder: `lez-events-decoder --receipt file.json` +- Full schema documented in `docs/event-format.md` + +### Reliability +- Events in `ProgramOutput.events` are committed atomically with program output — consistent with existing tx semantics +- `RejectedTxStore` is in-memory (cleared on restart) — sufficient for testnet; persistent storage is a natural next step +- 167 tests passing; all 118 existing nssa tests continue to pass + +### Performance +- Borsh encoding is zero-copy and allocation-minimal +- Thread-local event buffer adds negligible overhead to guest execution +- `RejectedTxStore` uses a `HashMap` — O(1) lookup per tx hash + +### Supportability +- New crates (`lez-events`, `lez-events-decoder`) are self-contained and independently testable +- `docs/event-format.md` documents the full schema, encoding, privacy considerations, and size guidelines +- `artifacts/program_methods/` update process documented (critical for future schema changes) +- Build scripts updated with `rerun-if-changed` for `nssa_core` and `lez-events` + +## Supporting Materials + +- **Event format spec:** [`docs/event-format.md`](https://github.com/bristinWild/logos-execution-zone/blob/main/docs/event-format.md) +- **Example program (success + failure):** [`examples/emit_event_demo/`](https://github.com/bristinWild/logos-execution-zone/tree/main/examples/emit_event_demo) +- **Guest SDK:** [`lez-events/src/lib.rs`](https://github.com/bristinWild/logos-execution-zone/blob/main/lez-events/src/lib.rs) +- **Decoder CLI:** [`lez-events-decoder/src/main.rs`](https://github.com/bristinWild/logos-execution-zone/blob/main/lez-events-decoder/src/main.rs) +- **RPC interface:** [`sequencer/service/rpc/src/lib.rs`](https://github.com/bristinWild/logos-execution-zone/blob/main/sequencer/service/rpc/src/lib.rs) +- **Related issues addressed:** #170 (Risc0 error handling), #379 (TX visibility), #347 (program_id), #131/#260 (Borsh encoding) + +## Terms & Conditions + +By submitting this solution, I confirm that I have read and agree to the [Terms & Conditions](../TERMS.md). From 74d4e05a893bca66e2dfde5197649d7dafcc120c Mon Sep 17 00:00:00 2001 From: Syafiq Nabil <146558571+syafiqeil@users.noreply.github.com> Date: Tue, 12 May 2026 13:55:42 +0700 Subject: [PATCH 06/11] Revise video demonstration section in LP-0016 Updated video demonstration links and added a note about upcoming content. --- solutions/LP-0016.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/solutions/LP-0016.md b/solutions/LP-0016.md index 828cf3a..f7d578f 100644 --- a/solutions/LP-0016.md +++ b/solutions/LP-0016.md @@ -108,7 +108,8 @@ The Logos stack provides three properties essential for this protocol: ## Supporting Materials -- **Video Demonstration:** https://youtu.be/Bj0GwITfYwM +- **Video Demonstration (SDK + On-Chain):** https://youtu.be/Bj0GwITfYwM +- **Video Demonstration (Basecamp Integration):** *(will be uploaded soon)* - **Protocol Specification Document:** Found within the PR at `docs/protocol.md`. ## FURPS Self-Assessment From 1bbdb919b88fe456944ee13986fc35033a6e8620 Mon Sep 17 00:00:00 2001 From: Syafiq Nabil <146558571+syafiqeil@users.noreply.github.com> Date: Fri, 15 May 2026 10:05:31 +0700 Subject: [PATCH 07/11] Update Basecamp Integration video link --- solutions/LP-0016.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/solutions/LP-0016.md b/solutions/LP-0016.md index f7d578f..c4ca5f2 100644 --- a/solutions/LP-0016.md +++ b/solutions/LP-0016.md @@ -109,7 +109,7 @@ The Logos stack provides three properties essential for this protocol: ## Supporting Materials - **Video Demonstration (SDK + On-Chain):** https://youtu.be/Bj0GwITfYwM -- **Video Demonstration (Basecamp Integration):** *(will be uploaded soon)* +- **Video Demonstration (Basecamp Integration):** https://youtu.be/_9RvF-oS7jM - **Protocol Specification Document:** Found within the PR at `docs/protocol.md`. ## FURPS Self-Assessment From f4a762348cd89122d6cb38535adee09fe4095e67 Mon Sep 17 00:00:00 2001 From: Syafiq Nabil <146558571+syafiqeil@users.noreply.github.com> Date: Fri, 15 May 2026 10:09:01 +0700 Subject: [PATCH 08/11] Correct repository section header in LP-0016.md --- solutions/LP-0016.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/solutions/LP-0016.md b/solutions/LP-0016.md index c4ca5f2..e73046c 100644 --- a/solutions/LP-0016.md +++ b/solutions/LP-0016.md @@ -6,7 +6,7 @@ A privacy-preserving forum protocol built on the Logos Execution Zone (LEZ) where members post anonymously via ZK proofs, moderators issue strikes through N-of-M threshold consensus, and K accumulated strikes cryptographically reconstruct the offender's secret key — enabling on-chain slashing and retroactive deanonymization. The deliverable includes a forum-agnostic moderation library (standalone SDK) and a working Logos Basecamp app demonstrating the full lifecycle. -## Repositories +## Repository - **Main Implementation (LEZ + Rust SDK + FFI):** https://github.com/logos-blockchain/logos-execution-zone/pull/465 - **Basecamp Core Module (C++ Qt Plugin):** https://github.com/syafiqeil/anonymous_forum_core From 39816fed86a8429490b700a1030b2e55bec9a809 Mon Sep 17 00:00:00 2001 From: syafiqeil Date: Fri, 15 May 2026 10:18:38 +0700 Subject: [PATCH 09/11] fix: point repo URL to fork for CI file validation --- solutions/LP-0016.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/solutions/LP-0016.md b/solutions/LP-0016.md index e73046c..929d610 100644 --- a/solutions/LP-0016.md +++ b/solutions/LP-0016.md @@ -8,7 +8,8 @@ A privacy-preserving forum protocol built on the Logos Execution Zone (LEZ) wher ## Repository -- **Main Implementation (LEZ + Rust SDK + FFI):** https://github.com/logos-blockchain/logos-execution-zone/pull/465 +- **Main Implementation (LEZ + Rust SDK + FFI):** https://github.com/syafiqeil/logos-execution-zone +- **Implementation PR:** https://github.com/logos-blockchain/logos-execution-zone/pull/465 - **Basecamp Core Module (C++ Qt Plugin):** https://github.com/syafiqeil/anonymous_forum_core - **Basecamp UI Module (QML):** https://github.com/syafiqeil/anonymous_forum_ui From 45dc37e434be747900fa1abe7ea1fb151f340aec Mon Sep 17 00:00:00 2001 From: syafiqeil Date: Fri, 15 May 2026 20:40:48 +0700 Subject: [PATCH 10/11] fix: update refs to standalone logos-anonymous-forum repo --- solutions/LP-0016.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/solutions/LP-0016.md b/solutions/LP-0016.md index 929d610..a86eb87 100644 --- a/solutions/LP-0016.md +++ b/solutions/LP-0016.md @@ -8,7 +8,7 @@ A privacy-preserving forum protocol built on the Logos Execution Zone (LEZ) wher ## Repository -- **Main Implementation (LEZ + Rust SDK + FFI):** https://github.com/syafiqeil/logos-execution-zone +- **Main Implementation (On-Chain + SDK):** https://github.com/syafiqeil/logos-anonymous-forum - **Implementation PR:** https://github.com/logos-blockchain/logos-execution-zone/pull/465 - **Basecamp Core Module (C++ Qt Plugin):** https://github.com/syafiqeil/anonymous_forum_core - **Basecamp UI Module (QML):** https://github.com/syafiqeil/anonymous_forum_ui @@ -99,9 +99,9 @@ The Logos stack provides three properties essential for this protocol: - [x] **Integration tests:** `integration_tests/tests/forum.rs` covers the full lifecycle: initialization, registration, ZK proof generation, N-of-M moderation with 3 strikes, NSK reconstruction, and slashing with stake confiscation. Runs with both `RISC0_DEV_MODE=1` (1.3s) and `RISC0_DEV_MODE=0` (98s). -- [x] **README:** `README_LP0016.md` documents deployment steps, build instructions, program architecture, API usage, and step-by-step demo instructions. +- [x] **README:** `README.md` in `logos-anonymous-forum` documents build instructions, program architecture, API usage, and step-by-step demo instructions. -- [x] **Reproducible demo:** `demo_e2e.sh` script and integration test suite. Build via `just build-artifacts` (Docker). Test command: `HOST_CC=gcc cargo test --release -p integration_tests -- test_forum_e2e_full_lifecycle --nocapture`. +- [x] **Reproducible demo:** `demo.sh` script and integration test suite. Build via `cargo build --release`. Test command: `./demo.sh`. - [x] **Video demo:** Narrated walkthrough covering architecture explanation, code highlights, IDL generation, E2E test with `RISC0_DEV_MODE=0` (real proofs), LEZ local deployment with bedrock/sequencer/indexer, and Basecamp app demonstration of the full moderation lifecycle. @@ -135,7 +135,7 @@ ZK proof generation is the primary bottleneck (~98s on i7-6600U). All other oper ### Supportability -The codebase is organized across three repositories with clear separation: `logos-execution-zone` contains the on-chain programs (`programs/membership_registry`), ZKVM binaries (`program_methods/guest`), the off-chain Rust SDK (`logos_moderation_sdk` with FFI layer), and E2E tests. `anonymous_forum_core` contains the C++ Qt plugin built with `logos-module-builder`. `anonymous_forum_ui` contains the QML interface built with `mkLogosQmlModule`. Formal protocol specification is provided in `docs/protocol.md`, including the Basecamp integration architecture (Section 5). The build system uses `just` for task automation, Docker for reproducible guest binary compilation, and Nix flakes for deterministic Basecamp module builds. All critical paths are covered by the integration test which runs in both dev mode and production mode. +The codebase is organized across three repositories with clear separation: `logos-anonymous-forum` contains the on-chain programs (`programs/membership_registry`), ZKVM binaries (`program_methods/guest`), and the off-chain Rust SDK (`logos_moderation_sdk` with FFI layer). `anonymous_forum_core` contains the C++ Qt plugin built with `logos-module-builder`. `anonymous_forum_ui` contains the QML interface built with `mkLogosQmlModule`. Formal protocol specification is provided in `docs/protocol.md`, including the Basecamp integration architecture (Section 5). Nix flakes are used for deterministic Basecamp module builds. The E2E integration test (with ZK proofs) runs within the LEZ workspace environment. ## Supporting Materials @@ -143,7 +143,7 @@ The codebase is organized across three repositories with clear separation: `logo - **Architecture audit:** Comparison of SPEL-based approach vs native NSSA programs - **IDL:** Generated via `spel generate-idl` — 4 instructions, ForumInstance account type - **Video demo:** Narrated architecture walkthrough + E2E test with RISC0_DEV_MODE=0 + LEZ deployment + Basecamp app demonstration -- **README:** `README_LP0016.md` — comprehensive build, deploy, and usage instructions (covers all 3 repositories) +- **README:** `README.md` in `logos-anonymous-forum` — comprehensive build and usage instructions (covers all 3 repositories) - **Basecamp module READMEs:** `anonymous_forum_core/README.md` and `anonymous_forum_ui/README.md` — API reference, build/run instructions, architecture diagrams ## Terms & Conditions From 8ed9501afaf1de42a2e7a316aa2bdb993fd5603f Mon Sep 17 00:00:00 2001 From: syafiqeil Date: Fri, 15 May 2026 21:12:09 +0700 Subject: [PATCH 11/11] ci: re-trigger validation for logos-anonymous-forum