docs(addition): add eth brief overview (#4158)

docs/docs/products/composable-ibc/cosmos-ibc.md

@@ -1,4 +1,4 @@
-## Cosmos ⬌ Polkadot Bridge
+# Cosmos ⬌ Polkadot Bridge
 
 IBC is the native communication protocol of the Cosmos ecosystem, it allows for trustless communication to occur between any blockchains built using the Cosmos SDK which have the IBC module enabled. For the IBC connection between Polkadot and Cosmos, the Tendermint and Grandpa light clients are utlised alongside `ibc-rs` and the Hyperspace relayer on Picasso and Cosmos chains.
 

docs/docs/products/composable-ibc/ethereum-ibc.md

@@ -0,0 +1,36 @@
+# 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.
+
+## Components
+
+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](https://ethereum.org/en/roadmap/beacon-chain/#what-is-the-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. 
+
+:::info
+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](light-clients.md).
+
+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](https://github.com/hyperledger-labs/yui-ibc-solidity). The contracts have been iterated upon and optimised for a production-ready environment tailored for Ethereum. 
+
+### Hyperspace Relayer
+Within the [Hyperspace](hyperspace-relayer.md) 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.
+
+:::tip
+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](https://ethereum.org/en/developers/docs/zksnarks).
+:::

docs/docs/products/composable-ibc/hyperspace-relayer.md

@@ -6,15 +6,15 @@ This section introduces [Hyperspace] - the first event-driven, chain-agnostic IB
 
 [Hyperspace]: https://github.com/ComposableFi/centauri/blob/master/hyperspace/README.md
 
-As Composable IBC was designed to extend the reach of IBC beyond the Cosmos ecosystem, we realized that we needed a relayer that was both rust-based and IBC-compatible in order to birth interoperability between the various ecosystems on our roadmap. 
+As Composable IBC was designed to extend the reach of IBC beyond the Cosmos ecosystem, it was necessary to develop a relayer that was both rust-based and IBC-compatible in order to birth interoperability on new ecosystems on. 
 
 :::info
 
 At present, there are three IBC relayers available in Rust, Golang, and Typescript, which can be found [here](https://ibcprotocol.org/relayers/). However, these existing relayers were not designed to support chains beyond Tendermint/CometBFT based chains, and reconfiguring them would require significant technical effort. Therefore, it was necessary to develop a new relayer that can function with any underlying consensus or programming language used by the source/destination chain.
 
 :::
 
-There are several client verification algorithms currently available in our light-client directory for different consensus engines, including:
+There are several client verification algorithms currently available in Composable's light-client directory for different consensus engines, including:
 
 - [Ics07-tendermint](https://github.com/ComposableFi/centauri/tree/master/light-clients/ics07-tendermint)
 - [Ics10-grandpa](https://github.com/ComposableFi/centauri/tree/master/light-clients/ics10-grandpa)
@@ -44,7 +44,7 @@ The diagram below provides a visual representation of the different components o
 
 ## Hyperspace runs the Fisherman Protocol
 
-While trustless bridges are a preferable alternative to trusted solutions, they are still subject to attacks if one of the blockchains in question is taken over by a malicious validator set. To address this threat, we implement the Fisherman Protocol. Thus, any relayer running Hyperspace in ‘Fisherman mode’ can report malicious blockchain headers to freeze bridges if a chain is taken over by bad actors. The relayer then receives the associated slashing rewards for themselves, thus incentivizing relayers to remain vigilant and on the lookout for malicious blockchain takeovers.
+While trustless bridges are a preferable alternative to trusted solutions, they are still subject to attacks if one of the blockchains in question is taken over by a malicious validator set. The solution lies in the Fisherman Protocol. Thus, any relayer running Hyperspace in ‘Fisherman mode’ can report malicious blockchain headers to freeze bridges if a chain is taken over by bad actors. The relayer then receives the associated slashing rewards for themselves, thus incentivizing relayers to remain vigilant and on the lookout for malicious blockchain takeovers.
 
 ![hyperspace_fisherman](../images-centauri/hyperspace-fisherman.png)
 

docs/sidebars.js

@@ -166,6 +166,7 @@
      "products/composable-ibc",
      "products/composable-ibc/cosmos-ibc",
      "products/composable-ibc/polkadot-kusama-ibc",
+     "products/composable-ibc/ethereum-ibc",
      "products/composable-ibc/near-ibc-bridge",
      "products/composable-ibc/hyperspace-relayer",
      "products/composable-ibc/light-clients",