このブログでGoogleのIlya Grigorikが言及している、

（ビットコインの）デジタル貨幣という側面より、もっと興味深く大きな意味をもつイノベーションは、その土台となっているブロックチェーンのテクノロジー。

という考え方は、いまやベイエリアの中心的な論調。ですので、ビットコインの貨幣的側面の規制を当局が検討したり、それがメディアで報じられても、まったくひるまずに、昨年後半あたりはブロックチェーン周辺のスタートアップにかなり投資がされています。

それらのスタートアップのサービスがこれから世の中に順次でてくるので、ブロックチェーンの仕組みについてはもう一段深く理解したいなと考えてました。その仕組みの概要や経済的な意味については、この日本語の記事のようにまとまったものはかなりでてきてますが、「どうしてこの仕組みにしたのか？」「この仕組みでなかったら、どういうリスクがでるのか？」という説明が詳しくされてないので、あまり腹落ちしてませんでした。しかし、このIlyaのブログはそこをしっかりカバーしてくれてます。経済的な議論は外して、デジタル署名 / proof-of-work / トランザクションブロックの仕組みに的を絞った内容です。原文が平易かつ詳細でよくできているので、是非一読ください。相当長いですが、丁寧に説明してイラスト入りなので長くなっているだけで、難解ではないです。

下記は、ご参考までに、自分自身の理解の確認のためのメモをシェアします。

1) 取引の信頼性を三者で担保する仕組みをつくってみる

• BobがAliceに切手を渡し、代金は将来払うという契約を結ぶ。その契約書に、第三者のChuckも立会人として署名し、３人がそれぞれコピーを保持する。その後、BobもしくはAliceが偽った主張をしても、Chuckのコピーで取引内容が証明できる。また、Chuckのコピーがなかった場合は、その取引がなかったことを証明できる。
• この仕組みの弱点は、立会人の信頼性に頼っていること。もし、Chuckが不正を働くと、全ての信頼性の仕組みが崩壊する。

2) PKI (公開鍵 & 秘密鍵) を利用した仕組みに変更する

• 上記1) で立会人が担っていた、本人認証 / 債務履行拒否の防止 / 取引内容改ざん阻止という役割をPKIに代替わりさせる。
• 取引の参加者はそれぞれの公開鍵/秘密鍵のセットをもち、公開鍵は誰でも確認できるように公開しておく。Aliceは、取引内容のデータを秘密鍵で改ざんできないように（注: 秘密鍵でデータを読めないようにするわけではない。）し、そこに彼女の署名を暗号文にして加える（これでデータと署名が紐づく。）。暗号文となった署名部分は、Aliceの公開鍵で解読できるようにしておく。
• Bobは、Aliceの公開鍵で署名を解読する。それができるということは、その署名がされたデータはAliceの秘密鍵で改ざんされないように作業されたことの証明になる。つまり、Aliceの秘密鍵を知っているのはAliceだけなので、彼女は取引内容を否定できない。この時点で、BobはAliceの本人認証もできる。また、Bobもしくは第三者は、Aliceの秘密鍵を持ってないので、取引内容が記載されたデータを改ざんできない。

3) 取引数が増えてきたら

• AliceとBobがその後、Alice->Bob、Bob->Aliceという切手取引を複数行うと、最終的にどちらがどちらにいくら払うべきか、相殺後の金額を計算することになる。
• これが示唆するところは、もし（ユーザIDから個人情報を特定できないように担保できて、かつ）取引内容が公開されていれば、どのIDがどのIDにいくら払うようになっているかというバランスを、世の中の全ての取引について、誰でも計算ができるようになる。つまり仲介者や監査する役目（= 銀行）がなくても自律的に管理できるようになるということ。

4) 三者間以上に取引が広がっていったら

• Alice -> Bob、Bob -> Alice、Bob->Johnというかたちで支払義務がある取引が行われたとする。Bob->Johnの取引について、BobはAlice->Bobでもらえることになっているお金を充当することにする。
• Bobは、Alice->Bobの取引のユニーク性を証明するSHA-256チェックサムを計算し、Bob->Johnの取引のデータに記載する。これで、Bob->Johnの取引は、Alice->Bobの取引を参照するようになる。
• Johnは、AliceとBobの公開鍵で各取引を認証でき、そのデータの内容を順次チェックすることで、「Alice->Bobの取引がBob->Johnの取引に引継がれていること。」「Bobは、Alice->Bobの取引を他の取引に引き渡したりしてないこと。」を確認できる。
• AliceはBob->Johnの取引に直接介在していないが、Bobの公開鍵でその取引を認証でき、データの内容をみるとAlice->Bobの取引が参照され引継がれていることが確認できる。

5) 二重取引の可能性

• 上記の4) の仕組みには穴がある。BobとJohnがお互いの取引を記帳した時点では、他のメンバはその取引の存在を認識していない。もし、Bobが悪意をもって、Bob->Johnの取引履歴を削除した記録を第三者であるKatyに見せることで、先ほどと同様に、今度はBob->Katyの取引にAlice->Bobの取引を充当したとする。いわゆる二重取引である。
• これはKatyがAliceに代金の支払を請求した際に、「もうJohnに払ったわよ。」ということで発覚する。しかし、その時点でBobは逃走しているので、詐欺が成立する。

6) 分散化した合意形成ネットワークの限界

• 上記5) の解決策としては、全員が取引に立ち会い同時に記帳することである。リアルに立ち会うことはムリでも、取引が起きるたびに都度全員が同じタイミングで記帳するソフトウェアの仕組みはつくれる。しかし、そのうちの誰かがオフラインになっていたら成り立たない。
• もし市場の参加者数が多くても、それが固定であれば、「50%以上の参加者が記帳することで承認すればOKで、残りの人はその後データを反映させる。」ということができる。しかし、現実は、市場への参加者はどんどん増えている途上で、何人が全員なのかというのことを把握できない。また、参加しているようにみえて、もう実は既に死んでいるメンバを把握できない。また、偽アカウントを大量につくる悪者を止められない。
• 一つの解決策としては、全ての参加者を登録制にして、一つのDBだけで全ての取引を管理すること。これはこれで別の問題を生む。システムの稼働は誰が担保し、どう冗長化し、セキュリティはどう対処するのか。誰が管理者権限をもつのか。そもそも、担当する人（or 組織）はその役割を担うのに、どのようなインセンティブがあるのか？などという別の悩みを続々と生み出してしまう。
• よって、分散化ネットワークを採用するときの要件を緩めないと、実現不可能。

7) 分散化した合意形成ネットワークの要件を緩める

• 一時的に記帳データに不整合がでることを許容する。
• 全ての参加者の記帳データが最終的には同じものに収束していくシステムにする。
• 記帳データの不整合に対処できる仕組みを用意する。
• 二重取引ができないかたちにする。
• 偽アカウントの大量発行への対策を取る。

8) proof-of-workで偽アカウントの大量発行による不正リスクから守る

• 偽アカウントの大量発行による不正リスク対策としては、アカウントを作成するコスト、もしくは取引を承認するコストを割に合わないものにする。
• 偽アカウントの発行をテクニカルに防止しなくても、システム全体を覆して得られる利益よりも、アカウントをつくる（or 取引を承認する）コストの方が高ければ、悪者にとっての動機がなくなるので、安全な市場になる。（承認数を水増しするような悪意のあるシステム操作は別論点。システム上、そのような不正に対する安全を担保できるという前提に立てば、コスト vs 利益の問題に集約されるというポイントである。）
• そこで取引の承認をする権利を得るコストを上げようというのが、proof-of-workの発想。SHA-256で生成するハッシュ値に、「頭のx桁が必ずゼロでなくてはいけない。」という制約をつける。16桁のうちの5桁をゼロにするには、平均で1000万回の試行が必要になる。

9) 二重取引の防止

• 取引を有効とする前に承認が必要であるというプロセスにすると、二重取引は防げる。しかし、全員の承認や過半数の承認としても、「全員」が誰か、またその数がわからない。そこで現実的には、「N人の承認」が必要というかたちで要件を緩める。Nの数が多いほどリスクは減らせる。N値は、リスクの大きさと承認までにかかる時間コストのトレードオフになる。
• 仮に10の利益が得られる取引があるとする。偽アカウントの複製に0.001コストがかかる場合に、10,001人以上の承認が必要だという条件にすると、利益以上にコストがかかるので、悪者は諦める。もしくは、proof-of-workの導入で、承認をするのにコストが1かかるようになったとする。そうなると、11人以上の承認が必要というルールにするだけで、悪者のモチベーションはなくなる。（そもそも恨みがある場合は除く。）

10) proof-of-workにインセンティブを与える

• 上記9) のように、proof-of-workには詐欺を防ぐ効果があるが、そもそもまともな取引をしたいだけのほとんどの参加者にとっては、わざわざproof-of-workをするモチベーションがない。そこで承認の対価として手数料を導入。
• 取引をして承認を求めるユーザにとっては、手数料は安くなくてはいけない。承認をする側は、proof-of-workの作業コスト以上のメリットが必要。そこで、承認をするユーザは、複数の取引をまとめてプールして承認する（= 手数料総額が多くなる）ことができるようにする。
• この取引をまとめたものが「ブロック」で、それぞれのブロックが直前のブロックを参照してつながっていることから「ブロックチェーン」と呼ばれている。
• 承認者は手数料総計が採算の合う数だけ積み上がれば、プールの中身に二重取引がないことを確認して、手数料総計を表した取引を1件最後に追加する。そしてproof-of-workで取得したハッシュと、直前のブロッグの参照情報を記載したうえで、ブロックを締めて、市場に宣言する。取引当事者はブロックの中身を確認することで、取引を正式に完了することができる。
• 同じ取引を複数の承認者がそれぞれの作成中のブロックにプールしている可能性はある。先にブロックを締めて宣言した承認者のものが、次々と別の承認者にも認められて、正当なブロックとなっていく。作業内容が重複していた承認者は、その状況に気づき、作業をやり直すことになる。

11) ブロックチェーンのコンフリクトを解消する

• どのブロックが生き残るかは市場の原理に任せるが、もう一つの条件として、長い方のブロックチェーンに常に従わなければいけない。よって、短い方のために追加のブロックをつくっていた承認者は、長いブロックを見つけたらそれを正として、その新しい情報に基づいた作業に切り替える。
• よって、どのブロックも「やり直しになるリスクがゼロ」ということはありえない。しかし、一般的には、長さの違うブロックには比較的短時間で出会うので、「承認されたと思ったブロックが後からなくなって、承認されない状態がまたずっと続く。」というリスクは低い。また、後ろにブロックが長くつながればつながるほど、そのブロックはやり直しになるリスクは低くなる。
• ブロックチェーンが長くなると、その途中のブロックにある特定の取引を無効にするような不正をするのが難しくなる。悪者は、その1個手前のブロックを作り直し、かつ、他のブロックチェーンより総延長が長くなるように、かなりのブロック数を追加しなくてはいけないので、やり直さなくてはいけない作業が膨大になる。