-
Notifications
You must be signed in to change notification settings - Fork 677
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
feat: use versioned signer message data #5489
feat: use versioned signer message data #5489
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to using Vec<T: StacksMessageCodec>
, is there a plan to make this new serialization code backwards-compatible? If so, then please also add it. If not, then let's figure out a way to ship this so that all signers upgrade at the same time, since new signers won't be able to decode old signers' messages and vice versa.
There is a unit test to ensure that new signers can decode old signer messages, which uses a fixture. Old signers can decode new messages, with the problem that they don't fully consume the serialized bytes. We actually already inadvertently introduced this problem when adding signer versions to block responses, and no problems came from it, because of what I've mentioned before about how we only ever decode a I'll resolve those other comments though, good points 👍🏼 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noice. LGTM!
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This essentially implements the design I commented in the related issue.
To ensure that, when deserializing, we always consume the full "intended" bytes, this struct appends an internal
bytes_len
in the serialization format. Any remaining bytes are consumed and included asunknown_bytes
.We really want to maintain backwards compatibility here, because it's bad if nodes/signers can't deserialize newer messages. To handle this, any future properties to
BlockResponseData
can be simply written/read from insideinner_consensus_serialize
andconsensus_deserialize
. As long as new properties are only appended, and that these new properties can have a default value, this design should last through future versions.Apologies for not implementing it this way when I added the signer version to block responses. I hadn't considered the need to ensure consistency in the amount of bytes consumed when dealing with different versions.