原文作者：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