-
Notifications
You must be signed in to change notification settings - Fork 10
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
BOLD: Move remaining JSON to protobuf #34
Comments
Protobuf serialization scheme isn’t deterministic. Many binary representations are possible for a given object, because fields can be encoded in any order. This malleability is acceptable for most use-cases, but not for signing and hashing in cryptographic attestations and consensus code. OpenDEX’s serialization use-cases are the following:
In case OpenDEX will be evolved to support gossip of orders, the order message will need to be signed, and the order id will likely to be a hash. Using protobuf here means that a malicious node which forward messages will be able to change the order id (without breaking the signature), which will lead, if instantiated, to a swap failure (because the message originator, the maker, won’t find that order id). So in the overall, it seems to me that protobuf is suitable for OpenDEX, except in a gossip scenario. Since it’s not clear whether it will be supported, I would recommend to switch the 2 & 3 JSON use-cases to protobuf, at least for now. |
Thank you for the neat and understandable summary of the status quo @LePremierHomme . Until a real gossip protocol is on the table, I would say let's do what you suggested and move everything to protobuf. |
PR is in testing 👍🏾 Are you also taking care of the changes in the BOLD docs? @LePremierHomme |
The OpenDEX protocol still has JSON in various places, which is bad because JSON can't be guaranteed to always be UTF-8 conform and requires implementations to use e.g. https://www.npmjs.com/package/json-stable-stringify in exactly the same way.
This issue is about moving all remaining JSON parts to protobuf to mitigate this issue. We should also evaluate alternatives like XDR.
The text was updated successfully, but these errors were encountered: