You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been bitten a few times by side effects while writing the bls aggregation service. I think we just followed the gnark-crypto library design. I raised an issue in their repo asking for the rationale behind this design choice. In the meantime, I think we might want to switch to non pointer receivers and args. A few stack copies is not worth optimizing for, especially if it can save a bunch of human debugging time.
EDIT: I'm stupid, you're smart. I was wrong, you are right. Actually I now don't like our interface for a different set of reasons, listed in that issue. Feels like we should just use the underlying bn254 methods directly (that take receiver and 2 pointer arguments)!
gnark-crypto has a PR open to add bls sigs over a bunch of curves. We should consider using their implementation once they merge it. It's been open and stale for quite a while though...
We originally took much of the crypto/bls module from eigenDA, so it currently contains code for both bls and some incredible-squaring specific code.
We need to refactor it and take out all the incredible-squaring code and put that in its own repo.
The text was updated successfully, but these errors were encountered: