BTCが10周年を迎えられた理由とは？BTCを存続させている5つの防御を解説

2019年6月8日から9日にかけて、アムステルダムでBreaking Bitcoinというカンファレンスが行われました。本コラムは、公開された動画や書きおこしをもとに、その発表内容を追いかけ、ビットコインのセキュリティに関する取り組みの最先端を知ろうという試みです。

発表内容を日本語で、かつ実際の事例などを交えて解説することで、少しでも皆様がビットコインの仕組みや最新の研究について詳しくなるための一助になれることを願います。

今回は「ビットコインの防御、5つの視点」と題し、Warren Togami氏の講演を見てみましょう。

安全重視のエンジニアリングプロセスによる防御

ビットコインの開発、そして長期的な成功のため、分散化された開発プロセスが非常に重要です。つまり、誰かに作業を強制される、あるいは作業を強制するといったことは忌避すべきです。安全を重視しつつ変更管理をピアレビューするというプロセスについての実現を、ビットコインはこれまで実証してきたと言えます。

ビットコインの開発者は、閉鎖的な環境での決定を好ましいと思っていません。対面での会議では、お互いのことを知り、アイディアを気軽に話し合い、問題を解決するためにブレインストーミングを行うこともできます。

しかし、オンラインではできません。オープンにオンラインで会話する場合、主な場所はbitcoin-devメーリングリストとIRCディスカッションを介して、ということになります。これは、ビットコイン改善提案（BIP）につながりました。

過去数年間で行われた主要なアップデートと言えば、segwitでしょう。元の実装の都合と、テストネットワーク上での多くの反復作業があり、実現に至るまでには13か月を要しました。完璧なものではないものの、非常に慎重で、安全を第一に考えたプロセスでした。慎重ということは、非常に遅いということでもあります。

一部の人たちは、統制（ガバナンス）が必要と考えています。ガバナンスは政治的、あるいはそれに類する外部要因に脆弱です。よくある問題としては、誰がコミット権を持っているか、あるいは持つべきかという点です。これを政治的な観点から決定するのは全く効率的ではありません。本来的には、政治的な要素は必要なく、コミット権を持つ人はピアレビュープロセスのファシリテータ、管理人としてふるまうべきです。

誰がコミット権を持っていようとも、参加するソフトウェアエンジニアの数が増えることで、コードに求められる品質は上がり、適切なレビューを経ていないものについては正しく弾かれるべきです。

リファレンス実装と多様な検証による防御

安全性重視のプロセスに対し、リファレンス実装が役に立つという場合は、これまでにないリファレンス実装も検討すべきでしょう。

例えば数年前、限られた範囲でOP_RETURNをサポートすることにしました。しかし一方、最近新しく機能追加が検討されているassumeutxoについては、議論を引き起こしています。これはフルノードを起動するひとつの方法であり、ウォレットを使用できるようになるまでの初期時間を短縮できる機能です。

リファレンス実装が十分でないと、多くの開発者が正しくない設計で実装を行ってしまったり、あるいは良くないオプションを使用する場合があります。リファレンス実装は、こうした事態を軽減する施策と言えます。

また、多様な検証についても、考える必要があります。ビットコイン開発者の多くは、コンセンサスに関して未発見のバグがある可能性や、実装によって生じうる不具合もありえるため、独自実装は本質的に危険だと考えています。

時間とともに、コードの品質は大きく向上しています。OpenSSLなど最も重要な部分の再実装や削除には多くの時間と労力が費やされていますし、2013年にはbdbでロック制限に関して不具合が発生していました。また、インフレを起こすバグもありました。

独自実装ではこういった修正済みの不具合が生じる可能性が否定できません。加えて、Bitcoin Coreを使っていたとしても、バージョン間での互換性のリスクがあります。現実には、いくつかの大手サービスでは独自実装になっています。そのため、偶発的な事故やコンセンサスの失敗を自動的に検出できるような方法が重要になってきます。

そして検知できたら、フェールセーフモードに切り替えて調査するなど、損失を減らす方向で対処すべきです。独自実装をネットワークから切り離すことで、ネットワーク上の他の利用者を保護し、ひいてはサービス提供者をも保護します。

リファレンス実装によるピアコードレビュープロセスにおいて、ミスがあっても通過してしまうことはまれにありますが、独自実装がこれに対し脆弱とは考えにくい点は、事実として補足すべきでしょう。

教育の観点からの防御

ひとつには、readingbitcoin.orgがあります。オープンソースソフトウェアも同じですが、誤った情報、混乱、そういった問題への対策には、教育が重要です。

現在、技術的なカンファレンスは数多くありますが、マーケティングに関するものは多くありません。ましてや、教育の視点を持つものは非常に少ないです。特にアジア圏の国では、多くの情報が英語に限られるため、非英語話者が十分な情報を得ることが困難です。

現在readingbitcoin.orgには5つのサンプル記事がありますが、記事については非常に注意深く翻訳しなければなりません。最初は中国語、日本語、韓国語に対応する予定です。また、需要という意味ではスペイン語も候補にあがっています。これらの作業は予算の許す限り進める予定で、現時点では大きな5つの企業から支援を得ています。

将来的には、毎週1記事を公開できるよう、翻訳者を含めたパイプラインプロセスを構築していきます。

非営利のプロジェクトとして行っていますが、これまで何百と実績のある進め方です。最近ではLinux Foundationがビットコインでの寄付を受け付けるようになりました。

通常、オープンソースに関して組織を作成する場合、2つの法人に分割します。1つは基金の監督、もう1つは技術プロジェクトです。技術プロジェクトは基本的に技術に強いリーダーが主導し、実力を持つ人が所属します。組織の構造上、資金提供者は技術プロジェクトに対して発言権を持ちません。

最後の防御は、たくさんの組織や人々の貢献です。

Square、Chaincode Labs、Digital Garage、DG Lab、MIT Digital Currency Initiative、Xapo、Blockstream、さらにはBitmainなどの企業を含め、ビットコインのリファレンス実装には多くの貢献者がいます。NY BitDevsミートアップ、SF Bitcoin Devsミートアップ、Boston BitDevsミートアップ、ソウルビットコインミートアップ、コインセンター、readingbitcoin.orgなどのローカルグループもあります。

中央組織はありませんが、これらのグループが相互に協力して全体に貢献し、あるいは相互に批判を行うこともありますが、そういった活動があることで、より大きな目標を成し遂げることができるでしょう。

まとめ

以上、5つの視点から、ビットコインの防御について講演をまとめさせていただきました。

記事中の表現については講演資料を筆者なりに読み解きつつ、前後で独自の解説を加えておりますが、なにぶん新しい技術に関する内容ですので、もしも間違いなどございましたらお気軽にご指摘くださいませ。（特に技術的な指摘は大歓迎です）