关于虚拟机:密码学探秘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 转给 B5 个 Token，tx2 中 B 转给 C3 个 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 曾经在以太坊上通过并施行，但该提案并没有强制要求用户必须指定所有的 access lists，如果要在 EVM 中实现用户指定读写集，须要在以太坊提交新的 EIP 提案，除此之外，用户确定读写集还须要 SDK 的反对。

通过 DAG 构建交易的依赖关系

对于单纯的转账交易或是下面提到的由用户指定了读集的交易，是齐全能够当时确定交易的依赖关系的，有向无环图（Directed Acyclic Graph）能够无效的解析这种依赖关系。对于如何应用 DAG 分批并行执行交易的内容能够参见咱们之前的技术文章。

一些要思考的问题

• EVM 架构适宜并行执行吗？

尽管并行执行能够做到无效利用硬件资源，晋升链解决交易的能力，但正如咱们在结尾提到的这绝不能以就义安全性和去中心化水平为代价，Ilya Sergey 就已经在 EVM 技术架构根底上对并行执行做过深刻的钻研，依据其钻研的论断，对于非垃圾回收类语言，对象在内存中的反复申明和应用过程必然会违反状态完整性，这给形式化验证智能合约带来微小的挑战。这或者是 EVM 设计者在最后的设计中没有思考到的问题。

• 公链适宜解决海量的交易吗？

公链是公众基础设施，其用户能够是任何人或个人，不可否认的是它解决能力越强越好，然而这并不意味着任何交易都须要上链，尽管 gas 机制能够缩小垃圾数据上链的可能性，但随着节点解决交易能力的晋升，矿工为了增加收入必然会打包尽可能多的交易，这将必然使 gas 价格越来越低，链上将不可避免的充斥着大量垃圾数据，这将使账本数据越来越收缩，到难以保护的水平。

• 适度依赖硬件资源将使网络去中心化水平升高

通过晋升 CPU 外围数能够做到高交易解决性能，减少磁盘容量能够存储更多数据，这将一直晋升节点的运行保护老本，最终导致的后果必然是只有多数人或个人有能力领取这些老本，不利于去中心化。