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
クラスターmempool
Search
shigeyuki azuchi
April 21, 2026
Technology
32
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
クラスターmempool
GBECの解説動画の資料です。
https://goblockchain.network/2026/04/cluster-mempool/
shigeyuki azuchi
April 21, 2026
More Decks by shigeyuki azuchi
See All by shigeyuki azuchi
FORS
azuchi
0
12
W-OTS+
azuchi
0
35
Shorのアルゴリズム
azuchi
0
57
DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures
azuchi
0
43
Fiat-Shamir変換と注意点
azuchi
0
230
AssumeUTXOを利用したブロックチェーンの同期
azuchi
0
55
BIP-374 離散対数の等価性証明
azuchi
0
74
BIP-353 DNS Payment Instructions
azuchi
0
89
OP_CAT and Schnorr Trick
azuchi
0
89
Other Decks in Technology
See All in Technology
Genie Ontologyは銀の弾丸かを考える / Is Genie Ontology a Silver Bullet?
nttcom
0
180
ボーイスカウトルールでメモリやスキルを改善しよう
azukiazusa1
1
230
End-to-Endで考える信頼性 —LINEアプリにおけるクライアント開発×SRE連携の実践
maruloop
4
3.9k
ローカルLLMとLINE Botの組み合わせ その3 / LINE DC Generative AI Meetup #8
you
PRO
0
130
DMM.com 購入改善推進チーム におけるCodeRabbitを用いた レビューフロー改善の一例
ysknsid25
2
580
AIに「使われる」時代のSaaS戦略 〜既存WebAPIのMCPサーバー化における開発ノウハウ〜
ekispert_api
0
310
AIレビューはどこまで任せられるのか?自動化と人が背負うレビューの境界
sansantech
PRO
2
450
DatabricksにおけるMCPソリューション
taka_aki
1
210
SRE本の知られざる名シーン / The Hidden Gems of Google SRE Book
nari_ex
1
340
【Claude Code】鹿野さんに聞く 私の推しの並行開発環境 大公開 / claude-code-parallel-2026-07-15
tonkotsuboy_com
10
5.8k
Oracle Exadata Database Service on Cloud@Customer X11M (ExaDB-C@C) サービス概要
oracle4engineer
PRO
2
8.4k
クラウド上のデータ復旧で見落としがちな制約: 医療系 SaaS の BCP 設計から得た教訓
kakehashi
PRO
0
3.2k
Featured
See All Featured
SEO for Brand Visibility & Recognition
aleyda
0
4.6k
Leveraging LLMs for student feedback in introductory data science courses - posit::conf(2025)
minecr
1
310
Lightning Talk: Beautiful Slides for Beginners
inesmontani
PRO
2
600
The Language of Interfaces
destraynor
162
27k
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
2.1k
How to build a perfect <img>
jonoalderson
1
5.8k
Exploring anti-patterns in Rails
aemeredith
3
440
Why You Should Never Use an ORM
jnunemaker
PRO
61
9.9k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
55k
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
Color Theory Basics | Prateek | Gurzu
gurzu
0
390
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
800
Transcript
クラスターmempool
1 mempool mempoolは未承認トランザクションが一時的に保持されるスペース mempool内のTxはインプット/アウトプットの関係からDAG(有向非巡回グラフ)を形成
2 従来のmempool設計の課題 各Txは複数の祖先(ancestor)および子孫(descendant)を持ち、 子をマイニングするためには必ず親もマイニングする必要がある(パッケージ手数料率の評価) • ancestor fee rate Txをマイニングするために必要な祖先全員を含めた、パッケージ全体の手数料率 •
descendant fee rate Txとそれに依存しているすべての子孫を含めたパッケージ全体の手数料率 • ancestor fee rateとdescendant fee rateの非対称性 ◦ マイニングではancestor fee rateでマイニング対象を選択 ◦ mempoolからの排除対象を選択する場合は descendant fee rateで選択 • マイニングされにくく、排除もされにくい Txがmempoolに居座ることになる
3 従来のmempool設計の課題 RBF(Replace-by-Fee)は、Tx単体の手数料率に基づき判断するため、 実際にはマイニング優先度が下がる置換を許してしまうケースがある Lightning NetworkなどのHTLCで、 • HTLC Success Txを低手数料率でmempoolに滞留させ
• 相手方のHTLC Timeout TxのRBFを防止する Tx A(3 sat/vB, 100vB, fee=300sat) Tx B(10 sat/vB, 100vB, fee=1000 sat) ancestor fee rateは、 (300 + 1000) / (100 + 100) = 6.5 sat/vB Tx A’(4 sat/vB, 100,000vB, fee=400,000sat) 手数料率、手数料額共にAより高いため(3 sat/vB → 4 sat/vB)置換可能 一方、Tx Bは無効になり排除される(6.5 sat/vB > 4 sat/vBであっても) ※ RBFはTx単体のみをチェックしパッケージを評価しない
4 従来のmempool設計の課題 CPFP(Child pay for Parents)では、子が親の手数料を補填するロジックが 祖先グラフ全体を正確に評価できず、マイナーにとって最適なパッケージ選択が保証されない Tx A(1 sat/vB,
100vB, fee=100sat) Tx B(10 sat/vB, 100vB, fee=1000 sat) Tx C(10 sat/vB, 100vB, fee=1000 sat) Tx B、Tx C共にancestor fee rateは、(100 + 1000) / (100 + 100) = 5.5 sat/vB 実際のマイニング手数料率は (100 + 1000 + 1000) / (100 + 100 + 100) = 7 sat/vB Tx D(6 sat/vB) ancestor fee rateの判断ではTx D > Tx B = Tx Cとなるが 本当は7 sat/vBのA, B, Cをマイニングする方が有利 Tx A, Bマイニング後、 Tx Cのancestor fee rateは10 sat/vB → mempool内のランキングはこの瞬間に何をマイニングするかによって変動する 超低手数料率の子 低手数料率の子がつくと descendant fee rateが下がり排除対象になるリスクが上がる
5 クラスターmempool 1. トランザクション間の依存関係を クラスターとして管理する ◦ クラスターA:[Tx 1 -> Tx
2 -> Tx 3] ◦ クラスターB:[Tx 4] ◦ クラスターC:[Tx 5 -> Tx 6] 2. リニアライゼーション :クラスター内のTxを最適な順序に並べる ◦ 依存関係を満たしつつ、手数料率が単調非増加のセットになるよう並べる https://techmedia-think.hatenablog.com/entry/2026/03/13/182359 3. チャンク分割:リニアライゼーションを手数料率の変化点で区切ったグループ 4. すべてのクラスターをばらしてチャンク単位でフラットにグローバルソート • マイニングでは先頭のチャンクを順次選択 • 排除は最後尾のチャンクから選択 • マイニングされてもチャンクの順序は変わらない 非対称性を排除
6 クラスターmempool • クラスター: ◦ Tx A: fee=100 sat, size=100vB
→ 1.0 sat/vB ◦ Tx B: fee=800 sat, size=100vB → 8.0 sat/vB ◦ Tx C: fee=600 sat, size=100vB → 6.0 sat/vB ◦ Tx D: fee=200 sat, size=100vB → 2.0 sat/vB ◦ Tx E: fee=150 sat, size=100vB → 1.5 sat/vB • チャンク: ◦ チャンク1:{Tx A -> Tx B -> Tx C}(5.00 sat/vB 300vB) ◦ チャンク2:{Tx D}(2.00 sat/vB 100vB) ◦ チャンク3:{Tx E}(1.5 sat/vB) Tx A Tx B Tx C Tx D Tx E 依存関係: 単調非増加の確認 : 5.00 ≥ 2.00 ≥ 1.50 ✓ トポロジカル制約 : A→B, A→C, B→D, C→E すべて満たす ✓
7 クラスターmempool 新しいTxが届いたら: • 依存関係がないTxの場合→新しいクラスターを作成→キューに追加 • 1つのクラスターの子孫の場合 →該当クラスターに追加し、 ◦ リニアライゼーションを再計算
◦ 該当クラスターのチャンクについてキューを更新 • 複数のクラスターにまたがる場合: ◦ 対象のクラスターを統合 ◦ マージ後のクラスターのリニアライゼーションを再計算 ◦ 旧チャンクを削除し、新チャンクをキューに追加 ※ 従来のmempoolではTxが届くたびにすべての祖先・子孫の ancestor/descendant feerateを再計算していたが、 クラスターmempoolでは影響を受けるクラスターのみの再計算 このケースで対象のクラスター数が増えると 再計算の計算量が爆発する可能性があるため、 クラスターには上限が設けられている
8 従来の手法との対比 従来のmempool クラスターmempool 手数料の評価単位 Tx個別/祖先チェーン クラスター→チャンク マイニング順序 ancestor fee
rate リニアライゼーション 排除 descendant fee rate リニアライゼーションの 末尾チャンクから削除 マイニングと排除の一貫性 非対称 同じリニアライゼーションから導出 RBFの判定 部分的な手数料率比較 置換前後のチャンクの手数料率を比較 祖先/子孫の上限 25/25 クラスターサイズの上限 CPFP 祖先のセット単位で比較(近似) クラスター全体で正確に評価