-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature]: add SignatureCache for checkTx and DeliverTx #15780
Comments
Can you post benchmarks please? This is going to be dwarfed by the fact that apps might have to verify 100+ signatures in |
thanks for your reply. These conclusions are based on pressure testing data, and haven't yet been compared to benchmarks. I'll perform some benchmarks next and provide feedback as soon as results are available. Besides, you said you already use Hashi's LRU cache, and the LRU cache is used for getting the signBytes, but it still has to do the pubkey.VerifySignature, and this operation of verifying signatures has a performance overhead. |
Hi @chengzhinei, any updates about the benchmarks? If not, someone from Zondax could look into doing them, so that a final decision can be made whether the code change is worth it? |
this will be on hold until the implementation of ADR071 is completed. |
Summary
Problem Definition
For a TX, when it is called through abci to deliverTx and checkTx, verification of the signature is used. However, it was found through pprof that the performance overhead of verifying the signature is still significant.
To save performance, the result of verifying the signature for the same TX can be cached during the first verification. This way, when the signature is needed for verification again, no decrypting and encrypting operations need to be performed, thereby saving performance.
Proposal
The code change is relatively simple, and this Pull-Request can be used as a reference.
https://github.com/cosmos/cosmos-sdk/pull/15778/files
https://github.com/okex
The text was updated successfully, but these errors were encountered: