-
Notifications
You must be signed in to change notification settings - Fork 238
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
Remove destinationAddress and destinationChainID from Warp Message #920
Remove destinationAddress and destinationChainID from Warp Message #920
Conversation
599baa3
to
f76be8c
Compare
f76be8c
to
b4a99ff
Compare
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.
Could you update the total size of the addressed payload in the README now that these two fields are removed? After that, this change LGTM
address indexed sender, | ||
bytes message | ||
); | ||
event SendWarpMessage(address indexed sender, bytes message); |
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.
note: since we removed two index fields with this change, we could include the unsigned warp message ID if we want to.
This should be a separate change if we want it though. cc @michaelkaplan13 @ceyonur
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.
Yup that's what I thought after seeing this lol. It would be a great change!
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.
I think that'd be a great idea. To confirm, that's the ID used for querying validators for their signature of a specific message right?
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.
I think the code change looks good.
The change itself makes it such that applications must emit logs for destination chain and address if indexing is desired. I think we could make it clear in the readme that the typical application will need to encode the destination chain and contract on sending then verify this information as the first step in processing.
82e7cff
to
fd00831
Compare
fd00831
to
8d8de76
Compare
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.
Could we regenerate the precompile to see if we need to modify packers/unpackers for changed inputs?
The generated code now matches the output of generate_procompile.sh script
Why this should be merged
Remove destinationChainID and destinationAddress from the payload. Other libraries can implement their own mechanism to make the messages specific instead of anycast. More context in #868
How this works
Remove any reference to destinationChainID and destinationAddress
How this was tested
Unit tests and pipeline
How is this documented
Internal documentation will be updated to reflect changes #868