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'm not sure if #3298 's implementation is actually useful in the majority of the cases. The main reason why I see developers using modexp is because they're working with RSA signatures (not sure if there are other use cases).
When working with RSA signatures, a private key consists of a modulus m and an exponent e. So for producing a signature, a signer should get a digest of the signed message and then do modexp(digest, e, m) in order to get a signature.
Similarly, for verifying it's needed to do modexp(signature, e, m).
Both operations don't fit in an uint256 since the values of both e and m are typically 3072 bits (for 128-bit security).
Although RSA signatures have never been popular on Ethereum, with the new Account Abstraction trend it can be used as an alternative authorization mechanism. So, I'm afraid that this implementation wouldn't solve that particular use case.
If there's another use case justifying this current implementation, we can consider merging it.
There are still use cases for higher results than uint256. And the account abstraction narrative might led us to prioritize this
The text was updated successfully, but these errors were encountered:
From #1985
There are still use cases for higher results than
uint256
. And the account abstraction narrative might led us to prioritize thisThe text was updated successfully, but these errors were encountered: