「会員管理」機能付きの仮想通貨コントラクトをデプロイしてみる（前編）
どうも、ぺろりんです。
まったり進行で、引き続きEthereumのお勉強を「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」でやっていきます。
今回は、教科書的には「キャッシュバック機能付き仮想通貨コントラクト」の続きです。
書いているうちに長くなってしまったので、前編と後編に分けることにしましたｗ
本当ならもう少し早くこれをやりたかったんですが、今回の内容は個人的につまずく箇所がいくつかあったので、「コントラクトの継承と連携（他のコントラクトのメソッド実行）」という記事をはさんでみました。
今回やりたいのは、暗号資産（仮想通貨）が1つあって、これに「紐づくユーザーが各々会員情報を持つ」状況をコントラクトで表現することです。
以下では教科書にあるサンプルコードをデプロイして、動きを追いつつコードについて考えたことなどをコメントしていきます。
今回もBrowser-SolidityでJavaScript VMを使い、すべてweb上で動かします。
先に、今回使うアドレスをまとめておきます。
今回は、以下4つのアドレスが登場します。
・ユーザーA：0xca35b7d915458ef540ade6068dfe2f44e8fa733c
・ユーザーB：0x14723a09acff6d2a60dcdf7aa4aff308fddc160c
・Membersのデプロイアドレス：0x692a70d2e424a56d2c6c27aa97d1a86395877b3a
・OreOreCoinのデプロイアドレス：0xdc04977a2078c8ffdf086d618d1f961b6c546222
先ほど大まかにご紹介した「やりたい」ことを、コードでどう表現されているかを軽く触れておきます。
コントラクトのコードとしては、だいたい以下のような構造になっています。
（１）所有者管理用コントラクト「Owned」、会員管理用コントラクト「Members」、会員管理機能付き仮想通貨コントラクト「OreOreCoin」の3つが1つの.solファイルに書かれている。
（２）（コードの見通しをよくする目的で）「Members」と「OreOreCoin」が「Owned」のサブコントラクトになっている。
（３）「OreOreCoin」に定義された関数の中で、「Members」で定義された関数を呼び出している
この（３）が、個人的にはポイントだと思っています。
さらに（後から出てきますが）動作させる上では、「Members」に定義された状態変数「coin」に「OreOreCoin」のデプロイアドレスを入れるので、（３）と合わせると「Members」と「OreOreCoin」が入れ子みたいな構造で動きます。
……これを理解するのに時間がかかった……(;´Д｀)
各コントラクトは以下のような内容です。
・Owned…オーナーアドレス「owner」の定義と、オーナーアドレスの変更をする。
・Members…状態変数として会員情報を定義し、会員情報と取引履歴を更新する関数を持っている。
・OreOreCoin…暗号資産（仮想通貨）OreOreCoinを定義し、送金、ブラックリスト、キャッシュバック機能を、Membersの情報を使いながら実装する。
コード自体は「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」をご参照ください。
いつも通り、サンプルコードをコピペして、コンパイラのバージョンをコードに合わせてコンパイルします。
平和にコンパイルできましたｗ
初期の頃はコンパイラのバージョンがコードに合っていなくて（選べなかったのか、選ばなかったのかは忘れましたが）、そこそこWarningが出ていましたｗ
まず、「Environment」を「JavaScript VM」にしつつ、教科書通りユーザーA（ここでのアドレス：0xca35b7d915458ef540ade6068dfe2f44e8fa733c）で「Members」をデプロイします。
今回は前の記事のように「new」していないので、いきなり「Members」をデプロイして「Owned」がデプロイされるのか気になっていましたが、「owner」にユーザーAのアドレスが入っているところを見ると、どうやらサブコントラクトをデプロイすると親コントラクトもデプロイされるみたいですね。
……というかむしろ、「Owned」がデプロイされているというよりも、「Owned」に（「クラス」的に）定義された部分はソースをコンパイルした時点で「Members」内でもデプロイできる状態になるので、“「Members」内に（継承された部分として）定義された「Owned」部分”がデプロイされて、“「Members」内に（継承された部分として）定義された”「owner」に値が入ったと考えるべきなのかな。
教科書的にも「MembersコントラクトのオーナーアドレスがユーザAであることを確認」と表現しているし、よく見たら「call to Members.owner」と出ていたりするので、ここでは「Members」の「owner」（＝Members.owner）ってことみたいですね。
ちなみに、あとで使うので「Members」コントラクトのデプロイアドレス（0x692a70d2e424a56d2c6c27aa97d1a86395877b3a）もコピっておきます(´・ω・｀)
教科書通りにサクッと会員ステイタスをpushしていきます。
ここで使う「pushStatus」は「onlyOwner」修飾子がかかっているので、「Members」のオーナーしか実行できません。
なので、「各メンバーが自分でステータスを変更」ということはできません。
一応、教科書に沿って「Members」のオーナーをユーザーB（0x14723a09acff6d2a60dcdf7aa4aff308fddc160c）にしておきます。
この「transferOwnership」も「Members」のオーナーしか実行できません。（という意図なんだと思います。たぶん）
せっかくなので、まだオーナーになっていないユーザーBのアドレスで、ユーザーBが自分をオーナーにするように「transferOwnership」を実行してみましょう。
やってみると……やはりユーザーBはオーナーではないので怒られます。
気を取り直してユーザーAで実行すると、無事に「owner」がユーザーBのアドレスになります。
例のごとく教科書に沿って、ユーザーAで「OreOreCoin」をデプロイします。
「OreOreCoin」のオーナーアドレスには、ちゃんとユーザーAのアドレスが入っています。
「OreOreCoin」のデプロイアドレス（0xdc04977a2078c8ffdf086d618d1f961b6c546222）も、後で使うのでコピっておきます。
ここがなかなか理解できなかったのですが、「Members」と「OreOreCoin」を、各々のデプロイアドレスを使って紐づけていきます。
やることは以下の2つです。
（１）ユーザーBで、「Members」のデプロイアドレスを引数にして（「OreOreCoin」内で定義された）「setMembers」を実行する。
（２）「OreOreCoin」のデプロイアドレスを引数にして（「Members」内で定義された）「setCoin」を実行する。（こちらは「Members」のオーナーアドレスという意味で、ユーザーBで実行する必要があります）
まず（１）をやってみます。
次に、（２）を実行します。
上記（１）、（２）で、以下の図のようなことをしています。
（逆に混乱しちゃったら無視してくださいｗ）
私が理解するにあたって、以下がポイントでした。
（A）「setMembers」は「OreOreCoin」、「setCoin」は「Members」内に定義されている。（名前が入れ子になっていてややこしい）
（B）「setMembers」の定義には「msg.sender」が入っているため、実行ユーザーを気にする必要がある。（後述しますが、「onlyOwner」修飾子がついている「setCoin」も実行ユーザーを気にする必要があります）
（C）「coin」はただのaddress型だけど、「members」はmapping型なので“配列”になっている。（「mapping」は「連想“配列”」であることを忘れていて、当初スカラー量のイメージで読んでいたせいで理解がなかなか進みませんでしたｗ）
「会員ごとに会員情報を持つ」ことを、
（B）→会員アドレスと会員情報（＝Members）の紐づけることで、会員が会員情報を持つこと
（C)→会員アドレスをインデックスとする配列（members）によって、会員ごとに情報を持つこと
という風に実装しています。
ここまでで、ユーザーBの「Members」コントラクトが準備できました。
前編はこのへんで、後編へ続きます。
まったり進行で、引き続きEthereumのお勉強を「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」でやっていきます。
今回は、教科書的には「キャッシュバック機能付き仮想通貨コントラクト」の続きです。
書いているうちに長くなってしまったので、前編と後編に分けることにしましたｗ
本当ならもう少し早くこれをやりたかったんですが、今回の内容は個人的につまずく箇所がいくつかあったので、「コントラクトの継承と連携（他のコントラクトのメソッド実行）」という記事をはさんでみました。
今回やりたいのは、暗号資産（仮想通貨）が1つあって、これに「紐づくユーザーが各々会員情報を持つ」状況をコントラクトで表現することです。
以下では教科書にあるサンプルコードをデプロイして、動きを追いつつコードについて考えたことなどをコメントしていきます。
今回もBrowser-SolidityでJavaScript VMを使い、すべてweb上で動かします。
アドレスのまとめ
先に、今回使うアドレスをまとめておきます。
今回は、以下4つのアドレスが登場します。
・ユーザーA：0xca35b7d915458ef540ade6068dfe2f44e8fa733c
・ユーザーB：0x14723a09acff6d2a60dcdf7aa4aff308fddc160c
・Membersのデプロイアドレス：0x692a70d2e424a56d2c6c27aa97d1a86395877b3a
・OreOreCoinのデプロイアドレス：0xdc04977a2078c8ffdf086d618d1f961b6c546222
「会員管理」機能付きの仮想通貨コントラクトのデプロイ
コントラクト（コード）の概要
先ほど大まかにご紹介した「やりたい」ことを、コードでどう表現されているかを軽く触れておきます。
コントラクトのコードとしては、だいたい以下のような構造になっています。
（１）所有者管理用コントラクト「Owned」、会員管理用コントラクト「Members」、会員管理機能付き仮想通貨コントラクト「OreOreCoin」の3つが1つの.solファイルに書かれている。
（２）（コードの見通しをよくする目的で）「Members」と「OreOreCoin」が「Owned」のサブコントラクトになっている。
（３）「OreOreCoin」に定義された関数の中で、「Members」で定義された関数を呼び出している
この（３）が、個人的にはポイントだと思っています。
さらに（後から出てきますが）動作させる上では、「Members」に定義された状態変数「coin」に「OreOreCoin」のデプロイアドレスを入れるので、（３）と合わせると「Members」と「OreOreCoin」が入れ子みたいな構造で動きます。
……これを理解するのに時間がかかった……(;´Д｀)
各コントラクトは以下のような内容です。
・Owned…オーナーアドレス「owner」の定義と、オーナーアドレスの変更をする。
・Members…状態変数として会員情報を定義し、会員情報と取引履歴を更新する関数を持っている。
・OreOreCoin…暗号資産（仮想通貨）OreOreCoinを定義し、送金、ブラックリスト、キャッシュバック機能を、Membersの情報を使いながら実装する。
コード自体は「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」をご参照ください。
コントラクトのデプロイ
いつも通り、サンプルコードをコピペして、コンパイラのバージョンをコードに合わせてコンパイルします。
平和にコンパイルできましたｗ
初期の頃はコンパイラのバージョンがコードに合っていなくて（選べなかったのか、選ばなかったのかは忘れましたが）、そこそこWarningが出ていましたｗ
「会員管理」機能付きの仮想通貨コントラクトの動作確認（その1）
会員管理用「Members」コントラクトのデプロイ
まず、「Environment」を「JavaScript VM」にしつつ、教科書通りユーザーA（ここでのアドレス：0xca35b7d915458ef540ade6068dfe2f44e8fa733c）で「Members」をデプロイします。
今回は前の記事のように「new」していないので、いきなり「Members」をデプロイして「Owned」がデプロイされるのか気になっていましたが、「owner」にユーザーAのアドレスが入っているところを見ると、どうやらサブコントラクトをデプロイすると親コントラクトもデプロイされるみたいですね。
……というかむしろ、「Owned」がデプロイされているというよりも、「Owned」に（「クラス」的に）定義された部分はソースをコンパイルした時点で「Members」内でもデプロイできる状態になるので、“「Members」内に（継承された部分として）定義された「Owned」部分”がデプロイされて、“「Members」内に（継承された部分として）定義された”「owner」に値が入ったと考えるべきなのかな。
教科書的にも「MembersコントラクトのオーナーアドレスがユーザAであることを確認」と表現しているし、よく見たら「call to Members.owner」と出ていたりするので、ここでは「Members」の「owner」（＝Members.owner）ってことみたいですね。
ちなみに、あとで使うので「Members」コントラクトのデプロイアドレス（0x692a70d2e424a56d2c6c27aa97d1a86395877b3a）もコピっておきます(´・ω・｀)
会員ステイタスの作成
教科書通りにサクッと会員ステイタスを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つです。
（１）ユーザーBで、「Members」のデプロイアドレスを引数にして（「OreOreCoin」内で定義された）「setMembers」を実行する。
（２）「OreOreCoin」のデプロイアドレスを引数にして（「Members」内で定義された）「setCoin」を実行する。（こちらは「Members」のオーナーアドレスという意味で、ユーザーBで実行する必要があります）
まず（１）をやってみます。
次に、（２）を実行します。
上記（１）、（２）で、以下の図のようなことをしています。
（逆に混乱しちゃったら無視してくださいｗ）
私が理解するにあたって、以下がポイントでした。
（A）「setMembers」は「OreOreCoin」、「setCoin」は「Members」内に定義されている。（名前が入れ子になっていてややこしい）
（B）「setMembers」の定義には「msg.sender」が入っているため、実行ユーザーを気にする必要がある。（後述しますが、「onlyOwner」修飾子がついている「setCoin」も実行ユーザーを気にする必要があります）
（C）「coin」はただのaddress型だけど、「members」はmapping型なので“配列”になっている。（「mapping」は「連想“配列”」であることを忘れていて、当初スカラー量のイメージで読んでいたせいで理解がなかなか進みませんでしたｗ）
「会員ごとに会員情報を持つ」ことを、
（B）→会員アドレスと会員情報（＝Members）の紐づけることで、会員が会員情報を持つこと
（C)→会員アドレスをインデックスとする配列（members）によって、会員ごとに情報を持つこと
という風に実装しています。
ここまでで、ユーザーBの「Members」コントラクトが準備できました。
前編はこのへんで、後編へ続きます。
Keyword : ブロックチェーン暗号資産仮想通貨イーサリアムEthereumSolidityBrowser-Solidityblockcahin
ブロックチェーン関連の記事紹介まとめ（2019年3月：#60-90） « ホーム
» 翻訳： zk-SNARKs 入門 （その1） （原題：Introduction to zk-SNARKs (Part 1)）
