Proof of WorkとProof of Stakeをざっくり整理する

Posted at 2026-07-06

概要

みんなが見る会計ノートや議事録を共同で管理している場面を想像してみてください。

誰かが新しく支出を追加したり、打ち合わせの決定事項を書き込んだりするとき、その記録はあとから全員で確認できる必要があります。
「この支出は本当にあったのか」「この決定はいつ追加されたのか」「誰かがあとから都合よく書き換えていないか」を確認できないと、記録そのものを信じにくくなってしまいます。

もし少人数なら、代表者を1人決めて、その人に記録を任せればよいかもしれません。
しかし、参加者が世界中にいて、お互いの顔も知らず、特定の管理者だけを信じたくない場合はどうでしょうか。

このとき問題になるのが、次のような問いです。

誰が次の記録を書いてよいのか
同時に別々の記録が出てきたら、どちらを採用するのか
悪意ある人が勝手な記録を追加しようとしたら、どう防ぐのか
不正をする人に、どのようなコストを負わせるのか

ブロックチェーンでも、これに近い問題が出てきます。

BitcoinやEthereumのようなパブリックブロックチェーンでは、特定の管理者がすべての記録を一方的に決めるのではなく、多くの参加者が取引やブロックを検証します。
NISTは、ブロックチェーンを、中央の保管場所や中央権限なしに分散的に実装される、改ざんを検知しやすく耐性を持つデジタル台帳として説明しています。

参考: NISTIR 8202: Blockchain Technology Overview

ただし、分散しているだけでは十分ではありません。

多くの参加者が同じ記録を共有するには、「誰が次のブロックを作るのか」「複数の候補が出てきたとき、どの履歴を正しいものとして扱うのか」といったルールが必要です。
この合意形成に関わる代表的な考え方が、Proof of Work と Proof of Stake です。

Proof of Workは、ざっくり言えば 計算作業にコストを払わせることで、不正な履歴を作りにくくする考え方 です。
Bitcoinのホワイトペーパーでは、P2Pネットワーク上で二重支払い問題を解決するために、ハッシュベースのProof of Workを使い、過去の記録を変えるにはProof of Workをやり直す必要があると説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

一方、Proof of Stakeは、ざっくり言えば 資産を預けた参加者に責任を持たせ、正しく振る舞う動機を作る考え方 です。
Ethereum公式ドキュメントでは、PoSのEthereumではバリデータが32 ETHをdeposit contractへ預け、ブロックの検証や提案に参加すると説明されています。

参考: Ethereum Documentation: Proof-of-stake

ここで大切なのは、PoWとPoSを「どちらが絶対に優れているか」で見るのではなく、不正をしにくくするために、何をコストとして使っているのか で見ることです。

方式	身近なたとえ	コストとして使うもの	ざっくりした考え方
Proof of Work	何度もくじを引いて、条件に合う当たりを探す	計算資源、電力、設備、時間	たくさん作業したことを根拠に、ブロック作成へ参加する
Proof of Stake	保証金を預けて、共同管理の当番に参加する	預けた資産、報酬、ペナルティ	資産を預けた責任を根拠に、ブロック提案や検証へ参加する

この記事では、PoWとPoSをいきなり難しい数式や仕様から説明するのではなく、まずは「みんなで共有する記録をどう信じるか」という身近な問題から整理します。

そのうえで、BitcoinではPoWがどのように使われているのか、現在のEthereumではPoSがどのように使われているのか、そして情報セキュリティの観点でどのような強みと注意点があるのかを見ていきます。

💡 豆知識
Proof of Workの work は、単なる「作業」というより、ネットワークに対して「これだけ計算を試しました」と示すための作業です。
たとえるなら、答えを見つけるまでは大変だけれど、答えが条件に合っているかはすぐ確認できるパズルに近いです。
この「見つけるのは大変、確認するのは比較的簡単」という非対称性が、PoWを理解する入口になります。

この記事の立ち位置

本記事は、以前作成した 「身近な記録から理解するブロックチェーンの全体像」 の派生記事です。

派生元の記事では、ブロックチェーンを「複数の参加者が同じ記録を共有し、その記録があとからこっそり書き換えられていないかを確認しやすくする仕組み」として整理しました。
そこでは、ブロック、チェーン、台帳、分散、ハッシュ、デジタル署名、コンセンサス、スマートコントラクトなどを広く扱いました。

本記事では、その中でも特に コンセンサス と呼ばれる領域に近い、Proof of WorkとProof of Stakeに絞って深掘りします。

ただし、厳密に言うと、PoWやPoSだけでブロックチェーンの合意形成がすべて完結するわけではありません。
Ethereum公式ドキュメントでは、PoWとPoSは簡単のためにコンセンサスプロトコルと呼ばれることがあるものの、実際にはSybil攻撃への耐性やブロック作成者を選ぶ仕組みであり、複数のブロック候補があるときにどれを選ぶかというchain selection、つまりfork choiceも重要だと説明されています。

参考: Ethereum Documentation: Consensus mechanisms

この点は少し難しく感じるかもしれません。
まずは、次のように分けると読みやすくなります。

観点	ざっくりした問い	本記事での扱い
ブロック作成者の選び方	誰が次のブロックを書くのか	PoWとPoSの中心として扱う
不正を防ぐコスト	不正すると何を失うのか	計算資源と預けた資産の違いとして扱う
フォーク選択	複数の履歴が出たとき、どれを正しいと見るのか	初学者向けに概要だけ扱う
報酬とペナルティ	正しく参加すると何を得て、不正すると何を失うのか	PoW/PoSのインセンティブとして扱う

派生元記事との関係を整理すると、次のようになります。

派生元記事	本記事
ブロックチェーン全体の地図を整理する	PoWとPoSに絞って整理する
身近な記録からブロックチェーンを説明する	共同編集メモや会計ノートから「誰が次に書くか」を説明する
ハッシュ、署名、分散、コンセンサスなどを広く扱う	マイナー、バリデータ、ステーキング、スラッシングなどを扱う
情報セキュリティ上の強みと限界を広く整理する	51%攻撃、集中、フォーク、ファイナリティなどの注意点を整理する

関連記事: 身近な記録から理解するブロックチェーンの全体像

Qiitaに投稿する際は、上記の ここに派生元記事のURLを挿入 の部分を、実際に投稿済みの派生元記事URLへ置き換えてください。

この記事で分かること

この記事で分かることは、次のとおりです。

PoWとPoSがなぜ必要になるのか
コンセンサス、Sybil耐性、フォーク選択のざっくりした関係
Proof of Workの基本的な考え方
BitcoinにおけるPoWの位置づけ
Proof of Stakeの基本的な考え方
現在のEthereumにおけるPoSの位置づけ
マイナーとバリデータの違い
計算資源をコストにする設計と、預けた資産をコストにする設計の違い
51%攻撃、スラッシング、集中リスクなどの注意点
PoWとPoSについてよくある誤解

特にこの記事では、次の2つを混同しないことを重視します。

混同しやすいこと	分けて考えたいこと
PoW/PoS = コンセンサスのすべて	PoW/PoSは、主にSybil耐性やブロック作成者選択に関わる要素
PoWは古くてPoSは新しいので、PoSが常に上位互換	それぞれコストの置き方、リスク、実装の複雑さが異なる
PoWは単なる無駄な計算	不正な履歴を作るコストを高めるための計算作業
PoSは電力消費が少ないので完全に安全	ステーク集中、運用、実装、ペナルティ設計など別の注意点がある
51%攻撃はPoWだけの話	PoSでも、総ステークに対する支配割合が重要な論点になる

たとえば、PoWでは「たくさん計算できる人」がブロック作成に参加しやすくなります。
一方で、PoSでは「資産を預けて責任を持つ人」がブロック提案や検証に参加します。

どちらも、ただ参加者を選んでいるだけではありません。
不正をしようとすると、計算資源や電力、設備投資、預けた資産、報酬、信用などを失う可能性があります。

このように、PoWとPoSは 不正を安く済ませないための設計 として見ると理解しやすくなります。

対象読者

この記事は、次のような人を想定しています。

ブロックチェーンを学び始めた人
BitcoinやEthereumの仕組みに興味がある人
PoWとPoSの違いをざっくり整理したい人
「マイナー」「バリデータ」「ステーキング」などの用語が気になっている人
コンセンサスやフォークという言葉で一度つまずいたことがある人
情報セキュリティの観点からブロックチェーンを理解したい人
いきなり論文や仕様書を読む前に、まず全体像をつかみたい人

前提知識としては、次の程度を想定しています。

前提知識	必要度
ブロックチェーンが取引や状態を記録する仕組みであること	あると読みやすい
ハッシュという言葉を聞いたことがあること	あると読みやすい
BitcoinやEthereumの名前を聞いたことがあること	あると読みやすい
暗号技術の数学的な理解	なくてもよい
分散システムや合意アルゴリズムの専門知識	なくてもよい
実際のマイニングやステーキング経験	なくてもよい
投資や暗号資産取引の経験	なくてもよい

途中で、nonce、difficulty、miner、validator、staking、slashing、fork choice、finalityといった言葉が出てきます。

ただし、最初から全部を知っている必要はありません。
それぞれの用語は、できるだけ身近な例と一緒に説明します。

たとえば、nonceは「条件に合うハッシュを探すために何度も変える数字」、difficultyは「当たりを出す難しさ」、validatorは「保証金を預けて記録の確認に参加する人」のように、まずはざっくりしたイメージから入ります。

本記事で扱わないこと

本記事は、Proof of WorkとProof of Stakeを初学者向けに整理する記事です。

そのため、以下は深く扱いません。

PoWやPoSの厳密な数学的証明
Bitcoin CoreやEthereumクライアントの実装詳細
EthereumのGasper、Casper FFG、LMD-GHOSTの詳細な仕様
各ブロックチェーンの網羅的な比較
投資判断、価格予測、マイニング収益、ステーキング利回りの推奨
マイニング機器の選び方
ステーキングサービスや取引所サービスの選び方
特定チェーンの政治的・思想的な優劣評価
実際の資産を使ったマイニング、ステーキング、バリデータ運用手順
秘密鍵や資産管理の実務的な手順

PoWやPoSは、技術だけでなく、経済性、運用、コミュニティ、規制、エネルギー、分散性などとも関わるテーマです。
そのため、深掘りしようとすると非常に広い話になります。

本記事では、まず初学者が全体像をつかめるように、次の観点に絞って扱います。

扱う観点	扱わない観点
PoWとPoSの基本的な考え方	厳密な数理モデルや形式的証明
BitcoinとEthereumを代表例にした説明	すべてのチェーンの詳細比較
不正をしにくくするためのコスト設計	投資判断や収益性の評価
マイナーとバリデータの役割	実運用の設定手順やサービス選定
51%攻撃、スラッシング、集中などの注意点	特定プロジェクトの優劣の断定

また、Ethereumは2022年9月15日のThe Mergeによって、Proof of WorkからProof of Stakeへ移行しました。
Ethereum公式は、The MergeがPoSへの移行を完了し、PoWを正式に廃止し、エネルギー消費を約99.95%削減したと説明しています。

参考: Ethereum Roadmap: The Merge

ただし、これはEthereumに関する説明です。
この事実だけをもとに、すべてのブロックチェーンについて「PoSが常にPoWよりよい」と一般化することは避けます。

コードを試す場合の前提

本記事では、後半の章で、PoWやPoSの考え方をイメージするためにPythonの小さなコード例を使う可能性があります。

ただし、コードはすべて 考え方を理解するための学習用 です。
実際のマイニング、バリデータ運用、ステーキング、暗号資産の送金、秘密鍵管理へそのまま使うことは想定していません。

項目	内容
目的	PoW/PoSの考え方を理解するための学習用
想定環境	Python 3.x系
主に使う標準ライブラリ	`hashlib`、`random`、`dataclasses` など
外部ライブラリ	原則なし。必要になった場合はその章で説明する
注意点	実際のマイニング、ステーキング、資産運用、秘密鍵管理へ流用しない

たとえば、次のような概念コードを扱う可能性があります。

PoWでnonceを変えながら条件に合うハッシュを探す簡易モデル
difficultyを変えると試行回数が変わるイメージ
PoSでステーク量に応じてブロック提案者を選ぶ簡易モデル
不正時にペナルティがあると、なぜ行動のインセンティブが変わるのかを示す小さな例

ここで扱うコードは、実際のBitcoinやEthereumの仕様を再現するものではありません。
あくまで、「なぜPoWでは計算作業が必要なのか」「なぜPoSでは預けた資産が重要になるのか」を、手元で動かしながらイメージするためのものです。

この区別を忘れないようにしながら、必要な章で小さなコード例を使っていきます。

全体の流れ

この記事では、次の順番で話を進めます。

最初は、会計ノートや議事録のような身近な共有記録から入ります。
そこで、複数人で同じ記録を扱うときには、誰が次の記録を書いてよいのか、そして 記録が食い違ったときにどちらを正しい履歴とみなすのか が問題になることを確認します。

次に、コンセンサスという言葉を整理します。
ここでは、PoWやPoSだけを「合意形成のすべて」として見るのではなく、Sybil耐性、ブロック作成者の選択、フォーク選択などの要素に分けて考えます。

そのうえで、Proof of Workを見ていきます。
PoWでは、条件に合うハッシュを見つけるために、nonceなどを変えながら何度も計算を試します。
Bitcoinのホワイトペーパーでは、ハッシュが一定数の0ビットで始まるような値を探し、その作業量は必要な0ビット数に対して指数的に増える一方、検証は1回のハッシュ計算でできると説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

次に、Proof of Stakeを見ていきます。
PoSでは、計算作業ではなく、預けた資産と報酬・ペナルティの仕組みによって、正しく振る舞うインセンティブを作ります。
Ethereum公式のステーキング解説では、32 ETHを預けることでバリデータを有効化し、データの保存、取引処理、新しいブロックの追加に責任を持つと説明されています。

参考: Ethereum Staking

後半では、PoWとPoSを表で比較しながら、情報セキュリティの観点での注意点を整理します。

たとえば、PoWでは計算能力の集中や電力消費、PoSではステーク集中やスラッシング、クライアント実装の偏りなどが論点になります。
また、PoWとPoSのどちらでも、攻撃コスト、インセンティブ、ネットワーク参加者の分散性を考えることが大切です。

最後に、よくある誤解と最近の動向を整理し、記事全体をまとめます。

この記事を通じて、最終的には次のような見方ができるようになることを目指します。

Proof of WorkとProof of Stakeは、どちらも「分散した参加者が同じ記録を信じるために、不正をしようとする人へコストを負わせる仕組み」です。
ただし、PoWは主に計算作業をコストにし、PoSは主に預けた資産をコストにします。
どちらが常に正解というより、それぞれの設計思想、強み、注意点を分けて理解することが大切です。

次の章では、まずPoWやPoSの前に、みんなで共有する記録では「誰が書くか」が問題になる というところから整理します。
ここを押さえておくと、PoWやPoSが単なる専門用語ではなく、「分散した記録をどう信じるか」という問題への答えとして見えやすくなります。

1. みんなで共有する記録では「誰が書くか」が問題になる

この章では、PoWやPoSの詳しい仕組みに入る前に、そもそも「みんなで同じ記録を共有する」ときに何が問題になるのかを整理します。
ポイントは、記録そのものよりも、誰が次の記録を書いてよいのか、そして 食い違う記録が出たときにどちらを採用するのか です。

概要では、会計ノートや議事録のような身近な共有記録から、PoWとPoSの入口を見ました。

ここからは、もう少し丁寧に「共有する記録では何が困るのか」を考えていきます。
まだこの章では、Proof of WorkやProof of Stakeの細かいアルゴリズムには入りません。

まずは、研究室やサークルで使う会計ノートを例にします。

たとえば、みんなで使う共有ノートに、次のような支出を記録しているとします。

日付	内容	金額	記録した人
2026-07-01	会場費	5,000円	Aさん
2026-07-02	飲み物代	1,200円	Bさん
2026-07-03	備品代	2,000円	Cさん

このような記録は、1人だけが管理しているなら比較的シンプルです。
会計係が1人いて、その人がすべての記録を確認し、必要に応じて修正すればよいからです。

しかし、みんながそれぞれ同じノートのコピーを持っていて、別々のタイミングで記録を追加できるとしたらどうでしょうか。

たとえば、Aさんのノートでは「飲み物代 1,200円」と書かれているのに、Bさんのノートでは「飲み物代 12,000円」と書かれているかもしれません。
あるいは、Cさんが「備品代」を追加した直後に、Dさんも別の「備品代」を追加して、どちらが先だったのか分からなくなるかもしれません。

このように、共有記録では次のような問題が出てきます。

問題	身近な例	ブロックチェーンでのイメージ
誰が記録を書くのか	会計係、議事録係、当番を決める	誰が次のブロックを作るのか
記録が正しいか	金額や内容に間違いがないか確認する	取引やブロックがルールに合っているか検証する
記録が食い違ったらどうするか	AさんのノートとBさんのノートで内容が違う	複数のブロック候補やチェーン分岐が出る
不正をどう防ぐか	勝手に金額を書き換えられないようにする	不正な取引や履歴改ざんを難しくする
不正した人に何を失わせるか	信頼、担当権限、保証金などを失う	計算コスト、報酬、ステークした資産などを失う

ブロックチェーンのコンセンサスを理解するときも、最初はこのくらい身近な問題から考えると分かりやすいです。

パブリックブロックチェーンでは、世界中の参加者が同じ記録を共有します。
参加者同士が全員知り合いとは限らず、誰か1人の管理者を無条件に信じるわけでもありません。

そのため、単に「記録を保存する」だけではなく、記録を追加する順番や、正しい履歴の選び方 が重要になります。

NISTIR 8202では、ブロックチェーンを、中央の保管場所や中央権限なしに分散的に実装される台帳として説明し、参加者が取引の妥当性にどう合意するか、Proof of WorkやProof of Stakeを含むコンセンサスモデルを整理しています。

参考: NISTIR 8202: Blockchain Technology Overview

1.1 まずは「全員が同じ記録を持つ」難しさを考える

少人数のグループなら、記録の管理はそこまで難しくありません。

たとえば、サークルの会計係が1人いて、その人が会計ノートを管理するなら、次のような流れで済みます。

1. 支出が発生する
2. 会計係にレシートを渡す
3. 会計係がノートに記録する
4. 必要なら、あとで全員に共有する

この場合、中心にいるのは会計係です。
会計係を信頼できるなら、仕組みはとても分かりやすいです。

しかし、ブロックチェーンが考えている世界では、少し条件が変わります。

1. 参加者がたくさんいる
2. 参加者同士が互いに知らない場合がある
3. 全員が同じ記録を見たい
4. でも、特定の管理者だけに頼りたくない
5. 悪意ある参加者が混ざる可能性もある

このような条件では、「会計係を1人決めればよい」とは言いにくくなります。

もちろん、中央管理者がいる仕組みが悪いわけではありません。
銀行、学校、会社、クラウドサービスなど、多くの仕組みでは中央管理者がいることで効率的に運用できます。

一方で、ブロックチェーンは、中央の管理者にすべてを任せるのではなく、複数の参加者が同じ履歴を検証しながら共有する方向を目指します。

そのため、次の問いが重要になります。

管理者が1人いない状態で、誰が次の記録を書いてよいのか。
そして、その記録を他の参加者はどうやって受け入れるのか。

この問いが、PoWやPoSの話につながっていきます。

1.2 記録が同時に追加されると、履歴が分かれることがある

もう少し具体的に考えてみます。

Aさん、Bさん、Cさんが、それぞれ同じ会計ノートのコピーを持っているとします。
最初の状態は全員同じです。

共通の記録:
1. 会場費 5,000円
2. 飲み物代 1,200円

ここで、Cさんが「備品代 2,000円」を追加しました。
一方で、ほぼ同じタイミングでDさんも「印刷代 800円」を追加したとします。

すると、一時的に次のような2つの履歴が生まれる可能性があります。

履歴A	履歴B
1. 会場費 5,000円	1. 会場費 5,000円
2. 飲み物代 1,200円	2. 飲み物代 1,200円
3. 備品代 2,000円	3. 印刷代 800円

どちらも、途中までは同じ履歴です。
しかし、3番目の記録だけが違っています。

このような状態になると、次の問題が出てきます。

履歴Aを正しいとするのか
履歴Bを正しいとするのか
両方を取り込めるのか
どちらかを一時的に保留するのか
悪意ある人が、わざと別の履歴を広めていないか

ブロックチェーンでも、ネットワークの遅延や同時提案によって、複数のブロック候補が一時的に存在することがあります。
これを広い意味で フォーク と呼ぶことがあります。

フォークという言葉は少し難しく聞こえますが、最初は「途中まで同じだった履歴が、ある地点から分かれること」と考えると分かりやすいです。

ここで大切なのは、分岐が起きること自体を完全にゼロにするのではなく、分岐が起きたときに、どの履歴を採用するかを決めるルールが必要になる という点です。

Ethereum公式ドキュメントでも、PoWやPoSはよくコンセンサス方式と呼ばれる一方で、実際にはSybil耐性やブロック作成者選択に関わる要素であり、複数のブロック候補がある場合にどれを選ぶかというchain selection、つまりfork choiceも重要だと説明されています。

参考: Ethereum Documentation: Consensus mechanisms

1.3 「誰でも書ける」だけでは不正に弱い

ここで、さらに厄介な問題があります。

もし「誰でも自由に記録を追加してよい」というルールだけにすると、悪意ある人が勝手な記録を追加できてしまいます。

たとえば、会計ノートに次のような記録が追加されたらどうでしょうか。

4. Aさんに返金 100,000円

本当に返金が必要ならよいですが、勝手に追加された不正な記録かもしれません。

そのため、共有記録では次の2つを分けて考える必要があります。

観点	説明	ブロックチェーンでのイメージ
記録の妥当性	その記録はルールに合っているか	取引の署名、残高、形式などを検証する
記録を追加する権利	誰が次の記録を追加できるか	マイナーやバリデータがブロックを提案する

記録の内容が正しいかを確認するだけでなく、誰がその記録を追加できるのかも決める必要があります。

このとき、単純に「早い者勝ち」にすると、ネットワークの近さや通信環境で有利不利が出やすくなります。
また、「アカウントをたくさん作った人が有利」というルールにすると、悪意ある人が大量の偽アカウントを作って影響力を増やせてしまいます。

このように、参加者を数だけで見ると、Sybil攻撃 が問題になります。

Sybil攻撃とは、1人の攻撃者がたくさんの偽の参加者を作り、まるで多数派であるかのように見せる攻撃です。
身近な例で言えば、1人がアンケートに何十回も回答して、投票結果をゆがめるようなものです。

そこで、PoWやPoSでは、単に「参加者の数」ではなく、何らかのコストを使って影響力を持たせます。

方式	偽参加者を増やすだけでは有利になりにくい理由
Proof of Work	たくさんの計算を行うには、計算資源や電力が必要になる
Proof of Stake	影響力を持つには、資産を預ける必要がある

この時点では、PoWとPoSの細かい違いまで理解できていなくても大丈夫です。
まずは、どちらも「安く大量に参加者を増やして不正する」ことを難しくするために、コストを使う仕組みだと押さえておきます。

💡 豆知識
Sybil攻撃の「Sybil」は、複数の人格を持つ人物を扱った書籍名に由来するとされています。
ブロックチェーンの文脈では、1人の攻撃者が大量のノードやアカウントを作り、ネットワーク上で多数派のように振る舞う問題を指します。
PoWやPoSは、この「数だけ増やせば勝てる」状態を避けるための仕組みとして見ることもできます。

1.4 小さなコードで見る：記録が食い違うと何が困るのか

ここで、共有記録が食い違う様子を、簡単なPythonコードで見てみます。

次のコードは、実際のブロックチェーンを再現するものではありません。
会計ノートのような共有記録を使って、「同じ履歴から別々の記録が追加されると、履歴が分かれる」という感覚をつかむための学習用コードです。

# これは共有記録の分岐を理解するための学習用コードです。
# 実際のBitcoinやEthereumの仕組みを再現するものではありません。

from dataclasses import dataclass
from typing import List


@dataclass
class Record:
    """共有ノートに追加される1件分の記録を表します。"""
    index: int      # 記録の順番
    text: str       # 記録の内容
    author: str     # 記録した人


def show_history(name: str, history: List[Record]) -> None:
    """履歴の中身を見やすく表示するための関数です。"""
    print(f"\n{name}")
    for record in history:
        print(f"{record.index}. {record.text} / 記録者: {record.author}")


# 最初は全員が同じ共有記録を持っている、という想定です。
common_history = [
    Record(index=1, text="会場費 5,000円", author="Aさん"),
    Record(index=2, text="飲み物代 1,200円", author="Bさん"),
]

# Cさんの手元では、3件目として「備品代」が追加されました。
history_a = common_history + [
    Record(index=3, text="備品代 2,000円", author="Cさん"),
]

# ほぼ同じタイミングで、Dさんの手元では「印刷代」が追加されました。
history_b = common_history + [
    Record(index=3, text="印刷代 800円", author="Dさん"),
]

# 2つの履歴を表示します。
show_history("履歴A", history_a)
show_history("履歴B", history_b)

# 3件目の記録が同じかどうかを確認します。
# 内容が違う場合、どちらを採用するかを決めるルールが必要になります。
if history_a[2] != history_b[2]:
    print("\n3件目の記録が食い違っています。")
    print("どちらの履歴を採用するかを決めるルールが必要です。")

このコードでは、最初の2件は同じですが、3件目だけが違う2つの履歴を作っています。

実行すると、次のような状況が見えてきます。

履歴A
1. 会場費 5,000円 / 記録者: Aさん
2. 飲み物代 1,200円 / 記録者: Bさん
3. 備品代 2,000円 / 記録者: Cさん

履歴B
1. 会場費 5,000円 / 記録者: Aさん
2. 飲み物代 1,200円 / 記録者: Bさん
3. 印刷代 800円 / 記録者: Dさん

3件目の記録が食い違っています。
どちらの履歴を採用するかを決めるルールが必要です。

この例で言いたいのは、履歴が分かれること自体よりも、分かれたあとにどう決めるか が重要だということです。

ブロックチェーンでも、複数のブロック候補が出ることがあります。
そのとき、ネットワークの参加者が「どちらの履歴を伸ばしていくか」を判断するルールが必要になります。

このルールがなければ、参加者ごとに違う履歴を正しいと思い込んでしまい、同じ台帳を共有できなくなります。

1.5 もう少しアルゴリズム風に考える：候補から1つを選ぶ

先ほどの例では、履歴Aと履歴Bのどちらを採用するかが問題になりました。

では、候補が複数あるときに、単純なルールで1つを選ぶとしたらどうなるでしょうか。

ここでは、あえてブロックチェーンの実際のルールではなく、学習用の簡単なルールを使います。
目的は、候補を選ぶルールがあると、全員が同じ履歴にそろいやすくなる ことを確認することです。

# これは「複数の記録候補から、同じルールで1つを選ぶ」ことを理解するための学習用コードです。
# 実際のPoWやPoSのフォーク選択ルールではありません。

from dataclasses import dataclass
from typing import List


@dataclass
class CandidateRecord:
    """次に追加される記録の候補を表します。"""
    text: str        # 記録の内容
    proposer: str    # 提案した人
    score: int       # 候補を比較するための学習用スコア


def choose_record(candidates: List[CandidateRecord]) -> CandidateRecord:
    """
    複数の記録候補から、スコアが最も高いものを選びます。

    注意:
    - ここでのscoreは説明用の値です。
    - 実際のPoWでは、累積された作業量などが重要になります。
    - 実際のPoSでは、バリデータの投票やファイナリティなど、もっと複雑なルールが関係します。
    """
    return max(candidates, key=lambda candidate: candidate.score)


# 次に追加される記録の候補が3つあるとします。
candidates = [
    CandidateRecord(text="備品代 2,000円", proposer="Cさん", score=10),
    CandidateRecord(text="印刷代 800円", proposer="Dさん", score=7),
    CandidateRecord(text="交通費 1,500円", proposer="Eさん", score=4),
]

# 全員が同じchoose_record関数を使えば、同じ候補を選べます。
selected = choose_record(candidates)

print("採用する記録:")
print(f"内容: {selected.text}")
print(f"提案者: {selected.proposer}")
print(f"スコア: {selected.score}")

このコードでは、score が一番高い候補を採用しています。

もちろん、実際のブロックチェーンでは、このような単純なスコアだけで決めているわけではありません。
ただ、ここで重要なのは、参加者が同じルールを使えば、候補が複数あっても同じ結果にそろいやすくなるという点です。

ブロックチェーンの世界では、この「同じルール」がとても重要です。

どの取引を有効とみなすか
どのブロックを有効とみなすか
どの履歴を伸ばすか
不正な提案をどう扱うか
正しく参加した人にどう報酬を与えるか
不正した人にどうコストを負わせるか

こうしたルールがそろっているからこそ、顔も知らない参加者同士が、同じ台帳を共有できます。

1.6 PoWとPoSは「次の記録を書く人」を決めるための代表的な考え方

ここまで、共有記録の問題を身近な例で見てきました。

話を整理すると、問題は大きく3つあります。

問題	ざっくりした意味	PoW/PoSとの関係
誰が次の記録を書くか	参加者が多い中で、次の記録の提案者を選ぶ	マイナーやバリデータの選び方に関係する
どの履歴を採用するか	複数の履歴候補があるときに、どれを伸ばすか	フォーク選択や投票に関係する
不正をどう抑止するか	嘘の記録を安く大量に出せないようにする	計算資源やステークをコストにする

PoWとPoSは、このうち特に 誰が次のブロックを作るのか、そして 不正をしようとする人にどのようなコストを負わせるのか に関係します。

PoWでは、計算作業をたくさん行うことが重要になります。
たとえるなら、「条件に合う当たりを引くまで、何度もくじを引く」ようなものです。

一方で、PoSでは、資産を預けて責任を持つことが重要になります。
たとえるなら、「保証金を預けて、共同管理の当番に参加する」ようなものです。

方式	次の記録を書く人の選び方のイメージ	不正時に意識されるコスト
PoW	条件に合う計算結果を見つけた人がブロックを提案する	計算資源、電力、設備投資、機会損失
PoS	ステークした資産などに基づいて選ばれたバリデータがブロックを提案する	預けた資産、報酬、ペナルティ、slashing

ここではまだ、PoWやPoSの詳しい仕組みまでは分からなくて大丈夫です。
次の章以降で、順番に見ていきます。

まずこの章で押さえたいのは、PoWとPoSが突然出てくる専門用語ではなく、次のような問題に対する考え方だということです。

みんなで同じ記録を共有したい。
でも、特定の管理者だけに任せたくない。
そのとき、誰が次の記録を書いてよいのか。
不正をしようとする人には、何をコストとして負わせるのか。

この問いへの代表的な答えが、Proof of WorkとProof of Stakeです。

💡 豆知識
「マイナー」や「バリデータ」という言葉は、どちらもブロックチェーンの記録作成・検証に関わる参加者を表します。
ただし、PoWでは計算作業を行う参加者をマイナーと呼ぶことが多く、PoSではステークした資産をもとに検証へ参加する人をバリデータと呼ぶことが多いです。
名前が違うのは、参加の根拠となるコストが違うからだと考えると理解しやすくなります。

1.7 この章のまとめ

この章では、PoWやPoSの詳しい説明に入る前に、みんなで共有する記録では何が問題になるのかを整理しました。

会計ノート、議事録、共同編集メモのような身近な記録でも、複数人が同時に書き込めるようにすると、次のような問題が出てきます。

誰が次の記録を書いてよいのか
記録が食い違ったとき、どちらを採用するのか
悪意ある人が勝手な記録を追加しようとしたらどうするのか
参加者を数だけで見ると、偽の参加者を大量に作られる可能性がある
不正を安く済ませられないように、何らかのコストが必要になる

ブロックチェーンでも、これに近い問題があります。
特定の管理者だけを信じるのではなく、多くの参加者が同じ台帳を共有するには、記録の追加方法や履歴の選び方に関するルールが必要です。

この章で特に押さえたいポイントは、次の通りです。

ポイント	説明
共有記録では、誰が書くかが問題になる	全員が勝手に書くと履歴が食い違う可能性がある
分岐が起きたときのルールが必要	複数の履歴候補が出たとき、どれを採用するか決める必要がある
偽参加者への対策が必要	アカウントを増やすだけで有利になると、Sybil攻撃に弱い
不正にはコストを負わせる必要がある	PoWでは計算資源、PoSでは預けた資産が重要な役割を持つ

次の章では、この流れを受けて、コンセンサス という言葉を整理します。

PoWやPoSはよく「コンセンサス方式」と呼ばれますが、厳密にはそれだけで合意形成のすべてが決まるわけではありません。
次章では、コンセンサス、Sybil耐性、ブロック作成者の選択、フォーク選択を分けながら、PoW/PoSに入る前の地図を作っていきます。

2. コンセンサスをざっくり整理する

この章では、PoWとPoSに入る前に、そもそもブロックチェーンでいう「コンセンサス」が何を指すのかを整理します。
ポイントは、コンセンサスを「みんなが同じ気持ちになること」ではなく、同じルールにもとづいて、同じ履歴を正しいものとして扱える状態に近づける仕組み として見ることです。

前の章では、会計ノートや議事録のような共有記録を例にして、次のような問題を見ました。

誰が次の記録を書いてよいのか
記録が食い違ったとき、どちらを採用するのか
偽の参加者を大量に作られたらどうするのか
不正をしようとする人に、どのようなコストを負わせるのか

この問題をブロックチェーンの文脈で考えるときに出てくるのが、コンセンサス という言葉です。

コンセンサスは、日本語では「合意」と訳されることが多いです。
ただし、日常会話でいう「全員が納得して賛成する」という意味で捉えると、少し誤解しやすくなります。

ブロックチェーンで重要なのは、全員が同じ感想を持つことではありません。
むしろ、世界中の参加者が同時に通信していても、多少の遅延や食い違いがあっても、最終的に「この履歴を正しいものとして扱おう」とそろっていくことです。

たとえるなら、共同編集メモで次のような状態を目指すイメージです。

状態	身近な例	ブロックチェーンでのイメージ
同じルールで記録する	会計ノートの書き方を決める	有効な取引・ブロックの条件を決める
次に書く人を決める	当番や担当者を決める	ブロック提案者を決める
記録が分かれたときに選ぶ	どちらの版を正式版にするか決める	フォークした履歴から採用するチェーンを選ぶ
不正にコストを負わせる	嘘を書いたら保証金を失う	計算資源やステークを失う可能性を持たせる

つまり、コンセンサスを理解するには、PoWやPoSだけを見るのではなく、いくつかの部品に分けて考えると分かりやすくなります。

Ethereum公式ドキュメントでも、Proof of WorkやProof of Stakeは簡単のために「コンセンサスプロトコル」と呼ばれることがある、と説明されています。
一方で、厳密には Sybil耐性の仕組み や ブロック作成者を選ぶ仕組み に近く、どのチェーンを正しいものとして選ぶかという chain selection / fork choice も重要だと説明されています。

参考: Ethereum Documentation: Consensus mechanisms

この章では、PoWやPoSの詳しい中身に入る前に、まず「コンセンサス周りの地図」を作っておきます。

2.1 コンセンサスは「全員が同じ意見になること」ではない

まず、コンセンサスという言葉を少しやわらかく考えてみます。

サークルの会計ノートで、「この支出を記録してよいか」を決める場面を想像します。
全員が毎回集まって、1件ずつ話し合って、全員一致で決められれば安心かもしれません。

しかし、人数が多くなると、それは現実的ではありません。

全員が同時にオンラインとは限らない
連絡が遅れる人がいる
同じタイミングで別の人が記録を追加することがある
悪意のある人が嘘の記録を出すかもしれない
そもそも全員の顔や名前を知らないかもしれない

ブロックチェーンも、かなり似た問題を抱えています。

BitcoinやEthereumのようなパブリックブロックチェーンでは、世界中のノードがネットワークに参加します。
そのため、あるノードには新しいブロックが届いているのに、別のノードにはまだ届いていない、ということが起こります。

つまり、ある瞬間だけを見ると、全員が完全に同じ情報を持っているとは限りません。

それでも、ルールに従って情報を受け取り、検証し、必要に応じて履歴を選び直すことで、ネットワーク全体として同じ履歴に近づいていきます。

この感覚を、かなり単純化して表すと次のようになります。

この図で大切なのは、コンセンサスが「1回の投票イベント」ではないことです。

ブロックチェーンでは、取引やブロックが次々に流れてきます。
そのたびに、各ノードはルールに従って検証し、自分が正しいと考える履歴を更新していきます。

したがって、コンセンサスは「一度だけ多数決をして終わり」というより、記録を追加し続けるための継続的なルールの集まり と見る方が近いです。

2.2 コンセンサス周りの仕組みは、いくつかの部品に分けられる

PoWやPoSを学び始めると、よく次のような説明を見かけます。

BitcoinはPoWで合意する
EthereumはPoSで合意する
PoWとPoSはコンセンサス方式である

この説明は、入門としては便利です。
ただし、少し慣れてきたら、もう一段だけ分解して見ると理解しやすくなります。

ブロックチェーンで同じ履歴を共有するには、少なくとも次のような要素が関係します。

要素	ざっくりした役割	身近な例
検証ルール	その記録が有効かどうかを確認する	会計ノートで、日付・金額・用途がそろっているか確認する
ブロック作成者の選択	次の記録を誰が提案するかを決める	当番や抽選で、次に書く人を決める
Sybil耐性	偽参加者を大量に作って有利になることを防ぐ	1人が投票用紙を大量に作れないようにする
フォーク選択	複数の履歴候補から、どれを伸ばすかを決める	共同編集メモで、正式版をどちらにするか決める
報酬・ペナルティ	正しく参加する動機を作り、不正を抑える	きちんと当番をした人に評価を与え、嘘を書いた人にペナルティを与える
ファイナリティ	ある記録を、どの程度「確定した」と見なすか	議事録を最終版として承認する

PoWやPoSは、この中でも特に Sybil耐性 と ブロック作成者の選択 に深く関わります。

たとえば、PoWでは「どれだけ計算作業を行ったか」が重要になります。
単にアカウントを100個作っただけでは、計算資源が増えるわけではありません。

一方、PoSでは「どれだけ資産をステークしているか」や、ステークした資産を失う可能性があることが重要になります。
こちらも、単に名前だけの参加者を大量に作るだけでは、影響力を簡単には増やせません。

ただし、PoWやPoSだけで全てが決まるわけではありません。
有効な取引かどうかを確認するルール、複数の履歴が出てきたときの選び方、正直に参加するための報酬、不正をしたときのペナルティなどが組み合わさって、全体としてブロックチェーンの合意形成が成り立ちます。

💡 豆知識
「PoW = コンセンサス」「PoS = コンセンサス」と短く説明されることは多いです。
ただし、より丁寧に見ると、PoWやPoSはコンセンサス全体の中の重要な部品です。
特に、偽の参加者を大量に作るSybil攻撃への対策や、誰がブロックを提案するかに関係します。

2.3 Sybil耐性：参加者の「数」だけで決めると危ない

1章でも少し触れましたが、パブリックブロックチェーンでは Sybil攻撃 への対策が重要です。

Sybil攻撃とは、1人の攻撃者が大量の偽アカウントや偽ノードを作り、多数派のように振る舞う攻撃です。

身近な例で考えると、次のような状況です。

1人1票のアンケートなのに、同じ人がアカウントを100個作って投票する
オンライン投票で、本人確認なしに何度も回答する
レビューサイトで、同じ人が大量の別名アカウントを使って評価を操作する

もしブロックチェーンで「ノードの数」や「アカウントの数」だけを見て多数決をすると、攻撃者は大量の偽参加者を作ることで有利になってしまいます。

そこで、PoWやPoSでは、影響力を持つために何らかのコストを必要にします。

方式	影響力の根拠	偽参加者だけでは有利になりにくい理由
PoW	計算作業	偽アカウントを増やしても、計算資源や電力がなければ有利になりにくい
PoS	ステークした資産	偽アカウントを増やしても、十分な資産を預けなければ影響力を持ちにくい

Ethereum公式ドキュメントでも、Sybil耐性は、ユーザーが複数アカウントを使ってネットワーク上の影響力を増やすことへの防御として説明されています。
また、PoWでは計算能力、PoSではステークした暗号資産が、影響力を持つためのコストとして使われると説明されています。

参考: Ethereum Documentation: Consensus mechanisms

ここでのポイントは、PoWもPoSも「参加者を信頼する」だけではなく、攻撃するにはそれなりのコストが必要になるように設計する という点です。

もちろん、コストをかければ絶対に攻撃できない、という意味ではありません。
ただ、攻撃を安く簡単にできないようにすることが重要です。

2.4 フォーク選択：履歴が分かれたとき、どちらを伸ばすか

次に大切なのが、フォーク選択 です。

フォークとは、かなりざっくり言えば、ブロックチェーンの履歴が一時的に分かれることです。
共同編集メモでいうと、「同じ2件目の記録までは一致しているけれど、3件目だけ違う版が2つできた」状態に似ています。

たとえば、次のようなイメージです。

この図では、Block 2 のあとに、Block 3A と Block 3B という2つの候補ができています。
その後、Block 3A 側に Block 4A が追加されています。

このようなとき、ネットワークの参加者は、どちらの履歴を正しい候補として伸ばしていくかを決める必要があります。

Bitcoinの文脈では、よく「longest chain rule」と説明されます。
ただし、PoWでは単純なブロック数だけでなく、チェーンに積み上がった累積的なProof of Work、つまりどれだけ作業量が積み重なっているかが重要です。Ethereum公式ドキュメントでも、Bitcoinの最長チェーンは、PoWチェーンではチェーンの総累積difficultyによって決まると説明されています。

参考: Ethereum Documentation: Consensus mechanisms

Bitcoin Developer Guideでも、ブロックチェーンのフォーク時には複数のブロックが同じ高さになることがあり、ブロック高だけをグローバルに一意な識別子として使うべきではないこと、またBitcoin CoreがチェーンのProof of Workを見てフォークを検出することが説明されています。

参考: Bitcoin Developer Guide: Block Chain

PoSでは、チェーンの選び方はPoWとは異なります。
Ethereumの現在のPoSでは、バリデータの投票やファイナリティに関係する仕組みが使われます。細かい仕様にはGasper、Casper FFG、LMD-GHOSTなどの用語が出てきますが、本記事では深追いせず、「PoSではステークしたバリデータの投票が履歴選択に関係する」程度に押さえます。

ここでは、次のように整理しておけば十分です。

観点	PoWのイメージ	PoSのイメージ
履歴を選ぶ根拠	累積した作業量が大きいチェーンを重視する	ステークしたバリデータの投票やファイナリティを重視する
身近なたとえ	作業実績が多く積み上がったノートを正式版として扱う	保証金を預けた確認者たちの投票で正式版へ近づける
注意点	単純なブロック数だけで見ると誤解しやすい	詳細仕様はチェーンごとに異なる

このように、コンセンサスを理解するには、「誰がブロックを作るか」と「複数の履歴からどれを選ぶか」を分けて考えることが大切です。

2.5 ファイナリティ：どのくらい「確定した」と見なすか

もう一つ、初学者がつまずきやすい言葉に ファイナリティ があります。

ファイナリティは、ある取引やブロックをどの程度「確定した」と見なせるかに関係する言葉です。

身近な例で言えば、議事録の「下書き」と「承認済み最終版」の違いに近いです。

下書きの議事録は、まだ修正されるかもしれません。
一方で、参加者の確認が終わり、最終版として承認された議事録は、あとから勝手に変えるべきではありません。

ブロックチェーンでも、ブロックに含まれた直後の取引は、ネットワークの状態によっては別の履歴に置き換わる可能性があります。
その可能性が十分に小さくなったり、プロトコル上の条件を満たしたりすると、「かなり確定した」と見なせるようになります。

PoWのBitcoinでは、ブロックが積み重なるほど、その取引を巻き戻すには大きな作業量が必要になります。
一方、PoSのEthereumでは、バリデータの投票によってcheckpointがjustifiedやfinalizedになる仕組みがあります。Ethereum公式ドキュメントでは、PoSのEthereumではslotとepochを使い、各slotでブロック提案者が選ばれ、epoch単位で投票やファイナリティが関係すると説明されています。

参考: Ethereum Documentation: Proof-of-stake

ここでは、細かい仕様よりも次の感覚を押さえると読みやすいです。

用語	ざっくりした意味	身近な例
ブロックに含まれる	取引が履歴候補に入る	議事録の下書きに記載される
confirmations	後ろにブロックが積み上がる	その記録を前提に、次の記録が増えていく
finality	かなり確定したと見なせる状態	議事録が最終版として承認される

もちろん、ファイナリティの意味や強さは、チェーンやプロトコルによって異なります。
そのため、記事では「何ブロック待てば絶対安全」といった断定は避けます。

2.6 小さなコードで見る：有効な候補を選び、同じルールで履歴をそろえる

ここで、コンセンサス周りの考え方を、もう一度小さなコードで見てみます。

次のコードは、実際のBitcoinやEthereumの実装ではありません。
目的は、次の3つを理解することです。

まず、無効な候補を除外する
次に、候補が複数ある場合は同じルールで1つを選ぶ
全員が同じルールを使うと、同じ履歴候補にそろいやすくなる

# これはコンセンサス周りの考え方を説明するための学習用コードです。
# 実際のBitcoinやEthereumの検証ルール・フォーク選択ルールではありません。

from dataclasses import dataclass
from typing import List


@dataclass
class BlockCandidate:
    """ブロック候補を表すための学習用データ構造です。"""
    block_id: str          # ブロック候補の識別子
    parent_id: str         # どのブロックの次に続くか
    proposer: str          # 提案した参加者
    transactions: List[int] # 取引金額だけを持つ、かなり単純化した取引リスト
    weight: int            # フォーク選択に使う学習用スコア


def is_valid_block(block: BlockCandidate) -> bool:
    """
    ブロック候補が有効かどうかを確認します。

    実際のブロックチェーンでは、署名、残高、二重支払い、ブロック形式、
    ガス、手数料、スマートコントラクト実行結果など、多くの検証があります。
    ここでは説明用に、取引金額がすべて正の値かどうかだけを確認します。
    """
    return all(amount > 0 for amount in block.transactions)


def choose_head(candidates: List[BlockCandidate]) -> BlockCandidate:
    """
    有効なブロック候補の中から、weightが最も大きい候補を選びます。

    注意:
    - ここでのweightは説明用の値です。
    - PoWでは、累積された作業量が重要になります。
    - PoSでは、バリデータの投票やファイナリティなどが関係します。
    - 実際のフォーク選択ルールは、この例よりずっと複雑です。
    """
    valid_candidates = [block for block in candidates if is_valid_block(block)]

    if not valid_candidates:
        raise ValueError("有効なブロック候補がありません。")

    return max(valid_candidates, key=lambda block: block.weight)


# 3つのブロック候補を用意します。
# block_bは取引金額に負の値が含まれているため、無効な候補として扱われます。
candidates = [
    BlockCandidate(
        block_id="block_A",
        parent_id="block_2",
        proposer="参加者A",
        transactions=[500, 1200, 300],
        weight=12,
    ),
    BlockCandidate(
        block_id="block_B",
        parent_id="block_2",
        proposer="参加者B",
        transactions=[700, -100],  # 説明用に不正な取引として扱う
        weight=30,
    ),
    BlockCandidate(
        block_id="block_C",
        parent_id="block_2",
        proposer="参加者C",
        transactions=[900, 400],
        weight=8,
    ),
]

selected = choose_head(candidates)

print("採用するブロック候補:")
print(f"ID: {selected.block_id}")
print(f"提案者: {selected.proposer}")
print(f"weight: {selected.weight}")

このコードでは、まず is_valid_block() で有効な候補かどうかを確認しています。
そのあと、choose_head() で有効な候補だけを比較し、weight が最も大きいものを選んでいます。

ここで注目したいのは、block_B の weight が一番大きいにもかかわらず、採用されない点です。

なぜなら、block_B には説明用に負の金額の取引を入れているため、検証ルールで無効とされるからです。

つまり、ブロックチェーンでは、単に「一番強そうな候補」を選ぶのではありません。
まず、有効なルールを満たしているかを確認します。
そのうえで、複数の有効な候補がある場合に、フォーク選択ルールでどれを伸ばすかを決めます。

この流れは、かなり単純化すると次のようになります。

1. 新しいブロック候補を受け取る
2. 取引やブロック形式が有効か検証する
3. 無効な候補は採用しない
4. 有効な候補が複数ある場合は、フォーク選択ルールで選ぶ
5. 選んだ履歴を前提に、次のブロックを受け入れていく

この分け方をしておくと、PoWやPoSの説明に入ったときも混乱しにくくなります。

2.7 小さなコードで見る：数だけの多数決が危ない理由

もう一つ、Sybil耐性を理解するための小さなコードを見てみます。

ここでは、単純な多数決だけで正式な記録を決める場合を考えます。
もし1人の攻撃者が偽アカウントを大量に作れるなら、多数決は簡単にゆがめられてしまいます。

# これはSybil攻撃の考え方を説明するための学習用コードです。
# 実際のPoWやPoSの投票・重み付けを再現するものではありません。

from collections import Counter


# 正直な参加者3人は「履歴A」を支持しているとします。
honest_votes = ["履歴A", "履歴A", "履歴A"]

# 攻撃者は偽アカウントを10個作り、「履歴B」に投票させます。
sybil_votes = ["履歴B"] * 10

# 単純な多数決では、偽アカウントの数がそのまま影響力になります。
all_votes = honest_votes + sybil_votes
vote_count = Counter(all_votes)

print("単純な多数決の結果:")
for history, count in vote_count.items():
    print(f"{history}: {count}票")

winner = vote_count.most_common(1)[0][0]
print(f"採用される履歴: {winner}")

このコードでは、正直な参加者は3人だけですが、攻撃者が偽アカウントを10個作っているため、単純な多数決では 履歴B が勝ってしまいます。

この例はかなり単純ですが、Sybil攻撃の怖さを直感的に示しています。

もし影響力が「アカウント数」だけで決まるなら、攻撃者はアカウントを増やすだけでネットワークを支配しやすくなります。

そこでPoWやPoSでは、単なるアカウント数ではなく、計算資源やステークのようなコストを使います。

# 今度は、参加者の数ではなく「重み」を使って投票する例です。
# ここでのweightは説明用です。
# PoWなら計算資源、PoSならステーク量のようなコストをイメージします。

from collections import Counter

weighted_votes = [
    {"history": "履歴A", "voter": "正直な参加者1", "weight": 40},
    {"history": "履歴A", "voter": "正直な参加者2", "weight": 35},
    {"history": "履歴A", "voter": "正直な参加者3", "weight": 25},
]

# 攻撃者は偽アカウントを10個作っていますが、各アカウントの重みは小さいとします。
for i in range(10):
    weighted_votes.append({"history": "履歴B", "voter": f"偽アカウント{i+1}", "weight": 2})

# 履歴ごとに重みを合計します。
weighted_count = Counter()
for vote in weighted_votes:
    weighted_count[vote["history"]] += vote["weight"]

print("重み付きで見た結果:")
for history, weight in weighted_count.items():
    print(f"{history}: weight={weight}")

winner = weighted_count.most_common(1)[0][0]
print(f"採用される履歴: {winner}")

この例では、偽アカウントの数が多くても、影響力の重みが小さければ、多数派を簡単には奪えません。

もちろん、実際のPoWやPoSはこのコードよりずっと複雑です。
PoWでは「投票」というより、計算作業にもとづいてブロック提案とチェーン選択が行われます。
PoSでも、単純に資産額だけで多数決するのではなく、バリデータの選出、投票、報酬、ペナルティ、ファイナリティなどが関係します。

ただ、入口としては次の感覚が大切です。

パブリックブロックチェーンでは、参加者の数だけを信じると危ない。
そのため、PoWやPoSでは、影響力を持つために何らかのコストを必要にする。

2.8 コンセンサスを理解するための地図

ここまでの内容を、PoW/PoSに入る前の地図として整理します。

この図で見ると、PoWやPoSがどこに位置するのかが少し見えやすくなります。

PoWやPoSは、ブロックチェーンの合意形成においてとても重要です。
しかし、それだけで全てが終わるわけではありません。

次の章からは、この地図の中でも特に重要な2つの方式を順番に見ていきます。

まずは、Bitcoinで使われているProof of Workです。
PoWでは、なぜ「計算作業」が記録の信頼性に関係するのでしょうか。
そして、なぜ「見つけるのは大変だけれど、確認するのは比較的簡単」という性質が重要なのでしょうか。

次の章では、くじ引きやパズルの例を使いながら、Proof of Workの基本的な考え方を整理します。

2.9 この章のまとめ

この章では、PoWとPoSに入る前に、コンセンサス周りの考え方を整理しました。

コンセンサスは、単に「全員が同じ意見になること」ではありません。
ブロックチェーンでは、世界中の参加者が同じ履歴を正しいものとして扱えるように、検証ルール、ブロック作成者の選択、Sybil耐性、フォーク選択、報酬・ペナルティ、ファイナリティなどが組み合わさっています。

この章で押さえたいポイントは、次の通りです。

ポイント	説明
コンセンサスは継続的なルールの集まり	1回の多数決ではなく、記録を追加し続けるための仕組みとして見る
PoW/PoSだけで全てが決まるわけではない	Sybil耐性やブロック作成者選択に深く関わるが、フォーク選択なども重要
数だけの多数決は危ない	偽アカウントを大量に作るSybil攻撃に弱くなる
フォーク選択が必要	履歴が一時的に分かれたとき、どちらを伸ばすか決める必要がある
ファイナリティも重要	記録をどの程度「確定した」と見なすかは、チェーンごとに考え方が異なる

次の章では、いよいよ Proof of Work を見ていきます。

まずはBitcoinの文脈を中心に、計算作業、ハッシュ、nonce、difficultyといった言葉を、できるだけ身近な例に置き換えながら整理します。
PoWは一見すると「ただ計算しているだけ」に見えるかもしれませんが、実際には不正な履歴を安く作れないようにするための重要な役割を持っています。

3. Proof of Workとは何か

この章では、Proof of Workを「計算作業を使って、次の記録を提案するための仕組み」として整理します。
ポイントは、答えを見つけるのは大変だけれど、答えが合っているか確認するのは比較的簡単 という性質です。

前の章では、ブロックチェーンのコンセンサス周りの考え方を整理しました。

ブロックチェーンでは、単に「みんなで多数決すればよい」とは言えません。
参加者を数だけで見ると、1人が大量の偽アカウントを作って多数派のように振る舞う Sybil攻撃 に弱くなるからです。

そこで必要になるのが、影響力を持つために何らかのコストを必要にする考え方です。

Proof of Work、略してPoWは、その代表的な方法の一つです。
かなりざっくり言えば、PoWは たくさん計算作業をしたことを根拠に、ブロック作成へ参加する仕組み です。

身近な例で言えば、「条件に合う当たり番号を見つけるまで、何度もくじを引く」ようなものです。

ただし、普通のくじ引きと少し違うのは、当たりを引いた人が「当たりました」と言ったとき、周りの人がすぐに確認できる点です。

観点	くじ引きの例	PoWのイメージ
探すもの	当たり番号	条件に合うハッシュ値
試す方法	何度もくじを引く	nonceなどを変えながら何度もハッシュ計算する
探す大変さ	当たりが少ないほど大変	difficultyが高いほど大変
確認	当たり番号か見れば分かる	ハッシュが条件を満たすか確認する
不正のしにくさ	当たりを偽造しにくい	過去のブロックを書き換えるには作業をやり直す必要がある

Bitcoinのホワイトペーパーでは、P2P上で分散タイムスタンプサーバーを実現するために、Hashcashに似たProof of Workを使うと説明されています。
そこでは、SHA-256のようなハッシュを使い、ハッシュ値が一定数の0ビットで始まるような値を探すこと、必要な作業量は要求される0ビット数に対して増える一方、検証は1回のハッシュ計算でできることが説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

つまり、PoWの入口は次の一文にまとめられます。

PoWは、条件を満たす計算結果を見つけるために作業を行い、その作業を他の参加者が簡単に検証できるようにする仕組みです。

ここから、ハッシュ、nonce、difficultyという言葉を順番に見ていきます。

3.1 まずは「当たり番号を探す」から考える

いきなりハッシュやnonceという言葉から入ると、少し難しく感じます。

そこで、まずは当たり番号探しで考えます。

たとえば、次のようなゲームがあるとします。

0から順番に数字を試していき、
あるルールを満たす数字を最初に見つけた人が勝ち。

ルールが簡単なら、すぐに当たりが見つかります。

数字が偶数なら当たり

この場合、2、4、6、8……とすぐ見つかります。
あまり大変ではありません。

一方で、ルールが厳しくなるとどうでしょうか。

計算結果の先頭が 0000 になる数字なら当たり

この場合、どの数字が当たりになるかは、実際に試してみないと分かりません。
何度も数字を変えながら試す必要があります。

PoWも、最初の理解としてはこれに近いです。

Bitcoinでは、ブロックヘッダなどの情報をもとにハッシュを計算し、その結果がネットワークの条件を満たすような値を探します。
Bitcoin Developer Referenceでは、ブロックヘッダに前のブロックのハッシュ、Merkle root、時刻、nBits、nonceなどが含まれると説明されています。

参考: Bitcoin Developer Reference: Block Headers

このとき、何度も変えながら試す値の一つが nonce です。

nonceは、ざっくり言えば 条件に合うハッシュを探すために変える数字 です。

用語	ざっくりした意味	身近なイメージ
ハッシュ	入力から作られる固定長の値	書類の指紋のようなもの
nonce	何度も変えて試す数字	くじ番号、試行番号
target	ハッシュが満たすべき条件	当たり判定の基準
difficulty	当たりの出にくさ	くじの当たりにくさ

💡 豆知識
nonce は、暗号や通信の文脈でよく出てくる言葉です。
「number used once」のように説明されることが多く、ざっくり言えば 一度使うための数字 という意味合いがあります。
PoWでは、条件に合うハッシュを探すために、このnonceを変えながら何度も試すイメージで理解すると分かりやすいです。

3.2 ハッシュは「同じ入力なら同じ結果」になる

PoWを理解するには、ハッシュの性質を少しだけ押さえておく必要があります。

ハッシュ関数は、入力データから固定長の値を作る関数です。
たとえば、同じ文字列を入れれば、同じハッシュ値が出ます。

一方で、入力が少しでも変わると、出てくるハッシュ値は大きく変わります。

身近な例で言えば、書類の内容から作る「指紋」のようなものです。

入力	ハッシュのイメージ
`会場費 5,000円`	あるハッシュ値になる
`会場費 5,001円`	まったく違うハッシュ値に見える
`会場費 5,000円 nonce=1`	nonceを含めた別のハッシュ値になる
`会場費 5,000円 nonce=2`	また別のハッシュ値になる

PoWでは、この性質を利用します。

ブロックの中身やnonceをもとにハッシュを計算し、そのハッシュが条件を満たしていれば「このブロック候補はPoW条件を満たしている」と確認できます。

ここで重要なのは、どのnonceが条件を満たすかを事前に簡単には予測できない ことです。

そのため、参加者はnonceなどを変えながら、何度もハッシュ計算を試します。

この図のように、PoWでは「試す → 確認する → だめなら変えてまた試す」という流れを繰り返します。

3.3 小さなコードで見る：ハッシュ値は少しの違いで大きく変わる

ここで、Pythonでハッシュの性質を見てみます。

次のコードは、実際のBitcoinマイニングを再現するものではありません。
あくまで、同じ入力なら同じハッシュになり、少し入力を変えると結果が大きく変わることを確認するための学習用コードです。

# ハッシュの基本的な性質を確認するための学習用コードです。
# 実際のBitcoinマイニングを再現するものではありません。

import hashlib


def sha256_hex(text: str) -> str:
    """
    入力文字列からSHA-256ハッシュを作り、16進数の文字列として返します。

    hashlib.sha256() はバイト列を入力として受け取るため、
    text.encode("utf-8") で文字列をバイト列に変換しています。
    """
    return hashlib.sha256(text.encode("utf-8")).hexdigest()


# ほとんど同じ内容の文字列を用意します。
message_a = "会場費 5000円"
message_b = "会場費 5001円"  # 金額を1円だけ変えています。

# それぞれのハッシュ値を計算します。
hash_a = sha256_hex(message_a)
hash_b = sha256_hex(message_b)

print("入力A:", message_a)
print("ハッシュA:", hash_a)
print()

print("入力B:", message_b)
print("ハッシュB:", hash_b)
print()

# 同じ入力をもう一度ハッシュ化すると、同じ結果になることも確認します。
print("入力Aをもう一度ハッシュ化した結果:")
print(sha256_hex(message_a))

このコードを実行すると、message_a と message_b は1文字しか違わないのに、ハッシュ値は大きく変わって見えます。

ここで押さえたいのは、次の2点です。

同じ入力なら、同じハッシュ値になる
入力が少し変わると、ハッシュ値は大きく変わって見える

PoWでは、この性質を使って、nonceを少しずつ変えながら条件に合うハッシュを探します。

3.4 nonceを変えながら「当たり」を探す

次に、PoWの雰囲気に近づけてみます。

ここでは、次のようなルールを考えます。

ハッシュ値の先頭が 0000 なら当たり

ハッシュ値は16進数の文字列として表示されます。
その先頭が 0000 になるようなnonceを探す、という学習用のミニPoWを作ります。

# nonceを変えながら、条件に合うハッシュを探す学習用コードです。
# 実際のBitcoinのPoWでは、ブロックヘッダ、target、difficultyなどが関係します。
# ここでは初学者向けに「ハッシュの先頭が0000になるnonceを探す」だけに単純化しています。

import hashlib


def sha256_hex(text: str) -> str:
    """入力文字列のSHA-256ハッシュを16進数文字列で返します。"""
    return hashlib.sha256(text.encode("utf-8")).hexdigest()


def find_nonce(block_data: str, prefix: str = "0000") -> tuple[int, str]:
    """
    block_data と nonce を組み合わせてハッシュ化し、
    ハッシュ値が指定した prefix で始まる nonce を探します。

    block_data: ブロック候補の内容を単純化した文字列
    prefix: 当たり条件。ここではハッシュの先頭文字列として扱います。

    戻り値:
    - 条件を満たした nonce
    - そのときのハッシュ値
    """
    nonce = 0

    while True:
        # block_data と nonce をつなげて、試行ごとの入力を作ります。
        # nonceを変えることで、毎回違うハッシュ値を試せます。
        candidate = f"{block_data}|nonce={nonce}"
        candidate_hash = sha256_hex(candidate)

        # ハッシュ値が指定したprefixで始まれば、条件を満たしたと判断します。
        if candidate_hash.startswith(prefix):
            return nonce, candidate_hash

        # 条件を満たさなければ、nonceを1増やして次を試します。
        nonce += 1


# 学習用のブロック内容です。
# 実際のブロックには、前のブロックのハッシュ、取引、時刻など多くの情報が含まれます。
block_data = "prev_hash=abc123; tx=A->B:10; tx=C->D:5"

nonce, block_hash = find_nonce(block_data, prefix="0000")

print("見つかったnonce:", nonce)
print("条件を満たしたハッシュ:", block_hash)

このコードでは、nonce を0から順番に増やしながら、block_data と組み合わせてハッシュを計算しています。
そして、ハッシュ値の先頭が 0000 になったところで探索を止めます。

この処理は、PoWの考え方をかなり小さくしたものです。

もちろん、実際のBitcoinでは、単に文字列の先頭が 0000 になるかを見るだけではありません。
Bitcoinでは、ブロックヘッダのハッシュがtargetを下回る必要があり、そのtargetやdifficultyはネットワークのルールに従って調整されます。

Bitcoin Developer Guideでは、BitcoinのPoWではブロックヘッダのハッシュがtarget以下であることが必要であり、difficultyはそのtargetの導き出しやすさを表すと説明されています。

参考: Bitcoin Developer Guide: Block Chain

ただし、入口としては次の理解で十分です。

PoWでは、条件に合うハッシュを探すために、nonceなどを変えながら何度も試します。

3.5 「探すのは大変、確認は簡単」が重要

PoWで大切なのは、当たりを探す作業が大変な一方で、当たりかどうかの確認は簡単であることです。

先ほどのコードで言えば、nonce を見つけるまでは何度も試す必要があります。
しかし、見つかった nonce が本当に条件を満たしているかどうかは、1回ハッシュを計算すれば確認できます。

この性質を、別のコードで確認してみます。

# 見つかったnonceが条件を満たすかを確認する学習用コードです。
# 探索は大変でも、検証は1回のハッシュ計算で済むことを確認します。

import hashlib


def sha256_hex(text: str) -> str:
    """入力文字列のSHA-256ハッシュを16進数文字列で返します。"""
    return hashlib.sha256(text.encode("utf-8")).hexdigest()


def verify_nonce(block_data: str, nonce: int, prefix: str = "0000") -> bool:
    """
    与えられた nonce が、指定したprefix条件を満たすか確認します。

    探索では何度もnonceを試しますが、検証では指定されたnonceで1回計算すれば十分です。
    """
    candidate = f"{block_data}|nonce={nonce}"
    candidate_hash = sha256_hex(candidate)
    return candidate_hash.startswith(prefix)


block_data = "prev_hash=abc123; tx=A->B:10; tx=C->D:5"

# ここでは、前のコードと同じblock_dataで見つかったnonceを入れています。
# 手元でblock_dataを変えた場合は、find_nonce() の結果を使ってください。
nonce = 3330

if verify_nonce(block_data, nonce, prefix="0000"):
    print("このnonceは条件を満たしています。")
else:
    print("このnonceは条件を満たしていません。")

このコードでは、指定されたnonceを使って1回だけハッシュを計算し、条件を満たすか確認しています。

PoWの重要な特徴はここにあります。

作業	大変さ	理由
条件に合うnonceを探す	大変	どのnonceが当たりか事前に分かりにくく、何度も試す必要がある
見つかったnonceを検証する	比較的簡単	そのnonceでハッシュを1回計算し、条件を満たすか見ればよい

Bitcoinのホワイトペーパーでも、PoWの平均作業量は要求される0ビット数に対して増え、検証は1回のハッシュ計算でできると説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

この「探すのは大変、確認は簡単」という性質があるからこそ、他のノードは提案されたブロックのPoWを確認できます。

3.6 difficultyは「当たりの出にくさ」

PoWでは、条件が厳しくなるほど当たりを見つけるのが大変になります。

先ほどの例で言えば、次のような違いです。

条件	ざっくりした難しさ
ハッシュが `0` で始まる	比較的見つけやすい
ハッシュが `00` で始まる	少し見つけにくい
ハッシュが `0000` で始まる	もっと見つけにくい
ハッシュが `000000` で始まる	かなり見つけにくい

この「当たりの出にくさ」に関係するのが difficulty です。

Bitcoinのホワイトペーパーでは、ハードウェア速度や参加状況の変化に対応するため、一定時間あたりのブロック数を目標にPoW difficultyを調整する、と説明されています。
ブロックが速く生成されすぎる場合は、difficultyが上がるという考え方です。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

身近な例で言うと、くじ引き大会で参加者が増えて当たりが早く出すぎるようになったら、当たり条件を厳しくするようなものです。

もちろん、実際のdifficulty調整はチェーンごとに仕様が決まっています。
ここでは、「difficultyは当たりの出にくさを調整するもの」と押さえておきます。

3.7 小さなコードで見る：条件を厳しくすると試行回数が増えやすい

次に、条件を変えると探索の大変さがどう変わるかを見てみます。

次のコードでは、ハッシュの先頭に必要な0の数を変えながら、nonce探索に何回くらい試行が必要だったかを表示します。

# difficultyのイメージをつかむための学習用コードです。
# 先頭に必要な0の数を増やすと、一般に当たりを見つけるまでの試行回数が増えやすくなります。
# 実際のBitcoinのdifficulty調整を再現するものではありません。

import hashlib


def sha256_hex(text: str) -> str:
    """入力文字列のSHA-256ハッシュを16進数文字列で返します。"""
    return hashlib.sha256(text.encode("utf-8")).hexdigest()


def find_nonce_with_attempts(block_data: str, prefix: str) -> tuple[int, str, int]:
    """
    指定したprefixで始まるハッシュを作るnonceを探します。

    戻り値:
    - 条件を満たしたnonce
    - 条件を満たしたハッシュ
    - 試行回数
    """
    nonce = 0
    attempts = 0

    while True:
        candidate = f"{block_data}|nonce={nonce}"
        candidate_hash = sha256_hex(candidate)
        attempts += 1

        if candidate_hash.startswith(prefix):
            return nonce, candidate_hash, attempts

        nonce += 1


block_data = "prev_hash=abc123; tx=A->B:10; tx=C->D:5"

# 条件を少しずつ厳しくして試します。
# 0000程度なら手元PCでも比較的短時間で見つかる想定です。
for prefix in ["0", "00", "000", "0000"]:
    nonce, block_hash, attempts = find_nonce_with_attempts(block_data, prefix)

    print(f"条件: hash starts with {prefix}")
    print(f"  nonce: {nonce}")
    print(f"  attempts: {attempts}")
    print(f"  hash: {block_hash}")
    print()

このコードを実行すると、条件が厳しくなるほど、一般に試行回数が増えやすいことが分かります。

ただし、ハッシュ探索にはランダムに近い性質があります。
そのため、必ず毎回きれいに試行回数が増えるとは限りません。

たとえば、000 の条件ではたまたま早く見つかることもあります。
一方で、0000 の条件では予想より時間がかかることもあります。

ここで大切なのは、個別の実行結果ではなく、条件が厳しくなるほど平均的には見つけるのが難しくなる という感覚です。

3.8 BitcoinにおけるPoWの流れ

ここまでの話を、Bitcoinの文脈に寄せて整理します。

Bitcoinのホワイトペーパーでは、ネットワークの流れとして次のようなステップが説明されています。

新しい取引が全ノードへブロードキャストされる
各ノードが新しい取引をブロックに集める
各ノードがそのブロックに対して難しいPoWを探す
PoWを見つけたノードが、そのブロックを全ノードへブロードキャストする
ノードは、そのブロック内の取引が有効で、まだ使われていない場合だけ受け入れる
ノードは、受け入れたブロックのハッシュを前のハッシュとして、次のブロック作成に取りかかる

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

この流れを図にすると、次のようになります。

ここで出てくる マイナー は、PoWでブロック作成に参加する人や仕組みを指します。

マイナーは、取引を集めてブロック候補を作り、条件を満たすハッシュを探します。
条件を満たすPoWを見つけると、そのブロックをネットワークへ共有します。

ただし、ブロックを共有したからといって、何でも受け入れられるわけではありません。
他のノードは、そのブロックがルールに合っているかを検証します。

この点はとても重要です。

PoWは「計算した人が何でも決められる仕組み」ではありません。
たとえPoW条件を満たしていても、ブロック内に無効な取引が含まれていれば、正直なノードはそのブロックを受け入れません。

Bitcoinのホワイトペーパーでも、ノードはブロック内のすべての取引が有効で、まだ使われていない場合だけブロックを受け入れると説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

3.9 PoWで「過去の書き換え」が難しくなる理由

PoWの重要な役割は、単に次のブロックを作る人を選ぶことだけではありません。

過去の履歴を書き換えようとすると、そのブロックだけでなく、その後ろに続くブロックのPoWもやり直す必要が出てきます。

身近な例で言えば、会計ノートの3ページ目を書き換えるだけでは済まず、3ページ目を参照して作られた4ページ目、5ページ目、6ページ目も全部作り直さなければならないようなものです。

Bitcoinのホワイトペーパーでは、一度PoWを行ってブロックが条件を満たすと、そのブロックを変更するには作業をやり直す必要があり、さらに後続ブロックがつながると、それらの作業も含めてやり直す必要があると説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

このため、ブロックが後ろに積み重なるほど、過去のブロックを書き換えるコストは大きくなります。

ただし、ここで注意したいのは、PoWが「絶対に改ざん不可能」を意味するわけではないことです。

PoWは、過去の履歴を書き換えるためのコストを高くする仕組みです。
十分な計算能力を持つ攻撃者がいれば、攻撃の可能性は議論できます。
この話は、次の4章で51%攻撃や不正抑止の観点からもう少し詳しく扱います。

この章では、まず次の感覚を押さえておきます。

PoWでは、ブロックを作るために計算作業が必要です。
そして、過去のブロックを書き換えようとすると、その作業を後続ブロック分も含めてやり直す必要があるため、履歴改ざんのコストが大きくなります。

3.10 EthereumにおけるPoWの位置づけ

PoWというとBitcoinの印象が強いかもしれませんが、Ethereumも以前はPoWを使っていました。

Ethereum公式ドキュメントでは、EthereumはかつてPoWを使っていたものの、2022年にPoWを廃止し、現在はPoSを使っていると説明されています。
また、PoWではマイナーがハードウェアを使って計算を行い、ブロックを作る競争に参加していたこと、PoSではマイナーではなくバリデータが使われることが説明されています。

参考: Ethereum Documentation: Proof-of-work

EthereumのPoWでは、Ethashというアルゴリズムが使われていました。
Ethereum公式ドキュメントでは、Ethashのもとでマイナーがnonceを見つけるために試行錯誤し、target以下のハッシュを見つける必要があったと説明されています。

参考: Ethereum Documentation: Proof-of-work

ただし、本記事ではEthereum PoWの詳細なアルゴリズムには踏み込みません。
現在のEthereumはPoSへ移行済みであり、次の5章以降では現在のEthereumを主な例としてPoSを整理します。

ここでは、次の程度に押さえておけば十分です。

チェーン	PoWとの関係
Bitcoin	現在もPoWを中心にした設計として説明される代表例
Ethereum	以前はPoWを使っていたが、2022年のThe MergeでPoSへ移行した

💡 豆知識
EthereumがPoWからPoSへ移行した出来事は The Merge と呼ばれます。
名前の通り、実行層としてのEthereum Mainnetと、PoSのコンセンサスを担うBeacon Chainが合流した更新です。
この話はPoSの章や最近の動向でもう少し扱います。

3.11 PoWを理解するときの注意点

ここまで見ると、PoWは「計算で競う仕組み」と説明できます。

ただし、いくつか誤解しやすい点があります。

誤解しやすい表現	より丁寧な見方
PoWはただの無駄な計算である	不正な履歴を安く作れないようにするためのコストとして計算作業を使う
計算に勝った人が何でも決められる	ブロック内の取引や形式は他のノードに検証される
longest chainなら単純にブロック数だけ見ればよい	PoWでは累積された作業量が重要になる
PoWなら絶対に改ざんできない	改ざんのコストを高める仕組みであり、攻撃可能性は計算能力の分布などに依存する
PoWはBitcoinだけの話である	Bitcoinが代表例だが、過去のEthereumなど他のチェーンでも使われてきた

特に大事なのは、「改ざん不可能」と言い切らないことです。

ブロックチェーンは、過去の記録をあとからこっそり書き換えにくくし、書き換えようとすると大きなコストが必要になるように設計されています。
しかし、どの程度安全かは、ネットワークの規模、計算能力の分布、参加者のインセンティブ、ソフトウェア実装、運用状況などにも左右されます。

そのため、本記事ではPoWを次のように整理します。

PoWは、計算作業をコストとして使い、不正な履歴を安く作れないようにする仕組みです。
条件に合うハッシュを探すのは大変ですが、見つかった結果を検証するのは比較的簡単です。

3.12 この章のまとめ

この章では、Proof of Workの基本的な考え方を整理しました。

PoWは、条件に合うハッシュを見つけるために、nonceなどを変えながら何度も計算を試す仕組みです。
答えを見つけるには計算資源や時間が必要ですが、見つかった答えが条件を満たしているかどうかは比較的簡単に確認できます。

この章で押さえたいポイントは、次の通りです。

ポイント	説明
PoWは計算作業をコストにする	影響力を持つために計算資源や電力が必要になる
ハッシュ条件を満たすnonceを探す	nonceなどを変えながら何度もハッシュ計算を試す
探すのは大変、確認は簡単	他のノードは提案されたPoWを比較的簡単に検証できる
difficultyは当たりの出にくさに関係する	条件が厳しいほど、平均的には多くの試行が必要になる
過去の書き換えには作業のやり直しが必要	後続ブロック分も含めて作業をやり直す必要があるため、改ざんコストが高くなる
PoWだけで何でも許可されるわけではない	ブロックや取引は他のノードによって検証される

次の章では、このPoWがどのように不正を抑止するのかをもう少し詳しく見ていきます。

特に、二重支払い、累積作業量、51%攻撃、マイニングプールの集中、エネルギー消費といった論点を整理します。
PoWは「計算で当たりを探す仕組み」として理解できますが、その目的は単なる計算競争ではありません。
不正な履歴を作ろうとする人に、どのようなコストを負わせるのかが次の章の中心になります。

4. PoWではどのように不正を抑止するのか

この章では、PoWがどのように不正をしにくくしているのかを整理します。
ポイントは、PoWが「うそを書けない魔法」ではなく、うそを通すためのコストをとても高くする仕組みだという点です。

前の章では、PoWを「条件に合うハッシュを探すために、nonceなどを変えながら何度も計算する仕組み」として見ました。

ここまでだと、PoWは単に「計算で当たりを探すゲーム」のように見えるかもしれません。
しかし、PoWの目的は、計算競争そのものではありません。

本当に大切なのは、次のような不正を安く済ませられないようにすることです。

すでに使った資金を、別の相手にも使ったことにしたい
過去の取引履歴を、自分に都合よく書き換えたい
不正なブロックを正しい履歴として広めたい
偽の参加者を大量に作って、ネットワーク上の影響力を大きく見せたい

このような不正に対して、PoWは「正しい参加者かどうかを身分証で確認する」のではなく、計算作業というコストを負わせることで対抗します。

たとえるなら、誰でも参加できる共同ノートに対して、次のページを書くには「かなり大変なパズルを解く必要がある」というルールを置くイメージです。
パズルを解くのは大変ですが、解けたかどうかの確認はすぐできます。

そのため、不正な履歴を作ろうとする人は、正直な参加者たちよりも多くのパズルを解き続ける必要があります。

Bitcoinのホワイトペーパーでは、過去のブロックを変えるには、そのブロックだけでなく後続ブロック分のPoWもやり直す必要があり、攻撃者は正直なノードの作業に追いついて追い越さなければならないと説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

また、Bitcoin Developer Guideでも、ブロックがつながっているため、あるブロックに含まれる取引を変更するには、そのブロックと後続ブロックも変更する必要があり、新しいブロックが追加されるほど変更コストが大きくなると説明されています。

参考: Bitcoin Developer Guide: Block Chain

4.1 まずは「二重支払い」から考える

PoWが防ごうとしている代表的な問題の一つが、二重支払いです。

二重支払いとは、かなりざっくり言うと、同じお金を2回使おうとすることです。

身近な例で考えてみます。

もし紙のチケットを1枚持っていて、そのチケットでイベントに入場したら、同じチケットでもう一度別の入口から入ることはできません。
なぜなら、紙のチケットは回収されたり、スタンプを押されたり、QRコードを読み取られたりして、「すでに使われた」と分かるからです。

しかし、デジタルな情報はコピーしやすいです。
もし「1枚のデジタルチケット」をコピーして、AさんにもBさんにも渡せてしまうなら困ります。

暗号資産でも似た問題があります。

同じ資金を使って、次の2つの取引を作ろうとするケースを考えます。

取引	内容
取引A	自分の資金をお店へ送る
取引B	同じ資金を自分の別アドレスへ戻す

この2つが両方とも有効になってしまうと、同じ資金を2回使ったことになります。

Bitcoin Developer Guideでは、ある取引出力はブロックチェーン上で一度だけ入力として使うことができ、同じ出力を後から参照することは、禁止された二重支払いの試みだと説明されています。

参考: Bitcoin Developer Guide: Block Chain

ここで大切なのは、ブロックチェーンでは どちらの取引が先に正しい履歴へ入ったのか をネットワーク全体でそろえる必要があることです。

PoWは、この「正しい履歴をどちらにするか」という問題に対して、計算作業を積み重ねたチェーンを重視することで対応します。

4.2 小さなコードで見る：二重支払いを単純化して考える

ここで、かなり単純化したコードで、二重支払いの考え方を確認してみます。

このコードは、実際のBitcoinのUTXO処理ではありません。
目的は、同じ資金を2回使おうとしたとき、どちらか一方だけを有効にしないといけない という感覚をつかむことです。

# これは二重支払いの考え方を説明するための学習用コードです。
# 実際のBitcoinやEthereumの実装ではありません。

# ある利用者が持っている「まだ使われていない資金」を、説明用に1つだけ用意します。
# 実際のBitcoinでは、このような未使用の受け取り分をUTXOとして扱います。
unspent_outputs = {
    "coin_001": {
        "owner": "Alice",
        "amount": 10,
        "spent": False,
    }
}

# Aliceが同じ coin_001 を使って、2つの取引を作ろうとしているとします。
transactions = [
    {"tx_id": "tx_A", "input": "coin_001", "to": "Shop", "amount": 10},
    {"tx_id": "tx_B", "input": "coin_001", "to": "Alice_Sub", "amount": 10},
]


def validate_transaction(tx, utxos):
    """取引が、まだ使われていない資金を使っているか確認します。"""
    input_id = tx["input"]

    # そもそも参照している資金が存在しない場合は無効です。
    if input_id not in utxos:
        return False, "参照している資金が存在しません"

    # すでに使われている資金をもう一度使おうとしていたら無効です。
    if utxos[input_id]["spent"]:
        return False, "この資金はすでに使われています"

    return True, "有効な取引です"


# 取引を順番に処理します。
# 最初に有効になった取引が資金を使い、後から同じ資金を使う取引は拒否されます。
for tx in transactions:
    is_valid, reason = validate_transaction(tx, unspent_outputs)
    print(f"{tx['tx_id']}: {reason}")

    if is_valid:
        # 有効な取引として受け入れたら、その資金を使用済みにします。
        unspent_outputs[tx["input"]]["spent"] = True

このコードを実行すると、最初の取引は有効になりますが、2つ目の取引は「この資金はすでに使われています」と判断されます。

実際のBitcoinでは、これよりはるかに複雑な検証が行われます。
しかし、入口としては次の点が大切です。

同じ資金を2回使わせないためには、ネットワーク全体で「どの取引が正しい履歴に入ったのか」をそろえる必要があります。

PoWは、その履歴を作るときに計算作業を必要にすることで、後から別の履歴を作って置き換えることを難しくします。

4.3 PoWは「過去を書き換えるコスト」を大きくする

PoWの強さは、1つのブロックを作るのが大変なことだけではありません。

ブロックがチェーン状につながっているため、過去のブロックを変えると、その後ろに続くブロックもまとめて作り直さなければならない点が重要です。

たとえば、次のような履歴があるとします。

ここで、ブロック2に含まれる取引をこっそり変えたいとします。

しかし、ブロック3はブロック2のハッシュを参照しています。
ブロック2の中身が変わると、ブロック2のハッシュも変わります。
すると、ブロック3が参照している「前のブロックのハッシュ」と合わなくなります。

そのため、ブロック2を書き換えたければ、ブロック3、ブロック4、ブロック5も作り直す必要が出てきます。

さらにPoWでは、それぞれのブロックについて条件を満たすハッシュを探し直す必要があります。

Bitcoinのホワイトペーパーでは、後続ブロックが追加されるほど、攻撃者が正直なチェーンに追いつく確率は下がっていくと説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

ここで、PoWを「改ざん不可能」と言い切らないことが大切です。

より正確には、PoWは 過去の履歴を書き換えるための作業量を大きくし、後ろにブロックが積み上がるほど書き換えを難しくする仕組み です。

4.4 小さなコードで見る：後ろにブロックが増えるほど作り直しが増える

次のコードでは、過去のブロックを書き換えると、どれだけのブロックを作り直す必要があるかを単純に数えます。

実際のPoWでは、ブロックごとに必要な作業量はdifficultyやハッシュレートに関係します。
ここではまず、古いブロックを書き換えるほど、後続ブロックも含めて作り直しが増える という構造だけを見ます。

# これは「過去のブロックを書き換えると、後続ブロックも作り直す必要がある」ことを
# 理解するための学習用コードです。
# 実際のBitcoinのPoW計算量を正確に表すものではありません。

# 5個のブロックがつながっているチェーンを用意します。
chain = [
    {"height": 1, "name": "block_1"},
    {"height": 2, "name": "block_2"},
    {"height": 3, "name": "block_3"},
    {"height": 4, "name": "block_4"},
    {"height": 5, "name": "block_5"},
]


def count_blocks_to_rebuild(chain, target_height):
    """指定した高さのブロックを書き換える場合、作り直しが必要なブロック数を数えます。"""
    # target_height 以上のブロックは、書き換え対象とその後続ブロックです。
    blocks_to_rebuild = [block for block in chain if block["height"] >= target_height]
    return blocks_to_rebuild


# ブロック2を書き換えようとすると、ブロック2〜5を作り直す必要があります。
for target_height in [5, 4, 3, 2, 1]:
    rebuild_targets = count_blocks_to_rebuild(chain, target_height)
    names = [block["name"] for block in rebuild_targets]

    print(f"ブロック{target_height}を書き換える場合:")
    print(f"  作り直しが必要なブロック数: {len(rebuild_targets)}")
    print(f"  対象: {names}")

出力を見ると、最新のブロックだけを変える場合より、古いブロックを変える場合の方が、作り直し対象が増えることが分かります。

もちろん、実際のPoWでは「ブロック数」だけでなく、それぞれのブロックに必要な計算作業が関係します。
ただ、最初の理解としては次のように考えると分かりやすいです。

後ろにブロックが積み重なるほど、その前の履歴を書き換えるには多くの作業をやり直す必要があります。

4.5 「承認数」が増えるほど安心しやすくなる理由

暗号資産の送金で、承認数 や confirmations という言葉を見かけることがあります。

これは、ある取引がブロックに入ったあと、その後ろにいくつブロックが追加されたかを表す考え方です。

たとえば、ある取引がブロック100に入ったとします。

現在のブロック	取引が入ったブロック	承認数のイメージ
100	100	1承認
101	100	2承認
105	100	6承認

後ろにブロックが増えるほど、その取引を取り消すためには、より多くのブロックを作り直す必要があります。

Bitcoinのホワイトペーパーでも、受取人は取引がブロックに入ったあと、さらに後続ブロックがいくつか追加されるのを待つことで、攻撃者が追いつく可能性を下げられるという考え方が説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

ここで注意したいのは、承認数が増えれば「絶対に安全」になるわけではないことです。
より正確には、過去の履歴を書き換えるために必要な作業量が増えるため、現実的に攻撃しにくくなる と考えるのが自然です。

💡 豆知識
Bitcoinでは、慣例的に「6承認」という表現がよく出てきます。
これは魔法の境界線ではなく、後ろに複数のブロックが積み上がることで、取引が覆されにくくなるという考え方です。
実際にどの程度待つかは、送金額、サービスの方針、リスク許容度などによって変わります。

4.6 51%攻撃とは何か

PoWの話でよく出てくる言葉に、51%攻撃 があります。

51%攻撃とは、かなりざっくり言えば、攻撃者側がネットワーク全体の計算能力の大きな割合を支配し、正直な参加者よりも速く別のチェーンを伸ばせるようになる攻撃です。

Ethereum公式ドキュメントでは、PoWにおいて悪意あるマイナーが継続的に悪意ある有効ブロックを作るには、ネットワークのマイニング能力の51%を超える必要があったと説明されています。
また、その量の作業には高価な計算能力とエネルギーが必要であり、攻撃で得られる利益を上回る可能性があるとも説明されています。

参考: Ethereum Documentation: Proof-of-work

Bitcoin Developer Guideでも、取引履歴に対する51%攻撃を信頼性高く実行するには、ネットワークのハッシュパワーの過半を得る必要があると説明されています。
ただし、50%未満でも一定の確率で攻撃が成功し得る点にも触れられています。

参考: Bitcoin Developer Guide: Block Chain

ここで、51%攻撃について誤解しやすい点があります。

51%攻撃は、攻撃者が何でも自由にできるという意味ではありません。

Bitcoinのホワイトペーパーでは、攻撃者が別チェーンを作れたとしても、無から価値を作ったり、攻撃者が所有していない資金を奪ったりするような任意の変更はできないと説明されています。
正直なノードは、無効な取引や無効なブロックを受け入れないためです。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

つまり、51%攻撃で問題になりやすいのは、主に次のようなことです。

攻撃で狙われ得ること	説明
二重支払い	いったん支払ったように見せた取引を、あとから別履歴で覆そうとする
一部取引の検閲	特定の取引をブロックに入れないようにする
チェーンの再編成	直近のブロックを別の履歴に置き換える

一方で、次のようなことは通常の検証ルールで拒否されます。

できると誤解されやすいこと	なぜ簡単にはできないか
他人の秘密鍵なしに資金を盗む	署名が無効な取引はノードに拒否される
無から好きなだけコインを作る	発行ルールに反するブロックは無効になる
どんな不正ブロックでも受け入れさせる	フルノードは各自でブロックと取引を検証する

この点はとても重要です。

PoWの安全性は、マイナーだけを信じる仕組みではありません。
ネットワークのノードが、ブロックや取引がルールに合っているかを検証することも重要です。

4.7 小さなコードで見る：攻撃者が追いつくかをざっくりシミュレーションする

Bitcoinのホワイトペーパーでは、攻撃者が正直なチェーンに追いつく確率について、確率的な考え方が示されています。
ここでは難しい数式には踏み込まず、簡単なランダムシミュレーションでイメージを見ます。

このコードは、実際のBitcoinの安全性を評価するものではありません。
あくまで、攻撃者の計算能力の割合が低く、承認数が増えるほど、追いつきにくくなる傾向を直感的に見るための学習用コード です。

# これはPoWにおける「攻撃者が正直なチェーンに追いつけるか」を
# ざっくり理解するための学習用シミュレーションです。
# 実際のBitcoinの安全性評価やリスク計算に使うものではありません。

import random


def attacker_catches_up(attacker_share, confirmations, max_steps=1000):
    """
    攻撃者が confirmations ブロック分だけ遅れている状態から、
    正直なチェーンに追いつけるかを簡単にシミュレーションします。

    attacker_share:
        攻撃者側が次のブロックを見つける確率のイメージです。
        0.3 なら、攻撃者が全体の30%程度の計算能力を持つようなイメージです。

    confirmations:
        正直なチェーンが何ブロック先行しているかを表します。
        承認数が増えるほど、攻撃者はより大きな差を追いかける必要があります。

    max_steps:
        いつまでもループしないようにするための上限です。
    """
    # gap は「正直なチェーンが攻撃者チェーンより何ブロック先行しているか」です。
    gap = confirmations

    for _ in range(max_steps):
        # 攻撃者が次のブロックを見つけた場合、差が1つ縮まります。
        if random.random() < attacker_share:
            gap -= 1
        else:
            # 正直な参加者側が次のブロックを見つけた場合、差が1つ広がります。
            gap += 1

        # gap が0以下になったら、攻撃者が追いついたとみなします。
        if gap <= 0:
            return True

    # 上限回数までに追いつけなかった場合は、失敗とみなします。
    return False


def estimate_success_rate(attacker_share, confirmations, trials=5000):
    """同じ条件で何度も試し、攻撃者が追いついた割合を数えます。"""
    success_count = 0

    for _ in range(trials):
        if attacker_catches_up(attacker_share, confirmations):
            success_count += 1

    return success_count / trials


# 再現しやすいように乱数の種を固定します。
random.seed(42)

# 攻撃者の計算能力の割合と承認数を変えて、追いつける割合の変化を見ます。
for attacker_share in [0.1, 0.3, 0.45]:
    print(f"攻撃者の計算能力の割合: {attacker_share:.0%}")

    for confirmations in [1, 3, 6]:
        rate = estimate_success_rate(attacker_share, confirmations)
        print(f"  承認数 {confirmations}: 追いつけた割合 {rate:.3f}")

    print()

このシミュレーションでは、攻撃者の計算能力が小さいほど、また承認数が増えるほど、追いつける割合が下がりやすくなります。

もちろん、実際のBitcoinの分析では、ホワイトペーパーで示されているような確率モデルや、現在のネットワーク状況、マイニングの分布などを考える必要があります。
このコードは、あくまで直感をつかむためのものです。

4.8 PoWは「正直に参加した方が得」になるようにも設計される

PoWでは、計算作業のコストだけでなく、報酬の設計 も重要です。

Bitcoinのホワイトペーパーでは、ブロックの最初の取引として新しいコインをブロック作成者に与える仕組みが、ノードにネットワークを支えるインセンティブを与えると説明されています。
また、取引手数料もブロック作成者へのインセンティブになり得ると説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

これは、身近な例でいうと、共同作業の当番に報酬を用意するようなものです。

行動	結果
正しくブロックを作る	ブロック報酬や手数料を得られる
無効なブロックを作る	他のノードに拒否され、作業が無駄になる
攻撃を試みる	大きな計算コストや機会損失を負う可能性がある

ここでいう機会損失とは、「攻撃に計算資源を使うくらいなら、正しくマイニングして報酬を得た方がよかった」という損失です。

つまりPoWでは、単に罰を与えるだけでなく、正直に参加する方が合理的になりやすいような設計も関係します。

ただし、このインセンティブ設計が常に完璧に働くとは限りません。
暗号資産の価格、マイニング設備、電力コスト、マイニングプールの構造、攻撃者の目的などによって、現実のリスクは変わります。

4.9 マイニングプール集中という注意点

PoWでは、計算能力を多く持つほどブロックを見つけやすくなります。

しかし、個人でマイニングしても、なかなかブロックを見つけられない場合があります。
そこで、多くのマイナーが計算能力を持ち寄り、報酬を分配する マイニングプール が使われることがあります。

マイニングプールは、参加者にとって報酬を安定させる効果があります。
一方で、マイニングプールに計算能力が集中しすぎると、ネットワークの分散性という観点で注意が必要になります。

ここで注意したいのは、マイニングプールに参加しているマイナーと、プール運営者の役割が完全に同じではないことです。
プールの設計によっては、どの取引をブロックに入れるか、どのブロックテンプレートを使うかなどに、プール側の影響が出る場合があります。

そのため、PoWを理解するときは、単に「世界中にマイナーがいるから分散している」と見るだけでなく、計算能力がどのように分布しているか も見る必要があります。

💡 豆知識
miner という言葉は、金を掘る「鉱夫」に由来するイメージで使われます。
ただし、実際に掘っているのは地面ではなく、条件に合うハッシュです。
報酬を得るために計算資源を使う点が、金鉱を掘る作業にたとえられています。

4.10 エネルギー消費はPoWの大きな論点

PoWでは、ネットワークの安全性を支えるために、多くの計算作業が行われます。
そのため、エネルギー消費は大きな論点になります。

Ethereum公式ドキュメントでは、PoWの大きな批判として、ネットワークを安全に保つために必要なエネルギー量が挙げられています。
また、EthereumがPoSへ移行する直前、Ethereumのマイナーは年間約70TWhを消費していたと説明されています。

参考: Ethereum Documentation: Proof-of-work

この話は、PoWを考えるうえで避けて通れません。

PoWでは、計算作業が攻撃コストを高める役割を持ちます。
しかし、その計算作業は現実の電力消費や設備投資を伴います。

観点	PoWでの見方
セキュリティ	攻撃するには大きな計算能力が必要になる
コスト	電力、設備、冷却、運用費が必要になる
分散性	誰でも参加できる設計を目指せるが、設備や電力コストで集中が起こり得る
環境面	エネルギー消費が批判されることがある

ここで、単に「PoWは悪い」と言い切るのは少し雑です。

