Bring back NativeToForeign storage in EthereumSystem to be more resilient against changes #9901
Conversation
This file contains hidden or 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
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.
This PR brings back the storage removed in #8473. The motivation on that PR was that the storage was not used, and it was true. However I think it should be used to have a more resilient structure against potential breaking changes in the future. The rationale is the following:
A) If any of the
HashedDescriptionor xcm locations changes there is a quite complex migration to be performed without this PR. It would involve both migrating bridgehub storages and ethereum mappings in a coordinated manner.B) With this new PR, there is no downside besides having to store a few more bytes in
EthereumSystem. The exporter has exactly the same amount of reads (as we were already checking whether the asset existed inEthereumSystem). This PR maintains theHashedDescriptionimplementation when the asset is registered, but from there on, it relies onEthereumSystemto do the conversionLocation->TokenId. Now any of the above breaking changes does not imply a migration, as the hash would still match the old one.I am making this PR as draft as I want to gather feedback. Obviously there are a few TODOs yet that I will implement if the feedback is positive
Checklist