Polkadot1、Polkadot2、およびそれらがJAMに進化する過程の詳細な説明について以下に示します。(詳細については、次を参照してください:https://www.navalmanack.com/almanack-of-naval-ravikant/how-to-think-clearly）. この記事は、特にPolkadotに詳しくないが、ブロックチェーンシステムについてある程度の知識を持ち、他のエコシステムの技術に精通している技術系の読者を対象としています。
この記事はJAMグレーペーパーを読む前置きとして役立つと信じています。(詳細はこちらを参照してください:https://graypaper.com/)

背景知識

この記事では、読者が次の概念に精通していることを前提としています。

• ブロックチェーンを状態遷移関数として説明する。
• "状態"の意味を理解すること。(詳細はこちらを参照:https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/blockchain_state_machines/index.html)
• 経済的セキュリティとステークの証明。(詳細はこちらを参照：https://polkadot-blockchain-academy.github.io/pba-book/economics/economics-of-polkadot/page.html#staking-concept，https://www.youtube.com/watch?v=suyram9vaFc)

イントロダクション：Polkadot1

まずは、Polkadot1の最も革新的な機能を再訪してみましょう。

社会的側面:

• Polkadotは巨大な分散型自律組織（DAO）です。このネットワークは完全にオンチェーンで、自己実行型のガバナンスを実装しており、フォークレスなランタイムアップグレードを含んでいます。
• SECはDOTをソフトウェアとして認識しており、証券ではありません。(詳細はこちらを参照: https://polkadot.com/newsroom/press-releases/web3-foundation-announces-polkadot-blockchains-native-token-dotが変化し、ソフトウェアであり、セキュリティではありません)
• ネットワーク上のほとんどの開発作業は、Polkadot Fellowshipによって処理されています（詳細については、次を参照してください:https://polkadot-fellows.github.io/dashboard/)、プロジェクトを財政的に支援している企業であるParity Technologiesではなく、https://www.parity.io/）

技術的な側面：

• Polkadotは共有セキュリティとシャーディングされた実行を実装しました。
• WASMベースのメタプロトコルを使用しています（詳細については、参照: https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/wasm_meta_protocol/index.html)、ブロックチェーンのコードはバイトコードとして状態に格納されます。これにより、ほとんどのアップグレードをフォークなしで実行でき、異種のシャーディングを可能にします。（「異種シャーディング」の詳細については関連するセクションを参照してください。)

分散実行: 主要ポイント

現在、私たちは、PolkadotやEthereumに類似した他のLayer 2「ブロックチェーン」ネットワークをホストするLayer 1ネットワークについて話しています。そのため、Layer 2とParachainという用語は互換に使用できます。

ブロックチェーンのスケーラビリティの中核的な問題は次のように表現できます: 一定のコードの実行が信頼できることを保証するために、プルーフ・オブ・ステークの暗号経済を使用するバリデータのセットが存在します。デフォルトでは、これらのバリデータはお互いの作業をすべて再実行する必要があります。すべてのバリデータが常にすべてを再実行するよう強制すれば、システム全体がスケーラブルでない状態が続きます。

このモデルにおいて、絶対再実行の原則が変わらない限り、バリデータの数を増やすことは実際にはシステムのスループットを向上させるわけではありません。

これは、シャーディングされたものとは対照的に、モノリシックなブロックチェーンを示しています。すべてのネットワーク検証者は、入力（すなわち、ブロック）を一つずつ処理します。このようなシステムでは、レイヤー1がより多くのレイヤー2をホストすることを希望する場合、すべての検証者がすべてのレイヤー2の作業を再実行する必要があります。明らかに、この方法はスケーリングできません。

楽観的ロールアップは、詐欺が主張されたときにのみ再実行（詐欺証拠）することで、この問題に対処します。SNARKベースのロールアップは、SNARK証明を検証するコストが生成するコストよりもはるかに低いことを活用することで、すべての検証者が効率的にSNARK証明を検証できるようにします。「付録：拡張性スペース図」については、詳細を参照してください。

シャーディングの直接的な解決策は、バリデータセットをより小さなサブセットに分割し、これらの小さなサブセットにLayer2ブロックを再実行させることです。このアプローチにはどのような問題がありますか？基本的に、ネットワークの実行と経済的セキュリティの両方をシャーディングしています。このようなLayer2ソリューションは、Layer1と比較してセキュリティが低く、バリデータセットをより多くのシャードに分割するとさらにセキュリティが低下します。

楽観的なロールアップとは異なり、再実行コストを常に回避することができないPolkadotは、シャーデッド実行を念頭に設計されました。これにより、一部のバリデータが第2レイヤーブロックを再実行できる一方で、全体のネットワークに十分な暗号経済学的証拠を提供して、第2レイヤーブロックが完全なバリデータセットが再実行した場合と同じくらい安全であることを証明します。これは、ELVESとして知られる新しい（最近形式化された）メカニズムを介して達成されます。（詳細については、次を参照してください:https://eprint.iacr.org/2024/961)

ELVESは、疑わしいロールアップメカニズムと見なすことができます。いくつかのラウンドのバリデーターが、与えられたレイヤー2ブロックが有効かどうかを積極的に他のバリデーターに問い合わせることにより、高い確率でブロックの有効性を確認することができます。紛争が発生した場合、フルバリデーターセットが迅速に関与します。Polkadot共同創設者のRob Habermeierは、この詳細を記事で詳しく説明しています。（詳細はこちらを参照してください：https://polkadot.com/blog/polkadot-v1-0-sharding-and-economic-security#approval-checking-and-finality)

ELVESは、従来は相互に排他的と考えられていた2つのプロパティ、すなわちシャーデッド実行と共有セキュリティを備えたPolkadotを実現するようにします。これは、Polkadot1のスケーラビリティにおける主要な技術的な成果です。

今度は、「コア」の類推を使って前に進みましょう。分散実行ブロックチェーンはCPUのようなものです：CPUが複数のコアで並列に命令を実行できるように、Polkadotはレイヤー2ブロックを並列に処理できます。これがPolkadotのレイヤー2をパラチェーンと呼ぶ理由であり、より小さなバリデータのサブセットが単一のレイヤー2ブロックを再実行する環境は「コア」と呼ばれます。各コアは「協力するバリデータのグループ」と抽象化できます。

モノリシックブロックチェーンを1つのブロックを1度に処理すると考えることができますが、Polkadotは同じ時間帯の各コアにリレーチェーンブロックとパラチェーンブロックの両方を処理します。

異質性

これまでに、私たちはPolkadotが提供するスケーラビリティとシャーデッド実行についてしか議論していません。重要なのは、Polkadotの各シャードが実際にはまったく異なるアプリケーションであるということです。これは、バイトコードとして保存されたメタプロトコルによって実現されています。つまり、その状態にブロックチェーン自体の定義をバイトコードとして保存するプロトコルです。Polkadot 1.0では、好まれるバイトコードとしてWASMが使用されており、JAMではPVM/RISC-Vが採用されています。

このため、Polkadotは異種なシャーディングされたブロックチェーンとして言及されています。(詳細はこちらを参照: https://x.com/kianenigma/status/1790763921600606259) それぞれのLayer 2は全く異なるアプリケーションです。

Polkadot2

Polkadot2の重要な側面の1つは、コアの使用をより柔軟にすることです。元のPolkadotモデルでは、コアリース期間は6か月から2年の範囲で、リソースが豊富な企業には適していましたが、小規模なチームには適していませんでした。Polkadotコアをより柔軟に使用できるようにする機能は、「アジャイルコアタイム」と呼ばれます。(詳細については、以下を参照してください。https://polkadot.com/agile-coretime) このモードでは、コアリースの期間は1ブロックだけでなく、1か月までの長さで設定でき、長期リースを希望する人には価格上限が設定されています。

Polkadot 2の他の特徴は、私たちの議論が進むにつれて徐々に明らかになっていますので、ここでさらに詳しく説明する必要はありません。

インコア対オンチェーンオペレーション

JAMを理解するには、まず、Layer 2ブロックがPolkadotコアに入ると何が起こるかを把握することが重要です。以下は単純化された説明です。

コアは主にバリデータのセットで構成されていることを思い出してください。つまり、「データがコアに送信される」ということは、そのデータがこのバリデータのセットに渡されることを意味します。

1. Layer 2ブロックとその一部の状態がコアに送信されます。このデータには、Layer 2ブロックを実行するために必要なすべての情報が含まれています。

2. 一部のコアバリデータは、Layer 2ブロックを再実行し、コンセンサスに関連するタスクを継続します。

3. これらのコアバリデータは、コア外の他のバリデータに再実行されたデータを提供します。 ELVESルールに従い、これらのバリデータは、このデータを使用してLayer 2ブロックを再実行するかどうかを決定することができます。

重要なのは、これまでのところ、すべてのこれらの操作が、主要なPolkadotブロックおよび状態遷移機能の外で行われているということです。すべてはコアおよびデータ可用性レイヤー内で行われます。

1. ついに、最新のLayer 2ステートの一部がPolkadotのメインリレーチェーン上で見えるようになりました。以前の操作とは異なり、このステップはLayer 2ブロックを再実行するよりもはるかに安く、Polkadotのメインステートに影響を与えます。これはPolkadotブロックで見え、すべてのPolkadotバリデータによって実行されます。

このことから、Polkadotが実行しているいくつかの主要な操作を探ることができます。

• ステップ1から、Polkadotは従来のブロックチェーンの状態遷移関数とは異なる新しい実行タイプを導入したことがわかります。通常、すべてのネットワーク検証者がタスクを実行すると、メインブロックチェーンの状態が更新されます。これが我々がいうものですオンチェーン実行, そしてそれがステップ3で起こることです。 ただし、コア（ステップ1）内で起こることは異なります。 この新しい形式のブロックチェーン計算は、「」と呼ばれています。イン・コア実行.
• ステップ2から、Polkadotはネイティブであることを推測しますデータ利用可能性（DA）レイヤー、およびLayer 2は、その実行の証拠が一定期間利用可能であることを確認するためにそれを自動的に使用します。ただし、DAレイヤーに投稿できるデータブロックは固定されており、Layer 2再実行に必要な証拠のみを含んでいます。さらに、パラチェーンコードはDAレイヤーデータを読み取りません。

これを理解することは、JAMを把握するための基盤を形成します。以下は概要です：

• インコア実行コア内で行われる操作を指します。これらの操作は豊富でスケーラブルであり、暗号経済学とELVESによって保護されており、オンチェーン実行と同じセキュリティを提供しています。
• オンチェーン実行: すべてのバリデータによって実行された操作を指します。 これらはデフォルトで経済的に安全であることが保証されていますが、誰もがすべてのタスクを実行するため、より高コストで制限されています。
• データの利用可能性Polkadotのバリデータが一定の期間にわたり特定のデータの利用可能性を保証し、他のバリデータに提供する能力を指します。

JAM

この理解を持って、私たちは今JAMを紹介することができます。

JAMはPolkadotの設計に触発された新しいプロトコルで、それと完全に互換性があり、Polkadotのリレーチェーンを置き換え、コアの使用を完全に非中央集権化および制限なしにすることを目指しています。

Polkadot 2に基づいて構築されたJAMは、コア上でのLayer 2の展開をよりアクセスしやすくし、アジャイルコアタイムモデルよりもさらに柔軟性を提供しています。

• Polkadot 2は、コア上でのLayer 2展開をより動的にすることを可能にします。
• JAMは、そのようなアプリケーションがブロックチェーンやLayer 2のように構造化されていなくても、Polkadotのコアに展開されることを可能にすることを目指しています。

これは、主に開発者に既に議論されている3つのコアコンセプト、オンチェーン実行、インコア実行、DAレイヤーを露出することによって達成されます。

言い換えれば、JAMでは、開発者は次のことができます:

• インコアおよびオンチェーンタスクを完全にプログラムします。
• PolkadotのDAレイヤーから読み書きを行い、任意のデータを取得します。

これはJAMの目標の基本的な概要を形成しています。言うまでもなく、これらの多くは簡略化されており、プロトコルはさらに進化する可能性があります。

この基本的な理解を持っていると、次の章でJAMの具体的な内容について詳しく調べることができます。

サービスと作業アイテム

JAMでは、以前はLayer 2またはパラチェーンと呼ばれていたものは、今ではと呼ばれていますサービスそして、以前はブロックやトランザクションと呼ばれていたものは、今はと呼ばれています作業項目または作業パッケージ具体的には、作業項目はサービスに属し、作業パッケージは作業項目のコレクションです。これらの用語は意図的に広い範囲をカバーしており、ブロックチェーン/Layer 2のシナリオを超えたユースケースにも対応しています。

サービスは、3つのエントリポイントによって記述されます。そのうち2つはfn refine()とfn accumulate()であり、前者はコア内実行中にサービスが行うことを説明し、後者はチェーン上での実行中にサービスが行うことを説明します。

最後に、これらのエントリーポイントの名前がプロトコルをJAM（Join Accumulate Machine）と呼ぶ理由です。参加する参照fn refine(), それはすべてのPolkadotコアが異なるサービス間で並列に大量の作業を処理する段階です。データが処理された後、次の段階に移動します。蓄積するこれは、すべてのこれらの結果をメインのJAM状態に蓄積するプロセスを指します。これはオンチェーン実行フェーズ中に行われます。

ワークアイテムは、コードがどのように、いつ、どこからデータを読み書きするかを、インコアおよびオンチェーンで正確に指定できます。

セミ一貫性

XCM（Polkadotがパラチェーン通信のために選択した言語）に関する既存のドキュメントをレビューすると、すべての通信が非同期です（詳細については、ここ）これは、メッセージを送信すると、その応答を待つことができないことを意味します。非同期通信は、システムの不整合の症状であり、Polkadot 1、Polkadot 2、およびEthereumの既存のLayer 2エコシステムの永続的にシャーディングされたシステムの主な欠点の1つです。

しかしながら、セクション2.4に記載されているようにグレーペーパー, すべてのテナントにとって同期したままである完全に一貫したシステムは、普遍性、アクセシビリティ、または弾力性を犠牲にすることなく、ある程度までスケーリングすることができます。

• 同期≈一貫性 || 非同期≈不一致

JAMはここで際立っています: いくつかの機能を導入することで、JAMは新しい中間状態である「セミコンシステントシステム」として知られるものを実現しています。このシステムでは、頻繁に通信するサブシステムが互いに一貫した環境を作成することができますが、システム全体が一貫している必要はありません。これは、グレイペーパーの著者であるDr. Gavin Woodによって最もよく説明されています。https://www.youtube.com/watch?t=1378&v=O3kRAVBTkfs&embeds_referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ

Polkadot/JAMを分散システムとして見る別の方法は、これらのシャードの境界が流動的で動的に決定されるというものです。

Polkadotは常にシャーディングされ、完全に異種です。

今、それはシャーディングされ、異種ですが、これらのシャードの境界は柔軟に定義できます—Gavin WoodがツイートやGraypaperで「半一貫性」システムと呼んでいます。（参照: https://x.com/gavofyork?ref_src=twsrc%5Etfw、https://graypaper.com/)

いくつかの機能により、この半一貫性のある状態が可能になります。

1. 状態なし、並列インコア実行へのアクセス、異なるサービスが同じコア内の他のサービスと同期的にのみ相互作用し、特定のブロック上で、およびチェーン上で実行され、すべてのコア上のすべてのサービスから結果にアクセスできる。
2. JAMは特定のサービススケジューリングを強制しません。頻繁に通信するサービスは、そのスケジューラに経済的なインセンティブを提供して、これらの頻繁に通信するサービスを含む作業パッケージを作成させることができます。これにより、これらのサービスが同じコア内で実行され、その相互作用が同期しているように見えますが、実際には分散しています。
3. さらに、JAMサービスはDAレイヤーにアクセスして、一時的ですが非常にコスト効率の良いデータレイヤーとして使用することができます。データがDAに配置されると、最終的にすべてのコアに伝播しますが、すぐに同じコア内で利用可能になります。したがって、JAMサービスは、連続するブロック内で自分自身をスケジュールして、同じコア内でデータアクセスの度合いを高めることができます。

これらの機能はJAM内で可能ですが、プロトコルレベルで強制されていません。そのため、一部のインターフェースは理論的には非同期ですが、洗練された抽象化とインセンティブにより実際には同期的に機能する場合があります。次のセクションで議論されるCorePlayは、この現象の例です。

コアプレイ

このセクションでは、JAM環境での実験的なコンセプトであるCorePlayが紹介されており、新しいスマートコントラクトプログラミングモデルとして説明されます。執筆時点では、CorePlayは完全に定義されておらず、推測のアイデアのままです。

CorePlayを理解するには、まずJAMが選んだ仮想マシン（VM）であるPVMを紹介する必要があります。

PVM

PVMは、JAMとCorePlayの両方で重要な詳細です。PVMの詳細なレベルは、この文書の範囲を超えており、Graypaperのドメイン専門家によって最もよく説明されています。ただし、この説明では、PVMのいくつかの主要な属性を強調します。

• 効率的な計量
• 実行を一時停止および再開する機能

後者は特にCorePlayにとって極めて重要です。

CorePlayは、JAMの柔軟なプリミティブを使用して、非常に柔軟なプログラミングインターフェースを備えた同期およびスケーラブルなスマートコントラクト環境を作成する方法の例です。CorePlayは、アクターベースのスマートコントラクトをJAMコアに直接展開し、同期プログラミングインターフェースの恩恵を受けることを提案しています。開発者は、単純なfn main()関数であるかのようにスマートコントラクトを記述でき、letなどの式を使用できます。result = other_coreplay_actor(data).await?to communicate. Ifother_coreplay_actor同じJAMコア内の同じブロックにある場合、この呼び出しは同期的です。別のコアにある場合、アクターは一時停止され、後続のJAMブロックで再開されます。これは、JAMサービス、その柔軟なスケジューリング、およびPVMの機能によって実現されています。

CoreChainsサービス

最後に、JAMがPolkadotと完全に互換性がある主要な理由を要約しましょう。Polkadotの看板商品は、JAMで続けられるアジャイルコアタイムのパラチェーンです。JAMで最初に展開されるサービスはおそらくCoreChainsまたはParachainsと呼ばれるでしょうが、既存のPolkadot-2スタイルのパラチェーンをJAMで実行することが可能になります。

JAMにはさらにサービスを展開することができ、既存のCoreChainsサービスはそれらと通信することができます。ただし、Polkadotの現行製品は強固なままであり、既存のパラチェーンチームに新たな可能性を開くだけです。

付録：データシャーディング

この文書のほとんどは、実行シャーディングの観点からスケーラビリティについて議論しています。しかし、データシャーディングの観点からこの問題を検討することもできます。興味深いことに、これは以前に言及された半一貫モデルに類似しています。原則として、完全一貫性のあるシステムは優れていますがスケーラブルではなく、一方で完全に不整合なシステムはスケーラビリティが高くなりますが最適ではありません。JAMは、その半一貫性モデルで新たな可能性を示しています。

• 完全一致システム: これらは、Solanaなど、Ethereum Layer 1に専用で展開されたものなど、すべてが同期されるプラットフォームです。すべてのアプリケーションデータはオンチェーンに保存され、すべての他のアプリケーションから簡単にアクセスできます。これはプログラム可能性の観点から理想的ですが、拡張性には欠けます。
• 一貫性のないシステム: アプリケーションデータは、レイヤー1の外または異なる、孤立したシャードに保存されます。これは非常にスケーラブルですが、合成性の観点でパフォーマンスが低いです。PolkadotとEthereumのロールアップモデルはこのカテゴリに該当します。

JAMはこれら2つのオプションを超えたものを提供します: 開発者がJAM DAレイヤーに任意のデータを公開できるため、チェーン上のデータとオフチェーンのデータの中間地点として機能します。新しいアプリケーションは、ほとんどのデータにDAレイヤーを活用し、JAMステートには絶対に重要なデータのみを永続化することができます。

付録：スケーラビリティの景観

このセクションでは、ブロックチェーンのスケーラビリティに対する私たちの視点を再検討します。これはGraypaperでも議論されていますが、ここではより簡潔な形で提示されています。

ブロックチェーンのスケーラビリティは、主に分散システムからの伝統的な手法に従います: 縦方向のスケーリングと横方向のスケーリング。

ソラナのようなプラットフォームが重点を置いているのは縦方向のスケーリングであり、コードとハードウェアの両方を限界まで最適化してスループットを最大化することです。

水平スケーリングは、EthereumとPolkadotによって採用されている戦略です：各参加者が処理する必要がある作業量を減らすこと。従来の分散システムでは、これはより多くのレプリカマシンを追加することによって達成されます。ブロックチェーンでは、「コンピューター」はバリデータの全ネットワークです。彼らの間でタスクを分散すること（ELVESが行うように）または楽観的に彼らの責任を減らすこと（オプティミスティックロールアップの場合）、私たちは全バリデータセットの作業量を減らし、それにより水平スケーリングを達成します。

ブロックチェーンでは、水平スケーリングは「すべての操作を実行する必要があるマシンの数を減らす」と例えることができます。

要約すると:

1. 垂直スケーリング: ハイパフォーマンスのハードウェア+モノリシックブロックチェーンの最適化。
2. 水平スケーリング：
   • オプティミスティックロールアップ
   • SNARKベースのロールアップ
   • ELVES: Polkadot’s Cynical Rollups

付録：同じハードウェア、カーネルのアップグレード

このセクションは、Rob Habermeier氏のSub0 2023からのアナロジーに基づいています。Polkadot: カーネル/ユーザーランド | Sub0 2023 - YouTube (see:https://www.youtube.com/watch?v=15aXYvVMxlw)、PolkadotのアップグレードであるJAMを紹介します：同じハードウェア上でのカーネルの更新。

典型的なコンピュータでは、スタック全体を3つの部分に分割できます。

1. ハードウェア
2. カーネル
3. ユーザースペース

Polkadotでは、計算とデータの利用可能性を提供するコアインフラストラクチャーであるハードウェアは、前述のように常にコアでした。

Polkadotでは、カーネルはこれまでに主に2つのパーツで構成されていました:

1. パラチェーンプロトコル: コアを利用する固定された、意見のある方法。
2. 低レベル機能のセット, 例えばDOTトークンとその移転可能性、ステーキング、ガバナンスなど。

これらの両方は、Polkadotのリレーチェーンに存在しています。

ユーザースペースアプリケーションは、一方で、パラチェーン自体、そのネイティブトークン、およびそれらの上に構築されたすべてのものです。

このプロセスを次のように視覚化することができます:

Polkadotは、より多くのコア機能を主要ユーザーであるパラチェーンに移行することを長く考えてきました。これが最小限のリレーRFCの目標です。(詳細はこちらを参照: 最小中継RFC)

これは、Polkadot Relay Chainがパラチェーンプロトコルの提供のみを担当し、それによってカーネルスペースをある程度削減することを意味します。

このアーキテクチャが実装されると、JAMの移行がどのように見えるかを視覚化することがより簡単になります。 JAMはPolkadotのカーネルスペースを大幅に削減し、より汎用性を高めます。さらに、Parachainsプロトコルは、同じコア（ハードウェア）およびカーネル（JAM）上でアプリケーションを構築する数少ない方法の1つであるため、ユーザースペースに移動します。

これは、なぜJAMがポルカドットリレーチェーンの代わりであり、パラチェーンの代わりではないかを強調するものでもあります。

言い換えると、JAMの移行をカーネルのアップグレードと見なすことができます。基盤となるハードウェアは変わらず、古いカーネルの大部分のコンテンツがユーザースペースに移動され、システムを簡素化します。

免責事項：

1. この記事は[から転載されていますPolkadot 生態研究所], すべての著作権は元の著者に帰属します [Polkadot生態研究所]. If there are objections to this reprint, please contact the Gate Learn(ゲート・ラーン)チームが速やかに対処します。
2. 責任免除：この記事で表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 記事の翻訳は、Gate Learnチームによって行われます。特に記載されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。