# [EIP8062] 0x01バリデータのsweep引き出しに手数料を課してステーク統合を促す仕組みを理解しよう！

> EIP8062は、0x01クレデンシャルを持つバリデータの部分的な「sweep」引き出し（残高が32 ETHを超えた分の自動引き出し）に対して、引き出し額の0.05%の手数料を課す提案です。

- URL: https://cardene.dev/articles/61f15547b3c97f9642d7
- 公開日: 2026-03-09
- 更新日: 2026-03-09
- トピック: Blockchain
- タグ: ethereum, eip, smartcontract, ブロックチェーン

## はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

https://amzn.asia/d/gxvJ0Pw

今回は、`0x01`バリデータのsweep引き出し（partial withdrawal）に0.05%の手数料を課し、ステーク統合とバリデータ間の公平性を改善する仕組みを提案している**EIP8062**についてまとめていきます！

:::message
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

https://eips.ethereum.org/EIPS/eip-8062

https://ethereum-magicians.org/t/eip-8062-add-sweep-withdrawal-fee-for-0x01-validators/26003

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

**EIP8062**は、`0x01`クレデンシャルを持つバリデータの部分的な「**sweep**」引き出し（残高が32 ETHを超えた分の自動引き出し）に対して、引き出し額の0.05%の手数料を課す提案です。

Ethereumの高速ファイナリティ（Fast Finality）ロードマップは、ステーキングサービスプロバイダー（SSP）が`0x01`バリデータから`0x02`コンパウンディングバリデータに移行することに大きく依存しています。
しかし、`0x01`バリデータは32 ETHを超えた残高を無料で自動引き出しできるため、移行のインセンティブが不足しています。

この提案では、`process_withdrawals()`関数を最小限に変更し、新しい定数`WITHDRAWAL_FEE_FRACTION = 2000`を適用することで、sweep引き出しに手数料を課します。

:::message
`0x01`と`0x02`は、バリデータの**引き出しクレデンシャル**（Withdrawal Credential）のプレフィックスです。
`0x01`は従来型のバリデータで、残高が32 ETHを超えた分が自動的にEL（実行レイヤー）に引き出されます。
`0x02`はコンパウンディングバリデータで、超過分が自動引き出しされず残高に積み上がり、最大2048 ETHまで有効残高（Effective Balance）を持てます。
:::

## 動機

この提案が生まれた背景には以下のような課題がありました。

#### Fast Finalityとステーク統合

Ethereumの高速ファイナリティロードマップは、アクティブなバリデータセットを縮小することで実現されます。
この実現には2つの方向性が検討されています。

1つは**Orbit SSF**と呼ばれるアプローチで、アクティブセットが加重方式でローテーションし、大規模な統合バリデータは常にアクティブになり、小規模なバリデータはより低い頻度でアクティブになります。

もう1つは、固定数のバリデータシート（例えば上位8,192件）を設け、最大のバリデータだけがシートを獲得するアプローチです。

どちらのアプローチも、ステーク統合（Stake Consolidation）を実現し、十分なステーク重量と最適なパフォーマンスを達成する必要があります。
ステーク統合とは、SSPが多数の32 ETH `0x01`バリデータを運用する代わりに、少数の大規模な`0x02`コンパウンディングバリデータに統合することです。

![ステーク統合とFast Finalityへの道筋](/images/qiita-845126d8-5a9b-48c0-9afa-0d3bda02f0cc.webp)

:::message
**EIP7251**では、バリデータの有効残高の上限を2048 ETHに引き上げることで、ステーク統合の基盤を整えています。
:::

[\[EIP7251\] ステーク上限を2048 ETHの仕組みを理解しよう！](/articles/f501837f250747fad8b6)

#### `0x01`バリデータの優位性

`0x01`バリデータには、`0x02`バリデータと比較して以下の優位性があります。

| 項目 | `0x01`バリデータ | `0x02`バリデータ |
|------|-----------------|-----------------|
| sweep引き出し手数料 | 無料 | 該当なし（自動引き出しなし） |
| 平均遊休資産 | 約0.01175 ETH | 約0.75 ETH |
| 資本効率 | 高い | 低い（特に中程度の残高で顕著） |
| リソース消費 | CL・ELの両方で消費 | ELトリガーの引き出しはELで課金済み |

![0x01 vs 0x02 バリデータの引き出し比較](/images/qiita-49492a8d-4cad-4ca0-a5b3-c2dd6630483f.webp)

`0x01`バリデータは、32 ETHを超えた残高が自動的に無料で引き出されるため、遊休資産がほとんど発生しません。
一方、`0x02`バリデータは現在のヒステリシス設計により、有効残高より平均0.75 ETH多い残高を保持する必要があり、その分がステーキング報酬に寄与しません。

さらに、sweep引き出しはコンセンサスレイヤー（CL）と実行レイヤー（EL）の両方でリソースを消費しますが、その費用が課金されていません。
Ethereumのロードマップが`0x02`バリデータへの移行に依存している状況で、`0x01`バリデータに会計上の優位性を与え続けることは適切ではありません。

#### 手数料による解決

この提案では、`0x01`バリデータのsweep引き出しに0.05%の手数料を課すことで、上記の問題に対処します。

平均的なsweep引き出し額は約0.0235 ETHであるため、1回あたりの手数料は約11,750 Gweiとなります。
1つのバリデータの年間手数料は約0.00048 ETHで、現在のETH価格で約2ドルに相当します。
SSPが50,000の`0x01`バリデータ（ステーク全体の5%をわずかに下回る）を運用している場合、年間の手数料は約10万ドルとなり、統合への中程度のインセンティブとなります。

手数料は固定額ではなくパーセンテージで設定されています。
これは、`0x01`バリデータの数が統合によって大幅に減少した場合に備えるためです。
バリデータ数が減ると、sweepがより頻繁に実行され、手数料もより頻繁に徴収されます。
パーセンテージ方式であれば、各回の引き出し額が小さくなっても、年間のステーカーへの負担は一定に保たれます。

## 仕様

#### パラメータ

| 定数 | 値 |
|------|-----|
| `WITHDRAWAL_FEE_FRACTION` | `2000` |

手数料率は `1 / WITHDRAWAL_FEE_FRACTION = 1 / 2000 = 0.05%` です。

#### `process_withdrawals`関数の変更

`process_withdrawals()`関数内で、`0x01`バリデータのsweep引き出しに対して手数料を計算し、CL上でバーン（消滅）させます。
以下は変更後のコードです。

```python
def process_withdrawals(state: BeaconState, payload: ExecutionPayload) -> None:
    ...
    # In this existing for-loop, calculate a fee before decreasing the balance
    for w in expected_withdrawals:
        vi = w.validator_index
        fee = 0
        if not has_compounding_withdrawal_credential(state.validators[vi]) and w.amount != state.balances[vi]:
            fee = w.amount // WITHDRAWAL_FEE_FRACTION
        decrease_balance(state, vi, w.amount + fee)
```

この変更は既存のfor文内に最小限のロジックを追加するものです。
各引き出しについて、以下の条件を両方満たす場合に手数料が課されます。

- バリデータが`0x02`コンパウンディングクレデンシャルを持っていないこと（`0x01`であること）
- 引き出し額がバリデータの全残高と等しくないこと（完全な退出ではなく、部分的なsweep引き出しであること）

手数料は引き出し額を`WITHDRAWAL_FEE_FRACTION`で整数除算して計算され、引き出し額に上乗せしてバリデータの残高から差し引かれます。
手数料分はELに送金されずCL上で消滅するため、バリデータの残高は32 ETHをわずかに下回ります。

```mermaid
flowchart TD
    A["0x01 バリデータ残高<br>32.0235 ETH"] --> B["sweep引き出し額<br>amount = 0.0235 ETH"]
    B --> C{"0x01クレデンシャル?<br>かつ部分引き出し?"}
    C -->|Yes| D["手数料計算<br>fee = amount ÷ 2000<br>≈ 11,750 Gwei"]
    C -->|No| E["fee = 0"]
    D --> F["decrease_balance<br>amount + fee を残高から差引"]
    E --> F
    F --> G["amount → EL引き出しアドレスへ"]
    F --> H["fee → CLでバーン（消滅）"]

    style A fill:#a5d8ff,stroke:#1971c2
    style B fill:#ffd8a8,stroke:#e8590c
    style C fill:#eebefa,stroke:#9c36b5
    style D fill:#ffc9c9,stroke:#e03131
    style G fill:#b2f2bb,stroke:#2f9e44
    style H fill:#ffc9c9,stroke:#e03131
```

:::message
**EIP4895**では、ビーコンチェーンからEVMへのバリデータ出金の仕組みが定義されています。
この提案は、EIP4895で導入されたsweep引き出しの仕組みに手数料を追加するものです。
:::

[\[EIP4895\] ビーコンチェーンからEVMへのバリデーター出金サポートの提案を理解しよう！](/articles/f154a261447388d500f1)

## 補足

#### 手数料の水準

CL利回り3%の場合、1バリデータあたりの年間コストは `32 × 0.03 / 2000 = 0.00048 ETH` となります。
以下の表は、バリデータ数ごとのコストをまとめたものです。

| バリデータ数（ステーク比率） | 年間コスト（ETH） | 年間コスト（USD） |
|----------------------------|-------------------|------------------|
| 1（約0.0001%） | 0.00048 | 約2ドル |
| 100（約0.01%） | 0.048 | 約200ドル |
| 10,000（約1%） | 4.8 | 約20,000ドル |
| 50,000（約5%） | 24 | 約100,000ドル |
| 100,000（約10%） | 48 | 約200,000ドル |

ソロステーカーが1つの`0x01`バリデータを運用している場合、年間2ドルの手数料は移行を決断させるほどの金額ではありません。
一方、SSPが50,000の`0x01`バリデータ（ステーク全体の5%をわずかに下回る）を運用している場合、年間10万ドルのコストは中程度のインセンティブとなります。
完全競争の下では、SSPはこのコストを顧客に転嫁できないため、統合へのプレッシャーとなります。

移行コスト（スマートコントラクトの変更、完全な退出と再エントリーに伴う機会費用など）は、年間手数料よりも大きい可能性があります。
しかし、手数料が導入され、プロトコルが`0x01`バリデータの段階的廃止にコミットすれば、移行はいずれ実行する必要があります。
そのため、より正確な比較は、繰り返し発生する手数料と移行のための資金調達コストの比較となり、後者は当然低くなります。

#### Gas計算の根拠

この手数料はELでのワークロードを近似するように設計されています。
過去1年間の平均ベースフィー（4.53 gwei）に対して、sweep引き出しが消費するガスは約2,204 gasと推定されています。

| 項目 | ガス量 | 根拠 |
|------|--------|------|
| アカウントのコールドタッチ | 500 gas | コードを持たないアカウントへの初回アクセス（EIP2780準拠） |
| アカウントトライの書き込み | 1000 gas | アカウントリーフへの1回の書き込み（EIP2780準拠） |
| 引き出しデータのcalldata | 704 gas | EIP4895の引き出しデータ44バイト（index 8 + validator_index 8 + address 20 + amount 8）× 16 gas/バイト |
| 合計 | 2,204 gas | |

推定手数料は `2,204 × 4.53 = 9,984 Gwei` となりますが、直近のベースフィーはこれより低い水準で推移しています。

なお、この計算では`0x01`バリデータがCLで消費するsweepのワークロードは考慮されていません。
`0x02`バリデータのEIP7002（ELトリガーの部分引き出し）についても、CLワークロードは課金されていませんが、ELでの引き出しトリガーに対してより多くの課金が行われています。

なお、2048 ETHのバリデータはsweep引き出し手数料が免除されます。
ステーク統合を阻害しないためと、2048 ETHがプロトコルが現在処理するよう設計された最大ステーク量であることが理由として挙げられています。

#### 資本効率と機会費用

sweep引き出しの無料化に加えて、`0x01`バリデータのもう1つの優位性は資本効率です。

`0x02`コンパウンディングバリデータは、現在のヒステリシス設計により、有効残高（EB）に対して平均0.75 ETHの遊休資産を保持します。
これは、残高が徐々に増加するバリデータがEBより0.25〜1.25 ETH多い残高を保持するためです。

:::message
**ヒステリシス（Hysteresis）** とは、有効残高の更新に「遊び」を設けることで、残高の小さな変動のたびにEBが頻繁に変わることを防ぐ仕組みです。
例えば、EBを1 ETH増やすには残高がEB+1.25 ETHに達する必要があり、EBを1 ETH減らすには残高がEB-0.25 ETHを下回る必要があります（EIP7251で規定）。
この仕組みにより、`0x02`バリデータは実際のEBより平均0.75 ETH多い残高を常に保持することになり、その分がステーキング報酬に寄与しない「遊休資産」となります。
:::

![ヒステリシスメカニズムと遊休資産ゾーン](/images/qiita-913b52fc-cbe4-48f9-860b-1b430a0cb349.webp)

一方、`0x01`バリデータの遊休資産は平均で `0.0235 / 2 = 0.01175 ETH` に過ぎず、特に中程度の残高を持つ`0x02`バリデータと比較して資本効率が大幅に高くなっています。

