共享排序器是近两年Rollup生态里讨论度最高的基础设施方向之一。过去一条Rollup通常由运营方自己运行一个中心化排序器，交易顺序完全由单一节点决定，这带来了审查、宕机和跨链排序割裂等一系列问题。Espresso提出的共享排序器网络允许多个Rollup共用同一套排序基础设施，而HotShot正是支撑这套网络的BFT共识协议实现。如果你的React应用此前直连某个单 Sequencer 提交交易，那么迁移到Espresso + HotShot组合时，前端架构需要做出哪些调整？这篇文章用一个完整的项目迁移过程来展开说明。
一、先搞清楚Espresso与HotShot各自负责什么
很多开发者在动手前容易把Espresso和HotShot混为一谈，实际上二者是不同层次的东西。HotShot是一个模块化的BFT共识协议实现，负责在一组验证者之间对交易批次达成最终排序共识，它的核心产出是 HotShot 共识下的区块和相应的 HotShot 提交证书。Espresso则是建立在这套共识之上的排序服务网络，它对外提供交易提交API、排序证明以及最终通过以太坊数据可用层结算的确认机制。
对前端应用来说，这个分层带来的直接变化是：你不再向某个熟悉的单一RPC端点提交交易然后等待它打包，而是先把交易推送到Espresso排序网络的入口，拿到一个临时的受理回执；随后HotShot共识会在数百毫秒到几秒的量级内对包含你交易的批次达成共识，你可以在前端轮询或订阅这个批次的状态；最终，排序结果连同证明会被发布到以太坊，此时交易获得全局排序最终性。理解这条确认链路，是设计前端状态机的前提。
还要注意一点，Espresso的排序证明（通常表现为一个命名空间内部的批次哈希与共识叶子节点的组合）在应用层是可以被本地验证的。这意味着你的React应用在拿到确认后，并不需要盲目信任服务端返回的“已确认”状态，而可以通过轻客户端逻辑校验证明的有效性。这种可验证性是共享排序器相对传统单排序器的核心价值之一，值得在迁移时充分利用。
二、迁移前的现状梳理与SDK封装
迁移的第一步不是改代码，而是盘点现有React应用中所有与排序器交互的路径。典型情况包括：交易签名后通过eth_sendRawTransaction直接发给Sequencer RPC、依赖gas预估接口、以及通过轮询nonce推断交易是否被包含。这些路径在共享排序器架构下语义都有变化，Espresso入口受理交易时并不会立刻给你以太坊层面的交易哈希语义，而是先返回一个批次级别的受理凭证。
建议的做法是在前端封装一个独立的提交模块，把所有排序器交互收敛到一个服务里，避免交易逻辑散落在各个组件中。下面是一个简化后的TypeScript封装示例：
// espressoClient.ts —— 统一的交易提交入口
import { ethers } from "ethers";
export class EspressoClient {
private baseUrl: string;
private signer: ethers.JsonRpcSigner;
constructor(baseUrl: string, signer: ethers.JsonRpcSigner) {
this.baseUrl = baseUrl;
this.signer = signer;
}
// 提交交易到Espresso排序网络入口
async submitTransaction(tx: ethers.TransactionLike) {
const signed = await this.signer.signTransaction(tx);
const res = await fetch(`${this.baseUrl}/v0/submit`, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ rawTransaction: signed }),
});
if (!res.ok) throw new Error(`提交失败: ${res.status}`);
const data = await res.json();
// 返回批次受理凭证，后续凭此查询共识状态
return { batchHash: data.batch_hash, namespace: data.namespace };
}
// 查询交易所在批次的HotShot共识状态
async queryBatchStatus(batchHash: string) {
const res = await fetch(`${this.baseUrl}/v0/status/${batchHash}`);
const data = await res.json();
return data.state; // 例如: "pending" | "hotshot-committed" | "ethereum-finalized"
}
}
这个封装的关键点在于状态分层：把“受理中”、“HotShot已共识”、“以太坊最终确认”三种状态明确暴露给上层UI。传统的React应用往往只有一个loading态，迁移后如果不区分这些阶段，用户会感觉确认时间变长，实际上是确认语义变得更精细了。通过在界面上展示中间确认态，可以在体验上反而优于原来的单排序器方案。
另一个容易被忽略的细节是钱包兼容。MetaMask等钱包签名的原始交易仍然可以直接提交，但如果你的应用支持多个Rollup之间的操作，就需要在交易里携带正确的命名空间信息，确保交易被路由到对应的Rollup命名空间。这个字段建议在SDK层集中管理，不要让业务组件直接拼装。
三、确认监听机制与React状态管理
交易提交之后的确认监听是迁移工作量最大的部分。原方案里大部分应用用provider.waitForTransaction就能解决，而在共享排序器架构下，你需要同时跟踪HotShot共识状态和以太坊结算状态。比较优雅的做法是用自定义Hook把整个确认流封装成可观察的状态机：
// useEspressoTx.ts —— 交易确认状态机Hook
import { useCallback, useEffect, useRef, useState } from "react";
type TxState =
| { phase: "idle" }
| { phase: "signed" }
| { phase: "submitted"; batchHash: string }
| { phase: "hotshotConfirmed"; batchHash: string }
| { phase: "finalized"; txHash: string }
| { phase: "failed"; reason: string };
export function useEspressoTx(client: any) {
const [state, setState] = useState<TxState>({ phase: "idle" });
const timerRef = useRef<number | null>(null);
const stopPolling = () => {
if (timerRef.current) {
window.clearInterval(timerRef.current);
timerRef.current = null;
}
};
const submit = useCallback(async (tx: any) => {
setState({ phase: "signed" });
const { batchHash } = await client.submitTransaction(tx);
setState({ phase: "submitted", batchHash });
// 轮询批次状态，直到进入最终态
timerRef.current = window.setInterval(async () => {
const status = await client.queryBatchStatus(batchHash);
if (status === "hotshot-committed") {
setState({ phase: "hotshotConfirmed", batchHash });
} else if (status === "ethereum-finalized") {
stopPolling();
const receipt = await client.fetchReceipt(batchHash);
setState({ phase: "finalized", txHash: receipt.tx_hash });
}
}, 1500);
}, [client]);
useEffect(() => stopPolling, []);
return { state, submit };
}
这个Hook把轮询逻辑和React生命周期绑定，组件卸载时自动清理定时器，避免内存泄漏。轮询间隔建议设置在1到2秒，HotShot共识通常在亚秒级完成，过度密集的轮询只会白白消耗资源。如果Espresso节点支持事件订阅（例如通过WebSocket推送批次状态变更），优先改用订阅模式，代码结构不变，只需把setInterval换成事件监听即可。
在状态展示层面，建议把hotshotConfirmed阶段明确告诉用户，例如“交易已排序，等待链上结算”。多数实际场景下，用户关心的操作互斥性在HotShot共识完成时就已经确定了，不必等到以太坊最终性才解锁下一步交互。这种“软确认 + 硬确认”的双层体验，正是共享排序器给前端带来的新能力，用好了可以显著缩短用户感知的等待时间。
四、降级策略与迁移验证
任何基础设施切换都必须考虑失败路径。Espresso网络理论上具备高可用，但前端仍应设计降级逻辑：当排序网络入口持续超时或返回错误时，回退到原有的直连Rollup节点提交方式，并在界面上提示用户当前处于降级模式。降级期间交易仍然有效，只是失去了共享排序的跨Rollup一致性保证。实现上可以做一个简单的健康检查，每隔一段时间向入口发送轻量请求，连续失败即触发切换。
迁移完成后的验证环节，建议从三个维度做对比测试。第一是延迟指标：分别统计提交受理、HotShot共识、以太坊最终确认三个阶段的耗时分布，确认共识延迟符合预期；第二是正确性：验证拿到的排序证明能被本地校验通过，批次内交易顺序与Rollup执行后的状态变化一致；第三是异常路径：故意断开网络、切换钱包账户、并发提交多笔交易，观察状态机是否始终收敛到明确的终态。上线初期最好保留灰度开关，让一部分用户先走新链路，收集到足够稳定的数据后再全量切换。
整体来看，从单排序器迁移到Espresso + HotShot，对React应用的改动主要集中在提交层封装和确认状态机两处，业务组件层面的改动其实有限。真正需要投入精力的是确认语义的精细化设计——把原本一次性的“打包成功”拆成多个阶段并合理暴露给用户，这既是迁移的挑战，也是提升体验的机会。如果你正计划做类似的迁移，建议先在测试网完整跑通上述状态机，再逐步把生产流量切过去。