CryptoZombies勉強会#3を開催しました - えんじにゃーず・ハイ

鉄は熱い内に打つと言ったな？

もちろん打つよ？

f:id:areph:20180630011325p:plain

ということでCryptoZombies勉強会#3を開催しました。

今回はレッスン3と、余裕があればいっしょにtruffleを導入しましょっか、という内容です。

鉄は熱い内に打つと言ったな？
レッスン3でやったこと
総括

レッスン3でやったこと

レッスン3はSolidityの特色を孕んだ内容がメインとなる。全体的にデータ構造が頭に入っていないと、このチャプターは何を狙いとしているのか理解ができずにコピペで流してしまう傾向が見られた。危険です。

Immutability of Contracts
- コントラクトは一度デプロイすると更新できない
  - それがスマートコントラクトの強みでもある
- 外部のコントラクトに依存している場合はデプロイしたコントラクトのアドレスをハードコーディングしてしまうと修正が効かない
- そのため、外部コントラクトのアドレスを変更できるように設計する
OpenZeppelinの Ownable
- Solidityのライブラリ群を提供するOpenZeppelin初登場
- 今後めっちゃお世話になる
- 今回はOwnableコントラクトを実装
- 中身を確認
  - Ownableコントラクト作成時に作成者(msg.sender)がOwnerとなる
  - modifier onlyOwnerでOwnerかどうかを関数修飾子(modifier)で宣言＆利用する
    - ヘルパー関数を呼び出すよりmodifierの方がすっきり書けて良い
    - 加えて関数行で何をしたいのか一目でわかる
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コストのほうが高いため、処理コストが高くても配列の操作などを行う方が良い