区块链的“确认”，究竟确认了什么（2026 年 10 月）

1 先说清这笔交易之后要做什么

同一笔付款，界面更新、商品交付和跨链释放资产，承担的风险不同。界面可以先显示“处理中”，随后纠正；已经寄出的商品很难随着区块重组收回；桥在另一条链铸出的资产，可能立即被转给第三个人。后一个动作越难撤销，系统越需要知道前一个结果由谁确认、还有哪些条件没有满足。

因此，本文把一次操作拆成五个可以分别核对的问题。交易是否按规则执行，回答有效性；相互冲突的交易采用什么顺序，回答排序；已有结果在什么假设下不再被替换，回答最终性；其他人能否取到重建或验证状态所需的材料，回答数据可用性；用户能否让下一步动作实际发生，回答结算或退出。它们是条件，不适合加权平均成一个“安全分”。缺少提款所需的数据，不能用更高的吞吐量补偿。

一个具体例子是跨域转账。用户在 L2 发起提款，L2 执行成功，随后批次被收录进已最终确认的 Ethereum 区块。此时能确定那份批次材料已落在 L1 的历史里；提款合约仍可能要求一个可接受的状态声明、一段等待时间和一次最终执行交易。L1 确认了材料的存在，状态转换的正确性和提款资格还要沿各自的验证路径判断。

后文采用三个研究问题。第一，各种状态模型怎样限制冲突，并让不同节点得出同一结果？第二，用户从一条回执走到可独立验证的结果，依赖哪些网络、数据和权限？第三，吞吐量、低延迟与低费用的证据，能支持多大的应用承诺？比较以具体交易和失败条件为单位，保留协议假设，避免把理论安全界限、客户端优化和生产部署状态揉成一个结论。

这也给“更好”划出了可以反驳的范围。若一个应用必须在运营方离线时自行恢复状态并完成退出，依赖运营方私有数据的方案就不满足它的要求。若应用只需要同一条链内频繁更新少量独立状态，额外承担跨层证明和提款的复杂性可能没有收益。需求变了，结论可以变；性能广告上的第一名不能替产品做这个决定。

2 签名被接受，账本才开始工作

签名首先证明某个密钥授权了这段消息。它没有证明消息描述的余额存在，也没有证明收款合约会按用户想象的方式运行。节点还要根据当前状态检查输入、序号、费用和执行规则。钱包中看起来相似的“发送”，在 UTXO、账户和对象模型里，指向的东西并不相同。

在 Bitcoin 中，交易花费的是已有的未花费输出，通常称为 UTXO。假设一个输出有 10 个单位，用户支付 6 个单位、手续费 1 个单位，就需要安排剩余 3 个单位的找零输出；协议不会替他保留一个可反复扣减的原始输出。输入通过交易编号和输出索引指向旧记录，验证脚本提供花费授权。接受新交易时，旧输出被消费，新输出成为之后可以花费的对象。

Bitcoin Core 31.1 的 CheckTxInputs() 会拒绝缺失或已经花费的输入，检查 coinbase 成熟条件与金额范围，并要求输入足以覆盖输出。随后 ConnectBlock() 的相关路径处理序列锁、脚本检查和 UTXO 更新。矿工对顺序有选择权，节点对有效性仍有自己的检查；增加工作量不会使凭空创造金额的交易通过这些规则。

这种设计把两次花费之间的冲突表示得很直接：它们指向同一个旧输出。两个互不相干的输出可以分别检查；同一个输出的两次花费，最后至多接受一笔。UTXO 也会把复杂业务拆成多个输出与脚本条件。它给了应用显式组织依赖的机会，同时要求钱包处理找零、输出选择以及交易图，而账户界面往往把这些细节隐藏了。

Ethereum 的常见操作则从账户状态出发。普通外部账户用 nonce 表示交易序号，交易携带目标、金额、调用数据和费用限制；合约执行可以读取和改变很多存储位置。一次交易调用交易所合约，后者再调用代币合约，最终余额变化取决于完整调用过程。合约地址相同、函数名相同，也要配上具体链、代码版本和执行时的状态才能解释结果。

这里最容易误读的是失败交易。Geth 1.17.7 的 状态转换路径在调用虚拟机前处理发送者 nonce；EVM.Call() 为调用建立状态快照，执行错误时恢复相应状态。应用调用回滚以后，交易仍可能已经被纳入区块，并消耗 nonce 和费用。把“合约没有完成转账”理解成“网络没有处理过这笔交易”，会在重试和会计对账时出错。

Move 进一步把资源使用规则放进语言和验证器。具有相应能力限制的资源不能随意复制或丢弃，模块控制资源如何创建和转移。这能约束一类资产误用，却不会自动验证交易所定价、权限配置或跨链消息是否正确。Aptos 和 Sui 都使用 Move 技术，存储组织与交易处理仍有明显差别：语言提供的保证，需要与链上状态模型一起理解。

三种模型都需要防止同一份权利被重复使用。UTXO 引用旧输出，账户检查序号并修改存储，对象模型跟踪对象身份、版本和所有权。它们为下一步的并行处理提供了不同的信息。能提前知道哪些状态会冲突，就能更早安排执行；不知道完整访问集的系统，则需要在执行后检查自己有没有读到过期结果。

3 多核能加速什么

设有两笔交易 T1 和 T2。T1 把账户 X 的余额从 10 改成 7，T2 要从 X 支付 8。如果两个线程都先读到 10，各自判断余额足够，再直接写回结果，账本就失去了统一含义。增加核心数之前，执行器必须保证并行结果等价于协议认可的某个顺序。另一组交易分别改 X 和 Y，且相互没有依赖，就有机会真正同时完成。

Solana 把账户访问声明放进交易消息，标记哪些账户可写、哪些只读。调度器因此能在运行程序前发现冲突。当前 Agave 固定版本中的账户锁实现，要求写访问与其他读写访问互斥，多个纯读访问可以共存。程序调用的权限也受传入账户及可写标记约束。访问列表使执行器少做猜测，但应用若把每笔交易都导向同一个可写账户，热点仍然存在。

