Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: new test program for verifying honk #6781

Merged
merged 2 commits into from
Jun 3, 2024

Conversation

lucasxia01
Copy link
Contributor

Adds a new test Noir program verify_honk_proof that takes in a honk proof and calls the honk recursive verifier.

Please read contributing guidelines and remove this line.

@lucasxia01 lucasxia01 self-assigned this May 31, 2024
@AztecBot
Copy link
Collaborator

AztecBot commented May 31, 2024

Benchmark results

No metrics with a significant change found.

Detailed results

All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.

This benchmark source data is available in JSON format on S3 here.

Proof generation

Each column represents the number of threads used in proof generation.

Metric 1 threads 4 threads 16 threads 32 threads 64 threads
proof_construction_time_sha256_ms 5,725 1,558 (+1%) 709 763 (+2%) 783 (+1%)
proof_construction_time_sha256_30_ms 11,530 (+1%) 3,105 (+2%) 1,393 (+1%) 1,451 (+1%) 1,473 (+2%)
proof_construction_time_sha256_100_ms 44,284 (+2%) 11,961 (+2%) 5,670 (+5%) 5,598 (+3%) 5,512 (+3%)
proof_construction_time_poseidon_hash_ms 78.0 34.0 34.0 58.0 (+2%) 89.0 (+3%)
proof_construction_time_poseidon_hash_30_ms 1,515 417 201 (+1%) 222 (-1%) 268 (+1%)
proof_construction_time_poseidon_hash_100_ms 5,755 1,563 727 (+1%) 783 (+2%) 801 (+2%)

L2 block published to L1

Each column represents the number of txs on an L2 block published to L1.

Metric 8 txs 32 txs 64 txs
l1_rollup_calldata_size_in_bytes 1,412 1,412 1,412
l1_rollup_calldata_gas 9,452 9,452 9,476
l1_rollup_execution_gas 616,093 616,093 616,117
l2_block_processing_time_in_ms 1,277 (-1%) 4,797 9,471 (-1%)
l2_block_building_time_in_ms 43,935 174,091 347,910
l2_block_rollup_simulation_time_in_ms 43,740 173,368 346,463
l2_block_public_tx_process_time_in_ms 38,075 165,162 (-3%) 341,205

L2 chain processing

Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric 3 blocks 5 blocks
node_history_sync_time_in_ms 9,492 14,460 (-1%)
node_database_size_in_bytes 14,495,824 21,352,528
pxe_database_size_in_bytes 18,071 29,868

Circuits stats

Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Circuit simulation_time_in_ms witness_generation_time_in_ms proving_time_in_ms input_size_in_bytes output_size_in_bytes proof_size_in_bytes num_public_inputs size_in_gates
private-kernel-init 134 (-3%) 505 (+9%) 12,476 (-1%) 20,634 64,614 89,536 2,731 524,288
private-kernel-inner 406 972 (+4%) 49,603 (+1%) 92,326 64,614 89,536 2,731 2,097,152
private-kernel-tail 582 (-1%) 2,652 (+2%) 50,806 (-1%) 96,545 77,732 11,648 297 2,097,152
base-parity 6.46 1,059 (+4%) 2,884 (+1%) 128 64.0 2,208 2.00 131,072
root-parity 49.4 (+1%) 61.8 40,461 (-2%) 27,100 64.0 2,720 18.0 2,097,152
base-rollup 8,952 (-5%) 2,405 (+1%) 79,258 (+5%) 119,738 756 3,648 47.0 4,194,304
root-rollup 110 (+1%) 77.6 (+3%) 21,487 (-6%) 25,309 620 3,456 41.0 1,048,576
public-kernel-app-logic 571 (-1%) 3,570 (+1%) 43,691 (-7%) 108,073 86,550 116,768 3,582 2,097,152
public-kernel-tail 1,122 (-1%) 22,455 (-5%) 182,666 (-3%) 403,238 7,646 11,648 297 8,388,608
private-kernel-reset-small 588 (-1%) 1,947 (-1%) 45,378 120,737 64,614 89,536 2,731 2,097,152
public-kernel-setup 668 (+2%) 2,769 (+2%) 44,484 (-1%) 108,073 86,550 116,768 3,582 2,097,152
public-kernel-teardown 572 (+1%) 3,508 43,901 (-3%) 108,073 86,550 116,768 3,582 2,097,152
merge-rollup 30.2 (-3%) N/A N/A 16,542 756 N/A N/A N/A
private-kernel-tail-to-public N/A 8,363 (-6%) 99,873 (+1%) N/A N/A 116,768 3,582 4,194,304

Stats on running time collected for app circuits

Function input_size_in_bytes output_size_in_bytes witness_generation_time_in_ms proof_size_in_bytes proving_time_in_ms size_in_gates num_public_inputs
ContractClassRegisterer:register 1,344 9,944 465 (+2%) N/A N/A N/A N/A
ContractInstanceDeployer:deploy 1,408 9,944 41.0 (+1%) N/A N/A N/A N/A
MultiCallEntrypoint:entrypoint 1,920 9,944 1,773 (+1%) N/A N/A N/A N/A
SchnorrAccount:constructor 1,312 9,944 1,429 (+1%) N/A N/A N/A N/A
SchnorrAccount:entrypoint 2,304 9,944 2,759 16,768 54,309 (+2%) 2,097,152 457
Token:privately_mint_private_note 1,280 9,944 1,573 (+1%) N/A N/A N/A N/A
FPC:fee_entrypoint_public 1,344 9,944 1,045 (+3%) 16,768 10,936 (+1%) 524,288 457
Token:transfer 1,376 9,944 5,294 (-1%) 16,768 53,750 (+4%) 2,097,152 457
Benchmarking:create_note 1,344 9,944 1,397 N/A N/A N/A N/A
SchnorrAccount:spend_private_authwit 1,280 9,944 77.2 (-2%) N/A N/A N/A N/A
Token:unshield 1,376 9,944 3,883 N/A N/A N/A N/A
FPC:fee_entrypoint_private 1,376 9,944 4,765 N/A N/A N/A N/A

Tree insertion stats

The duration to insert a fixed batch of leaves into each tree type.

Metric 1 leaves 16 leaves 64 leaves 128 leaves 512 leaves 1024 leaves 2048 leaves 4096 leaves 32 leaves
batch_insert_into_append_only_tree_16_depth_ms 10.4 16.9 N/A N/A N/A N/A N/A N/A N/A
batch_insert_into_append_only_tree_16_depth_hash_count 16.7 31.8 N/A N/A N/A N/A N/A N/A N/A
batch_insert_into_append_only_tree_16_depth_hash_ms 0.602 0.518 N/A N/A N/A N/A N/A N/A N/A
batch_insert_into_append_only_tree_32_depth_ms N/A N/A 48.8 (+1%) 77.1 (+1%) 245 476 930 (+1%) 1,835 N/A
batch_insert_into_append_only_tree_32_depth_hash_count N/A N/A 95.9 159 543 1,055 2,079 4,127 N/A
batch_insert_into_append_only_tree_32_depth_hash_ms N/A N/A 0.498 (+1%) 0.475 (+1%) 0.444 0.444 (-1%) 0.439 0.438 N/A
batch_insert_into_indexed_tree_20_depth_ms N/A N/A 58.2 112 354 701 (-1%) 1,381 2,751 N/A
batch_insert_into_indexed_tree_20_depth_hash_count N/A N/A 106 208 692 1,363 2,707 5,395 N/A
batch_insert_into_indexed_tree_20_depth_hash_ms N/A N/A 0.503 0.503 0.479 (-1%) 0.481 (-1%) 0.478 0.478 N/A
batch_insert_into_indexed_tree_40_depth_ms N/A N/A N/A N/A N/A N/A N/A N/A 62.7
batch_insert_into_indexed_tree_40_depth_hash_count N/A N/A N/A N/A N/A N/A N/A N/A 107
batch_insert_into_indexed_tree_40_depth_hash_ms N/A N/A N/A N/A N/A N/A N/A N/A 0.554

Miscellaneous

Transaction sizes based on how many contract classes are registered in the tx.

Metric 0 registered classes 1 registered classes
tx_size_in_bytes 84,053 665,267

Transaction size based on fee payment method

| Metric | |
| - | |

@@ -3,7 +3,7 @@
# BIN: to specify a different binary to test with (e.g. bb.js or bb.js-dev).
set -eu

