2010年の従業員は、10年後のBTCの構築にどのように関与しているかをどのように見ていますか

著者:ビットコインポッドキャストブロックダイジェストの共同作成者シノビ。 コンピレーション:ファイブバーツ、ゴールデンファイナンス

この記事はShinobiが10年前に書いたもので、2020年のBTCの姿について探っています。

本シリーズの最初の記事はこちらをクリックしてください:《2010年のプロフェッショナルが10年後のBTCエコシステムをどのように考えているか?》

私たちはすでに第2層の潜在能力の種が、最初の10年間の基本的な言語から発展し始めているのを見始めています。ライトニングネットワークはまだかなりの制約を受けていますが、確かに急速に発展しています。これは現在指定されて展開されている初期バージョンに過ぎません。現在、Liquid、RSKなどの様々なタイプのサイドチェーンが展開されています:さらに、BTCにバインドされたトークンチェーンを開発しているCommerceblockもあります。これはただの始まりに過ぎません。

シュノールとタプロット

間もなくして、私たちはSchnorrとTaprootの組み合わせを手に入れました。Schnorrから見ると、これはコストが低く、BTCのマルチシグスクリプトの構築を最適化する次の大きな飛躍であるバッチ検証署名スキームです。最初、マルチサインはすべての公開鍵とマルチサインスクリプトをトランザクションの出力に詰め込んで送信し、それらをすべて含めなければ使用できなかった。P2SHは、マルチサインの公開鍵とスクリプトを包含することで、マルチサインアドレスに送金された人々にコストを節約し、送信者にコストを追加することなく、出力を最適化しました。SegWitは、ウィットネスディスカウントによりマルチサインUTXOの消費をより安くし、さらに「最適化」しました。Schnorrは、これらすべての増分最適化を最大限に活用します。個々の公開鍵を1つの鍵に組み合わせ、各人がそれをサインすることができ、それをチェックすることができます。これにより、マルチサイン技術(ライトニングネットワーク(Lightning)やサイドチェーンなどの第2層を含む)のすべての使用者は多額のコストを節約し、すべてのこれらのマルチサインUTXOをシングルサインUTXOと区別できなくすることでプライバシーの利点をもたらします。

現在、これには全てが完全に秘密になるわけではないことを神秘的にすることはできません。ライトニングネットワークの状態(トランザクション)は、引き続き古い状態に対するペナルティトランザクションに反応するために、個別の鍵パスが必要です。これは、これらが出力スクリプトで指紋を作成する必要があることを意味します。Taprootは、その暗号魔法によってこの問題を解決し、異なる支出条件を持つMerkleツリーを提出し、使用する条件とMerkle証明をMerkleルートに支出するだけで、見かけ上正常なSchnorr公開鍵になります。今では、penaltyスクリプトパスを隠すためにTaprootを使用できます。Taprootを使用して見かけ上正常なSchnorrキーの下に非表示にすることができ、このキーを使用すると、すべての参加者が合意に達し、見かけ上非常に普通の取引を行うことができます。

ため息_ANYPREVOUTPUT

SIGHASH_ANYPREVOUTPUT(以前は SIGHASH_NOINPUT)が次の新しい原語になる可能性があります。これは新しい公開鍵形式/ sighash フラグのアップグレードです。Sighash フラグは、どの部分の取引に署名を提出するかを指定します。この機能の存在は、あなたが入力と出力だけに署名するなどの操作を実行できるようにし、他の人が自分の入力と出力を取引に追加しても無効にしないようにするためです。ただし、現時点では、署名は特定の取引からの特定のUTXOに提出する必要があります。他のことに加えて、SIGHASH_ANYPREVOUT は、署名をUTXOスクリプトに提出することができますが、実際の特定のUTXOではありません。これにより、新しい方法(eltoo)で閃光チャネル状態を構築することができ、罰金キーを処理せずに古い状態を処理し、被害者がすべての資金を没収できるようにします。その代わりに、現在のチャネル状態が二重支払い競争で失敗した場合、単純に古いチャネル状態を再利用することができ、それにより、すべての人がチェーン上で現在のチャネル残高を取得できることが保証されます。古い残高。同じスクリプトを正しい位置に再利用し、SIGHASH_ANYPREVOUTを使用するだけで、これを実現できます。

