模块化区块链和汇总设计的灵活性也激发了 IBC 设计的灵活性。IBC 网络拓扑正在从同质密集连接网络向异构稀疏连接网络转变。模块化 IBC 使 IBC 协议适应变化的新环境，本文我们将深入探讨模块化区块链如何影响 IBC 状态层的设计。

拆分状态层

目前，单个 Tendermint 轻客户端足以代表 IBC 网络中的逻辑区块链，因为网络本身是同构的。像 Celestia 这样的模块化区块链打破了这种同质性，将一个逻辑区块链拆分成许多链。因此需要多个轻客户端来表示单个逻辑区块链，而不是单个轻客户端来表示区块链。每个轻客户端都可以代表区块链堆栈的不同层。

证明的实现

在整体环境中，运行一个完整节点或验证一个单一的共识证明通常足以说服第三方进行状态转换。在模块化设置中，我们需要获取各种证据才能确信状态转换。可以将各种验证方法分类如下：

• 直接证明（例如运行一个完整的节点）
• 防欺诈（例如 optimistic rollups）
• 有效性或 ZK 证明（例如 zk 汇总）
• 共识证明（例如，轻客户端）

我们可以将区块链的可组合层与上述验证方法混合搭配，让我们相信状态转换。例如，我们可以直接针对 Celestia 执行数据可用性抽样。或者我们可以选择验证 Celestia 共识证明。无论使用何种证明类型，逻辑轻客户端 (LC) 都希望确信三件事：

• 数据可用性（DA）
• 排序或事务排序 (TO)
• 执行- 结算 为了展示其设计的灵活性，我们将看看在公共 DA 层之上的各种Rollups的设计。
• 执行 + 欺诈证明 == Optimistic Rollup
• 执行 + 共识证明 == Pessimistic Rollup
• 执行 + ZK 证明 == ZK Rollup

关于保证金

在单体区块链中，链的安全性在 PoW 链的情况下取决于挖矿能力，在 PoS 链的情况下取决于经济利益。这会在启动新链时导致各种安全问题，例如引导问题。在模块化区块链堆栈中，链可以从一个或多个来源外部获取安全性。

有几种共享安全模式，其中一些是开箱即用的 IBC 兼容的，而另一些则需要模块化 IBC 才能正常工作。通过链间安全性（例如 Cosmos Hub）从生产者链继承安全性——跨链验证[1]的 v1用生产者链验证器取代了消费者链验证器

• 从通用结算层（例如以太坊）继承安全性
• 从公共 DA 层（例如 Celestia、EigenDA）继承安全性
• • 公共 DA 层可以为信任最小化桥接的欺诈证明提供抗审查数据
• 从可编程安全提供者（例如 EigenLayer）继承安全性
• • 安全提供者是基于某些验证工作使自己受到额外削减条件的提供者
• 通过检查点机制（例如Babylon）从生产者链继承安全性
• • 检查点机制可以防止远程攻击和最薄弱的链接攻击（在多跳 IBC 路由中）
• 从重新质押和交叉质押中继承安全性（例如流动性质押、超流体质押等）
• • 使质押资本受制于验证者级别的削减条件

连接以太坊与 IBC

对于以太坊 L2连接，我们需要多个轻客户端来表示每个逻辑 L2 链。让我们具体看看 optimistic rollups。您可以在具有不同安全属性的 L2 之间形成不同的 IBC 通道路径。请注意，此示例假设我们在下面的链上运行 IBC 传输。使用 Polymer 进行 IBC 运输的模型是不同的。延迟较高但风险较低的路径：

• DA + 结算的以太坊轻客户端和状态证明。
• 一个Optimistic的轻客户端，在以太坊上具有  条件规则，代表 Aribitrum 或 Optimism 以证明执行 + TO。
• • 条件规则确保 Arbitrum 或 Optimism 区块在路由到另一个 L2 之前已经在以太坊上结算并最终确定。

较低延迟但高风险路径：

• 代表第三方或定序器作为软确认的证明的单机、委员会或共识轻客户端。
• 一个Optimistic轻客户端，在以太坊上有一个条件规则，代表执行证明 + TO 的 Arbitrum 或 Optimism。

将 IBC 扩展到 Celestia Rollups

以 Celestia 为例，需要多个轻客户端来表示一个逻辑上的 optimistic rollup。Celestia 提供共识证明作为 DA 和 TO 的证明。查看模块化 IBC 在连接到 Celestia rollup 的 IBC 链上的运行情况：

• 代表 Celestia 的 Tendermint 轻客户端 (TMLC) 用于 DA + TO 的证明
• 一个在 Celestia 上使用条件规则初始化的Optimistic轻客户端，表示执行证明的乐观汇总
• • 条件规则确保在最终确定块之前，Celestia 网络上的数据块可用。

请注意，多个Optimist轻客户端将依赖于 Celestia TMLC。此外，您可以为逻辑悲观汇总进行以下设置：

• 代表 Celestia 的 Tendermint 轻客户端 (TMLC) 用于 DA + TO 的证明。
• Tendermint 轻客户端 (TMLC) 在 Celestia 上使用条件规则初始化，表示执行证明的悲观汇总
• • 条件规则确保在最终确定块之前，Celestia 网络上的数据块可用。

使用 IBC 与 Eigenlayer 共享安全性

Eigenlayer 允许以太坊验证者重新质押或使他们的以太坊质押受到链上可执行的额外削减条件的约束。这允许 Eigenlayer 的消费链从以太坊网络借用安全性。通过在以太坊上添加削减条件，EigenLayer 验证者可以在消费链标头上签名以提高安全级别。如果 EigenLayer 集成了 IBC，可以使用跨链验证将 EigenLayer 验证人添加到消费者链的活跃验证人集合中[2]。否则，消费链仍然- 可以在连接链的 IBC 连接级别继承一些保护。这将如何工作：

• 以太坊上双签名标头的削减条件意味着如果 EigenLayer 验证者对消费链的标头进行双重签名，则 EigenLayer 上 ⅓ 的股份将被削减。
• 连接到支持 IBC 的 EigenLayer 消费链的链将需要运行两个轻客户端——一个用于 EigenLayer，另一个用于消费链。
• 连接的链将在接受之前验证标头是否已由消费链和 EigenLayer 签名。
• 这意味着 IBC 与 EigenLayer 消费链的连接具有分叉和额外的经济保护来抵御攻击。

使用 IBC 与 Babylon 共享安全性

就 Babylon 而言，它充当检查点或时间戳服务，向比特币发布聚合时间戳，以允许链在特定交易中利用比特币安全性。它充当安全的生产者，连接的链被视为安全的消费者。通过打开与 Babylon 的连接，消费链可以检查比特币的状态，以利用比特币的安全性进行高价值交易。此外，他们必须执行缓慢的最终规则来延迟这些交易的最终确定，直到比特币网络中的检查点状态为 k-*deep**。

查看 Babylon 消费链上的模块化 IBC：

• 使用Babylon TMLC 上的条件规则初始化本地主机客户端。
  • 条件规则确保提交的数据包在执行前被检查点。
• 数据包被写入初始化的本地主机连接/通道。
  • 数据包在检查点和提交之前不会被执行。
• 从 Babylon 消费链发送高价值数据包 → IBC 连接链：
  • 首先通过本地主机连接/通道发送，执行慢速最终规则。
  • 一旦保证了慢速最终性，数据包就会通过 IBC 连接发送到 IBC 连接链。

本文首发于：https://mp.weixin.qq.com/s/Vj2rwOiY4stqLztlA6HGPg