Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
4dccea4 to
9db332e
Compare
barretenberg/acir_tests/bootstrap.sh
Outdated
| echo "$prefix FLOW=sol_honk USE_OPTIMIZED_CONTRACT=true $run_test assert_statement" | ||
| echo "$prefix FLOW=sol_honk USE_OPTIMIZED_CONTRACT=true $run_test a_1_mul" | ||
| echo "$prefix FLOW=sol_honk USE_OPTIMIZED_CONTRACT=true $run_test slices" | ||
| echo "$prefix FLOW=sol_honk USE_OPTIMIZED_CONTRACT=true $run_test verify_honk_proof" |
There was a problem hiding this comment.
we don't care about optimized zk contract?
There was a problem hiding this comment.
not for now, its not P1 for audit right now, but will be made a priority once everything in the current round of audits is complete
| #!/bin/bash | ||
|
|
||
| # Script to copy optimized Solidity verifier files into the C++ honk_optimized_contract.hpp file | ||
| # This automates the manual process of copying optimized verifier contracts |
There was a problem hiding this comment.
Comments from slack:
No comments are blocking, ok with this going in as-is for now
but - we can probably remove a bit of brittleness. you're doing template discovery on what would normally be an output artifact, then doing find replace with strings.
What about:
the script copies the solidity as-is. but the solidity has e.g. // c++-replace VK_HASH comments.
the c++-replace directives can affect the next line
2. store the C++ artifacts in a map of symbol to string
3. process the c++-replace directives
probably error on any unused symbols
There was a problem hiding this comment.
the other thing is, it's more normal to bundle artifacts in C++ as its own header file
f824ebc to
4cfb472
Compare
Complete, without zk Cuts off a million next steps: proof size has a large consequence with this one, due to memory expansion, so having a different proof type for the keccak one which does tighter serialisation will save a good chunk of gas - working on this next - pr here #16018
4cfb472 to
39cc87a
Compare

Complete, without zk
Cuts off a million
next steps:
proof size has a large consequence with this one, due to memory expansion, so having a different proof type for the keccak one which does tighter serialisation will save a good chunk of gas - working on this next