You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ultra ecc op subtable columns t_j, j = 1,2,3,4 are committed to by the PG prover in CIVC (Mega). These commitments (received by the PG recursive verifier) must be connected to those used in the merge recursive verifier at the same step. The easiest way to do this is just to store the commitments from the PG verifier to be reused in the merge.
The text was updated successfully, but these errors were encountered:
Another thing that comes to mind: Let k_j be the length of t_j. We likely need to establish a connection between k_j implicitly encoded in the selector lagrange_ecc_op and the k_j used in the merge. Otherwise I don't think there's anything stopping the prover from merging t_j with T_{j,prev} in an overlapping way. The way to do this might be to bake k_j into the VK and use it both locations. (Can the verifier efficiently evaluate lagrange_ecc_op from knowledge of k_j?)
The ultra ecc op subtable columns t_j, j = 1,2,3,4 are committed to by the PG prover in CIVC (Mega). These commitments (received by the PG recursive verifier) must be connected to those used in the merge recursive verifier at the same step. The easiest way to do this is just to store the commitments from the PG verifier to be reused in the merge.
The text was updated successfully, but these errors were encountered: