-
Notifications
You must be signed in to change notification settings - Fork 8
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
Use borsh for internal state encoding #46
Comments
Yes that makes sense. |
mina86
added a commit
that referenced
this issue
Nov 1, 2023
Prefer borsh over JSON since it’s more compact and faster. Since tendermint’s ClientState doesn’t support borsh, use protobuf encoding in the borsh format. Note that protobuf encoding isn’t deterministic which means that the borsh encoding for AnyClientState isn’t deterministic either. Having said that, we should be good so long as clients wanting to verify the value don’t re-encode the borsh-encoded value. Lastly, it’s worth noting that alternatively to using borsh we could use Any protobuf encoding directly. That would be marginally less efficient (since the entire type URL needs to be stored rather than one-byte tag) but it would reduce amount of code. Issue: #46
mina86
added a commit
that referenced
this issue
Nov 2, 2023
mina86
added a commit
that referenced
this issue
Nov 2, 2023
mina86
added a commit
that referenced
this issue
Nov 2, 2023
mina86
added a commit
that referenced
this issue
Nov 16, 2023
Borsh is a deterministic encoding which is somewhat important in our case where we store hash of the serialised representation in one storage and the object in another. Furthermore, Borsh is more space and time efficient than JSON so using it has additional performance benefit. Closes: #46
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We’re currently using JSON to encode various state objects such as client state or consesus state. This is fine for now but for better performance we probably should eventually switch to borsh as demonstrated in #44.
The text was updated successfully, but these errors were encountered: