▪️Ethereum bridge

The TeleportDAO Ethereum bridge functions as an optimistic light client bridge, linking Ethereum to EVM chains. This integration allows any application on the EVM chain to verify Ethereum data inclusion in a trust-minimized manner. Operating as an implementation of the Ethereum Sync protocol through smart contracts, our bridge adopts an optimistic approach, reducing gas consumption by executing checks only during challenges rather than for every block submission.

The Sync protocol was introduced to Ethereum to enhance light client compatibility. Each Sync epoch selects 512 validators as the Sync committee, responsible for signing valid block headers. This setup enables light clients to verify header validity when signed by a majority of the sync committee.

Leveraging an optimistic approach to reduce costs

In our Ethereum bridge, Relayers submit new Ethereum block headers to the Relay contract without immediate verification. Instead, a challenge period is initiated, allowing anyone, including other Relayers, to challenge the validity of the block header.

Both the submitting Relayer and the challenger must lock a certain amount of collateral. The Relayer must then prove the validity of the block header by providing additional information. Failure to do so within the challenge period results in rejection of the block header by Relay, leading to the Relayer losing their collateral. Conversely, if successful, the challenger loses their collateral, and the block header is deemed valid.

Validating ethereum block headers

Relayers submit Ethereum block headers to the Relay contract, consisting of two types:

Super blocks

If a block header is signed by over 90% of the Sync committee, it qualifies as a super block header. The Relayer submits the block header, claiming it as a super block header, initiating a challenge period. During this period, other users can dispute the block. In case of dispute, the Relayer must provide the Sync committee's signature to the contract. If the block header is signed by over 90% of the committee, the challenger's dispute is rejected; otherwise, the Relayer's claim is rejected.

Once a super block is accepted by Relay, it points to a last finalized checkpoint, a block permanently part of the Ethereum chain.

Finalized blocks

Following the acceptance of a new finalized checkpoint, Relayers submit other finalized block headers between the last finalized checkpoint and the previous one. Starting from the last finalized checkpoint and moving backward, Relayers ensure Relay has access to all finalized Ethereum block headers. Applications can utilize finalized headers to confirm data inclusion on Ethereum.

Updating Ethereum Sync Committee

To verify signatures against block headers, the Relay contract requires knowledge of the current Sync committee. Ethereum includes both the current and next Sync committees in each block. When a block header becomes finalized, a Relayer submits the next Sync committee to the Relay contract, proving its inclusion in the finalized block.