オブジェクトの広場はオージス総研グループのエンジニアによる技術発表サイトです

クラウド/Webサービス

ビットコイン論文からさぐる ブロックチェーンのヒント

第7回 ネットワークと誠実なノード 後編：事例編
オージス総研
樋口 匡俊
2019年8月27日

前回は「前編：理論編」として、論文を読みながらビットコインの P2P ネットワークの仕組みについて説明しました。後編となる今回は、論文を補足すべく、実際に発生した二つの事件を通じて、ネットワークについてさらに詳しく見ていきます。

ビットコインは止まらない？

ビットコインは生まれてこのかた無停止、とはよく聞く話です。

ホントかどうか確かめようと思ったら、「bitcoin explorer」で検索してみましょう。エクスプローラー (explorer) というサービスがいくつも見つかるはずです。

エクスプローラーを見ると、過去にどのブロックがいつ生成されたかが分かります ※1。ざっと眺めてみると、数分から二十分ぐらいの間隔で生成されているブロックが多いようです。サトシが定めた基準は平均十分でしたので、妥当な結果かと思います。

では、以下のブロックはどうでしょうか。

Height Time (GMT) Hash
74635 2010-08-15 16:57:20 00000000004777fede3d9f39fd8513fce39932e7eaf1cada6481426835df6285
74636 2010-08-15 17:01:16 0000000000313ca3d16c7123eff441b15dfecbc33cd75e58907bb92b0777dbb4
74637 2010-08-15 17:02:43 0000000000606865e679308edf079991764d88e8122ca9250aef5386962b6e84
74638 2010-08-15 23:53:59 000000000069e1affe7161ab4bcbeacebb4ddf155b50e807f42de971b688a09b

74638番のブロックは、前のブロックから約七時間後に生成されています。

Height Time (GMT) Hash
225427 2013-03-11 21:25:37 000000000000008051f10f774fbcee0173dcca4682f0c2f694d3323f55e5c584
225428 2013-03-11 21:33:31 000000000000003a8a04797d89894b151c1604d14d861a16e40dc18d0ea9fc7f
225429 2013-03-11 21:59:31 0000000000000366ce98ca28338900094e8cbf445776253181749f782546d006
225430 2013-03-11 23:24:19 00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932

225430番のブロックは、約一時間半かけて生成されたようです。

今回は、これら二つのブロックにまつわる二つの事件を通じて、ビットコインのネットワークに関する理解を深めていきましょう。これまでの連載を前提にしていますので、不明な点があれば特に前回の記事を参照してください。

二つの事件

一つ目の事件は、2010年8月に発生した「Value Overflow Incident」です。第2回で紹介した、「トランザクションを信じるな」というメールの事件です。以下では、これをオーバーフロー事件と呼ぶことにします。

もう一つは、サトシ不在の中で発生した「March 2013 Chain Fork」です。以下では、その顛末をまとめた文書「BIP 50」にちなんで、BIP50事件と呼ぶことにします。

オーバーフロー事件の前夜

まずはオーバーフロー事件について、発生前の状況を簡単に見てみましょう。

ビットコインのネットワークは、2009年1月に稼働を開始したと言われています。当初、参加者はサトシやハル・フィニーなどごく少数でしたが、事件までの約一年半で増えていき、事件の三か月前には、例の L氏によるピザのオファーがビットコインのフォーラムに投稿されています。

その間のビットコインは、ジェームズ・ドナルドらの懸念をよそに、比較的順調だったと言ってよさそうです。そのことは、事件の二か月前の L氏とサトシのやりとりからも見てとれます。

L氏「みんな欠陥をさがしてるけど、よく持ちこたえてるよね」
サトシ「幸いにも、これまで生じた問題は全て想定内だった」※2

オーバーフロー事件の発生

74638番のブロックにおかしなトランザクションがある、という第一報がビットコインのフォーラムに投稿されたのは、2010年8月15日午後6時 (UTC) のことでした。

問題のトランザクションを見ると、何者かにコインが約1840億枚譲渡されています。ビットコイン論文に具体的な数字は書かれていませんが、サトシがあらかじめ決めておいたコインの総発行枚数は2100万枚です ※3。つまり、上限をはるかに超えるコインが、たった一つのトランザクションで生まれてしまったのです。

オーバーフロー事件の原因

すぐに原因の分析が行われ、どうやらトランザクションの検査処理の不備を突かれたらしいことが分かりました。大量のコインを譲渡するトランザクションを作ると、オーバーフローという現象が発生し、検査をすり抜けられるようになっていたのです。

この検査というのは、論文には書かれていないちょっとした足し算や数値の大小比較です。ブロックチェーンというとデジタル署名や PoW などの技術要素に目を奪われがちですが、一見単純そうな検査に「悪魔」が潜んでいたわけです。

バグは修正したものの…

サトシはギャヴィン・アンドリーセン (Gavin Andresen) らフォーラムに集う人々の力を借りつつ、第一報から約四時間という素早さで、バグを修正したパッチを公開しました。その後まもなく、正式に新バージョン 0.3.10 もリリースしています。

ここで全ノードを新バージョンに一斉更新、といきたいところですが、P2P ネットワークですのでそうはいきません。ネットワークの参加者は対等な仲間であって、命令も強制もできません。また、事件や新バージョンにそもそも気付いていない参加者は、旧バージョンを使い続けるでしょう。

さらに、新バージョンに更新しても問題のトランザクションは残ったままです。新バージョンは、今後の検査を正しく行うものであって、すでにブロックのチェーンに取り込まれたトランザクションを取り除くものではありません。

サトシの反撃

サトシは問題のブロックを削除し、新たなチェーンを伸ばすことを提案します。要するに、ビットコイン論文に出てくる攻撃者と同じことをして、問題のトランザクションを取消してしまおうというわけです。※4

以下、この案を三つのステップに分けて見てみましょう。

ステップ① 旧バージョンを止める

サトシは、とにかくまずは旧バージョンの PoW を止めて、問題のチェーンの伸びを鈍らせるようフォーラムで呼びかけます。目標は問題のチェーンを追い越すことであり、旧バージョンがワークをしなければそれだけ追い越すことが簡単になるからです。

このことは、見方を変えると、「誠実な」ノードが止まればサトシの「攻撃」が成功しやすくなるということですね。ビットコインが無停止かどうかはさておき、止まると危険なので止まるわけにはいかないのです。

ステップ② 問題のブロックを削除する

ノードを止めたら、次は問題のトランザクションが含まれている74638番ブロックを削除します。

ブロックに関する情報は、「blk0001.dat」や「blkindex.dat」といったファイルとして各ノードが持っていますので、それらのファイルを削除します。あるいは、問題のブロックを含まない古い状態のファイルで置き換えます。

たったそれだけで、個別のノードとしては削除完了です。あとはネットワークとして、問題のブロックを取消すことを目指すことになります。

ステップ③ 問題のチェーンを追い越す

新バージョン 0.3.10 に更新し、再びノードを起動します。新バージョンですので、問題のトランザクションや74638番ブロックが届いても、検査ではじいて受け入れません。かわりに、問題のトランザクションを含まない新たな74638番ブロックを作り、新たなチェーンを伸ばしていくことになります。

冒頭紹介した74638番ブロックの間隔が七時間ほど空いていたのは、事件発生から新たなブロック生成までに、それだけ時間を要したことの表れだったわけです。

新バージョンのノードのチェーン

こうした新たなチェーンを伸ばすノードが多数派になれれば、問題のチェーンを追い越すことができるでしょう。以下は、フォーラムに投稿されたサトシの説明です。

1) Once more than 50% of the node power is upgraded and the good chain overtakes the bad, the 0.3.10 nodes will make it hard for any bad transactions to get any confirmations.
2) If you didn’t remove your blk*.dat files, you’re not helping to contribute to that 50%, and you’ll still show bad transactions until the good chain overtakes the bad chain.

1) 50% 以上のノード・パワーが更新され、正しいチェーンが不正なチェーンを追い越せば、0.3.10 ノードによって不正なトランザクションが承認を得ることは困難になるでしょう。
2) blk*.dat ファイルを削除していなければ、あなたはその 50% に貢献できませんし、正しいチェーンが不正なチェーンを追い越すまで不正なトランザクションをさらすことになるでしょう。

つい数時間前まで誠実だった旧バージョンのノードは、いまや意図せずして攻撃者に加担するノードと化しています。放っておけば、問題のトランザクションを含むチェーンを伸ばし続けるでしょう。サトシは、命令や強制にならないよう言葉を選びつつ、正しいチェーンに貢献すべきだとほのめかしているのでしょう。

攻撃者に加担すると言っても、旧バージョンは、新バージョンから新たなブロックがブロードキャストされれば受け入れます。新バージョンが多数派となり、新たなチェーンが最長となれば、図のように旧バージョンも新たなチェーンを伸ばすようになります。

旧バージョンのノードのチェーン

