波卡，⽼牌区块链项⽬，从事 Web3 ⾏业的⼩伙伴们即使没⽤过他们的产品，⾄少也知道这么个项⽬。

近期波卡新闻不断，新的 JAM 架构让⼈眼前⼀亮，创始⼈演示 DOOM 游戏让我们看到了波卡新的局⾯，让我对其产⽣了巨⼤的研究兴趣，⽽波卡项⽬挺庞⼤的，⼤的⽐如有 Polkadot 链、Substrate 开发框架、还有中继 / 平⾏链等等，限于篇幅和注意⼒，我本次从中挑选我最感兴趣的执⾏层即虚拟机这条线给⼤家串⼀下它的发展史和当前的状况以及相关的信息。

前传

当年以太坊创⽴伊始，Gavin Wood 出于对以太坊的兴趣，Gavin 加⼊了以太坊的项⽬开发，当时以太坊还只是⼀个初步的框架，⽽ Gavin 加⼊之后使得以太坊在技术层⾯上得以落地，我们来看看他在以太坊的贡献：

（1）完成了以太坊的 PoC-1（Proof of Concept-1）；

（2）⼏乎是⼀个⼈完成了以太坊最早的 C++ 版本客户端 ；

（3）撰写了以太坊技术规范⻩⽪书 Yellow Book；

（4）发明了⽤于智能合约开发的⾼级语⾔ Solidity。

⾄于这段历史⼤家有兴趣可以阅读《点对万物：以太坊与未来数字⾦融》，⽽ Gavin Wood 的传奇故事⽹上也可以很容易搜索到，此处不再赘述。

让我们将眼光聚焦到 Solidity 和 EVM，⾸先看⼀段简单的 Solidity 计数器示例代码：

这个示例声明了⼀个 count 的状态变量，你可以将其视为数据库中的单个插槽，你可以通过管理数据库的代码来查询和更改它，在此示例中，合约定义了可⽤于修改或检索变量值的函数 inc,dec 和 get 。

经过 Solildity 编译器 solc 编译后，可以得到⼀段字节码（⻅下），通过 JSON-RPC 部署到节点后，执⾏层会先共识，确认后交由 EVM 执⾏。

我们换成汇编指令的⽅式来看看它是什么样⼦：

从编译原理⻆度看⼀下它的执⾏流程：

Solidity 源代码 -> 词法解析器 -> 语法解析器 -> 编译 -> 字节码 -> 虚拟机 -> 解释执⾏

是的，它在计算机⾏业只是⼀个新的编程语⾔⽽已，可这在当年真的是⼀件很 NB 的事情，在加⼊以太坊开发项⽬的两年后，以太坊如期上线。如果说 V 神创造了以太坊的形体，那么 Gavin 则是给予了以太坊灵魂。⽐特币是⼀个电⼦⽀付系统，⽽以太坊让区块链变得可编程化，以太坊喊出了“世界计算机”的⼝号，⼀切都变得不⼀样了。

Web 3.0

Gavin 还在担任以太坊的联合创始⼈和 CTO 期间，于 2014 年 4 ⽉ 17 ⽇在 「Insights into a Modern World」 博客上发布了⼀篇⽂章：DApps: What Web 3.0 Looks Like[1]，全⾯地解释了他⼼中的 Web3.0 时代应该是什么样的，以及构成 Web3.0 的四个组件。 Web3.0 这个概念有多⽕，影响⼒有多⼤，⼤家有⽬共暏，⽽ Gavin 他不仅技术好，还具有前瞻的视野。

关于 Web 3.0 的历史和争论，可以看看维基百科 Web3 词条[2]，美国企业家兼⻛险投资家诺瓦·斯⽪瓦克[3]建议将 Web3.0 的定义延伸⾄当前各⼤技术潮流迈向新的成熟阶段的具体体现，摘抄如下：

• ⽆处不联⽹：宽带⽹络的普及和发展，移动通信设备的互联⽹接⼊。（例如：平板电脑）

• ⽹络计算：“SaaS 服务”的商业模型，Web 服务互⽤性，分布式计算，⽹格计算和效⽤计算（⼜称“云端计算”）。

• 开放技术：开放 API 和协议，开放资料格式，开源软件平台和开放资料（如创作共享，开放资料授权）。

• 开放身份：OpenID，开放名声，跨域身份和个⼈资料。

