シーケンサーが停止している間、すでに送信したがまだブロックに収録されていない取引はどうなりますか？
この「保留状態」にある取引は、通常2つの結末のいずれかになる：停止が解消されシーケンサーが正常な稼働を再開すれば、元のロジックに従って処理が継続され、あなたの取引は正常に収録される。あるいは、停止時間が長すぎる場合、強制収録メカニズムを通じて自分で取引をシステムに送り込むことを選択し、機能不全のシーケンサーを迂回して取引を完了させることもできる。どちらの場合でも、あなたの取引が最終的に成功するかどうかは、取引自体のロジックが有効かどうか（アカウント残高が十分かどうかなど）によって決まり、シーケンサーの停止自体とは直接関係がない。
より現実的なリスクは時間的コストである——もしあなたの取引が時間的制約のある操作（清算保護や期間限定のアービトラージ機会など）に関わる場合、停止による遅延がこうした機会を失わせる可能性がある。これは資産が奪われる損失ではなく、機会費用の損失である。
強制収録メカニズムはセーフティネットのように聞こえますが、なぜすべてのロールアップがデフォルトでこのチャネルを使い、シーケンサーを飛ばさないのですか？
強制収録メカニズムの設計上の意図は「最後の手段」であり、日常的な操作チャネルではない。主な理由は性能とコストにおける大きな差だ——シーケンサーを通じて取引を送信すれば、即時のソフト確認と極めて低い手数料を享受できる。これはシーケンサーが大量のオフチェーンでの順序付けとバッチ処理を担っているからだ。一方、強制収録メカニズムはメインチェーンと直接やり取りする必要があり、これはロールアップが存在する中核的な価値（取引をオフチェーンで処理してコストを下げる）を迂回することに等しく、したがって速度が遅く、手数料もはるかに高くなる。
もし日常的な操作がすべて強制収録を経由することになれば、ロールアップがもたらす性能上の優位性を放棄することになる。これがほとんどのロールアップが強制収録を「シーケンサーが機能不全になったり悪意ある行動をとったりした場合の緊急出口」として設計し、シーケンサーに取って代わる日常的なメカニズムとしていない理由である——その存在価値は、この退路が本当に存在し利用可能であることを保証することにあり、常態的に使われることを期待されているわけではない。
この3件の実際の停止事故はそれぞれ何が原因で、今後完全に避けることはできますか？
これらの事故の直接的な原因はそれぞれ異なる——例えばトラフィックが突然急増し、当初の容量計画を超えたことは一般的な引き金の一つであり、この種の事故はある程度、単一シーケンサーアーキテクチャが極端な負荷下で直面する容量のボトルネックを反映している。この種の事故を完全に避けることを絶対的に保証するのは難しい。なぜなら単一の主体が運営するインフラである限り、運用上のミス、ハードウェア障害、容量計画の不足といったさまざまな可能性が存在するからだ。これがまた、共有シーケンサーや分散化された順序付けメカニズムが長期的な構造的解決策とみなされ、既存のシーケンサーの容量計画を単に改善するだけでは完全には解決できない理由でもある。
ユーザーにとっては、「今後同様の事故は二度と起きない」ことを期待するよりも、単一シーケンサーアーキテクチャが存在する限り、この種の事故の発生確率がゼロにはならないことを理解する方が実践的な心構えだ。重要なのは、事故が発生したときに自分の資産の実際のリスク状況（先に説明した通り、通常は活性度が影響を受けるのであって資産の安全性ではない）を理解し、それに応じて利用習慣を調整することであり、有名なロールアップを使っているからこの種の事故は絶対に起きないと誤解しないことである。
公式発表を確認する以外に、シーケンサーに問題が起きそうなことを早期に発見する方法はありますか？
L2Betaのような、ロールアップのリスクと稼働状況を専門に追跡するサードパーティの監視ツールを活用できる。これらは通常、各ロールアップのシーケンサーの稼働状況、分散化メカニズムが導入されているかどうか、過去の事故記録をほぼリアルタイムで表示している。一部のブロックエクスプローラーは最新ブロックが生成される時間間隔も表示しており、もしこの間隔が異常に長くなっていることに気づいたら、シーケンサーに問題が起きている早期の兆候かもしれない。
特定のロールアップをヘビーに利用しているユーザーにとっては、そのプロジェクトの公式コミュニティチャネル（公式Discordや公式Xアカウントの発表チャンネルなど）を購読することが、通常最も早く一次情報を得る方法である。ほとんどのチームはシーケンサーの異常を検知すると、数分から数十分以内に発表を行う。自分の操作が失敗して初めて問題に気づくよりも、早く状況を把握できる。
もしあなたがあるロールアップを利用中に「取引が止まって動かない」「インターフェースで送信できないと表示される」といった状況に遭遇したら、最初の反応はパニックかもしれない——このチェーンはハッキングされたのか？自分の資産はまだ残っているのか？しかし実際に起きたいくつかのシーケンサー停止事故を分解してみると、「取引が止まる」ことと「資産が盗まれる」ことはまったく異なるレベルの問題であることがわかる。この区別を理解しておくことは、次回同様の状況に遭遇したときに、より冷静な判断を下すのに役立つ。
Arbitrumは2023年12月にトラフィックの急増によりシーケンサーが処理しきれなくなり、数時間に及ぶサービス中断を引き起こした。Linaeは2024年6月に停止事故を起こした。Baseも2025年2月にサービス中断を経験した。この3件の事故は異なるロールアップで、異なる時期に、原因も完全には同じではないが、共通点は明確だ：停止期間中ユーザーは新しい取引を送信できず、インターフェースが固まり、体験は大きく損なわれたが、どの事故もユーザー資産の窃取にはつながらず、オンチェーンの状態が誤って改ざんされることもなかった。
なぜそうなるのかを理解するには、ロールアップアーキテクチャ自体の設計に立ち返る必要がある：シーケンサーが担うのは「取引を受け取り、実行順序を決定し、即時のソフト確認を提供する」ことだが、「この取引が実行された後、資産の状態がどうなれば正しいのか」を決定するのは、完全に独立した別のメカニズムに依存している——オプティミスティック・ロールアップは不正証明とチャレンジ期間に、ZKロールアップは暗号学的有効性証明に依拠する。この2つのシステムはいずれもシーケンサーによって制御されておらず、誰でも独立して検証できる。
これはつまり、たとえシーケンサーが完全に機能を停止しても、あるいは悪意を持って操作されたとしても、それができる最大限のことは「新しい取引を処理しない」か「不誠実な順序で取引を処理する」ことであり、ユーザーの資産を盗む取引を検証システムのチェックに通過させることはできないということだ。なぜなら検証システムはまさにこの状況を防ぐために存在し、その動作ロジックはシーケンサー自体が誠実かどうかとは完全に独立しているからだ。言い換えれば、シーケンサーの障害が影響するのはそのチェーンの「活性度」（新しい取引を正常に処理できるかどうか）であり、そのチェーンの「資産の安全性」（すでに記録された資産の状態が改ざんされるかどうか）ではない。
これはもう一つのよくある懸念だ：シーケンサーを運営する会社が倒産したり永久にサービスを停止したりした場合、ユーザーの資産は永久に凍結されてしまうのか？答えはそのロールアップのアーキテクチャ設計によるが、ほとんどの主要なロールアップには何らかの「強制収録」（force inclusion）メカニズムが組み込まれている——たとえシーケンサーが完全に機能不全になっても、ユーザーは依然としてメインチェーンと直接やり取りする方法で、機能不全のシーケンサーを迂回して自分の出金取引を強制的にシステムに送り込むことができる。このメカニズムの存在は、「ロールアップの安全性はメインチェーンから引き継がれる」という設計原則の具体的な実践である：シーケンサーは効率層の役割にすぎず、資産の安全性における最後の防衛線ではない。
これは強制収録メカニズムを通じた出金の体験が通常と同じくらいスムーズであることを意味しない——このチャネルは通常より遅く、操作もより複雑である——しかし重要なのは、この退路が確かに存在するということであり、ユーザーが完全に閉じ込められ資産が永久に取り戻せなくなるわけではない。
次にあなたが使っているロールアップで取引が止まったり、インターフェースに異常が出たりした場合、パニックになって焦るよりも効果的な最初のステップは、まずこれが「シーケンサー層の問題」なのか「より根本的なプロトコルの安全性の問題」なのかを確認することだ——公式発表、コミュニティの議論、あるいはそのロールアップのL2Betaのようなサードパーティ監視プラットフォームでのリアルタイムステータスを確認できる。ほとんどの場合、この種の事故は前者に該当し、あなたの資産自体には差し迫ったリスクはなく、一時的に操作できないだけである。もしあなたがより大きな金額を扱う場合、あるいは活性度の中断に特に敏感なユースケースを持つ場合は、そのロールアップに強制収録メカニズムがあるか、そのメカニズムが実際に機能するのにどれくらい時間がかかるかを事前に理解しておく方が、事故が発生した瞬間に慌てて調べるよりも役に立つ。