私がビットコインに出会ったのは2017年でした。

最初に疑問に思ったのは、なぜビットコインに価値があるのか、ということでした。紙幣でもなく、会社の株式でもないものに、なぜ値段がつくのでしょうか。

そもそも何なのかを知ろうと思い、サトシ・ナカモトが書いたとされるホワイトペーパーを読みました。ビットコインの仕組みを説明した、わずか9ページの論文It is.

ところが、読んでもよく分かりませんでした。英語だからというだけではありません。電子署名、ハッシュ、Proof of Work。言葉の意味を調べても、それらを組み合わせると、なぜ銀行を介さずにお金を送れるのかが、頭の中でつながらなかったのです。

それから年月がたち、今はAIに「ここが分かりません」「もっと簡単に」「その例えだと、ここはどうなるの？」と、何度でも聞けるようになりました。

そこで、あのホワイトペーパーを、もう一度読み直してみることにしました。今回はAIに手伝ってもらい、私を含めたエンジニアではない人にも分かる言葉で、一つずつ説明してもらいます。

以下は、原論文の順番に沿った日本語での要約と解説です。全文の日本語訳は、bitcoin.orgの日本語版から読むことができます。理解を助けるため、実際のビットコインの仕組みについても補足しています。

論文のタイトルと要旨

原題は「Bitcoin: A Peer-to-Peer Electronic Cash System」です。

日本語にすると、「ビットコイン：個人同士が直接やり取りできる電子的な現金の仕組み」という意味になります。

「Peer-to-Peer」、略してP2Pは、参加者同士が通信する方式です。ここでいう「直接」は、通信がほかのコンピューターを一切経由しないという意味ではありません。支払いを成立させるために、銀行などの中央の管理者を必須としない、という意味です。

論文全体を読むために、最初に三つの疑問を置いておきます。

この三つは、同じ問題ではありません。それぞれに対応する仕組みを組み合わせているため、専門用語だけを一つずつ覚えても、全体が分かりにくいのです。

第1章　Introduction――何を解決しようとしているのか

章の要点：金融機関を信頼して支払いを処理してもらう方式に対して、暗号技術によって支払いを検証できる方式を提案します。

銀行振込では、紙幣が相手に届くわけではありません。私の残高が減り、相手の残高が増えるように、金融機関が記録と決済を処理します。

では、その管理者を置かずに同じことができるでしょうか。

まず、参加者が同じ帳簿を持つことを考えます。誰か一人だけが管理する代わりに、複数の参加者が記録を保存し、支払いを検証するのです。

しかし、帳簿を配るだけでは解決しません。

ある人の帳簿には「Aさんへの支払い」、別の人の帳簿には「Bさんへの支払い」が書かれていたら、どちらを採用するのでしょうか。両方とも同じ資金を使った支払いなら、両方を認めるわけにはいきません。

ビットコインの仕組みを理解するうえで重要なのは、記録を共有することに加えて、食い違った記録をどう扱うかIt is.仕組みの概要

第2章　Transactions――誰が、そのお金を使えるのか

章の要点：電子署名で資金の移転を確認します。ただし、署名だけでは二重払いを防げません。

まず、「私のお金を他人が勝手に送金する」という問題を防ぎます。

ここで使うのが、秘密鍵と電子署名です。

秘密鍵は、支払いを承認するための秘密の情報です。ウォレットはこれを使い、支払いの内容に対応した電子署名を作ります。

大まかには、次の関係です。

印鑑に例えると、他人は印影の正しさを確認できますが、その確認用の情報から、印鑑そのものを簡単に作れるわけではありません。

ただし、電子署名は印影の画像とは違い、支払いの内容に結びついています。受取先などを書き換えると、元の署名はそのままでは通用しません。鍵とウォレットの説明

それでも、二重払いの問題は残ります。

私が同じ資金について、「Aさんに払います」「Bさんに払います」という二つの取引を作り、両方に自分で署名したらどうでしょうか。

署名は、どちらも本物です。

