为什么说 Aribitrum Stylus 是 L2 今年最重要的技术创新

作者：Yiping, IOSG Ventures

本文为IOSG原创内容，仅做行业学习交流之用，不构成任何投资参考。如需引用，请注明来源，转载请联系IOSG团队获取授权及转载须知。本文所提及所有项目均不构成推荐及投资建议。

随着像 zkSync 和 StarkNet 这样的 ZKRUs 推出主网，Layer2格局正在迅速演变。传统上，OPRUs 如 Arbitrum 是首个进入市场的，因而拥有更强大的生态系统。与之相反，ZKRUs 在技术上有所突破，提供更高的吞吐量和更低的费用。

近几个月，更多的活动从Layer1迁移到了Layer2，以寻求更快、更便宜的交易。以太坊的TVL过去一年中从近 400 亿美元降至 200 亿美元。然而，Layer2的 TVL 呈现出不同的画面，巨大的增长表明Layer2的采用正在加速。

Arbitrum 凭借超过 50% 的Layer2 TVL 市场份额领先，尽管 ZKRUs 也付出了努力。Arbitrum 的先发优势使其能够保持主导地位。

分析每日交易数量显示，像 zkSync 和 StarkNet 这样的 ZKRUs 在吞吐量上略微超过 OPRUs。然而，Arbitrum 的生态系统优势依然存在，尽管在每日 TPS 上稍微落后。

OPRUs 出现的时间比 ZKRUs 长。然而，ZKRUs 正在推出他们的主网，并从其他生态系统吸引用户。作为 OPRU 领域的领导者，Arbitrum 预计将通过他们的新更新来对抗 ZKRUs 的崛起。

Arbitrum：Stylus

随着开发者优化零知识技术和成本，由于其可扩展性优势，ZKRUs 可能会继续获得市场份额。但是，Arbitrum 的网络效应提供了尽管有竞争压力也能保持稳健的能力。通过像 Stylus 这样的创新解决方案，Arbitrum 可以用独特的技术能力补充其领导地位，并继续在Layer2竞赛中保持领先。

简而言之，Stylus 是一个为 Arbitrum 设计的革命性新智能合约环境，它允许开发者用像 Rust、C++ 和 Solidity 这样的编程语言编写高效、互操作的程序。

它向区块链开放了通用计算，并欢迎使用不同技术栈的开发者。

WASM

Stylus 通过添加一个与现有的以太坊虚拟机（EVM）并行运行的 WebAssembly（WASM）虚拟机来工作。编写在可以编译为 WASM 的语言的智能合约可以以比 Solidity 快 10 倍或更多的速度原生执行，大幅降低燃气费用。EVM 依然完全功能性，所以现有的 Solidity 合约仍然如同今天一样正常运行。两个 VMs 同步操作，允许用不同编程语言编写的合约相互调用，同时还能修改相同的底层区块链状态。

自定义预编译

此外，Stylus 也支持自定义预编译（Precompiles）。

预编译是 Ethereum 和 Arbitrum 上用于非常高效地执行特定加密或实用函数的底层模块。例如，有用于 ECDSA 签名验证和计算 SHA256 哈希的预编译。

要添加新的预编译需要所有验证者协调升级 EVM，因此门槛很高。而使用 Stylus，开发者可以轻松地部署他们自己用 Rust 或 C++ 编写的预编译。

例如，一个团队可以使用用 C 语言编写的加密库，并未经修改地将其部署到 Arbitrum。这将允许这些加密原语以超快的本地速度执行。

其他合约可以调用这个 Stylus “预编译”，就像它们调用原生预编译一样，来利用该加密技术。所有的燃气计量和欺诈证明都会自动工作。

这使得团队能够在没有任何特殊链支持的情况下，原型自定义加密、特殊的基于配对的曲线和其他新型原语。以太坊研究者甚至可以通过在 Arbitrum 上以 Stylus 预编译的形式部署它们，先行迭代 EIP 提案。

通过赋予开发者在链上原生地引入新的加密原语的能力，Stylus 大大拓展了可以构建的内容的范围。预编译不再仅限于 EVM 支持的功能。

Stylus 的工作原理

在深入探讨 WASM 在区块链宇宙中的更广泛角色之前，理解 Arbitrum 如何协调 EVM 和 WASM 的共存是至关重要的。这不仅仅是拥有两个独立的引擎；这是一种增强两者优势的协同关系。

Arbitrum 的独特架构允许 EVM 和 WASM 之间进行无缝和同步的操作，这要归功于其统一的状态、跨 VM 调用和兼容的经济模型。

用 Solidity 或其他 EVM 语言编写的智能合约会像往常一样编译为 EVM 字节码。当执行时，这些合约在 EVM 上运行，就像它们今天一样。

