著者: 0xfan、Smarti Lab、編集者: Peng SUN、Foresight News##TL;DR：> 1. 当社では 2 つの計算方法を使用して、ガス料金の削減可能性、TPS (1 秒あたりのトランザクション数)、および EIP-4844 実装後のロールアップに対応する能力を評価します。>> 2. Calldata サイズがそれぞれ 10KB と 2KB の場合、EIP-4844 は 38 回から 192 回の範囲で、より多くの Calldata を収容できると推定されます。より多くの Calldata を同じブロックに収容できるため、Calldata 単位あたりのコストもそれに応じて削減されます。>> 3. 各ロールアップの Calldata サイズが一律 2KB であると仮定すると、EIP-4844 は最大 384 個のロールアップまでしか対応できません。>> 4. 通常の状況 (つまり、ブロックがターゲット サイズに達したとき) では、イーサリアムは EIP-4844 を通じて 175 TPS (最大 350) に達します。>> 5. **一般に信じられていることに反して、EIP-4844 だけではイーサリアムのスケーラビリティを大幅に向上させるのに十分ではありません。 **>> 6. 代替 DA レイヤー (Celestia など) または DAC (zkPorter など) を利用し、L2 トランザクション データの圧縮率を向上させ、zk ロールアップの割合を増やすことは、イーサリアムのスケーラビリティをさらに向上させる上で重要な影響を及ぼします。Proto-danksharding (EIP-4844 としても知られる) は、Danksharding が将来使用する可能性のあるロジックとルールのほとんどを実装することを提案しています。現在、L1 のストレージ コストが高いため、L2 の移行料金も比較的高くなっています。この問題を解決するために、EIP-4844 では新しいデータ型 Blob が導入されています。これは calldata よりも安価で容量が大きく、ロールアップ データ ストレージの別の方法を提供します。EIP-4844 の今後の発売により、L2 シーケンサーの収益性がさらに高まる可能性があります。これは、シーケンサーがトランザクション バッチを L1 にインポートし、データ料金を支払う責任があり、シーケンサーが支払う L1 データ料金が大幅に削減されるためです。取引手数料が低いと、L2 での注文数が増加し、より多くの MEV が生成される可能性があります。カンクンのアップグレードには EIP-4844 が含まれますが、アップグレードの正確な時期はまだ決まっていません。イーサリアム財団の研究チームは、カンクンのアップグレードは10月末に開始される可能性があると述べた。ただし、2024 年の第 1 四半期頃に発売される可能性が高くなります。**それでは、EIP-4844 は取引手数料をどの程度削減できるでしょうか? **現在、L2 トランザクション手数料は主に 2 つの部分で構成されています。* **ロールアップコスト**: イーサリアム上でトランザクションをパッケージ化、送信、保存するコスト。* **実行 (ユーション) コスト**: L2 でトランザクションを実行するコスト> L2 トランザクション手数料 = ロールアップコスト + 使用コスト> = [ L1 ガス価格 \* (通話データ + 固定オーバーヘッド) ] + [ L2 ガス価格 \* 使用される L2 ガス ]Optimism を例にとると、現在、総取引手数料のほぼ 80% は L1 ストレージ コスト (つまり、Calldata コスト) から発生しています。現時点では他の手数料の影響を無視し、EIP-4844 後に L2 トランザクション手数料がどれだけ削減されるかを見積もる 2 つの方法を提案します。EIP-4844 では、提案が実装された後、各 BLOB のサイズは 128 KB になり、各 BLOB は 131,072 ガスを消費します。したがって、平均して、各 BLOB データ バイトは 128 \* 1024 / 131,072 = 1 ガスを消費します。比較すると、現在 1 つの Calldata バイトを保存すると 16 Gas が消費されます。これは、L2 トランザクションのストレージ コストが 16 分の 1 に削減されることを示しています。ただし、この方法ではバイトあたりのストレージ コストのみが比較され、ブロックの総ガス容量は考慮されません。 EIP-4844 以降は、単一のブロックが運ぶことができるガスの総量が変更される可能性があるため、L2 トランザクションのストレージ コストが 16 分の 1 以上削減される可能性があります。2 番目の方法では、ブロック サイズを考慮し、現在の Calldata がさまざまなブロック サイズに収容できる回数を確認します。現在のパラメーターによると、ターゲット ブロック サイズのシナリオでは、ブロックは 3 つの BLOB (0.375MB)、最大 6 つの BLOB (0.75MB) を収容できます。現在の各ブロックの Calldata が約 2 ～ 10KB を占めることを考慮すると、EIP-4844 以降は、最大 **0.75 \* 1024 / 2 = 384 倍** の Calldata を収容できます。ただし、ブロック サイズが目標値から最大値まで増加するにつれて、ガス価格は指数関数的に増加します。したがって、より一般的なケース (つまり、ブロックがターゲット サイズに達した場合) では、EIP-4844 は、それぞれ 10KB と 2KB の Calldata の 38 ～ 192 倍の Calldata を収容できます。 **ブロック内の Calldata の容量が増加すると、それに応じて Calldata のストレージ コストも減少します。したがって、L2 トランザクションのコストもそれに応じて削減されます。さらに、各ロールアップの Calldata サイズが一律 2KB であると仮定すると、EIP-4844 は最大 384 個のロールアップまでしか対応できません。これは、多くの人が想像していた数千のロールアップには達しません。これに基づいて、EIP-4844 以降にイーサリアムが達成できる TPS の次数も導き出すことができます。現在、平均的な L2 トランザクションには、L1 で約 3000 の Gas Calldata が必要です。 Calldata の 1 バイトあたりのガス コストが 16 であることを考慮すると、L1 上の各 L2 トランザクションが約 187 バイトであることを示します。EIP-4844 以降、ターゲット ブロック サイズは 0.375 MB で、イーサリアムは 12 秒ごとにブロックを生成します。したがって、1 秒あたりの利用可能なスペースは 0.375 / 12 \* 1024 = 32 KB となり、32 \* 1024 / 187 = 175 個のトランザクションに対応できます。したがって、通常の状況（つまり、ブロックが目標サイズに達したとき）では、EIP-4844 アップグレード後のイーサリアムの TPS は 175、最大 350 になるはずです。TPS が高くなると効率が向上しますが、EIP-4844 が実装されていても、イーサリアムは現在最大 1700 の TPS を持つ Visa ほど優れていないことは注目に値します。このギャップにより、特に需要が高いシナリオでは、L1 および L2 ネットワークの輻輳が依然として発生する可能性があります。**したがって、EIP-4844 だけでは、イーサリアムがより優れたスケーラビリティを実現するには十分ではありません。 **より多くの Calldata (Celestia のような DA レイヤーや zkPorter のような DAC など) を保存するための、よりコスト効率が高く効率的なデータ可用性ソリューションが依然として必要であり、これはスケーラビリティを実現するために依然として重要です。最後に、L2 トランザクションの圧縮率は、L1 に保存される Calldata のサイズに直接影響します。圧縮率が高いほど、必要な L1 コストは低くなります。 zkRollup が開発を続けるにつれて、L1 に保存する必要があるデータの量はますます少なくなり、イーサリアムのスケーラビリティの向上にも役立ちます。 zkRollup はオプティミスティック ロールアップとは異なるため、zkRollup はトランザクション全体ではなく、状態の変更のみを保存する必要があります。＃＃ 結論はこの記事では、2 つの異なる計算方法を使用して、ガス料金、TPS (1 秒あたりのトランザクション数)、および EIP-4844 実装後のロールアップに対応する能力の削減可能性を評価します。結果は、各ロールアップの Calldata サイズが一律 2KB であると仮定すると、EIP-4844 がサポートできるロールアップは最大でも 400 未満であることがわかります。これは、多くの人が予想していた数千のロールアップの需要とは大きく異なります。代替の DA レイヤーまたは DAC の利用、L2 トランザクション データの圧縮率の向上、および zk ロールアップの割合の増加はすべて、イーサリアムのスケーラビリティのさらなる向上に大きな影響を与えます。
ロールアップの経済性: スケーラビリティに対する EIP-4844 の影響は過大評価されている
著者: 0xfan、Smarti Lab、編集者: Peng SUN、Foresight News
##TL;DR：
Proto-danksharding (EIP-4844 としても知られる) は、Danksharding が将来使用する可能性のあるロジックとルールのほとんどを実装することを提案しています。現在、L1 のストレージ コストが高いため、L2 の移行料金も比較的高くなっています。この問題を解決するために、EIP-4844 では新しいデータ型 Blob が導入されています。これは calldata よりも安価で容量が大きく、ロールアップ データ ストレージの別の方法を提供します。
EIP-4844 の今後の発売により、L2 シーケンサーの収益性がさらに高まる可能性があります。これは、シーケンサーがトランザクション バッチを L1 にインポートし、データ料金を支払う責任があり、シーケンサーが支払う L1 データ料金が大幅に削減されるためです。取引手数料が低いと、L2 での注文数が増加し、より多くの MEV が生成される可能性があります。
カンクンのアップグレードには EIP-4844 が含まれますが、アップグレードの正確な時期はまだ決まっていません。イーサリアム財団の研究チームは、カンクンのアップグレードは10月末に開始される可能性があると述べた。ただし、2024 年の第 1 四半期頃に発売される可能性が高くなります。
**それでは、EIP-4844 は取引手数料をどの程度削減できるでしょうか? **現在、L2 トランザクション手数料は主に 2 つの部分で構成されています。
Optimism を例にとると、現在、総取引手数料のほぼ 80% は L1 ストレージ コスト (つまり、Calldata コスト) から発生しています。現時点では他の手数料の影響を無視し、EIP-4844 後に L2 トランザクション手数料がどれだけ削減されるかを見積もる 2 つの方法を提案します。
EIP-4844 では、提案が実装された後、各 BLOB のサイズは 128 KB になり、各 BLOB は 131,072 ガスを消費します。したがって、平均して、各 BLOB データ バイトは 128 * 1024 / 131,072 = 1 ガスを消費します。比較すると、現在 1 つの Calldata バイトを保存すると 16 Gas が消費されます。これは、L2 トランザクションのストレージ コストが 16 分の 1 に削減されることを示しています。
ただし、この方法ではバイトあたりのストレージ コストのみが比較され、ブロックの総ガス容量は考慮されません。 EIP-4844 以降は、単一のブロックが運ぶことができるガスの総量が変更される可能性があるため、L2 トランザクションのストレージ コストが 16 分の 1 以上削減される可能性があります。
2 番目の方法では、ブロック サイズを考慮し、現在の Calldata がさまざまなブロック サイズに収容できる回数を確認します。現在のパラメーターによると、ターゲット ブロック サイズのシナリオでは、ブロックは 3 つの BLOB (0.375MB)、最大 6 つの BLOB (0.75MB) を収容できます。現在の各ブロックの Calldata が約 2 ～ 10KB を占めることを考慮すると、EIP-4844 以降は、最大 0.75 * 1024 / 2 = 384 倍 の Calldata を収容できます。
ただし、ブロック サイズが目標値から最大値まで増加するにつれて、ガス価格は指数関数的に増加します。したがって、より一般的なケース (つまり、ブロックがターゲット サイズに達した場合) では、EIP-4844 は、それぞれ 10KB と 2KB の Calldata の 38 ～ 192 倍の Calldata を収容できます。 **ブロック内の Calldata の容量が増加すると、それに応じて Calldata のストレージ コストも減少します。したがって、L2 トランザクションのコストもそれに応じて削減されます。
さらに、各ロールアップの Calldata サイズが一律 2KB であると仮定すると、EIP-4844 は最大 384 個のロールアップまでしか対応できません。これは、多くの人が想像していた数千のロールアップには達しません。
これに基づいて、EIP-4844 以降にイーサリアムが達成できる TPS の次数も導き出すことができます。現在、平均的な L2 トランザクションには、L1 で約 3000 の Gas Calldata が必要です。 Calldata の 1 バイトあたりのガス コストが 16 であることを考慮すると、L1 上の各 L2 トランザクションが約 187 バイトであることを示します。
EIP-4844 以降、ターゲット ブロック サイズは 0.375 MB で、イーサリアムは 12 秒ごとにブロックを生成します。したがって、1 秒あたりの利用可能なスペースは 0.375 / 12 * 1024 = 32 KB となり、32 * 1024 / 187 = 175 個のトランザクションに対応できます。したがって、通常の状況（つまり、ブロックが目標サイズに達したとき）では、EIP-4844 アップグレード後のイーサリアムの TPS は 175、最大 350 になるはずです。
TPS が高くなると効率が向上しますが、EIP-4844 が実装されていても、イーサリアムは現在最大 1700 の TPS を持つ Visa ほど優れていないことは注目に値します。このギャップにより、特に需要が高いシナリオでは、L1 および L2 ネットワークの輻輳が依然として発生する可能性があります。
**したがって、EIP-4844 だけでは、イーサリアムがより優れたスケーラビリティを実現するには十分ではありません。 **より多くの Calldata (Celestia のような DA レイヤーや zkPorter のような DAC など) を保存するための、よりコスト効率が高く効率的なデータ可用性ソリューションが依然として必要であり、これはスケーラビリティを実現するために依然として重要です。
最後に、L2 トランザクションの圧縮率は、L1 に保存される Calldata のサイズに直接影響します。圧縮率が高いほど、必要な L1 コストは低くなります。 zkRollup が開発を続けるにつれて、L1 に保存する必要があるデータの量はますます少なくなり、イーサリアムのスケーラビリティの向上にも役立ちます。 zkRollup はオプティミスティック ロールアップとは異なるため、zkRollup はトランザクション全体ではなく、状態の変更のみを保存する必要があります。
＃＃ 結論は
この記事では、2 つの異なる計算方法を使用して、ガス料金、TPS (1 秒あたりのトランザクション数)、および EIP-4844 実装後のロールアップに対応する能力の削減可能性を評価します。結果は、各ロールアップの Calldata サイズが一律 2KB であると仮定すると、EIP-4844 がサポートできるロールアップは最大でも 400 未満であることがわかります。これは、多くの人が予想していた数千のロールアップの需要とは大きく異なります。代替の DA レイヤーまたは DAC の利用、L2 トランザクション データの圧縮率の向上、および zk ロールアップの割合の増加はすべて、イーサリアムのスケーラビリティのさらなる向上に大きな影響を与えます。