观点：区块链客户端的未来将百花齐放

当前作者任职于 Parity Technologies，从事建立区块链客户端的工作。区块链在很多方面都很吸引人，从软件工程的角度来看更是如此。从事区块链客户端的工作就意味着需要与软件堆栈的所有级别 (不管高低) 进行交互。

在最低级别上，你需要进行组装优化、编写编译器和虚拟机 (VM)。你通过网络和数据库进行工作。最后，在最高层次上，你将处理诸如开源组织以及如何在一个大型复杂的应用程序中组织代码之类的问题。

本文将主要涉及到更高的层次上，即我们如何管理应用程序的复杂性?

作者想补充一点关于区块链客户端的入门知识，以及它们如何随着时间的推移在生态系统中进行交互。区块链 (通常) 从协议开始，由某个协议规范加以规定。

比特币从一篇白皮书开始，紧接着是 C++ 实现。这种 C++ 实现已经成为协议的规范，且真正的多客户端生态系统从未得到过推广。

但是，在诸如以太坊 (Ethereum) 这样的区块链中，从其诞生伊始就存在了多个客户端。关于协议应该是什么而不是由任何一个实现来定义的黄皮书和其他规范，存在着某种社区共识。但这并没有将哪种类型的客户端可以或应该存在考虑在内。

本文将主要研究以太坊，所以作者将主要从这个角度来展开。在区块链生命的早期，存在一种可以做任何事情的客户端，所有区块链都是运行在这种客户端之上，这是无可厚非的。

那时，区块链和状态都足够小，同步不成问题，而且几乎不使用任何资源。每个人都运行一个全节点 (full node)，因此不需要轻客户端 (light clients)，而且在这条链上也没有一个大型的服务行业与客户端有着不同的需求。

但是，随着这个链条的增长，其生态系统也在增长，因此拥有一个可以做所有事情的软件已经没有任何意义了。我们早期在对以太坊的研究了解到，节点不应该负责管理私钥。如果用户拥有一个联网的软件，该软件同时还管理用户私钥，这将是一场灾难 (很多相关的灾难已经发生了)。

随着我们的进一步发展，作者相信我们将看到大量的专业客户端的出现。以太坊客户端主要负责以下工作：

• 作为轻客户端 (不存储完整的状态信息)，允许用户与网络进行交互；
• 作为全节点，存储完整的状态信息和所有的历史记录；
• 作为档案节点，能够创建自定义索引和数据集来检查过去的状态；
• 通过 JSON-RPC 处理来自节点的数据请求
• 为挖矿软件提供数据；
• 广播区块和交易；

这里的问题是，在一个成熟的生态系统中，几乎没有任何一个用户想要做所有上面这些事情。

这将如何影响软件的复杂性?

搭建一个完成所有这些任务的区块链客户端是一项巨大的任务，需要几年的技术工作。Parity 的以太坊代码库预计总共包含了约有 500kloc 行 Rust 代码。(备注：kloc 即 kilo lines of code, 千行代码)

但是代码行数并不是复杂性的最佳标志。作为一个开源项目，我们看到了不管是 Parity 公司内部还是外部的人员你都试图加入这个项目。根据经验，大约需要3个月的时间才能使代码库变得富有成效，然后你肯定依旧没有完全掌握它。我想说的是，全世界共计最多只有10个人了解以太坊客户端的方方面面。比特币的情况可以说更糟，因为它只有一种实现方式。我们曾建立一个比特币客户端，C++ 实现中存在的奇怪的边角案例 (corner cases) 和 bug 的数量令人吃惊。由于没有多个 (活跃的) 实现，这些漏洞从未被发现，因此成为了现在比特币的一部分。

对此我们能做些什么呢?

作者相信，在未来，区块链将变得司空见惯，生态系统将变得更加成熟，没有一个客户端可以完成所有这些事情。很有可能矿工将运行一种类型的客户端，诸如区块浏览器 (block explorers) 这样的归档服务将运行另一种客户端，而终端用户将运行轻客户端 (可能在移动应用程序中)。对于那些想通过向轻客户端提供数据或存储历史区块数据的方式来获利的人，区块链网络上将引入更多的角色。

关于为什么会发生这种情况，存在两个主要的论据。首先，这是处理复杂和大规模核心开发的唯一方法，如果我们想要有一个功能良好和成熟的生态系统，这是必要的。

第二个是经济问题。无论是以太坊还是比特币，目前核心开发者都不可能赚钱。这是一个典型的“公地悲剧 (tragedy of the commons)”的情况，即每个人都在使用这个软件，但没有人觉得对它负有责任，或特别想为它花钱。

作者认为，我们不可能摆脱这个公地悲剧的问题，除非我们实现客户端的专业化，并开始在软件的使用中引入经济模型。因为所有的都是开源软件，你总是可以删除任何硬编码的经济模型，但作者认为这并不是一个问题。

