BiTor オープンクラス: 分離検証

みなさんこんにちは。ビタイのウェンハオです。 「ビタイオープ​​ンクラス」を始める前に、皆様にとって良い新年になりますようお祈り申し上げます。

前回の「ビタイオープ​​ンクラス」からかなり時間が経ちましたが、理由は相変わらず「忙しい」という言葉です。

この期間中、「ハードフォーク？ソフトフォーク？」などの話題が取り上げられました。そして「コア？クラシック？」国内外のビットコインコミュニティで大きな論争を引き起こしました。多くの人が私たちのビットコインチームに意見を求めてきました:

※海外の業界メディアからアンケートが届きました。
* 一部のユーザーは、ビタイがどちらの側に立つのかを尋ねました（もちろん、私は個人的に「側に立つ」ことが嫌いです）。
* 多くの方から技術的な詳細についてお問い合わせをいただいております。たとえば、一部のネットユーザーはQQやWeChatを通じてSegWitの技術的な詳細について質問してきました。
さらに、この期間中に2つの関連するディスカッションミーティングにも参加しました。

* 北京の複数の企業でコア開発者の Jeff Garzik 氏と技術交流を実施しました。
* Haobit の年次会議でフォークに関連する技術的な議論に参加する。

ディスカッションに参加していると、みんなが互いに議論しながら楽しい時間を過ごしているのがわかりました。

この公開授業では物議を醸す問題については議論しません。多くのユーザーが「分離検証」などの技術の実装に懸念を抱いているため、バビット氏は関連する技術内容について皆さんとコミュニケーションをとることができることも望んでいます。そこで、私はこの「ビットコインオープンクラス」を準備し、「隔離された検証」の関連内容をできるだけ明確かつシンプルな方法で皆様に説明したいと考えました。

このオープン クラスで使用されるメソッドは、以前のものとは少し異なります。

1. Bitai WeChatグループでは主に音声で行われます。

2. BiTai QQ グループと Babbitt Forum は、メインコンテンツをテキスト形式で同期します。

3. 興味のある学生は、自分の都合の良い方法でこの公開クラスに参加できます。

4. 質問は複数の場所で行うことができます。状況に応じて回答を選択します。ただし、質問を聞く時間がない可能性があるため、音声で質問しないでください。

「分離検証」について話す前に、いくつかの点を強調しておきたいと思います。

1. このディスカッションでは、フォーク、ブロック サイズ、分割、誰が正しいか、誰が間違っているかといったトピックについては議論せず、分離された検証の技術的な原則についてのみ議論します。

2. このディスカッションの聴衆はハッシュや署名などについて基本的な理解があることを前提とします (実際に理解する必要はなく、大まかに意味を理解するだけで十分です)。 「ハッシュとは何ですか？」「署名とは何ですか？」とは言いません。その他、そういったもの。本当に分からない場合は、自分でGoogleで検索してください。

3. 分離検証の技術的原理をできるだけ簡単な方法で説明し、技術にあまり詳しくない人でも分離検証の原理を理解できるようにします。

この公開クラスの主な内容は、見逃した人のために Babbitt フォーラムでご覧いただけます。

http://8btc.com/thread-28719-1-1.html

分離検証自体は、ブロック サイズのトピックとは関係ありません。 「分離された検証によってブロック サイズがある程度増加する」という事実は、実際には副産物であり、主な目的ではありません。しかし、ブロックサイズやフォークの話題があまりにも激しく、また、分離検証はまさに対立する一方側が推進に尽力している技術実装であるため、2MB相当のブロックサイズ増加の技術実装とみなされている。たとえば、「Classic は直接 2MB にアップグレードされますが、Core は分離された検証と呼ばれる別の複雑なテクノロジを使用して最大 1.8MB にアップグレードされます」というようなことを言う人をよく見かけます。実際のところ、それは全く事実ではありません。

