Performance regression for version 2, with FK20 setup always running

[cakevm]

I have tried to upgrade c-kzg in lighthouse to the next major version from 1 to 2 (see: sigp/lighthouse#7271). But noticed that there is some performance degradation with the integration tests in lighthouse.

It seems that the initialization behavior has changed, and since #442 the FK20 setup always run. But in case of lighthouse would call KzgSettings::load_trusted_setup() with precompute = 0, because no cell operations are used, and currently it only needs basic blob operations like blob_to_kzg_commitment() right now. Where for my understanding no FK20 is needed.

I was checking the readme and the release notes, but maybe missed the point that version 2 is now optimized for applications that focus on using cell operations. And that the initialization is now 10x slower, but for the reason to always support cell operations. I have the feeling that this is also maybe "affecting" Alloy when looking at this comment here (PR for that was alloy-rs/alloy#2240).

In the PR #442 (review) I found this comment:

Maybe what we should do at some point is add an explicit disclaimer to the readme that this is not a general purpose KZG library.

So I have the feeling that all that is an intended behavior. But neverless I thought to bring this up to check:

• If you would consider to add in c-kzg-4844 an option for lazy loading FK20?
• Or maybe as the comment suggested, add a prominent warning about this behavior when only fn's for EIP-4844 are used to the readme?

[jtraglia]

Hey @cakevm, for simplicity I would prefer not to add lazy loading for this. Ideally, clients & testing frameworks should only load the trusted setup once.

Maybe what we should do at some point is add an explicit disclaimer to the readme that this is not a general purpose KZG library.

I would argue this is already pretty explicit 😅

The project's description is:

A minimal implementation of the Polynomial Commitments API for EIP-4844 and EIP-7594, written in C.

The project's name has "4844" in it.

The project is in the ethereum organization.

Since this issue is over a year old & we do not plan to add this feature, I'm going to close this issue.