Overview

Current code documentation does not do much to reason about what the public input delta calculation is for and how to reason about it. Include documentation for this.

Overview

Generated from this comment:

@follow-up Elaborate on naming to easily match with the paper (part of step 9?)

The linters in Remix IDE claim that _proof and _publicInputs variables on the verify function are unused. Is this just a false positive?

When copying the verifier contracts into Remix IDE, it errors with StackTooDeep. This goes away when optimizations are enabled (they are disabled by default).

Overview

Currently the ordering of the verification steps in the plonk paper are different to the implementation, elaborate on this at the top of the implementation

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:

0x [function signature] + [proof data pointer] + [length of proof data] + [public input 1] + [public input 2] + [proof data array]

Details

Function Signature

0x8e760afe

Proof Data Pointer

0000000000000000000000000000000000000000000000000000000000000020

Length of proof data array

00000000000000000000000000000000000000000000000000000000000004e0

Public Input 1

0bff8247aa94b08d1c680d7a3e10831bd8c8cf2ea2c756b0d1d89acdcad877ad

Public Input 2

2a5d7253a6ed48462fedb2d350cc768d13956310f54e73a8a47914f34a34c5c4

Proof Data Array

2abfb...

Doing this, I no longer get the G1 point not on curve, or is malformed] error, but I get the proof 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 this proof failed error..

Overview

Elaborate on the reasoning for why the implementation differs, issue created off the back of this recent comment from lasse.

                // @note that our r_0 looks different from the paper.
                // This related to the public input delta that we mentioned earlier.
                // So we are replacing PI with (z̄_ω - ∆PI) * L_n * α^2.
                // @follow-up Elaborate on this replacement
                // @note that our r_0 differs on the power of alpha from the paper. The alpha is a challenge
                // so having a different challenge is fine, as long as both verifier and prover use the same.

Add the gas usage for the different version to the readme so it can easily be found without pulling repo and running tests.

Hello, I'm writing educational content about Noir in spanish and @critesjosh has been guiding me on the process. I stumbled into following issue while writing a guide on how to create a dApp. I got redirected here from acvm-backend-barretenberg.

I did a PR #23 that solves this. Happy to hear your comments.

The problem

It should be common for devs to inherit from UltraVerifier while creating a dApp. This is to keep the codebase organized and readable. A normal implementation should look like the following example:

//SPDX-License-Identifier: MIT
pragma solidity >=0.8.19;

contract MyDApp is UltraVerifier {
    // Custom logic
    function proveStuff(bytes calldata _proof, bytes32[] calldata _publicInputs) public {
        verify(_proof, _publicInputs));
        // More custom logic
    }
}