# Hypothetical Post-Merge Ethereum cross chain bridge# Hypothetical Post-Merge Ethereum cross chain bridge
Ethereum ecosystem is currently moving towards a multi-chain environment. This both includes work on the sharding as part of the ETH2.0, as well as appearence of different side chains and rollups independent of Ethereum Mainnet. One of the basic needs for a multi-chain environment, is an existence of a secure communication channel between the chains.

This post is a high-level description for the cross-chain bridge between two independent ETH2.0 chains and their respective execution layers (e.g. a bridge between ETH2.0 and [SBC]( https://www.xdaichain.com/for-validators/consensus/sbc)).
The implementation phase will start as soon as possible, this post will be updated once more details are known.

## Assumptions

1. Eth 1.0 is getting merged into the Eth 2.0 beacon chain
2. xDai is getting merged into the SBC
3. [EIP2537](https://eips.ethereum.org/EIPS/eip-2537) is implemented in some of the execution layer post-merge hardforks. Hopefully it will included in the first feature-hardfork after the Merge itself.
4. Altair hardfork is activated and works on both, ETH2.0 and SBC.
5. Beacon block contains an accessable reference to the head of the execution layer shard. (e.g. `latest_execution_payload_header` in https://github.com/ethereum/consensus-specs/blob/dev/specs/merge/beacon-chain.md#beaconstate)
6. Independent oracles are willing to submit new headers to the destination chain smart contract (at least 1 tx is required per sync committee period (27 hours for ETH2.0, 16 hours for SBC)). Possibly with a some form of compensation.

## Operation Model
1. Given that the assumed model is pretty much symmetric, the bridge is expected to work in the full-duplex mode. Thus, it is possible to "transfer" information in both directions by following the same algorithm. In reallity, a full-duplex bridge is just a pair of two independent half-duplex bridges capable of transferring information in a single direction.
2. The model does not consider a fixed set of priviledged oracles or validators who are expected to confirm or sign some data. Instead, the bridge relies on the committee members of the beacon chain, who are frequently rotated and being chosen in pseudo-random way.
* We are using sync committee members and their signatures directly as a secure way of syncing the beacon blocks.
* We are trusting to the underlying attestation mechanism of the beacon chain and the way of how execution layer blocks are being included into the beacon block. Thus, we are transitevely trusting attestation committee members to link correct execution layer blocks.

## Data transfer sequence diagram
This is a high-level example for the ETH1.0 -> xDAI data transfer in the post-merge environment. However, an exact underlying chains can be freely interchanged by any other chains conforming to the initial requirements.

Title: ETH1.0 -> xDAI post-merge data bridge
participant ETH1.0 data
participant ETH1.0
participant ETH2.0 committees
participant ETH2.0
participant Oracle
participant XDAI Light Client contract
participant XDAI receiver contract

ETH1.0 data->ETH1.0: included in the merkle tree\nsecured by the ETH1.0 block hash
ETH2.0 committees->ETH1.0: get updated blocks\nhashes for proposals
ETH2.0 committees->ETH2.0: propose and attest updated\nETH1.0 block hashes
ETH2.0 committees->ETH2.0: sync committee contributions
ETH2.0 committees->ETH2.0: LMD GHOST votes
ETH2.0->ETH2.0: beacon block is marked as finalized
Oracle->ETH2.0: gather new blocks and\nsync committee signatures
Oracle->XDAI Light Client contract: check if the known\nETH2.0 is outdated
Oracle->ETH2.0: request beacon state, merkle proofs
Oracle->XDAI Light Client contract: submit ETH2.0 block hash,\nmerkle proofs,\nsync committee signatures
XDAI Light Client contract->XDAI Light Client contract: follow sync protocol\n verifications
XDAI Light Client contract->XDAI Light Client contract: save verified\nETH2.0 block hash
XDAI receiver contract->XDAI Light Client contract: get verified ETH2.0 block hash
XDAI receiver contract-->ETH2.0: get associated ETH1.0 block hash and merkle proof for it
XDAI receiver contract-->ETH1.0: get merkle proof for ETH1.0 data
XDAI receiver contract->XDAI receiver contract: combine merkle proofs
XDAI receiver contract->XDAI Light Client contract: verify combined merkle proof
ETH1.0 data-->XDAI receiver contract: data transfer happened

## Open questions
1. How to incentivize the oracles, so that there is always a sufficient(in terms of robustness) number of them?
2. How to choose delay parameters and timeouts for accepting non-finalized blocks in case of inactivity leak?
3. In case of oracle incentivization is used, how to prevent possible front running attacks for oracle transactions?
4. Does it makes sense to implement some non-strict sequencing for the oracles? How we can reduce possible number of failed transactions due to the race conditions in the Light Client contract updates?