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!: integrate AVM proving #6775

Merged
merged 5 commits into from
May 31, 2024
Merged

feat!: integrate AVM proving #6775

merged 5 commits into from
May 31, 2024

Conversation

fcarreiro
Copy link
Contributor

No description provided.

Copy link
Contributor Author

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @fcarreiro and the rest of your teammates on Graphite Graphite

/**
* Generates proofs for the public and public kernel circuits.
*/
export interface PublicProver {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Was unused.

*/
publicKernelRequests: PublicKernelRequest[];
publicProvingRequests: PublicProvingRequest[];
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I had discussed with Phil this rename.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We need this to be separate because the AVM cannot prove any bytecode right now. However, it CAN prove add_args. So that's what we are proving here. As we start proving more, we can change the method.

In other e2e tests (e.g., e2e_prover), avm proving IS enabled, but it does not throw if it fails.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Note for myself: add this to the CI.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, it's already there. The e2e test runs everything under e2e_prover.

@@ -525,9 +525,19 @@ void avm_prove(const std::filesystem::path& bytecode_path,
auto const [verification_key, proof] = avm_trace::Execution::prove(avm_bytecode, call_data);
// TODO(ilyas): <#4887>: Currently we only need these two parts of the vk, look into pcs_verification key reqs
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This has to be solved at some point. Also related to: #6773

@@ -144,8 +151,7 @@ export async function generateKeyForNoirCircuit(
result = await executeBB(pathToBB, `vk_as_fields`, asFieldsArgs, log);
}
const duration = timer.ms();
// Cleanup the bytecode file
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it's better if the inputs (and outputs) are not cleaned up here. It's already done by the caller.

@@ -591,8 +591,8 @@ async function fsCache<T>(
} else {
try {
run = !expectedCacheKey.equals(await fs.readFile(cacheFilePath));
} catch (err) {
if (err && err instanceof Error && 'code' in err && err.code === 'ENOENT') {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

From a discussion with Alex. See nodejs/node#31852

@AztecBot
Copy link
Collaborator

AztecBot commented May 30, 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,706 1,548 708 773 (+3%) 770 (-1%)
proof_construction_time_sha256_30_ms 11,380 3,066 (+1%) 1,370 1,414 (-1%) 1,456
proof_construction_time_sha256_100_ms 43,578 11,708 5,430 5,403 5,353
proof_construction_time_poseidon_hash_ms 78.0 34.0 34.0 58.0 (+2%) 87.0 (+1%)
proof_construction_time_poseidon_hash_30_ms 1,515 415 200 (+1%) 224 265
proof_construction_time_poseidon_hash_100_ms 5,739 1,559 723 773 (+1%) 792

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,464 9,476
l1_rollup_execution_gas 616,093 616,105 616,117
l2_block_processing_time_in_ms 1,292 4,824 9,589
l2_block_building_time_in_ms 44,252 174,634 348,556
l2_block_rollup_simulation_time_in_ms 44,054 173,904 347,103
l2_block_public_tx_process_time_in_ms 40,889 (+7%) 170,667 343,747 (+1%)

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,519 (+1%) 14,520
node_database_size_in_bytes 14,499,920 21,364,816
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 133 (-4%) 469 (+1%) 12,974 (+3%) 20,634 64,614 89,536 2,731 524,288
private-kernel-inner 405 933 49,595 (+1%) 92,326 64,614 89,536 2,731 2,097,152
private-kernel-tail 580 (-2%) 2,571 (-1%) 53,731 (+5%) 96,545 77,732 11,648 297 2,097,152
base-parity 6.44 1,019 2,871 128 64.0 2,208 2.00 131,072
root-parity 48.7 60.4 (-2%) 38,945 (-5%) 27,100 64.0 2,720 18.0 2,097,152
base-rollup 8,897 (-5%) 2,376 (-1%) 79,085 (+4%) 119,738 756 3,648 47.0 4,194,304
root-rollup 109 74.5 (-1%) 23,950 (+5%) 25,309 620 3,456 41.0 1,048,576
public-kernel-app-logic 567 (-1%) 3,427 (-3%) 44,971 (-5%) 108,073 86,550 116,768 3,582 2,097,152
public-kernel-tail 1,115 (-1%) 23,503 (-1%) 175,913 (-6%) 403,238 7,646 11,648 297 8,388,608
private-kernel-reset-small 587 (-1%) 1,905 (-3%) 45,406 120,737 64,614 89,536 2,731 2,097,152
public-kernel-setup 652 (-1%) 2,690 (-1%) 44,572 (-1%) 108,073 86,550 116,768 3,582 2,097,152
public-kernel-teardown 563 3,472 (-1%) 43,972 (-3%) 108,073 86,550 116,768 3,582 2,097,152
merge-rollup 28.9 (-8%) N/A N/A 16,542 756 N/A N/A N/A
private-kernel-tail-to-public N/A 8,325 (-6%) 101,094 (+2%) 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 457 N/A N/A N/A N/A
ContractInstanceDeployer:deploy 1,408 9,944 40.8 N/A N/A N/A N/A
MultiCallEntrypoint:entrypoint 1,920 9,944 1,751 N/A N/A N/A N/A
SchnorrAccount:constructor 1,312 9,944 1,408 (-1%) N/A N/A N/A N/A
SchnorrAccount:entrypoint 2,304 9,944 2,740 16,768 53,324 2,097,152 457
Token:privately_mint_private_note 1,280 9,944 1,530 (-2%) N/A N/A N/A N/A
FPC:fee_entrypoint_public 1,344 9,944 1,016 16,768 10,839 524,288 457
Token:transfer 1,376 9,944 5,244 (-2%) 16,768 52,080 (+1%) 2,097,152 457
Benchmarking:create_note 1,344 9,944 1,400 N/A N/A N/A N/A
SchnorrAccount:spend_private_authwit 1,280 9,944 80.7 (+3%) N/A N/A N/A N/A
Token:unshield 1,376 9,944 3,952 (+2%) N/A N/A N/A N/A
FPC:fee_entrypoint_private 1,376 9,944 4,844 (+1%) 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.3 (-1%) 17.1 (+1%) 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.598 (-1%) 0.514 (-1%) 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.3 76.3 248 (+1%) 476 930 (+1%) 1,842 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.493 0.470 0.449 (+1%) 0.444 (-1%) 0.441 0.440 N/A
batch_insert_into_indexed_tree_20_depth_ms N/A N/A 58.0 114 (+2%) 357 (+1%) 702 (-1%) 1,389 2,766 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.501 0.509 (+1%) 0.484 0.481 (-1%) 0.481 0.480 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.6
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.553

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 | |
| - | |

Copy link
Contributor

@dbanks12 dbanks12 left a comment

Choose a reason for hiding this comment

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

LGTM! Nice work! We should probably get @alexghr 's review on this before merging.

Comment on lines +25 to 33
/** Full path of the public key. */
pkPath?: string;
/** Base directory for the VKs (raw, fields). */
vkPath?: string;
/** Full path of the proof. */
proofPath?: string;
/** Full path of the contract. */
contractPath?: string;
};
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

inputSize: input.toBuffer().length,
circuitSize: verificationKey.circuitSize,
numPublicInputs: verificationKey.numPublicInputs,
} satisfies CircuitProvingStats,
Copy link
Contributor

Choose a reason for hiding this comment

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

TIL keyword satisfies....

yarn-project/bb-prover/src/test/test_circuit_prover.ts Outdated Show resolved Hide resolved
/**
* Simpler version of FullProverTest.
*/
export class FullProverTestAvm {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can't pull some of this into a shared parent class with FullProverTest? Fine if not!

Copy link
Contributor

Choose a reason for hiding this comment

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

Will this separate test class still exist after the AVM can prove everything?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah I see, the difference isn't just that it's testing the AVM, it's that it's using the AVM test contract and just doing addArgsReturn. You can probably ignore these comments! I guess once the AVM can prove everything, we can use this class for the simple test, and the other (more full) class for the token test (possibly with modifications if necessary?)

Comment on lines -116 to +169
abstract handle(
tx: Tx,
publicKernelPublicInputs: PublicKernelCircuitPublicInputs,
): Promise<{
/**
* The collection of public kernel requests
*/
kernelRequests: PublicKernelRequest[];
/**
* the output of the public kernel circuit for this phase
*/
publicKernelOutput: PublicKernelCircuitPublicInputs;
/**
* the final output of the public kernel circuit for this phase
*/
finalKernelOutput?: KernelCircuitPublicInputs;
/**
* revert reason, if any
*/
revertReason: SimulationError | undefined;
returnValues: NestedProcessReturnValues[];
/** Gas used during the execution this particular phase. */
gasUsed: Gas | undefined;
}>;
abstract handle(tx: Tx, publicKernelPublicInputs: PublicKernelCircuitPublicInputs): Promise<PhaseResult>;
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice cleanup

let gasUsed = Gas.empty();

let kernelPublicOutput: PublicKernelCircuitPublicInputs = previousPublicKernelOutput;
Copy link
Contributor

Choose a reason for hiding this comment

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

We pretty much renamed kernelOutput to kernelPublicOutput here. Should it be publicKernelOutput? Otherwise I'm not sure the word public is adding any value here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I struggled to make sense of this. The original code (well, and this one) actually handle 2 types of outputs/inputs for the kernel:

  1. the PublicKernelPrivateInputs (which are put into the private proving info); and
  2. the PublicKernelPublicInputs (which are used/returned as single kernelOutputs)

the idea to use public here was to make it evident that these were the PUBLIC kernel PUBLIC inputs/outputs (and not the private ones).

Copy link
Contributor

@alexghr alexghr left a comment

Choose a reason for hiding this comment

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

Looks great! :shipit:

@@ -278,7 +299,7 @@ export class BBNativeRollupProver implements ServerCircuitProver {
workingDirectory: string,
): Promise<{ circuitOutput: Output; vkData: VerificationKeyData; provingResult: BBSuccess }> {
// Have the ACVM write the partial witness here
const outputWitnessFile = `${workingDirectory}/partial-witness.gz`;
const outputWitnessFile = path.join(workingDirectory, 'partial-witness.gz');
Copy link
Contributor

Choose a reason for hiding this comment

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

❤️

} else {
logger.warn(`Error thrown when proving AVM circuit: ${err}`);
logger.warn(`AVM_PROVING_STRICT is off, faking AVM proof and carrying on...`);
return { proof: makeEmptyProof(), verificationKey: VerificationKeyData.makeFake() };
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this work because the public kernels do not aggregate on the avm proof?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes! The public kernels are, AFAIK, currently not taking any VM proof as input. This is because there's still no support for recursive verification for honk proofs in noir. When that changes, this should change. Hopefully we're feature-complete by then!

yarn-project/prover-client/src/prover-pool/prover-agent.ts Outdated Show resolved Hide resolved
@fcarreiro fcarreiro force-pushed the fc/avm-proving branch 2 times, most recently from 2e8c302 to f027c6c Compare May 31, 2024 10:55
@fcarreiro fcarreiro merged commit f1512a2 into master May 31, 2024
87 of 88 checks passed
@fcarreiro fcarreiro deleted the fc/avm-proving branch May 31, 2024 14:09
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.

5 participants