非技术专家对任何分布式系统最喜欢的问题是“您的区块链中有多少tps？”。但是，答复中给出的电话号码通常与提问者想听到的电话号码没有多少共同之处。实际上，他想问“您的区块链是否适合我的业务需求”，这些需求不是一个数字，而是许多条件-这是网络的容错性，最终性要求，规模，交易性质和许多其他参数。因此，“多少tps”这个问题的答案不太可能是简单的，而且几乎永远不会是完整的。具有数十个和数百个节点的分布式系统执行相当复杂的计算，可能处于与网络状态，区块链内容，技术故障，经济问题，网络攻击和许多其他原因相关的大量不同状态。可能出现性能问题的阶段与传统服务不同，而区块链网络服务器是一种结合了数据库，Web服务器和torrent客户端功能的网络服务，这使得所有子系统的负载配置文件极为困难：处理器，内存，网络，存储

碰巧的是，去中心化的网络和区块链对于集中式软件的开发者来说是非常特殊且不寻常的软件。因此，我想重点介绍分散网络的性能和可持续性的重要方面，以及衡量分散网络和发现瓶颈的方法。我们将考虑各种性能问题，这些问题会限制为区块链用户提供服务的速度，并注意此类软件的特定功能。

区块链客户服务请求阶段

为了诚实地谈论任何或多或少复杂服务的质量，您不仅需要考虑平均值，而且还要考虑最大值/最小值，中位数和百分位数。从理论上讲，我们可以在某个区块链中谈论1000 tps，但是如果以极高的速度执行900笔交易，并且“挂断”几秒钟的100笔交易，那么对于所有交易的客户而言，收集的平均时间并不是一个诚实的指标在几秒钟内无法完成交易。由于缺少共识轮或网络分离而导致的临时“坑”可能会严重破坏在测试台上表现出出色性能的服务。

要确定这种瓶颈，有必要很好地理解真正的区块链可能难以为用户提供服务的阶段。让我们描述交易的交付和处理周期，以及获得新的区块链状态，客户可以从中验证其交易已得到处理并考虑在内。

在客户上形成交易
交易在客户端上签名
客户端选择节点之一并将其事务发送给它
客户端订阅节点状态数据库的更新，等待其事务执行结果的出现
节点通过p2p网络传播事务
几个或一个BP（块生产者）将处理累积的事务，更新状态数据库
BP构成一个新块，处理所需数量的交易
BP通过p2p网络分发新区块
新块将传递到客户端访问的节点
节点更新状态数据库
节点看到与客户端有关的更新，并向其发送交易通知

现在，让我们仔细看看这些步骤，并描述每个步骤中潜在的性能问题。与集中式系统不同，我们还考虑在网络客户端上执行代码。通常，在测量tps时，事务处理时间是从节点收集的，而不是从客户端收集的-这并不完全诚实。客户不在乎节点处理交易的速度如何，对他而言最重要的是区块链中包含的有关此交易的可靠信息可供使用的那一刻。基本上就是完成一次交易所花费的时间。这意味着即使发送相同的事务，不同的客户端也可以接收完全不同的时间，这取决于通道，节点的负载和接近程度等。因此，绝对有必要在客户端上测量此时间，因为需要优化此参数。

客户端交易准备

让我们从前两点开始：交易由客户形成并签名。奇怪的是，从客户的角度来看，这也可能是区块链性能的瓶颈。对于集中式服务而言，这是不寻常的，集中式服务自己承担所有的计算和数据操作，并且客户端仅准备一个短请求即可请求大量数据或计算，从而获得最终结果。在区块链中，客户端代码变得越来越强大，而区块链核心也越来越轻巧，并且习惯上将大量计算任务交给客户端软件。区块链中有一些客户可以在相当长的时间内准备单个交易（我在谈论客户端的各种Merkle证明，简洁证明，阈值签名和其他复杂操作）。容易进行链上验证和在客户上进行交易的困难准备的一个很好的例子是证明它属于基于Merkle-tree的列表，这是一篇文章。

