FC2ブログ

「価値のインターネット」ってなんだろう?

どうも、ぺろりんです。

今回は、Rippleの言う「価値のインターネット」について自分なりに考えて再構築してみました。

抽象化して考えを再構築することで、より広い範囲に応用できるんじゃないかと思っています。

ここでは、「価値」を“資本主義経済における”「価値」であると考えることにします。
この前提で、まず経済学的に「価値」がどう考えられているかを調べ、「インターネット」がどんなものか考えた上で、「価値のインターネット」がどんなものか、どうあるべきものかを考えてみます。


価値とは何だろう?

結論

はじめに結論を書いておくと、資本主義経済において「価値=交換可能性」です。

資本主義経済の本質は「交換」で、この交換の動機は「差異」から生じます。
「差異」のある対象同士が「交換」されたとき、対象の「価値」が実現されます。

私の考えでは、この「差異」には以下の2種類が存在します。
(1)交換“対象”自体が持つ、“質”および“量”の差異
(2)交換対象の“所有者”が持つ、“主観価値”の差異

また、「交換」であるということは、以下のような点を含むことが重要だと考えています。
(A)絶対価値は存在せず、「価値」は常に相対的
(B)やり取りは一方的ではなく、常に2つ以上の対象(「交換するもの」と「交換されるもの」)が登場する


補足

経済学の本なんかには、ここで書いた「交換対象」は「商品」と書かれていたりします。
資本主義経済はこの「商品」の交換によって成り立っているわけですが、交換しようと思うのはなぜかというと、「自分が持っているもの」と「他人が持っているもの」に「差異」があるからです。
まったく同じものだったら交換する意味はありません。

経済学の価値論では、「価値」には「価値(or 交換価値)」と「使用価値」があると言います。

前者の「価値(or 交換価値)」は(1)につながる概念かと思います。
後者の「使用価値」は(2)に当たるもので、近年になって「効用価値」という考えが出てきた流れで「主観価値」とも呼ばれるようになったと理解しています。

(1)の「差異」はわかりやすいのですが、(2)の「差異」は経済学でも議論されるレベルで測定(というか定義)がむずかしいものです。

(2)の「差異」を考える上で、調べていた中で面白かったのが「マズローの欲求5段階説」を用いた話です。
これでもまだギャップがありますが、「主観価値」を定量化する足掛かりにはなりそうに思います。
少なくとも、「主観価値」とか「効用」とだけ言うよりは具体化されています。

(参考)
Textbook 資本主義経済の理論
市場経済と価値―価値論の新機軸 (明治大学社会科学研究所叢書)
限界効用価値説の展開と労働価値説との対比 : マルクス経済学と「限界革命」Ⅳ(山梨学院リポジトリ)
利益を生み出す「価格」の秘密(帝国書院)
経済学と労働価値説(九州大学)
文化と固有価値の経済学(J-Stage)
「価値」とは何か~あなたは価値を生み出せていますか~(Eureka!)
創造性における自己実現欲求と価値について―マズローの自己実現的創造性の検討―(CiNii)
マズロー=ウィルソン欲求理論が含意するもの(II)(明治学院大学)


インターネットとは何だったの?

結論

インターネットは、ひと言で表すなら「“データをやり取りするネットワーク”の、分散管理ネットワーク」です。


補足

Internetの単語自体も、「Inter-(間)Net(=Network)」というつくりをしています。

インターネット以前は、世界各地に点在する企業や学校などが各々が独自にコンピュータのネットワークを構成して、自分たちの中でコンピュータ同士のデータのやり取りをしていました。
インターネットの登場により、個々の組織で閉じていたネットワーク同士がデータのやり取りをできるようになりました。

そしてインターネットは、一元管理する「管理者」は存在しない「分散管理ネットワーク」になっています。

(参考)
平成11年版 通信白書 第1章 特集 インターネット コラム2 インターネット -「ネットワークのネットワーク」-(総務省)
インターネットって何?(総務省)
インターネットとは(日本ネットワークインフォメーションセンター)
【違い2】インターネットとネットワーク(OWLet)
Rippleプロトコル入門(Ripple総合まとめ)


じゃあ、価値のインターネットとは?

結論

私なりの結論としては、「価値のインターネット」とは「分散ネットワークにおける、データ差異の交換」です。

このとき、以下の点に注意する必要があります。
(1)分散ネットワークにおいて、データの一意性が保証されないといけない
(2)「交換」であるので、一方が“全取り”することはできない(「“0”と交換」という広義の解釈はアリだと思います)

