📈 economics

The Cost of Secure Restaking vs. Proof-of-Stake

この論文は、セキュアなリステーキングとプルーフ・オブ・ステーク（PoS）プロトコルを比較し、リステーキングが PoS に比べて最大で検証者数の平方根に比例するほど大きな資本効率の向上（追加ステーキングの削減）をもたらすことを示しています。

原著者： Akaki Mamageishvili, Benny Sudakov

公開日 2026-03-16

📖 1 分で読めます☕ さくっと読める

原著者： Akaki Mamageishvili, Benny Sudakov

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

🏠 物語：防犯カメラと警備員の二つのやり方

想像してください。街中に**「防犯カメラ（サービス）」が 100 台あります。これらを盗難や破壊から守るために、「警備員（バリデーター）」**を雇います。

1. 従来のやり方：個別の契約（PoS）

昔ながらの方法です。

カメラ A は、警備員 A だけが守ります。
カメラ B は、警備員 B だけが守ります。
ルール： 各カメラを守るために、そのカメラの価値に十分な数の警備員を雇わなければなりません。
特徴： 安全ですが、警備員が「余っている時間」があっても、他のカメラの守りには使えません。無駄なコストが発生しやすいです。

2. 新しいやり方：リステーキング（Restaking）

最近流行っている方法です。

警備員 A は、カメラ A だけでなく、カメラ B、C、D も同時に守ります。
ルール： 1 人の警備員が複数のカメラを兼任します。
メリット： 警備員の「余っている時間」を有効活用できるので、全体として雇う警備員の数（必要な資金）を減らせる可能性があります。
リスク： 「もし警備員 A が裏切ったら、カメラ A〜D すべてが同時に壊される」という連鎖的なリスクが生まれます。

🔍 この論文が解明した 3 つの重要なポイント

この研究では、この「リステーキング」が本当に節約になるのか、そしてその節約幅はどれくらいなのかをシミュレーションしました。

① 「安全なリステーキング」は、実は個別契約に分解できる

まず、ある条件を満たす「安全なリステーキング」のネットワークがあったとします。

発見： そのネットワークをバラバラにして、それぞれのカメラに専用の警備員を割り当てても、**「追加で警備員を雇う必要がない（あるいはごくわずか）」**ことが証明されました。
意味： リステーキングが「魔法のように」劇的にコストを削ってくれるわけではありません。安全を確保するためには、結局、個別の契約（PoS）と同じくらいの「防犯の厚み」が必要になる場合が多いのです。

② 節約できる額は、実は「すごい」可能性がある

しかし、特定の条件下では、リステーキングは劇的な節約になります。

発見： 警備員の数（ $n$ ）が増えるにつれて、節約できる資金は**「警備員数の平方根（ $\sqrt{n}$ ）」**の割合で増えることがわかりました。
例え：
- 警備員が 100 人なら、節約効果は 10 倍。
- 警備員が 10,000 人なら、節約効果は 100 倍。
- 大規模なシステム（イーサリアムのような巨大なネットワーク）では、リステーキングによる資金効率の向上は非常に大きい可能性があります。

③ 逆のパターン：個別契約をまとめても「高コスト」になる

逆に、すでに安全な「個別契約（PoS）」を無理やりまとめて「リステーキング」にしようとした場合を考えます。

発見： すると、**「追加で警備員を大量に雇わなければならなくなる」**ことがわかりました。
理由： 警備員が複数のカメラを同時に守ると、1 人が裏切った時の被害が甚大になるため、それを防ぐために「過剰な防犯（オーバー・カテラライゼーション）」が必要になるからです。
結論： 個別の安全なシステムを無理やり統合すると、逆にコストが跳ね上がります。

💡 要するに、何が言いたいのか？

この論文は、リステーキングを「万能の魔法」として過信しないよう警告しつつ、その**「正しい使い所」**を数学的に示しています。

リステーキングは「無駄な警備員」を減らす天才：
大規模なネットワークでは、警備員（資金）を有効活用して、同じセキュリティレベルを維持しながら、必要な資金を大幅に減らせる可能性があります。
でも、無理やり統合すると「高くなる」：
すでに安全に運用されている個別のシステムを、無理やりリステーキングの枠組みに組み込むと、セキュリティを維持するために逆にコストがかさみます。
設計が重要：
どの警備員がどのカメラを守るか（グラフの構造）によって、節約効果は大きく変わります。単に「繋げればいい」という話ではなく、「どう繋ぐか」の設計図が最も重要です。

