无需信任的跨链桥

这篇文章深入探讨了一种旨在实现跨链通信的信任桥接解决方案，主要强调了轻客户端协议、Merkle Mountain Range（MMR）和Beefy最终确定性技术的重要性。作者对当前的多链未来进行了分析，提出了如何实现无信任的跨链桥接，强调了这些新技术在确保跨链安全和提高效率方面的关键作用。

一个普遍的看法是，多链的未来注定将是一个多签名（multisig）的未来，其中中继者由多个内部成员控制，以监视和促进锁定与释放机制；此外，建立无信任的桥梁是“不可能的”，唯一的解决办法是通过硬分叉让第三方在网络之间解决冲突。行业内知名人士如 Vitalik Buterin 和 Rune Christensen 均对此发表了明确看法。

在 Composable，我们同意通过多签名操作的受信任桥梁并不是一种长远的解决方案。然而，我们认为现在得出无信任桥梁是不可能的结论还为时尚早。从理论上讲，如果我们能够就两条网络的真实状态达成一致并解决可能出现的不同分叉，则可以将一条网络的规范真实性传递到另一条网络。让两个网络以无信任的方式进行通信可能是一个大胆的追求 — 在网络内部通信如 Polkadot 的 XCM 或 Cosmos 的 IBC 仍在逐步推出和优化；但这是我们必须解决的问题，以实现无缝的跨链未来。如果没有无信任的桥梁，我们就被迫在流动性、信息和技术开发上陷入孤岛。

我们很高兴地分享我们在这方面的最新进展。在等待社区的评审时，该设备将使 Cosmos 链能够跟踪 DotSama 平行链的最终性，这是建立连接 Cosmos 和 DotSama 之间的 Centauri 桥的第一步。在本文章中，我们将提供更多背景信息并介绍让我们构建无信任桥梁的关键技术 — 轻客户端协议、Merkle Mountain Range 树，以及一种新颖的最终性设备。

轻客户端协议

高效的轻客户端协议对于区块链协议的去中心化和主流采用至关重要。它通过允许计算和内存资源受限（如移动设备、链上合约）的环境，不必执行和存储完整区块数据和状态即可验证最新的区块链状态。轻客户端通常只跟踪区块头，而不需要跟踪完整的区块和执行交易到达最新状态。需要注意的是，区块实际上只是头部和交易：

区块中的交易大小可能会有所不同，但头部有固定大小，通常不超过 1kb。有趣的是：比特币头部大小实际上是 80 字节，而以太坊是 508 字节。

放大区块头

轻客户端协议由交易 Merkle 证明、状态证明、共识证明和最终性证明的组合组成，所有这些通常包含在区块头中，除了最终性证明。因为最终性证明可能与共识证明不同，并且需要的数据显示是头部的扩展。让我们更详细地看看每一种。

交易根

这是已经在该区块中执行的所有交易的 Merkle 根。可以将这种 Merkle 根视为一种加密压缩，允许我们无信任地验证某些数据是否属于通过 Merkle 证明 压缩的原始数据。

因此，检查某个元素是否包含在根中的 Merkle 证明所需的日志为 log2(n) 的哈希，通常为 32 字节。在上面的图中，我们只需要 4 个蓝色轮廓的哈希来验证或者重构原始根哈希，以证明 K 确实是原始 Merkle 树的一部分。其中： n = 16， log2(16) = 4。这使得轻客户端能够有效地检查在一个区块中执行了哪些交易，而不需要下载可能包含成千上万交易并必须线性扫描的完整区块列表。

状态根

区块链的状态根类似于交易根，它是数据的加密压缩输出。然而，交易根是一组交易数据的压缩，状态根可以看作是键值对的压缩列表。

以太坊的状态 Trie 架构

因此，键和值是合约或核心区块链子系统（如共识协议存储的权威者列表及其权益）在区块链上存储的数据。通过将这些数据压缩为一种 Merkle 根，我们仍然能够在不维护整个区块链状态的情况下，通过根哈希和 Merkle 证明检查某些键和值的存在，同时也具备与完整节点相同的无信任保证。

共识证明

区块有效性的共识证明通常包含在其头中，其格式完全取决于区块链的共识协议。对于工作量证明（PoW）系统，共识证明是一个满足以下等式的随机数：

如上所示，找到满足该等式的值需要大量的计算，因为哈希函数不能暴力破解，而验证这种共识证明则成本较低且快速。

同时，权益证明（PoS）协议的共识证明通常是可验证随机函数的输出，其中：

