-
Notifications
You must be signed in to change notification settings - Fork 94
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
Fix how we handle public inputs in Tube circuit #1048
Comments
@Rumata888 can you add more details here? I recall you thinking this was tricky |
There are two problems right now:
|
Aside from the security caveats above, this is a basic description of what needs to be done to pipe the right public inputs into the base rollup: The base rollup circuit needs to perform some checks on the public inputs of the tail private kernel. With the Honk integration / introduction of the Tube circuit, the public inputs connection was broken. What needs to happen is roughly the following:
|
**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>
**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 - #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>
We currently just add some (correct amount of) public inputs as new variables to the builder when constructing the Tube circuit. However, we need to set witnesses (from the folding proof) to be public inputs instead.
The text was updated successfully, but these errors were encountered: