著者: ヴィタリック・ブテリン

イーサリアムの創設者ヴィタリック・ブテリンは最近、プロトダンクシャーディング (別名 EIP-4844) に関連する質問に答えました。 Danksharding はイーサリアムに提案された新しいシャーディング設計ですが、この技術は何をもたらすのでしょうか?

ダンクシャルディングとは何ですか？

Danksharding は、イーサリアム用に提案された新しいシャーディング設計であり、以前の設計と比較していくつかの大幅な簡素化が導入されています。

2020 年以降のすべての最近のイーサリアム シャーディング提案 (Danksharding と以前の Danksharding を含む) とほとんどの非イーサリアム シャーディング提案の主な違いは、イーサリアムのロールアップ中心のロードマップです。イーサリアム シャーディング シャーディングは、トランザクション用に追加のスペースを提供するのではなく、データ用に追加のスペースを提供します。プロトコル自体は説明しようとしていません。

BLOB の検証では、BLOB が利用可能であること、つまりネットワークからダウンロードできることを確認するだけです。これらの BLOB 内のデータ スペースは、高スループット トランザクションをサポートするレイヤー 2 (レイヤー 2) ロールアップ プロトコルによって使用されることが予想されます。

Danksharding によって導入された主な革新は、統合された手数料市場です。固定数のシャードの代わりに、各シャードには異なるブロックと異なるブロック プロポーザーがあり、Danksharding では 1 つのプロポーザーのみがスロットへの入力を選択します。すべてのトランザクションとすべてのデータです。

この設計では検証者に対する高いシステム要件を回避するために、提案者/構築者分離 (PBS) を導入します。ブロック ビルダーと呼ばれる特別なクラスの参加者がスロットを選択する権利を入札し、提案者は入札を選択するだけで済みます。最も高い有効なヘッダーで十分です。 。

ブロック全体を処理する必要があるのはブロック ビルダーのみです (ここでは、サードパーティの分散型 Oracle プロトコルを使用して分散ブロック ビルダーを実装することもできます)。他のすべてのバリデーターとユーザーは、データの可用性を非常に効率的にサンプリングできます。 ブロックを検証します (「大きな」ことを思い出してください)。ブロックの一部は単なるデータです)。

プロトダンクシャーディング (別名 EIP-4844) とは何ですか?

Proto-danksharding (別名 EIP-4844) は、完全な Danksharding 仕様を構成するほとんどのロジックと「スキャフォールディング」 (トランザクション形式、検証ルールなど) を実装するイーサリアム改善提案 (EIP) ですが、実際には実装されていません。 。プロトダンクシャーディングの実装では、すべてのバリデーターとユーザーが完全なデータの可用性を直接検証する必要があります。

proto-danksharding によって導入された主な機能は、BLOB を使用したトランザクションと呼ばれる新しいトランザクション タイプです。 BLOB を使用したトランザクションは通常のトランザクションと似ていますが、BLOB と呼ばれる追加データも運ぶ点が異なります。 BLOB は非常に大きく (~125 KB)、同様の量の呼び出しデータよりもはるかに安価です。ただし、EVM の実行では BLOB データにアクセスできず、EVM が参照できるのは BLOB への Promise のみです。

バリデーターとクライアントは依然として完全な BLOB コンテンツをダウンロードする必要があるため、proto-danksharding のデータ帯域幅の目標は、ソケットごとに完全な 16 MB ではなく 1 MB です。ただし、このデータは既存のイーサリアム トランザクションのガス使用量と競合しないため、依然としてスケーラビリティの大きな利点があります。

calldata を 10 倍安くする代わりに、全員がダウンロードする必要があるチャンクに 1 MB のデータを追加しても問題がないのはなぜですか?

これは、平均負荷と最悪の場合の負荷の差に関係します。現在、平均ブロック サイズが約 90 KB である状況に遭遇しましたが、理論的に可能な最大ブロック サイズ (ブロック内の 30M ガスすべてがデータの呼び出しに使用される場合) は約 1.8 MB です。イーサリアム ネットワークは、最大数に近いブロックを処理していました。

