kkmory;

エンジニア系ふわふわ大学生（だった）の雑記帳

CryptoZombies Cp.1 まとめ

Ethereum ブロックチェーン

忙しいなぁなんて思っていたらなんやかんやで1ヶ月経ちました。
Bancor Protocolの後半記事はいつ書くねん！と総ツッコミをもらいそうですが...実はですね...

普段は下書きをMarkdownで書いているのですが、先日何を思ったかファイルを上書きしてしまい、8割方書きかけていた下書きを吹っ飛ばしました。ということで心がポキっといったので、現在ちまちまと少しづつ書いてます。完成までもうしばらくお待ちを。

Git、大事。


で、今日はCryptoZombiesのチャプター1のまとめを書きたいと思います。 7月9日（今日！）のCryptoZombiesもくもく会向けに書いてたりします。ちなみに当日のスライドはこちら。


CryptoZombiesとは

Solidity（Ethereumのスマートコントラクトを記述する高級言語。実質デファクト）を学習できるサイト。日本語化されていて、実際に手を動かしながら勉強できるし、解説が丁寧なのでおすすめ。

cryptozombies.io


符号なし整数

uint : 符号なし整数

符号なし整数とは負数ではないということ。
uintはuint256（256bit）のエイリアス。


型キャスト

uint8 a = 5; //8bit uint
uint  b = 6; //256bit uint
uint8 c = a * uint8(b); // 8bit uint


可変長配列

可変長配列はデータベースのように使うことができる。
配列をPublicで宣言すれば、自動的にgetterが作成される。
Publicをつければ、他のコントラクトもこの配列を参照できる（が、書き込めない）。 その性質を使って、コントラクトの公開データを格納するときに便利に使える。

HogeArray[] public hogeArrayName;


関数

Solidityでは、グローバル変数と区別するため、関数パラメーター変数名はアンダースコアをつけるのが通例。（必須ではない）

function hogeFuga(uint _fuga, string hoge){...}

関数はデフォルトでpublicになる。
公開する必要のない関数にはprivateに設定し、他の関数からだけ呼ぶことができるようにする。

function hogePrvt(uint _fuga) private {...}

関数の宣言に戻り値の型を含む

function hogeFunc(uint _fuga) private returns (string) {...}

View関数：読み取り専用関数
値を変更することもないし、書き込むこともない。

function sayHello() public view returns (string) {...}

Pure関数：アプリ内のデータにすらアクセスできない。
戻り値が関数のパラメータに依存する。

function _multiply(uint a, uint b) private pure returns (uint) {
  return a * b;
}


配列の要素を削除できない問題

なかじょさんの記事↓に詳しいですが、簡単に言うと 「適切なOPCODEがなく、gas代がバカ高くなる問題があるから」らしいです。

y-nakajo.hatenablog.com


Keccak256の使い方

文字列をランダムな256bitの16進数にマッピングする。 https://y-nakajo.hatenablog.com/entry/2018/01/29/180920


Event

Events は、ブロックチェーンで何かが生じたときに、コントラクトがアプリのフロントエンドに伝えることができる。特定のイベントを'listening'状態にして、何かあった時にアクションを起こすこともできる。

event IntegersAdded(uint x, uint y, uint result);
function add(uint _x, uint _y) public {
  uint result = _x + _y;
  IntegersAdded(_x, _y, result); // イベントを発生
  return result;
}


Mapping

データの保管と参照のためのキーバリューストア。
Rubyのハッシュみたいにキーと値のペアで構成。

// uint:キー、string:場バリュー
mapping (uint => string) userIdToName;


msg.sender

めっちゃ使う。グローバル関数。
そのユーザーを呼び出したユーザー（コントラクト）のアドレスを参照する

bancor protocolとはなんぞや -1-

Bancor protocol ブロックチェーン

先日のRubyKaigiで、「bancor: Token economy made with Ruby」というセッションを聞きました。bancor protocolをRubyで実装したぜ！という話。

 

speakerdeck.com

bancor: Token economy made with Ruby - RubyKaigi 2018

 

 

それ以降、bancor protocolの中身について興味を持ったので、仙台から帰ってきてからホワイトペーパーを読んだりして調べてみました。

今日と次回で、備忘録としてまとめてみます。

 

はじめに、ホワイトペーパー(日本語訳)の要約です。

Bancor(バンコール)プロトコルには、スマートコントラクト上のトークンのための、価格発見*1 と流動性を担保するメカニズムが備わっている。スマートトークンはひとつ以上のトークンを準備残高として保有し、その準備トークンと交換することで、誰もが即座にスマートトークンを購入したり、精算したりすることができる。 そしてそれは、スマートコントラクトを直接的に通じて行われ、継続的に計出される価格において取引される。その計算は、売買をバランスする公式に基づいて行われる。 

 

...... ﾅﾆｲｯﾃﾝﾀﾞ？ 

わけが分からないので、基礎的なところから調べてみました。

 
欲求の二重一致問題
Bancor protocolについて調べて行くと、このワードが出てきます。
これが何かというと、物々交換がクソ難しいということ。
 
わらしべ長者を例に考えてみます。
 
登場人物：
・蜜柑を手に入れたわらしべ氏。
・喉が渇いて死にそうな商人
 
あらすじ通りにいくと、わらしべ氏の蜜柑と商人の反物を交換するという流れになるのですが、それは奇跡的なわけです。
 
なぜかというと、
 
わらしべ氏の、
・もっといいモノが欲しい
・蜜柑を誰かにあげてもいい
 
死にそうな商人の、
・とにかく水分が欲しい
・そのためには反物をあげてもいい
 
