This is great!

I had a quick look at the code and I am a bit confused how we'd use this in the bitvm setup. It seems like groth16_verify_to_segments is the main function to calculate the segments. However, this function takes as input the program proof and the public inputs. In a bridging setup, these are not known when setting up the scripts - these are to be input later on via bit commitments. Is supporting such a setup still to-do at the moment, or am I missing something?

I had a quick look at the code and I am a bit confused how we'd use this in the bitvm setup. It seems like groth16_verify_to_segments is the main function to calculate the segments. However, this function takes as input the program proof and the public inputs. In a bridging setup, these are not known when setting up the scripts - these are to be input later on via bit commitments. Is supporting such a setup still to-do at the moment, or am I missing something?

In general the idea is to reuse code for the compilation step in the actual evaluation/assert/disprove step. Thus, at compile time one can provide a placeholder proof that will only change the hints but alwasy return the same scripts. At run time the correct proof is provided which will fill in the correct hints.

Good point! The segments should work as Lukas mentioned. We are trying to add more unit test cases to show the placehoder works as Lukas mentioned.

Thank you guys. That's amazing work!

When I run the test_hinted_groth16_verifier it creates 1071 segments. I noticed in the code that the segments may have multiple inputs and outputs. So as I understand we might need even more than 1071 commitments in the assert transaction. Is my assumption correct? Do you know how many there are?

Thank you guys. That's amazing work!

When I run the test_hinted_groth16_verifier it creates 1071 segments. I noticed in the code that the segments may have multiple inputs and outputs. So as I understand we might need even more than 1071 commitments in the assert transaction. Is my assumption correct? Do you know how many there are?

The code was updated, now segments size is 975 and commitments size is 1079.

Good point! The segments should work as Lukas mentioned. We are trying to add more unit test cases to show the placehoder works as Lukas mentioned.

We add a new test case 'test_hinted_groth16_verifier_stable' located in src/chunker/chunk_groth16_verifier.rs, which could show the placeholder works. @sander2 @lucidLuckylee

Thank you guys. That's amazing work!
When I run the test_hinted_groth16_verifier it creates 1071 segments. I noticed in the code that the segments may have multiple inputs and outputs. So as I understand we might need even more than 1071 commitments in the assert transaction. Is my assumption correct? Do you know how many there are?

The code was updated, now segments size is 975 and commitments size is 1079.

The assert transaction will be about 3.6M (by using Winternize Signature and 16-byte version Blake3 Hash) and each slash transaction will be under the limitations of Bitcoin's consensus rules, including stack depth and the total size of witnesses and scripts.