honk e2e: revive kernel_prover.test.ts #7374
Comments
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 <[email protected]> Co-authored-by: ledwards2225 <[email protected]> Co-authored-by: lucasxia01 <[email protected]> Co-authored-by: maramihali <[email protected]>
|
Looks alive, closing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This used a lot of mocking so was brittle to big refactoring - needs a maintenance decision
The text was updated successfully, but these errors were encountered: