Secure acquisition of the last confirmed domain block

Research
1

Context (“snap-sync for domains” algorithm)

Prerequisites:

  1. MMR sync (new protocol) to support XDM and fraud proofs - from aux storage of the consensus chain client.
  2. snap-sync changes: “snap-sync from a custom block”
  3. Domains change:
    • enable block and state request protocols for domains and disable block sync for domains (pause_sync)
    • toggle consensus blocks notifications to pause/resume domain block derivation
    • add execution receipt of the last confirmed domain block and associated consensus block fields to LatestConfirmedDomainBlock

Algorithm:

  1. Get last_confirmed_domains_block from the consensus chain runtime state and retrieve execution receipt of the last confirmed domain block and associated consensus block fields of the LatestConfirmedDomainBlock from consensus chain runtime state.
  2. MMR-sync (must be done before the final domain blocks sync/derivation).
  3. Snap-sync consensus chain from the associated consensus block:
    a) After getting the state and before syncing/derivation domain chain blocks - download state and last_confirmed_domains_block from the domain network.
    b) Sync blocks for consensus chain (from DSN - because we can’t guarantee other peers don’t prune their local blocks at the arbitrary height) with reenabling domain chain notification. (edited)

How to get LatestConfirmedDomainBlock and execution receipt?

  1. Initially, we planned to obtain this information using snap-sync for consensus chain (from the local runtime state) but modifying polkadot-sdk to support multiple sync with gaps seems problematic.
  2. Alternatively, we can get this information from the consensus of connected peers - similar to the current segment headers obtained for DSN-sync.

Comment: we can also try to snap-sync to the local temporary chain and grab information from here (additional R&D required).

Can we trust the last confirmed block information when we get it from a consensus of peers (majority)?

2

IMO, it is fine to ask the peers what the latest confirmed domain block is in their view, similar to what we do for segment headers (spec). The peers would have to also provide the information about it from their runtime state with an MMR-proof tying to the consensus block that should be along the longest chain.

3

I think the peer should provide a storage proof of the LatestConfirmedDomainBlock instead, because the MMR proof

  • require the MMR data to verify statefully or require the consensus chain state to verify stateless
  • only prove a previous consensus block (i.e. block number/hash, state root)

We already use a lot of storage proof of the consensus state in FP, see the BlockRandomnessProof as an example.