Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ブロックチェーンとIndexer
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
yudetamago
January 24, 2020
Technology
970
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ブロックチェーンとIndexer
yudetamago
January 24, 2020
More Decks by yudetamago
See All by yudetamago
Unityでブロックチェーンアプリを作る
yudetamago
0
1.9k
DApps開発特有の_ハマりポイントご紹介.pdf
yudetamago
1
1.5k
スマートコントラクトの監査について
yudetamago
2
640
DApps開発事例 ~CryptoCrystal概要編~
yudetamago
3
340
Gasを誰が払うのか問題について
yudetamago
5
4.7k
Solidityの複数コントラク ト連携を色々試してる話
yudetamago
1
2.4k
Dapps開発におけるSoliidityのはまりどころ
yudetamago
3
2.4k
Other Decks in Technology
See All in Technology
【FinOps】データドリブンな意思決定を目指して
z63d
3
520
AIをフル活用してオンコール機能のプロトタイプを2日で作った話 / Building an AI-Powered On-Call Prototype in Just Two Days
nari_ex
0
160
そこにあるから地図ができる~位置を示す"モノ"を愉しむ~ - Interface 2026年6月号GPS特集オフ会 / interface_202606_GPS_offline
sakaik
1
140
Multi-Agent並列開発を 安全に回すための技術 / Technology for Safely Multi-Agent Parallel Development
tooppoo
0
230
小さいから、全部わかる。— 常駐AI "xangi" のすすめ
sugupoko
0
180
背中から、背中へ /paying forward to community
naitosatoshi
0
180
MySQL & MySQL HeatWave Report - June 2026
freshdaz
0
230
AWS Summit Japan 2026の振り返りと2027へ向けて / AWS Summit Japan 2026 Recap and Prospects for 2027
kaminashi
1
120
AWS Security Hub CSPMの成功・失敗体験
cmusudakeisuke
0
610
AWS PrivateLink × SCIM で実現する セキュアで運⽤負荷の低い Databricks 基盤の構築
tsuda7
0
110
はてなのサービス基盤を支える Kubernetes《足腰》
masayoshimaezawa
0
310
週末にループ・エンジニアリングの理解を深めるためのスライド
nagatsu
0
670
Featured
See All Featured
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
170
What's in a price? How to price your products and services
michaelherold
247
13k
Facilitating Awesome Meetings
lara
57
7k
Balancing Empowerment & Direction
lara
6
1.2k
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
2
400
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
How People are Using Generative and Agentic AI to Supercharge Their Products, Projects, Services and Value Streams Today
helenjbeal
1
220
Paper Plane (Part 1)
katiecoart
PRO
0
9.3k
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
290
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
2
870
Bash Introduction
62gerente
615
220k
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
2
400
Transcript
ブロックチェーンとIndexer 株式会社LayerX 神場 貴之 2019/1/24 blockchain.tokyo#24 supported by AWS 1
自己紹介 神場 貴之(じんば たかゆき) 株式会社LayerX Software Engineer Github: yudetamago Twitter:
takayukib 2
このスライドの前提 • ブロックチェーンとしてはQuorumを使います • 秘密鍵はサービス提供者が管理しています • (ブロックチェーンにある程度触れている方向けです) 3
indexerとは 4
シンプルなDAppsの構成 Quorum Frontend (+MetaMaskなど) tx送信 5
こんなときどうする? 6
デプロイ済みのERC20トークンを使って • 現在balanceが100以上で • 直近1週間のtransfer回数が100以上 のアドレスをリアルタイムに取得出来るよう にしたい 7
何が必要? • 過去1週間分のtransferのイベントログ ◦ 大量のイベント取得、どのブロック番号まで取得すればいい?? • (transferに関連する)アドレスのbalanceの一覧 ◦ アドレスそれぞれに対してERC20のbalanceOfを呼ぶ?? 8
RDBなら addresses address 0x…. balances address balance 0x…. 100 transfer_histories
from to amount block_timestamp 0x…. 0x…. 10 1579791600 joinとwhereで良い 9
indexerを使う理由 • コントラクト(Solidity)で柔軟な検索用メソッドを作るのは難しい • デプロイしてしまったコントラクトに後から検索用メソッドを追加することは出来な い ◦ イベントの定義に貼っているindexも後からは変えられない 10
ストレージのデータ、イベントをRDBに キャッシュ(インデクシング)しよう 11
indexer全体像 12
全体像 Quorum indexer RDB ログ取得 保存 API 取得 13
Indexer全体の流れ1 indexing_status not_indexing block_height 123 RDB ①現在indexing中でないことを確認 ②indexing中状態に変更 ③indexing済みの次のブロック(124)からログを取得する •
現在のindexing状態を記録(二重 実行防止) • indexing済みのブロック番号を記録 14
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
Indexer全体の流れ3 indexing_status not_indexing block_height 124 RDB ⑥block_heightを最新のものに更新 16
Indexingの仕方 1. Push型(WebSocketで常時接続) 2. Pull型(HTTPでPolling) 17
Push型 WebSocketでQuorumと常時接続しておき、イベントまたはブロックをsubscribeする • Pros ◦ リアルタイムにindexingすることが出来る • Cons ◦ 受け取る側でエラーになったときに備えてリトライ機構が必要
18
Pull型 HTTPでPollingを行い、Quorumに定期的にブロックを取りに行く • Pros ◦ 失敗しても(ブロック番号を調整して)再実行することが出来る • Cons ◦ Push型よりもリアルタイム性は多少下がる
19
その他 • 一度に取得するブロック数を制限してデータ量・処理時間が長くなりすぎないよ うにする • 中途半端に保存されないように(RDBの)トランザクションで実行する • uint256など通常の数値型では収まらない値に注意する 20
フロントエンドのUX 21
ブロック取り込み前, 未indexingの状態 Quorum API DB 最新のデータ 古いデータ 古いデータ ??? 22
API側でのレスポンスのタイミング 1. トランザクションの送信終了時 2. Quorumのブロック取り込み終了時 3. Indexing終了時 23
24
(ユーザーから見たときの) • レスポンスの待ち時間 • 状態が不整合となる時間 のトレードオフ 25