以太坊二层把区块封好的间隔通常是两秒左右，用户的交易即便早就被排序执行，也要等这个节奏才能拿到状态更新。Base 在官方文档里给出了拆法：在这两秒内部再切十等份，每两百毫秒交付一份增量状态更新，这套机制叫 Flashblocks。它与 Flashbots 合作构建，官方口径是始终在线，所有区块都由 Flashblocks 构建器产出，应用可以自行选择消费预确认还是继续等完整区块。
十份子块怎么长出来
一个完整区块由索引一到十的十个 Flashblocks 组成，每份子块装这个两秒窗口内的一部分交易；索引零的位置存在但只放系统交易，不占气体额度。构建循环每两百毫秒跑一轮：先算出当前子块的气体预算——第 j 份子块最多可以用整个区块气体上限的十分之 j，再把交易池里的待选项按费用从高到低排序，装入预算内塞得下的交易，执行并把子块流式推给 websocket-proxy。
预算设计值得多看一眼。它不是均匀分配而是递增分配：第一份子块只有一成气体空间，到第十份接近用满整块额度。这样早期子块能快速成型、先让用户拿到状态更新，后面的子块再有充裕空间吸收迟到的大交易。配套的动态交易池会一边建房一边继续收单，因此官方文档明确说明一种现象属于预期行为而非故障：一笔高费交易如果到得晚，可能排在同一子块里已经提交的低费交易之后——费用优先指的是选中时刻按费用排序，不是全程保持费用单调。
预确认从哪里读
交易一旦被装进某份子块，就进入预确认（preconfirmation）状态：官方给的定义是一个极快的信号，表示交易将被收录，此时完整区块还没有封好。分发路径是构建器把子块流推给 websocket-proxy，各 RPC 节点监听这条流并把预确认数据放进本地缓存；当应用调用支持预确认的方法，节点直接从缓存返回结果。公共端点全部启用 Flashblocks，标准 JSON-RPC 的 pending 标签因此不再指向未挖矿的交易池视图，而是指向大约两百毫秒精度的在建子块状态——eth_call、eth_getBalance 这类读操作可以在区块封好之前约一点八秒就读到排序后的真实状态。WebSocket 侧除了新头通知变成约两百毫秒一发，还有订阅新交易、订阅预确认日志、订阅整份子块负载三种专有事件。官方同时提醒：面向节点运维的原始基础设施流不要由应用直连，应用层应走 Flashblocks 感知的 RPC 端点。
快信号与慢账本各管什么
Flashblocks 没有改变 Base 的安全结构。两百毫秒信号来自排序执行层的承诺：它可信的前提是排序器持续诚实在线，预确认数据要随完整区块进入数据发布与后续的挑战窗口，才谈得上以太坊层面的最终性。所以官方文档把选择权交回应用：想更快反映状态变化的，消费预确认；只想等更强信号的，沿用两秒节奏的区块终局即可。同一笔交易在两个时间轴上会有不同可见形态——在子块里它已经有执行结果与日志，在封好的区块里才有规范的交易收据与区块哈希。
适合消费快信号的典型场景是前端状态展示、撮合类应用的挂单反馈、游戏与支付回调；需要谨慎的是把预确认当作不可逆事实的清算与提款逻辑。运维排障时也建议分开看两条通道：节点预确认缓存是否落后，与节点链同步是否落后，是两个互相独立的故障域。
核验与参数
机制类参数——两百毫秒、十份一组、气体预算比例——都写在官方文档的构建算法一节里，属于协议设计而非可调的市场参数；端点行为、订阅方法与缓存语义则以 Base 官方文档与 RPC 参考页为准。评估任何提速方案时都可以沿同一条线提问：信号从哪里发出、谁为它背书、升级到最终性还要经过哪些环节。
风险提示：本文只解释机制，不构成任何投资建议；预确认不等同于链上最终性，涉及资产的判定请以官方文档与链上数据为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。