ブロックチェーンとIndexer

Transcript

1. ブロックチェーンとIndexer 株式会社LayerX 神場 貴之 2019/1/24 blockchain.tokyo#24 supported by AWS 1

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

   takayukib 2

3. このスライドの前提 • ブロックチェーンとしてはQuorumを使います • 秘密鍵はサービス提供者が管理しています • （ブロックチェーンにある程度触れている方向けです） 3

4. indexerとは 4

5. シンプルなDAppsの構成 Quorum Frontend (+MetaMaskなど) tx送信 5

6. こんなときどうする？ 6

7. デプロイ済みのERC20トークンを使って • 現在balanceが100以上で • 直近1週間のtransfer回数が100以上 のアドレスをリアルタイムに取得出来るよう にしたい 7

8. 何が必要？ • 過去1週間分のtransferのイベントログ ◦ 大量のイベント取得、どのブロック番号まで取得すればいい？？ • （transferに関連する）アドレスのbalanceの一覧 ◦ アドレスそれぞれに対してERC20のbalanceOfを呼ぶ？？ 8

9. RDBなら addresses address 0x…. balances address balance 0x…. 100 transfer_histories

   from to amount block_timestamp 0x…. 0x…. 10 1579791600 joinとwhereで良い 9

10. indexerを使う理由 • コントラクト（Solidity）で柔軟な検索用メソッドを作るのは難しい • デプロイしてしまったコントラクトに後から検索用メソッドを追加することは出来な い ◦ イベントの定義に貼っているindexも後からは変えられない 10

11. ストレージのデータ、イベントをRDBに キャッシュ（インデクシング）しよう 11

12. indexer全体像 12

13. 全体像 Quorum indexer RDB ログ取得 保存 API 取得 13

14. Indexer全体の流れ1 indexing_status not_indexing block_height 123 RDB ①現在indexing中でないことを確認 ②indexing中状態に変更 ③indexing済みの次のブロック(124)からログを取得する •

    現在のindexing状態を記録（二重 実行防止） • indexing済みのブロック番号を記録 14

15. Indexer全体の流れ2 a 10 block_height 124 b 20 block_height 124 RDB

    Quorum name data A a=10 B b=20 ④取得したイベントのログの数だけループ ⑤indexing対象のログならblock_heightと共にDBに保存 • イベントと RDB上のテー ブルのマッピングを作っ ておく 15

16. Indexer全体の流れ3 indexing_status not_indexing block_height 124 RDB ⑥block_heightを最新のものに更新 16

17. Indexingの仕方 1. Push型（WebSocketで常時接続） 2. Pull型（HTTPでPolling） 17

18. Push型 WebSocketでQuorumと常時接続しておき、イベントまたはブロックをsubscribeする • Pros ◦ リアルタイムにindexingすることが出来る • Cons ◦ 受け取る側でエラーになったときに備えてリトライ機構が必要

    18

19. Pull型 HTTPでPollingを行い、Quorumに定期的にブロックを取りに行く • Pros ◦ 失敗しても（ブロック番号を調整して）再実行することが出来る • Cons ◦ Push型よりもリアルタイム性は多少下がる

    19

20. その他 • 一度に取得するブロック数を制限してデータ量・処理時間が長くなりすぎないよ うにする • 中途半端に保存されないように（RDBの）トランザクションで実行する • uint256など通常の数値型では収まらない値に注意する 20

21. フロントエンドのUX 21

22. ブロック取り込み前, 未indexingの状態 Quorum API DB 最新のデータ 古いデータ 古いデータ ？？？ 22

23. API側でのレスポンスのタイミング 1. トランザクションの送信終了時 2. Quorumのブロック取り込み終了時 3. Indexing終了時 23

24. 24

25. （ユーザーから見たときの） • レスポンスの待ち時間　 • 状態が不整合となる時間 のトレードオフ 25