本文详细介绍了Solana中的交易处理单元(TPU)的设计和工作原理,分析了在网络拥堵期间TPU性能下降的原因,并探讨了如何通过去重和过滤冗余数据来提高交易处理效率。文章对TPU的三个主要处理阶段进行详尽讲解,包含大量示意图和代码示例,使读者能够深入理解Solana事务处理的内部机制。
最近,Solana 由于网络拥堵经历了严重的性能下降。TPS(每秒处理的交易数量)在几个小时内下降了几个数量级(从数千降到几十)。
从技术上讲,这个问题是由于 Solana 的性能缺陷引起的,特别是——交易处理单元(TPU)。在市场波动期间,机器人大量发送重复的垃圾交易,这使得 TPU 负担沉重。
本文详细阐述了 TPU 的设计,并突出了一些复杂细节。
当用户提交一个交易时,它包含了一个编译好的指令序列的表示,称为 “message”:
message 必须被签名,由一个或多个密钥对签名:
签名的签名也包含在交易中,并与消息内容一起通过 RPCRequest 发送到 Solana 集群:
在接收到交易后,TPU 有三个主要阶段来处理它。
这三个阶段都由不同的线程执行,通过消息传递的方式进行通信,使用 crossbeam_channel(一个多生产者多消费者的通道)。
TPU 创建了一个无界容量的通道(packet_sender,packet_receiver):
fetch_stage 读取交易套接字上的数据包,并通过 packet_sender 将其简单地转发给 sigverify_stage。
sigverify_stage 从 packet_receiver 接收交易数据包,并使用 TransactionSigVerifier 验证每个数据包中的签名是否有效。
它假设每个数据包只包含一个交易,且这些数据包通过所有可用的 CPU 核心并行进行验证(也可以在可用时使用 GPU)。
注意,TPU 创建了另一个通道(verified_sender,verified_receiver),并通过 verified_sender 将验证通过的交易转发给下一个阶段(banking_stage)。
它不仅验证签名,还会过滤出冗余的数据包,并丢弃过量的数据包以提高性能。对此次性能下降的修复是在这个组件中实现的。
它包含三个步骤:
discard_excess_packets 函数定义如下:
ed25519_dalek::PublicKey.verify 函数定义如下:
它接受签名和消息作为输入,并使用密钥对的公钥验证该签名与消息的关系。
注意 ed25519_dalek::PublicKey.verify 函数是非平凡且微妙的,它是 未审计的 。
banking_stage 创建了一个线程,该线程在循环中执行以批量处理接收到的交易。每批交易的数量受限于
banking_stage 使用一个重要组件称为 bank 来加载和执行交易。该函数定义如下:
对于每个交易,bank 使用 MessageProcessor 来处理交易消息:
该方法在已加载的账户集上调用消息中的每个指令。
对于每个指令,它调用程序的 entrypoint,并验证调用的结果是否违反了 bank 的会计规则。
在内部,bank 创建一个 InvokeContext 来执行每个指令:
每个交易有一个有限的计算预算(默认是 200_000 单位),在 ComputeBudget 中定义:
bank 执行指令会涉及许多复杂情况,例如
我们将在下一篇文章中详细讲解这些细节以及 bank 的生命周期。
sec3 是一家安全研究公司,旨在为数百万用户准备 Solana 项目。sec3 的 Launch Audit 是一种严格的研究人员主导的代码审查,调查并认证主网级智能合约;sec3 的连续审计软件平台 X-ray 与 GitHub 集成,逐步扫描拉取请求,帮助项目在部署前加固代码;sec3 的部署后安全解决方案 WatchTower 确保资金安全。sec3 正在为 Web3 项目构建基于技术的可扩展解决方案,以确保协议在扩展时保持安全。
要了解更多有关 sec3 的信息,请访问 https://www.sec3.dev
- 原文链接: sec3.dev/blog/solana-int...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!