メモリプールとトランザクション伝播

未承認取引はどこにいるのか

利用者が送金取引に署名してネットワークへ流すと、それは即座にブロックへ入るわけではありません。次のブロックが作られ、そこに取り込まれるまでの間、取引は未承認（unconfirmed） の状態で宙に浮きます。この宙に浮いた取引を各ノードが一時的に保持する待機列がメモリプール（mempool） です。

まず押さえるべき原理は、mempoolはグローバルに単一の実体ではないことです。世界のどこかに「正式な未承認取引の一覧」があるのではなく、各ノードがそれぞれ自分のmempoolを独立して持ちます。ある取引を受理したかどうか、いつ破棄したかはノードごとにばらつくため、任意の2ノードのmempoolは完全には一致しません。分散台帳（/blockchain/finality-fork-choice/ 参照）が「確定済みの過去」で合意を目指すのに対し、mempoolは「まだ合意されていない未来の候補」を各自が主観的に見ている層だ、と捉えると全体像が掴めます。

mempoolへの受理と検証

ノードは、隣接ピアから受け取った取引を無条件にmempoolへ入れるわけではありません。受理の前に一連の受け入れ検証（mempool acceptance） を通し、通ったものだけを保持し、さらに他ピアへ中継します。無検証で通すと、不正取引やスパムがそのまま網へ増幅拡散し、DoSの温床になるためです（/blockchain/p2p-gossip-network/ の「検証してから中継する」原則と同じ）。

ここで重要なのは、コンセンサス規則とポリシー規則は別物という区別です。コンセンサス規則（署名の正当性・二重支払い禁止）は破れば無効ブロックになる絶対条件で、全ノード共通です。一方、手数料下限や標準スクリプトの縛りは各ノードが任意に設ける中継ポリシーで、ノードによって設定が異なりえます。だからこそmempoolの中身はノード間でずれ、あるノードが弾いた取引を別のノードは中継する、ということが起こります。

ゴシップによる伝播

受理された取引は、ブロックと同じくゴシップ（epidemic）プロトコルで網全体へ広がります。素朴なフラッディング（受け取った物をそのまま全ピアへ再送）は同じ取引が何度も重複して届き帯域を浪費するため、まず「在庫の一覧」を広告し、相手が未所持の分だけを要求する在庫先行方式を採ります。

inv → getdata → 本体 の3ステップ（取引の伝播）
  1. ノードA: 取引を受理・mempoolへ追加 → 隣接ピアへ inv(txハッシュのみ) を送る
  2. ノードB: そのハッシュがmempool未所持なら → A へ getdata(ハッシュ) を返す
              既に持っていれば → 何も要求しない（重複本体の受信を回避）
  3. ノードA: getdata に応え、取引の本体を送る
  4. ノードB: 受け入れ検証 → 通ればmempoolへ追加し、さらに隣接ピアへ inv（連鎖）

この連鎖は感染症モデルと同型で、1ノードから始まった取引が各ホップで隣接ピアへ「感染」し、感染ノード数が指数的に増えて短時間で全網を覆います。ネットワーク直径が log(N) 程度のランダムメッシュなら、全網到達はおおむね log(N) ホップで完了します。伝播は速いものの瞬時ではなく、各ノードのmempoolに取引が現れるタイミングにはずれが生じます。

手数料による優先順位

ブロック空間は有限な希少資源です。1ブロックに入る取引の総サイズには上限があるため、mempoolに待機列が積み上がると、採掘者/検証者はどれを先に取り込むかを選ばねばなりません。合理的な採掘者は自分の報酬を最大化するので、手数料率の高い取引から優先的にブロックへ詰めます。

ここで効くのが「総額」ではなく手数料率である点です。ビットコインでは取引の重さをvByte（仮想バイト） で測り、優先度は 手数料 ÷ サイズ、すなわち sat/vB で決まります。同じ手数料総額でも、サイズが小さい取引のほうが率が高く、先に取り込まれます。ブロック容量が有限である以上、採掘者にとっての価値は「1バイトあたりいくら払うか」だからです。

手数料率で並べ替えてブロックを充填する（貪欲法の概略）:
  1. mempool内の取引を sat/vB（手数料率）の降順に並べる
  2. ブロックの残り容量に収まる限り、率の高い順に取り込む
  3. 親子取引は「まとめた率」で評価する（CPFP: 子が親を引き上げる）
  → 混雑時は率の低い取引がいつまでも取り込まれず滞留する

