Gloria ZhaoとMurchによる

Bitcoin Coreがコンセンサスで認められているよりも制限的なポリシーを持つ理由や、 ウォレットがそのポリシーを最も効果的に使用する方法など、トランザクションリレー、 mempoolへの受け入れ、マイニングトランザクションの選択に関する週刊連載の全公開内容のコピーです。

  1. なぜmempoolがあるのか？
  2. インセンティブ
  3. ブロックスペースの入札
  4. 手数料率の推定
  5. ノードリソースの保護に関するポリシー
  6. ポリシーの一貫性
  7. ネットワークリソース
  8. インターフェースとしてのポリシー
  9. ポリシーの提案
  10. 参加してみよう

なぜmempoolがあるのか？

ニュースレター #251に掲載

Bitcoinネットワークの多くのノードは、未承認のトランザクションをインメモリのプール、 つまり mempool に保存しています。このキャッシュは、各ノードにとって重要なリソースであり、 ピアツーピアのトランザクションリレーネットワークを可能にしています。

トランザクションリレーに参加するノードは、ブロックを急激にではなく徐々にダウンロードし検証します。 ブロックが見つかる約10分ごとに、mempoolを持たないノードは帯域幅のスパイクが発生し、 その後、各トランザクションを検証するための計算負荷の高い期間が続きます。 一方、mempoolを持つノードは、通常、ブロック内のすべてのトランザクションをすでに確認しており、 それらをmempoolに保存しています。 コンパクトブロックリレーを使用すると、 これらのノードは、ブロックヘッダーとショートIDをダウンロードするだけで、 あとは自分のmempool内のトランザクションを使用してブロックを再構築します。 コンパクトブロックのリレーに使用されるデータ量は、ブロックのサイズに比べればごくわずかです。 ノードはすでに署名とスクリプトを検証し（かつキャッシュし）、タイムロックの要件を計算し、 必要に応じてディスクから関連するUTXOをロードしているため、トランザクションの検証もはるかに高速化されています。 また、ノードはブロックを他のピアに迅速に転送できるため、ネットワーク全体の ブロック伝播速度が劇的に向上し、ブロックが古くなるリスクも低減します。

また、mempoolは独立した手数料推定器を構築するためにも使用できます。 ブロックスペースの市場は手数料ベースのオークションであり、 mempoolを保持することで、ユーザーは他の人がどんな入札をしているか、 過去にどのような入札が成功したかをより正確に把握することができます。

しかし、すべての人にとって共通のmempoolというものは存在しません。 各ノードは異なるトランザクションを受信する可能性があります。 あるノードにトランザクションを送信したとしても、それが必ずマイナーにも届くとは限りません。 このような不確実性をもどかしく思うユーザーもいます。 「なぜ、マイナーに直接トランザクションを送信しないのか？」と疑問に思う人もいます。

すべてのトランザクションがユーザーから直接マイナーに送信されるBitcoinネットワークを考えてみましょう。 少数の事業者に対して、各トランザクションに対応するIPアドレスを記録し、 特定のパターンに一致するトランザクションの受け入れを拒否するよう要求することで、 金融活動を検閲し監視することができます。このようなBitcoinは、 ときにはより便利かもしれませんが、Bitcoinの最も重要な特性のいくつかが失われてしまいます。

Bitcoinの検閲耐性とプライバシーは、ピアツーピアのネットワークに由来します。 トランザクションをリレーするために、各ノードは匿名のピアのセットに接続します。 これらのピアは、マイナーである可能性もあれば、マイナーに接続されている誰かかもしれません。 この方法は、トランザクションがどのノードから発信され、 どのノードがそのトランザクションの承認を担当しているのかを難読化するのに役立ちます。 特定のエンティティを検閲したいと思う人は、マイナーや人気のある取引所、 または他の中央集権型の送信サービスを標的にするかもしれませんが、なにかを完全にブロックするのは難しいでしょう。

未承認トランザクションの一般的な可用性は、ブロックプロデューサーになるための参入コストを最小限に抑えるのにも役立ちます。 選択された（または除外された）トランザクションに不満を持つ人は、すぐにマイニングを開始することができます。 各ノードをトランザクションのブロードキャスト候補として平等に扱うことで、 トランザクションとその手数料への特権的なアクセスをどのマイナーにも与えないようにすることができます。

まとめると、mempoolは、ノードがブロックのダウンロードと検証のコストを時間的に分散させ、 ユーザーがより良い手数料の見積もりにアクセスできるようにする非常に有用なキャッシュです。 ネットワークレベルでは、mempoolは分散トランザクションとブロックのリレーネットワークをサポートします。 これらの利点はすべて、マイナーがブロックに含める前にすべてのトランザクションを誰でも確認することができる時に最も顕著になります。 他のキャッシュと同様に、mempoolは「ホット」なときに最も有用で、メモリに収めるためにサイズを制限する必要があります。 来週のセクションでは、最も有用なトランザクションをmempoolに保持するための指標として、 インセンティブの互換性の使用について検討します。

インセンティブ

ニュースレター #252に掲載

先週の記事では、mempoolについて、未承認トランザクションのキャッシュとして、 ユーザーがトランザクションをマイナーに送信するための分散化された方法を提供するものであると説明しました。 しかし、マイナーはそのトランザクションを承認する義務はなく、 コインベーストランザクションだけを含むブロックはコンセンサスルールにおいて有効です。 ユーザーは、トランザクションの総アウトプット額を変更せずに、総インプット額を増やすことで、 マイナーに自分のトランザクションを承認するインセンティブを与え、 マイナーはその差額をトランザクション 手数料 として請求することができます。

トランザクション手数料は、従来の金融システムでは一般的ですが、 新規のBitcoinユーザーは、オンチェーン手数料が取引額に比例するのではなく、 トランザクションのweightによって支払われることに驚くことがよくあります。 流動性ではなくブロックスペースが制限要因になります。 手数料率 は通常、仮想バイト（virtual byte）あたりのsatoshiで表されます。

コンセンサスルールにより、各ブロックでトランザクションが使用するスペースが制限されています。 この制限により、ブロックの伝播時間がブロック間隔に対して低く保たれ、 ブロックが古くなってしまう（ステイルブロック）リスクが軽減されます。 また、ブロックチェーンとUTXOセットの増加を抑制することができ、 これらはフルノードの立ち上げと維持にかかるコストに直接貢献します。

このように、未承認トランザクションのキャッシュとしての役割の他に、 mempoolはブロックスペースの公開オークションを促進します。 正常に機能している場合、オークションは自由市場の原則に従います。 つまり、優先順位はマイナーとの関係でははなく、純粋に手数料に基づきます。

ブロックのトランザクションを選択する際に手数料を最大化することは（総weightと署名操作の数の制限あり）、 NP困難な問題です。 この問題は、トランザクションの関係性によってさらに複雑になります。 高手数料率のトランザクションをマイニングするには、その低手数料率の親をマイニングする必要があるかもしれません。 別の言い方をすると、低手数料率のトランザクションをマイニングすることで、 高手数料率のその子をマイニングする機会が生まれるかもしれません。

