Plonky3 keccak optimization

[qwang98]

Issue
#1832 is ready to be merged, but currently uses 100 links to increment memory pointer using add_sub machine, which is quite inefficient for proving. increment_ptr constraint API won't work in #1832, as explained in issue #2022. It succeeds at the witness generation stage but fails at the proving/verification stage, depending on which prover is used.

Solution Implemented
This PR aims to implement the same increment pointer logic without relying on increment_ptr, by directly implementing the constraints in the Keccak main machine. On the high level, instead of creating carry and inverse columns, which is used to check if the next memory address will overflow using a zero check, I moved these two columns to the second and the penultimate (second last) rows of each 24 row blocks. Because addr_h[50] and addr_l[50] only uses the first and last row of each block, I put the inverse values a row below/above the first/last row of addr_l[50] and the carry values a row below/above the first/last row of addr_h[50]. This solution should be more efficient than the increment_ptr API in the context of this machine, because we avoid creating 50 inverse columns and 50 carry columns. It also solves the prior issue with increment_ptr mentioned in #1832 by only enabling the is zero check constraint in proper rows.

Current Status
Witness generation is functional, proving works with Halo2 mock prover when using dynamic vadcop limiting dynamic machines to min_degree: 1024, max_degree: 2048 (though not setting this limit kills the process after a very long run). Proving doesn't work with Plonky3 (see CI error). It's a polynomial commitment scheme on commit polynomial evaluation. I never reached a constraint error for Plonky3, which is what blocked our prior increment_ptr solution, but this could mean that we didn't even reach the stage for constraint errors. Previously Plonky3 errored out at verification stage.

I think this means that the implementation is correct, but am not sure how to debug the Plonky3 error. It seems that we might be able to just set some external parameters regarding size to make this work, so I'd appreciate some insights.

Here's my Plonky3 error:

Running `target/release/powdr pil test_data/std/keccakf16_memory_test.asm --force --field bb --prove-with plonky3`
[00:02:23 (ETA: 00:00:00)] ████████████████████ 100% - 102469 rows/s, 1639k identities/s, 100% progress                                                                                                                                                                             thread 'main' panicked at /Users/steve/.cargo/git/checkouts/plonky3-2a8c63bcd5ef83b0/2192432/fri/src/two_adic_pcs.rs:186:9:
assertion failed: lde.height() >= domain.size()

Additional Questions
Do we have a CLI option to provide the witness in future runs after it's generated in a specific run? I couldn't find an example from our official docs. This has been costing quite a bit of time as I was good with the witness but just wanted to test the prover with different parameters.

[qwang98]

Here are the relevant changes: https://github.com/powdr-labs/powdr/pull/2089/files#diff-f9fcf1597f4c7e16da854fd1ded4cbcfed738cc44655382ec0cec5140701f8e9R60-R107

[qwang98]

It's also based on a different commit from #1832 so a few comments addressed in that PR are not addressed here, as it's quite non trivial to move them here. I'd wait for that PR merged to merge main to this.

[georgwiese]

Can be rebased now :)

The error you have looks like a constraint has a too high degree. The error message is terrible, so I just opened #2091 to fix it.

[qwang98]

Can be rebased now :)

The error you have looks like a constraint has a too high degree. The error message is terrible, so I just opened #2091 to fix it.

Thanks and that makes sense. It gotta be the degree-4 constraint I added then (https://github.com/powdr-labs/powdr/pull/2089/files#diff-f9fcf1597f4c7e16da854fd1ded4cbcfed738cc44655382ec0cec5140701f8e9R67-R69), because prior versions with degree-3 constraints worked.

However, it's confusing from the Plonky3 doc that they seem to support arbitrary high degree, so in theory degree 4 constraint should work here, but with a proving time cost: https://docs.polygon.technology/learn/plonky3/examples/rangecheck/#constraint-degree

I'm not sure for folks writing Plonky3 circuits, are we concerned about the degree of constraints and what's the max degree we are targeting for so far? @leonardoalt

[georgwiese]

So, currently in Plonky3, there is a dependency between the "blow up" parameter of FRI (which we set to 2) and the maximum degree (for this parameter, it would be 3). Otherwise this assertion fails. From the TODO comment above the assertion I conclude that it doesn't have to be like this, but right now it is...

But a degree bound of 3 seems to a typical choice (our parameters are inspired from Plonky3's examples), so I think we should make it work for a bound of 3. You can always make it work by introducing more witness columns.

BTW, in the future, this should be done automatically (see section "Intermediate polynomials can be turned into witness polynomials to reduce the constraint degree" in #2009). But currently, it still needs to be done manually.

[qwang98]

So, currently in Plonky3, there is a dependency between the "blow up" parameter of FRI (which we set to 2) and the maximum degree (for this parameter, it would be 3). Otherwise this assertion fails. From the TODO comment above the assertion I conclude that it doesn't have to be like this, but right now it is...

But a degree bound of 3 seems to a typical choice (our parameters are inspired from Plonky3's examples), so I think we should make it work for a bound of 3. You can always make it work by introducing more witness columns.

BTW, in the future, this should be done automatically (see section "Intermediate polynomials can be turned into witness polynomials to reduce the constraint degree" in #2009). But currently, it still needs to be done manually.

Fully makes sense now. Technically I can make it work by sticking data to the next next row of the first row and the third last row, but might need to do hints to make witgen more efficient. I might also just use more columns if needed.