Parachains finality relay

[svyatonik]

on top of #1068

[AurevoirXavier]

I'd like to know the current status of this PR.
What block this?

Thanks.

[svyatonik]

I'd like to know the current status of this PR. What block this?

Thanks.

I've responded here (#1218 (comment)). I hope we'll have resources to work on this soon

[fig666]

invalid command

[svyatonik]

@eskimor Since you've reviewed parachains finality pallet recently (really appreciate that), would you be so kind to review this PR as well, when you have a spare hour? It introduces a relay (offchain actor) that connects to the source (relay) chain and target chain (relay or parachain) and polls source client for parachain heads updates. Whenever head changes, it submits updated-parachain-head transaction to the target chain. This code is abstracted from real chains, because it needs to work with our homegrown Rialto and Millau and with public Rococo/Wococo/Kusama/Polkadot chains.

The main logic is in the relays/parachains/src/parachains_loop.rs

[eskimor]

Things keep piling up on my list, but I'll try to squeeze it in.

[acatangiu]

Looks good, from a functional point of view I only have a single question below. 👍

[acatangiu]

why not "<=" in head_at_target.at_relay_block_number <= best_finalized_relay_block.0? It's my understanding that pallet_bridge_grandpa will sync headers then this pallet syncs para heads so it should be ok to sync para heads to the latest synced relay block.

Current code seems to want to keep para heads syncing one block behind finalized relay blocks syncing. Is that intentional?

[svyatonik]

The idea (that still may be criticized, though) was to avoid decoding parachain heads in the bridge-prachains pallet code. That's because of two things:

1. polkadot is also not doing that in their parachain-related pallets - heads are always opaque there;
2. the pallet supports syncing multiple parachains at once, so if e.g. two parachains are using different header structs (i.e. one is frame-based and another is not), it'd require some non-trivial configuration.

But we still want to import parachain heads in order. To do that I'm relying on the fact that the best-finalized-parachain-head is always increasing. I.e. best finalized parachain head at relay block 100 is always the ancsestor of the best finalized parachain head at relay block 200. This also means that if we have already delivered best finalized parachain head at relay block 100, we don't need to do it again - it'll be the same.

This condition is exactly for handling this latter case: head_at_target.at_relay_block_number < best_finalized_relay_block.0 means "if we MAY know better finalized-parachain-head than is currently available at the target" and the head_at_target.head_hash != *head_at_source means "and it is ACTUALLY BETTER". I.e. if first condition is true, and the second one is false, then the relay chain hasn't been updating parachain head for a while (it is a normal situation).

If we would change head_at_target.at_relay_block_number < best_finalized_relay_block.0 to head_at_target.at_relay_block_number <= best_finalized_relay_block.0, then it'd mean "if we MAY know better OR THE SAME finalized-parachain-head than is currently available at the target". And we don't want to deliver the same parachain head multiple times (pallet would reject such transaction). But actually, it is safe to change this condition to "<=", because then the second condition would fail anyway and the parachain head won't pass filter. But imo "<" is stricter and safer to use here :)

[acatangiu]

ok, that makes sense, let's keep the stricter/safer version and revisit if we see any need for lag improvements 👍