模块化世界中的模块化IBC-互推传媒

深入研究模块化区块链如何影响IBC状态层的设计。

模块化区块链和 Rollup 的设计灵活性也促使 IBC 具有更高的灵活性。IBC 网络拓扑结构正从一个同质化、密集连接的网络转变为一个异质化、稀疏连接的网络。模块化 IBC 将让 IBC 协议适应这种动态环境。

此前，我们谈论了如何思考模块化互操作性。今天，我们将深入研究模块化区块链如何影响 IBC 状态层的设计。

拆分状态层

目前，在 IBC 网络中，单个 Tendermint 轻客户端就足以代表一个逻辑区块链，因为网络本身具有同质性。不过，Celestia 这样的模块化区块链打破了这种同质性，将逻辑区块链分割成多条链。因此，你需要多个轻客户端来代表一个单独的逻辑区块链，而每个轻客户端可以代表区块链堆栈的不同层次。

证明方式

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

我们可以将各种验证方法分类如下：

· 直接证明（例如，运行全节点）

· 欺诈证明（例如，Optimistic Rollup）

· 有效性或零知识证明（例如，zk Rollup）

· 共识证明（例如，轻客户端）

我们可以将上述验证方法与区块链的可组合层进行混搭，以确信自己进行了状态转换。例如，我们可以直接针对 Celestia 执行数据可用性采样。或者，我们可以选择验证 Celestia 共识证明。

无论使用哪种类型的证明，逻辑轻客户端（LC）都希望确认以下三点：

· 数据可用性（DA）

· 序列或交易顺序（TO）

· 执行

——结算

为了展示设计的灵活性，我们将探究在通用数据可用性层上的各种 Rollup 设计：

· 执行+欺诈证明==Optimistic Rollup

· 执行+共识证明==Pessimistic Rollup

· 执行+零知识证明==ZK Rollup

获取安全性

在单一区块链中，链的安全性取决于 PoW 链的挖矿算力以及 PoS 链的 Token 质押。这在启动新链时会导致各种安全问题，比如自举问题（bootstrapping problem）。在模块化的区块链堆栈中，链可以从一个或多个外部来源获取安全性。

目前有几种共享安全模式，其中一些可以直接与 IBC 兼容，而其他一些需要模块化 IBC 才能正常工作。

· 通过链间安全从生产者链承接安全性（例如 Cosmos Hub）

——跨链验证的 v1 版本用生产者链验证者替换了消费者链验证者

· 从公共结算层承接安全性（例如，Ethereum）

· 从公共数据可用性层承接安全性（例如 Celestia, EigenDA）

——公共数据可用性层可以为基于欺诈证明的信任最小化桥接提供抗审查数据

· 从可编程安全提供商获取安全性（例如 EigenLayer）

——安全提供商会根据某些验证工作受到额外罚没条件的限制

· 通过检查点机制从生产者链获取安全性（例如 Babylon）

——检查点机制可以防止长距离攻击和最薄弱环节攻击（在多跳 IBC 路由中）

· 通过再质押和跨链质押获取安全性（例如流动性质押、超流动性质押等）

——让质押资本承担验证者级别的罚没条件

IBC 应用实例将 Ethereum 与 IBC 连接

对于 EthereumL2 <> L2 连接，我们需要多个轻客户端来表示每个逻辑 L2 链。我们可以具体看一下 Optimistic Rollup。在 L2 之间，你可以形成具有不同安全属性的 IBC 通道路径。请注意，此示例假定我们已在以下链上运行 IBC 传，使用 Polymer 进行 IBC 传输的模型有所不同。

高延迟但低风险路径：

· 一个 eth2 轻客户端代表 Ethereum 进行数据可用性和结算证明。

· 一个带有条件规则的 Optimistic 轻客户端，代表 Aribitrum 或 Optimism 进行执行和交易排序证明。

——该规则将确保在将 Arbitrum 或 Optimism 区块路由到其他 L2 之前，已在 Ethereum 上结算并最终确定。

低延迟但高风险路径：

· 一个独立机器、委员会或共识轻客户端，代表第三方或序列器的软确认进行见证。

· 一个带有 Ethereum 条件规则的 Optimistic 轻客户端，代表 Arbitrum 或 Optimism 进行执行和交易排序证明

将 IBC 扩展到 Celestia Rollup

以 Celestia 为例，你需要多个轻客户端来表示逻辑 Optimistic Rollup。Celestia 提供了共识证明作为数据可用性和交易排序的证明。

我们可以在连接到 Celestia Rollup 的 IBC 链上查看模块化 IBC 的实际操作：

· 一个 Tendermint 轻客户端（TMLC），代表 Celestia 进行数据可用性和交易排序证明。

· 一个带有 Celestia 条件规则的 Optimistic 轻客户端，代表 Optimistic Rollup 进行执行证明。

——该规则将确保在最终确定一个数据块之前，Celestia 网络上有一个数据块可用。

请注意，多个 Optimistic 轻客户端将依赖于 Celestia TMLC。此外，对于逻辑 pessimistic Rollup，你可以有以下设置：

· 一个 Tendermint 轻客户端（TMLC），代表 Celestia 进行数据可用性和交易排序证明。

· 一个带有 Celestia 条件规则的 Tendermint 轻客户端（TMLC），代表 pessimistic Rollup 进行执行证明。

——同样，该规则将确保在最终确定一个数据块之前，Celestia 网络上有一个数据块可用。

使用 IBC 的 Eigenlayer 共享安全性

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

通过在 Ethereum 上增加一个罚没条件，EigenLayer 验证者可以签署消费者链头以提高安全性。如果 EigenLayer 集成了 IBC，跨链验证可以用于将 EigenLayer 验证者添加到消费者链的活跃验证者集。否则，消费者链仍然可以在 IBC 链接层面为连接的链提供一定程度的保护。

这将通过以下方式实现：

· 在 Ethereum 上对双重签名的链头进行罚没，这意味着如果 EigenLayer 验证者为消费者链双重签名一个链头，EigenLayer 上 1/3 的质押将被罚没。

· 连接到启用了 IBC 的 EigenLayer 消费者链的区块链需要运行两个轻客户端——一个用于 EigenLayer，另一个用于消费者链。

· 连接的链将在接受之前验证链头是否已经被消费者链和 EigenLayer 签署。

· 这意味着与 EigenLayer 消费者链的 IBC 连接可以进行分叉并提供额外经济保护以抵御攻击。