Oracle Blockchain GIG#5

Oct 10, 2019

Blockchain GIG #5

• ハッシュタグは#blockchaingig

Oracleさん #

ユースケース #

• 食品のトレーサビリティ
• 貿易系
• 人事情報・学歴情報
• サプライチェーンが多い
• コバルトのトレーサビリティ
• 医療情報の共有
• サプライヤーの共有
• GEのインターカンパニーの売掛・買掛をブロックチェーンで管理しよう
  • インテグレーション・見える化・
  • データーの連携レイヤーをブロックチェーンで使った
  • 6週間で作れた

ベスプラ #

• チャネルとはサブネットワークに分けるもの
• ChannelとPeerの関係
• Transient Data
  • 台帳に含まれないようにChaincodeに引き渡せるデータ
• Pravate Data Collection
  • プライベートデータを持つノードを事前に決めておく必要がある
• 暗号化
  • 鍵交換問題
  • Transient Dataを使って共通鍵を引き渡す
  • 暗号化アルゴリズムは稀代化する
  • 誰をどの程度信頼するか
    • デフォルトではPeerにアクセスできれば台帳が読める
    • Peerも結局のところOS上のプロセスの一つなので、ホストマシンをキチンとセキュアにする
• アプリケーションとスマコン
  • スマコンをチェインコードという
  • 台帳に全てを書こうとしない
  • ワークフローはアプリケーションで行う
    • １企業内でのワークフローはアプリケーションで行う
  • スマコンは必ず決定論的にする
  • ワールドステートの現在状態と引数のみに依存するようにする
  • PushではなくてPullでスマコンを行うようにする
• パフォーマンス
  • ネットワーク構成
    • Channelの構成
      • プライバシーの構成に応じてChannelを分ける
    • Peerの構成
• World Stateへのアクセス
  • アクセスするデータの最小化
    • Read/WriteされるKeyを出来る限り最小にする
    • 大規模クエリや分析などはオンチェーンでの処理には向かない
  • SQL Rich クエリは使えない
• Oracle DB 20c
  • 行をハッシュ値で繋いだTableです

富士通さん #

ミッション #

• ブロックチェーンをSEが使いやすい状態に仕立てて提供・運用すること
• PaaS化して自動運用
• 短期開発のため、システム/アプリケーションの開発に密に関わる

SEが躓くHyperledger Fabricの壁 #

• 複数のPeerにリクエストする必要がある
• スマコン(チェーンコード)の開発
  • データとストアとしてStateDB(KVS)を持つアプリケーションのようなもの
  • 基本的には案件ごとに開発する必要がある
  • どこまで考慮するば良いかの線引きが難しい

SEが躓かないための解決策 #

• 使用性向上機能を設ける
  • RESTサーバーを設ける
  • ユースケース別チェーンコードを設ける

トラブル事例１(不自然な画面遷移) #

• スタンプラリーPoCのアプリ開発における事例
  • アプリからトランザクションが複数投げられてた

原因 #

• クーポン・スタンプに対する認識の違い
  • 来店前に用意するもの・来店後に用意するもの

対策 #

• １度のコールでメソッドを複数実行できるメソッドを追加した(バルク実行)
  • 一度にバルク実行するメソッド群に依存会計が無いことが前提
• アプリ側で吸収する
  • 処理をまとめる発想を捨てて、違和感のない箇所に分散させる
  • 違和感を消すために、同期・非同期で処理させる

テスト工程でエラーが発生する #

• 遅いPeerでエラーが発生する
  • ノードの配置はAnti-Affinityポリジーを守ってた
  • Anti-Affinityポリシーとは可用性のためにノードを物理的に分散化させること

原因 #

• 遅いPeerのトランザクションより先に速いPeerのトランザクションが処理さえる

解決策 #

• 遅いPeerのために待ってあげる

RFTの時にお客様から #

• トランザクション・チェーンコード・ステート・ブロックを事前に説明する

開発リードタイム短縮も大事ですが #

• 構想通りのブロックチェーンシステムが出来たか評価する
• No Block, No Life

LayerXさん #

DApps開発特有のハマりポイントご紹介 #

• アプリ開発の1つのコンポーネントとして使う

アジェンダ #

• DAppsのアーキテクチャ全体像
• Indexer
• イベント駆動のトランザクション実行
• コントラクトデプロイのフロー
• UX

DAppsのアーキテクチャ全体像 #

• サーバーが必要
  • MetaMask
• Indexerが必要
  • コントラクト上にあるデータをDBなどにキャッシュする
    • 二重実行されてないことを確認する
    • indexing済みの次のブロックからログを取得する
    • 取得したイベントのログの数だけループする
  • Quorum-indexer-DBの流れにする
  • DB-APIにする
• Quorum, indexer, API, DB, App

イベント駆動のトランザクション実行(ignitor) #

• トランザクションのイベント発火を起点として別のトランザクションを実行する
• トリガー専用のイベントを用意する
• 失敗専用のイベントを発火する。失敗をrevertとするのではなくて。

ignitorとindexerとの協調 #

• ignitorとindexerを完全に独立させることはできない
• indexerは1ブロックに含まれるイベントをatomicにDBに保存しているので、

コントラクのデプロイフロー #

トランザクション実行中の状態をどうするか？ #

• 途中のAPIで表示処理する

ディスカッション #

現実での紐付け問題はどうするか？ #

ブロックチェーンがはまるところは #

• 需要と供給が公開される市場