Ethereum IBC
Ethereum's integration with the IBC protocol expands the ability to offer novel and valuable DeFi use cases and enhance opportunities for participants across diverse ecosystems.
In line with prior IBC extensions, incorporating essential components such as a light client, relayer, and IBC implementation remains a prerequisite. However, when extending IBC compatibility to Ethereum, it became imperative to supplement the relayer with a ZK-Circuit. Previous IBC extensions relied on ibc-rs, whereas, this particular integration utilises an IBC implementation in Solidity.
The essential components powering the Ethereum IBC connection are described in the following section.
Light Clients
Before Ethereum transitioned to Proof of Stake (PoS) from its former consensus mechanism, Proof of Work (PoW), developing a light client was notably challenging. Building a light client for any PoW blockchain presents difficulties due to the need for resource-intensive validation of PoW, storage requirements for large block sizes, slow and bandwidth-intensive syncing and having non-deterministic finality - this means that transactions are never truly finalised so there is always the potential for someone to create a longer chain originating from a block preceding the current one, excluding it from the valid chain. These challenges arise from PoW's computational complexity and resource demands, making it more intricate to implement a light client compared to blockchains using PoS consensus mechanisms.
Composable has made substantial progress in developing light clients for networks that previously lacked them, conducting extensive research and development in this domain. Composable sees the contribution made to Ethereum not only by connecting it to Cosmos, Polkadot, and other chains via IBC but also by creating a Casper light client for the Ethereum Beacon Chain within an accelerated timeline. This light client will be deployed on the Composable Cosmos chain, which is already connected to the Cosmos and Polkadot ecosystems.
The Casper Light Client relies on the Sync Committee, which comprises 512 validators who undergo random selection once every sync committee period, approximately equal to one day. While a validator is actively participating in the sync committee, their primary responsibility entails consistently signing the block header representing the current chain head during each slot. The Sync Committee is a succinct way of getting a sample to verify a subset of the signatures of Ethereum.
Casper is Ethereum's PoS consensus protocol implemented within ETH 2.0. In Casper, validators participate in block creation and validation based on the amount of stake they lock up as collateral. This PoS system was adopted to enhance the security, scalability, and energy efficiency of Ethereum by reducing the need for computationally intensive mining while rewarding validators with transaction fees.
Composable will implement a Tendermint light client on Ethereum by deploying it as a smart contract. The Tendermint light client is responsible for verifying the validity of block headers from the Composable Cosmos chain and ensuring that the consensus state of the source blockchain is consistent with the header being presented. These headers contain data such as block hashes, timestamps, and state roots. It will be too expensive to verify signatures from the validator set of the Composable Cosmos chain therefore, ZK-Snarks are used to verify all signatures in succinct proofs. Read more on light clients here.
The ideal security to establish is for an attack to be as expensive as the smaller market cap of DOT and ETH. Unfortunately, only the bond of the few validators whose signatures are verified can be slashed so that any attack attempt can be cheaper than the whole market cap.
IBC implementation on Ethereum
Composable has built upon the existing IBC protocol implementation in Solidity by Hyperledger Labs. The contracts have been iterated upon and optimised for a production-ready environment tailored for Ethereum.
Hyperspace Relayer
Within the Hyperspace connection to Ethereum, a zero-knowledge (ZK) circuit is employed to optimise and sustain the cost of the relayer. A ZK circuit is a program capable of generating a proof when given a set of inputs. This proof can then be verified to ensure the correctness of each computational step executed within the circuit.
The ZK circuit involves a prover and verifier. Similar to Hyperspace, the prover is a permissionless off-chain component that anyone can run. The verifier lives on-chain as a smart contract on Ethereum. The role of the verifier is to verify proofs submitted by the prover, in this case, a succinct proof of client updates from the Composable Cosmos chain.
Verifiers receive proofs from provers and subsequently validate these claims, resulting in the generation of zero-knowledge proofs. For an in-depth explanation of this process, read here.