Ethereum Forum JP

トピックで絞り込む

すべてのタグ (154) →

Hegotaにおけるスケーリング：ETH転送をアンカーとして実行と帯域幅を固定する

35 min read

原文

Scaling in Hegota: using the ETH transfer to anchor execution and bandwidth — misilva73 (2026-06-19)

このレポートにつながる議論をしてくださったToni Wahrstaetter、Marius Vanderwijden、Parithosh Jayanthiに感謝いたします。

この投稿では、グラムステルダム以降もガス制限のスケーリングを続けるために、Hegotaが変更する必要があることについて考察します。出発点は一つの観察です。21,000ガスのETH転送は、スロットの両方の側面を制約します。

  • 実行側では、再価格設定により、グラムステルダムは転送上限が許す限りコストを押し上げ、最悪ケースの実行を100 Mgas/sに固定しました。
  • 帯域幅側では、転送でいっぱいのブロック自体がデータペイロード（エンベロープ、署名、BALエントリ）であり、21kを超える料金を課さずに価格設定手段が触れることはできません。

したがって、転送で満たされたブロックをアンカーブロックとして使用します。その帯域幅パフォーマンスを導出し、ガス制限を最大化するペイロード適時性委員会デッドラインを見つけ、敵対的なcalldata + SLOADブロックと比較し、これがステート成長、履歴、メモリに何を意味するかを問います。

主な発見事項

  • 21k ETH転送はスロットの両側面を固定します。 最悪ケースの実行を100 Mgas/sに固定し、かつ、いかなる価格設定手段も下回ることができない約0.0105 B/gas（転送あたり221 B、最悪ケース）の削減不可能なバイト密度を設定します。アンカーブロックは約214 Mgas/sで伝播するため、実行律速であり、両方の天井を対称的な25%バッファで解決すると、PTCデッドラインが約6.4秒で約422Mになります。25%バッファは厳密なフロアではなくガイドラインとして扱い、端数を丸めるためにわずかに緩和します。D = 6秒で450Mを推奨します。これにより、アンカーブロックは最悪ケースで約25%の実行バッファと約11%の伝播バッファで動作します。

  • Hegotaの再価格設定の役割は、あらゆる価格設定された構成を転送ラインまで引き下げることです。 21kの上限に触れずに転送を再価格設定することはできないため、目標は、設計上それを最悪ケースにすることです。グラムステルダムの価格設定はこれに失敗しています。混合calldata + SLOADブロックはラインの約2.2倍に位置し、システムを約302Mに固定し、アンカー最適値より約120M低くなっています。解決策は、calldataフロアを再度引き上げる（64 → 96）ことに加えてBALバイトをカバーするか、または単一の均一なcalldataレート（約94）を導入することです。これは、メカニズムの複雑さと影響範囲の広さのトレードオフです。

  • 転送ラインを下回る場合、さらなる最適化のみが最適点を動かします。 価格設定はライン上で構成を均等化できますが、それを下回ることはできません。1KBあたりの伝播時間が10%改善されるごとに、ガス制限は約+14〜18M増加し、最大618Mに達します。並行して、ETH転送の実行時間の改善は、PTCデッドラインを変更することなく、より高い実行アンカーを可能にし、より高い制限を許容します。

背景

グラムステルダムは、ePBS (enshrined Proposer-Builder Separation)（[EIP-7732]）、BAL（ブロックアクセスリスト）（[EIP-7928]）、およびデータ価格設定EIP（Ethereum 改善提案） 7976（calldataフロア64/64、標準4/16）と7981（フロアレートでのアクセスリストバイト）を含む再価格設定バンドルを出荷します。再価格設定は、最悪ケースの実行パフォーマンスを100 Mgas/sにすることを目標としました。この目標をさらに引き上げることはできません。そうするには、ETH転送のガスコストを21,000を超えるように再価格設定する必要があり、これにより一部のハードウェアウォレットの機能が損なわれます。したがって、Hegotaの場合、100 Mgas/sの実行アンカーは固定されており、追加のスケーリングは最適化（実行と伝播の両方）、ペイロード適時性委員会デッドラインの変更、および（別途）過剰に価格設定された計算操作を安くすることから来る必要があります。最後のオプションは並行して分析され、後述する一つの相互作用を通じてのみこのレポートに組み込まれます。

