从Substrate到Polkadot SDK：一场重构生态底层的技术革命

原文作者：Yuki, PaperMoon

从最初的 Substrate 到如今的 Polkadot SDK，Polkadot 的目标始终不是追求单链性能的极致，而是要构建一套服务异构多链的通用底座，让任何人都能像搭积木一样创建自己的区块链。

这套体系强调的不是兼容性，而是可组合性；不是单点优化，而是系统级协作。它通过模块化治理、安全机制和原生跨链协议（XCM），为未来的开发者提供“可被复用的底层秩序”。

正如 Gavin Wood 所言，Polkadot不是“卷兼容性的一条新链”，而是一种服务生态创新和多链未来的造链体系。而 Polkadot SDK，正是这台机器的最新形态，一个统一接口、标准化开发栈、跨 VM 的造链发动机。

Substrate 的历史与局限

Substrate由Parity于 2018 年推出，是一套以 Rust 编写的模块化区块链开发框架，为 Polkadot 主网及生态数十条链提供了核心技术底座。它最大的创新在于将共识算法、运行时逻辑、账户模型、资产治理、智能合约等全部拆分为可自由组合的 pallet 模块。任何团队都可以像搭积木一样拼出一条定制化区块链，这让 Substrate 成为业界公认的首个真正意义上的Layer-0 Framework。

Polkadot Substrate 首创了将搭建一条链从独立封闭的设计逻辑，变成“开放乐高”的定制化区块链。开发者可以通过 FRAME 体系自由拼装治理、质押、合约、身份、DEX 等功能模块，实现“链级拼装式开发”，快速构建面向 DeFi、NFT、DID 等场景的应用链。

这一设计使得 早期Polkadot 生态在极短时间内孕育出丰富多样的链级创新。

然而，模块化的高度定制自由也带来了生态层面的碎片化负担。经过多年迭代，构建一条平行链的代码与功能分散在多个代码仓库中，Substrate， Cumulus和Polkadot等。每个项目依赖不同版本、使用不同分支，API 与文档体系割裂严重。

为了避免主分支冲突，许多团队只能 fork 出各自的 runtime，手动维护版本，结果导致生态难以主干合流、库间同步复杂、版本更新滞后。当底层依赖与接口各自演化，整个生态陷入了三大瓶颈：

● 升级难：主干推进缓慢，模块更新需人工同步，许多链长期停留在旧版本。

● 协作难：不同团队的 runtime 无法直接复用，跨链或共享模块开发需重复劳动。

● 传播难：文档与工具链分裂，学习曲线陡峭，新开发者难以系统掌握链级开发。

最终结果是，Substrate 的模块化自由，在生态层面反而制造了碎片化的束缚。正因如此，Parity迈出了关键一步：将所有核心模块、接口与仓库统一整合，重构为一个完整、标准化的 Polkadot SDK。

Polkadot SDK 的诞生：重构统一框架

在经历多年碎片化协作之后，Parity 最终选择在2023–2024年进行一次历史性的架构整合。

官方将 Substrate、Cumulus、 Polkadot （以及 FRAME 与节点相关仓库） 全部合并为单一代码库：Polkadot SDK。

长期以来，多个仓库的独立演化让开发者在跨项目协作、依赖更新和版本管理上耗费巨大精力。

Polkadot SDK 通过统一的依赖管理、标准化的开发规范和同步的代码更新机制，彻底消除多仓库之间的频繁同步与冲突。

Parity 在合并公告中明确指出，这一步旨在让 Substrate 不再只是一个“灵活的工程框架”，而是成为支撑整个 Polkadot 生态的 标准化协议栈，新的Polkadot SDK库整合了 Polkadot 的全部核心组件：

● Substrate：提供区块链运行时、共识与核心模块；

● FRAME：构建 pallet 模块系统，实现可插拔式运行时逻辑；

● Cumulus：作为平行链适配层，使链能直接接入中继链；

● Polkadot Node：定义主节点协议栈与网络通信逻辑。

Polkadot SDK的技术核心结构

所有模块、依赖与文档体系现已统一在 一个仓库中 ，且拥有完整的迁移文档与更新历史。

这意味着开发者不再需要在多个代码库中查找、拼接、调试，而可以在统一的环境中构建、调试、部署整条链，开发者体验从“灵活模块化”提升为“全生态可组合”。

