---
title: Bitcoin Cash Upgrade 2024-05-15
tags: 
author: [haryu703](https://convert.docswell.com/user/haryu703)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/3EKDL44GJD.jpg?width=480
description: https://cryptocurrency.connpass.com/event/321358/
published: June 28, 24
canonical: https://convert.docswell.com/s/haryu703/5XYM3G-2024-06-28-230006
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/3EKDL44GJD.jpg)

Bitcoin Cash Upgrade 2024-05-15


# Page. 2

![Page Image](https://bcdn.docswell.com/page/L73R3LL5J5.jpg)

自己紹介
• haryu703
• コインチェック株式会社 (2020～)
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/87DY4NNY7G.jpg)

今回のアップグレードの概要
今回は下記の 1 件のプロトコルアップデートが行われた
• CHIP-2023-04 Adaptive Blocksize Limit Algorithm for Bitcoin Cash
‣ ブロックサイズの上限を需要に応じて自動で増減させる
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/VJP6M552E8.jpg)

ブロックサイズ上限の歴史
• 2010 年-2017 年: 1MB
• 2017 年-2018 年: 8MB
• 2018 年-2024 年: 32MB
• 2024 年-: 32MB -
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/2EV39PPX7Q.jpg)

背景
• ブロックサイズの上限はネットワークを健全に維持するために
必要
• 需要や技術の進歩に合わせて上限を変更する必要はある
• ブロックサイズを上げるには関係者の合意を取るなどのコスト
がかかる
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/57G3ZPPRJL.jpg)

目的
• 今後のブロックサイズに関する合意コストをなくす
• 需要に応じたブロックサイズの上限を自動で設定する
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/4EQ5L22YJP.jpg)