Bitcoin Coreのmempoolは、各エントリとその祖先の手数料率を計算し（祖先手数料率 と呼ばれる）、 その結果をキャッシュし、貪欲ブロックテンプレート構築アルゴリズムを使用します。 mempoolを 祖先スコア （祖先手数料率と個別手数料率の最小値）順にソートし、 その順番で祖先パッケージを選択し、残りのトランザクションの祖先手数料とweight情報を随時更新していきます。 このアルゴリズムは、性能と収益性のバランスを取るものであり、必ずしも最適な結果が得られるとは限りません。 その有効性は、トランザクションと祖先パッケージのサイズを制限することで向上させることができます。 Bitcoin Coreでは、その制限がそれぞれ400,000 weightと404,000 weightに設定されています。

同様に、高手数料率の子を持つ低手数料率のトランザクションを退去させるのは不利になるため、 mempoolから退去させるパッケージを選択する際に使用される 子孫スコア が計算されます。

mempoolの検証では、同じインプットを使用するトランザクション（つまり二重支払いや、競合するトランザクション）を処理する際も、 手数料と手数料率が使用されます。ノードは最初に確認したトランザクションを常に保持するのではなく、 一連のルールを使用して、どのトランザクションを保持するインセンティブがより高いかを決定します。 この動作はReplace by Feeとして知られています。

マイナーが手数料を最大化するのは直感的に理解できますが、 なぜマイニングを行わないノードのオペレーターがこのようなポリシーを実行しなければならないのでしょうか？ 先週の記事で説明したように、マイニングを行わないノードのmempoolの効用は、 マイナーのmempoolとの類似性に直接関係しています。 そのため、ノードオペレーターがmempoolの内容を使ってブロックを生成するつもりがなくても、 最もインセンティブに適合したトランザクションを維持することに関心があります。

トランザクションに手数料の支払いを要求するコンセンサスルールはありませんが、 手数料と手数料率は、ブロックスペースをめぐる競争を解決するための「公平な」方法として、 Bitcoinネットワークで重要な役割を果たしています。 マイナーは手数料率を使用して、受け入れ、退去および競合を評価し、 マイニングを行わないノードは、自分のmempoolの効用を最大化するためにその動作を反映します。

ブロックスペースの希少性は、トランザクションのサイズに低下圧力をかけ、 開発者がトランザクションをより効率的に構築するよう促します。 来週の記事では、オンチェーントランザクションの手数料を最小化するための実践的な戦略と技術を探ります。

ブロックスペースの入札

ニュースレター #253に掲載

先週、トランザクションは送金した額ではなく使用するブロックスペースに対して手数料を支払うと述べ、 マイナーは収集できる手数料を最大化するためにトランザクションの選択を最適化することを確認しました。 その結果、ブロックが見つかったときにmempoolの最上位に存在するトランザクションのみが承認されることになります。 この記事では、手数料を最大限に活用するための実践的な戦略について説明します。 手数料率の見積もりの適切な情報源があると仮定します。手数料率の見積もりについては、来週の記事で詳しく説明します。

トランザクションを構築する際、トランザクションのいくつかの部分は、他の部分よりも柔軟性があります。 すべてのトランザクションにはヘッダーフィールドが必要で、受信者のアウトプットは行われる支払いによって決まり、 ほとんどのトランザクションにはお釣りのアウトプットが必要です。 送信者と受信者の両方が、将来のトランザクションアウトプットの支払いコストを削減するために、 ブロックスペース効率の良いアウトプットタイプを優先すべきですが、 トランザクションの最終構成とweightを変更する余地が最も大きいのは、 インプットの選択時です。 トランザクションは、手数料率[fee/weight]で競争するため、 軽いトランザクションは同じ手数料率に達するのにより低い手数料ですみます。

Bitcoin Coreウォレットなど一部のウォレトは、お釣りのアウトプットが必要ないように、 インプットを組み合わせようとします。お釣りを避けることは、 現在のアウトプットのweightを節約するだけでなく、後でお釣りのアウトプットを使用するという将来のコストも削減します。 しかし、ウォレットがさまざまな額を持つ大きなUTXOプールを持っていない限り、 このようなインプットの組み合わせはめったにありません。

最新のアウトプットタイプは、古いアウトプットタイプよりもブロックスペース効率が高くなっています。 たとえば、P2TRインプットを使用すると、P2PKHインプットの2/5以下のweightしか発生しません。 （トランザクションサイズ計算ツールで試してみてください） マルチシグウォレットの場合、最近完成したMuSig2方式やFROSTプロトコルによって、 マルチシグ機能をシングルシグインプットのように見えるものにエンコードすることができ、 大幅なコスト削減が可能になります。特にブロックスペースの需要が急増した時には、 最新のアウトプットタイプを使用するウォレットは、それだけで大きなコスト削減につながります。

Overview of input and output weights

スマートウォレットは、手数料率に応じて選択の戦略を変更します。 手数料率が高い場合は、インプットのセットのweightをできるだけ小さくするために、 少ないインプットと最新のインプットタイプを使用します。 常に最も軽いインプットのセットを選択することで、現在のトランザクションのコストを局所的に最小化することができますが、 同時にウォレットのUTXOプールを小さな断片にすることになります。 このため、ユーザーはその後、高い手数料率で巨大なインプットのセットを持つトランザクションを作ることになります。 したがって、ウォレットが低手数料率でより多くの重いインプットを選択し、 その後のブロックスペース需要の急増を見越して、 より少ない最新のアウトプットに資金を集約することは先見の明があると言えます。

大量の支払いをするウォレットは、1回あたりの支払いのトランザクションweightを減らすために、 複数の支払いを1つのトランザクションにまとめることがよくあります。 支払い毎にヘッダーバイトとお釣り用のアウトプットのオーバーヘッドを負担するのではなく、 すべての支払いで共有されるオーバーヘッドコストだけを負担します。 いくつかの支払いをまとめるだけでも、支払い毎のコストはすぐに削減されます。

Savings from payment batching with P2WPKH

しかし、多くのウォレットが過払いな手数料率を推定しているにもかかわらず、 ブロックが遅くなったり、トランザクションの送信が急増すると、 トランザクションが予定よりも長く未承認のままになることがあります。 このような場合、送信者または受信者のどちらかがトランザクションの優先順位を変更したいと思うかもしれません。

一般に、ユーザーは自分のトランザクションの優先順位を上げるために、 CPFP（Child Pays For Parent）とRBF（Replace By Fee）の2つのツールを使うことができます。 CPFPでは、ユーザーは自分のトランザクションのアウトプットを使用して、高手数料率の子トランザクションを作成します。 先週の記事で説明したように、マイナーには手数料の高い子を含めるために親をブロックに含めるインセンティブがあります。 CPFPはトランザクションによて支払いを受けるユーザーなら誰でも利用できるため、 受信者または送信者（お釣り用のアウトプットを作成した場合）のどちらでも利用できます。

RBFでは、送信者は元のトランザクションより高い手数料率の置換トランザクションを作成します。 置換トランザクションは、元のトランザクションとの競合を確実にするため、 元のトランザクションから少なくとも１つのインプットを再利用しなければならず、 2つのトランザクションの内、1つだけがブロックチェーンに含まれます。 通常、この置換には元のトランザクションの支払いが含まれますが、 送信者は置換トランザクションの資金をリダイレクトしたり、 複数のトランザクションの支払いを置換トランザクションに統合したりすることもできます。 先週の記事で説明したように、ノードは元のトランザクションを退去させ、 よりインセンティブの高い置換トランザクションを採用します。

ブロックスペースの需要と生産は、どちらも私たちのコントロールが及ばないものですが、 ウォレットがブロックスペースを効果的に競り落とすために使えるテクニックはたくさんあります。 ウォレットは、お釣り用のアウトプットを排除したり、ネイティブsegwitアウトプット使用したり、 低手数料率の環境でUTXOプールをデフラグしたりすることで、より軽いトランザクションを作成して手数料を節約できます。 CPFPとRBFをサポートするウォレットは、控えめな手数料率から始めて、 必要に応じてCPFPまたはRBFを使ってトランザクションの優先順位を更新することもできます。

手数料率の推定

ニュースレター #254に掲載

先週は、手数料率を考慮したトランザクションで支払われる手数料を最小限に抑えるための手法を紹介しました。 しかし、その手数料率はどうあるべきなのでしょうか？理想的には、お金を節約するためにできるだけ低く、 ユーザーの時間的な優先順位に応じたブロックのスポットを確保するのに十分な額であることです。

手数料（率）推定 の目標は、承認のための目標時間枠を、 トランザクションが支払うべき最小手数料率に変換することです。

手数料の推定を複雑にする１つは、ブロックスペースの生産が不規則であることです。 たとえば、ユーザーが１時間以内に販売者に支払いを行う必要があるとします。 この場合、ユーザーは10分毎にブロックがマイニングされることを期待しているため、 次の6ブロック以内のスポットを狙うでしょう。しかし、1つのブロックがマイニングされるのに 45分かかることも十分あり得ます。手数料の推定では、ユーザーが希望する緊急性や時間枠 （「仕事終わりまでに承認してほしい」など）と、ブロックスペースの供給量（ブロック数）を調整する必要があります。 多くの手数料推定は、時間に加えてブロック数で承認目標を表すことで、この課題に対処しています。

承認前ののトランザクションに関する情報がない場合は、 どのような手数料率のトランザクションがブロックに入る傾向があるかについて過去のデータを使用する単純な手数料推定を構築できます。 この推定ツールは、mempoolで承認を待っているトランザクションを認識しないため、 ブロックスペース需要の予期せぬ変動や、時折発生する長めのブロック間隔に対して非常に不正確になります。 もう１つの弱点は、マイナーが完全に管理する情報に依存していることです。 マイナーは、ブロックに偽の高手数料率のトランザクションを含めることで、手数料率を上げることができます。

幸いなことに、ブロックスペースの市場はブラインドオークションではありません。 最初の記事で、mempoolを保持し、ピアーツーピアのトランザクションリレーネットワークに参加することで、 ノードがユーザーの入札を確認することができることを紹介しました。 Bitcoin Coreの手数料推定ツールも、履歴データを使用して、 nブロック以内に手数料率fでトランザクションが承認される確率を計算しますが、 特にノードが最初にトランザクションを発見した高さと承認された高さを追跡します。 この方法は、公開手数料市場の外で発生する活動を無視することで機能します。 マイナーが人為的に高い手数料率のトランザクションを自分のブロックに含めても、 承認される前に公にリレーされたトランザクションのデータのみを使用するため、 この手数料推定ツールが歪められることはありません。

また、トランザクションがブロックに選択される方法についての洞察もあります。 以前の記事で、ノードはインセンティブに適合するトランザクションを自分のmempoolに保持するために、 マイナーのポリシーをエミュレートすることを紹介しました。 このアイディアを発展させると、過去のデータだけを見るのではなく、 マイナーが行うであることをシミュレートする手数料推定ツールを構築することができます。 次のnブロック以内にトランザクションを承認するために必要な手数料率を見つけるために、 手数料推定ツールは、ブロック構築アルゴリズムを使用して、 mempoolから次のn個のブロックテンプレートを予測し、 ブロックnに入る最後のトランザクションに勝つ手数料率を計算することができます。

明らかに、この手数料推定ツールのアプローチの有効性は、 自分のmempoolのコンテンツとマイナーのコンテンツの類似性に依存し、これは決して保証されるものではありません。 また、承認のために帯域外で手数料を支払うトランザクションなど、 マイナーが外的な動機によって含める可能性のあるトランザクションも認識できません。 また予測では、現時点から予測されたブロックが見つかるまでの間に ブロードキャストされた追加のトランザクションも考慮する必要があります。 他のトランザクションを考慮し、予測されるブロックのサイズを減らすことでこれを実現できますが、 どれくらいでしょうか？

この質問は、履歴データの有用性を再び浮き彫りにします。 高度なモデルであれば、活動のパターンを組み込んで、典型的な営業時間や、 企業でスケージュールされたUTXOの統合、Bitcoinの取引価格の変化に応じた活動など、 手数料率に影響を与える外部イベントを考慮することができるかもしれません。 ブロックスペースの需要予測という問題は、まだ探求の余地があり、常にイノベーションの余地があると思われます。

手数料推定は多面的で難しい問題です。悪い手数料推定は、 手数料を過剰に支払うことで資金を浪費し、支払いにBitcoinを使用することに摩擦をもたらし、 別の使用条件を持つタイムロックされたUTXOがある期間を逃すことでL2ユーザーが損失を被る可能性があります。 良い手数料推定は、ユーザーがマイナーにトランザクションの緊急度を明確かつ正確に伝えることを可能にし、 CPFPやRBFにより、初期の見積もりが甘かった場合に入札の更新を可能にします。 インセンティブに適合するmempoolポリシーと、よく設計された手数料推定ツールとウォレットを組み合わせることで、 ユーザーはブロックスペースの効率的な公開オークションに参加することができます。

手数料推定ツールは、時間軸がどれくらい長くても、承認待ちのトランザクションがどれくらい少なくても、 通常1sat/vBを下回る値を返すことはありません。 多くの人が1sat/vBをBitcoinネットワークの事実上の下限手数料率と考えています。 これは、（マイナーを含む）ネットワーク上のほとんどのノードが、 mempoolがどれだけ空いていても、この手数料率以下のものを決して受け入れないという 事実があるためです。来週の記事では、このノードポリシーと、 トランザクションリレーで手数料率を利用するもう1つの動機であるリソースの枯渇からの保護について説明する予定です。

ノードリソースの保護に関するポリシー

ニュースレター #255に掲載

