Skip to content
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

Making relayer compatible with runtime upgrades #2956

Open
Tracked by #6071
svyatonik opened this issue Apr 18, 2024 · 0 comments
Open
Tracked by #6071

Making relayer compatible with runtime upgrades #2956

svyatonik opened this issue Apr 18, 2024 · 0 comments
Assignees
Labels

Comments

@svyatonik
Copy link
Contributor

Right now we need to prepare + deploy a new relay version for every runtime upgrade. And since relay is connected to 4 chains, we need to have a new version every time one of chains is upgraded. Some time ago we have lowered requirements and now only watch for bridge hub versions (2 chains).

What we are trying to solve with that:

  1. transaction encoding compatibility - when spec_version, transaction_version, our pallet calls encoding, pallet ordering or a set of signed extension changes, relay starts building invalid transactions. For first two things we have a CLI options - to read versions right from runtime. The rest should happen rarely;
  2. bridge configuration compatibility. E.g. if we will keep current version of relayer running after Bridge: make some headers submissions free polkadot-sdk#4102 will be merged and configured in the runtime, relayer will start losing its money. That's because we no longer refund fees for complex transactions, containing GRANDPA, parachain and messages proofs. There are other "bridge configuration" parameters that can make relayer craft unexpected transactions;
  3. unexpected/unknown issues. E.g. : change of paras pallet of the relay chain, storage trie version changes, ... That is something that we expect needs to be detected by zombienet/chopsticks tests in the fellowhsip repo. But so far it isn't automated and normally when we are building new relay version for upgraded chains, we need to run Add P<>K bridge manual zombienet test for asset transfer polkadot-fellows/runtimes#198 and at least detect it manually.

TLDR: by releasing a new relayer version on every runtime upgrade we are trying to ensure that everything works properly. If we ever have an automated testing for that, we will be able to solve that easier. Yet we have a #2491, to make relayer fully generic, but it is unlikely to be finished soon.

What we can do to make our lives easier now and not to rebuild relayer on every upgrade. Inspired by #2947: we can add some constant to every bridge pallet (GRANPA, parachains, messages) configuration and also add the same constant to relayer. Relayer should exit if it sees that the constant it has is different from the constant in the runtime. This should solve issues (1) and (2) from above. (3) is still actual and can't be detected without tests.

This constant should 'seal' everything related to bridge transaction encoding and bridge configuration compatibility:

  • a set of bridge calls encoding;
  • a set of bridge-related signed extensions IDs that are related to the bridge;
  • a set of all pallet settings that may affect relayer.

I thought about having a test that will hashing something that may be read from runtime metadata (calls encoding) and from signed extensions configuration, but it looks impossible to have that for everything. So maybe it should be u32 + H256, where u32 will need to be bumped manually every time we change something that can't be auto-detected (e.g. we stop refunding some relayer transactions) and H256 should be the hash of everything else (that can be detected with test - e.g. mostly related to encoding).

The relayer should check that constant before e.g. submitting transaction to the target chain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: In-Review
Development

No branches or pull requests

1 participant