寄付窓口はこちら

Hi-Ether Meetup # 6 Tokyo #HiEther

ブロックチェーン

Hi-Ether Meetup #6 Tokyoに参加したレポートです。

Hi-EtherはEthereumのテストネットワークRopstenで1Ether持っているとSlackグループに参加申請ができるEthereum技術者向けのコミュニティです。

このレポートはリアルタイムに聞き起こしたものなので、記述が変なところがあるかもしれませんがご容赦ください m(_ _ )m

次回 #HiEther はDMMさんにて、8月末頃に開催されるそうです（8/29から9/2のiOSDC Japan 2018と被らないといいなぁ...）。

11月にはカンファレンスも開催するそうです！

Bancor gemと最近のBancorの話し @kurotaky

いまはペパボでSUZURIやってます。社内でフィンテックコミュニティがあり有志で暗号通貨の話や新しい決済の話、自社に決済システムを導入したりと言った活動をしている。

SUZURIは書いた絵をウェブにアップロードしてスマートフォンケースやバッグ、Tシャツなどを作れるサービス。

他に、クリエイター向けで、クリエイターはメインの創作活動と別にお金を稼ぐ活動をしていたりするが、本業に集中できるように、個人が個人を支援できる SUZURI People ∞ クリエイター支援プラットフォーム というのもやっています。

（会場の）SmartNewsさんといえば、社員もみんな毎日情報収集に使っています。

ところで今日は何の日か知っていますか？やまなし桃の日です。地球くんをクリックすると毎日何の日か教えてくれて面白いですね。

それでは、RubyKaigiで話したBancorプロトコルの話などできればと思います。

Bancorは準備金のような仲介を導入してトークンの流動性と取引価格決定の自動化を行う。

トークンの価格はその時点でトークン発行者が保管している準備金の残高をトークン総発行量と固定準備率で割ったものだという方程式で、価格が決定する。詳しくは、この記事を見るとわかります。

Bancor Protocol はトークンエコノミーを支える大発明となるか？（前編） – Akinori Machino – Medium

クリエイターさんがトークンを発行できるようにと言うのを考えていました。

Webでの活用を考えると、トランザクションを意識したり、トークンが発行されるのを待つみたいなのが必要になります。さらに、Webとブロックチェーンの間でどう管理するかみたいなのが考えるの大変です。

個人支援プラットフォームでクリエイターがチケットを発行できるようにして、ファンクラブに入りたい人にチケットをうる、将来クリエイターが活躍するとチケットの価値が高くなるみたいなのを考えていて、そこでBancorを使うことを考えているのですが、そもそもBancorが有効かというのを試せるようにしようと思いました。

Bancorの実装はGithubにあるけど、それを使わずに、Webアプリだけで、RubyやPythonで実装してみたほうが、スピードもあるしWebアプリで使いやすいしいいのではないかということで、方程式などをシミュレートできるRuby実装を作って、Webアプリで検証できるようにした

bancor | RubyGems.org | your community gem host

ホワイトペーパーに、価格はこんなふうに変わりますというスプレッドシートがあって、それで確認できました。

コンソールで打って、価格が変動している様子をシミュレートできるようにした。

Webアプリを作って、写真家の人が活動を紹介してチケットを売るみたいなものを作った。

こういうものでは本来、買う人が居ないと売れないので、あまり知られていない状態でチケットを発行すると言って売っても、売り買いが起きない。が、Bancorの仕組みでそういうのを解決できる。 それをWebアプリ上で取引で使ってみて実際に自分がやりたいサービスとかで有効性があるのか検証できるようにしました。

作ってみたのはいいけど社内プロダクトで作ったけど、CRRを調整していろいろ試していない。 一回売買して終わっちゃった。

RailsアプリのSandboxを作って小規模のプロジェクトで実験してもらえるようにする予定。 個人がチケットじゃなくてコインでもいいけど、それを発行して売り買いできるみたいなのを作りたい。パラメータ調整どうするかみたいなときに簡単にWebアプリで、小さなコミュニティで実験できるようになったらいいなと思っている。