🎯 結論

リステーキングは、**「大規模なシステムでは、個別契約よりもはるかに効率的（お財布に優しい）」ですが、「小さくまとまったシステムや、設計が悪い場合は、逆に高コストになる」**という、両刃の剣であることがわかりました。

この研究は、ブロックチェーンの設計者が、**「いつリステーキングを採用すべきか」**を判断するための、確かな数学的な指針を提供しています。

論文「Secure Restaking と Proof-of-Stake のコスト比較」の技術的サマリー

この論文は、ブロックチェーンの暗号経済的安全性において、**リステーク（Restaking）と従来のProof-of-Stake（PoS）**プロトコルを比較し、両者の資本効率（Capital Efficiency）を定量的に評価する枠組みを提案しています。特に、安全なリステークグラフを、同等のセキュリティを持つ独立した PoS プロトコル群に変換するために必要な「追加ステーキング量（オーバーカレッジ）」を分析し、その節約効果（Restaking Savings）の理論的上限と下限を導出しています。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細をまとめます。

1. 問題定義と背景

背景

ブロックチェーンのセキュリティは、Proof-of-Work（PoW）から Proof-of-Stake（PoS）へ、さらに最近ではリステーク（EigenLayer など）へと進化しています。リステークでは、バリデーターがステーキングした資本を複数のサービス（プロジェクト）で再利用し、資本効率の向上を図ります。しかし、これによりプロトコル間の複雑な相互依存関係が生じ、セキュリティリスクが変化します。

核心的な問い

リステークは、独立した PoS プロトコルをそれぞれ実行する場合と比較して、総ステーキング量（Total Stake）を本当に削減できるのか？ もし削減できるなら、その節約幅（Restaking Savings）はどれほどか？
逆に、独立した PoS プロトコルをリステークグラフに集約した場合、セキュリティを維持するために必要な追加ステーキング量（PoS Savings）はどれほどか？

モデル

論文では、以下の要素を持つ二部グラフ $G = (S, \pi, \alpha, V, \sigma, E)$ としてリステークをモデル化します。

$S$ : サービス（プロジェクト）の集合。
$V$ : バリデーターの集合。
$\pi_s$ : サービス $s$ の価値。
$\alpha_s$ : サービス $s$ のセキュリティパラメータ（攻撃に必要となるステーキング比率の閾値）。
$\sigma_v$ : バリデーター $v$ のステーキング量。
$E$ : サービスとバリデーターを結ぶエッジ（ステーキング関係）。

安全性の定義: 攻撃者が得られる価値（攻撃対象サービスの価値の和）が、攻撃によって失われるステーキング量（スラッシング）を上回らない場合、そのグラフは安全であると定義されます。

2. 手法とアプローチ

著者は以下の 2 つの方向性から分析を行いました。

リステークから PoS への変換（Restaking Savings）:
既存の安全なリステークグラフにおいて、各バリデーターのステーキングを各サービスに分割し、独立した安全な PoS プロトコルを構築するために、追加で必要なステーキング量を求めます。
- 制約：バリデーターの初期ステーキング量は減らせず、増やすことのみ許可されます（オーバーカレッジ）。
- 目的：追加量の比率（Restaking Savings, $RS(G)$）を評価する。
PoS からリステークへの集約（PoS Savings）:
独立した安全な PoS プロトコル群を、単一のリステークグラフに集約した際、そのグラフを安全にするために追加で必要なステーキング量を求めます。
- 目的：集約による非効率性（PoS Savings, $PoSS(G)$）を評価する。

3. 主要な貢献と結果

3.1 リステークの節約効果 (Restaking Savings)

主要結果: 安全なリステークグラフを独立した PoS プロトコルに変換する際、必要な追加ステーキング量は、バリデーター数 $n$ の平方根に比例して増加する上限を持ちます。