PoWの計算作業は、ネットワークの不正抑止に関係しています。
一方で、その安全性のためにどれだけのエネルギーを使うべきか、どのような電源構成なのか、社会的にどう評価するのかは、技術だけではなく経済・環境・政策の議論にも関わります。

本記事では、次のように整理します。

PoWは、計算作業を現実のコストとして使うことで不正を抑止します。
その一方で、計算作業には電力消費や設備集中といった課題もあります。

4.11 PoWで防げること・防げないこと

ここまで見てきたように、PoWは不正をしにくくする強力な仕組みです。

ただし、PoWがあればブロックチェーンに関するすべての問題が解決するわけではありません。

観点	PoWが役立つこと	PoWだけでは防ぎにくいこと
二重支払い	履歴を一本化し、同じ資金を2回使いにくくする	確認前の取引を信用しすぎるリスク
過去の改ざん	後続ブロック分の作業やり直しを必要にする	計算能力が極端に集中した場合の攻撃
偽参加者対策	影響力を持つには計算資源が必要になる	マイニングプールや設備集中の問題
無効な取引	フルノードの検証により拒否される	ウォレットの秘密鍵漏えい、詐欺、取引所リスク
分散性	誰でも参加できる設計を目指せる	実際の参加には機材・電力・知識が必要になる

特に、PoWは秘密鍵の漏えいやフィッシング詐欺を防ぐ仕組みではありません。
ブロックチェーンの履歴を守る仕組みと、利用者のウォレットを守る仕組みは別です。

また、スマートコントラクトのバグや取引所の内部管理リスクも、PoWだけで解決できるものではありません。

この点は、情報セキュリティの観点でとても大切です。

ブロックチェーンの安全性は、PoWやPoSのような合意形成に関わる仕組みだけでなく、ウォレット、秘密鍵管理、スマートコントラクト、取引所、ブリッジ、ユーザー教育など、多くの層によって支えられています。

4.12 この章のまとめ

この章では、PoWがどのように不正を抑止するのかを整理しました。

PoWは、条件に合うハッシュを探す計算作業を必要にすることで、ブロック作成にコストを持たせます。
そのため、不正な履歴を作ろうとする人は、正直な参加者たちよりも多くの作業を行い、過去のブロックと後続ブロックをまとめて作り直す必要があります。

この章で押さえたいポイントは、次の通りです。

ポイント	説明
二重支払いは同じ資金を2回使おうとする問題	ブロックチェーンでは、どちらの取引が正しい履歴に入ったかをそろえる必要がある
PoWは過去の書き換えコストを高める	古いブロックを書き換えるほど、後続ブロックも作り直す必要がある
承認数が増えるほど覆しにくくなる	後ろにブロックが積み重なるほど、攻撃者が追いつくための作業が増える
51%攻撃は万能攻撃ではない	二重支払いや検閲などは問題になるが、無効な取引はノードに拒否される
報酬設計も重要	正しく参加した方が得になりやすいように、ブロック報酬や手数料がある
マイニング集中には注意が必要	マイニングプールや設備集中は分散性の論点になる
エネルギー消費は大きな課題	PoWの安全性を支える計算作業は、現実の電力消費を伴う

PoWは、計算資源を使って不正のコストを高める仕組みです。
ただし、その安全性は無料ではありません。
計算資源、電力、設備、マイニング参加者の分布といった現実のコストに支えられています。

次の章では、別の考え方で不正を抑止するProof of Stakeを見ていきます。

PoSでは、計算作業ではなく、預けた資産をコストとして使います。
PoWが「計算で責任を示す」仕組みに近いなら、PoSは「資産を預けて責任を持つ」仕組みに近いです。

5. Proof of Stakeとは何か

この章では、Proof of Stakeを「資産を預けて責任を持つ仕組み」として整理します。
ポイントは、PoWが計算作業をコストにするのに対して、PoSでは預けた資産や報酬・ペナルティを使って、正しく振る舞う動機を作ることです。

前の章では、Proof of Workがどのように不正を抑止するのかを見ました。

PoWでは、条件に合うハッシュを見つけるために、nonceを変えながら何度も計算を試します。
過去の履歴を書き換えようとすると、そのブロック以降の作業をやり直す必要があるため、不正には大きな計算コストがかかります。

では、同じように「不正を安く済ませられないようにする」ために、計算作業ではなく別のものをコストとして使うことはできないでしょうか。

ここで出てくるのが Proof of Stake です。

Proof of Stakeは、ざっくり言えば 資産を預けた参加者に、ブロックの提案や検証へ参加してもらう仕組み です。
正しく参加すれば報酬を得られる一方、不正や重大なルール違反をすると、預けた資産の一部を失う可能性があります。

身近な例でいうと、共同で管理する会計ノートの当番を決めるときに、当番が保証金を預けるようなイメージです。

観点	身近な例	PoSでのイメージ
参加するための条件	保証金を預けて会計係に参加する	資産をステークしてバリデータになる
正しく作業した場合	記録係として信頼され、報酬を得る	ブロック提案や検証で報酬を得る
ルール違反した場合	保証金の一部を失う	ペナルティやスラッシングを受ける場合がある
不正抑止の考え方	不正すると自分も損をする	預けた資産をリスクにさらすことで不正を抑える

もちろん、実際のPoSは会計ノートの当番よりずっと複雑です。
ただ、最初の理解としては、計算で責任を示すPoW に対して、資産を預けて責任を持つPoS と見ると分かりやすくなります。

Ethereum公式ドキュメントでは、Ethereumは2022年にProof of Stakeへ移行し、PoSは以前のProof of Work構成と比べて、より安全で、エネルギー消費が少なく、スケーリングの実装にも適していると説明されています。

参考: Ethereum Documentation: Proof-of-stake

ただし、この説明はEthereumの設計・実装を前提にしたものです。
PoSという名前が付いていても、チェーンによって細かい設計は異なります。
本記事では、代表例として現在のEthereumを中心に扱いながら、PoSの基本的な考え方を整理します。

5.1 まずは「保証金を預ける当番」から考える

まずは、研究室やサークルの会計ノートで考えてみます。

会計ノートには、誰が何にいくら使ったのか、いつ支払ったのか、残高がいくらなのかが記録されています。
この記録を全員で信じるには、記録係が勝手な内容を書き込まないことが大切です。

ここで、記録係を完全に1人へ固定すると、その人を強く信頼する必要があります。
一方で、誰でも自由に書き込めるようにすると、今度は間違いや不正な記録が増えるかもしれません。

そこで、次のようなルールを考えます。

1. 記録係になりたい人は、あらかじめ保証金を預ける
2. 毎回、保証金を預けた人の中から記録係を選ぶ
3. 正しく記録した人には、少し報酬を渡す
4. わざと不正な記録をした人は、保証金の一部を失う

このルールでは、記録係は「適当に書いても自分は損しない」という状態ではありません。
もし不正な記録をすると、自分が預けた保証金を失う可能性があります。

これが、PoSの基本的な考え方に近いです。

PoWでは、攻撃するには大量の計算資源が必要でした。
PoSでは、攻撃するには大きなステークを支配したり、預けた資産を失うリスクを負ったりする必要があります。

つまり、どちらも「不正をしようとする人にコストを負わせる」という点では共通しています。
違うのは、そのコストとして使うものです。

5.2 stake、staking、validatorを整理する

PoSでは、stake、staking、validator という言葉がよく出てきます。

用語	ざっくりした意味	身近なイメージ
stake	預ける資産、またはその持ち分	保証金、参加するための担保
staking	資産を預けてネットワークの検証に参加すること	保証金を預けて当番に参加すること
validator	ブロックの提案や検証に参加する主体	共有ノートの記録係・確認係
block proposal	ブロック候補を提案すること	次の記録案を書くこと
attestation	提案されたブロックに対して投票・証言すること	「この記録案は妥当だと思う」と確認すること
slashing	重大なルール違反時にステークを失う仕組み	不正をした記録係の保証金が没収されること

Ethereum公式のstakingページでは、stakingは32 ETHを預けてバリデータソフトウェアを有効化する行為であり、バリデータはデータの保存、取引処理、新しいブロックの追加に責任を持つと説明されています。

参考: Ethereum Staking

ここで注意したいのは、staking = 必ず楽に増える投資方法 と考えないことです。

本記事で扱うstakingは、投資判断や利回りの話ではありません。
あくまで、PoSネットワークの安全性を支えるために、資産を預けて検証へ参加する仕組みとして扱います。

また、Ethereumではバリデータを自分で起動するには、少なくとも32 ETHが必要と説明されています。
ただし、ステーキングの方法には、自分で運用する方法、サービスを使う方法、プールを使う方法など複数の選択肢があり、それぞれリスクや信頼前提が異なります。

参考: Ethereum Staking: comparison of staking options

本記事では、特定のステーキング方法やサービスを推奨しません。
PoSの仕組みを理解するために、Ethereumのバリデータを代表例として扱います。

💡 豆知識
stake は「賭け金」「利害関係」「持ち分」のような意味を持つ言葉です。
PoSでは、参加者が自分の資産をネットワークに預けることで、「自分もこの記録の正しさに利害関係を持っている」と示すイメージになります。
ただし、実際のPoSは単なる多数決ではなく、選出、投票、報酬、ペナルティ、フォーク選択などが組み合わさっています。

5.3 PoSは「資産を多く持つ人が毎回決める」だけではない

PoSを初めて聞くと、次のように感じるかもしれません。

資産を多く持っている人が、全部好きなように決められる仕組みなの？

これは半分だけ近く、半分は雑な理解です。

PoSでは、ステーク量が大きいほど、ブロック提案や検証で選ばれる確率・影響力が大きくなる設計がよくあります。
その意味では、ステーク量は重要です。

しかし、PoSは単に「一番お金持ちの人が毎回ブロックを作る」だけの仕組みではありません。
実際には、バリデータの選出、投票、報酬・ペナルティ、フォーク選択、スラッシングなどが組み合わさっています。

とても単純化すると、次のような違いがあります。

雑な理解	より正確な理解
資産が多い人が必ず決める	ステーク量が選出確率や影響力に関係する設計が多い
PoSはただの多数決	バリデータ選出、投票、フォーク選択、報酬・ペナルティが関係する
不正しても資産を持っていれば勝てる	不正行動にはスラッシングやペナルティが設計される場合がある
PoSなら電力を使わないので完全に安全	エネルギー消費は抑えやすいが、ステーク集中や実装リスクなどは残る

このあたりは、次章以降でより詳しく見ます。
この章ではまず、PoSの入口として「資産を預けて責任を持つ」という考え方を押さえます。

5.4 小さなコードで見る：ステーク量に応じて選ばれやすくする

ここで、PoSの雰囲気をつかむために、かなり単純化したコードを書いてみます。

次のコードは、実際のEthereumのバリデータ選出アルゴリズムではありません。
本物のEthereumでは、乱数、slot、epoch、validator set、フォーク選択など、もっと多くの仕組みが関係します。

ここでは、ステーク量が大きいほど選ばれやすくなる という感覚だけを学ぶためのモデルです。

# PoSの「ステーク量が選ばれやすさに関係する」イメージを理解するための学習用コードです。
# 実際のEthereumや他チェーンのバリデータ選出アルゴリズムではありません。

import random
from collections import Counter

# 架空のバリデータ一覧です。
# stake は、それぞれのバリデータが預けている資産量のイメージです。
validators = [
    {"name": "validator_A", "stake": 10},
    {"name": "validator_B", "stake": 30},
    {"name": "validator_C", "stake": 60},
]


def choose_validator(validators):
    """
    ステーク量を重みとして、バリデータを1人選ぶ関数です。

    注意:
    - これは学習用の単純な重み付き抽選です。
    - 実際のPoSでは、乱数の作り方、選出タイミング、投票、フォーク選択などが関係します。
    """
    names = [validator["name"] for validator in validators]
    weights = [validator["stake"] for validator in validators]

    # random.choices は、weights に指定した重みに応じて要素を選びます。
    selected = random.choices(names, weights=weights, k=1)[0]
    return selected


# 1回だけだと偶然の影響が大きいため、1000回試して選ばれた回数を数えます。
results = Counter()

for _ in range(1000):
    selected = choose_validator(validators)
    results[selected] += 1

print("選ばれた回数:")
for name, count in results.items():
    print(f"{name}: {count}回")

このコードでは、validator_C のステーク量が一番大きいため、1000回試すと多く選ばれやすくなります。
ただし、毎回必ず validator_C が選ばれるわけではありません。

ここで伝えたいのは、PoSでは ステーク量が影響力に関係する ということです。
ただし、実際のPoSはこのコードよりはるかに複雑で、単純な重み付き抽選だけで説明できるものではありません。

5.5 Ethereumではslotとepochという時間の区切りがある

EthereumのPoSでは、時間を細かく区切って処理を進めます。

Ethereum公式ドキュメントでは、Ethereumの時間は slot と epoch に分かれており、1 slotは12秒、1 epochは32 slotで構成されると説明されています。
各slotでは、1人のバリデータがランダムに選ばれてブロック提案者になります。

参考: Ethereum Documentation: Proof-of-stake

身近な例でいうと、会議の議事録係を時間ごとに決めるようなものです。

12秒ごとに「今回の記録案を書く人」が選ばれる
32回分のslotをまとめて、1つのepochとして扱う

かなり単純化して図にすると、次のようになります。

ここで重要なのは、ブロック提案者だけでなく、他のバリデータも検証に関わることです。
Ethereumでは、選ばれた提案者がブロックを提案し、他のバリデータがそのブロックについてattestationを行います。

attestationは、ざっくり言うと「このブロックは正しい履歴として扱ってよいと考えます」と証言・投票する行為です。

役割	Ethereum PoSでのイメージ	身近な例
block proposer	ブロック候補を提案する	議事録の案を書く人
attester	提案されたブロックに投票・証言する	議事録案を確認する人
validator	提案や投票に参加する主体	記録係・確認係のメンバー

このように、PoSでは「1人が勝手に記録を書く」というより、提案と確認が組み合わさって進みます。

5.6 小さなコードで見る：slotごとに提案者を選ぶ

次のコードは、slotごとにバリデータを選ぶ様子を単純化して表したものです。

これも、実際のEthereumの実装ではありません。
PoSでは時間が区切られ、各slotで提案者が選ばれる、という流れをイメージするための学習用コードです。

# slotごとにブロック提案者が選ばれるイメージを理解するための学習用コードです。
# 実際のEthereumの選出処理ではありません。

import random

validators = [
    {"name": "validator_A", "stake": 32},
    {"name": "validator_B", "stake": 32},
    {"name": "validator_C", "stake": 64},
]


def choose_proposer(validators):
    """
    ステーク量を重みとして、slotの提案者を1人選びます。
    ここでは説明のために、単純な重み付き抽選にしています。
    """
    names = [v["name"] for v in validators]
    weights = [v["stake"] for v in validators]
    return random.choices(names, weights=weights, k=1)[0]


# 8 slot分だけ、誰がブロック提案者になったかを表示します。
# Ethereumの1 epochは32 slotですが、ここでは見やすさのため8 slotにしています。
for slot in range(1, 9):
    proposer = choose_proposer(validators)
    print(f"slot {slot}: {proposer} がブロック提案者")

このコードでは、slotごとに提案者が選ばれます。
ステーク量が多い validator_C は選ばれやすくなりますが、毎回必ず選ばれるとは限りません。

実際のEthereumでは、乱数の扱いやバリデータ集合、attestation、fork choiceなどが組み合わさります。
そのため、このコードはあくまで「slotごとに提案者が決まる」という雰囲気をつかむためのものです。

5.7 報酬とペナルティで正しい参加を促す

PoSでは、バリデータが正しく参加するように、報酬とペナルティが設計されます。

Ethereum公式ドキュメントでは、バリデータは正しい投票、ブロック提案、sync committeeへの参加などによって報酬を得る一方、期待される行動をしない場合にはペナルティを受けると説明されています。
また、同じslotに複数のブロックを提案する、矛盾するattestationを行うなど、特に悪質な行動はslashingの対象になります。

参考: Ethereum Documentation: Proof-of-stake rewards and penalties

これも、会計ノートの例に戻すと分かりやすいです。

行動	身近な例	PoSでのイメージ
正しく記録する	会計ノートへ正しい支出を書く	正しいブロックを提案する
正しく確認する	記録案に間違いがないか確認する	正しいattestationを行う
作業をさぼる	確認担当なのに確認しない	オフラインや不参加でペナルティを受ける場合がある
矛盾した記録を出す	同じ時間に別々の議事録を出す	slashable behaviorになる場合がある

PoSでは、参加者に「正しく参加した方が得」「不正をすると損」という状況を作ることが重要です。

ここで注意したいのは、スラッシングは「少しミスしたら必ず全額没収」という単純な仕組みではないことです。
どのような行動が対象になるか、どの程度のペナルティになるかは、プロトコルの設計に依存します。

Ethereumでは、スラッシングの対象になる行動が明確に定義されており、ペナルティの仕組みも設計されています。
このあたりの不正抑止の詳しい話は、次章で扱います。

5.8 PoSは「電力をまったく使わない」わけではない

PoSは、PoWと比べてエネルギー消費を大きく抑えやすい仕組みです。

EthereumのThe Mergeページでは、The Mergeが2022年9月15日に実行され、EthereumのPoWからPoSへの移行が完了し、エネルギー消費が約99.95%削減されたと説明されています。

参考: Ethereum Roadmap: The Merge

ただし、ここで「PoSは電力をまったく使わない」と言うのは正確ではありません。

PoSでも、バリデータはノードを動かします。
サーバー、ネットワーク、ストレージ、監視、アップデートなど、運用には電力や管理コストが必要です。

違いは、PoWのように大量のハッシュ計算で競争し続ける必要がないことです。

観点	PoW	PoS
主なコスト	計算資源、電力、設備	預けた資産、運用、ペナルティリスク
ブロック作成者の選び方	計算競争で条件に合うハッシュを探す	ステークしたバリデータから選出される
エネルギー消費	大きくなりやすい	PoWより抑えやすい
注意点	マイニング集中、電力消費	ステーク集中、バリデータ運用、スラッシング

そのため、記事内では次のように表現するのが安全です。

PoSはPoWと比べて、ブロック作成のために大量の計算競争を行う必要がないため、エネルギー消費を大きく抑えやすい仕組みです。
ただし、ノード運用やネットワーク維持のためのコストがゼロになるわけではありません。

5.9 The Merge：EthereumはPoWからPoSへ移行した

PoSを理解するときに、Ethereumの The Merge は重要な出来事です。

EthereumはもともとPoWを使っていました。
しかし、2022年9月15日にThe Mergeが実行され、PoWによるブロック生成は廃止され、PoSへ移行しました。

Ethereum公式のThe Mergeページでは、この移行によってEthereumのProof of Stakeへの移行が完了し、Proof of Workが正式に廃止されたと説明されています。

参考: Ethereum Roadmap: The Merge

ここで注意したいのは、The Mergeを「Ethereumのすべての問題を一気に解決したアップデート」と捉えないことです。

The Mergeは、主にコンセンサス方式をPoWからPoSへ移行する大きなアップデートでした。
ガス代を直接下げるためのアップデートではありません。
また、PoSになったからといって、スマートコントラクトのバグやウォレットの秘密鍵管理リスクがなくなるわけでもありません。

観点	The Mergeで変わったこと	The Mergeだけでは直接解決しないこと
コンセンサス	PoWからPoSへ移行	すべてのアプリの安全性
ブロック作成	マイナーではなくバリデータが中心	ユーザーの秘密鍵管理
エネルギー消費	大きく削減	すべての手数料問題
セキュリティ設計	ステーク、報酬、ペナルティが重要に	スマートコントラクトの脆弱性

このように、The MergeはEthereumの歴史上とても大きな変更ですが、ブロックチェーン全体の安全性を考えるには、PoS以外の層も見る必要があります。

💡 豆知識
The Mergeは、Ethereumの「実行レイヤー」と、PoSを担う「コンセンサスレイヤー」が合流したアップデートとして説明されます。
名前の通り、2つの流れが合流したようなイメージです。
ただし、利用者目線では「急に別のコインになった」というより、裏側の合意形成の仕組みがPoWからPoSへ切り替わった、と捉えると分かりやすいです。

5.10 PoSで防ごうとしていること

PoSが目指しているのは、単に「電力消費を減らすこと」だけではありません。

PoSでも、PoWと同じように、ブロックチェーンの記録を安全に保つ必要があります。
そのためには、次のような問題に向き合う必要があります。

問題	PoSでの考え方
偽の参加者を大量に作る攻撃	参加にはステークが必要なため、影響力を持つには資産コストが必要になる
不正なブロック提案	他のバリデータによる検証や投票で拒否される
矛盾した投票や提案	スラッシングの対象になる場合がある
オフラインや不参加	報酬を得られない、またはペナルティを受ける場合がある
ステーク集中	大きなステークを持つ主体の影響が強くなりすぎる可能性がある

PoSでは、計算作業の代わりに、預けた資産を使って攻撃コストを作ります。
つまり、ネットワークを攻撃しようとする人は、大きなステークを集める必要があり、不正が検出されると、そのステークを失うリスクを負います。

この点で、PoSはPoWとは違う形で「不正を高くつくものにする」仕組みです。

5.11 小さなコードで見る：報酬とペナルティのイメージ

次に、PoSの報酬とペナルティをとても単純化したコードで見てみます。

このコードは、実際のEthereumの報酬計算ではありません。
Ethereumの報酬・ペナルティは、参加状況、全体のステーク量、役割、タイミング、スラッシング条件などにより変わります。

ここでは、正しく参加すると少し増え、参加しないと少し減り、重大な違反では大きく減る、という考え方だけを確認します。

# PoSにおける報酬・ペナルティの考え方を理解するための学習用コードです。
# 実際のEthereumの報酬計算やスラッシング処理ではありません。

validators = {
    "validator_A": {"stake": 32.0, "status": "honest"},
    "validator_B": {"stake": 32.0, "status": "offline"},
    "validator_C": {"stake": 32.0, "status": "double_vote"},
}


def apply_reward_or_penalty(validator):
    """
    バリデータの行動に応じて、ステーク量を増減させる簡易関数です。

    honest:
        正しく参加した想定。小さな報酬を加えます。
    offline:
        参加しなかった想定。小さなペナルティを引きます。
    double_vote:
        矛盾する投票をした想定。重大な違反として大きめに減らします。

    注意:
    - 数値は説明用に適当に置いています。
    - 実際のプロトコルでは、もっと複雑な計算と条件があります。
    """
    status = validator["status"]

    if status == "honest":
        validator["stake"] += 0.05
    elif status == "offline":
        validator["stake"] -= 0.02
    elif status == "double_vote":
        validator["stake"] -= 1.00


for name, validator in validators.items():
    before = validator["stake"]
    apply_reward_or_penalty(validator)
    after = validator["stake"]

    print(f"{name}: {before:.2f} ETH -> {after:.2f} ETH ({validator['status']})")

このコードでは、正直に参加した validator_A は少し増えます。
オフラインだった validator_B は少し減ります。
矛盾した投票をした validator_C は大きめに減ります。

実際のPoSでは、このような単純な3分類だけではありません。
しかし、PoSの考え方として、報酬とペナルティによって正しい参加を促す という点は重要です。

5.12 PoSを理解するときの注意点

PoSは、PoWの課題をすべて消す魔法の仕組みではありません。

PoWでは、計算資源や電力消費、マイニング集中が大きな論点でした。
一方で、PoSでは別の注意点が出てきます。

注意点	説明
ステーク集中	大きなステークを持つ主体やサービスに影響力が集中する可能性がある
バリデータ運用	ノードを安定して動かす必要がある
スラッシングリスク	誤設定や二重署名などでステークを失う可能性がある
クライアント集中	同じ実装に依存しすぎると、バグの影響が広がりやすい
サービス依存	ステーキングサービスやプールに頼ると、信頼前提が変わる
弱主観性	新規参加ノードや長期間オフラインだったノードが、信頼できる最近の状態を必要とする場合がある

これらは、6章でより詳しく扱います。

ここではまず、PoSを次のように理解しておけば十分です。

PoSは、資産を預けたバリデータがブロック提案や検証に参加し、正しく参加すれば報酬を得て、不正や重大な違反をするとペナルティを受ける仕組みです。
PoWが計算作業を不正抑止のコストにするのに対して、PoSは預けた資産を不正抑止のコストにします。

5.13 この章のまとめ

この章では、Proof of Stakeの基本的な考え方を整理しました。

PoSは、計算競争によってブロック作成者を決めるPoWとは異なり、資産を預けたバリデータがブロック提案や検証に参加する仕組みです。
正しく参加すると報酬を得られ、不正や重大なルール違反をするとペナルティやスラッシングを受ける場合があります。

この章で押さえたいポイントは、次の通りです。

ポイント	説明
PoSは資産を預けて責任を持つ仕組み	計算作業ではなく、ステークした資産を不正抑止のコストにする
バリデータが重要な役割を持つ	ブロック提案やattestationに参加する
Ethereumでは32 ETHが代表的な基準	自分でバリデータを起動するには少なくとも32 ETHが必要と説明されている
slotとepochで処理が進む	Ethereumでは12秒のslot、32 slotのepochという時間区切りがある
報酬とペナルティがある	正しく参加すれば報酬、不参加や違反にはペナルティがある
The MergeでEthereumはPoSへ移行した	2022年9月15日にPoWからPoSへの移行が完了した
PoSにも注意点がある	ステーク集中、運用ミス、スラッシング、クライアント集中などが論点になる

PoSを一言でまとめるなら、資産を預けることで、ネットワークの記録に責任を持って参加する仕組み です。

ただし、資産を預けるだけで安全になるわけではありません。
誰がどれだけステークしているのか、不正をどう検出するのか、どのようなペナルティがあるのか、バリデータが集中しすぎていないかなど、多くの要素が関係します。

次の章では、PoSがどのように不正を抑止するのかを、もう少し詳しく見ていきます。
特に、スラッシング、ステーク集中、攻撃に必要なステーク量、弱主観性など、PoS特有の注意点を整理します。

6. PoSではどのように不正を抑止するのか

この章では、Proof of Stakeで不正をしにくくする仕組みを整理します。
ポイントは、PoSが「預けた資産を失うかもしれない」というリスクを使って、正しく参加する動機を作っていることです。

前の章では、Proof of Stakeを 資産を預けて責任を持つ仕組み として整理しました。

PoWでは、マイナーが計算資源や電力を使って、条件に合うハッシュを探しました。
つまり、不正な履歴を作ろうとすると、大量の計算作業をやり直す必要がありました。

一方でPoSでは、計算競争そのものではなく、バリデータが預けた資産をもとにブロック提案や検証に参加します。
そのため、不正を抑止する考え方も少し変わります。

PoSでは、ざっくり言うと次のような設計になります。

観点	PoW	PoS
不正をしにくくする主なコスト	計算資源、電力、設備投資	ステークした資産、報酬、ペナルティ
不正時に失う可能性があるもの	計算に使ったコスト、報酬機会	ステークした資産の一部、報酬、バリデータ資格
正しく参加する動機	ブロック報酬・手数料を得たい	報酬を得たい、ステークを失いたくない
攻撃に必要な力	ハッシュレートの大きな割合	ステーク量の大きな割合

身近な例で言えば、PoSは「保証金を預けて共同管理に参加する」イメージに近いです。

たとえば、サークルの会計ノートを複数人で管理するとします。
管理担当者になる人は、あらかじめ保証金を預けるルールになっていると考えてみてください。

正しく記録を確認し、決められたタイミングで作業すれば、少し報酬をもらえます。
逆に、わざと二重の記録を出したり、明らかに矛盾した承認をしたりすると、保証金の一部を失います。

これが、PoSにおける不正抑止の入口です。

Ethereum公式ドキュメントでも、EthereumではETHをdeposit contractに預けたノード運用者がバリデータソフトウェアを動かし、新しいブロックの妥当性確認やfork-choice algorithmによるチェーン先頭の識別に参加すると説明されています。
また、バリデータには、新しいブロックを確認してattestationを行う役割と、選ばれたときに新しいブロックを提案する役割があると説明されています。

参考: Ethereum.org: Proof-of-stake rewards and penalties

ここからは、PoSがどのように不正を抑止しているのかを、順番に見ていきます。

6.1 PoSの基本は「報酬」と「ペナルティ」

PoSでは、バリデータに対して、正しく参加するほど得をし、間違った行動や不正をすると損をするような仕組みを作ります。

かなり単純化すると、次のようなイメージです。

バリデータの行動	起こり得る結果	ざっくりした意味
正しいブロックに投票する	報酬を得る	ネットワークに協力したためプラス
選ばれたslotでブロックを提案する	報酬を得る	ブロック作成に貢献したためプラス
投票しない・遅れる	報酬を逃す、またはペナルティ	役割を果たせなかったためマイナス
矛盾する投票をする	slashing対象になる場合がある	明確に危険な行動として重い罰
同じslotに複数ブロックを提案する	slashing対象になる場合がある	履歴を分裂させる危険な行動

Ethereum公式ドキュメントでは、バリデータは多数派と整合する投票、ブロック提案、sync committeeへの参加などで報酬を得ると説明されています。
一方で、同じslotに複数ブロックを提案する、同じslotに複数の候補へattestationするなどの行動はslashable behaviorとして扱われます。

参考: Ethereum.org: Proof-of-stake rewards and penalties

ここで大切なのは、PoSが単に「資産を持っている人に任せる仕組み」ではないことです。

資産を預けることで、参加者はネットワークの状態に責任を持つことになります。
正しく参加すれば報酬がありますが、不正や重大なミスには損失があります。

つまり、PoSでは次のような方向にインセンティブを作ります。

この図のように、PoSの不正抑止は「ルールを破ったら資産にダメージがある」という設計に支えられています。

6.2 小さなコードで見る：報酬とペナルティの基本

ここでは、バリデータの行動によって残高がどう変わるかを、かなり単純化したPythonコードで見てみます。

このコードは、実際のEthereumの報酬計算ではありません。
Ethereumの実際の報酬・ペナルティは、base reward、attestationの種類、inclusion delay、sync committee、提案者報酬など、さまざまな要素で計算されます。

ここでは、正しく参加すると少し増え、不参加や違反では減る という考え方だけを確認します。

# PoSにおける報酬とペナルティの考え方を理解するための学習用コードです。
# 実際のEthereumの報酬計算式ではありません。

validators = {
    "Validator_A": {"stake": 32.0, "status": "honest"},
    "Validator_B": {"stake": 32.0, "status": "offline"},
    "Validator_C": {"stake": 32.0, "status": "equivocating"},
}

# 説明用の固定値です。
# 現実の報酬やペナルティは、ネットワーク状態や仕様によって変わります。
REWARD = 0.03
OFFLINE_PENALTY = 0.02
SLASHING_PENALTY = 1.00


def apply_epoch_result(validator):
    """
    1 epoch分の行動結果を、説明用にstakeへ反映します。

    honest:
        正しく参加した想定です。少し報酬を得ます。
    offline:
        参加できなかった想定です。少しペナルティを受けます。
    equivocating:
        矛盾する行動をした想定です。重いペナルティを受けます。
    """
    status = validator["status"]

    if status == "honest":
        validator["stake"] += REWARD
        return "正しく参加したため、報酬を得ました。"

    if status == "offline":
        validator["stake"] -= OFFLINE_PENALTY
        return "参加できなかったため、ペナルティを受けました。"

    if status == "equivocating":
        validator["stake"] -= SLASHING_PENALTY
        return "矛盾する行動をしたため、重いペナルティを受けました。"

    return "状態が不明なため、変化なし。"


for name, validator in validators.items():
    before = validator["stake"]
    message = apply_epoch_result(validator)
    after = validator["stake"]

    print(name)
    print("  処理結果:", message)
    print(f"  stake: {before:.2f} -> {after:.2f}")

このコードでは、3人のバリデータを用意しています。

Validator_A は正しく参加する
Validator_B はオフラインになる
Validator_C は矛盾する行動をする

結果を見ると、正しく参加したバリデータはstakeが少し増え、オフラインのバリデータは少し減り、矛盾する行動をしたバリデータは大きく減ります。

