Download as PDF, PPTX
Uploaded byDaisuke Shimada
既存システムに対するブロックチェーン適用の検証と考察
2016/09/30(金)に開催された「オルトプラスラボTechセミナー2016 Fall」で話した内容です。
![[Modern Cloud Day Tokyo 2019] 実践エンタープライズ・ブロックチェーン ～ システム設計・運用における課題とそのソリューション](https://cdn.slidesharecdn.com/ss_thumbnails/mcd19e-8-190826052420-thumbnail.jpg?width=640&height=640&fit=bounds)
既存システムに対するブロックチェーン適用の検証と考察
- 1.
- 2. 目次 • BlockChainのあゆみ • 既存システムへのBlockChain適用と考察 •AltPlusの今後のBlockChainへの取り組み 1
- 3. 株式会社オルトプラスについて • 会社設立日：2010年5月6日 • 拠点：渋谷、ベトナム、韓国 •従業員数：300名(全体) • 事業： • ソーシャルゲーム • ゲーム運営移管 • オフショア開発 • 広告事業 • 起業支援事業など 2
- 4.
- 5.
- 6.
- 7.
- 8.
- 9. 自己紹介 • 嶋田 大輔(@cimadai) • 株式会社オルトプラス ラボメン • お仕事 • ラボでR&Dしたり、勉強会開いたり。 • オフショアの案件を対応していたり。 • 書いた本 • JavaScriptテクニックバイブル • すべての人に知っておいて欲しいJavaScriptの基本原則 • 最近のトピック • 筋トレと食事制限で半年で6kgの減量に成功！ • 来月は自転車でしまなみ海道を走ってきます。 8
- 10.
- 11. 2009年 01月 Bitcoinのgenesis blockが生成される。 01月 Bitcoin v0.1がリリース。 2010年 07月Mt.Gox取引所が公開。 09月 マイニングプールの原型ができる。 (採掘報酬の分割支払い) 2008年 10月 Bitcoinのホワイトペーパー公開。 2013年 09月 Ripple公開。 2013年12月〜2014年3月頃 多くのAltcoinが公開。 BlockChain関連年表（2008〜2016年） 10
- 12. 2014年 02月 Mt.Goxが破綻。 2015年 03月 NEM公開。 07月Ethereum公開。 09月 Orb公開。 09月 R3コンソーシアム発足。 12月 Hyperledger Project発足。 2016年 02月 mijinオープンβサービス開始。 04月 ブロックチェーン推進協会(BCCC)発足。 04月 日本ブロックチェーン協会(JBA)発足。 06月 The DAO Attack BlockChain関連年表（2008〜2016年）
- 13.
- 14. 世代別に見るBlockChain - 第一世代- • BlockChain 1.0 (通貨: Currency) • 暗号通貨、パブリックレジャー、プロトコルによって構成される 原始的なブロックチェーン。 • Bitcoinの実装をオリジナルとして、その後改変・改良が重ね られている。 • 実装例 • Bitcoin (の実装としてのBlockChain) • Litecoin, Dogecoin, Monacoinなど各種Altcoin 分散台帳 プロトコル 暗号通貨 13
- 15. 世代別に見るBlockChain - 第二世代- • BlockChain 2.0 (契約: Contract) • 通貨の概念の上位に、金融やリーガルの概念を載せたもの。 • 金融 (ローン、住宅ローン、証券、債権、先物、デリバティブ) • リーガル (権利証書、譲渡証書、エスクロー、遺言、個人情報、契約) • これらはスマートプロパティやスマートコントラクトを利用して 実現される。 金融、リーガル 分散台帳 プロトコル 暗号通貨 ローン、証券 債券、先物 デリバティブ、 権利証書、 譲渡証書、 遺言、契約等 14
- 16. 世代別に見るBlockChain - 第三世代- • BlockChain 3.0 (アプリケーション: Application) • 通貨、金融、リーガルといった領域の上位に、金融以外の サービス（政治やヘルスケア、科学、文学、芸術、知的財産 など）を載せる。 • 特定分野における応用的利用。 金融、リーガル 分散台帳 プロトコル 暗号通貨 ローン、証券 債券、先物 デリバティブ、 権利証書、 譲渡証書、 遺言、契約等 金融以外のサービス 政治、ヘルス、 科学、文学、 芸術、知的財産 サプライチェーン ID、手続き等 15
- 17.
- 18.
- 19.
- 20. この検証について • 今回の試みはブロックチェーン適用の実験的な試み。 • 従ってDBは極力つかわずできるだけBlockChainを利用 するようにする。 •スムーズな動作ができない場合はDBを併用するなど 工夫をするものとする。 • BlockChainのシステムとしてはEthereumを採用する。 • 前ページのよく言われるBlockChainの特性についても 合わせて検証する。 19
- 21.
- 22. 下記のような構成を題材に考える。 A社 B社 C社 共同開発 利用者 ¥P P サービス 付与・使用履歴 このあたりを BlockChainで 実装してみる 21
- 23. １．購買行動時（ポイント付与時） BlockChain Front Web Application ① 利用者による 購買行動 ② 利用者への ポイント付与を登録 ③BlockChainによる ポイント付与の承認 ④ 当該ポイントが 利用可能になる 22
- 24. ２．ポイント使用アクション実行時 BlockChain Front Web Application ⑤ ポイントを使った アクションの実行 ⑥ 利用者の ポイント消費を登録 ⑦BlockChainによる ポイント消費の承認 ⑧ アクション実行の 結果を受け取る。 ※動画や音楽の再生など 23
- 25.
- 26.
- 27. 従来型の方が簡単なのでは？ Front Web Application ① 利用者による 購買行動 ② 利用者への ポイント付与を登録 ③当該ポイントが 利用可能になる Database 26
- 28.
- 29.
- 30.
- 31.
- 32. いくつかの課題が見えてきた • トランザクションの承認が遅い • ポイント残高の確認がやや難あり •ポイント使用時の残高不足がつらい • コントラクトの書き換えがつらい 31
- 33. トランザクションの承認が遅い • 今回の組込みにおいて試した基盤であるEthereumは コンセンサスアルゴリズムとしてPoWを採用している。 • Ethereumのブロックの生成間隔は15秒程度になって いるのでそのタイミングでトランザクションは承認される。 •そのため、購入時のポイント付与、およびその後の ポイント使用におけるトランザクションの承認時に 素直に承認を待ってしまうと、通常のWebアプリでは 考えられない遅さがある。 • →承認を待たずに仮の状態でユーザーにレスポンスを 返すようにして見かけの応答を良くした。 32
- 34. ポイント残高の確認がやや難あり • (前述の通り)コントラクトの実行が承認されるのが遅い ので、購入時のポイント付与のタイミングが承認後に ずれる。 • →いま自分がどのくらいのポイントを利用できるのかが わからないので、手前のDBで仮ポイントを管理する ことで残高予定をわかるようにした。 •実際の使用は承認後に利用できるようになるので、 多少のタイムラグはあるものの残高予定がわかること で不安感は減った。 33
- 35. ポイント使用時の残高不足が辛い • (前述の通り)コントラクトの実行が承認されるのが遅い ので、ポイント使用においてはユーザーの要求時に 即時アクションを実行するようにした。 • すると、残高が1ポイントの時に1ポイント必要な動作を 2つ続けて実行された場合にいずれも実行可能になる。 •この場合、失敗した方のアクションを後から取り消す ことになるが、少しの間だけどちらも実行できてしまう のが気持ち悪い。 • →ポイント使用時に、承認待ち状態を手前のDBで管理 することで残高不足なのに実行できないようにした。 34
- 36. コントラクトの書き換えが辛い • Ethereumのコントラクトは、Solidity等の言語で書いた ものをBlockChainに登録することで利用できる。 • コントラクトはその内部に変数としてデータを保持する 構造になっている。 •登録の際に、コントラクトはそれぞれ異なるアドレスが 付与されるので、少しずつ修正してTry&Errorをしようと すると、その度に新しいコントラクトとして登録されて しまいデータが消えてしまう。 • →データの永続化について、消えないような仕組みを 考える必要がある。 35
- 37.
- 38.
- 39.
- 40. よくあるBlockChainへの印象への感想 • 開発工数自体は変わらないか、BlockChain独自の 実装や工夫をする分、増える可能性あり。 • BlockChain部分に関しては冗長化の仕組みを考慮 する必要がないのでHWコストは下がる可能性あり。 安い •BlockChain内に格納されたトランザクションやブロッ クを書き換えることは実質的に困難なので安全。 • The DAOアタックのように、BlockChainではない所の 脆弱性に起因して攻撃される懸念はある。 安全 • BlockChainを構築するノードの数が多くなるほど 可用性は高まるので、きちんとしたサイジングと ノードのロケーションを考えれば十分に高可用性。 • ただしPoWでは性能はスケールしないので要注意。 落ち ない 39
- 41. まとめ • トランザクションの承認の遅さをカバーする 実装上の工夫が必要。 • BlockChainのコントラクト上だけで情報を完結 させるのは利便性が良くない。 •承認待ちの間と実時間との差異をどう埋めるか の工夫が必要。 • コントラクトのデータの持ち方も要検討。 40
- 42.
- 43.
- 44.
- 45.
- 46.