Fix how we handle public inputs in Tube circuit

[lucasxia01]

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.

[ludamad]

@Rumata888 can you add more details here? I recall you thinking this was tricky

[Rumata888]

There are two problems right now:

1. Recursive verifiers take a vector of field elements as inputs, construct the transcript from them and only after that recursively verify the proof. The current architecture doesn't allow checking the correctness of those field elements (that the transcript in the decider corresponds to the Translator transcript, for example). We don't have access to those elements in circuit field form, so we can't set that as public input
2. The concept of the public input of the circuit and the context of results of the folding proof differ. It is ambiguous right now in the protocol what we want the Tube to present as public inputs. If the public inputs are just the public inputs of the last folding proof then it can become a problem, because technically two folding proofs can have the same public inputs and if we export just those it might not be possible to correctly pick the original ClientIVC proof that produced those. So technically what we need to export is probably at least the folding proof transcript. Maybe we need to show everything that we are recursively verifying as public inputs.

[ledwards2225]

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:

• a ClientIvc Proof contains a FoldProof which contains the explicit public inputs of the final circuit in the IVC (kernel tail or whatever)
• These public inputs are extracted in the ProtoGalaxyRecursiveVerifier (part of the ClientIvc recursive verifier, aka the tube) where they become private witnesses by default
• These witnesses must be explicitly converted to public inputs in that circuit (e.g. builder->set_public_input(pub_input.get_witness_index()) )
• This will result in those public inputs being explicitly added to the Tube circuit proof which gets sent to the base rollup circuit
• The base rollup circuit extracts the public inputs from the proof and uses them for Azteky checks as needed

[codygunton]

@ledwards2225 this will be closed by an upcoming PR of @sirasistant right? Or will that PR only pave the way for a final PR to fix this issue?

[ledwards2225]

@ledwards2225 this will be closed by an upcoming PR of @sirasistant right? Or will that PR only pave the way for a final PR to fix this issue?

This is unrelated to any ongoing work - I think you're thinking of the linking of the public inputs between noir witnesses and the witnesses in the recursive verifiers which is indeed completed by Alvaros recent merge but incidentally was never needed in the first place since the databus replaced the pub inputs.

[ledwards2225]

As of writing this things are closer to being correct than the original description suggests. The public inputs of the tail kernel are propagated from the hiding circuit to the tube circuit (then presumably they are used for some checks in the base rollup). At least one remaining issue is that in the tube circuit the public inputs extracted from the proof are not properly connected to those in the stdlib proof used in the recursive verifier. We instead need to create witnesses from the proof to be passed into the recursive verifier then call set public on those witnesses corresponding to the public inputs. This likely involves updating all of the recursive verifiers involved in CIVC recursive verification to consume a stdlib proof (instead of a native one that is internally converted to witnesses).

Update: the public inputs are now properly extracted from the stdlib proof.

[ledwards2225]

Referring to @Rumata888's original concerns, (1) is now handled properly. (2) needs further consideration

[Rumata888]

What do we do about checking that we handled the correct proof? Is it published completely as public inputs? Do we hash it a bit more and use that?

[federicobarbacovi]

Update: (1) is handled correctly (as per Luke's comment) (2) has been investigated, and it is not a problem. See explanation below.

Unless there are outstanding issues or clarifications needed, I will close this issue tomorrow (20/08/2025) @ledwards2225 @Rumata888

More details on (2):

1. Each transaction in Aztec is uniquely identified via its tx hash (which is the hash of the entire transaction simulation, see here).
2. No two tx with the same tx hash can ever be added to Aztec, as all transactions are required to produce a nullifier, and nullifiers are unique. See also here.
3. The tx hash uniquely identifies what the transaction has done (public calls, nullifiers added, header against which the tx was proven, etc.). It does not identify the proof which was submitted.

Prove nodes request ClientIVC proofs based on the tx hash. It doesn't matter which proof is submitted when this request arrives, as long as the proof is valid (see also here). The point is that the ClientIVC proof doesn't contain any information as to what the transaction is doing. The actions carried out by the transactions are uniquely identified by the tx hash.

In conclusion, the Tube proof/Base rollup proof doesn't need to contain a footprint of the proof it is recursively verifying, because the proof is only witness to the fact that the actions performed by the transaction are valid, not what these actions are.