ただし、単純に calldata ガスのコストを 10 分の 1 に削減すると、平均ブロック サイズはまだ許容できるレベルまで増加しますが、最悪の場合は 18 MB になり、これはイーサリアム ネットワークにとっては大きすぎます。

現在のガス価格設定スキームでは、これら 2 つの要素を分離できません。平均負荷と最悪の場合の負荷の比率は、通話データと他のリソースにどれだけのガスを費やすかというユーザーの選択によって異なります。つまり、ガス価格は、最悪の場合 の可能性設定により、負荷平均がシステムが処理できる値よりも不必要に低くなります。

ただし、ガス価格を変更してより明示的に多次元の料金市場を作成すると、平均ケースと最悪ケースの負荷の不一致を回避し、安全に処理できる最大量に近いデータを各ブロックに含めることができます。 Proto-danksharding と EIP-4488 は、これを行うための 2 つの提案です。

プロトダンクシャーディングと EIP-4488 を比較するとどうですか?

EIP-4488 は、同じ平均的な場合と最悪の場合の負荷の不一致の問題を解決するための、以前のより簡単な試みです。 EIP-4488 は、次の 2 つの単純なルールを使用してこれを実行します。

• Calldata のガスコストが 1 バイトあたり 16 ガスから 1 バイトあたり 3 ガスに削減されました

• ブロックごとに 1 MB の制限と、トランザクションごとに追加の 300 バイト (理論上の最大値: ~1.4 MB)

ハード制限は、平均的な場合の負荷が大幅に増加しても最悪の場合の負荷が増加しないようにする最も簡単な方法です。ガスコストの削減により、ロールアップの使用が大幅に増加し、平均ブロック サイズが数百 KB に増加する可能性がありますが、ハード リミットにより、単一ブロックに 10 MB が含まれる最悪の可能性が直接回避されます。実際、最悪の場合のブロック サイズは現在よりも小さくなります (1.4 MB 対 1.8 MB)。

プロトダンクシャーディングは代わりに、データを大きな固定サイズの BLOB に安価に保存し、各ブロックに含めることができる BLOB の数を制限する別のトランザクション タイプを作成します。これらの BLOB には EVM からアクセスできず (BLOB へのコミットメントのみ)、BLOB は実行層ではなくコンセンサス層 (ビーコン チェーン) によって保存されます。

EIP-4488 とプロトダンクシャーディングの主な実際的な違いは、EIP-4488 は現在必要な変更を最小限に抑えようとするのに対し、プロトダンクシャーディングには現在多くの変更が加えられているため、将来完全なシャーディングにアップグレードする際に必要な変更はほとんどないことです。

フルシャーディングの実装 (データ可用性サンプリングなどを使用) は複雑なタスクであり、プロトダンクシャーディング後も引き続き複雑なタスクですが、この複雑さはコンセンサス層に含まれています。プロトダンクシャーディングが開始されると、完全シャーディングへの移行を完了するために、エグゼクティブ層のクライアントチーム、ロールアップ開発者、およびユーザーがそれ以上の作業を行う必要はありません。

2 つの間の選択はどちらか一方ではないことに注意してください。EIP-4488 をできるだけ早く実装し、半年後にプロト ダンクシャーディングでフォローアップすることができます。

プロトダンクシャーディングは完全なダークシャーディングのどの部分を実装しますか?他に何を実装する必要がありますか?

EIP-4844 を引用すると、この EIP で行われた作業には次のものが含まれます。

• 「フル シャーディング」で存在する必要があるまったく同じ形式の新しいトランザクション タイプ。

• フルシャーディングに必要なすべての実行層ロジック。

• フルシャーディングにはすべての実行/コンセンサス相互検証ロジックが必要です。

• BeaconBlock 検証とデータ可用性サンプリング BLOB 間のレイヤー分離。

