[EIP2028] Calldataのガスコストを削減する提案について理解しよう！

# はじめに

初めまして。
**CryptoGames**というブロックチェーンゲーム企業でエンジニアをしている **cardene（かるでね）** です！
スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。

https://cryptogames.co.jp/

代表的なゲームは**クリプトスペルズ**というブロックチェーンゲームです。

https://cryptospells.jp/

今回は、ブロックサイズの増加がネットワーク遅延と効率比に与える影響を推定し、`Calldata`のガスコストを削減行う提案している**EIP2028**についてまとめていきます！

:::note info
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

https://eips.ethereum.org/EIPS/eip-2028

他にも様々なEIPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

# 概要

ブロックチェーンにおける特定のデータ送信コスト、具体的には「`Calldata`（`GTXDATANONZERO`）」と呼ばれる部分のガスコスト（ブロックチェーンの取引を行う時にかかる手数料の単位）を現在の`1`バイトあたり`68`ガスから`16`ガスに大幅に削減する提案をしています。
この提案は単なるアイデアにとどまらず、SompolinskyとZohar、そしてPass, Seeman, Shelatによる研究で使用された数学的なフレームワークを用いて、この変更がブロックチェーンのネットワークの遅延（取引の処理速度に影響する）とセキュリティにどのような影響を与えるかを理論的・実証的に評価することを計画しています。
具体的には、最初に理論モデルを用いてガスコストの減少がネットワーク遅延に与える影響を予測し、次に実際のデータや実験を通じてこのモデルの妥当性を検証します。
最終的には、この研究から得られた知見を基に、`Calldata`のガスコストをどの程度に設定するかを決定することを目指しています。

# 動機

`Calldata`のガスコストを下げることで、ブロックチェーンのスケーラビリティを向上させるというこの提案には、大きく分けて3つの主な利点があります。
まず、オンチェーンのスケーラビリティが向上します。
`Calldata`の帯域幅を増やすことで、1つのブロックに含めることができるデータ量が増え、結果としてトランザクションの処理能力が高まります。

次に、レイヤー2のスケーラビリティが向上します。
レイヤー2のソリューションは、計算やデータの保存をブロックチェーンの外に移すことでスケーラビリティを向上させますが、これにはデータの送信が伴います。
`Calldata`のガスコストを下げることで、このようなソリューションの効率が向上し、例えば、大量のトランザクションを処理する計算の証明を提供するSTARKsやSNARKsのような証明システムの利用が容易になります。

最後に、ステートレスクライアントに関する利点があります。
将来的には、ステートレスクライアントで状態アクセスのコストを決定する時にも、このモデルが使用される予定です。
ここでは、ブロックの証明を送信し検証するために必要な追加の帯域幅と処理能力に比例して、状態アクセスのガスコストが増加すると予想されます。
これにより、ブロックチェーンの効率的な運用がサポートされ、将来的にはより高度なスケーリングソリューションの実装が可能になります。

:::note info
### ステートレスクライアント

ステートレスクライアント（Stateless Client）とは、ブロックチェーンネットワークにおいて、各ノードが全てのトランザクションの履歴やアカウントの状態（ステート）を完全に保持せずに済むようにする概念です。
従来のブロックチェーンネットワークでは、各ノードが全てのトランザクションとそれによって発生した最終的なアカウント状態を保持している必要があります。
これは「**ステートフルクライアント（Stateful Client）**」と呼ばれます。

しかし、ブロックチェーンが成長するにつれて、全てのデータを保持し続けることは、ストレージコストの増大やネットワークの参加障壁の高さという問題を引き起こします。
ステートレスクライアントは、この問題に対処するために提案されました。
ステートレスクライアントは、ブロックチェーンの完全な状態を保持する代わりに、「**証明**」（Proofs）のみを保持します。
これらの証明によって、トランザクションが有効であること、または特定の状態が正しいことが証明されます。