对于编译为 WASM 的语言，例如 Rust、C++ 和 C，工作流程是：

• 开发者使用现成的 WASM 编译器，如 Clang 或 Rustc，将他们的智能合约编译为 WASM。

• WASM 字节码以压缩形式上传到 Arbitrum 链。

• 合约所有者调用 `ArbWasm` 预编译的 `compileProgram` 方法，该方法为 WASM 进行安全工具设置，对其进行Gas成本计量，并将其编译为针对验证器硬件优化的本地代码。

• 当合约被调用时，它在像 Wasmer 这样的 WASM 运行时上运行，比 EVM 快得多，从而节省了Gas Fee。

WASM 计量在每个基本块之前收取Gas，而不是像 EVM 那样按操作码收费。这更为高效，确保合约不会失控。

EVM 与 WASM

这两个虚拟机（VM）同步运行，允许它们在共享相同的全局状态的同时互相调用。一个交易可能部分在 EVM 中执行，部分在 WASM 中执行，并且结果无缝地组合在一起。

等一下，两个 VM 怎么能无缝地和同步地工作呢？

Polkadot 通过 XVM 实现这一点。与 Polkadot 不同，WASM 和 EVM 出于几个关键原因可以在 Arbitrum 上无缝地和同步地工作：

• 单一状态：两个 VM 都访问相同的底层数据结构和状态Trie。一个 VM 中的合约可以读/写到另一个 VM 中的合约相同的位置。这提供了对链状态的统一视图。

• 跨 VM 调用：当一个交易与 EVM 合约交互时，Geth 处理它并提供一个结果。如果 EVM 合约随后调用了一个 WASM 程序，WASM VM 接管以计算该部分的结果。

• 共享上下文：像区块数据、发送者地址等系统信息对两个 VM 都是可用的。一个 WASM 合约可以像 Solidity 合约一样获取区块号。

• 单一共识：验证者运行两个 VM 以验证交易并就正确的链状态达成共识。争议将调用统一的欺诈证明系统。

• 兼容的经济学：像Gas计量这样的概念延伸到各个 VM，确保在任一环境中都有适当的计算成本和资源。

对于欺诈证明，验证者会在 EVM 和 WASM 执行中进行细分（bisect），以必要时识别任何无效的步骤。WASM 的结构允许系统保证终止并强制证明的有效性。

区块链 | WASM

Arbitrum 并不是唯一认识到 WebAssembly（WASM）变革潜力的平台。Polkadot 和 Cosmos 也都将 WASM 整合到了他们的生态系统中，每个平台都提供了一组独特的优势和功能。

Polkadot 允许用户用 WASM 开发智能合约，并支持两种语言：一种嵌入式 DSL 的 AssemblyScript 和类似于 Rust 的 Ink!。

另一方面，Cosmos 使用 CosmWasm 作为其智能合约运行时，允许开发者用 Rust 编写合约。

在深入研究区块链行业为何如此接受 WASM 之前，有必要先了解 Cosmos 和 Polkadot 突出的具体优势：

Cosmos 强调 WASM 的以下优势：

• 与 Rust 库的兼容性

• 多样化的开发者社区

• 增强的安全性，包括防止重入攻击

• 易于测试

• 高性能

Polkadot 的 WASM 运行时具有这些特点：

• 高性能

• 与 EVM 的互操作性

• 平台不可知性

• 紧凑的二进制大小

• 同时支持 Rust 和 AssemblyScript（TypeScript 风格）

尽管 Polkadot、Cosmos 和 Arbitrum 共享 WASM 提供的一些共同优势，但每个平台也都有其自己独特的属性。

这些主要区块链平台对 WASM 的广泛采用证明了其在行业中日益增长的重要性，这使得理解为何这项技术正在迅速成为现代区块链架构基石变得至关重要。

为什么选 WASM

WASM 是什么

为了理解区块链和 WebAssembly（WASM）之间的协同作用，首先必须了解 WASM 是什么以及其发展背后的推动力。

WebAssembly 是一种二进制指令格式，使代码能够在 Web 浏览器内以接近本机速度执行。它作为一系列编程语言（包括 C 和 Rust）的编译目标，旨在快速、高效且安全。WASM 有效地弥合了基于 Web 和系统级编程之间的鸿沟，从而提高了 Web 性能和功能。

“Web” 在 WebAssembly 中突出了其在 JavaScript 环境（通常在浏览器中找到）中运行的能力。在这些设置中，开发者可以完全访问 WASM API，并且具有全面的 Web API 支持，赋予他们相当大的控制 Web 行为的能力。

WASM 历史