• フルシャーディングに必要な BeaconBlock ロジックのほとんど。

• BLOB の独立したガス価格を自動調整します。

• 完全なシャーディングを実現するには次の作業が必要です。

• 2D サンプリングを可能にするコンセンサス レイヤーの blob_kzgs の低レベル拡張。

• データ可用性サンプリングの実践的な実装、

• PBS (プロポーザー/ビルダー分割) により、1 つのスロットで 32 MB のデータを処理するために 1 つのバリデーターが必要になることを回避します。

• 各ブロック内のシャード データの特定の部分を検証するための、各バリデーターのエスクロー証明または同様のプロトコル内要件。

残りの作業はすべてコンセンサス層の変更であり、クライアント チーム、ユーザー、ロールアップ開発者が追加の作業を行う必要がないことに注意してください。

これらの非常に大きなチャンクがすべて必要なディスク容量を増やしたらどうなるでしょうか?

EIP-4488 と proto-danksharding の両方により、長期的な最大使用量はソケットあたり約 1 MB (12 秒) になります。これは年間約 2.5 TB に相当し、現在イーサリアムが必要とする成長率をはるかに上回っています。

EIP-4488 の場合、この問題を解決するには履歴有効期限スキーム (EIP-4444) が必要です。これにより、クライアントは一定期間 (1 か月から 1 年間の持続が提案されています) を超えて履歴を保存する必要がなくなります。 。

プロト ダンクシャーディングの場合、EIP-4444 が実装されているかどうかに関係なく、コンセンサス レイヤーは別のロジックを実装して、一定期間 (30 日など) 後に BLOB データを自動的に削除できます。ただし、短期的なデータ スケーリング ソリューションに関係なく、EIP-4444 をできるだけ早く実装することを強くお勧めします。

どちらの戦略も、コンセンサス クライアントの追加ディスク負荷を最大でも数百 GB に制限します。長期的には、何らかの履歴有効期限メカニズムの採用は基本的に必須です。フル シャーディングでは年間約 40 TB の履歴 BLOB データが追加されるため、ユーザーが実際に一時的に保存できるのはその一部のみです。したがって、早い段階でこれに対する期待を設定する価値があります。

データが 30 日後に削除された場合、ユーザーは古い BLOB にどのようにアクセスしますか?

イーサリアム コンセンサス プロトコルの目的は、すべての履歴データの永続的な保存を保証することではありません。代わりに、安全性の高いリアルタイム掲示板を提供し、他の分散プロトコルによる長期保存の余地を残すことが目的です。

掲示板は、掲示板に投稿されたデータを、そのデータを必要とするユーザー、またはデータをバックアップするための長期契約が必要なユーザーが、そのデータを取得して他のアプリケーションにインポートするのに十分な時間を確保できるよう、十分な期間利用可能であることを保証するために存在します。またはプロトコル。

一般に、履歴を長期間保存するのは簡単です。年間 2.5 TB は通常のノードには大きすぎる要件ですが、熱心なユーザーにとっては非常に扱いやすいものです。非常に大容量のハード ドライブを 1 TB あたり約 20 ドルで購入でき、愛好家にとっては十分以上です。

N/2-of-N 信頼モデルを持つコンセンサスとは異なり、履歴ストレージには 1-of-N 信頼モデルがあります。つまり、正直に言うと、データ ストアラーの 1 つだけが必要です。したがって、リアルタイムのコンセンサス検証を行う数千のノードではなく、各履歴データを数百回保存するだけで済みます。

完全な履歴を保存し、簡単にアクセスできるようにする実用的な方法には、次のようなものがあります。

• Rollup などのアプリケーション固有のプロトコルでは、ノードがアプリケーションに関連する履歴の部分を保存する必要がある場合があります。履歴データの損失はプロトコルにリスクをもたらすものではなく、個々のアプリケーションにのみリスクをもたらすため、アプリケーションが自身に関連するデータを保存する負担を負うことは理にかなっています。

