来源 | Ethereum Community Conference

译者注：此次分享由开发者 Piper Merriam 与 Angela Lu 共同呈现。此文非视频逐字转译。

第一部分由 Piper Merriam 分享

此次分享的大纲如下:

• 以太坊客户端的现状
• 无状态以太坊
• 更好的以太坊客户端

更优的以太坊客户端有四个指标:

• 低资源设备 (low resource device)(例如，手机、树莓派、笔记本电脑)
• 不需要同步 (No Syncing)
• 可扩展性 （Scalable)
• 使用相同的 JSON-RPC

以太坊客户端的现状

现在的以太坊客户端是非常重型的软件，它需要几百GB 的磁盘空间，你的 cpu 要运转非常长的时间来同步数据。但这不是客户端团队的工程能力问题，而是由我们的网络协议决定的。我们的网络协议是 DevP2P，是一个点到点的网络，其中一个协议叫 "ETH" ，也是所有以太坊客户端所在的地方。

在该网络里，有非常多的信息在客户端间传输，包括广播 (gossip) 未被打包的新区块和新交易、检索历史数据 (history)的信息 (如旧区块、旧收据等)，以及状态同步（尽管这实际上已经被snap protocol 取代了)。尽管这些东西决定了以太坊客户端必须有哪些功能，但同时你也必须满足这些条件才能作为客户端进入 DevP2P 网络——你必须有完整的状态、能够处理整个交易池、你需要存储所有的链上历史数据，而这些都是导致以太坊客户端如此重型的原因。这是我们想要改变的东西。

不幸的是，要与以太坊网络交互的选择只有两个极端的选项——自己运行非常重型的客户端，或使用像 Infura 和 Alchemy 这样的中心化服务。现在还没有既轻量、又去中心化的客户端，但这是我们努力的方向。

LES (light ethereum subprotocol) 是一个轻量以太坊子协议，它已经存在很多年了，但无法用它开发出一个可靠、轻量的方法来访问协议。因为根本上，它是以客户端服务器的架构来构建的。网络容量取决于服务器，而客户端寄生于网络，且不会对协议做贡献。你无法在一个网络里加入任意数量的客户端。所以 LES 无法解决问题的原因是很清楚的。

什么是“无状态以太坊”

