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
言語モデルによるAI創薬の進展 / Advancements in AI-Driven Drug Discovery Using Language Models
tsurubee
2
380
A multimodal data fusion model for accurate and interpretable urban land use mapping with uncertainty analysis
satai
3
220
Ad-DS Paper Circle #1
ykaneko1992
0
5.5k
クラウドのテレメトリーシステム研究動向2025年
yuukit
3
960
Cross-Media Information Spaces and Architectures
signer
PRO
0
220
データサイエンティストの就労意識~2015→2024 一般(個人)会員アンケートより
datascientistsociety
PRO
0
700
なめらかなシステムと運用維持の終わらぬ未来 / dicomo2025_coherently_fittable_system
monochromegane
0
570
プロシェアリング白書2025_PROSHARING_REPORT_2025
circulation
1
880
LLM-as-a-Judge: 文章をLLMで評価する@教育機関DXシンポ
k141303
3
820
【緊急警告】日本の未来設計図 ~沈没か、再生か。国民と断行するラストチャンス~
yuutakasan
0
130
[輪講] SigLIP 2: Multilingual Vision-Language Encoders with Improved Semantic Understanding, Localization, and Dense Features
nk35jk
2
550
在庫管理のための機械学習と最適化の融合
mickey_kubo
3
1.1k
Featured
See All Featured
For a Future-Friendly Web
brad_frost
179
9.8k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
510
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
Scaling GitHub
holman
459
140k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
How to train your dragon (web standard)
notwaldorf
94
6.1k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
960
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