私たちは、Bitcoinのプライバシーと検閲耐性の多くはネットワークの分散化された性質に起因していると述べて、 このシリーズを始めました。ユーザーが自分のノードを実行することで、 障害、監視、検閲の中心点を削減することができます。そのため、 Bitcoinノードソフトウェアの主な設計目標の１つは、ノードを実行するための高いアクセシビリティです。 各Bitcoinユーザーに、高価なハードウェアを購入したり、特定のオペレーティングシステムを使用したり、 また運用コストとして毎月数百ドルを費やすことを要求すると、ネットワーク上のノード数が減少する可能性が非常に高くなります。

さらに、Bitcoinネットワーク上のノードは、未知のエンティティへのインターネット接続を持つコンピュータであり、 ノードがメモリ不足に陥りクラッシュするようなメッセージを作成したり、 新しいブロックを受け入れるために意味のないデータに計算リソースや帯域幅を費やしたりすることで、 サービス拒否（DoS）攻撃を行う可能性があります。 これらのエンティティは設計上匿名であるため、ノードは接続前にそのピアが正直か悪意があるかを事前に判断することはできず、 攻撃が観測された後でも効果的に禁止することができません。したがって、 DoSから保護し、フルノードの実行コストを制限するポリシーを実装することは、単なる理想ではなく、必須なことです。

リソースの枯渇を防ぐために一般的なDoS保護がノードの実装に組み込まれています。 たとえば、Bitcoin Coreノードが１つのピアから多くのメッセージを受信した場合、 最初の１つだけを処理し、残りは他のピアのメッセージの後に処理されるようにワークキューに追加されます。 また、ノードは通常、ブロックをダウンロードして検証する前に、まずブロックヘッダーを最初にダウンロードし、 そのProof of Work（PoW）を検証します。したがって、ブロックリレーによってノードのリソースを枯渇させようとする攻撃者は、 まず有効なPoWを計算するために不釣り合いなほど膨大なリソースを費やす必要があります。 PoWの計算にかかる膨大なコストと検証にかかる些細なコストの非対称性により、 ブロックリレーにDoS耐性を組み込む自然な方法が提供されます。 この特性は、未承認 トランザクションのリレーには適用されません。

一般的なDoS保護では、ノードのコンセンサスエンジンがピアツーピアネットワークからの入力にさらされることを許容するだけの 十分な攻撃耐性を提供しません。最大限の計算量を必要とするコンセンサスが有効なトランザクションを作ろうとする攻撃者は、 #364292 ブロックにあった1MBの“メガトランザクション”のようなものを送信するかもしれません。 このトランザクションは、署名検証と二乗的なsighash計算によって検証に異常に長い時間を要しました。 攻撃者は、最後の署名以外はすべて有効な署名を作成し、ノードにトランザクションの検証に数分をかけさせ、 最後にそれがゴミであることがわかるようなものを作ることもできます。 その間、ノードは新しいブロックの処理を遅らせます。この種の攻撃は、 次のブロックで先手を打つために、競合するマイナーを標的にしていると想像できます。

非常に計算量の多いトランザクションの作業を回避するために、 Bitcoin Coreノードは、各トランザクションに対して、最大標準サイズと 最大署名操作数（または「sigops」）を課し、ブロックのコンセンサス制限よりも厳しく制限しています。 また、Bitcoin Coreノードは、祖先と子孫の両方のパッケージサイズに制限をかけることで、 ブロックテンプレートの作成と退去のアルゴリズムをより効果的にし、 トランザクションの祖先と子孫のセットを更新する必要があるmempoolの挿入と削除の 計算量を制限しています。 これは、一部の正当なトランザクションが受理またはリレーされないことを意味しますが、 そのようなトランザクションは稀であることが予想されます。

これらは トランザクションリレーポリシー の例で、 ノードが未承認トランザクションに適用する、コンセンサスに加えて行う一連の検証ルールです。

デフォルトでは、Bitcoin Coreノードは、1sat/vBの最小リレー手数料率（「minrelaytxfee」）を 下回るトランザクションを受け入れず、この要件を受け入れる前にいかなる署名も検証せず、 自分のmempoolに受け入れられない限りトランザクションをリレーしません。 ある意味、この手数料率ルールは、ネットワークの検証とリレーの最小「価格」を設定します。 マイニングを行わないノードは手数料を受け取ることはなく、 手数料はトランザクションを承認したマイナーにのみ支払われれます。 手数料が確認されるまでにネットワーク帯域幅の一部は既に使用されていますが、手数料は攻撃者にとってのコストになります。 検証とリレーを必要とするトランザクションを極端に多く送信する人は、やがて手数料を支払うお金がなくなります。

Bitcoin Coreに実装されているReplace by Feeポリシーは、 置換トランザクションは直接競合する各トランザクションよりも高い手数料率を支払う必要があり、 置き換えられるすべてのトランザクションよりも高い総手数料を支払う必要があります。 追加の手数料を置換トランザクションの仮想サイズで割った値は、少なくとも1sat/vBでなければなりません。 言い換えれば、元のトランザクションと置換トランザクションの手数料率に関係なく、 新しいトランザクションは1sat/vBで独自の帯域幅のコストをカバーするために「新しい」手数料を支払わなければなりません。 この手数料ポリシーは、インセンティブの互換性に主眼を置いたものではありません。 むしろ、これにより、帯域幅を浪費する攻撃を抑制するために、 トランザクションを繰り返し置換する最小限のコストを発生させます （たとえば、置換の度に1 satoshiだけ追加するようなもの）。

ブロックとトランザクションを完全に検証するノードは、メモリや計算リソース、ネットワーク帯域幅を含むリソースを必要とします。 ノードの実行を容易にし、ノードを攻撃から守るためには、必要なリソースを低く抑える必要があります。 一般的なDoS保護だけでは不十分なため、ノードは未承認トランザクションを検証する際に、 コンセンサスルールに加えてトランザクションリレーポリシーを適用します。 しかし、ポリシーはコンセンサスではないため、2つのノードが異なるポリシーを持っていても、 現在のチェーンの状態について合意することは可能です。来週の記事では、個人の選択としてのポリシーについて説明します。

ポリシーの一貫性

ニュースレター #256に掲載

先週の記事では、コンセンサスルールに加えて適用されるトランザクションの検証ルールのセットである ポリシーについて紹介しました。これらのルールは、ブロック内のトランザクションには適用されないため、 ノードのポリシーがピアと異なっていても、コンセンサスを維持することができます。 ノードオペレーターがトランザクションリレーに参加しないことを選択できるように、 どのようなポリシーを選択するかも自由で、全く選択しない（ノードがDoSのリスクにさらされる）ことも可能です。 つまり、ネットワーク全体でmempoolポリシーが完全に同一であるとは仮定できません。 しかし、ユーザーのトランザクションがマイナーに受信されるためには、 すべてのノードがそのトランザクションを自身のmempoolに受け入れる経路を通過する必要があり、 ノード間のポリシーの不一致はトランザクションリレーの機能に直接影響します。

ノード間のポリシーの違いの極端な例として、各ノードオペレーターがランダムなnVersionを選択し、 そのnVersionのトランザクションのみを受け入れるという状況を想像してみてください。 ほとんどのピアツーピアの関係は互換性のないポリシーを持つことになるので、 トランザクションはマイナーまで伝播しません。

一方、ネットワーク全体で同一のポリシーがあれば、mempoolの内容を収束させることができます。 mempoolが一致するネットワークは、トランザクションを最もスムーズにリレーし、 これまでの記事で説明したように、手数料の推定やコンパクトブロックリレーにも最適です。

mempoolの検証の複雑さとポリシーの不一致から生じる困難を考慮し、 Bitcoin Coreは歴史的にポリシーの設定可能性に関して保守的でした。 ユーザーは、sigopsのカウント方法（bytespersigop）を簡単に微調整したり、 OP_RETURNアウトプットに埋め込めるデータ量を制限したり（datacarriersizeおよびdatacarrier）できる一方で、 ソースコードを変更することなく、400,000 weight-unitの最大標準weightをオプトアウトしたり、 手数料関連のRBFルールに異なるセットを適用したりすることはできません。

Bitcoin Coreのポリシー設定オプションの中には、ノードの動作環境の違いや、 運用目的の違いに対応するためのものが存在します。たとえば、 マイナーのハードウェアリソースやmempoolを維持する目的は、 ラップトップやRaspberry Piで軽量ノードを実行する日常的なユーザーとは異なります。 マイナーはmempoolの容量（maxmempool）や有効期限のタイムライン（mempoolexpiry）を増やして トラフィックピーク時の低手数料率のトランザクションを保存し、 トラフィックが落ち着いたときにそれらをマイニングするかもしれません。 可視化やアーカイブ、ネットワーク統計を提供するウェブサイトでは、 できるだけ多くのデータを収集するために複数のノードを実行し、 デフォルトのmempoolの動作を表示することもあります。

個々のノードでは、mempoolの容量の選択が手数料引き上げツールの可用性に影響します。 デフォルトのmempoolサイズを超えるトランザクションの送信により、 mempoolの最小手数料率が上昇すると、mempoolの「底」からパージされたトランザクションと、 この手数料率を下回る新しいトランザクションは、CPFPを使って手数料を引き上げられなくなります。

一方、パージされたトランザクションによって使用されていたインプットは、 mempool内のどのトランザクションも使用していないので、 以前はできなかった RBFによる手数料の引き上げが可能になるかもしれません。 新しいトランザクションは、ノードのmempool内の何かを実際に置き換えているわけではないので、 通常のRBFルールを考慮する必要はありません。しかし、（より大きなmempool容量を持つため） 元のトランザクションをパージしていないノードは、新しいトランザクションを提案された置換トランザクションとして扱い、 RBFルールへの準拠を要求します。パージされたトランザクションがBIP125の置換可能性をシグナルしていなかったり、 新しいトランザクションの手数料が高い手数料率にも関わらずRBFの要件を満たしていない場合、 マイナーはその新しいトランザクションを受け入れない可能性があります。 ウォレットはパージされたトランザクションを注意深く扱う必要があります。 トランザクションのアウトプットは使用可能とは見なせませんが、インプットは同様に再利用することはできません。

一見すると、より大きなmempool容量を持つノードは、CPFPの有用性が高くRBFの有用性が低いように見えるかもしれません。 しかし、トランザクションのリレーは、ネットワークの創発的な挙動に左右され、 ユーザーからマイナーまでCPFPを受け入れるノードの経路が存在しないかもしれません。 ノードは通常、トランザクションをmempoolに受け入れた時に一度だけそれをリレーし、 自分のmempoolに既に存在するトランザクションの通知を無視します。 より多くのトランザクションを格納するノードは、それらのトランザクションが再度ブロードキャストされたときに ブラックホールとして機能します。 ネットワーク全体がmempoolの容量を増やさない限り（デフォルト値を変更する変調）、 自分自身のmempoolの容量を増やすことで利益を得ることはほとんど期待できないでしょう。 デフォルトのmempoolの最小手数料率は、トラフィックピーク時にCPFPを使用することの有用性を制限しています。 サイズを拡大した自分のmempoolにCPFPトランザクションを送信できたユーザーは、 そのトランザクションが他の誰にも伝播していないことに気づかないかもしれません。

トランザクションリレーネットワークは、ネットワークに動的に参加および離脱する個々のノードで構成されており、 それぞれが悪用から身を守る必要があります。そのため、トランザクションリレーはベストエフォート型でしかなく、 すべてのノードがすべての未承認トランザクションを学習することを保証することはできません。 同時に、Bitcoinネットワークは、mempoolを可能な限り均質にするトランザクションリレーポリシーの1セットに収束すれば、 最高のパフォーマンスを発揮します。次の記事では、ネットワーク全体の利益に適合するために、 どのようなポリシーが採用されているかを探ります。

ネットワークリソース

ニュースレター #257に掲載

前回の記事では、ノードリソースの保護について説明しました。 ノードリソースはノード毎に固有であり、設定可能な場合もあります。 また、1つポリシーに収束することが最善である理由についても説明しましたが、 そのポリシーの一部として何が含まれるべきでしょうか？ この記事では、スケーラビリティ、アップグレード性、ブートストラップやフルノードの維持のし易さなどにとって重要な、 ネットワーク全体のリソースの概念について説明します。

以前の記事で説明したように、Bitcoinネットワークの思想的目標の多くは、 その分散構造に具現化されています。Bitcoinのピア・ツー・ピアの性質により、 ネットワークのルールは個々のノードオペレーターの選択の大まかな合意から生まれ、 ネットワーク内で不当な影響力を獲得しようとする試みを抑制します。 これらのルールは、すべてのトランザクションを個別に検証する各ノードによって適用されます。 多様で健全なノード群を実現するには、ノードの運用コストを低く抑える必要があります。 世界中のユーザーを対象にプロジェクトを拡大するのは困難ですが、 分散化を犠牲にすることなくそれを行うことは、片手を背中に縛られて戦うようなものです。 Bitcoinプロジェクトは、共有ネットワークのリソース、つまりUTXOセットや、 ブロックチェーンのデータフットプリントとその処理に必要な計算量、 Bitcoinプロトコルを進化させるためのフックのアップグレードを厳重に保護することで、 このバランスをとろうとしています。

ブロックチェーンの成長に制限を設けることが自分自身のノードを運営するために手頃な価格を維持するのに必要であることを理解するために、 再度ブロックサイズ戦争を繰り返す必要はありません。ただし、ブロックチェーンの成長は、 「高度に複製された永久的なストレージに対する無制限の需要」の一部を表現するために必要な最小コストを確保する 1 sat/vbyteのminRelayTxFeeによってポリシーレベルでも抑制されています。

当初、ネットワークの状態は、未使用のアウトプットをまだ持つすべてのトランザクションを保持することで追跡されていました。 ブロックチェーンのこのより大きな部分は、資金を追跡する手段としてUTXOセットの導入により大幅に削減されました。 それ以来、UTXOセットは中心的なデータ構造となっています。特にIBD中だけでなく一般的にも、 UTXOのルックアップは、ノードのすべてのメモリアクセスの大部分を占めています。 Bitcoin Coreは、既にUTXOキャッシュ用に手動で最適化されたデータ構造を使用していますが、 UTXOセットのサイズはノードのキャッシュに収まらない量を決定します。 UTXOセットが大きいほどキャッシュミスが多くなり、ブロックの検証やIBD、トランザクションの検証速度が遅くなります。 ダスト・リミットは、UTXOの作成を制限するポリシーの例であり、 具体的には、その額が支払いに必要なコストを下回るため、 決して使用されない可能性のあるUTXOを抑制します。それでも、 数千件のトランザクションを伴う「ダスト・ストーム」は2020年にも発生しました。

データをブロックチェーン上に公開するためにベア・マルチシグアウトプットを使用するのが一般的になったとき、 標準トランザクションの定義が修正され、代わりに単一のOP_RETURNアウトプットを許可するようになりました。 人々は、ユーザーがブロックチェーン上にデータを公開するのを防ぐことは不可能であることに気づきましたが、 少なくともそのようなデータは決して使用されないアウトプットで公開される場合、 UTXOセットに永久に存在する必要はありません。 Bitcoin Core 0.13.0では、ユーザーがベア・マルチシグアウトプットを含む未承認トランザクションを 拒否するように切り替えることができる起動オプション-permitbaremultisigが導入されました。

コンセンサスルールでは、アウトプットスクリプトを自由な形式にすることができますが、 Bitcoin Coreノードによってリレーされるのはわずかなパターンだけです。 これにより、検証コストやプロトコルアップグレードメカニズムなど、 ネットワーク内の多くの懸念を理解しやすくなります。 たとえば、opcodeを含むインプットスクリプトや、15個以上の署名を持つP2SHインプット、 witnessスタックに100を超える項目を持つP2WSHインプットは、非標準トランザクションになります。 （ポリシーの例やその動機については、このポリシーの概要をご覧ください。）

最後に、Bitcoinプロトコルは、活動中のソフトウェアプロジェクトであり、 将来の課題やユーザーのニーズに対応するために進化し続ける必要があります。 そのため、annexやTaprootのリーフバージョン、witnessバージョン、OP_SUCCESSおよび 多数のno-op opcodeなど、コンセンサスが有効であるにもかかわらず未使用のまま意図的に残された多数のアップグレードフックがあります。 ただし、攻撃が中央集権的な障害点の欠如によって妨げられるのと同様に、 ネットワーク全体のソフトウェアのアップグレードには、数万もの独立したノードオペレーターの協調した取り組みが必要です。 ノードは、その意味が定義されるまで、予約されたアップグレードフックを利用するトランザクションをリレーしません。 この抑制は、アプリケーションが矛盾する標準を独自に作成することを思いとどまらせることを目的としています。 これにより、あるアプリケーションの標準を、別のアプリケーションの標準を無効にすることなくコンセンサスに採用することは不可能になります。 また、コンセンサスの変更が発生した場合、すぐにアップグレードしないノード、 つまり新しいコンセンサスを知らないノードは、「騙されて」無効なトランザクションを自分のmempoolに受け入れることはできません。 積極的な抑制により、ノードの前方互換性が維持され、完全に同期したソフトウェアアップデートを必要とせずに、 ネットワークがコンセンサスルールを安全にアップグレードできるようになります。

ポリシーを使用して共有ネットワークリソースを保護することで、 ネットワークの特性を保護し、将来のプロトコル開発のための道を開いておくことができます。 一方、厳しく制限されたblockweightに対してネットワークを成長させる摩擦が、 ベストプラクティの採用、優れた技術設計、イノベーションの採用をどのように推進しているかが分かります。 来週の記事では、2ndレイヤープロトコルやスマートコントラクトシステムのインターフェースとしてのmempoolについて説明します。

インターフェースとしてのポリシー

ニュースレター #258に掲載

本連載ではこれまで、分散型トランザクションリレーの動機と課題を探り、 コンセンサスよりも厳しいトランザクション検証ルールのローカルおよび グローバルな必要性を示しました。 トランザクションリレーポリシーの変更は、アプリケーションのトランザクションがリレーされるかどうかに影響を与えるため、 検討する前に、より広範なBitcoinコミュニティとの交流が必要です。同様に、 トランザクションリレーを利用するアプリケーションやセカンドレイヤープロトコルは、 拒否されるトランザクションを作成しないように、ポリシールールを考慮して設計する必要があります。

オンチェーンでの強制力はトランザクションを迅速に承認できるかどうかに依存するため、 コントラクトプロトコルは優先順位付けに関連するポリシーにさらに密接に依存します。 敵対的な環境では、不正な取引相手はトランザクションの承認を遅らせることに関心を持っている可能性があるため、 トランザクションリレーポリシーのインターフェースの癖がユーザーに対してどのように利用されるかについても考えなければなりません。

ライトニングネットワークのトランザクションは、以前の記事で説明した標準ルールに従います。 たとえば、ピアツーピアプロトコルは、open_channelメッセージでdust_limit_satoshisを指定し、 ダストの閾値を指定します。ダストの閾値より低い金額のアウトプットを含むトランザクションは、 ノードのダスト制限によりリレーされないため、それらの支払いは「オンチェーンで強制力がない」と見なされ、 コミットメントトランザクションから削除されます。

コントラクトプロトコルは、多くの場合、タイムロックされた支払いパスを使用して、 各参加者にオンチェーンで公開されたステートに異議を唱える機会を与えます。 影響を受けるユーザーがその時間内にトランザクションを承認できなければ、資金の損失を被る可能性があります。 このため、手数料は承認の優先度を高めるための主要なメカニズムとして非常に重要ですが、同時により難しくもあります。 手数料率の推定は、トランザクションが後でいつブロードキャストされるかわからず、 ノードがシンクライアントとして動作することが多く、一部の手数料引き上げオプションが利用できないという事実により、複雑になります。 どちらの参加者も共有されたUTXOを一方的に使用することはできないため、 どちらかがオフラインになった場合、コミットメントトランザクションの手数料を引き上げる 置換トランザクションに署名することはできません。 代わりに、LNのコミットメントトランザクションには、 チャネル参加者がブロードキャスト時に手数料引き上げの子トランザクションをアタッチするための アンカーアウトプットを含めることができます。

