TL;DR

    在一个街区

    图1. 一笔交易会经历几种不同的状态。“钱包已看到”“在某个内存池中”“已打包”“safe”和“已结算”并不是可以互换的说法。

    “已确认”到底是什么意思？

    简短回答：已确认意味着当前被视为规范链一部分的某个有效区块包含了这笔交易。在比特币上，包含该交易的区块本身就算第一个确认，之后每出一个区块就再加一个确认。在以太坊上，交易被打包之后还可以依次经过latest、safe和finalized状态而进一步成熟。

    “已确认”这个词听起来常常像非黑即白：先是什么都没有，然后就是确定无疑。区块链的情况要细致得多。钱包可能知道交易已签名，节点可能接受它进入本地内存池，出块方可能把它打包进区块，而收款方仍然可能要等到更有把握时才把这笔付款当作已结算。这些是彼此独立的事件。

    状态含义仍然可能发生什么
    已创建或已签名钱包已构造并授权了这笔交易。它可能永远不会被广播，发送方也可能广播一个相互冲突的版本。
    已广播交易已发送给至少一个对等节点或私有端点。其他节点可能没有看到它，也可能按自己的策略拒绝它。
    在某个内存池中某个具体节点把它作为有效的未确认候选交易保存下来。它可能一直等待、被逐出、被替换，或无法广泛传播。
    已打包 / 1个确认当前规范链中有一个区块包含它。一次浅层区块重组可以把那个区块移除。
    更多确认更多规范区块在它之上叠加。逆转通常会变得越来越昂贵，或越来越不可能。
    以太坊上的safe / finalized共识客户端提供更强的分叉选择状态和检查点状态。要逆转已最终确定的状态，需要严重的共识失败加上社会层面的恢复，而不是正常运行下会发生的事。
    对收款方而言已结算收款方自己的风险政策已经得到满足。这是一项业务决策，不是全网通用的协议标志。

    交易也可能执行失败。在以太坊上，一笔已被打包但合约调用发生回滚的交易，作为交易仍然是已确认的：它消耗了Gas，让发送方的nonce（账户交易序号）递增，并生成了状态为失败的收据，尽管它本来要做的状态变更被撤销了。因此“已确认”并不自动等于“应用层面的操作成功了”。

    小结：要问两个问题，而不是一个：这笔交易是否已被打包进规范链，以及它是否达到了这笔具体付款所要求的把握程度。

    交易到达内存池之前会发生什么？

    简短回答：钱包构造并签署一条特定于该链的消息，然后把它提交给某个节点或私有服务。接收方会先检查共识有效性和本地策略，再决定是否保存或中继。签名并不保证被接受、被传播或被打包。

    构造与签名

    一笔比特币交易会指明要花费哪些未花费输出、创建新的输出、设定金额和脚本，并附上满足花费条件的签名或其他见证数据。一笔以太坊交易会指明发送方控制的账户、nonce、目标地址、金额、可选数据、Gas上限和费用上限，再附上对这一确切内容的授权签名。

    提交不等于全网广播

    大多数钱包会把签好名的交易提交给自己的某个节点、某家基础设施服务商或一个已连接的对等节点。首个接收方随后可能把它中继到点对点网络上。有些交易则被送往私有中继、区块构建者、矿池服务或特定应用的端点。钱包显示“已发送”，往往只表示有一个端点接受了这次提交请求。

    有效性规则与中继策略

    共识规则决定一笔交易能否合规地出现在区块里：授权有效、没有被禁止的超额花费、状态转换正确，以及其他链规则。节点策略决定的是，在交易被打包进区块之前，是否值得保存并中继这笔未确认交易。策略可以比共识更严格，也会因软件版本或运营者配置而不同。被某个内存池拒绝的交易，在区块里仍可能是有效的，也可能被另一个节点接受。

    检查项比特币示例以太坊示例
    授权每个被花费的输出，其见证或脚本条件都通过验证。签名能标识发送方，且交易各字段有效。
    可花费性被引用的输出存在且未被花费，扣除手续费后金额平衡。发送方nonce符合要求，且账户余额能覆盖转账金额加上所需的最高成本。
    共识有效性交易符合脚本、锁定时间、权重和货币发行规则。交易类型、固有Gas和执行层规则都有效。
    本地策略标准性、最低中继费率、交易簇规则和替换规则。客户端交易池上限、加价幅度、账户槽位和其他运营者设置。
    打包的经济性构造区块模板时会权衡预期手续费贡献和依赖关系。基础费用资格、优先费用、构建者策略、私有订单流和MEV。

    小结：“网络拒绝了它”这种说法往往太笼统。要弄清是哪个节点拒绝的，原因是共识有效性还是本地策略，以及是否还存在另一个版本或另一条提交路径。

    什么是内存池，为什么不存在唯一的那一个？

    简短回答：内存池是节点在本地保存的一组有效但未确认的交易。节点会把其中许多交易传播给对等节点，因此各节点的内存池会有重叠，但永远无法保证完全相同。私有交易则可能完全绕过公共广播。

    这个词来自“内存池（memory pool）”。它不是协议在某一处设立的统一候车室。每个参与的节点都在实现和运营者设定的约束内，自行决定接受、保留、逐出、中继和替换哪些交易。节点上线时间不同、对等节点不同、使用的软件不同，分配的内存也可能不同。因此它们各自的待确认交易集合会持续出现分歧。

    比特币的内存池

    比特币节点会保存未确认交易并跟踪它们的依赖关系图，因为子交易可能花费尚未确认的父交易的输出。Bitcoin Core 31引入了簇内存池（cluster mempool）设计，把相互关联的交易成组评估，并按预期被挖出的“分块（chunk）”费率排序。这比早期那种入门模型更准确，后者假设每笔交易都独立地排在同一个按手续费高低排列的队列里。

    以太坊的交易池

    以太坊执行客户端通常会区分可执行（pending）交易和排队（queued）或存在nonce缺口的交易。使用下一个可用nonce的交易可以执行；nonce更靠后的交易则可能要等待，因为前面缺少一个或多个nonce。Geth的文档就区分了pending池和queued池，并说明同一发送方、同一nonce的交易可以被出价足够高的版本替换。

    公共内存池与私有订单流

    发送方可以把交易直接路由给某个区块构建者或专门服务，而不是在公共广播网络上散播。这可能减少被抢先交易（front-running）的公开暴露，或改善捆绑交易的处理方式，但同时引入了端点可用性、审查和信任方面的假设。以太坊自己的文档明确指出，高级用户可以把交易发给专门的区块构建者，而不是发到公共内存池。

    小结：要说“某个节点的内存池”或“公共交易广播”，而不要把“内存池”说成一个全网一致的数据库。

    比特币的手续费和交易选取是怎么运作的？

    简短回答：比特币的手续费是在为稀缺的区块权重付费。钱包通常以聪/虚拟字节报出费率，但矿工可能把相互关联的交易放在一起评估。一笔手续费很高的小额子交易，可以让低手续费的父交易在经济上变得有吸引力，链下安排同样会影响能否被打包。

    绝对手续费与费率

    绝对手续费是所花费输入的总金额与新建输出总金额之间的差额。费率是用这笔手续费除以虚拟大小，通常以sat/vB表示。1,000聪的手续费在一笔小交易上可能很有竞争力，在一笔大得多的交易上则远远不够。虚拟字节已经计入SegWit的权重折扣，并不等于原始的字节大小。

    为什么依赖关系会改变这场竞价

    子交易不可能先于它未确认的父交易获得确认，因为它要花费的那个输出还没有上链。因此理性的区块构造会考虑必须一起被挖出的那些交易的总收入和总大小。Bitcoin Core 31的簇内存池逻辑明确按预期挖出的分块来给相互关联的交易排序，而不是简单地一笔交易占一行。

    矿工和矿池在优化什么

    矿池通常会构造一个有效的区块模板，力求在权重、依赖关系、策略和运营约束之内让收入最大化。费率是核心因素，但不是唯一因素。运营者可以在本地给某些交易提高优先级、通过私有渠道接收交易、加入自己的交易、履行商业协议，或出于策略原因不收录某些交易。只要区块内容符合共识规则，共识节点就会接受这个区块，无论它是否与另一个节点的内存池一致。

    Side-by-side comparison of Bitcoin and Ethereum transaction-fee markets. Bitcoin shows satoshis per virtual byte, parent-child package evaluation, mining-template selection and RBF or CPFP. Ethereum shows max fee, base fee, priority fee, gas used, MEV and same-nonce replacement.
    图2. 手续费对能否被打包影响很大，但区块构造还取决于交易之间的依赖关系、私有路径和排序价值。
    比特币概念含义常见误解
    手续费交易一旦确认，总共支付的聪数。只比较绝对手续费，却不考虑交易大小。
    费率手续费除以虚拟大小，通常为sat/vB。以为报出的目标区块数就能保证进入某个特定区块。
    交易包 / 交易簇相互关联、可能需要一并评估的未确认交易。以为子交易的高费率帮不了低手续费的父交易。
    内存池最低费率某个节点在自身内存和策略下动态调整的接受门槛。把一个节点的拒绝当成共识规则。
    区块最低费率 / 运营者选择矿工或矿池可以设定自己的经济性收录策略。以为所有矿池构造的区块模板都一样。

    小结：比特币是一场对区块权重的竞价，但经济单位可能是一组相互关联的交易，而不是孤立的一笔交易。

    以太坊的Gas费和nonce顺序是怎么回事？

    简短回答：以太坊按Gas对执行收费。一笔交易会设定Gas上限、每单位Gas的最高费用和最高优先费用。协议基础费用会被销毁；实际生效的优先费用则奖励给区块提议者或其配置的收款地址。同一账户发出的交易按nonce顺序执行。

    已用Gas与Gas上限

    Gas（燃料费）衡量一笔以太坊交易所需的执行资源。Gas上限是发送方为该交易授权的最大Gas量。发送方只为实际消耗的Gas付费，最多不超过这个上限。一笔简单的ETH转账，其固有成本是可预期的；与合约交互则可能消耗多得多，而且会随状态变化。

    基础费用、优先费用和最高费用

    EIP-1559为每个区块设定了协议基础费用：当之前的区块Gas用量超过目标值时它上升，低于目标值时下降，每个区块最多变动12.5%。这部分基础费用会被销毁。发送方另外设定每单位Gas的最高优先费用和最高总费用。每单位Gas的实际收费受基础费用、允许的小费和发送方设定的最高费用共同约束；没用上的余量不会被收取。

    nonce顺序

    外部账户的nonce会随每笔已执行交易递增。使用较大nonce的交易，必须等前面每一个nonce都被消耗后才能执行。这就是为什么一笔出价过低或缺失的交易，会挡住同一账户后面一整串出价更高的交易。不同客户端和钱包服务可能把这些状态称为pending、queued或存在nonce缺口。

    执行回滚仍然要付Gas

    如果一笔以太坊交易被打包但合约执行发生回滚，协议会丢弃它本来要做的状态变更，但保留nonce的递增，并对已经完成的计算收费。收据状态会显示失败。相比之下，因为本身无效而在被打包前就被拒绝的交易，不会消耗链上Gas。

    blob费用是单独的

    携带EIP-4844 blob的交易（主要由Rollup使用）除了普通的执行Gas之外，还要参与一个单独的blob费用市场。普通的ETH转账不支付blob费用。这个区别在诊断Rollup成本时很重要，但它不属于标准钱包转账的费用计算。

    以太坊字段作用面向用户的解读
    nonce为同一发送方的交易排序，并防止在该账户序列内被重放。前面缺失或卡住的nonce会挡住后面的交易。
    gasLimit限定该交易最多可消耗多少执行Gas。设得太低会导致失败；没用完的Gas不收费。
    baseFeePerGas该区块的协议价格下限；会被销毁。如果交易的最高费用低于所需的基础费用，它就无法被打包。
    maxPriorityFeePerGas限定用于激励打包的小费上限。给得更高可以提升优先级，但排序也可能受MEV或私有订单流影响。
    maxFeePerGas限定基础费用加上生效优先费用的合计上限。防止支付超过签名时设定的每单位Gas上限。
    收据状态说明已打包的执行是成功还是回滚了。一笔已确认的交易，其应用层执行仍可能失败。

    小结：在以太坊上，要把交易是否被打包和它执行是否成功分开看，也要把Gas上限和实际收取的金额分开看。

    区块究竟由谁构建、由谁提议？

    简短回答：比特币矿池通常负责构造候选区块模板，矿工则对模板做工作量证明。以太坊为每个时隙指定一名验证者作为提议者，但许多提议者会通过协议外的提议者与构建者分离机制，把执行载荷的构造外包给专门的区块构建者。无论如何，每个全节点仍然独立验证有效性。

    比特币：矿池、模板构造和工作量证明

    矿池汇集参与矿工的算力，通常根据自己的区块模板下发候选工作。矿池或其基础设施负责挑选交易并构造coinbase交易；矿工则搜索满足工作量证明的区块头。找到有效区块的矿工或矿池会把它广播出去。独立的比特币节点会检查整个区块，只要有任何一条共识规则被违反就拒绝它。

    以太坊：提议者和构建者可以是不同角色

    每个12秒的时隙都有一名选定的验证者提议者。提议者可以用自己知道的交易在本地构建执行载荷，也可以使用构建者市场。协议外的提议者与构建者分离（PBS）通常通过Builder API和MEV-Boost生态实现，让专门的构建者竞价，争取提供执行载荷的权利。提议者对选中的区块签名；其他节点会重新执行并验证它。以太坊的路线图讨论了把这种分离写进协议本身，但路线图上的提案在真正上线之前不应被说成已经生效。

    MEV为什么会影响排序

    最大可提取价值指的是通过挑选、插入或排列交易而额外获得的利润，套利和清算就是典型例子。构建者可能更愿意选一个总价值很高的捆绑交易，而不是一笔公开小费略高的交易。因此“小费最高的永远排在最前面”并不能准确描述以太坊的区块排序。

    私有订单流的取舍

    私有提交可以减少在公开场合被抢先交易的风险，也支持要么全成、要么全不成的捆绑交易。但它同时会把可见性和审查权力集中到构建者、中继或端点运营者手里。用户应当把隐私和无需信任区分开：一笔对公共内存池隐藏的交易，对接收它的那个私有服务仍然是可见的。

    小结：提议区块的一方可能并不是决定其交易顺序的一方，在以太坊上尤其如此。能否被打包既是手续费问题，也是市场结构问题。

    交易为什么会卡住、消失，或显示互相矛盾的状态？

    简短回答：常见原因包括经济优先级太低、nonce或依赖关系存在缺口、本地策略差异、余额不足、出现了冲突的替换交易、端点故障、被内存池逐出，或发生了区块重组。先判断清楚状态，再动手处理。

    表现可能的原因先检查什么
    钱包显示已发送，浏览器却找不到钱包只提交给了一个端点、广播失败，或者交易走了私有路径。交易哈希、网络、钱包日志，以及另一个独立的节点或浏览器。
    能看到，但长时间处于待确认手续费或小费缺乏竞争力、父交易手续费太低，或以太坊上前面的某个nonce缺失。当前的手续费行情、依赖关系、nonce序列，以及是否支持替换。
    在一个浏览器上看得到，在另一个上看不到各节点内存池不同、对等节点可见性不同，或数据服务商存在延迟。核对交易哈希和网络；先稍等一会儿，不要急着判定失败。
    待确认的交易消失了本地逐出、被替换、节点重启或策略变动，或者数据服务商的索引发生变化。检查输入或nonce是否仍未被花费，以及是否存在冲突交易。
    先显示已确认，又变回待确认包含它的区块在一次区块重组中被移出了规范链。区块哈希、规范链、是否存在冲突花费，以及最新的打包状态。
    以太坊收据显示status 0交易已确认，但EVM执行发生了回滚。已用Gas、回滚原因、合约状态和应用日志。
    钱包里这笔比特币交易无法替换钱包不支持手续费加价、没有控制所需的输入或输出，或者交易关系图与策略不允许所选方法。钱包文档，以及是否可以使用CPFP。

    被丢弃不等于全网都忘了它

    节点会因为本地内存压力、交易存放时间或策略而逐出交易。另一个节点可能仍然保留它，并在之后重新广播。仅仅因为某个浏览器不再显示这笔交易，发送方就不能假定这笔资金可以安全地再次使用；要核实规范链上的UTXO或账户nonce状态，并使用钱包的冲突处理功能。

    手续费低并不是唯一原因

    一笔交易可能名义手续费很高却仍要等待：它依赖一个低手续费的父交易、卡在nonce缺口后面、不满足某条本地中继规则、被提交给了一个不向外发送的私有端点，或者在构建者眼里输给了更值钱的捆绑交易。诊断准确，才能避免不必要或不安全的替换尝试。

    小结：从可观测的链上状态和节点状态入手。在弄清楚问题出在手续费优先级、排序、策略、替换还是区块重组之前，不要反复随意重发各种版本。

    待确认的比特币交易怎样加速或替换？

    简短回答：两种标准工具是手续费替换（RBF），即用一笔冲突交易支付更多手续费；以及子付父费（CPFP），即花费一笔未确认输出，从而提高挖出这一组关联交易的经济价值。能不能用取决于钱包支持、交易结构和当前的节点策略。

    手续费替换（RBF）

    RBF会创建一笔新交易，它至少花费待确认交易所用的一个相同输入，并多付足够的手续费以满足替换策略。Bitcoin Core在28版本中把完全RBF设为默认，Bitcoin Core 31又围绕簇费率图进一步修改了替换的评估方式。在当前Core策略下，对一笔简单的单笔替换而言，新交易的绝对手续费和费率都必须更高，还要多付足够的增量手续费来覆盖中继成本。其他实现和服务的规则可能不同。

    尽可能使用钱包自带的“提高手续费”或“加速”功能。手动替换可能会不小心改动收款方、改变输出、破坏应用层的假设，或造出一笔无法按预期传播的交易。在其中一个版本获得确认之前，替换都不算尘埃落定。

    子付父费（CPFP）

    如果发送方或收款方控制着这笔未确认交易的某个输出，就可以创建一笔子交易去花费该输出，并支付足够的手续费，让这一组关联交易变得有吸引力。这不会改变父交易，而是给矿工一个把父交易和子交易一起打包的经济理由。当前Bitcoin Core的交易包和交易簇策略，比过去“把两笔的费率平均一下”的简化说法更为复杂，但用户层面的原则不变：只要交易包符合策略，子交易就可以为父交易补贴手续费。

    第三方加速服务

    一些矿业服务提供交易加速，有的免费，有的收费。它们不是协议功能，也无法保证自己控制不了的矿工会收录你的交易。绝不要提供助记词或私钥，遇到主动找上门的“加速服务支持”一律当作诈骗。正规服务最多只需要公开的交易信息；如果收费，也应当走普通的付款流程。

    方法谁可以使用它改变了什么主要限制
    RBF通常是控制原始输入的发送方或钱包。创建一笔手续费更高的冲突花费。受策略和钱包支持限制；原交易也可能先确认。
    CPFP任何控制该待确认交易某个可花费输出的人。添加一笔高手续费的子交易，它必须和父交易一起被挖出。需要有可用的输出和兼容的依赖关系图。
    等待任何人。什么都不改变；指望拥堵缓解，或某个出块方主动选中这笔交易。时间无法保证；交易可能在本地被逐出。
    加速服务被特定矿业服务接受的用户。请求参与的运营方优先处理。协议之外的信任、覆盖范围有限，且骗局常见。

    小结：比特币的手续费加价是在管理冲突和交易包，不是一个能凭空提高优先级的开关。尽可能让钱包来构造替换交易。

    待确认的以太坊交易怎样加速或取消？

    简短回答：用同一个账户、同一个nonce，再发一笔手续费参数足够高的新交易。若要尝试取消，替换交易通常是给发送方自己的地址转0 ETH。同一nonce的有效交易中，先执行的那笔会消耗掉这个nonce；这是一场竞赛，不是保证能撤回。

    加速式替换

    加速会保留原本要做的操作，但提高maxFeePerGas，必要时也提高maxPriorityFeePerGas。替换交易必须满足钱包、执行客户端或服务商的加价规则。由于交易待确认期间基础费用可能变动，如果最高费用已经无法覆盖基础费用加上生效小费，只提高小费未必有用。

    取消尝试

    钱包可以用相同nonce、更高手续费提交一笔简单的自转账。如果这笔替换交易先被打包，原交易就会失效，因为nonce已经被消耗。如果原交易先进入区块，取消就失败了。此外，如果原交易走的是私有路径，用于取消的公共端点可能根本看不到它，让这场竞赛更加复杂。

    不要跳过被卡住的nonce

    发一笔nonce更靠后的交易，既不会取消也不会绕过前面那笔。它通常只是排在后面等着。先解决最早那笔缺失或待确认的nonce，再检查后面的交易是否基于过时的假设，或是否重复了应用层的操作。

    合约与授权方面的提醒

    取消成功只是阻止了那一笔具体交易执行。它不会撤销代币授权，不会逆转此前已确认的合约调用，也不会撤回在别处提交的链下订单。如果这笔待确认交易涉及安全问题，还要检查钱包、dapp和授权状态，不要把替换nonce当成完整的事件响应。

    小结：以太坊上的“取消”意思是“用一笔无害的替换交易赢下同nonce竞赛”。它不是发给验证者的一条撤销消息。

    已确认的交易还能被逆转吗？

    简短回答：刚被打包的交易可能在一次区块重组中脱离规范链。在比特币上，随着累积的工作量增加，被逆转的概率通常会下降。在以太坊上，客户端提供latest、safe和finalized三种视图；要逆转已最终确定的状态，需要一次严重的共识失败，其中至少三分之一的质押ETH总量可被证明应予罚没，并从责任验证者那里销毁。

    什么是区块重组

    节点在链的顶端附近可能短暂收到相互竞争的有效区块。分叉选择规则决定哪一条分支成为规范链。当先前被接受的区块落败时，它会被断开，由胜出的分支取而代之。被断开区块中的交易会被重新处理：有些回到内存池，有些在新分支中获得确认，还有一些会因为冲突的花费或账户nonce已经胜出而变得无效。

    比特币：概率性最终性

    比特币节点选择累积工作量最多的有效链。随着有效区块在一笔交易之上不断累积工作量，它的可靠性随之提高，但协议并不把某个特定深度标记为数学意义上的最终状态。六个确认是由来已久的大额交易惯例；它既不是每笔交易都必需，也不是对拥有足够持续算力的攻击者的绝对保证。

    以太坊：latest、safe和finalized

    以太坊的执行API区分了几种近期状态。“latest”是客户端当前的规范链头，在正常运行中也可能发生重组。“safe”是在诚实多数和网络同步假设下预期不会被重组的状态。“finalized”是最新的、具备加密经济安全性的检查点；要推翻它，需要在共识失败之后由社区手动干预，并且会让至少三分之一的质押ETH总量可被证明应予罚没，也就是说责任验证者将失去并已销毁至少这一比例的质押，具体处罚力度还会随着同时被罚没的验证者数量而变化。

    Finality timeline comparing Bitcoin confirmation depth with Ethereum latest, safe and finalized states. Bitcoin shows the containing block as one confirmation and five later blocks as six confirmations. Ethereum shows progression from latest to safe to finalized under normal participation.
    图3. 比特币提供的是不断增强的概率性保障；以太坊还额外提供明确的safe和finalized共识视图。

    最终性不等于形而上的不可能

    “已最终确定”是很强的协议保证和经济保证，但它并不是说：在发生灾难性故障之后，软件、治理或人的协调永远不可能改动历史。以太坊在文档中把社会层面的恢复列为不诚实最终性之后的最后手段。比特币同样依赖用户在极端情况下选择软件和链规则。普通用户应当把这些看作极端的系统级应急情况，而不是日常的退款机制。

    小结：确认深度衡量的是不断增强的可靠性；协议最终性标记的是一个更强的状态。两者都不会为一次经过授权的失误提供客服式的撤销通道。

    确认和最终性需要多长时间？

    简短回答：比特币的目标是平均十分钟出一个区块，但实际出块是随机的，间隔可能只有几秒，也可能长得多。以太坊按12秒一个时隙来安排，不过时隙有可能被跳过。在正常参与率下，以太坊的最终性通常在大约两个32时隙的纪元之后达成，约13分钟。

    比特币的时间是概率性的

    比特币会调整挖矿难度，使出块时间长期平均在十分钟左右。这不是下一个区块的时刻表。工作量证明的求解是随机的：下一个有效区块可能马上出现，也可能隔很久才出现。手续费估算是根据过往内存池和挖矿数据，给出在若干区块内被确认的概率，它无法承诺具体的实际时间。

    以太坊的时间是按时隙划分的

    以太坊把时间划分为12秒的时隙，以及32个时隙组成的纪元。每个时隙选出一名提议者，但并不是每个时隙都一定有区块。只要交易能被胜出的提议者或构建者看到并支付了足够的手续费，就可能很快被打包；而私有路由、构建者策略、费用上限、nonce顺序或时隙被跳过都可能让它延迟。

    最终性可能停滞

    在正常情况下，检查点投票会在大约两个纪元之后让历史达到最终确定。如果参与率跌破所需的三分之二门槛，链可以继续出块，却无法达成最终性。以太坊的不活跃泄漏机制会逐步降低不在线验证者的权重，使在线的那部分最终能重新达成最终性，但这个延迟没有固定时长。

    网络 / 状态正常节奏这个数字不保证什么
    比特币的第一个确认预期出块间隔约10分钟。不保证下一个区块在10分钟内出现，也不保证钱包报出目标就一定被打包。
    比特币的六个确认常被说成平均约一小时。不保证正好60分钟，也不代表绝对不可逆。
    以太坊在下一个时隙被打包每12秒一个时隙。不保证每个时隙都有区块，不保证构建者能看到这笔交易，也不保证手续费足够、nonce顺序合适。
    以太坊的最终性正常情况下约两个纪元，大约13分钟。如果验证者参与率或网络状况恶化，它就不是一个固定期限。
    二层网络结算因Rollup设计而异。不代表L2打包、向L1提交数据、证明最终性和提现最终性是同一件事。

    二层网络增加了更多时钟

    在以太坊Rollup上，用户可能会看到几个不同阶段：排序器立即确认接收、L2区块打包、数据发布到以太坊、证明或挑战期结束，以及可以提现。正确的结算标准取决于具体的Rollup和应用。不要把以太坊主网约13分钟的最终性数字套用到每一种L2使用体验上。

    小结：出块节奏是结算时间的一个输入，不是服务等级承诺。给出的应当是区间和状态，而不是精确的保证。

    收款方应该等多少个确认？

    简短回答：没有通用数字。收款方应当根据交易金额、所交付商品的可逆性、交易对手风险、链的安全性、当前网络状况，以及自己监控重组和冲突花费的能力来选定门槛。

    一项低价值的数字服务，可以比一家为大额充值入账的交易所或一位交付不可撤回实物商品的商家承受更多的重组风险。具备实时双花监控的收款方，其选择会不同于只依赖某一个第三方浏览器的收款方。服务方的充值入账政策是风险控制手段，并不是对共识规则的直接陈述。

    场景合理的把握程度原因
    低价值、可撤回的服务视链和欺诈控制手段而定，可以接受广播即算、零确认风控，或较浅的打包深度。偶发逆转的代价有限，而且服务本身可能可以撤回。
    普通的链上转账等待被打包，并达到与风险金额相称的深度或safe状态。在速度和常见的浅层重组风险之间取得平衡。
    大额或不可撤回的交付采用保守的确认深度、以太坊最终性，或服务方公布的门槛。一旦被逆转会造成实质损失，且在操作上无法挽回。
    交易所充值遵循交易所针对该资产和该网络的入账规则。交易所会综合评估链的安全性、流动性和大量充值带来的运营风险。
    跨链桥或Rollup提现遵循该跨链桥或Rollup明确的最终性模型。源链打包、目标链铸造和挑战期或证明期是彼此独立的环节。

    比特币的六个确认为什么成了惯例

    六个确认指的是包含交易的那个区块，再加上之后的五个区块，按预期大约一小时，长期以来被用作大额交易的保守惯例。它并没有作为结算常量写进比特币共识。有些服务要求更少；在金额很大、链的安全性较低或攻击动机异常时，有些服务会要求更多。

    以太坊上的服务为什么可能在最终性之前就入账

    有些应用会基于latest或safe区块采取行动，因为等待完全最终性会增加延迟。这是一种有意的风险选择。稳健的系统会记录区块哈希，以幂等方式处理重组，并把不可撤回的下游动作推迟到所需状态达成之后。

    小结：把确认门槛当作经过校准的风险控制手段，而不是从另一条链或另一种业务照搬来的仪式性数字。

    怎样正确地核实一笔交易？

    简短回答：先确认具体网络和交易哈希，再核实它是否被打包进规范区块、确认深度或最终性状态，以及收款方、资产、金额、手续费和执行状态。大额转账要使用不止一个数据来源，也不要把不必要的地址信息透露给随便找到的浏览器。

    比特币方面

    • 确认交易ID和所在网络。
    • 查看交易是未确认还是已被打包进规范区块，并记录区块哈希，而不只是区块高度。
    • 核实每一个相关输出，而不只是显示出来的第一个地址。比特币交易可以有多个收款方，还有找零输出。
    • 如果是在排查延迟，检查手续费和虚拟大小。
    • 查看这些输入是否也被某笔冲突交易花费，以及是否存在未确认的父交易。
    • 计算确认数时，把包含交易的那个区块算作第一个。

    以太坊方面

    • 确认交易哈希、链ID和所在网络。
    • 检查from、to、value、输入数据和代币转账事件；一笔代币转账可能并不体现在顶层的ETH金额里。
    • 查看收据状态。status 1通常表示执行成功；status 0表示已被打包的调用发生了回滚。
    • 查看已用Gas和实际生效的Gas价格，不要想当然地以为签名时设定的最高费用被全额收取。
    • 记录区块哈希，以及你的数据服务商报告的是latest、safe还是finalized状态。
    • 涉及合约交互时，要核实调用的函数、日志和最终状态，而不只是看“已确认”。

    隐私与浏览器风险

    把地址和交易哈希粘贴到第三方浏览器，会暴露你的关注对象，还可能把IP或账户关联的元数据泄露给那家服务商。链上公开数据本来就可见，但你的查询行为是额外的信息。对敏感或机构级的工作流程，应当查询自己的节点或可信的基础设施服务商，避免使用搜索引擎链接或主动送上门的“客服浏览器”。

    小结：核实意味着检查具体的链上对象及其在规范链中的状态，而不是相信钱包通知、截图或复制过来的浏览器标签。

    排查清单

    简短回答：在采取行动之前，先确定这笔交易、所在网络、发送方的nonce序列以及当前的规范链状态。然后选择钱包支持的、针对该链的处理方法。

    • 从钱包复制交易哈希。确认网络和链ID。
    • 查看可信的节点或浏览器能否看到这笔交易。金额较大时使用第二个独立来源。
    • 如果尚未确认，检查手续费参数、依赖关系，以及这笔交易是公开广播的还是走了私有路径。
    • 在比特币上，检查未确认的父交易、当前的sat/vB行情，以及钱包是否支持RBF或CPFP。
    • 在以太坊上，确定账户nonce、最早的待确认nonce、最高费用、优先费用和当前基础费用。
    • 查找是否存在冲突的替换交易：相同的比特币输入，或相同的以太坊发送方加nonce。
    • 如果交易先确认后消失，把它原来的区块哈希与规范链对照，看是否发生了区块重组。
    • 如果以太坊交易确认了但操作失败，检查收据状态、日志和回滚信息。
    • 使用钱包自带的加速或取消功能，不要按客服消息里的任意指示去签名。
    • 绝不要透露私钥或助记词。诊断交易只需要公开的哈希和本地钱包信息，不需要任何密钥材料。

    小结：有条理地检查状态，比反复重新提交、切换网络或照做主动送上门的“找回”指示更快也更安全。

    常见问题

    加密货币里的一个确认是什么意思？

    一个确认通常表示交易已被打包进一个规范区块。在比特币上，包含它的区块就是第一个确认。在以太坊上，被打包对应latest状态；应用还可能继续等待safe或finalized状态。

    手续费更高就能保证进入下一个区块吗？

    不能。有竞争力的手续费能提高预期优先级，但出块时间、依赖关系、nonce顺序、本地策略、私有订单流、MEV和出块方的选择同样有影响。手续费估算是概率估计，不是保证。

    同一笔交易的两个版本会都确认吗？

    花费同一个输入的比特币冲突交易，不可能同时留在同一条有效链上。同一账户、同一nonce的以太坊交易，也不可能在同一条链上都执行。不过，两笔看起来相似但其实并不冲突的付款是可以都确认的，这正是手动重发很危险的原因。

    已确认的比特币交易可以取消吗？

    确认之后没有常规意义上的取消手段。浅层区块重组可以移除一个刚出的区块，但发送方无法申请退款。在确认之前，钱包可以视交易情况尝试RBF或CPFP。

    以太坊交易可以取消吗？

    只有在它还处于待确认状态时，才能通过提交一笔同nonce、出价足以赢下竞赛的交易来尝试替换。如果原交易先确认，取消就失败了。已确认的交易无法通过替换nonce撤回。

    为什么我的以太坊交易给了很高的小费还是待确认？

    可能是前面缺了一个nonce，可能是最高费用无法覆盖当前基础费用加小费，可能这笔交易只有一家服务商能看到，也可能构建者更青睐其他捆绑交易。先解决最早的nonce，并检查所有手续费字段，而不是只看小费。

    比特币交易被从内存池丢弃后会怎样？

    那个节点不再保存它，但其他节点可能仍然保留或重新广播它。只要没有任何版本被确认，这些输入在链上就仍然未被花费。重新使用这笔资金之前，先检查是否存在冲突交易以及钱包状态。

    为什么已确认的交易又变回待确认了？

    它所在的区块很可能在一次区块重组中被断开了。这笔交易可能回到内存池并再次确认，也可能因为在新的规范历史中有一笔冲突交易胜出而变得无效。

    六个确认总是足够吗？

    它是被广泛采用的保守比特币惯例，不是普适保证。合适的深度取决于金额、攻击动机、链的状况和收款方政策。其他链使用不同的保障模型。

    以太坊的最终性需要多久？

    在正常参与率下，大约是两个32时隙的纪元，约13分钟。如果参与率跌破所需门槛，可能更久。被打包通常发生得更早，而且和最终性不是一回事。

    确认数更多需要额外付费吗？

    不会仅仅因为后面又有区块叠加在这笔交易之上，就向发送方额外收费。最初被打包时的手续费只付一次。等待付出的是时间成本，而替换交易则可能需要额外的手续费。

    区块浏览器显示成功，就能证明收款方拿到了预期的代币吗？

    光凭这一点不能。要核实网络、合约、收款方和金额是否正确。在以太坊上，查看代币转账日志和收据状态；在比特币上，查看相关的输出和找零。

    小测验：记住了吗？

    1. 一笔比特币交易已在一个规范区块中，之后还没有新区块出现。它有几个确认？

    A. 零个

    B. 一个

    C. 两个

    D. 取决于钱包

    2. 为什么两个区块浏览器会对一笔交易是否待确认给出不同结果？

    A. 只有一个浏览器连上了互联网

    B. 每个节点都有自己的内存池和数据视图

    C. 交易哈希在不同网站之间会变

    D. 确认是私密的

    3. 子付父费（CPFP）的作用是什么？

    A. 删除父交易

    B. 添加一笔高手续费的子交易，让矿工对这组关联交易的评估更有利

    C. 改变父交易的签名

    D. 保证进入下一个区块

    4. 一笔以太坊取消交易使用了和原交易相同的nonce。结果由什么决定？

    A. 数据字段里写的cancel这个词

    B. 在相关的手续费和路由条件下，哪个有效版本先被打包

    C. 钱包厂商

    D. 由收款方决定

    5. 一笔以太坊交易的收据状态是status 0。这是什么意思？

    A. 它仍在待确认

    B. 它已被打包，但执行发生了回滚

    C. 它支付了零Gas

    D. 它已最终确定

    6. 关于最终性，哪种说法是准确的？

    A. 比特币的六个确认是协议层面的最终性标志

    B. 以太坊的latest和finalized是一回事

    C. 比特币的可靠性随深度增强，而以太坊提供明确的finalized检查点

    D. 已确认的交易永远不可能离开一条链

    答案

    1\. B。包含交易的那个区块就是第一个确认。

    2\. B。内存池和服务商索引都是本地的、彼此重叠的视图，而不是一个全网统一的队列。

    3\. B。CPFP用一笔高手续费的子交易去花费未确认输出，使父交易和子交易在经济上一起变得有吸引力。

    4\. B。“取消”是一场同nonce的替换竞赛；哪个版本先执行，就由它消耗掉这个nonce。

    5\. B。这笔交易作为被打包的对象已经确认，消耗了Gas和nonce，但它本来要做的EVM状态变更被回滚了。

    6\. C。比特币靠深度提供概率性保障；以太坊额外提供safe和finalized协议状态。

    参考来源与延伸阅读

    本文的主要参考资料，更新至2026年7月。

    这有帮助吗？