原作者：Yuki、PaperMoon

初期の Substrate から現在の Polkadot SDK に至るまで、Polkadot の目標は、単一チェーンの究極のパフォーマンスを追求することではなく、異種のマルチチェーンを提供するための普遍的な基盤を構築し、誰もがビルディング ブロックのように独自のブロックチェーンを作成できるようにすることです。

このシステムは、互換性よりも構成可能性を重視し、単一点の最適化よりもシステムレベルの連携を重視しています。モジュール式のガバナンス、セキュリティメカニズム、そしてネイティブなクロスチェーンプロトコル（XCM）を通じて、将来の開発者に「再利用可能な基盤となる秩序」を提供します。

ギャビン・ウッド氏が述べたように、Polkadotは「取引量互換性を持つ新しいチェーン」ではなく、エコシステムのイノベーションと複数のチェーンの未来に貢献するチェーン構築システムです。Polkadot SDKは、このシステムの最新版であり、統一されたインターフェース、標準化された開発スタック、そしてVM間のチェーン構築エンジンを備えています。

基質の歴史と限界

Parityが2018年にリリースしたSubstrateは、Rustで記述されたモジュール型ブロックチェーン開発フレームワークであり、Polkadotメインネットとそのエコシステムを構成する数十のチェーンの中核技術基盤を提供しています。その最大のイノベーションは、コンセンサスアルゴリズム、ランタイムロジック、アカウントモデル、アセットガバナンス、スマートコントラクトを自由に組み合わせ可能なパレットモジュールに分解していることです。あらゆるチームがブロックのようにカスタマイズされたブロックチェーンを組み立てることができるため、Substrateは業界初の真のレイヤー0フレームワークとして広く認知されています。

Polkadot Substrateは、ブロックチェーン開発における新たなアプローチの先駆者であり、チェーン構築の概念を、独立した閉鎖的な設計から「レゴのような」カスタマイズ可能なブロックチェーンへと変革しました。開発者は、FRAMEシステムを通じて、ガバナンス、ステーキング、コントラクト、アイデンティティ、DEXといった機能モジュールを自由に組み合わせることで、「チェーンレベルのモジュール開発」を実現し、DeFi、NFT、DIDなどのシナリオに対応したアプリケーションチェーンを迅速に構築できます。

この設計により、初期のPolkadotエコシステムは、非常に短期間で多種多様なチェーンレベルのイノベーションを促進することができました。

しかし、モジュール性によってもたらされる高度なカスタマイズの自由度は、エコシステムレベルでの分断という負担ももたらします。長年のイテレーションを経て、パラチェーンを構築するためのコードと機能は、Substrate、Cumulus、Polkadotといった複数のコードリポジトリに散在しています。各プロジェクトは異なるバージョンに依存し、異なるブランチを使用しているため、APIとドキュメントシステムの間に深刻な断絶が生じています。

メインブランチとの競合を避けるため、多くのチームは独自のランタイムをフォークし、手動でバージョン管理を行う必要があります。その結果、エコシステムをメインブランチにマージすることが困難になり、リポジトリ間の同期が複雑になり、バージョン更新が遅れるという問題が発生します。基盤となる依存関係とインターフェースが独立して進化するため、エコシステム全体が3つの大きなボトルネックに直面しています。

● アップグレードが困難: メイントランクの進行が遅く、モジュールの更新には手動の同期が必要であり、多くのチェーンが長期間古いバージョンのままになっています。

● コラボレーションの難しさ: 異なるチームのランタイムを直接再利用することはできず、クロスチェーンまたは共有モジュールの開発には反復的な作業が必要になります。

● 普及が困難: ドキュメントとツールチェーンが断片化しており、学習曲線が急峻であるため、新しい開発者がチェーンレベルの開発を体系的に習得することが困難です。

結果として、Substrateのモジュール化の自由度は、エコシステムレベルでの分断を招いてしまいました。そこでParityは重要な一歩を踏み出し、すべてのコアモジュール、インターフェース、リポジトリを、完全かつ標準化されたPolkadot SDKに統合しました。

Polkadot SDKの誕生：統合フレームワークのリファクタリング