再び問題のトランザクションが届いたら、旧バージョンは相変わらず検査を通過させ、不正なブロックでチェーンを枝分かれさせてしまいます。しかし、その枝はそのうちまた新たなチェーンに追い越されます。

早目に新バージョンに更新するに越したことはないのですが、新たなチェーンが最長のチェーンとして十分伸びてしまえば、事件はひとまず収束と言ってよいわけです。

オーバーフロー事件の収束

オーバーフロー事件の収束

第一報から十九時間後の8月16日午後1時、74689番ブロックのあたりで不正なチェーンを追い越したようだ、とサトシが投稿し、事件はひとまず収束します。念のため、旧バージョンが新たなチェーンに切り替えてから数時間待った上での投稿でした。

現在は、エクスプローラーを調べても問題のトランザクションは見当たりません。オーバーフロー事件によって、ビットコインは取消可能であることが実証されたわけです。論文の第1章には、現在のシステムの弱点を述べるにあたり、「完全に取消不能な取引を行うことはあまり現実的ではない (Completely non-reversible transactions are not really possible)」と書かれていますが、ビットコインもその点では同じです。

取消を提案したのは、他ならぬサトシです。フォーラムに集う人々は、大して反発することもなく、サトシに従い対応を進めていきました。オーバーフロー事件は、TTP が不要と謳うビットコインにおいて、実質的にはサトシが TTP であるように感じられる事件でもあります。

とはいえ、取消したトランザクションは、所有していない・所有できるはずのないコインを譲渡するものであり、不正とみなすのが自然でしょう ※5。また、ビットコインの危機に際し、その発明者であるサトシの判断を尊重し協力したことは、安易に責められるものではないでしょう。

それでは、もしも不正かどうか判断がつかない場合はどうなるのでしょうか？また、サトシが判断してくれない場合はどうでしょうか？そうした疑問を投げかけてくるのが、次に見る BIP50事件です。

サトシの退場と BIP の誕生

2010年末リリースのバージョン 0.3.19 を最後に、サトシはビットコインから離れ、フォーラムなどにもほとんど現れなくなります。その後のビットコインは、サトシに代わってソースコード・リポジトリを管理するようになったアンドリーセンらを中心に、開発が進められていきました。

絶対的な存在が去ったビットコイン・コミュニティは、RFC や PEP を参考に、BIP (Bitcoin Improvement Proposals, BIPs) を作り上げます。BIP は、コミュニティ運営の仕組みであり文書群です。

文書にはいくつか種類があり、その一つ Standards Track BIP には、ビットコインの新機能や技術的な変更点が記述されています。誰か一人が勝手に仕様を変更するのではなく、あらかじめ決められた手続きに沿って変更していこうというわけです。

BIP 50 は、一般的なガイドラインや参考情報が記述された Informational BIP に分類されます。以下では、主に BIP 50 の記述や、当時のヴィタリク・ブテリンの記事、アーヴィンド・ナラヤナン (Arvind Narayanan) の分析を参考にしながら、BIP50事件について見ていきます。

BIP50事件の発生

2013年3月11日深夜 (GMT) 、ビットコインのチャット (IRC) に、環境によってチェーンの長さが異なって見えるという書き込みがありました。例えば、あるノードでは 225431番のブロックが見えているのに、エクスプローラーで見ると一つ前の 225430番までしか見えないと言うのです。

はじめのうちは、一部のノードの問題と思われていたようですが、報告が増えるに従い、ネットワーク全体の問題らしいということが分かってきました。どうやら、ブロックのチェーンがフォーク (fork) しているらしいのです。

ここでいうフォークとは、ノードによって最長のチェーンが異なり、それぞれ別々に伸び続けているということです ※6。具体的には、最新バージョン 0.8.0 のノードと、旧バージョンである 0.7.2 以前のノードとの間で、フォークが発生していました。

BIP50事件の発生

図のように、新バージョンのノードは、五千を超える多数のトランザクションを含むブロックを受け入れていました。一方、旧バージョンにとって、そのトランザクション数は上限を上回っており、そのブロックを受け入れられませんでした。そうして新バージョンは問題のブロックを含むチェーンを、旧バージョンは含まないチェーンを、それぞれ正しい最長のチェーンとみなして伸ばし続けていたのです。

冒頭の225430番ブロックの生成に時間がかかっていたのは、そのときフォークが発生し、PoW を行うパワーも分裂・低下したためと推測されます。

意図しないルールの変更

原因は、新バージョン 0.8.0 から「一ブロックあたりのトランザクション数の上限」というルールが変更されていたことでした。本来なら、フォークするようなルール変更は前もって BIP などで議論されるはずですが、今回はデータベース・ライブラリを変更した結果、意図せず行われたルール変更でした。

旧バージョン 0.7.2 まで、ビットコインはブロックを記録するデータベース・ライブラリとして Berkeley DB を利用してきました。しかし、新バージョンからは、性能向上を目的として、LevelDB でブロックを記録するよう変更しました。※7

旧バージョンまでは、一ブロックあたりのトランザクション数は、Berkeley DB のロックの設定によって間接的に上限が決まっていました。そのことは、ビットコイン論文にはもちろん書かれていませんし、ソースコードを読んでも中々気付きません。ルールと言っても、認識されていないルールだったのです。おそらく、サトシ自身も気付いていなかったのではないでしょうか。

新バージョンで LevelDB が導入されると、Berkeley DB とともに設定は消えてなくなり、トランザクション数の上限は緩和されました。旧バージョンでも、設定を変更し上限を緩和することは可能であり、同様の事件は起こりえたと言われています。しかし、多くの人はデフォルトの設定値から変更せずにノードを運営していたため、これまで問題とはならなかったのです。

ノードの決裂

フォークした二つのチェーンは、どちらもルールに基づいているという点で正しいチェーンです。旧バージョンと新バージョンとでルールが違った、つまり、ブロックの正しさに関する意見が異なっていたというだけで、どちらが正しいとは一概には言えません。

サトシは第4章で、PoW を用いた仕組みを多数決による意思決定にたとえていました。その多数決は、同じ意見のノード同士を一つのチェーンに集約するものであって、異なる意見を一つにまとめあげるものではないわけです。異なる意見を持つノード同士は合意せずに決裂し、異なるチェーンを伸ばしていくことになるのです。

二つの解決案

どちらのチェーンが正しいとは言えませんが、早目にどちらかのチェーンに一本化しなければなりません。フォークが長びくと、たとえ大きな問題が発生しなかったとしても、ビットコインの信用が低下するかもしれないからです。論文の第2章には「参加者が合意するためのシステムが必要」と書かれていますが、現実にはうまく機能しないではないか、と。

姿を消したサトシに判断を仰ぐことができない中、コミュニティの中心メンバーたちは、二つの案を検討しました。

解決案①：アップグレード

一つは、多数派である新バージョン 0.8.0 にアップグレード（更新）してもらうという案です。

BIP 50 によると、事件発生時点で新バージョンは全体の 60% と多数派を占めていました。少数派の旧バージョンは、なぜ一か月も前にリリースされた新バージョンに更新していないのでしょうか。早目に更新すべきではないでしょうか。更新すれば、旧バージョンのチェーンよりも長い新バージョンのチェーンに切り替えるはずです。

しかしこの案では、いつになったら全員が新バージョンに更新してくれるか分かりません。その間、二つのチェーンはフォークしたまま伸び続け、二重使用攻撃のリスクにさらされます。いずれ旧バージョンから新バージョンのチェーンに切り替わったとき、無効になるトランザクションが多数出てくるかもしれないのです。

解決案②：ダウングレード

もう一つの案はダウングレード、つまり、すでに新バージョンに更新済みのノードを旧バージョンに戻して、旧バージョンを多数派にしてしまおうというものでした。

新バージョンは上限が緩和されており、より上限の低い旧バージョンのブロックを受け入れられます。旧バージョンが多数派になれば、いずれ図のように新バージョンのチェーンを追い越し、新バージョンは旧バージョンのチェーンに切り替えるはずです。

ダウングレード案

この案②は、全員がダウングレードする必要はありませんので、案①より早く事件を解決できそうです。しかし、新バージョンは多数派であり、今後も増え続けると予想されます ※8。なるべく早めに多くのノードをダウングレードしなければ、新バージョンのチェーンを追い越せなくなるかもしれません。

マイニングプールの役割

結局、案②が実行され成功するのですが、そのとき、BTCGuild と Slush Pool というマイニングプール (mining pool) が大きな役割を果たしたと言われています。

マイニングプールとは、複数のノードが参加し、協力して PoW を行うための仕組みです。マイニングプールには主催者がおり、参加しているノードが PoW を旧バージョンで行うか新バージョンで行うかを決めることができました。

事件発生当時、BTCGuild は新バージョンで PoW を行っており、ネットワーク全体で 20～30% のパワーを占めていたと言います。新バージョンは全体の 60% ですから、BTCGuild がダウングレードすれば、新バージョンは 30～40% となり、かわりに旧バージョンが 60～70% と多数派を占めるようになります。