全体を通して使用される仮定：

パラメータ値注釈
実行アンカー R100 Mgas/s21k転送上限により固定
スロット終了 T_312 s
ビーコンブロックボディアテステーション（証明）デッドライン T_13 sePBS (enshrined Proposer-Builder Separation)下でのペイロード伝播開始の最速時間；2s vs 3sはまだ未解決
安全バッファ実行ウィンドウと伝播ウィンドウの両方で25%ガイドラインであり、厳密なフロアではない；推奨される450M/6sの動作点は約25%実行 / 約11%伝播で動作
伝播モデルt = 569 + 0.443 \cdot \text{KB} ms (p90, MEV-boost)Toniの最悪ケースのブロックサイズ分析から；snappy圧縮サイズ、リリース後に測定 (p_{90} - \min)。転送ブロックは非圧縮性として扱われる (snappy圧縮後 ≈ 生データ)
コールド SLOAD3,000EIP（Ethereum 改善提案）-8038の暫定値；Hegotaでは変更なし
コールドアカウントアクセス (BALANCE)3,000EIP（Ethereum 改善提案）-8038の暫定値；Hegotaでは変更なし
コールド SSTORE13,000EIP（Ethereum 改善提案）-8038の暫定値；Hegotaでは変更なし
Calldata価格設定64/64フロア、4/16標準EIP（Ethereum 改善提案）-7976/7981
ステート作成CPSB = 1530, 固定最新のEIP（Ethereum 改善提案）-8037仕様 (150M参照、120 GiB/年)

リソースのマップ

リソースを制約の種類別に整理すると、ガス制限の増加に対してそれぞれがどのように反応するかが決まるため、役立ちます。

リソース制約タイプより高い制限での挙動（グラムステルダム価格設定）Hegotaのアクション
実行スロットごと、Dの後最悪ケースの実行時間はGとともに増加；Dを介して伝播とトレードオフ上方再価格設定なし（仮定による）
帯域幅スロットごと、Dの前最悪ケースのペイロードはGとともに増加；BALバイトは価格設定されていないフォーク変更（本レポートの核心）
ステート成長累積（ディスク）CPSBが固定されているため、成長率はGとともに増加CPSBを再導出（フォーク項目）
履歴累積（ディスク + サービス）Gとともに増加有効期限の前提条件；LOGDATAレビュー
メモリトランザクションごと（RAM）Gとともに増加しない（EIP（Ethereum 改善提案）-7825によりトランザクションごとに制限）なし

次のセクションでは、スロットごとのトレードオフ（ガス制限を設定する）について説明し、累積リソースについては最後に再び触れます。

アンカーブロックとしての転送ブロック

転送はどれくらいのバイトを運ぶか？

転送はストレージを書き込まず、オペコードも実行しませんが、バイトを送信します。そのエンベロープと署名、さらにEIP（Ethereum 改善提案）-7928がBALに保持するレコードです。

タイプ2転送のエンベロープは、現実的には約110 Bです。署名（r、sがそれぞれ32 B、プラスy_parity）が約65 B、20バイトの受信者アドレスがRLP (Recursive Length Prefix)フレーム化されると約21 Bとなり、ナンス、2つの手数料フィールド、ガス制限、値、チェーンID、および空のアクセスリストに約25 Bが残ります。現在のトランザクションタイプ全体での最悪ケースのエンベロープとして、表では130 Bに切り上げています。