これにより、現在のチャネルの状態を失うことによる罰金取引で資金を拘束するという意図しない損失のような多くのリスクが排除されます。それに加えて、これにより多くの機能が実現されることになります。現在、私たちは2人以上の参加者を持つライトニングチャネルを持つことができ、さらにそれらのチャネルの上に「サブチャネル」を積み重ねることができます。さらに、SIGHASH_ANYPREVOUTとeltooを使用することで、Statechainsを作成することができます。これは、新しい参加者が完全にオンチェーンで参入し、退出することを可能とし、同盟が過去の参加者と共謀して誰かをだますことはないというものです。これにより、私が常に「マルチパーティ静的UTXOプロトコル」と呼んでいるプロトコルに多くの可能性が開かれます。

OP_CHECKTEMPLATEVERIFY

OP_CTV は Jeremy Rubin によって提案されたBTC上で非常に基本的な「契約」を実現することを目的としています。契約は1BTCを使用する際のより複雑な制限であり、単に特定の鍵の署名にとどまりません。Rubin の提案で実装される契約タイプは「テンプレート」です。基本的には、UTXOのスクリプトが特定の正確な出力を生成するために支出トランザクションを要求します。したがって、OP_CTV を使用してUTXOを作成すると、それはコンセンサスによって強制的に実施され、つまり、UTXOを特定のアドレスに支出し、その金額をそのUTXOのスクリプトで定義する必要があります。それらをリンクして、1つのUTXOが再生成されるように強制し、そしてこれらのUTXOが再度強制的に生成されるようにすることさえできます。

どこにでも広く一般的に適用されます。高コストの環境では、信託実体が個々のUTXOを作成し、その実体が全顧客の資金を100%共通ルールに従って保証することにより、その資金が将来顧客によって制御されることを保証します。たとえその資金に直ちにアクセスできない場合でもです。これは多方チャネル(チャネルファクトリー)と非常に協力的な相乗効果を持っています。このような大規模な「引き出し」が同時にチャネルファクトリーとして作成および使用されることができるためです。OP_CTVを使用すると、受信側が関与せずまたはオンラインで受け取り鍵を所有する必要がなく、少なくとも一方向で機能する支払いチャネルを作成することができます(複数のチャネルをスタックできることを覚えておいてください)。これは、単一のチャネルが一度により多くのHTLCを処理することを可能にするためにも使用でき、これは、それらを1つにまとめ、最初の信託提供の例で使用されるテクニックと同じです。さらに、新しいタイプのcoinjoinにいくつかの可能性を生み出すことさえ可能です。

すべての要素を統合する

上記の提案がすべて受け入れられ、BTCに組み込まれたと仮定した場合、私は本当に、これらの先駆的な作業に従事する開発者以外の人々が、どのような種類のプロトコルやサービスが構築されるかさえ知らないと考えています。また、サービスやプロトコルの間には明確な境界線がない奇妙なものもあります。

それらは理論上参加者数に制限がないマルチパーティーチャネルを可能にし、これらのチャネルは基本チャネル参加者の小さなサブグループの上にスタックされることができます。これらの「チャネルファクトリー」の上にチャネルを構築することができ、人々はオンラインでホットウォレットのキーを所有していなくても支払いを受け取ることができます。これらのマルチパーティーチャネル自体は共同チャネル(ステートチェーン)の上にスタックすることができ、参加者がチェーン上でゼロ活動で入場または退出できるようにします!チャネルの「接続」構造により、流動性をさまざまなチャネル間で比較的シームレスに移動させることができ、人々はまだ考えていないさまざまなことを実現できます。

私のこのセクションでの最後の一文は、これは私がBTCプロトコルスタック自体の直接の構成要素と考えているものについて考慮されているだけです。中央集権型の保管サービスや、規制や法的障壁の影響を受けずに、これらのサービスがBTCのどのサブセットを提供できるかを調査し始めると、より多くのことができるようになります。

BTC-0.41%
原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • リポスト
  • 共有
コメント
0/400
コメントなし
  • ピン
いつでもどこでも暗号資産取引
qrCode
スキャンしてGateアプリをダウンロード
コミュニティ
日本語
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)