Gavin Woodの講演：JAMの進捗状況と、ZKをJAMに導入する中長期戦略！

この記事は、先月のWeb3 SummitでのGavin Woodの講演の日本語版です！内容が多いため、4部構成で公開します。本記事は第1部で、主な内容は以下の通りです：

• JAMの進捗状況
• ZKの性能は進歩したが、商用化にはまだ遠い
• 33回の再計算 vs 数学的証明：2つのセキュリティモードの実際のコスト
• ZK-JAMノードのコストは？答えは想像の10倍高い！
• JAMにおけるZKの短期・中期・長期の進化パス

それでは、Gavinがどんな素晴らしい見解を共有したのか、一緒に見ていきましょう！

では、早速ですが、今回の講演で何を話すのか？

まず、Polkadot全体に対する私の見解、つまり現在の思考の位置を共有したいと思います。これは「現状のスナップショット」とも言えます。皆さんは既にJAMについて聞いたことがあるかもしれません。これは私が長期的に研究しているプロジェクトで、Polkadotと密接に関係しています。最終的にはPolkadotの次の発展段階を支えることを目指しています。このほか、ゼロ知識暗号技術（ZK）、特にブロックチェーン機能拡張への応用についても話します。

また、DOTのトークン経済モデルについても触れます。さらに、最近私が研究している新しい内容も紹介します。これらの探求は既存能力の改善や、Polkadotおよびより広いWeb3世界に新たな可能性をもたらすことを目的としています。この部分は複数の側面に及び、詳細に説明するものもあれば、簡単に触れるだけのものもあります。それでは本題に入りましょう。

現在のJAMの進捗状況

JAMの最初のバージョンは0.1で、現在は1.0に近づきつつあります。1.0に到達すれば、JAMプロトコルはPolkadotのアップグレードに使用できる準備が整ったことを意味します。プロトコルが徐々に安定するにつれ、私たちの重点は最適化、特にgasモデリングに移っています。今年初め、私はPragueのEthereumカンファレンス（East Prague）でこのテーマについて講演しました。Gasモデリング自体は非常に興味深く、同時に極めて複雑な課題です。

JAMは今年、プロトコル監査を開始する予定です。0.7バージョンシリーズで完了すべき作業は多くありませんが、0.8バージョンではgasモデリングが正式に導入され、作業量が大幅に増加します。今年中に0.9バージョンまで進め、そこで正式に監査を開始できると予想しています。

もちろん、コアプロトコルを持つことと、その上で開発できることは別問題です。SDKやドキュメントなどの開発ツールが必要です。この部分はまだ初期段階です。現在、JAM上でソフトウェア開発は可能ですが、Parityでは主に私がSDKの構築とリリースを推進しています。しかし、現実的には今後数ヶ月から数年にわたる継続的な投資と磨き上げが必要です。もちろん、SDKの開発はParityに限定されません。今後、より多くのチームが独自のJAM SDKを構築することを期待しています。

私たちはすでにクロスサービスメッセージングの標準策定を始めています。これはJAM版のXCM/XCMPと見なせます。同時に、CoreVMは徐々にSDKの一部となり、今後数ヶ月で継続的に強化されます。CoreVMは現在、オーディオ出力、ビデオ出力、データ入出力、トランザクション処理、そして今後追加予定の内部サービスなど多くの機能をサポートしています。現時点ではEVMはサポートしていませんが、今後追加予定です。また、以前coreplayと呼んでいたコア協調スケジューリングの仕組みも、今後12〜24ヶ月で実装予定です。

最近、JAMのチャットグループで非常に興味深い質問がありました。「どのようにして私自身がJAMのシングルポイント・オブ・フェイラー（single point of failure）になるのを防ぐか？」現在、JAMプロトコルの進化は完全に私がGray Paperに書いた内容に依存しています。つまり、私に何かあればプロジェクト全体が停滞する可能性があります。これはJAMにも私自身にも良くありません。

したがって、Gray Paperの内容をJAMの技術仕様と見なしています。最新のGray Paperが最新のJAMです。あるバージョンのGray Paperが監査を通過していれば、その定義するJAMプロトコルはプロダクションレベルの成熟度を持つことになります。

では、今後Gray Paperの更新が完全に私の決定によらなくなった場合、どのように進化するのでしょうか？

私の構想は編集委員会を設立することです。初期メンバーは実際にGray Paperの執筆に参加し、深く理解し、実質的な貢献をした人々で構成されます。これらのメンバーがJAMの実装に高い技術的関与を維持することを期待しています。私は完全に退くわけではなく、引き続き編集長を務めますが、自分の作業量を減らし、他の人に提案・審査・修正統合の権限を与えたいと考えています。

