kkmory;

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

bancor protocolとはなんぞや -1-

先日の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に行くというきっかけをくださった小宮さん、ありがとうございました。

RubyKaigi 1日目レポ

昨日から仙台国際センターで開催されているRubyKaigiに参加してきました。簡単に1日目のレポをまとめます。


f:id:morrrry:20180601125452j:plain


基調講演

まつもとゆきひろ氏のKeynote
今回は「ことわざ」をテーマにした講演でした。

・名は体を表す

名前って重要だよね、という話
プログラミングは概念で構成されているものだから、名前付けがとても大事。

概念をよく理解していれば、名前付けが比較的簡単になる。つまり、概念を理解できなければイケてる名前をつけるの難しい、と。 名前は使い勝手へと結びつき、ユーザビリティにもつながる。

これからはグーグラビリティを意識していくことも大事。 GoとかSwiftは一般的な名詞だからグーグラビリティが良くない。そんな名前にしてもやっていけるのは裏に巨大なスポンサーがいるからで、僕らはそうではない。NokogiriとかRuby on Railsとか、名刺を組み合わせたりTypoを変えたりするとグーグラビリティ良くなるよね、と。

・時は金なり

プログラマーって忙しいよね。時は金なりだからコードを効率的に書くことってとても大事。 例えばStringクラスだと、使えるメソッドがズッラァァァァァと並んでいて、やりたい処理はだいたい載っている。

僕はRubyのそういうところが好きです。

・塞翁が馬

Ruby is dead every year.
Rubyは毎年死んでいる。それでも何度でも蘇るさ!」by Matz


これ以降はスライドのみ載せます。 (内容まで描きたかったけど時間が...)


bancor: Token economy made with Ruby

speakerdeck.com

Deep Learning Programming on Ruby

speakerdeck.com

All About RuboCop

speakerdeck.com

RubyGems 3 & 4

www.slideshare.net

A parser based syntax highlighter

speakerdeck.com

After PartyでMatz氏とツーショットを撮ってもらって感動中です。初めてRubykaigiに参加してみて、Rubyのコミュニティって素敵だなぁという感想でした。 2日目3日目も楽しみです。

※2日目のレポートは気が向いたらやります。