CryptoZombies勉強会#3を開催しました
鉄は熱い内に打つと言ったな?
もちろん打つよ?
ということでCryptoZombies勉強会#3を開催しました。
今回はレッスン3と、余裕があればいっしょにtruffleを導入しましょっか、という内容です。
レッスン3でやったこと
レッスン3はSolidityの特色を孕んだ内容がメインとなる。全体的にデータ構造が頭に入っていないと、このチャプターは何を狙いとしているのか理解ができずにコピペで流してしまう傾向が見られた。危険です。
- Immutability of Contracts
- OpenZeppelinの Ownable
- gas
- Ethereumブロックチェーンへ書き込む度に発生する使用料
- 分散されたノードに書き換えが発生した際に使用料が発生する
- サイドチェーンの話が出てる!前に僕がやった時は無かったはず。今後のレッスンが楽しみです
CryptoZombiesの作者がLoom Networkで構築しているようなサイドチェーンの場合は話は別です
- structのgas
- uintは予想されるbit数で抑える
- uintの型同士はまとめることでgas消費量を抑えることができる
- 恐らく一度にメモリを確保するサイズの問題?
- Cとかでもあった気がする
- Time Units
- days とか hours とか便利
- nowは現在のunixタイムスタンプ
- nowはblock.timestampのエイリアス
- マイナーのタイムスタンプになるので外部依存となる点に注意
- Solidityでの時間表現の注意すべきポイントとそのテスト方法
- 2038年問題
- 32bitだと2038年にtimestampの数値がオーバーフローする
- とはいえそれを考慮して64bitにすると2038年までgasコストが上がったままになるので気にしない方がいいかもというのが個人の意見
- このあたりでレッスン1,2を振り返らないと混乱するケースが出てきたのでデータイメージを書いてゆっくり進めた
- publicからinternalへ
- このチャプターではなぜinternalにしたのかを考える
- KittyでないのにKittyとして振る舞えてしまうのが問題
- View関数
- ブロックチェーンの読み取りのみの場合はgasが発生しない
- ただし、viewでない関数からview関数を呼び出した場合はgasが発生する?
- 外部からview関数を呼び出した場合のみ、と明記しているのが気になる
- Storageのgasコスト
- storageはブロックチェーンに書き込むためgasコストが高い
- では毎回storageかmemoryかを意識しなければいけないのかどうか
- Frequently Asked Questions — Solidity 0.4.25 documentation
- 気をつけるべきはローカル変数のstructとarray。これらは他の型と違いローカル変数でもstorageに保存される
- もしstorageに書き込むつもりではないなら明示的にmemoryを付ける
- OwnerのZombies配列をstorageに持たない理由
- 誰かにZombieを譲渡したい時に現在のデータ設計だと大変+gasコストが莫大
- ZombieのIDを配列のインデックスとかではなくmappingにすれば楽なような…
- また、forループ処理によるgasコストよりもstorageコストのほうが高いため、処理コストが高くても配列の操作などを行う方が良い
- 誰かにZombieを譲渡したい時に現在のデータ設計だと大変+gasコストが莫大
今回はここまで。3時間ほど掛かったのでtruffleは別の機会でやることになった。
総括
Solidityの特殊な言語仕様に加え、gasコストと処理コストを考慮するなど面白い内容になってきている。次もやっていきましょう。