• 智能⽹络：语义⽹技术⽐如资源描述框架，⽹络本体语⾔，SWRL,SPARQL 语义应⽤程序平台和基于声明的资料存储。

• 分布式数据库：万维数据库（“World Wide Database”，由语义⽹的技术实现）。

• 智能应⽤程序：普通语⾔的处理，机器学习，机器推理，⾃主代理。

2015 年年底，Gavin 从以太坊离开。

随后他创⽴了 Parity Technologies，并开发了⼀款⽤ Rust 语⾔编写的以太坊客户端，⼀度垄断以太系钱包市场。Gavin 离开以太坊的原因，我们不得⽽知，我们能知道的是 Gavin 的愿景是构建⼀个全新的去中⼼化的互联⽹世界。

“以太坊对我来说是⼀个实验，⼀个验证技术是否可⾏的产品原型。以太坊也是我的学校，我从这个学校毕业了，我想尝试做更多的事情。”

"其实我从以太坊学到最多的并不是技术（当时以太坊有⼀个专⻔负责管理技术细节的研究团队），⽽是社会经验。治理就是其中之⼀。我认为在区块链系统中，通过治理提升系统的能⼒是很重要的，这会是⼀个⾰命性的新特性，⽽这恰恰是以太坊没有做的事情。“

在以太坊期间，Gavin ⼀直是实践者，但是他不是设计者，⽽他也⼀直在酝酿新的创新。

波卡的诞⽣

⼀年后，Gavin 解开了⼀直以来萦绕在⼼头的难题，并在 16 年发布了波卡⽩⽪书。很多⼈都知道，波卡除了解决扩容问题之外，还想让各⾃独⽴的区块链能进⾏通信，也就是跨链问题。但是提到波卡，你最应该知道的是：分⽚，因为分⽚分到极致，其实就是波卡。

Polkadot 创始⼈ Gavin 的原话更能说明这⼀点：

"Polkadot ( 波卡 ) 的设计逻辑并没有直接联想到互操作性。我们在等以太坊的分⽚技术推出。但分⽚⼀直没有实现，现在也没有推出。因此我想⾃⼰做⼀个扩展性更强的“以太坊”，在设计过程中将分⽚概念推到了⼀个⽐较极端的程度，就⼲脆不要分⽚了，设计独⽴的链就⾏。这样设计的话，不同链之间就可以互相传递信息，最终的结果是通过⼀个共享的共识层⾯来实现通信。 "

那我们应该如何理解分⽚呢？⾸先我们聊⼀下以太坊的困境，⼀直以来，以太坊的性能问题是其硬伤，2018 年就因为⽕热的加密猫爆发了严重的拥堵，不仅增加了转账时间，还使得转账⼿续费居⾼不下。就如同银⾏办理业务，银⾏只有⼀个窗⼝并且处理速度较慢，当处理业务的⼈变多的时候，就会排起⻓队，等待办理。

但是，如果银⾏有好⼏个窗⼝，同时办理业务，可能就不需要排队了。这就是分⽚的基础逻辑，把整个⽹络的节点划分为不同的叫做分⽚的区域，把⼤量的交易交给不同的分⽚处理，极⼤的提升了效率。

所以在波卡中，每个分⽚都承载了核⼼逻辑，并且允许它们并⾏交易、交换数据，最终让多个区块链链接到⼀个⽹络上。

波卡的出现，不仅仅是媲美甚⾄超过以太坊 2.0 的设想，更具有创造性的地⽅是：在波卡⾥，可以有很多个以太坊。它不再是⼀个单纯的区块链，“波卡想为各种社会创新提供⼀个真正开放⾃由的平台”。

这是 Web3 的理想，是 Polkadot 的理想，也是 Gavin 的理想。

Polkadot 1.0

Polkadot 的中继链本身并不⽀持智能合约，但其连接的平⾏链[4]可以⾃由定义状态转换规则，因此能够提供智能合约功能。与其他⽣态系统的区别在于，在 Polkadot 的背景下，平⾏链和智能合约存在于堆栈的不同层：智能合约位于平⾏链之上。平⾏链通常被描述为第 1 层区块链 — 不同之处在于它们不必构建⾃⼰的安全性，并且可以升级和互操作。

Polkadot 为开发⼈员构建智能合约提供了灵活性，既⽀持由 EVM（以太坊虚拟机）执⾏的 Solidity 合约，也⽀持使⽤ ink! 的基于 Wasm 的合约：

与 EVM 兼容的合约

Polkadot ⽣态⽀持以太坊虚拟机（EVM），这得益于 Frontier[5] 这⼀⼯具集。Frontier 允许基于 Substrate 的区块链原⽣运⾏以太坊智能合约，并通过兼容以太坊的 API/RPC 接⼝，实现与以太坊⽣态的⽆缝交互。合约使⽤ Solidity 或 Vyper 等语⾔编写，EVM 在区块链中被⼴泛标准化，包括 Astar、Moonbeam 和 Acala 等 Polkadot 平⾏链。这种兼容性允许合约以最少的修改部署在多个⽹络中，从⽽受益于完善、⼴泛的开发⽣态系统。

举个例⼦：Astar[6] 是 Polkadot 上的关键智能合约平台，其独特的多虚拟机⽅法同时⽀持 EVM 和 WebAssembly(Wasm) 智能合约。这种双 VM ⽀持允许开发⼈员选择他们喜欢的编程环境，同时保持与以太坊的完全兼容性。该平台的运⾏时[7]使⽤ FRAME 在 Substrate 上构建，结合了来⾃ Polkadot-SDK 的关键组件以及⽤于处理其独特功能的定制模块。

这些链通常采⽤现成的合约模块，并在其基础上进⾏⼀些额外的创新。例如：

Phala[8]：在可信执⾏环境中使⽤合约模块，实现机密的智能合约执⾏和互操作性。

Aleph Zero[9]：在零知识环境中使⽤合约托盘。

t3rn[10]：使⽤合约模块作为构建模块，实现智能合约的多链执⾏。

查看更多如 Aster、Moonbeam、Acala 等相关兼容 EVM 的平⾏链的技术参⻅官⽅⽂档：平⾏链合约[11]

Wasm (ink!) 合约：

Polkadot 通过 FRAME 框架提供 Contracts 模块[12]，该模块采⽤ WebAssembly 作为合约的运⾏环境。理论上，任何可以编译为 Wasm 的语⾔都能⽤于开发智能合约，但出于优化和便捷性考虑 Parity 专⻔推出了 ink![13]。

在讨论 ink! 之前，我们⾸先需要澄清什么是 Substrate[14] 及其合约模块 (pallet-contracts)。Substrate 是⼀个⽤于构建区块链的框架，可以是独⽴的区块链，也可以是连接到 Kusama[15] 或 Polkadot[16] 的区块链，即所谓的平⾏链。

Substrate 包含许多模块，在 Substrate 术语中称为模块。Substrate 附带⼀组模块，可满⾜现代区块链通常具有的许多要求 — — 质押、同质化代币、⾮同质化代币、治理等。

Substrate 还附带⼀个⽤于智能合约的模块，称为 Contracts pallet。如果在 Substrate 中开发了平⾏链，则可以通过包含此 pallet 轻松添加智能合约功能。该模块只是执⾏环境，它以 WebAssembly ⽂件作为输⼊。该模块的智能合约必须编译为 WebAssembly (Wasm) ⽬标架构。

ink! 在这⾥是如何发挥作⽤的？ink! 是⼀种编程语⾔，具体来说，它是流⾏的 Rust 编程语⾔的嵌⼊式领域特定语⾔ (eDSL)。这意味着您可以使⽤所有常规 Rust 语法以及新添加的⼀些细节，使该语⾔适合智能合约世界。合约模块接收这些 ink! 合约并以安全的⽅式执⾏它们。简⽽⾔之：

使⽤ ink！您可以⽤ Rust 为使⽤ Substrate 构建的包含 Contracts 托盘的区块链编写智能合约。

ink! 并⾮创建⼀种新语⾔，它只是具有明确“合约格式”的标准 Rust，并带有专⻔的#[ink(…)]属性宏。这些属性宏告诉 ink! Rust 智能合约的不同部分代表什么，并最终允许 ink! 执⾏创建与 Polkadot SDK 兼容的 Wasm 字节码所需的所有魔法。由于 ink! 智能合约被编译为 Wasm，因此它们通过沙盒执⾏提供了⾼执⾏速度、平台独⽴性和增强的安全性。

