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

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

Cbfc9df248a5bcb1167d7ccb01407b00?s=47 yudetamago
October 10, 2019

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

Cbfc9df248a5bcb1167d7ccb01407b00?s=128

yudetamago

October 10, 2019
Tweet

More Decks by yudetamago

Other Decks in Technology

Transcript

  1. DApps開発特有の ハマりポイントご紹介 株式会社LayerX 神場 貴之 2019/10/10 Blockchain GIG #5 1

  2. 自己紹介 株式会社LayerX 神場貴之(じんば たかゆき) Senior Architect / Engineer Github: yudetamago

    Twitter: @takayukib 好きな言語: Ruby 2
  3. ブロックチェーンそのものの話 ➢ アプリ開発の1つのコンポーネントとして ブロックチェーンを使う時の話 (概要より実践向けの話が多いです) 3

  4. アジェンダ • DAppsのアーキテクチャ全体像 • Indexer • イベント駆動のtx実行(ignitor?) • コントラクトデプロイのフロー •

    UX 4
  5. DAppsアーキテクチャ 5

  6. 6 Blockchain node Frontend (+MetaMaskなど) Q. これで要求を満たすようなアプリケーションを作れるでしょうか? tx送信

  7. 7 Blockchain node Frontend A. このぐらい必要でした indexer API (サーバ) DB

    tx送信 イベント監視 保存 取得
  8. なぜサーバが必要? MetaMaskのようなWalletプラグイン(アプリ)は まだ一般に浸透しているとは言えない 8 秘密鍵?ニーモニック...?

  9. なぜIndexerが必要?(1) 9 Quorum ページング、検索、join、etc ➢ コントラクト側であらかじめ全てを用意しておくのは(一般には)難しい

  10. なぜIndexerが必要?(2) 10 Quorum indexer DB イベント監視 保存 ページング、検索、join、etc API 取得

  11. このスライドでのアーキテクチャの前提 11 Quorum indexer API DB App Quorum indexer API

    DB App ➢ 同じネットワークIDを使っているQuorumをそれぞれ運用している ➢ それぞれが独自のDAppsを提供している
  12. Indexer 12

  13. Indexerとは? 13 Quorum indexer DB イベント監視 保存 API 取得 ➢

    コントラクト上にあるデータをDBなどにコピー(キャッシュ)するもの
  14. Indexer全体の流れ 14 indexing_status not_indexing block_height 123 Quorum name data A

    a=10 B b=20 a 10 block_height 124 b 20 block_height 124 ①現在indexing中でないことを 確認 ②indexing済みの次のブロック からログを取得する ③取得したイベントのログの数 だけループ ④indexing対象のログなら block_heightと共にDBに保存 DB ⑤保存済みblock_heightを更新 イベント
  15. indexerその他 • イベントログが中途半端に反映されないように、1つの(RDBの)トランザクションで DBへの保存を行う • nodeとのコネクション管理などをしなくても良いように、WebSocketではなく Polling(定期的にHTTP get)をすることでブロックの取得を行う 15

  16. イベント駆動のtx実行 (ignitor?) 16

  17. Transaction A イベント駆動のtx実行(ignitor) 17 Quorum Quorum eventA a=10 kicker Transaction

    B API ①tx A実行 ③eventAを取得 ④eventAをトリ ガーとしてtx Bを実 行 ➢ txでのイベント発火を起点として別のtxを実行する ②eventA発火
  18. コントラクト上の工夫 18 contract TestContract { event Succeeded(uint256 a); event Failed(uint256

    a); function testFunction(uint256 a) public { if (a < 100) { emit Succeeded(a); } else { emit Failed(a); ... トリガー専用のイベントを用意 require(a < 100); ではない 失敗専用のイベントを発火 ➢ 「失敗」をトランザクションのrevertではなくイベントで表現する
  19. ignitorとindexerとの協調(1) 19 Transaction 1 eventA a=10 block_height 123 DB a

    10 Transaction 2 eventB b=10 block_height 124 Transaction 3 eventA a=30 block_height 125 function test(uint256 a) eventBをトリガーにして、testを実行(a=10) eventAをindexing ➢ block_height=124のイベントをトリガにして別のtxを実行 するには、block_height=123の時のindexingされたDB の情報が必要(block_height=125の時にはaの値が変 わってしまう)
  20. ignitorとindexerとの協調(2) 20 • ignitorとindexerを完全に独立にすることは出来ない • indexerは1ブロックに含まれるイベントをatomicにDBに保存しているので、 indexingが失敗したときにignitorが実行されないようにしないといけない ◦ e.g. Transaction

    2が来たタイミングで次のtxの引数だけ作っておき、indexingが成功し たときだけtxを実行する
  21. コントラクト デプロイフロー 21

  22. デプロイのフロー(1) nodeの運用主体が1つだけならtruffleのmigrationで良い。 複数の主体が別々にコントラクトをデプロイするときは? 22

  23. デプロイのフロー(2) 23 Quorum Quorum ①自分のコントラクトデプロイ ②seedデータなどを設定 ④他のnodeに依存するデータを設定 ③ABI(truffle artifact)を共有する

  24. UX 24

  25. tx実行中という状態をどう見せる? 25 Quorum API DB a=10 未indexing a 20 a=20

    a=20 ➢ indexingする前だとAPIから古い データが取得されてしまう ?
  26. API側でのレスポンスのタイミング 26 Quorum API DB ①txの送信終了時? ②ブロックの取り込み終了時? ③indexing終了時? ➢ ①に近いほどクライアントの待ち時間は短くなるが、クライアントから見た時

    に状態が不整合となる期間は長くなるというトレードオフ
  27. 実行中のtxどう管理する? • 異常系(e.g. APIの実行失敗)のフローでは①〜③どれを選んでもクライアント側に 対して何かしらのフォローが必要 • indexing済みかどうかはサーバ側でしか分からないのでサーバで管理 ◦ txごとにどういう状態かを管理する? •

    txがどういう状態にあるかを返すAPIを作ってクライアントで出し分けする? 27 ➢ To Be Continued...
  28. まとめ • 複数の主体がnodeを運用しているときには、コントラクトのデ プロイフローやイベント駆動のtx実行のためのワークフローが 必要 • 閲覧・検索系の機能を作るためにはindexerが必要 • UX上、実行中(indexing中)のtxを何かしらの方法で判別する 必要あり

    28