🔉 👲🏿 👨🏻‍💻 ダミーのための分離された証人 🚈 🔬 🤰🏻

ビットコインのスケーラビリティはその主要な問題の1つであり、その解決策は積極的に取り組んでいます。これらのソリューションの代表的なものの1つに、たとえば、Lightningネットワークテクノロジーがありますが、いくつかの脆弱性のため、その実装はまだ不可能です。別のソリューション-分離された証人は、スケーラビリティの向上を目指していますが、雷の実装を妨げるまさにその脆弱性を含む一連の問題全体も解決します。この記事では、分離された証人の主な利点を検討し、その仕組みを説明します。

分離された目撃者、または多くの場合SegWitと呼ばれるものは、一連のBIP（141、142、143、144、および145）で記述されたソフトフォークであり、その主な目的は、署名を使用してトランザクションとブロックの構造を最適化することですトランザクションから別の構造への「 scriptSig 」、「 目撃者 」、または「 ロック解除スクリプト 」と呼ばれます。これにより、トランザクションのサイズを小さくしてブロックをより容量的にするだけでなく、トランザクションの構造に依存する支払いチャネルや稲妻などの技術にとって非常に重要な「 可変性 」（ トランザクションの順応性、上記の脆弱性について前述しました）の問題も解決しますビットコイン。

仕組み

始める前に

まず、ビットコインの支払いシステムがどのようなものかを簡単に思い出してください。どの銀行にも実装できるため、残高リストのようなものはありません。代わりに、各アドレスの残高は、そのアドレスに送信される一連のトランザクションによって表されます。トランザクションは、入力と出力が主要なものである構造です。入力は、支出するために参照するトランザクションです（より正確には、これらはトランザクション全体ではなく、特定の出力です。1つのトランザクションでは複数のアドレスに資金を転送できるため）。出力は、資金を送金したい。ビットコイントランザクションの構造は次のようになります。

類似画像

出力のPubKeyスクリプトフィールド（以降scriptPubKey ）は、 ロックスクリプトと呼ばれるものです。資金の転送先の住所の所有者のみがこの出力を使用できるようにする必要があります。 Signature Scriptフィールド（以降scriptSig ）はロック解除スクリプトとも呼ばれます - ロックスクリプトを 「ロック解除」し、アドレスの所有権の証明を提供します。

トランザクションの詳細と、ロックおよびロック解除スクリプトの操作については、こちらをご覧ください。

後方互換性

実際、分離された証人はトランザクションの構造だけでなく、その出力も変更します。ただし、これは、従来のUTXO（未使用のトランザクション出力）とSegvitの両方を同じトランザクションで使用できないことを意味するものではありません。

Segregated Witnessは依然としてソフトフォークであるため、その更新は無視できます。つまり、古いシステムは何らかの形でSegvit出力を処理する必要があります。実際、古いノードまたはウォレットの場合、これらの出力は誰もがアクセスできるように見えます。つまり、空の署名で使用できますが、これは依然として有効です。更新を受け入れたノードとウォレットは、もちろん、特別な「目撃者」フィールドの入り口の外のすべての署名を検索します。

例

Pay-to-Witness-Public-Key-Hash

それでは、トランザクションの例と、分離された証人によってどのように変化するかを見てみましょう。標準のPay-to-Public-Key-Hash（P2PKH）トランザクションから始めます。

出力、つまり「scriptPubKey」フィールドに関心があります。典型的なロックスクリプトを考えてみましょう。

OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

分離された証人では、次のようになります。

 0 <PubKeyHash>

ご覧のとおり、Segvitの出力は従来の出力よりもはるかに単純です。これは、スクリプト実行スタックに配置される2つの値で構成されています。前に述べたように、ビットコインクライアントの古いバージョンでは、署名を必要としないため、この出力は誰でもアクセスできるように表示されます。しかし、更新されたクライアントの場合、最初の番号はバージョン番号として解釈され、2番目はロックスクリプト（監視プログラム）の類似物として解釈されます。実際、圧縮された公開キーのハッシュはここで使用する必要があります。これについては後で説明します。

ここで、この出力が費やされるトランザクションを見てみましょう。従来の場合、次のようになります。

 [...] "Vin" : [ { "txid": "8adbca5e652c68f8f3c30ac658115bc4af395d0cc7e6beaea18168295c29d011", "vout": 0, "scriptSig": "<our scriptSig>" } ] [...]

ただし、Segvit出力を使用するには、トランザクションに空のsriptSigフィールドがあり、すべての署名が別の場所に含まれている必要があります。

 [...] "Vin" : [ { "txid": "8adbca5e652c68f8f3c30ac658115bc4af395d0cc7e6beaea18168295c29d011", "vout": 0, "scriptSig": "" } ] [...] "witness": "<Witness data>" [...]

警告

従来の顧客はSegvitトランザクションを処理できるという事実にもかかわらず（古い顧客にとっては出力は誰でもアクセスできるように見えることを思い出してください）、彼らは出力を使うことができません。ただし、空の署名を持つ出口。このトランザクションは実際には無効です（分離された証人を持つノードは、このようなトランザクションを見逃すことはありません）。つまり、送信者は、目的のタイプの出力を作成するために、受信者のウォレットがsegwitをサポートしているかどうかを知る必要があります。

