FC2ブログ

日本仮想通貨交換業協会が自主規制団体に認定された意味

どうも、ぺろりんです。

2018年10月24日、日本仮想通貨交換業協会(JVCEA)が改正資金決済法に基づく自主規制団体に、金融庁から認定されました。
今回はこの意味について考えてみましょう。

日本仮想通貨交換業協会による自主規制の基本方針などはこちらから見ることができます。

また、「仮想通貨交換業等に関する研究会(第5回)」の資料にも自主規制の話がありましたので、気になる方はこちらからどうぞ。
「仮想通貨交換業等に関する研究会(第5回)」については当ブログでも以前取り上げたので、こちらもよろしければあわせてご覧ください。


日本仮想通貨交換業協会とは?

日本仮想通貨交換業協会は、仮想通貨交換業の
(1)適正性の確保
(2)健全な発展
(3)利用者保護
を目的として、2018年3月29日に設立された団体です。

この日本仮想通貨交換業協会には、2018年10月29日現在で以下16社が会員として登録されてます。
・株式会社マネーパートナーズ
・QUOINE株式会社
・株式会社bitFlyer
・ビットバンク株式会社
・SBIバーチャル・カレンシー
・GMOコイン株式会社
・ビットトレード株式会社
・BTCボックス株式会社
・株式会社ビットポイントジャパン
・株式会社DMM Bitcoin
・株式会社ビットアルゴ取引所東京
・Bitgate株式会社
・株式会社BitOcean
・株式会社フィスコ仮想通貨取引所
・テックビューロ株式会社
・株式会社Xtheta

(参考)
協会概要(一般社団法人 日本仮想通貨交換業協会)
「日本仮想通貨交換業協会」が正式発足、ルール整備で信頼回復を目指す(TechCrunch)
日本仮想通貨交換業協会が発足 —— 求められる「金融機関としての自覚」(BUSINESS INSIDER JAPAN)
金融庁、「日本仮想通貨交換業協会」を自主規制団体に認定--登録業者16社で構成(CNET Japan)


改正資金決済法に基づく自主規制団体とは?

もう少しちゃんと言うと、「『資金決済に関する法律』第87条に規定されている『認定資金決済事業者協会』」ですが、この「認定資金決済事業者協会」とはどんなものでしょうか?

これは以下のように規定されています。

第八十七条 内閣総理大臣は、政令で定めるところにより、前払式支払手段発行者、資金移動業者又は仮想通貨交換業者が設立した一般社団法人であって、次に掲げる要件に該当すると認められるものを、その申請により、次条に規定する業務(以下この章において「認定業務」という。)を行う者として認定することができる。
一 前払式支払手段(第三条第一項に規定する前払式支払手段をいう。以下この章において同じ。)の発行の業務、資金移動業又は仮想通貨交換業の適切な実施を確保し、並びにこれらの健全な発展及び利用者(第十条第一項第四号に規定する加盟店を含む。以下この章において同じ。)の利益の保護に資することを目的とすること。
二 前払式支払手段発行者、資金移動業者又は仮想通貨交換業者を社員(以下この章において「会員」という。)とする旨の定款の定めがあること。
三 認定業務を適正かつ確実に行うに必要な業務の実施の方法を定めているものであること。
四 認定業務を適正かつ確実に行うに足りる知識及び能力並びに財産的基礎を有するものであること。

資金決済に関する法律 第87条より)


ザクっというと、仮想通貨交換業の
(1)適正性の確保
(2)健全な発展
(3)利用者保護
を目的として、会員たちでしっかり自主規制しましょうね、という感じでしょうか。


日本仮想通貨交換業協会が自主規制団体に認定された意味とは?

どういうメリットがあるか考えてみる

一番大きいのはやはり、「仮想通貨業界の信用度を上げる」ということではないでしょうか。

仮想通貨交換業等に関する研究会(第5回)の資料でも2018年8月31日時点の市場規模が約25兆円と見積もられているように、仮想通貨市場はすでにかなり大きな市場となっています。
この有望な市場を無駄にせず、健全に発展させるにはまずこの市場が「マトモ」であることを示さないといけません。

少なくとも日本においては行政機関の信用度は高く認知されていると思われるので、行政機関である金融庁から認められることは信用度向上という意味で重要な一歩でしょう。


DJ Nobbyさんによる解説

これはVoicyでDJ Nobbyさんがとても分かりやすく解説されていました。


この回の「きょうの言葉」によると、この認定により、自主的にある程度ルールを定めることで「自由に営業活動」できるようになるというメリットがあるとのことでした。

もう少し詳しく書くと、以下のような解説がありました。

・法律だけではカバーしきれないような細かなルールを作って、業界団体に違反がないか取り締まるような自主規制団体がないと、金融庁からお墨付きを得られ辛くなり、法律がどんどん厳しくなってしまう。
・法律が厳しくなってしまう前に自主規制団体を設立して業界全体でルールを決めることで、これに則って活動しているアピールを金融庁や世間にアピールして、金融庁からお墨付きを与えてもらうことが目的。

(参考)
認定資金決済事業者協会の認定について(金融庁)
資金決済に関する法律第87条に基づく認定資金決済事業者協会の認定取得のお知らせ(一般社団法人 日本仮想通貨交換業協会)
金融庁 仮想通貨協会、自主規制団体に認定 健全化狙い(毎日新聞)
仮想通貨、自主規制団体を認定 金融庁(日本経済新聞)
金融庁が「自主規制団体」認可へ、日本の仮想通貨業界のターニングポイントに|ロイター報道 (CoinPost)
JVCEAが仮想通貨自主規制団体の金融庁認定を受け会見、年内にICO自主規制規則の確定・公表も(仮想通貨 Watch)


まとめ

今回は、「日本仮想通貨交換業協会が自主規制団体に認定された」ことがどういうことかを考えました。

自主規制団体への認定は、仮想通貨の業界団体が行政のお墨付きを得ることにより信用度を向上し、健全に仮想通貨業界を発展させていくための試みと思われます。
あえて自分で規制することにより、法律が必要以上に厳しくなることを防ぐという意味でも重要そうです。

「仮想通貨」という選択肢がすべてではないと思いますが、これを「お金」や「金融商品」の有用な選択肢としておくことは社会的な利便性向上に役立つことだと思います。
この意味でも、日本仮想通貨交換業協会がきっちりと自主規制を機能させ、世間の信用を得ることで「ちゃんとした」業界に仕上がることを期待しています。

テーマ : 仮想通貨
ジャンル : 株式・投資・マネー

Keyword : 仮想通貨 仮想通貨取引所 日本仮想通貨交換業協会 金融庁 自主規制団体

仮想通貨とポイントの違いと、仮想通貨を発行する意味のある場合を考えてみる

どうも、敬虔なジャンプ読者のぺろりんです。

今回は、仮想通貨とポイントの違いについて考えてみようかと思います。

というのも、いまだに毎週購読している週刊少年ジャンプを読んでいたらこの話題が出てきたのです。
2018年33号には50周年記念号ということで「こち亀」が載っていたのですが、その中で両さんと中川が次のようなやり取りをしていました。


 両さん「仮想通貨はその店だけで使えるポイントみたいなもんだろ」
 中川「まっザックリ言うと」

これを読んで、やっぱ少なくとも世間的にそんな認識だろうなー、と思いました。
たしかに最近よくある「仮想通貨を発行して……」という流れは、両さんが言うようにまさしくただのポイントみたいな感じで発行されている気がします。

ですが、ただのポイントとしての発行だと「仮想通貨だからこそ」という仮想通貨の本質を突いたような使われ方じゃないように思うのです。
というわけで、今回は仮想通貨とポイントを比べてみて、仮想通貨がどういう性質を持っているかを考えてみることにしました。

その上で、どんな使い方であれば仮想通貨を発行する意味があるのかを考えてみます。

(参考)
・週刊少年ジャンプ2018年33号


仮想通貨とポイントの違いって何だろう

