ブロックサイズについて：ガスキャップとスケーラビリティ

By Toni Wahrstätter

最近、エーテルブロックのガスキャップの引き上げについて多くの議論がなされている。多くの議論がありました。ある人はムーアの法則に基づき、ある人は個人的な直感に基づき、ある人はただ言葉を広めているだけで、ある人はSolanaのような他のチェーンが広くユーザーに採用されるという点でEtherを追い抜くことを心配しています。

次に、イーサの分散性を損なうことなくガスキャップを最大化するための判断材料となりそうなチャートやデータをお見せしたいと思います。

はじめに

ビットコインとは異なり、イーサリアムはブロックサイズの上限を固定していません。"で計測する。イーサでは、ガスは取引やスマートコントラクトなどの操作を実行するために必要な計算量を測定する単位です。イーサの各操作は、完了するために一定量のガスを必要とし、各ブロックには、ブロックが含むことができる操作の数を決定するガスの上限があります。

2015年の当初、イーサは1ブロックあたり5,000ガスが上限でした。この上限はすぐに約300万に引き上げられ、その後2016年には約470万に引き上げられました。2016年のTangerine Whistleハードフォーク（EIP-150）の実施に伴い、DoS攻撃に対応するため、Gasの上限は様々なIO集約型オペコードの再プライシングによって550万に引き上げられました。これらの攻撃の後、マイナーはGasキャップの引き上げを続け、2017年7月には～670万に、2017年12月には～800万に、2019年9月には～1000万に、2020年8月には～1250万に、そして最終的に2021年4月3日には～1500万に引き上げられた。

それ以来、スプリアスドラゴンとビザンチウム、コンスタンチノープル、イスタンブール、ベルリンのハードフォークが有効になって以来、特定のオペコードの価格設定はさらに洗練されてきました。これらの改良の例には、EIP-145、EIP-160、EIP-1052、EIP-1108、EIP-1884、EIP-2028、EIP-2200、EIP-2565、およびEIP-2929が含まれます。

最も重要なイーサネット料金市場の変化は、ロンドンの導入でした。EIP-1559は、ブロックスペースの需要に基づいて時間/ブロックの高さにわたって動的に調整される基本料金を導入しました。1ブロックあたり1,500万ガスという「ターゲットサイズ」も導入され、このターゲットが基本料金の動的調整の指針となります。ブロック内で使用されるガスの合計がこの目標を超えた場合、次のブロックの基本料金は引き上げられる。逆に、ガス使用量の合計が目標値を下回れば、基本料金は減少する。この仕組みは、より予測可能な料金市場を形成し、トランザクションのオーバーヘッドを安定させることでユーザー・エクスペリエンスを向上させることを目的としている。加えて、EIP-1559は基本手数料の破棄メカニズムを導入し、イーサのその部分を永久的に流通から排除します。これはプロトコルの持続可能性を高め、ウルトラサウンドマネーミームとして知られるものを作り出します。

EIP-1559では、目標の2倍である3000万ガスに設定された最大（または「ハードキャップ」）ガス上限もあります。これは、1つのブロックが合計で3000万ガスまでのトランザクションをパックできることを意味する。">ロンドンフォーク後のガス使用量

それ以来、イーサのブロックのガス上限は変わっていません。

ブロックサイズを増やす準備はできていますか？

最近、イーサネットのガス上限について懸念を表明し、上限を引き上げるよう求める声がありました。Redditでのイーサネット財団の最新のAMAで、Vitalik氏はGasの上限を33%増やして4000万にすることを検討したと述べています。ムーアの法則とは、マイクロチップ上のトランジスタの数がおよそ2年ごとに倍増し、それに伴って計算能力も向上するというものだ。この法則は、トランザクションを処理・実行する能力を含むネットワーク性能も、時間とともに向上する可能性があることを示唆している。

イーサネット財団の研究者であるDankrad氏とAnsgar氏も、Dencunのアップグレード後に何が起こるかを評価した後、ガスキャップを増やすというアイデアを支持しています。さらに、イーサネット財団のPariは、ガスキャップを増やす潜在的な方法を探る投稿を発表した。GethのPeterやMariusのような他の人たちは、特に適切なツールやモニタリングがないままガス・キャップを増やすことに懸念を表明している。これらの懸念は、主に以下の問題に関連しています：状態の成長の加速、同期時間、再編成ブロック率。