遵循“一次编写，到处运行”的原则，WASM 出现作为一组长期挑战的有力解决方案。截至 2016 年，许多程序通过领域特定语言（DSL）引入新功能，这通常涉及维护、效率和安全之间的权衡。有越来越多的需求寻求一种解决方案，该方案可以在不影响这些方面的前提下，为无数服务器提供新功能。

评估了各种现有解决方案的不足：

- 系统虚拟机

• 频繁启动和关闭带来过多的开销

• 缺乏代码可见性以确保安全

• 对性能需求过于抽象

- 容器

• 缺乏代码可见性以确保安全

• 由于高级抽象而效率低下

• 频繁操作带来显著的开销

- 语言级虚拟机

• 需要频繁修改以确保安全

• 嵌入式 VM，如 V8，资源密集型

• 适应新语言到安全模型缓慢

• 仍然过于抽象

- 指令集体系结构（ISA）

• 难以有效沙箱

• 以前的 Google 项目从其转向 WASM

• 缺乏成熟的实现

到 2018 年，WASM 开发获得了动力，重点是在各种架构、服务器、嵌入式硬件上运行，甚至支持多种语言。与 Java 不同，WASM 的设计没有妥协安全性。到 2019 年，引入了一个组件模型以提升 WASM 模块，实现跨语言互操作性。这允许了像一次编写 HTTP 库并在多种语言中使用它这样的解决方案。

至今，WASM 拥有一系列功能，并在云原生场景（包括区块链）中越来越多地被采用。其优点包括：

• 高性能

• 紧凑的二进制大小

• 跨平台可携带性

• 支持多种语言，如 C/C++、Rust、AssemblyScript 等

• 在 JavaScript 引擎中执行

• 带有内存和 CPU 限制的强大沙箱

• 极快的启动时间，通常在毫秒或更短时间内

WASM 社区继续努力实现跨语言的更大集成和性能。

了解 WASM 的历史演变为我们提供了有价值的背景，用于了解其在各种设置（包括像 Stylus 这样的区块链项目）中的当前和潜在角色。这一背景让我们在探索有关 WASM 在区块链生态系统中实现的问题和疑虑时，具备了细致的理解。

Stylus Q&A

语言支持

WASM 的发展历程揭示了为什么 Stylus 是 Arbitrum 生态系统的一个令人兴奋的补充，但它也突出了一些局限性和疑虑。其中一个疑虑就是语言支持。虽然 Stylus 确实扩大了 Arbitrum 开发者社群以包括像 C++ 和 Rust 这样的语言，但它在接纳流行语言如 JavaScript 和 Python 方面还有所不足。

虽然有初步的项目旨在将 Python 和 JavaScript 带到 WASM，但由于垃圾收集和性能问题的挑战，这些努力尚未准备好广泛采用。

语言兼容性

目前，Stylus 支持 C/C++ 和 Rust SDK，与这些语言的工具链无缝集成。开发者甚至可以在构建智能合约时整合第三方库，比如原生加密实现。做这样的事的主要限制是相关的 gas 费用。

虽然 Rust SDK 还处于初级阶段，Rust 和 C SDK 都有一些缺失的功能。例如，C SDK 不支持 ABI 导出函数，而修饰符在两个 SDK 中都还未得到支持。