とにかく、それぞれの性質を挙げてみて比べてみましょう。
「仮想通貨」、「ポイント」という観点から、思いつくものを挙げてみます。

仮想通貨
・マイナーにより、非中央集権的に発行される
・(取引所に上場した場合)換金可能
・(取引所に上場した場合)価格は市場が決める

ポイント
・発行者により、中央集権的に発行される
・換金可能とは限らない
・(換金できる場合)価格は発行者が決める

両さんの言う「その店だけで使える」という点については、仮想通貨の場合は取引所に上場さえしてしまえば、基本的に通貨ペアを組み合わせれば換金できるのであまり使う場所を制限されません。
ポイントも換金できる設計のものは利用場所の制限はありませんが、換金できないポイントも少なくない気がします。

ここで挙げた中で言えば、“発行者”と“価値の変動性”は特に、仮想通貨とポイントでそれぞれ真逆の特性があります。
厳密に言うと微妙なところもありますが、仮想通貨で中央集権的に発行権限を牛耳る“発行者”は存在しません。
また、ポイントの価値は企業などの発行者が発行時にレートを決めるので固定相場ですが、仮想通貨の価値は市場が決めるため変動相場です。

(参考)
仮想通貨って電子マネーやポイントと何が違うの?(仮想通貨購入方法ガイド)
ビットコインと、Tポイントやマイレージとの本質的な違い(仮想通貨JAPAN)
仮想通貨とポイントの違いとは?(CoinNavi)
今後10年で仮想通貨はメインストリームに、必要な6つの課題|英大学とeToro共同研究 (CoinPost)
ビットコインと企業ポイント(楽天ポイント、Tポイント)などの違い(ビットコイン研究所ブログ)


Voicyの配信で取り上げられていた内容

Voicyという音声メディアの「それでもメディアは面白い /赤メガネとコムギ」という配信の中で、ちょうど今回の話題にピッタリの内容が取り上げられていました!


この配信では色々と特徴を挙げられていましたが、個人的に重要かなと思った項目を列挙してみます。

仮想通貨(トークン)
・使用期限がない
・変動相場制
・発行上限あり
・トークンに情報を付加できる
・非中央集権的

ポイント
・使用期限がある(ポイントにもよりますが)
・固定相場制(基本的に価値は変わらない)
・発行上限なし
・ポイントに情報を付加できない
・中央集権的

利用する上では、使用期限の有無は使い勝手に効いてきますね。
変動相場と発行上限の存在に関しては、この配信でも言及されているように、仮想通貨を保持するモチベーションになります。

配信を聴いていて特にハッとなったのが、「情報を付加できる」という特徴です。
これはたしかに仮想通貨やトークンの顕著な特徴ですね。

ブロックチェーンの出生に関わる「非中央集権」という性質ですが、たしかにここで言われているように、実際に利用するユーザーからはどうでもいいかも知れません。
ただし実利もあって、「非中央集権」化することで第三者による手間賃が省かれ、手数料が安くなるということがあり得ます。


仮想通貨とポイントの違いって何だろう(再)

これまでの内容からすると、以下3つが重要な違いのように思えます。
(1)情報付加ができるか否か
(2)発行者(中央集権か非中央集権か)
(3)価値が変動するか否か

それ自身に「(1)情報付加ができるか否か」というのは、あえてそういう作り方をしない限りポイントには実装されていない、かなり仮想通貨(トークン)に特徴的な性質ではないでしょうか。
「(2)発行者」と「(3)価値が変動するか否か」についてはプロダクトによるところもありますが、これらもほとんどの仮想通貨とポイントに言える違いのように思えます。

加えて、ブロックチェーンという観点から考えると、
(4)すべての取引順序が記録されて管理されているか否か
ということが違っているのではないでしょうか?

基本的にポイントはユーザー間での取引が想定されていないと思われるので、ポイント発行者とユーザー間の取引(トランザクション)は厳格に順序を管理されているでしょうが、発行者とすべてのユーザーを含む全体の取引順が管理される必要はなさそうに思えます。(実際の実装はどうなっているんでしょう?)
こういう状況って、結局発行者のような元締め的第三者が居ないような世界なのかなと思うと、(2)と(4)は最終的に「非中央集権的なシステム」に帰着しそうな気がします。。

そうすると、(2)と(4)は一緒にできて、
(2’)中央集権か非中央集権か
と考えるのがやはり良いかもしれません。


ポイントとは違った、仮想通貨ならではの使い方って何だろう?

以上の違い、特徴を踏まえて、ポイントではなく仮想通貨(トークン)を使う意義がある、もしくは仮想通貨(トークン)でなければいけないような使い方ってどんなものでしょうか?

個人的な見解としては、
(1)トークン自体に情報付加する必要がある
(2’)非中央集権的である必要がある(第三者による手数料をかけたくない、など)
という、このあたりを満たすようなプロダクトであれば、かなりポイントではなく仮想通貨(トークン)を発行する必要性があるんじゃないかと思います。

(2’)について言えば、これは承認などのための「第三者」を置きたくない、もしくはこれまで必要だった「第三者」を取っ払うことでメリットが出るような状況を考えると良いかも知れません。

また、トークン自体に情報付加する必要がある非中央集権的に発行したいものであれば、固定相場であったとしても仮想通貨(トークン)である必要がありそうに思えます。
この意味で、私の見解としては、先ほど挙げた「(3)価値が変動するか否か」は「仮想通貨(トークン)を発行する必要性」には寄与しない性質なんじゃないかと考えています。

(1)と(2’)を満たすプロダクトというのは結局、著作権管理のように、「仮想通貨(トークン)」というよりも「ブロックチェーン」の活用になるかもしれません。
そんな中で、あえて通貨的な役割をする必要があるのはどんな場合なんでしょうか……?

「何らかの“価値”を別の形でストックしておくための“形”」として「通貨」を考えるとすれば、価値あるものを背景に、その価値をトークン化して、それが(1)や(2’)を満たすようなものであれば、それはかなり、「仮想通貨(トークン)」である必要がありますね。
こう考えると、「通貨」として発行したいなら、何らかの価値をトークン化することを前提にする必要がありそうに思えてきます。

そういえば、価値をトークン化する話は、以前イケハヤさんもブログで紹介されていました。

(参考)
【仮想通貨】「トークン」とは何か?事例で解説するよ。(まだ東京で消耗してるの?)


まとめ

さて、今回は仮想通貨とポイントの違いについて考えてみました。

今回考えた中では、以下3点が重要な違いなんじゃないかと提案してみます。
(1)情報付加ができるか否か
(2’)中央集権か非中央集権か
(3)価値が変動するか否か

そして、通貨的な役割をする必要があるもののうち、
(1)トークン自体に情報付加する必要がある
(2’)非中央集権的である必要がある(第三者による手数料をかけたくない、など)
を満たせば、(固定相場であっても)仮想通貨(トークン)ならではの使い方と言えるんじゃないかと考えてみました。
このとき、通貨(=何らかの“価値”を別の形でストックしておくための“形”)的な役割をするためには、そのトークンは何らかの価値に裏付けられている必要があるように思われます。

さて、仮想通貨よりもう少し広く、ブロックチェーンについても少し触れておきます。

個人的な意見としては、あくまでブロックチェーンは技術的な選択肢の一つであって、なんでもかんでも使えばいいというものではないと思います。
以前書いたように、「データの順序付けが、分散システムの中だけで保証できる」ということがブロックチェーンの本質かなと、現状の私は考えています。
なので、データの順序付けが保証される必要があるシステムを、「分散システムで作りたい」ときにブロックチェーンという技術が選択されるべきなのかな、と考えています。

と、こんな感じで今回はこのへんで。

テーマ : 仮想通貨
ジャンル : 株式・投資・マネー

Keyword : ブロックチェーン 仮想通貨 ビットコイン イーサリアム

「仮想通貨交換業等に関する研究会」(第5回)の資料を見てみる

どうも、ぺろりんです。

最近はあまり仮想通貨の話題を取り上げていなかった気がするので、今回は「仮想通貨交換業等に関する研究会(第5回)」の資料を見て感想を書いていこうかと思います。