以下の図は、ニュートラルなEB設計（残高の増加に伴い平均してEBと等しくなる）をベースラインとした時の、各バリデータ設定のステーキング利回りの相対的な変化を示しています。

![Figure 1 バリデータ設定ごとの資本効率の違いによるステーキング利回りの相対変化](https://raw.githubusercontent.com/ethereum/EIPs/master/assets/eip-8062/1.png)

https://eips.ethereum.org/EIPS/eip-8062

図の青い線は`0x02`コンパウンディングバリデータの利回りで、平均0.75 ETH低いEBにより利回りが低下しています。
緑の丸は32 ETHおよび2048 ETHのスキミングバリデータ（`0x01`）の利回りを示しています。
オレンジの線はこの提案で課される手数料（0.05%）による影響です。

この手数料は、バリデータ残高が約1,000 ETH未満の`0x02`バリデータが受けるYield Drag（利回り低下）を完全には相殺しません。
EIP8068はニュートラルなEB設計（ヒステリシス閾値を+0.5で引き上げることで、残高の増加に伴い平均してEBと等しくなる設計）によりこの資本効率の差を解消します。
この設計が導入されれば、Figure 1の青い線がベースライン（黒い線）に位置するようになります。

ただし、EIP8068がこの提案と同じハードフォークに含まれない場合は、手数料を引き上げて補償する代替仕様も検討されています。
なお、手数料の引き上げだけでは解決できない別の問題もあります。
`0x02`バリデータはヒステリシスを活用して、33 ETHのEBに達した後に部分引き出しを行うことで、32.75 ETHの残高を保持しながら33 ETHのEBを維持できてしまいます。
この問題についてはEIP8068の代替仕様で個別に対処できるとされています。

#### 代替仕様

EIP8068が同じハードフォークに含まれない場合、`0x02`バリデータの低い資本効率を補償するために手数料を引き上げることが検討されています。

以下の図は、3つの代替手数料率を赤い線で示しています。
白い四角は、提案された手数料の下で`0x01`バリデータと`0x02`バリデータの資本効率が等しくなるバリデータ残高を示しています。

![Figure 2 代替手数料率の比較](https://raw.githubusercontent.com/ethereum/EIPs/master/assets/eip-8062/2.png)

https://eips.ethereum.org/EIPS/eip-8062

以下の表は、各代替手数料率の特徴をまとめたものです。

| 手数料率 | `WITHDRAWAL_FEE_FRACTION` | 特徴 |
|---------|---------------------------|------|
| 0.05%（提案値） | 2000 | ELワークロードを近似した最小限の手数料 |
| 0.25% | 400 | より緩やかな補償 |
| 0.5% | 200 | 32 ETHの`0x01`バリデータが約128 ETHの`0x02`バリデータと同等の資本効率になる |
| 1% | 100 | 複数のバリデータを運用する場合、`0x02`への統合が常に中立以上になる |

0.5%の手数料（`WITHDRAWAL_FEE_FRACTION = 200`）を採用した場合のコストは以下です。

| バリデータ数（ステーク比率） | 年間コスト（ETH） | 年間コスト（USD） |
|----------------------------|-------------------|------------------|
| 1（約0.0001%） | 0.0048 | 約20ドル |
| 100（約0.01%） | 0.48 | 約2,000ドル |
| 10,000（約1%） | 48 | 約200,000ドル |
| 50,000（約5%） | 240 | 約1,000,000ドル |
| 100,000（約10%） | 480 | 約2,000,000ドル |

0.5%の手数料の場合、バリデータ1つあたり年間追加20ドルの負担となります。
SSPがステーク全体の5%を運用している場合、年間100万ドルの損失が発生し、統合へのより強いインセンティブとなります。

## セキュリティ

著者らの知る限り、この提案に伴うセキュリティリスクは確認されていません。

手数料はCL上でバーン（消滅）されるため、EL上での追加的な攻撃面は発生しません。
また、既存の`process_withdrawals()`関数への最小限の変更であり、新しいロジックの複雑さも限定的です。

## 引用

https://eips.ethereum.org/EIPS/eip-8062

https://ethereum-magicians.org/t/eip-8062-add-sweep-withdrawal-fee-for-0x01-validators/26003

https://eips.ethereum.org/EIPS/eip-4895

https://eips.ethereum.org/EIPS/eip-7251

## 最後に

今回は「EIP8062による0x01バリデータのsweep引き出し手数料の仕組み」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4