# Secure acquisition of the last confirmed domain block

**URL:** <https://forum.autonomys.xyz/t/secure-acquisition-of-the-last-confirmed-domain-block/4385>\
**Category:** Research\
**Created:** [July 22, 2024, 2:20pm UTC](https://forum.autonomys.xyz/t/secure-acquisition-of-the-last-confirmed-domain-block/4385 "2024-07-22T14:20:30Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![shamil](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/shamil/32/875_2.png) [@shamil](https://forum.autonomys.xyz/u/shamil)\
**Post date:** [July 22, 2024, 2:20pm UTC](https://forum.autonomys.xyz/t/secure-acquisition-of-the-last-confirmed-domain-block/4385/1 "2024-07-22T14:20:30Z")

</div>

**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)?**_

---

<div class="post-metadata">

**Author:** ![dariolina](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/dariolina/32/743_2.png) [@dariolina](https://forum.autonomys.xyz/u/dariolina)\
**Post date:** [July 23, 2024, 6:47am UTC](https://forum.autonomys.xyz/t/secure-acquisition-of-the-last-confirmed-domain-block/4385/2 "2024-07-23T06:47:19Z")

</div>

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](https://github.com/subspace/protocol-specs/blob/main/docs/consensus/consensus_chain.md#synchronization)). 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.

---

<div class="post-metadata">

**Author:** ![ning](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/ning/32/669_2.png) [@ning](https://forum.autonomys.xyz/u/ning)\
**Post date:** [July 23, 2024, 2:41pm UTC](https://forum.autonomys.xyz/t/secure-acquisition-of-the-last-confirmed-domain-block/4385/3 "2024-07-23T14:41:31Z")

</div>

> [@dariolina](#):
>
> 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.

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`](https://github.com/subspace/subspace/blob/fb2311b5a0ec62804022389bbf19356c751c2a35/crates/sp-domains-fraud-proof/src/storage_proof.rs#L177) as an example.