Turns our KZG with 2^15 elements could be quite costly to deal with, especially in runtime environment. Can we have multiple different set of public parameters (trusted setup) for KZG that work more efficiently for different use cases?
For instance we could use 2^8 for checking whether record belongs to particular segment, which would be much cheaper to work with.
Or is there some mathematical property that requires all KZG stuff to operate on the same trusted setup?
Yes, your intuition is correct! For example, we can use a degree-(2^8 - 1) polynomial to check whether a given record belongs to a particular segment.
While loading the 2^15 setup takes a lot of memory, having multiple setups is certainly not something I have seen around. One approach is to read a prefix of the existing trusted setup if you need to work with fewer elements. So when you need to commit or prove for a vector of 2^8 elements, you would just read to memory the first 2^8 G1 elements out of 2^15. However, it doesn’t look like rust-kzg supports this use, but it shouldn’t be that hard to implement.
Ethereum KZG ceremony created 3 trusted setups one 2^12 and two smaller ones.
Though I didn’t see a major performance improvement with smaller sizes locally, so will move forward with an assumption that we’ll use just one.
I ended up exposing host functions to the runtime in https://github.com/subspace/subspace/pull/1278, so we don’t do KZG in WASM at all (for now at least). I suspect even 2^8 might be still quite costly.
Why is the transaction amount for Ethereum wallet addrrss set so high?
I would assume active accounts over a period of time would be a qualifying metric.
128 transactions is a lot, I been actively using my wallet since 2017 and I dont even have that. Most wallets with over 128 transactions are bot traders, which seems to go against the purpose of the threshold in the first place.
Not sure what you’re talking about and how it is related to this topic 