这解释了“链支持并行”和“我的合约能并行”之间的距离。把一万个用户的操作都记到一个总计数器里，会制造共享写入；把可以独立处理的状态分散到不同账户，则给调度器留下空间。拆分需要守住业务不变量：若两个账户必须同时满足同一个总量约束，应用还要安排一致性检查，不能靠拆存储位置绕过真实依赖。

Aptos 的 Block-STM 论文选择另一条路径：先给区块交易一个确定顺序，再并行推测执行。线程读取的是排在自己前面的交易写出的最新可用版本，同时记录读集合。验证阶段检查这些读取是否仍成立；如果更早交易后来改变了结果，受影响交易重新执行。最终对外提交的状态，要与预定串行顺序一致。

回到 T1、T2 的例子。T2 可能先按余额 10 算出一次支付，T1 随后产生余额 7。读验证发现 T2 用的是旧版本，于是撤销这次推测并重算；第二次执行会看到余额不足。中间那次“成功”属于执行器内部的试算，不能作为用户可依赖的链上结果。Block-STM 还处理被撤销写入的估计标记和等待关系，防止线程把暂时缺失的版本误当成最终不存在。

这种方法让程序不必总能事先给出精确读写集合，也能利用低冲突负载的并行性。代价随冲突率变化：大量交易反复修改同一位置，就会增加失效、等待和重算。论文也讨论了费用累计等公共状态如何变成瓶颈，以及可交换操作怎样减少不必要的串行依赖。这里存在真实的算法收益；并行执行本身无需把验证权交给另一个受信任机构。

Sui 则把对象依赖更直接地交给系统。对象带身份、版本和所有权信息，交易声明使用哪些对象。拥有互不相干对象的操作，不必为了彼此不存在的冲突排进同一条串行队列；共享对象上的冲突写入仍需要一致顺序。早期 Lutris 论文用单所有者快路径与共享对象共识路径解释这个分工，并讨论用户对同一对象版本签出冲突交易时的锁定和 epoch 恢复。

2026 年的 Sui 已继续演进。Mysticeti v2 把交易验证并入 DAG 传播与投票，减少旧流程中的单独认证轮次；当前 Transaction Driver 再收集足够权重的一致执行结果。效果确认代码按 effects digest 分组累计验证者响应，达到 quorum 后才返回该摘要。不能把某个验证者执行完、交易得到足够认证和进入已认证 checkpoint 当成同一个观察点。

对象模型也没有冻结在早期论文里。Sui 1.72 引入 address balances，余额可以通过系统结算处理增减，费用支付还可能混合地址余额和 coin objects。2026 年 5 月的官方故障复盘显示，竞争支出导致取消以后，混合 gas 处理仍扣除了相关余额，随后结算出现下溢。语言资源约束、调度和费用结算必须一起正确；“对象可并行”无法替代这条完整路径的检查。

因此，评估高性能链应先拿出应用最热的那份状态。交易分散、操作简单时，网络可能轻松利用多核；交易集中抢同一池流动性、同一订单簿价位或同一资源时，要观察等待、重算、拒绝和尾延迟。平均每秒处理多少笔，解释不了最拥挤的那一笔为什么迟迟没有完成。

4 网络如何决定保留哪个结果

执行器能给定输入算出一致结果，网络仍可能同时看见两份合法历史。两个 Bitcoin 矿工几乎同时找到新区块，或者两个分支包含相互冲突但各自合法的花费。节点需要选择继续扩展哪一份历史；收款方还需要判断，自己看到的结果被替换的可能性已经降到什么程度。这是分叉选择与最终性的问题。

Bitcoin 白皮书把竞争放在累计工作量上。攻击者要追上诚实链，需要补足已经落后的工作；在其算力比例低于诚实方等模型条件下，落后越多，追上的概率越低。常见的确认数策略由此而来。六次确认是一种风险选择，协议不会在第六个块突然给交易盖上一枚绝对不可更改的印章。

源码中的选择对象也有条件。Bitcoin Core 的 FindMostWorkChain()会排除缺少必要数据或沿途已知无效的候选。多数算力能影响交易包含、审查和重组，却不能使正常验证规则下的节点接受任意伪造签名。应用若把算力攻击简化成“能改账本上的任何字段”，就把分叉选择权和规则修改权混淆了。

PoS 系统用权益权重安排提议和投票。Ethereum 的 Gasper 将 LMD-GHOST 分叉选择与 Casper FFG 检查点最终性组合起来：前者决定当前沿哪个分支前进，后者用足够权重的投票确定检查点之间的关系。当前主网每 slot 12 秒、每 epoch 32 个 slot；正常最终性节奏还依赖投票及时到达，slot 长度本身并不等于交易最终确认所需时间。

理解三分之二门槛，可以先看一个固定验证者集合。两组各至少三分之二权重的投票，交集至少三分之一。若协议禁止诚实验证者对冲突条件双投，那么出现冲突最终结果就意味着这部分约束被破坏。Gasper 论文进一步给出可罚没的投票条件和安全性分析。这个交集推理有明确对象：某个协议、权重集合和投票规则，不能直接推广成所有 PoS 网络共有的安全承诺。

停止投票与投出冲突票又是两种故障。足够多权重暂时离线，会让最终性停滞，即使节点仍能产生或观察新区块。Ethereum 的 inactivity leak 逐步扣减长期不参与者的余额，使继续参与的一方重新占到足够权重。长期分区时，两边可以在各自视图里经历这个过程，恢复因而需要更复杂的社会协调。罚没能够建立违反规则的成本与证据，无法让两边完全隔绝的参与者凭空知道哪一边代表外部世界。

长期离线节点还面对另一种时间问题。旧验证者退出后，其旧密钥可以签出看似自洽的历史；新节点只读一条长签名链，未必知道自己面对的是哪一个社会认可的起点。Ethereum 的弱主观性检查点要求节点从近期可信状态进入同步。这个外部起点与之后独立验证区块的能力可以同时存在，产品需要说明自己从哪里取得它。

留下来的历史，还会把交易顺序造成的得失一起固定下来。自动做市商的资金池中，一笔买入先改变储备，后一笔买入就面对新的价格；两笔交易都符合协议规则，交换顺序仍可能改变各自拿到的数量。MEV，即最大可提取价值，涵盖出块时通过选择、排除和重排交易取得的额外价值，其中既有套利、清算，也有恶化其他用户成交的行为。最终性固定了执行结果，应用还要另行检查用户允许的成交条件。只检查交易成功和确认数，会漏掉用户究竟接受了什么价格。

在 Ethereum 当前的可选 MEV-Boost 路径中，构建者组织交易并出价，中继核验区块及支付条件，提议者先签含载荷头的盲区块，再取得完整执行载荷。Flashbots 对中继职责的说明明确包含有效性检查、费用核对和数据交付。这让提议者可以采用外部构建的区块，也增加了对中继正确核验、及时交付的依赖。签名时承诺的载荷头与之后收到的完整内容必须对应；收到完整内容以后，区块才能继续传播。投票门槛、成交顺序和这段交付过程，分别回答不同的问题。

当前部署也必须与论文分开。截至本文核查，Ethereum 的下一次 Glamsterdam 升级仅公布了 10 月 6 日 Sepolia 测试网安排，主网时间尚未确定。官方公告中的 ePBS、Block-level Access Lists 等变化不能提前计入当前主网能力。论文解释某种设计成立的条件，客户端包含代码说明可以准备部署，主网激活才决定今天的交易经过哪条路径。

5 更快的确认，各自依赖谁

Solana 的 RPC 直接暴露了确认层次。processed 表示节点处理过某个块；confirmed 表示该块得到超过三分之二活跃权益的直接投票；finalized 对应达到最大锁定程度的集群最终状态。官方接口说明与 Agave 4.3.0 的选择逻辑可以相互对照。同一个查询换一个 commitment，读到不同高度，可能正是接口在履行约定。

当前主网的 Tower 投票锁定使验证者随着后续投票逐步强化对分支的承诺。PoH 提供可检查的时间与顺序结构，最终接受哪段历史仍依赖权益投票及相关规则。把 PoH 单独叫作整个共识，容易漏掉谁有投票权、分叉如何处理，以及节点为什么要等待更高的 commitment。

Solana 的 Alpenglow 是重要的后续变化，却还不属于本文观察时点的主网保证。官方状态页列出测试网和开发网已激活，主网未激活；2026 年 10 月 2 日 16:53 UTC 的官方主网 RPC 返回 Agave 4.3.0，getAgGenesisCert 返回 null，同次查询的 finalized slot 为 452,669,790。两类证据一致。新客户端版本已经发布，不足以把论文或路线图上的亚秒级目标写成全部主网交易的实测结果。

Sui 的 Mysticeti 使用有向无环图传播区块和投票关系，让网络在传播业务数据时也推进共识。DAG 中的引用提供投票信息，达到协议条件后决定哪些领导块被提交或跳过。论文中的静态委员会模型在固定 epoch 内使用 n = 3f + 1 个验证者、至多 f 个拜占庭验证者和部分同步等条件讨论安全与活性；生产实现还要完成执行、效果确认、checkpoint 和 epoch 切换。减少一轮通信是有意义的优化，仍需说明测量停在了哪一步。

本文在 2026 年 10 月 2 日 17:06 UTC 读取 Sui 官方 GraphQL：checkpoint 329,496,957、epoch 1268、协议版本 137，mysticeti_fastpath 为 true。这为当前配置提供一个可复核观察点。它没有测量全球节点延迟，也没有证明所有交易都使用相同快路径；共享状态、错误处理和重配置可以走到不同分支。

Aptos 也要把执行器与共识分开。Block-STM 负责按已确定顺序计算区块，不能独自决定网络接受哪个区块。2026 年 10 月 2 日 17:06 UTC，官方主网接口返回的链配置，按固定版本的 算法枚举和配置版本布局解码，前缀对应 V5 / JolteonV2。这次请求没有指定 ledger version，记录的是该时点的接口响应。节点发布页上的版本号、框架升级提案和一篇新共识论文，各自描述不同层面的状态。

这份配置同时启用了 order vote。沿固定实现看，每轮提议者给出区块与父块证书，接收者核对提议者、轮次、证书和投票安全条件；足够权益对同一结果签名后形成 QC，即法定人数证书。收到新 QC可以触发另一类针对排序的投票，通过安全检查且聚合到足够权益后形成 ordered certificate。这份证书把已经确定的区块路径交给执行器；执行结果随后通过 commit vote 与已排序的区块信息绑定。排序认证和执行结果认证因此有各自的步骤，Block-STM 加速其中的计算。

提议者失联时，验证者收集超时投票形成超时证书，推进轮次后再由相应提议者继续。新提议仍受已有证书和安全轮次约束；安全规则还保存投票状态，并限制已经超时的轮次再次产生排序投票。这些条件使“换一个人继续出块”与“可以另写一条冲突历史”区别开来，也解释了为什么正常路径的低延迟不能覆盖失联、换轮和执行滞后的全部情况。

BNB Smart Chain 将 Parlia 出块与快速最终性投票结合。当前源码中的 GetFinalizedHeader()既可读取已经进入链上记录的证明，也能利用本地 vote pool 中足够数量的投票更早识别最终状态。BEP-648优化的是观察与确认路径。发布者报告正常条件下约 0.65 秒达到最终性；应用通过不同 RPC 或等待链上可验证证据，未必在同一时刻看到同一个状态。

