一旦我们将留意力转向网络技能，尤其是 DevP2P ETH 协议，我们会发明尚有其他因素提高了客户端的巨大性。要想插手这个网络，客户端需要具备以下本领：
或者最明明的例子是，磁盘 I/O 向来都是客户端的一个瓶颈。这个瓶颈之所以存在，是因为客户端倾向于利用树布局（Trie）的朴素暗示来执行其状态数据库。状态数据库的构建方法由 GetNodeData 网络元件抉择。
事实证明，大部门坚苦都来自于组网协议（networking protocol），即以太坊客户端软件用于彼此毗连并分享区块链信息的那一组东西。以太坊的组网法则（界说在 devp2p 代码库中），最终影响甚至抉择了以太坊客户端的设计和要求。
有人大概会当即发起我们想步伐为落伍的客户端提供支持和辅佐。我很鉴戒这种 “人月神话” 式的办理方案 —— 在软件开拓进程中，让更多工程师来办理一个困难很少会乐成，并且我不指望这种方案会取得乐成。
因此，第一问的谜底是：
第一问：为什么 Geth 开拓团队的压力如此之大，甚至到了超负荷的境地？
一些组网东西指定了未经优化的架构，甚至要求以太坊客户端运行不须要的成果。客户端开拓者需要在这些限制下事情。
办理方案
第三问：为什么构建以太坊客户端会这么难？
从基础上来说，对付很多客户端操纵而言，处理惩罚这些请求所需的基本数据不是必须的，可是此刻却强制它们支持这些成果。这就需要所有客户端在除了满意本身自己的需求之外，还要别的构建大量成果。譬喻，主要作为生意业务发送网关的客户端并不需要汗青链上数据，大概只需要一个很小的状态子集。可是，就当前的以太坊版本而言，客户端依然需要生存完整的副本。
第四问：为什么网络互联协议提高了客户端实现的难度？
今朝，这样一个复杂的 DevP2P ETH 协议尚未完全解构。我们对付如何将这个网络拆分成三个独立的专用网络有了基本相识，可是今朝还没有人直接着手这块。
事不宜迟，先来看看第一问是什么。
注：人月神话，mythical man-month，指出以大量人员和较短的时间，并不能缩短软件的开拓进度。一窝蜂的功课方法无助于软件出产，且会制造贫苦，发生出更差的软件。向进度落伍的项目追加人力，只会使进度越发落伍。
以太坊主网上线时，我们有多个客户端。个中最主要的两个是 Geth 和 CPPEthereum 。之后又呈现了 Parity ，CPPEthereum 被裁减。
我相信，这个问题的谜底根基上可以分为两个部门。
Geth: 75%
这就要求 Geth 客户端和开拓团队绝对不能出错。
剩下 4% 由一些市场份额不到 1% 的客户端构成，因此忽略不计。
从我小我私家的履历角度来看，构建以太坊客户端难比登天。Geth 之所以能在以太坊网络上不变运行，是因为它引入了许多巨大的优化。Geth 团队耗费了数年时间才到达了如此高的巨大度，今朝仍在继承优化中。
第五问：为什么……
处理惩罚会见链上数据汗青记录的请求，包罗区块头、区块体和收据。
最近进行的第 90 期焦点开拓者集会会议险些全程都在接头一个问题。我强烈发起各人亲自听一下这场集会会议。
GetNodeData是我们用来同步状态的独一网络互联东西，针对特定的状态数据库名目（俗称 “the native layout”）举办了优化。由 Turbo Geth 推广的 “扁平式” 数据库机关在状态维护方面具有极大的机能优势，可是利用这种机关会加大 GetNodeData 请求的处理惩罚难度。
处理惩罚会见最近区块所生成的状态的 GetNodeData 请求；
重要的是，有高出 51% 的算力都会合在 Geth 客户端上。假设在即将到来的柏林硬分叉中，Geth 在实现个中一个 EIP（以太坊改造提案）时呈现了 bug 。纵然这个客户端的其它实现都没出 bug ，只要有区块碰上了这个 bug ，就会导致以太坊网络分叉。按理来说，这个区块是无效的，其他客户端也会将其视为无效块。可是，有高出 51% 的挖矿节点都运行的 Geth 客户端，因此整个网络城市被带到错误的分叉链上去。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