BALの場合、転送は2つのアカウント（送信者：残高 + ナンス；受信者：残高）に触れます。RLP (Recursive Length Prefix)は残高を最小長（合計ETH供給量に制限され、32ではないため≤ 11 B）でエンコードし、ナンスを1〜2 Bでエンコードするため、最悪ケースの限界貢献は約91 Bです。

シナリオ構成転送あたりのバイト数\beta_t (バイト/ガス)
最悪ケースの会計130エンベロープ + 91 BAL2210.01052

伝播モデルはsnappy圧縮後のバイトで校正されているため、この生データ221 Bを、転送ブロックを非圧縮性（snappy圧縮後 ≈ 生データ）として扱うことでワイヤーにマッピングします。これは最悪ケースで安全です。署名はsnappyが触れることのできないランダムなバイトであり、このレポートで最も重要な仮定です。実際の圧縮は、制約を緩め、達成可能なガス制限を上げるだけです。実際のエンコードされたブロックで圧縮された限界バイト勾配を測定することが、このレポートが特定する最も重要なデータタスクです。

ペイロード適時性委員会デッドラインはどこに設定すべきか？

デッドラインDは、スロットを伝播ウィンドウ（秒からDまで）と実行ウィンドウ（Dから12秒まで）に分割します。両方に25%のバッファガイドラインを保持すると、アンカーブロックが時間内に伝播と実行の両方を行える場合に、ガス制限Lが実現可能になります。

L \le 0.75 \cdot R \cdot (12 - D) \qquad \text{(実行)}

0.443 \cdot \beta_t \cdot \frac{L}{1000} + 569 \;\le\; 0.75 \cdot (D - T_1) \cdot 1000 \qquad \text{(伝播)}

最初の天井はDが遅くなるにつれて下がり、2番目の天井は上がります。最適点は交差点です。

シナリオD^* (s)L^*L^*でのペイロード
最悪ケースの会計 (221 B)6.38422M4.44 MB

転送をアンカーとする最適点（両方のウィンドウで25%のガイドラインを保持）は、D \approx 6.4秒で約422Mです。25%バッファは厳密なフロアではなくガイドラインであるため、丸められた運用数を推奨するためにわずかに緩和します。D = 6秒で450Mとし、デッドラインをわずかに早めて伝播ヘッドルームをより高い制限と交換します。実行バッファは約25%を維持し、伝播バッファはシフトを吸収し、25%から約11%に低下します。アンカーブロックは、75%ではなく伝播ウィンドウの約89%を使用します。

動作点実行バッファ伝播バッファ
422M @ 6.38s (対称最適点)25%25%
450M @ 6s (推奨)~25%~11%

残存する不確実性は、伝播適合（p90パーセンタイルとToniのテール強調型と保守的な \sqrt{n\cdot\text{size}} 重み付け）とsnappy圧縮後の仮定にあります。伝播の改善（下記）は、450Mで対称的な25%バッファを回復するか、制限をさらに高く押し上げるでしょう。

敵対的なブロック

転送ブロックは最悪ケースではない

転送ブロックはスロットを固定しますが、構築できる最も密度の高いブロックではありません。その \beta_t \approx 0.0105 B/gasはフロアであり、天井ではありません。21kの上限に触れずに転送ブロックに価格設定することはできないため、私たちの目標は、設計上それを最悪ケースにすることです。プロトコルが価格設定するすべての構成は、ガスあたり最大 \beta_t バイトを運ぶべきです。 \beta_t を超える価格設定されたブロックは、転送ブロックよりも先にスロットを制約し、L^*を422M未満に引き下げるため、それぞれをチェックします。

単一リソースブロックのバイト密度は、操作あたりのバイトフットプリントをガスコストで割ったもの、\beta = b/cです。

  • フロアでのcalldataの場合、1/F
  • コールドSLOADの場合、32/c（32バイトのBALキー）
  • BALANCEのようなコールドアカウントアクセスの場合、20/c（20バイトのアドレス）
  • コールドSSTOREの場合、64/c（BAL内の32バイトのキー + 32バイトの値）

