IPA Solidity unit-test generator

[storojs72]

This PR is a first step to solve verifier's Rust <-> Solidity compatibility problem (#337)

With a help of Handlebars templating engine this PR adds IPA unit-test which dynamically generates exact ipa.t.sol from our Solidity verifier (checked manually by running forge tests in Solidity with Solidity file generated by Rust).

How to run?

In order to create ipa.t.sol directly from Rust (Arecibo) environment I used following commands:

cargo test test_solidity_compatibility_ipa --release -- --ignored --nocapture > ipa.t.sol
cat ipa.t.sol | sed '1,3d' | sed -n -e :a -e '1,4!{P;N;D;};N;ba' > tmp.file && mv tmp.file ipa.t.sol

The ignored test test_solidity_compatibility_ipa is invoked and its stdout is redirected to the ipa.t.sol file with a little subsequent truncations of irrelevant lines.

Sidenote

It is possible to vary number of variables and test_solidity_compatibility_ipa can produce correspondent IPA test-vector which is useful for detecting upper-bound gas cost experiments.

P.S. As it is mentioned in #337, IPA now is a first building block that supports dynamic IO generation directly from Rust, and we can experiment with CI enforcements using it as an example in order to derive optimal compatibility rules for every stakeholder.
cc @samuelburnham

[huitseeker]

It would be great to add this to the code base, but the current setup is quite invasive to the existing source files.

What about the following organization instead?

src/
└── provider/
    ├── mod.rs                # The main module file for `provider`
    └── tests/
        ├── mod.rs            # The main module file for test utilities within `provider`
        └── ipa_pc.rs         # Test file for IPA polynomial commitment solidity tests within `provider`

This isn't meant to replace the current test organization (which is often useful because it can access private fields), but is a complement to the existing one.

[huitseeker]

I think pub (in crate::provider) would suffice.

[huitseeker]

Shouldn't this be a dev-dependency instead?

[huitseeker]

Back to your queue for the file hierarchy changes requested in #341 (review)

[storojs72]

Back to your queue for the file hierarchy changes requested in #341 (review)

In this case, we will need to make even more fields public (ck_v, ck_s of VerifierKey and L_vec, R_vec, a_hat of InnerProductArgument) in order to access them from different module. Is that acceptable?

[huitseeker]

In this case, we will need to make even more fields public (ck_v, ck_s of VerifierKey and L_vec, R_vec, a_hat of InnerProductArgument) in order to access them from different module. Is that acceptable?

Rust supports pub (in crate::provider), which is fine, and pub (crate) if you must.

[tchataigner]

LGTM!

[huitseeker]

🙏