# Unpredictable RANDAO

Co-Author [banri](https://x.com/banr1_) and [vita](https://x.com/keccak255), [Hiro](https://x.com/164zheng) from [Titania Research](https://titaniaresear.ch/).

Thank you [SoraSue](https://x.com/SoraSue77) and [Masato](https://x.com/grandchildrice) to discussed, and also thank you [Davide](https://x.com/0xseiryu), [Lin](https://x.com/linoscope), [donnoh](https://x.com/donnoh_eth), [Vitalik](https://x.com/VitalikButerin) and all the people to discussed with us in [ZuBerlin](https://zuberlin.city/).

## TLDR;

本稿では、Ethereum Beacon Chain における従来型 RANDAO が抱える predictability と manipulability の課題を定量的に整理し、攻撃者が連続 k スロットを支配した場合に得られる状態空間を指数関数的な $2^k$ から線形 $k+1$ へ抑制する Unpredictable RANDAO を提案する。具体的には、単一 proposer によるリビール値を廃止し、委員会による DKG ＋ しきい値署名でリビール値を生成することで、将来のミックス値の事前予測可能性を大幅に低減し、Selfish Mixing／Forking Attack の経済的インセンティブを根本から削減する。

## 1. 現行RANDAOの仕組み

Proof‑of‑Stake (PoS) コンセンサスにおいて、公平な乱数源は極めて重要である。Ethereum Beacon Chain では RANDAO により乱数を生成し、2 epoch 先（33–64 slot）の proposer 選定に利用している（アテステーション委員会選出にも乱数を用いるが本稿では割愛する）。

現行の RANDAO では、各スロット $l$ で選出された proposer $P_l$ が自身の秘密鍵 $sk_l$ を用いて次式の署名を作成する。

$$
\sigma_l = \mathrm{sign}_{\mathrm{BLS}}(sk_l, l)
$$

ここで、$\mathrm{sign}_{\mathrm{BLS}}$ はBLS署名を表す。

署名 $\sigma_l$ はそのままリビール値 $r_l$ としてブロックボディに含められる。

$$
r_l = \sigma_l
$$

各 attester は proposer $P_l$ の公開鍵 $pk_l$ を用いて署名が正当かを検証する。

$$
\mathrm{verify}_{\mathrm{BLS}}(pk_l, l, \sigma_l) = 1
$$

ここで、$\mathrm{verify}_{\mathrm{BLS}}$はBLSの検証関数を表す。

検証成功時のみ $r_l$ を受理し、スロット $l+1$ のミックス値 $m_{l+1}$ を次式で更新する。

$$
m_{l+1} = \mathrm{xor}(m_l, H(\sigma_l))
$$

失敗した場合、そのブロックは無効となりミックス値は更新されない。

Epoch $e$ の最終スロット $l$ でのミックス値を用いて、epoch $e+2$ の proposer 選定シード $S_{e+2}$ を得る。

$$
S_{e+2} = H\bigl(m_l + (e+2) \bigr)
$$

ここで、$H$はハッシュ関数を表し、$e+2$はバイトに変換されたものとする。


## 2. 既知の問題点

攻撃者が epoch の末尾 $k$ slot を連続してproposerとして専有した場合、各 slot のブロック提案または棄却というバイナリな選択肢を通じて、epoch $n + 2$ におけるプロポーザー割り当てを自らに有利な方向へ誘導できる。なぜなら、各スロットの リビール値を proposer 自身が生成する現行の仕組みでは、攻撃者はブロック提案するか否かの全パターン $2^k$ を事前に計算し、将来のミックス値出力をあらかじめ予測することが可能であるためである。

Alpturer & Weinberg（2024）[^op]は、このRANDAOの操作（Selfish Mixing）をマルコフ決定過程（MDP）として定式化した。これは攻撃者がエポック末尾で割り当てられたスロットを意図的にブロックを提出するかどうかを選択することで、次エポックのRANDAO出力を有利に操作する行動を理論的に分析した研究である。

具体的には、攻撃者が保有するステーク比率 $\alpha \in (0,1)$ とエポック末尾で連続して攻撃者が支配可能なスロット数（tailの長さ）$k$、およびそれまでのエポック内において攻撃者が既に占有したスロット数（countと表記）を状態変数として用い、この攻撃をマルコフ決定過程（MDP）として定式化した。攻撃者は、tail期間中の各スロットにおいてブロックを提出するかしないかというバイナリな選択を意図的に行うことができるため、取り得る行動パターンが合計で $2^k$ 存在することを示した。そして、これらの状態変数および行動空間に基づき、攻撃者にとって最適な攻撃戦略の数値評価を実施した。

彼らの解析の主要な結果は以下の通りである。

攻撃者が獲得できるブロック提案権の比率（平均的な報酬）は、tailの長さ $k$ が増加するにつれ、その選択可能性は指数関数的に増大するものの、実際にはスロットを棄却することによる報酬の即時喪失とtailの長さが発生する確率の急減（$\alpha^k$）により強く抑制されるため、利得は滑らかに増加することを示した。

ステーク比率 $\alpha$ を持つ攻撃者が Selfish Mixing 攻撃を行った際に獲得する平均的な proposer 割り当て比率を $f_{\mathrm{attack}}(\alpha)$ とし、攻撃を行わない場合の本来の正直な proposer 割り当て比率（期待値としてステーク比率と等しい）を $\alpha$ としたとき、余剰利得 $\Delta(\alpha)$ は以下のように定義される。

$$
\Delta(\alpha) = f_{\mathrm{attack}}(\alpha) - \alpha
$$

解析によれば、$\Delta(\alpha)\ge 1\%$が初めて達成されるステーク比率はおおむね$\alpha \approx 0.25$（25%）であり、ステーク比率$\alpha = 0.20$では、$\Delta(\alpha)$は約0.68%にとどまる。つまり、ステーク比率が20%の攻撃者がSelfish Mixing攻撃を実行した場合、その攻撃によって得られる平均的なproposer割り当て比率は20.68%となり、攻撃をしない正直な行動（20%）と比較した際の「攻撃の恩恵（余剰利得）」は0.68%程度に限定される。したがって、2〜3スロットのtailで1%以上の余剰利得を得るためには、少なくとも25%程度のステーク保有が必要になることを示している。

なぜなら、このSelfish Mixing攻撃では、攻撃者が自身に割り当てられたスロットを意図的に棄却する必要があるため、一定のブロック報酬を放棄する経済的コストを伴う。結果として、比較的小規模な攻撃者（$\alpha < 0.20$）にとっては、この手法単独での経済的な魅力は限定的となる。

このように、Selfish Mixingは理論上の攻撃シナリオであり、ステーク比率が比較的小さい攻撃者にとってはその経済的魅力が抑制される一方、ステーク比率が一定水準（例えば25%以上）を超える攻撃者にとっては無視できない経済的な利得をもたらす可能性が示された。

しかし、その後 Nagyら(2025)[^reorg]は、Selfish Mixingに加え、RANDAO Forking Attackという新たな攻撃手法を導入し、RANDAOの操作可能性がさらに深刻であることを明らかにした。

彼らは特に、攻撃者がエポック境界前後のスロットを支配する場合、攻撃者は自身が提案したブロックを意図的に非公開状態に保持し、後続の正直なブロックをフォークアウト（reorgで統一）することで、正規チェーンから除外可能であることを示した。

この攻撃（Ex-ante Forking）の成功条件は、フォークチョイスルールにおけるステーク比率 $\alpha$ と proposer boost $b$ を考慮した以下の重み条件で定式化される。

$$
2\alpha + b > 1 - \alpha \quad (b = 0.4)
$$

Nagyら(2025) はこの条件を以下の図で示している。


同図は、攻撃者がエポック末尾および次エポックの冒頭スロットを制御し、自身の提案したブロックを意図的に非公開状態に保持しつつ、後続の正直なproposerが提案したブロックをreorgすることでフォークを発生させる手順を示している。この図により、上記の不等式の条件下で攻撃者が重み付きフォークチョイスに勝ち、自身に有利な ミックス値 値を選択できるメカニズムを直観的に理解できる。

これにより、攻撃者は約20%以上（$\alpha \ge 0.20$）のステークを保有しているだけで特定のスロットにおいて容易にreorgを発生させ、自身に有利なミックス値出力を選択可能となる。

この攻撃手法の導入により、従来のSelfish Mixingと比較して以下の2つの大きな利点が生じることを示した。

1. 攻撃者が必ずしも連続した$k$個のスロットを直接支配しなくとも、reorgを挟むことで実質的に連続して支配した状況を再現できる。具体例として、epoch末尾の27, 28, 30, 31番目のスロットのみを攻撃者が支配し、29, 32番目を正直なproposerが取得した場合でも、29, 32番目の正直なブロックをreorgすることで、実質的に連続したスロットを獲得した場合と同等の予測可能性を得られる。
1. 攻撃者は自身の割り当てられたスロットを意図的に棄却・非公開にする必要がなくなり、正直なプロポーザのブロックのみをreorgするため、攻撃コストが著しく低下する。従来のSelfish Mixing攻撃は、自身の割り当てスロットを故意に棄却する必要があり、それが攻撃者にとってコスト要因となっていた。

さらにNagyらは、Forking Attack と Selfish Mixing を統合した攻撃モデルをマルコフ決定過程（MDP）として定式化し、攻撃者にとっての最適な攻撃ポリシーを数値解析した。その解析により、Forking Attack を併用すると、従来の Selfish Mixing 単独では攻撃コストが高すぎて利得を得られなかった比較的低いステーク比率（約8%）からでも、攻撃者が追加的な利得を得ることが可能となることが明らかになった。特に、攻撃者が全スロットの半数を支配するために必要なステーク比率が、Selfish Mixing 単独での約46.24%から、Forking Attack との統合により約41.95%に低下することを示した。

また、チェーン性能への影響も定量化されており、攻撃者が33%程度のステークを保有するだけで約3.9%のスループット低下が発生し、さらに30%のステークでもエポックの約18.9%にフォークが頻繁に発生することが判明した。これにより、Ethereumブロックチェーンのユーザーの取引体験やチェーンの信頼性が著しく損なわれる可能性が示された。

### 2.1 課題の整理

これまでの議論を踏まえると、現行のEthereumのRANDAOが抱える根本的問題は次の二つの要素に整理される。

* **Predictability**: 攻撃者が複数の tail $k$スロットを支配すると、将来のミックス値出力を $2^k$ 通り計算することができる。
* **Manipulability**: 攻撃者が上記の計算を踏まえ、利益を最大化するために意図的にブロックを提案しない、あるいは正直なブロックをreorgすることが可能である。

ここで、ManipulabilityよりもPredictabilityの方が重要であることに留意したい。どれだけManipulabilityがあっても、操作した際の期待収益の値が予測不可能であれば、インセンティブの観点からこの操作可能性は無意味に等しい。

本研究の目的は完全にmanipulabilityを排除することではなく、むしろpredictabilityの大部分を低下させることに焦点を当てている。具体的には、Proposerと別主体によるしきい値署名の仕組みを導入することで、エポック末尾の連続スロットを支配しても攻撃者が将来の乱数出力の事前予測可能性を限りなく下げる。

これにより、ミックス値の予測可能性が低下し、ブロックを非公開・棄却あるいはreorgする経済的あインセンティブが減少することを示す。本研究の中心的主張は、「ミックス値出力の予測可能性の大部分を取り除くことで、RANDAO操作の経済的インセンティブ自体を根本から弱められる」という点にある。

## 3. 我々の提案：Unpredictable RANDAO

本提案では、現行の RANDAO が持つ根本的な欠点、すなわち proposer が事前に乱数を計算可能であることを解決するため、単一の proposer によるリビール値の公開を廃止し、新たに複数のバリデータから構成される委員会を導入し、DKGとしきい値署名を用いてリビール値を生成する手法を提案する。

具体的には、ある slot $l+1$ における乱数リビール値$r_{l+1}$を次のように生成する。

まず、slot $l$ に対して事前に定められた委員会サイズを$n$、集合署名の生成に必要な署名数のしきい値$t$を$\lfloor 2n/3\rfloor+1$と定める。つまり、委員会の $2/3$ を超える署名して初めて集合署名が完成する。これにより、単一の検証者が乱数の生成をコントロールできないようになり、十分な数の署名が揃った場合にのみ乱数が確定する。

この委員会に属する各メンバー $A_{l,i}$ は、自身のシェア $s_{l,i}$ を用いて、スロット $l$ に依存する部分署名 $\sigma_{l,i}$ を以下のように計算する。

$$
\sigma_{l,i} = \mathrm{sign}_{\mathrm{share}}(s_{l,i}, l)
$$

ここで$\mathrm{sign}_{\mathrm{share}}$はしきい値署名スキームにおける部分署名を表す。
この署名シェアが $t$ に達すると、しきい値署名スキームを用いてユニークな集合署名 $\Sigma_l$ を出力することが可能になる。

$$
\Sigma_l = \mathrm{combine}(\{\sigma_{l,i}\}_{i\in T}), \ |T| \geq t
$$

ここで、$T$ は部分署名を提出した検証者のインデックス集合を表し、$\mathrm{combine}$ はBLSしきい値署名の結合演算子である。

得られたしきい値署名 $\Sigma_l$ は次スロット $l+1$ の proposer によってブロック内にリビール値として含められる。

$$
r_{l+1} = \Sigma_l
$$

スロット $l+1$ の proposer は、この集合署名$\Sigma_l$（リビール値）をブロックに含めて提案しなければならない。しきい値署名の検証は次の条件を満たす必要がある。

$$
\mathrm{verify}_{\mathrm{th.sig}}(\mathrm{PK}_{l}, l, \Sigma_l) = 1
$$

ここで、$\mathrm{PK}_l$ はスロット$l$のIL委員会の集合公開鍵を、$\mathrm{verify}_{\mathrm{th.sign}}$はしきい値署名の検証関数を表す。

attester によるブロックの正当性検証は以下の二つの条件を必ず満たさなければならない。

1. 提案されたブロック内に集合署名 $\Sigma_l$（リビール）が含まれていること。
2. 含まれているリビール値が正しい集合署名であること、つまり上記の検証が成功すること。

これらの条件が一つでも満たされない場合、attester はブロックを拒否（検証値を0）し、そのブロックは正規チェーンに含まれない。

この方式により、ある攻撃者が連続して複数の tail スロットを占有した場合でも、自身だけでリビール値を操作することが不可能となり、将来のミックス値を予測する能力が著しく低下する。

ここで特筆すべき点として、しきい値署名の値のユニーク性が挙げられる。$n$人のうち$t$人の署名が集まりさえすれば、そこで生成される値はどの$t$人が署名したかに依存せず、決定論的にユニークな値が生成される。かつ、大多数を支配してその秘密鍵を認知していない限り予測不可能である。つまり、しきい値署名は、**事前に予測不能でありながら、proposerが操作することも不可能である値を生成可能**な優れた暗号スキームである(本質的に避けられない、提案するか否かを除いて)。攻撃者が数人紛れ込んでいたとしても、彼らが署名するか否かが結果に影響しない。このしきい値署名の特性が、本提案でRANDAOをunpredictableにできた技術的要点である。

なお、我々が改善提案しているのはリビール値の計算源であり、ミックス値・シード値の計算方法に変更は加えていない。


### 3.1. 設計

#### 3.1.1. IL Committee

委員会として新たにRANDAO専用の委員会を設置することも選択肢の一つであるが、我々はIL Commitee[^focil]の仕事を増やすことを選定した。人数が多すぎるとパフォーマンスの観点からDKGが難しくなるが、現在のIL Committeeの16人はその観点で適している。また、新たに設けるよりも既存の委員会の仕事を増やす方がプロトコルをシンプルに保つことができる。

FOCILで提案されていたIL Committeeには経済的インセンティブは存在しない。しかし、この仕組みにおいては経済的インセンティブが存在していないとワークしない。本Unpredictable RANDAOを導入する際には、部分署名を提出した人に新たにattestation報酬を追加する必要があると考えられる。実際にプロトコルに組み込む際には、より詳細な報酬設計をするべきだろう。

#### 3.1.2. Fast Batched Asynchronous DKG

秘密分散法として、我々はFast Batched Asynchronous DKG[^fbadkg]を選定した。最も古典的なPedersen DKGではパフォーマンスの観点から、この方式で動かすことは難しい。Fast Batched Asynchronous DKGは完全非同期モデルで $t<n/3$ のビザンチン耐性を保ったまま、各ノードが送信する通信量が委員会サイズにほぼ依存しない。論文の評価では $n=49,\,t=16$ でも毎秒 5 万件のpresignatureを生成できるとされており、16名構成のIL Committeeでも十分に処理可能である。さらに FBADKG は多項式コミットメントを完全に排除してPedersen系DKGの $O(n^2)$ 通信と高ラウンド数を大幅に削減しているため、実装上の帯域・レイテンシ制約を満たしやすい。

#### 3.1.3. BLS Threshold Signature

しきい値署名スキームとしては、現在のBLS署名の仕様から自然に拡張可能なBLS Threshold Signature[^blsthsig]を選定した。同じ楕円曲線やペアリング関数を用いたまま、少しの追加実装で実現可能となる。Beam Chain[^beamchain]構想においては、FALCON[^falcon]などと相性のいい他のしきい値署名スキームを検討するべきだろう。

### 3.2. 全体フロー

委員会メンバーがDKGで秘密分散、しきい値署名を生成し、それをproposerがリビール値としてbeacon block bodyに含める、というフローを下記にまとめる。

なお、以下は抽象化したシンプルな手順であり、委員会の構成方法、DKG手法、しきい値署名スキームの選定手法次第で詳細は異なる。

例えば下記で登場するコミットメント$C_i$という値について、我々の提案で用いるFast Batched Asynchronous DKGではコミットメントという概念は登場しない。
しかし、本質的な手順としては以下フローで十分である。

前提の記号を定める。

- $n$: 委員会人数
- $t=\lfloor n2/3\rfloor+1$: しきい値
- $l$: スロット番号
- $i$: 委員会メンバーのインデックス
- $P_l$: スロット$l$のプロポーザー
- $A_{l,i}$: スロット$l$の$i$番目の委員会メンバー
- $f_{l,i}$: 委員会メンバー$A_{l,i}$が各自生成する多項式
- $a_{l,i,j}$: $f_{l,i}$の$j$次係数 ($0 \le j \le k-1$)
- $C_{l,i,j}$: 委員会メンバー$A_{l,i}$の多項式係数$a_{l,i,j}$に対するコミットメント
- $H$: 値が$G_1$上となるようなハッシュ関数
- $s_{l,i \rightarrow j} = f_{l,i}(j)$: 委員会メンバー$A_{l,i}$から$P_j$へと渡される部分的シェア
- $s_{l,i} = \sum_j s_{j \rightarrow i}$: 委員会メンバー$A_{l,i}$のシェア, しきい値署名に使用する
- $\mathrm{verify}_{\mathrm{DKG}}(C_j, s_{l,j \rightarrow i})$: DKGの部分シェアを検証する関数
- ${\mathrm{verify}_{\mathrm{th.share.sig}}}(PK_{l,i}, l, \sigma_l)$: しきい値署名の部分署名$\sigma_{l,i}$を検証する関数
- ${\mathrm{verify}_{\mathrm{th.sig}}}(PK_l, l, \Sigma_l)$: しきい値署名の集合署名$\Sigma_l$を検証する関数
- $pk_{l,i}$: スロット$l$の委員会メンバー${A_{l,i}}$の部分公開鍵
- $PK_l$: スロット$l$の委員会の集合公開鍵
- $\mathrm{sign}_{\mathrm{th.share.sig}}(s_i, l)$: シェア$s_i$によるスロット$l$への部分署名
- $\sigma_{l,i}$: 委員会メンバー$A_{l,i}$の部分署名値
- $T_l$: スロット$l$で署名したメンバー$A_{l,i}$のインデックス$i$の集合, $|T_l| \ge t$
- $\mathrm{combine}(\{\sigma_{l,i}\}_{i \in T_l})$: 部分署名値の結合
- $\Sigma_l$: スロット$l$での集合署名値
- $r_l = \Sigma_{l-1}$: スロット$l$のリビール値
- $m_l = \mathrm{xor}(m_{l-1}, r_l)$: スロット$m$のミックス値

全体のフローは以下である。

**1. シェア生成フェーズ (epoch $e-1$ の先頭slot $l'$ )**

1. 選出確認 (committee member, slot $l'$ ): 自分自身が委員会メンバーとして選ばれているか確認
1. 多項式生成 (committee member, slot $l'$ ): 自分自身の多項式$f_{l,i}$の係数$a_{l,i,0}, a_{l,i,1}, ..., a_{l,i,t-1}$を生成
1. コミットメント (committee member, slot $l'$ ): $C_i$を計算し全員にブロードキャスト
1. 部分シェアの交換 (committee member, slot $l'$ ): $s_{l,i \rightarrow j}$を計算し$P_j$へ送付
1. 部分シェアの検証 (committee member, slot $l'$ ): 受け取った$s_{l,j \rightarrow i}$を$\mathrm{verify}_{\mathrm{DKG}}$で検証
1. シェアの計算 (committee member, slot $l'$ ): $s_{l,i}$の計算
1. 部分公開鍵、集合公開鍵の保存: 部分公開鍵$pk_{l,i}$と集合公開鍵$PK_l$を計算しチェーンのステートに保存

**2. しきい値署名フェーズ (epoch $e$の各slot $l$ )**

1. 部分署名の生成 (committee member, slot $l$ ): $\sigma_{l,i}$の計算
1. 部分署名の提出 (committee member, slot $l$ ): $\sigma_{l,i},PK_i$をブロードキャスト
1. 部分署名の検証 (proposer, slot $l+1$ ): 集まった各$\sigma_{l,i}$を$PK_{l,i}$を用いて$\mathrm{verify}_{\mathrm{th.share.sign}}$で検証
1. 集合署名の生成 (proposer, slot $l+1$ ): $\mathrm{combine}(\{\sigma_{l,i}\}_{i \in T_l})$を計算して集合署名値$\Sigma_l$を生成
1. 集合署名の検証 (proposer, slot $l+1$ ): 集合署名値$\Sigma_l$を$PK_l$を用いて$\mathrm{verify}_\mathrm{th.sign}$で検証
1. ミックス値の計算 (proposer, slot $l+1$ ): $m_l, r_{l+1}(=\Sigma_l)$を用いて$m_{l+1}$を計算
1. ブロック提案 (proposer, slot $l+1$ ): $r_{l+1}$をbodyに含めたbeacon blockを構築し、ブロードキャスト
1. ブロックの検証と投票 (attester, slot $l+1$ ): $r_{l+1}$が正当な値であるか$PK_l$を用いて$\mathrm{verify}_\mathrm{th.sign}$で検証

ここで強調したい点として、proposerが攻撃者だった場合、ブロック提案した場合とそうでない場合の期待収益の計算は少なくとも4の実行後に初めて可能となる点である。
現状のRANDAOの仕組みでは、1epoch以上前から事前に計算可能であるが、この方式だと自分にproposerの番が回ってきて、少しの処理を実行して初めてミックス値へと繋がる集合署名$\Sigma_l$が分かる。

### 3.3. 仕様

仕様を定義する。まだ確定できない箇所も多いため、ここでは根幹のアイデアである `randao_reveal` の変更方法部分に絞って記述する。

現在の仕様では、`epoch_signature`を`BeaconBlockBody`の`randao_reveal`として代入している。

block.body.randao_reveal = epoch_signature

この`epoch_signature`は以下の関数から取得できるものである。

def get_epoch_signature(state: BeaconState, block: BeaconBlock, privkey: int) -> BLSSignature:
    domain = get_domain(state, DOMAIN_RANDAO, compute_epoch_at_slot(block.slot))
    signing_root = compute_signing_root(compute_epoch_at_slot(block.slot), domain)
    return bls.Sign(privkey, signing_root)

我々の提案は以下の変更を加える。

`block.body.randao_reveal = threshold_signature`

この`threshold_signature`は以下の関数から取得できることとする。

def get_threshold_signature(
    state: BeaconState,
    block: BeaconBlock,
    inclusionLists: List[InclusionList, IL_COMMITTEE_SIZE],
) -> BLSThresholdSignature:
    domain = get_domain(state, DOMAIN_RANDAO, compute_epoch_at_slot(block.slot))
    signature_shares = []
    for il in inclusionLists:
        signature_share = il.randao_signature_share
        signing_root = compute_signing_root(block.slot, domain)
        pubkey_share = compute_pubkey_share(state, il)
        assert thBls.Verify(pubkey_share, signing_root, signature_share)
        signature_shares.append(signature_share.signature)
        pubkey_shares.append(pubkey_share)
    combined_signature = thBls.Combine(signature_shares)
    combined_pubkey = thBls.CombinePKs(signature_shares)
    combined_signing_root = compute_signing_root(block.slot, domain)
    assert thBls.CombinedVerify(combined_pubkey, combined_signing_root, combined_signature)
    return combined_signature

ここで、`signature_share`は`InclusionList`から取得している。つまり、FOCILで提案されている

class InclusionList(Container):
    slot: Slot
    validator_index: ValidatorIndex
    inclusion_list_committee_root: Root
    transactions: List[Transaction, MAX_TRANSACTIONS_PER_INCLUSION_LIST]

に一つフィールドを追加し、以下のように定義する。

class InclusionList(Container):
    slot: Slot
    validator_index: ValidatorIndex
    inclusion_list_committee_root: Root
    transactions: List[Transaction, MAX_TRANSACTIONS_PER_INCLUSION_LIST]
    # we added
    randao_signature_share: BLSSignatureShare

### 3.4. 考察

従来の RANDAO 方式では、攻撃者が epoch の末尾で連続するスロットを占有した場合、各スロットにおいて proposer 自身の秘密鍵を用いた署名を含むか棄却するかというバイナリな選択が可能である。そのため、攻撃者が取れる戦略パターン数はスロット数 $k$ に対して指数関数的に増加し、$2^k$通り存在する。これにより、攻撃者は$2^k$のパターンを計算し、自身に最も有利なミックス値を選択することが可能である。

一方、本提案の方式では、各スロット $l$ における乱数生成を単一の proposer に依存するのではなく、委員会によるしきい値署名で決定するため、攻撃者が単独でリビール値を事前に計算することができなくなる。委員会内で攻撃者が$2/3$より多くを占めない限り、攻撃者は将来のリビール値を計算できない。

この状況をモデル化すると、各スロットのリビール値の決定は、攻撃者にとって制御不可能な乱数として振る舞い、スロット $l$ におけるリビール値の取り得る状態数は攻撃者の意思とは無関係に一意に定まる。そのため、攻撃者がスロットを連続して支配したとしても、各スロットで得られるリビール値に基づき次スロットの予測可能性が決定される。その結果、各スロットにおいて1つのリビール値が既に確定している状況を踏まえると**攻撃者が計算できる状態数は、$2^k$ から $k + 1$ になる。**

具体的には、攻撃者が $k$ 個の連続したスロットを占有している状況を考える。現状は、攻撃者は $2^k$ を計算することができる。本提案では、各スロット $l$ における リビール値は委員会によるしきい値署名に基づいて順次確定されるため、攻撃者は未来のリビール値を事前に知ることができない。攻撃者が占有した最初のスロットでリビール値が決定すると、攻撃者はそのリビール値を踏まえて次のスロットにおける行動を選択することになるが、その時点では2番目以降のリビール値は未決定であり、依然として予測不能である。

このプロセスが各スロットに対して繰り返されるため、攻撃者が事前に完全に計算可能な戦略パターンは存在せず、各スロットごとにリビール値の確定を待って戦略を再計算する必要がある。すなわち、攻撃者が $k$ スロットを連続して占有した場合、取り得るリビール値のシナリオ数は最大でも各スロットにおけるリビール値の決定に伴い逐次的に分岐する形となる。具体的には、攻撃者の行動が及ばない最初のリビール値を起点として、各スロットでリビール値が1つずつ確定していくため、攻撃者の戦略が取り得る選択肢はスロットごとに1つずつしか追加されない。結果として、攻撃者が直面する予測シナリオの総数は指数関数的な増加ではなく、最大でも線形的な $k+1$ に制限される。

以上の理由から、我々の提案する新しいリビール値の生成メカニズムにより、攻撃者が将来のリビール値を事前に計算するという行動が根本的に阻害され、攻撃者にとっての経済合理的な選択は意図的な reorg やブロックの棄却を伴わない正直なブロック提案となる。

## 4. Unpredictable RANDAOのデザインスペース

上記の我々の提案では、委員会をFOCIL[^focil]の仕様におけるIL委員会、秘密分散スキームをFast Batched Asynchronous DKG[^fbadkg]、署名スキームをBLSしきい値署名[^blsthsig]とした。しかし、何を選定するかはデザインスペースとして検討の余地がある。

* committee
* committeeサイズは何か
* committeeをどの程度の頻度で更新するか
* 新しいRANDAO committeeを作るのか、あるいは既存のどのcommitteeを選択するか
* インセンティブをどう設計するか
* DKG
* どのDKGを使うか
* (ハードウェア依存を許容するか)
* しきい値署名
* どのしきい値署名を使うか
* しきい値を何に設定するか
* 誰が部分署名、部分公開鍵を集約するか
* RANDAO
* 更新頻度をEpochにするか、Slotにするか
* リビール値が含まれなかったブロックをミススロットとするかどうか

## 5. Discussions

### 5.1. 攻撃者の状態空間縮小と実際の経済インセンティブへの影響

本提案では、攻撃者が連続スロットを支配した際に将来のミックス値を予測可能な状態空間を指数関数的な$2^k$から線形的な$k+1$へと縮小することで、RANDAOへの攻撃動機を抑制することを狙っている。しかし、状態空間が減少したという理論的結果が、実際に攻撃者の経済的インセンティブをどの程度まで削減できるのかについては、本稿ではまだ定量的な分析を実施していない。

実際の攻撃者にとって重要なのは、状態空間の規模そのものよりも、攻撃によって得られる利得の期待値である。攻撃者の目的はあくまで自身が次エポックでの proposer 選定確率を高めて得られる追加的な利益であり、この利益が攻撃実施に伴うコストを超えなければ、攻撃のインセンティブは生じない。そのため、本提案の効果を明確に評価するためには、状態空間の縮小が具体的な経済的インセンティブに与える影響を定量的に明らかにすることが必要不可欠である。

具体的には、Alpturer & Weinberg (2024) や Nagy et al. (2025) のようにマルコフ決定過程（MDP）やエージェントベースのシミュレーションを活用し、以下の観点から評価を進める必要がある：

* 状態空間の縮小が攻撃者の最適な行動ポリシーに与える影響
* さまざまなステーク比率、委員会サイズ、しきい値のパラメータ設定における攻撃ROI（投資収益率）の評価

これらの分析を通じて初めて、本提案が現実的な経済的インセンティブを十分に低下させることが実証可能となり、提案の実効性を具体的に示すことができる。

### 5.2. DKGおよびしきい値署名の導入によるLiveness問題

本提案では、委員会によるDKGとしきい値署名という強力な仕組みを導入することで、予測可能性を大きく低減させることができることを示した。一方で、この強力さは新たな問題として、ブロックチェーンのLivenessを脅かす。

しきい値署名を実現するためには委員会内の一定割合の署名が短時間で揃う必要があるが、以下の課題が存在する:

* **ネットワークの遅延・障害耐性の問題**:
実際のインターネット環境では、ノード間の通信遅延や障害が常に発生し得る。委員会の一定数が署名を提出できないだけでブロック提案が停止するリスクがあり、チェーンの可用性が損なわれる恐れがある。
一つの対策として、リビール値を更新せずともブロック提案可能にすることが挙げられる。そうした場合、委員会の2/3より多くの署名が集まらなくともリビール値が存在しないブロックが構築され続け、トランザクションは含まれ続ける。その際は、1epoch以上リビールの更新がされない時には旧来のRANDAO方式を採用する、といったようなInactivity Leakに近い仕組みが必要となるだろう。
* **Share Withholding 攻撃の可能性**:
攻撃者が委員会の一部を占有した場合、故意に署名シェアを提出しないことでチェーンを一時的に停止させる可能性がある。これは、経済的なインセンティブが操作可能性の抑止につながるのと同様に、攻撃者が新たな DoS 攻撃の機会を得る可能性を示唆する。

以上を踏まえると、将来的な研究として、本提案の具体的な経済的削減効果を数値的に評価するとともに、DKG・しきい値署名が実際のネットワーク環境下でLivenessにどの程度影響を与えるかを定量化し、その上で適切なパラメータ設定や補助的なフェイルセーフ設計を検討することが不可欠である。

## 6. 結論

本研究は、RANDAO 乱数生成過程の予測性が攻撃インセンティブの源泉であるという視点から、(i) 攻撃者の状態空間を指数関数から線形へ縮減し、(ii) 攻撃コストを正直行動よりも不利に転化させる Unpredictable RANDAO を提示した。委員会による DKG としきい値署名を導入することで、攻撃者がたとえエポック末尾の複数スロットを連続支配しても、将来のリビール値を事前に列挙できず、ブロック棄却・reorg に伴う期待利得は急速に消失する。数理モデル上、連続 $k$ スロットを支配した場合の計算可能シナリオ数が $2^{k} \rightarrow k+1$ に抑制されるため、Selfish Mixing 単独で $25\%$ 以上、Forking 併用でも $8\%$ 以上必要だった余剰利得閾値が実質的に消滅することを示唆した。実際にどの程度削減するかはfuture workである。

設計空間としては、委員会サイズ・更新頻度、DKGプロトコル、しきい値設定など複数のパラメータ調整が残されており、アプリケーションの待ち時間要求やネットワーク同期特性とのトレードオフ分析が今後の課題である。しかしながら、本提案が予測可能性そのものを削ぎ落とすことで攻撃動機を制度的に弱体化し、PoS チェーンのランダム性基盤を抜本的に強化し得ることを示した点は、シンプルな Beacon Chain 設計における重要な一歩と言える。

## Reference

[^book]:[eth2book: Randomness](https://eth2book.info/capella/part2/building_blocks/randomness/#randomness)

[^book2]:[eth2book: RANDAO takeover](https://eth2book.info/capella/part2/building_blocks/randomness/#randao-takeover)

[^op]:[Optimal RANDAO Manipulation in Ethereum](https://ar5iv.labs.arxiv.org/html/2409.19883)

[^reorg]:[Forking the RANDAO: Manipulating Ethereum’s Distributed Randomness Beacon](https://eprint.iacr.org/2025/037.pdf)

[^focil]: [EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL)](https://eips.ethereum.org/EIPS/eip-7805)

[^fbadkg]: [Fast Batched Asynchronous Distributed Key Generation](https://dl.acm.org/doi/10.1007/978-3-031-58740-5_13)

[^blsthsig]: [Threshold Signatures, Multisignatures and Blind Signatures Based on the Gap-Diffie-Hellman-Group Signature Scheme](https://link.springer.com/chapter/10.1007/3-540-36288-6_3)

[^beamchain]: [Keynote: [title redacted] at Devcon SEA](https://www.youtube.com/watch?v=lRqnFrqpq4k)

[^falcon]: [Falcon: Fast-Fourier Lattice-based Compact Signatures over NTRU](https://research.ibm.com/publications/falcon-fast-fourier-lattice-based-compact-signatures-over-ntru)