Sandboxみたいなのを作ってGithubに置いといたらいいのかなと思っている。

最近のBancor

最近のBancorは、6/12にBNT一周年。コンバージョンが2100万ドルを超えて２７０００以上のウォレット間で１０億以上のトークンの取引をした

ケニアで、Grassroots Economics非営利団体と協力して、世界初の流動性のある地域通貨を実現。 TREZORサポート、Bancor Walletからトークン送信時にガスを調整できるようになりましたとか。

LIQUID EOSというやつで投票システムみたいな実験をしているみたい。

Bancor Japanというのが最近誕生。 RubyKaigiでの発表をきっかけに声をかけられ参加することに。 日本のコミュニティマネージャーを探しています。 英語ができてBancorがわかって日本語が話せればいいらしいので、 僕か @amachino さんあたりにご連絡いただければ紹介します。 日本語Telegramも出来たので質問したり、英語ですがBancorの中の人に質問したりできます。

Factchain: The Decentralized Factcheck Network

@amachino / @y_matsuwitter

こんばんは。Hi-Etherコミュニティを去年立ち上げた @amachino です。 今日の発表はHi-Etherとは関係ない話です。

趣味でベランダにマイニングリグを作って動かしていましたが、熱くて冷えないです。昼間は止まっちゃって動かない。早く涼しくなってほしい。

今日はFactchainというプロジェクトについて。松本さん含めていろんな方に関わっていただいている。私の方から概要と、そのあと松本さんからシステムプロトタイプ開発を発表させていただきたいと思います。

概要 @amachino

分散ファクトチェックネットワーク

ファクトチェックとは、インターネット上などの情報に関して審議検証を行う作業。

大統領選で顕在化したフェイクニュース問題(SNSに嘘の情報が拡散して投票行動に影響を与えた)、日本のキュレーションサイトで起きた医療デマ問題(WELQなど、健康や命に関わる誤った情報が検索結果の上位に表示される)など、テクノロジーの進歩が図らずも虚偽情報の拡散を用意にしてしまった。個人が簡単にパブリッシュで来て世界中に簡単に拡散できる基盤が出来上がり、フェイクニュース問題も広く広がった。

そこから注目を集めている。

私もメディア業界に携わっていて、テクノロジーが生んでしまった闇を、テクノロジーで解決したいと思っている。思いを共有する数人の方々、SmartNewsのAtsuo Fujimura、Gunosy Yuki Matsumoto、Ex. TechCrunch Japanの Ken Nishimura、そして私 Ex. SmartNews Akinori Machinoが発起人となってFactchainプロジェクトを立ち上げた。

対象は幅広くて、政治分野、医療・健康分野、仮想通貨分野といったところに対して必要になってくるかと思っている。

ファクトチェックという活動を考えたとき、おおきく３つ課題があると思っている。

  • ファクトチェックすべき情報が膨大にある
    • 一つ一つを確認することは不可能
  • 経済的インセンティブの不足
    • 主観的なオピニオンで話をするのではなく、一次情報を探して、根拠を持って真偽を判定する。すごくコストがかかるが、経済インセンティブが全然無い。世界でもファクトチェック団体は立ち上がっているが、慈善的に、不安定な形でやらざるを得ない
  • ファクト・データ流通経路の不在
    • コストを掛けてファクトチェックをしても、その結果が流通しない。一般の、拡散してしまった人々に届かないし、拡散を抑制することに活用されていない。

そうした３つの大きな問題がある中で、テクノロジーで解決できる部分があるはずだよねと。

  • 機械学習による疑義情報の絞り込み
    • 情報量の多さは、機械学習などによって、機会だけで真偽判定はまだできないが、人間がファクトチェックすべき情報を発見する、数を絞ることには活用できると考えており、そこをアルゴリズム的にやりたい。
  • トークンを用いたインセンティブ設計
  • 中央不在のファクトデータベース
    • ある情報の真偽は特定の個人・法人が作成管理するのは、政治利用される可能性を考慮するとあまり良くない。分散的に運用して、活用されるのが良い

Factchainはオープンプロジェクトとして整備していく予定。

