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
Account/Balanceモデルのシャーディングと課題点
Search
minami
April 03, 2020
Research
1
750
Account/Balanceモデルのシャーディングと課題点
blockchain.tokyo Online#2
minami
April 03, 2020
Tweet
Share
More Decks by minami
See All by minami
Autocxx -RustからC++を安全かつ楽に-
minaminao
2
1.4k
Rustで始める競技プログラミング
minaminao
0
320
Other Decks in Research
See All in Research
Adaptive fusion of multi-modal remote sensing data for optimal sub-field crop yield prediction
satai
3
220
集合間Bregmanダイバージェンスと置換不変NNによるその学習
wasyro
0
110
なめらかなシステムと運用維持の終わらぬ未来 / dicomo2025_coherently_fittable_system
monochromegane
0
630
Generative Models 2025
takahashihiroshi
21
12k
Mechanistic Interpretability:解釈可能性研究の新たな潮流
koshiro_aoki
1
310
Self-supervised audiovisual representation learning for remote sensing data
satai
3
230
利用シーンを意識した推薦システム〜SpotifyとAmazonの事例から〜
kuri8ive
1
210
2025年度 生成AIの使い方/接し方
hkefka385
1
710
Transparency to sustain open science infrastructure - Printemps Couperin
mlarrieu
1
190
Weekly AI Agents News!
masatoto
33
68k
AI エージェントを活用した研究再現性の自動定量評価 / scisci2025
upura
1
120
(NULLCON Goa 2025)Windows Keylogger Detection: Targeting Past and Present Keylogging Techniques
asuna_jp
2
540
Featured
See All Featured
The World Runs on Bad Software
bkeepers
PRO
69
11k
Writing Fast Ruby
sferik
628
62k
BBQ
matthewcrist
89
9.7k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Bash Introduction
62gerente
613
210k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
Designing for Performance
lara
610
69k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
Transcript
Account/Balanceモデルの シャーディングと課題点 blockchain.tokyo Online#2 1
自己紹介 • 岡南 直哉 (おかなみ なおや) • LayerX Researcher •
筑波大M1 • @vinami • たまに: 競プロ, CTF, Kaggle 2
目次 • Account/Balanceモデルのシャーディング ◦ 中村さんの説明もあったので簡単に • 課題点 • 研究紹介: Load
Balancing for Sharded Blockchains ◦ WTSC’20 にて発表 • Q&A ゴール: シャーディングの課題点と解決策を通じて、シャーディングの理解を深める 3
Account/Balanceモデルの シャーディング 4
トランザクションモデル • どのようにトランザクションを管理・表現するか? • UTXOモデル (Unspent Transaction Output) ◦ アカウントと残高が明示的でない
◦ 代表例: Bitcoin ◦ Sharded Blockchain の例: Elastico, OmniLedger, RapidChain • Account/Balanceモデル ◦ アカウントと残高が明示的である ◦ 代表例: Ethereum ◦ Sharded Blockchain の例: Ethereum 2.0, Monoxide ◦ スマートコントラクトの実装に適している ▪ スマートコントラクトがある分、負荷により気を使う必要がある 5
シャーディング • イメージ: ブロックチェーンをたくさん作って並列化する技術 ◦ スケーラビリティの向上 • バリデータ集合およびトランザクション集合を分割 6
シャーディング (Account/Balanceモデル) • アカウント集合も分割 7
クロスシャードトランザクション • あるシャードから別のシャードへのトランザクションのこと • 通常のトランザクションより負荷が大きい・手数料が高い・承認が遅い 8
課題点 9
課題点3つ紹介 1. バリデータのシャッフルによるオーバーヘッド 2. クロスシャードトランザクションによるUXの悪化 3. 特定シャードへの負荷集中 10
課題点: バリデータのシャッフルによるオーバーヘッド • あるシャードを攻撃者が支配しないようにバリデータを定期的にシャッフル ◦ 例えば数日ごと • しかし、バリデータはステートを持つ必要がある • シャッフルのたびに別のシャードのステートをダウンロードしなければならない
◦ 通信コストがかかる ◦ 条件を厳しくすると通信環境が良い人しか参加できず中央集権化 11
解決策: Stateless client • フルノードがステートを保存しなくていい • 状態遷移に少し変更を加えることでステートルートだけを持てばよくなる • ステートの検証をユーザーに協力してもらう •
ストレージ負荷が小さくなる • https://ethresear.ch/t/the-stateless-client-concept/172 12
課題点: クロスシャードトランザクションによるUXの悪化 • クロスシャードトランザクションによってどれだけUXが悪化するのか? どんな現象が起こるのか? • クロスシャードトランザクションは、排他制御や二相コミットをベースにしている ◦ 処理が通常のトランザクションより重くなっている ◦
例: Yanking • まだUXがどう悪化するのか、詳細な分析はほぼされていない • UX悪化現象の例: 負荷集中現象 13
課題点: 特定シャードへの負荷集中 • 原因1: アカウントの配置の仕方 ◦ Ethereum 2.0 だと、基本はアカウントアドレスのプレフィックスを元に配置する ▪
0x00 -> Shard 0, 0x01 -> Shard 1, … のように ◦ 負荷に関して考慮しない ◦ 人気なコントラクトがいるシャードの負荷が高くなる • 原因2: ユーザーの利己的な行動 ◦ ユーザーとアカウントは 1対多の関係 ◦ 例: トランザクション手数料を安くしたい ◦ 頻繁に利用するアカウントが属するシャードに属したら手数料が安くなる ▪ クロスシャードトランザクションが減るため ▪ そのシャードへ集まってしまう ◦ ただ一方で、人気すぎるシャードに属すと手数料が高くなる ▪ トランザクションの採用はオークション制 14
解決策1: アプリケーションを複数シャードに配置 • 2つのやり方 ◦ 全く同じアプリケーションを複数シャードにデプロイ ◦ 1つのアプリケーションを複数シャードで並列化 • イマイチ?
◦ 金融アプリケーションだと流動性が小さくなる ◦ 並列化と相性の悪いアプリケーションもある ▪ 例: Uniswap ▪ 部分的に並列化するテクもある https://ethresear.ch/t/partially-sharding-single-threaded-apps-a-design-pattern/6287 • どれだけ改善するかはまだ詳細に分析されていない 15
解決策2: アカウントの動的割り当て • “GARET: improving throughput using gas consumption-aware relocation
in Ethereum sharding environments” ◦ Cluster Computing (2020) ◦ オンチェーンでトランザクション負荷を予測してアカウントをグループごとに割り当て • “Load Balancing for Sharded Blockchains” ◦ WTSC’ 20 ◦ 負荷分散を最適化問題に定式化してコンペティション得た最良の解を適用 ◦ GARET と違う点として、ユーザーの利己的な行動も考慮 ◦ 後で詳しく 16
補足: ユーザーの利己的な行動による負荷分散 • まだ詳しく検証されていない • 人気なシャードは手数料が高くなるので、極端に負荷集中が起こらない • さらに、人気なシャードへ移動するインセンティブを無くす ◦ 手数料の増加させる?
• 負荷集中を問題にならない程度に緩和できるかも • 一方で、全ユーザーの総手数料が増加しUX悪化する ◦ 個人的にはin-protocolで直接割り当てるのが効率良いのでは、と考えている ◦ 簡易的なシミュレーションでも確認できる 17
Load Balancing for Sharded Blockchains (WTSC’20) 18
この研究のフォーカスする課題点 1. バリデータのシャッフルによるオーバーヘッド 2. クロスシャードトランザクションによるUXの悪化 3. 特定シャードへの負荷集中 19 今回の研究は2,3にフォーカス
In-protocol Load Balancing • プロトコルで(In-protocol)直接ロードバランシングできれば、 よりユーザー全体の User Experience (UX) が良くなる
◦ パレート最適のような、みんなの幸せが総和が最大の状態に • ざっくり流れ ◦ シャードから負荷分散に必要な負荷情報を集める ◦ その情報を元にアカウントの割当問題を最適化問題として定式化 ◦ コンペティションとして公開、プレイヤーに解いてもらう ◦ 解をもとにアカウントを定期的に割り当て直す ▪ 定期的に割り当て直すことで利己的なシャード移動のインセンティブが下がる ▪ 利己的な移動で状態がめちゃくちゃになるのが起きにくくなる 20
In-protocol Load Balancing 全体像 21
負荷情報収集 • シャードが、ある期間にそのシャードに関係するアカウント間で取引された情報を集 める ◦ ある期間の例: 1エポック ◦ アカウント: ウォレットとコントラクト
◦ シャードは負荷情報を記録して保持する必要がある • この取引情報を、負荷情報に変換(圧縮)する ◦ 負荷情報は、Ethereum 2.0 だったらビーコンチェーンに刻まれる ◦ ただ、全体のデータ量がアクティブアカウントの数を nとしたときに、O(n^2)になる ◦ データ量が大きさ問題になる場合は、ランダムサンプリングや負荷の大きい順にアカウントを選択 する必要がある • シャードは、ビーコンチェーンにこれを提出する ◦ これはシャードのステートルートを刻むのと同じやり方で 22
負荷分散問題の定式化 23 最大負荷のシャードの負荷を最小化しよう(一例)
負荷分散問題の定式化結果 • 混合整数非線形最適化問題かつNP困難 ◦ 非常に難しいクラスの問題 ◦ NP困難である Task Assignment Problem
(TAP) から多項式時間還元可能より ◦ 負荷分散問題が多項式時間で解ける => TAPも多項式時間で解ける • ヒューリスティクス or ソルバで解く のが一般的 • ただし処理が重い ◦ オンチェーンで直接実行するのはコストに見合わない ◦ => コンペティションベースで解を集めよう • ※定式化のやり方はこれ以外にも色々考えられる ◦ UXが上がれば良い ◦ 良い問題性質の定式化があるかも 24
コンペティション形式にして解を集める • 最適化問題を公開 • 最も良い解を提出したプレイヤーに報酬を与える ◦ 報酬は手数料の一部を与えるなど ◦ Proof of
Work • 定期的(例: 1エポック = 64ブロック)に行う • 解の検証は、オンチェーンで行う • 他のプレイヤーが解のカンニングするとアンフェアなので解の暗号化など工夫が考 えられる ◦ いわゆるコミットメントスキーム 25
問題の解き方の例: メタヒューリスティクス • ヒューリスティックの中でも様々な問題に汎用的に用いられるもの • 例: 焼きなまし法 26 https://kumagallium.hatenablog.com/entry/2019/07/24/124501
評価・実験 • Ethereum 2.0 の仕様を参考にシミュレーション ◦ Beacon chain や Yanking
など • アカウント数 = 1000, シャード数 = 8 • 利己的のみ vs. プロトコルで直接 • 結果 ◦ 総手数料は約半分(図) ◦ クロスシャードトランザクション数 は約1/5程度に • モデル・仮定の妥当性については 改善の余地あり ◦ 動的に取引の分布が変化しない、など 27
全体のまとめ • Account/Balanceモデルのシャーディングにおける課題 ◦ バリデータのシャッフルによるオーバーヘッド ◦ クロスシャードトランザクションによる UXの悪化 ◦ 特定シャードへの負荷集中
• 「特定シャードへの負荷集中」の解決策 ◦ コンペティションベースのアカウント動的割り当て ◦ より現実的なモデル・仮定、プロトコル開発に向けて現在研究中 28
29 Join at slido.com #61956 Audience Q&A Session