📢 Gate广场 #创作者活动第一期# 火热开启,助力 PUMP 公募上线!
Solana 爆火项目 Pump.Fun($PUMP)现已登陆 Gate 平台开启公开发售!
参与 Gate广场创作者活动,释放内容力量,赢取奖励!
📅 活动时间:7月11日 18:00 - 7月15日 22:00(UTC+8)
🎁 活动总奖池:$500 USDT 等值代币奖励
✅ 活动一:创作广场贴文,赢取优质内容奖励
📅 活动时间:2025年7月12日 22:00 - 7月15日 22:00(UTC+8)
📌 参与方式:在 Gate 广场发布与 PUMP 项目相关的原创贴文
内容不少于 100 字
必须带上话题标签: #创作者活动第一期# #PumpFun#
🏆 奖励设置:
一等奖(1名):$100
二等奖(2名):$50
三等奖(10名):$10
📋 评选维度:Gate平台相关性、内容质量、互动量(点赞+评论)等综合指标;参与认购的截图的截图、经验分享优先;
✅ 活动二:发推同步传播,赢传播力奖励
📌 参与方式:在 X(推特)上发布与 PUMP 项目相关内容
内容不少于 100 字
使用标签: #PumpFun # Gate
发布后填写登记表登记回链 👉 https://www.gate.com/questionnaire/6874
🏆 奖励设置:传播影响力前 10 名用户,瓜分 $2
EVM并行化优化:以Reddio为例提升交易处理效率
EVM的并行优化之路
众所周知,EVM是以太坊的核心执行引擎和智能合约运行环境。作为一个包含大量节点的开放网络,公链面临着如何在硬件参数差异巨大的设备上实现一致性执行的挑战。虚拟机技术为解决这一问题提供了可能,使智能合约能够在不同操作系统和设备上以相同方式运行,确保结果的一致性。
智能合约在上链前会被编译为EVM字节码。EVM执行合约时按顺序读取这些字节码,每条指令都有相应的Gas成本。EVM会追踪每条指令执行过程中的Gas消耗,消耗量取决于操作的复杂度。
传统上,EVM采用串行方式处理交易,所有交易在单一队列中排队并按确定顺序执行。这种设计简单易维护,但随着区块链技术的发展和用户群的扩大,对TPS和吞吐量的要求不断提高。在Rollup技术成熟后,EVM串行执行的性能瓶颈在以太坊二层网络中变得尤为明显。
Sequencer作为Layer2的关键组件,以单个服务器形式承担所有计算任务。如果配套模块效率足够高,最终瓶颈将取决于Sequencer本身的效率,此时串行执行将成为重大障碍。因此,交易处理的并行化成为未来的必然趋势。
以太坊交易执行的核心组件
除EVM外,go-ethereum中与交易执行相关的另一核心组件是stateDB,用于管理以太坊中的账户状态和数据存储。以太坊使用Merkle Patricia Trie树状结构作为数据库索引。每次交易执行都会改变stateDB中的某些数据,这些变更最终反映在全局状态树中。
stateDB负责维护所有以太坊账户的状态,包括EOA账户和合约账户,存储账户余额、智能合约代码等数据。交易执行过程中,stateDB对相应账户数据进行读写。交易执行结束后,stateDB将新状态提交到底层数据库中进行持久化。
总的来说,EVM负责解释和执行智能合约指令,根据计算结果变更区块链状态,而stateDB作为全局状态存储,管理所有账户和合约的状态变化。两者协作构建了以太坊的交易执行环境。
串行执行的具体过程
以太坊的交易分为EOA转账和合约交易两种类型。EOA转账是最简单的交易类型,即普通账户间的ETH转账,不涉及合约调用,处理速度快,gas费低。
合约交易涉及智能合约的调用与执行。EVM处理合约交易时,需逐条解释和执行智能合约中的字节码指令。合约逻辑越复杂,涉及的指令越多,消耗的资源也越多。
例如,ERC-20转账的处理时间约为EOA转账的2倍,而更复杂的智能合约,如Uniswap上的交易操作,耗时可能是EOA转账的十几倍。这是因为DeFi协议在交易时需要处理流动性池、价格计算、代币swap等复杂逻辑,需要进行大量计算。
在串行执行模式下,EVM与stateDB的协作过程如下:
这种串行执行模式的瓶颈明显:交易必须按顺序排队执行,如遇到耗时较长的智能合约交易,其他交易只能等待,无法充分利用硬件资源,效率受到较大限制。
EVM的多线程并行优化方案
并行执行模式可以开启多个线程同时处理多笔交易,效率可提升数倍,但面临状态冲突问题。当多笔交易同时声明要改写某个账户的数据时,就会产生冲突,需要进行协调处理。
并行优化原理
以ZKRollup项目Reddio的并行优化思路为例,其主要特点包括:
多线程并行执行交易:设置多个线程同时处理不同交易,线程间互不干扰,可数倍提升交易处理速度。
为每个线程分配临时状态数据库:每个线程都有独立的临时状态数据库(pending-stateDB)。交易执行时,状态变化结果暂时记录在pending-stateDB中,不直接修改全局stateDB。
同步状态变更:区块内所有交易执行完毕后,将每个pending-stateDB中记录的状态变更结果依次同步到全局stateDB中。
Reddio对读写操作的处理进行了优化:
读操作:首先检查Pending-state的ReadSet。如存在所需数据,直接从pending-stateDB中读取;否则从上一个区块对应的全局stateDB中读取历史状态数据。
写操作:所有写操作先记录到Pending-state的WriteSet中,待交易执行完成后,通过冲突检测再尝试将状态变更结果合并到全局stateDB中。
为解决状态冲突问题,Reddio引入了冲突检测机制:
冲突检测:监测不同交易的ReadSet和WriteSet,如发现多个交易尝试读写相同状态项,视为发生冲突。
冲突处理:冲突交易被标记为需要重新执行。
所有交易执行完成后,多个pending-stateDB中的变更记录合并到全局stateDB中。合并成功后,最终状态提交到全局状态树中,生成新的状态根。
多线程并行优化显著提升了性能,特别是在处理复杂智能合约交易时。研究显示,在低冲突工作负载中,基准测试的TPS比传统串行执行提升了3~5倍。在高冲突工作负载中,理论上如果采用所有优化手段,甚至可达到60倍提升。
总结
Reddio的EVM多线程并行优化方案通过为每个交易分配临时状态库,并在不同线程中并行执行交易,显著提高了EVM的交易处理能力。通过优化读写操作和引入冲突检测机制,EVM系公链能在保证状态一致性的前提下实现交易的大规模并行化,解决了传统串行执行模式的性能瓶颈。这为以太坊Rollup的未来发展奠定了重要基础。
后续可进一步探讨Reddio的实现细节,包括如何进一步优化存储效率,高冲突情况下的优化方案,以及如何借助GPU进行优化等内容。