「使う権限があること」と「すでに使っていないこと」は、別に確認しなければならないのです。

現金なら、千円札をAさんに渡した後、同じ千円札をBさんに渡せません。電子的な記録では、その制約を別の方法で実現する必要があります。

第3章　Timestamp Server――記録を順番につなぐ

章の要点：データのハッシュを使い、前の記録と次の記録を結びつけます。

「ハッシュ」は、データを一定の計算にかけて得られる、決まった長さの値です。ここでは「内容から作る指紋」と考えてください。

同じデータからは、同じ指紋ができます。内容が少し変わると、通常はまったく違う指紋になります。

ただし、ハッシュは内容の真偽を判定しません。「私の残高は1億円」という嘘のデータにも、指紋は作れます。

役割は、同じ内容か、内容が変わっていないかを確認することIt is.

ビットコインでは、取引をまとめた記録の束を「ブロック」と呼びます。次のブロックには、前のブロックのハッシュが入っています。

Aを書き換えるとAの指紋が変わり、Bに記載された指紋と一致しなくなります。Bも直すと、今度はCとのつながりが変わります。

このように記録が鎖状につながるため、「ブロックチェーン」と呼ばれます。ブロックの構造

では、書き換えた後に、指紋を全部計算し直せばよいのではないでしょうか。

その疑問に対応するのが、次の章です。

第4章　Proof-of-Work――記録の作り直しに負担をかける

章の要点：ブロックを作るために計算を必要とし、過去の履歴を書き換えるにも計算のやり直しが必要になるようにします。

Proof of Work、略してPoWは、「計算の仕事を行った証拠」という意味です。

仕組みを単純にすると、次の作業になります。

1. ブロックのデータに、調整用の数字を入れます。
2. ハッシュを計算します。
3. 結果が決められた条件に合わなければ、数字などを変えて試します。
4. 条件に合う結果が出るまで繰り返します。

この調整用の数字が「nonce」、ノンスです。

実際の条件は、ハッシュの値が指定された基準値より小さいことです。「当たりが出るまで試す抽選」に近いと考えると分かりやすくなります。

重要なのは、次の性質です。

当たりを見つけるには大量の試行が必要ですが、出された結果が当たりかどうかは簡単に確認できます。

難しい定理を解いているわけではありません。条件に合う計算結果を探しています。これが、マイニングで行う仕事です。マイニングの説明

過去のブロックを書き換えると、それまでの計算結果は通常使えなくなります。そのブロックから先の仕事をやり直し、その間にも進んでいくほかの参加者の履歴に追いつく必要があります。

採用するのは、ルールに適合する履歴のうち、累積した仕事量が最も大きいものIt is.

人数の多数決ではありません。また、どれだけ計算しても、不正な署名や発行ルール違反が、それだけで正当化されるわけではありません。まず各ブロックが有効であることが必要です。チェーンの選択と検証

第5章　Network――実際の送金はどう進むのか

章の要点：取引とブロックを参加者に伝え、検証しながら共通の履歴を伸ばします。

私からAさんへ送金する場合を、最初から追ってみます。

1. ウォレットが、使う資金と支払先を指定した取引を作ります。
2. 秘密鍵で電子署名を作ります。
3. 取引をネットワークに流します。
4. 受け取った参加者が、署名や資金の状態などを確認します。
5. マイナーが取引を候補ブロックにまとめ、PoWの条件を満たす結果を探します。
6. 見つかったブロックをネットワークに流します。
7. 参加者がブロックを検証し、採用する履歴を更新します。

現代の仕組みを理解する際は、ブロックを作る「マイナー」と、取引やブロックを独立に検証する「フルノード」を区別すると分かりやすくなります。検証する参加者全員が、採掘競争をしているわけではありません。ネットワークの説明

ほぼ同時に二つのブロックが見つかることもあります。

例えば、ある参加者にはXが先に届き、別の参加者にはYが先に届く場合です。一時的に履歴が分かれ、その後の累積仕事量によって、採用される側が決まります。