BIP 143以降、圧縮された公開キーのハッシュを使用して出力を作成する必要があります。通常のアドレスまたは非圧縮公開キーを使用して出力を作成する場合、この出力は使用されません。

証人への支払いスクリプトハッシュ

次の非常に重要なトランザクションタイプはP2SHです。これにより、公開キーハッシュ（通常のビットコインアドレス）ではなく、スクリプトハッシュにトランザクションを送信できます。 P2SHトランザクションの出力を費やすには、資金が送金されたスクリプトのハッシュと一致するハッシュを持つスクリプト（引き換えスクリプトと呼ばれます）と、スクリプトに応じた署名/パスワード/何かを提供する必要があります。このアプローチを使用すると、何も知らない方法で保護されたアドレスにビットコインを送信できます。また、多くのスペースを節約できます。たとえば、マルチ署名ウォレットを備えたウォレットの場合、すべてを保存するとロックスクリプトが非常に大きくなります」「ハッシュだけでなく、完全にロックします。

そこで、5つのうち2つの署名を必要とするマルチ署名ウォレットの例を見てみましょう。ロックスクリプトの従来の形式では、P2SHトランザクションの出力は次のようになります。

 HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e EQUAL

それを使うには、マルチ署名2 of 5、および2つの署名の条件を定義する引き換えスクリプトを提供する必要があります。これはすべてトランザクション入力に含まれている必要があります。

 [...] "Vin" : [ "txid": "abcdef12345...", "vout": 0, "scriptSig": "<SigA> <SigB> <2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG>", ]

次に、送信者と受信者の両方が分離ウィットネスを使用した場合に、これらすべてがどのように見えるかを見てみましょう。

ロック終了スクリプト：

 0 9592d601848d04b172905e0ddb0adde59f1590f1e553ffc81ddc4b0ed927dd73

繰り返しますが、P2PKHトランザクションの場合のように、結果のスクリプトははるかに単純です。ここで、最初の値はバージョン番号で、2番目の値は、引き換えscript'a（監視プログラム）の32バイトのSHA256ハッシュです。このハッシュ関数は、ハッシュ長（32バイトのSHA256と20バイトのRIPEMD160（SHA256（スクリプト）））によって、監視プログラムP2WPKHとP2WSHのプログラムを何らかの形で区別するために選択されました。

この出力を使用したトランザクション：

 [...] "Vin" : [ "txid": "abcdef12345...", "vout": 0, "scriptSig": "", ] [...] "witness": "<SigA> <SigB> <2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG>" [...]

P2SH内に分離された証人を埋め込む

そのため、分離された証人の使用には利点があることを確認しましたが、上記の例では、送信者と受信者の両方を更新する必要がありますが、これは常に可能ではありません。たとえば、この状況を考えてみましょう。

アリスはビットコインをボブに送りたいと思っていますが、ボブには持っているのにセグベ財布はありません。もちろん、標準のトランザクションを使用することもできますが、Bobはsegwitを使用して手数料を削減したいと考えています。

この場合、Bobはsegwitスクリプトを含むP2SHアドレスを作成できます。アリスの場合、彼は最も一般的なP2SHアドレスとして表示され、問題なく資金を送金できます。ボブはこの出力をsegveトランザクションを使用して使用でき、手数料の割引を受けることができます（トランザクションを分離するための新しい手数料メトリックについては後述します）。

したがって、P2WSHとP2WPKHの両方のタイプのセグメントトランザクションをP2SH内に実装できます。

P2SH（P2WPKH）

P2SH内でP2WPKHトランザクションを使用するには、Bobは公開キーから監視プログラムを作成する必要があります。次に、結果をハッシュし、P2SHアドレスに変換する必要があります。

監視プログラムを作成します。

 0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7

いつものように-最初の数字はバージョンで、2番目は20バイトの公開鍵ハッシュです。結果のスクリプトは、SHA256によってハッシュされ、次にRIPEMD160によってハッシュされ、さらに20バイトのハッシュが発行されます。

監視プログラムP2WPKHのHASH160：

 3e0547268b3b19288b3adef9719ec8659f4b2b0b

そしてアドレスに変換します：

 37Lx99uaGn5avKBxiW26HjedQE3LrDCZru

このアドレスに送信される出力のロックスクリプトは、通常のP2SHアドレスのスクリプトのようになります。

 HASH160 3e0547268b3b19288b3adef9719ec8659f4b2b0b EQUAL

次に、Bobがこの出力をどのように使用できるかを検討します。

 [...] "Vin" : [ { "txid": "8adbca5e652c68f8f3c30ac658115bc4af395d0cc7e6beaea18168295c29d011", "vout": 0, "scriptSig": "0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7" } ] [...] "witness": "<Witness data>" [...]

最初に、提供した引き換えスクリプト（この場合、監視プログラムです）がハッシュされ、ロックスクリプトで指定されたハッシュと等しい場合、実行され、「監視」フィールドの署名がチェックされます。

P2SH（P2WSH）

