2017年7月24日、SegWitが #481,824ブロックよりビットコインネットワークにアクティベートされました。ネットワークのSegWit準備を完了している全てのノードは、ビットコイン史上最も重要なプロトコルアップデートとなるSegWitという新しいルールに従ってブロックを検証します。
この歴史的アップデートは御存知の通り容易ではなく、2年という長い歳月をかけて行われました。本稿ではSegWit実装という長い道のりを振り返ってみましょう。
スポンサーリンク目次
1.ビットコインの問題
ビットコインのトランザクションは下記2つの主要な部分によって構成されています。
1.ビットコインが送金され、どのアドレスが保持しているのかなどのデータが含まれている”ベーストランザクションデータ”
2.witnessという“署名”と呼ばれるデータ
これはビットコインの所有者がそのビットコインを使用したいということを証明する一部のコードと暗号署名データを含みます。
1-1.二重払いを可能とするマリアビリティ攻撃
ビットコインにはマリアビリティというバグが存在し、これは例えこれらの署名を作成後、かつこの署名を無効にすることなく誰でも僅かに署名を変更することが可能です。
このようなビットコインネットワークを中継するもの、またはトランザクションをブロックに入れるマイナーにより、トランザクション全体の見かけ、具体的に言うとトランザクションの識別子が変更される可能性があります。
1.2015年のビットコインへのマリアビリティ攻撃の統計
1-1-1.ライトニングネットワークがマリアビリティに依存する理由
トランザクションのマリアビリティ自体は大きな問題ではありません。トランザクション自体は有効であり、そのビットコインを同じ条件下で同じ場所に移動させます。しかし、新しいトランザクションは依存しているトランザクションの識別子を知る必要があり、未確認トランザクションによって新しいトランザクションを生成するのはとても難しくなります。
1-1-2.コアデベロッパーの議論の歴史
マリアビリティバグを解決する一般的なアイデアは署名データを他のトランザクションデータから”分離”するというもので、数年に渡り議論されてきました。
2012年以来、コアデベロッパーのRussell O’Connor氏、Matt Corallo氏、Luke Dashjr氏、Gregory Maxwell氏、Bitcon TalkのモデレーターであるTheymos氏などによりIRCビットコイン開発チャンネルで議論されてきました。当時はこの優秀なコアデベロッパー達でさえ署名を分離するという主張ができる方法を確立できていませんでした。
2012年のIRCでのマリアビリティバグについての議論
1年後の2013年8月にコアデベロッパーのPeter Todd氏とGreg氏が同様の議論をIRCで行ったため、再度問題が取り上げられました。そして現在、二人はこのマリアビリティバグに対処するアイデアを進展させました。
「SrciptSig全体を大きく分離することを話しており、ScriptSigをトランザクションから取り除いて使用することを提案しています」
と書き込みしていました。
１ヶ月後Greg氏とBlockstream CEOのAdam Back氏は再度IRCでマリアビリティ問題について議論を開始、Adam氏は署名を省略してトランザクションIDを計算することを同様に提案しました。
対してGreg氏は
「トランザクションIDの署名を取り除くことにより、マリアビリティ問題に対処することができるが、非常に深刻なハードフォークによるプロトコル変更になるでしょう。また安全性向上は難しい。」
とコメントしています。
1-2.ビットコインのサイドチェーン解決
2014年8月、ブロックチェーン技術会社のBlockstreamはAdam氏率いるGregory氏と企業家のAustin HIll氏とDr.Pieter Wuillie氏含む数名のビットコインコアデベロッパーによって設立されました。ビットコインに効果的にペッグすることが可能なサイドチェーンによる解決に着手していました。
2015年初旬までにBlockstreamエンジニアは同社のサイドチェーンのプロトタイプであるElementsの実装を決定、同年6月に正式に発表されました。
Elementsは署名データをベーストランザクションデータから他のデータ構造に格納し、分離することで決定的にマリアビリティ問題をサイドチェーン上で解消することが可能でした。
この新たな機能は現在ご存知のようにSegregated Witness通称SegWitとして知られています。
Blockstreamのサイドチェーン拡張提案
2.ブロックサイズ変更の論争激化
ブロックサイズについての議論は2010年以来、技術的に曖昧でしたが、2013年2月から具体的になり、ブロックサイズ制限の論争は2015年春から急激に激化しました。
当時のビットコインのリードコアデベロッパーだったGavin Andersen氏とBitcoinjのリードデベロッパーだったMike Hearn氏は、特に1MBのブロック制限はビットコインエコシステム全体を通し、互換性のないアップデートであるハードフォークにより引き上げるべきだと主張していました。
ですがコミュニティ全体での同意は得られず、このタスクは簡単ではありません。
2-1.コアクライアンと異なるBitcoin XT
それにもかかわらず2015年夏、Gavin氏とMike氏はこのブロックサイズ変更プランを行うためBitcon XTというコアクライアントと別のソフトウェアクライアントにより計画を実行すると発表。その結果、本質的に賛否両論となるこの発表はビットコイン開発コミュニテイと業界はある種の緊急事態となりました。
2015年後半、このコミュニティの分裂防止と潜在的なブロックサイズ論争の解決法を見出すため、２度に渡ってScalling Bitcoin MontrealとScaling Bitcoin Hong Kongというカンファレンスが開催されました。
2-2.ライトニングネットワークの発表
モントリオールで発表された最も将来有望なスケーリング解決方法は、Joseph Poon氏とThaddeus Dryja氏によりホワイトペーパーが公開された洗練されたレイヤー2となるライトニングネットワークでした。
ですがライトニングは問題点があり、マリアビリティ問題をまず先に修正する必要がありました。
3.ソフトフォークによる実装
この段階ではデベロッパーはこのマリアビリティバグを如何にして修正するかは定かではなく、多くの人はビットコインのメインチェーンにハードフォークなしでSegWitが実装するとは思いもしませんでした
しかしコアデベロッパーのLuke氏は違い、2015年10月、上記カンファレンスの間Eric Lombrozo氏とPieter氏、Wladimir van der Laan氏を含む4人は可能性のある新しいモデルのソフトフォークについてIRCで議論しました。Luke氏は提案されたメカニズムでは可能性のあるソフトフォークでは機能しないと指摘。
興味深いことに、Luke氏でさえSegWitをソフトフォークでビットコインネットワークにデプロイすることが可能であると当初は気づいていなかった様です。
スポンサーリンク3-1.SegWitの思いがけない恩恵
SegWitをソフトフォークで実装するためには署名データをビットコインブロックの新たな一部としてとして配置される必要があります。そのブロックに付属する全ての署名データ（マークルルート）のためのアンカーはマイナーに新しい報酬となるコインを与えるコインベーストランザクションに格納される必要がありました。
数週間後コアデベロッパーはこの手法に興味深い利点があることに気づくことになります。
署名データのためにブロックの新たな部分を作成することにより、アップデートしていない古いノードが検証するルール内でビットコインのブロックサイズを1MB以上に増加することができます。これにより既存のブロックサイズ制限をハードフォークで変更することなく実際のブロックサイズを増加することが可能となりました。
ほんの数週間前の2つ目のスケーリングビットコインワークショップで、数人のコアデベロッパーはこのブロックサイズ制限の論争の一時的な解決方法を見出したのではないかと考えていました。SegWitは後方互換があり、かつ効率的にブロック制限を増加し、更に長期的な問題となっていたマリアビリティバグを修正。その結果、ライトニングネットワークの様な更なるビットコインのスケーリング解決を可能とする魔法の様な解決策だとコアデベロッパー達は感じました。
コアデベロッパーによるソフトフォークについての議論
3-2.コアデベロッパーによるロードマップの承認
SegWitのソフトフォークは2015年12月に開催された香港でのスケーリングビットコインワークショップでPieter氏によってはじめてプレゼンされました。当初、多くの人がこの解決策が受け入れられた様に思われました。このカンファレンス後Gegory氏はSegWitを最も重要なプロトコルアップデートとして取り扱った開発ロードマップを提案、これはすぐにコアデベロッパーチームにより承認され、更にはビットコインエコシステム全体へと幅広く受け入れられました。
3-3.SegWitに対する批判
当初SegWitは受け入れられたものの、この提案されたプロトコルアップグレードへの懸念による批判の声も同様にありました。元ビットコインコアデベロッパーで、SegWit2xのデベロッパーであるJeff Garzik氏はSegWitは短期的なスケーリング解決にはならないと考えていました。
Bitcoin XTのリードデベロッパーであるMike氏はSegWitに納得が行かず、
「SegWitは実際のブロックサイズを増加しているにも関わらず、プロトコル上では1MBとして扱うというのは不正な経理操作に値する」
と批判、その後ビットコイン開発を去りました。
ビットコインのフォーククライアントであるBitcoin ClassicのデベロッパーであるJonathyan Toomim氏は
「この提案は全くを持って酷いし不便だ。ハードフォークによって実装を行うべき」
と主張。更にPeter氏でさえマイニングに関する懸念を持っていました。これらの問題は多くは解決できず、かつ納得もできないものでありコアデベロッパーにより他の代替案が行われる価値があったかもしれませんが開発を開始しました。
*文字数が1万文字を超えるため前編と後編にわけてあります。
元記事:The Long Road to SegWit: How Bitcoin’s Biggest Protocol Upgrade Became Reality
関連する記事
スポンサーリンク
ビットコインやイーサリアムその他仮想通貨の情報はツイッター上で速報を出しています。
Follow @bokujyuumai Tweet
仮想通貨ランキング Tweets by bokujyuumai