让我们看⼀个简单的 ink! 合约。此处的合约在其存储中保存⼀个布尔值。合约创建后，它会将布尔值设置为 true。合约公开两个函数：⼀个⽤于读取布尔值的当前值 (fn get())，另⼀个⽤于将值切换为其相反的布尔值 (fn flip()）。

看着与 Solidity 所提供的能⼒差不多，Storage 存储、Message 消息、Errors 错误，Event 事件等。对于合约开发者来说，这意味着他们可以使⽤ ink! 编写智能合约，但也可以决定使⽤其他语⾔： Solidity 的 Solang 编译器[17] 和 AssemblyScript 的 ask![18]（如下）

添加新语⾔并不难。只需要有⼀个适⽤于 WebAssembly 的语⾔编译器，然后就可以实现 Contracts pallet API。

⽬前，此 API 包含⼤约 15-20 个函数，可⽤于智能合约可能需要的任何功能：存储访问、加密功能、环境信息（如区块编号）、访问⽤于获取随机数或⾃⾏终⽌合约的函数等。并⾮所有这些都必须⽤该语⾔实现— ink！“Hello,World!” 只需要六个 API 函数。以下模式描述了这种关系：

与 EVM 相⽐，选择 ink! 和 Contracts pallet 有许多优势。总结⼀下本⽂中详细介绍的⼀些优势：

• ink! 只是 Rust — 您可以使⽤所有常规的 Rust ⼯具：clippy, crates.io[19], IDE 等。

• Rust 是⼀种融合了多年语⾔研究的语⾔，它安全且快速。除此之外，从较旧的智能合约语⾔（如 Solidity）中吸取了主要经验，并将其融⼊到 ink! 语⾔设计中。选择了更合理的默认⾏为，例如默认禁⽤ ⼊或默认将函数设为私有。

• Rust 是⼀种令⼈惊叹的语⾔，它在 StackOverflow 上连续七年被评为最受欢迎的编程语⾔（来源[20]）。

• 如果您是⼀家公司并希望聘请智能合约开发⼈员，您可以从 Rust ⽣态系统中聘请，该⽣态系统⽐ Solidity 开发⼈员的利基市场要⼤得多。

• ink! 是 Substrate 原⽣的，使⽤类似的原语，就像相同的类型系统⼀样。

• 从合约到平⾏链的迁移路径⾮常清晰。由于 ink! 和 Substrate 都是 Rust，开发⼈员可以 ⽤⼤部分代码、测试以及前端和客户端代码。

• WebAssembly 是⼀个⾏业标准，它不仅仅⽤于区块链世界。它由 Google、Apple、Microsoft、Mozilla 和 Facebook 等⼤公司不断改进。

• WebAssembly 扩展了智能合约开发⼈员可⽤的语⾔系列，包括 Rust、C/C++、C#、Typescript、Haxe、Kotlin 等。这意味着您可以使⽤任何您熟悉的语⾔编写智能合约。这种设计⽐语⾔和执⾏架构的紧密耦合更具前瞻性。

关于本节内容，可以阅读 What is Parity's ink!?[21] 了解更多信息。

Polkadot 2.0 / JAM

2 ⽉ 28 ⽇ Gavin Wood 在 JAM Tour 上海站⾸次公开演示了在 JAM 上运⾏ DOOM 游戏！这是区块链⾏业的⼀次历史性时刻，JAM 使得区块链不仅仅是⼀个⽹络，⽽是⼀个强⼤的超级计算机平台，⽀持像 DOOM 这样的常规软件运⾏，同时提供强⼤的计算能⼒和低延迟。

抛开其它先不谈，我们还是只看虚拟机，基于我这边⼏天对 PolkaVM 相关源代码的阅读，它确实是真实发⽣的，关键点在 PolkaVM 有 Host 运⾏了 VM，向上提供了导出接⼝，然后在 VM 上运⾏了 guest 版 Doom 的 RISC-V 版代码。

源代码在此：https://github.com/paritytech/polkavm/tree/master/examples/doom

让我们看⼀下，这次最关键的新智能合约解决⽅案的⼏个组件：

Revive Pallet

Revive Pallet[22] 为运⾏时提供部署和执⾏ PolkaVM 智能合约的功能。它是⼀个经过⼤量修改的 pallet_contracts 分⽀。这些合约可以⽤任何编译为 RISC-V 的语⾔编写。⽬前，唯⼀官⽅⽀持的语⾔是 Solidity（通过 revive[23] ）和 Rust（查看 fixtures ⽬录中的 Rust 示例）。

在合约语⾔层⾯兼容以太坊：可以⽤ Solidity 编写合约，并使⽤以太坊 JSON RPC 和 MetaMask 等以太坊钱包与节点交互。在底层，合约从 YUL 重新编译为 RISC-V，以使⽤ PolkaVM ⽽不是 EVM 运⾏它们。为简化操作，可使⽤定制版的 REMIX[24] Web 前端将合约编译为 RISC-V 并将其部署到 Westend Asset Hub Parachain[25]。

Revive

Revive[26] 是 “Solidity to PolkaVM” 编译器项⽬的总称，它包含多个组件（例如 YUL 前端以及 resolc 可执⾏⽂件本身）。resolc 是单⼊⼝点前端⼆进制可执⾏⽂件的名称，它透明地使⽤所有 revive 组件来⽣成编译的合约⼯件。可以将 Solidity 合约编译为 PolkaVM 可执⾏的 RISC-V 代码，从⽽实现 Solidity 合约在 Polkadot 上的运⾏。

为此需要⼀个编译器。它的⼯作原理是使⽤原始 solc 编译器，然后将其中间表示 (YUL) 输出重新编译为 RISC-V。LLVM[27] 是⼀种流⾏且功能强⼤的编译器框架，⽤作编译器后端，并在优化和 RISC-V 代码⽣成⽅⾯承担了繁重的⼯作。revive 主要负责将⽣成的 YUL 中间表示 (IR) 降低 solc 到 LLVM IR。

这种⽅法在保持⾼⽔平的以太坊兼容性、良好的合约性能和可⾏的⼯程努⼒之间提供了良好的平衡。与实现完整的 Solidity 编译器相⽐，这样做的好处是任务要⼩得多。通过选择这种⽅法，就能⽀持 Solidity 及其所有不同版本的所有怪癖和怪异之处。

PolkaVM

PolkaVM[28]是⼀个基于 RISC-V 的通⽤⽤户级虚拟机。这是相对于竞争技术做出的最明显的改变。使⽤新的⾃定义虚拟机⽽不是 EVM 来执⾏合约。⽬前，在运⾏时本身中包含了⼀个 PolkaVM 解释器。稍后的更新将提供在客户端内运⾏的完整 PolkaVM JIT。

• 默认情况下是安全的且处于沙盒中。虚拟机中运⾏的代码应在单独的进程中运⾏，并且不应能够访问主机系统，即使在虚拟机内部存在具有完全远程代码执⾏权限的攻击者的情况下也是如此。

• 执⾏速度快。VM 中运⾏的代码的运⾏时性能应该与最先进的 WebAssembly VM 相媲美，⾄少在同⼀数量级内。

• 编译速度快，保证单次编译 O(n)。将新代码加载到虚拟机中应该⼏乎是即时的。

• 内存占⽤低。虚拟机的每个并发实例的基准内存开销不应超过 128KB。

• ⼩型⼆进制⽂件。为此 VM 编译的程序应占⽤尽可能少的空间。

• 不浪费虚拟地址空间。VM 不应为沙盒⽬的预先分配 GB 级的虚拟地址空间。

• 完全确定性。给定相同的输⼊和相同的代码，执⾏应该始终返回完全相同的输出。

• ⽀持⾼性能异步 gas 计量。Gas 计ᰁ应便宜、确定且合理准确。

• 很简单。⼀个程序员可以在不到⼀周的时间内编写出⼀个与该虚拟机完全兼容的解释器。

• 版本化操作语义。未来对客户程序可观察到的语义的任何更改都将被版本化，并明确选择加⼊。

• 标准化。应该有⼀个规范来完整描述此虚拟机的客户可观察的操作语义。

• 跨平台。在未受⽀持的操作系统和平台上，VM 将以解释模式运⾏。

• 最⼩外部依赖。虚拟机应该基本独⽴、编译速度快，并且能够抵御供应链攻击。

• ⽤于调试和性能分析的内置⼯具。

与 EVM 的两个根本区别是：

• 寄存器机 - EVM 是堆栈机。这意味着函数的参数在⽆限堆栈上传递。PolkaVM 基于 RISC-V，它是⼀个寄存器机。这意味着它在⼀组有限的寄存器中传递参数。这样做的主要好处是，由于这些都是寄存器机，因此它使底层硬件的转换步骤更加⾼效。仔细选择了寄存器的数量，使它们⼩于臭名昭著的寄存器匮乏的 x86-64 指令集。允许将 NP-hard 寄存器分配问题简化为简单的 1 对 1 映射是 PolkaVM 快速编译时间的秘诀。

• 减⼩字⻓ - EVM 使⽤ 256 位的字⻓。这意味着每个算术运算都必须对这些⼤数字执⾏。这使得任何有意义的数字运算都⾮常慢，因为它必须转换为许多本机指令。PolkaVM 使⽤ 64 位的字⻓，底层硬件原⽣⽀持该功能。也就是说，当通过 YUL（#Revive）转换 Solidity 合约时，仍然会使⽤ 256 位算术，因为 YUL 太低级，⽆法⾃动转换整数类型。但是，完全可以⽤不同的语⾔编写合约并从 Solidity ⽆缝调⽤它。想象⼀个系统，其中业务逻辑⽤ Solidity 编写，但底层架构⽤更快的语⾔编写，类似于 Python，其中⼤部分繁重的⼯作由 C 模块完成。

总结

智能合约编程语⾔

智能合约语⾔的数量逐年增加。选择第⼀种语⾔可能具有挑战性，尤其是对于初学者⽽⾔。选择主要取决于您感兴趣的⽣态系统，尽管有些语⾔适⽤于不⽌⼀个平台。每种语⾔都有⾃⼰的优点和缺点，本⽂不打算⼀⼀介绍。

有⼈会问为什么会有这么多合约语⾔？我总结有这么⼏种可能：1) 已有语⾔不能满⾜链的专有特性；2）更好的性能、安全、成本；3）品味 :)

