关于性能和可扩展性的讨论是整个加密世界最持久的争论。关于第一层和第二层解决方案的优点和有效性的争论一直在进行。但由于缺乏标准化的指标和考核标准，各方在争论中拿出的数据往往不一致，这无疑进一步加剧了意见分歧。简单的说，我们需要一个更详细更透彻的性能对比方法。比如我们需要把性能分成几个维度进行比较，找到一个综合的权衡标准。在本文中，我将从基本术语入手，概述当今市场面临的挑战，并扩展评估区块链性能时要牢记的一些基本原则。可伸缩性和性能首先，让我们定义两个术语，可伸缩性和性能。这两个词具有标准的计算机科学含义，但在区块链上下文中经常被误用。性能一般用来衡量系统所能达到的目标性能。性能指标可能包括每秒可处理的进程数或特定要求下所需的时间长度。可扩展性用于衡量系统通过添加某些资源来提高性能的能力。为什么要先定义它，因为实际上很多提高性能的方法根本不会提高可扩展性。一个简单的例子是使用更高效的数字签名方案，例如BLS签名，它的大小大约是Schnorr或ECDSA签名的一半。如果比特币从ECDSA切换到BLS，每个区块的交易数量可能会增加20-30%，一夜之间提高性能。但是我们只能这样做一次——没有更节省空间的签名方案可以切换（BLS签名也可以聚合以节省更多空间，但这同样只是另一个一次性的技巧）。其实区块链网络中有很多改进的trick也是一次性的（比如SegWit），但是对于我们来说，真正需要的是一个可扩展的架构来实现持续的性能提升，只有这样我们才能通过不断的添加资源以不断提高性能。其实在Web2时代，这已经是一种常用的方法了。以搭建服务器为例。虽然我们可以直接搭建一个足够快的服务器，但是一般最后还是需要升级到多服务器架构。在此期间，我们需要不断添加新的服务器以满足不断增长的数据存储/处理需求。了解这种区别还有助于避免诸如“区块链具有高度可扩展性，它每秒可以处理多少笔交易！”等陈述中的常识性错误。虽然这种言论可能具有煽动性，但事实是处理了多少事务是性能指标而不是可扩展性指标。可扩展性本质上需要利用并行性。在区块链空间中，层扩展通常需要分片，或者看起来像分片。分片的基本概念其实就是把状态分成几块，让不同的验证者可以独立处理其中的一部分，这很符合可伸缩性的定义。当然，第二层还有更多选项可以添加并行处理，包括链下通道、汇总、侧链等。延迟和吞吐量过去，我们通常用延迟和吞吐量两个维度来评估区块链的性能：延迟可以用来衡量单笔交易的确认速度，而吞吐量用来衡量可以确认的交易一定时间内的总量。这一措施适用于Layer1和Layer2网络，甚至可以完美适用于区块链以外的其他类型的计算机系统。不幸的是，延迟和吞吐量这两个维度实际上都很难衡量和比较。还有一个非常重要的一点是，个人用户其实并不关心吞吐量，他们真正关心的是延迟和交易费用。交易费用是传统计算中不存在的区块链系统中的一个重要维度。测量延迟的挑战延迟的测量可能看起来很简单：确认交易需要多长时间？但在实践中，问题就会出现。首先，我们在不同时间点测量的延迟往往是不同的。我们是否从用户本地点击提交按钮开始计算？还是在任务到达内存池时开始计算？另外，当块被确认时，我们是否要立即停止计时器？不同的操作细节会带来不同的结果。衡量这一点的最常见方法是从验证者的角度来看，从客户首次广播交易到交易被合理确认（在现实世界的商人会考虑接收付款和发送物品的意义上）.当然，不同的商户可以采用不同的受理标准，甚至单个商户也可以根据交易金额采用不同的标准。以验证者为中心的方法忽略了一些在实践中很重要的事情。首先，它忽略了对等网络上的延迟（客户端广播交易需要多长时间，直到大多数节点听到它？）和客户端延迟（准备交易需要多长时间？在客户端的本地机器上加载需要多长时间？？）。对于签署以太坊支付等简单交易，客户端延迟可能非常小且可预测，但对于证明私人交易正确等更复杂的情况则不然。即使我们将测量延迟的时间窗口归一化，最终的答案仍然是个案分析。从来没有一种加密货币系统可以保证持续的交易延迟。要记住的基本经验法则是：延迟是一个分布，而不是一个数字。网络研究界早就认识到了这一点，并指出长尾非常关键，即使是一个过程中0.1%的延迟也会严重影响最终用户体验。对于区块链，确认延迟可能因多种原因而有所不同：批处理：大多数系统以某种方式批处理交易，这导致可变延迟，因为某些交易必须等到批处理后才会处理，直到队列已满。网络参与者可能很幸运能够搭乘该批次的末班车。这些交易立即得到确认，没有任何额外的延迟，但那些较早进入队列的人将不得不等待更长时间才能得到确认。不确定的拥塞：大多数系统都会遇到拥塞，这意味着发出的交易多于系统一次可以处理的数量。当交易在不可预测的时间广播（通常被抽象为泊松过程），或者当新交易的速率在一天或一周内发生变化，或者响应外部事件时，拥塞可能会有所不同。共识层差异：在一个层确认交易通常需要一组分布式节点在一个块上达成共识，这可以增加可变延迟而不受拥塞影响。工作量证明系统会在不可预测的时间发现区块。股权证明系统也会增加各种延迟。由于这些原因，一个好的指导方针是关于延迟的声明应该作为确认时间的分布而不是像平均值或中位数这样的单个数字来表示。虽然平均值、中位数或百分位数等汇总统计数据也可以指示某些模式，但准确评估系统需要考虑整个分布。在某些应用程序中，如果延迟分布相对简单，平均延迟可以提供很好的洞察力。但这种理想情况在加密货币中很少见：通常，确认时间会很长。闪电网络等支付渠道网络就是一个很好的例子。作为经典的L2扩展解决方案，这些网络在大多数情况下提供非常快速的支付确认服务，但有时它们需要通道重置，这可能会按数量级增加延迟。即使我们对确切的延迟分布有很好的统计数据，它们也可能随着系统和系统需求的变化而变化，并且如何比较竞争系统之间的延迟分布是非常模糊的。例如，考虑一个确认事务的系统，其延迟均匀分布在1到2分钟（平均和中值90秒）之间。如果一个竞争系统在1分钟内准确确认95%的交易，在11分钟内（平均90秒，中值60秒）准确确认其他5%，哪个系统更好？答案是可能不会一致地选择不同类别的应用程序。最后，重要的是要注意在大多数系统中并非所有事务都具有相同的优先级。用户可以支付更多费用以获得更高的包含优先级，因此除了上述所有内容外，延迟还取决于支付的交易费用。总之：延迟很复杂。先决条件越详细越好。理想情况下，应在不同的拥塞条件下测量完整的延迟分布。将延迟分解为不同的组件（本地、网络、批处理、共识延迟）也很有帮助。衡量吞吐量的挑战吞吐量乍一看似乎也很简单：系统每秒可以处理多少事务？但实际上问题也隐藏在表面之下。难度主要体现在两个方面。首先是什么算作交易。我们是否在衡量一个系统今天做了什么？或者衡量他能做什么？虽然每秒交易数（或TPS）是衡量区块链性能的常用指标，但作为衡量单位的交易数存在问题。提供通用可编程性（智能合约）甚至有限功能（如比特币的多交易或多签名验证选项）的系统的一个基本问题是，并非所有交易都是平等的。在以太坊网络中，交易可以包含任意代码和任意状态。以太坊中的Gas概念用于量化（并收取）一笔交易所做的总工作量，但这对EVM执行环境具有高度特定性。没有简单的方法可以直接将一组EVM事务??完成的工作总量与一组使用BPF环境的Solana事务完成的工作量进行比较。将它们中的任何一个直接与一组比特币交易进行比较也不是不合理的。将交易层分离为共识层和执行层的区块链可以使这一点更加清晰。在（纯）共识层中，吞吐量可以用每单位时间添加到链中的字节数来衡量。执行层要复杂得多。更简单的执行层，比如只支持支付交易的rollupserver，避免了量化计算的困难。但是，即使在这种情况下，付出的投入量和产出量也会不同。支付通道交易所需的可变参数数量可能会有所不同，这会影响吞吐量。汇总服务器的吞吐量可能取决于将一批交易“分解”为一组较小数据包的程度。吞吐量的另一个挑战是超越凭经验衡量当今的性能来评估理论容量。这引入了各种建模问题来评估潜在容量。首先，我们必须确定执行层的实际事务工作量。其次，真实系统几乎永远不会达到理论容量，尤其是区块链系统。出于稳健性的原因，我们希望节点实现在实践中是异构和多样化的（而不是所有客户端都运行一个软件实现）。这使得准确模拟区块链吞吐量变得更加困难。总的来说，吞吐量权衡需要仔细解释交易工作量和验证器数量。在没有明确标准的情况下，只能以以太坊比较流行的网络历史负载作为比较衡量的标准。时延和吞吐量的综合考虑在时延和吞吐量分别统计出来之后，我们还需要在两者之间做一个综合的权衡。正如LefterisKokoris-Kogias所指出的，这种权衡通常并不顺利，当系统负载接近其最大吞吐量时，延迟会急剧上升。ZKRollup系统提供了吞吐量/延迟权??衡的一个自然示例。大批量交易会增加证明时间，从而增加延迟。然而，链上计算能力在证明规模和验证成本方面将偏向于更大的交易集群，从而提高吞吐量。交易费用可以理解的是，最终用户更关心延迟和费用之间的权衡，而不是延迟和吞吐量。用户根本不必关心吞吐量，他们只希望交易能够以尽可能低的费用快速确认（一些用户更关心费用，另一些用户则关心延迟）。总的来说，成本受几个因素的影响：市场需求有多大？系统可达到的总吞吐量是多少？系统为验证者或矿工提供多少收入？这些收入中有多少是基于交易费用与通货膨胀奖励？简而言之，更高的吞吐量应该导致更低的费用，其他条件相同。但是，上面提到的第3点和第4点是区块链系统设计的基本问题。尽管对区块链共识协议进行了许多经济分析，但我们仍然没有关于验证者需要多少收入的共识模型。今天的大多数系统都建立在有根据的猜测之上，即在不损害网络对用户的吸引力的情况下，为验证者提供多少收入以诚实行事。在简化模型中，让发起51%攻击的成本与验证者的奖励成正比。提高攻击成本是好事，但我们也不知道多少安全性才“足够”。想象一下，您正在考虑去两个游乐园。其中一个声称在乘车维护上的花费比另一个少50%。去这个公园是个好主意吗？可能是因为它们效率更高，并以更少的钱获得相同的安全性。也许另一个人花费的钱比保护游乐设施安全所花费的更多，但没有任何好处。但也可能是第一个公园很危险。区块链系统是相似的。一旦考虑吞吐量，费用较低的区块链费用较低，因为它们奖励较少。我们今天没有好的工具来评估这是否可能，或者它是否会使系统容易受到攻击。一般而言：比较系统之间的成本可能会产生误导。交易手续费虽然对用户很重要，但除了系统设计本身，还受到很多因素的影响。吞吐量是分析整个系统的更好指标。结论公平准确地评估绩效很困难。衡量区块链就像衡量一辆汽车是否值得购买一样复杂。不同的人会关心不同的事情。对于汽车，有的用户会关心极限时速或者百公里加速性能，有的人关心油耗，有的人只关心汽车能装多少货物。正因为如此，美国环境保护署甚至发布了汽车评级标准的直接指南。在区块链领域，我们离可以出台标准的那一刻还很远。在某个时候，我们可能会找到一个标准的工作负载，并用它来绘制区块链网络吞吐量和延迟分布的“标准图表”。“但现在对于研究人员和建设者来说，最好的方式是尽可能多地收集数据，在发表意见之前尽可能详细地描述测试环境，因为只有这样才能得到一个相对客观的对比结果。
