Replies: 11 comments 10 replies
-
|
Thanks. I am supportive in principle of expanding the scope of the puzzle in order to make it more “useful”. What are the implications of this change on the economics? In other words, are there any changes expected in the puzzle difficulty adjustment algorithm that would potentially affect the inflation rate of ALEO? |
Beta Was this translation helpful? Give feedback.
-
|
May I ask when the algorithm upgrade is expected to start? |
Beta Was this translation helpful? Give feedback.
-
|
This ARC is currently a proposal in draft stage. As discussions and design proposals mature, this ARC will converge on a concrete design that can be implemented, analyzed, and reviewed. |
Beta Was this translation helpful? Give feedback.
-
|
I think this is the right direction both for incentivising the improvement of dedicated hardware for cryptographic operations and very importantly improving network performance. Do we have an idea on what the current impact of puzzle verification is to network consensus as a bottleneck ( in terms of time to verify ) ? |
Beta Was this translation helpful? Give feedback.
-
Because of the high verification requirements (0.5 GiB memory, takes 100s of ms), |
Beta Was this translation helpful? Give feedback.
-
|
Hi, we are Metaworks Lab from Australia. We are keen to contribute to Aleo and hope to work with the community to participate in the improvement and implementation of the ARC0043 proposal. We work with the ZK hardware accelerator team to do software and hardware co-design. We have the ability to support ARC43 and can also do general ZK accelerator. We can do:
|
Beta Was this translation helpful? Give feedback.
-
|
Hi, as a loyal fan of Aleo, I have a few questions to ask:
The current TPS is indeed very bad and needs to be solved urgently, otherwise the ecosystem cannot develop. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
@LoiusZK The most straightforward way to increasing TPS is by introducing more validators into the network. This ARC is likely to have little impact on TPS, as consensus currently verifies at most 4 valid puzzle solutions per block, each at around 100-200ms. This ARC would likely reduce the amount of time needed, but could also enable more puzzle solutions to be submitted in each block, allowing for more provers to earn rewards. |
Beta Was this translation helpful? Give feedback.
-
|
@howardwu If simply increase the number of validators based on the current instruction set puzzle algorithm, won’t the block time also increase? Cause we know the final calculation result of the current instruction set puzzle algorithm is not a Proof, so the validators need to execute it individually to verify, and cannot execute Proof verification in batches, which will also affect TPS. I think this ARC should also be a preparation for adding more validators in the future right? |
Beta Was this translation helpful? Give feedback.
-
It's CPU performance to verify one valid puzzle with 100~200ms? I think if GPU is used, the verification period can be much less. |
Beta Was this translation helpful? Give feedback.
-
|
While all three improvements to the puzzle are desirable, it appears that Goal #3: implementing a SNARK for verification is the most important. Without it, increasing the instruction count and complexity would only increase the solution verification time. In these benchmarks, we find that a puzzle program with 1000 instructions results in a solution that takes ~500ms to verify. Ideally, we'd like to increase instruction count well beyond this number. With succinct solution verification, we can increase program complexity in meaningful (and virtually unbounded) ways. An added benefit is that the protocol can support a larger number of solutions per block, allowing rewards to be distributed to more provers. One open question is: how do validators synthesize the verifying key? Furthermore, how do clients, which may have lower compute resources get this key? Solutions are verified live during consensus. Furthermore, the puzzle program changes every epoch. Even for small programs, the overall circuit can contain millions of constraints. Synthesizing verifying keys in these settings can take a significant amount of time. A naive design is to require validators to synthesize the key at the beginning of the epoch, however this could result in a verification delay. A possible solution is introduce a buffer during which a validator can synthesize the key. For example, the puzzle program can be generated using the previous epoch hash, while the seed for the puzzle inputs can use the current epoch hash. Validators are then responsible for storing and distributing verification keys to clients. Curious to hear what people think and other approaches to consider! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the thoughts @d0cd. Do you see any possibility of having a pipelined design, whereby provers have 1 full epoch to synthesize the verifying key and get it to all validators, then 1 full epoch to find solutions for the puzzle? By pipelining these two stages, one can have a continuous puzzle and verifying key synthesis procedure. |
Beta Was this translation helpful? Give feedback.
-
|
Pipelining sounds like a promising approach. I imagine validators would still have to verify the submitted verifying key against |
Beta Was this translation helpful? Give feedback.
-
Verification of just the Verifying Key
Very cool idea! I'm in favour to explore. To be clear, I think it would only make sense for verifying key submission to be an incentivised component, as this is what validators need. Currently I don't see any issues with this, though note that 1. it increases complexity, so can be added in a later stage 2. it adds a liveness assumption, namely that we expect a network participant to submit a verifying key to a validator participating in consensus. |
Beta Was this translation helpful? Give feedback.
-
|
When will the algorithm upgrade be completed? Can you give a plan? |
Beta Was this translation helpful? Give feedback.
-
|
This ARC is currently a proposal in draft stage. As discussions and design proposals mature, this ARC will converge on a concrete design that can be implemented, analyzed, and reviewed. |
Beta Was this translation helpful? Give feedback.
-
|
thank you very much! |
Beta Was this translation helpful? Give feedback.
-
|
We at Computation Frontier Labs are a team researching computation acceleration technology, including zero-knowledge proofs. We believe this proposal demonstrates a positive trend for Aleo in constructing a useful ZKP prover platform. It's beneficial for promoting the development and adoption of ZKP technology, much like Aleo's efforts with ZPrize. Furthermore, we have some questions:
PS: We've published an article analyzing the Aleo project: https://medium.com/@CFrontier_Labs/the-journey-toward-aleos-universal-zkvm-1df9114fbd86 We hope Aleo continues to encourage the community to develop ZKVM-specific hardware machines. This could benefit not only Aleo but also other ZKP projects, as the same acceleration technology and machines could be applied across various ZKP projects. |
Beta Was this translation helpful? Give feedback.
-
Regarding this ARC, I have a few questions to ask or my suggestions are as follows:
|
Beta Was this translation helpful? Give feedback.
-
很好 |
Beta Was this translation helpful? Give feedback.
-
|
您好，作为Aleo的忠实拥护者，我相信隐私之王Aleo未来的应用，一定可以改变世界web3时代，有问题想请教您，如果采用ARC—0043，我们基于当前主网算法开发ASIC芯片机，是否需要等一等，还是采用FPGA矿机推动Aleo发展？ |
Beta Was this translation helpful? Give feedback.
-
ARC-0043: Extending the Puzzle to a Full SNARK
arc: 0043
title: Extending the Puzzle to a Full SNARK
authors: @howardwu
discussion: #77
topic: Protocol
status: Draft
created: October 15, 2024
Abstract
This ARC proposes extending the current blockchain puzzle from a synthesis-focused operation to a full Succinct Non-interactive Argument of Knowledge (SNARK). The primary goals are to incentivize the acceleration of a full SNARK on dedicated hardware and improve block verification times through succinct puzzle verification. This proposal aims to mitigate bottlenecks in the block verification pipeline caused by synthesis operations, and to leverage recent advancements in GPU and FPGA acceleration to improve the puzzle challenge for provers.
Background
SNARK generation has seen significant performance improvements over the past several years, in part due to efforts such as the Aleo Testnets and ZPrize. While proof generation was initially bottlenecked by algorithms such as Multi-Scalar Multiplication (MSM) and Number Theoretic Transform (NTT), these algorithms have been accelerated significantly, resulting in synthesis becoming the most time consuming operation. With recent improvements to synthesis resulting from the launch of the Aleo Mainnet, there is now an opportunity to further optimize the end-to-end proving and verifying process.
Proposal
This proposal extends the current puzzle to a full SNARK with the following key changes:
1. Increased Instruction Count
The current puzzle has an artificially constrained number of instructions due to limitations in consensus verification. By implementing a full SNARK, one can expand the instruction count by orders of magnitude. This will significantly harden the puzzle for provers, expanding the utility of dedicated hardware and improving on current computational requirements for proving.
2. Expanded Instruction Set
Introducing a zkSNARK for verification allows for the inclusion of richer opcodes with larger operands. This expansion of the instruction set will increase the complexity and versatility of the puzzle challenge. However, careful consideration must be given to instruction selection to avoid degeneracy of operands (e.g., operands becoming 0 and propagating through the remainder of the function).
3. zkSNARK Verification
Implementing a zkSNARK for verification will enable succinct puzzle proof verification. This will improve block verification times, enhancing overall network performance.
Technical Considerations
Benefits
Risks and Mitigations
Risk: Increased complexity in puzzle design and verification.
Mitigation: Thorough testing and gradual implementation, with potential for a phased rollout.
Risk: Potential for new attack vectors due to expanded instruction set.
Mitigation: Rigorous security analysis & audits, alongside careful selection of new instructions.
Risk: Increased hardware requirements for miners/provers.
Mitigation: Phased implementation to allow for gradual hardware upgrades.
Conclusion
Extending the current puzzle to a full SNARK incentivizes a significant advancement for proving hardware. It addresses current bottlenecks for consensus, improves overall network performance, and incentivizes hardware acceleration for cryptographic operations. The next step is to gather community feedback to refine and improve this proposal.
Beta Was this translation helpful? Give feedback.
All reactions