公链的机制与挑战：AptosSuiLinera 和 Fuel

当我们审视整个区块链技术发展时，我们可以看到一个非常大的趋势，即新的 L1 更注重并行执行的能力。这个做法并不新鲜，比如在 Solana 的 Sealevel 执行环境就采用了并行执行，在过去的牛市当中，伴随着 DeFi 和 NFT 迅猛地发展，表明了这种改进的迫切性。当前采用并行执行理念的知名项目主要有 Aptos, Sui, Linera 和 Fuel。

本文将会讨论了这些项目的异同之处，以及它们所面临的各种挑战。

问题

智能合约平台支持创建各类去中心化的应用程序，为了执行这些应用程序，需要一个共享的计算引擎。公链网络中的每个节点都会运行这个计算引擎，并执行应用程序和用户的交互，当节点从执行后获得相同的结果时，它们就会达成共识并推进上链。

以太坊虚拟机是最主要的智能合约 (SC) 执行引擎，拥有大约 20 种不同的实现方式。自 EVM 创建以来，它已经被开发人员广泛采用。除了以太坊和以太坊的 L2 外，其他几个链包括 Polygon、BNB Smart Chain 和 Avalanche c Chain 都采用了 EVM 作为执行引擎，并专注于改变共识机制来提高网络吞吐量。

EVM 的一个主要限制因素是事务的顺序执行。EVM 本质上是一次执行一个事务，执行时会将其他事务置于暂停状态，直到此事务执行完成，并更新区块链状态。即使两个交易是独立的，例如，Alice 给 Bob 付款和 Carol 给 Dave 付款两个事务，EVM 不能并行执行这两笔交易。即使这种执行模型也有一些其他的用例，例如闪电贷款，但它既不高效，也无法扩展。

Aptos

Aptos 是一条建立在 Move 语言和 MoveVM 之上并实现了并行执行的高吞吐量公链。Aptos 的方法是在对用户 / 开发人员透明的情况下去检测依赖关系，即不需要事务显式声明它们使用的状态的哪一部分 ( 内存位置 )。Aptos 使用的是对软件事务性内存（STM）的修改，称为 Block-STM‌，在 Block-STM 中，事务在区块中预先排序，在执行期间会在处理器线程之间进行分割，以便乐观执行，所谓的乐观执行就是假定事务的执行没有依赖关系。这时会记录被事务修改的内存位置，执行之后，将验证所有事务结果。

在验证期间，如果发现一个事务访问了被前一个事务修改的内存位置，则该事务将失效，接着会刷新事务的结果，并重新执行事务，这个过程不断重复，直到区块中的所有事务都被执行。当使用多核处理器时，Block-STM 可以显著提高执行速度，当然，这种速度还取决于事务之间的相互依赖程度。据 Aptos 团队的研究的结果显示，当使用 32 核处理器时，即使是在高度相互依赖的情况下速度也能提高 8 倍，而在低相互依赖的情况下则可以提高 16 倍。如果一个区块中的所有事务都是相互依赖的，那么与顺序执行相比，Block-STM 也只会导致较小的性能损失。Aptos 声称，这种方法可以造就 160,000 TPS 的吞吐量。

Sui

另一种 PE 方法是要求交易明确声明它们修改的链状态部分。Solana 和 Sui 目前正在使用这种方法，在 Solana 网络中，当调用内存单元帐户时，交易就必须声明它修改了哪些内容，Sui 使用的也是类似的方法。

Sui 也是以 Diem 的 MoveVM 技术为基础，但 Sui 使用不同版本的 Move 语言。Sui Move 语言是为了改变 Diem 体系下的核心移动存储模型和资产权限，这也是与 Aptos 的主要区别。Sui Move 定义了一种状态存储模型，可以更轻松地识别独立交易。在 Sui 中，状态存储被定义为对象，而对象通常代表资产并且可以共享，这意味着多个用户可以修改对象，每个对象在 Sui 执行环境中都有一个唯一的 ID，并具有指向所有者地址的内部指针。通过使用这些概念，就可以很容易的通过检查事务是否使用相同的对象来识别依赖关系。

