EIP-8037には2つの故障モードがあります:(1)生成される状態バイトが少なすぎる、(2)通常のガス使用量が少なすぎる。もしユーザーが今日のように通常のガスユニットあたりの状態バイト数を同じ数作成し、10倍にスケールすれば、平衡状態では通常のブロック空間の約6%しか利用されません。🧵⬇️
したがって、故障モード(2)は極端にePBSやBALによって得られたスケーリングの大部分を失うことになります。問題は、需要の価格弾力性に関する私たちの不完全な知識にあります。利用者は州と通常のガスの50/50の支出配分から逸脱する可能性があります。
6%のブロックスペース利用率は、ユーザーが18.9倍のガスコスト上昇で相対的な状態生成を減らすことになるため、非常に非現実的です。それでも、状態が少なすぎるか、通常のガスを消費しすぎているかのどちらかという、もっともらしい結果の幅は広範囲にあります。
この問題に対処する最も原則的な方法は、EIP-8075のようにヘッダー変数で状態作成を追跡することです。状態ガスコストは需要に応じて適応し、目標および制限がそれに応じて拡大・収縮するために必要な状態バイト数が生成されます。
また、弾性を最初に観測した後にEIP-8075処理を手動で適用することも可能です。これは、望ましい均衡をもたらすと考えるガスコストを調整するための別個の州ガス制限を設定し、メーターの際に州のガスを正規化する可能性を含みます。
必要に応じて、このような変更は後のハードフォークで行うことも可能です。しかし、この方法には長期間誤った価格設定のリスクを抱えるという欠点もあります。このため、成長調整にも使える状態-ガスパラメータのみ(SGPO)ハードフォークを検討できます。
しかし長期的なビジョンは、EIP-7999のような多次元的な料金市場と、州の成長をより良く管理するための工学的取り組み(州の一部が期限切れになる可能性もあります)を組み合わせることです。
32