JAMが1.0を超えて進化するにつれ、この編集委員会はより高次の責任を担います：

• 小さな変更だけでなく、JAMの発展方向や優先順位を決定する；
• 意見の相違が生じた場合、委員会の集団的判断が最も重視されるべきです。

私は副手を任命する予定です。私が不在や休暇などの場合に業務を引き継ぎます。長期的には、副手が新たな編集委員会メンバーの選定・招待・決定も担当し、仕組みが自律的に運用できるようにします。最終的には、このガバナンス体制が徐々に独立し、Polkadot Fellowshipなど外部組織の参加も受け入れることを望んでいます。

私はGray Paperをオープンライセンスの下に置く予定です。具体的なライセンスはまだ決まっていませんが、copyleftライセンスを選び、特許の濫用を防ぐ条項を加える可能性が高いです。

Polkadotのガバナンスについては、どのプロトコルを運用するかを完全に自分で決定できます。Polkadotは主権プロトコルであり、ガバナンスこそがその主権の体現です。現在、PolkadotガバナンスはJAMを採用したいという明確な意向を示しています。これは良いことです。同時に、他のネットワークもJAMを選択できます。JAMはオープンプロトコルだからです。

今後JAMが進化し続ける場合、Polkadotは最新バージョンに追従することも、特定バージョンで固定することも、コアプロトコルを修正したりGray Paperをフォークすることも可能です。つまり、JAM自体は独立した体系であり、私はPolkadotと長期的に相互利益の関係を維持したいと考えています。もちろん、将来的に両者が独立して発展することも完全に可能です。

両者が一致している限り、PolkadotガバナンスはGray Paper編集委員会の運営に積極的に参加・支援すると予想しています。他のプロトコルがJAMを採用する場合も、同様の形で参加してほしいと考えています。

以上がJAMの現在の進捗、あるいはこれから到達する段階です。次に、ゼロ知識証明（ZK）について話したいと思います。

ZKの性能は進歩したが、商用化にはまだ遠い

多くの人が私にこの質問をします：ZK（ゼロ知識証明）はいつ本当に商用化されるのか？

EthereumはZKに非常に熱心で、ロードマップのほぼ全てがZKを中心に展開されています。一方、JAMでは、ブロック構築の特定のコンセンサスメカニズムで少しZKを使っているだけで、全体としては依存していません。しかし、それでもこれは真剣に考えるべき問題です：

• ZKはいつ本当に計算能力を拡張し、商業的に実用可能な技術になるのか？
• その時は今なのか？
• まだなら、あとどれくらいかかるのか？

Ethereumエコシステムの資料（例えばethprovers.com）を見ると、ZKはすでに経済的に実用可能だという驚くべき数字が並んでいます。しかし、私たちが調査したところ、これらの数字は現実的ではありません。良いニュースは、まだ完全に実用化されていないものの、18ヶ月前と比べて差は大きく縮まったことです。

例えば、現在のJAMの仮想マシンPVM（JAM版EVMに相当）は、コード実行時にネイティブ実行より約34%遅いです。つまり、ネイティブ環境でプログラムを34分で実行できるなら、PVMでは約100分かかります。

この結果はかなり良好で、私たちは満足していますし、さらに改善の余地もあります。

もちろん、場合によっては差が50%以上になることもあります。特にSHA-1ハッシュのようなタスクでは、PVMの実行は遅くなります。これは、ネイティブ環境ではコンパイラがSIMD命令セットや他の最適化手段を使えるのに対し、PVMは現時点でそれができないためかもしれません。

次にもう一つ重要な数字を見てみましょう。これは、現在入手可能な最良のプローバーであるSuccinct SP1を使った場合、実行証明を生成するコスト、つまりPVMで直接実行するのに比べて余分にかかるコストです。ここで比較対象はPVMであり、ネイティブ環境ではありません。PVM自体がすでにネイティブより約34%遅いです。

現在のテスト結果はこうです：最新バージョンのソフトウェアを使い、GPU1枚のみを使用（公開コードベースは単一GPUのみ対応）。クローズドソースの商用版ならGPUクラスターに拡張できるかもしれませんが、オープンソース環境ではこれが限界です。テスト内容は以前と同じくSHA-1ハッシュで、比較の一貫性を保っています。

では、何が変わったのでしょうか？

18ヶ月前にも同様の実験を行い、その時のデータは6000万〜6400万のオーダーでした。現在のコストは明らかに大幅に下がっています。

理由は主に2つあります：