「仮想通貨交換業等に関する研究会」とは?

そもそもこれって何??というのをまずはおさらいしておきましょう。

この研究会は、金融庁がとりまとめをしている、「仮想通貨まわりのいろんな問題について考えましょう」という内容の有識者の集まりです。

仮想通貨というものが広まりつつあるものの、アングラな資金に使われたり制度が整っていなかったりしていた中、コインチェック社で大規模な流出事件が発生した、というのが発足の背景にあります。
こういう状況を受けた行政としての具体的な対応の1つが、この研究会というわけですね。

傍聴もできるようなので、ご興味ある方は行ってみるのもおもしろいかもしれません。

(参考)
仮想通貨交換業等に関する研究会(金融庁)
「仮想通貨交換業等に関する研究会」の設置について(金融庁)


「仮想通貨交換業等に関する研究会」(第5回)の資料を見てみる

というわけで、資料をネチネチ読んでみようかと思いますw
以下では、参考に挙げた金融庁のサイトに載っている資料をサラッと読んでみて、大事だと思ったところとか感想とかを書いていきます。

資料を見ていると、これだけの内容を2時間で話すの大変だなというのが一番初めの感想ですw

(参考)
「仮想通貨交換業等に関する研究会」(第5回)議事次第(金融庁)


資料2

メンバー名簿は飛ばすことにして、資料2から見ていきましょう。

この資料は問題提起みたいな内容です。

この資料の印象としては、
・良い面も考えようとしている
・色んな観点から考えている
という感じです。

当たり前ではありますが、「行政はわかってない」という意見をよく見かける中、「やっぱりちゃんと考えている」と思える内容なのは良かったです。

この資料によると、「仮想通貨はリスクの方が大きいが、ブロックチェーンはプラスの面の方が大きいという評価が一般的」だそうです。
少なくともここでは、ブロックチェーン自体はポジティブなとらえ方をされているようです。

この資料を通して、やはり仮想通貨まわりの規制はすすんでいきそうな印象を受けます。
規制関連でいくつか抜粋すると、以下のようなことが書いてありました。
「仮想通貨は、「注意を要するもの」としてグローバルにも規制を強めていこうとしており、我が国においても、業界の育成というよりは、規制に軸足を置いて考える必要があるのではないか」
「参入規制が少し緩いのではないか。例えば、自己資本も低い額になっているが、一旦流出事故が起きれば、数十億、数百億単位で喪失が出ることもあり得るので、自己資本に限らないが、参入規制についてもう一回考えてもよいのではないか」
「仮想通貨のリスクを抑え、適切な方向への展開を促す観点から、参入規制を含めて、市場や規制によるコントロールを強めていく必要があるのではないか」
「マネーロンダリングの疑いや匿名性のある仮想通貨が出てきている中で、法定通貨でも厳しいマネーロンダリングの規制がある以上、同じように考えていく必要があるのではないか」

規制の方向性としては以下のようなものがあるように思います。
(1)仮想通貨関連事業への参入規制
(2)取引方法・内容の規制
(3)扱う仮想通貨の規制
(4)登録業者への運営上の規制
(5)ICOの規制

規制関連で個人的には、Zcashのゼロ知識証明なんかはせっかく画期的でおもしろい技術なのにもったいないなぁ、という思いがあります。

ICOやトークンに関してもいろいろ書いています。

トークン関連の記述もいくつか抜粋してみるとこんな感じです。
「トークンを使おうが、金銭や証券を使おうが、経済的な機能やリスクが同じであれば、同じような規制を適用していくことが基本的にあるべき姿と思われるので、新しい法制のあり方を考える際にも、ICOであるからといって過剰反応するのではなく、機能とリスクを見極めていくことが重要ではないか」
「トークン自体は価値がないものであるにもかかわらず、セカンダリーマーケットで、高額で売れてしまう現状を放置していくことは、問題をさらに深刻・複雑なものにしかねず、投資家保護の問題をより大きく引き起こしかねないのではないか」
「トークンの流通市場を何らかの規制によって合理的なものにできるかどうかが重要ではないかICOについては、少なくとも一般の投資家への販売は禁止すべきではないか」

これも意外と(少なくともこの段階においては)、「規制を強行する」ような印象は受けませんでした。
また、規制することにより有望なベンチャー企業も海外に流出する可能性があることには、行政としても危機感を感じていることがこの資料からうかがえました。


資料3

資料3は、仮想通貨交換業者まわりが現状がどんな風になっているかをまとめた資料です。

ここでもいくつか記述を抜粋してみます。
「主にみなし業者において、昨年秋以降、取引が急拡大し、ビジネス展開を拡大する中、内部管理態勢の整備が追いつかず」
「取り扱う暗号資産(仮想通貨)のリスク評価をしていない」
「法令等のミニマムスタンダードにも達していない内部管理」
「内部監査計画を策定しているが、リスク評価に基づくものとなっていない」

この資料にも明確に書いてあるように、現状はコーポレート・ガバナンスというものがうまく機能していないようです。
金融商品を扱う業者なので、リスク評価・管理なんかは特に重要ですね。

また、「セキュリティ人材が不足している」というのもなかなか残念な状況ですよね。。

このあたりのリスク評価・管理、セキュリティ周りをうまいことやれる人は結構高給で雇ってもらえるのではw

この資料で個人的に意外だったのが、「上場企業を含む様々な企業が新規参入の意向(160社超)」という記述です。
最近の仮想通貨の相場は昨年末に比べるとだいぶ下がってしまいましたが、今後まだ伸びると考えているということでしょうか?
いやむしろ、「仮想通貨の“交換”は今後必要になってくるので、プラットフォーム事業は将来性がある」というような考えなのかな……?

いずれにしろ、仮想通貨自体は今後「使われるようになる」と考えている企業が100以上あるように見えます。
もしくは自分たちで発行して使うために、交換業が必要なのかも知れませんね。


資料4

資料4は、日本仮想通貨交換業協会による自主規制の概要説明です。

基本的には利用者保護に重点がおかれているようです。
広告の規制も結構いろいろ書いています。

「移転記録の追跡ができない又は著しく困難な仮想通貨(いわゆる匿名仮想通貨)については、AML/CFT[注]や適切な監査の実施の確保の観点から問題があるため、これら問題が解決されない限り禁止」と書いているということは、逆に、「ここで挙げられた問題が解決されたら解禁される可能性がある」とも読めますね。
この意味なら、管理方法に関してブレイクスルーが起きれば、Zcashみたいな匿名性の高い仮想通貨も復権するのでは。

あと、この資料で証拠金倍率の協会指定水準というのが「4倍(証拠金率25%)」とされています。
個人的にはこれだけ値動きが激しいので、仮想通貨にレバレッジをかける必要性を感じないですが……w

最後の方にある参考資料の「仮想通貨の意義・必要性」というのがなかなか勉強になります。

事例を見ると、以下の内容が読み取れてタメになりました。
・細分化しての共有やシェア・レンタルと相性が良い。
・独自通貨の発行はまだまだありそう。
・著作権がらみの利益分配に便利。
・スマートコントラクトで、契約の履行と支払が同時に行われることが可能になる。
・主にゲーム系がDapps(分散アプリケーション)として作られている。

仮想通貨全体の時価総額が2018年8月31日時点で「225,466,537,354USD(約25兆円)」というのは無視できない規模なんでしょうね。
この無視できない市場を健全に発展させるためのインフラとして、仮想通貨交換業者の必要性が最後に書いてあります。


まとめ

「仮想通貨交換業等に関する研究会(第5回)」の資料を見て大事そうなところとか感想とかを書いてみました。

全体を通しての印象としては、以下の内容です。
・ちゃんと色んな観点から議論している。
・基本的には仮想通貨まわりは規制に向かっている。
・現状「ブロックチェーン技術」はポジティブに考えられていて、仮想通貨市場も健全な「発展」を望まれている。