• BitTorrent への履歴データの保存。ブロックの BLOB データを含む 7 GB ファイルが自動的に生成され、毎日配布されます。

• イーサリアム ポータル ネットワーク (現在開発中) は、履歴を保存するために簡単に拡張できます。

• ブロック エクスプローラー、API プロバイダー、およびその他のデータ サービスには、完全な履歴が保存される場合があります。

• データ分析に携わる個人の愛好家や学者は、完全な履歴記録を保存する場合があります。後者の場合、履歴をローカルに保存すると、履歴に基づいて直接計算することが容易になるため、大きな価値が得られます。

• TheGraph などのサードパーティのインデックス作成プロトコルには、完全な履歴が保存される場合があります。

履歴ストレージのレベルが高くなると (例: 年間 500 TB)、一部のデータが忘れられるリスクが高くなります (さらに、データ可用性検証システムの負荷も高くなります)。これが、シャード化されたブロックチェーンのスケーラビリティの本当の限界である可能性があります。しかし、現在提案されているパラメータはすべてこの点からは程遠いものです。

BLOB データの形式と送信方法は何ですか?

BLOB は、4096 個のフィールド要素のベクトルであり、次の範囲の数値です。

0 <= x < 52435875175126190479447740508185965837690552500527637822603658699938581184513

ブロブは、上記の係数を持つ有限体上の次数 4096 未満の多項式を表すものとして数学的に見なされます。ブロブ内の位置 i のフィールド要素は、wi でのその多項式の評価です。 ｗはｗ＝１を満たす定数である。

BLOB へのコミットメントは、多項式への KZG コミットメントのハッシュです。ただし、実装の観点からは、多項式の数学的な詳細を気にすることは重要ではありません。代わりに、(信頼できるラグランジュ設定に基づく) 楕円曲線点のベクトルのみが存在し、ブロブに対する KZG コミットメントは単に線形結合になります。 EIP-4844 からコードを引用:

def blob_to_kzg(blob: Vector[BLSFieldElement, 4096]) -> KZGCommitment: computed_kzg = bls.Z1 for value, point_kzg in zip(tx.blob, KZG_SETUP_LAGRANGE): assert value < BLS_MODULUS computed_kzg = bls.add( computed_kzg, bls.multiply(point_kzg, value) ) return computed_kzg

BLS_MODULUS は上記の係数、KZG_SETUP_LAGRANGE は楕円曲線点のベクトルで、ラグランジュに基づく信頼できるセットアップです。実装者にとって、これを単にブラックボックスに特化したハッシュ関数と考えるのが妥当です。

なぜ直接 KZG ではなく KZG のハッシュを使用するのでしょうか?

KZG を使用して BLOB を直接表す代わりに、EIP-4844 はバージョン付きハッシュを使用します。つまり、単一の 0x01 バイト (このバージョンを示す) の後に KZG の SHA256 ハッシュの最後の 31 バイトが続きます。

これは、EVM の互換性と将来の互換性のために行われます。KZG の約束は 48 バイトですが、EVM はより自然に 32 バイトの値を使用します。KZG から他のものに切り替えても (たとえば、量子耐性の理由で)、KZG の約束は引き続き使用できます。 32バイト。

proto-danksharding で導入された 2 つのプリコンパイルとは何ですか?

プロトダンクシャーディングでは、ブロブ検証プリコンパイルとドッ​​ト評価プリコンパイルの 2 種類のプリコンパイルが導入されています。

BLOB 検証プリコンパイルは一目瞭然です。入力としてバージョン付きハッシュと BLOB を受け取り、提供されたバージョン付きハッシュが実際に BLOB の有効なバージョン付きハッシュであることを検証します。このプリコンパイルは、オプティミスティック ロールアップで使用することを目的としています。 EIP-4844 を引用:

オプティミスティック ロールアップでは、不正行為の証拠を提出するときに、実際に基礎となるデータを提供するだけで済みます。不正証明送信機能では、不正 BLOB の内容全体を呼び出しデータの一部として送信する必要があります。 BLOB 検証を使用して、以前にコミットされたバージョン管理されたハッシュに対してデータを検証し、その後、現在と同様にそのデータに対して不正行為の証明の検証を実行します。