それが本当なら、この時 BTCGuild の主催者は、多数派を決めるキャスティング・ボートを握っていたことになります。短い時間ではあったかもしれませんが、どちらのチェーンが最長となるかが、一人の決断にかかっていたのです。

適切な人々

次回以降またとり上げる予定ですが、議論の結果、BTCGuild の主催者はダウングレードすることを決定しました。フォークが発覚してから約一時間後の、素早い対応でした。それに応じて、フォーラムでもダウングレードの呼びかけが行われ、旧バージョンのチェーンが最長となり、事件はひとまず収束しました。

BIP 50 には、「適切な人々 (right people)」同士で直接話ができたことが良かったと記録されています。その人々とは、コミュニティの中心メンバーや、BTCGuild の主催者のことでしょう。実際、この事件は彼らのおかげで解決したと言ってよいでしょう。一方で、少数の「適切な人々」が多大な影響力を持つ場合があると感じさせる事件でもあったと言えるでしょう。

また、ある程度 PoW を行うパワーが要るものの、ちょっとしたルール変更でフォークが発生し、ネットワークが混乱しうることも示されました ※9。ややこしいのは、変更前と後、どちらのルールが正しいとは一概には言えないことです。「適切な人々」同士で意見が合わなかったら、チェーンともども決裂してしまうのでしょうか？

今回はとり上げませんが、「ビットコイン」や「ブロックチェーン」を「ハードフォーク」や「ガバナンス」などと組み合わせて検索してみると、そうした疑問に関する多くの議論が見つかるでしょう。

おわりに

今回は、ビットコインのネットワークについて、論文を補足すべく、オーバーフロー事件とBIP50事件を紹介しました。

タイムスタンプや PoW など、比較的明確な個々の技術要素と違い、それらを統合する P2P ネットワークでは、「誠実なノード」や「適切な人々」など、揺れ動く人間の行動や判断に関する話に踏み込まざるをえないように思われます。次回は、第6章「Incentive」を読みながら、そうした人間にかかわるビットコインの仕組みを見ていく予定です。

注

※1: ブロックの日時は、二時間程度はズレる可能性があるので、大体の目安と考えた方がよいでしょう。ただしズレると言っても、その日時は各ノードによる一定のルールに基づく検査を通過しています。精度が低いと見るよりも、ネットワークの参加者たちが認めたという、ビットコインらしい確かさを持った日時と見た方がよいでしょう。また、エクスプローラーは特定の個人・団体が運営するサービスであり、その情報を信じるかどうかはユーザー次第です。

※2: laszlo: “Everyone has the obvious questions looking for holes in it but it is holding up well”
satoshi: “Fortunately, so far all the issues raised have been things I previously considered and planned for.”

※3: サトシが「21,000,000 coins」と表現していることを踏まえて2100万「枚」と数えています。

※4: 前回読んだ第4章の一文を再掲します。

To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes.

過去のブロックを書き換えるには、そのブロックとその後のすべてのブロックに対して、攻撃者はプルーフ・オブ・ワークを再実行し、その後で誠実なノードのワークに追いつき、追い越さなければならないだろう。

※5: 正しいか不正かではなく、コードを実行したありのままの結果に従うという考え方もありますが、今回はとり上げません。

※6: ハードフォーク (hardfork) と呼ばれることもありますが、今回は単にフォークとしています。ソフトフォーク (softfork) ともども、当たり前のように使われる用語ですが、意外に定義はまだ統一・洗練されていないように思います。フォークの分類・定義を試みる BIP 99 がありますが、Status は Draft です。

※7: このとき全面的に LevelDB に移行したわけではなく、ウォレット機能は Berkeley DB のままでした。

※8: 当時、旧バージョンのノードには次の警告メッセージが表示されていたそうです。「警告: 表示されているトランザクションは正しくないかもしれません！ あなたがアップグレードするか、他のノードがアップグレードする必要があるかもしれません。 (Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade.)」

※9: すでにオーバーフロー事件の前に、アンドリーセンはフォーラムで次のように語っていました。「遅かれ早かれ誰かがネットワークをめちゃくちゃにしようとするだろう。」「その人たちは既存のコードを改造するか独自のバージョンを作って、ネットワークにとって脅威となるだろう。」(Good idea or not, SOMEBODY will try to mess up the network (or co-opt it for their own use) sooner or later. They’ll either hack the existing code or write their own version, and will be a menace to the network.) BIP50事件は、「適切な人々」が図らずも脅威となるバージョンを作ってしまった事件でもありました。

参考資料

オーバーフロー事件：

BIP50事件：