「ビットコインとか勉強会#13」に参加してきました

タイトル

ビットコインとか勉強会#13 - connpass　（2017.12.11）
cryptocurrency.connpass.com

主催

「暗号通貨読書会／勉強会」運営委員会

会場

株式会社 LIFULL
〒102-0083 東京都千代田区麹町 1-4-4 8F

Twitter

twitter.com

全体の感想など

「ビットコインとか勉強会」の参加はこれで 5回目です。　*1,　*2,　*3,　*4

最近はブロックチェーンの本を読んだりインターネットや Twitter で情報と集めたりしていろいろ勉強をしていて、仮想通貨やブロックチェーンの勉強会に行っても昔と比べて理解度が上がっていると思っていたのですが、「insight」や「electrumx」などのサーバサイドプロダクトの存在は初めて知りました。まだまだアンテナの張り方が足りないようですね。

もう少し話を聞きたかったので急遽、懇親会にも参加してみました。久々でしたが、すごくいい話が聞けました。

今回はどちらかと言うと開発者寄りの話でしたが、実際に手を動かしてコマンドを叩いてみるようなもくもく会的なイベントにも今後参加していきたいと思います。

ビットコインを支えるインフラについて

Yuki Akiyama 氏 (@you21979)（ビットバンク株式会社　ビットコインエンジニア）

「暗号通貨 Advent Calendar 2017 - Qiita」を立てた方だとか。最近では、

などの記事も。

なぜインフラが必要なのか？
- ウォレットを作るときに困るから
- （自分以外の）ビットコインアドレスを指定して未使用のトランザクション（UTXO）の一覧を取得する、などの一見簡単なことができない
解決するプロダクト
- insight, electrumx
- 端末側でウォレットを動かすためのバックエンドサーバ
insight
- Node.js で作られている
- REST-API で簡単に情報を取得できる（これがスゴイところ）
  - 例）https://insight.bitpay.com/api/addrs/{bitcoin_address}/utxo
- 5つの部品から構成されている
  - 魔改造版 bitcoind
  - bitcore-lib
  - bitcore-node（UTXOのデータベース）
  - insight-ui（ブロックエクスプローラの画面）
  - insight-api（REST-API）
- マルチプラットフォームのウォレットをホスティングできる
- まだ SegWit に対応していない（v5 から対応予定？）
  - Confirmされるまで見れない？
- 最新版に追従しにくい。自分で魔改造版 bitcoind にパッチを当てる必要がある。かなり大変
- データベースが巨大。来年には500BG超えそう。。
- 開発が滞ってた？最近活発に？
- オルトコインの対応は？ ⇒ しにくい
  - 開発チームが insight の対応をしているところもあるが（Litecoin, ZCash, Dash, Zcoin）、結構不安定？
electrumx
- ウォレットソフト electrum のサーバサイド実装
- Python3で作られている。作者は kyuupichan
- electrum を使ったクライアント？例えば、Coinomi など
- 最初からオルトコインに対応できるように設計されているのがスゴイ
  - 現在30種類くらい対応
  - coins.py に記述されているコインであれば、設定ファイルに記載するだけで対応可能。
  - 積極的にプルリクを取り込んでくれる
- REST-API じゃないが、プッシュ通知とかがあって便利
- APIの設計が細切れ？になってて、必要なデータを一度で取得できないため、いくつか組み合わせる必要あり
- トランザクションをデコードしてくれない。自分で解析が必要
- システム的に、定期的にメンテが必要。ダウンタイムが必要。オルトコインだと1ヶ月ちょっと？？（ビットコインだと1年くらい）
- ウォレット作るなら十分。他のことをやろうとすると大変？？

しっかり学ぶ ICOのベストプラクティス

千賀優作氏 (@syrohei)（一般社団法人分散技術総合研究所　代表理事）

千賀さんは最強のイーサリアマーだそうです。
RICO をオープンソースで開発中とのことで、それについての説明です。

スマートコントラクトが必要
（EIP20Token以外の）ICOの規格が統一されていない
- 今年のICO の 90〜95％くらいは EIP20トークン？
- Golem, Gnosis は受け取ったEtherを認識できないとか？で ICO が失敗したとか？？
学習コスト、開発コスト、ハードルが高い
セキュリティ的な要件、法的リスクもある
ICOのベストプラクティスとは？
- スムーズなICOを実現するための準備
  - なりすましやフィッシング詐欺に適切な対処が可能
- スマートコントラクトのメリットを強力に活用
  - Trusted なアプリケーションを低コストで稼働
- コードの信頼性を維持
  - 絶対にバグをうまないコードを
RICO と Truffle フレームワークによるベストでナイスな ICO開発
Ethereum のウィークポイント
- Ethereum の tx は一つの tx で一つの method しか実行できない
  - 設計を考え直すこともしばしば
- スマートコントラクトの無限ループが発生しやすい
  - 再帰的呼び出しに弱い（The DAO の攻撃）
- 設計が複雑になりやすい。挙動を正確に把握しないとガスが無駄になりがち
- 構造体が使いにくい（代わりにコントラクトを新規に生成したほうがいい？）
- function() は多用しない（無限ループの脆弱性）
- できる限りグローバル変数（外部変数）は使わない。設計を見直す
- 条件分岐（if else）を多用し過ぎるとテストしづらくなるので、適度に列挙型 enum で状態遷移を明確に
- 常にガスの利用を意識した処理を心がける（ストレージをなるべく使わない）
Truffle は Solidity ベースのスマートコントラクトを作成するのに最適
- 最低限のコントラクト管理機能があり、テストも簡単に書ける
- もはやデファクトスタンダードに
RICO における Proof of Donation による寄付証明とイベントハンドリング
RICO は、ICOに最適化されたオープンソースフレームワーク
- Truffle のテンプレートエンジン
- 誰かが誰かに寄付をした、ということを証明する
- （機能拡張すれば）ホワイトリストにも対応できる