長年にわたる断片的な協力関係を経て、パリティは最終的に 2023 ～ 2024 年に歴史的な建築物の統合を実施することを決定しました。

公式チームは、Substrate、Cumulus、 Polkadot (および FRAME とノード関連のリポジトリ) を単一のコードベースである Polkadot SDK に統合しました。

長い間、複数のリポジトリが独立して進化してきたため、開発者はプロジェクト間のコラボレーション、依存関係の更新、バージョン管理に多大な労力を費やしてきました。

Polkadot SDK は、統合された依存関係管理、標準化された開発仕様、同期コード更新メカニズムを通じて、複数のリポジトリ間の頻繁な同期と競合を完全に排除します。

Parityは合併発表において、今回のステップはSubstrateを単なる「柔軟なエンジニアリングフレームワーク」から、Polkadotエコシステム全体をサポートする標準化されたプロトコルスタックへと変革することを目指していると明確に述べています。新しいPolkadot SDKライブラリは、Polkadotのコアコンポーネントをすべて統合しています。

● Substrate: ブロックチェーンのランタイム、コンセンサス、コアモジュールを提供します。

● フレーム: プラグイン可能なランタイムロジックを実装するためのパレットモジュールシステムを構築します。

● Cumulus: パラチェーンアダプタ層として、チェーンをリレーチェーンに直接接続できるようにします。

● Polkadot ノード: マスターノードのプロトコルスタックとネットワーク通信ロジックを定義します。

Polkadot SDKのコア技術構造

すべてのモジュール、依存関係、ドキュメントが1 つのリポジトリに統合され、完全な移行ドキュメントと更新履歴が保存されます。

つまり、開発者は複数のコード リポジトリで検索、組み合わせ、デバッグする必要がなくなり、チェーン全体を統合された環境で構築、デバッグ、デプロイできるようになり、開発者エクスペリエンスが「柔軟なモジュール性」から「エコシステム全体で構成可能」へと向上します。

その後のPolkadot SDKは、開発者やエコシステムコミュニティから幅広い認知を得ました。

これは、Polkadot の将来のチェーンレベルのイノベーションのバックボーンを形成するだけでなく、開発者がモジュール方式で独自の Appchains または Rollups を構築することも容易になります。

ドキュメント システム、API 構造、ビルド ツールが完全に統合されているため、学習曲線が大幅に短縮され、コラボレーションの効率が大幅に向上します。

Parityにとって、この統合はPolkadotの誕生以来の重要なアーキテクチャ的進化を表しています。エコシステム全体にとって、Polkadot SDKは「マルチチェーン共存」から「マルチチェーンコラボレーション」への移行の真の始まりとなります。Substrateはチェーン作成の自由を提供し、SDKはエコシステムに秩序をもたらします。

SDKからREVMへ: EVMネイティブ化の必然的な結果

PolkadotはネイティブEVMをサポートしています。REVMの登場により、Polkadot SDKをベースとするチェーンはEthereumのすべての機能を容易に組み込むことができます。これは、Polkadotがもはや外部のEVM互換性ソリューションに依存せず、Ethereumエコシステムのコア実行環境を自社システムに直接統合していることを意味します。

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 アドオンは不要になります。

● 統合された開発者エクスペリエンス: Ethereum ツールチェーン全体 (Foundry、Hardhat、Ethers.js) と互換性があり、開発者は既存の Ethereum ツールを「そのまま」直接使用できます。

● 移行コストゼロ: Solidity コントラクトは、変更なしで Polkadot メインネットまたは任意の SDK チェーンにデプロイできます。

● エコシステムレベルの統合: すべての新しいチェーンにはデフォルトで EVM 実行機能が備わっており、互換性エントリ ポイントを提供するために Moonbeam などの個々のプロジェクトに依存する必要がなくなりました。

これは、EVM 契約の展開と実行が初めて Polkadot メインネット レベルのネイティブ機能になることを意味します。

REVMの出現は外部との競争によるものではなく、SDK統合の必然的な産物でした。基盤となるモジュールとプロトコルが完全に標準化されれば、EVMの互換性は追加のプラグインではなく、システム標準に自然に吸収されるでしょう。これは、Polkadotが実行層で真に「Ethereumを吸収」した初めてのケースであり、「互換性」から「ネイティブ」への飛躍を達成したと言えるでしょう。

2025年に、Parityは開発フレームワーク全体を書き直すことを決定しました。

新しい Polkadot SDK は、Substrate の本質を継承するだけでなく、Ethereum の EVM をそのコアに直接コンパイルします。

これは単なるバージョンの反復ではなく、基礎となる哲学の再構築です。

Polkadot はもはや Ethereum と互換性があるだけでなく、それを吸収してそのネイティブの一部になっています。

しかし、疑問は、Polkadot は現状を維持できたはずなのに、なぜ 2025 年に SDK 全体を書き直し、EVM をシステム カーネルに直接組み込むというリスクを冒したのかということです。

Substrateは、Polkadotのコア開発を担うParity社によって開発された、Rust向けのモジュール型ブロックチェーン開発フレームワークです。任意のブロックチェーンを構築するために使用され、コンセンサス、ストレージ、ネットワーク、ランタイムといったコアモジュールが含まれています。Polkadotネットワークの基盤となる技術です。

2023年から2024年にかけて、ParityはSubstrate、Cumulus（クロスチェーンモジュール）、およびPolkadotクライアントをPolkadot SDK（ソフトウェア開発キット）という単一のリポジトリに統合し、開発構造とAPI管理を簡素化しました。

この統合により、開発者は単一の SDK メイン リポジトリを使用して、チェーン レベルのモジュール、コンセンサス、クロスチェーン、ノード、アセット、ガバナンスのすべての開発作業を完了できるようになり、プロセスが「同じライブラリを使用する複数のプロジェクト」から「統合スタック統合開発」へと変化します。

現在の Polkadot SDK のコア コンポーネント:

将来、 REVM は、EVM (Ethereum Virtual Machine) 互換性をサポートする仮想マシン バックエンド モジュールとして PolkaVM/PVM エコシステムの一部となり、pallet-revive + ETH-RPC とともに「EVM 互換ソリューション」の一部を形成します。

Polkadot SDKの最新バージョンでは、REVMがコアコンポーネント（スマートコントラクト実行レイヤーの標準モジュール）に明示的に組み込まれました。今後のすべてのSDKチェーンは、サードパーティ製のアドオンや互換性パッケージを必要とせずに、自動的にREVM/EVMをサポートします。「PolkadotエコシステムにネイティブEVM互換性を提供する」という戦略は、メインコードベースと公式開発ドキュメントに明確に記載されています。

Polkadot SDKのコア技術

Polkadot SDKは単なる「統合リポジトリ」ではなく、ブロックチェーン構築のロジックを再定義する標準化されたプロトコルスタックです。その主な目標は、ブロックチェーンの構築、アップグレード、クロスチェーンインタラクション、そしてガバナンスにおいて「システムレベルの一貫性」を確保することです。開発者は複雑なエンジニアリング構成から解放され、ビジネスとイノベーションに集中できるようになります。

この構造により、Polkadot SDK は単なる「チェーン構築フレームワーク」ではなく、継続的に進化できるオペレーティング システムのようなものになります。

公式ドキュメントで強調されているように、SDK はモジュールを提供するだけでなく、モジュールが安全に連携し、リソースを共有し、アップグレードする方法も定義します。

SubstrateからPolkadot SDKへ: EVMがPolkadotで「ネイティブ時代」に突入した理由

Substrate自体にはEVMは付属していません。代わりに、Frontierリポジトリ内のパレットとRPCモジュールを通じて動的に統合されます。Substrateチェーン（Moonbeam、Astar、Acalaなど）は、これらのモジュールをインポートする必要があります。

Frontier ノードは、RPC インデックス クエリ機能を満たすために追加のデータ構造 (Ethereum ブロック ハッシュ、トランザクション インデックス、ログなど) を維持するため、純粋な Substrate ノードよりもリソース オーバーヘッドが高くなります。

Substrate 環境外で完全な EVM 実行とストレージ モデルをシミュレートするため、一部の開発者はこれを「Substrate 内の Ethereum サンドボックス」と呼んでいます。