ステートレスクライアントの導入により、ネットワーク参加者は必要最小限のデータのみを保持することで、トランザクションの検証やブロックの検証を行うことが可能になります。
これにより、ノードの運用コストを削減し、より多くのユーザーやデバイスがブロックチェーンネットワークに参加できるようになります。
特に、リソースが限られたデバイスやモバイルデバイスでも、ネットワークのフルノードとして機能できるようになります。
ステートレスクライアントは、ブロックチェーンのスケーラビリティとアクセシビリティを向上させる重要な技術とされています。
:::

# 補足

`Calldata`のガスコストを下げると、理論的にはブロックサイズが大きくなる可能性があり、これによりネットワーク上でのデータ伝送にかかる遅延が増加することが予想されます。
ただし、これはネットワーク遅延全体の一部にすぎず、ブロック処理時間（その一環としてのストレージアクセスも含む）も遅延に影響を与える要因です。
ネットワーク遅延の増加は、ブロックチェーンの最新状態に更新されているノードが少なくなるため、ネットワーク攻撃のコストが低下し、結果的にセキュリティが低下する可能性があります。

Yonatan SompolinskyとAviv Zoharは、ネットワーク遅延とネットワークセキュリティの関係を示す洗練されたモデルを提案しました。
このモデルはRafael Pass、Lior Seeman、Abhi Shelatの研究でも使用されています。
ここでは、`Calldata`の低ガスコストを提案するために、このモデルを理論的に研究し、実証的な測定によって検証する予定です。

このモデルは次の自然なパラメーターを使用します。

- **λ（ラムダ）**はブロック作成率[1/秒]を示し、PoW（Proof of Work）ソリューションを見つけるプロセスを率λのポアソン過程として扱います。
- **β（ベータ）**はチェーン成長率[1/秒]で、最も重いチェーンに新しいブロックが追加される率を表します。
- **D**はブロック遅延[秒]で、新しいブロックがマイニングされてからすべてのマイナーによって受け入れられる（すべてのマイナーがそのブロックの上にマイニングを切り替える）までの経過時間です。

:::note info
### λ（ラムダ）
λ（ラムダ）とは、ブロックチェーン上で新しいブロックがどれくらいの頻度で作成されるかを示す数値です。
この数値は「**ブロック作成率**」と呼ばれ、単位は「**1秒あたりのブロック数**」で表されます。
つまり、ラムダの値が高いほど、ブロックがより頻繁に生成されることを意味します。

ブロックの生成プロセスは、Proof of Work（PoW）と呼ばれる計算問題を解くことによって行われます。
マイナー（ブロックを生成する参加者）は、特定の計算問題の解を見つけることによって新しいブロックを作成します。
このプロセスは確率的なものであり、いつ正確に新しいブロックが見つかるかは予測できません。

このような確率的なプロセスを数学的に表現する一つの方法が「**ポアソン過程**」です。
ポアソン過程は、一定時間内にランダムに発生するイベントの数をモデル化するために用いられます。
ここでのイベントは新しいブロックの発見です。
ラムダはこのポアソン過程の「**率**」を示し、1秒あたりに平均して何回のブロックが生成されるかを表します。

**λ（ラムダ）**はブロックがどれくらいの速さで生成されるかを示す指標であり、PoWを通じてブロックが生成されるプロセスはランダムなイベントの連続としてモデル化されます。
これにより、新しいブロックの生成タイミングが予測不可能であることが数学的に表現されます。

## ベータ下限

ベータの下限についての注意点ですが、全ての発見されたブロックがメインチェーンに入るわけではないため（アンクルブロックの場合のように）、**λ（ラムダ）**は**β（ベータ）**以上であると言えます。
参考の[1]で示されたように、最長チェーンルールを使用するブロックチェーンでは、**β**の下限を`λ / (1 + D * λ)`によって制約することができます。
この下限は、ネットワークのトポロジーが各ノード間の遅延が**D**であるクリーク（最大可能遅延）である極端なケースで成立します。
**β**の下限と上限の両方を記録すると、以下のようになります。