協力いただける開発者や企業を募集しています。

興味が湧いた方へ、明後日、FIJ(FactCheck Initiative Japan)主催のファクトチェックセミナーがあります。

ＦＩＪセミナーを開催します – ファクトチェック・イニシアティブ

Factchain MVPの現状について Gunosy @y_matsuwitter

実際実装進めているところについてお話したいと思います。

どういうユースケース、アーキテクチャ、課題。ゆっくり進んでいてまだまだ詰まっていないところがあります。意見を集めたいので懇親会などでぜひツッコミをください。

GunosyのCTOをやっている松本です。ブロックチェーン周りで、GunosyはLayerXという新しい会社を作ってそちらでブロックチェーン専業会社としてやっています。

Factchainがどういうことをしているのか、どういうユースケースを想定しているか

ファクトチェックすべき候補を絞り込む、インセンティブを与える、透明性を保つというのを全部一気にやるより、ひとつずつ固めようと思ってやっている。

まずはワークフローを完成させるところ、簡単なものを作ってみて、どれぐらい使えるかやってみようというのをやっているところ。トークン付与は、どういう行為で付与するかは、ファクトチェックをする人間（どうしても人間がチェックする）の負荷を下げる方向にトークンを付与していく必要がある。

利用価値を本当に出すためにはトークンをどう使うかとインセンティブデザインが必要だが、まずは、それ以前の部分を先に作ってしまおうというのをやっている。

登場人物は３名。URLに対して、Fakeと思しきものを提出する人、それに対して多数決投票する人たち、本当にファクトチェックする段階、がある。

Claim Reviewフォーマットに従ったデータを作ると、Googleが認識してくれて検索結果に表示されるようになる。FactCheckerがClaim Review Formatを最終的に作るワークフローを目指してやっていく。

Crawler、Voterは怪しいURLを収集する。Face角度の高いURLを提供することにインセンティブを持つ。FactCheckerに以下にFake角度の高いURLを提供するか。Fact Checkする人間が最も重要なリソースであると考えている。 最終的に、Fact CheckerのFact checkによってFake判定がfinalizeされる。

全体的な設計主眼 Factcheckerの負担を下げる方向にインセンティブが働くように設定する。 全部FakeなURLが渡されるのが100% Fact checkerを活用している状態だと言える。

  • Filtering
    • 全世界の中のURLの中からFake newsに近いURLを抽出する
      • 器械によるクローリングを想定している
  • Prioritize
    • ユーザーによるという表を通じてFake newsかどうかのコミュニティスタンスを表明
      • 医療（命に関わる）、政治（国の方向を変える）ものは重要
      • Fakeにも需要度がある。より重みのあるものからチェックする必要がある
  • Fact Check

クローリングの仕組み

SmartNewsさんが試作されているシステムが有る。URLリストを提出する前にDepositを要求する。より角度の高いFakeURLを、より早く提供して欲しい。 Fact Checkされない場合は一定期間後にDepositを返却する。Fakeならリワードを与える。

VotingはURLに対してFakeかFakeじゃないか投票し、当てたほうがリワードを得る。 Fact Checkerは投票状況を見ながら（どう並び替えるかは運用の中で決める方針）チェックするものを決め、チェックする。

どういうアーキテクチャでやるか、基本的にはWebクライアント、Ethereum、APIの3つで、Webフロントエンドは通常のSPAでMetamaskなど使ってやる。

Ethereum側について

トークンと、Workflow関連コントラクト。workflowはCrawl, Vote, Fact Checkの各アクションを実装。

BackendはFact Checkデータの永続化を行う。検索を提供する ユーザービリティを提供しないといけないので、テスト版としては中央集権で。

将来的にはIPFS化しても良い。

課題

  • トークンの用途と消費のされ方
    • 価格がつかないと付与されたトークンが価値を持たない。インセンティブにならないといけないので市場売買される必要がある。それには用途が必要。データ利用でトークンを消費するなどを検討しているが、データの透明性に逆行するのでいい方法はないか検討している。
  • 用途ができても、対価として、作業に見合うと思う価値が着くのか。
    • インフレ通貨設定すると価格維持が難しい
  • スコアリング
    • ICOホワイトペーパーはAIによるスコアリングというが、だいたい中央集権。どう分散的に行うかが課題。

