Modular IBCs in a modular world

Modular IBC for the Modular World

Original article by Polymer Labs

Kxp, BlockBeats

The design flexibility of modular blockchains and Rollup also drives greater flexibility in IBCs. IBC network topology is changing from a homogeneous, densely connected network to a heterogeneous, sparsely connected network. Modular IBC will adapt the IBC protocol to this dynamic environment.

Earlier, we talked about how to think about modular interoperability. Today, we'll delve into how modular blockchains affect the design of the IBC state layer.

Split state layer

Currently, in the IBC network, a single Tendermint light client is sufficient to represent a logical blockchain because of the homogeneity of the network itself. However, modular blockchains like Celestia break this homogeneity, splitting the logical blockchain into multiple chains. So, you need toMultiple light clients to represent a single logical blockchainAnd each light client can represent a different level of the blockchain stack.

Mode of proof

在单一环境中，运行一个完整节点或验证单个共识证明通常足以使第三方相信状态转换。在模块化环境中，我们需要获取各种证明以确认状态转换。

We can classify the various verification methods as follows:

,  Direct proof (for example, running a full node)

,  Proof of fraud (e.g., Optimistic Rollup)

,  Validity or zero-knowledge proof (e.g., zk Rollup)

,  Consensus proof (e.g., light client)

We can mix and match these verification methods with the composible layer of the blockchain to be confident that we are making a state transition. For example, we can perform data availability sampling directly against Celestia. Alternatively, we can choose to verify the Celestia Consensus proof.

No matter what type of proof is used, Logical Light clients (LC) want to confirm three things:

,  Data availability (DA)

,  Sequence or transaction order (TO)

,  execute

-- settlement

To demonstrate the flexibility of the design, we'll explore various Rollup designs on the common data availability layer:

,  Execute + Proof of fraud ==Optimistic Rollup

,  Implementation + consensus proof ==Pessimistic Rollup

,  Do + zero knowledge proof ==ZK Rollup

Access security

In a single blockchain, the security of the chain depends on the mining power of the PoW chain and the Token pledge of the PoS chain. This can lead to various security issues when starting a new chain, such as the bootstrapping problem. In a modular blockchain stack, a chain can obtain security from one or more external sources.

There are several shared security modes available, some of which are directly compatible with IBCs, while others require modular IBCs to function properly.

,  Subcontracting security from the producer chain through interchain security (for example, Cosmos Hub)

The v1 version of cross-chain validation replaces the consumer chain validator with the producer chain validator

,  Taking security from the common clearing layer (for example, Ethereum)

,  Undertake security from the common data availability layer (for example, Celestia, EigenDA)

The public data availability layer can provide censor-resistant data for trust-minimization bridging based on proof of fraud

,  Obtain security from the programmable security provider (for example EigenLayer)

Security providers may be subject to additional forfeiture conditions based on certain validation efforts

,  Obtain security from the producer chain via checkpoint mechanism (e.g. Babylon)

Checkpoint mechanism prevents long distance attacks and weakest link attacks (in multi-hop IBC routes)

,  Security through repledge and cross-chain pledge (e.g. liquidity pledge, superliquidity pledge, etc.)

-- Subject the pledged capital to verifier level forfeiture conditions

IBC application instance

Connect Ethereum to IBC

For EthereumL2< > L2 connection, we need multiple light clients to represent each logical L2 chain. We can look specifically at Optimistic Rollup. Between L2, you can form IBC channel paths with different security properties. Note that this example assumes that we have run the IBC pass on the following chains, but the model for using Polymer for the IBC transfer is different.

High delay but low risk path:

,  An eth2 light client performs data availability and settlement proofs on behalf of Ethereum.

,  An Optimistic light client with conditional rules for execution and trade ordering proof on behalf of Aribitrum or Optimism.

-- This rule will ensure that Arbitrum or Optimism blocks are settled and finalized on Ethereum before routing them to other L2.

Low-latency but high-risk path:

,  An independent machine, committee, or consensus light client testifies on behalf of soft validation by third parties or sequencers.

,  An Optimistic light client with Ethereum conditional rules for execution and trade ordering proof on behalf of Arbitrum or Optimism

Extend IBC to Celestia Rollup

In the case of Celestia, you need multiple light clients to represent a logically Optimistic Rollup. Celestia provides proof of consensus as proof of data availability and transaction sequencing.

We can see modular IBCs in action on the IBC chain connected to Celestia Rollup:

,  A Tendermint light client (TMLC) that performs data availability and transaction ordering proofs on behalf of Celestia.

,  An Optimistic light client with Celestia conditional rules that performs proof on behalf of Optimistic Rollup.

This rule will ensure that a block is available on the Celestia network before a block is finalized.

Note that multiple Optimistic light clients will rely on Celestia TMLC. In addition, for logical pessimistic Rollup, you can have the following Settings:

,  A Tendermint light client (TMLC) that performs data availability and transaction ordering proofs on behalf of Celestia.

,  A Tendermint Light client (TMLC) with Celestia condition rules, which represents the pessimistic Rollup for proof of execution.

- again, this rule will make sure that before finally determine a data block, Celestia has a block of data is available on the network.

Share security with IBC's Eigenlayer

Eigenlayer 允许 Ethereum 验证者重新将其 Ethereum 质押置于可在链上执行的额外罚没条件之下。这使得 Eigenlayer 消费者链可以借用 Ethereum 网络的安全性。

By adding a forfeiture condition to Ethereum, EigenLayer verifiers can sign the consumer chain head for increased security. If the EigenLayer is integrated with IBC, cross-chain validation can be used to add the EigenLayer verifier to the active verifier set of the consumer chain. Otherwise, the consumer chain can still provide a degree of protection for connected chains at the IBC link level.

This will be achieved by:

,  Forfeit double signed headers on Ethereum, which means that if the EigenLayer verifier double signs a header for the consumer chain, 1/3 of the pledge on EigenLayer will be forfeited.

,  A blockchain connected to the IBC-enabled EigenLayer consumer chain needs to run two light clients -- one for EigenLayer and one for the consumer chain.

,  The attached chain will verify that the chain header has been signed by the consumer chain and EigenLayer before accepting.

,  This means that IBC connections to the EigenLayer consumer chain can be forked and provide additional economic protection against attacks.

Use IBC's Babylon sharing security

For its part, Babylon will provide a checkpoint or timestamp service that processes specific transactions with Bitcoin's security by issuing an aggregate timestamp to Bitcoin. It acts as a producer of security, and the connected chain is considered a consumer of security.

By connecting to Babylon, the consumer chain can connect status checkpoints to Bitcoiin in order to take advantage of Bitcoiin's security during high-value transactions. In addition, they must enforce slow confirmation rules to delay the finalization of these transactions to ensure that checkpoint status reaches *k-* depth in the Bitcoin network.

在 Babylon 消费者链上查看模块化 IBC 实际操作：

,  Initialize a local client with Babylon TMLC's conditional rule.

——该规则将确保在执行之前对提交的数据包设置检查点。

,  Writes a packet to the initialized local connection/channel.

The packet is not executed until it is checked and committed.

,  Chain that sends high value packets from Babylon Consumer Chain to IBC connection:

-- First enforce the slow acknowledgement rule over the local connection/channel.

The packet is then sent through the IBC connection to the IBC connected chain.

Polymer participates in the Shared Security Summit

During 2023 at ETH Denver Polymer Labs co-hosted the Shared Security Summit with many of our ecosystem partners. Luckily, our friends at Eigenlayer and Babylon Chain documented itAll speeches.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia