Base 或 Arbitrum 的 sequencer 出故障时，还能提现吗？

Rollup 可以为那些交易卡在 sequencer 的用户保留一条 Ethereum 路径。这条路径负责交易包含。但资金能否回到 Ethereum，还取决于 rollup 的提现是否能在桥接规则下被证明并完成。

• 当常规 sequencer 不可用时，Base 和 Arbitrum One 都提供 Ethereum 侧的交易包含路径，但最终提现仍必须满足官方桥的规则。
• 一笔在故障前已经被包含的交易，可能比一笔新的提现更接近完成。发布到 Ethereum 的状态以及证明状态，决定下一步是什么。
• ETHBEAT 将这两个 rollup 都评为 Stage 1，但其评估对常规升级和紧急升级的保护不同。两项评估都没有给用户提供文中所述紧急路径下的退出窗口。
• Base 的 Azul 升级引入了新的证明选项，而 Arbitrum 的 Delayed Inbox 让用户可以通过 Ethereum 提交消息。这些功能解决的是提现的不同环节。
• 快速桥可以用单独的流动性先向用户付款，而外部发行的代币则可能有自己的赎回规则。两者都需要与官方桥一起考虑。

设想两个持有 ETH 的用户，一个在 Base 上，一个在 Arbitrum One 上。两人都使用官方桥，但他们在一次故障中处于不同阶段尝试离开。一个提现已经记录在 rollup 中，另一个还需要先让交易被接受。

Ethereum 可以为正常 sequencer 路径提供替代方案。但这是否能让两位用户最终完成提现，取决于桥接的下一步，以及那些有权修改或暂停合约的人是否已经采取行动。

提现不止一步

在正常运行时，用户先在 rollup 上发送一笔提现交易。sequencer 会将其与其他交易一起排序。等相关 rollup 状态可用，并满足适用的证明和等待要求后，桥上的提现就可以在 Ethereum 上建立。

这两笔交易在钱包里可能看起来像一个动作。第一步是在 rollup 上记录提现。后续一步则是在 Ethereum 上完成它。用户如果能在区块浏览器里看到第一笔交易，就能证明它已经被包含，即便资金在 Ethereum 上仍不可用。

绕过 sequencer 的路径

Arbitrum 的强制交易文档描述了一条通过 Ethereum 上 Delayed Inbox 的路径。交易可以先在那里等待，直到具备被强制包含的资格。这个等待期与完成 Ethereum 提现所需的时间是分开的。

Base 的 derivation 规范描述了从 Ethereum 派生的存款，包括协议的强制包含路径。真正有用的比较是：用户是否能通过 Ethereum 发起必要动作、协议可能需要多久才会包含，以及包含之后还要发生什么。

这个备用路径可能涉及 Ethereum 交易手续费。它还取决于用户或代其操作的服务能否提交正确消息。钱包如果与正常端点的连接损坏，可能需要换一个界面才能使用可用的链路。

紧急升级考验的是另一种保护

故障会引出一个问题：交易能否进入 rollup。升级则会引出另一个问题：谁能修改决定提现是否会被承认的合约。强制交易路径本身并不能在用户完成提现前维持现有规则。

ETHBEAT 将 Base 和 Arbitrum One 都列为 Stage 1。其评估显示 Base 没有退出窗口，而 Arbitrum One 则区分了常规升级和紧急升级。Arbitrum 的常规路径有 10 天窗口，而紧急路径没有这样的窗口。

这也是为什么仅凭 Stage 1 评级无法回答用户有多久可以离开。通知期必须与启动、证明和最终完成提现所需的时间一起考虑。相关期限是扣除用户需要完成的步骤后剩下的时间。

第三方桥会增加自己的条件

快速桥可以先用它已经在 Ethereum 上持有的流动性向用户付款，然后再在之后结算自己的头寸。这在正常运行时可以让提现看起来更快。但它也引入了一个在 rollup 承压时同样重要的提供方：它的流动性和运营政策。

资产本身也很重要。通过第三方桥发行的余额，即使显示在 Base 或 Arbitrum 上，也可能取决于该桥的合约。对 rollup 官方退出机制的评估，不能单独说明外部发行方会如何赎回。

更公平的比较方式，是把同一种资产通过两个官方桥都走一遍，并记录首次包含、证明和最终完成的步骤。然后再比较当 sequencer 停止时会发生什么，以及在提现完成前，紧急升级能做什么。

先从同样的提现开始

假设一个用户在两个网络上各持有原生 ETH，并希望把 ETH 退回 Ethereum。使用同一种资产会让比较更简单，因为它避开了包装代币可能适用的单独赎回规则。官方桥仍然需要证据证明提现已经开始，以及包含该提现的状态已按 rollup 规则被接受。

在正常运行时，用户在 rollup 上提交一条指令。它被包含后，会形成一条记录，提现系统之后可以识别。然后，用户或代其操作的界面可以在 Ethereum 上执行所需步骤。相关桥合约执行提现后，资金就会在 Ethereum 上可用。

钱包可以显示多种进度。它可以显示 sequencer 已接受交易、某个批次已到达 Ethereum，或者提现已经准备好进入下一步。这些标签描述的是不同事件。一个界面即便把交易显示为已确认，也可能只是在描述它在 rollup 上的状态。

一笔在故障前开始的提现，也不同于用户尚未发起的提现。如果交易和支持它所需的状态都已经到达 Ethereum，剩余工作可能会在那里完成。如果只有 sequencer 最近给出的响应，那用户仍需要相关数据和状态，才能走完系统的其余部分。

这种区别有助于解释为什么在故障期间，第一个有用的问题是提现停在哪一步。缺少 rollup 交易，就需要一条进入路径。一笔已经记录在 rollup 上的提现，可能正等待证明或最终完成阶段。下一步取决于网络已经走到哪一阶段。

sequencer 停止时会发生什么

sequencer 通常为用户提供一条快速的交易排序路径。如果服务停止响应，已提交的交易可能不会出现，尽管 Ethereum 仍在运行。通过 Ethereum 的路径让用户可以把消息放进 rollup 的输入中，而不必等正常端点恢复。

在 Arbitrum One 上，Ethereum 会在 Delayed Inbox 中记录消息。sequencer 可以在正常流程中将其包含。如果消息在适用等待期之后仍留在那里，强制包含路径就可以把它纳入序列。记录消息的 Ethereum 交易与执行它的 rollup 交易，仍然是两个不同的观察点。

在 Base 上，记录在 Ethereum 上的存款会成为 rollup 派生规则的输入。这里的 deposit 一词可能会让人误解，因为它也指一种消息类型，Ethereum 交易可以通过它触发 rollup 上的动作。用户想要的 rollup 操作，在包含之后仍必须成功执行。

ETHBEAT 的项目页面描述了它们模型下的延迟。这个估计适用于备用步骤，而且两个网络之间可能不同。但它不会把 rollup 到 Ethereum 的桥变成即时提现。最终付款仍取决于桥是否接受相应状态并完成自己的步骤。

用户还需要具备提交 Ethereum 交易的手段。把全部余额都放在 rollup 上的人，可能需要在 Ethereum 上有 ETH 才能使用备用路径。平时替用户处理这些操作的应用，如果依赖失效端点或没有暴露 Ethereum 路径，也会遇到同样的现实限制。

接收方也应区分“请求失败”和“已成功提交但尚未生效”的 onchain 提交。来自 Ethereum 的交易哈希，如果其回执确认了，就能证明备用消息已经提交。但它不能证明之后在 rollup 上执行的结果。

当网络还在出块，但提现卡住时

一个网络可以继续产出交易，而提现流程的另一部分却被延迟。Ethereum 上的合约需要一个被认可的 rollup 结果说明。状态发布或建立的延迟，可能会让用户在 sequencer 已经恢复成功结果后仍继续等待。

区别来自不同环节的职责。sequencer 负责交易排序。数据可用性让其他方能够重建已排序内容。提议和证明系统则决定 Ethereum 合约应承认哪个最终状态。一个服务可以完成其中一项工作，而另一项仍在等待。

因此，对观察者来说，区块浏览器仍显示活动，并不能作为完整判断。观察者可以把最近的 rollup 交易包含情况，与 Ethereum 上关于状态或提现主张的记录进行对比。两者之间的差距有助于判断瓶颈是在更早还是更晚的环节。

ETHBEAT 之所以区分 sequencer 失败和 proposer 失败，是因为一方的备用方案并不一定能解决另一方的问题。它的分类方式是为了看出在常规操作者缺席时，谁可以接手。阅读时应结合每个项目描述的条件和延迟。

