Skip to content

Latest commit

 

History

History
47 lines (30 loc) · 3.07 KB

frictionlog.md

File metadata and controls

47 lines (30 loc) · 3.07 KB
Raw

Friction Log Nargo 0.1

  1. Prover.toml & Verifier.toml interface Expected: Verifier.toml values are be auto-generated and abstracted away from the user. IT does seem to be autogenerated at the nargo prove.. step, but the docs indicate that's something the user should manually key in. Expected: Verifier.toml variable format should be consistent with Prover.toml. Actual: Prover.toml variables are numeric, e.g. x=1, while Verifier.toml auto formats variables into hex , e.g. x=0x0000..1.

1.1. I'm not sure why we need Verifier.toml in the first place... All public input values from Prover are/should be accessible to Verifier anyway.

1.2 Return value is just another public input signal (like in Circom). So having a hardcoded/custom return type in NOIR seems redundant, especially since nothing is logged to console to help the development process/we can't actually see what the return values are.

1.3 Also, in V.toml What is setpub = [] ? Docs do not explain

  1. Error handling Expected: better error messages for simple CLI errors, i.e. referencing non-existent file, bad cli subcommands. Actual: "thread 'main' panicked" error msg is returned for most cases.

  2. Docs confusion Can you publish reference docs to docs.rs or somewhere? Was kind of hard to comb through this repo to see the available apis: https://github.com/noir-lang/noir/tree/master/crates/std_lib/src

  3. unused variable _ error can be stubbed? Expected: would be great to port over some of unimplemented! macros from rust into the NOIR devex, i.e. let users stub parts they haven't implemented yet after defining the interface.

  4. error: Expected type (), found type [()] error thrown when I forgot a ; at the end of a if block. Expected: a better syntax error

  5. Is there opcode/syntax to handle exponentiation?

  6. Field overflow/underflow error msg confusing: Got: thread 'main' panicked at 'assertion failed: bit_size < FieldElement::max_num_bits()' Expected: underflow/overflow...

  7. Print which constraints cannot be satisfied Got: could not satisfy all constraint maybe intentionally vague? But not great for development process..

  8. Not being able to console log or see outputs is hard. I configured a ts project to generate the expected pedersen hash , signature, etc values. That said, circom doesn't handle this well either. It would be killer devex to have NOIR CLI keep pace with opcodes, so I can just generate values on the command line.

Related: when inputing hex values, it seems I have to be careful about how many significant digits are used. BOTH in Prover.toml files AND in the Pedersen TS package.

Expected: hashing 0x0001 and 0x00000001 yield equivalent results, but it does not! Maybe I lack understanding of some important rule here...

  1. Not clear what conditions, beyond +/*, can be constrained:
  • [doesn't work] constrain x == 0 | 1
  • [not sure] constrain x == 10 / 2 Seems to be a cool/macro thing that a DSL should handle. Understand docs are in progress.

In all this was fun. Excited to try out NOIR again once there are some guided workshops/docs out demonstrating how to write better constraints!