もちろん、これは説明用の単純化です。
ただ、PoSの考え方としては、次の点が見えてきます。

PoSでは、正しく参加するほど得をし、ネットワークに害を与える行動をすると損をするように設計されます。

6.3 slashingは「重大な違反」に対する強いペナルティ

PoSを理解するときに重要なのが、slashing です。

slashingは、バリデータが重大なルール違反をした場合に、預けた資産の一部を失い、ネットワークから退出させられる仕組みです。
日本語では「罰金」や「没収」に近いニュアンスで説明されることがあります。

身近な例で考えると、保証金を預けて会計ノートの管理担当になる場面に似ています。

正しく管理しているうちは問題ありません。
しかし、同じ日付に2つの違う会計記録を出したり、都合のよい履歴にすり替えようとしたりした場合、保証金の一部を没収されるようなイメージです。

Ethereum公式ドキュメントでは、slashingはバリデータをネットワークから強制的に退出させ、ステークしたETHの損失を伴う重い処置だと説明されています。
また、代表的なslashable behaviorとして、同じslotに2つの異なるブロックを提案すること、履歴を変えるようなattestation、同じブロックに対して二重投票することが挙げられています。

参考: Ethereum.org: Proof-of-stake rewards and penalties

整理すると、次のようになります。

行動	なぜ問題か	PoSでの扱い
同じslotに複数のブロックを提案する	どちらの履歴が正しいか分裂しやすい	slashing対象になり得る
同じ対象に対して矛盾する投票をする	合意形成を壊す可能性がある	slashing対象になり得る
履歴を書き換えるような投票をする	過去の確定性を弱める	slashing対象になり得る
単にオフラインになる	役割を果たせないが、悪意とは限らない	通常はより軽いペナルティ

ここで大切なのは、すべての失敗が同じ重さで罰せられるわけではないことです。

ネットワーク障害や設定ミスで一時的にオフラインになることと、矛盾する署名を出して履歴を壊そうとすることは、危険度が違います。
PoSでは、この違いに応じて、報酬を逃す、軽いペナルティを受ける、slashingされる、といった段階があります。

💡 豆知識
slashingは「うっかりミスを何でも重く罰する仕組み」というより、同じslotに複数ブロックを提案する、二重投票するなど、ネットワークの履歴を壊し得る行動を強く抑止する仕組みです。
ただし、バリデータの鍵管理や冗長化設定を間違えると、意図せずslashable behaviorを起こすリスクもあるため、運用面では注意が必要です。

6.4 小さなコードで見る：二重投票を検出する

ここでは、slashing対象になり得る「二重投票」のイメージを、学習用コードで見てみます。

実際のEthereumのattestationやslashing条件はもっと複雑です。
このコードは、同じバリデータが同じslotで異なる候補に投票したら危険 という考え方を理解するための簡易モデルです。

# 二重投票を検出する考え方を理解するための学習用コードです。
# 実際のEthereumのslashing検出ロジックではありません。

attestations = [
    {"validator": "Validator_A", "slot": 100, "block": "Block_X"},
    {"validator": "Validator_B", "slot": 100, "block": "Block_X"},
    {"validator": "Validator_C", "slot": 100, "block": "Block_Y"},
    {"validator": "Validator_C", "slot": 100, "block": "Block_Z"},  # 同じslotで別ブロックに投票
    {"validator": "Validator_A", "slot": 101, "block": "Block_M"},
]


def detect_double_votes(attestations):
    """
    同じvalidatorが同じslotで異なるblockに投票していないかを確認します。

    key:
        validator名とslotの組み合わせです。
    seen:
        すでに確認した投票先を記録します。
    double_votes:
        二重投票の疑いがあるものを保存します。
    """
    seen = {}
    double_votes = []

    for attestation in attestations:
        key = (attestation["validator"], attestation["slot"])
        voted_block = attestation["block"]

        # 初めて見るvalidator/slotの組み合わせなら、投票先を記録します。
        if key not in seen:
            seen[key] = voted_block
            continue

        # すでに同じvalidator/slotで別のblockに投票していたら、二重投票として記録します。
        if seen[key] != voted_block:
            double_votes.append({
                "validator": attestation["validator"],
                "slot": attestation["slot"],
                "first_vote": seen[key],
                "second_vote": voted_block,
            })

    return double_votes


for item in detect_double_votes(attestations):
    print("二重投票の疑い:")
    print(f"  validator: {item['validator']}")
    print(f"  slot: {item['slot']}")
    print(f"  first vote: {item['first_vote']}")
    print(f"  second vote: {item['second_vote']}")

このコードでは、Validator_C が同じslot 100 で Block_Y と Block_Z の両方に投票しています。

これは、共有ノートの例で言えば、同じ担当者が同じ時刻に「こっちが正しい記録です」と「いや、こっちが正しい記録です」を同時に出しているようなものです。
このような行動を許すと、どの履歴を正しいと見るべきかが分かりにくくなります。

そのため、PoSではこのような矛盾した行動を強く抑止します。

6.5 オフラインや不参加も問題になる

PoSでは、悪意ある行動だけでなく、バリデータが長時間オフラインになることも問題になります。

なぜなら、PoSではバリデータが投票し、ネットワーク全体として「この履歴でよい」と確認していくからです。
多くのバリデータが参加しなければ、十分な同意が集まりにくくなります。

Ethereum公式ドキュメントでは、consensus layerが4 epochを超えてfinalizeできない場合、inactivity leakという緊急プロトコルが有効になると説明されています。
また、1/3を超えるバリデータがオフライン、または正しいattestationを提出しない場合、2/3のsupermajorityを作れず、checkpointをfinalizeできなくなると説明されています。

参考: Ethereum.org: Proof-of-stake rewards and penalties

ここで出てくる finalize は、「十分な合意によって、後から覆りにくい状態になる」くらいに考えると分かりやすいです。
完全に未来永劫変更不能という意味ではありませんが、通常の運用では強い確定性を持つ状態です。

この図のように、PoSでは「何もしないこと」もネットワークに影響します。

もちろん、一時的なオフラインがすぐに重い不正扱いになるわけではありません。
ただし、多数のバリデータが長時間参加しない状態になると、ネットワークのfinalityに影響するため、ペナルティの仕組みが必要になります。

6.6 小さなコードで見る：inactivity leakのイメージ

inactivity leakは、PoSの中でも少し難しい概念です。

ここでは、非常に単純化したモデルで考えます。
目的は、非参加バリデータのステークが少しずつ減り、最終的に参加しているバリデータ側が2/3を超える状態を回復する という雰囲気をつかむことです。

実際のEthereumのinactivity leakの計算式ではありません。

# inactivity leakの考え方を理解するための学習用コードです。
# 実際のEthereumのペナルティ計算ではありません。

active_stake = 60.0
inactive_stake = 40.0

# 非参加バリデータのstakeを毎roundで少しずつ減らす説明用の値です。
# 現実のEthereumの計算式ではありません。
LEAK_RATE = 0.05


def active_ratio(active, inactive):
    """全体のstakeに対して、active側が占める割合を計算します。"""
    return active / (active + inactive)


round_number = 0

print("初期状態")
print(f"  active stake: {active_stake:.2f}")
print(f"  inactive stake: {inactive_stake:.2f}")
print(f"  active ratio: {active_ratio(active_stake, inactive_stake):.2%}")
print()

# active側が2/3を超えるまで、inactive側のstakeを少しずつ減らします。
# これはfinality回復のイメージを説明するための単純化です。
while active_ratio(active_stake, inactive_stake) < 2 / 3:
    round_number += 1

    # inactive側にペナルティがかかり、stakeが少し減ると考えます。
    inactive_stake *= (1 - LEAK_RATE)

    print(f"round {round_number}")
    print(f"  active stake: {active_stake:.2f}")
    print(f"  inactive stake: {inactive_stake:.2f}")
    print(f"  active ratio: {active_ratio(active_stake, inactive_stake):.2%}")
    print()

このコードでは、最初はactive側が60%、inactive側が40%です。
この状態では、active側だけでは2/3に届きません。

そこで、inactive側のstakeが少しずつ減ると、相対的にactive側の割合が上がっていきます。
やがてactive側が2/3を超えると、再びfinalityを回復できるイメージになります。

実際のEthereumでは、もっと厳密な条件と計算に基づきます。
ただし、考え方としては次のように押さえると分かりやすいです。

多くのバリデータが参加しないとfinalityが止まることがあります。
その場合、参加していない側の影響力を少しずつ下げることで、参加している側が再びfinalizeできる状態を目指します。

6.7 攻撃者が多くのステークを持つと何が起きるのか

PoSでは、攻撃者がどれだけのステークを持っているかが重要になります。

PoWでは「どれだけのハッシュレートを持っているか」が問題になりました。
PoSでは、それに対応するように「どれだけのステークを持っているか」が問題になります。

Ethereum公式ドキュメントでは、攻撃者が持つ総ステーク割合ごとに、起こり得る攻撃の影響が整理されています。
たとえば、33%以上ではfinalityを妨げられる可能性があり、34%ではdouble finalityの可能性、51%では検閲や将来のブロック内容の支配、66%以上では過去を含むより強い影響が説明されています。

参考: Ethereum.org: Proof-of-stake attack and defense

ざっくり整理すると、次のようになります。

攻撃者のステーク割合	Ethereum公式が説明する主な影響	初学者向けのイメージ
33%以上	finality delay	決定に必要な2/3同意を妨げやすくなる
34%程度	finality delay、double finality	2つの履歴がどちらも確定したように見える危険がある
51%程度	検閲、将来のブロック内容への強い影響	今後どの取引を入れるかに大きく影響できる
66%以上	過去を含む強い支配、finalized chainへの影響	自分の好む履歴をfinalizeできる危険がある

ただし、この表は「その割合を持てば何でも自由にできる」という意味ではありません。

攻撃者は莫大なステークを用意する必要があります。
さらに、不正行動が検出されればslashingや社会的対応の対象になります。
Ethereum公式も、これらの攻撃には大きなコストがあり、特に高い割合の攻撃では社会層での調整が防御の一部になると説明しています。

ここでのポイントは、PoSの攻撃が「無料でこっそりできる」ものではないことです。

PoSでは、攻撃者が大きな影響力を持つには、多くのステークを用意する必要があります。
そして、そのステークは攻撃時に大きく危険にさらされます。

6.8 小さなコードで見る：ステーク割合ごとのリスク分類

ここでは、攻撃者が持つステーク割合によって、どのようなリスクが考えられるかを、単純な分類コードで見てみます。

このコードは、Ethereum公式ドキュメントにある割合の考え方を、学習用に整理したものです。
実際のネットワーク攻撃可能性を判定するものではありません。

# 攻撃者のステーク割合ごとのリスクを、学習用に分類するコードです。
# 実際のEthereumネットワークの安全性を判定するものではありません。


def classify_pos_attack_risk(attacker_stake_ratio):
    """
    attacker_stake_ratio:
        攻撃者が総ステークのうち何割を持っているかを0.0〜1.0で表します。

    返り値:
        初学者向けの説明文を返します。
    """
    if attacker_stake_ratio >= 0.66:
        return "66%以上: finalized chainを含む強い影響を持つ危険があります。"

    if attacker_stake_ratio >= 0.51:
        return "51%以上: 検閲や将来のブロック内容への強い影響が問題になります。"

    if attacker_stake_ratio >= 0.34:
        return "34%以上: double finalityのような深刻な問題が議論されます。"

    if attacker_stake_ratio >= 0.33:
        return "33%以上: finalityを妨げる可能性が問題になります。"

    return "33%未満: ただちに大きな支配力を持つとは限りませんが、攻撃手法や条件には注意が必要です。"


examples = [0.10, 0.33, 0.34, 0.51, 0.66, 0.80]

for ratio in examples:
    print(f"攻撃者のステーク割合: {ratio:.0%}")
    print("  ", classify_pos_attack_risk(ratio))

このコードでは、攻撃者のステーク割合を入力すると、ざっくりしたリスク分類を返します。

もちろん、現実の攻撃はこのような単純な条件だけでは決まりません。
ネットワーク遅延、クライアント実装、バリデータの分布、社会的対応、攻撃者の資金調達、取引所やステーキングサービスの集中など、多くの要素が関係します。

それでも、PoSでは「ステークの割合」が安全性を考えるうえで大きな指標になることが分かります。

6.9 ステーク集中はPoSの大きな注意点

PoSでは、ステーク量が影響力につながります。

そのため、ステークが一部の事業者やサービスに集中しすぎると、ネットワークの健全性に関わる問題になります。

身近な例で言えば、共同管理の会計ノートで、確認担当者のほとんどが同じ会社や同じグループに属している状態です。
形式上は複数人で確認していても、実質的には同じ判断に偏りやすくなるかもしれません。

PoSでも、次のような集中が論点になります。

集中の種類	何が問題になり得るか
ステーク集中	少数の主体が大きな投票力を持つ
ステーキングサービス集中	利用者の資産が特定サービスに集まり、運用判断が偏る
クライアント集中	同じソフトウェアのバグが広範囲に影響する
インフラ集中	同じクラウド、同じ地域、同じネットワークに依存する

Ethereum公式のclient diversityページでは、複数の独立したクライアントが存在することはネットワークを攻撃やバグに強くするために重要であり、クライアントが均等に採用されることが望ましいと説明されています。
また、1つのクライアントに多数が集中すると、そのクライアントの重大なバグがネットワーク全体に影響するリスクが高まると説明されています。

参考: Ethereum.org: Client diversity

ここで注意したいのは、PoSの集中リスクは「お金持ちがいるから危険」という単純な話だけではないことです。

どのサービスにステークが集まっているか
どのクライアント実装が使われているか
どのインフラに依存しているか
バリデータ運用者が地理的・組織的に分散しているか

こうした複数の観点で見る必要があります。

6.10 小さなコードで見る：ステーク集中を測る

ここでは、バリデータ運用者ごとのステーク割合を見て、集中度をざっくり確認するコードを書いてみます。

このコードは、実際のEthereumのステーク分布を分析するものではありません。
あくまで、一部の主体にステークが集まると、影響力も大きくなる という考え方を理解するための学習用です。

# ステーク集中をざっくり確認するための学習用コードです。
# 実際のEthereumのステーク分布ではありません。

operators = {
    "Operator_A": 4200,
    "Operator_B": 2600,
    "Operator_C": 1500,
    "Operator_D": 900,
    "Operator_E": 800,
}


def calculate_stake_share(operators):
    """
    運用者ごとのステーク割合を計算します。

    operators:
        運用者名 -> ステーク量 の辞書です。
    """
    total_stake = sum(operators.values())

    shares = []
    for name, stake in operators.items():
        share = stake / total_stake
        shares.append({"operator": name, "stake": stake, "share": share})

    # 割合が大きい順に並べます。
    return sorted(shares, key=lambda item: item["share"], reverse=True)


for item in calculate_stake_share(operators):
    print(f"{item['operator']}: stake={item['stake']}, share={item['share']:.1%}")

# 上位2運用者の合計割合も確認します。
shares = calculate_stake_share(operators)
top2_share = shares[0]["share"] + shares[1]["share"]
print(f"上位2運用者の合計割合: {top2_share:.1%}")

このコードでは、架空の運用者ごとのステーク量を用意し、それぞれの割合を計算しています。

もし上位数社だけで大きな割合を占めているなら、ネットワークの意思決定や障害耐性に偏りが生まれる可能性があります。
もちろん、実際には単純なステーク量だけでなく、サービスの運用方針、クライアント構成、地理分散、法域、ノード構成なども見る必要があります。

6.11 弱主観性というPoS特有の考え方

PoSを学ぶときに少し難しいのが、weak subjectivity という考え方です。

日本語では「弱主観性」と訳されることがあります。

名前だけ見るとかなり難しく感じますが、最初は次のように捉えると分かりやすいです。

長くオフラインだったノードや、新しく参加するノードは、最近の正しい状態を信頼できる情報源から確認する必要がある場合がある。

たとえば、共同編集ノートを半年ぶりに開く人を考えてみます。

その人が持っている古いコピーだけを見ると、その後に何が起きたか分かりません。
そこで、信頼できるメンバーや公式のバックアップから「今の最新版はこれです」と確認してから、そこから先を自分で検証していく必要があります。

Ethereum公式ドキュメントでは、PoS Ethereumではweak subjectivity checkpointsが使われると説明されています。
これは、ネットワーク上のノードがcanonical chainに属すると合意しているstate rootであり、そのcheckpointから先を独立に検証していくための基準として扱われます。

参考: Ethereum.org: Weak subjectivity

重要なのは、これはPoSが「適当に信じるだけの仕組み」という意味ではないことです。

最新に近い信頼できるcheckpointを得たうえで、そこから先のブロックや状態遷移を検証します。
つまり、全部を盲目的に信じるのではなく、出発点を確認したうえで自分で検証するイメージです。

💡 豆知識
weak subjectivityは、PoSをPoWと比べるときに出てきやすい論点です。
PoWでは累積作業量を見て客観的にチェーンを選びやすい一方、PoSでは長期間離脱していたノードが古い情報だけで安全に復帰するのが難しい場合があります。
そのため、最近の信頼できるcheckpointを使うという考え方が重要になります。

6.12 PoSで防げること・防げないこと

ここまで見ると、PoSはかなり強力な仕組みに見えるかもしれません。

たしかに、PoSはステークした資産をリスクにさらすことで、不正な行動をしにくくします。
また、報酬、ペナルティ、slashing、inactivity leakなどにより、正しく参加する動機を作ります。

ただし、PoSも万能ではありません。

観点	PoSで期待できること	PoSだけでは防ぎきれないこと
ブロック提案	不正な提案を抑止しやすくする	すべてのバグや実装ミスを防ぐわけではない
投票・検証	多数のバリデータで履歴を確認する	ステーク集中があると偏りが生まれる可能性がある
不正抑止	slashingで重大な違反を重く罰する	鍵管理ミスや運用ミスを完全には防げない
finality	十分な同意により履歴を覆りにくくする	1/3超の不参加などでfinalityが止まる可能性がある
攻撃耐性	攻撃者に大量のステークを要求する	33%、51%、66%などのステーク支配は重大なリスクになる
分散性	多数のバリデータ参加を促せる	ステーキングサービス、クライアント、インフラ集中の問題は残る

PoSを安全に運用するには、単に「PoSだから安全」と考えるのではなく、次のような周辺要素も大切になります。

バリデータの鍵管理
クライアントの多様性
ステーキングサービスへの集中回避
ネットワーク監視
slashing防止の運用設計
仕様変更やアップグレードへの追従
コミュニティや社会層での対応

これは、情報セキュリティ全般にも似ています。

暗号アルゴリズムが強くても、鍵管理が甘ければ危険です。
同じように、PoSの仕組みがよく設計されていても、運用や実装が偏るとリスクが残ります。

6.13 PoSの不正抑止を一枚で整理する

ここまでの内容を、PoSの不正抑止の流れとしてまとめると次のようになります。

この図で大切なのは、PoSの不正抑止が1つの機能だけで成り立っているわけではないことです。

報酬
通常のペナルティ
slashing
inactivity leak
ステーク割合による攻撃コスト
クライアント多様性
社会層での対応

こうした複数の要素が組み合わさって、PoSの安全性を支えています。

6.14 この章のまとめ

この章では、PoSがどのように不正を抑止するのかを整理しました。

PoWが計算資源や電力をコストにして不正をしにくくするのに対して、PoSはステークした資産、報酬、ペナルティ、slashingを使って、不正をしにくくします。

この章で押さえたいポイントは、次の通りです。

ポイント	説明
PoSでは報酬とペナルティが重要	正しく参加すると報酬、不参加や遅延にはペナルティがある
slashingは重大な違反への強い罰	二重投票や矛盾する提案などを強く抑止する
オフラインもfinalityに影響する	多数が参加しないと2/3以上の同意を作れない場合がある
inactivity leakはfinality回復の仕組み	非参加側の影響力を下げ、参加側がfinalizeできる状態を目指す
攻撃者のステーク割合が重要	33%、51%、66%などの割合に応じて影響が大きくなる
ステーク集中には注意が必要	少数の主体やサービスに影響力が集まりすぎるとリスクになる
クライアント多様性も重要	同じ実装への集中は、バグや攻撃への弱さにつながる
weak subjectivityという論点がある	長く離脱したノードや新規ノードは、最近の正しいcheckpointを確認する必要がある

PoSを一言でまとめるなら、預けた資産をリスクにさらすことで、正しく参加する動機を作る仕組み です。

ただし、PoSだから自動的に安全になるわけではありません。
ステークの分散、クライアントの多様性、鍵管理、運用設計、社会層での対応など、多くの要素が安全性に関わります。

ここまでで、PoWとPoSの基本的な考え方をそれぞれ見てきました。

次の章では、両者を横に並べて比較します。
「どちらが絶対に優れているか」ではなく、何をコストにして不正を抑止するのか、どのような強みと注意点があるのかを整理していきます。

7. PoWとPoSを比較する

この章では、ここまで別々に見てきたProof of WorkとProof of Stakeを横に並べて整理します。
ポイントは、「どちらが絶対に優れているか」ではなく、何をコストにして不正を抑止しているのか、そして どのような注意点があるのか を分けて見ることです。

ここまでで、PoWとPoSをそれぞれ見てきました。

PoWは、nonceを変えながら条件を満たすハッシュを探す仕組みでした。
不正な履歴を作ろうとすると、大量の計算資源、電力、設備投資が必要になります。

一方でPoSは、資産をステークしてバリデータとして参加する仕組みでした。
正しく参加すれば報酬を得られますが、不参加や重大な違反にはペナルティやslashingが関係します。

つまり、PoWとPoSはどちらも「不正を無料でできないようにする」ための仕組みです。
ただし、そのために使うコストの種類が違います。

身近なたとえで言えば、次のように考えると分かりやすいです。

たとえ	PoWに近い考え方	PoSに近い考え方
共有ノートの記録係	大量の計算作業をした人が記録を追加できる	保証金を預けた人が記録係として参加できる
不正への抑止	ズルをするには作業をやり直す必要がある	ズルをすると保証金を失う可能性がある
参加の重み	計算能力・電力・設備	ステークした資産
悪用しにくくする方法	作業コストを重くする	不正時の損失を大きくする

この章では、PoWとPoSを次の観点で比較します。

参加するために必要なもの
ブロック作成者の選ばれ方
不正時に何を失うのか
攻撃に必要な資源
エネルギー消費
分散性と集中リスク
実装・運用の複雑さ
どちらか一方を「完全上位互換」と言ってよいのか

Ethereum公式ドキュメントでも、PoWとPoSはよく「コンセンサス方式」と呼ばれる一方で、厳密にはSybil耐性やブロック作成者選択に関わる要素であり、fork choiceなども含めた全体でコンセンサス機構が成り立つと説明されています。

参考: Ethereum.org: Consensus mechanisms

そのため、この章でもPoW/PoSを単純な一言で片付けず、複数の観点に分けて見ていきます。

7.1 まずは大きな違いを表で見る

最初に、PoWとPoSの違いを大きく整理します。

観点	Proof of Work	Proof of Stake
ざっくりした考え方	計算作業を行い、条件を満たすブロックを見つける	資産をステークし、バリデータとしてブロック提案や検証に参加する
代表的な参加者	miner	validator
参加の重み	計算能力、電力、専用機材など	ステークした資産、バリデータの参加状況など
不正時に失うもの	電力、設備投資、機会損失、報酬機会など	ステークした資産、報酬、バリデータ資格、信用など
代表例	Bitcoin	現在のEthereumなど
攻撃の見方	ハッシュパワーの支配が問題になる	総ステーク量に対する割合が問題になる
フォーク選択の考え方	累積されたPoWが大きいチェーンが重視される	バリデータの投票・ステーク重みに基づくfork choiceが関係する
主な論点	電力消費、マイニング集中、専用機材化	ステーク集中、slashing、弱主観性、実装・運用の複雑さ
よくある誤解	「ただの無駄な計算」と見られやすい	「電力を使わないから完全に安全」と見られやすい

この表だけを見ると、PoWとPoSはかなり違う仕組みに見えます。

しかし、目的の方向性は似ています。
どちらも、誰でも参加できるネットワークで、悪意ある参加者が安く大量に影響力を持つことを防ぐための仕組みです。

2章で扱ったSybil攻撃の話を思い出すと分かりやすいです。

もし「1アカウント1票」のような仕組みにしてしまうと、悪意ある人が大量の偽アカウントを作って影響力を持ててしまいます。
そこで、PoWでは計算資源を、PoSではステークした資産を使って、参加の重みにコストを持たせています。

Bitcoinホワイトペーパーでも、単純な「1 IPアドレス1票」では多数のIPを用意できる人に悪用され得るため、PoWは「1 CPU 1票」のように扱われると説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

7.2 PoWは「外側のコスト」、PoSは「内側のコスト」に近い

PoWとPoSの大きな違いは、どこにコストを置くかです。

PoWでは、計算機、電力、冷却、設備、運用といった、ブロックチェーンの外側にある現実世界の資源が重要になります。
不正な履歴を作ろうとすると、正直な参加者よりも多くの計算作業を続ける必要があります。

一方でPoSでは、チェーン上の資産をステークすることが重要になります。
不正をすれば、ステークした資産が減ったり、バリデータ資格を失ったりする可能性があります。

かなり単純化すると、次のように言えます。

観点	PoW	PoS
主なコストの置き場所	チェーン外の計算資源・電力・設備	チェーン内の資産・報酬・ペナルティ
攻撃者が必要とするもの	大きな計算能力	大きなステーク量
攻撃後に残るもの	ハードウェアなどを再利用できる場合がある	slashingでステークを失う可能性がある
安全性の支え方	計算作業をやり直すコストを高くする	不正時の経済的損失を大きくする

Ethereum公式のPoW/PoS比較では、PoSでは攻撃者が総ステークの大きな割合を集める必要があり、攻撃が検出されるとslashingによりステークを失う可能性があると説明されています。
一方、PoWでは攻撃にはハードウェアや電力が必要になり、EthereumがPoWだった時代については、攻撃コストは十分な計算能力を継続的に所有するコストとして説明されています。

参考: Ethereum.org: Proof-of-stake vs proof-of-work

ただし、この説明はEthereum文脈の比較です。
すべてのPoWチェーン、すべてのPoSチェーンにそのまま同じ結論を当てはめるのは避けた方がよいです。

チェーンごとに、参加者数、資産規模、クライアント実装、マイニング環境、ステーキングサービスの集中度、フォーク選択ルールなどが違うからです。

7.3 ブロック作成者の選ばれ方の違い

次に、ブロック作成者の選ばれ方を見てみます。

PoWでは、マイナーが条件を満たすハッシュを探します。
誰が次のブロックを作るかは、ざっくり言えば「計算競争で当たりを見つけた人」によって決まります。

PoSでは、バリデータの中からブロック提案者が選ばれます。
Ethereumの場合、各slotで1人のバリデータがブロック提案者として選ばれ、他のバリデータはattestationによりそのブロックやチェーンの見方に投票します。

参考: Ethereum.org: Proof-of-stake

図にすると、次のようなイメージです。

この違いは、読者にとって少し直感的に分かりにくいかもしれません。

身近な例で言えば、PoWは「毎回、難しい計算くじを最初に解いた人が記録係になる」イメージです。
PoSは「保証金を預けて記録係候補になり、その中から当番が選ばれる」イメージです。

もちろん、実際のブロックチェーンはもっと複雑です。
ただ、入口としてはこのくらいの理解で十分です。

7.4 フォーク選択の違い

ブロックチェーンでは、同じ高さに複数のブロック候補が出てくることがあります。
このとき、「どちらを正しい履歴として伸ばしていくか」を決める必要があります。

これがfork choice、つまりフォーク選択の話です。

PoWでは、累積されたProof of Workが大きいチェーンが重視されます。
Bitcoinホワイトペーパーでは、最長チェーンが出来事の順序の証明であるだけでなく、最大のCPU powerのプールから来た証明でもあると説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

一方で、EthereumのPoSでは、バリデータの投票をステーク量で重み付けしたfork choiceが関係します。
Ethereum公式ドキュメントでは、PoWでは累積PoW difficultyが重要であり、PoSではバリデータの投票をステークされたETH残高で重み付けしたchain weightを使うと説明されています。

参考: Ethereum.org: Consensus mechanisms

かなり単純化すると、次のようになります。

観点	PoW	PoS
どの履歴を選ぶか	多くの作業量が積み上がった履歴	多くのステーク重みを持つバリデータが支持した履歴
見ているもの	累積作業量	投票・attestation・ステーク重み
直感的なたとえ	一番作業量の多いノートを採用する	保証金を預けた参加者の重み付き投票を見る

ここで大切なのは、PoWもPoSも「ブロックを1つ作る」だけで終わりではないことです。
複数の候補が出たときに、どの履歴を伸ばしていくかを決めるルールが必要になります。

2章で説明したように、PoW/PoSはコンセンサス全体の一部です。
検証ルール、ブロック作成者選択、フォーク選択、報酬・ペナルティが組み合わさって、ネットワーク全体の合意が作られます。

7.5 小さなコードで見る：作業量とステーク重みの違い

ここで、PoWとPoSの「重み」の違いを、かなり単純化したコードで見てみます。

このコードは、実際のBitcoinやEthereumのfork choiceを再現するものではありません。
あくまで、PoWでは作業量、PoSではステーク重みのような別々の指標で候補を比べる、という考え方を理解するための学習用です。

# PoWとPoSにおける「どの候補を重く見るか」の違いを学ぶための簡易コードです。
# 実際のBitcoinやEthereumのfork choiceを再現するものではありません。

# PoWの候補チェーンを、累積作業量で表します。
# cumulative_work が大きいほど、多くの作業が積み上がっていると考えます。
pow_chains = [
    {"name": "chain_A", "height": 5, "cumulative_work": 1200},
    {"name": "chain_B", "height": 6, "cumulative_work": 1180},
    {"name": "chain_C", "height": 5, "cumulative_work": 1260},
]

# PoSの候補チェーンを、支持したバリデータのステーク重みで表します。
# vote_weight が大きいほど、多くのステーク重みを持つ投票が集まっていると考えます。
pos_chains = [
    {"name": "chain_A", "height": 5, "vote_weight": 64},
    {"name": "chain_B", "height": 6, "vote_weight": 58},
    {"name": "chain_C", "height": 5, "vote_weight": 71},
]

# PoWでは、ここでは累積作業量が最大の候補を選ぶという単純なモデルにします。
# 実際の実装では、ブロックの有効性やネットワーク上の状況など、他の要素も関係します。
best_pow_chain = max(pow_chains, key=lambda chain: chain["cumulative_work"])

# PoSでは、ここでは投票重みが最大の候補を選ぶという単純なモデルにします。
# 実際のEthereumでは、LMD-GHOSTやfinalityなど、より複雑なルールが関係します。
best_pos_chain = max(pos_chains, key=lambda chain: chain["vote_weight"])

print("PoWで選ばれた候補:", best_pow_chain)
print("PoSで選ばれた候補:", best_pos_chain)

このコードでは、PoW側では cumulative_work、PoS側では vote_weight を見ています。

実際の仕組みはもっと複雑ですが、比較の入口としては次の感覚が大切です。

仕組み	何を重く見るか
PoW	どれだけ作業量が積み上がっているか
PoS	どれだけのステーク重みが支持しているか

ここで注意したいのは、単純なブロック高だけで選んでいるわけではないことです。

PoWでは、ブロック数だけでなく、累積された作業量が重要になります。
PoSでは、単にバリデータの人数だけでなく、ステーク量で重み付けされた投票が関係します。

7.6 攻撃の見方の違い

PoWとPoSでは、攻撃を考えるときの見方も変わります。

PoWでは、攻撃者が大きなハッシュパワーを持つことが問題になります。
Bitcoinホワイトペーパーでは、過半のCPU powerが正直なノードに支配されていれば、正直なチェーンが最も速く伸び、攻撃者のチェーンを上回ると説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

PoSでは、攻撃者が大きなステーク割合を持つことが問題になります。
Ethereum公式ドキュメントでは、攻撃者の総ステーク割合に応じて、finality delay、double finality、検閲、finality reversionなどのリスクが整理されています。