同样的原则也适用于服务降级的报道。前端可能不可用，但合约仍可调用。浏览器可能滞后，而链仍在推进。桥接界面可能在事故期间禁止提交，但另一个界面仍可访问合约。每种情况都应在发生的层面上检查。

Crypto.news 报道称，Base 在 2025 年 8 月曾发生一次 33 分钟的故障。这个事件可以用来追问哪些用户操作被中断、哪些替代路径仍然可用。但它的持续时间并不能说明未来涉及不同组件的事件会如何影响提现。

包含之后的等待属于桥

一旦提现进入 rollup 状态，它仍必须通过桥的证明和最终完成条件。乐观型设计会给参与者一个挑战错误主张的机会。这个延迟可能是该流程的刻意组成部分，而不是 sequencer 离线的迹象。

计时从桥定义的事件开始，而不一定与用户第一次点击提现的瞬间一致。等待时间可能取决于相关输出或主张何时可用，以及所需证明是否已经提交。用户可能会先等待一段时间，之后桥描述中出现的挑战期才真正开始起作用。

因此，钱包里的倒计时可能只是一个估计，而不是无条件的付款日期。它可能取决于正常发布和证明活动持续进行。如果状态存在争议，即便提现指令已经出现在 rollup 上，最终完成所需时间也可能改变。

Arbitrum 的证明系统和 Base 的证明设计在实现细节上不同。对用户来说，实际比较的是：谁可以提交主张、谁可以挑战，以及当通常提交下一项主张的角色停止工作时会发生什么。withdrawal 这个词在这些系统中对应的是不同的流程。

这个延迟也会影响与第三方桥的比较。能够立即在 Ethereum 上向用户付款的服务，使用的是自己的流动性或另一套参与者网络。这个快速付款可能在官方提现具备结算资格之前就已经完成。

此时，用户依赖的是第三方的支付能力和支付意愿。如果流动性耗尽，或者提供方停止接受请求，平时交易中报价的速度就可能不再适用。底层 rollup 的退出保护和商业服务的付款条件仍然是两回事。

升级问题关乎明天适用哪些规则

sequencer 故障会阻止用户进入正常链路。升级则可能改变这条链路本身的规则。即便 sequencer 运行正常、每笔交易都被接受，升级延迟也仍然相关。

在常规治理流程下，公告中的升级可能要经过一段延迟后才能生效。在这段时间里，用户可以评估提案，并在桥仍然开放时开始离开。真正有用的退出窗口，是扣除正常提现步骤后剩下的时间。

在紧急路径下，指定签名者有时可以不经过常规延迟直接行动。这有助于快速应对安全事件。但它给用户的保障，与治理按正常路径运行时看到的并不相同。

Arbitrum One 的评估列出常规路径为 10 天，而紧急升级没有退出窗口。Base 的评估则没有退出窗口。头条式的 Stage 评级可以相同，但这些权限在实践中可能不同。

暂停是另一种需要区分于升级的动作。暂停可以在现有合约规则下停止某项特定操作。升级则可以替换或更改这些规则。暂停所需的签名者和阈值，可能与新实现所需的不同。

Crypto.news 曾报道过 Arbitrum 安全委员会在 Binance 黑客事件中转移相关资金的具体案例。那一事件涉及已识别资金和临时合约变更。它在这里的相关性在于：紧急权限可以在实践中被行使，而且可以独立于之后决定资金去向的流程。

如何理解 Stage 1，而不是把它误当成退出保证

Stage 分类会把 rollup 的多个维度放在一起。它们说明系统在框架标准下，已经在多大程度上摆脱了对操作者或委员会的依赖。但 stage 标签无法回答所有故障模式，因为每种保护对应的是不同工作。

对用户来说，关键是与其交易相关的条件。若交易无法被包含，sequencer 备用机制就很重要。若 rollup 的常规 proposer 停止工作，提议状态的能力就很重要。若有人能在用户等待时改变桥会做什么，升级延迟就很重要。

数据可用性也属于同一比较范围。如果重建 rollup 所需的数据可在 Ethereum 上获得，其他参与者就有了沿链跟进的依据。但数据的存在本身并不会替用户完成证明或提交 Ethereum 交易。

Base 和 Arbitrum One 都可以在 sequencer 出问题时提供一条通过 Ethereum 的路径，同时在升级权限上保持不同。实际评估应把这两点都记录下来，而不是把它们平均成一个分数。试图离开的用户，需要面对的是与其所处事件相关的最薄弱环节。

这些假设也会因代币不同而变化。原生 ETH 可以遵循官方桥自己的规则。通过第三方合约到达的代币，可能会增加发行方或桥的控制。即便两个钱包都在同一个 rollup 上，它们也可能面临不同的赎回条件，尽管界面显示的都是相同的美元金额。

Ankr 桥事件则提供了另一个例子，说明桥逻辑如何决定一笔提现是否有效。那是另一个系统。它的相关性在于：链上的活动与桥用来接受消息并释放资产的规则，是两回事。

退出比较能说明什么

比较两个在 sequencer 故障前发起普通提现的用户。如果各自的提现都已经成为 Ethereum 上桥可用的状态，那么剩余步骤取决于证明和最终完成流程。只要 Ethereum 执行仍可用，这次故障对已经成熟的提现可能没有直接影响。

现在把故障提前。两位用户都还没有让提现交易被包含。两人都需要进入 rollup 的 Ethereum 侧路径，或者等待正常服务恢复。包含所需时间可能不同，而桥本身的等待则发生在之后。

最后，设想在提现待处理时发生一次紧急合约操作。此时相关证据变成了该操作背后的授权、受影响的具体合约，以及新配置允许哪些步骤。此前已包含的交易，仍可能需要桥按用户完成时生效的规则来识别它。

这些情况说明，公平比较应从相同状态开始。已经把消息提交到 Ethereum、但还没看到 rollup 执行的人，不应与桥证明已经被接受的人直接比较。计时起点不同。

Crypto.news 曾报道过让 Ethereum rollup 协同工作的努力。更顺畅的前端可以在正常交易中隐藏多个步骤。但在压力下，用户会受益于知道哪些环节发生在哪条链上，以及每个环节由谁负责。

Crypto.news 对与 Binance 相关的 Arbitrum 恢复提案的报道，也说明了为什么治理动作应与其授权的交易一起阅读。提案描述的是预期结果。Ethereum 和 rollup 记录则显示它何时、何地被执行。

退出路径只有在持有人能从自己当前的位置使用它时才有用。最清晰的记录会标明资产、所在链、已经完成的交易，以及控制下一步的主体或合约。这样的记录能告诉用户，剩余等待属于 sequencer、桥，还是能够改变两者的权力方。

为什么更快的证明不一定缩短每一种退出

Base 的 Azul 升级引入了新的证明选项。Crypto.news 曾报道过可能实现一天内提现的路径。目标或证明能力，必须与用户在当前配置下真正能依赖的提现时间区分开来。

证明可以帮助建立提现所依赖的状态。但桥在释放资金前，仍可能施加其他条件。流程也可能因网络使用哪条证明路径，以及该路径不可用时会发生什么而不同。

因此，退出比较应说明自己测量的是哪条路径。乐观路径可能有挑战期。使用不同证明的路径，可能缩短流程的一部分。升级风险则关乎在流程完成前，控制任一路径的合约或权限是否会改变。

Ethereum 提现还需要一笔可以在 Ethereum 上提交并执行的交易。第三方网站可能会代为完成这一步，但它是否接受请求，与官方合约能否处理，是两回事。用户即使看到动作可用了，仍需要一个能提交它的钱包或服务。

当用户代表应用或客户持有资产时，这种区别就更重要了。资金库在任何 Ethereum 操作前，可能都需要多重审批。普通用户则可能只需要钱包连接和 gas。协议可用的退出时间，与个人实际操作所需时间，可能并不相同。

故障后公开记录能显示什么

一次事件记录可以从最后一次正常的 sequencer 响应和第一笔延迟交易开始。随后它可以识别数据和状态是否继续到达 Ethereum。这些记录有助于解释为什么有些用户看到中断，而另一些用户仍能完成更早的提现。

最有用的时间线还会标明所涉应用和资产。钱包报告余额过时，与桥拒绝接受最终完成交易，是两回事。第三方提供方暂停付款，与官方桥更改规则，也是两回事。

Crypto.news 对 Arbitrum 紧急干预的报道，说明了为什么需要把委员会执行的动作与随后进行的治理流程区分开来。Ethereum 记录的存在可以证明某项合约动作发生过。但它并不能免除阅读是谁执行了该动作，以及它影响了什么。

关于提现问题的直接答案，取决于故障发生在什么时候。在包含之前，看 Ethereum 备用路径以及它附带的延迟。在包含之后，看状态、证明和最终完成要求。在紧急变更期间，即便其他系统都在正常运行，暂停或修改合约的权限也会变得决定性。

一个用户也可能在这一序列中有多笔处于不同阶段的提现。一笔可能已经准备好完成，另一笔仍在等待被包含。给出单一预期恢复时间的故障通知，无法同时确定两者的状态。

提现回执是最后的检查

桥界面可能会在用户尚未提交完成交易之前，就把提现标记为“已准备好”。Ethereum 交易回执则是另一份记录。对于原生 ETH，接收方还可以检查转账是否到达预期地址，以及接收方是否可以使用它。

当用户在故障后重试动作时，这种区别很重要。两次提交指令的尝试，可能会产生不同的消息，或者只会有一笔被接受的交易，这取决于请求是如何发出的。钱包历史记录可以帮助用户在尝试下一步之前，识别桥认的是哪条消息。

rollup 和桥也可能按不同节奏恢复。sequencer 可能已经恢复，而更早的提现仍在等待状态或证明。rollup 交易重新出现，说明排序服务已恢复；但等待在 Ethereum 上收款的用户，仍需要检查自己的最终完成状态。

升级通知也适用同样原则。公告可能说桥已暂停，但这并不一定改变 rollup 继续处理的内容。用户需要识别暂停影响的是发起、证明、最终完成，还是其他操作。对处于不同阶段的持有人来说，同一则通知的影响可能不同。

对前文比较中的两位用户来说，最终证据是一样的：他们的官方桥提现在 Ethereum 记录向预期接收方释放 ETH 时才算完成。在那之前的一切，只是在告诉他们哪一段路径在工作，以及还剩下什么。

需要关注什么

• Sequencer 状态：状态通知和 rollup 交易记录可以显示正常排序何时停止、何时恢复。
• Ethereum inbox：成功的 Ethereum 回执可以证明备用消息已提交，以及它何时具备被包含的资格。
• 状态发布：Ethereum 记录可以显示桥是否拥有处理提现所需的主张或输出。
• 紧急动作：授权签名者、受影响的合约以及交易时间，决定暂停或升级是否改变了用户路径。
• 资产支持：代币发行方和桥决定官方提现比较是否适用于该余额。

常见问题

如果 Base 或 Arbitrum 的 sequencer 离线，用户还能提现吗？

当常规 sequencer 不可用时，确实有 Ethereum 侧的交易包含路径。包含是新提现的第一项要求。但官方桥在释放资金前，仍需要相关状态以及任何必要的证明和等待期。

强制包含是否意味着资金会立刻到达 Ethereum？

强制包含能帮助用户把交易送入 rollup。但它不能取代桥的规则。用户应区分备用消息的 Ethereum 回执，与之后证明 rollup 提现已执行并可最终完成的证据。

为什么一笔更早开始的提现仍可能完成？

如果提现已经拥有所需的被接受状态，并且已经度过等待期，剩余动作可能会在 Ethereum 上进行。sequencer 故障对那些交易从未被包含、或证明仍在等待状态的用户，影响可能不同。

Stage 1 评级对用户说明了什么？

它是在一个框架下对 rollup 的描述，该框架评估了对操作者和特权方的多种依赖。要找出与故障、提案延迟或合约变更相关的具体保护，还需要项目层面的风险细节。

Arbitrum 的 10 天退出窗口是什么意思？

ETHBEAT 将该窗口列在常规升级路径下。这个框架考虑了使用提现路径所需的时间。紧急路径可以不经过这个窗口，这使得具体升级的授权和时点变得重要。

更快的第三方桥能绕过卡住的官方提现吗？

在正常条件下，第三方服务可能会用自己的流动性先付款。它在故障期间是否还能这样做，取决于服务本身、资产以及可用流动性。用户面对的是一套与官方桥不同的条件。

为什么同一网络上的两个用户退出时间会不同？

他们可能持有不同资产，或者处于提现的不同步骤。一个人可能已经有可在 Ethereum 上完成的主张，而另一个人仍需要把指令送入 rollup，或者依赖单独的代币发行方。

紧急暂停会改变什么？

它可以停止相关合约权限覆盖的操作。这与升级不同，升级会改变合约适用的规则。要判断某笔提现是否受影响，需要查看采取了什么动作、涉及哪些合约，以及提现已经走到哪一步。