ビットコインの開発現場は誰がどのように運営管理しているのか？
 |
ハウツー、ビットコインコア開発に参加するには |  |
初級 |  |
17分 |
|---|
本記事は Casa の共同創設者＆最高技術責任者 JAMESON LOPP 氏著「 Who Controls Bitcoin Core? 」（2018年12月15日公開）を Katakoto さんが翻訳、@TerukoNeriki が一部加筆修正したものです。
Bitcoin Core の GitHub リポジトリにコード変更をマージする権限は一体誰が持っているのか？これは非常によくある質問です。長年、関係者の間では、マージ権限がビットコインプロトコルの「管理中枢」とされてきました。しかし、私はこの質問自体が権威主義的で的外れだと考えます。私の主張に賛同する人は少ないでしょう。そこで本記事では、 Bitcoin Core の開発現場、さらにはビットコインプロトコルの進化過程を解説します。
Bitcoin Core の歴史
Bitcoin Core はビットコインプロトコル開発の指揮中枢と言うよりは、フォーカルポイント（ゲーム理論でプレイヤーが相互にコミュニケーションをとれない場合にデフォルトで選択される傾向があるソリューション）です。もし何らかの理由で Bitcoin Core が消滅しても、新たなフォーカルポイントが生まれるでしょう。現在は GitHub リポジトリが技術議論のプラットフォームとしてプロトコル開発拠点となっていますが、コミュニケーションプラットフォームは利便性の問題であり、プロジェクトの定義や整合性とは無関係です。実際、ビットコイン開発のフォーカルポイントは、プラットフォームだけでなく、その名前さえも変化してきたのです。
- 2009年初頭、ビットコインプロジェクトのソースコードは SourceForge に保存されたただの .rar ファイルでした。サトシと初期開発者たちはコードパッチを電子メールで送受信していました。
- 2009年10月30日、 Sirius （ Martti Malmi ）が SourceForge にビットコインプロジェクトのために Subversion リポジトリを作成しました。
- 2011年、ビットコインプロジェクトは SourceForge から GitHub に移行。
- 2014年、ビットコインプロジェクトは Bitcoin Core に改名されました。
誰も信用しない
GitHub には Organization レベルの「メンテナー」アカウントが複数あります。メインテナーはマスターブランチにコードをマージできます。メインテナーは特権的立場というよりは、保守管理機能に近いです。もし誰でも自由にマスターブランチにマージできるとしたら、すぐに「船頭多くして船山に登る」状況に陥ることは目に見えています。 Bitcoin Core は個人に与えられた権力が乱用された場合、容易にそれを覆せるという「最小特権の原則」に従っています。
Core はマージコミットへの署名が可能な PGP 鍵という重要リストに関して透明性を保っています。
ここで学ぶべきは GitHub を信用してはいけないということです！ Bitcoin Core でさえ、リポジトリの変更権限を持つ人物を全員把握しているわけではありません。おそらく GitHub 従業員だけでも数十人がその権限を持つでしょう。
Peter Todd（2018年10月4日）
敵対的アプローチをとるなら、GitHub は信用できません。GitHub の従業員は管理者権限を使って、メンテナーの同意なしにリポジトリに悪意あるコードを追加することができます。しかしながら、 GitHub 従業員が Bitcoin Core メンテナーの PGP 鍵を不正入手する可能性は限られています。 Bitcoin Core はコードの整合性を GitHub アカウントではなく、すべてのマージコミットが信頼できる PGP 鍵で署名されていることを確認するという継続的な統合システムに委ねています。PGP 鍵は既知のIDと紐づいていますが、常にそうであると仮定するのは危険です。なぜなら鍵が漏洩しても、鍵保有者が他のメンテナーに通知しない限り、漏洩事実を知る術がないからです。このように、コミットに署名する PGP 鍵は完璧なセキュリティを保証するものではありません。攻撃者による不正なコードの追加を困難にするだけです。
王国への鍵
執筆時点で信頼できる PGP フィンガープリントは以下の通りです。
71A3B16735405025D447E8F274810B012346C9A6
133EAC179436F14A5CF1B794860FEB804E669320
32EE5C4C3FA15CCADB46ABE529D4BCB6416F53EC
B8B3F1C0E58C15DB6A81D30C3648A882F4316B9B
CA03882CB1FC067B5D3ACFE4D300116E1C875A3D
上記の鍵は、以下５名のものとされています。
Wladimir J. van der Laan <laanwj@protonmail.com>
Pieter Wuille <pieter.wuille@gmail.com>
Jonas Schnelli <dev@jonasschnelli.ch>
Marco Falke <marco.falke@tum.de>
Samuel Dobson <dobsonsa68@gmail.com>
これは私たちがこの５人を信用しているということを意味するのでしょうか？必ずしもそうではありません。鍵は身分証明書ではないですし、鍵が誰か他の人の手に渡る可能性もあります。では、検証用の verify-commits という Python スクリプトを実行することで得られる保証とは一体何でしょうか？
python3 contrib/verify-commits/verify-commits.py
Using verify-commits data from bitcoin/contrib/verify-commits
All Tree-SHA512s matched up to 309bf16257b2395ce502017be627186b749ee749
There is a valid path from “HEAD” to 82bcf405f6db1d55b684a1f63a4aabad376cdad7 where all commits are signed!
verify-commits スクリプトを使えば、誰でも自分のコンピュータで Bitcoin Core のコードの整合性を確認できます。スクリプトを実行すると、2015年12月のコミット 82bcf405...以降のすべてのマージコミット（執筆時点で3,400以上のマージ）の PGP 署名をチェックし、スクリプトが正常に完了すると、2015年12月以降に変更されたコードのすべての行について、 Bitcoin Core の開発プロセスを経てメンテナー鍵を持つ誰かによって「サインオフ」されたことが示されます。これは悪意あるコードが紛れ込んでいないことを100%保証するものではありませんが（メンテナーが不正を働いたり、鍵を盗まれる可能性もあるため）、攻撃リスクを大幅に下げます。ではメンテナーとは何なのでしょうか？メンテナーになる方法は？これは後ほど説明します。
重層的なセキュリティ
Bitcoin Core のコードの整合性は暗号鍵のみに依存するわけではなく、他にもさまざまなチェック機能が働いています。何層にもなるセキュリティのおかげで高い防衛力を維持できるのです。
プルリクエストのセキュリティ
- bitcoin/bitcoin のマスターブランチにプルリクエストを送ることで、誰でも自由にソフトウェアを改善するコード変更を提案できます。
- プルリクエストは他の開発者がレビューし、有害でないことを確認します。プルリクエストのレビューやフィードバック提供は誰でも自由にできます。 Bitcoin Core に貢献するのに試験はありませんし、ゲートキーパーもいませんから。プルリクエストのマージに対して合理的反論がなくなると、メンテナーによってマージされます。
- コアメンテナーは未署名コミットがリポジトリにプッシュされるのを防ぐため、プッシュ前のフックを設定します。
- マージコミットに OpenTimestamps を使って安全にタイムスタンプを打つことも可能です。
- Travis CI （Travis 継続的統合）システムは、 Git ツリー（履歴）の整合性をチェックし、マスターブランチのすべてのコミットに信頼できる PGP 鍵の署名があるかを確認するために、このスクリプトを定期的に実行します。
- このスクリプトは誰でも実行可能で、2015年12月以降の全マージコミットの PGP 署名を検証できます。この記事の執筆中、私も自分のノートパソコンで実行してみたところ、検証は25分で完了しました。
リリースのセキュリティ
- Gitian の決定論的ビルドシステムでは、同一バイナリの作成を目的として、複数の開発者が各々個別にソースコードをビルドします。もし他の開発者のものと一致しないものをビルドした開発者がいれば、非決定性の発生を意味するので、最終的なリリースは見送られます。非決定性が生じた場合、開発者は問題を突き止めて修正し、別のリリース候補をビルドします。決定論的ビルドが成功したら、開発者はバイナリに署名して、そのバイナリとツールチェーンは改ざんされていないことと、同じソースが使用されていることを保証します。この方法により、ビルドと配布プロセスが単一障害点となるのを防ぎます。技術的スキルがあれば、誰でも自身のビルドシステムを実行できます。手順についてはこのリンクをご参照ください。
- Gitian ビルドが正常に完了し、ビルダーが署名すると、Bitcoin Core のメンテナーが各ビルドの SHA256 ハッシュを使ってメッセージに PGP 署名します。ビルド済みバイナリを実行する際、ダウンロード後にハッシュを確認することで、署名されたリリースメッセージが本物かどうか検証できます。そのための手順はこちらをご参照ください。
- 上記はすべてオープンソースなので、スキルと意欲さえあれば誰でも監査が可能です。
- 上記の品質および整合性チェックをすべて通過すると、 Bitcoin Core にコミットされて最終的にリリース版となるコードはネットワークを構成するノードにデプロイされます。デプロイする主体は中央集権的組織ではなく、ノード運用者です。ノード運用者はノードが実行するコードを更新するかどうか、各自判断しなければなりません。 Bitcoin Core は意図的に自動更新機能を提供していません。ユーザーが明示的に選択していないコードを実行するのを防ぐためです。
Bitcoin Core プロジェクトは、こうした数々の技術的なセキュリティ対策を講じていますが、対策はどれも完璧ではなく、理論的には攻撃は可能です。Bitcoin Core のコード整合性の最後の砦は、他のオープンソースプロジェクトと同様、常時警戒体制です。 Bitcoin Core のコードをレビューする人が多ければ多いほど、悪意や欠陥のあるコードのリリース可能性は下がります。
コードカバレッジ
Bitcoin Core にはテストコードが多数用意されており、すべてのプルリクエストに対して実行される統合テストスイートとマスター上で毎晩実行される拡張テストスイートがあります。
テストのコードカバレッジは、以下の方法で確認できます。
- Bitcoin Core GitHub リポジトリをクローン
- ソースからビルドに必要な依存関係をインストール
- これらのコマンドを実行
- ./total_coverage/index.html にあるレポートを表示
または Marco Flake がホストしているカバレッジレポートをこちらから確認できます。
コードカバレッジ・レポート
テストカバレッジの広さは、コードが意図通りに動く確実性の高さを意味します。
コンセンサスが肝となるソフトウェアにとって、テストは非常に重要です。特に複雑な変更に際しては、綿密なミューテーションテスト、すなわち、意図的にコードを破壊して想定通りにテストが失敗するかをテストします。 Greb Maxwell は、0.15バージョンのリリース時の議論で、このプロセスについて以下のように述べています。
「テストとはソフトウェアのテストです。ではテストのテストとは？テストをテストするには、ソフトウェアを壊さなければなりません。」— Greg Maxwell
自由な市場競争
BitMEX がビットコイン実装のエコシステムについて素晴らしい記事を書いています。ビットコインと互換性のある実装は十数種類あり、「競合ネットワーク」の実装はさらに多いです。これこそオープンソースが実現する自由です。Bitcoin Core プロジェクトに不満があれば、誰でも自由に新たなプロジェクトを始められます。ゼロから作ってもよいですし、 Bitcoin Core のソフトウェアをフォークしてもよいのです。
本記事執筆時点で、アクセス可能なビットコインノードの96％は Bitcoin Core のいずれかのバージョンを実行しています。なぜ Bitcoin Core がここまで優勢なのでしょうか？他の実装への乗り換えコストがゼロに近い場合、Bitcoin Core が独占的地位を維持できる理由は何でしょう？答えは、他の実装も結局はその大半が Bitcoin Core と互換性があるか、少なくとも Bitcoin Core に非常に類似した RPC API を提供しているからです。
これは Bitcoin Core が開発のフォーカルポイントであることの証明だと私は考えています。 Bitcoin Core は他の実装と比べて開発者のレベルの高さと数の多さが桁違いなため、Bitcoin Core のソフトウェアはパフォーマンス、堅牢性、安全性が最も高い傾向にあります。ノード運用者は大切なお金を管理するのに、わざわざ２番目に優れたソフトウェアを選ばないでしょう。またビットコインはコンセンサスソフトウェアであり、ビットコインプロトコルには公式仕様が存在しません（この点についてのコンセンサスはないですが）。なぜなら仕様を決める権限を持つ人がいないからです。こうした状況では、フォーカルポイントの実装を選ぶ方が安全です。バグまで含めて他のネットワーク参加ノードと互換性を保てる可能性が高いためです。この意味において、開発フォーカルポイントのコードは実質的に公式仕様に最も近いと言えます。
Core 開発者とは？
Bitcoin Core の開発プロセスに馴染みのない人が外から見ると、プロジェクトチームは一枚岩に見えるかもしれませんが、実際にはそんなことはありません。Core 開発コントリビューター（貢献者）間の意見の対立は日常茶飯事で、既に多大な貢献をしているベテランのコントリビューターでさえ、マージされずに終わったコードをたくさん書いています。コントリビューターのためのガイドラインを読むと、かなり緩いことに気が付くでしょう。コントリビューションプロセスは、まさに「ラフな合意」と呼ぶにふさわしいかもしれません。
「メンテナーはパッチがプロジェクトの一般原則に沿っているか、マージ要件を満たしているかを考慮し、コントリビューターの全体的な合意を判定します。」
Bitcoin Core のメンテナーとは誰でしょう？一定期間、コンスタントに質の高いアウトプットを出すことで、プロジェクト内で社会資本を築き上げたコントリビューターがメンテナーになります。既存メンテナーたちが、特定分野で能力、信頼性、モチベーションを証明したコントリビューターをメンテナーに加えることが利益に叶うと思えば、その人の GitHub アカウントにコミットアクセスを許可します。リードメンテナーはプロジェクトのあらゆる面における監督者であり、リリース調整の責任者です。リードメンテナーは前任者が自発的に後任者に託す形で交代してきました。以下、これまでと現在のリードメンテナーです。
- Satoshi Nakamoto: 2009年１月３日 ～ 2011年2月23日
- Gavin Andresen: 2011年2月23日 ～ 2014年4月7日
- Wladimir van der Laan: 2014年7月14日 ～ 現在
Bitcoin Core のメンテナーは、しばしば清掃員と呼ばれます。メンテナーはコントリビューターやユーザーの合意を覆すような大きな権限は与えられていないにも関わらず、過剰な注目を集めるなど負担が大きいからです。例えば、Gregory Maxwell は2017年に個人的な理由からメンテナーを退任しましたが、一因としてスケーリング議論中に経験したプレッシャーがあると考えられます。Wladimir は Core メンテナーのストレスと、エコシステムに動揺を招いた Gavin のコミットアクセス権の削除が正しい判断だった理由について示唆に富む投稿をしています。
同様に Jeff Garzik が GitHub の Organization アカウントから削除された際には、本人も含め憤慨した人が大勢いましたが、Jeff はその時点で Core には２年間全く貢献していませんでした。そんな彼の GitHub アカウントにリポジトリ書き込み権限を残しておくことは、プロジェクトにとってメリットがないばかりか、セキュリティ上のリスクとなります。これはWladimir が投稿で言及した最小特権の原則に反します。
Bitcoin Core はテクノクラシーや象牙の塔のように参加ハードルが高いと感じる人もいるかもしれません。でも実際にコントリビューターと話せば、それは誤解だとわかるはずです。コミット権を持つのは数十人程度ですが、参加する開発者は数百人にのぼります。私もいくつか小さな貢献をしました。自分ではそうは思っていませんが、私はまぎれもなく「コア開発者」なのです。コントリビューターになりたいと思うなら、誰もあなたを止めたりしません。
「2011年、ポインターの意味すら知らなかった高校生の私が送ったひどいパッチを @bitcoincoreorg の開発者コミュニティ（特に Greb Maxwell や @pwuille ）がマージできるものにすべく色々教えてくれました。学びの場としては最高の環境です。」Matt Corallo（2018年11月18日）
「2016年に @TheBlueMatt は @ChaincodeLabs でのトレーニングプログラムを企画しました。私はビットコインについて手に入るものは全て読んでいましたが、プルリクエストを送る勇気はありませんでした。そんな私に Matt、 Alex 、 Suhas は貴重な時間を割いてビットコインについて、ビットコインへの貢献方法について教えてくれました。」John Newbery（2018年11月18日）
「 @bitcoincoreorg にマイナーなコミットをし、私が送ったプルリクエストについて @MarcoFalke、@pwuille、@orionwl、@LukeDashjr 、@jfnewbery らと畏れ多くも議論しました。みんな親切で心温かい人たちです！」Jeff Rade（2018年11月19日）
多くの人が理解に苦しむものに、ビットコイン開発のフォーカルポイントは単に Bitcoin Core の GitHub アカウントを基盤とする開発体制ではないという事実があります。Bitcoin Core はある程度体系立っています（サブプロジェクトでは、調整プロセスは中央集権的なコミュニケーション手段に頼っています）。しかし、こうしたメンバーが Core プロジェクトを意のままに操ることはできません。そんなことは GitHub リポジトリで特別な権限を付与された人でも不可能です。メンテナーが結託してクーデターを起こして GitHub リポジトリを乗っ取り、対立する開発者を検閲したり、「 Bitcoin Core 」というブランド名を使い続けることは技術的には可能です。ただ、そんなことをすれば、 Bitcoin Core は開発のフォーカルポイントではなくなるでしょう。メンテナーの行動に抗議する開発者たちはコードをフォークし、Bitcoin Core のメンテナーが管理者権限を持たない別のリポジトリで開発を続けるでしょう。
「クーデーター」まで行かなくても、物議をかもすような変更が Core に加えられた場合、一部の開発者がコードをフォークして変更前の状態に戻したソフトウェアを配布することは十分考えられます。Amaury Sechet が Bitcoin Core をフォークしてSegWit（セグリゲイテッド・ウィットネス）機能を削除し、Bitcoin ABC を作った時がまさにそうでした。あるいは、一部の人々が望む変更を Core が拒否した場合も、開発者は Core のコードをフォークして変更を加えることができます。これは以下を含め、実際に何度も起きました。
- Mike Hearn が Core のコードをフォークして Bitcoin XT を作成
- Andrew Stone が Core のコードをフォークして Bitcoin Unlimited を作成
- Jeff Garzik が Core のコードをフォークして BTC1 を作成
コードをフォークするのは簡単ですが、ビットコイン開発のフォーカルポイントを移行するのは簡単ではありません。新しいプロジェクトに時間を費やす方が賢明だと Core コントリビューターたちを説得しなければなりません。
「ビットコインに関して、私は誰にも、どの開発チームにも忠誠を誓いません。私はただ、自らの金融主権を最も確実に守ることができると判断したコードを実行するだけです。」Jameson Lopp（2017年3月18日）
もう一つよくある誤解に、ユーザーは Bitcoin Core の変更を黙って受け入れるしかないというものがあります。これはユーザーが自分に与えられた選択肢を理解した上で合意形成プロセスに参加しないなら、自らの権限の一部を開発者に移譲するも同然という自己強化型の思い込みなのかもしれません。しかし、2017年の UASF（ユーザー・アクティヴェイテッド・ソフトフォーク）運動はユーザーの力を見せつけました。shaolinfry という仮名を名乗る匿名のビットコイン開発者が、8月1日前後に予測される特定のブロック高において、マイナーに SegWit 機能の有効化を強制する BIP148 を提案しました。しかし、BIP148 は激しい物議を呼ぶ提案であったため、Bitcoin Core に採用されることはないと悟ったshaolinfry は、Core のコードをフォークして「 Bitcoin UASF 」ソフトウェアを配布しました。Bitcoin UASF のダウンロード数は無視できないレベルにまで伸び、このユーザーの支持が BIP148 の期限前にフォークのフォークを提案する BIP91 の採用をマイナーに促すプレッシャーとして機能しました。
私が考える最高の Bitcoin Core コントリビューターとは、オーナーシップを極限まで発揮する人です。John Newbery がまさにこれに該当します。CVE-2018-17144と呼ばれるコンセンサスバグを含んだコードは彼が書いたわけではありませんが、そのマージをレビューによって防げなかったこと、そしてテストケースを書いていながら見つけられなかったことに対して、今でも責任を感じています。
「CVE-2018-17144 バグの責任は私にある。」John Newbery（2018年9月24日）
私たちは皆、サトシなのです。
Bitcoin Core に貢献するには
Core コントリビューターとなるのは、気が遠くなるほど大変だと感じるかもしれませんが、やる気のある開発者を支援するリソースは豊富にあります。ここにガイドラインがありますが、Jimmy Song の「Gentle Introduction to Bitcoin Core Development 」から始める方が良いかもしれません。
Core 開発者 Eric Lombrozo も Core リポジトリ内の変更プロセスについて解説記事「 The Bitcoin Core Merge Process 」を執筆しています。
Alex B. は、ビットコイン開発の背後にある哲学について素晴らしい記事を書いています。真剣にコントリビューターになりたいと考える人は、これを読むことで大いに時間を節約できるでしょう。
慣れないうちは、Bitcoin Core プルリクエスト・レビュークラブに参加して、コードレビューの流れを確認するのも良いでしょう。
具体例を挙げましょう。本記事執筆中に、 GitHub のコミット履歴の整合性を監査するため、自分のコンピュータで verify-commits.py スクリプトを実行したところ、問題に遭遇しました。開発者が今後同じ問題に煩わされることのないように、私はドキュメント改善のプルリクエストを送りました。プルリクエスト履歴を見ればわかるように、４人の開発者が私のプルリクエストの改善法を提案をしてくれました。提案は Wiki マークアップの使い分けから Bash コマンドの簡略化、 verify-commits.py スクリプトで利用できる新しいパラメーターまで多岐にわたっていました。どの提案も理に叶っていたので、全てコードに取り入れて、自分のプルリクエストとして修正バージョンをプッシュしました。レビュークラブに参加していた開発者たちは、このプルリクエストを受け入れて、メンテナーの Macro Falke が0.18リリースに含めるためのタグ付けをしました。数日経過後も開発者からの異議申し立てがなかったため、このコードはメンテナー Samuel Dobson によって Core にマージされました。
結局、誰がビットコインを支配しているのか？
システムとしてのビットコインを完全に理解するのは事実上不可能だと私は以前から言い続けています。プロトコルであるビットコインを定義（支配）することは、言語を定義するようなものです。言語は自然発生するもので、言葉の意味に関する合意は辞書に基づくのではなく、有機的に形成されます。辞書は言語を定義するのではなく、言語という事象を記述します。同様に、ビットコインの実装はコードを介してビットコインという言語を記述します。辞書に書かれた言葉の定義についての同意を強制されることがないように、特定のビットコインの実装コードを実行するよう強制されることもありません。
言語は民主主義に基づいて管理運営されてはいません。ビットコインも同じです。マイナー、ノード、開発者、ユーザーの「投票」に基づく管理運営法について耳にしたことがあるかもしれませんが、ビットコインには該当しません。多数派が望む変更を反対する少数派に強制同意、強制採用させる仕組みはビットコインにはありません。ビットコインは支配者のいない無政府主義です。支配者（ruler: ルーラー）はいませんが、規則（rule: ルール）はあります。規則はネットワーク参加者が各々定義、施行します。
ビットコインプロトコルの変更は通常ビットコイン改善提案プロセス（BIP）を経て反映されますが、BIP は単に推奨されるベストプラクティスという位置付けで、遵守を強制されることはありません。BIP はピアレビューと合意形成プロセスを通して実施可能な変更へと導く方法にすぎないのです。
これは説明するのも理解するのも難しいですが、これこそがビットコインの反脆弱性にとって非常に重要な側面です。もし管理中枢があったら、それはビットコインの成功に怯える個人や組織に悪用される単一障害点になり得ます。最終的には、ノード運営者が各々、他のネットワーク参加者が合意規則に違反していないことを確認することで、自らを管理しているのです。このセキュリティモデルが、ビットコインのボトムアップガバナンスの基礎です。
ビットコインをコントロールする者はいません。
ビットコイン開発のフォーカルポイントをコントロールする者もいないのです。