此外，请不要忘记，客户端代码不仅将事务发送到区块链，而且还会首先询问区块链的状态-此活动可能会影响网络负载和区块链节点。因此，进行测量时，以尽可能最完整的方式模拟客户端代码的行为将是合理的。即使您的区块链上有固定的轻型客户，他们在最简单的交易中添加了简单的数字签名以转移某些资产，每年客户上的计算量仍然很大，加密算法变得更强大，这部分处理可能会成为一个严重的瓶颈，未来。因此，在持续3.5 s的事务中，花费2.5 s来准备和签名事务，并花费1.0 s-发送到网络并等待响应时，请不要错过这种情况。为了评估此瓶颈的风险，您需要从客户端计算机收集指标，而不仅仅是从区块链节点收集指标。

发送交易并监控其状态

下一步是将交易发送到选定的区块链节点，并在交易池中接收其采用状态。该阶段类似于普通的数据库访问，节点应将事务写入池中并开始通过p2p网络分配有关该池的信息。此处评估性能的方法类似于评估传统Web API微服务的性能，并且可以更新区块链本身中的事务并主动更改其状态。通常，某些区块链中的交易信息更新可能会发生多次，例如，当在链的分支之间切换时或当BP告知其打算将交易包含在区块中时。该池的数量及其中的事务数量的限制会影响区块链的性能。如果事务池被阻塞到最大可能的大小，或者不适合RAM，网络性能可能会急剧下降。区块链没有针对垃圾消息流的集中保护，如果区块链支持大量交易和低廉的费用，这可能导致交易池溢出-这是另一个潜在的性能瓶颈。

在区块链中，客户将交易发送到他喜欢的任何区块链节点，客户通常在发送之前就知道交易的哈希值，因此他所要做的就是获得连接，并在转移后等到区块链改变其状态并开启交易。注意，通过测量“ tps”，对于连接到区块链节点的不同方式，您可以获得完全不同的结果。这可以是常规的HTTP RPC或WebSocket，允许您实现“订阅”模式。在第二种情况下，客户端将更早收到通知，并且节点将在有关事务状态的响应上花费较少的资源（主要是内存和流量）。因此，在测量“ tps”时，您需要考虑客户端连接到节点的方式。因此，要评估此瓶颈的风险，区块链的基准必须能够模拟WebSocket和HTTP RPC请求的客户端（对应于真实网络的分数），并更改交易的性质和规模。

为了评估此瓶颈的风险，您还需要从客户端计算机收集指标，而不仅仅是从区块链节点收集指标。

通过P2P网络传输交易和区块

在区块链中，点对点（p2p）网络用于在交易参与者和区块之间转移。事务从节点之一开始在网络上分发，直到它们到达生产者的对等块，生产者将事务打包为块并使用相同的p2p在网络的所有节点上分发新块。大多数现代p2p网络的基础是对Kademlia协议的各种修改。这是此协议的简要概述，并且是有关BitTorrent网络的各种测量方法的文章，根据该文章，您可以了解到，与硬配置的集中式服务网络相比，这种类型的网络更加复杂且难以预测。另外，这是一篇有关测量以太坊节点的各种有趣指标的文章。

简而言之，此类网络中的每个对等方维护自己的其他对等方的动态列表，这些动态对等方请求由内容寻址的信息块。接收到请求后，对等端会提供必要的信息或将请求发送到列表中的下一个伪随机对等端，并且在接收到响应后将其传递给请求者并缓存一会儿，从而在下一次更早地提供此信息块。因此，流行信息出现在大量对等方的大量缓存中，并且逐渐流行了不受欢迎的信息。对等方跟踪谁向谁发送了多少信息，并且网络试图通过提高对它们的评级并为其提供更高水平的服务来刺激活跃的分发者，从而自动将不活跃的参与者从对等者列表中删除。

因此，现在需要在整个网络中分配事务，以便块生产者可以看到它并将其包含在块中。 Noda主动向所有人“分发”新交易，并监听网络，等待该区块，索引中将出现必要的交易，以通知正在等待的客户端。网络之间相互发送有关p2p网络中新事务和块的信息的时间取决于很多因素：附近工作的诚实节点的数量（从网络角度来看），这些节点的缓存的“预热”，块的大小，事务，更改的性质，网络地理位置，节点数和许多其他因素。在这样的网络中对性能指标进行全面的测量是一件复杂的事情，有必要同时评估客户端和对等方（区块链节点）上请求的处理时间。任何p2p机制中的问题，不正确的数据导出和缓存，对等体列表的管理效率低下以及许多其他因素都可能导致延迟，从而影响整个网络的整体效率，而这个瓶颈是最难分析，测试和解决的瓶颈。结果的解释。