混合ブロックは、最も密度の高い安価なcalldata（EIP（Ethereum 改善提案）-7976フロアを下回る範囲で16ガス/バイトの標準レート）を追加し、残りをコールドSLOADで埋めます。

\beta(F, c) = \frac{1 - 512/c}{F} + \frac{32}{c}

グラムステルダムの仮定された価格（コールドSLOAD 3,000、コールドアカウントアクセス 3,000、コールドSSTORE 13,000、calldataフロア F = 64）でメニューを評価すると、次のようになります。

ブロック構成\beta (B/ガス)× 転送ライン
ETH転送（アンカー）221 B / 21,000 ガス0.010521.00×
コールド SSTORE64 B / 13,0000.004920.47×
コールド BALANCE20 B アドレス / 3,0000.006670.63×
コールド SLOAD32 B キー / 3,0000.010671.01×
フロアでのCalldata1/F, F = 640.015631.49×
混合 25% calldata@16 + 75% SLOAD\beta(64, 3000)0.023632.25×

主な観察結果：

  • コールドSLOADのみが転送ラインに匹敵します。 コールドBALANCEは、3,000ガスで20バイトのアドレスのみをBALに書き込み（0.63×）、コールドSSTOREは、13,000ガスで64バイトのキー+値を書き込みます（0.47×）。どちらも十分に下回っています。コールドSLOADの3,000ガスで支払われる32バイトのストレージキーは、ステートアクセスがガスあたりに追加できる最もバイト密度の高いものであり、敵対的なブロックがコールドSLOADから構築される理由です。

  • コールドSLOADは実質的にライン上にあります。 3,000ガスで32バイトのキーは0.01067 B/gasを与え、\beta_tより1%高くなっています。ラインはc = 3,041で正確に到達します。

  • 2つの価格設定されたブロックがラインを超えています：純粋なcalldata（1.49×）と混合ブロック（2.25×）。 どちらも同じ根本原因（転送ラインを下回る価格設定のcalldata）のために超過していますが、次に示すように、異なる修正が必要です。

最小のレバー：calldataフロアの再引き上げ

純粋なcalldataブロックがラインを超えているのは、一言で言えば、EIP（Ethereum 改善提案）-7976のフロアが64ガス/バイトであるため、1/64 = 0.0156 B/gasとなり、\beta_tより49%高くなるからです。修正は単一の定数です。フロアを次のように引き上げます。

F^* = \left\lceil 1 / \beta_t \right\rceil = \lceil 1 / 0.01052 \rceil = \lceil 95.06 \rceil = 96 \text{ gas/byte}

これはHegotaにとって最も簡単なデータ価格設定の変更です。しかし、これでも混合ブロックは修正されません。 Fを引き上げると、安価なcalldataの割合が縮小されます（16/64 = 25%から16/96 = 16.7%に）が、コールドSLOADの残りがBALにバイトを追加し続け、結果として全体のバイト密度は\beta(96, 3000) = 0.0193 B/gasになります。これは依然としてラインの1.84倍です。

実際、F \to \inftyの場合、バイト密度は32/cに近づき、これはSLOADブロック自体の密度です。これは、いかなる有限のcalldataフロアも混合ブロックを十分に引き下げないことを意味します。

混合ブロックを制御する3つの方法

残りのボトルネックは、ラインの1.84倍である混合ブロックです。3つのオプションがあります。最初の2つは、先に導出された64 → 96のフロア引き上げに加えて、calldataフロアでは見えないBALバイトに価格設定します。3番目はBALを価格設定せず、代わりに混合ブロックが悪用する二重レートのcalldata構造を削除します。

