きの仮想通貨コントラクトをデプロイしてみる(前編)どうも、ぺろりんです。Books)」でやっていきます。今回は、教科書的には「キャッシュバック機能付き仮想通貨コントラクト」の続きです。書いているうちに長くなってしまったので、前編と後編に分けることにしましたw本当ならもう少し早くこれをやりたかったんですが、今回の内容は個人的につまずく箇所がいくつかあったので、「コントラクトの継承と連携(他のコントラクトのメソッド実行)」という記事をはさんでみました。今回やりたいのは、暗号資産(仮想通貨)が1つあって、これに「紐づくユーザーが各々会員情報を持つ」状況をコントラクトで表現することです。以下では教科書にあるサンプルコードをデプロイして、動きを追いつつコードについて考えたことなどをコメントしていきます。VMを使い、すべてweb上で動かします。アドレスのまとめ先に、今回使うアドレスをまとめておきます。今回は、以下4つのアドレスが登場します。先ほど大まかにご紹介した「やりたい」ことを、コードでどう表現されているかを軽く触れておきます。コントラクトのコードとしては、だいたい以下のような構造になっています。き仮想通貨コントラクト「OreOreCoin」の3つが1つの.solファイルに書かれている。(2)(コードの見通しをよくする目的で)「Members」と「OreOreCoin」が「Owned」のサブコントラクトになっている。(3)「OreOreCoin」に定義された関数の中で、「Members」で定義された関数を呼び出しているこの(3)が、個人的にはポイントだと思っています。(後から出てきますが)動作させる上では、「Members」に定義された状態変数「coin」に「OreOreCoin」のデプロイアドレスを入れるので、(3)と合わせると「Members」と「OreOreCoin」が入れ子みたいな構造で動きます。́Д`)各コントラクトは以下のような内容です。・Owned...オーナーアドレス「owner」の定義と、オーナーアドレスの変更をする。・Members...状態変数として会員情報を定義し、会員情報と取引履歴を更新する関数を持っている。・OreOreCoin...暗号資産(仮想通貨)OreOreCoinを定義し、送金、ブラックリスト、キャッシュバック機能を、Membersの情報を使いながら実装する。Books)」をご参照ください。コントラクトのデプロイいつも通り、サンプルコードをコピペして、コンパイラのバージョンをコードに合わせてコンパイルします。VM」にしつつ、教科書通りユーザーA(ここでのアドレス:0xca35b7d915458ef540ade6068dfe2f44e8fa733c)で「Members」をデプロイします。今回は前の記事のように「new」していないので、いきなり「Members」をデプロイして「Owned」がデプロイされるのか気になっていましたが、「owner」にユーザーAのアドレスが入っているところを見ると、どうやらサブコントラクトをデプロイすると親コントラクトもデプロイされるみたいですね。......というかむしろ、「Owned」がデプロイされているというよりも、「Owned」に(「クラス」的に)定義された部分はソースをコンパイルした時点で「Members」内でもデプロイできる状態になるので、“「Members」内に(継承された部分として)定義された「Owned」部分”がデプロイされて、“「Members」内に(継承された部分として)定義された”「owner」に値が入ったと考えるべきなのかな。Members.owner」と出ていたりするので、ここでは「Members」の「owner」(=Members.owner)ってことみたいですね。教科書通りにサクッと会員ステイタスをpushしていきます。ここで使う「pushStatus」は「onlyOwner」修飾子がかかっているので、「Members」のオーナーしか実行できません。「各メンバーが自分でステータスを変更」ということはできません。一応、教科書に沿って「Members」のオーナーをユーザーB(0x14723a09acff6d2a60dcdf7aa4aff308fddc160c)にしておきます。この「transferOwnership」も「Members」のオーナーしか実行できません。(という意図なんだと思います。)せっかくなので、まだオーナーになっていないユーザーBのアドレスで、ユーザーBが自分をオーナーにするように「transferOwnership」を実行してみましょう。やってみると......やはりユーザーBはオーナーではないので怒られます。気を取り直してユーザーAで実行すると、無事に「owner」がユーザーBのアドレスになります。会員管理機能付き仮想通貨コントラクト「OreOreCoin」のデプロイ例のごとく教科書に沿って、ユーザーAで「OreOreCoin」をデプロイします。「OreOreCoin」のオーナーアドレスには、ちゃんとユーザーAのアドレスが入っています。「OreOreCoin」のデプロイアドレス(0xdc04977a2078c8ffdf086d618d1f961b6c546222)も、後で使うのでコピっておきます。「Members」と「OreOreCoin」の紐づけここがなかなか理解できなかったのですが、「Members」と「OreOreCoin」を、各々のデプロイアドレスを使って紐づけていきます。やることは以下の2つです。(1)ユーザーBで、「Members」のデプロイアドレスを引数にして(「OreOreCoin」内で定義された)「setMembers」を実行する。(2)「OreOreCoin」のデプロイアドレスを引数にして(「Members」内で定義された)「setCoin」を実行する。(こちらは「Members」のオーナーアドレスという意味で、ユーザーBで実行する必要があります)まず(1)をやってみます。次に、(2)を実行します。上記(1)、(2)で、以下の図のようなことをしています。(逆に混乱しちゃったら無視してくださいw)私が理解するにあたって、以下がポイントでした。(A)「setMembers」は「OreOreCoin」、「setCoin」は「Members」内に定義されている。(名前が入れ子になっていてややこしい)(B)「setMembers」の定義には「msg.sender」が入っているため、実行ユーザーを気にする必要がある。(後述しますが、「onlyOwner」修飾子がついている「setCoin」も実行ユーザーを気にする必要があります)(C)「coin」はただのaddress型だけど、「members」はmapping型なので“配列”になっている。(「mapping」は「連想“配列”」であることを忘れていて、当初スカラー量のイメージで読んでいたせいで理解がなかなか進みませんでしたw)「会員ごとに会員情報を持つ」ことを、(B)→会員アドレスと会員情報(=Members)の紐づけることで、会員が会員情報を持つこと(C)→会員アドレスをインデックスとする配列(members)によって、会員ごとに情報を持つことという風に実装しています。ここまでで、ユーザーBの「Members」コントラクトが準備できました。前編はこのへんで、後編へ続きます。»PagetopプロフィールAuthor:ぺろりんまだ始まってもいない暗号資産(仮想通貨)、今後が楽しみです。基本的な技術をちゃんと知りたいなぁと思いつつ、まったりお勉強していこうかと思います。Reserved.|プライバシーポリシ。