我本⼈对合约语⾔没有偏⻅性，以下摘抄⼏个不同的声⾳，从中也能获取⼀些不同的收获，⽆论是从使⽤者⻆度，还是语⾔或 VM 设计的⻆度。

• 为什么不使⽤ Solidity？ Solidity 是备受推崇的先驱，但它受制于 EVM 的许多历史怪癖。它缺乏程序员所期望的常⻅功能，类型系统相对缺乏表现⼒，并且缺乏统⼀的⼯具⽣态系统。在 Sway 中，我们让您使⽤⼀整套现代⼯具来设计智能合约。您将获得⼀种功能⻬全的语⾔，其中包括泛型、代数类型和基于特征的多态性。您还可以获得⼀个集成、统⼀且易于使⽤的⼯具链，其中包含代码完成 LSP 服务器、格式化程序、⽂档⽣成以及运⾏和部署合约所需的⼀切，这样您就可以轻松实现所需的功能。我们的表达类型系统允许您捕获语义错误，我们提供良好的默认值，并进⾏⼴泛的静态分析检查（例如强制执⾏检查、效果、相互作⽤您可以使⽤ java.lang.Integer.pattern 来确保在编译时编写出安全、正确的代码。via https://docs.fuel.network/docs/sway/

• 为什么不使⽤ Rust？ 虽然 Rust 是⼀种出⾊的系统编程语⾔（Sway 本身也是⽤ Rust 编写的），但它并不适合智能合约开发。Rust 之所以出⾊，是因为它可以使⽤零成本抽象及其复杂的借⽤检查器内存模型，为没有垃圾收集器的复杂程序实现令⼈印象深刻的运⾏时性能。在区块链上，执⾏和部署的成本是稀缺资源。内存使⽤率低，执⾏时间短。这使得复杂的内存管理通常过于昂贵⽽不值得，⽽ Rust 的借⽤检查器则成为⼀种负担，没有任何好处。通⽤编程语⾔通常不适合这种环境，因为它们的设计必须假设在通⽤计算环境中执⾏。Sway 试图通过提供熟悉的语法和适合区块链环境特定需求的功能，为智能合约开发⼈员带来 Rust 的所有其他优势，包括其现代类型系统、安全⽅法和良好的默认值。 via https://docs.fuel.network/docs/sway/