参考: Ethereum.org: Ethereum proof-of-stake attack and defense

比較すると次のようになります。

観点	PoW	PoS
攻撃に必要なもの	大量のハッシュパワー	大量のステーク
よく出る数字	51%攻撃	33%、51%、66%などのステーク割合
攻撃で狙われること	二重支払い、取引検閲、短期的なチェーン再編成など	finality delay、検閲、double finality、履歴への影響など
攻撃後の扱い	ハードウェアや電力コストが問題になる	slashingや社会層での対応が問題になる

ここでも、「PoWは51%攻撃だけ」「PoSは33%攻撃だけ」のように単純化しすぎるのは避けた方がよいです。

攻撃の影響は、チェーンの設計、資産規模、ネットワークの分散性、取引所やアプリ側の確認ルール、コミュニティ対応によって変わります。

7.7 エネルギー消費の違い

PoWとPoSの比較でよく出てくるのが、エネルギー消費です。

PoWでは、マイナーが計算作業で競います。
計算を速く行えるほどブロックを見つける可能性が高まるため、設備や電力への投資が大きくなりやすいです。

一方でPoSでは、PoWのように全員が大量のハッシュ計算で競う設計ではありません。
そのため、PoWと比べてエネルギー消費を大きく抑えやすいと説明されます。

Ethereum公式のPoW/PoS比較では、EthereumがPoSへ移行する直前には約78TWh/年を消費していたこと、PoSへの切り替えによりエネルギー消費が約99.98%削減されたことが説明されています。

参考: Ethereum.org: Proof-of-stake vs proof-of-work

ただし、ここでも表現には注意が必要です。

PoSは「電力をまったく使わない」わけではありません。
バリデータを動かすサーバー、ネットワーク、ストレージ、監視環境などは必要です。

正確には、次のように表現すると誤解を避けやすくなります。

避けたい表現	より安全な表現
PoSは電力を使わない	PoSはPoWのような大規模なハッシュ計算競争をしないため、エネルギー消費を大きく抑えやすい
PoWは電力を無駄にしているだけ	PoWは電力・計算資源を不正抑止のコストとして使っているが、エネルギー消費は大きな論点になる
PoSは環境面で完全に問題がない	PoWより省エネルギー化しやすいが、運用インフラや集中リスクなど別の論点がある

💡 豆知識
EthereumのThe Mergeでは、PoWからPoSへ移行したことでエネルギー消費が大幅に削減されたと説明されています。
ただし、The Mergeは「ガス代を直接下げるための更新」ではありません。
主な変更点は、Ethereumのコンセンサス方式をPoWからPoSへ切り替えたことです。

7.8 分散性と集中リスクの違い

PoWとPoSは、どちらも分散型ネットワークを支える仕組みとして使われます。
しかし、集中リスクの出方は少し違います。

PoWでは、マイニング設備や電力コスト、専用機材、マイニングプールへの集中が問題になり得ます。
個人でも理論上参加できるとしても、実際に報酬を得るには大きな計算能力が必要になりやすく、マイニングプールに参加する動機が生まれます。

PoSでは、ステーク量、ステーキングサービス、リキッドステーキング、クラウドインフラ、クライアント実装への集中が問題になり得ます。
Ethereum公式のPoW/PoS比較でも、PoSは個人や小規模組織が参加しやすい面がある一方、リキッドステーキングなどによる集中懸念があると説明されています。

参考: Ethereum.org: Proof-of-stake vs proof-of-work

整理すると、次のようになります。

観点	PoWの集中リスク	PoSの集中リスク
参加資源	専用機材、電力、設備	ステーク資産、バリデータ運用環境
集中しやすい場所	マイニングプール、大規模採掘事業者	ステーキングサービス、リキッドステーキング、クラウド、クライアント
個人参加の難しさ	報酬を得るには計算能力の競争が厳しい場合がある	直接バリデータ参加には一定の資産や運用知識が必要な場合がある
注意点	ハッシュパワー集中	ステーク集中・運用集中

PoWもPoSも、仕組みだけ見れば「誰でも参加できる」ように見えます。
しかし、実際の参加しやすさは、経済条件、技術条件、運用コスト、周辺サービスの存在によって変わります。

そのため、分散性を考えるときは、単に「参加できるか」だけでなく、実際に影響力がどこへ集まっているかを見ることが大切です。

7.9 小さなコードで見る：集中度をざっくり測る

分散性を考えるときは、「誰か1人が参加できるか」だけでなく、影響力がどのくらい偏っているかを見ることが大切です。

ここでは、学習用に、PoWのハッシュパワー分布とPoSのステーク分布を比較してみます。

このコードは実在ネットワークの評価ではありません。
架空のデータを使って、影響力の集中を数値で見る感覚をつかむためのものです。

# PoWのハッシュパワー分布とPoSのステーク分布の集中度を、
# 架空データでざっくり比較する学習用コードです。
# 実在するネットワークやサービスの評価ではありません。


def normalize(shares):
    """入力された値の合計が1になるように正規化します。"""
    total = sum(shares)
    return [value / total for value in shares]


def hhi(shares):
    """
    HHIに近い集中度指標を計算します。
    各参加者のシェアを2乗して足し合わせるため、
    少数の参加者に大きなシェアがあるほど値が大きくなります。
    """
    normalized = normalize(shares)
    return sum(share ** 2 for share in normalized)


def top_k_share(shares, k):
    """上位k参加者が全体のどれくらいを占めるかを計算します。"""
    normalized = normalize(shares)
    return sum(sorted(normalized, reverse=True)[:k])


# 架空のPoWマイニングプールのハッシュパワー分布です。
# 数字が大きいほど、そのプールが大きなハッシュパワーを持つとします。
pow_hashrate_shares = [35, 22, 15, 10, 8, 5, 3, 2]

# 架空のPoSステーキング主体のステーク分布です。
# 数字が大きいほど、その主体が大きなステークを持つとします。
pos_stake_shares = [28, 24, 18, 12, 8, 5, 3, 2]

for name, shares in [
    ("PoWの架空ハッシュパワー分布", pow_hashrate_shares),
    ("PoSの架空ステーク分布", pos_stake_shares),
]:
    print(name)
    print("  HHI風の集中度:", round(hhi(shares), 4))
    print("  上位3主体のシェア:", round(top_k_share(shares, 3), 4))
    print()

このコードでは、HHI に近い考え方で集中度を見ています。

HHIは本来、経済学や競争政策などで市場集中度を見るときに使われる指標です。
ここでは厳密な分析ではなく、「影響力が一部に偏ると数値が大きくなる」という感覚をつかむために使っています。

出力を見ると、上位数主体が大きな割合を持っているほど、集中度が高くなります。

この考え方は、PoWにもPoSにも使えます。

見たいもの	PoWでの例	PoSでの例
上位主体への偏り	上位マイニングプールのハッシュパワー	上位ステーキングサービスのステーク量
参加者の分散	小規模マイナーやプールの数	個人バリデータや独立運用者の数
運用集中	特定地域・電力環境への偏り	特定クラウド・クライアントへの偏り

ただし、このコードだけで「このチェーンは安全」「このチェーンは危険」と判断することはできません。

実際には、次のような情報も見ます。

参加者の実体がどこまで独立しているか
プールやサービスの運営方針
地理的な分散
クライアント実装の多様性
ノード運用の分散
過去の障害や攻撃への対応
コミュニティやガバナンスの動き

集中度は大切な手がかりですが、それだけで安全性を断定しないことが重要です。

7.10 実装の複雑さと運用の違い

PoWとPoSは、実装や運用の複雑さにも違いがあります。

PoWは、基本的な考え方だけ見ると比較的シンプルです。
ハッシュ条件を満たすnonceを探し、見つかったブロックを他のノードが検証します。

一方で、実際のPoWネットワークを安全に運用するには、difficulty調整、ネットワーク伝播、マイニングプール、手数料市場、ASIC化、エネルギー調達など、多くの要素が関係します。

PoSは、PoWのような大規模な計算競争を避けやすい一方で、プロトコル自体は複雑になりやすいです。

Ethereum公式のPoW/PoS比較でも、PoSはPoWより複雑であり、攻撃面も増える可能性がある一方、長年の研究、シミュレーション、テストネット、複数クライアント実装などによって複雑さを抑え込んできたと説明されています。

参考: Ethereum.org: Proof-of-stake vs proof-of-work

比較すると、次のようになります。

観点	PoW	PoS
直感的な理解	当たりハッシュ探しとして説明しやすい	報酬、投票、slashing、finalityなど複数要素がある
実装の論点	difficulty、マイニング、ブロック伝播	validator選出、attestation、finality、slashing、weak subjectivity
運用の論点	電力、設備、マイニングプール	鍵管理、常時稼働、slashing防止、クライアント多様性
障害時の注意	ハッシュパワー低下やプール集中	バリデータ停止、クライアントバグ、finality停止

つまり、PoWは「単純で何も問題がない」、PoSは「複雑だから危険」と単純に言うことはできません。

PoWにはPoWの運用上の難しさがあります。
PoSにはPoSの設計・運用上の難しさがあります。

7.11 「PoSはPoWの完全上位互換」とは言い切らない

ここまで比較すると、PoSは電力消費を大きく抑えやすく、slashingのような明示的な罰も設計できるため、PoWより良い仕組みに見えるかもしれません。

実際、Ethereum公式ドキュメントでは、Ethereum文脈においてPoSの安全性や持続可能性の利点が説明されています。

参考: Ethereum.org: Proof-of-stake vs proof-of-work

ただし、本文では「PoSはPoWの完全上位互換です」と断定しない方が誤解を避けやすいです。

理由は、比較する軸によって評価が変わるからです。

評価軸	PoWが重視されやすい理由	PoSが重視されやすい理由
実績	Bitcoinで長期間使われている	Ethereumで本格運用されているが、PoWより新しい
省エネルギー	大きな弱点になりやすい	大きな利点になりやすい
実装の単純さ	基本概念は説明しやすい	多くの要素が絡むため複雑になりやすい
攻撃後の処理	攻撃者の設備が残る可能性がある	slashingや社会層での対応が関係する
分散性	マイニングプール集中が課題	ステーキングサービス集中が課題
新規参加	機材・電力が壁になり得る	資産・運用知識・32 ETHなどが壁になり得る

このように、何を重視するかによって見え方は変わります。

たとえば、Bitcoinの文脈では、PoWはネットワークの思想や設計と深く結びついています。
一方で、Ethereumの文脈では、PoSへの移行はエネルギー消費削減や将来のスケーリング戦略と結びついて説明されます。

つまり、PoWとPoSは、単なる性能比較だけではなく、チェーンの目的、設計思想、参加者、経済圏、セキュリティモデルと一緒に考える必要があります。

💡 豆知識
PoWとPoSの議論では、「どちらが正しいか」という対立に見えることがあります。
しかし実際には、どのようなネットワークを作りたいのか、何をリスクと見るのか、どの資源を不正抑止のコストにするのかによって、選ばれる設計が変わります。
技術比較では、単に勝ち負けを決めるよりも、前提条件をそろえて見ることが大切です。

7.12 小さなコードで見る：評価軸を変えると見え方も変わる

ここでは、評価軸を変えるとPoW/PoSの見え方が変わることを、簡単なスコア計算で見てみます。

このコードは、PoWとPoSの優劣を決めるものではありません。
あくまで、「どの観点を重視するかによって比較結果が変わる」という考え方を理解するための学習用です。

# PoWとPoSの比較では、どの評価軸を重視するかによって見え方が変わります。
# このコードは学習用の簡易モデルであり、実際のチェーン評価や投資判断には使えません。

# 各方式に対して、説明用の仮スコアを置きます。
# 5に近いほど、その観点で強みがあるという単純なモデルです。
# 数値は説明用であり、実測値ではありません。
scores = {
    "PoW": {
        "time_proven": 5,        # 長期運用実績のイメージ
        "energy_efficiency": 1,  # 省エネルギー性のイメージ
        "simplicity": 4,         # 基本概念の説明しやすさ
        "slashing_design": 1,    # プロトコル内での明示的な罰の設計
    },
    "PoS": {
        "time_proven": 3,
        "energy_efficiency": 5,
        "simplicity": 2,
        "slashing_design": 5,
    },
}

# 読者が何を重視するかを、重みとして設定します。
# ここでは例として、省エネルギー性とslashing設計をやや重視しています。
weights = {
    "time_proven": 0.25,
    "energy_efficiency": 0.30,
    "simplicity": 0.15,
    "slashing_design": 0.30,
}


def weighted_score(method, scores, weights):
    """方式ごとの仮スコアに、評価軸の重みを掛けて合計します。"""
    return sum(scores[method][key] * weight for key, weight in weights.items())


for method in ["PoW", "PoS"]:
    result = weighted_score(method, scores, weights)
    print(f"{method} の説明用スコア: {result:.2f}")

このコードでは、weights を変えると結果が変わります。

たとえば、省エネルギー性やslashing設計を重視すればPoSが高く出やすくなります。
一方で、長期運用実績や基本概念の単純さを重視すればPoWが高く出やすくなります。

繰り返しになりますが、このコードは実際のネットワークを評価するものではありません。
比較記事を書くときに大切なのは、自分がどの評価軸を置いているのかを明示することです。

7.13 PoWとPoSの比較を一枚で整理する

ここまでの内容を、全体図としてまとめると次のようになります。

この図で押さえたいのは、PoWもPoSも「不正を防ぐ魔法」ではないという点です。

どちらも、不正をしようとする人に高いコストを負わせる仕組みです。
ただし、そのコストの置き方が違います。

PoWは、計算作業を通じて現実世界の資源を消費させます。
PoSは、ステークした資産をリスクにさらします。

どちらの方式でも、次のような周辺要素が重要です。

ノードや参加者の分散
検証ルールの正しさ
フォーク選択の設計
報酬や手数料の設計
クライアント実装の安全性
鍵管理や運用体制
コミュニティの対応力

7.14 この章のまとめ

この章では、PoWとPoSを横並びで比較しました。

PoWとPoSは、どちらも分散した参加者が同じ履歴を共有するために重要な仕組みです。
ただし、不正を抑止するために使うコストの種類が違います。

ポイント	PoW	PoS
不正抑止のコスト	計算資源、電力、設備	ステークした資産、報酬、ペナルティ
主な参加者	マイナー	バリデータ
影響力の源泉	ハッシュパワー	ステーク量
攻撃の見方	51%攻撃など、計算能力の支配	33%、51%、66%など、ステーク割合による影響
主な強み	Bitcoinで長く使われている、基本概念を説明しやすい	省エネルギー化しやすい、slashingなど明示的な罰を設計できる
主な注意点	エネルギー消費、マイニング集中	ステーク集中、実装・運用の複雑さ、弱主観性

PoWは、計算作業を積み重ねることで、過去の履歴を書き換えるコストを高めます。
PoSは、資産を預けたバリデータに報酬とペナルティを与え、不正時にはステークを失う可能性を持たせます。

この2つは、単純な勝ち負けで比較するよりも、次のように見る方が分かりやすいです。

PoWは、計算資源を使って不正を高くつかせる仕組み。
PoSは、預けた資産を使って不正を高くつかせる仕組み。

つまり、どちらも「不正をしようとする人にコストを負わせる」という目的は似ています。
違うのは、そのコストをどこに置くかです。

次の章では、この比較をさらに情報セキュリティの観点から見ていきます。
Sybil攻撃、51%攻撃、ステーク集中、クライアント集中、MEV、検閲リスクなど、PoW/PoSを支える仕組みがどのようなセキュリティ論点につながるのかを整理します。

8. 情報セキュリティの観点で見る注意点

この章では、PoWとPoSを情報セキュリティの観点から整理します。
ポイントは、PoWやPoSだけでブロックチェーン全体の安全性が決まるわけではない、という点です。

ここまで、PoWとPoSをそれぞれ見てきました。

PoWでは、計算作業にコストを払わせることで、不正な履歴を作りにくくします。
PoSでは、預けた資産をリスクにさらすことで、正しく参加する動機を作ります。

どちらも、ブロックチェーンの安全性を支える重要な仕組みです。
ただし、ここで注意したいのは、PoWやPoSを理解しただけで、ブロックチェーン全体のセキュリティを理解したことにはならない という点です。

身近な例で考えてみます。

学校や研究室で、みんなが見る共有ノートを使っているとします。
「誰が次に書いてよいか」「どの版を正しい記録にするか」というルールがあると、記録の食い違いはかなり減らせます。

しかし、それだけで次のような問題まで防げるでしょうか。

ノートを置いている部屋の鍵が盗まれる
書く内容そのものが間違っている
ノートを読む人が偽の案内にだまされる
管理者が偏った運用をする
一部の人だけが記録追加を独占する

おそらく、防げません。

ブロックチェーンでも同じです。
PoWやPoSは、主に 記録の追加や履歴の選び方 に関わる仕組みです。
一方で、ウォレットの秘密鍵管理、スマートコントラクトのバグ、取引所の管理、ブリッジの設計、アプリのフロントエンド、利用者のフィッシング対策などは、また別のセキュリティ論点です。

この章では、PoW/PoSそのものだけでなく、その周辺にあるセキュリティ上の注意点も含めて整理します。

8.1 コンセンサスは「安全性の一部」であって全部ではない

まず、コンセンサスとセキュリティの関係を整理します。

2章でも触れたように、Ethereum公式ドキュメントでは、PoWやPoSはよくコンセンサス方式と呼ばれるものの、厳密にはSybil耐性やブロック作成者選択に関わる要素であり、chain selection / fork choice も重要だと説明されています。

参考: Ethereum Documentation: Consensus mechanisms

つまり、PoWやPoSだけで「合意」が完成するわけではありません。

たとえば、次のような部品が組み合わさって、ブロックチェーンの履歴が成り立ちます。

要素	ざっくりした役割	PoW/PoSとの関係
検証ルール	その取引やブロックが正しい形式か確認する	PoW/PoS以前に、不正な取引を拒否する土台
ブロック作成者の選択	誰が次のブロックを提案するか決める	PoW/PoSが深く関係する
Sybil耐性	偽の参加者を大量に作っても影響力を安く増やせないようにする	PoW/PoSが特に関係する
フォーク選択	複数の履歴候補があるとき、どちらを採用するか決める	PoWでは累積作業量、PoSでは投票や重みが関係する
報酬・ペナルティ	正しい参加を促し、不正や不参加を抑える	PoWではマイニング報酬、PoSでは報酬・ペナルティ・slashingなど
ノード実装	ルールを実際に動かすソフトウェア	バグや偏りがあるとネットワーク全体のリスクになる

この表を見ると、PoW/PoSはとても重要ですが、全体の一部であることが分かります。

たとえば、PoWやPoSがうまく動いていても、利用者が秘密鍵を盗まれれば資産は失われます。
スマートコントラクトにバグがあれば、正しいコンセンサスの上で、バグを含んだ処理がそのまま実行されてしまう場合もあります。

そのため、この記事では次のように整理します。

PoWとPoSは、ブロックチェーンの履歴を守るための重要な仕組みです。
ただし、ウォレット、スマートコントラクト、取引所、ブリッジ、利用者の運用まで含めた安全性とは分けて考える必要があります。

8.2 Sybil攻撃：偽の参加者を大量に作る問題

PoW/PoSを情報セキュリティの観点で見るとき、最初に押さえたいのが Sybil攻撃 です。

Sybil攻撃とは、ざっくり言えば、1人の攻撃者が大量の偽アカウントや偽ノードを作り、まるで多数派であるかのように見せる攻撃です。

身近な例で言えば、クラスの投票で「1人1票」と決めていたのに、1人が偽名で100票入れられるような状況です。

仕組み	攻撃者がやりたいこと	問題点
単純な多数決	偽アカウントを大量に作って票を増やす	参加者数だけで決めると弱い
PoW	票の代わりに計算作業を要求する	偽アカウントを作っても、計算資源がなければ影響力を増やしにくい
PoS	票の代わりにステークを要求する	偽アカウントを作っても、ステーク量がなければ影響力を増やしにくい

Bitcoinホワイトペーパーでは、「1 IPアドレス1票」のような方式は、IPアドレスを大量に割り当てられる攻撃者に破られ得るため、PoWを「1 CPU 1票」のように使う考え方が示されています。

参考: Bitcoin Whitepaper

この発想は、PoWとPoSを比較するときにも重要です。

PoWでは、影響力を持つには計算資源が必要です。
PoSでは、影響力を持つにはステークが必要です。

つまり、どちらも 単にIDを増やすだけでは影響力を増やしにくくする ための設計です。

💡 豆知識
Sybil攻撃の「Sybil」は、複数の人格を持つ人物を扱った書籍名に由来すると説明されることがあります。
ブロックチェーンの文脈では、「1人がたくさんの参加者に見えるようにする攻撃」と考えると分かりやすいです。

8.3 51%攻撃は「何でもできる攻撃」ではない

PoWのセキュリティでよく出てくる言葉に 51%攻撃 があります。

これは、ネットワークの計算能力の過半を攻撃者が支配した場合、履歴の一部を作り直したり、特定の取引を承認されにくくしたりできる可能性がある、という攻撃です。

ただし、ここで誤解しやすいのは、51%攻撃が「何でもできる攻撃」ではないという点です。

51%攻撃で問題になり得ること	通常できないこと
自分の送金をなかったことにして二重支払いを狙う	他人の秘密鍵なしに勝手に署名する
特定の取引をブロックに入れにくくする	検証ルールを無視した無効な取引を通す
直近のブロックを再編成する	何年も前の履歴を低コストで自由に書き換える
自分に都合のよいチェーンを伸ばす	他人の残高を自由に移動する

Bitcoinホワイトペーパーでは、攻撃者が過去の取引を変更しようとする場合、そのブロック以降のPoWをやり直し、正直なノードのチェーンに追いついて追い越す必要があると説明されています。

参考: Bitcoin Whitepaper

PoSでも、似たように「過半の影響力」が問題になります。
Ethereum公式ドキュメントでは、PoSでも51%攻撃の脅威は存在し、攻撃者はステークされたETHの51%を必要とすると説明されています。さらに、攻撃者が持つステーク割合によって、finality delay、censorship、reorg、double finalityなど、起こり得る影響が変わると整理されています。

参考: Ethereum Documentation: Proof-of-stake FAQs
参考: Ethereum Documentation: Ethereum proof-of-stake attack and defense

ここで大切なのは、攻撃を「起こり得る / 起こり得ない」の二択で見るのではなく、どの程度の影響力を持つと、どのようなことが可能になるのか を分けて見ることです。

8.4 小さなコードで見る：攻撃リスクをざっくり分類する

ここでは、PoWとPoSの攻撃リスクを、かなり単純化したコードで分類してみます。

このコードは、実際のBitcoinやEthereumの安全性を評価するものではありません。
あくまで、「攻撃者の影響力が大きくなるほど、できることが増える」という感覚をつかむための学習用です。

# PoW/PoSの攻撃リスクをざっくり分類する学習用コードです。
# 実際のネットワーク安全性を評価するものではありません。
# 本物のリスク評価では、ノード数、クライアント実装、流動性、取引所、社会的対応なども考慮します。


def classify_pow_risk(hashpower_ratio):
    """
    攻撃者が持つハッシュパワー割合から、PoWでのリスクをざっくり分類します。

    hashpower_ratio:
        攻撃者が持つ計算能力の割合です。
        0.10 は 10%、0.51 は 51% を表します。
    """
    if hashpower_ratio < 0.33:
        return "直ちに多数派支配とは言いにくいが、ネットワーク規模によって注意が必要"
    if hashpower_ratio < 0.50:
        return "大きな影響力を持つ。小規模チェーンでは特に注意が必要"
    return "過半のハッシュパワーを持つため、二重支払いや検閲のリスクが高い"


def classify_pos_risk(stake_ratio):
    """
    攻撃者が持つステーク割合から、PoSでのリスクをざっくり分類します。

    stake_ratio:
        攻撃者が持つステーク割合です。
        0.33 は 33%、0.66 は 66% を表します。
    """
    if stake_ratio < 0.33:
        return "直ちにファイナリティ停止を起こす水準とは言いにくい"
    if stake_ratio < 0.50:
        return "ファイナリティ遅延など、ネットワーク運用上のリスクが高まる"
    if stake_ratio < 0.66:
        return "検閲やフォーク選択への影響が大きくなる可能性がある"
    return "非常に大きな影響力を持つ。履歴やファイナリティへの重大なリスクがある"


examples = [0.10, 0.34, 0.51, 0.67]

print("PoWの例:")
for ratio in examples:
    print(f"攻撃者のハッシュパワー: {ratio:.0%} -> {classify_pow_risk(ratio)}")

print("\nPoSの例:")
for ratio in examples:
    print(f"攻撃者のステーク: {ratio:.0%} -> {classify_pos_risk(ratio)}")

このコードでは、PoWではハッシュパワー、PoSではステーク割合を使って、リスクをざっくり分類しています。

もちろん、実際の攻撃可能性はこれだけでは決まりません。

たとえば、PoWではハッシュレートを一時的に借りられるか、マイニングプールがどのように分散しているか、取引所がどれくらい承認を待つかが関係します。
PoSでは、slashingの設計、社会的対応、クライアント分布、ステーキングサービスの集中、流動性などが関係します。

このコードで伝えたいのは、数字だけで安全・危険を断定することではありません。
攻撃者の影響力が増えると、どのようなリスクが増えるのかを段階的に見る ことです。

8.5 中央集権化はPoWにもPoSにもある

ブロックチェーンを学んでいると、「分散しているから安全」という説明をよく見かけます。

たしかに、分散性はブロックチェーンの重要な特徴です。
ただし、PoWでもPoSでも、実際の運用では中央集権化のリスクがあります。

観点	PoWでの集中リスク	PoSでの集中リスク
参加者	大規模マイナーやマイニングプールに集まる	大規模バリデータ、ステーキングプール、取引所ステーキングに集まる
コスト	専用機材、電力、設備、場所	まとまった資産、運用知識、安定したサーバー運用
収益	規模が大きいほど安定しやすい	規模が大きいほど運用効率やMEV対応で有利になる場合がある
セキュリティ上の懸念	マイニングプールが大きくなりすぎる	ステーキング事業者やクライアント実装が偏る

マイニングプールは、小さなマイナーが報酬を安定させるうえで役立ちます。
しかし、プールが大きくなりすぎると、ブロック作成に対する影響力が一部に偏る可能性があります。

PoSでも、個人でバリデータを運用するには資産や運用知識が必要です。
そのため、ステーキングプールや取引所などのサービスに参加者が集まりやすくなる場合があります。

Ethereum公式のMEV解説でも、PoS移行後のEthereumでは、32 ETHが個人にとって高いハードルになり得るためステーキングプール参加が現実的な選択肢になる一方、健全なsolo stakerの分布が分散性とセキュリティの面で望ましいと説明されています。

参考: Ethereum Documentation: Maximal extractable value (MEV)

ここで重要なのは、集中しているから即危険、分散しているから絶対安全、と単純に言えないことです。
集中には、運用効率や参加しやすさという面もあります。
ただし、影響力が一部に偏ると、検閲、障害、方針変更、規制対応、実装バグの影響が大きくなりやすい点には注意が必要です。

8.6 クライアント集中：同じ実装に偏るリスク

PoS、とくにEthereumを考えるときに重要なのが クライアント集中 です。

クライアントとは、ブロックチェーンのルールを実際に処理するソフトウェアです。
身近な例でいうと、同じWebサイトを見るためにChrome、Firefox、Safariなど複数のブラウザがあるように、Ethereumにも複数のクライアント実装があります。

もしネットワーク参加者の多くが、同じクライアントだけを使っていたらどうなるでしょうか。

そのクライアントに重大なバグがあった場合、多くのノードやバリデータが同じ間違いをしてしまう可能性があります。
逆に、複数の実装に分散していれば、1つの実装にバグがあっても、ネットワーク全体への影響を抑えやすくなります。

Ethereum公式ドキュメントでは、client diversity はバグや攻撃への耐性を高めるうえで重要であり、支配的なクライアントに偏ると、そのクライアントに対する攻撃やバグのリスクが高まると説明されています。

参考: Ethereum Documentation: Client diversity

状態	メリット	リスク
1つのクライアントに大きく偏る	情報やサポートが集中しやすい	その実装のバグが広範囲に影響する可能性
複数クライアントに分散する	1つの実装のバグに強くなりやすい	運用者は選定や更新情報の確認が必要
少数派クライアントも使われる	実装の多様性が高まる	ツールや情報が少ない場合がある

💡 豆知識
「分散性」は、単にノードの数だけでは測れません。
ノードの地理的分布、運用者の偏り、クライアント実装の偏り、クラウド事業者への依存、ステーキングサービスの集中など、いくつもの角度から見る必要があります。

8.7 検閲耐性：取引を入れない・遅らせる問題

情報セキュリティの観点では、検閲耐性 も重要です。

ここでいう検閲とは、ブロック作成者やネットワーク参加者が、特定の取引を意図的にブロックへ入れない、あるいは遅らせるような問題です。

身近な例でいうと、共有ノートの管理者が「この人の記録だけは書かせない」と言っているような状態です。
記録自体を改ざんしていなくても、記録に載せないことで影響を与えられます。

攻撃・問題	ざっくりした意味	影響
取引検閲	特定の取引をブロックに入れない	送金や操作が遅れる、または通りにくくなる
一時的な遅延	取引の取り込みを遅らせる	ユーザー体験や価格変動に影響する
ブロック作成者の偏り	一部の主体がブロック作成を支配する	検閲や順序操作のリスクが高まる
規制・方針による偏り	特定アドレスや取引への対応が偏る	パーミッションレス性に影響する可能性

Ethereum公式のPoS FAQでは、PoSが検閲耐性を持つのか、51%攻撃を受け得るのかといった論点が整理されています。

参考: Ethereum Documentation: Proof-of-stake FAQs

検閲耐性を見るときも、PoWだから絶対に強い、PoSだから必ず弱い、とは単純に言えません。
どちらの方式でも、ブロック作成者や大規模事業者が偏ると、特定の取引を入れない・遅らせるといったリスクは考えられます。

8.8 MEV：取引の順番もセキュリティ論点になる

ブロックチェーンでは、「どの取引を入れるか」だけでなく、どの順番で入れるか も重要です。

ここで出てくるのが MEV です。
MEVは Maximal Extractable Value の略で、ブロック内の取引を含める、除外する、順番を変えることで、通常のブロック報酬や手数料を超えて取り出せる価値を指します。

Ethereum公式ドキュメントでは、MEVはブロック内の取引を含める・除外する・順序を変えることで抽出される価値だと説明されています。
PoW時代には miner extractable value と呼ばれることがありましたが、The Merge後はバリデータがその役割に関わるため、より一般的に maximal extractable value と呼ばれるようになっています。

参考: Ethereum Documentation: Maximal extractable value (MEV)

身近な例で言うと、行列の順番をこっそり入れ替えて、自分に有利な順番で処理してしまうようなものです。

たとえば、分散型取引所で大きな注文が見えている場合、その前後に別の取引を差し込むことで利益を得るような行動が議論されます。
これは、ユーザーの取引価格や体験に悪影響を与える場合があります。

MEVに関係する観点	説明
取引の含め方	どの取引をブロックに入れるか
取引の除外	どの取引を入れないか
取引の順序	どの順番で実行するか
ユーザーへの影響	slippage、front-running、sandwich attackなどにつながる場合がある
ネットワークへの影響	ブロック再編成や中央集権化のインセンティブになり得る

Ethereum公式ドキュメントでは、MEVにはDeFiの価格調整や清算などに役立つ面がある一方、sandwich tradingのようにユーザー体験を悪化させるものや、ブロック再編成・コンセンサス安定性への悪影響があり得ることも説明されています。

参考: Ethereum Documentation: Maximal extractable value (MEV)

ここで大切なのは、MEVを「PoWかPoSか」だけの問題として見ないことです。
ブロックを作る人、取引を送る人、探索ボット、リレー、ビルダー、ウォレット、DeFiアプリなど、複数の層が関係します。

8.9 小さなコードで見る：セキュリティ論点をリスク表として整理する