BIN=${BIN:-../cpp/build/bin/bb}
BIN=${BIN:-../cpp/build-debug/bin/bb}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

now that the debug build and standard build have diverged, I just changed this to debug, but maybe I can print out something that informs the user that the binary is defaulted to the debug version.

@@ -28,18 +28,15 @@ VFLAG=${VERBOSE:+-v}
RFLAG=${RECURSIVE:+-r}

echo "Write VK to file for assert_statement..."
$BIN write_vk_ultra_honk $VFLAG -c $CRS_PATH -o ./target/vk
$BIN write_vk_ultra_honk $VFLAG -c $CRS_PATH -o ./target/honk_vk
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just some name changes to separate it from the plonk vk and proof

@@ -732,8 +737,7 @@ template <IsUltraFlavor Flavor> void vk_as_fields_honk(const std::string& vk_pat

auto verification_key = std::make_shared<VerificationKey>(from_buffer<VerificationKey>(read_file(vk_path)));
std::vector<bb::fr> data = verification_key->to_field_elements();

auto json = vk_to_json(data);
auto json = honk_vk_to_json(data);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixing the vk generation for honk.

@@ -0,0 +1,21 @@
use dep::std;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

new test program that verifies 1 honk proof recursively

@@ -115,6 +112,23 @@ std::array<uint32_t, HonkRecursionConstraint::AGGREGATION_OBJECT_SIZE> create_ho

// Recursively verify the proof
auto vkey = std::make_shared<RecursiveVerificationKey>(builder, key_fields);
if (!has_valid_witness_assignments) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

second fix: we must know what recursive verifier to generate without knowing the witnesses

@lucasxia01 lucasxia01 requested a review from vezenovm June 3, 2024 15:54
Copy link
Contributor

@vezenovm vezenovm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Would be good to make these tests something more similar to double_verify_* and double_verify_nested_* as that follows the use case for recursion more closely.

Comment on lines +60 to +62
// ASSERT(static_cast<uint32_t>(circuit_size.get_value()) == key->circuit_size);
// ASSERT(static_cast<uint32_t>(public_input_size.get_value()) == key->num_public_inputs);
// ASSERT(static_cast<uint32_t>(pub_inputs_offset.get_value()) == key->pub_inputs_offset);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// ASSERT(static_cast<uint32_t>(circuit_size.get_value()) == key->circuit_size);
// ASSERT(static_cast<uint32_t>(public_input_size.get_value()) == key->num_public_inputs);
// ASSERT(static_cast<uint32_t>(pub_inputs_offset.get_value()) == key->pub_inputs_offset);
ASSERT(static_cast<uint32_t>(circuit_size.get_value()) == key->circuit_size);
ASSERT(static_cast<uint32_t>(public_input_size.get_value()) == key->num_public_inputs);
ASSERT(static_cast<uint32_t>(pub_inputs_offset.get_value()) == key->pub_inputs_offset);

Should we bring these back?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, they don't work anymore since the proof is garbage when the witnesses are not valid

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then let's delete or pass in the has_valid_witness_params field

@lucasxia01 lucasxia01 marked this pull request as ready for review June 3, 2024 16:27
@lucasxia01 lucasxia01 merged commit 1324d58 into master Jun 3, 2024
88 checks passed
@lucasxia01 lucasxia01 deleted the lx/honk-recursion-test-program branch June 3, 2024 18:09
Maddiaa0 pushed a commit that referenced this pull request Jun 5, 2024
Adds a new test Noir program verify_honk_proof that takes in a honk
proof and calls the honk recursive verifier.

Fixes a couple of errors in the flow: we shouldn't be doing vkey hash stuff when processing the vkey anymore since taht isn't being attached, and we need to be able to figure out the proof size and public input size without having valid witnesses (for the write_vk_honk flow).
Maddiaa0 pushed a commit that referenced this pull request Jun 5, 2024
Adds a new test Noir program verify_honk_proof that takes in a honk
proof and calls the honk recursive verifier.

Fixes a couple of errors in the flow: we shouldn't be doing vkey hash stuff when processing the vkey anymore since taht isn't being attached, and we need to be able to figure out the proof size and public input size without having valid witnesses (for the write_vk_honk flow).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants