Findora优化其在EVM层的TPS
编者注：本文是根据Findora的多位工程师的意见撰写的，并不代表一个人的努力。这是Findora优化其在EVM层的初步成果，不久还会有更多的优化。
介绍
Findora区块链是UTXO和EVM分类帐的组合，通过称为PrismTransfer的原子桥连接在一起。Findora的目标是通过扩展以太坊隐私来创建一个基于区块链的内置隐私的新金融互联网。并通过先进的ZK密码学和SNAKRS来保护公链上的交易数据。
因此，虽然隐私是Findora的主要关注点，但可扩展性也必不可少——如果没有足够的带宽，网络就无法为多个生态系统提供隐私保护。
然而，虽然一些项目追求每秒10,000+笔的交易速度，但现实情况是许多项目并不需要如此高的TPS。绝大多数TVL存在于Ethereum和Bitcoin上，它们的TPS分别约为每秒15和6左右。
因此，高TPS是重要的但不是必要的，尤其是在刚开始。例如，Avalanche的理论TPS为4,500，但实际很少超过9TPS。
在过去的两个月中，Findora开发团队成功地将其EVM层的TPS提高了近4倍，达到了150左右——这足以承载它在未来将面临任何负荷。
大部分优化来自：
并行化TendermintABCI
使用读写锁代替唯一锁
增强交易检查逻辑
优化冗余序列化
本文将介绍实现这些优化的科学过程，并重点介绍一些突出的优化领域。希望通过分享我们在过去3个月进行的优化分析、执行和测试的技术细节，使其他使用EVM的团队可以充分利用我们所作的工作，并复制和扩展我们的成果。
方法论概述
我们相信，测试和提高性能的最佳方法是使用科学的方法：测试环境、分析结果、部署修复程序，然后重复。因此，我们将优化过程分为5个步骤：
测试
测试结果收集
分析
结果分析
更新代码并再次部署
通过简化和去除冗余，我们缩短了交易时间，提高了效率。隐私交易比透明交易需要更多的计算能力。尽管网络必须能够承载足够的负荷才能在现实世界的应用中使用，并且可扩展性是一个关键目标，但FindoraNetwork仍认为它的重要性次于隐私。
大部分TPS的优化来自快速累积的小改进。例如，团队通过优化序列化和反序列化过程，减少数据库读取和组合功能，提高了大约10TPS。
其他改进，例如改进check_tx函数和删除冗余内存分配，再次提高了TPS。
潜在的优化领域
总共有10点我们认为可以改进。不过，大多数优化来自以下6点：
改进了主界面中的deliver_tx和check_tx?
减少了数据存储结构中的持久化操作的次数
优化需要持久数据调用的功能，减少调用次数
为deliver_tx和check_tx频繁调用的接口优化Vault性能
优化了日志记录流程
优化读写锁功能
以下四种方法没有多大成果。前三种是Tendermint的功能，我们团队对此无所进展。最后一种并不如预期的那样富有成效:
1.检查新交易的过程
Web3PRC服务器的处理功能
ABCIcheck_tx的处理功能
2.将交易传输到验证器以及区块链上的所有节点的传输速度。
ABCI的函数调用功能
3.优化依赖库的性能
使用高性能替代库或接口
调整了库的编译选项
优化交易速度的工具
在确定哪些地方可以提高性能之前，我们使用了两个工具来测试网络性能。大多数优化进来自消除冗余。这两个工具是：
CLI工具用于模拟交易环境的
pprof-rs用于分析ABCI和Findora节点的CPU使用率
我们将详细介绍如何部署以及使用它们。
CLI工具
我们编写了CLI工具来模拟客户端并方便测试。它允许我们进行交易、制作钱包、编写脚本等，并且让我们可以在基本不破坏网络的情况下进行压力测试。
通过Prism将原生FRA转换为智能FRA，并发送到root帐户
Root帐户将FRA发送到多个地址，并保存到文件
并行执行以下操作：
随机生成一批地址，并指定一个endpoint
获取nonce源
生成一个EVM转账交易，并通过send_raw_transaction发送到端点。保存哈希
客户端增加nonce，生成并提交交易，直到所有目标都发送一个交易。
如果交易失败的原因不是“mempoolfull”引起的，则会获得一个新的nonce并重新提交
为了减少服务器没有响应的影响，在nonce的接口中加入了服务弹性的逻辑
为了减少服务器的“mempoolfull”错误和服务器压力，增加了并行等待同步。
Pprof-rs和CPU分析
“CPUProfiling”是指我们用来测试和调优Findora网络性能的工具。我们提出了一个迭代过程，允许我们在不破坏网络的情况下对网络进行压力测试，以查看哪些功能可以优化。
用于进一步研究和找出Findora瓶颈的主要工具是pprof-rs。Pprof-rs是一种流行的测试Rust程序CPU使用率的方法。
如何使用Pprof-rs
我们在abciappcrate中导入了pprof-rs，并启用了火焰图功能。pprof-rs被编译成abcid。有了这个，分析器可以按指定的频率对adcid中的操作上下文进行采样。
在abcid过程中，我们主要使用以下接口进行分析。
1.使用ProfilerGuardBuilder启用分析器，并将频率设置为100。
2.将分析结果保存为火焰图。
3.因为abcid是一个持久进程，所以分析器可以通过以下方法停止:
Pprof-rs的工作原理
分析器将按给定频率暂停程序，并采样程序的堆栈跟踪。采样数据存储在哈希图中。在采样中，分析器扫描每个堆栈帧，并累积存储在哈希图中的计数。
然后，采样数据可用于生成火焰图或其他形式来表示网络性能。
当ProfileGaurdBuilder启动分析器时，它将向SIGPROF注册一个信号处理程序和一个用于暂停主程序的计时器。当触发SIGPRO时，将调用处理程序对堆栈跟踪进行采样。这个过程由backtracecrate来执行。
使用Pprof-rs分析Findora全节点
首先，了解我们的区块链和Tendermint共识引擎的结构是很重要的。
在ETH全节点中，Tendermint进程通过socket与ABCI进程通信。ABCI应用程序默认注册以下接口：
Begin_block
Check_tx
Deliver_tx
End_block
Commit
它还为Web3RPC服务器提供了以下接口，Web3客户端可以通过这些接口执行测试：
eth_sendRawTransaction
https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_sendrawtransaction?
eth_getTransactionCount
https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactioncount?
eth_getTransactionReceipt
https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionreceipt?
该图显示了ETH全节点的基本工作流程。全节点是收集新交易并重放新交易的节点，是所有交易的入口和检查点。通过对全节点的ABCI进行剖析，我们可以获得关于链性能的完整数据。
在分析abcid之前，我们将Tendermint的ABCI并行化为两个线程，而不是单个线程。它允许全节点同时为新交易调用check_tx函数并重播新生成的块。此次升级后，全节点的CPU平均分配。因此，每个区块的交易数量在3000左右，减少了出块时间。
我们还测试了只有一笔交易的区块的时间成本。主要测试函数是：
begin_block
deliver_tx
commit
end_block
除deliver_tx函数外，其他函数仅在一个块中被调用一次。当一个区块中的交易较少时，调用这四个函数的计数很小很小而且很接近。
对于包含很多交易的区块，除了deliver_tx，其他三个函数的时间成本都很小。
根据修改和测试结果，我们得出结论：check_tx和deliver_tx函数占用全节点的大部分CPU。
为了得出这个结论，我们在每个块的开头启动分析器。然后我们保存分析火焰图，并在下一个块之前停止分析器，以免影响全节点的性能。为此，我们使用了两个全局变量：
原子布尔变量用于确定是启动还是停止分析器
一个变量用于存储正在运行的profileGuard
pprof-rs不提供停止分析器的接口。我们通过转移ProfileGuard的所有权来停止分析器并释放数据。
在停止分析器之前，可以将采样数据作为火焰图文件存储在分类帐目录中。
出于测试目的，我们添加了两个RPC。一个用于启用/禁用分析器。
另一个用于检索火焰图文件中生成的分析数据存储。
第1步：开始测试
我们的测试是由使用CLI工具调用feth的脚本来执行的。在选择一个全节点进行测试后，我们通过子命令fund将FRA转移到2000个测试账户：
fethfund—networkhttp://dev-qa01-us-west-2-full-001-open.dev.findora.org:8545?—amount2000—redeposit—load—count2000
然后，我们开始向全节点发送交易。每个帐户的并行度、超时和交易计数都是可配置的。例如
feth—networkhttp://dev-qa01-us-west-2-full-001-open.dev.findora.org:8545?—max-parallelism300—timeout100—count10
第2步：收集测试结果
有四种方法可以收集测试数据并分析它们。
我们可以使用Blockscout手动监控测试结果和块。这个过程让我们可视化块来评估性能。
我们从Web3RPC中获取性能数据。首先，我们可以使用接口eth_getBlockByNumber来获取目标块。然后，我们可以通过交易数组的长度得到实际的交易数。只能从此接口检索有效交易。对于区块时间，我们可以通过相邻块的时间戳之间的差异来计算它。
TendermintRPC：与Web3RPC类似，我们使用curl、jq等工具来检索交易数量和区块时间。这个RPC为我们提供了打包在块中的所有交易的数量。注意：Web3RPC和TendermintRPC有时都会出现“无响应”问题。
Tendermint日志：为了更方便地检索、保存和分析测试数据，我们在feth中使用了子命令etl。有了这个，该命令可以解析fullnode的日志，并将其保存到redis数据库中。如下图所示，出块时间、总交易数、有效交易都可以通过全节点重放出块过程中产生的terdermint日志进行解析。
第3步：分析测试结果
一旦我们得到测试结果，我们就会对结果进行分析或可视化，以便我们可以迭代代码。分析是其中一个步骤，我们可以发现是什么占用了CPU和时间，并寻找优化的方法。
我们在feth中添加了一个启用分析器的子命令。例如：
在下一个块中启用分析器
fethprofiler—networkhttp://dev-qa01-us-west-2-full-001-open.dev.findora.org:8669–enable
生成火焰图并停止分析器
fethprofiler—networkhttp://dev-qa01-us-west-2-full-001-open.dev.findora.org:8669?
这个火焰图展示了一个CPU函数所花费的时长。时间越长，函数就越长，因此通过查看长条图形，我们可以知道哪些过程需要优化。
第4步：重新部署代码?
代码更新后，我们使用Jenkins将其部署到测试环境中。
为优化Findora所做的更改
根据我们的测试，以下是我们已经实施或将要实施的一些更改，以提高Findora的EVM层TPS。
将内存池设置为8k
通过测试，我们发现为了提高全节点的稳定性并确保生成块不会花费太长时间，内存池的最佳大小是8,000。我们希望尽快更新主网上的内存池。
并行TendermintABCI
并行化TendermintABCI以便可以同时执行check_yx和Deliver_tx，这是我们发现的另一个可改进之处。这也有助于防止堵塞时间过长。但这并不能显著提高TPS，因为交易是均匀分布的。
减少序列化/反序列化
通过结合SDK中打包的帐户中的一些函数来减少数据库读取和反序列化。
通过这种优化，TPS提高了大约10txn/s。
删除不必要的检查
函数check_tx和Deliver_tx使用相同的逻辑来处理交易，唯一的区别在于上下文。但是对于check_tx函数，它不需要PendingTransactions、emit、events等逻辑。因此，我们可以通过上下文将这两个函数分开。TPS已提高到79.2txn/s。
重构SessionCache
在之前的执行中，cur和base之间用了大量的内存copy/allocation.deallocation来执行一个交易。
通过减少这些操作的次数，TPS达到了149txn/s。
避免打印冗余日志
我们删除了数百个不必要的日志。这些日志可以重新打印用于调试，但不会在主网上自动打印。
未来优化点
根据火焰图，我们在未来还可以做两件事。
Recover_signer函数
secp256k1_ecdsa_recover函数在recover_signer函数中占用了大量时间。这个secp256k1_ecdsa_recover函数的核心部分是libsecp256k1:recover，它的crate接口花费的时间最多。
我们可以考虑优化这个库，用另一个高性能库替换它，或者减少调用。
适用于EVM的Findora后端
这部分占据了整个交易过程的很大一部分，但是我们仍然找不到优化的地方。未来我们可能需要对这部分进行更多的测试和分析。
结论
提高TPS是一个迭代过程，我们一直在寻找新的方法来扩容。虽然我们想要保持竞争力，但我们更愿意相信在Web3中合作才能使整个行业强大。因此，我们很乐意分享我们的优化过程，以帮助其他团队，并获得建设性的反馈。希望此次分享可以帮助到EVM环境中的其他团队，以便他们提高自己的TPS。
来源：金色财经
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。