内容摘要与导读：
Gattaca 发布全新以太坊共识客户端 Silver，从零构建，重点优化性能与健壮性。Silver 基于线程分核、无共享、非阻塞的 Flux 框架，使用 6 个绑定 CPU 核心的 tile 并行处理，并实现了新的 p2p 网络、状态哈希库以及面向现代 CPU 优化的 BLS/KZG 密码库。官方称状态转换 p99 延迟低于 10ms，可每 slot 聚合全部 attestation 子网，并支持节点集群实现 slashing 保护与零停机。主网窗口对比中，Silver 区块处理中位数 6.5ms、p99 9.5ms，低于 Prysm、Lighthouse、Grandine。超级节点在全订阅和全数据列托管下延迟与内存仍保持相近。项目目前为 alpha，审计和最终测试待完成，后续将推进 Quick Slots 与后量子聚合。
今天要介绍的是 Silver，Gattaca 推出的全新以太坊共识客户端，从零开始构建，目标直指性能与健壮性。
我们的愿景是让以太坊更快，拥有更短的 slot 时间和后量子安全性。我们希望在实现这一目标的同时，保持并增强网络的去中心化、抗审查、隐私和安全性。Silver 是完全开源软件，任何人都可以在其上构建，并验证真正重要的事情：
- 状态转换函数的 p99 延迟 <10ms：比其他客户端快约 10 倍（包括 epoch 转换）
- 每个 slot 聚合所有 attestation subnet，且性能无损
- 用于 slashing 保护和零停机的节点集群
实时 dashboard： https://silver.gattaca.com 。
Silver 完全从零编写。不过如今开发新的共识客户端已经容易许多，这要归功于优秀的规范、测试套件、devnets，以及以太坊研究人员和核心开发者共享的丰富经验——他们在构建和运行以太坊 beacon chain 方面做出了出色工作。
Silver 目前处于 alpha 阶段，审计和最终测试仍在进行中。
我们对以太坊的押注
我们对以太坊的信念建立在其去中心化以及围绕它形成的网络效应之上。开发者、运营者和用户多年的工作创造了一个几乎不可能复制的网络。我们希望保持并增强其对抗审查、开源、隐私和安全的承诺，同时让它成为一个更好用的网络。
这意味着要平衡可能相互拉扯的需求。更强的安全性可能需要更多计算和带宽，而广泛参与则取决于让独立运营者能够承受这些负担。响应更快的网络给客户端完成工作的时间更少。我们认为研究和工程可以帮助以太坊同时满足这些需求。
更短的 slot 和后量子安全性是两个典型例子。提出的后量子 attestation 方案涉及更大的签名和更苛刻的聚合，繁重的证明生成被分配给专门的聚合器。
与此同时，十二秒区块限制了以太坊能提供的体验。更多执行容量和更低费用将有助于让以太坊 L1 更有吸引力，但活动的增加也需要更低的延迟。
我们认为，通过更好地利用已经在运行以太坊的硬件，在实现层面还有相当大的改进空间。这些收益可以通过客户端版本发布，而无需更改共识规则或等待硬分叉。一个增加昂贵计算的提案，如果搭配抵消新增成本的优化，就不一定提高硬件要求。
我们希望让这些收益在整个生态系统中可用，从而加速以太坊的发展。我们将发布可复用库、测量数据和设计说明，供其他团队评估和采用。
对于确实需要硬分叉的变更，Silver 提供了一个实现，可以与其他客户端团队一起开发和测试提案。我们正在开始 Quick Slots 和后量子聚合方面的工作，目标是将这些工作推进通过 devnets，并为未来升级决策贡献可运行代码和测量数据。
按设计实现性能与规模
Silver 构建在 Gattaca 的 thread-per-core、share-nothing、non-blocking Flux 框架之上。Silver 使用 6 个固定到 CPU 核心的线程——我们称之为“tiles”（感谢 Firedancer 提供这个名称）。不同的 tile 并行工作，并通过显式队列传递消息。
Silver 附带：
- 新的 p2p 网络实现，专为低延迟和高吞吐量构建（最高 2 Gbit/s 的 gossip 流量，亚毫秒级开销）
- 新的状态哈希库，哈希性能最高提升 2 倍
- 新的经过形式化验证的 BLS 和 KZG 加密库，针对现代 CPU 优化，性能提升超过 2 倍
- 用于 slashing 保护的节点集群（在一组 beacon node 集群中保证 attestation / 区块提议至多一次）
请关注未来关于这些库的文章！
性能
我们在同一个 mainnet 窗口期内比较了 Silver、Prysm、Lighthouse 和 Grandine，时间为 2026 年 10 月 17 日至 20 日。每个客户端处理了相同的 20,300 个 canonical 区块。
Silver 的区块处理延迟中位数为 6.5 ms，而第二低的中位数为 33.5 ms。其 p99 为 9.5 ms，第二低报告的 p99 为 91 ms。这分别相差 5.2 倍和 9.6 倍。样本中最慢的 Silver 区块耗时 17.8 ms。
Validator 需要及时处理区块以进行 attest。更低处理延迟在区块迟到或其他检查耗时更长时留下更多余量。
四个客户端都作为 supernode 运行，订阅全部 64 个 attestation subnet，并托管全部 128 个 data column。每台机器使用 AMD EPYC 4585Px CPU 和 64 GB RAM。共识客户端和执行客户端运行在独立的八核 chiplet 上，执行客户端为 ethrex v29.0.1。
比较使用每个客户端可用的共识处理指标，不包括执行客户端处理。状态转换延迟的测量方式如下：
- Silver：从 gossip 到达到状态转换完成，来自 Silver 的 telemetry。
- Lighthouse：来自其日志的 consensus_time_ms（从 gossip 到达到共识验证完成）。
- Prysm：ExecuteStateTransition OpenTelemetry span。这仅是状态转换。
- Grandine：来自其 LogBlockProcessingTime 日志的“processed in”。这是从提交到 store 插入，减去等待数据而停放的时间。
Epoch 边界会给区块处理增加工作。Silver 在区块之间准备 epoch 工作，减少边界区块到达时剩余的工作量。在本次运行的 616 个 epoch 边界 slot 中，其中位数为 6.2 ms，p99 为 8.9 ms。
规模
在一项单独的实验中，我们在相同硬件上比较了 Silver 的默认配置和 supernode 配置。默认节点订阅两个 attestation subnet，并托管八个 data column。supernode 订阅（并聚合）全部 64 个 attestation subnet，并托管全部 128 个 column。
与最小节点相比，supernode 每个 slot 验证（在本例中还聚合）的 attestation 数量是 32 倍，平均验证的 KZG cell proof 数量是 16 倍。区块处理延迟和常驻内存保持在同一范围内。
在此工作负载中，额外的验证工作对区块处理延迟或常驻内存几乎没有影响。网络流量和 column 存储随着额外职责而增加。这些内存数据涵盖 Silver 进程，不包括执行客户端。
公开测量数据
Dashboard
查看我们的实时节点和完整性能数据： https://silver.gattaca.com 。
在“Slots”面板中，你可以点击并展开从 block recv 到 attestation 流水线的不同阶段，并比较我们的最小节点 silver-client-a 与 super node silver-client-b 的性能。
在“Peers”和“Gossip”面板中，在两个客户端之间切换，并点击行以展开更多详细信息。
“Data flow”面板显示 Silver 的 tile 之间的数据流详细信息。在消息队列和 tcaches（批量数据环形缓冲区）视图之间切换。点击各个链接以查看进一步详细信息。
Xatu
我们的四个比较节点也向 ethPandaOps Xatu 报告。它们的活动可在 The Lab 的 slot 时间线 中看到，位于法国的贡献者 listeningammonia96 下。在这个记录的 slot 中，Silver 被标记为 unknown。时间线包括执行客户端处理和等待 data column 的时间，因此它们涵盖的路径比上面的共识处理测量更广。
未来的工作
Gattaca 正在资助一个专门的内部团队来开发和维护 Silver，作为对以太坊的长期投资。加固客户端是当务之急，包括审计和最终测试。
我们已经在文档化假设下，发布了针对选定的加速 BLS 解码、子群检查和 KZG cell 操作的 Lean 证明。我们打算随着 Silver 的发展扩展这项工作。
我们计划将哈希实现提取到一个独立库中，以便其他客户端可以直接对其进行基准测试，或在自己的实现中使用该设计。随着 Silver 的发展，我们将发布更多测量数据，同时还会发布我们在更短 slot、后量子聚合和网络方面的工作。
只有当每个客户端都变快时，以太坊才会变快，因此我们正在发布并打包我们构建的一切，供其他团队使用。享受吧！
原文链接：x.com/gattacahq/status/...
发表于 前天 23:20
|
查看: 18|
回复: 0
/1 