ポイント評価プリコンパイルは、バージョン化されたハッシュ、x 座標、y 座標、および証明 (BLOB の KZG コミットメントおよび KZG 評価証明) を入力として受け取ります。これは、P(x) = y であることを確認する証明を検証します。ここで、P は、指定されたバージョン化されたハッシュを持つ BLOB によって表される多項式です。このプリコンパイルは、ZK Rollup で使用することを目的としています。 EIP-4844 を引用:

ZK ロールアップは、トランザクションまたは状態デルタ データに対して 2 つのコミットメントを提供します。BLOB 内の KZG と、ZK ロールアップが内部で使用する証明システムを使用したコミットメントです。彼らは、点評価プリコンパイルを使用した等価プロトコルのコミットメント証明を使用して、kzg (利用可能なデータを指すプロトコル保証) と ZK ロールアップ自身のコミットメントが同じデータを参照していることを証明します。

ほとんどの主要なオプティミスティック ロールアップ デザインでは、マルチラウンドの不正防止スキームが使用されており、最後のラウンドに必要なデータは少量だけであることに注意してください。したがって、おそらく、Optimistic Rollup は、BLOB 検証プリコンパイルの代わりにポイント評価プリコンパイルを使用することもでき、そうするほうがコストが安くなります。

KZG の信頼できるセットアップはどのようなものですか?

見て：

信頼できる設定がどのように機能するかについての一般的な説明

powers-of-tau については https://vitalik.ca/general/2022/03/14/trustedsetup.html 

すべての重要な信頼できるセットアップ関連の計算の実装例

https://github.com/ethereum/research/blob/master/trusted_setup/trusted_setup.py

特に今回の場合、現在の計画では 4 つのサイズ (n1=4096、n2=16)、(n1=8192、n2=16)、(n1=16834、n2=16)、および (n1= 32768、 n2=16) 儀式 (別の秘密を使用)。理論的には、最初の 1 つだけが必要ですが、より大きなサイズをより多く実行すると、ブロブ サイズを増やすことができるため、将来の適用性が向上します。効果的にコミットできる多項式の数に、BLOB サイズと等しい厳密な制限を設ける必要があるため、単に大規模なセットアップを行うことはできません。

考えられる実際的なアプローチは、Filecoin のセットアップから始めて、それをスケールするセレモニーを実行することです。ブラウザ実装を含む複数の実装により、多くの人が参加できるようになります。

信頼できるセットアップなしで他のコミットメント スキームを使用することはできないでしょうか?

残念ながら、KZG 以外 (IPA や SHA256 など) を使用すると、シャーディング ロードマップがより困難になります。これにはいくつかの理由があります。

非算術コミットメント (ハッシュ関数など) はデータ可用性サンプリングと互換性がないため、そのようなスキームを使用する場合、フル シャーディングに移行するときに、とにかく KZG に変更する必要があります。

IPA はデータ可用性サンプリングと互換性があるかもしれませんが、弱い特性を持つより複雑なスキームになります (例: 自己修復や分散ブロックの構築が難しくなります)。

ハッシュと IPA は両方とも、ポイント評価プリコンパイルの安価な実装と互換性がありません。したがって、ハッシュまたは IPA ベースの実装では、ZK ロールアップを効果的に有効にしたり、オプティミスティック ロールアップの複数ラウンドで安価な不正証明をサポートしたりすることはできません。

したがって、残念なことに、KZG 以外のものを使用することによる機能の喪失と複雑さの増大は、KZG 自体のリスクをはるかに上回ります。さらに、KZG 関連のリスクもすべてカバーされます。KZG の障害は、ロールアップおよび BLOB データに依存するその他のアプリケーションにのみ影響し、システムの残りの部分には影響しません。