ただし、いくつかの制限もあります。

ユーザーエクスペリエンスのセグメンテーション：Polkadot.jsのようなウォレットはMetamaskと組み合わせる必要があります。EVM/ERC20とSubstrateアセットは通常、独立して動作します（一部のプロジェクトではアドレスマッピングやカスタムフロントエンドによってこの問題を軽減していますが、本質は同じです）。

リソース消費量が多い: ノードは EVM 関連の RPC に対して専用のインデックス作成とブロック解析を実行する必要があり、データとストレージの負荷が増加します (特に ETH スタイルのブロック/エクスプローラーなど)。

EVM と Substrate モジュールの分離: EVM 契約では、Substrate のネイティブ パレットを直接呼び出したり操作したりすることが困難で、ロジックの再利用や権限管理が複雑になり、「サンドボックス効果」が明らかになります。

これらの制限を克服するため、PolkadotのパラチェーンMoonbeamは、既存のFrontierをベースにEVMとの互換性を備えた、より深い統合を実現しました。Moonbeamは単にFrontierと統合するだけでなく、Frontierを大幅に書き換え、Substrateと深く結び付けています。EVMパレット、Ethereumパレット、アカウント管理、XCMクロスチェーンコンセンサスインターフェースをメインランタイムに組み込み、基盤となるSubstrateの配布をEVMアセット、イベント、ガバナンスと統合しています。

Moonbeam は、マルチマッピングとブリッジパレット設計を使用して EVM アドレスを Substrate アドレスにマッピングし、アカウントが EVM レイヤーと Substrate レイヤー間で資金を転送し、資産を管理し、ネイティブパレットをスムーズに呼び出すことを可能にし、ユーザーの「デュアルウォレット」間の切断を大幅に緩和します (秘密鍵の形式は異なりますが、ほとんどがデュアル署名と自動認識をサポートしています)。

Moonbeam ノードは Ethereum JSON-RPC と Substrate RPC の両方を外部に公開し、開発者がMetamask/Hardhat/tools と Polkadot.js/app を使用して同じアセットを操作できるようにします。

しかしながら、MoonbeamはEVMアドレスとSubstrateアドレス間のマッピングブリッジを実装していますが、基盤となるユーザー秘密鍵の種類と署名アルゴリズム（Ethereum secp256k1とSubstrate sr25519/ed25519）は常に異なります。すべてのハードウェアウォレットやエコシステムツールがデュアルチェーン署名を「自動的にサポート」できるわけではなく、極端なシナリオでは互換性の問題が容易に発生する可能性があります。

一部の高度な操作（特にチェーンネイティブのガバナンス、委任など）には専用の Substrate ウォレットが必要であり、接続エクスペリエンスは純粋な EVM チェーンに比べて依然として劣っています。

複数の資産やトークン（ネイティブ、ERC20、Substrateアセット）が関与するクロスチェーンシナリオでは、依然として異なる形式のアドレス/ID、承認ロジック、マッピングテーブルの管理が必要です。開発と運用には依然としてメンテナンスの複雑さが伴い、一部のチェーン間転送は後処理にXCMまたはブリッジプロトコルに依存しているため、同期の遅延が発生します。

ほとんどのEVMコントラクトはガバナンスを通じてアップグレードできますが、アップグレードの柔軟性とアクセス制御は、Substrateランタイムアップグレードと完全に同等ではありません。極端なケースでは、一部のアセットとコントラクト状態の移行に、純粋なEVM操作ではなく、チェーンレベルの調整が必要になる場合があります。

免責事項

PaperMoonが提供し、本記事に含まれる資料は教育目的のみに使用されます。財務または投資に関するアドバイスを構成するものではなく、また、いかなるビジネス上の意思決定の指針として解釈されるべきではありません。投資またはビジネス関連の意思決定を行う前に、読者の皆様には独自の調査を行い、専門家にご相談されることをお勧めします。PaperMoonは、本記事の内容に基づいて行われたいかなる行動についても一切責任を負いません。

続きを読む

https://polkadot-evm.github.io/frontier/概要

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