ブロックサイズとは何ですか？

ブロック・サイズは2つの方法で測定できます：

ガス使用量

ブロック・サイズ（バイト単位）

これら2つの指標は関連していますが、独立して考える必要があります。

たとえば、多くの非ゼロ calldata バイトを含むブロックはバイト サイズが大きくても、実際のガス使用量 (非ゼロ バイトあたり 16 ガス) は比較的小さいかもしれません。

圧縮を少し無視すると、今日達成可能な最大ブロック サイズは、 Geth の 128 KB-per-transaction 制限を守りながら、約6.88 MB です。これにより、このようなブロックに詰め込まれる128KBのトランザクションの数が最大になる。実際の結果は、約130,900バイトのゼロバイトcalldata（1バイトあたり4ガス）を含む55のトランザクションと、残りのスペースを埋めるための1つのトランザクションである。しかし、キビキビした圧縮の後では、このようなブロックの大きさは結局約0.32MBとなり、無視できる程度である。

可能な最大のブロックサイズを考慮した別のシナリオでは、非ゼロバイトのcalldataを運ぶ15個のトランザクションが含まれ、圧縮後のサイズは約1.77MBになります。

つまり、今日現在、1.77 MBは実行レイヤブロックの真のブロックサイズの上限を表しています。

訳者注:

上記の段落では、著者らは30Mという固定ガス制限でブロックサイズを最大化しようとしており、最大でどれだけの大きさのブロックを詰め込めるかを計算しようとしていました。を詰め込むことができる。

ガスリミットを固定した場合、ブロックサイズを大きくする唯一の方法はcalldataを詰め込むことです（compute/STOREのようなバイトコードは実際にはブロックストレージを消費しないため）。

つまり、ブロックを大きくする唯一の方法は、トランザクションにできるだけ多くのcalldataを詰め込むことであり、そのためには「0 calldataを詰め込む」方法と「0以外のcalldataを詰め込む」方法があり、これらはブロックサイズを大きくするために計算を必要とします。そして、"stuff 0 calldata "と "stuff non-0 calldata "という方法があり、どちらがブロックサイズを大きくするかを知るためには計算が必要である。最終的には、"stuffed non-0 calldata "のブロックサイズが大きくなります。

Gethクライアントはトランザクションあたり最大128KBに制限されているという前提のもと、計算方法の例を2つ紹介します。

