-
Notifications
You must be signed in to change notification settings - Fork 270
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
honk e2e: Improve structure of pxe/kernel_prover after move to honk+ivc #7368
Labels
Comments
ludamad
changed the title
Naming and structure improvements after honk+IVC integration
Improve structure of pxe/kernel_prover after move to honk+ivc
Jul 5, 2024
ludamad
changed the title
Improve structure of pxe/kernel_prover after move to honk+ivc
honk e2e: Improve structure of pxe/kernel_prover after move to honk+ivc
Jul 5, 2024
ludamad
added a commit
that referenced
this issue
Jul 11, 2024
**THE AWESOME:** PXE uses ClientIVC. Public kernels, rollup, and parity circuits use vanilla recursion-based IVC using UltraHonk. 🎉 Linear time proofs without FFTs, better constraint counts for poseidon (eventually) and no recursion in the private kernel circuits **THE CAVEATS:** This merges with many TODOs to reinstate functionality, improve security and performance. - If you are lead to believe honk proofs are constant-sized, you have been fed lies We are rounding up to a proof size that allows 2**28 gates. Please take effort to NOT rely on this assumption, as it is just a stop-gap. It is OK to temporarily rely on this to simplify kernel development in particular, but we should not hard-code this assumption into e.g. typescript in the future - Things are a bit slower now, not faster We prioritized correctness and any slowdowns will be investigated soon. Some of it comes from the larger constant size proof. As well, we will soon be able to drop constraint count in poisedon with UH - Transcript hashing is not yet in place - #7410 Alvaro's recent work with the VK tree had to be partially undone (aka the parts that made it really validate in kernels, so most of it for now) because our tube VK currently cannot be written ahead of time. What's more, correctly handling log-sized proofs will mean many tube and kernel VKs in the future. This will need a pass. - #7374 This test used a lot of mocking and was stubbed out in the interest of time. It's not necessarily hard to bring back. - #7373 We need one soon. The relevant deploying functionality has been commented out for now with this issue linked. - #7372 This needs to be double-checked for current kernel proof, but we will do this post-merge with a pass on observability - #7371 We need to figure out how to get this program stack bincode-encoded in the future - #7370 Right now redundant VKs are serialized with the client ivc proofs - #7369 Related to #7410, currently tube proving is too unlike the rest of the pattern - #7368 It's currently a bit of a mess of grabbing bytecode artifacts with ad-hoc logic - AztecProtocol/barretenberg#1048 Inputs should be passed to the tube circuit correctly, but they are NOT currently used. Fixing this should be contained within bb --------- Co-authored-by: codygunton <codygunton@gmail.com> Co-authored-by: ledwards2225 <l.edwards.d@gmail.com> Co-authored-by: lucasxia01 <lucasxia01@gmail.com> Co-authored-by: maramihali <mara@aztecprotocol.com>
This is still relevant looking at pxe/kernel_prover.ts |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: