Payment channels

提供: tezos-wiki
移動先: 案内検索

A Micropayment Channel Payment Channel は、ユーザーがBitcoinブロックチェーンにすべてのトランザクションをコミットせずに、複数のBitcoinトランザクションを作成できるように設計された技術の一種である[1]典型的な決済チャネルでは、ブロックチェーンに2つのトランザクションしか追加されませんが、参加者間で無制限またはほぼ無制限の支払いが可能です。

長年に渡っていくつかのチャネル設計が提案され、実施されてきた。この記事では、そのいくつかについて説明します。多くのデザインはトランザクション可用性に対して脆弱です。具体的には、多くの設計では、チャネルをアトミックに開くことができるように、符号なしトランザクションを使用できる方法が必要です。したがって、これらの設計では、txidを形成するためにハッシュされるトランザクションの部分からシグネチャを分離する展性修正が必要です。

中本高頻度取引[編集]

Bitcoin 0.1に実装されているのは、 transaction replacement [2]、入力シーケンス番号(nSequence)、nLockTimeなど、複数の当事者が繰り返し更新できるようにする機能それが確認される前の未確認取引の状態。

Satoshi Nakamotoはこの技術をBitcoin開発者に個人的なメールで説明しました:[3]

未記録のオープントランザクションは、nLockTimeまで置き換えられ続けることができます。複数の当事者による支払いが含まれる場合があります。各入力所有者は入力に署名します。書き込まれる新しいバージョンでは、それぞれがより高いシーケンス番号に署名する必要があります(IsNewerThanを参照)。署名することによって、入力所有者は、「誰もがお金を入れて、その成果がこれなら、私のお金を入れることに同意する」と言う。 SIGHASH_SINGLEのようなSignatureHashには他のオプションがあります。これは、「この1つの出力(つまり私のもの)が私の望むものであれば、私はあなたが他の出力で何をしているか気にしません」という意味です。それが高いnSequenceNumberで書かれている場合、当事者はその1つの規定を除いて交渉から外れ、またはSIGHASH_NONEに署名して完全に外に出ることができます。

当事者は、OP_CHECKMULTISIGを使用してより高いnSequenceNumber txを作成することにより、事前に合意されたデフォルトオプションを作成することができます。署名者は、署名を完了するために署名する部分のサブセットが必要です。両当事者はこの予約を保留にし、必要に応じて十分な署名があるまでそれを渡します。

nLockTimeの1つの使用法は、一連の当事者間の高頻度取引である。彼らは全会一致でtxを更新し続けることができます。お金を払っている当事者は、次のバージョンに最初に署名することになります。一方の当事者が変更に同意しなくなると、最後の状態がnLockTimeに記録されます。必要に応じて、n-1当事者が応答しないパーティーを押し出すことができるように、各バージョンの後にデフォルトトランザクションを準備することができます。中間トランザクションは、ブロードキャストする必要はありません。最終結果のみがネットワークによって記録される。 nLockTimeの直前に、当事者といくつかの目撃者ノードが、見た最も高いシーケンスtxをブロードキャストします。 </ blockquote>

この設計は安全ではありませんでした。[citation needed]一方の当事者は、最終的な取引をコミットするために鉱夫と共謀し、おそらく他の当事者から資金を盗む可能性があります。

スピルマンスタイルの支払いチャネル[編集]

bitcoin-developmentメーリングリスト[4]で議論され、BitcoinJ、[5]で実装され、保証されたデポジットを作成し、鉱夫が取引の非最終版をコミットできないようにすることで合意した。しかし、Spillmanモデルのチャンネルを開くことにより、預金者は預金者の資金を人質に保つことができる展望リスクにさらされた。[6]

プロトコルの詳細な説明は契約ページの例7にあります。

スピルマンの支払いチャネルは一方向です(支払人と受取人があり、逆の方向に送金することはできません)。

スピルマン支払いチャネルは特定の時間後に期限切れになり、受信者は期限切れになる前にチャネルを閉じる必要があります。

CLTVスタイルの決済チャネル[編集]