并后的Polkadot SDK 得到了开发者与生态社区的广泛认可。

它不仅主导了 Polkadot 未来链级创新的主干，也让开发者能够更轻松地以模块化方式搭建自己的 Appchain 或 Rollup。

文档体系、API 结构与构建工具全面统一，学习曲线大幅降低，协作效率显著提升。

对于 Parity 而言，这次整合是 自 Polkadot 创世以来非常大的一次架构进化；对于整个生态而言，Polkadot SDK 标志着从“多链共存”到“多链协同”的真正开始。Substrate给了造链自由，SDK给了生态秩序。

从 SDK 到 REVM：EVM 原生化的必然结果

原生EVM在波卡上得到了原生的支持。 REVM的出现，使得基于polkadot sdk的链可以轻松包含以太坊的所有功能。它标志着 Polkadot 不再依赖任何外挂式的 EVM 兼容方案，而是将以太坊生态的核心执行环境，直接纳入自身体系之中。

早期Polkadot生态的EVM 兼容性由各平行链自行解决，Moonbeam、Astar、Acala 等链都采用了 Parity 提供的 Frontier 框架，一种通过模块化方式实现 EVM 功能的方案。这种模式让平行链拥有高度灵活性，但也带来了工程层面的割裂，每条链都需要独立维护 Frontier 模块、管理 RPC 兼容、调试 EVM 逻辑、修复兼容性问题。

Parity 团队将EVM引擎以 REVM的形式直接嵌入 SDK 主体，与 FRAME、Cumulus、XCM 并列为核心模块。EVM 兼容从各平行链的外挂工程，正式被收编进系统核心，成为 Polkadot 的标准能力。

REVM 由 Parity 以 Rust重写，原生适配 Polkadot SDK 架构。它的诞生不是一个额外的兼容层，而是一种系统级的整合。

核心特征包括：

● Rust 实现：性能高、内存安全，与 SDK 其他组件无缝协作；

● 原生集成：REVM 直接编译进 Polkadot SDK，无需 Frontier 外挂；

● 开发者体验统一：兼容以太坊全套工具链（Foundry、Hardhat、Ethers.js），开发者可直接使用现有以太坊工具“开箱即用”；

● 零迁移成本：Solidity 合约无需修改即可部署至 Polkadot 主网或任意 SDK 链；

● 生态级统一：所有新链默认拥有 EVM 执行能力，不再依赖 Moonbeam 等个体项目提供兼容入口。

这意味着，EVM 合约的部署与执行将首次成为 Polkadot 主网级的原生功能。

REVM 的诞生不是外部竞争的结果，而是 SDK 一体化的必然产物。当底层的模块与协议实现彻底标准化，EVM 兼容自然会被吸收为系统标准，而非额外插件。这也是 Polkadot 首次在执行层真正意义上“吸收以太坊”，实现从“兼容”到“原生”的跃迁。

直到 2025 年，Parity 决定重写整个开发框架。

新的 Polkadot SDK 不仅继承了 Substrate 的灵魂，更把以太坊的 EVM 直接编译进核心。

这不只是一次版本迭代，而是一场理念的重构——

Polkadot 不再只是兼容以太坊，而是吸收它，让它成为原生的一部分。

但问题是——Polkadot 本可以继续维持现状，为什么要在 2025 年冒险重写整个 SDK，把 EVM 直接放进系统核心？

Substrate最初是Parity（Polkadot核心开发公司）推出的Rust模块化区块链开发框架，用于构建任意区块链，包含共识、存储、网络、运行时等核心模块，是Polkadot网络的底层技术基础.​

2023–2024年间，Parity将Substrate、Cumulus（跨链模块）、Polkadot客户端等项目统一合并为单一存储库，命名为Polkadot SDK (Software Development Kit)，以简化开发结构和API管理.​

这一整合让开发者可以用一个SDK主仓库完成链级模块、共识、跨链、节点、资产、治理所有开发工作，从此由“多项目用同一个库”转为“统一栈的一体开发”。

目前Polkadot SDK的核心组成：

未来， REVM 属于 PolkaVM / PVM 生态中作为支持 EVM （即 Ethereum Virtual Machine）兼容性的 虚拟机后端（VM backend） 模块，与 pallet‑revive + ETH-RPC 等构成 “EVM 兼容解决方案” 的一部分。

