Bitcoin Cash Upgrade 2024-05-15
607 Views
June 28, 24
スライド概要
関連スライド
各ページのテキスト
Bitcoin Cash Upgrade 2024-05-15
自己紹介 • haryu703 • コインチェック株式会社 (2020～) 2
今回のアップグレードの概要 今回は下記の 1 件のプロトコルアップデートが行われた • CHIP-2023-04 Adaptive Blocksize Limit Algorithm for Bitcoin Cash ‣ ブロックサイズの上限を需要に応じて自動で増減させる 3
ブロックサイズ上限の歴史 • 2010 年-2017 年: 1MB • 2017 年-2018 年: 8MB • 2018 年-2024 年: 32MB • 2024 年-: 32MB - 4
背景 • ブロックサイズの上限はネットワークを健全に維持するために 必要 • 需要や技術の進歩に合わせて上限を変更する必要はある • ブロックサイズを上げるには関係者の合意を取るなどのコスト がかかる 5
目的 • 今後のブロックサイズに関する合意コストをなくす • 需要に応じたブロックサイズの上限を自動で設定する 6
方法 「control function」と「elastic buffer function」という 2 つの要素で制御される 𝑦𝑛 = 𝜀𝑛 + 𝛽𝑛 ⎧𝜀0 if 𝑛 ≤ 𝑛0 { { 𝜁⋅𝑥 −𝜀 𝜀𝑛 = ⎨𝜀𝑛−1 + 𝛾 ⋅ (𝜁 ⋅ 𝑥𝑛−1 − 𝜀𝑛−1 − 𝜁 ⋅ 𝛽𝑛−1 ⋅ 𝜁⋅𝑦𝑛−1−𝜀𝑛−1 ) if 𝑛 > 𝑛0 and 𝜁 ⋅ 𝑥𝑛−1 > 𝜀𝑛−1 𝑛−1 𝑛−1 { {max(𝜀𝑛−1 + 𝛾 ⋅ (𝜁 ⋅ 𝑥𝑛−1 − 𝜀𝑛−1 ), 𝜀0 ) if 𝑛 > 𝑛0 and 𝜁 ⋅ 𝑥𝑛−1 ≤ 𝜀𝑛−1 ⎩ ⎧𝛽0 if 𝑛 ≤ 𝑛0 { 𝛽𝑛 = ⎨max(𝛽𝑛−1 − 𝜃 ⋅ 𝛽𝑛−1 + 𝛿 ⋅ (𝜀𝑛 − 𝜀𝑛−1 ), 𝛽0 ) if 𝑛 > 𝑛0 and 𝜁 ⋅ 𝑥𝑛−1 > 𝜀𝑛−1 {max(𝛽 if 𝑛 > 𝑛0 and 𝜁 ⋅ 𝑥𝑛−1 ≤ 𝜀𝑛−1 𝑛−1 − 𝜃 ⋅ 𝛽𝑛−1 , 𝛽0 ) ⎩ 7
• 𝑦: ブロックサイズの上限 • 𝑛: ブロック高 • 𝜀: control function • 𝛽: elastic buffer function • 𝑛0 , 𝜀0 , 𝛽0 : 初期値 • 𝑥: 実際に作られたブロックのサイズ • 𝛾: control function の 「forget factor」 ‣ ブロックサイズの増減率を調整する • 𝜁: control function の「asymmetry factor」 ‣ ブロックサイズの増加率と減少率の差を調整する • 𝜃: elastic buffer の減少率 ‣ control function 側の増加率が𝜃より低いと elastic buffer は減少する • 𝛿: elastic buffer の「gearing ratio」 ‣ elastic buffer と control function をどの程度連動させるかを調整する 8
mainnet のパラメータ • 𝜀0 = 16000000 • 𝛽0 = 16000000 • 𝑛0 = ハードフォーク時点のブロック高 • 𝜁 = 1.5 1 • 𝛾 = 37938 • 𝛿 = 10 1 • 𝜃 = 37938 • ブロックサイズ上限の初期値は 𝑦0 = 𝜀0 + 𝛽0 = 32000000 でハードフォーク前と同じ • このアルゴリズムが有効化されている testnet は𝜀0 、𝛽0 および𝑛0 が異なる • その他、一時的に𝑦temporary_max = 2000000000(2 GB)が設定されている ‣ 32-bit アーキテクチャや p2p プロトコルの制約 ‣ 2028 年 5 月までに取り除かれるらしい 9
パラメータの特徴 control function • ブロックサイズ増加率の上限: ( 𝜀𝑛𝜀−𝜀𝑛−1 ) 1 = 𝛾 ⋅ (𝜁 − 1) = 75876 ‣ 年間で最大 +200 % • ブロックサイズ減少率の上限: ( 𝜀𝑛𝜀−𝜀𝑛−1 ) 1 = −𝛾 = − 37938 𝑛−1 max 𝑛−1 min ‣ 年間で最大 −75 % elastic buffer function • 𝜀 に対する 𝛽 の上限: ( 𝛽𝜀 𝑛 ) 𝑛 max 𝜁−1 = 𝛿 ⋅ 𝛾𝜃 ⋅ 𝛾 ⋅(𝜁−1)+1 = 3.33 𝜃 • 𝛽の減少率は𝜃で、年間で最大 −75 % log(0.5) ‣ 半減するのは log(1−𝜃) = 26296ブロックで 10 分間に 1 ブロックなら約 6 ヶ月 • 急激なブロックサイズの上昇に対応できるような増加をするらしい 10
パラメータの選び方 Asymmetry factor (𝜁) 「Asymmetry factor」は control function の増減率の関係を決める 𝜁 = 2 だと増加率と減少率は同じになる • ハッシュレートを 50 % 持った攻撃者によるスパム TX でブロックサイズを増やす攻 撃に対し、防御側が空ブロックを作ることが強制される ‣ 防御側は fee を得られないため攻撃側に対して不利 𝜁 = 1.5だと上記の攻撃シナリオに耐性がつく • ハッシュレートが 50:50 の場合、防御側は上限の 33% のブロックサイズまで作れる • 空ブロックでブロックサイズを小さくする攻撃はしやすくなる ‣ こちらは防御側が fee を受け取れるため有利 11
Forget factor (𝛾) 「Forget factor」は control function の増減率の関係を決める • 1 年間(52959 ブロック)の最大増加率が +100 % になるように設定された • BIP-101 で提案されていた増加率よりは高いが、最大増加率を維持するのは現実的 ではないため実際に BIP-101 のブロックサイズを超えることは考えにくい Gearing ratio (𝛿) と Decay rate (𝜃) 「Gearing ratio」と「Decay rate」は elastic buffer の大きさと増減速度を決める • 大きさは最大で𝛽が𝜀の 3.33 倍になるように設定されている ‣ 数ヶ月でブロックサイズが倍になっても大丈夫らしい • 減少速度は半年で半分になるように設定されている 12
シナリオ 下記を繰り返す場合¹ • すべてのブロックがブロックサイズ上限で 8 ヶ月 • 33% のブロックがブロックサイズ上限、他のブロックが 21MB で 4 ヶ月 ¹https://gitlab.com/0353F40E/ebaa/-/raw/9606b73b10551e4ef56e238c7a7bedc4f95236dd/simulations/results/abla-ewma-elastic-buffer-bounded-01-ne-scenario-13.png 13
90% のブロックがブロックサイズ上限の 90%、残りが 21MB が続く場合² ²https://gitlab.com/0353F40E/ebaa/-/raw/9606b73b10551e4ef56e238c7a7bedc4f95236dd/simulations/results/abla-ewma-elastic-buffer-bounded-01-ne-scenario-14.png 14
ハッシュレートの 50% がスパム攻撃をする場合³ • 1-4 年目: 50% のブロックがブロックサイズ上限、残りが 10.67MB • 5-8 年目: 50% のブロックがブロックサイズ上限、残りが 21.33MB ³https://gitlab.com/0353F40E/ebaa/-/raw/9606b73b10551e4ef56e238c7a7bedc4f95236dd/simulations/results/abla-ewma-elastic-buffer-01-scenario-15.png 15
まとめ • ブロックサイズの上限を自動で変更するアルゴリズムが導入された • 今後ブロックサイズの上限は需要に応じてハードフォーク無しに変更される 16