しかし、この手数料の引き上げ方法にも制限があります。以前の記事で説明したように、 mempoolの最小手数料率がコミットメントトランザクションの手数料率よりも高くなると、 CPFPトランザクションを追加しても効果がないため、将来mempoolの最小手数料率が上昇した場合に備えて、 若干多めに見積もった手数料率で署名する必要があります。 さらに、アンカーアウトプットの開発には、一方の参加者が承認を遅らせることに関心を持っている可能性があるという事実に対する 多くの考慮事項が含まれていました。たとえば、一方の参加者（アリス）は、 オフラインになる前に自分のコミットメントトランザクションをネットワークにブロードキャストすることができます。 このコミットメントトランザクションの手数料率が即時承認されるには低すぎ、 アリスの取引相手（ボブ）が彼女のトランザクションを受け取っていない場合、 ボブは自分のコミットメントトランザクションをブロードキャストしても正常にリレーされないため、混乱するかもしれません。 各コミットメントトランザクションには、2つのアンカーアウトプットがあり、 どちらの参加者もコミットメントトランザクションをCPFPすることができます。 たとえば、ボブはアリスが以前コミットメントトランザクションをブロードキャストしているか確信を持てない場合でも、 アリスのコミットメントトランザクションのCPFPによる手数料の引き上げトランザクションを やみくもにブロードキャストしようとするかもしれません。 各アンカーアウトプットには、ダストの閾値を超える少額が割り当てられ、 UTXOセットの肥大化を防ぐために、しばらくすると誰でもそれを請求できるようになります。

しかし、各参加者がトランザクションをCPFPできることを保証することは、 各参加者にアンカーアウトプットを与えるよりも複雑です。 以前の記事で説明したように、Bitcoin Coreは DoS対策として未承認トランザクションにアタッチできる子孫トランザクションの数と合計サイズを制限しています。 各取引相手は、共有トランザクションに子孫をアタッチする能力を持っているため、 一方がこの制限を使い果たすことで、他方のCPFPトランザクションのリレーをブロックすることができます。 このような子孫の存在は、結果的にコミットメントトランザクションをmempool内で低優先度の状態に「固定」します。

この潜在的な攻撃を緩和するために、LNアンカーアウトプットの提案では、 すべてのアンカーアウト以外のアウトプットを相対的なタイムロックでロックし、 それらがトランザクションが未承認の間に使用されるのを防ぎます。 また、Bitcoin Coreの子孫制限ポリシーは、新しい子孫が小さく、他に祖先がない場合にのみ、 1つの追加の子孫を許可するよう変更されました（CPFP carve out）。 これら2つのプロトコルの変更の組み合わせにより、トランザクションリレーのDoS攻撃面を大幅に増加させることなく、 共有トランザクションの少なくとも2人の参加者がブロードキャスト時に手数料率の調整を行うことができるようになりました。

子孫制限の支配によるCPFPの防止は、Pinning攻撃の一例です。 Pinning攻撃は、mempoolポリシーの制限を利用して、インセンティブに適合するトランザクションが mempoolに入ったり承認されるのを阻止します。この場合、mempoolポリシーは、 DoS耐性とインセンティブ適合性の間のトレードオフを行っています。 ノードは手数料の引き上げを考慮すべきですが、無制限に多くの子孫を処理することはできません。 CPFP carve outは、特定のユースケースのためにこのトレードオフを洗練させています。

子孫制限を使い果たす以外にも、RBFの使用を完全に阻止したり、 RBFを法外に高価にしたり、RBFを活用してANYONECANPAYトランザクションの承認を遅らせたりするPinning攻撃があります。 Pinningが問題になるのは、複数の参加者が共同でトランザクションを作成するシナリオや、 信頼できない参加者がトランザクションとやりとりする余地がある場合のみです。 一般的に、信頼できない参加者へのトランザクションの露出を最小限に抑えることが、Pinningを回避する良い方法です。

これらの摩擦点は、Bitcoinエコシステムにおけるアプリケーションとプロトコルのインターフェースとしてポリシーの重要性だけでなく、 改善が必要な部分を浮き彫りにしています。来週の記事では、ポリシーの提案と未解決の問題について説明します。

ポリシーの提案

ニュースレター #259に掲載

先週の記事では、アンカーアウトプットと CPFP carve outについて説明しました。 これにより、どちらのチャネル参加者も、協力することなく共有されたコミットメントトランザクションの手数料を 引き上げることができます。このアプローチには、まだいくつかの欠点があります。 アンカーアウトプットを作成するためにチャネル資金が拘束され、 コミットメントトランザクションの手数料率は、mempoolの最小手数料率を満たすことを保証するために、 通常過大に支払われ、CPFP carve outでは追加の子孫は１つしか認められません。 アンカーアウトプットでは、Coinjoinやマルチパーティコントラクトプロトコルなど、 ２人よりも多い参加者間で共有されるトランザクションの手数料の引き上げを保証することはできません。 この記事では、これらの制限やその他の制限に対処するための現在の取り組みについて説明します。

パッケージリレーには、トランザクショングループの転送と検証を可能にする P2Pプロトコルとポリシーの変更が含まれています。 これは、コミットメントトランザクションがmempoolの最小手数料率を満たしていない場合でも、 子によるコミットメントトランザクションの手数料の引き上げを可能にします。 さらに、パッケージRBF は、子トランザクションによる 競合する親トランザクションの置換のための手数料の引き上げを可能にします。 パッケージリレーは、ベースプロトコルレイヤーにおける一般的な制限を取り除くように設計されています。 しかし、共有トランザクションの手数料の引き上げにおけるその有用性から、 特定のユースケースにおけるPinningを排除するための多くの取り組みも生まれています。 たとえば、パッケージRBFは、コミットメントトランザクションがそれぞれの手数料引き上げの子トランザクションと一緒にブロードキャストされる際に、 相互に置換できるため、各コミットメントトランザクションに複数のアンカーアウトプットは必要なくなります。

注意すべき点は、既存のRBFルールでは、置換トランザクションには、 置換されるすべてのトランザクションによって支払われる合計手数料よりも高い手数料を支払う必要があるという点です。 このルールは、置換の繰り返しによるDoSを防ぐのに役立ちますが、 悪意あるユーザーが、低手数料率であるものの手数料額は高い子トランザクションをアタッチすることで、 トランザクションを置換する際のコストを増加させることを可能にします。 これは、高手数料率パッケージによるトランザクションの置換を不当に阻止することで、 トランザクションがマイニングされるのを妨げるものであり、よく「ルール３Pinning」と呼ばれています。

開発者はまた、署名済みトランザクションに手数料を追加する全く異なる方法を提案しています。 たとえば、SIGHASH_ANYONECANPAY | SIGHASH_ALLを使用してトランザクションのインプットに署名することで、 トランザクションブロードキャスターは、アウトプットを変更することなく、トランザクションにインプットを追加して手数料を提供できます。 しかしながら、RBFには置換トランザクションがより高い「マイニングスコア」を持つこと（つまり、より速くブロックに選択される）を 要求するルールがないため、攻撃者は低手数料率の祖先に邪魔される置換トランザクションを作成することで、 この種のトランザクションをPinning可能です。 トランザクションおよびトランザクションパッケージのマイニングスコアの正確な評価を複雑にしているのは、 既存の祖先と子孫の制限が、この計算の計算量を制限するには不十分であることです。 接続されているトランザクションは、トランザクションがブロックに選択される順序に影響を与える可能性があります。 クラスター とよばれる完全に接続されたコンポーネントは、現在の祖先と子孫の制限があれば、 任意のサイズにすることができます。