从作者今天在许多生态系统中观察到的情况来看，核心的开发工作往往是通过团队提供顾问服务或者从慷慨的捐助者获取的资金来加以支撑的。但这是不可持续的。对于大多数核心开发团队来说，从事顾问工作是让人分心的，这并不是他们想从事的工作。这就是专业的区块链客户端可以发挥作用的地方。

区块链客户端的类型 & 如何通过客户端来获利

当前，矿工并不认为他们应该为使用某个区块链客户端而付费，因为客户端是开放源代码的，对每个人都有好处。但如果存在一个专门为矿工服务的区块链客户端，那会怎样呢？这个客户端可能有一个小标志，即它允许你设置一个贡献率，并且默认值可以设为诸如每挖一个区块则需要支付1美元。

如果 Parity 公司通过 Parity 客户端从以太坊主网获得$1/区块的收益，那么该公司从中获得的收益将超过其获得的任何商业项目和赠款的总和。更重要的是，它将给 Parity 一个可持续的和可预测的收入来源，只要 Parity 客户端被矿工使用且有价值。但其中的问题是，对于矿工来说，某个客户端将可能要远优于其他试图为所有人提供最优服务的客户端，如此一来，多客户生态系统所带来的好处将荡然无存。

如果你关注挖矿用例，你可以对节点的操作方式进行基本的更改。你可以使用完全不同的方式来管理 merkle-trie。不需要通过 trie 访问数据的方式来实现同步或为轻客户端提供服务，只需要生成一个 merker-root 即可。你可以对资源使用进行完全不同的假设，比如要求矿工必须有 32GB 的内存，而轻客户端用户则无需如此。

你将根本不需要管理 RPC，并且可以为此消除整个复杂性。矿工们将需要去工作并报告挖出的区块，这是两个端点。你可以通过在客户端中囊括矿池软件、部署分层服务器所需的工具等等来提升竞争力。这些都与普通用户无关，也不属于“适用所有人”的区块链客户端范畴。

为了解决所有矿工都使用相同的挖矿软件的问题，你可以根据挖矿软件的分布情况来衡量奖励，鼓励更多的参与者，或者任何人都没有奖励。你还可以在这里玩其他聪明的经济游戏，但是它们都需要非常复杂的协议层更改，这可能会导致其他副作用。作者还不清楚如何解决这个问题，除非希望市场上的经济竞争对它不利。

轻客户端需要一种与网络进行交互的方式来请求数据，它需要验证默克尔证明 (Merkle proofs) 和 PoW 哈希，之后它需要一组 RPC 方法才能够向使用该轻客户端的应用程序传递这些信息，不管该应用程序是 Dapp 或是钱包应用。

从概念上讲，这比其他任何事情都要简单得多。在实践中，轻客户端与全节点在 RPC 方面有很多重叠的地方，我们稍后将讨论这个问题。

轻客户端的问题在于，它们目前依赖于利他行为 (altruistic behavior)。没有人有任何理由去服务轻客户端。它不能增强网络 (这就是为什么你想要广播区块和交易)，所以你没有理由去这么做。在理想的情况下，轻客户端的用户将使用一个轻客户端服务器来开启一个支付通道，并为他们发出的每个请求发送一个微支付。

此外，你还可以让轻客户端打开一个通向软件制造商的通道，并将该微支付的千分之一发送给软件制造商 (或者任何其他适当的费率，也可能由用户选择)。假设某个轻客户端拥有一个由数百万移动轻客户端用户组成的庞大且健康的生态系统，这可能会带来相当可观的收入。

在编写和维护的复杂度方面，全节点一直是复杂度最高的软件，因为全节点需要进行的工作量最多。但仍然有一些事情是它们不需要做的：它们不需要成为轻客户端，也不需要处理挖矿和区块的生成。

它们需要能够在网络上发送、接收和验证数据。它们还需要能够为轻客户端提供服务。它们可以从为轻客户端提供服务而获得报酬。与轻客户端类似，软件制造商也可以从获得的利润中抽取一部分 (通常是可选择性的)。

我们可以想象通过取消 RPC 接口来消除大量的复杂性。除了通过一个轻客户端之外，基本上没有其他方法可以与节点进行交互。这可能会对性能产生负面影响 (尤其是对于没有针对轻客户端进行优化的 DApp)。高级用户可能希望能够直接与全节点交互，从而获得最佳性能。但是，在轻客户端和全节点之间添加一个“本地”接口 (例如 IPC 或类似的接口) 会更简单，所以如果你是高级用户，你可以同时运行这两个接口，且轻客户端仍然完全负责 RPC 接口的复杂性。

对于简化接口，并围绕生成 GraphQL 之类的提出更好的结构，这方面也有一些值得注意的地方，生成 GraphQL 既可以在“客户端”( 用户和节点之间) 也可以在“服务器端 ”(节点之间) 进行。

