-
Notifications
You must be signed in to change notification settings - Fork 272
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: Epoch orchestrator #8614
base: master
Are you sure you want to change the base?
feat: Epoch orchestrator #8614
Conversation
25dedf6
to
0a4558f
Compare
const previousKernelProof = await this.previousKernelProof.promise; | ||
const avmProof = await this.nestedAvmProof.promise; | ||
|
||
// TODO: The kernel does not require the AVM VK, we're just getting the proof. Is that correct? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it will require the VK. Maybe it doesn't now because we don't recursively verify the AVM proof, but we will do.
const avmProof = await this.nestedAvmProof.promise; | ||
|
||
// TODO: The kernel does not require the AVM VK, we're just getting the proof. Is that correct? | ||
// TODO(#7369): How should we properly set up vkPath, vkIndex, and clientIvc for previous kernel? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I follow. All of the public kernels are recursively verified at the moment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, but public kernels require not just the recursive proof and vk, but also the vkPath, vkIndex, and clientIvc:
aztec-packages/yarn-project/circuits.js/src/structs/kernel/public_kernel_data.ts
Lines 21 to 41 in a098d41
/** | |
* Proof of the previous kernel. | |
*/ | |
public proof: RecursiveProof<typeof NESTED_RECURSIVE_PROOF_LENGTH>, | |
/** | |
* Verification key of the previous kernel. | |
*/ | |
public vk: VerificationKeyData, | |
/** | |
* Index of the previous kernel's vk in a tree of vks. | |
*/ | |
public vkIndex: UInt32, | |
/** | |
* Sibling path of the previous kernel's vk in a tree of vks. | |
*/ | |
public vkPath: Tuple<Fr, typeof VK_TREE_HEIGHT>, | |
/** | |
* TODO(https://github.com/AztecProtocol/aztec-packages/issues/7369) this should be tube-proved for the first iteration and replace proof above | |
*/ | |
public clientIvcProof: ClientIvcProof = ClientIvcProof.empty(), |
However, in the current orchestrator, only proof and vk are set:
aztec-packages/yarn-project/prover-client/src/orchestrator/tx-proving-state.ts
Lines 87 to 89 in a098d41
// pass both the proof and verification key forward to the next circuit | |
nextFunction.publicKernelRequest.inputs.previousKernel.proof = proof; | |
nextFunction.publicKernelRequest.inputs.previousKernel.vk = verificationKey; |
if (!this.context.options.simulationOnly) { | ||
void job | ||
.prove() | ||
.then(proof => rootParityJob.setNestedProof(proof, index)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm having difficulty understanding the general flow. I can see here we update the nested proof for each base parity, what kicks off the root parity once the final base parity is completed?
eeef089
to
35a0494
Compare
59cd9bb
to
3773e64
Compare
3773e64
to
54ece9e
Compare
Adds a new decorator for memoizing results. Extracted from #8614.
Paused in favor of #8675