この記事は、villanuevawill と Quilt チームの多大な協力を得て、samwilsn と adietrics との共同作業で執筆されました。
導入 Ethereum 2.0 のステートレス性は、トランザクションがアクセスしたい状態を保持する必要があることを意味します。より正確には、ブロック提案者 (BP) の場合、ブロックにはトランザクションが含まれているだけでなく、すべてのトランザクションによってアクセスされるすべての状態と、対応する証人情報も含まれている必要があります。トランザクションを作成するユーザーも BP も状態データを保存しないと仮定すると、ネットワークにはこの状態を保存して提供する別のグループが必要になります。この役割は、多くの場合、状態プロバイダー (SP) と呼ばれます。
ブロック提案者と状態プロバイダーがどのように状態を交換するかに関係なく、ユーザーはトランザクションを作成する前に状態を取得する必要がある場合があります。たとえば、契約のバイトコードを取得したり、ガスコストを見積もったり、アカウントの残高を確認したりします。つまり、状態プロバイダーはプルのようなインターフェースをユーザーに公開する必要があります。インセンティブ レイヤーがなくても、無私のステート プロバイダーだけに頼ってユーザーにステートを提供したり (これが Ethereum 1.0 の機能です)、ステート プロバイダーにインセンティブ レイヤーを追加してステート チャネルを通じて支払いを実装したりすることも可能です。
比較基準 州の提供者を全体のシステムに統合する方法について、さまざまなアイデアが提案されています。次のセクションでは、いくつかのオプションを簡単に紹介します。一般的な説明に加えて、次の特性も比較します。
ステータスアクセス制限 トランザクションの実行は実行時の状態に基づいて行われるため、基礎となる状態が変化すると、トランザクションの実行も変化します。特に、一部のトランザクションでは、状態アクセスの場所が変わる場合があります。これは、単純なジャンプ ステートメント (if など) が原因である場合もあれば、アクセスされる場所が実行時に計算される場合もあります。どちらの場合も、動的状態アクセス (DSA) と呼びます。ステートレス モードでは、トランザクション作成プロセスが複雑になります。問題は、これらのトランザクションの状態を事前に提供できない場合があることです (これらのトランザクションがアクセスするグローバル状態が事前にわからないため)。さまざまな州のプロバイダー パターンは、これらのトランザクションをサポートする範囲が異なります。
モードによって動的状態アクセスが制限されている場合、Eth1 は Eth2 EE になることができない可能性が高く、特別な処理が必要になることがよくあります。
インセンティブ 州の提供者に対する報酬は、次の 2 つの方法で比較されます。
最初は無私の州の提供者が優遇されるのでしょうか。もしそうなら、インセンティブは後から追加できるのでしょうか。 集中化リスク 状態プロバイダーはどのくらいの状態を保存できますか?どのようなハードウェアが必要ですか? ブロック提案者と州のプロデューサーの間にはどの程度の相互信頼が必要ですか? 時間的制約 ブロックプロデューサーがブロックをブロードキャストする時間は固定されています。したがって、この時間制約下でさまざまなモードがどのように機能するかを具体的に検討します。 失われた状態の帰属可能性 Eth1 では、特定のトランザクションの署名検証と残高および nonce チェックが完了すると、マイナーはトランザクション手数料を受け取ることができると確信できます。 Eth2 では、ブロック提案者が支払いを受けられるかどうかは、失われた状態が帰属障害であるかどうかによって決まります。そうであれば、状態の損失によりトランザクションが失敗した場合でも、ブロック提案者は支払いを受けることができます。それ以外の場合、失われた状態を持つトランザクション自体はパッケージ化できませんが、ブロック提案者はすべての（通常は非常に長い）トランザクションが実行されるまでそれを発見できない可能性があります。 （翻訳者注：ここでの支払いは、ブロック提案者がパッケージ化されたトランザクションで徴収しなければならないトランザクション手数料を指します。原因不明のエラーの場合、ブロック提案者はトランザクションをパッケージ化するためのコストを支払いますが、トランザクションでトランザクション手数料を受け取ることはできません。） ブロック提案者がエラーを発見するためにトランザクションを実行する必要があるが、これらのトランザクションがパッケージ化されていない場合（つまり、トランザクション手数料を支払うことができない場合）、ブロック提案者はほぼゼロのコストでサービス拒否攻撃に対して脆弱になります。 モデル モデル ステータスアクセス インセンティブ 集中化リスク 時間的制約 ダイレクトプッシュモード 制限付き 自発的な寄付または支払いチャネル 目立つステータスプロバイダーは有利になる なし リレープッシュモード 制限なし 一括または限定期間による課金 検閲の可能性がある スロット内でデータのバッチを更新して転送する必要がある プルモード 制限なし 支払いチャネル 目立つステータスプロバイダーは有利になる 1つのスロットで複数のステータスを一括してリクエストするには
ダイレクトプッシュモデル ユーザーは、必要な状態を 1 つ以上の状態プロバイダーに直接要求し、その状態を含むトランザクションをネットワークに送信します。ノードは保留中のトランザクションのプールを維持し、ネットワーク上で新しいブロックが生成されるたびに証人情報を更新します。ブロック提案者がブロックを作成するとき、トランザクション プールからパッケージ化するトランザクションのサブセットを選択し、それを新しいブロックに含めます。 トランザクションを作成したユーザーは、基本的にそのトランザクションの唯一のステータス プロバイダーになります。一般的に言えば、将来のトランザクションがチェーン上に置かれるときに、ユーザーが提供する状態がすべてのアクセス ニーズを満たすことができることを保証する方法はありません。したがって、ダイレクト プッシュ モードでは、予測可能な状態アクセスを持つトランザクションのみが実行できます。トランザクションは静的な状態アクセスのみを使用できるため、コントラクト作成者は予測可能な状態アクセスを持つようにコントラクトを設計する必要があります。これは、実行時にコントラクトがアクセスできる場所を詳細に示すアクセス リストなどの注釈を使用して行うことができます。これを、動的な状態アクセスを回避するパターンと組み合わせると (Eth1.x スレッドの Vitalik によるこのブログ投稿を参照)、十分な機能が提供されるはずです。 ただし、これは現在の Eth1 システムとは大きく異なります。これにより、Eth1 を Eth2 に変換する計画が失敗する可能性があります。 このパターンは、一般的な状態プロバイダー ネットワークのみに依存します。前述の通り、インセンティブ制度がなくてもできると思われます。 支払いチャネルを通じてインセンティブ システムを追加することもできます。このアプローチは、各ユーザーが 1 つ以上の州プロバイダーと支払いチャネルを確立する必要があることを考えると、特に複雑になります。 ユーザーは複数の州のプロバイダーに複数のクエリを送信できるため、単一の州のプロバイダーがトランザクションを検閲することは不可能です。 状態プロバイダーは状態の一部のみを保持できるため、必要に応じてハードウェア要件を削減できます。 金銭的なインセンティブにより、一部の状態プロバイダーが集中化する可能性もあるため、ユーザーは支払いチャネルを通じて状態を購入する際に相手方を信頼する必要があります。 失われた状態はユーザーに起因する可能性があります。ほとんどの場合、ブロックプロバイダーは不十分な状態のトランザクションをパッケージ化しても、ユーザーが支払いを行うことを許可できます。唯一の例外は、最初の署名検証または料金支払いに必要な状態も失われている場合です。この場合、トランザクションは含まれません。 Eth1 の場合と同様に、ネットワーク内のノードはトランザクション プールからそのようなトランザクションを破棄できます。これらの初期トランザクション部分については、ガスの利用率を最大化するためにいくつかの制限を課す必要があります。
主な利点: シンプルさ。プロフェッショナル ステータス プロバイダーやインセンティブ システムは必要ありません。特別な時間制限はありません。 主な欠点: すべての状態アクセスのニーズが事前にわかっているトランザクションでのみ機能します。これにより、システム全体の機能が制限されます。いくつかの緩和策はありますが、互換性の問題は解決できません。特に、このモデルでは、Eth1 は Eth2 の動作環境になることはできません。 リレープッシュモデル
ユーザーは、リレーヤー（専門の国家プロバイダー）にトランザクションを独自に送信します。リレーヤーは複数のトランザクションをまとめてトランザクションステータスを添付し、バンドルされたトランザクションパッケージをネットワークに中継します。ノードは保留中のトランザクション パッケージのプールを維持します。新しいブロックが生成されるたびに、リレーヤーはトランザクション パッケージのステータスを更新し、すべてのノードは対応する証人情報を更新します。ブロックを作成するとき、BP はトランザクション パッケージ プールから最新の保留中のトランザクション パッケージを選択し、新しいブロックに含めます。 したがって、トランザクション パッケージ プール内のトランザクション パッケージが使用できないことが判明した場合でも、システムは引き続き動作できます。リレーはトランザクション パッケージの存在のみを通知します。ブロック提案者はリレー担当者に直接連絡してトランザクション パッケージを取得し、それを新しいブロックに含めます。 制限はありません。リレーヤーが各スロットのトランザクション パッケージにステータスをプッシュし、状態アクセスのニーズが満たされていることを確認できる限り、問題ありません。さらに、各新しいブロックには 1 つのデータ パケットのみが含まれるため、トランザクション パケット間の干渉が防止されます。 リレーヤーに対するインセンティブ メカニズムの設計は、実際にはかなり複雑です。ステータスと証人情報が公開されると、ユーザーや BP は証人を迂回してトランザクション パッケージを自分で再作成できるためです。
トランザクション プールがない場合、トランザクション パッケージは公開されません。リレーは、状態が添付されたトランザクション パッケージをブロック提案者に販売します (手数料はトランザクション手数料よりわずかに低くなります)。これにより、トランザクション パッケージ市場が形成されます。ブロック提案者にはいくつかのリスクがあります。トランザクションが別のブロックに含まれていて無効になっている可能性があります。または、受け取った取引手数料が、リレー業者が販売時に発表した手数料よりも少ない場合。 あるいは、トランザクションには、トランザクション プールの有無にかかわらず、特定のリレーヤーへの支払いが含まれる場合があります。ユーザーは、排他期間（つまり、一定数のタイムスロット）を約束し、その期間中は他のトランザクションを作成しません。独占期間中にユーザーが同時に 2 つ以上のトランザクションに署名すると、ペナルティが課せられます。これを実現するために、EE はユーザーに「罰金」を科す方法を提供する必要があります。しかし、ユーザーは預金をロックしないため、口座残高が十分でないユーザーにどのように罰金を科すかは不明だ。
集中化リスクは、どのリレーヤーインセンティブメカニズムが使用されるかによって異なります。
バンドルのマージは複雑であるため（動的な状態アクセスのため）、バンドル マーケットは高度な集中化につながり、個々のリレーヤーがトランザクションを検閲できるようになります。 BP が被る可能性のある上記のようなリスクがあるため、BP はよく知られた信頼できるリレー業者と協力することを好みます。これらの有名なリレー業者と比較すると、個々のユーザーは十分に高い取引手数料で取引パッケージを提供することはできません。 排他期間とトランザクション プールを使用すると、高度な分散化が実現しますが、ユーザーの利便性が低下し、トランザクション プールの実装がより複雑になります。理論的には、どのユーザーもトランザクション プールからトランザクション パッケージを取得し、独自のトランザクションを追加してトランザクション パッケージを拡張し、より高いトランザクション手数料でトランザクション パッケージを中継することができます。
すべてのタイプのトランザクションをサポートするには、ブロックに含まれるトランザクション パッケージに最新の状態が含まれている必要があります。リレーヤーは以前のブロックをダウンロードし、トランザクション パッケージの対応する更新を作成してブロック プロポーザーに送信する必要があり、ブロック プロポーザーは更新されたトランザクション パッケージを新しいブロックに含めます。これらのアクションはすべて、1 つのスロットの時間内に完了する必要があります。 状態の損失はリレーヤーに起因する可能性があります。ブロック提案者は、リレーヤーにトランザクションに「払い戻しトランザクション」を添付するように依頼できます (またはリレーヤーが自発的に選択できます)。払い戻しトランザクションは、状態の損失によりトランザクションが失敗した場合に、ブロック提案者に払い戻すために使用されます。
トランザクション パッケージのサイズは大きく (Eth1 の個々の取引所で構成されるトランザクション プールとは対照的)、時間制約が厳しいため、単一のトランザクション プールでは不十分な場合があります。 トランザクション プールがないと、トランザクション パッケージを組み合わせることができないため、ブロックには単一のリレーヤーによって提案されたトランザクション パッケージのみを含めることができます。リレーラーは潜在的に集中化して検閲を導入する可能性があります。 トランザクション プールがあっても、トランザクション パッケージの組み合わせ機能が検閲の懸念を完全に軽減するのに十分であるかどうかは不明です。 プルモデル
ユーザーはネットワークにトランザクションを送信し、ノードは保留中のトランザクションのプールを維持します。ブロックを作成する前に、ブロック提案者はトランザクション プールから保留中のトランザクションをいくつか選択し、トランザクション パッケージを形成して、それをステータス プロバイダーに送信し、このトランザクション パッケージのステータスを要求します。ステータスを受け取った後、ブロックプロバイダーはトランザクション パッケージを新しいブロックにパッケージ化します。 状態プロバイダーがすべての状態を提供する前に、中間ノードとブロック提案者がトランザクションの有効性を検証できるように、ユーザーは署名とトランザクション手数料の支払い能力を検証する証人メッセージをトランザクションに添付する必要があります。したがって、この部分はさまざまな実行環境 (EE) で標準化する必要があり、すべての EE は最小限の検証機能オプションを提供する必要があります。 あるいは、Value-Holding EE (VHEE) を使用することもできます。各取引では、この VHEE を使用して手数料を支払います。ネットワーク内のノードは VHEE を理解し、トランザクションの有効性を検証できます。 どちらの場合も、ネットワーク内のノードは、新しいブロックが到着したときに追加の状態の証拠を更新する必要があります。 ブロック提案者は、トランザクション パッケージの実際のガス コストを予測することはできません。特別な状況では、トランザクション パッケージ内のトランザクションによって、送信者の残高が 0 に減るなど、このトランザクションの後続のすべてのトランザクションが無効になる可能性があります。この問題を軽減するために、ブロック提案者は「オーバーバンドル」、つまり、ブロックに含めると予想されるよりも多くのトランザクションを状態プロバイダーに送信します。州のプロバイダーは、ブロック上限に達するまでこれらのトランザクションのステータスを提供します。 VHEE が使用される場合、トランザクションには、VHEE アドレスのリストやこれらのアドレスから取得できる最大金額などの追加データが添付されることもあります。このようにして、ブロック提案者は、以前のトランザクションが後続のトランザクションを無効にすることを防ぐことができます。 主要な取引には制限はありません。ブロック提案者は、ブロックを作成するときにのみ状態プロバイダーに連絡し、返される状態が最新であることを確認します。さらに重要なのは、トランザクションをバンドルし、トランザクション バンドルで状態を要求することによって、状態が正しいコンテキストにアタッチされることです。このアプローチにより、提供される状態が常に十分であることが保証されます。これには、トランザクションがバンドルされる前に状態がアタッチされ、状態へのアクセスが制限されるダイレクト プッシュ モデルとの重要な違いがあります。 ユーザーは署名を検証するための状態と料金を支払う能力を含める必要があるため、技術的にはトランザクション部分の制限は Direct Push モデルに記載されているものと同じです。ただし、これらの制限は実際には重要ではありません。 Eth1 では署名検証と手数料支払いが予測可能な状態アクセスであるため、Eth1 と Eth2 間の互換性が損なわれることはありません。さらに、VHEE の場合、その設計により予測可能な状態アクセスが保証され、さらなる制限が不要になります。 ブロック提案者は、支払いチャネルまたはその他の手段を通じて、提供した状態に対して状態プロバイダーに支払うことができます。 BPと相手方のSP間の信頼に応じて、手数料は取引数（信頼を最小限に抑える）または取引パッケージ（より効率的）によって支払われる。 状態プロバイダーはすべての状態を保存する必要があり、大量のストレージが必要になります。州のプロバイダーはトランザクション パッケージを迅速に実行することも求められるため、計算能力に対する要件もあります。 ブロック提案者は、信頼する状態プロバイダーのグループから状態を取得する傾向が強くなり、悪意のある損害のリスクが軽減され、集中化が進む可能性があります。 ただし、ブロック提案者がトランザクション パッケージの作成と順序付けを担当するため、単一の状態プロバイダーがトランザクションを検閲することはできません。状態プロバイダーはトランザクションに必要な状態を隠す可能性がありますが、そうすると評判が損なわれ、ブロック提案者は別の状態プロバイダーで簡単に再試行できるようになります。 ブロック提案者は、トランザクション パッケージをチェーンにアップロードするために必要な状態を TA に提供できる状態プロバイダーに、時間枠内に連絡する必要があります。 状態プロバイダーは、常に、提供した状態に対して責任を負います。ブロック提案者は、不十分なステータスのトランザクションをブロックに含めることはできず、ステータスが十分であることを確認した後にのみ支払います。
重大な集中化リスクはありません。一部の州プロバイダーがブロック提案者への州サービスの提供を専門にすることが予想されますが、単一の州プロバイダーがプロセス全体に大きく干渉することはできません。状態プロバイダーが行う最悪の行為は、要求されたときに状態を提供しないことです。 主な欠点: 検証スクリプトまたは VHEE を使用して、署名検証の標準化を行う必要があります。 拡張された議論
自立した証人情報とガソリン代
トランザクションの送信者が残高を保証するのに十分な証人情報を提供できる場合、状態アクセスはより安価になりますか?証人情報もトランザクション内に配置され、署名されている場合、その最終性は保証されますが、複雑さが増します。
ステータス料金
ブロック提案者と状態プロバイダーはどのようにして状態の料金を交渉するのでしょうか?ネットワークによって設定されるのですか?ブロックを生成するには、ブロック提案者が複数の状態提案者に入札し、最も安価なものを選択する必要がありますか? 料金は国賓訪問の回数に基づいて計算されますか?それとも、証人データのサイズに基づいて計算する必要がありますか? 料金が証人データの量に基づいている場合、BP は SP に余分なバイトが含まれていないことをどのように知るのでしょうか? 複数のトランザクションで同じ証人を使用する場合、手数料は均等に分割される必要がありますか?それとも、取引ごとに全額が支払われるのでしょうか?それとも最初の取引のみ支払う必要がありますか?
状態抽象化
この提案では、実行環境がどのように状態を取得するかを正確に定義していませんが、プル モデルまたはリレー モデルのランタイムが必要になります。
分散型ステートネットワーク
トランザクションを収集してトランザクション パッケージ全体を状態プロバイダーに送信する代わりに、分散ハッシュ テーブルを作成し、ブロック提案者が実行中に状態を動的に取得できるようにすることは可能でしょうか?この代替アプローチでは、ネットワーク要求時のトランザクションの実行がブロックされるため、トランザクションのシリアル化が非常に遅くなったり、予測不可能になったりする可能性があります。この代替アプローチは、ソフトウェア トランザクション メモリの進歩を活用することでも実現できます。
（以上）