Polkadot SDK在最新迭代中，REVM已被明确纳入核心组件（即智能合约执行层标准模块），未来所有SDK链都自动支持REVM/EVM，无需第三方外挂或兼容包。“REVM为Polkadot生态提供原生EVM兼容力”的战略已经在主代码库和官方开发文档固化。

Polkadot SDK 的技术核心

Polkadot SDK 并非仅是一个“整合版仓库”，而是一套重新定义造链逻辑的标准化协议栈。它的核心目标是让链的构建、升级、跨链交互与治理都具备“系统级的一致性”，让开发者从复杂的工程配置中解放出来，专注于业务与创新。

这一套结构使 Polkadot SDK 不再只是“造链框架”，而更像一个能够持续进化的操作系统。

正如官方文档所强调的那样：SDK 不仅提供模块，更定义了模块之间如何安全协作、共享资源与升级。

从 Substrate 到 Polkadot SDK：为什么 EVM 在 Polkadot 进入“原生时代”

Substrate本身不带EVM，而是通过Frontier仓库中的pallets和RPC模块动态集成。任何Substrate链（如Moonbeam、Astar、Acala等）均需导入这些模块。

Frontier节点维护额外的数据结构（以太坊区块哈希、交易索引、日志等），以满足RPC索引查询功能，因此资源开销高于纯Substrate节点。

一些开发者称之为“Ethereum sandbox in Substrate”，因为它在Substrate环境外层模拟了完整EVM执行与存储模式。

但也会带来一些局限性：

用户体验分割：需用Polkadot.js类钱包与Metamask组合，EVM/ERC20和Substrate资产通常各自为政（部分项目通过地址映射和自定义前端部分缓解，但本质未变）。

资源占用大：节点需要为EVM相关RPC进行专门索引和区块解析，新增数据与存储压力（特别是ETH-style_block/explorer等）。​

EVM & Substrate模块隔离：EVM合约很难直接调用或操作Substrate的native pallets，逻辑复用/权限管理变复杂，“沙盒效应”明显。

Polkadot的平行链Moonbeam为了打破这些局限，基于已有的frontier之上对EVM兼容做了更升深入的融合。Moonbeam并非“简单接入Frontier” —— 它对Frontier进行大量重写和与Substrate的深度绑定，将EVM pallet、Ethereum pallet、账户管理与XCM跨链共识接口等植入主Runtime，并统一了底层Substrate与EVM资产、事件和治理分布。

Moonbeam通过多重映射与bridge pallet设计，使EVM地址与Substrate Address映射，允许账户在EVM与Substrate层之间流畅转账、管理资产与调用native pallet，大幅缓解用户“双钱包”割裂（虽然私钥格式不同，但多数支持双签名及自动识别）。

Moonbeam节点对外同时暴露Ethereum JSON-RPC和Substrate RPC，开发者能用Metamask/Hardhat/tools与 Polkadot.js/app交互同一资产。

但是，虽然Moonbeam实现了EVM地址和Substrate地址的映射桥接，但用户私钥类型、签名算法（Ethereum secp256k1与Substrate sr25519/ed25519）底层始终不同，并非所有硬件钱包或生态工具都能“自动支持”双链签名，易造成极端场景下的兼容性障碍。

一些高级操作（特别是链原生治理、代理委托等）需用专门的Substrate钱包操作，连通体验还是逊于纯EVM链。

多资产、多代币（Native、ERC20、Substrate资产）的跨链场景，依旧需管理不同形式的address/ID、Approve逻辑和映射表，开发和运营仍有维护复杂度，且部分链间转账依赖XCM或桥协议后处理，存在同步延迟。

虽然大多数EVM合约可用治理升级，但与Substrate runtime升级的灵活性和权限管控依然不完全等价，极端情况下导致部分资产、合约状态迁移需要链层协调而非纯EVM操作。

免责声明

由PaperMoon提供并包含在本文中的材料仅用于学习目的。它们不构成财务或投资建议，也不应被解读为任何商业决策的指导。我们建议读者在做出任何投资或商业相关的决定之前，进行独立研究并咨询专业人士。PaperMoon对根据本文内容采取的任何行动不承担任何责任。

阅读更多

https://polkadot-evm.github.io/frontier/overview

https://github.com/polkadot-evm/frontier