仮想通貨のコア技術ブロックチェーン課題の対策「Segwit」とは何か？

仮想通貨の一技術であるブロックチェーン、それは仮想通貨を取引する上で記録する台帳のようなものです。

ブロックチェーンは仮想通貨のコア技術として、仮想通貨にとどまらず様々なシーンでの利用も検討されていますが、大きな課題も含まれています。

それはブロックに記録するスペースがなくなってきているという問題です。

こういった問題を、スケーラビリティ問題やブロックサイズ問題と呼んでいます。

Segwitはそんな問題を解決するための対策の１つなのです。

Segwitを理解するには、ビットコインの取引に関する基礎知識がある程度必要ですが、一言でいうと、ビットコインの取引データ内に従来含まれていた署名を分離して別の領域に格納するということです。

ビットコインの取引には入力することと出力することという二つの要素に分けられます。入力には、送信元の情報が含まれ、出力には、送信先の情報が含まれます。一つの取引内に入力と出力が複数存在することもあります。そしてその入力と出力のビットコイン量の差は取引手数料となります。取引手数料はcoinbaseと呼ばれる特殊なトランザクションによって、ブロックを生成したマイナーにブロック生成報酬とともに付与されます。

入力にはscriptSigと呼ばれるスクリプト（プログラムコード）が含まれています。scriptSigは、取引の署名及び公開鍵などから構成されています。署名は、送信元のビットコインアドレスの秘密鍵を使用して作成される、アドレスの所有権を証明するためのデータです。署名と公開鍵を利用することで誰でもその署名が正しいことを検証できます。

また、出力にはscriptPubKeyと呼ばれるスクリプトが含まれています。scriptPubKeyは、送信先アドレスの公開鍵のハッシュ値などから構成されています。

scriptPubKeyは「ロックスクリプト」とも呼ばれ、「次のトランザクションのscriptSig内に対応する署名が含まれていなければならない」という意味のコードが書かれており、秘密鍵の所有者以外ビットコインを使用できないようにロックする役割があります。ロックという観点でいうと、scriptSigは「ロック解除スクリプト」です。秘密鍵の所有者のみがscriptSig内に署名データを入れてビットコインのロックを解除することができます。

本題のSegregated Witnessとは何なんだろうか？

Segwit(Segregated Witness）とは、従来scriptSigに含まれていたデータを、分離して全く別の領域に格納することです。この新しいデータ領域のことはwitnessと呼ばれており、取引データとは別に署名データとしてまとめられ、まとめられたwitnessはcoinbaseトランザクション内に格納されます。従来のscriptPubKeyの内容を、「scriptSig内に対応する署名が含まれていなければならない」という意味のスクリプトから、「witness内に対応する署名が含まれていなければならない」という意味のスクリプトに変更するものでもあります。

Segregated Witnessってなにがトクなの？

ビットコインには「トランザクション展性」と呼ばれる脆弱性があります。ビットコインでは各トランザクションを識別するために、トランザクションIDと呼ばれるトランザクションのデータ全体のハッシュ値が使われます。取引の内容（送信先・送信元アドレスとビットコイン量）を変更することなく、このトランザクションIDだけを変更できる脆弱性をトランザクション展性と呼びます。

トランザクション展性を利用した攻撃方法は主に二つに分けられます。一つ目は単純に秘密鍵の所有者が署名データを作り直すことで、署名以外は同じ取引内容を保ったままトランザクションIDを変更する方法です。二つ目は、第三者がトランザクションIDを変更する方法です。ビットコインのトランザクションには署名そのものや取引内容以外にあまり重要でない誰でも変更できるデータが含まれており、このデータを変更することで誰でもトランザクションIDが変更できてしまいます。

このトランザクション展性は、トランザクションIDのみを取引の識別に利用しているウォレットで特に問題が発生します。IDを改ざんされた取引がブロックに取り込まれ確認された場合、改ざん後の取引が完了しているのに、最初にウォレットから送信された改ざん前取引とはトランザクションIDとは違うために、ウォレット内では改ざん前取引が完了したと見なされず、ウォレット内の残高の不一致が発生してしまいます。最初の改ざん前の取引はノードから二重支払いとみなされ、無効な取引として弾かれてしまうためです。

Segregated Witnessでは、署名その他のトランザクションIDの計算に使われるデータを取引とは別の領域に格納することで、トランザクションIDの変更ができなくなります。

これによって、取引所やウォレットの開発者にとっては取引の追跡に単純にトランザクションIDのみを利用すれば良くなりコードが単純になるという利点の他にも、トランザクション展性を利用した二重支払いのリスクがなくなる利点や、Lightning Networkという新しい技術の実装が容易になるという利点なども挙げられています。

トランザクション展性を利用した二重支払いというのは、約10分かかる「確認」前の状態の未確認のビットコインを使用する場合などに発生します。例えば、取引所Aから攻撃者Bに1BTCを引き出した後、未確認の状態ですぐに攻撃者Bから店舗Cにその1BTCを商品代金として送信したとします。この時、店舗Cが未確認状態のトランザクションであっても送金完了とみなしている場合、攻撃者Bは取引所Aからの引き出しのトランザクションIDを変更することで、店舗Cへの支払いのトランザクションが無効と見なされ、支払い完了として扱ってしまったのに実際には店舗Cへ支払われないという状況になります。（トランザクションもブロックと同様にチェーン状になっているため、前のトランザクションが改ざんされると後のトランザクションも無効と見なされます。）

Segwitにより不可能になるのはこのタイプの二重支払いのみであり、他にも未確認状態での二重支払いの方法は存在するので、未確認のトランザクションを送金完了とみなすことにリスクが伴うことはSegwitの採用後も変わりません。

また、ビットコインのブロックには1MBというブロック制限があります。この制限が原因でスケーラビリティ問題として最近のビットコインの最重要課題となっています。

そのスケーラビリティ問題の一つの対応策となるのがSegwitです。署名を分離することで、その署名分のサイズがブロックサイズの制限には考慮されず、実質的に1MB以上の取引をブロックに含めることができるようになります。

Segwitの導入と同時に新たなブロックサイズの制限の様式も導入される予定です。

旧バージョンからみた場合は、ブロック≦1MBというかたちを変更することなくSegwitを実装することになります。

もしも取引データがすべてwitnessであれば、最大4MBの取引データが格納できることになります。しかし、これはあくまでも理論的な話であり、取引データのすべてが署名データということは現実的にないため、実際にはせいぜい1.6～2MB程度になると考えられています。なお、ブロックにおける署名データのサイズの割合が増えるほどより多くのサイズが格納できることになるため、いわゆる署名が複数となるマルチシグネチャアドレスからの送信が増えるほど、実質的なブロックサイズ制限が上昇します。

witnessのデータ量は4分の1のみが取引データの総サイズとして考慮されるため、Segwitには副次的に取引手数料が減る効果もあるとされています。