对于任何分布式系统，非技术人员最喜欢问的问题是“您的区块链上有多少 tps？” 然而，回答中给出的数字通常与提问者希望听到的数字没有什么共同之处。 事实上，他想问“你的区块链能满足我的业务需求吗”，而这些需求不是一个数字，而是很多条件——这里有网络容错性、最终性要求、规模、交易性质和许多其他参数。 因此，“多少 tps”这个问题的答案不太可能简单，而且几乎永远不会完整。 具有数十或数百个节点执行相当复杂计算的分布式系统可能处于与网络状态、区块链内容、技术故障、经济问题、网络攻击和许多其他原因相关的大量不同状态。 可能出现性能问题的阶段与传统服务不同，区块链网络服务器是一种结合了数据库、Web 服务器和 torrent 客户端功能的网络服务，这使得它在所有子系统的负载情况方面极其复杂：处理器、内存、网络、存储
碰巧，对于中心化软件开发人员来说，去中心化网络和区块链是非常具体且不寻常的软件。 因此，我想强调去中心化网络的性能和可持续性的重要方面，以及衡量它们和查找瓶颈的方法。 我们将研究限制向区块链用户提供服务的速度的各种性能问题，并注意此类软件的功能特征。
区块链客户端的服务请求的阶段
为了诚实地谈论任何或多或少复杂的服务的质量，您不仅需要考虑平均值，还需要考虑最大值/最小值、中位数、百分位数。 理论上，我们可以在某些区块链中谈论 1000 tps，但是如果 900 笔交易以极快的速度完成，并且 100 笔交易“卡住”了几秒钟，那么所有交易收集的平均时间对于客户端来说并不是一个完全公平的指标我无法在几秒钟内完成交易。 由于错过共识回合或网络分裂而导致的临时“漏洞”可能会极大地破坏在测试平台上表现出出色性能的服务。
为了识别此类瓶颈，有必要充分了解真正的区块链可能难以为用户服务的阶段。 让我们描述一下交付和处理交易以及获取区块链的新状态的周期，客户端可以从中验证他的交易是否已被处理和记账。
- 交易在客户端形成
- 交易在客户端签名
- 客户端选择其中一个节点并向其发送交易
- 客户端订阅节点状态数据库的更新，等待其事务结果出现
- 节点通过 p2p 网络分发交易
- 多个或一个 BP（区块生产者）处理累积的交易，更新状态数据库
- BP处理完所需数量的交易后形成一个新的区块
- BP 通过 p2p 网络分发新区块
- 新区块被传送到客户端正在访问的节点
- 节点更新状态数据库
- 节点看到有关客户端的更新并向他发送事务通知
现在让我们仔细看看这些阶段并描述每个阶段潜在的性能问题。 与集中式系统不同，我们还将考虑在网络客户端上执行代码。 通常，在测量 TPS 时，交易处理时间是从节点收集的，而不是从客户端收集的 - 这并不完全公平。 客户并不关心节点处理他的交易的速度有多快；对他来说最重要的是他可以获得区块链中包含的有关该交易的可靠信息的那一刻。 这个指标本质上是交易执行时间。 这意味着不同的客户端，即使发送相同的交易，也可能收到完全不同的时间，这取决于节点的通道、负载和邻近度等。 因此绝对有必要在客户端上测量这个时间，因为这是需要优化的参数。
在客户端准备交易
让我们从前两点开始：交易由客户端形成并签名。 奇怪的是，从客户端的角度来看，这也可能是区块链性能的瓶颈。 这对于中心化服务来说是不寻常的，中心化服务接管了所有与数据相关的计算和操作，客户端只需准备一个简短的请求，就可以请求大量的数据或计算，从而获得现成的结果。 在区块链中，客户端代码变得越来越强大，区块链核心变得越来越轻量级，海量计算任务通常转移到客户端软件。 在区块链中，有些客户端可以准备一笔交易相当长的时间（我指的是客户端的各种默克尔证明、简洁证明、阈值签名和其他复杂操作）。 简单的链上验证和客户端交易的大量准备的一个很好的例子是基于 Merkle-tree 的列表中的成员资格证明，这里 .
另外，不要忘记客户端代码并不是简单地将交易发送到区块链，而是首先查询区块链的状态 - 而此活动可能会影响网络和区块链节点的拥塞。 因此，在进行测量时，尽可能完整地模拟客户端代码的行为是合理的。 即使你的区块链里有普通的轻客户端，在最简单的交易上打上常规的数字签名来转移一些资产，每年客户端上的海量计算仍然越来越多，加密算法越来越强大，这部分处理可以成为未来的一个重要瓶颈。 因此，请注意，不要错过这样的情况：在一个持续 3.5 秒的交易中，2.5 秒用于准备和签署交易，1.0 秒用于将交易发送到网络并等待响应。 要评估此瓶颈的风险，您需要从客户端计算机收集指标，而不仅仅是从区块链节点收集指标。
发送交易并监控其状态
下一步是将交易发送到选定的区块链节点并接收接受其进入交易池的状态。 此阶段类似于常规数据库访问；节点必须将交易记录在池中，并开始通过 p2p 网络分发有关该交易的信息。 这里评估性能的方法类似于评估传统Web API微服务的性能，区块链中的交易本身可以更新并主动改变其状态。 一般来说，更新某些区块链上的交易信息可能会发生多次，例如在链分叉之间切换时或当 BP 宣布打算将交易包含在区块中时。 该池的大小和其中的交易数量的限制可能会影响区块链的性能。 如果事务池被填满到最大可能的大小，或者内存无法容纳，网络性能可能会急剧下降。 区块链没有集中的手段来防止大量垃圾消息，如果区块链支持大容量交易和低费用，这可能会导致交易池溢出——另一个潜在的性能瓶颈。
在区块链中，客户端向他喜欢的任何区块链节点发送交易，交易的哈希值通常在发送之前客户端就已知，因此他所需要做的就是实现连接，传输后等待区块链发生变化它的状态，使他的交易成为可能。 请注意，通过测量“tps”，对于连接区块链节点的不同方法，您可以获得完全不同的结果。 这可以是常规的 HTTP RPC 或允许您实现“订阅”模式的 WebSocket。 在第二种情况下，客户端会更早收到通知，节点会花费更少的资源（主要是内存和流量）来响应交易状态。 因此，在测量“tps”时，有必要考虑客户端连接到节点的方式。 因此，为了评估这一瓶颈的风险，基准区块链必须能够按照与真实网络相对应的比例模拟具有 WebSocket 和 HTTP RPC 请求的客户端，并改变交易的性质及其大小。
要评估此瓶颈的风险，您还需要从客户端计算机收集指标，而不仅仅是从区块链节点收集指标。
通过 p2p 网络传输交易和区块
在区块链中，点对点（p2p）网络用于在参与者之间传输交易和区块。 交易从一个节点开始传播到整个网络，直到到达对等区块生产者，后者将交易打包到区块中，并使用相同的 p2p 将新区块分发到所有网络节点。 大多数现代 p2p 网络的基础是 Kademlia 协议的各种修改。 该协议的一个很好的总结，以及 - 一篇对 BitTorrent 网络进行各种测量的文章，从中可以了解到这种类型的网络比集中式服务的严格配置的网络更复杂且更难以预测。 还， 关于测量以太坊节点的各种有趣指标的文章。
简而言之，此类网络中的每个对等点都维护自己的其他对等点的动态列表，从这些对等点请求按内容寻址的信息块。 当对等点收到请求时，它要么提供必要的信息，要么将请求传递给列表中的下一个伪随机对等点，并在收到响应后将其传递给请求者并缓存一段时间，给出此下次早一点信息块。 这样，流行的信息最终会被大量节点的大量缓存，而不流行的信息会逐渐被取代。 同行记录了谁向谁传输了多少信息，并且网络试图通过提高活跃的分发者的评级并为他们提供更高水平的服务来刺激活跃的分发者，自动将不活跃的参与者从同行列表中取代。
因此，交易现在需要分布在整个网络中，以便区块生产者可以看到它并将其包含在区块中。 节点主动向所有人“分发”新交易，并监听网络，等待索引中出现所需交易的区块，以通知等待的客户端。 网络在 p2p 网络中相互传输有关新交易和区块的信息所需的时间取决于很多因素：附近工作的诚实节点的数量（从网络的角度来看）、“热节点”的数量。这些节点的缓存、块的大小、交易、变化的性质、网络地理、节点数量和许多其他因素。 在此类网络中对性能指标进行复杂的测量是一件复杂的事情；有必要同时评估客户端和对等点（区块链节点）上的请求处理时间。 任何一个p2p机制出现问题，不正确的数据驱逐和缓存，对活跃节点列表的无效管理等许多因素都可能导致延迟，影响整个网络的整体效率，而这个瓶颈是最难分析的、测试和结果解释。
区块链处理和状态数据库更新
区块链最重要的部分是共识算法、其对从网络接收的新区块的应用以及交易处理并将结果记录在状态数据库中。 向链添加新块然后选择主链应该尽快进行。 然而，在现实生活中，“应该”并不意味着“有效”，例如，我们可以想象这样一种情况：两条长的竞争链不断地在自身之间切换，每次切换都会更改池中数千笔交易的元数据，不断回滚状态数据库。 这个阶段，就定义瓶颈而言，比p2p网络层更简单，因为交易执行和共识算法是严格确定性的，在这里更容易测量任何东西。
最主要的是不要将此阶段性能的随机下降与网络问题混淆 - 节点传递块和有关主链的信息的速度较慢，对于外部客户端来说，这可能看起来像一个缓慢的网络，尽管问题在于一个完全不同的地方。
为了优化此阶段的性能，从节点本身收集和监控指标非常有用，并将与更新状态数据库相关的指标包含在其中：节点上处理的块数量、大小、交易数量、链分叉之间的切换次数、无效块的数量、虚拟机运行时间、数据提交时间等。 这将防止网络问题与链处理算法中的错误混淆。
处理交易的虚拟机可以成为可以优化区块链操作的有用信息源。 内存分配数量、读/写指令数量以及其他与合约代码执行效率相关的指标可以为开发人员提供很多有用的信息。 同时，智能合约是程序，这意味着理论上它们可以消耗任何资源：CPU/内存/网络/存储，因此交易处理是一个相当不确定的阶段，此外，在版本之间移动时，它会发生很大的变化以及更改合同代码时。 因此，还需要与交易处理相关的指标来有效优化区块链性能。
客户收到有关将交易纳入区块链的通知
这是区块链客户端接收服务的最后阶段；与其他阶段相比，没有很大的开销成本，但仍然值得考虑客户端从节点接收大量响应的可能性（例如，智能合约）返回数据数组）。 无论如何，这一点对于提出“你的区块链中有多少 tps？”这个问题的人来说是最重要的，因为此时，记录了接受服务的时间。
在这个地方，总是有一个发送客户端必须花费等待区块链响应的完整时间；正是这个时间，用户将在他的应用程序中等待确认，这就是它的优化开发商的主要任务。
结论
因此，我们可以描述在区块链上执行的操作类型并将其分为几类：
- 密码转换、证明构造
- 点对点网络、交易和块复制
- 交易处理、智能合约执行
- 将区块链中的更改应用到状态数据库，更新交易和区块的数据
- 对状态数据库、区块链节点 API、订阅服务的只读请求
总的来说，现代区块链节点的技术要求极其严格——用于密码学的快速CPU、用于存储和快速访问状态数据库的大量RAM、使用大量同时打开的连接的网络交互以及大存储。 如此高的要求和丰富的不同类型的操作不可避免地导致节点可能没有足够的资源，然后上面讨论的任何阶段都可能成为整体网络性能的另一个瓶颈。
在设计和评估区块链的性能时，您必须考虑所有这些要点。 为此，您需要同时从客户端和网络节点收集和分析指标，寻找它们之间的相关性，估计为客户端提供服务所需的时间，考虑所有主要资源：CPU/内存/网络/存储，了解它们如何使用以及如何相互影响。 所有这些使得以“多少 TPS”的形式比较不同区块链的速度成为一项极其吃力不讨好的任务，因为存在大量不同的配置和状态。 在大型中心化系统中，数百台服务器的集群中，这些问题也很复杂，也需要收集大量不同的指标，但在区块链中，由于p2p网络、虚拟机处理合约、内部经济、度数自由度要大得多，这使得即使在多个服务器上进行测试，它也是非指示性的，仅显示与现实几乎没有联系的极其近似的值。
因此，在区块链核心开发时，为了评估性能并回答“与上次相比是否有所改进？”的问题，我们使用相当复杂的软件来协调具有数十个节点的区块链的启动，并自动启动基准测试并收集指标；如果没有这些信息，调试与多个参与者一起使用的协议将极其困难。
因此，当您收到“您的区块链中有多少 TPS？”的问题时，请为您的对话者提供一些茶，并询问他是否准备好查看十几个图表，并听取区块链性能问题的所有三个框以及您的建议解决他们...
来源： habr.com