ここで、この文を繰り返し強調する必要があります。「分離検証は分離検証です。その主な目的は文字通りの意味と同じで、ブロック サイズを増やすのではなく、分離して検証を実行することです。結局のところ、分離検証では副産物としてのみブロック サイズを増やすことができます。」この文を覚えておいてください。

さて、隔離された検証について正式に議論する前に、質問させてください。ビットコインの取引の構造とは何でしょうか?

本日の講演の聴衆は、業界関係者かビットコイン愛好家です。誰もがビットコイン取引についてある程度理解しています。トランザクション構造に関する同様の記事を読んだことがある人は多いでしょう。コーダーは、Bitcoin wiki や開発者ドキュメントを読んで、TxIn、TxOut、OP_CHECKSIG、OP_EQUAL、ScriptSig、ScriptPubKey などの用語を知っているかもしれません。しかし、Bitcoin トランザクションを本当に「理解」しているでしょうか?

たとえば、ビットコインの取引はなぜこのように設計されているのでしょうか?何が良いのでしょうか？何が問題なのですか?

さて、隔離された検証について正式に議論する前に、質問させてください。ビットコインの取引の構造とは何でしょうか?

本日の講演の聴衆は、業界関係者かビットコイン愛好家です。誰もがビットコイン取引についてある程度理解しています。トランザクション構造に関する同様の記事を読んだことがある人は多いでしょう。コーダーは、Bitcoin wiki や開発者ドキュメントを読んで、TxIn、TxOut、OP_CHECKSIG、OP_EQUAL、ScriptSig、ScriptPubKey などの用語を知っているかもしれません。しかし、Bitcoin トランザクションを本当に「理解」しているでしょうか?

たとえば、ビットコインの取引はなぜこのように設計されているのでしょうか?何が良いのでしょうか？何が問題なのですか?

特定のビットコイン取引を見てみましょう。

ビットコイン cli getrawtransaction c0a0d0f4de3be3b57f516f127a6fa5d5895f09bfacbb001853593320fb0a4164
0100000001473e2a366b081a0e6645199692ccf2f6e25e4556a18265785a88b46d50fd68c2000000006a4730440220296dd1587b8290a04a9253de431b5dbb698030527df5ca75592ab29eea12e85b0220737cafd85b79a7dea1b29c0a5753432d1dacb50f5225221974e38134617ff c85012103dd38b9b13b24498c382045afb08a4256c3c8bf86e15122df741bd2c2a0bd120ffffffffff02a0d21e000000000017a914d1640264c522d9a31aaf69207e57d0a224eb7e6687701101000000000001976a914dfd6b01e5ec1ecb1568da79931ddd8327dafd9b588ac00000000

tx_id = tx_ハッシュ = c0a0d0f4de3be3b57f516f127a6fa5d5895f09bfacbb001853593320fb0a4164
生の_tx = 0100000001473e2a366b081a0e6645199692ccf2f6e25e4556a18265785a88b46d50fd68c2000000006a4730440220296dd1587b8290a04a9253de431b5dbb698030527df5ca75592ab29eea12e85b0220737cafd85b79a7dea1b29c0a5753432d1dacb50f5225221974e38134617ff c85012103dd38b9b13b24498c382045afb08a4256c3c8bf86e15122df741bd2c2a0bd120ffffffffff02a0d21e000000000017a914d1640264c522d9a31aaf69207e57d0a224eb7e6687701101000000000001976a914dfd6b01e5ec1ecb1568da79931ddd8327dafd9b588ac00000000

tx_hash = double_sha256(raw_tx)

これは実際には生の形式 (16 進数) の Bitcoin トランザクションです: rawtx。これは、ビットコイン ネットワーク上でブロードキャストされるトランザクションの種類であり、送受信されるビットコイン トランザクションは実際には同じです。

分からないと言う人もいるかもしれません。
読めない？それは問題ではありません。今日の内容を理解するために、取引形式を理解する必要はありません。
前回のトランザクションでは、署名は次のようになりました。

 30440220296dd1587b8290a04a9253de431b5dbb698030527df5ca75592ab29eea12e85b0220737cafd85b79a7dea1b29c0a5753432d1dacb50f5225221974e38134617ffc8501