この結果、mempoolは事実上の手数料オークションとして機能します。混雑すると、取り込まれたい送信者は率を吊り上げて競り合い、「次のブロックに入る最低ライン」の率が上がっていきます。手数料が資源計量とスパム抑止を担う設計そのものについては/blockchain/tokenomics-incentives/ を参照してください。

置き換え（Replace-By-Fee）

一度送った未承認取引の手数料が低すぎて滞留したとき、CPFPのほかに取引そのものを差し替える手段があります。それがRBF（Replace-By-Fee） です。同じ入力（UTXO）を使う、より高手数料の新しい取引を送ると、ノードはmempool内の古い取引を破棄し、新しいほうで置き換えます。

RBFが成立する原理は、両者が同じ入力を消費する競合取引（コンフリクト） だという点にあります。同じUTXOは一度しか使えないため、片方しかブロックに入れません。採掘者は当然、手数料の高い置換版を選ぶので、置き換えは採掘者の利得と一致し、自然に受理されます。アカウントモデル（/blockchain/utxo-vs-account-model/）では入力の代わりに同一 nonce の再送が同じ役割を果たし、同じ送信者・同じ nonce で高いガス価格の取引が前のものを置き換えます。

無条件のRBFには二重支払いの懸念が伴います。加盟店が0-confで商品を渡した直後、送信者が同じ入力で「宛先を自分に変えた」高手数料の置換取引を流せば、元の支払いは無効化されうるからです。この危険こそ、ゼロ確認を最終扱いしてはならない直接の理由です。歴史的には「明示的にRBFを許可した取引だけ置き換え可能」とするフラグ方式（opt-in RBF）で、受取側が置き換えの可否を事前に判別できるようにしてきました。

リオーグ時の戻しとスパム対策

mempoolとブロックの間の出入りは一方通行ではありません。取引はブロックに取り込まれるとmempoolから外れますが、リオーグ（チェーン再編成） が起きると逆向きの動きが発生します。それまで正典だった枝が、より重い別の枝に置き換わると、破棄される枝に含まれていた取引の一部は新しい枝に入っていないことがあります。ノードはこれらをmempoolへ戻し（re-add）、再び未承認の待機列に載せて次のブロックを待たせます。

リオーグ時のmempoolの動き:
  1. 新しい最重鎖を検知 → 旧枝を分岐点まで巻き戻す
  2. 旧枝のブロックに含まれた取引を取り出す
  3. 新枝に既に含まれる／新枝の状態と競合する取引は捨てる
  4. それ以外の有効な取引をmempoolへ戻し、再び承認待ちにする

この戻しがあるため、浅いリオーグでも「一度承認された」ように見えた取引が未承認へ逆戻りしうる、というのが確率的ファイナリティの現実です（/blockchain/finality-fork-choice/）。

最後にスパム対策です。手数料下限を設けても、mempoolは開かれた受け皿である以上、資源を食い潰そうとする攻撃に晒されます。ノードは複数の防御を重ねます。

いずれの対策も根底の発想は同じで、mempoolに載せる操作へコストを結び付けることです。無料であれば無限に送りつけられますが、最低手数料率・追い出し・置き換えの追加コストを課せば、攻撃者はスパム量に比例した経済的負担を負います。mempoolのスパム耐性は、暗号や合意ではなく、この手数料という経済的な計量で支えられているわけです。

まとめ

• 未承認取引は各ノードのmempoolに滞留する。mempoolはグローバルに単一ではなくノードごとに独立した揮発的な待機列で、中継ポリシーの違いから中身は完全一致しない。
• ノードは受け入れ検証（署名・二重支払い・手数料下限・依存・ポリシー）を通した取引だけを保持・中継し、伝播は inv→getdata→本体 のゴシップで指数的に広がる。コンセンサス規則とポリシー規則は別物。
• 採掘者は手数料率（sat/vB） の高い順にブロックへ詰めるため、mempoolは実質的な手数料オークションになる。CPFPは子が親を引き上げる後追い手段。
• RBFは同じ入力（またはアカウントモデルでは同一 nonce）を使うより高手数料の取引で未承認取引を差し替える。0-confでの受領はゼロ確認二重支払いの危険があるため不可逆な引き渡しに使ってはならない。
• リオーグでは旧枝の取引がmempoolへ戻される。スパム対策は手数料下限・サイズ上限・eviction・連鎖制限・置き換えコストを重ね、mempoolへの操作に経済的コストを結び付けることで成立する。