Ethereumの承認数とファイナリティ: Successだけでなくブロックを確認

Ethereumに取り込まれた取引は、それを含むブロックが確定する前にSuccessと表示されることがあります。 Successは実行結果を示し、承認数はツールの数え方に従って取り込み後に追加されたブロックを表します。ファイナリティは別の合意状態です。これらを同じ意味にせず、取引のブロックとネットワークの確定済みチェーンを確認します。

この手順はプルーフ・オブ・ステーク移行後のEthereum Mainnetが対象です。ロールアップ、ブリッジ、他のチェーン、資産を預かるサービスには追加の規則があります。すでに持っている取引を読み取り専用で確認する方法であり、支払いの送信、取消、再送を勧めるものではありません。

取り込み、実行、確定を分ける

JSON-RPCのレシート仕様は、取引を含むブロックの番号とハッシュ、および実行ステータスを返します。保留中の取引には、まだ取り込み済みのレシートがありません。ステータス1は生のJSON-RPCでは0x1と表示され、実行成功を示します。0または0x0は失敗です。

どちらも確定フラグではありません。実行が取り消された取引でも、確定済みブロックに入ることがあります。逆に、実行が成功しても、まだ確定していない新しいブロックに入っている場合があります。確定を待っても、取り消された処理が成功に変わることはありません。

観察した情報	分かること	まだ分からないこと
ブロック付きレシート	プロバイダーはそこへの取り込みを報告している	そのブロックが確定済みか
レシートのSuccess	最上位の実行が成功した	目的のトークン受取や確定
承認数	ツールが取り込み後の深さを報告している	共通の確定条件や入金反映条件
確定済みチェーンにブロックがある	そのブロックに合意上の確定が及ぶ	コントラクトの安全性や取引所への入金反映

まだ保留中なら、次の操作を考える前に保留中の取引のガイドを参照してください。成功しているのに目的のトークンがない場合は、送金の証拠を確認するガイドが、その別の問題を扱っています。

Ethereumの確定済みとは何か

Ethereumのプルーフ・オブ・ステークの説明では、バリデーターがチェックポイントへ投票します。確定は、単に現在のチェーン先端に近いことより強い保証です。確定済みブロックを覆すには、深刻な経済的影響を伴う重大な合意の障害が必要です。ただし、そのブロック内のすべてのアプリや資産の安全性を約束するものではありません。

Ethereum Foundationのアプリ層向け説明は、safeヘッドと確定済みブロックを区別しています。safeは中間的な信頼状態であり、finalizedの同義語ではありません。実行APIはlatest、safe、finalizedのブロックタグを公開しているため、必要なヘッドを問い合わせられます。

これらのラベルはEthereumの文脈で使ってください。ロールアップでは、シーケンサーと親チェーンに関係する段階に似た言葉を使う場合があります。Mainnetの手順をそのままブリッジ送金に当てはめたり、送信元チェーンでの確定が送信先の処理完了を意味すると考えたりしないでください。

ここでは一定の待ち時間を約束しません。遅延、古いプロバイダーデータ、ネットワークの問題があると、タイマーは実際の状態確認の代わりになりません。サービスが特定の承認数などを要求する場合は、その現在の公式条件を別途確認します。

取引を確定済みチェーンと照合する

信頼できる経路から、使い慣れたEthereumエクスプローラーか公開ブロック閲覧ツールを開きます。確定状態を直接表示するものも、ブロック詳細だけを表示するものもあります。以下のメソッド名は公開情報の読み取りを示し、取引実行やウォレット接続の指示ではありません。この手順は2026年10月27日に資料と照合しましたが、この記事のために実際のウォレットで試してはいません。

1. 取引を特定する情報を固定します。 Ethereum Mainnetであることと、完全な取引ハッシュを記録します。レシートから、取引を含むブロックの番号、ハッシュ、実行ステータスを控えます。レシートを取得できない場合は未解決です。失敗と判断する前にネットワークとプロバイダーを確認します。
2. 報告された確定状態を読み取ります。 エクスプローラーが文書で説明しているブロックラベルを使います。JSON-RPCの閲覧ツールでは、eth_getBlockByNumberにfinalizedを指定すると現在の確定済みヘッドを取得できます。返されたブロック番号と観察時刻を保存します。未対応や読み取り失敗なら未確認のままにします。
3. 高さだけでなくブロックの同一性も比べます。 確定済みヘッドが取引を含むブロックより低ければ、その観察ではまだ取引をカバーしません。同じ高さ以上に達していれば、取引を含む高さの正規チェーン上のブロックを再取得し、ハッシュをレシートのブロックハッシュと比較します。一貫した最新のプロバイダーを使い、ハッシュが違えばレシートも再確認します。
4. 結果が示す範囲を明確にします。 確定済みヘッドと同じかそれ以前に一致するブロックがあれば、報告されたチェーン上での確定を裏付けます。ただし、古い情報や不整合なプロバイダーは誤ったデータを返す可能性があります。不一致を記録し、異なる時点の情報を混ぜて結論を強制せず、プロバイダーの公式稼働情報やサポートを確認します。
5. アプリの条件は別途確認します。 取引が実際に何をしたか、受取サービスが独自の規則に従って入金を反映したかを確かめます。ギャラリーや入金ページが更新されないという理由だけで、二度目の支払いを送らないでください。

ブロック取得の仕様は番号とハッシュを返します。記録が食い違う場合、高さだけでは不十分です。チェーンの再編成では、異なる二つのブロックが同じ高さを占めることがあります。番号とともにハッシュを保存し、取引を含んでいた特定のブロックを比較します。

変化する承認数を慎重に読む

仮のレシートで取引がブロック100に入り、閲覧ツールの確定済みヘッドが98だとします。Success表示はすでに出ていても、その確定済みヘッドの観察はブロック100をカバーしません。後の一貫した読み取りで確定済みヘッドが102となったら、高さ100の正規ブロックが今もレシートのハッシュと一致することを確認してから、取引のブロックがカバーされたと記録します。

意図的に小さくしたこれらの番号は架空の例であり、現在のMainnetの観察ではありません。確定までの時間や入金の閾値を示していません。表示承認数には取引を含むブロック自体を数える方式もあるため、二つの画面を比べる前にツールの定義を読んでください。

再編成により、取引が別のブロックへ移ったり、以前の取り込み記録がなくなったりすることがあります。元の取引ハッシュを保存し、レシートを更新して現在の記録を比較します。数が変わっただけでは再送すべき証拠になりません。ウォレットの古い通知も、新しいブロック記録に優先しません。

日時付きのブロック記録を残す

ネットワーク、取引ハッシュ、取引を含むブロックの番号とハッシュ、実行ステータス、観察した確定済みヘッド、確認時刻をまとめて保存します。記録に整合性があったか、確定はエクスプローラーの直接表示か、上記のブロック比較による推定かを明記します。

確定は、正しいトークンが正しい相手へ届いたこと、コントラクトが信頼できること、資産を預かるサービスが内部会計を完了したことを証明しません。取引が確定した後でも、ポートフォリオ残高の不一致は表示、対応範囲、価格の問題の場合があります。

これらの公開記録に署名、承認、リカバリーフレーズは不要です。承認数や確定状態を表示するだけなのにサイトがそれらを要求したら、その操作を中止してください。結果は、限界を伴う特定の観察状態として残します。緑の表示が支払いの全工程の完了を保証するとは考えないでください。