```math
\lambda \geq \beta \geq \frac{\lambda}{1 + D \times \lambda}
```

常識チェックとして、遅延がない場合（`D=0`）では、期待通り**β**は**λ**と等しくなります。

:::note info
ブロックチェーンにおける2つの重要なパラメーター、**λ（ラムダ）**と**β（ベータ）**について説明しています。
**λ**はブロックの作成率を示し、一方で**β**は実際にメインチェーンに追加されるブロックの率を示します。

ブロックチェーンでは、すべてのマイナーが同時にブロックを生成することがありますが、それらのすべてが最終的なブロックチェーンに含まれるわけではありません。
このような場合、メインチェーンに含まれないブロックは「**アンクルブロック**」と呼ばれます。
そのため、実際にメインチェーンに追加されるブロックの率である**β**は、ブロックの作成率である**λ**よりも小さいか、同じになります。

さらに、ネットワークの遅延（**D**）が存在する場合、それが**β**の値にどのように影響するかを理解することが重要です。
遅延が大きいほど、ノード間で情報が伝わるのに時間がかかり、その結果、ブロックがメインチェーンに追加される率（**β**）が低下します。
この関係は、**β**の下限を`λ / (1 + D * λ)`として数学的に表現できます。
これは、遅延とブロックの作成率の両方が**β**にどのように影響するかを示しています。

この式によると、遅延がない場合（`D=0`）、**β**は**λ**と等しくなります。
これは、ブロックの作成とブロックチェーンへの追加が即時に行われることを意味します。
しかし、遅延が存在すると、**β**は**λ**よりも小さくなり、この差は**D**と**λ**の値によって大きくなります。

ブロックの作成率（**λ**）とメインチェーンに追加されるブロックの率（**β**）の関係を説明し、ネットワークの遅延がこの関係にどのように影響するかを数学的に示しています。
:::

## ネットワークのセキュリティ

ネットワークのセキュリティに関して、攻撃者がメインチェーンを再編成しようとする場合、**β（ベータ）**よりも高い率でブロックを生成する必要があります。
Proof of Work（PoW）パズルの難易度レベルを固定すると、システム内の総ハッシュレートは**λ（ラムダ）**に関連しています。
したがって、`β / λ`はシステムの効率として定義され、ネットワークのメインチェーンを生成するために使用される総ハッシュパワーの割合を測定します。

```math
\lambda \geq \beta \geq \frac{\lambda}{1 + D \times \lambda}
```

上記の式を再配置すると、遅延の観点から効率の下限について以下のようになります。

```math
\frac{\beta}{\lambda} \geq \frac{1}{1 + D \times \lambda} \space\space\space[**]
```

これは、遅延**D**とブロック作成率**λ**がシステムの効率にどのように影響するかを示しています。
遅延が増加すると、メインチェーンに寄与するハッシュパワーの割合、つまりシステムの効率が低下することを意味します。
この式は、ネットワークのセキュリティを保つために、遅延による影響を考慮に入れながら、十分なハッシュパワーがメインチェーンの生成に使用されていることを確保する必要があることを示しています。

:::note info
```math
\lambda \geq \beta \geq \frac{\lambda}{1 + D \times \lambda}
```

上記の式を再配置して、システムの効率に関する遅延の観点からの下限を求めています。
具体的には、**β（メインチェーンに追加されるブロックの率）**と**λ（ブロック作成率）**の比、つまり $\(\frac{\beta}{\lambda}\)$ が、システムの効率を示しています。

この比率 $(\frac{\beta}{\lambda})$ は、生成されたブロックのうち、実際にメインチェーンに追加されるブロックの割合を表し、これがシステムの効率の尺度となります。
再配置とは、先ほどの式からこの比率 $(\frac{\beta}{\lambda})$ に関する不等式を導出することを指しています。

