文/JosephBonneaua16zCrypto研究员
性能和可扩展性是加密世界面临的挑战，一直是一个激烈讨论的话题，与L1项目和L2解决方案密切相关。然而，我们还没有标准化的指标或基准进行衡量。数据报告往往不一致且不完整，这使得项目间的准确比较变得非常困难，而且常常使实践中最重要的内容模糊不清。
我们需要一种更细致、彻底的方法来衡量和比较区块链性能——应将性能分解为多个组件，并在多个轴上进行比较权衡。在本文中，我定义了基本术语，概述了困难挑战，并提供了评估区块链性能需要谨记的指导方针和关键原则。
可扩展性vs.性能
首先，让我们先定义两个术语，那就是可扩展性和性能，它们具有标准的计算机科学含义，在区块链背景下经常被误用。性能用来衡量系统当前能够实现的目标。正如我们下面将要讨论的，性能指标可能包括每秒交易数量或交易确认时间中位数。另一方面，可扩展性则用来衡量系统通过添加资源来提升性能的能力。
这个区别是很重要的：如果定义正确，很多提高性能的方法是根本不能提高可扩展性的。一个简单的例子就是使用更有效的数字签名机制，例如BLS签名，其长度约是Schnorr或ECDSA签名的一半。如果比特币从ECDSA签名切换到BLS，每个区块的交易数量可能会增加20-30%，一夜之间就能提高性能。但我们只能这样做一次——再没有其他更节省空间的签名机制可供切换。
在区块链中还有其他一些一次性技巧可以使用，但你需要一个可扩展的体系架构来实现持续的性能优化，添加更多的资源可以随着时间的推移提升性能。这也是许多其他计算机系统的传统智慧，比如构建一个网络服务器。通过一些常见技巧，你可以构建一个速度非常快的服务器；但最终，你需要一个多服务器体系架构，通过不断添加新的服务器来满足不断增长的需求。
Web3操作协议dappOS发布V2路线图，包括统一账户等新功能:7月8日消息，Web3 操作协议 dappOS 发布 V2 版本路线图，包括统一账户、任务关联订单执行、全新竞价系统等新功能，此外 dappOS V2 首批支持项目包括 Benqi、Cheems、Curve、DeFi Kingdom、Frax Finance、GMX、KyberSwap、Lido、Perpetual、QuickSwap、StarryNift、SyncSwap 和 SynFutures。
此前报道，2023 年 6 月，dappOS 获得 Binance Labs 投资。[2023/7/8 22:25:36]
懂得这个区别还有助于避免语句中出现的常见类别错误，比如“区块链X是高度可扩展的，它每秒可以处理Y个交易！”后半句说法可能令人印象深刻，但它是一个性能指标，而非可扩展性指标。它说的并不是通过添加资源来提升性能的能力。
可扩展性本质上要求利用并行性。在区块链世界中，L1扩展明显需要分片或类似于分片的支持。分片的基本概念是将状态分割成一系列分区，以便不同的验证者可以独立处理，此概念与可扩展性的定义非常匹配。在L2上还有更多选项，L2允许添加并行处理，包括链下通道、rollup服务器和侧链。
延迟vs.吞吐量
通常，区块链系统性能是通过两个维度进行评估的，即延迟和吞吐量：延迟用以衡量确认单个交易的速度，而吞吐量用以衡量随着时间的推移交易的总速率。这些度量轴既适用于L1和L2系统，也适用于许多其他类型的计算机系统。
隐私网络Iron Fish激励测试网Phase 3启动:1月26日消息，Layer1隐私网络IronFish激励测试网Phase 3启动，用户可以通过与其交互赚取积分，IronFish将在主网启动时将积分转化为Token。[2023/1/26 11:30:25]
遗憾的是，对延迟和吞吐量的衡量和比较都很复杂。此外，个人用户实际上并不关心吞吐量。个人用户真正关心的是延迟和交易费——更具体地说，就是他们的交易尽可能快、尽可能低成本地得到确认。尽管许多其他计算机系统也以成本/性能为基础进行评估，但交易费是区块链系统的一个新的性能轴，并不真实存在于传统计算机系统中。
衡量延迟面对的挑战
延迟一开始看起来简单明了：交易需要多长时间才能得到确认？但总是有几种不同的方法来回答这个问题。
首先，我们可以在不同时间点衡量延迟，得到的结果也不同。例如，我们什么时候开始计时衡量？是当用户在本地点击“提交”按钮时，还是当交易进入内存池时？我们又在什么时候停止计时呢？是当交易进入提议区块中，还是当一个区块被后续一个或六个区块确认时？
最常用的方法是从验证者角度出发，衡量从一个客户端第一次广播交易到合理“确认”交易的时间。当然，不同的商家可能采用不同的验收标准，甚至同一个商家也可能根据交易金额的不同采用不同的标准。
以验证者为中心的方法忽略了在实践中的一些重要事项。首先，它忽略了点对点网络上的延迟，也忽略了客户端延迟客户端延迟可能非常小，对于签署以太坊支付等简单的交易来说是可以预测的，但对于更复杂的情况延迟问题则可能变得非常显著，如证明一个被屏蔽的Zcash交易是正确的。
前职业跆拳道选手Andrew Tate：我会再买一些比特币:金色财经报道，网络红人前职业跆拳道选手Andrew Tate表示，“我今天会再买一些比特币”。[2022/12/19 21:52:46]
即使我们将试图衡量延迟的时间窗口标准化，答案也几乎总是视情况而定。迄今为止，还没有哪个加密货币系统能提供固定的交易延迟。要记住一个基本的经验法则：
延迟是一个分布，而非一个数字。
网络研究界早就明白这一点。对分布的“长尾”进行了特别强调，因为即使是0.1%的交易的延迟也会给终端用户带来严重影响。
在区块链中，延迟确认可因多种原因发生变化：
批处理：大多数系统都以某种方式进行交易批处理，例如，在大多数L1系统上交易被批处理到区块中。这将导致延迟变数，因为一些交易将不得不排队等候，直到这批交易填满区块。其他交易可能比较幸运，因最后加入该批交易而无需等待。这些交易会立即得到确认，不会经历任何额外延迟。
拥堵变量：大多数系统都会出现拥堵，也就是发布的交易量大于系统能够立即处理的交易量。当交易在不可预测的时间进行广播时，或者当新交易在一天或一周内的交易速度发生变化时，亦或在响应外部事件时，拥堵程度会发生变化。
共识层差异：在L1上确认交易通常需要一组分布式节点来达成对一个区块的共识，无论拥堵情况如何，都可能会增加可变的延迟。工作量证明系统在不可预测的时间找到区块。权益证明系统也可以添加各种延迟。
国家网信办集中整治涉虚拟货币炒作乱象:8月9日消息，国家网信办集中整治涉虚拟货币炒作乱象。按照《关于进一步防范和处置虚拟货币交易炒作风险的通知》精神，国家网信办督促指导主要网站平台切实落实主体责任，持续保持对虚拟货币交易炒作高压打击态势，加大对诱导虚拟货币投资等信息内容和账号自查自纠力度。
此外，指导地方网信部门约谈涉虚拟货币宣传炒作的“链节点”、“创投圈”等经营主体500余家次，要求全面清理宣传炒作虚拟货币交易的信息内容。对专门为虚拟货币营销鼓吹、发布教程讲解跨境炒币、虚拟货币“挖矿”的“币头条”等105家网站平台，国家网信办会同相关部门依法予以关闭。（网信中国）[2022/8/9 12:11:20]
基于这些原因，一个极价的指导原则就是：
关于延迟的声明应该显示确认时间的分布，而不是平均值或中位数这样的单个数字。
虽然像平均值、中位数或百分位数这样的汇总统计数据提供了部分情况，但准确评估一个系统需要考虑整个分布。在某些应用程序中，如果延迟分布相对简单，则平均延迟可以提供很好的洞察。但在加密货币中，几乎从来都不是这样：通常情况下，确认时间非常缓慢。
支付渠道网络就是一个很好的例子。这是一个经典的L2扩展解决方案，这些网络多数时候提供非常快速的支付确认，但偶尔需要重置通道，由此便会增加延迟的数量级。
即使我们对确切的延迟分布有充分的统计，也可能会随着系统和系统需求的变化而变化。另外，关于如何比较竞争系统间的延迟分布也并不总是很清晰。例如，假设一个系统确认的交易延迟均匀分布在1到2分钟之间。如果另一个竞争系统在1分钟内准确确认95%的交易，而在11分钟内确认另外5%的交易，那么哪个系统更好？答案可能是，有些应用程序更喜欢前者，而有些则更喜欢后者。
美SEC诉Ripple案进展：法官拒绝SEC将Hinman演讲文件保密的动议:7月13日消息，美国证券交易委员会（SEC）在针对瑞波的Ripple中遭受了打击，一名美国法官否认了其关于“Hinman演讲”相关文件属于律师-当事人特权的主张。7月12日，美国地方法官Sarah Netburn在否认该动议时指出，SEC辩称该演讲是Hinman的个人事务，但同时声称该演讲文档应保密，因为他从SEC获得了确认委员会政策的法律建议。
Netburn法官表示，SEC一方面向法院辩称该演讲与市场对SEC将如何或是否将监管加密货币的理解无关，而另一方面，Hinman在起草演讲稿时寻求并获得了SEC律师的法律建议，SEC在这一点上很虚伪，这表明SEC采取其诉讼立场是为了进一步实现其期望的目标，而不是出于对法律的忠诚。
据悉，Hinman曾在2018年金融科技周会议上发言时表示，出售ETH并不构成“证券交易”。SEC一直在努力保密的Hinman演讲草案已被XRP社区中的许多人视为可能有利于Ripple Labs的关键证据。（Cointelegraph）[2022/7/13 2:10:05]
最后，需要注意的是，在大多数系统中，并非所有交易的优先级都是相同的。用户可以通过支付更多钱来获得更高的优先级，所以除了上述几个因素外，延迟也取决于所支付的交易费。总而言之：
延迟是复杂的。报告的数据越多越好。理想情况下，应该在不同拥堵条件下衡量完整的延迟分布。将延迟分解为不同组件也会有所助益。
衡量吞吐量面对的挑战
乍一看，吞吐量似乎也很简单明了：一个系统每秒可以处理多少交易？这里存在两个主要难点：究竟什么是“交易”，以及我们是在衡量一个系统今天正在做什么，还是未来可能做什么？
虽然“每秒交易量”是衡量区块链性能的实际标准，但交易量作为度量单位是有问题的。对于提供通用可编程性的系统或者甚至是有限功能的系统，如比特币的多路交易或多信号验证选项，存在的基本问题是：
并非所有的交易都是平等的。
以太坊明显如此。在以太坊中，交易可以包括任意代码和任意修改状态。以太坊中的gas概念用于量化一笔交易正在进行的总体工作量，但这与EVM执行环境高度相关。没有简单的方法可以比较一组EVM交易与一组应用BPF环境的Solana交易所处理的工作总量。将两者与一组比特币交易进行比较同样令人担忧。
将交易层划分为共识层和执行层的区块链可以让这一点更加明确。在共识层上，吞吐量可以用每单位时间添加到链上的字节来衡量。执行层的情况总是更加复杂。
例如只支持支付交易的rollup服务器这种比较简单的执行层，避免了量化计算的困难。即使在这种情况下，支付也会因投入和产出的数量不同而变化。支付通道交易可能因所需的影响吞吐量的“跳数”而异。rollup服务器吞吐量可取决于将一批交易“联网”到更小的汇总更改集的程度。
吞吐量的另一个挑战是并非以经验衡量今天的表现，而是评估其理论能力。这就引入了各种建模问题来评估潜在能力。首先，我们必须为执行层确定一个实际的交易工作负载。其次，实际系统几乎从未达到理论容量，尤其是区块链系统。出于运行强健的考虑，我们希望节点实施在实践中是异构的、多样化的。这使得精确模拟区块链吞吐量更加困难。
总之：
吞吐量声明需要仔细说明交易工作负载和验证者。在没有任何明确标准的情况下，来自以太坊等主流网络的历史工作负载就足够了。
延迟—吞吐量间的权衡
延迟和吞吐量通常是一种权衡关系。正如LefterisKokoris-Kogias所描述的那样，这种权衡通常不是一条顺滑的线，存在一个拐点，即当系统负载接近最大吞吐量时，延迟会急剧增加。
零知识rollup系统是吞吐量/延迟权衡的一个天然例子。大批量的交易会增加证明时间，从而增加延迟。但无论是在证明大小还是在验证成本方面，链上足迹将分摊到更大批、更多的交易中，进而增加吞吐量。
交易费
可以理解的是，终端用户更关心延迟和费用之间的权衡，而不是延迟和吞吐量之间的权衡。用户根本没有关心吞吐量的直接原因，他们只关心是不是能够以尽可能低的费用快速确认交易。总结起来，费用受多重因素影响：
1、有多大市场需求支持交易？
2、系统能达到的总吞吐量有多大？
3、系统提供给验证者或矿工的总收益有多少？
4、该收益中有多少是基于交易费或通货膨胀奖励？
前两个因素大致构成导致市场出清价格的供应/需求曲线。在其他条件相同的情况下，更高的吞吐量应该会导致更低的费用，但还有更多的因素。
特别注意上面的第3点和第4点，是区块链系统设计的基本问题，但是对它们我们还没形成良好的原则。关于给予矿工通胀奖励还是交易费的优缺点我们已有一定的了解。然而，尽管有许多关于区块链共识协议的经济分析，我们仍然没有一个广泛适用的模型来说明需要给验证者多少收益。今天，大多数系统都内建一个有根据的猜测，即多少收益足以让验证者诚实作为，同时又不会妨碍系统的实际使用。
提高攻击成本是一件好事，但我们也不知道多少安全措施才是“足够的”。想象一下，你正在考虑去两个游乐园。其中一个声称在游乐设施维护上比另一个少花50%的费用。去这个公园是个好主意吗？可能因为这个公园的设施效用更高，用更少的钱就能获得同等安全性。也许另一个公园花费超过正常所需费用来保证游乐设施的安全，但没有额外好处。但也可能是第一个公园真的很危险。区块链系统也类似。一旦剔除吞吐量，费用较低的区块链之所以费用低，是因为它们对验证者的奖励较少。我们现在没有得力工具来评估这样是否可行，或者是否会让系统更容易受到攻击。总之：
在不同系统之间比较费用可能会产生误导。虽然交易费对用户来说很重要，但除了系统设计本身之外，费用还会受到很多因素的影响。吞吐量则是分析整个系统的更好指标。
结束语
公平准确地评估性能是很难的。就好比测量一辆汽车的性能。拿区块链来说，不同的人会关心不同的方面。对于汽车，有些用户会关心最高车速或加速性能，有些人会关心油耗，还有一些人会关心牵引力。所有这些都不容易评估。例如，美国环境保护署就制定了详细的指导方针，规定如何评估汽油里程数，以及在经销商处必须如何向用户展示。
区块链世界要达到这个级别的标准化还有很长的路要走。在某些领域，未来我们可能会使用标准化的工作负载来评估系统吞吐量，或者使用标准化的图形来表示延迟分布。目前，对评估者和建设者来说，最好的办法就是采集和公布尽可能多的数据，并对评估方法进行详细描述，以便该方法能够得以复制，与其他系统进行比较。
来源：金色财经
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。