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
610
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
1k
Rustで始める競技プログラミング
minaminao
0
280
Other Decks in Research
See All in Research
Refactoring Mining - The key to unlock software evolution
tsantalis
0
270
MLtraq: Track your AI experiments at hyperspeed
micheda
1
110
動物倫理学ことはじめ:人間以外の動物との倫理的な付き合い方を考える
takeshit_m
0
300
20240209 データを肴に熊本の交通を考える会「車1割削減、渋滞半減、公共交通2倍」をめざし世界に学ぼう
trafficbrain
0
860
SSII2023 医療支援における画像処理研究の動向と展望
moda0
0
110
F0に基づいて伸縮された画像文字からの音声合成 [ASJ2024春]
nehi0615
0
120
Ground Metric Learning with applications in genomics
gpeyre
0
370
Alexander Mielke Hellinger--Kantorovich (a.k.a. Wasserstein-Fisher-Rao) Spaces and Gradient Flows
jjzhu
3
190
AIを前提とした体験の実現に向けて/toward_ai_based_experiences
monochromegane
1
250
継続的な研究費獲得のための考え方
moda0
2
440
Source Code Diff Revolution (JetBrains Open Reading Club)
tsantalis
0
280
Generative AI - practice and theory
gpeyre
1
580
Featured
See All Featured
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
21
1.4k
Building Applications with DynamoDB
mza
88
5.6k
Making Projects Easy
brettharned
109
5.5k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
7
1.3k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
34
8.9k
How to Ace a Technical Interview
jacobian
273
22k
Optimising Largest Contentful Paint
csswizardry
12
2.4k
The Brand Is Dead. Long Live the Brand.
mthomps
49
29k
Building Better People: How to give real-time feedback that sticks.
wjessup
356
18k
Thoughts on Productivity
jonyablonski
59
3.9k
Become a Pro
speakerdeck
PRO
12
4.6k
Imperfection Machines: The Place of Print at Facebook
scottboms
261
12k
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