オプション1：フロアにBALバイトを含める。 明らかな解決策は、BALバイトをフロア計算に含め始めることです。[Toniによるこの提案]は、7623スタイルのフロアをBALバイトを含むすべてのペイロードバイトに拡張します。これにより、価格設定されたすべてのバイトはガスあたり最大1/96バイトを生成し、SLOADの変更は一切ありません。コストは、すべてのコールドアクセスパスに触れるランタイムフロアアキュムレータを維持する新しいガス会計メカニズムです。これはフロア側のみに作用するため、通常のユーザーと21k転送には影響しません。

オプション2：本質的なデータ追加料金。 あるいは、BALに貢献するすべての操作（コールドアクセス、コールドストレージなど）に明示的なデータコンポーネントを追加することもできます。これは定数のみであり、フロアの上に最も単純なメカニズムです。しかし、この方法でBALバイトに価格設定することは、事実上のステートアクセス再価格設定です。混合ブロックをラインに合わせるには、コールドステートアクセスのコストを大幅に引き上げる必要があり、これは実行安全であるにもかかわらず、固定アンカーの根拠と矛盾します。さらに、これはすでにラインを下回っている純粋なオペコードブロックの価格をさらに誤らせます。

オプション3：均一なcalldata価格、BAL価格設定なし。 混合ブロックが機能するのは、calldataが2つのレートを持っているためです。安価な16ガス/バイトの標準レート（フロアシェアまで利用される）と、それより上のフロアです。calldataに単一のレートpを与えれば、このボトルネックは解消されます。すべてのcalldataバイトはpのコストがかかるため、calldataブロックは1/pで制限され、それをステートブロックに混合しても密度が希薄化されるだけです。最悪ケースは、最も密度の高い価格設定されていないステート操作、つまり32/cのコールドSLOADに戻ります。したがって、pは純粋なcalldataがSLOADを上回るのを止めるだけでよいのです。

\frac{1}{p} \le \frac{32}{c} \;\Rightarrow\; p \ge \frac{c}{32} \approx 94 \text{ gas/byte} \quad (c = 3{,}000)

これはフロアの96をかろうじて下回っています。フロアを下げても、支払う人が変わるだけでレートは変わりません。 フロアが96の場合、データ量の多いトランザクションのみに影響しますが、均一な94はすべてのcalldataバイトにフロアレートを課します。これは16の標準レートに対して約6倍の増加です。その代わりに、最も単純なメカニズム（1つのレート、BAL会計なし、max()なし）です。

選択は、メカニズムの複雑さと影響範囲の広さのどちらを取るかです。オプション1はユーザーへの影響が最も小さい（calldataフロアを超えるブロックのみに影響する）ですが、新しいガス会計メカニズムを導入します。オプション2と3はどちらも定数のみの変更ですが、BALに影響する操作のすべてのユーザー（オプション2）またはcalldataのすべてのユーザー（オプション3）に影響します。オプション3はオプション2よりもクリーンで擁護しやすいです。なぜなら、BALバイトを生成する操作は、その実行コストと帯域幅コストの両方に対してすでに正しい価格を持っているからです。混合ブロックはcalldataの二重レート構造を悪用しているだけなので、それを削除することが、BALバイトに触れる必要のない直接的な修正となります。

伝播が速くなったらどうなるか？

価格設定は転送ラインで構成を均等化できますが、それを下回ることはできません。その点を超えると、メムプール (Mempool)ベースのペイロード再構築（ほとんどのペイロードバイトはすでにピアのメムプール (Mempool)にある）、ゴシップとトポロジーの改善、または消失訂正符号化された伝播を通じて、伝播モデル自体のみが動くことができます。x%改善された傾きで中央の交差点を再実行します。

傾きの改善D^* (s)L^*
— (0.443 ms/KB)6.38422M
−10%6.19436M
−20%6.00450M
−30%5.79466M
−40%5.56483M
−50%5.32501M
オーバーヘッドのみ半減 (569 → 285 ms)6.12441M

