zkVerify's Runtime Upgrade 0.9.0 and Node Release 0.7.0
We're thrilled to announce the activation of a significant node release, marking a transformative step forward in how proofs are managed and verified on the zkVerify network.
Through zkVerify's Substrate-based architecture, we're able to roll out these improvements seamlessly without requiring a hard fork, ensuring a smooth transition for everyone, from node operators to users.
Key Highlights
Verification Keys and Domains
Proof generation systems, such as Groth16, rely on two essential components:
- Proving Key: To generate the proof
- Verification Key: To validate the proof
In this release, we introduce Domains, a powerful new concept that defines how proofs are processed after being verified.
When you register a domain, you create a pathway that determines:
- Where aggregation receipts (proofs’ verification results) should go
- How these receipts should be managed
Domains also support customizable aggregation policies, enabling developers to:
- Specify a minimum number of proofs before publishing receipts
- Set time-based triggers for receipt publication
- Define custom conditions tailored to your zkApp’s requirements
These policies optimize the balance between cost efficiency and latency, giving you full control over proof handling.
Economic Model: Sustaining Growth
To ensure the sustainable growth of our network, we've implemented a thoughtful economic model based on token bonding for both verification keys and domains.
For verification keys:
- Tokens are bonded based on the key's size during registration.
- Bonded tokens are returned when the verification key is unregistered
For domains:
- Tokens are bonded based on the reserved domain’s “bandwidth”
- Bonded tokens are returned when the domain is unregistered
This model ensures fair resource allocation and incentivizes efficient network use.
Hyperbridge-Enabled Cross-Chain Receipts
Since zkVerify's launch, we've relied on our relayer to ensure aggregation receipts reach their destination chains. This approach helped us establish a stable foundation and gain the trust of early adopters. While effective, this approach is centralized, and we've always known that true scalability and censorship resistance require a more decentralized solution.
With this release, we're integrating Hyperbridge, offering a fully decentralized relaying mechanism as an alternative. With this integration, developers can now choose between:
- Our default relayer
- The fully decentralized relayer through Haperbridge
This is a significant step that strengthens our partnership with Hyperbridge and brings us closer to our vision of a truly scalable and resilient ecosystem.
Additional Technical Enhancements
- Expanded Tooling: We updated the zkverifyjs toolkit to support Groth16 Gnark proofs on both bn254 and bls12-381 curves.
- Polkadot 1.15 Alignment: We've aligned our system with the latest Substrate improvements, ensuring compatibility and staying ahead of the curve.
How to Update Your Node
Follow our step-by-step guides to update your node:
- Binaries: https://docs.zkverify.io/tutorials/how_to_run_a_node/run_using_docker/update_running_node/
- Docker: https://docs.zkverify.io/tutorials/how_to_run_a_node/run_using_binaries/update_running_node/
For any questions or support, don’t hesitate to reach out to the team on Discord!
Get Started
- Explore our updated documentation at: https://docs.zkverify.io
- Join zkVerify Discord community: https://discord.com/invite/zkverify
- Join zkVerify Telegram channel: t.me/zkverify
We're excited to see how developers will use these new capabilities to build more efficient and flexible zk apps. Together, we're making proof systems more accessible and efficient than ever before!