-
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
perf: bech32 library, implement a decode algorithm that doesn't check the checksum #10025
Comments
Tested three cases:
Normalization here is checking and changing address to have only lower-case letters. If we normalize address when it is stored within state machine, normalization can be omitted too. |
|
Yup! Also @conr2d can you post a benchmarks with the memallocs as well? Add |
In original version (enigmampc/btcutil), memory allocation always happens multiple times due to string copy. By merging the latest version (btcsuite/btcutil), memory allocation only happens when a given bech32 string consists of upper case letters. Now all tests have |
Thats amazing! Thanks |
@conr2d would you like to update the sdk? |
@marbar3778 Yes, if possible. Do you mean changing decoding address from state to unsafe decode? |
yes! would you make the required changes? |
@marbar3778 @robert-zaremba OK, I will check it. Thank you. |
Hmm, I can add
We cannot know in advance whether the module will call |
In many places we know if we deserialize address from store or from a request. So we can have functions like:
BTW: there is always a dilemma, half of my brain would prefer to put Unsafe at the end to keep the prefix by object name (AccAddress...) |
Personally I prefer to keep address as bytes in the store, and don't do any verification. That would require to have 2 type of structures: one for store and one for response. I think that this is the right way to go, instead constraining ourselves (in order to use the same struct for store and response) and doing potentially bad decisions. But that's a separate topic ;) |
What's the status of this issue? |
this was partially implemented. There is a fork but the function to skip the checksum is not being used |
I shall close this as implemented, under the assumption that the optimized function is used on a per-case basis. |
this isnt completed, i dont believe we are using the function that doesnt check checksums? want to work on this? |
I would, but surely the checksum-skipping variant shall only be used where it matters for performance? My reasoning for closing this was because that is determined on a case-by-case basis. |
i have removed a few of these calls in staking and we plan on removing them more when we migrate state for now we can close this |
Summary
Now that we are using bech32 strings in several locations within the state machine (e.g. all the proto structs for staking), we should be mindful of the efficiency. Bech32 decoding for checksum checks with the current implementation checks isn't negligible time at scale, especially if your doing a large operation over state. (E.g. in epoch based models)
Any bech32 address that makes it into state should be a correct bech32 address. Therefore, we do not need to check its checksum upon decoding. We should implement a method in our bech32 library for
DecodeAssumingValidChecksum
Problem Definition
This feature helps improve performance of going to and fro 'native' data representation, and bech32 strings, for objects within the state machine.
The downside of this feature is it may add some additional thinking to relevant parts of the logic, for something that in the "standard" path of the SDK (e.g. not a large batch computation), will not be high impact.
Proposal
In the bech32 library we currently use, add a method for
DecodeAssumingValidChecksum
that simply omits thebech32verifychecksum
callFor Admin Use
The text was updated successfully, but these errors were encountered: