きの仮想通貨コントラクトをデプロイしてみる(前編)」の続きです。きの仮想通貨コントラクトでした。やりたいのは、暗号資産(仮想通貨)が1つあって、これに「紐づくユーザーが各々会員情報を持つ」状況をコントラクトで表現することです。前回はコントラクトをデプロイし、「暗号資産(仮想通貨)のコントラクト」と「会員管理のコントラクト」を紐づけるところまで動かしてみました。今回は、送金の動作確認と、送金によって「会員管理」部分がちゃんと機能するかという動きをみていきます。アドレスのまとめまずは前回に引き続き、使うアドレスをまとめておきます。以下4つのアドレスが登場します。引き続き教科書に沿って、ユーザーAからユーザーBへ2000[oc]送金します。ちなみになぜユーザーAから送金するのかというと、「OreOreCoin」をデプロイすると「デプロイ実行ユーザー」の残高に全OreOreCoinが付与される仕様になっていて、送金によってOreOreCoinを流通させるまではユーザーAしかOreOreCoinを持っていないためです。送金するための「transfer」も「msg.sender」を含むので、実行ユーザーを気にする必要があります。今回はユーザーAから送金するために、実行ユーザーをAにして「transfer」します。各ユーザーの残高も無事に増減しています。ユーザーAの「tradingHistory」を見るとカウントが増えているはずなんですが......なぜか更新されない......w(解決するのは後述)会員ステイタスのランクアップ会員情報が更新されないですが、めげずに教科書通り、取引を続けてみましょうwユーザーAからユーザーBへ、4回100[oc]を送金してみました。「tradingHistory」更新されないので、「coin」を確認したら値が入ってない......!w先ほどアドレスを入れようとしたとき、「setCoin」に「onlyOwner」修飾子がかかっているのを忘れて「Members」のオーナーではないユーザーAで実行していた気がします。「Members」のオーナーであるユーザーBを実行ユーザーにして、再度「setCoin」で「OreOreCoin」のアドレスを「coin」に代入してみます。「coin」にアドレスが入りました。再度ユーザーAからユーザーBへ、1回100[oc]を送金。今度はちゃんと「tradingHistory」が更新されていました。ユーザーAからユーザーBへ、100[oc]を送金を繰り返すと、「statusIndex」が「2」になりました。ちなみに、「transfer」は送金の実行ユーザーを「msg.sender」で取得して「updateHistory」という「tradingHistory」更新のための関数を呼び出すので、送金を実行していないユーザーBの「tradingHistory」は更新されていません。キャッシュバック機能の確認ユーザーAへのキャッシュバック率を「getCashbackRate」で確認すると、ちゃんと「Silver」の「5」(%)になっています。先ほど送金を数回した途中で(ボタンを押しすぎてw)「Silver」になってしまい、最後の送金にはキャッシュバックが反映されていました。ユーザーAの残高に100×5%の5[oc]という端数が現れています。「updateHistory」の実行ユーザーについて「updateHistory」は「onlyCoin」という、「OreOreCoin」しか実行できないようにする修飾子がついています。ユーザーではない「OreOreCoin」が実行するというのがどういうことなのか、個人的にはこれがちょっと気持ち悪くて考えてみました。結論としては、「OreOreCoin」に定義された「transfer」が「updateHistory」を呼ぶとき、“msg.sender=OreOreCoinのアドレス”になっていると思われます。このあたりの関数の呼び出しが、次の図のような構造になっていると考えるのが良いのかな、と思います。「transfer」を呼ぶのはユーザーAなんですが、「updateHistory」は「OreOreCoin」が呼んでいると考える必要がありそうです。きの仮想通貨コントラクトで遊んでみました。“暗号資産(仮想通貨)が1つあって、これに「紐づくユーザーが各々会員情報を持つ」状況をコントラクトで表現する”ことをやってみました。このコントラクトのコードと動きを理解するにあたって、個人的には以下の点がポイントだと感じました。(1)コントラクト名と関数名が入れ子になっていて、コードをしっかり追う必要があった。(「setMembers」は「OreOreCoin」、「setCoin」は「Members」内に定義されている)(2)関数の定義に関わることから、実行ユーザーを気にする必要があった。(「msg.sender」や「onlyOwner」修飾子による)(C)mapping型は「連想“配列”」なので、配列になっている。(これをポイントに挙げるのは、特に個人的な勉強不足ゆえですw)......と、こんな感じの内容でした。同じようなところで詰まった方のお役に立てれば幸いです。0Pagetopブロックチェーン関連の記事紹介まとめ(2019年3月:#60-90)どうも、ぺろりんです。́・ω・`)自由化による電力の流れの双方向化って、いわれてみればたしかにそうなりますね......あと、インフラにはダウンしにくい分散ネットワークって合いそうですね。どこにも使ってないんだっけ?自分の理解が曖昧だなぁ。公式のドキュメントを読みにいかないといけないな。今後としては、分散型と集中型を組み合わせて使う世界観が筆者の主張のようです。アルゴリズムによる合意を「『信頼された中央の帳簿管理者』を置かない中で、帳簿等への『信頼』を新たに創り出すためのコスト」と表現してるの面白かったです。優秀って言ってるように見えるがどうなんだろう。危ない感じになってしまったもんなぁ。実装はもーちょい複雑なのかもですが、秘密分散って1次関数で説明できる、こんな簡単な原理なんですね。分散DBについてはこのへんも参考に。そもそもが違う概念って印象だなぁ。́・ω・`)ここに出てくる「AIによる完全自動企業」って、もはや「組織」と呼ぶ意味もないような気が。2019年3月10日バイト毎に下位順で並べるのをリトルエンディアンって言うんですね。データ量は、やっぱり問題になりますよねぇ。これ個人的に以前から気になってるんですよね。将来的に、最終的には検証用ノードが、ストレージも十分にある数台のスパコンにしか務まらなくなるようにならないかなぁと。́Д`)理解が浅いので、ブルームフィルタは他の記事も読もう。別に調べる方が良いかもなぁ。2019年3月14日>「楽しそうな作業だと思われるかもしれません。コアな部分に根本的な問題あるように見える。#暗号資産(#仮想通貨)の新しい可能性を示すアイデアで、個人的には画期的だと思うなぁ。学習のご参考にどうぞ。元記事のブログ、他の記事も面白そうな感じです。数式を入れて書いてくれてるのがうれしい。́・ω・`)仕組みによって原理的に競合するかもだけど、一般に、論理的に競合するのかしら。関係なさそうな雰囲気を感じるけど。凄さはこの政治力だと思う。淡々と支配圏を拡大してるwインフラ作りだと「当たり前」に広がるのが重要で、プロダクトがしっかりしてるならこういうとこで勝負がつくんだろうな。「全ての責任をユーザーに帰属」ってかなり難しそうだなぁ。現状の日本の国民性だと、まだここに到達できる気がしない。基盤は数社のジャイアントが握るような未来になりそうかなぁ。#暗号資産(#仮想通貨)は須く関係ありますね。文献いっぱい載ってて嬉しいwユーザー側に技術知識を要求する状況では、インフラとして広まるにはまだまだ不十分だよなぁ。文脈でよく出てくる楕円曲線暗号の話。思ってたよりだいぶ簡単な仕組みだな。́・ω・`)これをやるメンタリティとして、発信してゲーム外で稼ぐってのは良いですね。ある程度やり込む必要はありそうですが。公開鍵暗号つながりで。途中計算の記載に優しさを感じるwmodの割り算がどうも慣れないな......群はまだしも体はあまり馴染みがなくてとっつき辛いwまぁQ、R、Cは別だけどww記事としては、すごくわかりやすくスッキリ説明されてて、最後のf_pの補足も有り難い。0PagetopホームPagetopプロフィールAuthor:ぺろりんまだ始まってもいない暗号資産(仮想通貨)、今後が楽しみです。基本的な技術をちゃんと知りたいなぁと思いつつ、まったりお勉強していこうかと思います。Reserved.|プライバシーポリシ。