Load G1 and G2 points from a file rather than relying on the setup function

[belijzajac]

Summary

We're using Arkworks at sifraitech/rust-kzg and are currently undergoing a migration to EIP-4844 by using ethereum/c-kzg-4844 as a reference. The said implementation loads trusted setups from files, e.g., trusted_setup.txt, that hold the following information:

G1Count | G2Count | [G1] | [G2]

On the contrary, Arkworks invokes the method kzg10::setup and feeds it a RngCore object to generate the setup, which is not as secure as loading the precomputed G1 and G2 points from a file.

Problem Definition

As far as I'm understanding, powers_of_g and powers_of_gamma_g are responsible for holding G1 and G2 points, respectively. But as you can see, the type of powers_of_gamma_g is BTreeMap::<usize, G1Affine>, which by definition cannot hold G2 points. We attempted to replace the values of powers_of_g with G1 points loaded from a setup file, but we are unsure of where to put the G2 points.

Proposal

Allow us to load G1 and G2 points from a file rather than relying on the setup function.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[ToufeeqP]

This would be very helpful

[mmagician]

In general for most schemes in this repo the setup function is meant for convenient setup (e.g. for testing) and not for production use - instead, you should supply your own universal parameters and pass them to the trim function to obtain the committer/verifier keys.

Alternatively, you can supply CK/VK directly, but I think it's more convenient.

The universal parameters implement CanonicalDeserialize so you should be able to load these from a file, instead.

[belijzajac]

I don't work on the project anymore, but the way we accomplished things in the recent PR was by ditching Arkworks functions and computing stuff in our way (e.g., commitment is a sum of G1 points from the trusted setup file multiplied by polynomial coefficients) and then converting the result to Arkworks data types (G1Affine, BigInteger256) and back forth.

But by doing this we miss out on Arkworks optimizations and perhaps compatibility with projects that already use Arkworks.