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

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