原文
The case for a variable PTC deadline with affine metering and a unified calldata price — aelowsson (2026-04-22)
アフィンメータリングと統一されたcalldata価格を用いた可変PTCデッドラインの提唱
フィードバックをくれたToniに感謝します。
この記事では、単一の統一されたcalldata価格と組み合わせた可変PTCデッドラインの使用を提唱します。提案するアプローチは、可変PTCデッドラインを、最新のPTCデッドライン後にも常に実行のための余地を残す上限と組み合わせるというものです。この余地は、いずれにせよ伝播には使用できません。calldataの使用量によってPTCデッドラインが線形にシフトし、calldataと実行の間にアフィンなリソース制約を定義するため、この一般的なアプローチをアフィンメータリングと呼びます。
特定された利点は以下の通りです。
- スロットのより大きな割合を実行に使用できるため、Ethereumのスループットとガス制限を約2倍にすることができます。この側面は、議論を裏付ける方程式と図とともに、この記事の焦点となります。
- すべてのcalldataバイトに対して単一の価格を使用することで、ガス会計が簡素化されます。
- ゲーム化されやすさを回避します。EIP（Ethereum 改善提案）-7976では、多くの実行を伴うトランザクションが、大きな価格差のために安価なcalldataアロケーションを競りにかける可能性があります。
- 多次元手数料市場と互換性があります。EIP（Ethereum 改善提案）-7999で同じアプローチを使用する意図があり、Block-in-Blobs（EIP（Ethereum 改善提案）-8142）の実装が最終的にcalldata価格のさらなる調整を必要とするまで続きます。これについては、記事の最後のセクションでさらに詳しく説明します。
欠点としては、この提案がすべてのトランザクションのcalldata価格変更を必要とするのに対し、EIP（Ethereum 改善提案）-7976はフロアコストのみを変更する点です。しかし、いずれにせよcalldataの価格改定が予定されているのであれば、これが適切なタイミングかもしれません。他のいくつかのリソースはすでに価格改定されているため、追加のリソースを変更することによる相対的な影響は小さいと考えられます。もしEIP（Ethereum 改善提案）-7976がGlamsterdamにとって好ましいアプローチであり続けるとしても、アフィンメータリングは、特に互換性があり、多次元手数料市場の下でもスケーリングの恩恵をもたらすため、Hegota以降のcalldata価格設定における次のステップとなり得るでしょう。
はじめに
ePBS（プロポーザー・ビルダー分離）の下では、PTCペイロード観測デッドラインは2つの役割を同時に果たしています。それはペイロード伝播の適時性しきい値であり、スロットが終了するまでに残された実行時間も決定します。EIP（Ethereum 改善提案）-7732は、コンセンサス検証と実行検証の分離を明確にしています。ペイロードサイズに応じてシフトする可変PTCデッドラインが提案されています。可変デッドラインは、可変ペイロード観測時間を持つデュアルデッドライン設計を使用します。EIP（Ethereum 改善提案）-7976スタイルの価格設定の下では、可変PTCデッドラインはスケーリングにあまり貢献せず（1、2）、ガス制限を1/16増加させるだけであることが指摘されています。
すべてのcalldataがゼロである最悪のケースでは、トランザクション内の15実行ガスごとに、ユーザーは1ガスで16ガス相当のフロア価格のcalldataを購入できます。より高いグローバルガス制限は、完全なcalldata価格が示唆する真のネットワークフットプリントと比較して、非常に少ないガスしか消費しない多くのcalldataを含むペイロードを許容することになります。可変デッドラインは、安価なcalldataとフロア価格のcalldataの比率、つまり4/64 = 1/16に相当する追加のヘッドルームしかサポートできません。個々のブロックにははるかに多くの余裕があるとしても、その余裕は、時間内に伝播および実行できないブロックを許容することなく、より高いガス制限に変換することはできません。
代わりに、統一されたcalldata価格、例えば32ガス/バイトが、すべてのcalldataユニットに一律に適用される場合、状況は改善します。可変PTCデッドラインは、その全運用範囲にわたってスケーリングの恩恵を提供できます。これは、小さなペイロードが配信され得る最も早い時点から、PTCがその投票を伝播させる時間を残しつつ投票できる最も遅い時点までです。この記事では、可変PTCデッドラインの下でのアフィンメータリングをレビューし、一般的な方程式を設定し、スケーリングの利点を示します。
一般的なモデル
ePBS（プロポーザー・ビルダー分離）によって課される制約の下で、最大のスケールを促進するためにcalldataはどのように扱われるべきでしょうか？T_1をアテステーションデッドライン、T_2をPTCの可能な限り最新のデッドライン、T_3をスロットの終わり、cを固定の伝播オーバーヘッドとします。伝播時間を測定するためのより精緻なタイミングモデルが開発されていますが、ここでは単純なモデルで十分です。g_cをペイロードが使用するcalldataガス、G_cをデータ負荷が最大のペイロード、つまりT_2に間に合うように到着することが許されるペイロードに対応するcalldataガス予算とします。全体のガス制限はGで示されます。G_c = Gとすることも可能ですが、以下に示すように、calldataにG_c < Gというより厳格な制限を課す方が望ましいです。t_bをcalldataバイトあたりの伝播時間、Bを最大calldataバイト予算とします。同じアプローチは、例えばBALバイトやEIP（Ethereum 改善提案）-7934のようなブロックサイズ制限でカバーされる任意のバイトなど、他のバイトにも拡張できます。そのような考慮事項は統合することが重要ですが、この記事の焦点ではなく、ここではベースラインのモデリングに焦点を当てます。
ペイロードがT_2までに完全に伝播することを保証するために、最大バイト予算は以下を満たす必要があります。
T_1 + c + t_b B = T_2.
したがって、calldataバイトサイズに関する制約は次のようになります。
B = \frac{T_2 - T_1 - c}{t_b}.
calldataが単一の価格を持ち、バイトあたりg_bガスで線形に価格設定されている場合、calldataガス予算は次のようになります。
G_c = g_b B,
したがって、必要なcalldataガス価格は次のようになります。
g_b = \frac{G_c}{B} = \frac{t_b G_c}{T_2 - T_1 - c}.
同様に、g_c calldataガスを使用するペイロードの場合、可変PTCデッドラインは直接次のように書くことができます。
T_{\mathrm{PTC}}(g_c) = T_1 + c + \frac{g_c}{G_c}(T_2 - T_1 - c).
calldataの割合 p = \frac{g_c}{G_c} を定義すると便利です。このモデルではcalldataが線形に価格設定されているため、pは使用される最大バイト予算の割合でもあります。前の式は次のようになります。
T_{\mathrm{PTC}}(p) = T_1 + c + p(T_2 - T_1 - c).
これにより依存関係が明確になります。calldataの使用量が0からG_cに移動するにつれて、デッドラインはT_1+cからT_2に線形に移動します。PTCデッドライン後に残された実行ウィンドウは次のとおりです。
W_e(p) = T_3 - T_{\mathrm{PTC}}(p).
代入すると次のようになります。
W_e(p) = (T_3-T_2) + (1-p)(T_2-T_1-c).
したがって、calldataの使用量が減少するにつれて、未使用の伝播時間が追加の実行ウィンドウになります。図1は、以下の例示的な条件下で、価格設定とメータリングがスケーリングにどのように影響するかを示しています。
T_1 = 3\mathrm{s}, \qquad T_2 = 9\mathrm{s}, \qquad T_3 = 12\mathrm{s}, \qquad c = 2\mathrm{s}.
スケーリング効果を分かりやすくするために、両軸は正規化されています。縦軸はバイトシェアb、すなわちcalldataバイトをバイト上限Bで割ったものであり、線形価格設定の下ではb=p=g_c/G_cです。横軸は、元の全実行ブロックに対する実行量です。
e = \frac{W_e(p)}{T_3-T_2}.
これらの正規化された例全体を通して、eの1単位は、元のT_3-T_2実行ウィンドウを埋める実行作業です。
図1. 簡素化された価格設定とアフィンメータリングを用いた可変PTCデッドラインの下でのスケーリングの利点を示す。青色の提案の下では、固定PTCデッドラインと比較してガス制限をs = 7/3倍に増やすことができる。赤色のEIP（Ethereum 改善提案）-7976の下では、ヘッドルームは1/16、すなわち17/16倍に過ぎない。現在のEIP（Ethereum 改善提案）-7623の下では、可変PTCデッドラインはEIP（Ethereum 改善提案）-7976よりも大きな利点をもたらす可能性があるが、そのEIP（Ethereum 改善提案）はガス制限が増加するにつれてペイロードが大きくなりすぎることを許容する。細い点線で示される典型的なブロック構成の場合、提案された設計ではEIP（Ethereum 改善提案）-7976と比較して約2倍のスループットが達成される（青と赤の円を比較）。
この提案の下では、正規化された実行フロンティアは次のようになります。
e = 1 + \frac{T_2-T_1-c}{T_3-T_2}(1-b).
提案された条件では、T_2-T_1-c = 4\mathrm{s}、T_3-T_2 = 3\mathrm{s}となります。したがって、提案フロンティアは次のようになります。
e = 1 + \frac{4}{3}(1-b).
これは図1の青い実線です。分数4/7はタイミングの分割に由来します。可変伝播間隔は4\mathrm{s}、T_1+cからT_3までのオーバーヘッド後の全間隔は7\mathrm{s}です。これはcalldata上限G_c=\frac{4}{7}Gに対応し、データ負荷が最大のブロック（b=1）でも、1つの全実行ブロック（e=1）のための余地を残します。もう一方の極端なケースでは、b=0の場合、T_1+cからT_3までの全間隔を実行に使用でき、e=\frac{7}{3}となります。具体的には、G=300\mathrm{M}、G_c=4G/7の場合、統一されたcalldata価格が32ガス/バイトであれば最大5.36 MBのcalldataを、48ガス/バイトであれば3.57 MBを許容します。
点線の青い線は、代わりにG_c=Gの場合を示しています。この場合、バイトと実行は同じガス予算に対して完全にトレードオフされるため、データ負荷が最大のブロックはガス制限全体を消費し、ガス会計に実行を残しません。図1には、実行とバイトが単純に1対1で置き換わる、EIP（Ethereum 改善提案）-7623以前のケースである灰色のベースラインe+b=1も含まれています。
オレンジ色と赤色の線は、バイト側が元の最大calldataブロックで個別に上限設定されていると仮定しています。そのような上限がない場合、EIP（Ethereum 改善提案）-7976の下でガス制限をGからG’に引き上げると、すべてのフロア価格の最大バイトブロックはG/64からG’/64に単純に増加し、ブロックは伝播予算を超過することになります。バイト上限が設定されている場合、余分なガスは実行としてのみ現れ、バイトシェアの各単位は、ゼロバイト/フロア価格比率（EIP（Ethereum 改善提案）-7976では4/64=1/16、EIP（Ethereum 改善提案）-7623では4/10=0.4）によってのみ実行を置き換えます。したがって、バイトシェアが0から1に移動するにつれて、赤色の線はわずか1/16しか減少しないため、ほぼ垂直になります。より包括的な分析は次のセクションで提供されます。薄い赤色とオレンジ色のセグメントは、元のガス制限s=1での対応する固定デッドラインフロンティアを示しています。可変PTCデッドラインはこれらのフロンティアを右にシフトさせます。
円は、正規化された9:1の実行対バイト比、つまり9/10の実行と1/10のバイトに対応する、例示的なミックスb=e/9との交点を示しています。EIP（Ethereum 改善提案）-7623とEIP（Ethereum 改善提案）-7976の場合、この点は、バイトの5/6が安価に購入され、1/6がフロア価格であると仮定されるトランザクションミックスに従ってシフトされます。
可変PTCデッドラインの下でのEIP（Ethereum 改善提案）-7623およびEIP（Ethereum 改善提案）-7976価格設定の限界
わずかに異なる焦点を当てた別の説明がこちらで利用可能です（1、2）。
図1の提案は、calldataが生成する伝播負担に直接比例してcalldataを価格設定します。この場合、calldataを減らすと常に伝播時間が解放され、それが追加の実行時間として使用できます。EIP（Ethereum 改善提案）-7976およびEIP（Ethereum 改善提案）-7623の下では、calldataには2つの実効価格があります。一部のcalldataは実行とともに安価に運ぶことができ、残りのcalldataはより高いフロア価格で購入されます。
固定デッドラインのガス制限が、純粋な計算ブロックが実行ウィンドウをちょうど満たし、最大バイトブロックが伝播ウィンドウをちょうど満たすまで、すでに引き上げられていると仮定します。EIP（Ethereum 改善提案）-7976の下では、すべてのフロア価格の最大バイトブロックのサイズはB = G/64です。ここでガス制限をG’ > Gに引き上げると、最悪ケースのすべてのフロア価格のブロックはB’ = G’/64に増加します。古い最大バイトブロックはすでにT_2までにちょうど収まっていたため、新しいブロックは収まりません。この枠組みでは、可変PTCデッドライン自体はガス制限の増加を全く正当化しません。
しかし、バイトサイズもBに固定されている場合、例えば別のバイトサイズ上限によって、ガス制限をG’に引き上げることが可能になります。ほとんど実行のみを含むブロックには、より早いデッドラインを割り当てることができます。ブロックがその実行とともに安価なバイトを運び始めると、デッドラインは元の開始点であるT_2に到達するまで遅くプッシュされなければなりません。
これは、ブロックが実行にGガス、安価なバイトにG’-Gガスを費やすときに起こります。確立された最大バイト量はB = G/64です。安価なバイトは4ガス/バイトかかるため、この価格で同じバイト量を購入すると、わずか4B = 4(G/64) = G/16のコストがかかります。したがって、G’-G = G/16となり、G’ = (17/16)Gとなります。求められるブロック構成で安価なcalldataガスに費やされる割合は(G/16)/(17G/16) = 1/17であり、残りの16/17は実行ガスに費やされます。
図2は、以前使用したタイミング条件下でのこの計算を示しています。x軸は最適なPTCデッドライン、y軸は元の固定デッドラインガス制限に対するガス制限乗数s=G’/Gです。各マーカーはブロック構成を固定します。ラベルは、引き上げられたガス制限のうち安価なバイトに費やされた割合を示し、残りは実行に費やされます。
図2. EIP（Ethereum 改善提案）-7976の下での安全なガス制限乗数。安価なcalldataに費やされるガスの割合が増加するにつれて、バイト上限は元の最大calldataブロックに固定されたままと仮定する。各マーカーは安価なバイトのガスシェアを示し、残りは実行である。曲線はT_1+c=5\mathrm{s}での純粋な実行制限7/3から、乗数が17/16であるT_2=9\mathrm{s}でのキーポイント1/17まで低下する。1/16への点線での継続は、元のガス制限で既にバイト上限を満たしており、スケーリングの利点がない古い最大バイトの安価な構成を示す。
純粋な実行（0）の下では、PTCデッドラインはT_1+cまで移動でき、最大の実行ウィンドウを生成します。安価なバイトシェアが増加するにつれて、より多くのバイトが伝播しなければならないため、最適なデッドラインは遅くなり、安全なガス制限乗数は低下します。重要な点は1/17のマーカーです。この構成では、ブロックは元の最大バイト量Bと元の全実行ガスGを含みます。両方の制約が古い固定デッドラインで結合するため、最適なデッドラインは再びT_2 = 9\mathrm{s}となり、ガス制限乗数は17/16です。1/16への点線での継続は視覚的な補助にすぎません。その構成は元のガス制限で既にバイト上限を満たしており、したがってスケーリングの利点はありません。
EIP（Ethereum 改善提案）-7976の下でより大きな可変PTCスケーリングの利点を回復するには、デッドラインがEIP（Ethereum 改善提案）-7976のcalldataガスではなく、生calldataバイトによって変化する必要があります。しかし、生バイトが希少なタイミングリソースである場合、両方の価格レベルは同じ伝播予算を消費しますが、同じガスを支払いません。その場合、安価なcalldataは優先手数料を通じて生バイト容量を競合する必要があるかもしれません。これは深刻なUX上の懸念となるでしょう。
多次元手数料市場の下でのアフィンメータリング
この提案のアフィンメータリングアプローチは、EIP（Ethereum 改善提案）-7999のような多次元手数料市場の下でも適用できます。これには2つの自然な方法があります。
-
単一のEVMガスリソースがまだ存在している限り、根本的な変更を必要としない、この記事で概説されているベースライン提案を適用する。実行が複数のリソースに分割される場合、それらの処理時間への複合的な影響を考慮する必要があります。
-
calldataを別のリソースとして切り出すが、その生バイト消費、または生バイト消費の定数倍であるcalldataガスユニットを使用して、以前と同様に可変PTCデッドラインを定義する。
ここでは(2)に焦点を当てます。このアプローチとの唯一の根本的な違いは、calldataが独自のリソースベース手数料を持つことです。引き続きG_cという制限があり、ブロックが最大で消費できるcalldata量を決定します。この制限は、これまでと同様に、典型的なブロックがそれに達しないように設定できます。ブロックレベルでは、calldataバイトは、e+r b\le 1+rという条件を課すことで、利用可能な実行ガスとPTCデッドラインの両方を制約します。ここで、r=(T_2-T_1-c)/(T_3-T_2)は伝播対実行のタイミング比率です。calldataサイズは事前に静的に決定できるため、これは実装が簡単です。リソースの消費がEVM実行時に決定されなければならない場合に生じるような種類の複雑さは発生しません。
連続性のために、calldataバイト消費は、それが生バイト消費の固定倍数である限り、引き続きガスで表記することができます。しかし、これは必須ではなく、calldataリソースは代わりに直接バイトで表記することもできます。バイトあたりの価格は、平均してブロックあたり目標とするバイト数が消費されるように調整されます。
結論として、EIP（Ethereum 改善提案）-7999にわずかな変更を加えることで、この記事で概説されているスケーリングの利点は、多次元手数料市場の下でも達成でき、そのような手数料市場がすでに達成しているスケーリングの利点をさらに向上させることができます。
1投稿 - 1参加者