feat: implement program hash integrity constraints for continuations

[avorylli]

Add mathematical constraints to prevent program hash overwriting via swap instructions when opstack size ≤ 21.

• Prevents swap operations from targeting program hash elements (st11-st15) in shallow stacks
• Provides formal constraint: swap_indicator · (n - 21) · indicator_{i≥11} = 0
• Resolves TODO in TIP-0008 section (a) Program

[aszepieniec]

Thanks for the contribution.

The instructions pick and place, which were introduced after this note was written, likewise have the capacity to disturb the program hash. So they should be included also in swap_indicator.

$(n - 21)$ is positive when $n > 21$ (stack is deep enough to protect program hash)

I'm afraid I don't see how the factor $n-21$ activates the constraint when $n \leq 21$. Rather, it looks to me like it disactivates the constraint when $n = 21$ and activates it in all other cases.

I do see how the factor max(0, 21-n) achieves this purpose, but then the question is how to represent max as an arithmetic circuit of low degree.

[aszepieniec]

I'm afraid this constraint is not complete. Counterexample: the instruction is swap 15 when $n = 22$. The constraint evaluates to $P-1 \neq 0$ meaning that this particular instruction in this particular context is not allowed. But it should be allowed because when $n = 22$ there is no risk of disturbing the program hash.

[aszepieniec]

I think it is correct now, but you've introduced another drawback: the maximum stack size is actually $P-1 = 2^{64} - 2^{32}$ which is huge when it is supposed to be a bound on the degree of an AIR constraint.

[avorylli]

made it simpler, if you don't like it, then I could probably think of something else to improve the variant before

[jan-ferdinand]

Frankly, I don't think protecting the program's hash digest against modification is necessary. In my mind, the entire program is executed by one entity. There is never any “execution handover”; for example, it is not possible to execute a different program as a subroutine of some sort (other than straight up incorporating that other program, then executing it, which means that it's not a different program).

Summarizing, with the threat model we're currently working with, I don't see additional protection we gain by disallowing write access to the program's hash digest.

In case I misunderstand your, @avorylli, intentions, would you mind opening an issue? There might be other possible solutions to discuss before deciding on a strategy to implement them.

[aszepieniec]

This PR attempts to fill in details in TIP-0008, which proposes a construction for continuations. In that context, there is a notion of handover of execution control between separate entities -- these entities each prove separate chunks of the long-running computation. So we do need to protect the program digest.

[jan-ferdinand]

Oh, I see! I hadn't realized this was about continuations. Thanks for clarifying.