課題だらけで設計が始まったばかりぐらい。時間もまだまだ使えていない。幅広くご意見、ご協力いただきたい。

QA

Q: Voterも機会でできそう

A: データが必要だが、出来ると思います。そのデータを集める仕組みにもなる

Q: ？？？？

A: ファクトチェック済みのバッジをつけるとかはあってよいのではという意見も上がっている。そうした意見を検討していきたい。

Q: スピードは意識されているのか、占拠の3日前に大きなネタが出てきたとき、結果が後では困る。時間には勝ちがあると思う。どう考えているか

A: クロールの先着順などのインセンティブや、Votingをどこで締め切るか、いろんなインセンティブの作り方があると思う。海外のオラクライズのプロジェクトとも議論して、やはり大事だと思っている

Q: ？？？

A: メディアサイドから使えそうなデータになると思うが、そうなるかどうかを試さなければというところ

Generalized state channel @veryNR

State Channnel、その分野の代表的なGeneralized State Channnel。スケールするDappを作るにあたって大事だが、Plasmaに比べて注目されていないので紹介したい。

オフチェーンで状態遷移をして最終結果だけ書き込む方法。具体的には参加者間でChannnelをオープンしてステートをマルチシグでロックする。オフチェーンで状態遷移をコミットメントして、チャンネルをクローズしてオンチェーンに反映する。Lightning Networkなどで有名。EthereumではPayment以外でも応用できる。

  • Payment Channnel
    • Raidenが最も有名、Liquidity Networkが頑張ってて先日双方向に成功している
  • Application-specific State Channnel
    • 特定アプリケーションに特化したチャンネル
    • FunFair, Gnosis
  • Generalized State Channnel
    • 今日お話したいやつ
    • アプリケーションに依存しないState Channnel

Game-changing blockchain casino technology - FunFair

オンラインカジノを全部オンチェーンでやったら大変。これをStateChannelでやろうとしている。

新しいアプリケーションを導入すると気温チェーンの操作が特に必要ないチャンネル。

すでに別の目的で開いていあるチャンネルを別のアプリケーションを利用するときに活用できる。

Perun, Celer Network, Counterfactualなど、ココ数ヶ月でホワイトペーパーが続々公開されている。

今日はCounterfactualを取り上げる。L4 Mediaが提案するGeneralized State Channelフレームワーク。チャンネルを開くのに必要なのはマルチシグウォレットのデプロイだけ。

Counterfactualってなにか。単語にこだわりがある。State Channnelの本質的な概念。

  • "Counterfactual X" というとき...

    • Xがオンチェーンでいつでも起きるけど、まだ起きていない。
    • 参加者の誰でも一方的にXをオンチェーンで起こせる
    • 参加者がXが実際に起きたかのように振る舞える

  • 取引情報に全員が署名することでその取引はCounterfactualになる。

    • Lightning Network はトランザクション自体に署名
    • RaidenはJSONに署名してオンチェーンに署名検証のロジックがある

  • 古い状態もCounterfactualでのこる

    • フリ状態が提出された場合のChallengeの仕組みも必要
    • Counterfactual & Challenge 可能というのがGeneralized State Channelの状態遷移

  • 任意のアプリケーションの実行をオンチェーンなしに実現するには

    • まだデプロイされていないコントラクトを参照する方法
      • アドレスがわからない
    • マルチシグウォレット - チャンネル解説で必要なユイツのコントラクト
      • 一般的なマルチシグウォレットと同様の機能
      • executeTransaction関数
    • デポジットのアサイン
    • 基本プロトコル
      • Instantiate
      • CommitWithdrawal
        • stateを参照した引き出しにコミット
      • Update
        • State更新にコミット

  • Meta Channnel

    • Counterfanctualにおける仲介のしくみ
    • 各中継チャンネルでAlice-Bob Payment Objectの残高のProxyObjectへの反映をコミットする。詳しくは別の機会に。

