Add Recursive Batch-STARK Verifier Circuits

[sai-deng]

Also removed MMCS from the batch proof.

[Nashtare]

Maybe worth renaming as it also contains the removal of MMCS?

[sai-deng]

Maybe worth renaming as it also contains the removal of MMCS?

It did not completely remove MMCS. Just removed it from BatchProof to make the circuit simpler.

[Nashtare]

To reply to your last comment

It did not completely remove MMCS. Just removed it from BatchProof to make the circuit simpler.

I find it quite confusing tbh. Either we remove MMCS altogether in this PR or we keep it in both regular and batch proof until future removal. Also note that it makes your approach look simpler, but that's because you're abstracting away the handling of non-primitive ops at runtime.

[sai-deng]

To reply to your last comment

It did not completely remove MMCS. Just removed it from BatchProof to make the circuit simpler.

I find it quite confusing tbh. Either we remove MMCS altogether in this PR or we keep it in both regular and batch proof until future removal. Also note that it makes your approach look simpler, but that's because you're abstracting away the handling of non-primitive ops at runtime.

My goal is to keep this PR as simple as possible. Why are we adding it to the recursion circuits if this table will be removed soon?

[Nashtare]

My point was rather to remove it from the rest of the codebase, as you already started doing it, otherwise the PR looks half done.

[sai-deng]

My point was rather to remove it from the rest of the codebase, as you already started doing it.

That would make the PR very large and distract from the main goal of this one.

[Nashtare]

You could always do it on a separate PR targeting this branch, so that both can be reviewed / merged together before landing into main. That keeps PRs light, without having the inconsistency that the current PR brings to main.

We must strive to keep the codebase as clean and understandable as possible for external developers too. I don't think the argument "I removed MMCS only here because it makes things simpler" is valid. In that case, we can first merge a PR removing it altogether, and then we review this PR, which will remain clean and light?

[sai-deng]

You could always do it on a separate PR targeting this branch, so that both can be reviewed / merged together before landing into main. That keeps PRs light, without having the inconsistency that the current PR brings to main.

We must strive to keep the codebase as clean and understandable as possible for external developers too. I don't think the argument "I removed MMCS only here because it makes things simpler" is valid. In that case, we can first merge a PR removing it altogether, and then we review this PR, which will remain clean and light?

I disagree. MMCS is currently the only non-primitive operation in the system, and I think it would be better to refactor it into circuits rather than fully removing it right now, to avoid introducing unnecessary simplifications. Also, we can’t really keep the codebase clean at this moment, since the MMCS refactor is blocked by the Poseidon table work.

[Nashtare]

Just to clarify, by fully removing it I meant removing the dedicated table, not the logic. Removing it plainly would just be a step back.

But I think we need to clarify on how we want to iterate over the codebase, because this is getting messy. I disagree about the fact that we cannot keep the codebase clean, it's just less "trivial" but it's an effort worth doing, as it also forces us to take into considerations other factors that may be outside the scope of our respective PRs.

[Nashtare]

I don't want to be blocking your work for too long if that conversation goes on, so I won't insist further, but I strongly believe this is a discussion worth having and sooner than later.

[sai-deng]

I don't want to be blocking your work for too long if that conversation goes on, so I won't insist further, but I strongly believe this is a discussion worth having and sooner than later.

I agree that we should decide on a clear direction for how to handle MMCS going forward, because right now the partial state creates some confusion.

For this PR though, my goal is still to keep the recursion batch verifier focused and reviewable. I’d prefer not to bundle a wider MMCS removal/refactor into it, since that would introduce a lot of unrelated changes and make reviewing harder.