• Clarity 代码的解释和提交完全按照编写⽅式进⾏。 Solidity 和其他语⾔在提交到链之前会被编译为字节码。编译智能合约语⾔的危险有两个⽅⾯：⾸先，编译器增加了⼀层复杂性。编译器中的错误可能会导致字节码与预期不同，从⽽带来引⼊漏洞的⻛险。其次，字节码不是⼈类可读的，这使得很难验证智能合约实际上在做什么。问问⾃⼰，你会签署⼀份你⽆法阅读的合约吗？如果你的答案是否定的，那么智能合约⼜有什么不同呢？有了 Clarity，你所看到的就是你所得到的。via https://docs.stacks.co/concepts/clarity\#clarity-is-interpreted-not-compiled

虚拟机及指令集

从我们熟知的 JVM 到 EVM 在区块链领域有启发式崛起，就我所知的虚拟机就有⼏⼗个，不同的虚拟机实现⽅式不同，其中最核⼼的解释器（Interpreter）通常是最基础的执⾏⽅式之⼀，特别是在 Just-In-Time (JIT) 编译 或 Ahead-Of-Time (AOT) 编译 之外，Interpreter 仍然⼴泛⽤于代码执⾏，它负责解析和执⾏字节码。

解释器示例

下⾯⽤⼀个⼩示例演示⼀个最基础本质的解释器，暂不考虑各种优化机制。

