Develop with pleasure!

福岡でCloudとかBlockchainとか。

ピアにトランザクションをリレーしないことを通知するdisabletxメッセージを定義したBIP-338

Bitcoin Coreはネットワークに接続すると8つアウトバウンドピアを選択するが、エクリプス攻撃などに対する堅牢性を高めるため、Bitcoin Core 0.19.0.1以降これにブロックリレーのみを行う2つのアウトバウンド接続(ブロックオンリーリレー)が追加されている。そのためアウトバウンド接続の合計数は10。

8つアウトバウンド接続ではこれまで通りトランザクションなど様々なP2Pメッセージを送信するが、このブロックオンリーリレーの2つのアウトバウンドピアにはブロックのリレーしかしない。そのため、これらの2つのピアに対して消費されるネットワーク帯域は他の接続に比べてとても低リソースになる。

このブロックオンリーリレーは、Bloom Filterを利用した軽量クライアントのプロトコルを定義したBIP-37↓

techmedia-think.hatenablog.com

で拡張された、ノード接続の開始時に交換するversionメッセージのfRelayフィールドをfalseにセットすることで実現している。ただ、これはもともと、軽量クライアントがフィルターをロードするまでの間に大量にinvトランザクションが通知されても困るので、それを停止させる目的で導入されたフィールドになる。このinvの停止はピアとの接続においてずっと保証されるものではなく、フィルター操作をするメッセージfilterloadfilteraddfilterclearが呼ばれると、停止していたinvが再開される。

この接続を受け入れたピアにとっても、途中からトランザクションが通知される可能性もあり、それがブロックオンリーリレーかどうか判断することができなくなってしまうので、今回新しくdisabletxというメセージを導入して、そのノードがトランザクションの通知をしないことを接続の初期化時に明示的に宣言できるようにしようというのがBIP-388の内容↓

https://github.com/bitcoin/bips/blob/master/bip-0338.mediawiki

基本的にdisabletxメッセージを送信した接続は、ブロックリレーのためのもので、Txに加えてaddr/getaddrメッセージなどを利用したアドレスのリレーをすることもなくなる。ただし、これらが送られてきたからといって、接続は切断することはないようになっている。このあたりは、このBIPを実装しないソフトウェアとの動作互換を保つためかな?またCompact Block(BIP-152)で必要なトランザクションを送受信することは可能になっている。

以下、BIPの意訳。

概要

このBIPでは、接続がトランザクションリレーに使用されないことをノードがピアに通知し、ネットワークで現在使用されているブロックオンリーリレーの接続をサポートするためのP2Pプロトコルの変更について説明する。

同期

この提案は、トランザクションをリレーするピアとリレーしないピアを区別することで、ピアがサービス可能なインバウンド接続数を増やすための取り組みの一環である。

2019年以降、Bitcoinネットワーク上の接続開始時にトランザクションリレーフィールド(BIP 37によって導入されBIP 60でも定義されている)をfalseに設定し、その接続においてトランザクションリレーが発生しないようにするソフトウェがデプロイされている*1。さらに、ピアからaddrメッセージを受信しても、このソフトウェアによって無視される。

この接続の目的は2つある。ブロックが伝播する低帯域幅の接続を追加することで、ネットワーク分断攻撃に対するノードの堅牢性が強化される。さらに、トランザクションをリレーせず、受信したアドレスを無視することで敵対者が完全なネットワークグラフ(もしくはサブグラフ)を学習する能力が低下するため*2、ネットワーク分断攻撃を実行しようとする敵対者にとっては(そのような知識を持っている場合に比べて)コストや難易度が高くなる。