对于大多数区块链协议，其共识机制通常只保证 存活性¹，因此验证这些共识证明仅告诉我们该区块是否有效。然而，它并没有告诉我们该区块是否应被 视为最终的。在 PoS 的情况下，未由已知权威集中的公钥签名的块将被认为是无效的。共识证明为网络上待最终化的区块向节点提供信任保证，因为在拜占庭系统中，可能会产生相同区块高度的竞争区块。最终化协议完全有责任提供 安全性² 保障。

（有趣的是，Polkadot 使用混合共识协议，其中 Babe³ 保证 存活性¹，而 Grandpa⁴ 保证 安全性²）

最终性证明

为了让轻客户端验证事件在链上发生，它们需要最终性证明，即交易在一个区块中是最终的，且该区块永远无法被撤回的加密证明。这些证明可以是头部的一部分，也可以与全节点的头部一起请求。

对于工作量证明区块链，这个“最终性证明”实际上嵌入在头部中，作为工作量证明的随机数。但单独这一点并不足以保证最终性。相反，我们需要一定数量的有效头部也将该头部作为其父头部，以便对其最终性有真正的信服。可以想象，这增加了希望对最终性有信服的轻客户端的存储要求，因为他们必须存储 n 个头部以验证 n-1 个头部的最终性。

即便如此，最终性完全是概率性的，并且取决于用来推导工作量证明随即数的哈希函数的安全性。

对于权益证明区块链，最终性证明通常不包含在头中，而是可选地可供轻客户端请求以获取头部。最终性证明通常由已知权威集的签名组成，他们在网络上进行质押并签署他们认为是网络最新区块的重要信息。该系统中的最终性证明是来自已知权威集中 2/3 + 1 的签名，根据保护假设，少于三分之一的权威集是恶意的。

祖先证明

不幸的是，大多数最终性证明要求轻客户端了解所有已经最终化的头部的完整链，以便跟踪最终性协议。为了通过或轻客户端之间进行无信任桥接，我们需要更小的祖先证明，这些证明不需要了解区块链中的每个头部。

我们可以尝试使用 Merkle 树来实现这一点，轻客户端简单地跟踪到目前为止看到的所有区块头的 Merkle 根。这将使我们能够使用 Merkle 证明来证明对任何头部的最终性，而这些轻客户端只知道所有已最终化区块的 Merkle 根。但是，由于 Merkle 树的结构，我们必须从创世区块重新计算从创世区块到最新区块的完整树结构，对于每个新块!

一些快速计算：

树高 = log₂(1,000,000) // 一百万区块

树高 = 20

树中的节点 = 2^(20 + 1) — 1

树中的节点 = 2,097,151

在已经具有一百万个区块的区块链中，需要为每个新块重计算 2,097,151 个节点的计算是令人惊讶的。我们需要一种树结构，它能保持 Merkle 树的 log2(n) 证明大小，同时在向树添加新数据时能够以某种方式重用对树中较旧节点的先前哈希计算。让我们简要了解 Merkle Mountain Range 树，以及它们如何实现高效的祖先证明。

Merkle Mountain Ranges

Merkle Mountain Ranges (MMR) 是一种特殊的 Merkle 树，它本身由大小完美的二叉子树按高度降序组成。例如，具有 1,000,000 个叶子的 MMR 树将由高度分别为 19、18、17、16、14、9 和 6 的 8 棵完美子树组成。

它确实符合其名称，看起来像山脉

MMR 的一个关键特性是，在向树中添加新叶时，我们可以重用先前的计算（根哈希）。向现有 MMR 树添加新叶的规则要求我们合并任何两个相同高度的子树（将粉色部分与蓝色部分合并到蓝色哈希），因此我们永远只有一棵每个高度级别的子树。

这里我们只有 2 棵子树

我们合并相同高度的子树

Merkle Mountain Ranges 在证明中也非常高效，因为树本身是由子树组成的。由于 MMR 子树以高度降序排列，第一棵子树通常是计算量最大的。也意味着随着列表的增长，添加新的叶子实际上是更便宜的。

在我们的树中，需要证明项目最多的子树是第一棵子树，4 + 2（其他 2 棵子树的峰值节点）= 6 个证明节点。MMR 的美妙之处在于在添加新的叶子时，我们从不需要重新计算第一棵子树的哈希，只需要处理更新的哈希。

MMR 将“轻量”放入 Beefy 轻客户端

通过 Beefy 协议，权威集为轻客户端生成额外的最终性证明，其中包括在某给定高度由 grandpa 最终化的所有区块的 MMR 根哈希。引入此协议后，轻客户端不再需要了解链中所有的头部才能对最终性有信服。这大大减少了轻客户端跟踪链共识所需存储的数据量，仅需 124 字节!