一部のmempoolの欠陥とRBFのPinning攻撃に対処するための長期的な解決策は、 mempoolのデータ構造を再構築して、 祖先と子孫のセットだけでなくクラスターを追跡することです。これらのクラスターのサイズは制限されます。 クラスターの制限により、ユーザーが未承認のUTXOを使用できる方法が制限されますが、 祖先スコアベースのマイニングアルゴリズムを使用してmempool全体を線形化し、 ブロックテンプレートを極めて迅速に構築し、置換トランザクションのマイニングスコアが 置換されるトランザクションよりも高いという要件を追加することは可能になります。

それでも、トランザクションリレーの幅広いニーズと期待に応えるための単一のポリシーセットは存在しない可能性があります。 たとえば、バッチ処理された支払いは、多数の未承認の子孫を必要とするかもしれませんが、 これは総手数料を通じて共有トランザクションのパッケージRBFをPinningする余地を残します。 v3トランザクションリレーポリシーの提案は、 コントラクトプロトコルがより制限的なパッケージ制限のセットをオプトインできるようにするために開発されました。 v3トランザクションは、サイズ2（親1つ子1つ）のパッケージのみを許可し、子のweightを制限します。 これらの制限は、総手数料を通じたRBF Pinningを緩和し、 mempoolの再構築を必要とせずにクラスターmempoolのメリットの一部を提供します。

エフェメラルアンカーは、v3トランザクションとパッケージリレーの特性をベースに、 アンカーアウトプットをさらに改善するための提案です。これは、手数料ゼロのv3トランザクションに属するアンカーアウトプットが、 手数料を引き上げる子トランザクションによって使用される場合に限り、ダスト制限から免除されます。 手数料ゼロのトランザクションは、正確に1つの子トランザクションによって手数料を引き上げる必要があるため （そうしないと、マイナーはそれをブロックに含めるインセンティブを得られません）、 このアンカーアウトプットは「エフェメラル」であり、UTXOセットの一部にはなりません。 エフェメラルアンカーの提案により、チャネルクローズトランザクションの手数料供給メカニズムとして CPFPを使用したLN symmetryが実現可能になります。 また、このメカニズムは、3人以上の参加者で共有されるトランザクションにも利用可能です。 開発者は、bitcoin-inquisitionを使用してエフェメラルアンカーをデプロイし、 signet上でこれらのマルチレイヤーの変更を構築してテストするためのソフトフォークを提案しています。

この記事で強調されたPinningの問題は、昨年、メーリングリストやプルリクエスト、 ソーシャルメディア、直接の会議を通じてRBFポリシーを改善するための豊富な議論や提案を生み出しました。 開発者は、小さな修正から完全な刷新に至るまで、さまざまな解決策を提案し、実装しました。 -mempoolfullrbfオプションは、Pinningの懸念とBIP125実装の不一致に対処することを意図したもので、 トランザクションリレーポリシーにおけるコラボレーションの難しさと重要性を浮き彫りにしました。 1年前にbitcoin-devメーリングリストで会話を始めるなど、一般的な手段を使って コミュニティを巻き込もうとする真摯な努力がされましたが、 既存のコミュニケーションや意思決定の方法が意図した結果を生んでおらず、改善が必要であることは明らかでした。

非中央集権的な意思決定は困難なプロセスですが、Bitcoinのトランザクションリレーネットワークを利用する プロトコルやアプリケーションの多様なエコシステムをサポートするためには必要です。 来週は、このシリーズの最終回で、読者の皆さんにこのプロセスへの参加と改善を奨励していただきたいと考えています。

参加してみよう

ニュースレター #260に掲載

このシリーズが読者の皆様に、承認を待っている間に何が起こっているのかについて、 より良く理解する助けになっていれば幸いです。私たちは、Bitcoinのイデオロギー的な価値のいくつかが、 その構造や設計目標にどのように反映されているかという議論から始めました。 ピアツーピアネットワークの分散構造は、典型的な中央集権的モデルよりも、 検閲への耐性とプライバシーを高めています。オープンなトランザクションリレーネットワークは、 承認前にブロック内のトランザクションを誰もが知るのを助け、ブロックリレーの効率を向上させ、 新しくマイナーとして参加しやすくし、ブロックスペースの公開オークションを作り出します。 理想的なネットワークは、ノードを実行する多くの独立した匿名のエンティティで構成されるため、 ノードソフトウェアはDoSから保護し、一般的に運用コストを最小限に抑えるよう設計されなければなりません。

手数料は、ブロックスペースの競争を解決するための「公正な」方法として、Bitcoinネットワークで重要な役割を果たしています。 トランザクションの置換やパッケージに対応した選択および排除アルゴリズムを備えるmempoolでは、 トランザクションを保存する有用性を測定するためにインセンティブ互換性が使用され、 ユーザーに対してRBFやCPFPを使用した手数料の引き上げを可能にします。 このようなmempoolポリシーや、経済的にトランザクションを構成するウォレット、 そして優れた手数料の推定が組み合わさることで、 ブロックスペースの効率的な市場が形成され、すべての人に利益をもたらします。

また、個々のノードは、リソースの枯渇から自らを守り、 個人的な好みを表明するために、トランザクションリレーポリシー を適用します。 ネットワーク全体のレベルでは、標準ルールとその他のポリシーが、 スケーリングやノードの実行しやすさ、コンセンサスルールを更新する能力にとって重要なリソースを保護します。 ネットワークの大多数がこれらのポリシーを適用しているため、 BitcoinのアプリケーションやL2プロトコルが構築されるインターフェースの重要な部分でもあります。 そしてまた、完璧ではありません。私たちは、広範な制限やL2決済トランザクションに対するPinning攻撃など 特定のユースケースに対処する、いくつかのポリシー関連の提案について説明しました。

また、ネットワークポリシーの継続的な進化には、プロトコル、アプリケーション、 ウォレットに携わる開発者間の協力が必要であることも協調しました。 Bitcoinエコシステムがソフトウェア、ユースケース、ユーザーに関して成長するにつれて、 分散型の意思決定プロセスはより必要とされるようになりますが、同時により困難にもなります。 Bitcoinの普及が拡大しても、このシステムはステークホルダーの懸念や努力から生まれています。 顧客からのフィードバックを集め、新しいプロトコル機能を構築したり 使用されなくなった機能を削除したりするためのエンジニアを雇用する責任を負う企業はありません。 ネットワークのラフコンセンサスに参加したいステークホルダーには、 さまざまな参加方法があります。情報を提供したり、質問や問題を提起したり、 ネットワークの設計に参加したり、あるいは改善の実装に貢献したりすることです。 この次、あなたのトランザクションの承認に時間がかかっている場合は、何をすればいいか分かりますね！