KZGはどれほど「複雑」で「新しい」のでしょうか？

KZG コミットメントは 2010 年の論文で導入され、2019 年以降 PLONK スタイルの ZK-SNARK プロトコルで広く使用されています。ただし、KZG が約束する基礎的な数学は、楕円曲線演算とペアリングの基礎的な数学に加えて、比較的単純な算術です。

使用される特定の曲線は、2002 年に Barreto-Lynn-Scott によって発明された BLS12-381 です。 KZG の約束を検証するために必要な楕円曲線ペアは非常に複雑な数学ですが、1940 年代に発明され、1990 年代から暗号化に使用されてきました。 2001 年までに、ペアリングを使用した暗号化アルゴリズムが多数提案されました。

実装の複雑さの観点から見ると、KZG は IPA よりも実装が難しくありません。コミットメントを計算する関数 (上記を参照) は、楕円曲線点定数の異なるセットを使用するだけで、IPA の場合とまったく同じです。ポイントベリファイ プリコンパイルはペアの評価を伴うためより複雑ですが、計算は EIP-2537 (BLS12-381 プリコンパイル) 実装ですでに行われているものと同じであり、bn128 ペア プリコンパイルと非常によく似ています (「最適化」も参照) Python の達成)。したがって、KZG 検証を実装するために複雑な「新たな作業」は必要ありません。

プロトダンクシャーディング実装のさまざまなソフトウェア部分は何ですか?

主要なコンポーネントは次の 4 つです。

1. 実行層のコンセンサスが変更されました (詳細については EIP を参照してください)。

• BLOB を含む新しいトランザクション タイプ

• 現在のトランザクションの i 番目の BLOB のバージョン付きハッシュを出力するオペコード

• BLOB 検証のプリコンパイル

• ドット評価プリコンパイル

2. コンセンサス層のコンセンサスの変更 (リポジトリ内のこのフォルダを参照):

• BeaconBlockBody の BLOB KZG のリスト

• 完全な BLOB コンテンツが BeaconBlock から別のオブジェクトとともに渡される「サイドカー」メカニズム

• 実行層の BLOB バージョン管理ハッシュとコンセンサス層の BLOB KZG の間のクロスチェック

3. メモリプール

• BlobTransactionNetworkWrapper (EIP のネットワーク セクションを参照)

• 大きなブロブ サイズを補うための強力な DoS 対策保護

4. ブロック構築ロジック

• メモリプールからトランザクションラッパーを受け入れ、トランザクションをExecutionPayloadに配置し、KZGをビーコンブロックに配置し、ボディをサイドカーに配置します

• 二次元的な料金市場への対応

最小限の実装では、mempool はまったく必要なく (第 2 層のトランザクション バンドル マーケットに依存できます)、クライアントがブロック構築ロジックを実装するだけでよいことに注意してください。実行層とコンセンサス層のコンセンサス変更のみが広範なコンセンサス テストを必要とし、比較的軽量です。このような最小限の実装と、すべてのクライアントがブロック生成とメモリプールをサポートする「完全な」展開との間のあらゆるものが可能です。

ダンクシャーディングの原型となる多次元手数料市場とはどのようなものでしょうか?

プロトダンクシャーディングでは、ガスとブロブという 2 つのリソースを備えた多次元 EIP-1559 料金市場が導入され、個別の変動ガス価格と個別の制限が設けられています。

イーサリアム

BLOB 料金はガスで請求されますが、ガスの量は可変であり、長期的にはブロックあたりの平均 BLOB 数が実際に目標量と等しくなるように調整されます。

二次元の性質は、ブロックビルダーがより困難な問題に直面することを意味します。つまり、トランザクションがなくなるかブロックガスの制限に達するまで、単に最優先の手数料でトランザクションを受け入れるのではなく、両方の異なる制限に達することを回避する必要があります。

ここに一例を示します。ガス制限が 70、ブロブ制限が 40 であるとします。 mempool にはブロックを埋めるのに十分な多くのトランザクションがあり、2 つのタイプがあります (TX ガスには BLOB ごとのガスが含まれます)。