だから、「ブロックに一度入ったら、何があっても絶対に変わらない」という仕組みではありません。

取引の上にさらにブロックが積み重なることで、後から覆すために必要な仕事が増えていきます。

第6章　Incentive――計算をする人の報酬は何か

章の要点：新しく発行されるコインと取引手数料を、ブロックを作る仕事の報酬にします。

計算には設備や電力が必要です。そこで、ルールに従って採用されるブロックを作ったマイナーが、報酬を得られるようにしています。

報酬には、新規発行分と、そのブロックに含まれる取引の手数料があります。

ここでいう新規発行は、好きなだけ作ってよいという意味ではありません。発行できる額も検証ルールに含まれます。過大な報酬を要求したブロックは、検証する側に拒否されます。報酬と検証ルール

これは、ネットワークを維持する仕事に経済的な動機を与える設計です。「報酬があるから、誰も絶対に不正をしない」という意味ではありません。

第7章　Reclaiming Disk Space――記録の保存量を減らせるか

章の要点：取引をハッシュの木構造にまとめ、記録の保存を効率化する方法を考えます。

ここで「マークルツリー」が登場します。

四つの取引があるとします。それぞれのハッシュを作り、二つずつ組にしてまたハッシュを作り、最後に全体を一つのハッシュにまとめます。

              全体のハッシュ
              ／        ＼
       A・Bのハッシュ   C・Dのハッシュ
         ／    ＼        ／    ＼
        A      B        C      D

下から上に、指紋をまとめていく構造です。

例えばAという取引が含まれているか確認する際、B・C・Dの取引内容をすべて受け取る必要はありません。必要な途中のハッシュがあれば、Aから全体のハッシュまで計算をつなげられます。マークルツリーの仕組み

原論文では、この構造を古い記録の保存量を減らすためにも使うことを提案しています。

ただし、全体のハッシュから元の取引を復元できるわけではありません。指紋は、元のデータを丸ごと圧縮したものではないからです。

第8章　Simplified Payment Verification――簡単な方法で受取りを確認する

章の要点：すべての取引を自分で検証せず、ブロックのヘッダーと取引の包含証明を使って支払いを確認する方法を示します。

これが「SPV」、簡易な支払検証です。

ブロックのヘッダーは、本文の取引を全部含むものではなく、前のブロックへの参照や、取引全体のハッシュなどを含む小さな部分です。

SPVでは、そのヘッダーのつながりとPoWを確認し、自分の取引がブロックに含まれている証拠を受け取ります。

先ほどのマークルツリーが、その証拠を小さくするために役立ちます。

ただし、次の二つは別です。

• 自分の取引が、そのブロックに含まれていると確認すること。
• そのブロック内の全取引を、自分ですべて検証すること。

SPVは後者を省くため、フルノードと同じ検証をしているわけではありません。データや処理を軽くできる一方、ネットワークに関する追加の前提に依存します。SPVとフルノードの違い

第9章　Combining and Splitting Value――資金をまとめ、分ける

章の要点：一つの支払いに複数の資金を使ったり、受取先とお釣りに分けたりできるようにします。

ビットコインでは、以前受け取ってまだ使っていない資金のまとまりを、次の取引で使います。

これを「未使用の取引出力」、UTXOと呼びます。

仮に私が1 BTCのまとまりを持ち、Aさんに0.3 BTCを支払うとします。手数料を説明用に0.0001 BTCとすると、次のようになります。

元の1 BTCは、その取引で使われます。そして、Aさんが使える資金と、私がお釣りとして使える資金が、新たにできます。

千円札で買い物をしてお釣りを受け取ることに似ています。ただし、固定された紙幣の額面があるわけではありません。

逆に、0.1 BTCと0.2 BTCという別々のまとまりを、一つの取引にまとめて使うこともできます。取引の入力・出力・お釣り

ここで「データはコピーできるのに、なぜ二度使えないのか」がつながります。

取引データをコピーしても、資金のまとまりが増えるわけではありません。同じ資金をもう一度使おうとする取引は、同じ有効な履歴の中では認められないis.

