Altair并非轻客户端

一张星星的照片，因为 Altair 是一颗星星或者什么。照片由 Jake Weirick 在 Unsplash 上拍摄

背景信息

在 Altair 硬分叉中，eth2 引入了一个链上协议系统，可以支持信标链 轻客户端(light client)。轻客户端 是一个遵循共识过程的节点，但不会验证和重新执行区块内容。这是一种“仅头部”模式，用于同步区块链。对于那些懒得一直运行服务器，但又不想仅仅相信 Infura 的人来说，轻客户端 很有吸引力。最著名的 eth2 轻客户端 实现是 Helios。

相对于完整客户端，轻客户端 的安全性有所降低。因为它不验证区块主体或面向用户的状态（仅验证头部和共识状态），所以 轻客户端 必须假设非共识状态和状态转换是正确的。由于历史原因，我们将此称为“SPV 假设”。有关 轻客户端、SPV 假设和 ZK 轻客户端(ZKLCs) 的更多入门知识，你可以查看我在 Starkware Sessions 2019 上的演讲。

没有人，我的意思是 没有 人，对链上 eth2 轻客户端 有一个可信的设计。它们都很糟糕。有人需要制定一个明智的、标准化的、可审查的、合理的、值得信赖的规范。

Altair 轻客户端

Altair 轻客户端(我称之为“ALC”)有一个非常简单的设计。每 256 个 epoch（大约 27 小时），共识过程会选择一个由 512 个验证者组成的委员会。如果这些验证者签署并提交对最新信标链区块的证明，他们在此期间会收到大约 0.1 个 ETH（每个）。如果这些证明没有包含在下一个区块中，他们将被处以相应数量的 ETH 罚款。如果这些证明包含在下一个区块中，提议者也会收到少量额外的奖励。当前和下一个同步委员会列在区块头中，因此 轻客户端 可以“展望”下一个同步委员会。

为了同步链，轻客户端 会保留一个本地头部，并记录当前和下一个同步委员会。然后，他们可以使用同步委员会的签名来更新他们对链状态的本地视图。因为同步委员会对头部进行签名，而头部承诺了链的最终性，所以 轻客户端 可以很容易地发现最新的最终头部。这使得它可以快速启动并加入网络。我显然忽略了一些实现细节。如果你对完整的 ALC 规范感兴趣，你可以在这里找到它。

同步委员会的行为不受约束

ALC 的设计依赖于同步委员会的签名。轻客户端 获取同步委员会的证明，并将它们应用于他们对链的本地视图。不幸的是，对于这个签名可以是什么，没有协议约束。同步委员会因生成有效的证明而获得奖励。他们不会因无效的证明而受到惩罚。委员会可以撒谎。委员会成员可以随意对任何东西产生任意数量的签名。他们不能被罚没。并且只要他们除了错误的签名之外还生成正确的签名，他们就会获得全部奖励。同步委员会的主导策略是盲目地签署任何人呈现给他们的每一个头部，以便他们能希望击中正确的一个。

这允许同步委员会成员进行协调，从而导致一些退化的情况：

• 轻客户端 可能会收到许多在语义上无效的证明，但签名有效。

• ZKLC 可能会收到有效的证明，但数据在语义上无效。

• ZKLC 可能会收到有效的证明，但数据被扣留。

此外，同步委员会的惩罚很小（每个验证者在 27 小时内上限约为 0.1 ETH）。因此，对于一个委员会来说，仅仅在一段时间内不产生任何有效的证明是很便宜的（大约 82,000 美元或 0.3% 的权益）。为了稍微损失一点回报，同步委员会可以确保 只有 无效的证明可用。因为同步委员会的行为不受共识过程的约束，所以 ALC 的设计没有从基础链共识过程中继承任何经济安全性。委员会可以随意签署任何东西。

一张小鹅跟随父母的照片。Altair 轻客户端 就像小鹅一样，它们很笨，如果你假装成鹅，它们就会顺其自然，做任何你想做的事。照片由 Vivek Kumar 在 Unsplash 上拍摄

Altair 无法桥接

链上 轻客户端 桥，如 TBTC 和 IBC，需要 SPV 假设。在一个链上验证另一个链是不可能的（没有递归 ZK 链（别抱太大希望））。轻客户端 桥会等到它们高度确信远程链已经最终确定后，才接受跨链消息或转移。它们通过遵循共识过程并做出 SPV 假设来实现这种信任。一个错误的假设是灾难性的。开发人员需要彻底理解给定共识系统的 SPV 假设的局限性。

给定链的 SPV 假设的安全性总是被表达为一个非此即彼的陈述。“ 要么 状态是正确的 要么 [发生了特定的故障]。”我们希望这个故障尽可能昂贵和不太可能发生。并且我们希望在出现问题时有后果。

• PoW：“ 要么 状态是正确的 要么 在伪造的头部上花费了大量的 工作量证明(Proof of Work)”