ここまでの内容を、簡単なリスク表として整理してみます。

次のコードは、実際の監査やリスク評価に使うものではありません。
「PoW/PoSの記事で、どのような観点を分けて説明すべきか」を整理するための学習用コードです。

# PoW/PoS周辺のセキュリティ論点を、学習用のリスク表として整理するコードです。
# 実際のブロックチェーンやプロジェクトを評価するものではありません。
# 影響度や発生しやすさの点数は、説明のための仮の値です。

from dataclasses import dataclass
from typing import List


@dataclass
class SecurityRisk:
    """セキュリティ論点を表す簡単なデータクラスです。"""

    name: str          # リスク名
    layer: str         # どの層の話か
    pow_related: bool  # PoWと関係が深いか
    pos_related: bool  # PoSと関係が深いか
    impact: int        # 影響度。1が低く、5が高いという説明用の値です。
    likelihood: int    # 起こりやすさ。1が低く、5が高いという説明用の値です。
    note: str          # 説明メモ

    def score(self):
        """影響度と起こりやすさを掛け合わせて、説明用スコアを計算します。"""
        return self.impact * self.likelihood


risks: List[SecurityRisk] = [
    SecurityRisk(
        name="51%攻撃",
        layer="コンセンサス",
        pow_related=True,
        pos_related=True,
        impact=5,
        likelihood=2,
        note="PoWではハッシュパワー、PoSではステーク割合が重要になります。",
    ),
    SecurityRisk(
        name="マイニングプール集中",
        layer="参加者分布",
        pow_related=True,
        pos_related=False,
        impact=4,
        likelihood=3,
        note="PoWでブロック作成の影響力が一部のプールに偏る可能性があります。",
    ),
    SecurityRisk(
        name="ステーキング集中",
        layer="参加者分布",
        pow_related=False,
        pos_related=True,
        impact=4,
        likelihood=3,
        note="PoSでステーキングサービスや大規模バリデータに影響力が集まる可能性があります。",
    ),
    SecurityRisk(
        name="クライアント集中",
        layer="ノード実装",
        pow_related=True,
        pos_related=True,
        impact=5,
        likelihood=2,
        note="同じ実装に偏ると、バグの影響が広がりやすくなります。",
    ),
    SecurityRisk(
        name="秘密鍵漏えい",
        layer="ウォレット",
        pow_related=False,
        pos_related=False,
        impact=5,
        likelihood=3,
        note="PoW/PoSとは別に、利用者や運用者の鍵管理が重要です。",
    ),
    SecurityRisk(
        name="スマートコントラクトのバグ",
        layer="アプリケーション",
        pow_related=False,
        pos_related=False,
        impact=5,
        likelihood=3,
        note="コンセンサスが正しくても、コントラクトの処理にバグがあれば被害につながります。",
    ),
    SecurityRisk(
        name="MEV・取引順序操作",
        layer="ブロック構築",
        pow_related=True,
        pos_related=True,
        impact=4,
        likelihood=4,
        note="取引の含め方や順番が、ユーザー体験や公平性に影響する場合があります。",
    ),
]

# スコアが高い順に並べます。
# ただし、このスコアは説明用であり、実際のリスク評価ではありません。
for risk in sorted(risks, key=lambda item: item.score(), reverse=True):
    related = []
    if risk.pow_related:
        related.append("PoW")
    if risk.pos_related:
        related.append("PoS")
    if not related:
        related.append("PoW/PoS以外")

    print(f"{risk.name} [{risk.layer}]")
    print(f"  関係: {', '.join(related)}")
    print(f"  説明用スコア: {risk.score()}")
    print(f"  メモ: {risk.note}")
    print()

このコードを見ると、セキュリティ論点にはPoW/PoSそのものに近いものと、それ以外の層にあるものが混ざっていることが分かります。

たとえば、51%攻撃やマイニングプール集中、ステーキング集中は、PoW/PoSと直接関係します。
一方で、秘密鍵漏えいやスマートコントラクトのバグは、PoW/PoSとは別の層の問題です。

この区別は、ブロックチェーンのセキュリティを考えるうえでとても大切です。

8.10 PoW/PoSで防げること・防げないこと

ここまでの内容を、もう一度整理します。

PoWやPoSは、ブロックチェーンの履歴を守るための仕組みです。
しかし、すべての攻撃を防ぐわけではありません。

観点	PoW/PoSが関係すること	PoW/PoSだけでは防げないこと
履歴の一貫性	正しい履歴候補を選びやすくする	アプリのバグそのもの
Sybil耐性	影響力を安く増やしにくくする	秘密鍵の盗難
ブロック作成	誰がブロックを作るかに関わる	フィッシングサイトへの署名
フォーク選択	複数履歴から採用候補を選ぶ	取引所の内部不正
不正抑止	コストやペナルティで不正を高くつかせる	スマートコントラクトの設計ミス
検閲耐性	ブロック作成者の分散性と関係する	法規制・事業者運用による制限すべて

PoW/PoSを学ぶと、つい「どちらが安全か」という話に寄りがちです。
しかし、実際には次のように見る必要があります。

そのチェーンの参加者はどれくらい分散しているか
ノードやクライアント実装は偏っていないか
検証ルールは明確か
フォーク選択やファイナリティの仕組みはどうなっているか
鍵管理や運用は安全か
スマートコントラクトやブリッジに脆弱性はないか
利用者がフィッシングや署名詐欺に巻き込まれない設計になっているか

つまり、PoW/PoSは重要ですが、セキュリティ全体の入口 です。

8.11 セキュリティを見るときのチェックリスト

PoW/PoSを学んだあと、ブロックチェーンの安全性を見るときは、次のようなチェックリストを持っておくと整理しやすいです。

チェック項目	見るポイント
コンセンサス方式	PoWかPoSか、それ以外か。どのようなコストで不正を抑止しているか
フォーク選択	複数の履歴候補があるとき、どのように正しい履歴を選ぶか
ファイナリティ	どの時点で履歴が覆りにくくなるか
参加者分布	マイナー、マイニングプール、バリデータ、ステーキング事業者が偏っていないか
クライアント分布	1つの実装に依存しすぎていないか
鍵管理	バリデータ鍵、ウォレット秘密鍵、管理者鍵が安全に扱われているか
アプリ層	スマートコントラクトやフロントエンドに脆弱性がないか
周辺システム	取引所、ブリッジ、オラクル、RPC、クラウド環境に依存しすぎていないか
利用者保護	誤署名、フィッシング、詐欺への対策があるか

このように見ると、PoW/PoSは「どのコンセンサス方式が好きか」という話だけではありません。
システム全体のリスクを整理するための入り口になります。

💡 豆知識
ブロックチェーンの事故や被害は、必ずしもコンセンサス方式そのものが破られて起きるとは限りません。
実際には、スマートコントラクトのバグ、秘密鍵の漏えい、取引所やブリッジの管理、フィッシングなど、周辺部分が原因になることも多いです。
そのため、「チェーン自体の仕組み」と「その上で動くサービスや運用」は分けて見ることが大切です。

8.12 この章のまとめ

この章では、PoWとPoSを情報セキュリティの観点から整理しました。

PoWやPoSは、ブロックチェーンの履歴を守るための重要な仕組みです。
PoWは計算資源を、PoSはステークした資産をコストとして使い、不正をしにくくします。

ただし、それだけでブロックチェーン全体が安全になるわけではありません。

この章で押さえたいポイントは、次の通りです。

PoW/PoSは、ブロックチェーンの安全性の一部である
Sybil攻撃への耐性を考えるうえで、PoW/PoSは重要である
51%攻撃は「何でもできる攻撃」ではないが、二重支払い、検閲、履歴再編成などのリスクがある
PoWにもPoSにも、参加者や影響力の集中リスクがある
EthereumのPoSでは、クライアント多様性やステーキング集中も重要な論点になる
MEVのように、取引の順序や含め方もセキュリティ・公平性に関係する
秘密鍵漏えい、スマートコントラクトのバグ、フィッシング、取引所やブリッジの問題は、PoW/PoSだけでは防げない

PoWとPoSを理解することは、ブロックチェーンのセキュリティを考えるうえで大切な土台です。
ただし、実際の安全性は、コンセンサス、実装、運用、アプリ、利用者保護まで含めて見る必要があります。

次の章では、ここまでの内容を踏まえて、PoWとPoSについてよくある誤解を整理します。
「PoWはただの無駄な計算なのか」「PoSは完全に安全なのか」「ブロックチェーンは改ざん不可能なのか」といった、初学者がつまずきやすいポイントを確認していきます。

9. よくある誤解

この章では、PoWとPoSについてよくある誤解を整理します。
ポイントは、どちらか一方を「完全に良い」「完全に悪い」と見るのではなく、何を守るための仕組みで、どこに限界があるのかを分けて考えることです。

ここまで、PoWとPoSをかなり長めに見てきました。

PoWでは、計算作業にコストをかけることで、不正な履歴を作りにくくします。
PoSでは、資産を預けたバリデータに報酬とペナルティを与えることで、正しく参加する動機を作ります。

ただ、PoWやPoSは説明されるときに、かなり短い言葉でまとめられがちです。

たとえば、次のような説明を見かけることがあります。

PoWは電気を無駄にする仕組み
PoSはPoWの完全上位互換
PoSは電力を使わないから安全
51%攻撃が起きると何でもできる
ブロックチェーンは改ざん不可能

どれも、完全に意味がない説明ではありません。
しかし、そのまま覚えてしまうと、少し危険です。

PoWもPoSも、ブロックチェーンの安全性に関わる大事な仕組みです。
一方で、万能ではありません。

この章では、ここまでの内容を復習しながら、初学者がつまずきやすい誤解を一つずつ整理していきます。

9.1 誤解1：PoWはただの無駄な計算である

PoWについて、よくある説明の一つが「無駄な計算をしている」というものです。

たしかに、PoWでは大量のハッシュ計算を行います。
Bitcoinでは、条件を満たすブロックハッシュを見つけるために、nonceなどを変えながら何度も計算を試します。

Bitcoinのホワイトペーパーでも、PoWではブロックにnonceを追加し、ブロックのハッシュが必要な数の0ビットで始まる値になるまでnonceを増やす、と説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

この計算は、何かの画像を作ったり、科学計算をしたり、直接的に別の用途へ使われるものではありません。
その意味では、外から見ると「何度も試しているだけ」に見えます。

しかし、PoWの目的は、計算結果そのものを別の仕事に使うことではありません。

PoWの重要な役割は、ブロックを作るために現実のコストを払わせること です。

たとえば、会計ノートに誰でも無料で好きな記録を書き込めるとします。
その場合、悪意ある人が大量の偽記録を作って、正しい記録を埋もれさせることが簡単になります。

そこで、「次の記録を書くには、かなり手間のかかる作業を先に終える必要がある」というルールを置くと、不正な記録を大量に作るコストが上がります。

PoWは、この「手間のかかる作業」を計算によって実現していると考えると分かりやすいです。

見方	説明
表面的な見方	何度もハッシュを計算している
セキュリティ上の見方	不正な履歴を安く大量に作れないようにしている
攻撃者から見た意味	履歴を書き換えるには、多くの計算資源・電力・時間が必要になる

もちろん、PoWのエネルギー消費が大きな論点であることは事実です。
Ethereum公式ドキュメントでも、PoWはエネルギー消費が大きい点を批判として挙げており、Ethereumは2022年にPoWからPoSへ移行したと説明されています。

参考: Ethereum Documentation: Proof-of-work

そのため、記事では次のように書くのが安全です。

避けたい表現	より正確な表現
PoWはただの無駄な計算である	PoWは計算資源をコストにして、不正な履歴を作りにくくする仕組みである
PoWは悪い仕組みである	PoWには長く運用されてきた実績がある一方、エネルギー消費やマイニング集中などの課題がある

💡 豆知識
PoWの計算は「答えを見つけるのは大変、でも答えが合っているか確認するのは簡単」という性質を利用しています。
これは、難しいパズルを解くのは時間がかかるけれど、完成したパズルを見て「条件を満たしているか」を確認するのは比較的簡単、という感覚に近いです。

9.2 誤解2：PoSはPoWの完全上位互換である

次によくある誤解は、「PoSはPoWの完全上位互換である」というものです。

たしかに、PoSにはPoWと比べて大きな利点があります。
特に、電力消費を大きく抑えやすい点は分かりやすい違いです。

Ethereum公式は、The MergeによってEthereumがPoWからPoSへ移行し、エネルギー消費を約99.95%削減したと説明しています。

参考: Ethereum Roadmap: The Merge

しかし、だからといって「PoSはPoWの完全上位互換」と言い切るのは避けた方がよいです。

PoWとPoSでは、不正を抑止するために使うコストの種類が違います。

観点	PoW	PoS
主なコスト	計算資源、電力、設備、時間	預けた資産、報酬、ペナルティ
代表的な参加者	マイナー	バリデータ
不正時に失うもの	電力・設備投資・機会損失など	ステークした資産、報酬、信用など
代表例	Bitcoin	現在のEthereum
注意点	エネルギー消費、マイニング集中	ステーク集中、弱主観性、実装・運用の複雑さ

PoSは、計算競争を減らしやすい一方で、ステーク集中、バリデータ運用、クライアント集中、slashing、weak subjectivityなど、別の論点を持ちます。

Ethereum公式でも、PoSはPoWよりエネルギー効率が高く、いくつかの攻撃に対するコストを高めると説明される一方で、PoS特有の設計や運用上の論点も扱われています。

参考: Ethereum Documentation: Proof-of-stake

つまり、PoWとPoSは単純な上下関係ではなく、コストの置き方が違う設計 と見る方が自然です。

避けたい表現	より正確な表現
PoSはPoWの完全上位互換	PoSは、計算資源ではなくステークを中心に不正を抑止する別設計の仕組み
PoWは古いので不要	PoWはBitcoinなどで使われ続けている一方、エネルギー消費などの課題がある
PoSならすべて解決する	PoSでは、ステーク集中や運用・実装の複雑さなど別の注意点がある

9.3 誤解3：PoSは電力を使わないので完全に安全である

PoSは、PoWのような大規模な計算競争を必要としにくいため、エネルギー消費を大きく抑えやすい仕組みです。

この点は大きな利点です。
しかし、「電力消費が少ない = 完全に安全」と考えるのは早すぎます。

PoSの安全性は、電力ではなく、主にステークした資産、報酬、ペナルティ、slashing、ファイナリティなどの設計によって支えられます。

Ethereum公式では、バリデータが正しく参加すると報酬を得る一方、不適切な行動にはペナルティがあり、同じslotに複数ブロックを提案する、矛盾するattestationを行うなどの重大な違反はslashing対象になり得ると説明されています。

参考: Ethereum Documentation: Rewards and penalties

つまり、PoSのセキュリティは「電気をあまり使わないから安全」なのではありません。

むしろ、次のような設計によって不正を抑止します。

正しく参加すると報酬がもらえる
オフラインや不参加が続くと報酬を逃したり、ペナルティを受けたりする
重大な違反をすると、ステークの一部を失う可能性がある
多くのステークを支配しないと、ネットワークに大きな影響を与えにくい
ファイナリティによって、履歴が覆りにくくなる地点を作る

ただし、PoSにも注意点があります。

注意点	説明
ステーク集中	少数の事業者や参加者にステークが偏ると、影響力が集中する可能性がある
クライアント集中	同じクライアント実装に偏ると、バグや攻撃の影響が広がりやすい
弱主観性	新規参加ノードや長期間オフラインだったノードが、信頼できるcheckpointを確認する必要がある
運用ミス	バリデータ鍵の管理や設定ミスがペナルティにつながる可能性がある

Ethereum公式は、client diversityがネットワークの強さに関わる重要な要素だと説明しています。

参考: Ethereum Documentation: Client diversity

そのため、PoSについては次のように理解するとバランスがよいです。

PoSはPoWと比べてエネルギー消費を抑えやすい一方で、ステーク集中、クライアント集中、運用、ペナルティ設計など、別の観点から安全性を見る必要があります。

9.4 誤解4：51%攻撃が起きると何でもできる

51%攻撃という言葉は、PoWやPoSの話でよく出てきます。

この言葉だけを見ると、「過半数を取られたら何でも好き放題できる」と感じるかもしれません。
しかし、実際にはもう少し分けて考える必要があります。

PoWでは、攻撃者がネットワークの計算能力の過半に近い力を持つと、正直なチェーンに追いついたり、特定の取引を含めないようにしたり、二重支払いを狙ったりするリスクが高まります。

Bitcoinのホワイトペーパーでは、攻撃者が正直なノードよりも多くのCPUパワーを持たない限り、正直なチェーンが最も速く伸びると説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

一方で、51%攻撃があっても、通常の検証ルールを無視して何でもできるわけではありません。

たとえば、次のようなことは通常できません。

他人の秘密鍵なしに、その人の資産を自由に送る
プロトコルの発行ルールを破って、無限に通貨を増やす
明らかに無効な取引を、全ノードに有効な取引として認めさせる

ノードは、ブロック作成者が出したブロックをそのまま信じるわけではありません。
検証ルールに合っているかを確認し、無効なブロックは拒否します。

PoSでも、攻撃者がどれくらいのステークを持つかによって、できることやリスクは変わります。
Ethereum公式では、攻撃者が持つステーク割合に応じて、finality delay、double finality、検閲、過去を含む履歴への影響などが整理されています。

参考: Ethereum Documentation: Proof-of-stake attack and defense

誤解	実際に分けて考えたいこと
51%攻撃なら何でもできる	二重支払い、検閲、履歴再編成などは問題になり得るが、無効な取引を自由に有効化できるわけではない
過半を取られたらすべての資産が盗まれる	秘密鍵なしに他人の資産を勝手に送ることは通常できない
51%未満なら完全に安全	小さな割合でも、検閲や一時的な混乱など別のリスクがある場合がある

つまり、51%攻撃は重大なリスクです。
ただし、「何でもできる万能攻撃」として説明すると、少し雑になってしまいます。

9.5 誤解5：ブロックチェーンは改ざん不可能である

ブロックチェーンの説明では、「改ざん不可能」という言葉がよく使われます。

たしかに、ブロックチェーンは過去の記録を書き換えにくくする仕組みを持っています。
各ブロックは前のブロックの情報とつながっており、過去のブロックを書き換えると、その後ろのブロックとのつながりも崩れます。

NISTIR 8202でも、ブロックチェーンは改ざんを検知しやすく、改ざん耐性を持つデジタル台帳として説明されています。

参考: NISTIR 8202: Blockchain Technology Overview

ただし、「改ざん不可能」と言い切ると、強すぎる表現になります。

より正確には、ブロックチェーンは 過去の履歴を書き換えるコストを高め、改ざんに気づきやすくする仕組み です。

強すぎる表現	より正確な表現
ブロックチェーンは改ざん不可能	ブロックチェーンは、過去の履歴を書き換えるコストを高め、改ざんを検知しやすくする
一度書かれた記録は絶対に変わらない	チェーンや状況によっては、フォークや再編成が起こる場合がある
ブロックに入ったら完全確定	承認数やファイナリティの考え方によって、覆りにくさが変わる

BitcoinのようなPoWでは、後ろにブロックが積み重なるほど、過去を書き換えるために必要な作業量が増えます。
EthereumのPoSでは、ファイナリティという考え方があり、正当化・確定されたブロックが覆りにくくなる仕組みがあります。

参考: Ethereum Documentation: Proof-of-stake

そのため、本記事では「改ざん不可能」ではなく、できるだけ 改ざんしにくい、改ざんを検知しやすい、過去を書き換えるコストを高める という表現を使います。

9.6 誤解6：PoW/PoSだけでコンセンサスがすべて決まる

PoWやPoSは、よく「コンセンサス方式」と呼ばれます。

この表現は間違いではありません。
ただし、厳密に見ると、PoW/PoSだけでブロックチェーンの合意形成がすべて決まるわけではありません。

Ethereum公式ドキュメントでは、PoWやPoSは簡略的にコンセンサスプロトコルと呼ばれることがあるものの、実際にはSybil耐性やブロック作成者を選ぶ仕組みであり、chain selection、つまりfork choiceも重要だと説明されています。

参考: Ethereum Documentation: Consensus mechanisms

もう一度、会計ノートの例に戻って考えてみます。

会計ノートを共同管理するには、単に「誰が次に書くか」だけでは足りません。

どの形式の記録を有効とみなすか
誰が次に記録を追加してよいか
同時に2つの記録が出てきたら、どちらを採用するか
不正な記録を書いた人にどのようなペナルティを与えるか
どの時点で記録がほぼ確定したと見るか

このように、合意形成には複数の部品があります。

部品	ざっくりした役割
検証ルール	その取引やブロックが有効かを判断する
Sybil耐性	偽の参加者を大量に作って影響力を増やす攻撃を防ぎやすくする
ブロック作成者選択	誰が次のブロックを作るかを決める
フォーク選択	複数の履歴候補があるとき、どれを採用するかを決める
報酬・ペナルティ	正しく参加する動機、不正を避ける動機を作る
ファイナリティ	履歴が覆りにくくなる地点を作る

PoWとPoSは、この中でも特に Sybil耐性 や ブロック作成者選択 に深く関係します。

そのため、記事では次のように書くと誤解が少なくなります。

PoWとPoSは、ブロックチェーンの合意形成に関わる重要な仕組みです。
ただし、合意形成全体には、検証ルール、フォーク選択、報酬・ペナルティ、ファイナリティなども関係します。

9.7 誤解7：PoSではお金持ちが毎回必ず勝つ

PoSはステーク量に応じて影響力を持つため、「お金持ちが毎回必ず勝つ仕組み」と思われることがあります。

この見方には、半分正しい部分があります。
PoSでは、ステーク量が多いほど、ブロック提案や検証に関わる機会が増えやすくなります。

Ethereum公式でも、PoSではバリデータがETHをステークし、ブロック提案や検証に参加すると説明されています。

参考: Ethereum Documentation: Proof-of-stake

ただし、だからといって「一番多くステークしている人が毎回必ず決める」というわけではありません。

EthereumのPoSでは、時間はslotとepochに分かれ、各slotでブロック提案者が選ばれます。
また、他のバリデータもattestationを通じてブロックやチェーンの選択に関わります。

誤解	実際の見方
一番ステークが多い人が毎回ブロックを作る	ステーク量は選ばれやすさに関係するが、実際にはプロトコルに従って提案者が選ばれる
少額参加者は完全に無意味	単独バリデータ以外にも、プールや委任などチェーンごとの参加形態がある。ただし集中リスクには注意が必要
PoSではお金持ちは絶対に損しない	不正や重大な運用ミスがあれば、slashingやペナルティで損失が発生し得る

もちろん、ステーク集中はPoSの重要な課題です。
少数の事業者や大口参加者にステークが偏ると、ネットワークの分散性や検閲耐性に影響する可能性があります。

そのため、PoSについては次のように整理できます。

PoSではステーク量が影響力に関係します。
ただし、「一番資産を持つ人が毎回自由に決める」という単純な仕組みではなく、プロトコル上の選出、投票、報酬、ペナルティ、slashingなどが組み合わさっています。

9.8 誤解8：マイナーやバリデータは取引内容を自由に変えられる

マイナーやバリデータは、ブロック作成に関わる重要な参加者です。

そのため、「マイナーやバリデータなら、他人の取引内容を自由に書き換えられるのでは？」と思うかもしれません。

しかし、通常はそうではありません。

ブロックチェーンでは、取引は署名によって本人の意思を示します。
他人の秘密鍵を持っていない人が、その人の資産を自由に動かす正当な取引を作ることはできません。

マイナーやバリデータが主に関わるのは、次のような部分です。

関わる部分	説明
どの取引をブロックに含めるか	手数料や方針に応じて、取引を選ぶことがある
取引の順番	ブロック内でどの順序に並べるかが問題になる場合がある
ブロック提案	条件を満たすブロックや、プロトコルに従ったブロックを提案する
検証	他の参加者が、そのブロックや取引がルールに合っているか確認する

一方で、次のようなことは通常できません。

他人の署名済み取引の送金先を勝手に変更する
他人の秘密鍵なしに、その人の資産を送る
検証ルールに反する無効な取引を、全員に有効と認めさせる

ただし、取引を含めない、遅らせる、順番を変えるといった問題はあり得ます。
前章で触れたMEVや検閲耐性は、このあたりに関係します。

Ethereum公式では、MEVを、ブロック内の取引を含める、除外する、順序を変えることで、標準的なブロック報酬やガス代とは別に抽出される価値として説明しています。

参考: Ethereum Documentation: Maximal extractable value

つまり、マイナーやバリデータは強い役割を持ちますが、「他人の取引を何でも自由に書き換える人」ではありません。

9.9 誤解9：ファイナリティがあれば絶対に覆らない

PoSを学ぶと、ファイナリティ という言葉が出てきます。

ファイナリティは、ざっくり言えば「その履歴がかなり覆りにくくなった状態」を表す言葉です。

ただし、ここでも「絶対に覆らない」と表現すると強すぎます。

EthereumのPoSでは、checkpointがjustified、finalizedといった状態になる仕組みがあります。
ファイナライズされたブロックを覆そうとすると、多くのバリデータがslashing対象になるような重大な状況が関係します。

参考: Ethereum Documentation: Proof-of-stake

そのため、初学者向けには次のように説明すると分かりやすいです。

表現	注意点
完全に確定する	強すぎる。システム上の例外や社会的対応を無視しやすい
覆りにくくなる	初学者向けには安全な表現
経済的に覆しにくくなる	PoSのslashingやステーク損失とつなげやすい
実用上ほぼ確定と扱われる	用途やチェーンによって確認基準が異なることを示せる

PoWでもPoSでも、どの時点で「十分安心」と見るかは、チェーン、取引額、用途、リスク許容度によって変わります。

たとえば、少額の支払いなら数ブロックで十分と考える場面があるかもしれません。
一方で、大きな金額や重要な処理では、より長く待ったり、ファイナリティを確認したりする必要があります。

ファイナリティはとても重要な考え方ですが、「絶対」という言葉を使わず、覆りにくさの度合い として理解する方が安全です。

9.10 小さなコードで見る：強すぎる表現を見つける

ここまで見てきたように、PoWやPoSを説明するときは、強すぎる表現を避けることが大切です。

たとえば、次のような表現は、記事を書くときに注意したい言葉です。

絶対に安全
完全に改ざん不可能
必ず防げる
何でもできる
完全上位互換

もちろん、文脈によっては使える場合もあります。
しかし、技術記事では、こうした表現を見つけたら「本当にそこまで言い切れるか？」と確認した方がよいです。

ここでは、Markdown文章の中から強すぎる表現を簡単に探す学習用コードを書いてみます。

# これは技術記事を書くときに、強すぎる表現を簡易チェックするための学習用コードです。
# 実際の校正ツールではありませんが、断定しすぎを見直す入口として使えます。

# チェック対象の文章です。
# 実際には、自分が書いたMarkdown本文をここに入れる想定です。
draft_text = """
PoWはただの無駄な計算です。
PoSはPoWの完全上位互換です。
ブロックチェーンは完全に改ざん不可能です。
51%攻撃が起きると何でもできます。
"""

# 技術記事で強すぎる可能性がある表現をリストにします。
# ここに入っている言葉が必ず間違いという意味ではありません。
# 見つかったら、根拠や文脈を確認するための目印として使います。
strong_phrases = [
    "ただの無駄",
    "完全上位互換",
    "完全に安全",
    "完全に改ざん不可能",
    "絶対に",
    "必ず",
    "何でもできます",
    "何でもできる",
]

# 見つかった表現を保存するためのリストです。
findings = []

# 1行ずつ確認します。
for line_number, line in enumerate(draft_text.splitlines(), start=1):
    # 各行に強すぎる表現が含まれていないか確認します。
    for phrase in strong_phrases:
        if phrase in line:
            findings.append({
                "line": line_number,
                "phrase": phrase,
                "text": line.strip(),
            })

# 結果を表示します。
# 見つかった表現は、より慎重な表現に直せないか確認します。
for item in findings:
    print(f"{item['line']}行目: '{item['phrase']}' が含まれています")
    print(f"  対象文: {item['text']}")
    print("  確認: 根拠を示せるか、より慎重な表現にできるか見直しましょう。")
    print()

このコードは、PoW/PoSの仕組みを実装するものではありません。
あくまで、記事を書くときの表現チェックをイメージするためのものです。

技術記事では、正しさそのものだけでなく、どこまで言い切ってよいか も大切です。
特にブロックチェーンのように、設計・実装・運用・経済的インセンティブが絡む分野では、強い断定を避ける姿勢が読み手の信頼につながります。

9.11 よくある誤解を一枚で整理する

ここまでの内容を、表でまとめます。

よくある誤解	より正確な見方
PoWはただの無駄な計算	PoWは計算資源をコストにして、不正な履歴を作りにくくする仕組み。ただしエネルギー消費は大きな論点
PoSはPoWの完全上位互換	PoSはステークをコストにする別設計。省エネルギー化しやすい一方、ステーク集中や運用の複雑さがある
PoSは電力を使わないから完全に安全	PoSの安全性は報酬、ペナルティ、slashing、ファイナリティなどの設計に支えられる
51%攻撃なら何でもできる	二重支払い、検閲、履歴再編成などのリスクはあるが、他人の秘密鍵なしに資産を自由に動かせるわけではない
ブロックチェーンは改ざん不可能	改ざんを検知しやすくし、過去を書き換えるコストを高める仕組みと考える方が正確
PoW/PoSだけでコンセンサスが完結する	検証ルール、フォーク選択、報酬・ペナルティ、ファイナリティなども関係する
PoSではお金持ちが毎回必ず決める	ステーク量は影響力に関係するが、選出・投票・ペナルティなどのルールが組み合わさる
マイナーやバリデータは取引を自由に書き換えられる	取引の採用や順序に影響する場合はあるが、他人の署名済み取引を自由に変更できるわけではない
ファイナリティがあれば絶対に覆らない	実用上かなり覆りにくくなるが、「絶対」というより経済的・プロトコル的に覆しにくい状態として見る

この表を見ると、PoWとPoSの理解で大切なのは、単語を丸暗記することではないと分かります。

重要なのは、次の問いを持つことです。

何を守るための仕組みなのか
不正をすると何を失うのか
どの層の安全性に関係しているのか
どこから先はPoW/PoSだけでは防げないのか
チェーンや実装によって違う部分はどこか

この問いを持っておくと、PoW/PoSに関するニュースや技術記事を読んだときも、表面的な比較だけでなく、少し落ち着いて整理しやすくなります。

9.12 この章のまとめ

この章では、PoWとPoSについてよくある誤解を整理しました。

PoWは、ただ無意味に計算しているわけではありません。
計算資源や電力をコストとして使うことで、不正な履歴を安く作れないようにする仕組みです。

一方で、PoSも「PoWの完全上位互換」や「電力を使わないから完全に安全」とは言い切れません。
PoSは、ステークした資産、報酬、ペナルティ、slashing、ファイナリティなどを組み合わせて、不正をしにくくする仕組みです。

この章で押さえたいポイントは、次の通りです。

PoWは「ただの無駄な計算」ではなく、不正コストを高めるための計算作業である
PoSはPoWの完全上位互換ではなく、ステークを中心にした別設計である
PoSは省エネルギー化しやすいが、ステーク集中や運用上の注意点がある
51%攻撃は重大だが、何でもできる万能攻撃ではない
ブロックチェーンは「改ざん不可能」ではなく、改ざんを検知しやすくし、書き換えコストを高める仕組みである
PoW/PoSだけでコンセンサス全体が完結するわけではない
技術記事では、「絶対」「完全」「必ず」といった強い表現を慎重に扱う必要がある

ここまでで、PoWとPoSの仕組み、比較、セキュリティ上の注意点、よくある誤解を整理できました。

次の章では、PoWとPoSに関する最近の動向を確認します。
EthereumのPoS移行、ステーキングの広がり、クライアント多様性、エネルギー消費、規制や運用面の論点など、今後も学び続けるうえで押さえておきたいポイントを整理していきます。

10. 最近の動向