每条指令由⼀个 opcode （操作码）组成，可能带有参数，解释器使⽤ 栈（stack） 存储计算数据，只有 6 条指令。

指令集分类

从上⾯的解释器示例来看，指令的数量和可扩展性决定了⼀个虚拟机的⼤⽅向，按我的分析，虚拟机可以按指令集归类，⼤致可以分成下⾯ 4 类：

1. EVM 代表的⾃制指令集，导致要做⼤量的重复⼯作，⽐如编译器、指令设计... 在 EIP-3855[29] 之前已经有 141 条指令了，⽽且还在不断增加新的指令。

2. WASM，开箱即⽤，⽀持多种语⾔，但⽐较重，在 Polkadot ⽂档中也提出 WASM 这⼀点。我是觉得，WASM 的优势在于天然的多语⾔⽀持，如果某个链只是想运⾏⼀段逻辑，⽐较野蛮地将状态写⼊ account storage slot，那就⽐较合适。快速开发，快速接⼊，但缺点是其指令并不是专为区块链设计的，想⽀持⼀些特殊能⼒，想裁剪就很难了 (150+ 条指令[30])。

这⾥另外也要提到 Solana 的 SVM，它执⾏的是 BPF 指令，可以将任意编程语⾔编译成 BPF 指令的动态链接库，只是相对 WASM 要相对⼩众⼀些。

3. 基于 RISC-V 指令集，⽐如 PolkaVM 和当前很多的 zkVM 系：ceno、eigen zkvm、jolt、mozak vm、nexus、o1vm、openvm、powdrVM、risc0、sp1、sphinx 等等。其它我还没来得及研究，只说我知道的 PolkaVM 和 Nexus zkVM，它实现了通⽤的 RISC-V 指令解释，⽬前多数语⾔经过 GCC 或 LLVM 编译后都是可以输出为 RISC-V 指令的， 这就从语⾔层⾯上打开了视角，为未来多语⾔的⽀持打好了基础。基础 RV32I 指令是 47 条，可选扩展，对⽐ x86 3000+ 条指令，真的算是精简了。

4. 解释型，⽐如 Stacks 的 Clarity（Lisp），AO 的 Lua，Mina 的 Typescript 等。

所以，总结来说，如果左⼿是 EVM 代表私有指令，右⼿边是开放性的 WASM 的话，RISC-V 就是⼀个⽐较平衡的⼆次开发的好选择，⾸先，各编译器已经⽀持此指令集，可参考实现⽐较多。其次，很容易基于它做⾃定义指令的设计。

额外：探索多链智能合约的未来

随着区块链⽣态的多样化发展，越来越多的项⽬为⽀持独特功能⽽推出了⾃⼰的智能合约语⾔（如 Solidity、Move、Cairo、Sway 等）。这种创新虽然丰富了技术栈，但也带来了新的学习成本和兼容性挑战。⼀个核⼼问题逐渐浮现：能否将成熟的 Solidity 合约⽆缝部署到新兴的区块链上？

为此，我们联合⼏位对编译器技术充满热情的研究者，共同发起了 Hummanta 编译器项⽬。该项⽬旨在打破链间壁垒，实现智能合约语⾔的跨链编译，⽀持将 Solidity、Move、Cairo、Sway 等语⾔编译到多种虚拟机环境，包括：EVM 和新兴 VM：PolkaVM、SolanaVM、MoveVM、FuelVM 等。