• 優先料金 1 ガスあたり 5、ブロブ 4、合計ガス 4

• 優先料金 1 ガスあたり 3、ブロブ 1、ガス合計 2

イーサリアム

実行クライアントは、ブロック生成を最適化するために複雑な多次元ナップザック アルゴリズムを実装する必要がありますか?いいえ、いくつかの理由があります。

• EIP-1559 は、ほとんどのブロックがどちらの制限にも達しないことを保証するため、実際に多次元最適化問題に直面するブロックは少数です。どちらかの制限に達するのに十分な (支払いに十分な) トランザクションが mempool にない通常の場合、マイナーは目にするすべてのトランザクションを含めることで最適に収益を得ることができます。

• 実際には、かなり単純なヒューリスティックが最適に近づく可能性があります。同様の状況でのデータについては、Ansgar による EIP-4488 の分析を参照してください。

• 多次元の価格設定は専門化による最大の収益源ですらない - MEV です。オンチェーン DEX 裁定取引、清算、フロントランニング NFT 販売などから専用アルゴリズムを介して抽出された専用 MEV 収益は、「抽出可能な収益」合計 (優先手数料など) のかなりの部分を占めます。専用 MEV 収益は平均約 0.025 ETH であると思われますゾーンブロックごとの優先料の合計は、通常、ブロックごとに約 0.1 ETH です。

• 提案者と構築者の分離は、高度に特殊化されたブロック生成を中心に設計されています。 PBS は、ブロック構築プロセスをオークションに変え、プロの参加者がブロックを作成する特権を競います。通常のバリデーターは、最高入札額を受け入れるだけで済みます。これは、MEV 主導の規模の経済がバリデータの集中化に忍び寄るのを防ぐためですが、ブロック構築の最適化をより困難にする可能性があるすべての問題に対処します。

これらの理由から、より複雑な料金市場の動向によって集中化やリスクが大幅に増加することはありません。実際、より広範に適用される原則により、実際に DoS 攻撃のリスクを軽減できます。

Exponential EIP-1559 BLOB 料金調整メカニズムはどのように機能しますか?

現在の EIP-1559 では、特定の目標ガス使用量レベル t を達成するために、基本料金 b を次のように調整します。

ここで、b(n) は現在のブロックの基本料金、b(n+1) は次のブロックの基本料金、t はターゲット、u は使用されるガスです。

イーサリアム

平均使用量は t ですが、基本料金は 63/64 下がります。したがって、基本料金は、使用量が t をわずかに上回る場合にのみ安定します。正確な数値は変動によって異なりますが、実際には約 3% 高いようです。

より良い公式は指数調整です。

exp(x) は指数関数 e^x で、e≈2.71828 です。 xの値が小さい場合は、exp(x)≒1+xとなります。ただし、トランザクションの順列とは関係のない、多段階調整という便利な特性があります。

イーサリアム

したがって、含まれる同じトランザクションは、異なるブロック間でどのように分散されているかに関係なく、最終的な基本料金は同じになります。

上記の最後の式にも自然な数学的解釈があります。項 (u1+u2+...+u/n-nt) は冗長であると見なすことができます。つまり、実際に使用される総ガスと使用が意図されている総ガスの差です。

現在の基本料金は次のとおりです

超過額が非常に狭い範囲を超えることはできないという事実: 超過額が 8t*60 を超えると、基本料金は e^60 になり、非常に高すぎて誰も支払うことができなくなり、0 を下回った場合、リソースは基本的に無料になります。そして、超過がゼロを超えるまでチェーンはスパム送信されます。

調整メカニズムは、実際の合計 (u1+u2+...+u/n) を追跡し、目標合計 (nt) を計算し、その差の指標として価格を計算します。計算を簡単にするために、e^x の代わりに 2^x を使用します。実際には、2^x の近似値 (EIP の fake_exponential 関数) を使用します。偽のインデックスは、ほとんどの場合、実際の値の 0.3% 以内にあります。

