「仮想通貨交換業等に関する研究会」（第５回）の資料を見てみる
どうも、ぺろりんです。
最近はあまり仮想通貨の話題を取り上げていなかった気がするので、今回は「仮想通貨交換業等に関する研究会（第５回）」の資料を見て感想を書いていこうかと思います。
「仮想通貨交換業等に関する研究会」とは？
そもそもこれって何？？というのをまずはおさらいしておきましょう。
この研究会は、金融庁がとりまとめをしている、「仮想通貨まわりのいろんな問題について考えましょう」という内容の有識者の集まりです。
仮想通貨というものが広まりつつあるものの、アングラな資金に使われたり制度が整っていなかったりしていた中、コインチェック社で大規模な流出事件が発生した、というのが発足の背景にあります。
こういう状況を受けた行政としての具体的な対応の1つが、この研究会というわけですね。
傍聴もできるようなので、ご興味ある方は行ってみるのもおもしろいかもしれません。
（参考）
・仮想通貨交換業等に関する研究会（金融庁）
・「仮想通貨交換業等に関する研究会」の設置について（金融庁）
「仮想通貨交換業等に関する研究会」（第５回）の資料を見てみる
というわけで、資料をネチネチ読んでみようかと思いますｗ
以下では、参考に挙げた金融庁のサイトに載っている資料をサラッと読んでみて、大事だと思ったところとか感想とかを書いていきます。
資料を見ていると、これだけの内容を2時間で話すの大変だなというのが一番初めの感想ですｗ
（参考）
・「仮想通貨交換業等に関する研究会」（第５回）議事次第（金融庁）
資料２
メンバー名簿は飛ばすことにして、資料２から見ていきましょう。
この資料は問題提起みたいな内容です。
この資料の印象としては、
・良い面も考えようとしている
・色んな観点から考えている
という感じです。
当たり前ではありますが、「行政はわかってない」という意見をよく見かける中、「やっぱりちゃんと考えている」と思える内容なのは良かったです。
この資料によると、「仮想通貨はリスクの方が大きいが、ブロックチェーンはプラスの面の方が大きいという評価が一般的」だそうです。
少なくともここでは、ブロックチェーン自体はポジティブなとらえ方をされているようです。
この資料を通して、やはり仮想通貨まわりの規制はすすんでいきそうな印象を受けます。
規制関連でいくつか抜粋すると、以下のようなことが書いてありました。
「仮想通貨は、「注意を要するもの」としてグローバルにも規制を強めていこうとしており、我が国においても、業界の育成というよりは、規制に軸足を置いて考える必要があるのではないか」
「参入規制が少し緩いのではないか。例えば、自己資本も低い額になっているが、一旦流出事故が起きれば、数十億、数百億単位で喪失が出ることもあり得るので、自己資本に限らないが、参入規制についてもう一回考えてもよいのではないか」
「仮想通貨のリスクを抑え、適切な方向への展開を促す観点から、参入規制を含めて、市場や規制によるコントロールを強めていく必要があるのではないか」
「マネーロンダリングの疑いや匿名性のある仮想通貨が出てきている中で、法定通貨でも厳しいマネーロンダリングの規制がある以上、同じように考えていく必要があるのではないか」
規制の方向性としては以下のようなものがあるように思います。
（１）仮想通貨関連事業への参入規制
（２）取引方法・内容の規制
（３）扱う仮想通貨の規制
（４）登録業者への運営上の規制
（５）ICOの規制
規制関連で個人的には、Zcashのゼロ知識証明なんかはせっかく画期的でおもしろい技術なのにもったいないなぁ、という思いがあります。
ICOやトークンに関してもいろいろ書いています。
トークン関連の記述もいくつか抜粋してみるとこんな感じです。
「トークンを使おうが、金銭や証券を使おうが、経済的な機能やリスクが同じであれば、同じような規制を適用していくことが基本的にあるべき姿と思われるので、新しい法制のあり方を考える際にも、ICOであるからといって過剰反応するのではなく、機能とリスクを見極めていくことが重要ではないか」
「トークン自体は価値がないものであるにもかかわらず、セカンダリーマーケットで、高額で売れてしまう現状を放置していくことは、問題をさらに深刻・複雑なものにしかねず、投資家保護の問題をより大きく引き起こしかねないのではないか」
「トークンの流通市場を何らかの規制によって合理的なものにできるかどうかが重要ではないかICOについては、少なくとも一般の投資家への販売は禁止すべきではないか」
これも意外と（少なくともこの段階においては）、「規制を強行する」ような印象は受けませんでした。
また、規制することにより有望なベンチャー企業も海外に流出する可能性があることには、行政としても危機感を感じていることがこの資料からうかがえました。
資料３
資料３は、仮想通貨交換業者まわりが現状がどんな風になっているかをまとめた資料です。
ここでもいくつか記述を抜粋してみます。
「主にみなし業者において、昨年秋以降、取引が急拡大し、ビジネス展開を拡大する中、内部管理態勢の整備が追いつかず」
「取り扱う暗号資産（仮想通貨）のリスク評価をしていない」
「法令等のミニマムスタンダードにも達していない内部管理」
「内部監査計画を策定しているが、リスク評価に基づくものとなっていない」
この資料にも明確に書いてあるように、現状はコーポレート・ガバナンスというものがうまく機能していないようです。
金融商品を扱う業者なので、リスク評価・管理なんかは特に重要ですね。
また、「セキュリティ人材が不足している」というのもなかなか残念な状況ですよね。。
このあたりのリスク評価・管理、セキュリティ周りをうまいことやれる人は結構高給で雇ってもらえるのではｗ
この資料で個人的に意外だったのが、「上場企業を含む様々な企業が新規参入の意向（１６０社超）」という記述です。
最近の仮想通貨の相場は昨年末に比べるとだいぶ下がってしまいましたが、今後まだ伸びると考えているということでしょうか？
いやむしろ、「仮想通貨の“交換”は今後必要になってくるので、プラットフォーム事業は将来性がある」というような考えなのかな……？
いずれにしろ、仮想通貨自体は今後「使われるようになる」と考えている企業が100以上あるように見えます。
もしくは自分たちで発行して使うために、交換業が必要なのかも知れませんね。
資料４
資料４は、日本仮想通貨交換業協会による自主規制の概要説明です。
基本的には利用者保護に重点がおかれているようです。
広告の規制も結構いろいろ書いています。
「移転記録の追跡ができない又は著しく困難な仮想通貨（いわゆる匿名仮想通貨）については、AML／CFT[注]や適切な監査の実施の確保の観点から問題があるため、これら問題が解決されない限り禁止」と書いているということは、逆に、「ここで挙げられた問題が解決されたら解禁される可能性がある」とも読めますね。
この意味なら、管理方法に関してブレイクスルーが起きれば、Zcashみたいな匿名性の高い仮想通貨も復権するのでは。
あと、この資料で証拠金倍率の協会指定水準というのが「４倍（証拠金率25％）」とされています。
個人的にはこれだけ値動きが激しいので、仮想通貨にレバレッジをかける必要性を感じないですが……ｗ
最後の方にある参考資料の「仮想通貨の意義・必要性」というのがなかなか勉強になります。
事例を見ると、以下の内容が読み取れてタメになりました。
・細分化しての共有やシェア・レンタルと相性が良い。
・独自通貨の発行はまだまだありそう。
・著作権がらみの利益分配に便利。
・スマートコントラクトで、契約の履行と支払が同時に行われることが可能になる。
・主にゲーム系がDapps（分散アプリケーション）として作られている。
仮想通貨全体の時価総額が2018年8月31日時点で「225,466,537,354USD（約２５兆円）」というのは無視できない規模なんでしょうね。
この無視できない市場を健全に発展させるためのインフラとして、仮想通貨交換業者の必要性が最後に書いてあります。
まとめ
「仮想通貨交換業等に関する研究会（第５回）」の資料を見て大事そうなところとか感想とかを書いてみました。
全体を通しての印象としては、以下の内容です。
・ちゃんと色んな観点から議論している。
・基本的には仮想通貨まわりは規制に向かっている。
・現状「ブロックチェーン技術」はポジティブに考えられていて、仮想通貨市場も健全な「発展」を望まれている。
個人的に感じたのは、仮想通貨に関しても管理的な問題が払拭されてくれば、規制も多少は緩まるような余地はあるんじゃないかなということです。
現状まだまだ一般参加者にとっては投機対象でしかない感じがする仮想通貨ですが、健全に発展してより社会が便利になると嬉しいところです。
[注] AML／CFT…マネーローンダリング／テロ資金供与対策（Anti-Money Laundering ／ Counter Financing of Terrorism）。
（参考）
・AML／CFTにおけるリスクベースアプローチ（PwC）
最近はあまり仮想通貨の話題を取り上げていなかった気がするので、今回は「仮想通貨交換業等に関する研究会（第５回）」の資料を見て感想を書いていこうかと思います。
「仮想通貨交換業等に関する研究会」とは？
そもそもこれって何？？というのをまずはおさらいしておきましょう。
この研究会は、金融庁がとりまとめをしている、「仮想通貨まわりのいろんな問題について考えましょう」という内容の有識者の集まりです。
仮想通貨というものが広まりつつあるものの、アングラな資金に使われたり制度が整っていなかったりしていた中、コインチェック社で大規模な流出事件が発生した、というのが発足の背景にあります。
こういう状況を受けた行政としての具体的な対応の1つが、この研究会というわけですね。
傍聴もできるようなので、ご興味ある方は行ってみるのもおもしろいかもしれません。
（参考）
・仮想通貨交換業等に関する研究会（金融庁）
・「仮想通貨交換業等に関する研究会」の設置について（金融庁）
「仮想通貨交換業等に関する研究会」（第５回）の資料を見てみる
というわけで、資料をネチネチ読んでみようかと思いますｗ
以下では、参考に挙げた金融庁のサイトに載っている資料をサラッと読んでみて、大事だと思ったところとか感想とかを書いていきます。
資料を見ていると、これだけの内容を2時間で話すの大変だなというのが一番初めの感想ですｗ
（参考）
・「仮想通貨交換業等に関する研究会」（第５回）議事次第（金融庁）
資料２
メンバー名簿は飛ばすことにして、資料２から見ていきましょう。
この資料は問題提起みたいな内容です。
この資料の印象としては、
・良い面も考えようとしている
・色んな観点から考えている
という感じです。
当たり前ではありますが、「行政はわかってない」という意見をよく見かける中、「やっぱりちゃんと考えている」と思える内容なのは良かったです。
この資料によると、「仮想通貨はリスクの方が大きいが、ブロックチェーンはプラスの面の方が大きいという評価が一般的」だそうです。
少なくともここでは、ブロックチェーン自体はポジティブなとらえ方をされているようです。
この資料を通して、やはり仮想通貨まわりの規制はすすんでいきそうな印象を受けます。
規制関連でいくつか抜粋すると、以下のようなことが書いてありました。
「仮想通貨は、「注意を要するもの」としてグローバルにも規制を強めていこうとしており、我が国においても、業界の育成というよりは、規制に軸足を置いて考える必要があるのではないか」
「参入規制が少し緩いのではないか。例えば、自己資本も低い額になっているが、一旦流出事故が起きれば、数十億、数百億単位で喪失が出ることもあり得るので、自己資本に限らないが、参入規制についてもう一回考えてもよいのではないか」
「仮想通貨のリスクを抑え、適切な方向への展開を促す観点から、参入規制を含めて、市場や規制によるコントロールを強めていく必要があるのではないか」
「マネーロンダリングの疑いや匿名性のある仮想通貨が出てきている中で、法定通貨でも厳しいマネーロンダリングの規制がある以上、同じように考えていく必要があるのではないか」
規制の方向性としては以下のようなものがあるように思います。
（１）仮想通貨関連事業への参入規制
（２）取引方法・内容の規制
（３）扱う仮想通貨の規制
（４）登録業者への運営上の規制
（５）ICOの規制
規制関連で個人的には、Zcashのゼロ知識証明なんかはせっかく画期的でおもしろい技術なのにもったいないなぁ、という思いがあります。
ICOやトークンに関してもいろいろ書いています。
トークン関連の記述もいくつか抜粋してみるとこんな感じです。
「トークンを使おうが、金銭や証券を使おうが、経済的な機能やリスクが同じであれば、同じような規制を適用していくことが基本的にあるべき姿と思われるので、新しい法制のあり方を考える際にも、ICOであるからといって過剰反応するのではなく、機能とリスクを見極めていくことが重要ではないか」
「トークン自体は価値がないものであるにもかかわらず、セカンダリーマーケットで、高額で売れてしまう現状を放置していくことは、問題をさらに深刻・複雑なものにしかねず、投資家保護の問題をより大きく引き起こしかねないのではないか」
「トークンの流通市場を何らかの規制によって合理的なものにできるかどうかが重要ではないかICOについては、少なくとも一般の投資家への販売は禁止すべきではないか」
これも意外と（少なくともこの段階においては）、「規制を強行する」ような印象は受けませんでした。
また、規制することにより有望なベンチャー企業も海外に流出する可能性があることには、行政としても危機感を感じていることがこの資料からうかがえました。
資料３
資料３は、仮想通貨交換業者まわりが現状がどんな風になっているかをまとめた資料です。
ここでもいくつか記述を抜粋してみます。
「主にみなし業者において、昨年秋以降、取引が急拡大し、ビジネス展開を拡大する中、内部管理態勢の整備が追いつかず」
「取り扱う暗号資産（仮想通貨）のリスク評価をしていない」
「法令等のミニマムスタンダードにも達していない内部管理」
「内部監査計画を策定しているが、リスク評価に基づくものとなっていない」
この資料にも明確に書いてあるように、現状はコーポレート・ガバナンスというものがうまく機能していないようです。
金融商品を扱う業者なので、リスク評価・管理なんかは特に重要ですね。
また、「セキュリティ人材が不足している」というのもなかなか残念な状況ですよね。。
このあたりのリスク評価・管理、セキュリティ周りをうまいことやれる人は結構高給で雇ってもらえるのではｗ
この資料で個人的に意外だったのが、「上場企業を含む様々な企業が新規参入の意向（１６０社超）」という記述です。
最近の仮想通貨の相場は昨年末に比べるとだいぶ下がってしまいましたが、今後まだ伸びると考えているということでしょうか？
いやむしろ、「仮想通貨の“交換”は今後必要になってくるので、プラットフォーム事業は将来性がある」というような考えなのかな……？
いずれにしろ、仮想通貨自体は今後「使われるようになる」と考えている企業が100以上あるように見えます。
もしくは自分たちで発行して使うために、交換業が必要なのかも知れませんね。
資料４
資料４は、日本仮想通貨交換業協会による自主規制の概要説明です。
基本的には利用者保護に重点がおかれているようです。
広告の規制も結構いろいろ書いています。
「移転記録の追跡ができない又は著しく困難な仮想通貨（いわゆる匿名仮想通貨）については、AML／CFT[注]や適切な監査の実施の確保の観点から問題があるため、これら問題が解決されない限り禁止」と書いているということは、逆に、「ここで挙げられた問題が解決されたら解禁される可能性がある」とも読めますね。
この意味なら、管理方法に関してブレイクスルーが起きれば、Zcashみたいな匿名性の高い仮想通貨も復権するのでは。
あと、この資料で証拠金倍率の協会指定水準というのが「４倍（証拠金率25％）」とされています。
個人的にはこれだけ値動きが激しいので、仮想通貨にレバレッジをかける必要性を感じないですが……ｗ
最後の方にある参考資料の「仮想通貨の意義・必要性」というのがなかなか勉強になります。
事例を見ると、以下の内容が読み取れてタメになりました。
・細分化しての共有やシェア・レンタルと相性が良い。
・独自通貨の発行はまだまだありそう。
・著作権がらみの利益分配に便利。
・スマートコントラクトで、契約の履行と支払が同時に行われることが可能になる。
・主にゲーム系がDapps（分散アプリケーション）として作られている。
仮想通貨全体の時価総額が2018年8月31日時点で「225,466,537,354USD（約２５兆円）」というのは無視できない規模なんでしょうね。
この無視できない市場を健全に発展させるためのインフラとして、仮想通貨交換業者の必要性が最後に書いてあります。
まとめ
「仮想通貨交換業等に関する研究会（第５回）」の資料を見て大事そうなところとか感想とかを書いてみました。
全体を通しての印象としては、以下の内容です。
・ちゃんと色んな観点から議論している。
・基本的には仮想通貨まわりは規制に向かっている。
・現状「ブロックチェーン技術」はポジティブに考えられていて、仮想通貨市場も健全な「発展」を望まれている。
個人的に感じたのは、仮想通貨に関しても管理的な問題が払拭されてくれば、規制も多少は緩まるような余地はあるんじゃないかなということです。
現状まだまだ一般参加者にとっては投機対象でしかない感じがする仮想通貨ですが、健全に発展してより社会が便利になると嬉しいところです。
[注] AML／CFT…マネーローンダリング／テロ資金供与対策（Anti-Money Laundering ／ Counter Financing of Terrorism）。
（参考）
・AML／CFTにおけるリスクベースアプローチ（PwC）
ブラックリスト機能付き仮想通貨コントラクトをデプロイしてみる
どうも、ぺろりんです。
今回も「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」で勉強していきます。
前回は最低限みたいな機能が付いた仮想通貨コントラクトをデプロイして遊んでみましたが、次の話題は「ブラックリスト」です。
登録されると取引禁止になる「ブラックリスト」機能付きの仮想通貨コントラクトをデプロイして、実際にユーザーをブラックリストに追加したり、リストからはずしたりしてみて、挙動を確認してみます。
引き続きJavaScript VMを使って、ブラウザ上で完結した環境で動作確認していきます。
ブラックリストの仕組み
コード自体は「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」を参照していただきたいのですが、基本的な仕組みは簡単なものです。
「blackList」という名前の変数をフラグとして使ってif文でフラグをチェックし、そのユーザーに「ブラックリスト」フラグが立っていたら取引がなかったことになる、という内容です。
今回のコードは、前回のコードにこの変数「blackList」を使ったフラグチェック機能が付いたものです。
「ブラックリスト」機能付きの仮想通貨コントラクトをコンパイルしてみる
さて、教科書通りのコードを入れてコンパイルしてみると、案の定めっちゃ怒られますｗ
数は結構ありますが、内容を分類すると前回対処した4通りの警告と同じものでした。
というわけで、前回の知識をそのまま使えばコードを修正できます。
やることをザクっと書くと以下の4つですが、詳しくは前回の記事をご覧ください。
・「public」をつける
・「emit」をつける
・「throw」を「revert()」に置き換える
・コントラクタを「constructor」にする
上記の4種類をやってみると、「Static Analysis raised 2 warning(s) that requires your attention. Click here to show the warning(s).」というのは残るものの、いっぱい出ていた警告は綺麗になりました＼(^o^)／
このメッセージは害はなさそうなので先に進みます。
「ブラックリスト」機能付きの仮想通貨コントラクトをデプロイしてみる
EnvironmentでJavaScript VMを選び、Deployのプルダウン的なところを開いて仮想通貨の総量、名前、単位、小数点以下の桁数をそれぞれ入力してtransactします。
これでデプロイできました。
デプロイした「ブラックリスト」機能付きの仮想通貨コントラクトで遊んでみる
ここでは、以下のアドレスをユーザーA、ユーザーBと呼ぶことにします。
ユーザーA：0xca35b7d915458ef540ade6068dfe2f44e8fa733c
ユーザーB：0x14723a09acff6d2a60dcdf7aa4aff308fddc160c
ユーザーAは、この仮想通貨コントラクトをデプロイしたときのユーザーです。
なのでこのコード上、ユーザーAが「owner」となり、ブラックリストにユーザーアカウントを追加/削除できる権限を持ちます。
残高確認
まずは、ユーザーA、Bそれぞれの残高確認をしてみます。
これはbalanceOfというので確認できます。
まだ送金していないので、ユーザーAの残高は、全OreOreCoinである10000[oc]です。
そして、送金していない状態なので、当然ユーザーBは残高0[oc]です。
送金
このままだとあまり面白くないので、この世界にOreOreCoinをすこし流通させてみましょう。
というわけで、すべてのOreOreCoinを持っているユーザーAから、ユーザーBへ2000[oc]を送金してみます。
まずはAccount欄をユーザーAにして、送金先アドレスと送金する量を入力しつつtransferを実行します。
これでユーザーAからユーザーBへ2000[oc]送金できました。
残高を確認してみましょう。
まずはユーザーAを見るとbalanceOfのところに8000とあります。
次にユーザーBは、balanceOfのところに2000とあります。
ユーザーBをブラックリストに登録してみる
入力欄にユーザーBのアドレスを入れて（言い忘れましたが、アドレスは「"（ダブルクォーテーション）」で囲む必要があります）、blacklistingを実行してみました。
これでユーザーBのアドレスがブラックリストに登録され、ユーザーBとOreOreCoinのやり取りができなくなっているはずです。
ユーザーBをブラックリストに登録した状態でユーザーAからユーザーBへ送金してみる
ユーザーBをブラックリストに登録した状態で、ユーザーAからユーザーBへ2000[oc]送金してみます。
「logs」欄を見ると、RejectedPaymentToBlacklistedAddrという、ブラックリストに登録されたユーザーに送金した際に呼び出されるイベントが呼び出されていました。
実際、残高確認をしてみると、以下の通り2000[oc]の移動がなかったことがわかります。
ユーザーA。
ユーザーB。
逆に、ユーザーBからユーザーAへ1000[oc]送金してみる、というのも同様にできません。
ユーザーBをブラックリストからはずしてみる
ブラックリストからはずすには、ユーザーBのアドレスを入力してdeletefromblacklistを実行します。
ユーザーBをブラックリストからはずしてから送金してみる
ユーザーAからユーザーBへ1000[oc]送ってみました。
うまくいくと、eventとしてTransferが呼び出されます（、というコードになっています）。
ちゃんと送金できたようです。
逆に、ユーザーBからユーザーAへ2000[oc]送ってみます。
残高も想定通りの挙動になっていることがわかります。
その他の挙動確認
個人的に挙動が気になったところも確認してみます。
変数blackListにユーザーBのアカウントを入れるとどうなるか？
blackListは、これの値によってユーザーがブラックリストに入っているかどうかを管理する変数です。
ブラックリストに登録するときは、引数にされたアドレスのblackList値を1に、ブラックリストからはずすときには-1にするような動作をします。
で、恐らくアドレスを入れてblackListボタンを押すと、引数にしたアドレスのblackList値を返すと思われます。
実際、ユーザーBのアドレスを入れてblackListボタンを押すと、先ほどブラックリストからはずしたときに設定された-1が返ってきました。
特にブラックリストの追加削除していないユーザーAについては、blackList値は0でした。
何もしていないユーザーのblackList値が0なら、個人的にはブラックリストからはずすときにはblackList値は0で良いような気もするのですが、ブラックリストに登録されたという履歴を残すためなんでしょうか？
ユーザーAをブラックリストに登録してみる
これは普通にできました。
そして、ちゃんとブラックリスト登録されたユーザーAからユーザーBへ送金しようとしても、送金されませんでした。
オーナーがブラックリストに登録されてはダメかと思いましたが、考えてみれば、オーナーはブラックリストの追加/削除をするだけで、ブラックリストに登録されていようがブラックリストの追加/削除はできるので、別に変なことにはならないんですねｗ
まとめ
今回は、「ブラックリスト」機能付き仮想通貨コントラクトをデプロイして、その動きを確認してみました。
コンパイル時の警告に関しては前回の知識だけで乗り切れたので、スムーズにデプロイできました。
デプロイ後の動きとしても、教科書の想定通りに動いていることが確認できました！
次回はキャッシュバック機能をつけて遊んでみます。
というわけで、今回はこのへんで。
今回も「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」で勉強していきます。
前回は最低限みたいな機能が付いた仮想通貨コントラクトをデプロイして遊んでみましたが、次の話題は「ブラックリスト」です。
登録されると取引禁止になる「ブラックリスト」機能付きの仮想通貨コントラクトをデプロイして、実際にユーザーをブラックリストに追加したり、リストからはずしたりしてみて、挙動を確認してみます。
引き続きJavaScript VMを使って、ブラウザ上で完結した環境で動作確認していきます。
ブラックリストの仕組み
コード自体は「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」を参照していただきたいのですが、基本的な仕組みは簡単なものです。
「blackList」という名前の変数をフラグとして使ってif文でフラグをチェックし、そのユーザーに「ブラックリスト」フラグが立っていたら取引がなかったことになる、という内容です。
今回のコードは、前回のコードにこの変数「blackList」を使ったフラグチェック機能が付いたものです。
「ブラックリスト」機能付きの仮想通貨コントラクトをコンパイルしてみる
さて、教科書通りのコードを入れてコンパイルしてみると、案の定めっちゃ怒られますｗ
数は結構ありますが、内容を分類すると前回対処した4通りの警告と同じものでした。
というわけで、前回の知識をそのまま使えばコードを修正できます。
やることをザクっと書くと以下の4つですが、詳しくは前回の記事をご覧ください。
・「public」をつける
・「emit」をつける
・「throw」を「revert()」に置き換える
・コントラクタを「constructor」にする
上記の4種類をやってみると、「Static Analysis raised 2 warning(s) that requires your attention. Click here to show the warning(s).」というのは残るものの、いっぱい出ていた警告は綺麗になりました＼(^o^)／
このメッセージは害はなさそうなので先に進みます。
「ブラックリスト」機能付きの仮想通貨コントラクトをデプロイしてみる
EnvironmentでJavaScript VMを選び、Deployのプルダウン的なところを開いて仮想通貨の総量、名前、単位、小数点以下の桁数をそれぞれ入力してtransactします。
これでデプロイできました。
デプロイした「ブラックリスト」機能付きの仮想通貨コントラクトで遊んでみる
ここでは、以下のアドレスをユーザーA、ユーザーBと呼ぶことにします。
ユーザーA：0xca35b7d915458ef540ade6068dfe2f44e8fa733c
ユーザーB：0x14723a09acff6d2a60dcdf7aa4aff308fddc160c
ユーザーAは、この仮想通貨コントラクトをデプロイしたときのユーザーです。
なのでこのコード上、ユーザーAが「owner」となり、ブラックリストにユーザーアカウントを追加/削除できる権限を持ちます。
残高確認
まずは、ユーザーA、Bそれぞれの残高確認をしてみます。
これはbalanceOfというので確認できます。
まだ送金していないので、ユーザーAの残高は、全OreOreCoinである10000[oc]です。
そして、送金していない状態なので、当然ユーザーBは残高0[oc]です。
送金
このままだとあまり面白くないので、この世界にOreOreCoinをすこし流通させてみましょう。
というわけで、すべてのOreOreCoinを持っているユーザーAから、ユーザーBへ2000[oc]を送金してみます。
まずはAccount欄をユーザーAにして、送金先アドレスと送金する量を入力しつつtransferを実行します。
これでユーザーAからユーザーBへ2000[oc]送金できました。
残高を確認してみましょう。
まずはユーザーAを見るとbalanceOfのところに8000とあります。
次にユーザーBは、balanceOfのところに2000とあります。
ユーザーBをブラックリストに登録してみる
入力欄にユーザーBのアドレスを入れて（言い忘れましたが、アドレスは「"（ダブルクォーテーション）」で囲む必要があります）、blacklistingを実行してみました。
これでユーザーBのアドレスがブラックリストに登録され、ユーザーBとOreOreCoinのやり取りができなくなっているはずです。
ユーザーBをブラックリストに登録した状態でユーザーAからユーザーBへ送金してみる
ユーザーBをブラックリストに登録した状態で、ユーザーAからユーザーBへ2000[oc]送金してみます。
「logs」欄を見ると、RejectedPaymentToBlacklistedAddrという、ブラックリストに登録されたユーザーに送金した際に呼び出されるイベントが呼び出されていました。
実際、残高確認をしてみると、以下の通り2000[oc]の移動がなかったことがわかります。
ユーザーA。
ユーザーB。
逆に、ユーザーBからユーザーAへ1000[oc]送金してみる、というのも同様にできません。
ユーザーBをブラックリストからはずしてみる
ブラックリストからはずすには、ユーザーBのアドレスを入力してdeletefromblacklistを実行します。
ユーザーBをブラックリストからはずしてから送金してみる
ユーザーAからユーザーBへ1000[oc]送ってみました。
うまくいくと、eventとしてTransferが呼び出されます（、というコードになっています）。
ちゃんと送金できたようです。
逆に、ユーザーBからユーザーAへ2000[oc]送ってみます。
残高も想定通りの挙動になっていることがわかります。
その他の挙動確認
個人的に挙動が気になったところも確認してみます。
変数blackListにユーザーBのアカウントを入れるとどうなるか？
blackListは、これの値によってユーザーがブラックリストに入っているかどうかを管理する変数です。
ブラックリストに登録するときは、引数にされたアドレスのblackList値を1に、ブラックリストからはずすときには-1にするような動作をします。
で、恐らくアドレスを入れてblackListボタンを押すと、引数にしたアドレスのblackList値を返すと思われます。
実際、ユーザーBのアドレスを入れてblackListボタンを押すと、先ほどブラックリストからはずしたときに設定された-1が返ってきました。
特にブラックリストの追加削除していないユーザーAについては、blackList値は0でした。
何もしていないユーザーのblackList値が0なら、個人的にはブラックリストからはずすときにはblackList値は0で良いような気もするのですが、ブラックリストに登録されたという履歴を残すためなんでしょうか？
ユーザーAをブラックリストに登録してみる
これは普通にできました。
そして、ちゃんとブラックリスト登録されたユーザーAからユーザーBへ送金しようとしても、送金されませんでした。
オーナーがブラックリストに登録されてはダメかと思いましたが、考えてみれば、オーナーはブラックリストの追加/削除をするだけで、ブラックリストに登録されていようがブラックリストの追加/削除はできるので、別に変なことにはならないんですねｗ
まとめ
今回は、「ブラックリスト」機能付き仮想通貨コントラクトをデプロイして、その動きを確認してみました。
コンパイル時の警告に関しては前回の知識だけで乗り切れたので、スムーズにデプロイできました。
デプロイ後の動きとしても、教科書の想定通りに動いていることが確認できました！
次回はキャッシュバック機能をつけて遊んでみます。
というわけで、今回はこのへんで。
Keyword : ブロックチェーンBrowser-SoliditySolidityEthereumイーサリアム仮想通貨
仮想通貨コントラクトを作成してみる
どうも、ぺろりんです。
「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」のつづきです。
このシリーズでは、前回はSolidityの仕様についてまとめました。
この本もようやく実践編にきました！
今回は、教科書の実践編で基本的な仮想通貨コントラクトを作成するところをBrowser-Solidity上でやっていきます。
ここではこれまで通り、JavaScript VMで実行するのでオンライン上で完結した環境です。
仮想通貨コントラクトのデプロイ
教科書通りのコードで「OreOreCoin」なるものをデプロイしていきます。
が、そのままのコードだとこんな感じでコンパイル時にエラーが出ます。
すべて警告で、内容的には以下の4種類です。（キャプチャの順番とは前後していますが、あとの説明用にこの順で載せています）
これら4種類の警告について、それぞれ対処してみましょう。
Warning: No visibility specified. Defaulting to "public".
「public」のところは以前調べたのと同じで、以下のように「public」を入れると消えました。
Warning: Defining constructors as functions with the same name as the contract is deprecated. Use "constructor(...) { ... }" instead.
これも以前調べたのと同じです。
以下のように、コンストラクタのところで「function OreOreCoin(…」としていたのを「constructor(…」に直すと上手くいきました。
Warning: "throw" is deprecated in favour of "revert()", "require()" and "assert()".
「throw」ではなく、「revert()」、「require()」、「assert()」の使用が推奨されているみたいです。
たとえば「require()」なら、どうやら
if(＜条件＞) throw
と
require(＜throwのときに各条件の反対＞)
が同等の意味になるようです。（「反対」の意味は、おそらく補集合と考えると良さそう）
「throw」を一番簡単に書き換えるとすると、「throw」を「revert()」に置き換えれば上手くいきそうです。
実際、
を
に書き換えて再度コンパイルしてみると、この部分のWarningが消えました。
これに関しては、参考に挙げたSolidityのassertとrequireとrevertの違い（アルゴリズムとかオーダーとか）にとても分かりやすくまとめられていました。
最近のバージョンのSolidityでは「throw」が「revert()」に自動で変換されるようです。
参考サイトにあった内容をさらに短くまとめておくと、以下の内容のようです。
・revert(＜メッセージ＞) → ここでコントラクトは停止して実行前に戻す。残りのガスは返却。条件は指定できない。
・require(＜条件＞) → ここでコントラクトは停止して実行前に戻す。残りのガスは返却。条件を指定する。
・assert(＜条件＞) → ここでコントラクトは停止して実行前に戻す。残りのガスも消費。条件を指定する。
（参考）
・ERC20 Token Standard Interface を使った Smart Contractの実装について（Qitta）
・Error creating contracts on Ethereum wallet（StackeEchange）
・Solidityのassertとrequireとrevertの違い（アルゴリズムとかオーダーとか）
・Error handling: Assert, Require, Revert and Exceptions（Solidity）
Warning: Invoking events without "emit" prefix is deprecated.
さしあたり、解決策としては
の冒頭に「emit」を付けて
とすれば、この部分のWarningが消えました。
これでようやく怒られないコードになりました＼(^o^)／
（追記：2018/9/3）--
参考に挙げた「‘emit’ keyword in Solidity（Medium）」によると、これはv0.4.21以降で推奨される書式で、イベントの呼び出しを明示するためのようです。
明示する理由の1つがDAO事件とありますが、いまいちピンとこない。。
ちょっと調べた感じではこの辺の関連を見つけられなかったので、分かる方ぜひ教えてください。
--（追記ここまで）
（参考）
・‘emit’ keyword in Solidity（Medium）
・Invoking events without “emit” prefix is deprecated in Transfer(msg.sender, _to, _value);（StackExchenge）
・【備忘録】【Solidity】【Truffle】エラー：Warning: Invoking events without "emit" prefix is deprecated.（katonobo’s blog）
・Warning: Invoking events without "emit" prefix is deprecated #8（GitHub）
OreOreCoinをデプロイしてみる
ようやくコンパイルが（ほぼ）綺麗に通ったので、この状態でデプロイしてみます。
（実はまだメッセージは残るんですが、無害そうなのでとりあえず先に進みます。）
Deployのところを開いて、テキスト通り値を入力しつつtransactします。
うまいことデプロイできました。
ボタンを押してコンストラクタの値を取得してみると、デプロイ時に入力した内容が反映されていることが確認できます。
balanceOfでユーザーアカウントごとのOreOreCoin残高も確認してみましょう。
まずはデプロイしたユーザーアカウントです。
この「…a733c」（以下、「ユーザーA」と呼ぶことにします）というアカウントアドレスを、「"」（ダブルクォーテーション）で囲んでbalanceOfのところに入力してbalanceOfボタンを押します。ちゃんとユーザーAが 10000 [oc]持っていることがわかります。
次に、別の「…c160c」（以下、「ユーザーB」と呼ぶことにします）というユーザーアカウントについて、残高確認をしてみましょう。
OreOreCoinの送金はまだしていないので、ユーザーA以外のアカウントは残高 0 [oc]のはずです。
先ほどと同様の手順で、今度はユーザーBのアカウントアドレスでbalanceOfしてみると、たしかに残高が 0 [oc]であることが確認できます。
OreOreCoinを送金してみる
デプロイがうまくいって、現状の値確認もできたので、今度は送金してみましょう。
ユーザーAからユーザーBへの送金を試みてみます。
失敗例
transferのところに、送り先であるユーザーBアドレスと、送りたい値（ 2000 [oc]）を入力してtransactします。
ここで、送り主のアドレスはグローバル変数msg.senderにより、現在の送信主アドレスを自動取得するため、特に入力はしません。
で、やってみましたが、うまくいかない……
画像にあるエラーメッセージを見てみると、「from」のところがなぜかユーザーBになっている。。
どうやら原因は、先ほどbalanceOfしたときの流れでやっていたので、このときに取得したユーザーBのmsg.senderの値が残っていたか、もしくはBrowser-SolidityのAccount欄アカウントを間違ってユーザーBにしたままtransferやってたせいでtransferのときに取得するmsg.senderの値がユーザーBになってしまったかで、残高 0 [c]のユーザーBから送金しようとしていました。
たぶん後者の、Account欄の問題かな……？
いずれにしろ、msg.senderでユーザーBのアドレスを取得してtransferしようとしたことが原因でした。
そして、まだOreOreCoinを持っていないユーザーBからの送金はできないと、エラーになりました。
成功例
原因がわかったので、Browser-SolidityのAccount欄をユーザーAにしつつ、念のためもう一度ユーザーAについてbalanceOfを実行してから、あらためてユーザーBへ 2000 [oc]送金してみたら、今度はうまく送金できました。
ユーザーA、ユーザーBそれぞれについて、送金後の残高をbalanceOfで確認してみます。
まずはユーザーA。
つづいてユーザーB。
ユーザーAからユーザーBへ、2000 [oc]がちゃんと送金できたことが確認できました。
まとめ
今回は、「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」の実践編にあるOreOreCoinという、簡単な仮想通貨のサンプルコードをデプロイして、状態確認と送金をやってみました。
テキストのサンプルコードをそのままコンパイルすると4種類の警告が出たので、それらの対処もしてみました。
送金はいい感じに教育的な内容で（笑）失敗しましたが、エラー内容をもとに対応してうまく解決できました。
警告とかエラーの対処が、やっぱり勉強になるなぁとあらためて実感しました。
ではでは今回はこのへんで。
「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」のつづきです。
このシリーズでは、前回はSolidityの仕様についてまとめました。
この本もようやく実践編にきました！
今回は、教科書の実践編で基本的な仮想通貨コントラクトを作成するところをBrowser-Solidity上でやっていきます。
ここではこれまで通り、JavaScript VMで実行するのでオンライン上で完結した環境です。
仮想通貨コントラクトのデプロイ
教科書通りのコードで「OreOreCoin」なるものをデプロイしていきます。
が、そのままのコードだとこんな感じでコンパイル時にエラーが出ます。
すべて警告で、内容的には以下の4種類です。（キャプチャの順番とは前後していますが、あとの説明用にこの順で載せています）
Warning: No visibility specified. Defaulting to "public".
Warning: Defining constructors as functions with the same name as the contract is deprecated. Use "constructor(...) { ... }" instead.Warning: "throw" is deprecated in favour of "revert()", "require()" and "assert()".
Warning: Invoking events without "emit" prefix is deprecated.
これら4種類の警告について、それぞれ対処してみましょう。
Warning: No visibility specified. Defaulting to "public".
「public」のところは以前調べたのと同じで、以下のように「public」を入れると消えました。
function OreOreCoin(uint256 _supply, string _name, string _symbol, uint8 _decimals) public {function transfer(address _to, uint256 _value) public {Warning: Defining constructors as functions with the same name as the contract is deprecated. Use "constructor(...) { ... }" instead.
これも以前調べたのと同じです。
以下のように、コンストラクタのところで「function OreOreCoin(…」としていたのを「constructor(…」に直すと上手くいきました。
constructor(uint256 _supply, string _name, string _symbol, uint8 _decimals) public {Warning: "throw" is deprecated in favour of "revert()", "require()" and "assert()".
「throw」ではなく、「revert()」、「require()」、「assert()」の使用が推奨されているみたいです。
たとえば「require()」なら、どうやら
if(＜条件＞) throw
と
require(＜throwのときに各条件の反対＞)
が同等の意味になるようです。（「反対」の意味は、おそらく補集合と考えると良さそう）
「throw」を一番簡単に書き換えるとすると、「throw」を「revert()」に置き換えれば上手くいきそうです。
実際、
if (balanceOf[msg.sender] < _value) throw;
if (balanceOf[_to] + _value < balanceOf[_to]) throw;
を
if (balanceOf[msg.sender] < _value) revert();
if (balanceOf[_to] + _value < balanceOf[_to]) revert();
に書き換えて再度コンパイルしてみると、この部分のWarningが消えました。
これに関しては、参考に挙げたSolidityのassertとrequireとrevertの違い（アルゴリズムとかオーダーとか）にとても分かりやすくまとめられていました。
最近のバージョンのSolidityでは「throw」が「revert()」に自動で変換されるようです。
参考サイトにあった内容をさらに短くまとめておくと、以下の内容のようです。
・revert(＜メッセージ＞) → ここでコントラクトは停止して実行前に戻す。残りのガスは返却。条件は指定できない。
・require(＜条件＞) → ここでコントラクトは停止して実行前に戻す。残りのガスは返却。条件を指定する。
・assert(＜条件＞) → ここでコントラクトは停止して実行前に戻す。残りのガスも消費。条件を指定する。
（参考）
・ERC20 Token Standard Interface を使った Smart Contractの実装について（Qitta）
・Error creating contracts on Ethereum wallet（StackeEchange）
・Solidityのassertとrequireとrevertの違い（アルゴリズムとかオーダーとか）
・Error handling: Assert, Require, Revert and Exceptions（Solidity）
Warning: Invoking events without "emit" prefix is deprecated.
さしあたり、解決策としては
Transfer(msg.sender, _to, _value);
の冒頭に「emit」を付けて
emit Transfer(msg.sender, _to, _value);
とすれば、この部分のWarningが消えました。
これでようやく怒られないコードになりました＼(^o^)／
（追記：2018/9/3）--
参考に挙げた「‘emit’ keyword in Solidity（Medium）」によると、これはv0.4.21以降で推奨される書式で、イベントの呼び出しを明示するためのようです。
明示する理由の1つがDAO事件とありますが、いまいちピンとこない。。
ちょっと調べた感じではこの辺の関連を見つけられなかったので、分かる方ぜひ教えてください。
--（追記ここまで）
（参考）
・‘emit’ keyword in Solidity（Medium）
・Invoking events without “emit” prefix is deprecated in Transfer(msg.sender, _to, _value);（StackExchenge）
・【備忘録】【Solidity】【Truffle】エラー：Warning: Invoking events without "emit" prefix is deprecated.（katonobo’s blog）
・Warning: Invoking events without "emit" prefix is deprecated #8（GitHub）
OreOreCoinをデプロイしてみる
ようやくコンパイルが（ほぼ）綺麗に通ったので、この状態でデプロイしてみます。
（実はまだメッセージは残るんですが、無害そうなのでとりあえず先に進みます。）
Deployのところを開いて、テキスト通り値を入力しつつtransactします。
うまいことデプロイできました。
ボタンを押してコンストラクタの値を取得してみると、デプロイ時に入力した内容が反映されていることが確認できます。
balanceOfでユーザーアカウントごとのOreOreCoin残高も確認してみましょう。
まずはデプロイしたユーザーアカウントです。
この「…a733c」（以下、「ユーザーA」と呼ぶことにします）というアカウントアドレスを、「"」（ダブルクォーテーション）で囲んでbalanceOfのところに入力してbalanceOfボタンを押します。ちゃんとユーザーAが 10000 [oc]持っていることがわかります。
次に、別の「…c160c」（以下、「ユーザーB」と呼ぶことにします）というユーザーアカウントについて、残高確認をしてみましょう。
OreOreCoinの送金はまだしていないので、ユーザーA以外のアカウントは残高 0 [oc]のはずです。
先ほどと同様の手順で、今度はユーザーBのアカウントアドレスでbalanceOfしてみると、たしかに残高が 0 [oc]であることが確認できます。
OreOreCoinを送金してみる
デプロイがうまくいって、現状の値確認もできたので、今度は送金してみましょう。
ユーザーAからユーザーBへの送金を試みてみます。
失敗例
transferのところに、送り先であるユーザーBアドレスと、送りたい値（ 2000 [oc]）を入力してtransactします。
ここで、送り主のアドレスはグローバル変数msg.senderにより、現在の送信主アドレスを自動取得するため、特に入力はしません。
で、やってみましたが、うまくいかない……
画像にあるエラーメッセージを見てみると、「from」のところがなぜかユーザーBになっている。。
どうやら原因は、先ほどbalanceOfしたときの流れでやっていたので、このときに取得したユーザーBのmsg.senderの値が残っていたか、もしくはBrowser-SolidityのAccount欄アカウントを間違ってユーザーBにしたままtransferやってたせいでtransferのときに取得するmsg.senderの値がユーザーBになってしまったかで、残高 0 [c]のユーザーBから送金しようとしていました。
たぶん後者の、Account欄の問題かな……？
いずれにしろ、msg.senderでユーザーBのアドレスを取得してtransferしようとしたことが原因でした。
そして、まだOreOreCoinを持っていないユーザーBからの送金はできないと、エラーになりました。
成功例
原因がわかったので、Browser-SolidityのAccount欄をユーザーAにしつつ、念のためもう一度ユーザーAについてbalanceOfを実行してから、あらためてユーザーBへ 2000 [oc]送金してみたら、今度はうまく送金できました。
ユーザーA、ユーザーBそれぞれについて、送金後の残高をbalanceOfで確認してみます。
まずはユーザーA。
つづいてユーザーB。
ユーザーAからユーザーBへ、2000 [oc]がちゃんと送金できたことが確認できました。
まとめ
今回は、「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」の実践編にあるOreOreCoinという、簡単な仮想通貨のサンプルコードをデプロイして、状態確認と送金をやってみました。
テキストのサンプルコードをそのままコンパイルすると4種類の警告が出たので、それらの対処もしてみました。
送金はいい感じに教育的な内容で（笑）失敗しましたが、エラー内容をもとに対応してうまく解決できました。
警告とかエラーの対処が、やっぱり勉強になるなぁとあらためて実感しました。
ではでは今回はこのへんで。
Keyword : ブロックチェーンBrowser-SoliditySolidityEthereumイーサリアム仮想通貨