目前，没有本地 Stylus 测试环境，但开发者可以直接在 SDK 内运行测试。对于部署智能合约，目前只有测试网是唯一的选项，并且它还不支持智能合约验证。目前正在进行努力，以将各种 ERC 代币和 **[Uniswap V2](https://twitter.com/evmcheb/status/1697537852522049990)** 引入 Stylus 生态系统。

语言选择的困境

在领域特定语言（DSL）、嵌入式 DSL（eDSL）和通用语言之间做选择需要在低级控制和高级抽象之间权衡。开发全新的 DSL 需要在工具链和生态系统开发上做出重大投资。与此相反，作为通用语言的子集，eDSL 允许更容易地与现有工具集成，并有更低的学习曲线。例如，在像 JavaScript 或 Python 这样的流行语言中创建 eDSL 将是有益的。

通用语言需要使用 SDK，这引入了额外的工具，增加了冗长性，并减少了代码的表达性，同时伴随着更长的 API 调用和对象操作。

在语言选择和 eDSL 开发之间找到正确的平衡可能是吸引更广泛开发者社区的关键，同时提供用户友好的工具。根据当前数据显示，顶级加密开发者社区仍集中在以太坊周围。然而，利用 Rust 进行智能合约的平台，如 Polkadot、Cosmos 和 Solana，也在获得关注，并在其开发者社区中快速增长。

 

性能

WASM 显著提高了执行速度并减小了包大小。虽然 Stylus 还未在主网上部署，但其他网络的基准测试可以作为有用的参考。观察到的执行时间快了4-8倍，编译后的大小减少了大约50%。

Stylus 目前对其合约设有大小限制，未压缩时上限约为 128KB。这一限制使得将大型智能合约从其他语言（如 Solidity）移植过来变得具有挑战性。在 Stylus 代码库中，该限制如下所述：

值得注意的是，WASM 在启动和关闭时会产生一些开销。对于轻量级操作，EVM 实际上可能比 WASM 更具成本效益。

与 EVM 的互操作性

EVM 和 WASM 共享相同的存储槽和状态树，这有助于 Stylus 与 EVM 的互操作性。这是通过在 WASM 中实现的 EVM API 来实现的，使用流行的 Host I/O 模式。支持的 EVM API 的全面列表表明互操作性得到了全面支持。

 

自定义预编译合约

这个方面尤为令人兴奋，因为它代表了未知的领域。自定义预编译合约有潜力以更低的执行成本将额外的加密原语引入链上。它们还可以通过引入张量计算作为预编译合约来降低推理成本。然而，目前似乎还没有与自定义预编译合约相关的现有代码。虽然 EVM 组件存在预编译合约，但它们不是热插拔的。

这个功能可能仍在开发中，利用 WASM 的能力。EVM 可以调用用 WASM 编写的函数，然后将其编译为机器代码。

可重入功能

与 CosmWasm（采用没有可重入功能的 Actor 模型）相反，Stylus 的 Rust SDK 默认情况下关闭了可重入功能作为一个功能标志。开发者有选择手动启用此功能的选项。

激活可重入功能将需要进行一些 API 调整。特别是在调用过程中刷新存储缓存等安全预防措施方面，开发者需要小心谨慎。

洞见

Stylus 开放了一些在仅使用 EVM 时太耗费 gas 的新用例，如高性能加密、游戏和 AI。它还允许自定义预编译合约，使开发者可以添加自己的加密和其他基础功能，而无需等待升级。在过去，我们看到一些非以太坊生态系统采用了 WASM，如 Cosmos 和 Polkadot。这是以太坊社区首次采用 WASM。总体而言，Stylus 代表了智能合约开发的重大进化，将有助于以太坊和 Arbitrum 实现扩容，同时与所有现有应用保持互操作性。

将 Stylus 集成到 Arbitrum 的Layer2 SDK 可为第三层开发者提供更大的灵活性。他们现在可以将以前超过 gas 限制的密集计算移到链上，从而打开新的可能性。开发者不再仅限于使用 Solidity，如果 Rust 或 C++ 更符合他们的需要和专长，也可以选择这些语言。自定义预编译合约允许无缝地将首选的加密、实用程序和其他助手函数迁移到链上以获得最佳性能。以适应每个用例的语言直接编写低级逻辑会导致更加流畅的开发。开发者可以专注于核心产品功能，而不是为了避免 gas 成本而采取权宜之计。通过消除语言和 gas 限制，Stylus 使第三层构建者能够从一开始就使用适合其领域的正确工具，构建最高效的用户体验。

Stylus 也证明了 Arbitrum 有能力进行大规模革新，并且集成新的虚拟机。Ed Felten, Co-founder & Chief Scientist of Arbitrum & Offchain Labs 提到 Arbitrum 基于业界热门工具和编程语言开发。他们可以更加迅速地编写测试以及在原用系统之上开发新功能。OP 在 ZK 化的道路上走的更远，已经逐渐走向了混合 Rollup 的思路。Optimism 目前和 Risc0 合作，使用 Zeth 为 OPRU 生成零知识证明。使用这套解决方案，Optimism 并不用对 OPRU 进行额外的修改。如果你对 Zeth 感兴趣，可以看我之前写的[推特](https://x.com/glazecl/status/1709947992168710174?s=20)。

我们非常期待在 Arbitrum 上看到 AI 应用。目前，在链上进行机器学习非常耗费 gas，使得开发成本高昂。零知识 ML 可以降低成本，但也会为开发者带来显著的额外复杂性。如果我们能通过 Stylus 实现张量操作作为自定义预编译合约，并以一小部分的成本原生执行它们，那么就会为高性能的在链上机器学习打开新的可能性。通过让开发者用他们熟悉的语言（如 Python）快速构建和部署 ML 算法作为易于集成的预编译合约，Arbitrum 可以推动 DeFi、GameFi 等领域的下一代 AI 创新。Stylus 的性能和灵活性将使我们能够专注于创新的 ML 架构，而不是 gas 优化。我们期待看到社区的创造力应用于这一新兴范式。