同様に、どのP2WSHスクリプトもP2SH内に実装できます。前述のmultisigスクリプト2/5を使用してください。すべての手順は、P2SH（P2WPKH）の場合とほぼ同じです。

まず始めに、監視プログラムを作成します。

 0 9592d601848d04b172905e0ddb0adde59f1590f1e553ffc81ddc4b0ed927dd73

1番目の番号-バージョン、2番目-マルチ署名スクリプトの32バイトのSHA256ハッシュ。次に、手順が繰り返されます-ミラーリング監視プログラムからHASH160を取得し、通常のP2SHアドレスに変換します。このアドレスに送信された出力を使用するには、scriptSigで監視プログラムを作成し、監視フィールドにすべての署名と完全なマルチシグスクリプトを記述する必要があります。

分離された証人の利点

技術的な部分を理解したので、分離された証人の主な利点を見ていきます。

トランザクションの順応性

segwitが解決する最も重要な問題の1つは、トランザクションの「可変性」、またはむしろハッシュであるIDです。よく見てみましょう

従来のケースでは、入力内のトランザクション内の署名は、第三者が無効にすることなく変更できます。これにより、入力/出力/資金のような「基本」フィールドを変更せずに、そのハッシュであるトランザクションIDを変更できます。したがって、トランザクションは引き続き有効ですが、IDが異なるため、サービス拒否など、あらゆる種類の攻撃が可能になります。

Segwitはこの問題を解決します。これは、すべての署名がトランザクションの外部にあるため、ハッシュされず、変更してもトランザクションIDに影響しないためです。別のwtxid識別子も導入されます。トランザクションだけでなく、監視部分全体をハッシュするため、トランザクションが監視データなしで送信される場合、txidはwtxidです。

この問題を解決すると、リスクなしで未確認のトランザクションのチェーンを作成できます。これは、Lightning Networkなどのプロトコルにとって非常に重要な機能です。

ネットワークとストレージのスケーリング

証人データは、多くの場合、トランザクションの大部分を占めます。マルチシグのようなスクリプトでは、トランザクションで使用されるスペースの最大75％を占める可能性があります。 segwitのおかげで、署名の転送はオプションになります-ノードは、トランザクションを検証する場合のみ署名を要求します。 segwitをサポートしないSPV（単純な支払い確認）クライアントまたはノードは、この場合、不要なデータをロードせず、ディスク容量を節約できます。

ブロックサイズの増加と取引手数料の削減

Segwitトランザクションは、監視データストレージの割引により、従来のトランザクションよりも安価です。より正確には、segwitトランザクションの「サイズ」の概念が変更されました。通常のサイズの代わりに、「仮想サイズ」の概念が導入されました-「監視」に保存されているすべてのデータは、0.25の係数で考慮され、ブロック内により多くのトランザクションを配置できます。例を考えてみましょう。

従来の200バイトのトランザクションがあるとします。 1 MBブロックは、これらの5,000個に適合します。ここで、約120バイトが監視データであるsegwitと同等のものを取得します。次に、vsize = 80 + 0.25 * 120 = 110となり、そのようなトランザクションの9090がブロックに収まります。また、最初のトランザクションの場合、たとえば40サトシ/バイトのコミッションで、8000サトシのコミッションと、2番目の4400サトシのコミッションがほぼ半分になります。

スクリプトのバージョン管理

お気づきかもしれませんが、各ロックスクリプトには、スクリプトのバージョンを管理するバイトがあります。バージョンを使用すると、ソフトフォークの形で追加や変更（構文の変更、新しい演算子など）を行うことができます。

署名検証の最適化

分離された証人は、署名アルゴリズム（CHECKSIG、CHECKMULTISIGなど）のパフォーマンスも最適化します。 segwit以前は、ハッシュ計算の数は署名の数から2次的に増加しましたが、更新ではアルゴリズムの複雑さはO（n）に減少しました。

線形対二次

それで問題は何ですか？

分離された監視媒体の画像

それで、もしすべてがとても良いなら、問題は何ですか？このアップデートには、ネットワーク上の多くの敵がいます。すべての明らかな利点にもかかわらず、弱点もあるからです。反対の議論をいくつか考えてください。

segwitはソフトフォークであるため、すべてのクライアントが更新されるわけではありません。つまり、ネットワーク上に2種類のUTXOが同時に存在し、トランザクションIDの脆弱性の排除や線形時間でのハッシュなどの重要な変更は、非Segvitアウトレットには適用されません。ネットワークは、トランザクションIDのボラティリティに基づく攻撃、および2次ハッシュ時間の問題に対して依然として脆弱です。
Segwitはネットワークセキュリティを低下させる可能性があります。完全検証を実行するノードの数は大幅に減少します。これは、セグウィットを受け入れる人のみがトランザクションの監視部分を検証できるためです。
Segwitはキャンセルできません。キャンセルしてすべての変更をロールバックすると、すべてのsegwit出力がすべてのユーザーに利用可能になります。
Segwitはすべての問題を一度に解決しようとします。その結果、膨大な量のコードが変更されます。これにより、さらなる作業が複雑になり、バグの除去がより困難になる可能性が高くなります。