#bitcoin-wizards IRCチャンネルで開始された議論の後、[citation needed]のbitcoin-developmentとbitcoin-devメーリングリストに移って、[citation needed]のCLFソフトフォークの起動によって、Decemember 2015で可能になりました[7]をリストアップし、BIP65にデザイン仕様を掲載しました。新しいOP_CLTVオペコードを使用して構築されたチャンネルは、スピルマンスタイルの構造に固有の可鍛性の問題に耐性がありました。[6]

Spillmanの決済チャネルと同様に、CLTV形式の決済チャネルは単方向であり、特定の時間が経過すると期限切れになります。

Poon-Dryja支払いチャネル[編集]

Poon-Dryjaの支払いチャネルは、<ref name = "ln_pdf"> Lightning Network paper、v0.5.9.1に掲載されました
Joseph Poon& Thaddeus Dryja
['Lightning Network]]を紹介した' Retrieved 2016-04-10 </ ref>チャネルバッキングファンドは2-of-2 multisigにロックされますが、資金調達取引にサインする前に、各当事者のコミットメント取引が最初に書かれ署名されます。まだ署名されていないトランザクションを参照する必要があるため、[[分離監視(Separation Witness)]などのtxidを生成するためにハッシュされるトランザクションの部分から署名を分離するトランザクション形式を使用する必要があります。

Poon-Dryjaチャンネルは一方的に閉鎖されるか(片方の参加が必要)、または双方向に閉鎖される(双方の参加が必要)。 Poon-Dryjaチャンネルは、双方向に閉じたとき、2-of-2マルチサインアドレスの使用とチェーン上区別できません。一方的に閉鎖された場合、チャネルを閉鎖した当事者の資金は一時的にタイムロックされます。これにより、相手方は、閉鎖当事者(閉鎖時に古い状態を与えた可能性がある)によって送信された状態に異議を唱えることができます。

Poon-Dryjaの支払いチャネルには、無期限の生涯があります。また、SpilmanやCLTVの決済チャネルとは異なり、双方向性もあります。

Lightning BOLTの仕組みには、Poon-Dryja支払い札幌の推奨実装が含まれています。

Decker-Wattenhofer二重支払チャネル[編集]

二重支払チャネルは、<ref name = 'duplex_pdf'> BitCinを使用した高速かつスケーラブルな決済ネットワークデュプレックスマイクロペイメントチャネル Decker、C。 Wattenhofer、R。Christian DeckerとRoger Wattenhoferによる</ ref>このタイプのペイメントチャンネルには、nSequenceという新しいBIP68 <ref name = 'bip68'> BIP68 </ ref>の意味が必要です。この名前が示すように、双方向決済チャネルは、双方向の一方向決済チャネル2つで構成されています。単方向支払いチャネルは基本的にSpillmanチャネルですが、nLockTimeではなく相対ロック時間(nSequence)を使用します。

しかし、チェーン上の資金調達取引から単方向決済チャネルに直接資金を提供するのではなく、資金調達取引と決済チャネルファイナンス取引との間のオフチェーン取引の「無効化ツリー」があります。無効化ツリートランザクションも相対ロック時間を使用します。トランザクションの最初のバージョンは大きな相対ロック時間を持ち、トランザクションの次のバージョン(最初のバージョンを無効にする)は相対的に小さなロック時間を使用します。相対ロック時間のタイムアウトを開始する「キックオフ」トランザクションもあります。トランザクションのシーケンスは、こうして資金調達 - >キックオフ - >無効化ツリー - >決済チャネルです。

最初、無効化トランザクションは100日の相対ロック時間を持つことができ、その出力はいずれかの方向に1つずつ2つの単方向支払チャネルに移動します。そして、双方の当事者は、1つのチャネルが使い尽くされるまで、支払いチャネルを使用することができる。その後、両当事者は支払いチャネルをリセットし、99日の相対的なロック時間を有する新しい無効化トランザクションを作成し、金銭を正しく再分配するが、一方向性の支払いチャネルをリセットしてもよい。

支払いチャネルは、ブロックチェーン上でキックオフ取引をブロードキャストすることにより、いずれかの当事者(他者の助けを借りずに)によっていつでもクローズすることができる。このような一方的な決済の場合、両当事者は、支払いチャネル終了取引をブロードキャストできるようになるまで、相対ロック時間を待たなければならない。

締約国は、キックオフ、無効化ツリー、および決済チャネル取引を両当事者に資金を支払う単一の単純な取引に崩壊させる双方向(協調)決済を優先するべきである。

二重決済チャネルの有効期間は不定ですが、無効化ツリーのために可能な更新数には制限があります。この限度は、無効化ツリーに追加のレイヤーを追加し、下位レイヤーをリセットすることによって乗算することができます。最後に、一方的なクローズド・デュープレックスの場合、支払いチャネルにはかなりの待ち時間とかなりの数の取引がブロックチェーンに掲載される必要があります。

無効化ツリー構造は、実際には2つ以上の参加者を有することができる。 3つ以上の当事者のグループが、この無効化ツリー構造によって裏付けされた複数の支払いチャネルを構築し、ブロックチェーンに当たることなく支払いチャネルを再調整することが可能です。<ref name = 'scaling_funding_pdf'> [https:/ / /www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf Bitcoin Micropayment Channel Networksのスケーラブルな資金調達]無効化ツリー構造がPoon-Dryjaの資金を調達することも可能です単方向の支払いチャネルのペアではなく、

ハッシュタイム・ロック・コントラクト(HTLC)[編集]

完全な記事:Hashed Timelock Contracts

例えば、アリスがボブに開かれたチャンネルを持っていて、ボブにチャーリーに開かれているチャンネルがある場合、アリスはHTLCを使ってチャリティーを支払うことができますボブが輸送中の支払いを盗むリスクなしにボブ。 HTLCは、Lightning Networkによって使用されるような、より高度な支払いチャネルの設計に不可欠です。

参考文献[編集]

<リファレンス>

<ref name = "bitcoinorg_dev_guide"> Bitcoin.org開発者ガイド<https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channel> </ ref>

<ref name = "replacement_in_original_code"> [1]
GitHub </ ref>中本聡>

<ref name = "hearn_hft_quote"> txを置き換えるためのアンチDoS、Mike Hearn、bitcoin-developmentメーリングリスト、4月17日2013 </ ref>

Jeremy Spillman、bitcoin-developmentメーリングリスト、<ref name = "spillman_channel_description"> [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Re: 2013年4月20日</ ref>

<ref name = "channels_bitcoinj"> [2]、Mike Hearn&Matt Corallo、BitcoinTalk.org、2013年6月27日</ ref >

2016年10月28日に取得されたBIPリポジトリのPeter Todd氏<ref name = "bip65"> BIP65 </ ref>

<ref name = "bitcoin_dev_bip65"> [bitcoin-dev BIP65 CHECKLOCKTIMEVERIFYを導入しよう!]、Peter Todd、bitcoin-devメーリングリスト、2015年9月27日</ ref> </リファレンス>

Category:技術
  1. 引用エラー: 無効な <ref> タグです。 「bitcoinorg_dev_guide」という名前の引用句に対するテキストが指定されていません
  2. 引用エラー: 無効な <ref> タグです。 「replacement_in_original_code」という名前の引用句に対するテキストが指定されていません
  3. 引用エラー: 無効な <ref> タグです。 「hearn_hft_quote」という名前の引用句に対するテキストが指定されていません
  4. 引用エラー: 無効な <ref> タグです。 「spillman_channel_description」という名前の引用句に対するテキストが指定されていません
  5. 引用エラー: 無効な <ref> タグです。 「channels_bitcoinj」という名前の引用句に対するテキストが指定されていません
  6. 6.0 6.1 引用エラー: 無効な <ref> タグです。 「bip65」という名前の引用句に対するテキストが指定されていません
  7. 引用エラー: 無効な <ref> タグです。 「bitcoin_dev_bip65」という名前の引用句に対するテキストが指定されていません