> For the complete documentation index, see [llms.txt](https://book.ethereum-jp.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.ethereum-jp.net/what_is_ethereum/blockchainrev_md.md).

# ブロックチェーン革命

## 中央機関の存在しない通貨：ビットコイン

2008年のNakamoto氏による論文[「Bitcoin: A Peer-to-Peer Electronic Cash System」](https://bitcoin.org/bitcoin.pdf)の発表と、その後の有志による[ビットコイン](https://bitcoin.org)の開発は、通貨の世界に革新を起こしました。

ビットコインを利用するためのソフトはオープンソースで提供され、PCからスマートフォンまで様々なデバイス上で動作します。ユーザーはネットワークを通じてビットコインをやり取りすることで、従来の通貨で行うほぼ全てのこと、つまり物品の売買から個人や組織への送金、そして融資も行なうことが可能です。ビットコインには国境や地域の概念がなく世界共通通貨であること、それにより海外への送金も非常に高速かつ安全で低コストに行えます。以上のような理由からビットコインは通貨の理想形と考えれられています。

このような通貨としての利便性はもちろんですが、ビットコインの最も重要な革新性は、従来の（電子マネーを含む）通貨とは異なり、通貨発行や決済にいかなる中央機関や管理者も必要としないP2Pの通貨システムであるということにあります。

冒頭に挙げたNakamoto氏の論文は、「ビザンチン将軍問題」と呼ばれる分散コンピューティングの分野での難問に初めて実用的な解を与えるものでした。そしてこの発明こそが、中央機関の必要としない通貨システムの実現の鍵となるものでした。

「ビザンチン将軍問題」とは、不特定多数のノードで構成され潜在的に悪意のあるノードも含まれるようなP2Pネットワークの中で、各ノードの情報交換によって通貨の取引情報（例えば誰から誰にいくら支払った等）にネットワーク全体で合意を形成することは可能か？可能である場合はどのように行えばよいのか？という問題です。

P2Pは不特定多数のノードがランダムに接続されたネットワークです。例えば、P2Pのネットワーク内で悪意のあるノードがAに$100を送金したという情報をそのノードに繋がっているノードの一つに送り、同時に同じ$100をBに送金したいう情報を別のノードに送信したとしたらどうなるでしょう（二重支払問題）。それぞれの情報を受け取ったノードがそれらの情報を信じて動作すると、ネットワーク内の資金の流れの情報に整合性が無くなり、たちまちこの通貨システムは破たんしてしまいます。

Nakamoto氏はブロックチェーンとプルーフ・オブ・ワークという仕組みを導入することで、P2Pのシステム上で通貨システムを実現しようとする際に生まれるこの問題を解決することに成功しました。次節以降で、ビットコインの動作の概略とともに、どのように解決したのかについて見ていきましょう。

## ビットコインでの送金の仕組み

技術的には、ビットコインの世界では、実際に何らかの電子的なコインが存在しそれをやり取りしているわけでは*ありません*。「送信者から受信者へある一定量の額面を移動させる」という取引（トランザクション）の中で各ユーザーのビットコインの保有額が暗に示されるものです。

つまり、ある時点でのあるユーザー（のアドレス）が保持するビットコインの量は、その時点より以前にそのユーザーに向けて支払われたトランザクションのうち、まだ他の誰かに支払うために使われていないトランザクション（UTXO: Unspent Transaction Output ）を寄せ集め、そのそれぞれのUTXOの額面の総和になります。

例えば、太郎がビットコインを始めようとアカウント（アドレス）を作成し、その後、友人Aから 10 BTC、友人Bから 20 BTC のビットコインを送ってもらったとします。それ以降、太郎は誰にもビットコインを支払っていないとすると、太郎は２つのUTXO を持っていることになります。そしてその総額が 30 BTCなので、太郎はビットコイン30 BTC を保有しているということになります。

さて、ここで太郎が花子に 25 BTC を送金したいとするとどうなるでしょうか？ UTXO自体はトランザクションの情報なので、その額面を分割することはできません。そのため太郎は「自分の持っている２つのUTXO （計 30 BTC）を使って、25 BTC を花子のアドレスに、5 BTC を *自分自身のアドレスに* 送金する」という新しいトランザクションを生成します。これにより花子と太郎はそれぞれ 25 BTC、5 BTC のUTXOを新たに得ることになります。これは現実世界で950円支払うのに千円札で支払い、50円のお釣りを受け取ることに似ています。

## ブロックチェーン

従来のように中央管理機関が存在している通貨システムであれば、太郎は自ら生成したトランザクションの情報をその中央機関に送信し、その機関は受信したトランザクションの情報に基づいて、自ら管理する取引台帳にその情報を更新すればよいだけです。

システムの参加者は、この信用に足る中央機関の管理する台帳が「正」であると皆で「合意」することができます。また、たとえ太郎に悪意があって、花子に 25 BTC を送った後に同じUTXOを使って 25BTC を別の人に送ろうとしても、中央機関はそのUTXOは使用済みと知っているので、「使えない」とすればよいだけです。非常にシンプルです。

一方、P2Pのネットワーク上で動作するビットコインは、代表して台帳を管理する中央機関（システム）が存在しません。そのため、各ノードが「ブロックチェーン」と呼ばれる取引台帳をネットワークへの参加者間で共有・管理し、その台帳を「正」とする合意をとります。

ビットコインのシステムでは、参加者間でビットコインの送金（＝トランザクション）が行われるとその情報がP2Pネットワーク全体に伝搬します。ネットワーク内には「採掘者」と呼ばれるノードが多数参加しており、これら採掘者は、ある時点からある時点までの間に行われたトランザクションの情報を1つの「ブロック」と呼ばれるパッケージを生成する「採掘」という作業を行います。そのブロックには、前に作成されたブロックへの参照 を含めることで、そのブロックが時系列に連なった一本のチェーン（ブロックチェーン）が連なっていきます。このブロックチェーンは、ビットコインが始まって以来の全てのトランザクション情報が含まれ、かつネットワークへの参加者全員が参照可能なものです。いわば公開取引台帳の役割を果たします。

「採掘者」はブロックを生成時、

* UTXOの所有者以外が、そのUTXOを用いて送金を行っていないか？
* 同じUTXOを複数回使用するようなトランザクションがないか？

といった、ブロックに含めるトランザクションの正当性を確認してブロック生成します。 また、その「採掘者」が生成したブロックを他のノードが受け取った際にも同様の確認をし、新しいブロックが追加されたブロックチェーンを「正」として合意するという仕組みで、取引台帳としてのブロックチェーンの正当性を合意していく仕組みをとっています。

## プルーフ・オブ・ワーク

さて、P2Pシステムの性質上、このブロックを生成する「採掘者」は特別な権限を与えられた参加者ではなく、任意の参加者が「採掘者」になることが可能です。しかし一方で、誰でも何の制限もなくブロックが生成できるとなると、皆が好き勝手にブロックチェーンを連ねていき、どのブロックチェーンが皆が合意する「正」のブロックチェーンかが分からなくなる事態になります。

そこでビットコインでは、「プルーフ・オブ・ワーク」という仕組みを導入します。これは、ブロックを採掘する際の条件に、その生成するブロックのヘッダ・データのSHA256ハッシュ値が、規定された値以下でなければならないという条件を課すものです。この制限を満たすために、採掘者はnonce（ノンス）と呼ばれる付加データをヘッダに追加することで、ハッシュ値が規定された値以下になるように調整を行います。SHA256のような暗号学的ハッシュ関数は、出力されるハッシュ値が元のデータからは予見できないように設計されている関数のために、採掘者は条件を満たすハッシュ値が出力される（＝採掘に成功する）までナンスの値を変更しながら試行錯誤を繰り返します。

多数参加している採掘者の中で最初に採掘に成功した採掘者は、その情報をビットコイン・ネットワーク内に発信します。それを受信した他の参加者は採掘されたブロックを調べ、

* 前のブロックの参照が含まれているか
* プルーフ・オブ・ワークの条件を満たしているか
* ブロックに含まれているトランザクションに不整合はないか

などを確認し、問題がないことが分かればそのブロックが「正」として合意します。

採掘に成功したノードには、インセンティブとして25 BTC の報酬が与えられます。この報酬を目当てに多数の採掘者がビットコイン・ネットワークに参加し、常に採掘競争を行っています。

プルーフオブワークの制限は、ネットワーク全体で「採掘者」達が10分に１回程度の頻度でその条件に合うハッシュ値を生成するノンスを見つけ、新しいブロックを採掘できる程度に動的に調整されます。

## ２重支払問題の解決

このブロックチェーンとプルーフオブワークの組み合わせにより、悪意のある参加者（攻撃者）が２重支払を行うことを防ぐことが可能になります。少し具体的な例として攻撃者が以下のように２重支払いを行って商品をだまし取ろうとした場合のケースを考えましょう。

1. 攻撃者が、あるEC業者から商品を購入し100BTCを送金する。
2. EC業者は100BTCが送金されたことをブロックチェーンの記録を見て確認する。送金されたことが確認できたら商品を発送する。
3. 攻撃者が商品を受け取る。
4. 攻撃者が業者に支払った100BTCをなかったことにするために、同じ100BTCを自分自身に送金したというように、ブロックチェーンを書き換える。

ステップ１の送金の事実が、ここでは仮にブロック番号2000番のブロックに記録されていたとします。ブロックが生成され、ネットワークがそれを受け入れた時点（他の採掘者がそのブロックに連なる次のブロックを採掘し始めた時点）でビットコイン・ネットワーク内で「攻撃者からEC業者への100BTCの送金した」という事実が存在するという合意が得られたことになります。攻撃者が送金の事実を消そうとした場合、このブロック番号2000番のブロックに含まれるトランザクション情報を書き換える必要があります。トランザクションの中身が変わっているために既に存在するブロック番号2000のハッシュ値も変わるため、攻撃者はこの書き換えたトランザクションの内容で番号2000のブロックを再び採掘する必要があります。また、採掘しなおしたブロックはオリジナルのブロックとは異なるハッシュ値を持っているため、他の採掘者が採掘した2001番以降のブロックはもはや攻撃者が書き換えたブロックの方を参照しません。

ビットコインのブロックチェーンのルールとして、Forkができた場合は、最も長いForkを正とするというルールがあるため、攻撃者が2,000番のブロックを採掘したとしても他の採掘者はそれに連なるブロックを採掘しようとはせず、正当な方の分岐の採掘を行おうとします。一方で攻撃者は、自分のみで2,000番のブロックに続くブロックを採掘していこうとするのですが、攻撃者が自分のブロックチェインが正統なほうのチェーンより長く連ねるには、正当な方のチェーンを採掘し続けている残りのネットワーク全部の計算パワーを上回る必要があります。ビットコイン・ネットワークに十分な採掘者が参加していれば、攻撃者単独で残りの採掘者達の計算パワーには勝つことは容易ではありません。（攻撃者が単独で全採掘者の計算パワーの51%を占める必要があります。）そのため、２重支払が出来ない仕組みとなっているのです。

## ブロックチェーンの応用

Nakamoto氏の発明の本質は、いかなる中央機関も存在しないP2Pネットワーク上で、「合意」の形成を行うことを可能にしたことにあります。送金の事実についての合意形成を実現することで、P2Pネットワーク上に「通貨」を実現したビットコインは、このブロックチェーンによる革新の一つの応用に過ぎません。事実2009年以降、ブロックチェーンによる合意形成を応用した様々なサービスが生み出されています。

一つの例が[Namecoin](https://namecoin.info/)です。Namecoinは名前登録を分散システム上で行うものです。例えば、Webサイトなどに用いられるドメイン名は現在ICANNという組織を中心に管理されているものです。このようなドメイン名の管理をブロックチェーンを利用してP2Pシステム上で実現しようとするのがNamecoinです。「いつ誰がどのドメイン名を登録した」という事実をブロックチェーンに登録し、それをネットワーク参加者の誰もが参照可能な公開ドメイン登録台帳として管理していきます。Namecoinは、ブロックチェーンの応用の中でも最も古く成功した例として知られています。

この他にも、[Storj](http://storj.io/)（分散ストレージ）、[Proof of Existence](http://www.proofofexistence.com/)（ドキュメント存在証明）などの様々な応用サービスがローンチされてきています。ブロックチェーンを用いたP2Pの分散型のサービスは現在の時点では思いつかないアイデアのサービスに広がっていくかもしれません。

## 脚注

[This work](http://book.ethereum-jp.net/) is licenced under a [Creative Commons Attribution-ShareAlike 4.0 International License](http://creativecommons.org/licenses/by-sa/4.0/).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://book.ethereum-jp.net/what_is_ethereum/blockchainrev_md.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.