パターンは、傾きが10%改善されるごとに約+14〜18Mのガス制限であり、デッドラインは段階的に早まります。−20%の傾きは、D = 6.0秒で丸められた450Mに達し、推奨される制限で対称的な25%バッファを回復します。−50%はD \approx 5.3秒で約501Mに達します。固定オーバーヘッドを半減する（569 → 285 ms）だけでも、約1傾きデシル（約+19M）の価値があります。転送量の多いペイロードは最も圧縮されにくい形状（署名はランダムなバイト）であるため、圧縮による改善は、アンカーブロック自体よりも敵対的なテールに役立ちます。

この全体的な枠組みのハードな上限は実行です。DがT_1と固定オーバーヘッドに近づくにつれて、実行ウィンドウは約8.2秒で飽和します。つまり、100 Mgas/sの75%で618Mです。それを超えるには、実際の実行スループットを上げる必要があり、それは過剰に価格設定された計算操作の再価格設定に関する並行分析が対処するものです。その作業は、1つの点でこのレポートにフィードバックされます。安価な実行は、より多くのトランザクションをcalldataフロアに押し込むため、F = 96でのフロアの発生率は、再価格設定後の実行コストに対して評価されるべきです。

他のリソースへの影響

ステート成長：CPSBの再導出

最新のEIP（Ethereum 改善提案）-8037仕様は、150Mの参照制限で120 GiB/年の目標に対して導出されたCPSB = 1530を固定し、その後のフォークでの再導出を明示的に延期しています。1,530のままでは、450Mの制限での目標レート成長は年間約360 GiBになります。新しい制限で仕様自身の導出を使用すると、次のようになります。

動作点CPSB新しいスロット (64 B)新しいアカウント (120 B)24 KiBデプロイ
450M~4,600294k551k113Mステートガス
501M (p2pストレッチ)~5,110327k613k126Mステートガス

転送はどちらの場合も影響を受けません。なぜなら、新規アカウント作成のみが、リザーバーモデルによる別の次元でステートガスを支払うからです。

また、より高いブロック制限と増加したCPSBに対して実際の需要がどのように反応するかという問題もあります。グラムステルダムフォークにユーザーがどのように適応するかを観察した後、最終的な値はおそらく異なるでしょう。

履歴：再価格設定は不要だが、有効期限がより重要になる

メインネットのgeth履歴（ヘッダー、ボディ、レシート）は、2024年5月から2025年5月にかけて36Mの制限で約525 MiB/日、つまり年間約180 GiBで増加しました（詳細はこちら）。これを450Mに線形にスケーリングすると、年間約2.2 TiBになります。これにはレシートに含まれるログがすでに含まれていますが、測定期間はBAL導入前であるため、その数値は省略されています。BAL（EIP（Ethereum 改善提案）-7928）は、同程度のサイズの2番目の履歴チャネルであり、転送ブロックのバイトの約41%を占め、ステートアクセス量の多い構成では支配的ですが、EIP（Ethereum 改善提案）-7928は保存されたBALをハッシュルートに剪定することを許可しているため、その永続的な貢献は保持ウィンドウに依存します。

これらの履歴ステート成長率では、ローリング履歴有効期限（EIP（Ethereum 改善提案）-4444ファミリー）がイーサリアムバリデータにとってより重要になります。しかし、この成長率はまだ管理可能であり、したがって再価格設定する必要はありません。

メモリ：何もすることはない

最悪ケースのEVMメモリはトランザクションごとの量です。EIP（Ethereum 改善提案）-7825の上限に対する二次的な拡張コストは、単一フレームを約3〜4 MBに制限し、メモリは順次実行されるトランザクション間で解放されます。より高いブロック制限は、ブロックあたりのトランザクション数を増やしますが、同時メモリは増やしません。これは、EIP（Ethereum 改善提案）-7825の上限が引き上げられるか、線形メモリ価格設定（EIP（Ethereum 改善提案）-7923/7686）が補償的な制限なしに出荷された場合にのみ変更されます。

