密码学探秘EVM链和并行执行交易

　　概述
　　在web3.0世界中，交易的处理性能一直是公链面临的一大技术挑战，如何在不降低安全性和去中心化程度的前提下显著的提升区块链交易的TPS无疑成为众多公链技术专家追逐的目标。以Solana、Aptos为代表的新一代公链的出现更是吹响了通过并行执行交易来攻克公链可扩展性瓶颈的号角。
　　以太坊虚拟机因其最早在区块链中引入智能合约，不仅拥有最多的DApp开发者，更有众多新生公链直接将EVM采用作为其智能合约交易执行引擎，其在web3.0中的受欢迎程度可见一斑，然而受限于顺序执行（Sequential Execution）EVM无疑在扩展性方面广受诟病。
　　是否也可以既做到对EVM的兼容，又可以通过并行执行交易来达到提升性能的目的呢？今天我们就来对这个话题做一些探讨。 EVM交易执行机制
　　众所周知，EVM中交易的执行实际上是状态的转换，交易执行前的状态 σt和交易transaction作为EVM的输入，输出为交易执行后的状态σt+1为输出:
　　要说明的是，每个交易执行前的状态 σt 和执行后的状态 σt+1 都是‘世界状态’，也就是整个账本所有账户的实时状态（如balance、nonce、storageroot等），这种账户模型在一定程度上方便了实际应用的开发，但由于每笔交易的执行都需要依赖一个 确定 的’世界状态‘，这也给可扩展性带来诸多限制，正是因为这一点，EVM-based链鲜有通过并行执行交易提升TPS的案例。 并行执行的挑战
　　基于这种账户模型，想要通过并行执行重复利用节点的硬件资源提高网络吞吐量是很困难的。举个简单的例子： A  转账给B  的交易tx1  和C  转账给D  的交易tx2  在理论上是可以并行执行的，因为两个交易没有任何关联，但如果将tx2  调整为B  转账给C  情况会是怎么样呢？假如最初B  的余额是0，tx1  中A  转给B  5个Token，tx2  中B  转给C  3个Token，我们会发现，tx1  没有执行前tx2  注定会失败，因为B  此时的状态是余额不足。这种情况在链上被称为’状态冲突 ‘(State conflicts)
　　当然，对于只做转账的交易，是可以通过静态分析来确定交易彼此的依赖关系的，事实上，DApp开发者们经常通过复杂的智能合约逻辑在EVM虚机中实现某些特殊的业务需求，在一个智能合约交易中，EVM会根据合约的Code逻辑执行用户千奇百怪的操作，这就不能通过简单的对交易内容分析来确定交易间的依赖关系了。
　　可尝试的改进
　　Solidity被称为图灵完备的智能合约语言，通过对交易指令集的静态分析来确定交易依赖关系的可行性基本是不存在的，但这并不意味着我们只能按顺序执行，我们可以从近期一些优秀的区块链项目中得到更多启发。 乐观执行是一种可尝试的方案
　　既然不能事先分析交易的关联关系， 那我们是否可以先乐观的将交易全部独立执行，然后再事后分析呢？
　　Aptos项目的PE(parallel execution) 方案便是这种思路的代表，根据项目方公布的数据，在低关联交易集合的场景（low inter-dependence），交易的执行效率最高可以是串行执行的16倍之多。
　　EVM中虽然没有类似Block-STM的机制，但我们完全可以通过对区块中交易的执行逻辑稍加优化就可以做到既和EVM保持兼容，又能支持将明显无关的交易分成不同批次进行支持，即：可以先根据交易发送方和接受方账户地址将交易依赖关系构建成可逐批执行的交易集合，乐观的在不同的线程（或协程）中独立执行，等所有交易都被执行完以后，再将执行过程中使用的读集（所有用到的状态变量）和写集（所有由交易产生的需要记录到链上的结果）做对比分析，检查交易序号（区块中的交易顺序编号）靠后的交易的读集是否与交易序号靠前的所有交易写集有交集，如果没有，说明执行结果是正确的， 否则意味着该交易需要依赖之前交易的最新状态， 需要根据前面交易的结果重新执行。
　　由用户指定交易的读写集
　　普通的转账交易可以简单的通过 from 和 to 确定交易彼此的依赖关系，而智能合约交易虽然在EVM执行它之前不能确定其对哪些账户有依赖，但发送交易的用户多数情况下是可以确定交易的读写集的，而Sui项目正是将交易的依赖和结果完全交由用户来指定并最终签名确定，这将极大的简化了分析交易关联性的逻辑。
　　然而EVM现在并没有这种机制，虽然 Vitalik 和 Holiman 提交的关于指定交易访问lists的提案 [EIP-2930](EIPs/eip-2930.md at master · ethereum/EIPs · GitHub) 已经在以太坊上通过并实施，但该提案并没有强制要求用户必须指定所有的access lists， 如果要在EVM中实现用户指定读写集，需要在以太坊提交新的EIP提案，除此之外，用户确定读写集还需要SDK的支持。 通过DAG构建交易的依赖关系
　　对于单纯的转账交易或是上面提到的由用户指定了读集的交易，是完全可以事先确定交易的依赖关系的，有向无环图（Directed Acyclic Graph）可以有效的解析这种依赖关系。
　　关于如何使用DAG分批并行执行交易的内容可以参见我们之前的技术文章。 一些要思考的问题EVM 架构适合并行执行吗？
　　虽然并行执行可以做到有效利用硬件资源，提升链处理交易的能力，但正如我们在开头提到的这绝不能以牺牲安全性和去中心化程度为代价，Ilya Sergey 就曾经在 EVM 技术架构基础上对并行执行做过深入的研究，根据其研究的结论，对于非垃圾回收类语言，对象在内存中的重复声明和使用过程必然会违反状态完整性，这给形式化验证智能合约带来巨大的挑战。这或许是 EVM 设计者在最初的设计中没有考虑到的问题。 公链适合处理海量的交易吗？
　　公链是公众基础设施，其用户可以是任何人或团体，不可否认的是它处理能力越强越好， 然而这并不意味着任何交易都需要上链，虽然 gas 机制可以减少垃圾数据上链的可能性，但随着节点处理交易能力的提升， 矿工为了增加收入必然会打包尽可能多的交易，这将必然使gas价格越来越低，链上将不可避免的充斥着大量垃圾数据，这将使账本数据越来越膨胀，到难以维护的程度。 过度依赖硬件资源将使网络去中心化程度降低
　　通过提升CPU核心数可以做到高交易处理性能，增加磁盘容量可以存储更多数据，这将不断提升节点的运行维护成本，最终导致的结果必然是只有少数人或团体有能力支付这些成本，不利于去中心化。