Grandine Ethereum共识客户端现已开源，旨在为以太坊社区提供一个快速、轻量级的客户端，支持从个人到大型机构的各种验证者。客户端采用了独特的核心设计，如并行化和低内存占用，并与现有其他客户端有所区别。未来计划包括接收用户反馈、参与早期测试网活动以及实现更长期的结构性改进。
Grandine Ethereum 共识客户端开源了！
我们在 2019 年开始构建 Grandine，当时已经有两个 Rust 语言的以太坊 2.0 客户端 —— Lighthouse 和 Shasper。因此，这个领域已经有两个 Rust 客户端以及其他多种语言编写的客户端，竞争非常激烈。我们唯一现实的选择是筹集非公共资金，并在保密模式下进行实验。我们的目标是，如果我们成功为社区创造了有价值的东西，就将我们的努力转化为公共产品。早期采用者对预发布版的积极反馈，促使我们坚定了开源 Grandine 的决心。
什么是 Grandine？
我们的目标是构建一个非常快速且轻量级的以太坊客户端。因此，我们构建了一个注重并行化和低内存占用的核心。Grandine 的初始理念与其他客户端有很大的不同，尤其是与另一个 Rust 客户端 Lighthouse 相比：
\* Grandine 有一个原创的分叉选择实现，而其他客户端都使用了 protoarray 分叉选择。这种方法帮助我们发现了一个 protoarray 实现中的 bug；
\* Grandine 从一开始就使用树状状态。整个客户端围绕“状态是廉价的”这一理念构建。这与基于扁平状态的客户端架构迥然不同；
\* Grandine 很长时间以来都是一个内存中客户端，没有任何持久存储。这种方法极大地提高了性能和降低了内存占用，并使我们的存储层非常轻量 —— 只需编写约 100 行代码即可添加另一个数据库后端；
\* 它从一开始就内置了验证者客户端。从长远来看，这并不是最好的架构，因为单独分离的客户端会更灵活，然而，这种方法非常轻量，符合我们最初的性能和轻量化目标。
人们经常问我们，Grandine 是否是 Lighthouse 的一个分叉。它不是。Grandine 始于不同的设计理念，从而发展出不同的核心共识实现。然而，这并不意味着 Grandine 不使用其他客户端团队维护的优秀库。例如，Grandine 从开始就使用了基于“rust-libp2p”的网络库，这些库由 Lighthouse 团队开发。Lighthouse 的“eth2_libp2p”库在那时就很通用，我们现在仍然使用它的一个分叉版本。我们还使用了 Akula 维护者开发的“libmdbx-rs”绑定库，现在我们使用的是由 Reth 团队维护的分叉版本。因此，我们专注于原创的共识核心，因为它代表了 Grandine 为社区提供的独特价值，但我们也非常乐意使用其他客户端团队和社区开发的一些优秀 crate。我们还乐于构建诸如“rust-kzg”这样的库，它们对其他客户端团队也有帮助。没有其他客户端团队和社区的努力，Grandine 不会有今天的成就！非常感谢大家！
谁可以使用 Grandine？
Grandine 既是一个高性能的客户端，也是一个轻量级的客户端。这意味着该客户端适用于广泛的质押者，包括在资源有限的设备（如 Raspberry Pi）上运行的 solo stakers，以及运行数万个验证者的大型机构 stakers。我们已经看到寻找快速轻量客户端的 solo stalkers 越来越多采用 Grandine。我们相信，这种采用将逐渐扩展到更大的机构 stakers，因为客户端可以在一台机器上处理大量验证者，从而节省大量成本。例如，我们在一台开发机器上运行了 50,000 个 Holesky 验证者。运行如此多的验证者几乎毫无成本！
接下来的计划是什么？
接下来几个月，我们将全力关注用户反馈。通常新用户会向我们报告一些相对容易实现的细节，这会使客户端更加完善。现在是成为早期采用者的最佳时机，因为你的反馈将得到最多的关注。与此同时，我们将更多地参与其他客户端团队正在参与的活动中，例如参与新硬分叉的早期测试网、协议研究等。更长期的关注点将放在较大的结构性变化上，比如单独的验证客户客户端。我们还需要全面转换为一个公共产品项目。这也意味着公共物品的资助和涉及 Grandine 的收益模型，比如节点运营者活动，因为我们迄今的资助模式在开源的公共物品模型中无法运作。所以如果你喜欢 Grandine，我们将非常感谢你的支持。我们感谢所有到目前为止支持了我们的人（Optimism Retro PGF 等等）!
我们长期的奋斗目标是什么？
我们第一个长期目标是助力分散化 Ethereum 共识层，实现网络中各客户端最多仅占有少于 1/3 主网验证节点的份额占比。这不仅能屏蔽单个客户端 bug 导致的取非终结性问题，也更能在强制执行无效链通过至少需要三个客户端同时出现相同 bug。社区已经成功地脱离了超级大多数具有共识层客户端的风险，并期待下一阶段目标的实现。这一定在社区的支持下完成！让我们一起努力吧！
特别感谢 Thorsten Behrens、Isidoros Passadis 和 James Smith 对本公告草稿的反馈。
