假如我们但愿以太坊网络可以或许取得久远的乐成，我认为整个社区都要就办理这些问题展开相助，给以其基础原因足够的存眷和接头。最重要的是，我们要联袂打造出有效的技能办理方案。
事不宜迟，先来看看第一问是什么。
从当时起，除了 Parity 之外，没有一个客户端能得到较大的市场份额。去年，Nethermind 异军突起，，成为了一颗冉冉上升的新星，可是今朝只占据了 1% 的市场份额。最近，由于 Parity 遭遇了一些妨害，前途一片黯淡，Parity 的市场份额大幅下降。我们认为，在抱负环境下，以太坊网络需要有 3 个及以上的客户端、每个客户端占有的客户端份额都不至于太高、没有任何一个客户端能占据远远高出 51% 市场份额。固然在抱负环境下应该实现客户端多元化，可是我们已经习惯了客户端霸权的排场。
第一问：为什么 Geth 开拓团队的压力如此之大，甚至到了超负荷的境地？因为以太坊网络的客户端缺乏足够的多样性。
Geth: 75%
因此，第一问的谜底是：
第二问：为什么以太坊网络缺乏客户端多样性？
为了办理这个问题，我们需要对以太坊共鸣层以及网络层的各个部门举办查验。今朝，查验事情已经启动。大量事情已经在 Alexey 和我配合率领了 8 个月的「无状态以太坊」名义下开展。我们所做的一些事情至少减轻了 Geth 团队的承担，因为他们用上本身开拓了经年之久的 SNAP 同步协议。尚有一部门事情需要深入领略这个问题并想到可行方案的才俊来包袱。
就状态打点而言，以太坊客户端必需可以或许同步网络上的完整状态，并维护该状态的当地副本。这两点都很难做到。对客户端以及读取并处理惩罚状态要求的处事器来说，同步状态需要提出数百万个请求，而且会导致磁盘 I/O 饱和。新同步的状态需要颠末维护和删减，以便数据库能足够快地执行新区块。从工程上来说，这是一项严峻挑战！
从我小我私家的履历角度来看，构建以太坊客户端难比登天。Geth 之所以能在以太坊网络上不变运行，是因为它引入了许多巨大的优化。Geth 团队耗费了数年时间才到达了如此高的巨大度，今朝仍在继承优化中。
以太坊主网上线时，我们有多个客户端。个中最主要的两个是 Geth 和 CPPEthereum。之后又呈现了 Parity，CPPEthereum 被裁减。这就要求 Geth 客户端和开拓团队绝对不能出错。
从基础上来说，对付很多客户端操纵而言，处理惩罚这些请求所需的基本数据不是必须的，可是此刻却强制它们支持这些成果。这就需要所有客户端在除了满意本身自己的需求之外，还要别的构建大量成果。譬喻，主要作为生意业务发送网关的客户端并不需要汗青链上数据，大概只需要一个很小的状态子集。可是，就当前的以太坊版本而言，客户端依然需要生存完整的副本。
最近进行的第 90 期焦点开拓者集会会议险些全程都在接头一个问题。我强烈发起各人亲自听一下这场集会会议。
第四问：为什么网络互联协议提高了客户端实现的难度？
剩下 4% 由一些市场份额不到 1% 的客户端构成，因此忽略不计。
别的，尚有像 re-genesis 之类的想法，提供了完全回避这些问题的机制。这是一种激进的要领，假如能乐成的话，或将为我们带来很大的优势。
已往一整年，我都在存眷这个问题。令我震惊的是，以太坊上很多问题的来源其实都可以追溯到网络层。有人大概会当即发起我们想步伐为落伍的客户端提供支持和辅佐。我很鉴戒这种「人月神话」式的办理方案——在软件开拓进程中，让更多工程师来办理一个困难很少会乐成，并且我不指望这种方案会取得乐成。
今朝，这样一个复杂的 DevP2P ETH 协议尚未完全解构。我们对付如何将这个网络拆分成三个独立的专用网络有了基本相识，可是今朝还没有人直接着手这块。
那么，我们为什么需要多个客户端？
一旦我们将留意力转向网络技能，尤其是 DevP2P ETH 协议，我们会发明尚有其他因素提高了客户端的巨大性。要想插手这个网络，客户端需要具备以下本领：
相反，我认为应该将存眷点放在巨大性上。
办理方案
或者最明明的例子是，磁盘 I/O 向来都是客户端的一个瓶颈。这个瓶颈之所以存在，是因为客户端倾向于利用树布局（Trie）的朴素暗示来执行其状态数据库。状态数据库的构建方法由 GetNodeData 网络元件抉择。
首先，我们应该清楚的是，以太坊网络尚有很多难题的任务需要完成，只有少数人可以或许胜任这些任务。固然天天都有越来越多的开拓者参加进来，可是他们需要投入时间和精神来进修必备技术。客户端开拓者在专注于办理日常用户看不到的底层问题时，还要抽出时间来开拓新的 EVM 成果。
Nethermind: 1%原文来历：以太坊喜好者
Parity & OpenEthereum: 20%
一些组网东西指定了未经优化的架构，甚至要求以太坊客户端运行不须要的成果。客户端开拓者需要在这些限制下事情。
此刻，我们正越来越靠近问题的来源。在这场集会会议上，Alexey 提出了客户端开拓者负荷过重的问题。固然我认为这场接头是一个重要的开始，可是我们太急于寻求办理方案了，充实领略这个问题才是当务之急。重要的是，我们需要花点时间来阐明问题。在问题内在的阐明上，「五问法（Five Whys）」是最简朴有效的要领之一。
值得一提的是，客户端多样化不会溘然将客户端开拓酿成一项轻松的事情。但客户端多样性自己依然是一个值得摸索的规模，有助于我们找到提高客户端开拓的效益，同时减轻开拓团队承担的要领。不行否定的一点是，只在 Geth 团队上下工夫不太大概办理这个问题。
– 处理惩罚会见链上数据汗青记录的请求，包罗区块头、区块体和收据。
注：人月神话，mythical man-month，指出以大量人员和较短的时间，并不能缩短软件的开拓进度。一窝蜂的功课方法无助于软件出产，且会制造贫苦，发生出更差的软件。向进度落伍的项目追加人力，只会使进度越发落伍。
通过 etherscan，我们可以看到各个客户端的装机量所占份额的统计数据如下所示：
重要的是，有高出 51% 的算力都会合在 Geth 客户端上。假设在即将到来的柏林硬分叉中，Geth 在实现个中一个 EIP（以太坊改造提案）时呈现了 bug。纵然这个客户端的其它实现都没出 bug，只要有区块碰上了这个 bug，就会导致以太坊网络分叉。按理来说，这个区块是无效的，其他客户端也会将其视为无效块。可是，有高出 51% 的挖矿节点都运行的 Geth 客户端，因此整个网络城市被带到错误的分叉链上去。
看来我只问了四个「为什么」就找到了基础原因。以太坊协议还没有完全成熟。在设计以太坊协议时，我们并没有意识到现如今发明的大大都问题，可能因为其时状态局限较小、成长汗青较短，这些问题还不成问题。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
