来源|?paradigm.xyz
作者|?LefterisKokoris-Kogias
大家鲜少提到如何正确地测量一个系统，但它却是系统设计和评估过程中最重要的步骤。系统中有许多共识协议、各种性能的变量和对可扩展性的权衡。
然而，直到目前都没有一种所有人都认同的可靠方法，能够让人进行苹果对比苹果这种同一范畴内的合理比较。在本文，我们将概述受到数据中心化系统测量机制启发的一种方法，并探讨在评估一个区块链系统时可以避免的一些常见错误。
关键指标及其相互作用
在开发区块链系统时，我们应该将两个重要指标考量在内：延迟和吞吐量。
用户关心的第一件事就是交易延迟，即发起交易或支付和收到确认交易有效性信息之间的时间。
在传统的BFT系统中，一旦交易被确认就会被敲定，而最长链共识机制中，一笔交易可能会被打包进区块，然后再重组。结果就是，我们需要一直等到交易达到“k个区块深”了才能进行敲定，这就导致了延迟的时间大大超过了单次确认的时间。
金融稳定委员会发布国际加密资产监管框架:10月16日消息，金融稳定委员会 (FSB) 本周发布国际加密资产监管框架“International Regulation of Crypto-asset Activities”，为每个司法管辖区的立法者提供政策建议，旨在保持加密领域的创新。
FSB 表示，有效的监管框架必须确保加密资产活动受到全面监管，与加密资产活动带来的风险相称，同时利用其背后技术的潜在优势。此类监管应确保在它们造成与传统金融活动所造成的风险类似的风险时产生同等的监管结果，同时处理加密资产的新特征。FSB 还强调，立法者应监控 Stablecoin 发行公司的后端运营，以确保发行方不断维持已发行 Stablecoin 背后的资金，防止类似 TerraUSD 崩盘的事件再次发生。据悉，FSB 要求旗下成员在 2022 年 12 月 15 日之前就这一全球监管框架发表意见。[2022/10/16 17:27:56]
其次，系统的吞吐量一般对于系统设计者来说十分重要。这就是系统每单位时间所处理的总负载，一般表达为每秒交易量(TPS)。
欧盟加密资产市场 (MiCA) 法规文本或将在6周内准备就绪:金色财经报道，欧盟主要立法者Stefan Berger表示，欧盟加密资产市场 (MiCA) 法规的文本可能会在六周内准备就绪。立法者和政府已于6月30日就立法的主要大纲达成一致，该法案要求加密资产提供者在6月30日向监管机构注册以在整个欧盟范围内提供服务，但在没有最终法律文本的情况下，仍存在相当大的不确定性。
Berger表示，根据最终协议，任何拥有超过1500万活跃用户的加密服务提供商都将受到欧洲层面的监管，这表明除了最大的参与者之外，所有参与者都将受到德国Bafin等国家监管机构的监督。但Berger也对该法律将如何对待NFT表示怀疑。业界担心，如果法律要求OpenSea等专门的NFT平台寻求授权，过早的监管可能会扼杀新兴和发展中的行业。我们决定将NFT排除在法律之外，除非它们类似于传统的金融资产。[2022/9/2 13:03:56]
乍一看，这两个关键指标看起来是完全相反的东西。但因为吞吐量由每秒的交易量得出，而延迟则是以秒为单位进行测量。自然而然地，我们会认为吞吐量=负载/延迟。
加密资产管理公司Valkyrie完成1115万美元融资，BNY Mellon等参投:6月8日消息，加密资产管理公司 Valkyrie 完成 1115 万美元战略融资，本轮融资由 Coinbase 旗下风险投资部门和 BNY Mellon、Wedbush Financial Services、SenaHill Partners、Belvedere Strategic Capital、Clearsky、Zilliqa Capital、C-Squared Ventures 等参投。本轮融资资金将用于继续建设其基础设施，旨在将更多机构投资者带入数字资产领域。
Valkyrie 目前提供八个协议信托、一个去中心化金融 (DeFi) 对冲基金、三个在纳斯达克上市的交易平台交易基金 (ETF) 和一个协议资金管理业务，截止 2022 一季度末，Valkyrie 资产管理规模已达 12 亿美元。（coindesk）[2022/6/8 4:11:11]
但事实并非如此。因为许多系统倾向于生成在y轴上展示吞吐量或延迟，而在x轴上展示节点数量的图表，所以这种计算方式的实现是不可能的。相反，我们能生成一个更好的、包含吞吐量/延迟指标的图表，它以非线性的方式呈现让图表清晰易读。
动态 | 英格兰及威尔士特许会计师协会发布《加密资产：会计师反指引》:英格兰及威尔士特许会计师协会（ICAEW）发布了《加密资产：会计师反指引》。该指引概述了关于区块链及加密货币的主要基本术语，并为会计师们提出了一些需考虑因素，包括协会会计师在采取行动前应提出的六个问题，以及了解风险的流程图。（Accountancy Daily）[2019/9/6]
当没有竞争时，延迟是恒定的，仅是改变系统的负载，就可以改变吞吐量。会发生这种情况，是因为低竞争情况下，发送交易的最小开销是固定的，且队列延迟为0，致使“无论进来什么，都能直接出去”。
在竞争激烈的情况下，吞吐量是恒定的，但仅是改变负载就可以让延迟发生变化。
这是因为系统已经超负载了，而增加更多负载会造成等待队列无限变长。更反常的是，延迟似乎会随着实验长度而发生变化，这是一个无限增长队列的人为结果。
动态 | 金融稳定委员会发布监测加密资产的新框架:据CCN报道，负责监督全球金融体系，同时协调G20国家监管的国际机构金融稳定委员会（FSB）发布了一个监测加密货币资产的新框架。本周一，FSB公布了其报告，透露其标准化的框架已于7月21日至22日在布宜诺斯艾利斯举行的会议前交付给了G20的财长和央行行长们。该框架是与由G10国家央行行长组成的支付与市场基础设施委员会（CPMI）协调制定的，提出了FSB将用于监控加密资产市场的一些指标。主要风险指标包括市值（规模和增长率），价格水平和主要加密货币的波动性。ICO发行以及来自法定货币的资本流入和流出将被视为财富效应指标，同时还将分析制度指标以关注传统金融市场的交易量，利润率和利息。FSB补充说，该框架“应有助于识别和减轻与消费者和投资者保护，市场诚信以及潜在的金融稳定性有关的风险”。FSB主席、英国央行行长Mark Carney表示，虽然FSB认为加密资产目前不会对全球金融稳定构成重大风险，但已认识到需要根据市场发展的速度对其进行警惕的监控。[2018/7/17]
这些表现都可以在典型的“曲棍球图”或“L型图”上看到，它取决于到达间隔的分布。因此，这篇文章的关键要点是，我们应该在热区进行测量，这里的吞吐量和延迟都会影响我们的基准；而不用测量边缘区域，这里的吞吐量和延迟只有一个是重要的。
测量方法论
在做实验时，实验者有三种主要的设计选项：
开环vs.闭环
现在有两种可以控制对目标发出请求流的主要方法。开环系统基于n=∞个客户端进行建模，这些客户端根据速率λ和到达间隔分布向目标发送请求。闭环系统会在任何给定时间内限制未完成请求的数量。开环系统和闭环系统的区别是特定部署的特点，同一个系统可以部署在不同的场景中。
例如，一个键值存储可以在一个开环部署中为数千个应用程序服务器提供服务，或在一个闭环部署中只为几个阻塞客户端提供服务。
对正确的部署场景进行测试是必不可少的，因为比起闭环系统的延迟通常受制于潜在的未完成请求数量，而开环系统可能会产生大量的等待队列，所以，延迟会更长。一般来说，区块链协议可以被任意数量的客户端使用，所以在开环环境下对其做评估会更准确。
综合基准测试的到达间隔分布
在创建合成工作负载时，我们必然会问：如何向系统提交请求？许多系统在测量之前会先预加载事务，但这会使测量产生偏差，因为系统从异常状态0开始运行。此外，预加载的请求已经在主存储器中，也因此绕过了其网络堆栈。
更好一些的方法则是以确定的速率发送请求，这会导致L型的图表的出现，因为系统的容量得到了最佳使用。
然而，开放系统往往不以可预测的方式运作。相反，它们有处于高负载和低负载的时间段。为了对此进行建模，我们可以采用概率间隔分布，该分布一般是基于泊松分布。它将导致“曲棍球”图表，因为即使平均速率低于最佳值，泊松爆发也会导致一些排队延迟。但这对我们十分有利，因为我们可以看到系统如何处理高负载以及负载恢复正常时，系统恢复的速度有多快。
热身阶段
最后要考虑的一点是何时开始测量。我们希望流水线在开始之前充满事务；否则，将需要测量预热延迟。理想情况下，预热延迟的测量应该通过热身阶段中的延迟测量来完成，直到测量结果遵循预期的分布。
如何进行比较
最后一个难题是合理比较系统的各种部署。同样，难点在于延迟和吞吐量是相互依赖的，因此我们可能难以生成公平的吞吐量/节点数图表。
最好的方法是定义服务级别目标?(SLO)并测量当时的吞吐量，而不是简单地将每个系统推到其最高吞吐量。在吞吐量/延迟图上绘制一条与延迟轴相交SLO处的水平线并对相交点进行采样，这是一种可视化的好方法。
但我设置了5秒的SLO，它只需要2秒
有人可能想要增加这里的负载，以便利用饱和点之后稍高的可用吞吐量。但是这很危险。如果系统操作配置不足，意外的请求爆发将导致系统达到完全饱和，致使延迟激增且很快会违背SLO。实质上，在饱和点之后运行会导致一种不稳定的平衡。
因此，有两点需要考虑：
过度配置系统。本质上，系统应该在饱和点以下运行，以便吸收到达间隔分布中的爆发，而不会导致排队延迟增加。
如果SLO下方有空间，请增加batch的大小。这会增加系统关键路径上的负载，而不会增多排队延迟，它为你提供更高的吞吐量以获得你所要的更高延迟权衡。
我正在产生巨大的负载，该如何测量延迟呢？
当系统的负载很高时，尝试访问本地时钟，并为到达系统的每个事务添加时间戳可能会导致结果出现偏差。
相反，还有两个更可行的选择。第一种也是最简单的方法是对事务进行抽样；例如，在某些事务中可能存在一个魔数，而这些事务是客户端为其保留计时器的事务。在提交时间之后，任何人都可以检查区块链以确定这些事务何时提交，从而计算它们的延迟。这种做法的主要优点是，它不会干扰到达间隔分布。但是，因为必须修改某些事务，所以它可能被认为是“hacky”。
而更系统的方法则是使用两个负载生成器。第一个是主要的负载生成器，由它来遵循泊松分布。第二个请求生成器则用来测量延迟，并且它的负载会低得多；与系统的其余部分相比，可以将这个请求生成器视为单个客户端。即使系统向每个请求发送回复，我们也可以轻松地将所有回复放到负载生成器中，并只测量来自请求生成器的延迟。
唯一棘手的部分是，实际的到达间隔分布是两个随机变量的总和；但是，两个泊松分布的总和仍然是泊松分布，所以数学并不难:)。
总结
测量大规模分布式系统对于识别瓶颈和分析压力下的预期行为是至关重要的。希望通过使用上述方法，我们都可以朝着公用语言迈出第一步，这最终将让区块链系统更适用于他们所做的工作以及他们对终端用户的承诺。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。