この章では、PoWとPoSに関する最近の動向を整理します。
ポイントは、「PoWからPoSへ移ったチェーンがある」だけで終わらせず、PoWが今も使われている領域、PoS移行後に見えてきた運用課題、ステーキングの変化、クライアント多様性、規制・制度面の確認ポイントまで分けて見ることです。

ここまでで、PoWとPoSの基本的な考え方、比較、セキュリティ上の注意点、よくある誤解を整理してきました。

最後に、最近の動向を確認しておきます。

ブロックチェーンの分野では、「ある時点では正しかった説明」が、数年後には少し古くなることがあります。
特にEthereumのように継続的にアップグレードされるチェーンでは、コンセンサス方式そのものだけでなく、ステーキング、バリデータ運用、クライアント、Layer 2との関係も変化していきます。

一方で、BitcoinのようにPoWを中心に長く運用されているチェーンもあります。
そのため、「最近はPoSが主流だからPoWは古い」と一言で片付けるのではなく、どのチェーンが、どの目的で、どのような設計を採用しているのか を見ることが大切です。

この章では、次の観点で整理します。

EthereumはPoWからPoSへ移行した
EthereumではPoS移行後も、ステーキングやバリデータ運用が継続的に変化している
BitcoinではPoWが今も中核的な仕組みとして使われている
PoSではステーキング集中、クライアント集中、バリデータ運用の複雑さが論点になる
PoWではエネルギー消費やマイニング集中が引き続き論点になる
規制・制度面では、ステーキングサービスやVASP、トラベルルールなども確認が必要になる
今後の記事更新では、公式情報を見ながら書き換える必要がある

10.1 EthereumはPoWからPoSへ移行した

最近のPoW/PoSを語るうえで、まず押さえておきたいのがEthereumの移行です。

Ethereumは、もともとPoWを使っていました。
しかし、2022年9月15日に実行された The Merge によって、EthereumはPoWを廃止し、PoSへ移行しました。

Ethereum公式ドキュメントでは、The Mergeについて、EthereumのPoSへの移行を完了し、PoWを正式に廃止したアップグレードだと説明しています。
また、この移行によってEthereumのエネルギー消費は約99.95%削減されたと説明されています。

参考: Ethereum.org: The Merge

ここで注意したいのは、The Mergeは「Ethereumが全部新しい別チェーンになった」というより、Ethereumの実行レイヤーと、PoSを担うBeacon Chainが統合された出来事として理解すると分かりやすいです。

かなり単純化すると、次のようなイメージです。

The Merge後のEthereumでは、マイナーではなく、ETHをステークしたバリデータがブロック提案や検証に関わります。
Ethereum公式のPoS解説でも、Ethereumが2022年にPoSへ移行したこと、PoSではバリデータがステークをもとにブロック提案や検証へ参加することが説明されています。

参考: Ethereum.org: Proof-of-stake

ただし、ここで「EthereumがPoSに移ったから、PoWはもう不要」とは言い切れません。
Bitcoinのように、PoWを中核にしているチェーンは今も存在します。

Ethereumの移行は、特定のチェーンが、自分たちの設計目標に合わせてPoSへ移行した例 として見るのが自然です。

💡 豆知識
The Mergeという名前から「Ethereumが何かと合体した」という印象を受けるかもしれません。
実際には、PoWで動いていたEthereumの実行レイヤーと、PoSの土台として先に稼働していたBeacon Chainが統合されたアップグレードです。
そのため、The Mergeは「PoWからPoSへ切り替わった歴史的なイベント」としてよく紹介されます。

10.2 PoS移行後も、Ethereumのアップグレードは続いている

EthereumはPoSへ移行して終わりではありません。
The Merge後も、ステーキング、バリデータ運用、Layer 2の拡張、アカウント抽象化、データ可用性など、さまざまな改善が続いています。

たとえば、EthereumのShanghai/Capellaアップグレードでは、ステーキングしたETHの引き出しが可能になりました。
Ethereum公式のstakingページでも、Shanghai/Capella upgradeが2023年4月12日に完了し、staking withdrawalsが可能になったことが説明されています。

参考: Ethereum.org: Ethereum staking

これは、PoSの運用を考えるうえで重要です。

PoSでは、バリデータが資産を預けてネットワークに参加します。
そのため、「預けた資産をいつ、どのように引き出せるのか」は、バリデータ運用やステーキングサービスにとって大きな関心事になります。

さらに、2025年のPectraアップグレードでは、validator experienceに関わる改善も入りました。
Ethereum公式のPectra解説では、EIP-7251により、バリデータのmaximum effective balanceが2048 ETHまで引き上げられ、複数バリデータの集約や運用効率化につながることが説明されています。

参考: Ethereum.org: Prague-Electra (Pectra)

ここで大切なのは、PoSは単に「32 ETHを預ければ終わり」という静的な仕組みではないことです。
実際には、ネットワークアップグレードによって、バリデータの運用方法、報酬の扱い、引き出し、集約、ネットワーク負荷などが変わっていきます。

表で整理すると、次のようになります。

動向	ざっくりした意味	PoS理解との関係
The Merge	EthereumがPoWからPoSへ移行	PoSがEthereumの中核になった
Shanghai/Capella	staking withdrawalsが可能に	預けたETHの引き出しが運用上の論点になった
Pectra	validator experienceや有効残高などを改善	ステーキング運用の効率化・柔軟化に関係する
今後のロードマップ	scaling、finality、statelessnessなど	PoSだけでなく、周辺設計も進化し続ける

PoSを学ぶときは、最初に「資産を預けてバリデータとして参加する」という基本を押さえれば十分です。
ただし、実際のEthereumを見る場合は、アップグレードによって細部が変わるため、公式情報を確認する必要があります。

10.3 BitcoinではPoWが今も中核にある

一方で、BitcoinではPoWが今も中核的な仕組みです。

Bitcoinのホワイトペーパーでは、信頼できる第三者なしに二重支払いを防ぐため、P2Pネットワーク上でハッシュベースのPoWを使うことが説明されています。
また、Bitcoin Developer Guideでは、ブロックをつなげることで、あるブロック内の取引を変更するには後続ブロックも変更する必要があり、ブロックが追加されるほど変更コストが大きくなると説明されています。

参考: Bitcoin Whitepaper
参考: Bitcoin Developer Guide: Block Chain

ここで見えてくるのは、PoWが単なる古い方式ではなく、Bitcoinの設計思想や運用と深く結びついていることです。

PoWでは、ブロックを作るために計算資源と電力を使います。
そのため、エネルギー消費やマイニング設備の集中は大きな論点になります。

一方で、PoWは「外側のコスト」、つまり電力・設備・計算資源を使って不正をしにくくする仕組みとして理解できます。
PoSがステークした資産をコストにするのに対し、PoWは現実世界の資源をコストにする、という違いがあります。

観点	BitcoinのPoWで見るポイント
不正抑止	過去を書き換えるには大きな計算コストが必要になる
参加者	minerが計算作業を通じてブロック作成に参加する
フォーク選択	累積されたPoWが重要になる
主な論点	エネルギー消費、マイニングプール集中、専用機材、地域集中
学ぶときの注意	EthereumのPoS移行を、Bitcoinにもそのまま当てはめない

Bitcoinを理解するときは、PoWを「昔の仕組み」として片付けるのではなく、Bitcoinの安全性や分散性を支える重要な部品として見る必要があります。

10.4 エネルギー消費はPoWを考えるうえで避けられない論点

PoWの最近の動向で、よく出てくるのがエネルギー消費です。

Ethereum公式のPoW解説では、PoWは安全性を維持するために大きなエネルギーを必要とし、EthereumがPoSへ移行する前には年間約70TWhを消費していたと説明されています。
また、The MergeによってEthereumのエネルギー消費は約99.95%削減されたと説明されています。

参考: Ethereum.org: Proof-of-work
参考: Ethereum.org: The Merge

ここで注意したいのは、PoWのエネルギー消費を「ただ悪い」とだけ見ると、仕組みの理解が浅くなることです。

PoWでは、計算作業に現実のコストをかけることによって、不正な履歴を安く作れないようにしています。
つまり、エネルギー消費はPoWの安全性と無関係な副作用ではなく、仕組みそのものと結びついています。

ただし、社会的・環境的な観点では、当然大きな論点になります。

見方	内容
技術的な見方	計算作業をコストにすることで、不正な履歴を作りにくくする
経済的な見方	マイニング設備、電力、運用コストが参加条件に関係する
環境的な見方	大量の電力消費が社会的な議論になる
セキュリティ上の見方	ハッシュパワーが特定の地域・事業者・プールに集中しないかを見る

PoWを記事で扱うときは、エネルギー消費を軽く見すぎても、逆にPoW全体を単純に否定しすぎても、バランスを欠いてしまいます。

この記事では、PoWを次のように表現すると伝わりやすくなります。

PoWは、計算資源と電力という現実世界のコストを使って、不正な履歴を作りにくくする仕組みです。
その一方で、エネルギー消費やマイニング集中は、PoWを考えるうえで避けられない重要な論点です。

10.5 PoSではステーキング集中と運用の複雑さが論点になる

PoSでは、PoWのような大きな計算競争を行わないため、エネルギー消費を抑えやすいという利点があります。
しかし、PoSにも別の注意点があります。

代表的なのが、ステーキング集中です。

PoSでは、ステーク量がブロック提案や検証への参加に関係します。
そのため、ステーキングサービス、取引所、リキッドステーキング、バリデータ運用事業者などにステークが集中すると、ネットワークの分散性や検閲耐性の観点で注意が必要になります。

また、PoSは報酬、ペナルティ、slashing、finality、weak subjectivity、クライアント多様性など、考える要素が多くなりがちです。

Ethereum公式のclient diversityページでは、複数のクライアント実装が存在することが、バグや攻撃への耐性を高めるうえで重要だと説明されています。
もし大多数のバリデータが同じクライアントに偏っていると、そのクライアントのバグがネットワーク全体へ大きな影響を与える可能性があります。

参考: Ethereum.org: Client diversity

PoSの注意点を整理すると、次のようになります。

論点	ざっくりした意味	なぜ重要か
ステーク集中	少数の主体にステークが偏る	検閲耐性やガバナンス上の懸念につながる可能性がある
ステーキングサービス集中	利用者が特定サービス経由で参加する	サービス障害・規制・運用ミスの影響が大きくなる可能性がある
クライアント集中	同じ実装を多くのノードが使う	バグが広範囲に影響する可能性がある
slashingリスク	重大な違反でステークを失う	運用ミスや設定ミスもリスクになる
weak subjectivity	新規・長期停止ノードが最近の正しい状態を確認する必要がある	PoWとは異なる信頼の置き方が必要になる

PoSを「省エネルギーだから安全」とだけ見るのではなく、運用・実装・集中リスクまで含めて見る ことが大切です。

💡 豆知識
PoSでは「電気代」よりも「運用ミス」が目立つ場面があります。
たとえば、バリデータを二重に動かしてしまう、鍵管理を誤る、同じクライアントに偏る、といった問題です。
つまりPoSでは、マシンを速くするだけでなく、正しく・安定して・安全に運用する力も重要になります。

10.6 規制・制度面ではステーキングサービスやVASPも確認が必要になる

PoW/PoSは技術的な仕組みですが、実際の利用や運用では制度面も関係します。

特にPoSでは、個人が自分でバリデータを運用するだけでなく、取引所、カストディアン、ステーキングサービス、リキッドステーキングなどを通じて参加するケースがあります。
そのため、技術的なPoSの理解とは別に、サービス利用時のリスクや規制上の位置づけも確認が必要になります。

暗号資産分野では、FATFがVirtual AssetsやVASPに関するAML/CFT基準の実装状況を継続的に更新しています。
また、日本の金融庁も、暗号資産や電子決済手段の移転におけるトラベルルールの対象法域などを更新しています。

参考: FATF: Virtual Assets
参考: 金融庁: トラベルルールの対象法域について

ここで大切なのは、この記事で扱うPoW/PoSの技術理解と、実際のサービス利用・法的判断は分けることです。

観点	記事で扱うこと	記事で扱わないこと
技術理解	PoW/PoSがどのように不正コストを設計しているか	特定サービスの利用推奨
セキュリティ	中央集権化、クライアント集中、51%攻撃、slashingなど	個別事件の法的判断
規制・制度	VASPやトラベルルールなど、確認が必要な論点があること	法律上の助言
運用	ステーキングサービス利用時には委任先・管理方法を確認する必要があること	ステーキング利回りや投資判断

ここを深追いしすぎると、PoW/PoS本体から話が離れてしまいます。
そのため、本記事では「制度やサービス利用の話は変化しやすいので、投稿時点の公式情報を確認する」という注意に留めます。

10.7 今後も注目したい技術テーマ

PoW/PoSを理解したあとに、さらに深掘りしやすいテーマを整理しておきます。

テーマ	ざっくりした内容	PoW/PoSとの関係
Finality	ある履歴がどれくらい覆りにくいか	PoSではfinalityの考え方が特に重要になる
Single Slot Finality	1 slotでfinalityを得ることを目指す考え方	Ethereumロードマップ上の重要テーマの一つ
MEV	取引の順序・採用・除外から生じる価値	ブロック提案者や検閲耐性と関係する
Client Diversity	複数クライアントを使う重要性	PoSの安全性・障害耐性と関係する
Liquid Staking	ステークした資産の流動性を高める仕組み	ステーキング集中の論点にも関係する
Layer 2 / Rollup	メインチェーン外で処理を増やす仕組み	EthereumのPoS移行後のスケーリング文脈と関係する
Post-quantum security	量子コンピュータへの備え	長期的なブロックチェーン安全性に関係する

Ethereum公式ロードマップでも、今後の技術テーマとしてSingle Slot Finality、Post-quantum security、Account abstraction、Danksharding、Statelessnessなどが整理されています。

参考: Ethereum.org: Ethereum roadmap

ここから分かるのは、PoW/PoSはブロックチェーン理解の重要な入口でありつつ、それだけで全体像が完結するわけではない、ということです。

PoW/PoSを理解すると、次のようなテーマに進みやすくなります。

なぜfinalityが重要なのか
なぜバリデータやクライアントの集中が問題になるのか
なぜLayer 2やRollupがEthereumの文脈で重要になるのか
なぜMEVや検閲耐性がセキュリティ論点になるのか
なぜ暗号アジリティや耐量子暗号も長期的には関係するのか

この記事ではPoW/PoSに絞っていますが、今後の派生記事では、これらのテーマをさらに深掘りできます。

10.8 小さなコードで見る：投稿前に確認すべき情報を整理する

最後に、記事を公開する前に確認すべき情報を、簡単なPythonコードで整理してみます。

このコードはPoWやPoSを実装するものではありません。
技術記事を書くときに、どの情報を投稿前に再確認すべきかを整理するための学習用コードです。

# これは、PoW/PoSの記事を投稿する前に確認すべき情報を整理するための学習用コードです。
# 実際のブロックチェーンノード、マイニング、ステーキング処理を行うものではありません。

from dataclasses import dataclass
from typing import List


@dataclass
class CheckItem:
    """投稿前に確認したい項目を表すデータクラスです。"""
    topic: str           # 確認するテーマ
    reason: str          # なぜ確認が必要か
    source_type: str     # どの種類の情報源を見るべきか
    freshness: str       # どれくらい新しさが重要か


# PoW/PoS記事で、投稿前に確認したい項目をまとめます。
# 仕様や規制、ロードマップのように変わりやすいものは、特に最新確認が必要です。
check_items: List[CheckItem] = [
    CheckItem(
        topic="Ethereumのアップグレード状況",
        reason="PoS移行後もPectraや今後のロードマップなどが更新されるため",
        source_type="Ethereum公式ドキュメント・Ethereum Foundation Blog",
        freshness="高",
    ),
    CheckItem(
        topic="staking withdrawalsやvalidator仕様",
        reason="バリデータ運用やステーキングの説明に関わるため",
        source_type="Ethereum公式stakingページ・launchpad",
        freshness="高",
    ),
    CheckItem(
        topic="BitcoinのPoW説明",
        reason="基本概念は安定しているが、表現の根拠を確認するため",
        source_type="Bitcoin Whitepaper・Bitcoin Developer Guide",
        freshness="中",
    ),
    CheckItem(
        topic="エネルギー消費に関する数値",
        reason="時期や測定方法によって数値が変わるため",
        source_type="公式資料・信頼できる調査機関",
        freshness="高",
    ),
    CheckItem(
        topic="規制・制度面の記述",
        reason="FATFや金融庁の情報は更新されるため",
        source_type="FATF・金融庁などの一次情報",
        freshness="高",
    ),
]


# 確認優先度が高いものを抽出します。
high_priority_items = [item for item in check_items if item.freshness == "高"]

print("投稿前に特に最新確認したい項目:")
for item in high_priority_items:
    print(f"- {item.topic}")
    print(f"  理由: {item.reason}")
    print(f"  推奨情報源: {item.source_type}")

このコードでは、投稿前に確認すべき情報を CheckItem として整理しています。

PoW/PoSの記事では、BitcoinホワイトペーパーやNISTIR 8202のように比較的安定した一次情報もあります。
一方で、Ethereumのアップグレード、ステーキング仕様、規制・制度、エネルギー消費の数値などは変わりやすいため、投稿直前に確認した方が安全です。

技術記事を書くときは、次のように分けて考えるとよいです。

情報の種類	更新されやすさ	例
基本原理	比較的安定	PoWのハッシュ探索、PoSのステークによる参加
特定チェーンの仕様	中〜高	Ethereumのslot、epoch、validator仕様、アップグレード
数値情報	高	エネルギー消費、バリデータ数、ステーク量、手数料
規制・制度	高	FATF、金融庁、各国規制、Travel Rule
サービス情報	高	ステーキングサービス、取引所、ウォレット対応

この表を意識しておくと、「古くなりにくい説明」と「投稿前に確認すべき説明」を分けやすくなります。

10.9 最近の動向を一枚で整理する

ここまでの内容を、表でまとめます。

動向	何が起きているか	PoW/PoS理解でのポイント
EthereumのThe Merge	EthereumがPoWからPoSへ移行	PoSが大規模チェーンで本格運用されている代表例
Ethereumのstaking withdrawals	ステークしたETHの引き出しが可能になった	PoSは運用・資金ロック・退出の設計も重要
Pectraなどのアップグレード	validator experienceや有効残高などが改善	PoS移行後も仕様は進化し続ける
BitcoinのPoW継続	BitcoinではPoWが中核として使われている	PoWは今も重要な設計として残っている
エネルギー消費の議論	PoWの電力消費が社会的論点になる	PoWの安全性と現実世界のコストは結びついている
ステーク集中	PoSでステークが少数主体に偏る可能性	分散性・検閲耐性・運用リスクを見る必要がある
クライアント多様性	同じ実装への偏りを避ける動き	バグや攻撃への耐性に関係する
規制・制度の更新	FATF、金融庁などが継続的に情報更新	技術説明と法的判断は分ける必要がある

この表を見ると、PoW/PoSの学習は「方式名を覚える」だけでは不十分だと分かります。

大切なのは、次のように動きを追うことです。

どのチェーンがPoWを使い続けているのか
どのチェーンがPoSを採用しているのか
PoS移行後にどのような運用課題が出ているのか
ステーキングやバリデータ運用がどう変化しているのか
エネルギー消費や集中リスクがどう議論されているのか
規制や制度面でどのような確認が必要なのか

10.10 この章のまとめ

この章では、PoWとPoSに関する最近の動向を整理しました。

Ethereumは2022年のThe MergeによってPoWからPoSへ移行し、その後もstaking withdrawals、Pectraなどのアップグレードを通じて、PoS運用やバリデータ周りの改善が続いています。
一方で、BitcoinではPoWが今も中核的な仕組みとして使われており、PoWを単純に「古い方式」として片付けることはできません。

この章で押さえたいポイントは、次の通りです。

EthereumはThe MergeによってPoWからPoSへ移行した
PoS移行後も、ステーキングやバリデータ運用はアップグレードによって変化している
BitcoinではPoWが現在も中核的な仕組みとして使われている
PoWではエネルギー消費やマイニング集中が重要な論点になる
PoSではステーク集中、クライアント集中、運用ミス、slashingなどが重要な論点になる
規制・制度面では、VASP、ステーキングサービス、トラベルルールなども確認が必要になる
技術記事では、基本原理と更新されやすい情報を分け、投稿前に公式情報で確認することが大切である

ここまでで、PoWとPoSの基本、仕組み、不正抑止、比較、セキュリティ上の注意点、よくある誤解、最近の動向まで整理できました。

次の章では、記事全体を振り返ります。
PoWとPoSを「どちらが優れているか」ではなく、分散した参加者が同じ記録を信じるために、どのようなコストを使って不正を抑えるのか という視点でまとめていきます。

11. まとめ

この章では、記事全体を振り返りながら、Proof of WorkとProof of Stakeをどのように理解するとよいかを整理します。
ポイントは、PoWとPoSを「どちらが常に優れているか」ではなく、分散した参加者が同じ記録を信じるために、何をコストとして使うのか という視点で見ることです。

ここまで、Proof of WorkとProof of Stakeについて、身近な共有記録の例から順番に整理してきました。

最初に見たのは、会計ノートや議事録、共同編集メモのような「みんなで共有する記録」です。
少人数であれば、代表者を1人決めて記録を任せることもできます。

しかし、ブロックチェーンのように、参加者が世界中に分散していて、お互いを直接知らない場合は、それだけではうまくいきません。

誰が次の記録を書いてよいのか。
もし同時に別々の記録が出てきたら、どちらを正しい履歴として扱うのか。
悪意ある参加者が、安いコストで偽の参加者や偽の履歴を作ろうとしたらどうするのか。

このような問題に向き合うために登場する代表的な考え方が、Proof of WorkとProof of Stakeでした。

11.1 記事全体の振り返り

この記事では、PoWとPoSをいきなり定義から覚えるのではなく、次の流れで整理しました。

最初に確認したように、ブロックチェーンは単に「データをつなげたもの」ではありません。
複数の参加者が同じ履歴を共有し、その履歴があとからこっそり書き換えられていないかを確認しやすくする仕組みです。

ただし、記録を共有するには、ブロックを作る人、ブロックを検証する人、複数の履歴候補が出てきたときに選ぶルール、不正に対するコストなどが必要になります。

このとき、PoWとPoSはとても重要な役割を持ちます。

11.2 本記事で整理したこと

本記事で整理した内容を、章ごとに振り返ると次のようになります。

章	整理したこと	大事なポイント
1章	共有記録で「誰が書くか」が問題になる理由	記録を信じるには、書き込み権限や履歴の選び方が必要
2章	コンセンサスの全体像	PoW/PoSだけでなく、検証ルールやfork choiceも重要
3章	PoWの基本	条件を満たすハッシュを探す計算作業が中心
4章	PoWによる不正抑止	過去を書き換えるには、その後の作業もやり直す必要がある
5章	PoSの基本	資産を預け、バリデータとして参加する
6章	PoSによる不正抑止	報酬、ペナルティ、slashingによって正しい参加を促す
7章	PoWとPoSの比較	コストの置き方、攻撃の見方、集中リスクが異なる
8章	セキュリティ上の注意点	PoW/PoSは安全性の一部であり、周辺リスクも見る必要がある
9章	よくある誤解	「PoSは完全上位互換」「51%攻撃は何でもできる」などを避ける
10章	最近の動向	EthereumのPoS移行、BitcoinのPoW継続、規制・運用面の変化を確認する

こうして見ると、PoWとPoSは単なる用語ではなく、ブロックチェーンの安全性、分散性、運用、エネルギー消費、規制、ユーザー体験にまで関わるテーマだと分かります。

11.3 PoWとPoSは「何を失うか」が違う

この記事全体を一言でまとめるなら、次のようになります。

Proof of WorkとProof of Stakeは、どちらも「不正を安く済ませられないようにする」ための仕組みです。
ただし、PoWは主に計算資源や電力をコストにし、PoSは主に預けた資産やペナルティをコストにします。

PoWでは、ブロックを作るために大量のハッシュ計算を行います。
そのため、不正な履歴を作ろうとすると、電力、計算機、設備投資、時間といった現実世界のコストが必要になります。

一方で、PoSでは、バリデータが資産を預けて参加します。
正しく参加すれば報酬を得られますが、不正や重大な違反をすると、預けた資産の一部を失う可能性があります。

観点	Proof of Work	Proof of Stake
主なコスト	計算資源、電力、設備投資	預けた資産、報酬、ペナルティ
代表的な参加者	マイナー	バリデータ
不正をしにくくする考え方	不正な履歴を作るには大量の計算作業が必要	不正をすると預けた資産を失う可能性がある
攻撃時に問題になるもの	ハッシュパワーの集中	ステークの集中
代表例	Bitcoin	現在のEthereum

ここで重要なのは、どちらも「何らかのコスト」を使っていることです。

PoWは外側の資源、つまり電力や計算機を使います。
PoSは内側の資産、つまりそのチェーン上の資産や報酬・ペナルティ設計を使います。

この違いを押さえておくと、PoWとPoSを単純な優劣ではなく、設計思想の違いとして見やすくなります。

💡 豆知識
Proof of WorkやProof of Stakeの「Proof」は、日本語でいう「証明」に近い言葉です。
ただし、学校の数学の証明というより、「これだけの作業をした」「これだけの資産を預けて責任を持っている」という 参加資格や責任の根拠 に近い感覚で捉えると分かりやすいです。

11.4 PoWとPoSはブロックチェーン全体の一部である

この記事ではPoWとPoSを中心に扱いましたが、ここで一度、ブロックチェーン全体の中での位置づけを整理しておきます。

ブロックチェーンの安全性は、PoWやPoSだけで成り立っているわけではありません。

たとえば、次のような要素も関係します。

取引が正しいかを確認する検証ルール
ブロック同士をつなぐハッシュ
取引に署名するためのデジタル署名
ノード同士が情報を伝えるP2Pネットワーク
複数の履歴候補が出たときのfork choice
報酬や手数料などのインセンティブ設計
ウォレット、取引所、スマートコントラクトなど周辺システムの安全性

PoWやPoSは、その中でも特に、誰がブロック作成に参加しやすいか、悪意ある参加者が安く影響力を持てないようにするか に関わる重要な部品です。

この図のように、PoW/PoSはブロックチェーン全体の中の重要な一部分です。

そのため、PoW/PoSだけを見て「このブロックチェーンは完全に安全」と判断するのは危険です。
逆に、PoW/PoSを理解しておくと、ブロックチェーン全体の安全性や限界を考えるための土台ができます。

11.5 派生元記事とのつながり

本記事は、以前作成した 「身近な記録から理解するブロックチェーンの全体像」 の派生記事です。

派生元記事では、ブロックチェーンを、身近な記録から理解するための全体地図として整理しました。
その中では、ブロック、チェーン、ハッシュ、デジタル署名、分散、コンセンサス、スマートコントラクト、情報セキュリティ上の強みと限界を広く扱いました。

本記事では、その中でも特に コンセンサス周辺 に注目し、PoWとPoSを深掘りしました。

派生元記事	本記事
ブロックチェーン全体の地図を整理する	PoW/PoSに絞って深掘りする
身近な記録からブロックチェーンを説明する	共有記録の「誰が書くか」からPoW/PoSを説明する
ハッシュ、署名、分散、コンセンサスを広く扱う	PoW、PoS、攻撃、集中リスク、最近の動向を扱う
全体像をつかむ入口	コンセンサス周辺を理解する続編

関連記事: 身近な記録から理解するブロックチェーンの全体像

Qiitaに投稿する際は、上記の ここに派生元記事のURLを挿入 の部分を、実際に投稿済みの派生元記事URLへ置き換えてください。

11.6 PoW/PoSを学ぶときに意識したいこと

PoWとPoSを学ぶときは、次の点を意識すると理解しやすくなります。

意識したいこと	理由
「どちらが優れているか」だけで見ない	チェーンの目的、設計、運用体制によって評価が変わるため
「何をコストにしているか」を見る	PoWは計算資源、PoSは預けた資産を中心に考えると整理しやすいため
「誰が失敗したときに何を失うか」を見る	不正抑止の仕組みを理解しやすくなるため
「攻撃者が何を支配すると危ないか」を見る	PoWではハッシュパワー、PoSではステーク量が重要になるため
「集中リスク」を見る	マイニングプール集中、ステーキング集中、クライアント集中が安全性に関係するため
「周辺システム」も見る	ウォレット、取引所、スマートコントラクトの問題はPoW/PoSだけでは防げないため
「最新情報」を確認する	Ethereumのアップグレードや規制情報などは変化し続けるため

特に、次のような表現には注意が必要です。

避けたい表現	より丁寧な表現
PoWは無駄な計算である	PoWは計算資源をコストにして不正な履歴作成を難しくする仕組み
PoSはPoWの完全上位互換である	PoSはPoWとは異なるコスト設計を持つ仕組み
ブロックチェーンは改ざん不可能	履歴を書き換えるコストを高め、改ざんを検知しやすくする仕組み
51%攻撃ですべてを自由にできる	直近履歴の再編成や二重支払いなどが問題になり得るが、検証ルールを無視できるわけではない
PoW/PoSがあるから全体が安全	PoW/PoSは安全性の一部であり、周辺システムや運用も重要

技術記事として書く場合も、学習する場合も、強すぎる言い切りを避けることが大切です。

ブロックチェーンは「完全に安全な魔法の仕組み」ではありません。
一方で、「危険だから意味がない」と単純に片付けられるものでもありません。

どの部分が強く、どの部分に限界があり、どこから運用や周辺システムの問題になるのかを分けて考えることが重要です。

11.7 今後深掘りしたいテーマ

PoWとPoSを理解すると、次に気になってくるテーマがいくつかあります。

テーマ	ざっくりした内容	PoW/PoSとの関係
fork choice	複数の履歴候補が出たとき、どれを選ぶか	PoW/PoSだけでは合意全体を説明できないため重要
finality	あるブロックがどれくらい覆りにくいか	PoSでは特に重要な概念
MEV	取引の順序変更などから生まれる価値	ブロック提案者や検証者のインセンティブに関係する
ステーキングサービス	個人が直接バリデータ運用しない場合の参加方法	ステーク集中や規制面の論点につながる
マイニングプール	複数のマイナーが協力して報酬を分ける仕組み	ハッシュパワー集中の論点につながる
クライアント多様性	同じソフトウェア実装に偏らないこと	バグや攻撃への耐性に関係する
Layer 2 / Rollup	メインチェーン外で処理を増やす仕組み	PoS化後のEthereumスケーリングとも関係する
ブリッジ	異なるチェーン間で価値を移す仕組み	コンセンサスの異なるチェーンをまたぐとリスクが増える
耐量子暗号	量子コンピュータ時代の暗号移行	署名や鍵管理の将来リスクに関係する

この記事では、PoWとPoSの全体像を初学者向けに整理することを優先しました。
そのため、EthereumのGasper、Casper FFG、LMD-GHOST、Bitcoinのdifficulty adjustment、MEVの詳細、ステーキングサービスの法的整理などは深く扱っていません。

これらは、別記事として一つずつ掘り下げる価値があります。

11.8 最後に

Proof of WorkとProof of Stakeは、どちらもブロックチェーンを理解するうえで避けて通れないテーマです。

ただ、最初から技術仕様や数式、厳密なプロトコルの話に入ると、かなり難しく感じるかもしれません。

そのため、本記事では、会計ノートや議事録のような身近な共有記録から始めました。

みんなで同じ記録を信じたい。
でも、特定の管理者だけには任せたくない。
悪意ある人が安いコストで記録を書き換えられる状態も避けたい。

このような状況で、PoWは計算作業を、PoSは預けた資産を使って、不正をしにくくする仕組みとして働きます。

もちろん、PoWにもPoSにも限界があります。
PoWにはエネルギー消費やマイニング集中の論点があります。
PoSにはステーク集中、クライアント集中、slashing、弱主観性などの論点があります。

それでも、どちらも「分散した参加者が同じ履歴を信じるにはどうすればよいか」という大きな問いに対する、重要な設計の一つです。

この記事を通じて、PoWとPoSを単なる用語としてではなく、次のように捉えられるようになっていれば幸いです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up