档案节点 (archive node) 是一个有趣的例子，因为它在区块链网络上没有任何用途，并且经常与全节点合并。档案节点处理了很多额外的复杂性，因为它伴随着更高的资源使用。

比特币没有类似于档案节点的节点，但区块浏览器仍需要建立自己的档案节点。作者过去曾建议从主客户端中删除档案节点，让使用它的用户构建自己的版本。当前，这显然不会受那些依赖于档案节点软件的人的欢迎。

档案节点是一个能够快速获取历史数据、构建额外的索引和存储中间状态的全节点。对于构建上文描述的全节点的人来说，这里有一个添加“钩子”的机会，这样就可以“将所有处理过的交易发送到 Elasticsearch 搜索引后端”。归档服务变得越来越复杂，现在出现了一些根本不使用内置归档模式的服务。它们使用全节点的 RPC 来提取数据并将其塞入 Kafka 或类似的东西中进行处理。

我们可以想象一个单独与网络交互来获取数据的软件。然后，它将为外部索引器和数据源提供灵活性，使它们能够获取数据并进行处理。

无论哪种情况，这都是很难收费的，因为期间并没有发生链上交易或链下支付。作者相信，一个好的档案软件将会成为一个封闭源码专用软件的绝佳案例，因为它本质上只是一个分析工具。

这类软件有很多的消费者。Block explorers 是区块链世界的 Infura，它向终端用户提供数据，而不需要经过网络、或者是研究区块链交易模式或行为的分析者或者研究者。它们都有不同的需求，但最好是通过构建连接到现有数据库和工具的软件来满足这些需求，从而完成除了它们之外任何人都不需要做的事情。

这个角色还不存在，但作者认为这就是为什么许多人将档案节点与其他节点混淆的原因。在以太坊中，一个全节点存储所有历史数据，但它不需要这样做。

实际上，全节点不需要存储超过最后100个区块的数据就可以达到敲定区块的目的。移除其他的数据可以使全节点的存储需求节省 100 GB 的容量。当前还没有出现移除这些数据同时确保历史数据的可用性的方法。当已经出现一些相关的讨论，即将这些数据放在 IPFS (星际文件系统) 中，并将几个对此感兴趣的人的数据固定在 IPFS 上。

当然，这与一个需要利他行为者的轻客户端的处境是一样的。理想的情况是，我们能想出一种激励机制来存储这些历史数据，这样至少有一些经济上的保证可以使用这些数据。人们可以想象使用某个互操作性网络将这些数据存储在众多区块链中的一个之上，该区块链专门为长时间存储大量数据而定制。

然后我们就可以解决这个问题，并消除所有全节点存储所有历史数据记录的必要性。问题是谁将为此买单，因为确保数据可用性并不是单个实体的责任。它将必须通过通胀来进行支付，这需要一项艰难且可能引发争议的共识改变。

未来之路

作者个人认为，区块链的未来就是权益证明 (PoS)。这并不是说工作量证明 (PoW) 会消失，PoW 是一个了不起的发明，比特币将永远使用它。新的区块链将使用 PoS 机制，并可能使用 PoW 来实现特殊的抗女巫攻击，或者在诸如 VDF (可验证延迟函数) 或 VRF (可验证随机函数) (作者倾向于将其归类为 PoW 的一个子集) 等中使用 PoW。

我们已经在区块链世界中看到了一些 PoS 的尝试，但它们通常都非常简单。在更复杂的 PoS 设计中，我们已经看到了将协议分为许多新角色的趋势。

在 PoS 机制中会存在验证者 (validator) 取代矿工 (miner)，但有时也存在继任者 (nominator) 或者代理人 (delegator)。在诸如比特币等区块链中，我们看到在第二层出现了许多新的角色，比如闪电网络的瞭望塔 (watch tower) 等等。作者相信，上面的布局同样适用于 PoS 世界。

验证者与全节点具有完全不同的兴趣和需求。全节点的功能与轻客户端也非常不同。

当第一次搭建软件时，将所有东西构建为一个整体要容易得多，并且少数理解整个设计的人可以在一个地方完成所有的事情，并确保从第一天开始所有事情都是一致的和有效的。如果你从第一天就开始尝试以分散的方式构建这种去架构，我几乎完全肯定你会搬起石头砸自己的脚。

我们进入以太坊已经5年了，我们现在才开始清楚地看到这些用户和他们的需求。没人能在第一天就预测到，几乎整个以太坊的用户群都会通过一个中心化的服务与网络进行交互。再过5年或10年，作者认为我们将见证这些针对所有下一代区块链的专业化客户端的崛起。

问题是我们是否将会看到这些客户端是否会像当前一样针对比特币和以太坊。作者对此持怀疑态度，因为这涉及到大量的工作，但其中的有利可图将可能会鼓励更多的人参与进来。

点击链接入群：One生态钉钉学习群