Design proposal: dual-parent finality in fendermint topdown module (Ethereum Sepolia as second parent)

[phutchins]

Summary

This is a design proposal for extending the fendermint topdown finality module to support a second parent chain (Ethereum Sepolia alongside Filecoin Calibration). We are seeking core team feedback on the proposed approach before any implementation begins.

Context: We are building a dual-parent smart bridge that enables Ethereum contracts to send native IPC cross-messages into an IPC subnet with arbitrary calldata (not just token transfers). The EthGatewayMessenger contract on Ethereum Sepolia is already implemented (see PR #1551). This proposal covers the fendermint-side finality tracking needed to support it.

---

Proposed Design: Composition, Not Modification

The existing VoteTally, CachedFinalityProvider, and LotusParentSyncer are correct for a single parent. The proposal is to instantiate them twice and compose results one layer above — no changes to existing internals.

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: EthereumParentProxy

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

• Uses eth_getBlockByNumber("finalized") for checkpoint-based PoS finality
• Queries EthGatewayMessenger events on Sepolia for top-down messages

Config Extension (backward-compatible)

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

What Stays the Same

VoteTally, CachedFinalityProvider, single-parent gossip wire format, single-parent subnet genesis — all unchanged.

---

Open Questions (need core team input before we begin)

1. Ledger schema: DualParentFinality new variant vs. two sequential single-parent commits?
2. Gossip protocol: Two separate gossip topics vs. tagged enum on existing topic?
3. Ethereum finality model: Is finalized block tag sufficient, or is beacon chain BLS proof verification required?
4. WS-C3 routing: Does cross-message routing to Ethereum need both parent heights committed simultaneously, or can Ethereum finality be incremental?

---

Related

• PR feat(bridge): IPC ERC20 cross-chain bridge — Filecoin Calibration ↔ Ethereum Sepolia #1551: testnet bridge (BridgeLock, BridgeMint, bridge-relay actor, SDK, deploy scripts, QA)
• contracts/contracts/gateway/EthGatewayMessenger.sol: Ethereum-side gateway (in PR feat(bridge): IPC ERC20 cross-chain bridge — Filecoin Calibration ↔ Ethereum Sepolia #1551)

No implementation will begin until we have alignment on the four questions above. Happy to discuss here or on a call.

[linear]

IPC-389

[phutchins]

Closing as duplicate of #1552 — same proposal, opened simultaneously. Consolidating discussion on #1552.