Dev Update
1. Last Week by the Numbers
neptune-core
Pull Requests: 1 opened
triton-vm
Issues: 1 raised
neptune-explorer
Pull Requests: 1 merged
Commits: 2 merged into master
2. Stand-up Summary
Alan Szepieniec
Last Week: Migrated the Zero Knowledge (ZK) construction to the V8 branch due to complexity with STIR on master. Verified the ZK proof specification using AI tools, identifying and resolving flaws in the batch randomizer polynomial degrees and distribution argument (requiring a hybrid argument approach). Confirmed quotient table adjustments resulting in two single-point quotients. Benchmarked the chaining pipeline (30% cheaper than single proof) and designed generic case handler integration for backward compatibility.
Coming Week: Review the updated ZK specification document before deployment, verify the hybrid argument proof, provide chaining pipeline benchmark data, and update the TASM library (<100 lines of code).
Thorkil Værge
Last Week: Evaluated FRI parameter adjustments (80 vs 85 rounds for Elias bound). Implemented transaction pipeline security rules banning negative fees and zero throughput/zero input updates. Planned simultaneous V7 and V8 Triton VM deployment to ensure high uptime, and agreed to convert the Mempool transaction struct into an enum.
Coming Week: Conduct a thorough review of the five proof transformation consensus programs (Forge, Cupdate, Chain, Cast, Fix) including internal checks, and integrate transaction chaining into the Neptune Core transaction infrastructure.
3. Technical Discussion
- Triton VM Zero Knowledge Implementation: The ZK construction was moved to the V8 branch because the master branch contains the STIR implementation, which introduced excessive complexity to the TASM code. Review of the ZK proof specification revealed two critical issues: incorrect polynomial degrees for the batch randomizer and an inadequate distribution argument requiring a hybrid argument approach. Updating the ZK construction alters the quotient table to include an additional segment and two out-of-domain rows (producing two single-point quotients and requiring one extra term in the batch). Downstream adjustments to
tasm-libare minor (<100 lines of code). - FRI Parameter & Soundness Review: The team evaluated increasing the number of FRI round calculations from 80 to 85 to align with the Elias bound conjecture and preserve 160 bits of soundness. This parameter review remains open for further evaluation.
- Transaction Pipeline Optimizations & Security: Benchmarking confirmed that producing transactions via the chaining pipeline is 30% cheaper than single proof methods, though single proof collection remains essential for devices with under 64 GB of RAM. Security restrictions were implemented to prevent shortcut exploits, including banning negative fees, prohibiting transaction updates with zero thruputs and zero inputs, and requiring the single proof hash in claims output. The chaining pipeline will initially deploy as a soft option with flag-based configuration.
- Core Integration & Backward Compatibility: To support linked transactions while maintaining backward compatibility with version 17, the case handler will be extracted into a generic function used by both single proof and linked transactions. The Mempool transaction structure will be modified into an enum, and existing RPC endpoints with configuration flags will be utilized. Consensus program naming has been aligned to Forge, Cupdate, Chain, Cast, and Fix.