4 月 19 日、ドバイで開催された Token 2049 カンファレンスで、ギャビン ウッド氏は次世代の Polkadot テクノロジーの大胆なビジョンを発表しました。 Polkadot が市場にもたらした他の画期的な初物と同様、この新しいビジョンは Web3 の将来に革命を起こすでしょう。これは、Web3 とテクノロジー分野全体の深い革新を推進するために Web3 が必要とする速度、規模、完全な分散化、および使いやすさを提供します。
このビジョンの中心となるのは、Polkadot チェーンの新しいバージョンである JAM です。JAM は、Polkadot の機能を現在の Web3 の境界を超えて押し広げ、同時に Polkadot 上に幅広いテクノロジーを展開できるようにします。 JAM を使用すると、現在ロールアップでのみ見られる画期的なスケーラビリティがコンセンサス層にもたらされます。
開発が完了すると、JAM はサービスとして表現できるほぼすべての種類のタスクを実行できる分散コンピューターになります。 JAM は、Polkadot を同期コンポーザビリティの世界に押し込みます。これにより、断片化が軽減され、アクティビティが統合され、Polkadot 上のアプリケーションがエコシステム全体のネットワークをより適切に活用できるようになります。これにより、深いイノベーションの新たな可能性が開かれ、これまで不可能だった方法で作成できる強力な環境が開発者に提供されます。
JAMは現在研究開発段階にあります。現在、Polkadot コミュニティは、この新しい方向性を確認し、テクニカル フェローシップに JAM を承認する権限を与える提案を投票にかけています (国民投票 682 https://polkadot.polkassembly.io/referenda/682)。
JAM の開発をサポートし、それが真の分散型の精神で構築されることを保証するために、Gavin はスピーチの中で Web3 Foundation と共同で JAM ボーナスの創設を発表しました。総額は 1,000 万 DOT となります。 JAM 開発の他の実装を刺激するために使用されます。
ギャビンはスピーチ中に、技術的な灰色の文書も発表しました。プロジェクトのビジョンと技術的な詳細をさらに詳しく知りたい場合は、この論文を新しい JAM Graypaper Web サイト (https://graypaper.com/) で見つけることができます。
ギャビンとポルカドットは共に、自由でオープンなネットワークを構築するというビジョンの実現を目的とした革新的なテクノロジーの創造を主導しています。 JAM は、進化する Polkadot ストーリーの次の章です。
以下は、Gavin Wood によって書かれた、Polkadot Wiki からの JAM の最新の紹介です。
JAM の正式名は Join-Accumulate Machine で、既存のリレー チェーンを置き換える予定の新しい設計です。 JAM という名前は、Collect Refine Join Accumulate の略で、もともと Gavin Wood による RFC で説明された、マシンによって具現化された計算モデルを表す CoreJAM に由来しています。ただし、実際のチェーンでは結合と蓄積のみが実行され、収集と調整のプロセスはオフチェーンで発生します。
現在の反復的なアプローチとは異なり、JAM は包括的な単一のアップグレードとして導入されます。これを行う理由は次のとおりです。
この移行には大幅な画期的な変更が必要ですが、私たちはその影響を管理可能なレベルに抑えるために懸命に取り組んでいきます。新しいブロックチェーンの概念を導入し、さまざまな既存のアイデアを統合する、複数の小さな破壊的変更を 1 つの移行に組み合わせる方が良いでしょう。
JAM は、特定のドメインの問題に対処するために使用されるドメイン固有のチェーンになります。この場合、それはロールアップであり、イーサリアム コミュニティではオプティミスティック ロールアップと呼ばれています。 JAM のロールアップはセキュリティの点で非常に制限されています。これは、Polkadot が過去 5 年間行ってきたことであり、高度にドメイン固有のロールアップ チェーンになりました。 JAM は基本的に、プリセット設定の数を減らして、より多用途な機能を提供します。
JAM チェーンはロールアップの出力、より一般的には他の場所で行われた計算ビットを受け取り、Polkadot リレー チェーンの機能と同様に、出力を共有状態に統合します。
JAM チェーンの仕事は、変換後の出力が入力を正しく反映していることを確認するために必要な機器を提供することです。
JAM には、スマート コントラクト チェーンとの類似点がいくつかあります。
これらの状態のカプセル化はサービスと呼ばれます。したがって、JAM のステータスはサービスごとに分かれています。新しいサービスの作成は、スマート コントラクト チェーンにスマート コントラクトを展開するのと同様に、許可が必要ありません。したがって、新しいパレットの追加にガバナンスの承認が必要な基板ベースのチェーンとは異なり、JAM チェーンに新しいサービスを追加する場合、権威ある承認やガバナンス メカニズムへの準拠は必要ありません。サービスには、スマート コントラクト チェーンで一般的に見られる構造と同様の、コード、残高、および特定の状態コンポーネントが含まれます。
JAM サービスのコードは 3 つの異なるエントリ ポイントに分かれています:
作業パッケージはサービスへの入力です。作業パッケージには多くの作業項目を含めることができます。各作業項目はサービスに関連付けられており、そのサービスへの実際の入力が反映されます。パラチェーン サービスの場合、ここにトランザクションとすべてのブロックチェーン入力が入ります。
JAM の安全装置は 2 段階の処理で構成されています。Refine 機能は作業項目を入力として受け入れ、作業の結果を出力として生成し、次に Accumulate 機能に入ります (最初に Refine、次に Accumulate)。作業項目は作業結果に絞り込まれます。そのため、多数の作業項目を含む作業パッケージは、複数の作業項目に対応する結果として絞り込まれます。ワーク パッケージは、特定の期間 (通常は 6 秒) コアを使用するように割り当てることができます。
JAM は、トランザクションレスな操作を通じてスマート コントラクト チェーンとは区別されます。 JAM 内にはトランザクションはなく、すべてのアクションは許可がなく、最初は調整フェーズを通過します。この段階で、サービスは入力データを事前に調整し、作業の結果を含む作業レポートに変換します。これらの取り組みの結果はオンチェーンに転送されます。
トランザクションがないにもかかわらず、JAM は特定の形式で外部情報を受け入れます。外部情報には 5 つの種類があります:
2. 保証
4. 事前画像
最初の 3 つのタイプは、JAM チェーン セキュリティ フレームワークの一部です。 「保証」と「保証」には、サービスの「絞り込み」機能を通じて変換されたときに、作業結果が対応する作業項目の結果を正確に反映していることを集合的に証明するバリデーターが含まれます。 判断は、作業結果の完全性が疑問視されるとき、つまり多数のバリデーターがその正当性または欠如を証明するときに行われます。この場合、無効な作業項目がサービスの状態に組み込まれている可能性があるため、ロールバックが必要になる場合があります。判定はチェーンに作業報告書を提出してから1時間以内に行われ、その間はブロックが一時停止される。 プリイメージは、Refine 機能のために JAM チェーンによって提供される機能です。 Refine 関数は通常ステートレスですが、ハッシュ化されたプリイメージの検索という 1 つのステートフルな操作を実行できます。この機能は、Refine 機能の中でデフォルト設定がある唯一の機能です。 チケットは匿名エントリとしてブロック生成メカニズムに入ります。これらはブロック生成の直接の要件ではなく、システムは 2 エポックを事前に実行します。このメカニズムは、元の SASSAFRAS アルゴリズムの改良版である SAFROL アルゴリズムの一部です。 Refine 関数 JAM では、Refine 処理ステージは、期間ごとに最大 15 MB のデータを受け入れることができ、各期間は 6 秒続きます。ただし、Refine によって生成されるデータは最大 90 KB であり、可用性システムの分散型の性質により大規模なデータ圧縮が必要になります。たとえば、パラチェーンのコンテキストでは、15 MB のデータは有効性証明 (PoV) を表し、90 KB のデータは候補受領書に対応します。 Refine は、リレー チェーンの全ブロック期間に相当する最大 6 秒間の PVM ガスを使用できます。 PVF の現在の 2 秒制限と比較して、この延長された実行時間は、安全計測およびその他の最適化によって実現されます。 絞り込みではオリジナル画像検索も行えます。ハッシュとそれに関連付けられたプリイメージが JAM チェーン上で利用可能であると考えられる場合、ハッシュを提供することでプリイメージをリクエストできます。この機能により、パラチェーン コードを JAM チェーンに保存し、ワーク パッケージでそのハッシュを参照するなど、コードの効率的な保存と取得が可能になります。 Refine は主要な処理能力であり、ステートレス操作であるタスクのほとんどを処理します。 Accumulate 関数 Accumulate 関数は、Refine 関数によって生成された出力をチェーン状態に統合する役割を果たします。 Accumulate は、Refine からの複数の出力を受け入れることができ、すべて同じサービスからのものです。 Refine と Accumulate はどちらも、特定のサービス コード ブロックからのエントリ ポイントとして機能します。 Accumulate の出力ごとの実行時間は Refine よりもはるかに短く、通常は最大でも 10 ミリ秒のみです。ただし、期間は作業パッケージ内の作業項目の数によって異なります。ワーク パッケージに複数のアイテムが含まれている場合、使用可能な時間はアイテム間で分割されます。 Refine とは異なり、Accumulate はステートフルであり、JAM チェーンの状態にアクセスできます。任意のサービスからストレージを読み取り、その Key-Value ストアに書き込み、資金を転送し、資金転送時にメモを含めることができます。さらに、Accumulate は、新しいサービスの作成、コードのアップグレード、プリイメージの可用性のリクエストなどを行うことができます。 さらに、Refine は PVM のサブインスタンスを呼び出すことができます。これにより、コードとデータを展開できるサブインスタンスまたは仮想マシンの作成、メモリとスタック構成のカスタマイズ、および柔軟なフレームワーク内での計算の実行が可能になります。
JAM システムの onTransfer 関数もステートフルであり、サービスのステータスを変更できます。他のサービスのステータスを確認し、自身のステータスを変更する機能があります。この機能により、非同期ではあるものの、サービス間の通信が容易になります。
インタラクションが同期的に発生する多くのスマート コントラクト プラットフォームとは異なり、JAM では、カプセル化されたコンポーネント (この場合はスマート コントラクトやサービスなど) 間のインタラクションは非同期的に発生します。メッセージとトークンは一緒に送信され、同じ 6 秒の実行サイクル内のどこかの時点で、受信サービスによって処理されます。即時のリターン パスはありません。リターン パスが必要な場合、送信側サービスは別の転送を開始するか、受信側サービスが後で解釈できる方法でその状態を変更する必要があります。
Accumulate と onTransfer はどちらも並行して実行されるように設計されており、異なるサービスの Accumulate と転送を同時に実行できます。この設計により、現在の 10 ミリ秒を超えてガス入力を割り当てるなど、将来の機能拡張の可能性が開かれます。理論的には、セカンダリ コアを使用して特定のアキュムレートを実行し、より多くのガスを利用できるようにすることができます。
オリジナルの Polkadot ホワイトペーパーで述べられているように、Polkadot は主に特定のサービス プロファイル、つまりパラチェーンの提供用にカスタマイズされています。このサービスを実装するために、Polkadot は 2 つの重要なサブコンポーネントを開発しました:
Polkadot と比較すると、JAMプリセット設定が少なく、より高いレベルの抽象化と一般化が提供されます。これにより、個人の好みに基づいて基礎となるコンポーネントを活用しやすくなります。
JAM は、スマート コントラクト チェーンと同様に、許可のない方法で動作し、個別のアップロードと目的のコードの実行を許可します。さらに、キーと値のシステムと同様に、データをホストし、プリイメージ ルックアップを有効にし、状態を管理します。 JAM にはトランザクションを直接受け入れるメカニズムがないため、JAM のジェネシス ブロックには新しいサービスの作成を容易にするサービスが含まれています。
JAM 内のサービスには、コード、データ、または状態の量に関する事前定義された制限はありません。それらの機能は暗号経済的要因によって決定され、DOT トークンがデポジットされるほど、データと状態の容量が大きくなります。たとえば、JAM のパラチェーン サービスは、Polkadot 1.1 のすべての機能を 1 つのサービスに統合し、他のサービスも Polkadot の分散可用性システムや、計算の監査および保証システムを利用できます。
PVM は、そのシンプルさと多用途性で知られる RISC-V 命令セット アーキテクチャ (ISA) に基づいて設計されています。 RISC-V ISA にはいくつかの利点があります:
1. x86、x64、ARM などの一般的なハードウェア形式への簡単な変換。
2. LLVM などのツールで十分にサポートされています。
PVM 自体はシンプルさとセキュリティを体現しており、サンドボックス化する機能があり、さまざまな実行保証を提供します。それは決定論的でコンセンサスに敏感であり、測定が簡単です。他の仮想マシンと比較して、PVM には複雑さがなく、過剰なプリセット設定がありません。
WASM は Web ユースケース向けに最適化されていますが、特に継続性の処理に関してスタック管理の課題ももたらします。 RISC-V はスタックをメモリ内に配置することでこの問題を解決し、複雑さを増すことなく自然に逐次処理を容易にします。
さらに、PVM は、レガシー ハードウェア、特に X64 および ARM で実行する場合に優れた実行速度を示し、WASM に匹敵する無料のメータリングなどの利点を提供します。
RISC-V 継続性のサポートにより、JAM のようなマルチコア プラットフォーム全体でスケーラブルなコーディングの新しい標準が確立されます。非同期並列アーキテクチャは、ハードウェアおよびソフトウェア プラットフォームのスケーラビリティにとってますます重要になっており、この傾向はブロックチェーンやコンセンサス アルゴリズムにも拡大すると予想されます。
SAFROLEは、SASSAFRASを簡略化したブロック生成アルゴリズムです。パラチェーンに役立つ可能性のある一部のコンポーネントは除外されます。したがって、パラチェーンはサフロールではなくササフラスにくっつく可能性があります。 SAFROLE は可能な限りシンプルです:
Polkadot 1.0 がエンドツーエンドでどのように動作するかを理解するのは困難です。 JAM を使用する場合、イエロー ペーパーを読んで理解できる人は、JAM の仕組みを非常に早く読んで理解できるはずです。したがって、シンプルさが重要です。
SAFROLEはSNARKをベースにしたブロック生成アルゴリズムです。 SNARK の匿名化特性により、SNARK が使用されます。また、ほぼ完全にフォーク不要の定時間ブロック生成を提供します。フォークが発生する可能性のある数少ない例は、基本的に、ネットワークが分割された場合、または誰かが意図的に悪意を持って行動した場合にのみ発生します。匿名性の大きな価値は、バリデーターの身元を秘密にしておくことではありません。実際、バリデーターがブロックを生成するときは、とにかくその身元を明らかにします。これは、基本的にスパム攻撃を避けるため、ブロック生成メカニズム自体のセキュリティを確保するためです。
JAMのネットワークはQUICプロトコルを使用しています。これにより、多数のバリデータ間で直接ピアツーピア接続が可能になります。その結果、Polkadot 上の 1,000 を超えるバリデータは、ソケットの問題の可能性を心配することなく、相互に永続的な接続を維持できます。 JAMでは取引を扱っておりませんので、基本的に噂話は必要ありません。ポイントツーポイントではない、またはバリデーターの非常に小さなサブセット内での分散が必要な状況では、グリッド拡散が使用されます。この場合、バリデーターがグリッドに配置され、パケットが行に送信され、各ノードがそれを送信します。そのすべての列メンバー。
イーサリアムのような状態ベースのブロックチェーンでは、通常、ブロックのヘッダーには、すべてのブロックの計算された状態を要約する状態後のルートが含まれます。したがって、すべての計算が完了するまでブロック ヘッダーは送信できません。ただし、一部の計算は、その結果によってブロックの有効性が決定されるため、ブロック ヘッダーを送信する前に実行できます。
ただし、JAM は異なるアプローチを採用し、状態後のルートではなく状態前のルートをブロック ヘッダーに置きます。これは、ヘッダーに示されている状態が 1 ブロック遅れていることを意味します。その結果、ブロックのワークロードまたは実行時間の約 5% を占める軽量の計算を実行でき、ブロックを即座に分散できます。ブロック計算の残りの 95% (主に累積タスク) は、後で完了できます。これにより、現在のブロックが実行される前に次のブロックを開始できるようになります。
このアプローチにより、ブロック間の時間をより効率的に使用できます。 Polkadot の 6 秒のブロック時間などの従来の設定では、ポストステートのルートを指定する必要があり、時間の一部しか計算できません。ただし、JAM のパイプラインを使用すると、ブロック時間全体を計算に効果的に利用でき、効率を最大化できます。
ブロック時間全体を計算に使用することは、永続的な追いつきやブロックインポートの遅延を引き起こす可能性があるため理想的ではないかもしれませんが、JAM のアプローチは従来のセットアップと比較して計算時間を大幅に延長できます。これは、約 3 ～ 3.5 秒という有効なブロック計算時間が達成できることを意味しており、現在の設定に比べて大幅に改善されています。
JAM とリレー チェーンのアーキテクチャの違いの 1 つは、固定機能の程度です。リレー チェーンはプロトコルの定義に使用される言語 (WASM) などのいくつかの要素を修正しますが、JAM はこの点でさらに進んでいます。たとえば、ブロック ヘッダーやハッシュ スキームのエンコードに使用されるタイプが決定されるため、これらの側面を変更することが困難になります。
ただし、JAM は、リレー チェーンの WebAssembly メタプロトコルによって実現されるものと同等のサービス モデルを通じて柔軟性を保持しています。このモデルでは、アップグレード可能性の責任がサービスに移され、チェーン自体がアップグレードの負担から解放されます。この決定を支持する主な理由は次の 3 つです:
これらの違いにもかかわらず、JAM はコアタイムセール、ステーキング、ガバナンスなどのアプリケーションレベルの機能の柔軟性を維持しており、すべてサービス内で管理されます。さらに、JAM はトークン残高をサービスに関連付けることによって新しい概念を導入し、リレー チェーンなどの純粋にアップグレード可能なチェーンでは簡単に達成できない経済モデルの調整の機会を提供します。
JAM が当初の期待に応えられるようにするため、継続的な取り組みとして、JAM チェーンの包括的なテスト環境の構築が含まれています。クラウド コンピューティングのコストを管理するために、信頼性の低いハードウェアで小規模のテスト ネットワークを実行するのではなく、この取り組みには多額の投資が必要です。ここで紹介する
JAM Toaster は、大規模な実験や性能評価を行うためのテスト プラットフォームです。これは、Polkadot Relay Chain の開発中に遭遇した以前の課題に対処するもので、このような規模でネットワークの新たな効果とダイナミクスを運用するのは難しいことが判明しました。これまでの試みは、テスト ネットワークと Kusama ネットワーク上の数十ノードに限定されており、検証ノードへのアクセスが不足していたため、包括的な監視機能が不足していました。対照的に、小規模なテスト ネットワークでは、大規模な展開のネットワーク ダイナミクスを正確にシミュレートできません。
JAM Toaster は、1023 ノードを含む JAM ネットワーク全体を詳しく調べることで、このギャップを埋めることを目指しています。このプラットフォームは、ネットワークの動作とパフォーマンス特性の研究を容易にし、開発者にパラチェーンの期待されるパフォーマンスについての貴重な洞察を提供します。
JAM では、ベンチマークまたはパフォーマンス テストをオプションにできます。場合によってはベンチマークが必要な場合もありますが、JAM の測定システムでは通常、頻繁にベンチマークを行う必要がありません。 JAM は、ユーザーが完了時に計算ワークロードを評価できる計測システム上で実行されます。さらに、ブロックの構築時に計算を制御する理論的なメカニズムがあります。
ただし、場合によっては、依然としてベンチマークが必要です。たとえば、特定のユースケースに対して測定が保守的すぎる場合、パフォーマンスを向上させるためにベンチマークが必要になる場合があります。さらに、ベンチマークは、実行時間が長くなりすぎないようにするために、長時間の実行時間を必要とするタスクに役立ちます。
次はクロスチェーンメッセージング (XCMP) で、JAM には XCMP の完全なサポートが必要です。これは、リレーチェーンでは、すべてのパラチェーンが常にすべてのデータを送信すると、より多くのデータが候補受信を通過できるためです。 JAM は、パラチェーン サービスであっても、「精製」ステージと「蓄積」ステージの間のデータ転送の制限を含む、厳格なルールに従います。現在、水平リレー チェーン メッセージング (HRMP) を使用すると、すべてのメッセージがリレー チェーンを通過し、データ ペイロードが 4 kB 以下に制限されますが、これは実用的ではない可能性があります。その結果、XCMP はチェーンを介してメッセージ ヘッダーのみを中継し、実際のメッセージ データはオフチェーンに送信されます。これは必要であり、長い間待ち望まれていた改善です。
アコードは基本的に、スマート コントラクトと同様に、各パラチェーンの複数のインスタンスを使用して状態とロジックをカプセル化します。これらはインスタンス間のメッセージ交換を容易にし、パラチェーンとの同期対話を可能にします。このプロトコルは、トークン転送など、パラチェーン間に信頼性が欠如しているシナリオで役立ちます。予備仲介者を伴う既存のアプローチとは異なり、Accords はパラチェーン間の直接トークン転送を簡素化し、信頼を損なう仲介者の必要性を排除します。さらに、Accords は XCM 転送メカニズムとして機能し、サードパーティの仲介者を介して中継される場合でもメッセージの整合性を確保できるため、明示的な発信元タグの必要性がなくなります。
最後に、JAM は、基盤となるコンセンサス メカニズムを活用するために、より広範で事前に好まれないアプローチを採用し、より革新的なソリューションの実装を支援します。たとえば、ゼロ知識証明のような複雑なタスクでは、分散型可用性がより実用的かつ効率的になります。さらに、JAM は混合リソース消費モデルをサポートしており、作業パッケージにはコンピューティング集約型のタスクとデータ集約型の操作の両方を含めることができます。 JAM は、コンピューティング集約型のサービスと高いデータ可用性を必要とするサービスを組み合わせることで、バリデーター リソースの利用を最適化し、コストを削減します。この柔軟なアプローチにより、分散型可用性や SNARK 検証などのワークロードをパラチェーンと組み合わせることで、効率を高めながらコストを下げることができます。
JAM は、既存の Polkadot 1 パラチェーンとの互換性を優先するように設計されました。 Polkadot SDK との互換性を維持しながら、Polkadot Validator Function (PVF) が再利用されています。これは、WebAssembly ではなく、Polkadot 仮想マシン (PVM) をターゲットとします。この移行は、PVM が LLVM のターゲットとして正式に認定された RISC-V をわずかに修正したものであるという事実によって促進されます。したがって、JAM が展開される前に、PVM が正式な LLVM ターゲットになる可能性があります。
JAM はパラチェーンのホストであることに加えて、大幅な機能強化を導入しています。これにより、ベンチマークの取り組みが簡素化され、将来のベンチマークのニーズが軽減される可能性があります。さらに、JAM は、パラチェーン間の特定の対話プロトコルを管理および実行するために、プロトコル、マルチインスタンス、およびマルチシャード スマート コントラクトの概念を導入します。さらに、包括的なクロスチェーン メッセージング (XCMP) のサポートが重要であり、パラチェーン間の情報転送の制限を取り除くことが可能になります。これは通常、クロスチェーン メッセージング (XCM) によって促進されます。
Agile Coretime に関しては、JAM は既存の設定との互換性を維持します。ただし、パラチェーンだけでなく、あらゆる作業パッケージのグループでもコアタイムを特定できる機能が導入されています。この柔軟性により、JAM エコシステム内でのリソース割り当ての汎用性と効率が向上します。
以上がギャビン・ウッド氏が正式発表した次世代ポルカドットテクノロジービジョン「JAM」とは？の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