区块链处理和更新状态数据库

区块链工作中最重要的部分是共识算法，它适用于从网络接收到的新块以及将结果记录在状态数据库中的事务处理。向链中添加新块以及随后选择主链应该尽快进行。但是，在现实生活中，“应该”并不意味着“工作”，例如，您可以想象这样一种情况：两个相互竞争的长链不断在彼此之间切换，在每次切换时更改池中数千个事务的元数据，并不断回滚状态数据库状态。就确定瓶颈而言，此步骤比网络p2p层更简单，因为交易执行和共识算法得到严格确定，在这里进行任何测量都更加容易。
最主要的是不要将此阶段性能的随机降低与网络问题混淆-节点更慢地提供有关主链的块和信息，对于外部客户端来说，它看起来像是一个缓慢的网络，尽管问题出在完全不同的地方。

为了在此阶段优化性能，从节点本身收集和监视指标非常有用，其中包括与状态数据库更新有关的指标：节点上处理的块数，它们的大小，事务数，链叉之间的切换数，无效块数，虚拟机运行时，数据提交时间等。这不会使网络问题与链处理算法中的错误混淆。

运行事务的虚拟机可以是有用的信息源，可以优化区块链的运行。内存分配的数量，读/写指令的数量以及其他与执行合同代码的效率有关的度量标准可以为开发人员提供许多有用的信息。同时，智能合约是程序，这意味着从理论上讲它们可以消耗任何资源：cpu /内存/网络/存储，因此事务处理是一个相当不确定的步骤，此外，当在版本之间以及何时切换版本时，其变化都很大。更改合同代码。因此，还需要有关交易处理的指标来有效地优化区块链性能。

客户收到交易包含在区块链中的通知

与其他阶段相比，这是客户端接收区块链服务的最后阶段，没有太大的开销，但是仍然值得考虑客户端从节点接收批量响应的可能性（例如，返回数据数组的智能合约）。无论如何，对于问“您的区块链中有多少tps？”这一问题的人，这一刻是最重要的，因为目前，接收服务的时间是固定的。

在这个地方，总是有客户必须等待区块链响应的全部时间发送，这是用户将等待其应用程序中的确认的时间，而优化是开发人员的主要任务。

结论

结果，可以描述在区块链上执行的操作的类型并将它们分为几类：

密码转换，证据建立
对等网络，事务和块复制
交易处理，智能合约的执行
将区块链中的更改应用于状态数据库，更新交易和区块数据
对状态数据库的只读请求，区块链节点API，订阅服务

通常，现代区块链节点的技术要求非常严格-它们是用于加密的快速CPU，用于存储和快速访问状态数据库的大量RAM，使用大量同时打开的连接的网络交互以及庞大的存储量。如此高的要求和各种类型的操作的丰富性不可避免地导致以下事实：节点的资源可能不足，因此上面讨论的任何步骤都可能成为整个网络性能的下一个瓶颈。

在开发和评估区块链的性能时，您必须考虑所有这些要点。为此，您需要同时从客户端和网络节点收集和分析指标，寻找它们之间的关联性，评估向客户提供服务的时间，并考虑所有主要资源：CPU /内存/网络/存储，了解它们的使用方式以及相互影响。所有这些使以“多少个TPS”的形式比较各种区块链的速度成为一项极其不费力的任务，因为存在大量不同的配置和条件。在大型的集中式系统中（由数百个服务器组成的集群），这些问题也很复杂，并且还需要收集大量不同的指标，但是在区块链中，由于p2p网络，运行合同的虚拟机，内部经济，自由度要大得多，因此需要进行测试即使在多台服务器上，它也不会显示并且仅显示非常近似的值，而这些值几乎与实际情况无关。

因此，当在内核中开发区块链时，为了评估性能并回答“与上次相比是否有所改善”的问题，我们使用了相当复杂的软件，通过数十个节点协调区块链的启动，并自动启动基准测试和收集指标，没有这些信息，调试起来非常困难。适用于许多参与者的协议。

因此，在收到“您的区块链中有多少TPS？”问题后，请您与正在聊天的人聊天，以了解他是否准备好了解十二张图表，并聆听所有三个方框的区块链性能问题以及您提出的解决问题的建议...

您的区块链中有多少TPS？