通过将工作转移给开发人员来声明依赖关系，执行引擎的实现变得更加容易，这意味着它理论上可以拥有更好的性能和可扩展性，然而，这也伴随着开发人员体验欠佳的问题。

目前，Sui 尚未启动，该项目刚刚启动了他们的测试网。Sui 的创始人声称，并行执行的实现以及使用 Narwhal & Tusk 共识机制可以让吞吐量超过 100,000 tx/sec，如果这个吞吐量是真的，那么它将超过 Solana 当前 2400 tx/sec 的吞吐量，并超过 Visa 和 Mastercard 的吞吐量。

Linera

Linera 是并行处理领域的最新成员，最近宣布了由 a16z 牵头的第一轮融资。关于项目的细节并未透露很多，然而，根据他们的资金公告，我们知道它是基于 Facebook 开发的 FastPay 协议。Fastpay 基于一种称为拜占庭一致广播的技术，该技术专注于加速独立支付，例如发生在销售点网络中的支付，它允许一组验证者确保支付的完整性，只要其中三分之二以上是诚实的。Fastpay 是实时总结算 (RTGS) 系统的一种变种，主要用于银行和金融机构之间的网络。

在 FastPay 的基础上，Linera 计划通过并行执行支付交易来构建一个专注于快速结算和低延迟的公链。值得注意的是，Sui 也使用了拜占庭一致广播方法来进行简单的支付，对于其他交易，Sui 自己的共识机制 Narwhal 和 Tusk 会用于高效处理 DeFi 交易等更复杂和依赖交易。

Fuel

Fuel 专注于成为模块化区块链堆栈中的执行层。也就是说，Fuel 不实现共识，也没有将区块链的数据存储在 Fuel 链上。对于一个功能性区块链，Fuel 与其他公链（例如 Ethereum 或 Celestia）交互以获得共识和数据可用性，这篇文章‌对模块化区块链概念进行了很好的分析。

Fuel 使用 UTXO 创建了严格的访问列表，即通过列表来控制对同一区块状态的访问。该模型建立在经典的交易排序的概念之上。在该方案中，区块中的事务排序会让检测事务之间的依赖关系变得简单。为了实现这种架构，Fuel 构建了一个名为 FuelVM 的新虚拟机和一种名为 Sway 的新语言。FuelVM 是对 EVM 的兼容且简化的实现方式，可以有效地将开发人员引入 Fuel 生态系统。此外，由于 Fuel 专注于模块化区块链，Fuel 智能合约的执行可以在以太坊主网上进行。这种方法与合并后以太坊的愿景一致，即作为以 Rollup 为中心的结算和数据可用层。在这种架构中，Fuel 可以实现在以太坊上批量和结算的高效执行。

作为概念验证，Fuel 团队创建了一个与 Uniswap 风格类似的 SwaySwap AMM ，目前它还在测试网上运行，以证明与 EVM 相比 FuelVM 的性能有所提高。

结论

并行执行引擎有望改善智能合约平台的吞吐量。结合创新的共识机制，事务的并行执行可以催生吞吐量接近 10 万 TPS 的链，与 Visa 和万事达一决高下或成为可能，此外，一些现在难以实现的应用也能得到进一步的发展，比如：全链上游戏和去中心化的微支付。但这些令人印象深刻的吞吐量改进也对如何确保去中心化的问题提出了新的挑战。

希望这篇文章对大家有一定的帮助。

今天的分享就到这里，后期会给大家带来其他赛道的龙头项目分析。感兴趣的可以点个关注。我也会不定期整理一些前沿资询和项目点评，欢迎各位志同道合的币圈人一起来探索。有问题可以评论提问或者私信。