---
# System prepended metadata

title: 1コントラクト当たりのCommonly Shared Storageのデータ制限を考える

---

# 1コントラクト当たりのCommonly Shared Storageのデータ制限を考える

## 現状のイーサリアムの1コントラクト当たりのStorageのデータ制限について

[Is there a (theoretical) limit for amount of data that a contract can store?](https://ethereum.stackexchange.com/questions/1038/is-there-a-theoretical-limit-for-amount-of-data-that-a-contract-can-store)

False. There are 2^256 different keys, and each key can store 32 bytes, so that's a total of **2^261** bytes that could be stored. That said, by then the Ethereum blockchain will probably break due to a hash collision....

上記の通り無限に大きいためほぼストレージの制限はない。

## 今回のTOTOROネットワークでの1コントラクト当たりのCommoly Shared Storageのデータ制限について

まず、結論としてイーサリアムのコントラクトと同様に**無限に大きいサイズ制限**でよい。

理由としては、ストレージの上限を決めてしまうと、上限以上のストレージサイズに書き込もうとしたコントラクトにてデータの不整合が発生してしまう可能性があるため。最悪GOXする恐れもある。

データ制限については無限に大きいので、実際にそのストレージを使用した分だけユーザに支払ってもらうモデルで**現実的な制限を**設けるような設計を考えた方がよい。

つまり

- 書き込めるデータは無限。
- ストレージに書き込む料金を高くすることで、現実的なサイズでしかデータを書く込めなくする。

また、トランザクションで大量にストレージにデータを書き込む処理を防ぐために下記も検討する。

- 1トランザクションで書き込めるストレージ回数やサイズを制限する。20とか30とか。
- 上限を超えて書き込みたい場合は、複数にトランザクションを分けてもらう。