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)
- Ledger schema:
DualParentFinality new variant vs. two sequential single-parent commits?
- Gossip protocol: Two separate gossip topics vs. tagged enum on existing topic?
- Ethereum finality model: Is
finalized block tag sufficient, or is beacon chain BLS proof verification required?
- WS-C3 routing: Does cross-message routing to Ethereum need both parent heights committed simultaneously, or can Ethereum finality be incremental?
Related
No implementation will begin until we have alignment on the four questions above. Happy to discuss here or on a call.
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
EthGatewayMessengercontract 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, andLotusParentSyncerare 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:
DualParentFinalityCommitted to ledger when both parents have quorum. Single-parent subnets continue using
IPCParentFinalityunchanged.New:
EthereumParentProxyNew
ParentQueryProxybacked byethers::Provider<Http>:eth_getBlockByNumber("finalized")for checkpoint-based PoS finalityEthGatewayMessengerevents on Sepolia for top-down messagesConfig Extension (backward-compatible)
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)
DualParentFinalitynew variant vs. two sequential single-parent commits?finalizedblock tag sufficient, or is beacon chain BLS proof verification required?Related
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.