2024年にGavin Woodが発表したJAM（Join-Accumulate Machine）プロトコルは、ブロックチェーン技術の新たな方向性として業界内に大きな反響を呼びました。JAMはPolkadotのリレーチェーンを将来的に置き換えることを視野に入れた次世代アーキテクチャであり、その設計思想は従来のスマートコントラクトプラットフォームとも、現在のPolkadot 1.0とも大きく異なります。
本記事では、JAMプロトコルの計算モデルである「Join-Accumulate」の概念から、実行環境として採用されるPVM（Polkadot Virtual Machine）、そして「サービス」という新しい抽象化まで、技術的な内容をできる限り平易に解説します。
JAMはまだ研究・開発段階にあり、仕様は変更される可能性があります。投資判断や技術採用の意思決定には、公式の最新情報を必ず参照してください。
1. JAMが生まれた背景：なぜPolkadotの再設計が必要か
1-1. Polkadot 1.0の設計上の制約
Polkadot 1.0はリレーチェーンを中心とした設計で、パラチェーンが接続することで共有セキュリティを享受できます。しかし、この設計にはいくつかの根本的な制約があります。
- リレーチェーンが処理できるパラチェーン数に上限がある（数十〜百程度）
- パラチェーンはWebAssembly（WASM）ランタイムとして実装する必要があり、任意のロジック実行には制約がある
- リレーチェーン自体はスマートコントラクトを直接実行しない
Polkadot 2.0のアジャイルコアタイムでこれらの多くは改善されますが、Gavin Woodはさらに根本的な見直しが必要だと判断し、JAMを提案しました。
1-2. JAMのビジョン：汎用計算機としてのL1
JAMのビジョンを一言で表すと「汎用的な計算機能を持つLayer 1ブロックチェーン」です。現在のPolkadotリレーチェーンはパラチェーンの状態を検証・最終化することが主な仕事ですが、JAMではリレーチェーン相当のレイヤーが任意の計算を実行できる基盤となります。
これはEthereumのスマートコントラクトよりも汎用的で、Solanaのような単一のグローバルな実行環境よりもスケーラブルな中間的なポジションを目指しているとも言えます。
1-3. JAMグレイペーパーの発表とコミュニティの反響
JAMは「グレイペーパー（Gray Paper）」と呼ばれる仕様書として公開されており、Gavin Woodのブログ・Polkadotフォーラム・各種カンファレンスで詳細が説明されています。仕様は現在も更新が続いており、実装チームからのフィードバックを受けて細部が修正されることがあります。最新バージョンのグレイペーパーはJAMの公式リポジトリで確認することが推奨されます。
2. Join-Accumulate計算モデルの仕組み
2-1. 「Join」フェーズ：並列処理による高スループット
JAMの計算は大きく「Join（結合）」と「Accumulate（蓄積）」の2フェーズに分かれます。まず「Join」フェーズを理解しましょう。
Joinフェーズはコア（Core）上で並列実行される処理です。各コアは独立した計算を行い、その結果をブロックに「結合（Join）」します。この並列処理こそがJAMの高スループットの根拠であり、341個のコアが同時並行で動作することで、現在のPolkadotパラチェーンモデルよりも大幅に多くの処理を同時実行できると期待されています。
Joinフェーズで行われる計算は「精錬（Refine）」とも呼ばれ、サービスのロジックを実際に実行する部分です。この処理はブロックチェーンの外部で実行（オフチェーン的な側面を持つ）され、結果のみがブロックチェーンに記録されます。
2-2. 「Accumulate」フェーズ：状態の更新と最終化
「Accumulate（蓄積）」フェーズでは、Joinフェーズで得られた結果を使ってブロックチェーンの状態を更新します。Accumulateはシーケンシャルに実行され、グローバルな状態整合性を保ちます。
この設計のポイントは、処理の多くをJoin（並列）で済ませ、Accumulate（シーケンシャル・コスト大）は最小限にするという点にあります。これにより、スループットを高めながら状態の一貫性を維持するというバランスを取っています。
2-3. トランスファー（Transfer）：サービス間通信
JAMではサービス間の通信にトランスファー（Transfer）という仕組みが使われます。一方のサービスが別のサービスにトークンやデータを送ることで、サービス間の連携が実現します。これはXCMの役割を果たす要素であり、JAMレベルでのチェーン間通信の基盤となります。
3. PVM（Polkadot Virtual Machine）の設計と特徴
3-1. なぜWASMからPVMへ移行するのか
現在のPolkadotはパラチェーンランタイムの実行環境としてWebAssembly（WASM）を採用しています。WASMはブラウザ向けに開発された実行環境で、移植性と安全性が高い一方、ブロックチェーン向けに最適化されているとは言い難い側面があります。
JAMではPVM（Polkadot Virtual Machine）という独自の仮想マシンが導入されます。PVMはオープンソースのRISC-V命令セットアーキテクチャをベースにしており、以下の点でWASMより優れていると主張されています。
- よりシンプルな命令セットによる実装の容易さ
- ガスコストの精密な計算（各命令のコストが明確）
- 将来的な専用ハードウェアでの高速実行の可能性
- 検証可能なプログラム実行（formal verification）との相性の良さ
3-2. RISC-Vベースの利点と課題
RISC-V（リスク・ファイブ）はオープンで拡張可能な命令セットアーキテクチャで、組み込みシステムからサーバー向けCPUまで幅広く採用されつつあります。ブロックチェーンVMにRISC-Vを採用した主要事例は少なく、PVMは先進的な取り組みと言えます。
一方で、既存のEVM（Ethereum Virtual Machine）エコシステムやWASMエコシステムとの互換性が失われるため、既存ツールやコントラクトの移行コストが発生する可能性があります。エコシステムの移行期間中は開発者の混乱が生じるリスクも考慮すべき点です。
3-3. PVMとEVMの互換性レイヤー
JAMの上でEVM互換の実行環境（MoonbeamのようなEVMパラチェーン相当）を動かすには、EVMコードをPVMに変換・実行する互換性レイヤーが必要になります。この互換性レイヤーの開発も進んでいるとされており、既存のEthereumエコシステムとの連携が完全に断たれるわけではないと見られています。
4. サービス（Service）アーキテクチャ：パラチェーンを超えた柔軟性
4-1. サービスとは何か
JAMにおけるサービス（Service）は、現在のパラチェーンに相当する概念ですが、より汎用的かつ軽量に設計されています。サービスはJAMコア上で実行されるプログラムで、独自の状態（State）とロジックを持ちます。
パラチェーンとの最大の違いは柔軟性です。パラチェーンは完全なブロックチェーン（ブロック生成・検証機能を含む）として実装する必要がありますが、JAMのサービスはより小さな粒度のプログラムユニットとして実装できます。
4-2. サービスの種類と用途
JAMのサービスは理論的には任意のロジックを実装できるため、以下のような多様なユースケースが考えられます。
- スマートコントラクトプラットフォーム：EVMやWASMベースのコントラクト実行環境をサービスとして実装
- ロールアップ：EthereumのOptimistic RollupやZK-Rollupと類似した仕組みをJAM上で実現
- データ可用性レイヤー：他のブロックチェーンのデータ可用性を保証するサービス
- プライバシー計算：ZK証明の生成や機密データ処理を担うサービス
- オラクル：外部データをブロックチェーンに取り込むサービス
4-3. サービスとコアタイムの連携
サービスがJAMコア上で実行されるには、コアタイムを確保する必要があります。コアタイムの取得・管理はPolkadot 2.0で導入されるコアタイム市場を通じて行われる見通しです。JAMへの移行後も、コアタイムという概念はネットワークリソース配分の基本単位として機能し続けると考えられています。
5. JAMのコンセンサスとセキュリティ
5-1. SAFROLEとBANDERSNATCH
JAMのコンセンサスメカニズムにはSAFROLEとBANDERSNATCHという要素が含まれます。SAFROLEはブロック生成者の選択に関連するプロトコルで、BANDERSNATCHはブロック生成者のアノニマスな選択を可能にする暗号プリミティブです。
BANDERSNATCHを使うことで、次のブロック生成者が誰であるかを事前に知ることができないため、特定のバリデーターへのDDoS攻撃が難しくなるというセキュリティ上の利点があります。
5-2. GRANDPA・BEEFYとの関係
現在のPolkadotはGRANDPAという最終化（Finality）プロトコルを使っており、BEEFY（Bridge Efficiency Enabling Finality Yielder）によってブリッジ向けの軽量な最終化証明を提供しています。JAMでもこれらの概念を引き継ぎつつ、より効率的な実装が目指されています。
5-3. データ可用性（DA）サンプリング
JAMではデータ可用性（Data Availability）の問題にも取り組んでいます。コア上で実行されたサービスのデータが実際に利用可能であることを保証するための仕組みが設計されており、特定のバリデーターだけがデータを持つ状況を防ぐためにイレイジャーコーディングが活用されます。
6. JAMの開発ロードマップと現在の進捗
6-1. JAM Toaster：実装テスト環境
JAMの実装を検証するため、JAM Toasterと呼ばれるテスト環境が開発されています。JAM Toasterは1,000台以上のノードからなる大規模テストネットで、JAMのスケーラビリティを実証することを目的としています。
6-2. JAM Prize：実装競争の奨励
Polkadot財団はJAM Prizeを設定し、JAMプロトコルの独立した実装を奨励しています。複数の実装が存在することで、クライアントの多様性が生まれ、単一クライアントのバグによるネットワーク全体の停止リスクを軽減できます。これはEthereumがMultiple Client Strategyを採用しているのと同様の発想です。
6-3. JAMとPolkadot 2.0の関係
JAMはPolkadot 2.0の延長線上にある将来の構想であり、Polkadot 2.0（アジャイルコアタイム）が先行して実装される予定です。JAMへの移行はその後の段階的なアップグレードとして位置づけられており、Polkadot 2.0が稼働してからJAMへの本格移行が始まると見られています。
まとめ
JAMプロトコルはPolkadotの次世代アーキテクチャとして、Join-Accumulate計算モデルによる高スループット・PVMによる効率的な実行環境・サービスという柔軟な実行単位を組み合わせた野心的な設計です。現在のブロックチェーンが抱えるスケーラビリティとプログラマビリティのトレードオフを新しいアプローチで解決しようとしています。
一方で、JAMはまだ開発段階にあり、仕様の確定・実装・テスト・ガバナンス承認・本番稼働まで多くのステップが残っています。技術的な可能性に対する期待と、実装リスクを冷静に見極めることが重要です。
よくある質問（FAQ）
Q1. JAMが実装されると、現在のパラチェーンはどうなりますか？
JAMへの移行は段階的に行われる予定であり、既存のパラチェーンがすぐに廃止されるわけではありません。パラチェーンはJAMの「サービス」として再実装されるか、移行期間中は従来の仕組みで動作し続けると考えられています。具体的な移行計画はPolkadotのガバナンスを通じて決定されます。
Q2. PVMはEVMと互換性がありますか？
PVMとEVMは命令セットが異なるため、直接の互換性はありません。しかし、PVM上でEVMの動作を模倣するコンパイラ・インタープリタを実装することは技術的に可能であり、EVM互換レイヤーの開発が進められています。詳細はJAMの公式リソースを参照してください。
Q3. JAMの開発状況はどこで確認できますか？
JAMの最新情報はGavin Woodの公式ブログ・Polkadotフォーラム・GitHubリポジトリ（polkadot-fellows/jamテストネット等）で確認できます。グレイペーパーの最新版も公式サイトから入手可能です。日本語情報はPolkadot Japanコミュニティが発信していることがあります。
※本記事は情報提供を目的としており、投資を推奨するものではありません。暗号資産への投資は元本割れのリスクがあります。投資判断はご自身の責任で行ってください。