計算：下方再価格設定

100 Mgas/sアンカーを固定することの裏返しは、ほとんどの操作がそれに対して過剰に価格設定されていることです。それらの最悪ケースのクライアント実行時間は現在のガスコストを下回るため、実際に費やす時間よりも多くのブロックのガス予算を消費します。[現在のクライアントパフォーマンス結果]を見ると、約62のEVM操作とプリコンパイルを再価格設定でき、そのうち36はアンカーレートで1ガスを下回ります。これらは、安価で高頻度の算術、ビット演算、スタック、メモリ操作です。

この過剰な価格設定は、利用されずに残されたスループットです。メインネットのトラフィック（https://misilva73.github.io/hegota-compute-repricing/fracgas.html）では、今日、ブロックガスの約**12.4%が、公正な実行時間コストを超えて課金される操作に実質的に無駄にされています。整数丸め（max(⌈exact⌉, 1)）による下方再価格設定は、それを約2.6%**に削減します。

10%の利益は良いですが、62の操作を再価格設定するコストを補償する可能性は非常に低いです。したがって、ここでの推奨事項は、Hegotaで計算コストを変更しないことです。

Hegotaが実際に提供するもの

#項目タイプ
1ガス制限 → ~450M、D = 6秒イーサリアムバリデータ協調、2〜5にゲートされる
2Calldataフロア 64 → 961つの定数 (7976/7981)
3混合ブロックの修正：BALフロアペア、本質的な追加料金、または均一なcalldata価格 (~94)唯一未解決のメカニズム決定
4CPSB再導出：1,530 → 4,600（p2pストレッチで5,110）EIP（Ethereum 改善提案）-8037仕様のプロセスに従った1つの定数
5p2p傾き/オーバーヘッドの改善非フォークトラック：10%傾きあたり+14〜18M、最大~501M

制限事項

  • すべての伝播数値は、Toniのp90 MEV-boost適合（569 + 0.443 \cdot \text{KB} ms、snappy圧縮サイズ、リリース後にp_{90} - \minとして測定）と秒の仮定を継承しています。どちらも与えられたものではなく、選択肢です。Toniの保守的な \sqrt{n\cdot\text{size}} 重み付けはより急な傾きを与え（ローカル/より高いパーセンタイルの適合はさらに急）、それぞれが最適点を引き下げます。交差点はT_1の1秒あたり約51M、傾きに比例して移動します。

  • 転送あたりのバイト数は、確認済みのRLP (Recursive Length Prefix)最小長エンコーディングから導出されているため、フレーミングオーバーヘッドは解決されています。しかし、Toniの伝播モデルはsnappy圧縮後のバイトで校正されており、転送ブロックは非圧縮性（snappy圧縮後 ≈ 生データ221 B）であると仮定しています。実際のワイヤー圧縮とトランザクション数に伴うblock_access_index幅の成長はモデル化されておらず、すべての主要な数値を動かします。特に圧縮は、制限を緩め、L*を上げるだけです。

  • 交差点モデルは、伝播と実行を厳密に直列で、25%のハードバッファを持つものとして扱います。パイプライニングや重複検証は、最適点を外側にシフトさせるでしょう。

  • EIP（Ethereum 改善提案）-8037の数値はライブ仕様（CPSB = 1530）に従います。ローカルのEIP（Ethereum 改善提案）リポジトリは依然として古い自動スケーリングドラフトを保持しており、その数値は適用されません。

  • 履歴予測は、今日の測定された履歴成長（ヘッダー、ボディ、レシート）をガス制限に線形にスケーリングします。観測された30M→36Mのスケーリングは線形に近いですが、構成の変化（ブロブ採用、実際のBALサイズ）がそれらを動かすでしょう。

1投稿 - 1参加者

トピック全文を読む

グラフビュー