• 一つはGPUレンタル価格が安くなったこと；
• もう一つはソフトウェア自体が大幅に最適化され、1桁以上の向上があったことです。

補足すると、18ヶ月前に使ったプローバーはSP1ではなくRISC-0でした。しかし、いずれにせよ、最先端技術が急速に進歩していることは明らかです。

2025年7月時点で、SP1（Succinctのプローバー）を使って実行トレースの証明を生成するコストは、PVMで同じ計算を安全に実行するより306,451倍高いです。過去18ヶ月で証明コストは約200倍下がりましたが、それでも非常に大きな値です。ZK技術は確かに急速に進歩していますが、依然として直接実行よりはるかに高価です。

次にGas計測について話しましょう。

コードの実行が速いことは重要ですが、もっと重要なのはそれを信頼できることです。誰かが意図的に「遅くなる」コードを書いたらどうなるでしょうか？コンセンサスメカニズムでは、システムが規定時間内に合意に達する必要がありますが、そのコードが悪意を持って遅く設計されていた場合、システム全体が停止または麻痺する可能性があります。

Polkadotではこの問題はそれほど深刻ではありません。なぜなら、パラチェーンスロットオークションがあるからです。つまり、システムにコードを提出できる人の身元は基本的に明らかで、実際にお金を払ってスロットを獲得しているため、自己利益に反する破壊行為をする可能性は低いです。

しかし、よりオープンで汎用的な環境に拡大すると問題は深刻になります。

解決策は何でしょうか？

それは、コードの実行時間の上限、つまり最悪の場合どれだけ時間がかかるかを事前に大まかに見積もることです。そして、どんな場合でもその最悪ケースより遅くならないことを保証します。もし誰かが予想より10倍遅いコードを書けるなら、それは大問題です。

では、現在の最悪ケースの見積もりはどの程度でしょうか？

SHA-1ハッシュを例にすると、現在の結果は：安全を確保するためには、通常より4.5倍遅くなる可能性を想定しなければなりません。つまり、通常1秒で終わるコードでも、最悪ケースでは4.5秒かかると見積もる必要があります。これで、どんな悪意ある攻撃者でもそれ以上遅くできません。

この「何倍か多めに見積もる」方法こそが、時間制約のあるコンセンサスメカニズムで安全性を確保するために必要です。

将来的には、この倍率はさらに下がるはずです。つまり、見積もりがより正確かつ効率的になります。現在の4.5倍は、1〜2週間の努力で得られた最良の結果です。楽観的に見れば、将来は3倍程度まで下がるかもしれませんが、それ以上は難しいでしょう。

33回の再計算 vs 数学的証明：2つのセキュリティモードの実際のコスト

PolkadotとJAMでは、elvesというプロトコルを使って計算の安全性を保証しています。その役割は、ある計算が確実に正しく実行されたことを確認することです。

本質的に、elvesとゼロ知識証明（ZK）は少し似ています：

• ZKは数学的証明を使い、「鉄壁の証拠」を直接提供します；
• elvesは暗号経済学的なゲームで、参加者が署名とルールで結果の正しさを証明します。前提は「悪人が3分の1を超えない」ことです。

elvesを実行する際、計算は繰り返し実行されます。参加者はランダムに自分が再計算を行うかどうかを決めます。

結果として、このモードでは作業が平均して約33回再実行されます。したがって、コストは通常実行の約33倍です。

これで、ZKとelvesのコスト差が計算できます。答えは：ZKはelvesより約4000倍高いです。つまり、ゼロ知識証明で正しさを検証するコストは、elvesという暗号経済学システムよりはるかに高いです。これは異なるRollup方式のコスト比較とも言えます。

PolkaWorld注：elvesはクラスの33人全員が宿題を写して最後に答え合わせをして確認するイメージ、ZKは数学博士に「絶対に間違いない証明」を書いてもらうイメージですが、博士が証明を書くのに数日かかるかもしれません。

4000倍という差は非常に大きく、ZKを実用化するにはコストを大幅に下げる必要があります。もちろん、elvesもさらに効率化できます。

ただし、コスト問題はハードウェアだけではありません。いくつか重要な点があります：

• 運用コスト（sysadmin）：どんなハードウェアを使っても運用担当者の給与はほぼ同じです。多くの場合、運用コストはハードウェアより高いこともあります。
• ステーキングコスト：悪人が3分の1を超えないようにするため、システムにはフィルタリング機構が必要です。Polkadotでは「ステーキング＋ペナルティ」で実現しています。つまり、参加者は一部資金（リスク資本）を担保にし、「良いバリデーター」と「悪いバリデーター」を区別します。