Dappsゲームから読み解くCentralizedなDapps @biga816

Centralized Dapps to read from Dapps game - Speaker Deck

Trident ArtsでDapps絶賛開発中。

DAppsゲームは本当にDecentralizedなのか？

DAppsとは、非中央集権型アプリケーション。大石さんの定義→DApps (非中央集権・分散型アプリケーション)とは何か?なぜ重要か? | ビットコイン研究所

ではCryptokittiesの構成を見てみましょう。

Client ←→ Heroku ←→ Ethereum

herokuがReactのWebアプリケーションをブラウザにかえして、WebアプリがデータをAPIに取りに行きます。マーケットプレイスとかはブロックチェーンを直接見ると検索とか上手くできないのでAPI叩くのはいいかと思うが、MyKittiesを取得するためにもAPIサーバーを叩いている。

どこでブロックチェーンをつないでいるかというと、kittieを売る、買うというときに、Metamaskを使ってトランザクションを発行している。

猫の画像もGCPのファイルサーバーに乗っているだけ。

すごい中央集権感があるなぁと。

APIサーバーにあるデータをどうやって得ているのかは、バッチ処理やEvent監視でデータを反映しているんだろうなと思います。

コントラクトは非中央集権可と思いきや、KittyAccessControlというのがあって、onlyCEO関数、onlyCFO, onlyCOOとかがある。で、全部の更新を止める関数とかがあって、CEOが怒ると全部止まる。

Etheremonも、かつてはブロックチェーン見てたけど、API見るようになっていて、スケーリングやパフォーマンスを考えるとそうなっちゃう。

Etheremonほど中央集権感丸出しではない名前だが、onlyOwnerとかでパラメータを変えたりモンスターを作ったり出来る。

もう CApps, CentralizedAppではないか。ブロックチェーンを活用したアプリケーション。

非改ざん性や透明性といったブロックチェーンの特性を生かしている。

...面白いクソみたいなDAppsを作っていきましょう！！

protobufによるフレキシブルなコントラクトデータの管理 @umegaya

qiita.com

今日はDAppの運用にprotobufを使う話し。なぜそう考えたか。ゲームサーバーフレームワークとしてEthereumを見ると思うことがあった。という話を先にさせていただきます。

コントラクトのコードはimmutable、コントラクトのデータ構造はコードでしか定義できない。

コントラクトのデータ構造はimmutable。

最初にないデータが必要になったらどうするのか。

ゲームが発展するとデータ果たしたい。データのマイグレーション。- サービス運用では避けて通れない重要な問題。

巨人の方に乗ろう。みんなどうしているのか

丸コピー

ロジックとデータを同じコントラクトに置くと否応なしにこうなる。 データを新しいコントラクトにコピーする。

ストレージコントラクトとその拡張

ロジックとデータを扱うコントラクトを分離する。 追加データはほにゃららExtraを作りそこに置く。Extra2, Extra3…となっていく？

protobufを使うとうまくいくのではないか

Googleが開発したIDL。複数のアプリケーションで共通データを交換するためのツールセット。

message Foo {
  uint64 id = 1;
}

これがいろんな言語のコードに出力される。これのバイナリフォーマットがナイス。

データスキーマを protobuf で定義する。コントラクトにはbytesとして保存する。

FooServiceは各データスキーマの現バージョンを持っておく。スキーマのバージョンを上げるときはFooServiceの新しいバージョンをデプロイする。データのコピーが発生しないように、Storageにデータはおいておく。 新しくデータを作るときは、今のバージョンで保存する。読み出すときは、古いバージョンのデータなら必要な処理をやってあげる。

このやり方を使うメリットは、 protobufでserializeされたbytesを返す関数を作って、受け側でdeserializeする ABIEncoderV2不要で、すでに実用的な大部分の言語で利用できる。

ところでsolidityでprotobufは使えましたっけ？

コンパイラはあった。Haskellで書かれたVersion2用。

というわけで作りました。

umegaya/pb3sol: protobuf3 compiler plugin for solidity and protobufjs integration support

pythonでprotobuf3のコンパイラ実装。

スターください