-
Notifications
You must be signed in to change notification settings - Fork 8
compiling plonk_vk.sol throws YulException: too deep in the stack & then fails to verify proof format #22
Comments
From the noir issue it seems to be turbo verifier, which is not in here. Noir is in progress to use Ultraplonk instead which should switch to the verifiers in here, which also support an interface where you don't have to prepend data but can just pass it in as a list of I think there was an issue with challenge computation (@Globallager, @kevaundray) where the backend computed different challenges (different hashfunction) than the verifier which sohuld make it fail consistently. Related, we are working on moving the verifiers from here into Barretenberg (AztecProtocol/barretenberg#363), |
Yeah this issue would be TurboPlonk related -- Please wait for us to switch to UP, as Lasse said, it has a much better interface and support :) |
@LHerskind @kevaundray this sounds like a plan. Do you both have any rough timelines on when this can be accomplished? Our project heavily depends on being able to provide a valid proof via smart contract. Also, will there be some type of tutorial on actually submitting a proof to the smart contract and encoding it correctly? It was kind of hard to find the exact steps to get this far on our end. We had to rely on different sources of information to get this far towards an end-to-end workflow. Thanks in advance team! 🚀 |
This should be much easier when this work is in. The new Interface looks like this: function verify(bytes calldata _proof, bytes32[] calldata _publicInputs) external view returns (bool); So no more prepending or dealing with the bytes directly, just passing in a list of the public inputs. |
@Jovonni There were some unexpected delays and our latest outlook timeline-wise is roughly the end of month. You can subscribe to noir-lang/noir#991 for notification when it's out from the oven 🙌 |
Awesome team thanks. Am I waiting for noir 0.4.1? Just want to make sure I know what to watch out for. Thanks again for the explanation! @LHerskind @Globallager Update: Nevermind, I see the PR, thanks 🚀 |
Hey team @Globallager @LHerskind @kevaundray , I am trying to update noir to the most recent PR that implements this fix, via this command:
But i get the following error:
When I change the
To this (since ./crates/nargo folder doesn't exist):
I get the following output:
I see the released version of noir is still 0.4.1, but how do I upgrade my noir version to take advantage of the newly finished PRs you linked above? Is there a step I am missing with brattenburg or something else? Thanks for working speedy team. |
Cc @TomAFrench for this noirup issue |
I am working on noir v0.5.1 now, good work on this so far on this implementation. I am seeing an issue that I also experienced in previous versions. My
My circuit is:
Why would the UltraVerifier expect 3 public inputs, when I only define 2? I am passing a
I am just calling the verify function: function verify(bytes calldata _proof, bytes32[] calldata _publicInputs) external view returns (bool) { Is that expected behavior? I would assume my public inputs in the generated contract should be two with my noir script shown here. I see in the plonk_vk.sol the uint256 internal constant NUM_INPUTS_LOC = 0x3a0; declaration. Wondering if the issue is here: assembly {
requiredPublicInputCount := mload(NUM_INPUTS_LOC)
}
if (requiredPublicInputCount != _publicInputs.length) {
revert PUBLIC_INPUT_COUNT_INVALID(requiredPublicInputCount, _publicInputs.length);
} @kevaundray @Globallager @LHerskind @TomAFrench |
The output of your main function is also a public input to the verifier so you have 3 public inputs |
It works. Thank you kindly team. Great work, and great response effort. @LHerskind @Globallager @kevaundray Also wondering if this was the cause of my issue in the TurboVerifier as well. Not passing the return value in to the verify function call! 🙃 |
On the bright side your issue made an improvement to the docs! 🎉 https://noir-lang.org/nargo/solidity_verifier/#public-inputs |
Linked from issue in noir repo:
noir-lang/noir#1140
Here is the most updated issue:
Update:
I still got the "proof failed" error. Here I am doing it again to show you the results.
I am passing the following format:
Details
Function Signature
Proof Data Pointer
Length of proof data array
Public Input 1
Public Input 2
Proof Data Array
Doing this, I no longer get the
G1 point not on curve, or is malformed]
error, but I get theproof failed
error. This seems like it indicates the formatting is correct, but the proof input is wrong...If I don't prepend my proof data with the two public inputs, then I get the
G1 point not on curve, or is malformed]
error again, so it seems like prepending the two public inputs works, but I cannot get past thisproof failed
error..The text was updated successfully, but these errors were encountered: