3つのケースでReviveとPolkadot Hubが実現できることを紹介！

この記事は、PolkaWorldがParityのSub0カンファレンスでの講演内容をまとめたものです。

ここ数年で、Polkadotは強力で柔軟なモジュラーシステムへと発展してきました。しかし、明らかな課題もあります。多くのコア機能が異なるチェーンに分散していることです。

例えば：

• スマートコントラクトエンジンは一部のパラチェーンにしか存在しません； 
• ガバナンス、ステーキング、ネイティブトークンなどのシステムは、他のパラチェーンやシステムチェーンにあります。 

この分散により、非常に複雑になっています。ごく単純なアプリケーションフローであっても、複数のチェーン間でのやり取りや非同期通信に依存しなければなりません。

Polkadot Hubはこの状況を根本から変え、すべてを大幅に簡素化します！

Polkadot Hub：すべての機能を一箇所に集約

自己紹介します。私はTorstenで、Parityのスマートコントラクトチームを担当しています。本日は、Polkadot Hubとその内蔵スマートコントラクト実行エンジンについて、これらの新機能がPolkadot上でのアプリケーション構築方法をどのように再定義するかをお話しします。

まず、過去の課題を振り返ります。従来のアーキテクチャでは：

• スマートコントラクトはパラチェーン上にしかデプロイできません； 
• ネイティブトークン、ステーキング、ガバナンスなどのロジックはリレーチェーンやシステムチェーンに分散しています。 

つまり、これらのシステムをまたいで少しでも組み合わせる必要がある場合、XCMや複雑な非同期メッセージフローに依存しなければなりません。

その結果：

• 開発者はアプリケーションをどのチェーンにデプロイすべきか分からない；
• 全体のフローが断片化し、ツールチェーンも統一されていない；
• チェーンごとに動作方式が異なり、開発体験が非常に分断されている。 

しかし今、すべてが変わろうとしています。Polkadot Hubがまもなく登場するからです！

Polkadot HubはPolkadotエコシステムにおける新しい「アプリケーションセンター」です。これまで分散していたすべての重要な機能：

• アセット 
• ネイティブトークン 
• ステーブルコイン 
• ステーキング 
• ガバナンス 
• スマートコントラクト 

これらすべてを同じ環境に集約します。

Hubの登場により、これまでのチェーン間の境界は取り払われ、今後Polkadotアプリケーションは全く新しい方法で構築・デプロイされることになります。

スマートコントラクトはデュアルエンジン時代へ：ReviveがPolkadotのアプリケーション層を再構築

次に、私が最も注目している部分——Hubのスマートコントラクト実行エンジンについて話します。

この実行エンジンはReviveと呼ばれます。最大の特徴は、Reviveが2つの実行環境を内蔵し、2種類のスマートコントラクトシステムを実行できることです。

• 一つはおなじみのEVMで、Solidityで書かれたEVMコントラクトを直接実行できます； 
• もう一つはよりモダンなPVMで、SolidityまたはRustで記述可能です。 

特に注目すべきは、EVMとPVMは2つの孤立した世界ではなく、同じアドレス空間で動作し、相互に呼び出しが可能なことです。つまり、一方のシステムのスマートコントラクトがもう一方のシステムのスマートコントラクトと完全に相互運用できるのです。相互呼び出し時、相手がPVMコントラクトかEVMコントラクトかを意識する必要はありません。

さらに、Reviveはプリコンパイル（precompiles）を通じて、スマートコントラクトがランタイムのコア機能（ステーキング、ガバナンス、アセット管理、XCMなど）に直接アクセスできるようにしています。これらのコンポーネントはReviveとシームレスに連携します。

次に、Reviveでアプリケーションをデプロイする方法を簡単に説明します。現在、SolidityまたはRustの2つの言語を選択できます。

Solidityを使う場合、従来のSolidityコンパイラでコードをEVMバイトコードにコンパイルし、ReviveのEVMエンジン上で実行できます。また、Parity独自開発のResource Cコンパイラを使えば、SolidityコードをPVMバイトコードにコンパイルし、PVMエンジンにデプロイできます。EVMコードもPVMコードも相互に呼び出し可能です。 

Rustを使う場合、RustコンパイラでPVMスマートコントラクトとしてコンパイル・デプロイできます。これらのコントラクトもランタイムコンポーネントと直接やり取りできます。 

なぜReviveに2つの実行エンジンが必要なのか、それぞれのメリットについて説明します。

PVM：高性能でモダンな実行エンジン

PVMは全く新しいスマートコントラクト実行環境で、従来のEVMよりはるかに高い計算能力を提供します。したがって：

• より大規模で複雑なスマートコントラクトをデプロイできる 
• これまでほぼ不可能だった新しいタイプのアプリケーションを構築できる 

PVMはRISC-V命令セットに基づいています。Ethereumも将来的にRISC-Vを検討していますが、Reviveはすでに先行して採用し、開発者はすぐにこの技術を利用できます。

Reviveの実行方式は2種類あります：

• インタプリタ実行モード（現行モード、パフォーマンスは標準的） 
• JIT（Just-In-Time）コンパイルモード（来年公開予定、パフォーマンスを最大限に発揮） 

JITモードでは、スマートコントラクト内で非常に重い計算も実行可能です。例えば：

• 複雑な数学演算 
• 暗号アルゴリズム（EVMではほぼ不可能） 

EVMでは新しい暗号プリミティブを追加したい場合、ネットワーク全体でプリコンパイルをアップグレードする必要があり非常に面倒ですが、PVMではスマートコントラクト内で「独自のプリコンパイル」を直接実装できます。十分な計算能力があるからです。

それでもなぜEVMが必要なのか？

EVMにも明確なメリットがあります：

• Ethereumや他のEVMチェーンで動作していたプロトコルをそのままReviveに移行できる
• コードの修正不要 
• ツールもそのまま使える 
• FoundryやHardhatも引き続き利用可能 
• デプロイはすぐに可能 

さらに、EVMコントラクトとPVMコントラクトはシームレスに相互呼び出しできます。

特に強調したいのは、元々のプロトコルが古いバージョンのSolidityコンパイラでコンパイルされている場合、そのバイトコードはPVM上で動作しないことがありますが、ReviveのEVMエンジンでは全く問題ありません。

これがEVMエンジンが必要な理由——EVMとの完全な互換性を保証するためです。

ただし、私たちのEVMエンジンと標準Ethereumの間には重要な違いがあります。それはgasとリソースの扱い方です。

一般的に、すべてのEVMチェーンのgas計算方法は同じですが、Polkadotでは通用しません。Polkadotは基盤で全く異なるリソース管理システムを使っているからです：

• Polkadotのリソースはweights（重み）と呼ばれ、2次元で、2種類の異なるリソースを計算する必要があります； 
• さらに、Reviveのスマートコントラクトエンジンは3つ目のリソース：ストレージデポジット（storage deposit）を追加しています。 

つまり、システム内部では実際に3種類のリソースを管理しています。

それでも外部にはEthereumのツールチェーンと同じ使い勝手を維持したいので、これらを「gasのように見えるリソース」としてマッピングしています。言い換えれば、EthereumウォレットはPolkadotの内部リソースを理解しないため、Ethereum式のgasをエミュレートする必要があります。内部的には、3種類のリソースを決定論的に「gas」にマッピングしています。

システムは複雑でEthereumと細かな違いもありますが、開発者が正しいgas推定に依存し、ハードコード値を使わなければ、実際の利用に影響はありません。

この仕組みにより、Ethereumとの互換性を維持しつつ、スマートコントラクトに必要なDOS防御能力も確保できます。

3つの事例で見るReviveとPolkadot Hubの可能性

次に、視点をPolkadot Hub全体に戻します。

ここで重要なプロジェクトを紹介します：Asset Hub Migration（アセットセンター移行）。これはPolkadot Hubの基盤を整え、ステーキング、残高、アセット、ガバナンスを同じ統一環境で動作させる役割を果たします。

Asset Hub Migrationは最近完了したばかりで、おそらく数週間前のことです。

今、すべての準備が整い、Reviveはこの環境でその能力をフルに発揮できます。

これこそがReviveのために設計された理想的な環境であり、今後Polkadot Hubでスマートコントラクトを動かす最適な場所です。

次に、ReviveとPolkadot Hubで何ができるのか、3つの例を挙げます。