さて、テキスト エディター (メモ帳など) を見つけて、元のトランザクション rawtx 内の署名を検索します。質問させてください。取引において署名はおおよそどこに表示されますか?

検索した人は、この質問に答えられるはずです。前方中央の位置にあります。つまり、署名は基本的にトランザクションの前半（実際には TxIn の位置）にあります。

ここで疑問になるのは、なぜ署名がここにあるのか、そしてここに署名があることでどのような利点があるのか​​ということです。

答えは、サトシ・ナカモトがこのように設計したので、署名がここにあるということです。メリットに関して言えば、実はあまり多くありません。メリットがないだけでなく、デメリットもかなりあります。

1. この設計により、ビットコインの取引構造には多くの「秘密」が隠されています。たとえば、署名されていないトランザクションは実際には ScriptPubKey と呼ばれる別のコンテンツを使用します。このコンテンツは、最初に署名に必要な位置を占め、次に署名されていないトランザクションに署名し、最後に署名結果を置き換えます。これは実は非常に面倒なことです。わかりやすく説明するのは簡単ではなく、コードで実装するのも困難です。トランザクションに複数の入力 (TxIn) がある場合、署名されていないトランザクションを順番に準備し、署名を順番に置き換えるための一連の「チート」が必要です。トランザクションにマルチ署名トランザクションが含まれる場合、署名されていないトランザクションを準備し、署名後にデータを置き換えるために、別の一連の合意されたルールが必要になります。トランザクションに複数の入力と複数の署名の両方が含まれる場合はどうなりますか?それはチートコードの中にチートコードがあり、非常に厄介です。興味があり、能力のある人は、さまざまな言語での Bitcoin プロトコルの実装を調べてみることをお勧めします。 C++、Java、Python などの言語で書かれた Bitcoin プロトコル ライブラリであっても、通常、前述のトランザクション データ構築作業を行うには多くの面倒なコードを記述する必要があり、非常に面倒であることがわかります。書いた人は分かるでしょう。

2. トランザクション構造に署名を入れます。署名の可変性により、トランザクションにも可変性が生まれます。たとえば、楕円曲線の対称性により、s と s' はどちらも検証可能な署名であると、かなり前に説明しました。この場合、ブロードキャストしたトランザクションを受信するノードは、s を s' に置き換えて再ブロードキャストすることができます。再ブロードキャストされたトランザクションは、実際には同じコンテンツ（入力 TxIn と出力 TxOut）を持ちますが、tx_id（tx_hash）が異なります。これにより、一般の人々を混乱させる目的が達成され、一部の Bitcoin 企業（取引所など）のサービスにさえ影響を与える可能性があります。取引の柔軟性は、コインの損失を直接引き起こすことはありませんが、ビットコイン取引の状況に関する個人や企業の判断に影響を与え、資産管理のリスクにつながる可能性があります。これまで、bitcoin-core は BIP62 のトランザクションの可塑性の問題を解決しようと試みてきましたが、ある意味では、トランザクションの可塑性を完全に治すことはできません。少なくとも秘密鍵の所有者は署名を再生成できます。トランザクションは変更されませんが、署名が変更され、最終的な tx_id も変更されます。この状況は、マルチ署名の場合に適用され、トランザクションにおける他の鍵保有者の判断にも影響を及ぼし、潜在的な資産リスクにつながる可能性があります。現在の取引構造では、このような状況の発生を完全に防ぐことはできません。

3. トランザクションに署名する必要がある場合、各 TxIn に署名するためのハッシュは異なります (上記の「チート」を参照)。そのため、「コールド ウォレット」などのオフライン署名の実装は、データ構造とコードの両方の点で実際には難易度が高くなります。

つまり、トランザクション コンテンツに署名を入れることには、実際には何のメリットもありません。代わりに、構造の複雑さとトランザクションのスケーラビリティのリスクが増大し、明らかにコストに見合うものではありません。
では、最も合理的な取引構造とはどのようなものでしょうか?実はとても簡単です:

