Erlay

通常の中継では、接続したノード同士が INV メッセージで32バイトの取引識別子を通知します。相手がその取引をすでに知っている場合も少なくありません。接続数が増えると通信量も増えますが、多様な接続はノードの孤立やネットワークの分断への耐性を高めます。 [1]

Erlay は一部の接続で素早い通知を維持します。ほかの接続では、まだ相手に通知していない取引の集合を二つのノードが定期的に照合します。完全なリストを送る代わりに、sketch と呼ぶコンパクトな数学的要約から差分を求めます。必要な P2P 拡張を定めているのが BIP 330 です。 [1]

接続ごとに別の集合を持ち、各ラウンドではその固定スナップショットを使います。双方が salt を提供します。これは wtxid から32ビットの短い識別子を導出するための補助入力です。PinSketch によって識別子の集合を照合できます。sendtxrcncl、reqrecon、sketch、reqsketchext、reconcildiff の各メッセージで対応状況を確認し、要約を交換して不足する通知を特定します。 [1]

差分が見つかった後も、ノードは完全な取引を要求し、自分のルールで検証します。Salt は短い識別子の衝突を事前に用意しにくくする補助値であり、パスワードでも取引の暗号化でもありません。要約の容量が足りなければ拡張を要求し、照合に失敗すれば通常の通知に戻ります。接続相手による資源の使い尽くしを防ぐため、実装には計算量とメモリの上限も必要です。 [1]

2026年10月の確認時点で、BIP 330 は Draft 状態で、原論文から修正された手順を記述していました。Bitcoin Core の議論 #34542 では通信量の削減、遅延、コードの複雑さを再検討していました。これだけで特定の Bitcoin Core が Erlay を使っているとは判断できません。その版のリリースノート、実装、双方のノードで確認された対応状況を調べる必要があります。 [4]

2019年の論文は、実験条件のもとで総通信量を約40%、取引通知の通信量を84%削減したと報告しています。シミュレーションと試作実装の結果であって、現在のあらゆるネットワークへの保証ではありません。次のラウンドを待つことで遅延が増える場合があります。取引を受信しても中継しないノードは、さらに伝播を遅らせ得ます。節約量と速さは一緒に測る必要があります。 [2]

Erlay は未承認取引の重複通知を減らします。一方、Compact Blocks は、ノードが大半をすでに知っている取引から新しいブロックを復元する際の通信量を減らします。両者は補完関係にありますが、どちらも単独ではノードのネットワーク上の識別情報を隠しません。それぞれに失敗時の処理と資源枯渇への対策が必要です。 [3]

まず BIP 330 の版と、ノードが実際に動かしているコードを確認します。対応状況の確認手順、短い識別子と salt の導出、各ラウンドの間隔、要約の上限、reqsketchext の動作を調べます。通常の通知への切り替えと、その後の完全な取引の検証も確認します。Erlay という名前だけでは、実際の節約量や遅延は分かりません。 [1]