具体的には、先ほどの式の下限 $(\beta \geq \frac{\lambda}{1 + D \times \lambda})$ から、両辺を**λ**で割ることで、効率の下限に関する式 $(\frac{\beta}{\lambda} \geq \frac{1}{1 + D \times \lambda})$ を得ています。
この式は、遅延（**D**）がシステム効率に与える影響を数学的に表しており、遅延が大きくなるほどシステムの効率が低下することを示しています。
:::

## 遅延パラメータD

遅延パラメーター**D**について、ネットワーク遅延はマイニングノードのネットワーク内の位置と現在のネットワークトポロジー（動的に変化する）に依存し、そのため直接測定するのはやや困難です。
以前、Christian DeckerとRoger Wattenhoferは、伝播時間がブロックサイズに比例して拡大することを示し、Vitalik Buterinは効率（**）の測定に密接に関連するアンクルレートもブロックサイズに比例して拡大することを示しました。

しかし、遅延関数は`D = D_t + D_p`として2つの部分に分解することができます。
ここで`D_t`はブロックの伝送によって引き起こされる遅延、`D_p`はノードによるブロックの処理によって引き起こされる遅延です。
私たちのモデルとテストは、`Calldata`が`D_t`と`D_p`のそれぞれに与える影響を検討し、それらの影響が異なると仮定します。
これは特にレイヤー2のスケーラビリティやステートレスクライアントにとって関連性が高いかもしれません。
なぜなら、これらの目標に関連する`Calldata`のほとんどは、`D_t`の成分が大きいが`D_p`の値が比較的小さいメルクル認証パスで構成されているためです。

# テスト

`Calldata`のガスコストを提案するために、2種類のテストを実施しています。

- ネットワークテスト
    - thereumメインネット上で行われ、ブロックサイズの増加が`D_p`（ブロック処理遅延）と`D_t`（ブロック伝送遅延）、全体的なネットワーク遅延**D**、効率比（**）、さらには異なるマイニングプール間の遅延に与える影響を推定するために使用されます。
    - このテストには、既存のデータに対する回帰テストと、極端なシナリオを導入するストレステストが含まれます。

- ローカルテスト
    - 単一のノード上で行われ、`Calldata`の量と一般的な計算制限の関数としての処理時間を測定します。

これらのテストを通じて、Calldataに関連するガスコストの適切な設定を特定し、Ethereumネットワークの効率とセキュリティを最適化することを目指しています。

# 参考

- [1] Yonatan Sompolinsky, Aviv Zohar: [Secure High-Rate Transaction Processing in Bitcoin.](https://eprint.iacr.org/2013/881.pdf) Financial Cryptography 2015: 507-527
- [2] Rafael Pass, Lior Seeman, Abhi Shelat: [Analysis of the Blockchain Protocol in Asynchronous Networks](https://eprint.iacr.org/2016/454.pdf), ePrint report 2016/454
- [3] Christian Decker, Roger Wattenhofer: [Information propagation in the Bitcoin network.](https://www.gsd.inesc-id.pt/~ler/docencia/rcs1314/papers/P2P2013_041.pdf) P2P 2013: 1-10
- [4] Vitalik Buterin: [Uncle Rate and Transaction Fee Analysis](https://blog.ethereum.org/2016/10/31/uncle-rate-transaction-fee-analysis/)

# 引用

Alexey Akhunov (@AlexeyAkhunov), Eli Ben Sasson <eli@starkware.co>, Tom Brand <tom@starkware.co>, Louis Guthmann <louis@starkware.co>, Avihu Levy <avihu@starkware.co>, "EIP-2028: Transaction data gas cost reduction," Ethereum Improvement Proposals, no. 2028, May 2019. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2028.

# 最後に

今回は「ブロックサイズの増加がネットワーク遅延と効率比に与える影響を推定し、`Calldata`のガスコストを削減行う提案している**EIP2028**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://chaldene.net/

https://zenn.dev/heku

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4