この接続の低帯域幅/最小リソースの性質は、現在、接続の開始者のみが知っている。これはversionメッセージのトランザクションリレーフィールドが接続の存続期間中の永続的な設定ではないためだ。その結果、トランザクションリレーが無効になっているインバウンド接続を受信するノードは、トランザクションリレーを有効にしないピア(BIP 37で定義)と有効にするピアを区別できない。さらに、インバウンド接続がリレーされたアドレスを無視することも判断できない。その知識があれば、ノードは通知されたアドレスを代わりに受け取るために他のピアを選択する可能性がある。

この提案では、ノードがピアへの接続を開始する際に、接続が存続中はトランザクションリレーに使用されるべきではないことを示す新しいオプションメッセージを追加する。さらに接続において、アドレスをリレーすべきかどうかをネゴシエートする仕組みが現在ないため、このBIPではトランザクションリレーが無効化されたリンクにおいてはアドレスメッセージを送信しないよう提案する。

このBIPがデプロイされると、ノードは(disabletxを送信するような)低リソースノードとフルリレーピアを区別するインバウンド接続制限をより簡単に実装でき、ネットワーク上で可能なブロックオンリーリレーの接続数を増やすことができる。

仕様

  1. 新しくdisabletxメッセージが追加される。このメッセージはメッセージタイプがdisabletxの空のメッセージとして定義される。
  2. このBIPを実装するノードのプロトコルバージョンは70017以上に設定する必要がある。
  3. ノードがversionメッセージのトランザクションリレーフィールドをfalseにセットした場合、ピアのプロトコルバージョンが70017以上であれば、そのピアからversionメッセージに応答してdisabletxメッセージも送信される可能性がある。送信された場合、verackを送信する前にdisabletxメッセージを送信しなければならない。
  4. ピアとの間でdisabletxメッセージを送受信したノードは、以下のメッセージをピアに送信してはならない:
    1. トランザクションinvメッセージ
    2. トランザクションに対するgetdataメッセージ
    3. merkleblockに対するgetdataメッセージ(BIP 37)
    4. filteradd/filterload/filterclear(BIP 37)
    5. mempool(BIP 35)
    6. tx メッセージ
  5. ピアとの間でdisabletxメッセージを送受信したノードは、以下のメッセージをピアに送信しないことを推奨する:
    1. addr/getaddr
    2. addrv2(BIP 155)
  6. 他のメッセージタイプの送信または処理に関する動作は、このBIPでは指定されていない。
  7. ノードはこのメッセージを送るピアとの接続を維持しない可能がある(例えば、トランザクションをリレーするピアを見つける場合など)。

互換性

このBIPを実装していないプロトコルバージョン>= 70017のノードおよび、プロトコルバージョン< 70017のノードは、実装ソフトウェアとの互換性を維持する。トランザクションdisabletxメッセージを送信するピアにリレーされず(BIP 37もしくはBIP 60が実装されている場合)、定期的なアドレスのリレーは引き続き行われる可能性はあるが、このBIPを実装するソフトウェアは、その理由だけで、そのようなピアとの接続を切断すべきではない。

アドレスリレーのネゴシエーション方法をより慎重に指定する可能性のある将来のプロトコル拡張を可能にするたえ、アドレスリレーの無効化を提案するがこのBIPでは必須ではない。アドレスをリレーしないソフトウェアに関するこのBIPの推奨事項は、既存のソフトウェアの動作に対応するため、そのような将来のプロトコル拡張がない場合のガイダンスとして解釈されることを意図している。

blocktxnおよびgetblocktxnを含むBIP 152で定義されたすべてのメッセージは、BIP 152の機能ネゴシエーションに従って、disabletxメッセージを送受信したピア間で許可されていることに注意すること。

この提案はBIP 37と互換性があるが、独立している。

実装

https://github.com/bitcoin/bitcoin/pull/20726

*1:Bitcoin Coreは2019年11月にリリースされたバージョン0.19.0.1以降、この機能を実装している

*2:例えば、https://www.cs.umd.edu/projects/coinscope/coinscope.pdfhttps://arxiv.org/pdf/1812.00942.pdf を参照。