Paralle EVM 最直接的优势是让现有的去中心化应用，实现互联网级别的性能。Parallel EVM 既能利用大量成熟的现有智能合约的同时，还能实现高性能、并行化公链吞吐量的新技术。
- 押注资本：Paradigm、Jump、Dragonfly 等。
- 代表项目：Monad、Sei、MegaETH、Polygon、Neon EVM、BSC 等。
- 技术难点：除了要对整个技术栈重构之外，还有如何提前预判并行的交易是否会冲突，以及遇到冲突后的重新执行效率。
- 架构挑战：如何在开源生态构建差异性、如何在去中心化和性能之间找到平衡。
EVM交易执行机制
EVM中交易的执行实际上是状态的转换，交易执行前的状态 σt和Transaction作为EVM的输入，输出为交易执行后的状态σt+1为输出。
不过每个交易执行前的状态 σt 和执行后的状态 σt+1 都是“世界状态”，也就是整个账本所有账户的实时状态（如Balance、Nonce、StorageRoot等），这种账户模型在一定程度上方便了实际应用的开发，但由于每笔交易的执行都需要依赖一个确定的“世界状态”，这也给可扩展性带来诸多限制，正是因为这一点，EVM-based链鲜有通过并行执行交易提升TPS的案例。
并行执行的挑战
基于这种账户模型，想要通过并行执行重复利用节点的硬件资源提高网络吞吐量是很困难的。例如：
“状态冲突”(State conflicts)：A转账给B的交易tx1和C转账给D的交易tx2在理论上是可以并行执行的，因为两个交易没有任何关联，但如果将tx2调整为B转账给C时，假如最初B的余额是0，会发现，tx1没有执行前tx2注定会失败，因为B此时的状态是余额不足。
只做转账的交易，是可以通过静态分析来确定交易彼此的依赖关系的，事实上，DApp开发者们经常通过复杂的智能合约逻辑在EVM虚机中实现某些特殊的业务需求，在一个智能合约交易中，EVM会根据合约的Code逻辑执行用户千奇百怪的操作，这就不能通过简单的对交易内容分析来确定交易间的依赖关系了。
乐观执行
既然不能事先分析交易的关联关系， 是否可以先乐观的将交易全部独立执行，然后再事后分析呢？
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）可以有效的解析这种依赖关系。
相关项目
主打「并行 EVM」（Parallel EVM）的 Monad
赛道：Layer1
创始人：Keone Hon – 前做市巨头 Jump Trading 的研究负责人
资方：2023 年 2 月，Monad 宣布完成了 1900 万美元融资，Dragonfly Capital 领投， Placeholder Capital、Lemniscap、Shima Capital、Finality Capital、Naval Ravikant、Cobie、Hasu 等参投。
一些观点：
「并行 EVM」本质上是对 EVM 环境下交易执行顺序的改革。
- 愿景：通过「并行处理」的方式在 Layer1 单层大规模改进 EVM 的执行效率，进而释放 EVM 生态系统的潜力。
- 看法：Keone，得益于以太坊充分的用户教育，EVM 几乎已成为 Web2 世界中 Javascript 那般的「标配」选择，然而当前以太坊所走的扩容路径却存在一定的问题，Layer1 + Layer2 的分层策略会造成区块链被划分成独立的执行环境，从而破坏链上的可组合性，因此需要构建一个性能更高的底层网络。
- 预估：Monad 的性能可达到以太坊的 1000 倍以上。
并行EVM新叙事
赛道：专注于交易的Layer1
创始人：Jeff Feng – 前高盛TMT投资银行部门） ；Jayendra Jog – 前Robinhood软件工程师。
资方：2022 年 8 月，Sei Network 背后的团队 Sei Labs 完成 500 万美元种子轮融资， Multicoin Capital 领投， Coinbase Ventures、 GSR 等参投。2023 年 2 月，Sei 宣布正在以 4 亿美元进行 A 轮融资。4 月，Sei Network 宣布以 8 亿美元估值完成 3000 万美元融资， Jump Capital、 Distributed Global、Multicoin Capital、 Bixin Ventures 等参投，本轮资金被用于开发与亚太地区市场推广。同月，Sei Labs 生态基金完成 5000 万美元新一轮融资， 包括OKX Ventures、Foresight Ventures等。
一些观点：
- Sei V2支持 EVM 并不意味着放弃 WASM，计划同时支持这两个虚拟机；
解决方案：
2024 将会是“并行 EVM 之年”
- 智能区块传播
- 在 Sei 中，区块提议者在区块提案中不包含交易数据，而是交易的哈希值，以及 区块 ID，它是对区块的引用。交易的哈希值是对现有交易数据进行汇总的哈希函数，因此具有体积小的优点。区块提议者首先将区块提议传播到网络，如下图所示，然后将完整的区块分成小块传播。如果从区块提议者接收到区块提议的验证者已经在其本地内存池中拥有与该哈希值相对应的所有交易，那么他们将从本地内存池中重建该区块，而不是等待完整的区块到达它们。如果某个特定验证器在其本地内存池中丢失了一笔交易（概率非常小），那么它可以等待整个区块到达它。
- 乐观区块处理
- Sei 使用 Tendermint 核心，但进行了一些修改，以显着减少出块时间并提高可扩展性。Tendermint 核心是一个共识引擎，结合了委托权益证明 (DPoS) 和 PBFT 共识算法。Tendermint BFT 共识流程为：Propose — — Prevote（2/3共识） — — Precommit（2/3共识） — — Commit
- Sei 的 Optimistic Block Processing 将 Tendermint BFT 流程修改，在 BFT 的一般流程中 Precommit 和 Commit 之间有一个块处理过程，假设恶意节点很少，验证者已经从 Prevote 阶段收到了在 Propose 阶段计算所需的数据。因此，为了进一步减少出块时间，Sei 开始与 Prevote 并行处理计算。通过乐观块处理减少块时间应该不是问题，因为大多数时候块的有效性没有问题，但如果在执行计算时的预投票和预提交过程中块被网络拒绝，可以简单地丢弃。
- 事务并行化处理
- Sei 所基于的 Cosmos SDK 也以串行方式处理交易。在 Cosmos 应用链中，当收到区块时，验证器按顺序执行 BeginBlock 逻辑、DeliverTx 和 EndBlock 逻辑，而 Sei 则修改 DeliverTx 和 EndBlock 以并行处理交易。首先，DeliverTx 流程处理代币转移、治理提案和智能合约调用等交易，重要的是要确保并行处理的交易不会引用相同的密钥。例如，A向B发送X代币和C向D发送Y代币的两笔交易可以并行处理，但A向B发送X代币和B向C发送X代币的两笔交易不能并行处理，因此它们将被连续处理。为了并行化多个事务，需要确保它们不引用相同的键，为此，Sei 构建了一个 DAG（有向无环图）来在执行事务之前检查事务之间的依赖关系。在下图中，假设 DAG 显示中间的 R 3 依赖于第一列中的 R 2 ，第三列中的 R 3 依赖于中间的 W 1 。结果，交易将如右图所示进行处理。
- 在区块的最后一部分EndBlock中，与撮合引擎相关的交易由原生订单撮合引擎执行。同样，与匹配引擎相关的交易不是按串行顺序处理的，而是在确认它们彼此不相关后并行处理。
一些要思考的问题
- EVM架构适合并行执行吗？
- 不能以牺牲安全性和去中心化程度为代价。
- 根据Ilya Sergey 在 EVM 技术架构基础上对并行执行研究的结论，对于非垃圾回收类语言，对象在内存中的重复声明和使用过程必然会违反状态完整性，这给形式化验证智能合约带来巨大的挑战。
- 公链适合处理海量的交易吗？
- 不是任何交易都需要上链的。
- 过度依赖硬件资源将使网络去中心化程度降低
EVM链和并行执行交易
解析 Monad：Layer1 赛道的潜在颠覆
全面解读公链Sei：并行EVM新叙事叠加积极运营
To be continued.
Li Yingxuan 
留下评论