KIP-16 #775
Open
KIP-16 #775
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Increase MAX_SCRIPT_SIZE, MAX_SCRIPT_ELEMENT_SIZE, MAXIMUM_STANDARD_TRANSACTION_MASS - Implement OpZkPrecompile opcode
Introduces sigop cost calculation for ZK precompiles in txscript, updates OpZkPrecompile to consume sigops based on verifier tag, and adds a benchmarking test comparing ZK proof verification and ECDSA signature verification. Also adds a sample STARK proof hex file and lowers MAX_SCRIPT_ELEMENT_SIZE to 250,000.
This finalizes the PoC implementation of OP_ZK_PRECOMPILE.
Collaborator
Author
|
Currently tests are failing from what I believe is due to the upgrade of sigopcount from a u8 to a u16. Would need more assistance on how to resolve these failures. |
Collaborator
|
Relevant KIP PR: kaspanet/kips#31 |
- If a sigop count is > 100 each sigop count value will be counted as 10 (everything above 100)
- Remove scriptpubkey size check, since we can have largerlocking scripts due to larger scripts (zk) - Allow larger than 520 bytes to be passed in script test - Update misc tests
Reorganizes the zk_precompiles module by removing RISC0 Groth16 and succinct submodules, introducing a new Groth16 precompile using arkworks libraries, and centralizing error handling. Updates dependencies to include arkworks crates, adjusts trait and error types for modularity, and moves/renames benchmark files for clarity. The changes improve maintainability and add support for Groth16 proof verification. - In order to facilitate verification of arbitrary proofs we need to use the inner functionality that risc0 uses in order to verify g16 proofs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Zero-Knowledge Proof Verification Opcodes - KIP-16 Reference Implementation
AI Use Disclosure
Some parts of this PR description was generated using AI based on a manually written draft.
Overview
This pull request implements the reference code for KIP-16, introducing zero-knowledge proof verification to Kaspa through the new
OpZkPrecompileopcode. This enables on-chain verification of cryptographic proofs, providing the foundation for decentralized Layer 2 solutions and verifiable off-chain computation.The implementation includes two RISC Zero-based precompiles: RISC0-Groth16 (tag 0x20) for compact proofs and RISC0-Succinct (tag 0x21) for quantum-resistant STARK verification. Both verify proofs generated by RISC Zero's lift program attesting to correct execution of RISC-V programs.
Implementation Status
This reference implementation demonstrates the viability of zero-knowledge proof verification on Kaspa and establishes the architectural direction. It should be understood as a foundational building block intended to facilitate technical review and community discussion rather than a production-ready implementation. Feedback from this review process will inform refinements to both the code and the KIP specification.
Examples demonstrating how to generate compatible proofs using RISC Zero tooling will be added to the repository soon to assist developers in testing and building applications on these opcodes.
Key Components
The implementation introduces the core opcode handler that dispatches to specific proof system implementations based on tag identifiers, the two RISC Zero precompile verifiers with their cryptographic binding logic, a benchmarking suite for performance measurement, and comprehensive error handling for verification failures.
Testing and Benchmarks
The implementation includes unit tests verifying correct operation with valid proofs and appropriate error handling for invalid inputs. The benchmarking suite measures verification performance for ECDSA signatures, Groth16 proofs, and STARK proofs, establishing the empirical basis for the proposed pricing model of 140 sigops for Groth16 and 740 sigops for STARK verification.
Security Considerations
This implementation introduces dependencies on RISC Zero's verification libraries. The security of transactions using these precompiles depends partially on the correctness of these external dependencies, representing a conscious trade-off to enable advanced functionality. The precompile architecture isolates different proof systems such that vulnerabilities in one system do not compromise others or the base layer security.
Request for Review
This implementation warrants careful technical review. Feedback is particularly valuable regarding the precompile architecture and security properties, parameter adjustments and their network impact, pricing model validation through independent benchmarking, error handling and failure modes, and performance characteristics under load. The complete specification and rationale are available in KIP-16.
Community members with expertise in zero-knowledge cryptography, network performance optimization, or script engine design are encouraged to provide feedback. Developers planning to build applications on these opcodes can help evaluate the interface design and developer experience.
Testing
To test the implementation one can run the javascript examples added against a devnet node.