あなたがイーサリアムの取引を送信すると、本当は何が起きるのか
--> 問題
あなたはウォレットで「送信」をクリックします。UIが取引を確認します。
でもその後……何も起きません。
場合によっては、数秒で確認されます。
場合によっては、数分間フリーズするか、まったく失敗します。
なぜ？
多くの説明は「ブロックチェーンに送られるところまで」で止まります。
. 上でシステムを構築しているなら、それでは役に立ちません。
裏側で実際に何が起きているのか、分解してみましょう。
メンタルモデル（クイック理解）
取引は即座に実行されるわけではありません。
取引は3つの明確な段階を経ます：
伝播（メンプール）
包含（ブロック提案）
実行（状態遷移）
各フェーズがレイテンシー、リスク、失敗パターンを持ち込む。
ステップ1：トランザクション作成
「送信」を押すと：
ウォレットがトランザクションを構築する：
—
送金額（value）
gasLimit
maxFeePerGas
data（コントラクト呼び出しがある場合）
あなたの秘密鍵を使ってトランザクションに署名する
この時点で：
👉 トランザクションは有効だが、まだネットワークには知られていない
ステップ2：ネットワークへブロードキャスト
ウォレットがそのトランザクションをノードに送信する。
このノード：
署名を検証
nonceを確認
基本的な妥当性を保証
有効なら→メンプールに入る
ステップ3：メンプール（面白くなるところ）
メンプールは：
一時的な保持領域
グローバルに一貫していない
ノードごとに異なる
つまり：
👉 あなたのトランザクションは一部のノードに存在するかもしれないが、他では存在しない可能性がある
重要な挙動：
ノードは手数料（fee）でトランザクションを優先する
maxFeePerGasが高いほど優先度が高い
📊 図1：トランザクション伝播フロー
図は次を示すべき：
ユーザーのウォレット → ノードA → ノードB → ノードC
それぞれのノードに独自のメンプールがある
ゴシップ伝播を示す矢印
ハイライト：「すべてのメンプールが同一ではない」
ステップ4：ブロック提案
バリデータは自分のメンプールからトランザクションを選択する。
彼らは選ぶ：
手数料が最も高いトランザクションから順に
ガス上限の範囲内に収まるトランザクション
重要：
👉 あなたのトランザクションは他のトランザクションと競合しています
ステップ5：実行（EVMレベル）
ブロックに含まれたら
そのトランザクションはEVM内で実行される
状態の変更が発生：
残高が更新される
スマートコントラクトのストレージが変更される
実行が失敗したら：
ガスは引き続き消費される
状態の変更は巻き戻る
📊 図2：実行フロー
図は次を示すべき：
ブロック → EVM → 状態遷移
入力：
トランザクション
現在の状態
出力：
新しい状態
各ステップで「ガス消費」を含める
ケース別の例外（Edge Cases）& 失敗パターン
ここでほとんどの記事が失敗します。さらに深掘りしましょう。
❌ 1. メンプール内で詰まる（スタックする）
手数料が低すぎる
バリデータにより選ばれることはない
❌ 2. ドロップされたトランザクション
ノードは次の理由でそれを削除する：
手数料が低い
メンプールのオーバーフロー
❌ 3. 置き換えられたトランザクション
同じnonce + より高い手数料→元のものを置き換える
❌ 4. ガス不足による実行
途中で実行が停止する
状態が巻き戻る（revert）
消費されたガスが失われる
❌ 5. チェーンの再編成（Reorg）
ブロックが置き換わる
トランザクションが一時的に消えることがある
現実での影響
開発者向け：
即時ファイナリティを前提にできない
保留状態（pending）を扱う必要がある
UXのために：
ユーザーは「保留（pending）」を見る→混乱する
手数料の見積もりが決定的に重要になる
システム設計のために
リトライのロジックが必要
トランザクションの監視は必須
要点
トランザクションは複数段階のプロセスであり、単一の出来事ではない
メンプールは非決定的で分断されている
手数料は実行確率に直接影響する
失敗は複数の層で起こり得る
システムは を前提に設計されるべき不確実性と遅延
もしあなたがEthereum上に構築しているなら、このパイプラインを理解するのは必須です—それが土台です$ETH