問題は、ステーキング自体も高コストで、これが追加コストとなることです（後ほど詳しく説明します）。

対照的に、ZK自体にはステーキングの負担がありません。ZKのロジックは単純で、正しいか間違いか一目で分かります。

しかし、問題はZKの証明生成が非常に遅いことです。単一GPUで実行すると数時間かかる場合もありますが、PVM（または通常のCPU）で同じ計算を直接実行すれば数ミリ秒から数秒で済みます。差は歴然です。

ただし、GPUクラスターによる並列化で遅延を短縮できることは既に示されています。十分な数のGPUを接続すれば遅延は下がりますが、問題は：

並列化の効率係数が不透明で、コストがどれだけ増加するかは不明です。実験した人はこのデータを公開していませんし、公開したくないかもしれません。したがって、自分で実験設計やコード開発をするか、未発見の関連研究を探す必要があります。

このほか、検証と決済の問題もあります。

例えばEthereum L1で検証する場合、コストは証明生成より高いこともあります。私たちの試算では、証明生成は約1ドル〜1.20ドルですが、Ethereum L1での検証は1.25ドルかかります。もちろん、独自チェーンなら検証コストは安くなりますが、それでも：

• 検証（verification）
• 決済（settlement）
• ファイナリティ（finality）
• ストレージ（storage）

これらの工程はZKでも消せません。最終的には、悪意ある参加者が3分の1を超えないことを保証する必要があり、結局はステーキングに戻ります。これはEthereum L1、Polkadot、ほとんどのチェーンと同じです。

ZK-JAMノードのコストは？答えは想像の10倍高い！

では、別の観点から考えてみましょう。ZK-JAMの担保ノード（guarantor node）の運用コストはどれくらいでしょうか？

簡単に説明すると、JAMには担保人（guarantors）という役割があり、彼らはシステムの「門番」のような存在です。全てのトランザクションやタスクはまず彼らが処理し、計算結果をまとめて他のバリデーターに渡します。バリデーターは結果を再確認することもあれば、しないこともあります。

ここで仮定するシナリオは：

• 再確認を省略（他人が担保人の作業を再チェックしない）；
• ステーキング要件を下げる（担保人の信用に完全依存しない）；
• 担保人にGPUクラスターを強制し、ZKで証明を生成させる。

この場合のコストは？

試算によると、ZK証明生成コストは約1.18ドル（SHA-1の場合、6秒の計算量・12MBのI/O）。これはJAM coreが1スロットで処理できる作業量に相当します。JAMには合計341coreあり、これは1coreあたりのコストです。

もちろん、これは大まかな見積もりです。タスクによってコストは上下しますが、だいたいこのオーダーです。

年換算すると、1coreあたり年間約950万ドルです。

ここでは、GPUクラスターの並列化による追加コストを50%と仮定しています。これは遅延を下げるためですが、50%はあくまで推測で、実際は5%かもしれませんし、200%かもしれません。確実なのは追加コストが必ず発生し、それが小さくない可能性があることです。

では、Polkadotの現行ステーキングメカニズムと比べると？

現行メカニズムでは、elves（または約80%のelvesセキュリティ）に相当する安全性を提供するには、1coreあたりのコストは100万ドル未満です。

ここでいう80%は、ZKに切り替えても一定のステーキングが必要で、主チェーンの正常運用、決済、ファイナリティ、ストレージなど他の重要部分の安全性を確保するためです。

• 主チェーンの正常運用
• 決済
• ファイナリティ
• ストレージ

これらは非常に重要ですが、計算の正確性がステーキングコストの約80%を占めます。

341coreを運用し、現在のPolkadotのステーキング経済モデルを維持すれば、コストはこの通りです。core数が減れば、1coreあたりのコストは逆に上がります。なぜなら、ステーキングの「総額」は変わらず、分担する人数が減るからです。

まとめると、現時点でZKのコストはelvesの約10倍です。

もちろん、安全コストを下げられれば（これは可能だと思います）、例えば916万ドルから270万ドル、さらに新しい仕組みを組み合わせて144万ドルまで下げられれば、ZKとelvesのコスト差は縮まります。ただし、144万ドルはかなり楽観的な見積もりです。

最終的な結論は？

ZKのコストは確かに徐々に下がっていますが、それでも現時点ではelvesより10〜100倍高いです。さらに、決済、ストレージ、ファイナリティなど追加の不確定コストもあります。これらはJAMが内蔵サポートしていたり、elvesが利用できたりしますが、ZKではできません。

