Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
DApps開発特有の_ハマりポイントご紹介.pdf
yudetamago
October 10, 2019
Technology
1
1.1k
DApps開発特有の_ハマりポイントご紹介.pdf
yudetamago
October 10, 2019
Tweet
Share
More Decks by yudetamago
See All by yudetamago
ブロックチェーンとIndexer
yudetamago
0
490
Unityでブロックチェーンアプリを作る
yudetamago
0
870
スマートコントラクトの監査について
yudetamago
2
540
DApps開発事例 ~CryptoCrystal概要編~
yudetamago
3
250
Gasを誰が払うのか問題について
yudetamago
5
3.7k
Solidityの複数コントラク ト連携を色々試してる話
yudetamago
1
1.6k
Dapps開発におけるSoliidityのはまりどころ
yudetamago
3
1.7k
Other Decks in Technology
See All in Technology
Accelerating ZOZOTOWN Modernization with Istio
yokawasa
0
210
僕の Microsoft Teams (+α) 便利技紹介 2022年春
taichinakamura
0
1.9k
プロダクトグロースと技術のベースアップを両立させるRettyのアプリ開発スタイル / Achieve Product Growth and Tech Update
imaizume
1
250
一人から始めるプロダクトSRE / How to start SRE in a product team, all by yourself
vtryo
3
1.8k
Red Hat Summit 2022 の概要とオススメセッションのご紹介
rhpej
1
200
Kubernetesの上に作る、統一されたマイクロサービス運用体験
tkuchiki
1
630
Power BI Report Ops
hanaseleb
0
140
LINEスタンプの実例紹介 小さく始める障害検知・対応・振り返りの 改善プラクティス
line_developers
PRO
3
840
OSINT/GEOINT ワークショップ 20220514 古橋資料
furuhashilab
2
200
ISUCON で使えるツールを作った
shotakitazawa
0
350
The Real MVP: Going from idea to users' hands
adavis
0
520
完全に理解した incremetal 〜そして、何もわからないへ〜
mashiike
0
200
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
499
110k
The Power of CSS Pseudo Elements
geoffreycrofte
46
3.9k
Designing for humans not robots
tammielis
241
23k
Faster Mobile Websites
deanohume
294
28k
Code Reviewing Like a Champion
maltzj
506
37k
Thoughts on Productivity
jonyablonski
43
2.2k
Statistics for Hackers
jakevdp
781
210k
Product Roadmaps are Hard
iamctodd
34
6.1k
GraphQLの誤解/rethinking-graphql
sonatard
24
6.1k
The Invisible Customer
myddelton
110
11k
The Brand Is Dead. Long Live the Brand.
mthomps
45
2.7k
Happy Clients
brianwarren
89
5.5k
Transcript
DApps開発特有の ハマりポイントご紹介 株式会社LayerX 神場 貴之 2019/10/10 Blockchain GIG #5 1
自己紹介 株式会社LayerX 神場貴之(じんば たかゆき) Senior Architect / Engineer Github: yudetamago
Twitter: @takayukib 好きな言語: Ruby 2
ブロックチェーンそのものの話 ➢ アプリ開発の1つのコンポーネントとして ブロックチェーンを使う時の話 (概要より実践向けの話が多いです) 3
アジェンダ • DAppsのアーキテクチャ全体像 • Indexer • イベント駆動のtx実行(ignitor?) • コントラクトデプロイのフロー •
UX 4
DAppsアーキテクチャ 5
6 Blockchain node Frontend (+MetaMaskなど) Q. これで要求を満たすようなアプリケーションを作れるでしょうか? tx送信
7 Blockchain node Frontend A. このぐらい必要でした indexer API (サーバ) DB
tx送信 イベント監視 保存 取得
なぜサーバが必要? MetaMaskのようなWalletプラグイン(アプリ)は まだ一般に浸透しているとは言えない 8 秘密鍵?ニーモニック...?
なぜIndexerが必要?(1) 9 Quorum ページング、検索、join、etc ➢ コントラクト側であらかじめ全てを用意しておくのは(一般には)難しい
なぜIndexerが必要?(2) 10 Quorum indexer DB イベント監視 保存 ページング、検索、join、etc API 取得
このスライドでのアーキテクチャの前提 11 Quorum indexer API DB App Quorum indexer API
DB App ➢ 同じネットワークIDを使っているQuorumをそれぞれ運用している ➢ それぞれが独自のDAppsを提供している
Indexer 12
Indexerとは? 13 Quorum indexer DB イベント監視 保存 API 取得 ➢
コントラクト上にあるデータをDBなどにコピー(キャッシュ)するもの
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を更新 イベント
indexerその他 • イベントログが中途半端に反映されないように、1つの(RDBの)トランザクションで DBへの保存を行う • nodeとのコネクション管理などをしなくても良いように、WebSocketではなく Polling(定期的にHTTP get)をすることでブロックの取得を行う 15
イベント駆動のtx実行 (ignitor?) 16
Transaction A イベント駆動のtx実行(ignitor) 17 Quorum Quorum eventA a=10 kicker Transaction
B API ①tx A実行 ③eventAを取得 ④eventAをトリ ガーとしてtx Bを実 行 ➢ txでのイベント発火を起点として別のtxを実行する ②eventA発火
コントラクト上の工夫 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ではなくイベントで表現する
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の値が変 わってしまう)
ignitorとindexerとの協調(2) 20 • ignitorとindexerを完全に独立にすることは出来ない • indexerは1ブロックに含まれるイベントをatomicにDBに保存しているので、 indexingが失敗したときにignitorが実行されないようにしないといけない ◦ e.g. Transaction
2が来たタイミングで次のtxの引数だけ作っておき、indexingが成功し たときだけtxを実行する
コントラクト デプロイフロー 21
デプロイのフロー(1) nodeの運用主体が1つだけならtruffleのmigrationで良い。 複数の主体が別々にコントラクトをデプロイするときは? 22
デプロイのフロー(2) 23 Quorum Quorum ①自分のコントラクトデプロイ ②seedデータなどを設定 ④他のnodeに依存するデータを設定 ③ABI(truffle artifact)を共有する
UX 24
tx実行中という状態をどう見せる? 25 Quorum API DB a=10 未indexing a 20 a=20
a=20 ➢ indexingする前だとAPIから古い データが取得されてしまう ?
API側でのレスポンスのタイミング 26 Quorum API DB ①txの送信終了時? ②ブロックの取り込み終了時? ③indexing終了時? ➢ ①に近いほどクライアントの待ち時間は短くなるが、クライアントから見た時
に状態が不整合となる期間は長くなるというトレードオフ
実行中のtxどう管理する? • 異常系(e.g. APIの実行失敗)のフローでは①〜③どれを選んでもクライアント側に 対して何かしらのフォローが必要 • indexing済みかどうかはサーバ側でしか分からないのでサーバで管理 ◦ txごとにどういう状態かを管理する? •
txがどういう状態にあるかを返すAPIを作ってクライアントで出し分けする? 27 ➢ To Be Continued...
まとめ • 複数の主体がnodeを運用しているときには、コントラクトのデ プロイフローやイベント駆動のtx実行のためのワークフローが 必要 • 閲覧・検索系の機能を作るためにはindexerが必要 • UX上、実行中(indexing中)のtxを何かしらの方法で判別する 必要あり
28