Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ブロックチェーン基盤比較_向き不向きの観点でユースケースを考える.pdf

 ブロックチェーン基盤比較_向き不向きの観点でユースケースを考える.pdf

* エンタープライズブロックチェーン基盤比較に求められる観点について
* チェーンの基本性質からみるユースケースの向き不向き
* プライバシー・interoperabilityの観点について
* パフォーマンスの観点について

More Decks by Masashi Salvador Mitsuzawa

Other Decks in Technology

Transcript

  1. 2 CONFIDENTIAL : © 2019 LayerX Inc. LayerXのミッション すべての経済活動を、デジタル化する。 ブロックチェーン技術をもとに、「新たな経済基盤」をつくりだす。

    それは、信用や評価のあり方を変え、 業務や生産をはじめとした経済活動の摩擦を解消し、 この国の課題である生産性向上を実現する。 私たちは、そう信じて行動し続けます。 ブロックチェーンが実装された社会、 そこには、これまでの延⻑にはないまったく新しい可能性が広がっている。 LayerXは、デジタル社会への発展を後押しすることで、 経済史に新たな1ページを刻んでいきます。
  2. 3 CONFIDENTIAL : © 2019 LayerX Inc. 三津澤 サルバドール 将司

    Masashi Salvador Mitsuzawa @MasashiSalvador Lead Engineer @ LayerX 発表者プロフィール • 金融中心に複数のプロジェクトの技術リード • LayerXには創業当初からジョイン • 好きな言語 Go, TypeScript, Haskell • 最近鬼滅の刃の壮絶なネタバレを喰らいました
  3. 4 CONFIDENTIAL : © 2019 LayerX Inc. #1 BC基盤比較の比較要件・評価軸について #2

    ビジネスロジック実装に際する得意・不得意 #3 プライバシー・interoperabilityに関する比較 #4 パフォーマンスの観点について Agenda
  4. 6 CONFIDENTIAL : © 2019 LayerX Inc. テーマ:チェーン選定 BC基盤選択 ….

    なかなかに難しい • 「Cordaは金融資産用のライブラリが標準で存在して...」 • 「EthereumベースだとERC20等の標準規格が使えて...、Fabricは標準トークンはないらしい」 • 「秘密鍵の管理法とか違いあるのか?」 • 「エンドユーザもノードを持たないといけないのか?」 • 「Solidityは結構癖が強いから開発生産性が....」 ◦ 「EVMつらいってツイッターに書いてあるぞ」 ◦ 「Fabricの環境構築が大変だってツイッターに書いてあるぞ」 ◦ 「そんなことはない」 • 「あああああああああああ!!!!」
  5. 7 CONFIDENTIAL : © 2019 LayerX Inc. BC基盤比較をする際に気をつけるべきこと • 各BC基盤のbuilt-inの本質的な差異を客観的に整理する

    差異がユースケース・ビジネス要件に影響するかを検討する BC比較基準に求められるもの • 理論的な整理に基づき客観的な分類・整理を行い比較 • 向き・不向きの評価の理由を解説 • 極力 ‘フェア’ に意味のある比較軸を検討 客観性 設計パターンの提示 • 実際のBC基盤選択者の検討に資するよう、設計上・実装上の制約と設 計パターンを明確化 運用の観点 • 最大瞬間風速での比較ではなく、中長期目線での比較へ • BC基盤の長期的運用を見据え、BC基盤上で自然に実装しやすいユー スケースについて検討 • 運用に必要なエコシステムについても検討
  6. 8 CONFIDENTIAL : © 2019 LayerX Inc. LayerXのBC基盤比較:4つの評価軸 + α

    • アプリケーション実装に際し、向き・不向きの検討 • コンソーシアム組成の際、参加者の技術的・ビジネス的負荷の検討 基本機能・基本設計 • 何をどう隠すことができるのかの整理 • セキュリティの観点(可用性・真正性)でプライバシー機能を評価 • プライバシー機能の設定の柔軟性の評価 プライバシー • 他のBCサービスと接続する際の設計・実装パターンの類型化 • 各BC基盤との接続の難易度・留意点などの差異を明確化 interoperability • 先行研究を参考にBC基盤に求められるパフォーマンス指標を整理 • 特殊な条件下での最大瞬間風速ではなく、特定のユースケースのパ フォーマンスを計測・比較 パフォーマンス • ガバナンス・開発者の数・開発容易性の評価 • ライブラリ・関連ソフトウェア・クラウド対応状況を評価 • R&Dプロジェクトの数やプラグイン実装の容易性などを評価 エコシステム (環境・柔軟性・拡張性)
  7. 10 CONFIDENTIAL : © 2019 LayerX Inc. LayerXのBC比較で取り扱うブロックチェーン • JP

    Morganが開発するEthereumベースのブロックチェーン基盤 • Ethereumの基本機能に、プライバシー保護技術が付加 • JPM Coin, Project Ubin, Project Khokha等 • R3の開発するブロックチェーン基盤 • 取引当事者間でのみtxを共有することによるプライバシー担保 • ネットワーク構築・ワークフロー作成用の豊富なソフトウェア群 • Marco Polo, HSBC, Project Jasper等 • Linux FoundationのHyperledger Projectの1つ、IBMが主に開発を主導 • built-inのプライバシー保護技術・アプリケーション単位の柔軟な承認ルー ルの設定 • IBM Food Trust等多数 • Amazon QLDB … 単一主体内のデータのトレーサビリティ担保のための 台帳データベース • Hyperledger BESU … Ethereumベースのプライバシー保護技術が組み 込まれた基盤・豊富なネットワーク管理・構築ソフトウェア群 • substrateもエンタープライズユースケース向けパッケージが存在
  8. 12 CONFIDENTIAL : © 2019 LayerX Inc. 各ブロックチェーンで共有されてるデータとは? • 宛先アドレス

    • 送信者の署名 • 実行する関数名+引数 or バイトコード • ナンス、ガス等 • inputのUTXOsとoutputのUTXOs • txHashへのtx関係者の署名 + Notaryの署名 • 検証ルール・必要な署名 • txのtime-window • RWSet (tx前のstate, tx後のstate) ◦ keyのバージョン • 実行する関数・引数 • endorserの証明書・署名
  9. 13 CONFIDENTIAL : © 2019 LayerX Inc. コンセンサス・トランザクションフロー • txを取引当事者で署名しNotaryへ

    • Notaryが署名するとfinalize • initiatorが起点となってtxを中継 • blockという単位はなくtx単位で処理 • 普通のノードは全データを持たない • propose -> ordering -> validate & commit • Ordererがtxを順序付け • Ordererがblockをbroadcast(finalize?) • 各ノードは全tx/blockを保持 • pre-prepared -> prepared -> commit • validatorはtxの状態遷移を検証 • tx / ブロックは全ノードにbroadcast • 2N/3以上の署名でfinalize
  10. 14 CONFIDENTIAL : © 2019 LayerX Inc. ビジネスロジックの実装方法・考慮点 スマートコントラクト オフチェーンのロジック

    • 開発言語 • データ設計(アセット管理の単位等) • 標準データ形式の有無 • セキュリティ上の考慮点の有無(re-entrancy等) • 台帳上のデータをどの程度利用できるか • SDKの対応言語・使いやすさ(tx作成・イベント監視) • 署名収集等のワークフローが作りやすいか • 台帳のクエリ性能 • 台帳外のindexが作りやすいか
  11. 15 CONFIDENTIAL : © 2019 LayerX Inc. 特定のキーに頻繁な書き込み データ設計に要工夫 得意なユースケース・不得意なユースケース

    得意 不得意 特定のキーに頻繁な書き込み マルチシグ(Workflow作成が容易) 台帳へのクエリ 標準規格(ERC20, ERC721) の承認・移転 グローバルな値を見る必要がある場合 assetの全移転に署名するノード必要 台帳へのクエリ 複雑なデータ構造(EVMの限界) 柔軟なキー設計 台帳へのクエリ 柔軟な検証ルール設定 chaincodeA :2 of 4 chaincodeB: A + 1 of 3
  12. 16 CONFIDENTIAL : © 2019 LayerX Inc. 運用を見据えて:アップデート・アセット管理 etc •

    スマートコントラクトは工夫をしない限りアップデートできない • EVMに引きづられる形でaddressにアセットが紐づく設計になりやすい • コントラクトはアップデート可能 • キー設計の自由度は高い(アセットをどのキーに紐付けるかの自由度高い) • プラグインによる検証ルールの追加(Endorsement plugin) • Contract(検証ルール)・Flow(ワークフロービルダー)共にアップデート・配布可能 • NotaryのFlowに対して検証ルールを付加することも柔軟に可能 • アセットは公開鍵に紐づく設計になりやすい
  13. 18 CONFIDENTIAL : © 2019 LayerX Inc. 実ユースケースではデータを共有したいが全てを見せたくないという要件は必ず存在する • 商流データから算出したスコアは公開していいけど、生の商流データは見られたくない

    • リアルタイムで証券の注文の情報が公開されるのは困る • 取引している証券の銘柄が公開されるのは困る、残高も隠したい ユースケース例 各チェーンのPET Private Data Private State Non validating Notary • 同じカテゴリの技術 • 共有先を限定 ◦ コンセンサスノードもTxを全て検証するわけではない ◦ グループ外のユーザはTxを検証しない • グループ内のユーザは全員honestである前提 ◦ accountabilityなしに情報を漏洩できる BC基盤比較:各チェーンのプライバシー保護技術 Private Ledger(PL)
  14. 19 CONFIDENTIAL : © 2019 LayerX Inc. プライバシー比較軸 BC基盤比較:プライバシー 秘匿したい対象

    • txの存在・txのタイムスタンプ・txの状態遷移内容... etc • 誰から見られないか(コンセンサスノード・取引当事者以外) • 一見秘匿できていても、ヒューリスティクスで推測可能かも検討 • PLが壊れることがあるか、どの場合に壊れるかを検討 • 壊れる = validity, safety, liveness, data availabilityが破綻する • 壊れた場合に原因が分かるか(accountabilityがあるか)を検討 • 「攻撃が存在する」という意味でセキュリティは同一 • Quorum, HLF 対 Cordaで存在 • PLのユーザ設定の柔軟性に関して検討 • 追加・削除の柔軟性 • コントローラビリティ ◦ 見せる範囲をコントロールできるか ◦ Cordaは遡及的検証があるので... セキュリティ 設定の柔軟性 >(越えられない壁)> になるので助っ人を..
  15. 22 CONFIDENTIAL : © 2019 LayerX Inc. プライバシー比較結果 • CordaはPrivacyは優秀だが、Public

    stateは持ちづらい • HLFはトントンでEndorsement Policyによってはpublic, private 両方のstateを触れる • Quorumは..... となるので BESUを使うと良さそう ◦ Quorum頑張ってくれ... プライバシー比較結果 より詳しくは... 背景のロジック、理論的な詳しい整理解説はレポートに!
  16. 23 CONFIDENTIAL : © 2019 LayerX Inc. ブロックチェーン基盤比較:interoperability 色々なBC基盤上のサービスが発展中で、相互に接続してTxを発行するニーズは高まっている •

    商流データの載るチェーンと商流データを元にファイナンスが実行されるチェーンが別 • 証券決済を行なうチェーンと資金決済を行なうチェーンをつなぐ • データ共有PFを実装するにあたり、他から相乗りしやすい基盤を探したい・ ユースケース例 各チェーンにおける 手法の向き・不向き • 伝達手法によっては相手型チェーンが特定のノードが何をすべきか決まる • 自サービスのチェーンの情報を伝達する際に、考慮しなければ行けない点が決まる
  17. 24 CONFIDENTIAL : © 2019 LayerX Inc. ブロックチェーン基盤比較:チェーンのつなぎ方一般の話 チェーン間接続法 2020.05.14

    - Introduction to Cordage v0.2 (日本語) @ blockchain.tokyo Online by @shuntak に詳しく整理されてます  https://docs.google.com/presentation/d/1pTf-jmhg6mCeNAXH2p-eCxXdZtiRYAIFK70ZZB-_slc/edit#slide=id.p10 今後リリースするinteroperabilityレポートでも詳しく解説します。 TTP Relay HTLC Trustless(汎用) Trust Pointあり(汎用) Trustless(特化)
  18. 25 CONFIDENTIAL : © 2019 LayerX Inc. BC基盤比較:interoperabilityの軸で interoperability比較観点 •

    チェーンの接続方法をRelay・TTP・HTLCに類型化 • 各接続方法のセキュリティの仮定を含む性質を明確化 チェーン間接続方法 • 各手法(Relay・TTP・HTLC)ごとに自サービス上の誰が何の役割をするべき かを明確化 • 接続先チェーンに求められる要件の明確化 各チェーンでの 設計パターン • 各手法の各チェーンにおける実装難易度を総合的に検討 ◦ 十分なライブラリがあるかないか ◦ 署名アルゴリズム・ブロックデータのパーサ等...etc 実装難易度等 チェーン間接続法 は相対的に優秀 は実装上の工夫が必要 (VN) (NN)
  19. 27 CONFIDENTIAL : © 2019 LayerX Inc. interoperability: LayerX’s solution

    blockchain.tokyo Onlineの発表資料: Introduction to Cordage by @shuntak GitHub https://github.com/LayerXcom/cordage Gitter chat https://gitter.im/LayerXcom/Cordage
  20. 29 CONFIDENTIAL : © 2019 LayerX Inc. BC基盤比較チームの取り組み:パフォーマンス パフォーマンス比較観点 パフォーマンス指標の

    明確化 パフォーマンス計測 ツールの比較 • スループットに限らない指標: Latency(e2e), Network Latency等を整理 • 各基盤ごとにどこで計測するのがフェアな計測値かを検討 • Blockbench (NUS), Hyperledger Caliper含むツールの検討 • 指標を正確に計測できていないツールに関してはカスタマイズ 先行研究 最大瞬間風速 計測ツール・手法 • Blockbenchはベンチマーク用のワークロードのパターンを整理 • Hyperledger CaliperのPSWGのペーパーに計測値の定義が整理 6300 tps? 617 tps 2100 tps 2700 tps Thakkar et al. Baila et al. R3 blog etc.