ケース1: サイズ130,900 B (< 128 KB)の56トランザクション(すべてcalldataがゼロ、gas/Bが4)：gas = 56* (130,900 * 4(+21000)=30497600>(30M)なので、上記のトランザクションのうち最大55個+上記より小さいトランザクション1個が収まる。対応するブロックサイズは約55*128 = 7040 kB = 6.875 MBですが、calldataはすべてゼロなので、圧縮されたブロックサイズは約0.32 MBです。サイズ130,900 B (< 128 KB)のトランザクション(すべて非ゼロのcalldata、16 gas/B)：使用ガス = 15 *(130900 *16+21000) = 31731000 > 30 M. 対応するブロックサイズは約14 *128 = 1792 kB = 1.75 MB ~ 15 * 128 = 1.875 M.です。ただし、calldataは0ではなく、うまく圧縮されないため、圧縮されたブロックサイズは約1.77MBとなります）

この最大ブロックサイズに関して、それに影響を与えるいくつかの要因を特定することができます。

ガス・キャップ: ガス・キャップが最大ブロック・サイズに影響することは間違いありません。キャップが高ければ高いほど、より多くのデータをブロックに詰め込むことができます。

操作とデータの価格: 操作のガスが安いほど、ブロック内で実行できる操作が増えます。CALLDATALOAD や CALLDATACOPY のようなオペレーションは3ガスオーバーヘッドで比較的安価ですが、 CREATE や CREATE のような他のオペコードは比較的安価です。code> はより高価である。ブロック内で使用されるオペコードが高価であればあるほど、そのブロック内で calldata（または他の操作）のためのスペースは少なくなります。

クライアント側の制限: クライアント側の制限の影響はあまり明らかではありませんが、例えばGethクライアントのように、トランザクションごとに128kbの制限がある場合も、最終的なブロックサイズに影響を与える可能性があります。トランザクションあたりの固定料金は21kガスなので、クライアントのトランザクションあたりのサイズ制限が低ければ低いほど、クライアントはより頻繁に固定料金を支払う必要があり、その結果、 calldata に使えたはずのガスを「浪費」することになります。 そのため、結局のところ、制限はクライアント側の制限はトランザクションのブロードキャストにのみ影響し、すでに確認されたブロックには影響しないことに注意してください。

まず、ブロックごとのGas制限を見てみましょう:

イーサのようなブロックチェーンでは、ブロックガスの上限を引き上げることが容量を拡大する最も直接的で明白な方法です。上限が高くなれば、データ容量が増えることを意味します。しかし、それはまた、より大きなブロックをフルノードを実行しているすべての人に伝播し、ダウンロードする必要があることを意味します。上に示したように、"最悪のケース（つまり、前の計算から導き出された最大ブロックサイズ）"のブロックサイズは、ブロック・ガス・キャップの増加にほぼ直線的に比例します。このような最大ブロックサイズは、できるだけ多くの非ゼロバイトのcalldataトランザクションで満たされたブロックを作成することで達成できます。

次に、もう1つの影響要因であるイーサネットの価格設定メカニズムを見てみましょう。現在の例では、特に、 calldata  の非ゼロ バイトのオーバーヘッドは、現在 16 Gas に設定されています。

上で示したように、非ゼロ calldata オーバーヘッドを増やすと、ブロック サイズが小さくなります。言い換えれば、オーバーヘッドを例えば1バイトあたり8ガスに減らすと、ワーストケースのブロックサイズは2倍になります。価格を下げると、ブロックに入れられるデータ量が2倍になるので、これは直感的です。

EIP-4844（Proto-Danksharding）が稼動するときはどうですか?

4844についてはeip4844.comに詳しく書かれているので、ここでは詳しく説明しませんが、簡単に言うと、EIP-4844はブロブと呼ばれる「サイドカー」のような構造を導入します。EIP-4844はblobと呼ばれる「サイドカー」のような構造を導入し、各blobには～125kbのデータを詰め込むことができ、blobデータコストのメカニズムは、blobの数を固定する「ターゲット」が存在するという点で、EIP-1559に似ている。Dencunのハードフォークでは、ターゲットは1ブロックあたり3ブロブに設定され、上限は1ブロックあたり6ブロブに設定された。注目すべきは、ブロブには独自のコスト市場があり、多次元コスト市場として知られるものが形成されていることである。これは、blobが標準的なトランザクションと競争する必要がなく、EIP-1559メカニズムのもとで手数料から切り離されていることを意味する。

ここまでは順調だ。このアップグレードがイーサの平均ブロックサイズにどのような影響を与えるか見てみましょう。

今日現在、スナッピーを使用して圧縮されたビーコンチェーンのブロックの平均ブロックサイズは以下の通りです。今日現在、snappy圧縮を使用したビーコン・チェーン・ブロックの平均ブロック・サイズは約125KBです。 4844を使用すると、ブロックごとにさらに375KBが追加され、現在の平均ブロック・サイズは4倍になります。ブロブの最大数に達すると、現在のブロックサイズは実質的に7倍になります。

最悪の場合のブロックサイズは～1.77MBから～2.5MBに増加し、この見積もりではブロックのCL（コンセンサスレイヤー）部分は考慮されていません。しかし、いずれにせよ、DoS攻撃の際には、この最大ブロックサイズに備えなければなりません。

まとめ

結局のところ、現在のブロックガス上限を増やすのであれば、実施前に徹底的な調査と分析を行う必要があります。Coinbase、Binance、Kraken、またはLidoノード運営者のような確立された事業体は、4000万を超えるブロックガスの上限を扱うことができますが、独立した誓約者はより困難な時間を過ごすことになるかもしれません。

そのため、このような決定は、分散化を犠牲にしないよう、よく考えなければなりません。

結局のところ、フェイスブックと同じくらいの容量とパフォーマンスを持つものを構築するのは比較的簡単ですが、私たちの多くが求めているもの、つまり分散化を失わないようにすることが重要です。