また、elvesには超線形スケーリングという利点があります。つまり、複数のJAMネットワークを接続し、同じバリデーターセットを共有でき、全体の効率が向上します。ZKにはこの能力がなく、リニアにしか増やせません。別のcoreの証明を生成するには、同じコストを再度支払う必要があり、合併や再利用はできません。

JAMにおけるZKの短期・中期・長期の進化パス

したがって、戦略的観点からどの道を選ぶかは状況次第です。

私が考える合理的な戦略は：

• 証明コストを下げる：少なくともあと1〜2桁下げる必要があります。過去の経験から、これには18ヶ月〜5年かかるかもしれません。
• オープンソースツールが必要：GPUクラスターで効率的に分散証明生成できるツールが必要です。現時点では成熟したツールはなく、最速でもありません。これがなければ、現在のコスト見積もりも信頼できません。
• coreの価格問題：coreの市場価格がelvesモードに合理的な範囲に収まっていれば、ZKの優位性はなくなります。
• セキュリティ選択：市場が2つのセキュリティ（ZKの「完全な安全」とelvesの「経済的制約下の安全」）を区別できる必要があります。市場がどちらを重視するかはまだ不明です。
• 高額ステーキング依存の排除：大規模なステーキングに依存せず、JAM/elvesが担当する他のタスク（ストレージ、決済、ファイナリティ）を完了できる必要があります。今のように大量のステーキングに依存していれば、ZK案は高コストになるだけです。

これらを踏まえた上で、私が提案するZK戦略は：

• まず試しやすい方向から始める：例えばZK-JAMサービスフレームワークを開発し、現行JAMの暗号経済学的仕組み（elves）で安全性を提供する。
• JAMの強みを活かす：JAM coreは強力な計算能力（CPU）と十分なI/O（12MB）を持ち、PVMの実行効率も高い。つまり、JAM core内で大量のZK検証を直接行えるため、外部の高コストな証明プロセスを経る必要がありません。
• 証明プロセスの最適化：従来のZK証明プロセスは複数段階に分かれ、最後に「証明圧縮」で証明を小さくし検証を容易にします。しかしJAM core内では計算力が十分なため、この工程を省略でき、コスト削減が可能です。
• ストレージ証明を優先：JAM coreは計算能力が高い一方、I/Oはやや不足しているため、ストレージ証明でこの弱点を補い、大量トランザクションの高速処理を実現できます。
• 他の簡単なタスク：例えば署名検証は元々容易で、ボトルネックにはなりません。

つまり、本当の難題は、トランザクションが依存するデータの正確性を保証することです。これこそが重点的に解決すべき課題です。

中期的には、より合理的なアプローチは：

私たちはすでに新しいKusamaビジョン——ZK対応ネットワークの構築——を持っています。この予算と他チームとの協力を活用し、効率的かつ分散可能な証明生成ツールに重点投資するのが最適です。

• 今この分野に取り組むチームがなければ、新規プロジェクトを立ち上げる；
• 既に取り組むチームがある、または転向可能なら、彼らと協力し、成功を支援する。

特に注目すべきはPVM実行証明です。これは将来ZK-JAMと通常JAMの互換性を保つ鍵であり、分散証明生成も不可欠です。

目標はシステムのモジュール化とオープン性を維持し、最先端研究に追随することです。技術進歩に遅れずについていくことで、証明コストをさらに数桁下げ、商業的実用性を実現できます。

長期的には、ZKをコアソリューションにしたいなら、ステーキング（staking）に代わる方法を見つける必要があります。ステーキングが残る限り、コストは非常に高くなります。

では、完全にZKベースのJAMをどう実現するか？

まず、これはZKのコストが十分に下がり、coreの利用率が現行モードで経済的に成立しないと確定した場合にのみ意味があります。現時点では確定できないので、条件付きの構想です。

条件が整えば、JAMを多モードセキュリティモデルに進化させられます：

• 一方で、安価だが限定的な安全性（elves類似、低コスト）を提供；
• 他方で、高価だがより強力な完全安全性（ZK依存、コストはリニア増加）を提供。

鍵となるのは、ステーキングに依存せずにファイナリティ（finality）とストレージ（storage）を実現する方法を見つけることです。

一つの方向性は人格証明（Proof of Personhood）です。これをコアプロトコルに統合できれば、効率と資金活用率が大幅に向上します。

ただし、これを実現するには非常に強力なアンチシビル攻撃メカニズム（anti-sybil mechanism）が必要です。現状ほとんどの案は十分強力ではなく、権威機関に依存したり、特定組織がユーザーデータを収集して本人確認を行うものが多いです。この方法は明らかに中央集権的で、実用に近い案はごくわずかです。