Account/Balanceモデルのシャーディングと課題点

blockchain.tokyo Online#2

Transcript

1. Account/Balanceモデルの シャーディングと課題点 blockchain.tokyo Online#2 1
2. 自己紹介 • 岡南 直哉 (おかなみ なおや) • LayerX Researcher • 筑波大M1 • @vinami • たまに: 競プロ, CTF, Kaggle 2
3. 目次 • Account/Balanceモデルのシャーディング ◦ 中村さんの説明もあったので簡単に • 課題点 • 研究紹介: Load Balancing for Sharded Blockchains ◦ WTSC’20 にて発表 • Q&A ゴール: シャーディングの課題点と解決策を通じて、シャーディングの理解を深める 3
4. Account/Balanceモデルの シャーディング 4
5. トランザクションモデル • どのようにトランザクションを管理・表現するか？ • UTXOモデル (Unspent Transaction Output) ◦ アカウントと残高が明示的でない ◦ 代表例: Bitcoin ◦ Sharded Blockchain の例: Elastico, OmniLedger, RapidChain • Account/Balanceモデル ◦ アカウントと残高が明示的である ◦ 代表例: Ethereum ◦ Sharded Blockchain の例: Ethereum 2.0, Monoxide ◦ スマートコントラクトの実装に適している ▪ スマートコントラクトがある分、負荷により気を使う必要がある 5
6. シャーディング • イメージ: ブロックチェーンをたくさん作って並列化する技術 ◦ スケーラビリティの向上 • バリデータ集合およびトランザクション集合を分割 6
7. シャーディング (Account/Balanceモデル) • アカウント集合も分割 7
8. クロスシャードトランザクション • あるシャードから別のシャードへのトランザクションのこと • 通常のトランザクションより負荷が大きい・手数料が高い・承認が遅い 8
9. 課題点 9
10. 課題点3つ紹介 1. バリデータのシャッフルによるオーバーヘッド 2. クロスシャードトランザクションによるUXの悪化 3. 特定シャードへの負荷集中 10
11. 課題点: バリデータのシャッフルによるオーバーヘッド • あるシャードを攻撃者が支配しないようにバリデータを定期的にシャッフル ◦ 例えば数日ごと • しかし、バリデータはステートを持つ必要がある • シャッフルのたびに別のシャードのステートをダウンロードしなければならない ◦ 通信コストがかかる ◦ 条件を厳しくすると通信環境が良い人しか参加できず中央集権化 11
12. 解決策: Stateless client • フルノードがステートを保存しなくていい • 状態遷移に少し変更を加えることでステートルートだけを持てばよくなる • ステートの検証をユーザーに協力してもらう • ストレージ負荷が小さくなる • https://ethresear.ch/t/the-stateless-client-concept/172 12
13. 課題点: クロスシャードトランザクションによるUXの悪化 • クロスシャードトランザクションによってどれだけUXが悪化するのか？ どんな現象が起こるのか？ • クロスシャードトランザクションは、排他制御や二相コミットをベースにしている ◦ 処理が通常のトランザクションより重くなっている ◦ 例: Yanking • まだUXがどう悪化するのか、詳細な分析はほぼされていない • UX悪化現象の例: 負荷集中現象 13
14. 課題点: 特定シャードへの負荷集中 • 原因1: アカウントの配置の仕方 ◦ Ethereum 2.0 だと、基本はアカウントアドレスのプレフィックスを元に配置する ▪ 0x00 -> Shard 0, 0x01 -> Shard 1, … のように ◦ 負荷に関して考慮しない ◦ 人気なコントラクトがいるシャードの負荷が高くなる • 原因2: ユーザーの利己的な行動 ◦ ユーザーとアカウントは 1対多の関係 ◦ 例: トランザクション手数料を安くしたい ◦ 頻繁に利用するアカウントが属するシャードに属したら手数料が安くなる ▪ クロスシャードトランザクションが減るため ▪ そのシャードへ集まってしまう ◦ ただ一方で、人気すぎるシャードに属すと手数料が高くなる ▪ トランザクションの採用はオークション制 14
15. 解決策1: アプリケーションを複数シャードに配置 • 2つのやり方 ◦ 全く同じアプリケーションを複数シャードにデプロイ ◦ 1つのアプリケーションを複数シャードで並列化 • イマイチ？ ◦ 金融アプリケーションだと流動性が小さくなる ◦ 並列化と相性の悪いアプリケーションもある ▪ 例: Uniswap ▪ 部分的に並列化するテクもある https://ethresear.ch/t/partially-sharding-single-threaded-apps-a-design-pattern/6287 • どれだけ改善するかはまだ詳細に分析されていない 15
16. 解決策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
17. 補足: ユーザーの利己的な行動による負荷分散 • まだ詳しく検証されていない • 人気なシャードは手数料が高くなるので、極端に負荷集中が起こらない • さらに、人気なシャードへ移動するインセンティブを無くす ◦ 手数料の増加させる？ • 負荷集中を問題にならない程度に緩和できるかも • 一方で、全ユーザーの総手数料が増加しUX悪化する ◦ 個人的にはin-protocolで直接割り当てるのが効率良いのでは、と考えている ◦ 簡易的なシミュレーションでも確認できる 17
18. Load Balancing for Sharded Blockchains (WTSC’20) 18
19. この研究のフォーカスする課題点 1. バリデータのシャッフルによるオーバーヘッド 2. クロスシャードトランザクションによるUXの悪化 3. 特定シャードへの負荷集中 19 今回の研究は2,3にフォーカス
20. In-protocol Load Balancing • プロトコルで（In-protocol）直接ロードバランシングできれば、 よりユーザー全体の User Experience (UX) が良くなる ◦ パレート最適のような、みんなの幸せが総和が最大の状態に • ざっくり流れ ◦ シャードから負荷分散に必要な負荷情報を集める ◦ その情報を元にアカウントの割当問題を最適化問題として定式化 ◦ コンペティションとして公開、プレイヤーに解いてもらう ◦ 解をもとにアカウントを定期的に割り当て直す ▪ 定期的に割り当て直すことで利己的なシャード移動のインセンティブが下がる ▪ 利己的な移動で状態がめちゃくちゃになるのが起きにくくなる 20
21. In-protocol Load Balancing 全体像 21
22. 負荷情報収集 • シャードが、ある期間にそのシャードに関係するアカウント間で取引された情報を集 める ◦ ある期間の例: 1エポック ◦ アカウント: ウォレットとコントラクト ◦ シャードは負荷情報を記録して保持する必要がある • この取引情報を、負荷情報に変換（圧縮）する ◦ 負荷情報は、Ethereum 2.0 だったらビーコンチェーンに刻まれる ◦ ただ、全体のデータ量がアクティブアカウントの数を nとしたときに、O(n^2)になる ◦ データ量が大きさ問題になる場合は、ランダムサンプリングや負荷の大きい順にアカウントを選択 する必要がある • シャードは、ビーコンチェーンにこれを提出する ◦ これはシャードのステートルートを刻むのと同じやり方で 22
23. 負荷分散問題の定式化 23 最大負荷のシャードの負荷を最小化しよう（一例）
24. 負荷分散問題の定式化結果 • 混合整数非線形最適化問題かつNP困難 ◦ 非常に難しいクラスの問題 ◦ NP困難である Task Assignment Problem (TAP) から多項式時間還元可能より ◦ 負荷分散問題が多項式時間で解ける => TAPも多項式時間で解ける • ヒューリスティクス or ソルバで解く のが一般的 • ただし処理が重い ◦ オンチェーンで直接実行するのはコストに見合わない ◦ => コンペティションベースで解を集めよう • ※定式化のやり方はこれ以外にも色々考えられる ◦ UXが上がれば良い ◦ 良い問題性質の定式化があるかも 24
25. コンペティション形式にして解を集める • 最適化問題を公開 • 最も良い解を提出したプレイヤーに報酬を与える ◦ 報酬は手数料の一部を与えるなど ◦ Proof of Work • 定期的（例: 1エポック = 64ブロック）に行う • 解の検証は、オンチェーンで行う • 他のプレイヤーが解のカンニングするとアンフェアなので解の暗号化など工夫が考 えられる ◦ いわゆるコミットメントスキーム 25
26. 問題の解き方の例: メタヒューリスティクス • ヒューリスティックの中でも様々な問題に汎用的に用いられるもの • 例: 焼きなまし法 26 https://kumagallium.hatenablog.com/entry/2019/07/24/124501
27. 評価・実験 • Ethereum 2.0 の仕様を参考にシミュレーション ◦ Beacon chain や Yanking など • アカウント数 = 1000, シャード数 = 8 • 利己的のみ vs. プロトコルで直接 • 結果 ◦ 総手数料は約半分(図) ◦ クロスシャードトランザクション数 は約1/5程度に • モデル・仮定の妥当性については 改善の余地あり ◦ 動的に取引の分布が変化しない、など 27
28. 全体のまとめ • Account/Balanceモデルのシャーディングにおける課題 ◦ バリデータのシャッフルによるオーバーヘッド ◦ クロスシャードトランザクションによる UXの悪化 ◦ 特定シャードへの負荷集中 • 「特定シャードへの負荷集中」の解決策 ◦ コンペティションベースのアカウント動的割り当て ◦ より現実的なモデル・仮定、プロトコル開発に向けて現在研究中 28
29. 29 Join at slido.com #61956 Audience Q&A Session