TRON 的 27 位活跃超级代表按时隙轮流出块，协议默认时隙为 3 秒。固化高度的计算查看各代表最近出块高度：在 27 个活跃代表的集合中，至少 19 个不同代表已经在某高度或其后出块，才把对应高度推进为固化。实现中的排序与取位比“等 19 个块”更准确；反复由少数代表出块并不能代替不同代表的确认。代表集合与部分网络参数又受投票和维护周期影响。

这些系统可以给用户很快的反馈，支持反馈的证据形态却不同：本地处理状态、权益直接投票、投票锁定、DAG 提交、效果摘要、代表节点固化。真正有用的接口会把这个状态名称、对应高度与错误结果一起给应用。只返回一个不带含义的绿色成功标记，会把协议已经认真区分的风险重新混在一起。

6 你能不能自己检查

多数用户通过 RPC 查询余额。RPC 返回一份 JSON，意味着服务向用户报告了某个结果；能否独立检查这个结果，取决于用户另外掌握什么。换三家供应商可以降低单点故障和错误报告的风险，三家若共享同一上游、同一缓存或同一客户端缺陷，独立性就会小于表面的数量。

Bitcoin 全节点维护并验证自己接受的有效链。轻客户端可以检查区块头工作量，并用 Merkle 证明判断交易是否包含在某个块中；它没有因此执行块内所有交易、检查所有历史输入。白皮书的简化支付验证本来就保留了这层区别。使用近期快照、裁剪旧块、保留完整历史或验证启动阶段的假设，还会形成不同的运行与恢复成本，不能统一归为“运行了节点”。

Ethereum 的轻客户端同样需要一个可信起点。固定规范中的 初始化流程先把 bootstrap 区块头与 trusted_block_root 对齐，再验证同步委员会的 Merkle 分支。之后的更新检查核对时间、委员会周期、最终性分支与 BLS 聚合签名。轻客户端缩小了需要下载和验证的材料，也明确依赖委员会抽样、起始检查点和更新规则。

“验证了证明”还需要说清证明的命题。Merkle 证明可以说明某个值属于一个承诺根；它不自动说明这个根代表诚实执行的最新状态。同步委员会签名证明委员会对区块头的支持，执行有效性要沿协议的其余条件理解。若应用选用乐观头或在长时间无最终性时强制推进同步，其风险也要与正常最终头区分。规范分别维护 optimistic 和 finalized 状态，正是为了让使用者作这个选择。

数据可用性带来另一组问题。一个提供者可以公布某批数据的哈希，却拒绝交出原文。哈希能在拿到原文后检查它是否匹配，无法从一个短摘要恢复所有数据。Rollup 若要让其他人重新执行交易、生成挑战或恢复状态，就要保证必要数据能被取到。一个正确性证明与一份可下载的数据，解决的是两个不同障碍。

Ethereum 的 PeerDAS 用纠删编码和分布式取样降低每个节点承担的下载量。EIP-7594及 Fulu 数据可用性规范把 blob 扩展为可验证的数据列；节点保管和抽取部分列，达到足够列数后可以重建。KZG 证明帮助检查取到的单元与承诺相符，取样与网络传播提供数据可获得性的依据。伪造一个单元和扣住一部分单元，是两种不同威胁。

这种概率与网络假设不能省略。抽样依赖足够多、分布合理且能够互通的节点；提供者针对不同观察者选择性供数、节点分区或托管集中，会影响应用真正取得数据的能力。当前规范也规定了保管与裁剪窗口，主网配置中的 4096 个 epoch 大约相当于 18 天。它不是永久归档承诺。长期审计、灾难恢复和后来加入的执行节点，还需要自己的历史数据来源。

所以，一个准备托管长期资产的系统，应把“今天有人证明数据可用”和“半年后我能重建相关状态”分别设计。前者可以由共识与取样机制支持，后者涉及归档、快照可信性、索引以及恢复演练。只保留交易哈希，往往不足以重建一次复杂合约调用的输入、代码与历史状态。数据保存的费用没有消失，只是可能没有出现在用户那一笔 gas 账单里。

7 把计算搬走以后，谁来检查结果

在 Ethereum 主网上，每个验证执行层状态的全节点都要按规则处理区块。Rollup 将大量执行放到另一套系统，再把数据、状态承诺或证明交给 Ethereum。用户因此可以得到更低的单次执行成本；L1 承担的工作也发生了变化。比较时需要沿着一笔交易问：L1 到底收到了什么，又检查了什么？

先看 OP Mainnet 一类派生链的常见过程。排序器收到交易，运行执行器，给用户一个快速结果；批次随后被发布到 L1，其他节点依据 L1 数据重新派生 L2 区块。节点据此区分 unsafe、safe 与 finalized 头：排序器单独提供的最新结果，比已经具备 L1 派生材料的结果更容易被替换；相关 L1 历史完成最终确认，又增强了数据顺序的稳定性。三个状态描述派生链的进展，提款合约对状态声明的接受条件还在另一条路径上。

乐观证明系统允许参与者提交状态声明，也允许有条件的挑战者指出错误。假设双方同意起点状态与输入，却对执行后的根不同意，就可以不断缩小有争议的计算范围，最终把可判定的一步交给 L1 合约。这样，L1 不必每次重做整批普通执行。安全条件包含一个现实参与者：有人取得数据、运行正确实现，并在期限内承担发起和继续争议的费用。

Arbitrum BoLD 将挑战组织成可以并行处理的竞争，限制恶意方靠反复开启争议拖延确认的能力。它保留“至少一个诚实参与者”这一条件，同时需要保证该参与者有数据、资金和及时向父链提交交易的机会。官方说明的普通挑战期与最坏争议处理上界是两种时间：后者包含两个挑战期、安全委员会干预宽限及计算余量。把其中一个数直接展示为所有提款的到账时间，会丢掉路径差异。

排序器能否拒收交易，属于另一件事。Arbitrum 的 Delayed Inbox 让用户把消息送入父链；达到规定等待条件后，forceInclusion()核对延迟、消息索引与累积承诺，把消息推进序列。强制包含需要父链可用、用户能支付费用、正确构造消息，并完成之后的执行与结算。它是停机或审查时的一条替代入口，使用成本和体验与正常排序器通道不同。

OP 系列的 L1 deposit 路径也承担类似的强制入口职责，派生规则会处理排序窗口和缺失批次。普通用户通过前端点击“提现”，通常没有走过这条恢复路径；产品若承诺运营方失联时仍可退出，就要具备离开前端后的消息构造、数据取得和证明能力。地址别名、消息发送者与目标合约检查也必须保持一致，不能把两个域中相同的十六进制地址直接视为相同调用身份。

有效性证明把检查方式改为：证明者为一段计算生成证明，L1 验证器检查这份证明是否符合指定程序与输入输出承诺。接受证明后，不需要再等待某个人主动指出同一段执行错误。但证明程序可能描述错了状态转换，电路或验证器可能有实现缺陷，升级权限也可能改变以后接受的程序。系统减少了某种在线挑战依赖，同时把证明系统、实现正确性和部署配置推到了更重要的位置。

ZKsync Era 的官方生命周期把 L1 批次区分为提交、证明和执行，提款还须等待可接受的执行状态。其安全延迟说明将最低执行等待从 21 小时改为 3 小时，同时明确保留批次聚合、证明生成和执行调度的额外时间。这个延迟为发现异常与治理冻结留下机会。证明可以已经正确生成，而用户尚未到达领取资产的那一步。

“ZK”也不会自动带来隐私。若交易输入和状态变化被公开发布，旁观者依然可能看到地址、金额和调用关系；零知识属性能否隐藏某种信息，取决于具体证明陈述及公开输入。类似地，validium 把数据放在链外后，即便状态转换附有有效性证明，用户仍可能因为拿不到必要材料而无法重建或退出。Arbitrum One 的 Ethereum 数据发布路径与 Nova 的委员会数据路径，也应分别评价，不能因为同属一个品牌而合并保证。

这些差别对链上交易用户的意义很直接。在 L2 内进行下一次合约调用，往往无需等待向 L1 提款的全部条件；把这笔收益拿去在另一个域里发货、偿债或释放抵押，则需要更强的确认。应用应让自己的不可逆动作，等待与该动作匹配的证明和结算状态。把所有操作都拖到最长等待期会损害体验，全部按排序器回执完成又会承担额外风险。

8 Base 的提款，为什么有不止一个时钟

Base 很适合说明一份“主流 L2 对比表”怎样迅速过期。它在 2026 年 5 月启用 Azul 独立升级，6 月 Beryl 缩短证明等待，9 月 30 日 Cobalt 又改变 TEE 签名者注册方式。官方升级表把这三次列为已生效；计划中的 Denim 才准备引入 200 毫秒 canonical blocks。今天的 Flashblocks 预确认与未来原生区块，不能共用一个没有状态说明的速度标签。

现行证明设计接受两种来源。TEE 路径在 AWS Nitro Enclave 内重新执行区块范围，由注册密钥对结果签名；ZK 路径使用 SP1 程序为结果生成证明。前者依赖受保护执行环境、远程证明、允许的程序镜像和签名者注册，后者依赖所证明程序、证明系统及验证器。两种证据可以相互补强，但不能简单按“证明数量”判断独立性：共同的状态转换错误或错误输入承诺，仍可能影响两条路径。

固定源码中，TEEVerifier从证明材料恢复签名者，检查注册状态和预期镜像等约束。Cobalt 将注册用的远程证明检查移到链上，调用者可以观察证书、镜像与公钥如何被接受。硬件厂商证明链仍是这条路径的信任来源；把检查过程搬进智能合约，没有自动移除硬件与签名身份的假设。

本文读取了 Ethereum 已最终确认的区块 26,106,155，时间为 2026 年 10 月 2 日 17:33:11 UTC。这个固定状态里，Base 的受认可 game type 为 621，对应实现 0xef9ecea15265321753047ebf7d54c858d53cb94f；单类证明的等待参数为 432,000 秒，两类证明为 86,400 秒，证明数量门槛为 1。它们分别是 5 天、1 天与至少一类有效证明，和 Beryl 后的官方规则相符。这里记录的是公开节点返回的只读合约状态，原始请求、响应与区块哈希保存在附录快照中。

这些数值控制一个状态声明何时可以解决。固定实现中的 resolve()还检查父声明、计时和争议结果；证明状态更新函数在证明加入、被反驳或验证器失效后调整预计解决时间。第二类证明较晚加入时，能缩短到什么时点取决于当时已经经过的时间。正式部署的参数由链上读取确认，本文所固定的源码还含未来升级分支，未把整个仓库 HEAD 当作已完成字节码比对的部署证明。

用户的提款还要通过 Portal。先在 L2 发起提款，再在 L1 提交它属于某个状态根的证明，最后调用最终执行。所选状态声明须被系统接受，证明需要成熟，暂停和重放检查也必须通过。同一固定区块里，Portal 的证明成熟参数为 86,400 秒，AnchorStateRegistry 的额外最终性延迟为零，Portal 未暂停。证明计时和状态声明计时可以重叠，也可能因为较晚证明、换用另一个声明或争议而延后，不能将两个数字机械相加。

用这组参数算一个条件示例就清楚了。假设某个已包含提款的状态声明在 t0 获得第一类证明，预计解决时间为 t0 + 5 天；第二类证明在两天后到达，代码取 min(当前时间 + 1 天, 原预计时间)，于是改为 t0 + 3 天。若用户到 t0 + 2.5 天 才向 Portal 提交提款证明，这个证明的成熟时间是 t0 + 3.5 天。两项时间条件要到较晚的时点才同时满足，父声明被接受、没有暂停和争议等条件仍须成立。这是固定参数下的计算示例，未测量一笔真实提款耗时。

最终执行也值得单独检查。Portal 发出的目标调用可以失败，消息或资产的最终可用状态还取决于上层 messenger、桥和目标合约怎样处理结果。提款规范因此保留了发起、证明和完成三个动作。第三方流动性桥可以先在目的地垫付，再自行等待协议结算；用户得到更快资金的同时，增加了桥、资金提供者和对应资产路径的风险。

协议还有能处理紧急问题的管理者。固定块的 Safe 查询显示，外层管理 Safe 需要两名持有人共同同意；这两名持有人分别是 Coinbase 的 3/6 Safe 与安全委员会的 8/11 Safe。它是嵌套的两组门槛，双方都要满足各自条件。职责说明再把这些主体与升级及紧急控制相连。地址数量只描述钥匙集合，实际机构独立性、密钥托管和组织相关性还需另外调查。

这项观察改变了怎样评价 Base：可以确认它具备具体的证明与退出机制，也应把当前证明参数、硬件路径和管理权一起纳入信任模型。准备长期持有资产的应用，要关注自身能否取得数据、在替代通道提交请求，以及谁能暂停或改变退出条件。单看“基于 Ethereum”或“提款一天”，都不足以回答这些问题。

9 跨链以后，两边都要有答案

一笔原生转账只需让一个状态机认可结果。跨链转账通常先在 A 链锁定或销毁资产，再让 B 链接受一条关于 A 链的消息，随后释放或铸造对应资产。B 链必须判断消息来自哪里、是否确实发生、是否已经处理，以及 A 链的结果是否足够稳定。桥把原本分开的两套故障条件连到了一次用户操作上。

Cosmos/IBC 提供一个清楚的实现例子。这里的 Cosmos 是生态与协议集合，各链有自己的验证者和治理，不能把它当成一条共享全部安全性的链。常见的 Tendermint 轻客户端在接收链上保存对方的可信状态，验证后续区块头与验证者集合变化；中继者负责搬运区块头、数据包和证明。中继者可以延迟工作，正确运行的客户端仍会拒绝与可信根不符的证明。

轻客户端更新需要核对可信验证者信息、时间与有效投票关系；客户端状态检查会识别冻结和过期。信任期需要短于解除绑定期，才能在旧验证者不再承担相应约束之前更新信任。一个长期没有更新、已经过期的客户端，无法无限期凭旧根接受新消息；恢复路径取决于该链实现与治理。

数据包本身也有状态机。ibc-go 11.2.0 的 RecvPacket()检查通道和连接状态、对端标识、超时边界、成员证明以及重复接收。有效区块头只建立了一个可验证的根，数据包还须证明自己属于那个根，并满足当前通道的处理条件。证明链上存在任意一段字节，不代表目标应用应当执行这段字节。

异步过程意味着两边不会在同一瞬间完成。接收方成功处理后产生确认，发送方随后根据确认结束等待；若在可证明的超时条件下仍未接收，则走相应的超时处理。超时通常仍需要另一笔交易和正确证明，用户关掉页面不会自动撤销已经发生的源链操作。应用必须区分等待中、成功确认、可退款和退款已完成，才能避免把暂时停在中间的资产记成丢失或重复可用。

轻客户端路径的主要风险落在源链共识、可信起点、更新规则、证明与应用实现上。由一组签名者见证跨链消息的桥，则额外依赖那组签名者正确观察并授权。依赖流动性预付的桥还面对资金容量与结算失败。三种方案可能有相似的按钮和到账速度，却把“凭什么放款”交给了不同的证据。

资产名称又增加一层混淆。目的链上的某种代币，可能是发行方直接发行的资产，也可能是锁仓凭证、多跳桥的凭证或流动性平台提供的替代资产。链的共识只检查该代币合约按规则执行，无法替用户保证链外储备、赎回资格或发行方的冻结政策。识别资产时，应沿具体合约地址追到发行、锁仓和赎回关系；同一个 ticker 不提供这条证明。

因此，若业务只是链内频繁交互，跨链不应被当作默认的免费扩展。确实需要跨域时，先选择能够解释源链确认、消息验证、目标执行和失败回收的完整路径，再比较费用。少一跳可以减少一个证明与恢复环节，但不会自动使剩余的桥可靠；每个环节仍要独立成立。

10 发生故障时，谁能让系统继续走

形式化共识通常讨论一定比例的节点恶意或离线。生产系统还会出现另一种故障：大多数节点运行同一个错误实现，收到相同输入后一起卡住。此时节点数量再多，也没有产生足够独立的行为。评估分散程度，要看权益与运营者，还要看代码、云服务、构建和更新路径是否相关。

Solana 对 2024 年 2 月 6 日停机的官方复盘记录了这样一条路径。LoadedPrograms 缓存中，旧 loader 对部署 slot 的特殊值与被移除程序的真实 slot 发生冲突，触发反复加载、编译的循环。当时超过 95% 的活跃权益使用受影响的 1.17 系列，网络因共同实现问题停止推进。恢复通过 1.17.20 的临时限制和协调重启完成；这是历史事故的修复边界，不能据此声称今天的版本仍受该缺陷影响。

Sui 2026 年 1 月的停机复盘呈现另一种保护效果。共识垃圾回收与冲突交易的交互让验证者形成不同的 checkpoint 摘要，足够权重无法认证同一结果，系统停在认证阶段。RPC 仍能报告最后已经认证的状态，新状态没有继续获得认证。钱包查得到旧余额与网络正在推进是两件事；只检查 HTTP 200 的监控会错过这种故障。

5 月的连续停机又说明，修复一个执行分支还可能漏掉恢复状态。地址余额的混合费用路径出错后，某些取消交易仍产生扣费，导致后续系统结算下溢。临时补丁按特定取消原因绕开扣费，另一个覆盖错误原因的分支又让问题重现。随后重启遇到分布式随机数生成失败状态没有持久化，待处理交易既不能正常完成，也不能按原失败状态取消，epoch 清空过程继续等待。复盘中的三个故障把执行、取消、持久化和重配置连在了一起。

这些事故支持一个可检验的工程判断：恢复能力必须覆盖“程序在中间停下，然后重新启动”的状态。只测试一笔成功交易与一个明确拒绝的输入，不能验证暂停后留下的锁、未确认效果、待结算费用和 epoch 交接。历史事故也不能直接变成各链今天的故障率排名；发布者披露的范围、观察年限与业务损失口径并不相同。

Rollup 的恢复还涉及能修改 L1 合约的人。OP Mainnet 的当前安全安排区分基金会与安全委员会，并为暂停、状态声明处理及升级保留权限。Arbitrum 的现行宪章允许安全委员会以 9/12 门槛执行紧急动作；常规治理路径有投票和执行延迟。组织承诺规定什么时候应当动用权力，合约权限决定技术上能够做什么。两者都值得读，不能互相代替。

紧急权限有真实收益：证明系统出现漏洞时，暂停可以阻止错误状态迅速兑现成资金流出。同一权限也意味着，用户的正常退出可能等待管理者解除限制，或在升级后面对新规则。若协议存在即时紧急升级，常规时间锁就无法给所有变更提供同样的退出窗口。把暂停、升级、证明作废和资金转移权限分别画出来，比给它们统一贴一个“去中心化”标签更能解释风险。

基础链的升级则主要依赖客户端实现、验证者采用和更广泛的社会协调。代码合并不等于全网切换，少数节点升级也不等于规则已经激活。应用自己的节点和 RPC 提供者若停在不同规则或不同高度，会产生看似正常的响应分歧。一个可用的恢复方案需要知道可信的链头从何取得，状态怎样校验，客户端如何升级，以及何时重新接受不可逆业务。

还有一个常被忽视的失败：所有链和桥都正确运行，应用仍然记错账。索引器漏了重组回滚，重试重复执行了外部付款，或者把目标调用失败当成跨链业务成功，都会在协议外制造损失。协议给出的状态与证明，应成为应用会计和幂等处理的输入。链的最终性无法修复已经错误发出的第二次银行付款。

11 把 TPS 还原成实际做过的工作

读完前面的处理过程，再看性能数字就容易发现问题。一份论文测执行器每秒算完多少笔交易，另一份测共识每秒传播多少条消息，第三份把一笔交易里的 100 次转账计成 100 次操作。它们都可能如实报告实验结果，拼成同一列 TPS 后却失去了共同单位。

Block-STM 论文报告 Aptos 执行环境在特定低冲突负载下达到约 170,000 笔每秒，Diem 环境约 110,000 笔每秒。实验使用 AWS c5a.16xlarge、32 个物理核心、128 GiB 内存，围绕合成点对点转账改变账户数与块大小，重复运行。测量重点是并行执行，结果持久化没有计入该吞吐量，网络传播和共识也不在同一终点。这个数字很好地支持执行器能利用并行性，无法独自支持端到端到账速度。

原论文的反例同样重要。高度竞争的两个账户让并行收益明显收缩，调度与验证开销仍然存在；较分散的账户集才给线程留下更多独立工作。论文还给出串行对照和不同线程数。若应用是一万人争用同一流动性池，应该先看冲突实验与尾延迟，再看低冲突峰值。把最有利负载当作所有业务的默认性能，恰好避开了选型最需要回答的问题。

Mysticeti 的原始共识实验则使用 512 字节消息，在跨区域节点之间测量排序提交，包含日志等实现成本，但不等于完成生产虚拟机、状态写入和用户效果确认。论文另做了一组私有 Sui 网络集成实验：137 个验证者、每秒 5,000 笔输入、指定机器和区域条件下，报告约 650 毫秒 p50 与 975 毫秒 p95。它比原始共识吞吐量更接近应用路径，仍然是那次受控配置的历史结果。

Lutris 论文中超过 150,000 次操作每秒的演示，又采用了每笔可编程交易包含 100 次转账的批处理。因此大约 1,500 笔这样的交易，就构成每秒 150,000 次转账操作。实验基于当时的 Sui 1.4.3、100 个验证者、专门的负载发生器和持久化存储条件。批处理能摊薄签名与调度成本，是有价值的工程设计；比较时也必须保留交易与操作这两个分母。

三组原论文结果回答的不同问题；数值均为论文报告，未由 SOSEC 重跑。

生产指标还有不同的分母。共识投票、系统交易、失败交易、用户交易和交易内部调用，不能任意互换。只统计成功交易，会漏掉拥堵时大量未完成的请求；把所有进入区块的交易都计成业务成功，又会掩盖失败费用。至少需要保留提交数、纳入数、成功执行数和达到目标确认级别的数量，并注明观察窗口与去重方式。

延迟也要有起点和终点。客户端开始提交到排序器响应，衡量的是接入与预确认；提交到全网可核验的最终结果，则还包含传播、共识或证明。p50 是延迟中位数，约一半请求的延迟不超过这个值；p95、p99 则帮助理解用户抱怨“偶尔卡很久”的部分。持续压满系统时若排队不断增长，短时吞吐峰值不能代表可长期维持的服务能力。

费用同样不能只取一笔最便宜的转账。Ethereum L1 的计算、存储和拥堵定价，Rollup 的执行费、数据发布与批次摊销，高性能链的计算和状态资源约束，都可能在不同负载下成为主项。低交易费还可能与补贴、较高节点硬件要求或外部证明成本同时存在。应用要比较相同业务完成到相同终点的总成本，包括失败重试、跨链和必要数据服务。

一个严谨的后续基准可以从三类工作开始：分散账户转账、集中争用同一状态的交易，以及具有真实存储增长的合约调用。固定输入分布与成功条件，报告硬件、带宽、存储、客户端版本、运行时长和重复次数，再分别记录执行与最终确认。本文没有做这项跨链实验，因此不根据不兼容的历史结果选出“最快主网”。目前能给出的，是哪些性能主张适用于什么工作，以及哪些证据仍缺失。

12 技术取舍从应用的代价开始

如果应用的主要需求是保存和转移 Bitcoin 原生资产，并且愿意用工作量确认承担重组风险，Bitcoin 的 UTXO 与脚本验证提供了相对明确的验证对象。为了获得另一种合约能力而把资产包装到其他域，会增加新的保管或验证关系。是否值得，应由确实需要的功能决定，而不由目的链一个更大的吞吐数字决定。

复杂、可组合的合约应用更容易从 Ethereum 和 EVM 生态已有工具、资产与审计经验中获益。直接在 L1 执行，少了一套外部排序、证明与退出状态机；费用和吞吐限制则更直接。Rollup 把许多日常操作做得更便宜，适合能够理解并承受跨层状态差异的应用。选择具体 Rollup 时，应查看今天的证明、数据与升级安排，不能把 Ethereum 的共识属性完整复制到每一个上层组件。

对高频链内交互，Solana 的显式账户访问、Aptos 的推测并行、Sui 的对象依赖分别提供了可以利用的空间。应用应先把最拥挤的状态路径实现出来，观察冲突与重试，再决定语言和模型的迁移收益。分散独立资产操作与共享撮合逻辑可能适合不同组织方式，同一条链也不会让两者获得完全相同的扩展曲线。

以现有稳定币收付或成熟渠道接入为重点的系统，可能因实际收款网络而选择 TRON、BNB Smart Chain 或其他生态。此时代表集合、固化或最终性接口、资源费用、资产发行方政策与现成托管能力都进入成本。本文没有测量这些链上的支付份额，也没有用份额替它们的权限设计背书。业务兼容性是一项实际需求，可以与明确接受的信任条件一起作决定。

希望控制执行环境和升级节奏的团队，可以考虑应用链及 IBC 一类互操作机制，但要承担独立验证者、客户端更新、桥和运维的责任。专用区块空间可以减少和无关应用争用，较小的验证者经济体、链间依赖和恢复协调又带来新的问题。把业务拆到更多链，通常会增加需要持续维护的状态机数量；只有隔离、自治或负载需求足够具体时，这个成本才容易判断。

这些选择都需要一次失败场景来校验。假设默认 RPC 停止更新、排序器拒收、某个证明器离线，或桥的一端暂停：应用能看到哪一个已验证状态，用户还可以提交什么，谁能恢复下一步？如果答案完全依赖一个没有替代入口的服务，那么这项依赖就应进入产品承诺。它可以是合理的工程选择，但用户不应直到提款失败时才第一次知道。

我更看重能够清楚暴露状态、保留独立验证材料并让恢复路径可操作的系统。这种取舍可以被具体证据改变：一个原本依赖私有数据的方案公开了可恢复材料，一个受限证明器开放参与，一个管理权限加入了真实可用的退出延迟，都会改善相应判断；反过来，界面更快却让用户失去可验证结果，也会使原来的选择变差。

13 这项比较怎样复核，哪里仍有空缺

本文是一项代表性协议的系统化证据综述与机制比较。纳入对象需同时具备持续运行或明确主网部署的技术生态、可公开核对的关键规范与实现，以及对研究问题有实际增量的机制。Bitcoin、Ethereum 与代表性 Rollup 构成不同结算路线；Solana、Aptos、Sui 提供不同执行依赖；BNB Smart Chain 与 TRON 补充代表节点和确认接口；IBC 展示异构链如何验证消息。这个取样覆盖重要设计差异，没有声称收齐所有被称作“主流”的链。

检索与状态核查截至 2026 年 10 月 3 日，以交易生命周期中的输入、接受条件、停止位置和规则修改者为提取单位，交叉比较协议论文、官方规范、固定源码、激活记录及事故复盘。性能结果另外记录单位、负载、机器、测量终点与排除项，无法对齐时不计算统一均分。历史论文解释设计成立的条件，激活记录与有高度的观察说明当前路径；Gasper 的早期参数和 Lutris 的旧认证流程，均按这一区分处理。

JSON 附录保留全部实现版本、固定来源、只读查询与原始响应。Base 的参数和持有人集合来自同一个 finalized L1 区块；Sui、Aptos、Solana 的观察保留接口、时间和高度。Aptos API 的节点构建与源码 tag 不同，匹配的配置布局仅用于解码字段。历史区块复查可能需要归档服务，当前状态不能覆盖旧快照；单点 RPC 返回也不能代表全球节点一致或长期可用。

Cardano、XRP Ledger、Stellar、Avalanche、NEAR、Polkadot 等生态没有得到等深度处理，这限制了总体覆盖。本文还没有建立可比的验证者实体控制图、量化基础设施共同故障概率或运行长期负载实验；未独立重放完整链，未核验全部代理字节码与存储槽，也未审计所有证明系统及资产赎回安排。Alpenglow 部分限于激活状态，未独立复核其完整形式化证明。依赖这些性质的选型，还需继续补证据。

因此，本文的结论适用于公开实现中结果被接受、核验和释放的条件，以及已发表性能实验能支持的范围。未来事故概率与每个应用的最优选择，需要更长的观察、更具体的业务输入和可比实验才能回答。

14 让“完成”配得上后面的动作

区块链把许多原来藏在服务端的决定公开了：谁能写入，节点怎样核对，冲突时保留哪段历史，错误怎样被挑战，资产凭什么释放。公开本身很有价值，前提是应用真的沿着这些规则理解结果。钱包的一次变绿，只是整条路径中方便展示的一个位置。

好的技术选型应当让这个位置与用户接下来要做的事对齐。界面可以先快一点，发货要有自己的确认条件，跨链和提款需要继续核对证明与目标执行。用户能够理解等待来自哪里，运营者能够解释失败停在哪里，独立参与者能够检查和恢复状态，“确认”才从一个好看的词，变成一项可以承担责任的承诺。