RFC: Dual-parent finality tracking in fendermint topdown (Ethereum Sepolia as second parent)

[phutchins]

Background

This RFC is part of the IPC cross-chain bridge workstream. We are building a production bridge between Filecoin Calibration and Ethereum Sepolia via an IPC subnet, and need the subnet to track finality on both parent chains simultaneously.

Codebase analysis (fendermint/vm/topdown/) shows the existing architecture is well-suited to this extension. The key finding: VoteTally and CachedFinalityProvider require zero internal changes. The dual-parent extension is purely additive composition.

Proposed Design

New type: DualParentFinality

pub struct DualParentFinality {
    pub filecoin: IPCParentFinality,   // existing type, unchanged
    pub ethereum: IPCParentFinality,   // same shape, different chain
}

Committed to ledger when both parents have quorum. Single-parent subnets continue using IPCParentFinality unchanged.

New component: EthereumParentProxy

New ParentQueryProxy implementation backed by ethers::Provider<Http>:

• get_chain_head_height: eth_getBlockByNumber("finalized") — Ethereum PoS checkpoint finality (~12 min latency, 2 epochs). No BLS proof verification required at this layer.
• get_block_hash, get_top_down_msgs, get_validator_changes: standard EVM RPC calls to the IPC gateway on Sepolia.

Config extension (backward-compatible)

[ipc.topdown]
# Existing fields unchanged
parent_http_endpoint = "..."
parent_registry = "0x..."
parent_gateway = "0x..."

# New: optional second parent (omit = single-parent mode, no migration)
[ipc.topdown.second_parent]
chain_id = 11155111
http_endpoint = "https://rpc.sepolia.org"
gateway = "0x..."
chain_head_delay = 2
polling_interval = 60

Proposal coordination

When second_parent is configured:

1. Two independent CachedFinalityProvider + VoteTally + syncer loops run in parallel (one per parent).
2. A DualParentFinalityProvider wrapper holds refs to both; next_proposal only fires when both tallies have quorum.
3. set_new_finality commits both parent heights atomically.
4. VoteTally and CachedFinalityProvider internals: no changes required.

What stays the same

• VoteTally — no changes
• CachedFinalityProvider — no changes
• Single-parent gossip wire format — no changes
• Single-parent subnet genesis — no changes

Open Questions for Core Team

We need answers to these before beginning implementation:

1. Ledger schema: Should the committed finality in the ledger be a new DualParentFinality variant (atomic commitment), or two independent sequential IPCParentFinality commits? Preference is a single new variant for atomicity, but this affects serialization compatibility.

2. Gossip protocol: The P2P vote gossip currently carries IPCParentFinality. For dual-parent, validators need to gossip votes for both chains. Options:

• (a) Two separate gossip topics (one per parent chain)
• (b) Single topic with a tagged enum (enum Vote { SingleParent(IPCParentFinality), DualParent(DualParentFinality) })

Which approach does the core team prefer?

3. Ethereum finality model: Is the finalized block tag sufficient (checkpoint-based, ~12 min, trusts the RPC endpoint), or is beacon chain BLS proof verification required (cryptographic guarantees, ~3-4 weeks additional implementation)?

4. Cross-message routing dependency (WS-C3): Does the subnet's cross-message routing layer need both parent heights to be committed simultaneously, or only the Ethereum finality? This affects the minimum viable scope for unblocking WS-C3.

Implementation Plan (pending answers above)

Phase	Scope	Estimated effort
1	DualParentFinality type, EthereumParentProxy, config extension	~1 week
2	DualParentFinalityProvider composition, dual syncer launch	~1 week
3	Unit + integration tests with mock Ethereum RPC	~1 week
4	Core team review, revisions, merge	TBD

Total: ~3 weeks + review cycle (assuming finalized tag is acceptable).

Context

This is part of the IPC cross-chain token bridge project. The Ethereum gateway contract (EthGatewayMessenger) is already deployed on Sepolia and provides sendContractXnetMessage — the subnet needs to accept those messages as valid top-down messages from the Ethereum parent.

We are not touching any fendermint files until this RFC is reviewed by the core team.

[linear]

IPC-388

[phutchins]

Friendly ping — we're holding implementation until we hear back on the four open questions in the proposal above. Any initial thoughts from the core team would unblock the next workstream. Happy to adjust the design based on feedback.