方法
「control function」と「elastic buﬀer function」という 2 つの要素で制御される
𝑦𝑛 = 𝜀𝑛 + 𝛽𝑛
⎧𝜀0
if 𝑛 ≤ 𝑛0
{
{
𝜁⋅𝑥
−𝜀
𝜀𝑛 = ⎨𝜀𝑛−1 + 𝛾 ⋅ (𝜁 ⋅ 𝑥𝑛−1 − 𝜀𝑛−1 − 𝜁 ⋅ 𝛽𝑛−1 ⋅ 𝜁⋅𝑦𝑛−1−𝜀𝑛−1 ) if 𝑛 &gt; 𝑛0 and 𝜁 ⋅ 𝑥𝑛−1 &gt; 𝜀𝑛−1
𝑛−1
𝑛−1
{
{max(𝜀𝑛−1 + 𝛾 ⋅ (𝜁 ⋅ 𝑥𝑛−1 − 𝜀𝑛−1 ), 𝜀0 )
if 𝑛 &gt; 𝑛0 and 𝜁 ⋅ 𝑥𝑛−1 ≤ 𝜀𝑛−1
⎩
⎧𝛽0
if 𝑛 ≤ 𝑛0
{
𝛽𝑛 = ⎨max(𝛽𝑛−1 − 𝜃 ⋅ 𝛽𝑛−1 + 𝛿 ⋅ (𝜀𝑛 − 𝜀𝑛−1 ), 𝛽0 ) if 𝑛 &gt; 𝑛0 and 𝜁 ⋅ 𝑥𝑛−1 &gt; 𝜀𝑛−1
{max(𝛽
if 𝑛 &gt; 𝑛0 and 𝜁 ⋅ 𝑥𝑛−1 ≤ 𝜀𝑛−1
𝑛−1 − 𝜃 ⋅ 𝛽𝑛−1 , 𝛽0 )
⎩
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/KJ49DLLZ71.jpg)

• 𝑦: ブロックサイズの上限
• 𝑛: ブロック高
• 𝜀: control function
• 𝛽: elastic buﬀer function
• 𝑛0 , 𝜀0 , 𝛽0 : 初期値
• 𝑥: 実際に作られたブロックのサイズ
• 𝛾: control function の 「forget factor」
‣ ブロックサイズの増減率を調整する
• 𝜁: control function の「asymmetry factor」
‣ ブロックサイズの増加率と減少率の差を調整する
• 𝜃: elastic buﬀer の減少率
‣ control function 側の増加率が𝜃より低いと elastic buﬀer は減少する
• 𝛿: elastic buﬀer の「gearing ratio」
‣ elastic buﬀer と control function をどの程度連動させるかを調整する
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/LE1KZLLDJG.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/GEWD9VV8J2.jpg)

パラメータの特徴
control function
• ブロックサイズ増加率の上限: ( 𝜀𝑛𝜀−𝜀𝑛−1 )
1
= 𝛾 ⋅ (𝜁 − 1) = 75876
‣ 年間で最大 +200 %
• ブロックサイズ減少率の上限: ( 𝜀𝑛𝜀−𝜀𝑛−1 )
1
= −𝛾 = − 37938
𝑛−1
max
𝑛−1
min
‣ 年間で最大 −75 %
elastic buﬀer function
• 𝜀 に対する 𝛽 の上限: ( 𝛽𝜀 𝑛 )
𝑛
max
𝜁−1
= 𝛿 ⋅ 𝛾𝜃 ⋅ 𝛾 ⋅(𝜁−1)+1
= 3.33
𝜃
• 𝛽の減少率は𝜃で、年間で最大 −75 %
log(0.5)
‣ 半減するのは log(1−𝜃)
= 26296ブロックで 10 分間に 1 ブロックなら約 6 ヶ月
• 急激なブロックサイズの上昇に対応できるような増加をするらしい
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/47ZG9449E3.jpg)

パラメータの選び方
Asymmetry factor (𝜁)
「Asymmetry factor」は control function の増減率の関係を決める
𝜁 = 2 だと増加率と減少率は同じになる
• ハッシュレートを 50 % 持った攻撃者によるスパム TX でブロックサイズを増やす攻
撃に対し、防御側が空ブロックを作ることが強制される
‣ 防御側は fee を得られないため攻撃側に対して不利
𝜁 = 1.5だと上記の攻撃シナリオに耐性がつく
• ハッシュレートが 50:50 の場合、防御側は上限の 33% のブロックサイズまで作れる
• 空ブロックでブロックサイズを小さくする攻撃はしやすくなる
‣ こちらは防御側が fee を受け取れるため有利
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/YJ6YK33D7V.jpg)

Forget factor (𝛾)
「Forget factor」は control function の増減率の関係を決める
• 1 年間(52959 ブロック)の最大増加率が +100 % になるように設定された
• BIP-101 で提案されていた増加率よりは高いが、最大増加率を維持するのは現実的
ではないため実際に BIP-101 のブロックサイズを超えることは考えにくい
Gearing ratio (𝛿) と Decay rate (𝜃)
「Gearing ratio」と「Decay rate」は elastic buﬀer の大きさと増減速度を決める
• 大きさは最大で𝛽が𝜀の 3.33 倍になるように設定されている
‣ 数ヶ月でブロックサイズが倍になっても大丈夫らしい
• 減少速度は半年で半分になるように設定されている
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/GJ5GPLL8J4.jpg)

シナリオ
下記を繰り返す場合¹
• すべてのブロックがブロックサイズ上限で 8 ヶ月
• 33% のブロックがブロックサイズ上限、他のブロックが 21MB で 4 ヶ月
¹https://gitlab.com/0353F40E/ebaa/-/raw/9606b73b10551e4ef56e238c7a7bedc4f95236dd/simulations/results/abla-ewma-elastic-buﬀer-bounded-01-ne-scenario-13.png
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/LE3R3LLG75.jpg)

90% のブロックがブロックサイズ上限の 90%、残りが 21MB が続く場合²
²https://gitlab.com/0353F40E/ebaa/-/raw/9606b73b10551e4ef56e238c7a7bedc4f95236dd/simulations/results/abla-ewma-elastic-buﬀer-bounded-01-ne-scenario-14.png
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/8EDY4NNNEG.jpg)

ハッシュレートの 50% がスパム攻撃をする場合³
• 1-4 年目: 50% のブロックがブロックサイズ上限、残りが 10.67MB
• 5-8 年目: 50% のブロックがブロックサイズ上限、残りが 21.33MB
³https://gitlab.com/0353F40E/ebaa/-/raw/9606b73b10551e4ef56e238c7a7bedc4f95236dd/simulations/results/abla-ewma-elastic-buﬀer-01-scenario-15.png
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/V7P6M55NJ8.jpg)

まとめ
• ブロックサイズの上限を自動で変更するアルゴリズムが導入された
• 今後ブロックサイズの上限は需要に応じてハードフォーク無しに変更される
16