この統一環境では、スマートコントラクトは：

• ガバナンスやステーキングに直接アクセスできる 
• ネイティブ残高や他のアセットに直接アクセスできる 
• すべての操作が同期的に完結し、クロスチェーンの非同期通信は不要 

1つ目の例として、スマートコントラクトがガバナンス状態を直接読み取り、ガバナンス提案の変化に反応したり、ガバナンスイベントに応じて独自のロジックをトリガーできます。これらすべてが同じシステム内で即時に完結します。

もう一つの例は、PVMによってより複雑なワークロードが可能になることです。先ほど述べた通り、PVMのJITコンパイルモードは来年公開予定で、その時に計算性能が完全に解放されます。

PVMがあれば、オンチェーンで複雑な数学演算を実行可能です。EVMでは計算力が限られているため不可能でした。例えばDeFiプロトコル（貸付プロトコルなど）では、多くの複雑な計算（リスク再評価、ユーザーポジションの更新、市場変動への対応など）が必要です。これらのロジックは従来オンチェーンで実行できず、オフチェーンで処理するしかありませんでした。しかしオフチェーン計算は検証できず、非分散的で、第三者への信頼が必要です。PVMならこれらのロジックを再びオンチェーンに戻し、分散型・信頼不要な方法で実行できます。

このようなプロトコルはオンチェーンでシミュレーション計算も可能です。シミュレーションや特定の状況を試したい場合、今やオンチェーンで直接実行できます。シミュレーションは計算量が多く、特にループが必要な場合、従来は実現不可能でした。

先ほど暗号技術についても触れました。今では、複雑な暗号アルゴリズムもスマートコントラクト内で直接実行できます。これらのアルゴリズムは非常に計算負荷が高いですが、PVMはまさにこの用途に最適です。暗号分野で特に重要なのはゼロ知識アプリケーションです。ゼロ知識証明は現在非常に注目されていますが、計算量が大きすぎて、従来はスマートコントラクトで本格的に動作できませんでした。PVMの登場により、これらのゼロ知識アプリケーションがついにスマートコントラクトで実現可能となりました。

続いて、Parityのプロダクト戦略についてお話しします。

ご存知の通り、私たちは多くの新製品を開発しますが、ReviveとPolkadot Hubはこれら製品の基盤となります。もちろん他にも基盤レイヤーはありますが、スマートコントラクト実行エンジンが関わるものはすべてReviveとPolkadot Hub上で動作します。

構造的には、次のように理解できます：

• 最外層がPolkadot Hubで、Hub内でReviveが動作；
• プロジェクトの要件に応じてEVMまたはPVMを選択してアプリケーションを構築；
• その上に、最終ユーザー向けの各種プロダクトが展開されます。

Polkadot Hubは12月に正式ローンチ

最後に、簡単な展望を述べます。

ReviveとPolkadot Hubで開発を始めたい方は、以下の方法からスタートできます。

既存の開発手法を継続したい場合——すでに確立したワークフローがある、またはFoundryやHardhatなどEthereumツールをよく使う場合——EVMを選べば、エンジンはすぐに使えます。

もちろん、PVMを選ぶこともできます。PVM向けにもFoundryやHardhatに似たツールを提供していますが、標準バージョンはPVMやPVMコンパイラをサポートしていないため直接は使えません。ただし、私たちの適合バージョンを使えば、ほぼ同じ方法で利用できます。

さらに、プリコンパイル（precompiles）を通じてPolkadot Hub上の他のコア機能とも連携できます。

ローンチ時期についてですが、Polkadot Hubおよび関連コンポーネントは11月にKusamaへデプロイされ、すぐに利用可能となります。12月にはPolkadotメインネットで正式ローンチされます。

先ほど述べた通り、Reviveのための基礎作業はすべて完了しています。

より高度な機能は来年以降順次公開予定で、特にPVMのJITエンジンを強調したいです。

また、今後は新しいスマートコントラクト言語のサポートなど、さらに先進的な技術も模索しています。ここでは詳細は控えますが、ぜひご注目ください。

Polkadot HubとReviveで開発したい方は、このQRコードをスキャンしてください。

ParityとPolkadotの未来の一員になりましょう！ご清聴ありがとうございました！