概述
在web3.0世界中，交易的处理性能一直是公链面临的一大技术挑战，如何在不降低安全性和去中心化程度的前提下显著地提升区块链交易的TPS无疑成为众多公链技术专家追逐的目标。以Solana、Aptos为代表的新一代公链的出现更是吹响了通过并行执行交易来攻克公链可扩展性瓶颈的号角。
以太坊虚拟机因其最早在区块链中引入智能合约，不仅拥有最多的DApp开发者，更有众多新生公链直接将EVM采用作为其智能合约交易执行引擎，其在web3.0中的受欢迎程度可见一斑，然而受限于顺序执行，EVM无疑在扩展性方面广受诟病。
是否也可以既做到对EVM的兼容，又可以通过并行执行交易来达到提升性能的目的呢？今天我们就来对这个话题做一些探讨。
EVM交易执行机制
众所周知，EVM中交易的执行实际上是状态的转换，交易执行前的状态σt和交易transaction作为EVM的输入，输出为交易执行后的状态σt+1:
Web3社区构建平台Galxe集成LayerZero:金色财经报道，Web3社区构建平台Galxe在社交媒体表示，全链互操作协议LayerZero已经整合Galxe，3个合作伙伴将通过在Galxe上开展活动。[2023/8/13 16:23:13]
要说明的是，每个交易执行前的状态σt和执行后的状态σt+1都是‘世界状态’，也就是整个账本所有账户的实时状态，这种账户模型在一定程度上方便了实际应用的开发，但由于每笔交易的执行都需要依赖一个确定的‘世界状态’，这也给可扩展性带来诸多限制。正是因为这一点，EVM-based链鲜有通过并行执行交易提升TPS的案例。
Bybit上线BTC和ETH USDC结算期货合约:3月22日消息，据官方公告，Bybit宣布上线USDC期货合约。BTC和ETH USDC结算期货合约现在可以在Bybit Web和API上进行交易，并将很快上线Bybit App（4.14.0版本）。[2023/3/22 13:19:49]
并行执行的挑战
基于这种账户模型，想要通过并行执行重复利用节点的硬件资源提高网络吞吐量是很困难的。
举个简单的例子：A转账给B的交易tx1和C转账给D的交易tx2在理论上是可以并行执行的，因为两个交易没有任何关联，但如果将tx2调整为B转账给C情况会是怎么样呢？假如最初B的余额是0，tx1中A转给B5个Token，tx2中B转给C3个Token，我们会发现，tx1没有执行前tx2注定会失败，因为B此时的状态是余额不足。这种情况在链上被称为’状态冲突‘(Stateconflicts)。
破产法官：Celsius应在3月底之前继续拥有制定退出破产计划的专有权:金色财经报道，破产法庭法官Martin Glenn周三裁定，Celsius Network 应在 3 月底之前继续拥有制定退出破产计划的专有权。Glenn法官表示，在准备与新公司 NovaWulf 建立新的回收公司的交易方面取得了足够的进展。纽约南区法院被告知，同意这项交易可能意味着该加密货币贷款机构在6月底前退出破产保护。
Glenn表示，我将批准所请求的独家经营权延期。Celsius 已经能够填写交易的细节，并且不会在此期间消耗客户资金，该计划将提交给债权人以供批准。截至周二，已经有1770万美元从托管账户中提取，还有350万美元正在提取中，占合格用户的60%，按价值计算占80%。[2023/3/9 12:50:27]
当然，对于只做转账的交易，是可以通过静态分析来确定交易彼此的依赖关系的，事实上，DApp开发者们经常通过复杂的智能合约逻辑在EVM虚拟机中实现某些特殊的业务需求，在一个智能合约交易中，EVM会根据合约的Code逻辑执行用户千奇百怪的操作，这就不能通过简单的对交易内容分析来确定交易间的依赖关系了。
Celsius地址向Aave协议偿还3000万枚USDC:7 月 11 日消息，据欧科云链链上天眼监测显示，北京时间19:09:48被OKLink ETH浏览器标记为 Celsius Network 的钱包地址（0x8ace开头）向 Aave 协议偿还3,000万枚USDC。[2022/7/11 2:05:20]
可尝试的改进
Solidity被称为图灵完备的智能合约语言，通过对交易指令集的静态分析来确定交易依赖关系的可行性基本是不存在的，但这并不意味着我们只能按顺序执行，我们可以从近期一些优秀的区块链项目中得到更多启发。
Immutable X宣布更新品牌:6月17日消息，Immutable X宣布更新品牌，其使命是与StarkWare合作，通过Immutable X和Immutable Games Studio推动下一代Web3游戏发展，使数字世界成为现实。Immutable已经发布新品牌Logo和全新网站。[2022/6/17 4:34:38]
乐观执行是一种可尝试的方案
既然不能事先分析交易的关联关系，那我们是否可以先乐观的将交易全部独立执行，然后再事后分析呢？
Aptos项目的PE(parallelexecution)方案便是这种思路的代表，根据项目方公布的数据，在低关联交易集合的场景，交易的执行效率最高可以是串行执行的16倍之多。
EVM中虽然没有类似Block-STM的机制，但我们完全可以通过对区块中交易的执行逻辑稍加优化就可以做到既和EVM保持兼容，又能支持将明显无关的交易分成不同批次进行支持，即：
可以先根据交易发送方和接受方账户地址将交易依赖关系构建成可逐批执行的交易集合，乐观的在不同的线程中独立执行，等所有交易都被执行完以后，再将执行过程中使用的读集和写集做对比分析，检查交易序号靠后的交易的读集是否与交易序号靠前的所有交易写集有交集，如果没有，说明执行结果是正确的，否则意味着该交易需要依赖之前交易的最新状态，需要根据前面交易的结果重新执行。
由用户指定交易的读写集
普通的转账交易可以简单的通过from和to确定交易彼此的依赖关系，而智能合约交易虽然在EVM执行它之前不能确定其对哪些账户有依赖，但发送交易的用户多数情况下是可以确定交易的读写集的，而Sui项目正是将交易的依赖和结果完全交由用户来指定并最终签名确定，这将极大的简化了分析交易关联性的逻辑。
然而EVM现在并没有这种机制，虽然Vitalik和Holiman提交的关于指定交易访问lists的提案(EIPs/eip-2930.mdatmaster·ethereum/EIPs·GitHub)已经在以太坊上通过并实施，但该提案并没有强制要求用户必须指定所有的accesslists，如果要在EVM中实现用户指定读写集，需要在以太坊提交新的EIP提案，除此之外，用户确定读写集还需要SDK的支持。
通过DAG构建交易的依赖关系
对于单纯的转账交易或是上面提到的由用户指定了读集的交易，是完全可以事先确定交易的依赖关系的，有向无环图可以有效的解析这种依赖关系。
关于如何使用DAG分批并行执行交易的内容可以参见我们之前的技术文章。
一些要思考的问题
EVM架构适合并行执行吗？
虽然并行执行可以做到有效利用硬件资源，提升链处理交易的能力，但正如我们在开头提到的这绝不能以牺牲安全性和去中心化程度为代价，IlyaSergey就曾经在EVM技术架构基础上对并行执行做过深入的研究，根据其研究的结论，对于非垃圾回收类语言，对象在内存中的重复声明和使用过程必然会违反状态完整性，这给形式化验证智能合约带来巨大的挑战。这或许是EVM设计者在最初的设计中没有考虑到的问题。
公链适合处理海量的交易吗？
公链是公众基础设施，其用户可以是任何人或团体，不可否认的是它处理能力越强越好，然而这并不意味着任何交易都需要上链，虽然gas机制可以减少垃圾数据上链的可能性，但随着节点处理交易能力的提升，矿工为了增加收入必然会打包尽可能多的交易，这将必然使gas价格越来越低，链上将不可避免的充斥着大量垃圾数据，这将使账本数据越来越膨胀，到难以维护的程度。
过度依赖硬件资源将使网络去中心化程度降低
通过提升CPU核心数可以做到高交易处理性能，增加磁盘容量可以存储更多数据，这将不断提升节点的运行维护成本，最终导致的结果必然是只有少数人或团体有能力支付这些成本，不利于去中心化。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。