TxIns + TxOuts + [签名]

つまり、署名を別途取り出して外側に置くことで、上記の問題をすべて解決できるのです。

ここで、今日お話しするテーマ「孤立した証人」に戻ります。

分離検証では、実際には元のビットコイン取引の署名部分を取り出し、それを witness と呼ばれる別の構造に入れて、前述の目的を達成します。

これを読めば、一見複雑そうに見える「分離検証」の基本原理が、実はそれほど複雑ではないことが分かるはずです。達成すべき目標は実際には非常に単純で、署名を取り出して別の場所に置くこと、いわゆる「分離」です。とても簡単です。

署名は「検証」に使われるデータであり、それを別の場所に置くことは「分離」することなので、これを「分離検証」と呼ぶのは妥当です。

上記の説明により、誰もが分離検証の利点を理解できるはずです。その利点は実に大きいです。

トランザクションはトランザクションであり、署名は署名です。トランザクションの場合、TxIn と TxOut のみに注意する必要があります。ビットコインのトランザクションでは、実際には以前に受け取ったお金が使われていることは誰もが知っています。つまり、以前に受け取った TxOut がこのトランザクションの TxIn として使用され、その後、後続の TxOut に送信されます。分離されたトランザクション構造とは、どのお金を使うか、誰に使うかを決めるときに、トランザクションの内容がすでに決まっており、トランザクションデータは変更されず、最終的な tx_id も変更されないことを意味します。署名を検証しますか?次に、証人のところに行き、対応する署名データを見つけて正当性を確認します。シンプルで取引の柔軟性にも問題はありません。プログラマーの言葉を借りれば、それは本当に「クールすぎる」です!

ご存知のとおり、当社の BitTorrent ウォレットは、使いやすく安全なコールド ウォレット ソリューションを提供します。もちろん、私たちにとっては、オフライン署名プロセス中に、コールド秘密鍵が署名する必要があるハッシュが正確であり、変更されないことを願っています。これは実際には分離された検証の利点の 1 つです。

ちょうど今、Babbitt フォーラムで、分離された検証は Lightning ネットワークに適しているかどうかを尋ねる人がいました。

私の答えは、分離された検証は、ビットコイン ブロックチェーンに基づくすべての拡張アプリケーション (取引所やウォレットなどを含む) にとって有益であるということです。正確な tx_id により、tx_id に基づく多くのアプリケーションがはるかに簡単かつ信頼性の高いものになります。

上記の利点は、実際には分離された検証の本質です。

いわゆる分離された検証は、本質的にはブロック サイズの問題を解決するために行われた変更ではありません。これは、一部の人が言うように、「コアチーム内の BlockStream のコア開発者数名による、容量拡張を妨害するための陰謀」ではありません。代わりに、ビットコインの取引はそのようになるはずです。公開鍵の圧縮形式のような分離された検証の構造的改善（詳細については、以前の公開クラス「サトシ・ナカモトについてのゴシップ」、http://8btc.com/thread-14057-3-1.html を参照してください）は、当初の構造設計が不合理であったため、改善が必要なものです。

つまり、ビットコインの取引は本来「隔離された検証」であるべきだったが、サトシ・ナカモトがそれを現在の形に設計したため、今日までそれが維持されているのだ。もし当時それを変える決心がされていたら、今日これほど多くの論争は起こらなかったかもしれない。ビットコインのプログラマーは、トランザクションの構造に苦労する代わりに、より有意義なことをするために多くの脳細胞を節約することができ、さまざまなビットコイン企業はトランザクションのスケーラビリティなどの問題に悩まされることが少なかったでしょう。

さて、ここまで議論した後、個別の検証を行うべきでしょうか?

私の答えは「もちろんそうすべきだ」です。合理的な改善を行ってみてはいかがでしょうか?例えば、「圧縮形式の公開鍵」の改善は必要でしょうか？

