Add deployment-specific prefix to message hashing #274
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Hyodar
force-pushed
the
feat/message-verifier
branch
from
d765981
to
54272bf
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Current Behavior
Currently, messages are hashed as
keccak256(prefix || digest),prefixbeing a message name used to avoid collisions with other messages - both in terms of internal messages and also other protocols'.However, if we are to be completely resistant to collisions, separate deployments should also be considered. As EIP712 has specific chain ID and verifier contract specifications, something similar, though not exactly the same, is needed here. Otherwise, we can have collisions with different deployments of the protocol. Of course, that would be avoidable in the current state by changing the message names on the other deployment and, considering BLS keys should differ between them, this is not an issue at the current stage. Also, the collision wouldn't be impactful.
Either way, this is something that should be changed soon because it affects the messaging protocol formats. So, the sooner the better.
New Behavior
We can't properly use something as EIP712, as already discussed in #104, because our messages are actually meant to be verified cross-chain by different contracts. At the same time, changing constant message prefixes per deployment is not that interesting of a solution. It could be if we had a Solidity preprocessor though.
What we can do instead is introducing a deployment-specific member to our prefix. So, with this we now have a
messagingPrefixmember which is set up in theSFFLTaskManagercontract andSFFLRegistryRollupcontracts as immutable (can be changed in upgrades, which would already be needed anyway in case of a messaging protocol change) and we use a type hash structure for it throughSFFLMessagingPrefix(string version,address taskManager,uint256 chainId).Breaking Changes
This is a breaking change and requires coordination for upgrades. The reason for that is nodes, as contracts, hash messages, and these hash functions must be the same. We could make a compatibility layer, but it'd require operators to track contract upgrades, so it's some added complexity.
It also requires contract upgrades!