# 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とか。 - 上限を超えて書き込みたい場合は、複数にトランザクションを分けてもらう。