You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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;
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;
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.
The text was updated successfully, but these errors were encountered:
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:
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;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:
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
, whereu32
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) andH256
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.
The text was updated successfully, but these errors were encountered: