---
title: "区块确认"
description: "一份以核验为先的指南，介绍 PoW 确认深度、PoS 安全与最终确定状态、内存池替换、链重组及交易所入金记账政策。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 区块确认
> 仅供教育参考，不构成财务或安全建议。确认、最终性、替换和入金记账规则会因网络、节点、资产、平台及事件状态而异。
## 直接答案
区块确认是针对特定观察者和协议的陈述，表示某笔交易已纳入该观察者当前所见规范链上的某个区块。Bitcoin Core 常用包含式口径，把收录交易的区块计为第一次确认：若收录高度为 `h`、最佳链高度为 `H`，深度就是 `H - h + 1`。有些服务只计算后继区块，显示为 `H - h`，因此必须明确所用口径。
在给定假设下，工作量证明的深度会降低链重组风险，却不存在某个能带来绝对最终性的神奇数字。权益证明系统可以直接提供协议原生状态。以太坊区分 `latest`、`safe` 和 `finalized`；固定的区块数、时隙数或已过分钟数不能替代这些标签。即使达到链上门槛，平台的已检测、已记账、可交易和可提现仍是彼此独立的内部政策状态。
## 运作机制
1. 固定链和网络、资产、交易标识符、节点或 API、观察时间、共识模型及计数口径。在把匹配的哈希视为目标付款之前，核对收款方、金额以及任何备注或标签。
2. 区分已签名、已广播、被某个节点的本地内存池接受和已传播。内存池是节点的策略视图，不是全网共识队列。检查手续费状态、未确认祖先交易、手续费替换或相同 nonce 替换，以及冲突花费。
3. 依据区块哈希、高度、交易索引和规范链祖先关系核验收录，不能只看高度或区块浏览器徽标。对于账户型链，还要查看收据状态、日志及实际状态变化；已被收录的执行仍可能回滚。
4. 按共识模型处理。对于 PoW，应声明口径、计算深度，并比较独立节点所见的最佳链和累积工作量。对于 PoS，应查询原生的链头、安全、已论证或最终确定状态；不要依据固定区块或时隙距离推断这些状态。
5. 将生命周期记录为明确状态：已创建、已广播、本地内存池已接受、已收录、规范链深度或安全/最终确定状态、已重组、再次收录、已替换或已冲突。链重组不保证原交易会返回每个节点的内存池。
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`，且全部位于同一祖先链。数值上的最新深度为 `20,000,020 - 20,000,000 + 1 = 21`；该交易已安全，但尚未最终确定。必须核对哈希祖先关系和客户端的共识标签，单凭高度并不充分。
- **链上门槛与平台记账。** 某平台政策要求 `6 confirmations`。位于区块 `900,000` 的入金显示 `5/6` 时，链头为 `900,004`；显示达到 `6/6` 时，链头为 `900,005`。若平台随后实施 `15-minute compliance hold`，链上资格与内部记账、交易或提现时间仍是不同状态；这段等待不是第七次确认。
## 风险
- 查看了错误的链、网络或资产。
- 使用了错误的交易哈希、收款方、备注或标签。
- 把已签名但尚未广播的交易当成待处理交易。
- 把某个节点的内存池当成全网状态。
- 漏看策略拒绝、逐出或未传播。
- 忽略 RBF、相同 nonce 或冲突替换。
- 误读未确认的祖先、后代交易或交易包手续费。
- 混用包含式和只计后继区块的确认数。
- 信任陈旧、正在同步或被隔离的节点。
- 比较高度时没有核对区块哈希和祖先关系。
- 因短期 PoW 链重组而失去确认。
- 把固定深度视为对任何金额和攻击者都绝对安全。
- 混淆经过时间、时隙、时期和实际产出的区块。
- 把 PoS 链头区块视为安全区块。
- 把安全区块视为最终确定区块。
- 链仍在出块时漏看最终性延迟。
- 把已收录但已回滚的执行视为应用成功。
- 把代币日志或区块浏览器界面等同于最终状态。
- 混淆平台检测、记账、交易和提现权限。
- 把源链确认视为跨链桥、发行方或目标链流程已经完成。
## 常见误解
- 能搜索到交易哈希或看到本地内存池条目，就表示交易已经确认。
- 一种确认数口径和六次确认门槛适用于所有链、金额和服务。
- 支付更高手续费会让后续区块或 PoS 最终性更快到来。
- 固定的以太坊区块数或时隙数等同于 `safe` 或 `finalized`。
- 链上收录或最终确定保证合约执行成功、收款信息正确、平台记账或跨链桥流程完成。
## 相关主题
- [内存池](/zh-cn/crypto/mempool/)
- [比特币](/zh-cn/crypto/bitcoin/)
- [最终性](/zh-cn/crypto/finality/)
## 来源
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org（访问日期：2026-08-13）
- [Payment Processing](https://developer.bitcoin.org/devguide/payment_processing.html) - Bitcoin Developer Documentation（访问日期：2026-08-13）
- [gettransaction](https://developer.bitcoin.org/reference/rpc/gettransaction.html) - Bitcoin Developer Documentation（访问日期：2026-08-13）
- [BIP 125: Opt-in Full Replace-by-Fee Signaling](https://bips.dev/125/) - Bitcoin Improvement Proposals（访问日期：2026-08-13）
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org（访问日期：2026-08-13）
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org（访问日期：2026-08-13）
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org（访问日期：2026-08-13）
- [Cryptocurrency deposit processing times](https://support.kraken.com/articles/203325283-cryptocurrency-deposit-processing-times) - Kraken Support（访问日期：2026-08-13）
Source: https://wiki.fcontext.com/zh-cn/crypto/block-confirmation/index.mdx