長時間の使用率不足により 2x フルブロックが長時間発生することを防ぐために、余分なブロックをゼロ以下にしないという追加機能を追加しました。 actual_total が target_total よりも小さい場合は、actual_total を target_total と等しく設定するだけです。極端な場合（BLOB ガスがゼロまで低下する場合）、これによりトランザクション順序の不変性が崩れますが、安全性が追加されるため、これは許容可能なトレードオフになります。

また、この多次元市場の興味深い結果にも注目してください。プロトダンクシャーディングが最初に導入されたとき、最初はユーザーが非常に少ない可能性が高いため、しばらくの間は、ブロブのコストは、「通常の」場合でも、ほぼ確実に非常に安くなります。イーサリアムブロックチェーン活動は依然として高価です。

著者らは、この料金調整メカニズムは現在のアプローチよりも優れていると考えているため、最終的には EIP-1559 料金市場のすべてのセグメントがこのメカニズムの使用に移行するはずです。

より長く詳細な説明については、Dankrad の投稿を参照してください。

fake_exponential はどのように機能しますか?

便宜上、fake_exponential のコードを次に示します。

def fake_exponential(numerator: int, denominator: int) -> int: cofactor = 2 ** (numerator // denominator) fractional = numerator % denominator return cofactor + ( fractional * cofactor * 2 + (fractional ** 2 * cofactor) // denominator ) // (denominator * 3)

イーサリアム

目標は、(QX) の多数のインスタンスをつなぎ合わせ、そのうちの 1 つを [2^k,2^(k+1)] 範囲ごとに適切にシフトおよびスケーリングすることです。 Q(x) 自体は、0≤x≤1 の 2^x の近似値であり、次の特性のために選択されます。

• シンプルさ（二次方程式です）

• 左端の正確さ (Q(0)=2^0=1)

• 右エッジの正確性 (Q(1)=2^1=2)

• 滑らかな傾き (Q'(1)=2∗Q'(0) であることを保証するため、Q の各シフト + スケールされたコピーの右端の傾きは、次のコピーの左端の傾きと同じになります)

最後の 3 つは、3 つの未知の係数を与えられた 3 つの線形方程式を必要とし、上で与えられた Q(x) が唯一の解を与えます。

イーサリアム

プロトダンクシャルディングではどのような問題がまだ議論されていますか?

注: このセクションは古くなりがちです。特定の問題に関する最新の考え方を提供するものだと信じないでください。

• すべての主要なオプティミスティック ロールアップはマルチラウンド証明を使用するため、BLOB 検証プリコンパイルの代わりに (はるかに安価な) ポイント評価プリコンパイルを使用できます。本当に BLOB 検証が必要な場合は、誰でも自分で実装できます。BLOB D とバージョン付きハッシュ h を入力として受け取り、x=hash(D,h) を選択し、重心評価を使用して y=D(x) を計算し、h をコンパイルして検証します。 (x)=y。それでは、BLOB 検証のプリコンパイルは本当に必要なのでしょうか、それともそれを削除してポイント評価のみを使用できるのでしょうか?

• チェーンは長時間続く 1 MB 以上のブロックを処理する能力はどの程度ですか?リスクが大きすぎる場合は、まずターゲット BLOB 数を減らす必要がありますか?

• BLOB はガスまたは ETH (燃焼) で表されるべきですか?手数料市場には他にも調整が必要でしょうか?

• 新しいトランザクション タイプは BLOB として考慮されるべきですか、それとも SSZ オブジェクトとして考慮されるべきですか。後者の場合、ExecutionPayload をユニオン タイプに変更しますか? (これは、「今さらに作業を行う」と「後でさらに作業を行う」のトレードオフです)

• 信頼できるセットアップの実装の正確な詳細 (このようなセットアップは実装者にとって「単なる定数」であるため、技術的には EIP 自体の範囲を超えていますが、それでも実行する必要があります)。