Beefy 的初步 规范 已经可用，并且主要已实现，还有一些需要解决的小问题。但从高层次来看，这是一个无需硬分叉就能添加到 Polkadot 的新协议。得益于 WASM 运行时和链上治理协议，该新协议将为轻客户端生成更加轻量化的最终性证明，用于链上和链下的应用。它将通过现有的 Grandpa 权威集定期投票于所有由网络视为最终的区块的 Merkle Mountain Range 根哈希。

pub struct BeefyNextAuthoritySet {
    /// 下一个集合的 ID。
    ///
    /// ID 需要将 BEEFY 签署的承诺与验证者集相关联。
    /// 轻客户端可以轻松验证其获取的承诺见证是由最新的验证者集生成的。
    pub id: u64, // 8 字节
    /// 集合中的验证者数量。
    ///
    /// 一些 BEEFY 轻客户端可能使用交互协议仅验证签名的子集。我们在此处放置集合长度，以便这些客户端可以验证最小数量的所需签名。
    pub len: u32, // 4 字节
    /// 从 BEEFY AuthorityIds 构建的 Merkle 根哈希。
    ///
    /// 这由轻客户端用于确认承诺是由正确的验证者集签署的。采用交互协议的轻客户端，可能仅验证签名的子集，因此不需要在此处保留完整列表（将接收包含证明）。
    pub root: H256, // 32 字节
}

// 轻客户端跟踪的 relay chain 共识所需的数据
pub struct BeefyLightClient {
    pub latest_beefy_height: u32, // 4 字节
    pub mmr_root_hash: H256, // 32 字节
    pub current_authorities: BeefyNextAuthoritySet<H256>, // 44 字节
    pub next_authorities: BeefyNextAuthoritySet<H256>, // 44 字节

贡献于 Beefy 协议

在 Composable Finance，我们全力以赴地致力于实现一个跨链未来，通过我们积极推进无信任跨链基础设施、协议和生态系统应用的交付。我们在核心 Beefy 子系统中总共完成了 8 个 PR，在运行时和子树客户端中，正在等待 Substrate 桥接团队进行进一步审查。

11-BEEFY COSMOS-IBC 轻客户端

作为我们将 Cosmos 生态系统引入 DotSama 的努力的一部分，我们很高兴地宣布，我们已完成针对 Cosmos 生态系统的 beefy 轻客户端 的开发，目前正在使用 golang 开发！在进行进一步审核后，该轻客户端将合并到 IBC-Go 仓库，后者托管扫一扫豆的 Tendermint 轻客户端的规范实现。

我们的意图是我们的轻客户端将作为 Cosmos 链与 Kusama/Polkadot 平行链直接通信的规范轻客户端。该轻客户端的单个实例可以跟踪 Kusama 或 Polkadot relay chain 的最终性，并可用于证明任何连接的平行链状态的最终性。本着无信任的精神，我们已经用 说明 替换了一次演示，供大家运行测试以验证轻客户端的操作。你可以在此找到草案 规范。

Beefy 轻客户端是朝着构建连接 DotSama 和 Cosmos 的 Centauri 桥迈出的重要一步。总体来说，该桥由三部分组成：两条网络上的轻客户端，用于证明对另一个网络的最终性，以及中继器，用于转发 IBC 包和轻客户端证明。我们已完成在 Cosmos 一侧合并 Beefy 轻客户端的开发（待评审），而其他两个组件正在开发中。

总结

我们正在构建 Centauri，这是一个连接 Picasso（我们在 Kusama 的平行链）和 Cosmos 生态系统的无信任桥梁。面临的主要挑战是以无信任的方式达成对两个网络最终性的共识，从而保证跨链桥接的正确性和安全性。这是通过几项新技术实现的：首先，轻客户端允许节点无需下载完整区块数据即可验证区块链状态，从而确保轻计算需求和去中心化；其次，Merkle Mountain Range 允许新的区块头以“仅添加”的方式进行哈希，这比其他 Merkle 树更适合用于共识子系统；最后，Beefy 最终性设备利用 Merkle Mountain Range 以更高效的方式产生平行链的最终性证明。Composable 团队目前正在为核心 Beefy 系统做贡献，同时审查 IBC 轻客户端用于 Cosmos — 一旦与 IBC 合并，并经过进一步审核，这将允许 Cosmos 链与 Dotsama 上的 Substrate 链直接通信。

这只是我们跨链桥接努力的第一步。如果你想讨论无信任桥接的前沿领域，请通过 Twitter 联系我。

¹ & ² Lamport, Leslie (2005). “ 广义共识与 Paxos”。

³ 区块链扩展的盲分配

⁴ 基于 GHOST 的递归祖先派生前缀协议

  • 原文链接： medium.com/composable-fi...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
seunlanlege
seunlanlege
江湖只有他的大名，没有他的介绍。

seunlanlege

如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！