分離検証をどのように改善すればよいでしょうか?

下位互換性や、さまざまなクライアントの古いバージョンとの互換性を考慮する必要があるため、開発者は可能な限り「ソフトフォーク」アプローチを使用したいと考えています。これを実現するために、合計 4 つの関連する BIP (141-144) が提案されています。

コンピュータ システムの新しい構造を設計するのは簡単ですが、下位互換性を実現するのははるかに難しいことは誰もが知っています。新旧の構造を共存させ、旧バージョンを正常に動作させることはさらに困難であり、特にこれらの新旧の構造のデータを同じブロックチェーン上で送信する必要があることを考慮すると、より多くの努力が必要になります。これらの部分については、いくつかの bip で詳しく説明されています。興味のある方は、関連する技術文書をお読みください。

例えば：
bip141 では、スクリプトや署名などのデータが移動される「witness」と呼ばれる新しい構造について詳しく説明し、Segwit が下位互換性を実現する方法についても紹介しています。
bip142 は、分離された検証のための新しいアドレス形式について説明します。
bip143 では、分離検証トランザクション署名の検証方法を例とともに説明します。
bip144 は、分離された検証のサポートをノードに通知する方法と、下位互換性を維持しながら検証データを伝播および要求する方法について説明します。

さて、ここまで説明した後は、分離検証がどのようなものであるかについて、誰もが大まかな理解が得られるはずです。分離された検証自体はブロック サイズとは関係ありません。互換性のために検証データが別のスペースに配置されているだけです。同時に、ブロック上限値の計算方法も変更され、隔離検証自体が容量拡張において一定の役割を果たせるようになります。このため、誰もがこれを別の容量拡張ソリューションと見なし、2MB ソリューションの反対と見なしています。

最後にまとめると、分離された検証は、実際には以前の不合理なビットコイン取引構造の最適化です。開発者は、影響をできるだけ少なくし、下位互換性をできるだけ保つ「ソフトフォーク」方式で実装しようとしました。この改善自体は（「圧縮された公開鍵」と同様に）非常に合理的であり、ブロック サイズの論争とは何の関係もありません。分離された検証のソフトフォークがオンラインになった場合、一部の人が今日まで (K と L で始まる秘密鍵の圧縮バージョンではなく) 5 で始まる秘密鍵をまだ使用しているのと同じように、Bitcoin ネットワーク上でトランザクションの古いバージョンと新しいバージョンがかなり長い間共存する可能性があります。

分離された検証によってもたらされるブロック サイズの増加は、副産物にすぎません。ブロック サイズを増やすべきかどうか、またどのように増やすべきかは、実際には別の話題です。これには、すべての関係者による十分な議論と、可能な限り客観的かつ公平に互いの意見を聞くことが必要です。私は個人的に、ブロックサイズの議論についてはコメントしません。ビットコインのコードをどのように管理するかという問題については、これはガバナンスの問題であり、政治的な問題であり、このオープンクラスの議論の範囲外です。

分離検証は改善すべき点です。しかし、ブロックサイズをめぐる論争と混同されているため、「孤立検証」を見ると感情的な意味合いを抱く人が多いようです。私の個人的な提案は、分離された検証は分離された検証であるということです。下位互換性、ソフトフォーク、問題なしを実現するには、コア開発者、産業チェーンの上流と下流の関連企業、ビットコインウォレット開発者の共同の努力により、この改善の安全な実装を確保する必要があります。分離された検証スキームにリスクがあるかどうかを尋ねなければならない場合、最大のリスクは、誰もが「分離された検証スキームはいつ開始されますか? 来月には 2MB をフォークできます」と言わざるを得なくなり、コア開発者がブロック サイズを増やすために急いで取り組むことを余儀なくされることだと思います。これはちょっと損です。分離検証のアップグレードはまだ十分にテストする必要があり、関連企業とソフトウェア ソリューションもオンラインになる前に可能な限り完全に互換性をテストする必要があります。