すべての“モノ”や“コト”は何らかの方法でデータ化(もしくは「トークン化」)された時点からインターネット上でやり取りが可能になり、それらの差異はデータの一意性が保証された「価値のインターネット」上で「交換」が可能になります。


補足

これまで書いた内容から「価値のインターネット」は、「価値=交換可能性」にあたるデータを「分散ネットワーク」でやり取りするものだと言えます。

インターネット上でやり取りするのはあくまで「データ」で、「価値」の源泉が「差異」にあることから、やり取りされるものは「データの差異」であるはずです。
また、「価値」が実現されるためには「交換」される必要があります。

このような考えから、上記の結論に至りました。

(1)について、「交換可能性」の源泉である「差異」が、(コピペするようなノリで)消えたり簡単に現れたりしては困ります。
「差異」がなくなれば「交換」の動機はなくなるため、この「差異」はやり取り(=「交換」)の間、保存されないといけません。
これは分散ネットワーク上で、データの一意性が保証されていれば良いかと思います。

「データが一意であること」は「同じ時刻にそのデータが1か所にしか存在できない」わけです。
分散ネットワークにおいて、これはブロックチェーンによる「データの順序付け」により達成されます。

(2)について、一方が、もしくは交換の仲介者が“全取り”することを防ぐのは、RippleからすればInterledger Protocol(ILP)で実現できます。
私がここで言う「交換」は何らかの通貨で媒介してもしなくても良いと思っていますが、Ripple的にはXRPに仲介させて「交換」するのがベスト、ということになるのでしょうw

(参考)
価値のインターネット:何を意味し、どのような恩恵を人々に与えるか(Ripple)
Ripple Protocol Consensus Algorithm日本語訳(Qitta)
価値のインターネットとは(Ripple総合まとめ)
IoV(Internet of Value:価値のインターネット)とは・意味(HEDGE GUIDE)
ブロックチェーンがもたらす次の破壊と創造 第6回 日本銀行・副島豊、gumi・國光宏尚、アクセンチュア・高橋良之の3氏による鼎談(日経BizGate)
日本政府は“トークンエコノミー”を理解できていない(アゴラ)


まとめ

資本主義経済における「価値」を前提として、「価値のインターネット」がどんなものか自分なりに考えて再構築してみました。

私の結論としては、「分散ネットワークにおける、データ差異の交換」が「価値のインターネット」であるという考えに至りました。

これは以下のような考えからきています。
(1)インターネットであるからには「分散ネットワーク」でデータがやり取りされる
(2)価値の源泉が差異であることからやり取りされるべきは「データの差異」である
(3)価値を実現するためにやり取りは「交換」でなければならない

抽象化しすぎて無意味になっていたりすると悲しいですが(笑)、ブロックチェーン応用の足しにちょっとでもなれば良いなと思います(´・ω・`)

現状ある考えでの、もう少し具体化された応用というのがイケハヤさんの記事だったり赤メガネとコムギさんのVoicy配信だったりで取り上げられている「トークンエコノミー」の世界観だったりします。
これに関しては、「ポイント」との違いについて考えるのも面白いです。

……といったところで、今回はこのへんで。

テーマ : ビジネスアイディア
ジャンル : ビジネス

Keyword : ブロックチェーン blockcahin 仮想通貨 暗号資産 Ripple リップル 価値のインターネット

キャッシュバック機能付き仮想通貨コントラクトをデプロイしてみる

どうも、ぺろりんです。

新年あけましておめでとうございます。
昨年読んで下さった方もそうでない方も、本年もどうぞよろしくお願いします。

さて、だいぶ時間が空いてしまいましたが、引き続きEthereumのお勉強を「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」でやっていきます。

前回はブラックリスト機能付きの仮想通貨コントラクトで遊んでみました。
今回は上の教科書でこの次に書いてある、キャッシュバック機能付きの仮想通貨コントラクトをデプロイして遊んでみようかと思います。

コードはJavaScript VMを使って、ブラウザ上で動かします。


キャッシュバックの仕組み

キャッシュバックの仕組みとしては簡単です。

「setCashbackRate」というメソッドを通して、キャッシュバック率を変数「CashbackRate」に設定します。
送金時にこのキャッシュバック率分を、送金額から引いてやることで「キャッシュバック」を実現します。


コードのデプロイ

コンパイル

まずはコードをコンパイルします。
「Auto compile」にはチェックしてないんですが、どうも勝手にコンパイルされる……?


ちなみに、コンパイラをちゃんと選ばないと怒られます。
サンプルコードで
pragma solidity ^0.4.8;

となっているので、0.4.8のバージョンを選ぶとうまくいきました。



デプロイ

無事コンパイルできたので、デプロイしてやります。

まずは「Environment」を「JavaScript VM」にしてやって、VM環境に設定しておきます。


デプロイ時のパラメータを入力しつつ、「Deploy」を実行します。
文字は「"(ダブルクォーテーション)」で囲む必要があるので注意が必要です。


無事にデプロイできました。


今回の状態変数はこんな感じです。




キャッシュバックの動作確認

前回までのコードに“キャッシュバック機能”が付いたものなのでブラックリスト用の変数があったりしますが、気にせずキャッシュバック関連だけイジって遊んでみます。


今回使うアドレス

先に、以下で使いたいアドレスをまとめておきます。

Aさん、Bさん、Cさんとして、以下のアドレスを使うことにします。
Aさんはデプロイ時に使ったアドレスなので、オーナーアドレスとなります。

 Aさん: 0xca35b7d915458ef540ade6068dfe2f44e8fa733c
 Bさん: B 0x14723a09acff6d2a60dcdf7aa4aff308fddc160c
 Cさん: 0x4b0897b0513fdc7c541b6d9d7e929c4e5364d2db


各アドレスの初期残高確認

まずは初期状態を確認しておきましょう。

Aさんはオーナーアドレスなので、初期状態ではすべてのOreOreCoin( 10000 [oc])を所有しています。


Bさんの初期状態は 0 [oc]です。


同じく、Cさんの初期状態も 0 [oc]です。



OreOreCoinを流通させる

このままだと面白くないので、OreOreCoinをすこし流通させてみましょう。

まずはAさんからBさんへ 2000 [oc]プレゼントしてみます。




同様に、AさんからCさんへ 1500 [oc]プレゼントしておきます。




CさんからBさんに送金してみる(キャッシュバックなしの場合)

はじめに、キャッシュバック率が0の場合の挙動を見ておきましょう。

まずはBさんのキャッシュバック率が0であることを確認しておきます。
具体的には、「Account」をBさんのアドレスにして、「CashbackRate」の値を確認します。



たしかにBさんの「CashbackRate」が0であることがわかりました。

つぎに「Account」をCさんのアドレスにして、Bさんへ 500 [oc]送ってみます。





キャッシュバックなしなので、普通に送金されました。


CさんからBさんに送金してみる(Bさんがキャッシュバック率を設定した場合)

今度はBさんがキャッシュバック率 20% を設定した場合を見てみましょう。

「Account」をBさんのアドレスにして、「setCashbackRate」に「20」を入れて実行してやります。



これで、Bさんの「CashbackRate」というキャッシュバック率を表す状態変数の値が「20」(%)になりました。


この状態で「Account」をCさんのアドレスにして、再びBさんへ 500 [oc]送ってみます。



BさんとCさんの残高を確認すると、たしかにBさんへは2割引きの 400 [oc]が送金されたことがわかります。




まとめ

今回は、キャッシュバック機能付きの仮想通貨コントラクトをデプロイして遊んでみました。

詳しいコードは「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」を見ていただきたいのですが、やっていることは簡単で、送金時に
 (送金額)=(送金しようと設定した額) - (送金しようと設定した額)×(キャッシュバック率)
と計算した“送金額”を送金しています。

テキストではデプロイ時のアドレス(オーナーアドレス)と普通のユーザーだけで動作確認していたので、オーナーアドレス以外の普通のユーザー2人の場合で動作を見てみました。

それでは今回はこのへんで。

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

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

Ripple(リップル)って何をしてるの?

どうも、ぺろりんです。

今回はRipple(リップル)の取り組みがどんなものか勉強してみました。

参考サイトで勉強した内容をもとに、自分が理解した内容をまとめてみます。
間違ってたら修正しますので、メールフォームから教えていただけると非常に助かります。


Rippleが目指していること

Rippleが目指しているのは、「サービスごとにバラバラな“決済”ネットワークを(分散ネットワークとして)統一すること」のようです。

インターネット初期の電子メールは、複数あるメールサービスの中で、同じサービスを使っている人同士しかメールを送ることができませんでした。
SMTP(Simple Mail Transfer Protocol)というメールのプロトコルが作られたことで、異なるサービス間でもメールを送れるようになりました。

同様に今の世界では、クレジットカードならそのカード会社のシステムが導入されているお店だったり、サービスごとに“決済”ネットワークが分離されています。

メールにおけるSMTPのように、「異なるサービス間でも決済できるプロトコルを作る」ことをRippleは目指しているようです。
しかも第三者の承認機関なしに、分散ネットワークとして成立させようとしています。
(こういうのを、Rippleは「価値のインターネット」と表現しています)

(参考)
Rippleプロトコル入門(Ripple総合まとめ)
価値のインターネット:何を意味し、どのような恩恵を人々に与えるか(Ripple)
SMTP(Simple Mail Transfer Protocol)~前編(@IT)
Simple Mail Transfer Protocol (- srgia.memo.space - )


Rippleが提唱しているプロトコル

先述した決済プロトコルとしてRippleが提唱しているのが、W3Cで標準化がすすめられているInterledger Protocol(ILP)です。

ILPは、インターネットのTCP/IPのような考え方で「アプリケーション」、「トランスポート」、「インターレジャー」、「レジャー」という4つの層からなるプロトコルです。

基本的な仕組みは、「異なる決済サービスを使うAさんとBさん間で決済する」ときに、「Aさんのサービスと決済可能」かつ「Bさんのサービスと決済可能」なCさんが、AさんとBさんの仲介をします。
もっと具体的に言うと、AさんのユーロとBさんの円を交換したいときに、Cさんのドルを介して通貨交換を行うことを一般化した内容になっています。

RippleNetというネットワークに参加した人の中から、このようなCさんを探してきて仲介してもらいます。

何も考えず
 Aさん→Cさん→Bさん
とお金を移動すると、Cさんが途中で持ち逃げできてしまうので、この辺の仕組みをちゃんと考えてやる必要があります。
くわしくは参考サイトにゆずりますが、「決済しますよ」という“情報”だけ先に「Aさん→Cさん→Bさん」と流し、実際の決済は逆順に「Bさん←Cさん」を実行してから「Aさん←Cさん」を実行したりすることで持ち逃げを回避します。

(参考)
【図解】リップルが提唱したインターレジャープロトコル(ILP)の仕組み(ZOOM)
Ripple Protocol Consensus Algorithm日本語訳(Qitta)
【ビギナーシリーズ】第5回 全ての台帳を繋ぐインターレジャープロトコル(ILP)とは?(仮想通貨リップル研究室)
【初心者向けに大体わかる】TCP/IPとは?(エンジニアの入り口)
通信周りに疎いエンジニアがTCP/IPの要点を頑張って教えます(Qitta)


暗号資産「XRP」の位置づけ

ILPの中で出てくる仲介役は、マイナー通貨同士の交換だったりすると“Cさん”だけでなく“Dさん”や“Eさん”が必要な場合もあります。
(マイナーな草コインなんかだと、通貨交換がめっちゃ面倒だったりします。。)

これを解消する、「どんなサービス(だったり、通貨だったり)とも交換できる“ブリッジ通貨”」が「XRP」です。

「XRP」を使える決済はどんな組み合わせでも“Cさん”までで完結し、“Dさん”や“Eさん”が必要になることはありません。
これにより、マイナー通貨同士の交換みたいな場合でも決済スピードが上がります。


まとめ

Rippleはニュースを見ていると淡々と事業をすすめている印象をうけていますが、実際にやりたいことは実は今まであまり理解していませんでした。

今回勉強してみて、以下の理解が得られました。
(1)Rippleは、異なるサービス間の決済プロトコルを作っている。
(2)ILPでは、分散ネットワーク内の仲介者を使って異なるサービス間の決済を行う。
(3)XRPの導入により、決済の仲介者は最大1人になる。

しっかり政治をしていっているRippleが決済インフラとして根付いて、社会をより便利にしてくれることを期待しています(´・ω・`)

(参考)
リップルの国際ネットワーク、5大陸の40カ国に広がる|米資産額9位の銀行も参加を表明 (CoinPost)
リップルネットの参加企業200社越えに|2ヶ月で100社の増加実績 (CoinPost)
リップル社のニュースに湧いた2018年。Q3決算での売り上げ大幅アップは何を意味するのか(たのしい仮想通貨女子会)
RippleNet(リップルネット)にイギリスの決済プロバイダMoneyNetintが参加(CRYPTO TIMES)
三菱UFJ銀行がブラデスコ銀行と新たな覚書を締結、Ripple(リップル)の技術を用いた国際送金の研究を開始(COIN TOKYO)



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

Keyword : ブロックチェーン 暗号資産 Ripple リップル ILP InterledgerProtocol

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

どうも、ぺろりんです。

今回も 「はじめてのブロックチェーン・アプリケーション 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:ぺろりん@ぶろっくちぇーん

カテゴリ
最新記事
最新コメント
月別アーカイブ
カレンダー
12 | 2019/01 | 02
- - 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 31 - -
検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

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

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