第10章　Privacy――公開された帳簿とプライバシー

章の要点：取引を公開しながら、実名との結びつきを抑える方法を考えます。

ビットコインの取引履歴は公開されています。ただし、一般に、氏名がそのまま記載されているわけではありません。

これは「名前のない取引記録」と考えると分かりやすいでしょう。

しかし、名前が直接書かれていないことと、誰の取引か絶対に分からないことは違います。

あるアドレスが私のものだと分かれば、そこに関係する取引をたどる手掛かりになります。アドレスの使い回しや、複数の資金をまとめた支払いも、関連づけに使われる場合があります。

したがって、「完全に匿名」と理解するのは正確ではありません。プライバシーの説明

第11章　Calculations――数式は何を計算しているのか

章の要点：攻撃者が別の履歴を作り、正直な側の履歴に追いつく可能性を、一定の前提の下で計算します。

数式を見る前に、場面を決めます。

攻撃者がお店に支払い、お店が商品を渡します。その後、攻撃者は、その支払いを別の支払いに置き換えた履歴を採用させようとします。

公開されている履歴を、Aと呼びましょう。攻撃者が裏で作っている別の履歴を、Bとします。

AもBも、時間とともに伸びます。Aだけが進み、Bがじっと待っているわけではありません。

そこで、次の記号を使います。

モデルでは、pとqを足すと1になります。

まず「今、何個遅れているか」を考える

攻撃側の計算能力が小さく、qがpより小さいとします。

攻撃側が現時点でz個遅れている場合、将来いつか同点に追いつく確率は、このモデルでは次の形になります。

（q ÷ p）のz乗

これは「差が大きくなるほど、追いつく可能性が急速に小さくなる」という式です。

ただし、これはすでに分かっている差から追いつく確率です。「z回承認された取引が覆る確率」と、そのまま同じにはできません。

相手が裏でどこまで進んでいるかは見えない

商品を渡す側は、攻撃者の秘密の履歴を見ることができません。自分が待っている間、相手も何個かブロックを作っているかもしれません。

そこで論文は、攻撃側が裏で作った個数を確率で扱います。

その近似で使う平均が、次の式です。

λ ＝ z × q ÷ p

λは「ラムダ」です。正直な側がz個のブロックを作る平均的な時間に、攻撃側が何個くらい作っていそうかを表します。

平均が分かっても、実際にその個数になるとは限りません。ゼロ個の場合も、一個の場合も、それ以上の場合もあります。

そのばらつきを「ポアソン分布」で扱い、最後に次の計算をします。

それぞれの進み具合が起きる確率 × そこから追いつく確率

これを、考えられる進み具合について足し合わせます。論文に出てくる大きなΣの記号は、この「足し合わせる」という指示です。

続いて掲載されているプログラムは、この計算を実行するものです。ビットコインを採掘するプログラムそのものではありません。原論文第11章

実際の支払いでは、取引を含むブロックの上に、さらにブロックが積まれるのを待ちます。これは、履歴を覆すための負担を増やすためです。

ただし、待てば無条件に安全になるという意味ではありません。攻撃側の計算能力などの前提によって、リスクは変わります。承認と二重払い

第12章　Conclusion――仕組み全体をつなげる

章の要点：電子署名、ネットワーク、PoWによる履歴の合意を組み合わせ、中央の管理者を必須としない支払いを構成します。

最後に、それぞれの役割を一枚の表にまとめます。

銀行を介さずに送れるというのは、確認作業がなくなるという意味ではありません。

送り手が取引に署名し、参加者がルールを検証し、有効な履歴を共有することで、受取人が次にその資金を使える状態にします。

ここで移転しているのは、ビットコインです。円の銀行預金を相手の口座へ振り替えているわけではありません。

原論文の9ページ目には、参考文献が並んでいます。本文の説明は第12章までです。読み返す際は、英語の原文、掲載されている日本語訳、そしてこの記事を、章ごとに見比べていただければと思います。