本文へ移動
Financial Context Wiki

ブロック承認

PoW の承認深度、PoS の safe/finalized 状態、メンプールでの置換、チェーン再編成、取引所の入金反映方針を検証重視で解説します。

更新日

教育目的の情報であり、財務・セキュリティ上の助言ではありません。承認、ファイナリティ、置換、入金反映の規則は、ネットワーク、ノード、資産、取引所、障害状況によって異なります。

直接の答え

ブロック承認とは、特定の観測者とプロトコルを前提に、その観測者が現在認識する正規チェーン上のブロックに取引が含まれているという状態です。Bitcoin Core で一般的な包含方式では、取引を収録したブロックを 1 承認目に数えます。収録高を h、ベストチェーン高を H とすると、深度は H - h + 1 です。後続ブロックだけを数えて H - h と表示するサービスもあるため、採用する方式を明示する必要があります。

所定の前提の下で、プルーフ・オブ・ワークの深度はチェーン再編成リスクを下げますが、絶対的なファイナリティを生む魔法の境界ではありません。プルーフ・オブ・ステークでは、プロトコル固有の状態が示される場合があります。イーサリアムは latest、safe、finalized を区別しており、一定のブロック数、スロット数、経過時間でこれらのラベルを代用できません。チェーン上の基準を満たした後も、取引所による検知、入金反映、取引可能、出金可能は別々の内部方針上の状態です。

予想待ち時間
1.2 min
例示範囲
54s - 1.5 min

結果は教育用の概算です。明示されない限り、取引所ルール、税、遅延、オラクル動作、固有のプロトコル条件は含みません。

仕組み

  1. チェーンとネットワーク、資産、取引識別子、ノードまたは API、観測時刻、コンセンサスモデル、計数方式を固定します。一致するハッシュを目的の支払いと判断する前に、受取人、金額、メモやタグを照合します。
  2. 署名済み、ブロードキャスト済み、あるノードのローカルメンプールで受理済み、伝播済みを分けます。メンプールは各ノードの方針に基づくビューであり、世界共通のコンセンサスキューではありません。手数料状況、未承認の親取引、Replace-by-Fee または同一 nonce による置換、競合支出を確認します。
  3. 高さやエクスプローラーの表示だけでなく、ブロックハッシュ、高さ、取引インデックス、正規チェーン上の祖先関係から収録を検証します。アカウント型チェーンでは、レシートの status、ログ、実際の状態変化も調べます。収録済みでも実行は revert している場合があります。
  4. コンセンサスモデルに応じて判定します。PoW では方式を明示して深度を計算し、独立したノードが認識するベストチェーンと累積作業量を比較します。PoS では固有の head、safe、justified、finalized 状態を照会し、一定のブロック距離やスロット距離から推測しません。
  5. ライフサイクルを明示的な状態で追跡します。作成、ブロードキャスト、ローカルメンプールでの受理、収録、正規チェーン深度または safe/finalized 状態、再編成、再収録、置換、競合です。再編成後に元の取引がすべてのメンプールへ戻る保証はありません。
  6. 取引所の台帳を分けます。観測済み、ネットワーク基準達成、入金反映済み、取引可能、出金可能を区別します。資産、ネットワーク、金額、障害状況に応じた取引所の現行方針を適用し、保守、コンプライアンス、手動審査による独立した遅延も考慮します。
  7. 独立したノードやプロバイダーを相互照合し、必要な状態に達するまで監視します。ハッシュ、高さ、タイムスタンプ、RPC ラベル、方針のスナップショットを記録し、置換、再編成、ファイナリティ遅延、古いノード、ブリッジ中継、取引所停止への対応を訓練します。

例

  • 計数方式。 ビットコイン取引が正規ブロック h = 900,000 にあり、ベストチェーンの先端が H = 900,005 なら、包含方式の深度は 900,005 - 900,000 + 1 = 6 confirmations です。後続ブロックのみを数える表示では 900,005 - 900,000 = 5 です。同じブロックハッシュと祖先関係を参照している限り、これは用語と方式の違いです。
  • 再編成と再収録。 取引は当初 1 confirmation を得ており、その収録ブロックは 900,000 でしたが、後にベストチェーンから外れます。取引がなお有効で競合していなければ、承認数は 0 に戻ります。900,003 で再収録され、先端が 900,006 に達した場合、包含方式の深度は 900,006 - 900,003 + 1 = 4 confirmations です。承認済みの競合取引に置き換えられた場合、Bitcoin Core は負の承認数を返すこともあります。
  • PoS ラベルはブロック数ではない。 イーサリアム取引が実行ブロック 20,000,000 にあり、あるノードが同じ祖先関係上で latest = 20,000,020、safe = 20,000,012、finalized = 19,999,980 と報告したとします。数値上の latest 深度は 20,000,020 - 20,000,000 + 1 = 21 で、取引は safe ですが finalized ではありません。ハッシュの祖先関係とクライアントのコンセンサスラベルが必要であり、高さだけでは不十分です。
  • チェーン基準と取引所の入金反映。 取引所の方針が 6 confirmations を要求するとします。ブロック 900,000 の入金が 5/6 と表示される時点の先端は 900,004 で、表示が 6/6 に達する時点の先端は 900,005 です。その後に取引所が 15-minute compliance hold を適用する場合、チェーン上の適格性と内部の入金反映、取引、出金の時刻は別々です。この保留は 7 回目の承認ではありません。

リスク

  • 誤ったチェーン、ネットワーク、資産を確認する。
  • 誤った取引ハッシュ、受取人、メモ、タグを使用する。
  • 署名済みでも未送信の取引を pending とみなす。
  • 一つのノードのメンプールをネットワーク全体の状態とみなす。
  • 方針による拒否、排除、未伝播を見落とす。
  • RBF、同一 nonce、競合取引による置換を見落とす。
  • 未承認の親子取引やパッケージ手数料を読み違える。
  • 包含方式と後続ブロックのみの承認数を混同する。
  • 古い、同期中、または隔離されたノードを信頼する。
  • ブロックハッシュと祖先関係を検証せず高さを比較する。
  • 短期の PoW チェーン再編成で承認を失う。
  • あらゆる金額や攻撃者に対して固定深度を絶対安全とみなす。
  • 経過時間、スロット、エポック、実際に生成されたブロックを混同する。
  • PoS の head ブロックを safe とみなす。
  • safe ブロックを finalized とみなす。
  • ブロック生成が続く中でファイナリティ遅延を見落とす。
  • 収録済みでも revert した実行をアプリケーション成功とみなす。
  • トークンログやエクスプローラー表示を結果の状態と混同する。
  • 取引所の検知、入金反映、取引可能、出金可能を同一視する。
  • ソースチェーンの承認をブリッジ、発行者、宛先側の処理完了とみなす。

よくある誤解

  • 検索できる取引ハッシュやローカルメンプールの項目は、すでに承認済みである。
  • 一つの承認数方式と 6 承認の基準が、すべてのチェーン、金額、サービスに適用される。
  • 高い手数料を払えば、後続ブロックや PoS のファイナリティも早く到来する。
  • イーサリアムの固定ブロック数やスロット数は safe または finalized と同じである。
  • チェーンへの収録や finalized 状態は、コントラクト実行の成功、正しい受取人、取引所の入金反映、ブリッジ処理の完了を保証する。

関連トピック

出典

ナビゲーション

Wiki を検索...