上限 bound (Upper Bound):
- 任意の安全なリステークグラフ $G$ $G$ について、Restaking Savings $RS(G)$ は以下の値で抑えられます。
  - $RS(G) \leq 2\sqrt{n} - 1$ （ $n$ はバリデーター数）
  - または、セキュリティパラメータ $\alpha$ を用いて $RS(G) \leq \frac{1}{\alpha_2}$ （ $\alpha_2$ は 2 番目に小さいセキュリティパラメータ）
- この結果は、多くの実用的なケース（ $\alpha \in \{1/2, 1/3, 1/4\}$ ）において、追加コストは元のステーキング量の 2〜4 倍程度に収まることを示唆しています。
下限 bound (Lower Bound):
- 特定のグラフ構成において、 $RS(G) \in \Omega(\sqrt{n})$ となる例を構築しました。
- つまり、上限と下限が漸近的に一致し、 $RS(G) = \Theta(\sqrt{n})$ であることが証明されました。
- これは、大規模なシステムにおいてリステークが PoS に対して劇的な資本効率の向上（数百〜数千倍の節約）をもたらす可能性があることを意味します。
EigenLayer の十分条件との比較:
- 既存の EigenLayer が提唱する「十分条件（式 1）」を満たすグラフは、リステークによる節約効果がゼロ（$RS(G)=0$）であることが示されました。つまり、この条件は安全だが、資本効率の観点からは最適ではない（過剰なステーキングを要求する）ことが明らかになりました。

3.2 PoS の集約コスト (PoS Savings)

主要結果: 独立した PoS プロトコルをリステークグラフに集約する場合、セキュリティを維持するために必要な追加ステーキング量は、グラフの最大次数（サービスが接続されているバリデーター数）に依存します。

上下限 bound:
- PoS Savings $PoSS(G)$ について、以下の上下限が一致することが証明されました。
  - $PoSS(G) \leq \max_{s \in S} d_G(s) - 1$
  - 下限も同様に $m-1$ （ $m$ はサービス数、かつ $m=n$ の場合）で達成されます。
- これは、集約による非効率性が、サービスの接続数（次数）に比例して増大することを示しています。

3.3 結論的な洞察

リステーク vs 独立 PoS: どちらかが常に優れているわけではなく、グラフの構造（次数分布など）によって資本効率の優劣が決まります。
無限大の可能性: サービス数とバリデーター数が無限に増加する場合、リステークの節約効果（$RS$）も PoS の集約コスト（$PoSS$）も無限大に発散する可能性があります（Corollary 2, 3）。

4. 意義と示唆

理論的枠組みの確立:
リステークの安全性と資本効率を数学的に厳密に比較する初めての定式化を提供しました。これにより、直感的な「コスト対効果」の議論を超えた、定量的な評価が可能になります。
設計指針への貢献:
- 大規模システムでの利点: バリデーター数が非常に多い（例：Ethereum の数十万）場合、リステークは独立した PoS に比べて $\sqrt{n}$ のオーダーで資本を節約できるため、大規模なエコシステムにおいて極めて有効であることが示されました。
- パラメータの影響: セキュリティパラメータ $\alpha$ が $1/2, 1/3, 1/4$ などの典型的な値を持つ場合、追加コストは現実的な範囲（数倍）に収まることが示されました。
- EigenLayer の制限: 現在の EigenLayer の「単一スラッシング（Single Slashing）」制限は、事実上ステーキングの分割を強制し、リステークによる資本効率のメリットをゼロに帰着させることを指摘しました。真の資本効率を得るには、より柔軟なスラッシングモデルが必要である可能性があります。
今後の課題:
多項式時間でチェック可能な「十分条件」でありながら、かつ正の節約効果（$RS(G) > 0$）を持つリステークグラフを許容する条件の設計が、重要な未解決問題として残されています。

まとめ

この論文は、リステークが単なる「資本の再利用」ではなく、数学的に証明可能な劇的な資本効率の向上をもたらす可能性を示しました。特に、大規模なネットワークにおいて、リステークは独立した PoS プロトコル群を構築するよりも、はるかに少ない総ステーキング量で同等のセキュリティを達成できることを理論的に裏付けました。一方で、その逆（集約）には高いコストがかかる可能性も示しており、システム設計においてはグラフ構造の最適化が重要であることを強調しています。