この記事は、提案されたTaprootプロトコルのアップグレードに基づく技術的概念についてです。 Taprootの動作の基本にまだ慣れていない場合は、まず読むことをお勧めします この説明者.
Taproot、Bitcoin Coreの貢献者であるGregory Maxwellによって最初に提案されたBitcoinプロトコルへの潜在的なアップグレードは、開発の後半の段階にあります。 この技術は、ユーザーが複雑なスマートコントラクトを通常のトランザクション内に隠すことができる暗号トリックの巧妙な組み合わせで構成されています。複雑さは、契約の当事者が協力的でない場合にのみ明らかになります。
このアイデアを活用して、ジェレミー・ルービン、アントワーヌ・リアード、グレブ・ナウメンコ、グレゴリー・マクスウェルなどを含むビットコインコアの寄稿者自身が、 支払いプール, ジョインプール またはコインプール。 これらのプール—ここではそれらを支払いプールと呼ぶことにします—は、ユーザーのグループがビットコインブロックチェーンに記録されたものと同じコイン（技術的にはUTXO）の所有権を共有できるようにする一方で、これらのユーザーは支払いを行う（または受け取る）ことができます彼らと。 グループとその個々のメンバーがTaproot構造に「非表示」になると、すべてのメンバーがプライバシー、スマートコントラクトの柔軟性、その他のメリットを享受できます。また、これらのメリットをオフチェーンで享受して、支払いプールを新しいレイヤーXNUMXソリューションにすることもできます。
設計の詳細は支払いプールの提案ごとに少し異なりますが、一般的な概念は同じです。 これが基本的なアイデアです…
コインを共有する
まず、支払いプールを作成するために、ユーザーは、それらの間で共有されるTaprootアドレスにそれらを集約することにより、それらの（一部の）コインを結合します。 つまり、アリスがXNUMX枚のコインを所有し、ボブがXNUMX枚のコインを所有し、キャロルがXNUMX枚のコインを所有し、合計でXNUMX枚であるとします。 一緒に、これらのコインを共有アドレスに送信するトランザクションを作成し、XNUMXつのコインを含む支払いプールにします。
ブロックチェーンでは、支払いプールのアドレスは通常のビットコインアドレスのように見え、現在XNUMXつのコインを保持しています。 しかし、水面下で、アリス、ボブ、キャロルは巧妙にタップルートを使用して、支払いプール内のコインのシェアをそれぞれが確実に制御できるようにしました。 アリスはいつでも住所からXNUMX枚のコインを請求でき、ボブはいつでもXNUMX枚、キャロルXNUMX枚を請求できます。
これは、住所からコインを使うための主なオプションがXNUMXつしかないためです。
最初のオプションは、技術的にはTaprootキーパスで、アドレスから直接使うことです。 これには、XNUMX人の参加者全員の協力（つまり、暗号化署名）が必要です。 アリス、ボブ、キャロルのすべてが同意すれば、XNUMX枚のコインは好きなように使えます。これは、ビットコインネットワーク上の他の通常のトランザクションと同じように見えます。 トリオは、たとえば、それぞれの残高を個々の住所に送り返すことを決定できます。XNUMXつはアリス、XNUMXつはボブ、XNUMXつはキャロルです。 しかし、彼らがそうすることを選択した場合、彼らはまた、XNUMXつのコインすべてをジュリアンに寄付するために協力するか、または同意する可能性のある他の方法でそれを使うこともできます。 重要なのは、XNUMX人とも参加する必要があるため、自分の協力なしにバランスを費やしていないことです。
XNUMX番目のメインオプションは、実際にはいくつかのサブオプションで構成されています。 コインを支払いプールに送る前に、アリス、ボブ、キャロルは暗号ツリーのTaprootアドレスの後ろに何かを隠しました：彼らは支払いプールから資金を送る別の方法を含んでいました。 （現在、これは、XNUMX人の参加者全員がこれらのパスからトランザクションに事前に署名することで実現できます。これは、すべてのオプションを設定するために複雑さを必要とし、十分に拡張されません。提案されているプロトコルアップグレードは、将来これを容易にする可能性があります。 。）
参加者のXNUMX人が代替のTaprootパスを介して支払いプールでコインを使うことを選択する場合、彼らは通常、その参加者の残高に対応する金額を、自分が制御する個々のアドレスなど、選択したアドレスに送信します。 （アリスの場合、自分の住所にXNUMX枚のコイン、ボブの場合は彼の住所にXNUMX枚、キャロルの場合はXNUMX枚）。
この代替パスを使用すると、残りのコインも自動的に使用されます。 これは、支払いプールの設計に応じていくつかの方法で行うことができ、複雑さとスケーラビリティに関して異なるトレードオフを提供します。
最も簡単な解決策は、他のすべての参加者にコインのシェアも送信し、選択したアドレスに送信することです。 言い換えると、XNUMX人のユーザーがプールを終了すると、全員がプールを終了します。
RiardとNaumenkoが好むXNUMX番目の解決策は、残りのすべてのコインを 新製品 支払いプール。最初の支払いプールとまったく同じように見えますが、現在終了しているユーザーに関係するものはすべて取り除かれています。 この設計は最高のユーザーエクスペリエンスを提供しますが、すべての潜在的な新しいプールのすべての可能な終了シナリオを含むすべての可能な終了シナリオを準備する必要があるため、最も重要なことに、拡張が最も困難です。 ただし、以前の支払いプールからのルールが新しい支払いプールに確実に引き継がれるようにするために、まだ名前が付けられていない可能性のあるビットコインプロトコルのアップグレードでスケールを達成できます。
ルービンは、このXNUMX番目のソリューションは非現実的であると考えており、最初とXNUMX番目のソリューションの中間に行くことを好みます。一部の参加者は選択したアドレスにコインをすぐに受け取り、他の参加者は新しい支払いプールにコインを送ってもらいます。 この設計では、ユーザーエクスペリエンスは理想的ではありませんが、拡張性は高くなります。OP_CHECKTEMPLATEVERIFYプロトコルのアップグレードの可能性があると、設計が簡素化され、規模がさらに拡大します。 （出口はTree Paymentsを通じて発生します。これらのタイプの支払いは、 この記事.)
（XNUMX番目とXNUMX番目のソリューションの間にはトレードオフがありますが、すべての長所と短所の詳細はこの記事の範囲外です。 bitcoin-devメーリングリストディスカッション 詳細については）。
残りのコインが新しい支払いプールに送られるときの意味を確認するために、アリス、ボブ、キャロルがXNUMX番目のオプションを選択するとします。 を 残りのコインは新しい支払いプールに送られます。 この設計でアリスが最初の支払いプールを出ると、XNUMXつのコインが彼女の選択したアドレスに送られ、他のXNUMXつのコインはボブとキャロルの間の新しい支払いプールに送られます。 その時点でのアリスは、自分のコインを再び単独で制御できますが、ボブとキャロルの場合はそれほど変わっていません。 XNUMX人は引き続き協力して、残りのXNUMX枚のコインを好きなように使うことができます。または、アリスが以前に行ったように、どちらかを一方的に出ることもできます。
その後、ボブがXNUMX番目の支払いプールから一方的に出る場合、彼は自分の選択したアドレスにXNUMX枚のコインを送り、キャロルのみが残っているXNUMX枚のコインをさらに新しい支払いプール（XNUMX番目）に送ります。 （もちろん、この単純化された例では、この最後の支払いプールがCarolが選択したアドレスに置き換えられた設計が実際にはより理にかなっていますが、これは実装の詳細です。）
重要なポイントは、支払いプールの参加者が協力して必要なプールからあらゆる種類の支払いを行うことができる一方で、誰でもいつでも自分のコインで出て、他の参加者が自分のコインを制御できるということです。
支払いを支払いプールに入れる
したがって、すべての参加者が個別に支払いプールから残高を引き出すことができるか、全員が同意する場合はプールから使うことができることを確立しました。 賢いことを可能にするのは、このXNUMX番目のオプションです。支払いプールは動的にすることができます。 すべての参加者が同意する限り、彼らは自分自身に資金を返済したり、他の人（ジュリアンなど）に支払うだけでなく、さらに興味深いことを行うことができます。 彼らは、異なるデザインの新しいバージョンの支払いプールに資金を移動できます。
これにより、たとえば、プールからXNUMX人が費やすことができます。
アリスが新しい車を購入していて、XNUMXつのビットコインでそれを支払いたいとしましょう。 次に、アリス、ボブ、キャロルは、XNUMXつのコインを自動車販売店に送信し、残りのXNUMXつのコインを 新製品 最初の支払いプールと同じように見える支払いプールですが、今回は、アリスは片側にXNUMX枚のコインしか出せません。
その間、トランザクションは他の通常のビットコイントランザクションのように見えました。 自動車販売店（またはブロックチェーンのスパイ）は、アリスがXNUMX枚のコインをすべて所有し、XNUMX枚を単に車の購入に使用し、残りのXNUMX枚は釣銭として残したと結論付けることができます。 彼らは、コインの一部がボブとキャロルに属していることや、取引にまったく関与していたことを知りません。
次回は、ボブが支払いを行い、アリスとキャロルが協力する場合、同じ支払いプールから行われ、再び外界への通常のビットコイン取引のように見えます。 結果としての支払いプールの反復では、ボブはXNUMX枚ではなくXNUMX枚のコインで終了できます。 その間、同じブロックチェーンのスパイは、アリスが再び支払いをして、さらに混乱させたと思ったかもしれません。 （そして、ブロックチェーンスパイがアドレスが実際にアリス、ボブ、キャロルの間の支払いプールであることを何らかの方法で理解したとしても、彼らはまだXNUMX人のうちのどれが最後の支払いをしたかを知ることができませんでした。）
アリス、ボブ、またはキャロルがコインを使うたびに、トランザクションはそれらのいずれかからのものである可能性があり、支払いプールの外部の誰も違いを見分けることができません。
支払いプールは、支出を可能にするだけではありません。 アリスが支払いプールで「残高」を補充したい場合、アリスもこれを行うことができます。 この場合、アリス、ボブ、キャロルは、現在のXNUMX枚のコインを新しいタップルートアドレスに移動するために協力します。同じトランザクションで、アリスは自分の（個人の）アドレスのXNUMXつから追加のコインをXNUMX枚送信します。 タップルートの新しいアドレスには、XNUMXつのコインが含まれており、そのうちのXNUMXつはアリスのもので、片側の出口オプションに反映されています。
同様に、まったく新しいユーザーも支払いプールに参加できます。 アリス、ボブ、キャロルがデイブの参加を許可することに同意した場合、XNUMX人はデイブと協力して、デイブの新しいコインと共にペイメントプールの資金を新しいペイメントプールに送信するトランザクションを作成します。彼がそう選ぶなら。
さらに、支払いプール内の参加者がお互いに支払うオプションがあります。 たとえば、アリスがボブにXNUMX枚のコインを支払う場合、XNUMX人は協力して新しい支払いプールに送金し、アリスは残高からコインを差し引いて、ボブはコインを追加します。 ブロックチェーンでも、これは通常の支払いのように見え、ブロックチェーンのスパイはだれが誰に、どれだけの金額を支払ったかを知りません。 （Daveが、既存の参加者のXNUMX人から内部支払いを受け取ることで、同様の方法でプールに参加できたことを指摘する価値があります。）
少し複雑になっています（理想的には、ビットコインプロトコルのアップグレードをXNUMXつ以上追加すると 入力なし）、転送はチェーン外で完了することもできます。 アリスがボブに支払うとき、すべての参加者はこの場合、同じように新しい支払いプールに資金を費やすトランザクションを作成しますが、このトランザクションはそれらの間でのみ共有され、ネットワークにブロードキャストされません（だれかが不正行為を試みない限り）。 このようにして、アリス、ボブ、キャロルはバランスを「内部で」更新し続け、ある時点でデイブをプールに入れることさえできました。 全員がプールを閉鎖することに同意すると、元の支払いプールから費やして最終的なトランザクションを作成し、それぞれに最新の残高を付与できます。
として知られている古いアイデアに似ています チャネルファクトリ、これらのタイプの支払いプールは、最終的には、Lightningチャネル、ボールト、またはその他のレイヤーXNUMXプロトコルをホストするために使用することもできます。 これにより、そのようなプールにあらゆるタイプの追加プロトコルレイヤーを「ラップ」する可能性があり、そのため、同一で通常のトランザクションの複雑さをすべて隠すことができます。