という需要と要求が全てマッチしているからです。
なんという奇跡！ さすが昔話。
 
 
話を元に戻すと、物々交換を円満に行うためには、2者のそれぞれの要求（ここで言うとわらしべ氏と商人）が同時に発生する必要があります。物々交換がなぜ難しいかというと、この「要求の二重一致」が起こる可能性が低いからだといえます。
 
そこで、それを解決すると思われたのがお金、貨幣です。
"と思われた” が重要です。
 
人々が「これは価値があるよね」と認めていて、物々交換を媒介してくれる何かがあれば、要求の二重一致問題を解決できるのでは？
ということで、貨幣が生まれました。
 
貨幣の何がすごいかといえば、要求の二重一致を吸収してくれること。
 
物語中のわらしべ氏は、"蜜柑が欲しい人” かつ "蜜柑の対価としてより価値のある何かをくれる人” を探す必要がありました。しかし、貨幣が導入された後のわらしべ氏は “蜜柑が欲しい人” だけを探せばいいのです。
 
相手が何を持っているかを気にする必要がなくなる、と。
 
 
これで、要求の二重一致問題は解決されました。
ところが、「これでよかったね一件落着」ではないんです。
 
なぜかと言うと、貨幣が導入されたあともわらしべ氏は「蜜柑が欲しい人」を探さなければいけないということ（要求の一重一致）。蜜柑が欲しい人がいなければわらしべ氏は一銭も手にすることができないわけです。
 
そう、それで生まれるのが「流動性リスク」の問題。
 
 
流動性リスクの問題
 
自分が持っている資産を売りたいときに売れるか（買い手がつくか）ということ。例えば何らかの株式を売りたい！というときに、大手企業の株なら買い手がすぐに見つかりそうですが、どこの誰か知らない会社が出した株を買おうとする人はそうそういないわけです。
 
このように、売りたいときに売れないというリスクがいわゆる流動性のリスクと言われるものです。これは株式だけでなく、トークンにおいても起き得ることです。
 
今、僕がモリコインとか出して買う人いますか？
......ということです。
 
じゃあ、どうするのさ？　と。
 
そこで生まれたのがBancor protocolでした。
 
 
ということで、今日はここまで。
明日以降続きを書こうと思います...
 
 

RubyKaigiで感動した話

5/31〜6/2に仙台国際センターで開催された"RubyKaigi2018"に行ってきました。
2日目3日目の各セッションごとにレポートするつもりでしたが、体力気力がもたなかったのでまとめだけ書きます！

f:id:morrrry:20180604063228j:plain


最終日 : TRICK

RubyKaigi2018最後のセッション。

TRICKとは。

「変なRubyプログラムを書いたら勝ち」 というコンテストらしい。

今回、自分は初めてTRICKの存在を知ったのですが、そこには想定以上に頭のおかしいコードの世界が広がっていました。

例えば、ソースコードにはAAのように"Merry Christmas"と読めるコードが書かれていて、それを実行するとコンソール上に3Dのクリスマスツリーがレンダリングされるやつ。しっかり雪も降っててすごく手が込んでました。


そして1位は、Rubyの予約語のみで書かれたプログラム。

実行結果としては何も表示されないのですが、エラーが出てないのがすごい。
defとかendとかの順番や階層構造を意識した上でプログラミングしないとエラーが出ますよね。でもこれはエラーがでない。すご...

と、エントリーされていた方々のコードがどれも変態的だったんですが、TRICKのセッション中の会場の雰囲気がすごくエモくて。 というのも、日本中世界中から1017人のRubyistが仙台に集まって、ソースを見てみんなで笑ってる。そんな光景がなんか、すごくエモかったです（語彙力）

会場の一体感、Rubyコミュニティの温かさを感じました。


最終日：Close session

最終日、TRICKが終わった後のクロージングです。 熱い3日間が終わるんだなぁという寂しさと、また来年があるんだというワクワクした気持ちと。

そして司会の＠a_matsudaさんによるクロージングがすごくエモかった。

＠a_matsudaさんの話を要約すると、
「仙台でのRubyKaigi、参加者が1017人、千台にのりました！（ﾄﾞﾔｧ）」
「RubyKaigiはみんなのおかげだよ、Rubyist、そうYouのおかげ。RubyKaigiは人間賛歌ッ！！」
「来年は海を越えます。九州？......福岡！　4/18〜4/20でRubyKaigi2019やるよ！」
と、

えっ、ふくおか？


そう、来年のRubyKaigiは福岡です！

やったね！！！！！ 来年の楽しみができました。


2日目：RubyKaraoke

カオスと話題のRubyKaraokeに参加してしまいました。
まあカオスなことカオスなこと。
海外Rubyistたちがはっちゃけてました。

そこで得られた知見としては
・YMCAはだいたいみんな分かる
・Queen歌っとけばだいたい大丈夫
というところです。現場からは以上です。


全体的にどうだったか

今回、初めてRubyKaigiに参加しました。
セッションの中には内容の理解が追いつかないものもあって、Ruby初心者がセッションを本気で楽しむことはできないかもしれません。というか、できません。

そんな自分でもRubyKaigi行ってよかったなぁと思えたのは

・Rubyコミュニティの中を覗くことができた
・知らないことばかりだってことを再認識できた
・断片的な知識が繋がる瞬間があった

からだと思ってます。

来年はもっとセッションの内容を理解できるように、これからも勉強を続けていかなければと気を引き締めました。これからも頑張りますよ

RubyKaigiに行くというきっかけをくださった小宮さん、ありがとうございました。