# [EIP170] コントラクト作成時にサイズ制限を設ける提案を理解しよう！

> ブロックチェーンでは、各トランザクションが含まれるブロックには一意の番号（ブロック番号）が割り当てられています。FORK_BLKNUMは、特定のブロックチェーンアップグレードやフォーク（分岐）が適用されるブロック番号を指します。

- URL: https://cardene.dev/articles/eef7d90d07aae21dfe6f
- 公開日: 2024-01-29
- 更新日: 2024-01-29
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

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

https://cryptogames.co.jp/

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

https://cryptospells.jp/

今回は、コントラクト作成時に最大コードサイズを超えると、ガス不足でコントラクトの作成が失敗する新しいルール仕組みを提案している**EIP170**についてまとめていきます！

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

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

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

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

## パラメータ

| | |
| - | - |
| `MAX_CODE_SIZE` | `0x6000 (2**14 + 2**13)` |
| `FORK_BLKNUM` | `2,675,000` |
| `CHAIN_ID` | `1` (Mainnet) |

## 仕様

ブロックチェーンでは、各トランザクションが含まれるブロックには一意の番号（ブロック番号）が割り当てられています。
`FORK_BLKNUM`は、特定のブロックチェーンアップグレードやフォーク（分岐）が適用されるブロック番号を指します。
ここでは、`FORK_BLKNUM`は特定の変更が有効になるブロック番号を意味します。

コントラクトの作成とは、ブロックチェーン上に新しいスマートコントラクトをデプロイするプロセスのことです。
このプロセスは、初期化コードの実行を伴い、その結果としてコントラクトのバイトコードが生成されます。
`MAX_CODE_SIZE`は、ブロックチェーンにおけるスマートコントラクトのコードサイズの最大許容値を指します。
これは、ブロックチェーンのパフォーマンスやセキュリティを維持するために設けられた制限です。

したがって、`FORK_BLKNUM`以上のブロック番号でコントラクトが作成される時に、その初期化プロセスが`MAX_CODE_SIZE`バイトを超えるデータを返すと、コントラクトの作成は「**ガス不足**」のエラーで失敗します。
ガスは、ブロックチェーン上での操作（トランザクションの実行、コントラクトの作成など）に要する計算資源の単位です。
ガス不足のエラーは、トランザクションに割り当てられたガスが実行に必要な量を下回る場合に発生します。
この場合、コントラクトのコードサイズが大きすぎるため、その作成に必要なガス量が割り当て量を超え、結果としてトランザクションは失敗します。

## 補足

イーサリアムのシステムでは、スマートコントラクトが呼び出されるときに一定量のガス（ブロックチェーン上での操作に必要な計算資源の単位）が消費されますが、このプロセスは予想外の追加コストを発生させる可能性があります。
具体的には、コントラクトのコードをディスクから読み込む、仮想マシン（VM）での実行に向けてコードを前処理し、ブロックの正当性の証明に必要なマークル証明にデータを追加するという工程が、データの量に比例した（`O(n)`の）コストを引き起こす可能性があります。

このような二次的なコストは、現在のガスレベルでは許容されるかもしれませんが、将来的にガスの上限が動的に増加する可能性がある場合（これは実際に近い将来に起こり得ます）、より大きな問題となります。
これは、サービス拒否（DoS）攻撃ほど深刻な問題ではないにせよ、ブロックチェーンの有効性や無効性を証明するための証拠を検証するライトクライアント（ブロックチェーンの全データをダウンロードせずに済む軽量クライアント）にとって都合が悪いです。

この問題に対処するための提案された解決策は、ブロックチェーンに保存できるオブジェクトのサイズに上限を設けることです。
この上限は現在のガスリミットで実現可能なサイズをわずかに上回る値に設定することで、システムに悪影響を与えずに実装できます。
これにより、将来的にガスリミットが増加したとしても、スマートコントラクトのサイズが無制限に大きくなることを防ぎ、関連するコストの増加やシステムの脆弱性を事前に抑制することが期待されます。

## 参考

- [**EIP-170**](issue and discussion: https://github.com/ethereum/EIPs/issues/170)
- [**pyethereum implementation**](https://github.com/ethereum/pyethereum/blob/5217294871283d8dc4fb3ca9d8a78c7d416490e8/ethereum/messages.py#L397)

## 引用

Vitalik Buterin (@vbuterin), "EIP-170: Contract code size limit," Ethereum Improvement Proposals, no. 170, November 2016. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-170.

## 最後に

今回は「コントラクト作成時に最大コードサイズを超えると、ガス不足でコントラクトの作成が失敗する新しいルール仕組みを提案している**EIP170**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下の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