项⽬当前进展

我们正从三个⽅向推进这⼀愿景：

1. 语法与指令集标准化 系统整理各语⾔的语法定义和虚拟机指令集，为跨链编译奠定基础。

2. 编译器⼯具链开发 基于 LALRPOP[31] 构建解析器，利⽤ Cranelift[32] / LLVM 实现代码⽣成，⽀持多语⾔到多⽬标字节码的转换。

3. ⼀体化开发体验 开发 Hummanta CLI ⼯具[33]（类似 Cargo），提供从编译到部署的全流程⽀持。

加⼊技术交流群

我们正在寻找对以下领域感兴趣的贡献者：编译器设计与优化、虚拟机开发、智能合约安全分析等，欢迎扫码加⼊开发者技术交流群，与志同道合的伙伴一起开启 Web3 开发者成长之旅！

项⽬当前进展

我们正从三个⽅向推进这⼀愿景：

1. 语法与指令集标准化 系统整理各语⾔的语法定义和虚拟机指令集，为跨链编译奠定基础。

2. 编译器⼯具链开发 基于 LALRPOP[31] 构建解析器，利⽤ Cranelift[32] / LLVM 实现代码⽣成，⽀持多语⾔到多⽬标字节码的转换。

3. ⼀体化开发体验 开发 Hummanta CLI ⼯具[33]（类似 Cargo），提供从编译到部署的全流程⽀持。

加⼊技术交流群

我们正在寻找对以下领域感兴趣的贡献者：编译器设计与优化、虚拟机开发、智能合约安全分析等，欢迎扫码加⼊开发者技术交流群，与志同道合的伙伴一起开启 Web3 开发者成长之旅！

添加小助手微信：placelessplace22，加入交流群

👏 欢迎关注 OpenBuild，获取更多 Web3 深度内容解读与开发者资源！

引用链接

[1] DApps: What Web 3.0 Looks Like:https://gavwood.com/dappsweb3.html

[2]维基百科 Web3 词条:https://zh.wikipedia.org/wiki/Web3

[3]诺瓦·斯⽪瓦克:https://zh.wikipedia.org/wiki/%E8%AF%BA%E7%93%A6%C2%B7%E6%96%AF%E7%9A%AE%E7%93%A6%E5%85%8B

[4]平⾏链:https://polkadot.network/features/parachains/

[5]Frontier:https://github.com/paritytech/frontier

[6]Astar:https://astar.network/

[7]运⾏时:https://github.com/AstarNetwork/Astar

[8]Phala:https://www.phala.network/

[9]Aleph Zero:https://alephzero.org/

[10]t3rn:https://www.t3rn.io/

[11]平⾏链合约:https://docs.polkadot.com/develop/smart-contracts/evm/parachain-contracts/

[12]Contracts 模块:https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/contracts/

[13]ink!:https://use.ink/

[14]Substrate:https://substrate.io/

[15]Kusama:http://kusama.network/

[16]Polkadot:http://polkadot.network/

[17]Solang 编译器:https://github.com/hyperledger-labs/solang

[18]ask!:https://github.com/ask-lang/ask

[19]crates.io:http://crates.io/

[20]来源:https://survey.stackoverflow.co/2022/

[21]What is Parity's ink!?:https://www.parity.io/blog/what-is-paritys-ink

[22]Revive Pallet:https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/revive

[23]revive:https://github.com/paritytech/revive

[24]REMIX:https://remix.polkadot.io/#lang=en&optimize=false&runs=200&evmVersion=null

[25]Westend Asset Hub:https://docs.polkadot.com/develop/networks/#westend-asset-hub

[26]Revive:https://github.com/paritytech/revive

[27]LLVM:https://github.com/llvm/llvm-project

[28]PolkaVM:https://github.com/paritytech/polkavm

[29]EIP-3855:https://eips.ethereum.org/EIPS/eip-3855

[30]150+ 条指令: https://webassembly.github.io/spec/core/syntax/instructions.html

[31]LALRPOP: https://github.com/lalrpop/lalrpop

  [32]Cranelift:https://github.com/bytecodealliance/wasmtime/tree/main/cranelift

 [33] Hummanta CLI ⼯具:https://github.com/hummanta/hummanta