• Tendermint IBC：“ 要么 状态是正确的 要么 整个链都出现故障。”

• ALC：“ 要么 状态是正确的 要么 同步委员会决定从我们这里偷东西。”

PoW 轻客户端 伪造的成本很高。IBC 轻客户端 伪造会产生重大后果。与其他 轻客户端 设计不同，ALC 允许同步委员会简单地签署一个错误的证明，而无需付出成本或承担后果。

假设一个桥使用 ALC 系统来更新其状态。同步委员会成员可以随时选择向桥提供无效的信息，而无需承担任何惩罚。该桥依赖于来自没有约束的参与者的签名。ALC 相当于一个 多重签名(multi-sig)。然而，与 多重签名 不同，ALC 多重签名 每 27 小时更改一次，是随机选择的，并且与桥没有任何关联。同步委员会没有任何协议内的理由不从桥上偷东西，并且可能有很大的经济动机去偷。编写一个类似于 flashbots 的客户端修改程序，机会主义地伪造同步委员会的证明并利用 轻客户端 并不困难。

ALC 与 多重签名 无法区分，但是桥无法选择其参与者。随机 多重签名 是更糟糕的 多重签名。永远不要对未知方做出诚实假设。

一张灯塔的照片。它是一个信标。就像这条链。明白了吗？说实话，我只是用这些来打断文本。照片由 Alfred Leung 在 Unsplash 上拍摄

题外话

ALC 设计适用于链下 轻客户端，因为它们可以使用它来引导对共识过程的看法。它们不是简单地信任同步委员会，而是必须根据其对验证者集合的本地视图来验证其更新。然后，它们必须验证历史 epoch 证明和验证者集合漂移，以确保同步委员会的证明检查无误。也就是说，同步委员会是一个 多重签名，可以帮助同步最近的事件。

如果 轻客户端 不验证 epoch 委员会的证明，它就无法防御恶意同步委员会，因此没有经济安全性。轻客户端 需要验证历史 epoch 委员会证明以获得经济安全性的要求没有在规范中记录。目前尚不清楚设计者是否完全理解这一要求。

轻客户端 从协议中获得安全性，在其 SPV 假设的范围内。因为 ALC 没有从协议中获得任何经济安全性，所以它不是 轻客户端。相反，我会称它为 轻客户端 的引导机制。ALC 设计代表了以太坊生态系统的首创：官方认可了一个没有经济论据的诚实假设。不知道我对这种进军 Cosmos 政治理论的感觉如何。

解决方案

轻客户端 桥可以实施两个合理的解决方案来在今天中继 eth2。

首先，它们可以像链下 轻客户端 那样遵循 epoch 委员会的证明。与同步委员会不同，epoch 委员会并未明确在区块头中承诺。因此，该解决方案将要求 轻客户端 维护一个对（非常大的）验证者集合的本地视图，并检查每个 epoch 的正确 epoch 委员会选择。错过一个 epoch 将需要重新启动桥。因为这需要更昂贵的计算（跟踪验证者集合很难）和更频繁的计算（每 12 分钟而不是每 27 小时），所以相对于简单的 ALC 同步委员会跟随者来说，这对于链上 轻客户端 来说是一个惊人的成本增加。

或者，他们可以引入自己的 多重签名，并具有新的定制激励。ALC 委员会是一个不受约束的链状态 预言机(oracle)，所以为什么不创建你自己的链状态 预言机，并使用你更喜欢的约束呢？这似乎很可能发生，因为它是一个可以强行插入代币的好地方。一个专门为 轻客户端 服务的单独委员会对于链上 ZKLC 尤其必要，这些 ZKLC 容易受到数据扣留攻击，并且除了新的激励区块链状态 预言机 委员会之外，还需要一个 DA 委员会。

这些解决方案都不能让人满意。

第三个选择（是的，我说了两个 合理的 解决方案。这是不合理的解决方案）是硬分叉以添加显式的 epoch/slot 委员会承诺。显式承诺使我们能够直接验证聚合证明，而不是依赖同步委员会。如果我们能够将 轻客户端 直接连接到可被罚没的证明，那就太好了。如果硬分叉正在讨论中，那么这个问题是可以解决的。但是，与此同时，我们必须处理我们所拥有的东西

现状

ALC 不适用于桥。它们仅适用于作为引导机制的链下 轻客户端，并且必须遵循 epoch 证明验证。Altair 不是 轻客户端。它是新共识跟踪节点的快速同步助手。虽然它本身很有用，但偷梁换柱令人讨厌。轻客户端 从共识过程中获得安全性。Altair 从一个新的诚实假设中获得安全性。

用于桥的 Eth2 轻客户端 解决方案都很糟糕。我们可能会看到混乱的混合方案。我们不太可能在未来的 eth2 硬分叉中看到真正的 轻客户端。老实说，我宁愿选择 多重签名，也不愿选择所有这些 Eth2 轻客户端 的混乱。

• 原文链接： prestwich.substack.com/p...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～