无状态以太坊由多个团队一起研究，工作已经进行了2年了。当我们谈论无状态以太坊时，其实我们在说区块执行模型。总的来说，这就是区块链的工作原理。“之前的状态根 (Previoius State Root)" 代表当前区块之前的区块链状态（包括账户余额、合约存储、代币余额等），区块由事务组成 (例如代币转账、状态转换)，当区块被执行，这些执行后的事务都转变为”后状态根 (Post State Root)"。当我们说无状态以太坊时，说的是这种二分法。目前所有的客户端都是左边 (看下图）的情况——满状态 ("statefull")。它们维护一个非常大的状态数据库，它们也是用这个数据库来做区块执行，负荷非常大。

当我在说无状态以太坊的时候，我说的是对共识协议的修改，使一个不同的区块执行模型变得可行。这个模型基于见证数据 (witness) 这个神奇的东西，它们可以提供执行某特定区块所需的东西。因此，在无状态模型里，不同于管理一个状态的数据库，客户端实际上不需要存储状态、甚至没有任何关于状态的信息，而只需要知道区块链头是什么样的。无状态客户端从网络上获取见证数据，用它来执行区块。这就是我们说无状态以太坊代表的意思。

我们需要“无状态以太坊”

我们的共识基础设施从根本上需要无状态以太坊，它与验证者基础设施有关。尽管分片的规范还没有确定下来， 所以这里讲的只是一个近似情况。但重点是，我们有一个一个的分片，验证者在这些不同的分片里被混洗，然后在被分配到的分片执行他们的职责，职责之一就是验证最新的状态转换，验证最新的区块执行从前一个状态根转到到下一个状态根。我们之所以需要无状态，是因为在“满状态”模型里，验证者要履行他们的职责，他们实际上必须追踪每个分片的状态，这样的工作量太大了。几乎不可能要求他们这样做。因此我们必须转用无状态模型，使验证者在被分到任何分片里没有开销负担，并可以快速获取见证数据，进行区块执行验证。这就是我们需要无状态的原因。

轻量级客户端？

无状态客户端虽然不需要状态数据库，但这并不意味着我们就实现了既去中心化、又是轻量级的客户端。简单来说，无状态客户端模型能实现用低资源设备来验证区块执行，客户端可以在链的前面直接接入网络，并开始执行区块。但在给客户端减负的过程里失去了一些重要内容。

第二部分由 Angela Lu 分享

我想让大家把现在的以太坊客户端想象成你最喜欢的披萨，它有代表着共识基础设施的面包皮，也就是基础，面包皮上有芝士、香肠各种料，这些代表面向用户的功能，例如提交交易、构建交易、JSON RPC API。现在问题是披萨太重了，我们现在要做的是拿掉所有的料，只留下面包皮，这就是无状态客户端。但我们不想要这样的无状态客户端。

无状态客户端不存储状态和区块链历史数据，这些东西都对带宽、CPU、存储有很高的要求。而当我们不存储这些东西时，我们就失去了面向用户的功能——无法加入 DevP2P 网络，无法像一般以太坊客户端那样发送交易、甚至不能构建交易，或使用 JSON RPC API。但我们非常想要这些面向用户的功能。Piper 的团队用了三年时间尝试将轻量节点接入以太坊网络，但它们从根本上来说是完全不同的东西，所以行不通。

我们构思出了门户网络 (The Portal Network)，一个针对轻量客户端的全新 P2P 网络。

我们是这样实现的：

首先把重型的操作从客户端转移到网络层，即由门户网络来负责；

第二，我们放弃了LES现有的客户端服务器架构。因为我们希望可以有更多的客户端加入，网络变得更强大，我们从 Bittorent 获得灵感——多个小客户端加起来的净总容量和可以实现几个大型客户端可以实现的相同功能和容量。

现在有了门户网络，我们就有了最终构建功能完备的轻量客户端的基础了。它们是低资源设备、无需同步数据、有可扩展的基础设施可以使用 JSON RPC API。

很多之前无法参与以太坊网络的设备，例如笔记本电脑 (无法24小时、一周7天保持在线，离线后再上线需要很长时间同步数据)、手机 (存储小)、树莓派 (基本上什么条件都不具备)，但门户网络使得这些设备可以加入以太坊网络，且还是专为这些低资源设备设计的。

实际上，现在以太坊有很多项目其实都有中心化风险，虽然隐藏起来了，但实际上这些项目必须在背后运行中心化的基础设施，以与以太坊网络通信。而门户网络实际上给了它们移除中心化风险的选项，因为它们现在可以本地嵌入门户客户端，实现与以太坊网络通信。

因此，受惠于门户网络，应用可以移除与以太坊网络通信中心化的风险；用户可以无需额外努力就能贡献以太坊网络；网络因为有更多应用、移动端、或台式电脑加入而变得容量更大、更强健、更去中心化，也因此更安全。

Piper 总结

搭建门户网络的工作虽然才刚起步，但它正如火如荼地进行着。我们现在有三支独立的客户端实现团队——我的团队、Status (正在构建 Fluffy，并计划把它嵌入 Status 钱包)、以太坊 js 团队(开始构建自己的门户客户端了)。虽然我们才刚开始，但我们已经用了很多时间去搞清楚我们要实现什么，我们要如何实现这些问题，接下来要做的就是实现。这是多个团队一起努力的事业，我们现在构建的东西超出了现在以太坊网络的范围。大家可以期待在未来的 6 到 12 个月内看到成果。

ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系[email protected]进行授权。