個人的に感じたのは、仮想通貨に関しても管理的な問題が払拭されてくれば、規制も多少は緩まるような余地はあるんじゃないかなということです。
現状まだまだ一般参加者にとっては投機対象でしかない感じがする仮想通貨ですが、健全に発展してより社会が便利になると嬉しいところです。



[注] AML/CFT…マネーローンダリング/テロ資金供与対策(Anti-Money Laundering / Counter Financing of Terrorism)。
(参考)
AML/CFTにおけるリスクベースアプローチ(PwC)


テーマ : 仮想通貨
ジャンル : 株式・投資・マネー

Keyword : ブロックチェーン 仮想通貨 仮想通貨取引所 金融庁

ブラックリスト機能付き仮想通貨コントラクトをデプロイしてみる

どうも、ぺろりんです。

今回も 「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門」で勉強していきます。

前回は最低限みたいな機能が付いた仮想通貨コントラクトをデプロイして遊んでみましたが、次の話題は「ブラックリスト」です。

登録されると取引禁止になる「ブラックリスト」機能付きの仮想通貨コントラクトをデプロイして、実際にユーザーをブラックリストに追加したり、リストからはずしたりしてみて、挙動を確認してみます。

引き続きJavaScript VMを使って、ブラウザ上で完結した環境で動作確認していきます。


ブラックリストの仕組み

コード自体は 「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門」を参照していただきたいのですが、基本的な仕組みは簡単なものです。

「blackList」という名前の変数をフラグとして使ってif文でフラグをチェックし、そのユーザーに「ブラックリスト」フラグが立っていたら取引がなかったことになる、という内容です。

今回のコードは、前回のコードにこの変数「blackList」を使ったフラグチェック機能が付いたものです。


「ブラックリスト」機能付きの仮想通貨コントラクトをコンパイルしてみる

さて、教科書通りのコードを入れてコンパイルしてみると、案の定めっちゃ怒られますw


数は結構ありますが、内容を分類すると前回対処した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へ送金しようとしても、送金されませんでした。




オーナーがブラックリストに登録されてはダメかと思いましたが、考えてみれば、オーナーはブラックリストの追加/削除をするだけで、ブラックリストに登録されていようがブラックリストの追加/削除はできるので、別に変なことにはならないんですねw


まとめ

今回は、「ブラックリスト」機能付き仮想通貨コントラクトをデプロイして、その動きを確認してみました。

コンパイル時の警告に関しては前回の知識だけで乗り切れたので、スムーズにデプロイできました。
デプロイ後の動きとしても、教科書の想定通りに動いていることが確認できました!

というわけで、今回はこのへんで。

テーマ : プログラミング
ジャンル : コンピュータ

Keyword : ブロックチェーン Browser-Solidity Solidity Ethereum イーサリアム 仮想通貨

仮想通貨コントラクトを作成してみる

どうも、ぺろりんです。

「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門」のつづきです。
このシリーズでは、前回は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によるスマートコントラクト開発入門」の実践編にあるOreOreCoinという、簡単な仮想通貨のサンプルコードをデプロイして、状態確認と送金をやってみました。

テキストのサンプルコードをそのままコンパイルすると4種類の警告が出たので、それらの対処もしてみました。
送金はいい感じに教育的な内容で(笑)失敗しましたが、エラー内容をもとに対応してうまく解決できました。

警告とかエラーの対処が、やっぱり勉強になるなぁとあらためて実感しました。
ではでは今回はこのへんで。

テーマ : プログラミング
ジャンル : コンピュータ

Keyword : ブロックチェーン Browser-Solidity Solidity Ethereum イーサリアム 仮想通貨

プロフィール

ぺろりん

Author:ぺろりん
最近仮想通貨が楽しくなってきました。
基本的な技術をちゃんと知りたいなぁと思いつつ、まったりお勉強していこうかと思います。

twitter:ぺろりん@ぶろっくちぇーん

カテゴリ
最新記事
最新コメント
月別アーカイブ
カレンダー
10 | 2018/11 | 12
- - - - 1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 -
検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QR
メールフォーム

名前:
メール:
件名:
本文: