시퀀서 장애는 보통 빠른 L2 거래 접수와 블록 생성의 가용성 문제다. 이미 L1에 게시되어 safe·finalized가 된 상태까지 자동으로 무효화하거나 자산을 없애는 뜻은 아니다. 마지막 unsafe·safe·finalized head, L1 batch 제출, deposit·withdrawal 경로, 장애 시작·복구 시각을 각각 확인해야 안전 문제와 지연을 구분할 수 있다.
시퀀서는 빠른 순서 결정과 L1 게시를 맡는다
OP Stack 명세에서 sequencer는 사용자의 L2 거래를 받아 블록을 만들고, batcher를 통해 해당 거래 묶음을 데이터 가용성 계층인 L1에 제출한다. 사용자는 L1 확인 전에 sequencer가 배포한 최신 블록을 빠르게 볼 수 있다. 이 최신 상태는 낮은 지연을 제공하지만 아직 L1 데이터로 재구성된 safe 상태와는 구분된다.
따라서 시퀀서가 멈추면 가장 먼저 영향을 받는 것은 새 거래 접수와 새 L2 블록 생성이다. 이미 finality를 얻은 과거 블록과 계약 잔액이 곧 사라진다는 뜻은 아니다. 다만 sequencer, batcher, proposer, RPC 중 무엇이 고장 났는지에 따라 새 블록, safe 승격, 출금 증명, 화면 조회의 지연 조합이 달라진다.
시퀀서 장애의 첫 질문은 자산이 사라졌는지가 아니라 어느 head가 마지막으로 전진했는가이다.
JOBCOIN 해설
세 개의 head로 멈춘 지점을 찾는다
OP Stack derivation은 sequencer의 p2p payload를 unsafe block으로 먼저 처리하고, L1에 게시된 batch와 deposit을 다시 읽어 safe chain을 만든다. finalized head는 L1 finality까지 반영한 더 느린 기준이다. unsafe는 가장 빠르지만 재구성 과정에서 바뀔 가능성이 상대적으로 크고, safe와 finalized는 더 강한 확인 단계를 거친다.
교육용으로 장애 직전 unsafe head가 10,050, safe가 10,020, finalized가 10,000이었다고 하자. 새 블록이 멈추면 세 값 모두 고정될 수 있고, sequencer만 복구되면 unsafe가 먼저 늘 수 있다. 10,021~10,050의 거래를 finalized 거래라고 부르면 안 된다. 반대로 10,000 이하 상태까지 손실됐다고 쓰려면 별도의 reorg나 validity fault 증거가 필요하다.
증상별로 다른 운영 구성요소를 의심한다
상태 페이지 공지와 RPC 관측을 아래처럼 맞추면 ‘체인이 멈췄다’는 모호한 표현을 줄일 수 있다.
| 관측 | 가능한 영향 범위 | 추가 증거 |
|---|---|---|
| unsafe head 정지 | 새 sequenced 블록 지연 | sequencer 상태와 최근 block time |
| unsafe 증가·safe 정지 | L1 batch 게시 또는 derivation 지연 | batch inbox의 최근 제출 |
| 블록 증가·RPC 오류 | 특정 제공자 조회 장애 | 다른 공식 RPC·노드 비교 |
| L1 deposit 지연 | 강제 포함 경로 대기 | deposit tx와 sequencing window |
| 출금 UI 지연 | 증명·challenge·relay 단계 문제 | withdrawal 메시지 상태 |
강제 포함 경로도 즉시 대체재는 아니다
OP Stack 명세는 L1 deposit transaction이 L2 derivation에 포함되도록 설계하고 sequencing window가 sequencer 검열을 제한한다고 설명한다. 표준 구성 문서는 window 크기를 3,600 L1 블록, Ethereum 12초 블록 가정에서 약 12시간으로 제시한다. 이는 시퀀서 장애 때 모든 일반 L2 거래가 즉시 L1에서 같은 속도로 처리된다는 뜻이 아니다.
사용자가 L1 경로를 이용하려면 해당 롤업의 공식 bridge·portal 절차와 비용, 포함 지연을 확인해야 한다. 장애 중 비공식 ‘긴급 RPC’나 서명 요청에 응하지 않는다. 강제 포함이 존재한다는 구조적 사실과 특정 거래가 언제 L2에 반영됐는지는 deposit 이벤트와 파생 블록으로 별도 검증한다.
- 공식 incident 시작 시각과 영향 컴포넌트를 저장한다
- 마지막 unsafe·safe·finalized block을 각각 기록한다
- L1 batch inbox의 마지막 정상 제출을 확인한다
- L1 deposit과 L2 반영 블록을 연결한다
- 출금은 prove·challenge·finalize 단계를 구분한다
- 복구 후 backlog와 reorg 공지를 확인한다
자산 안전 주장은 더 강한 증거가 필요하다
UI 잔액이 갱신되지 않거나 거래가 pending인 현상은 가용성 저하의 증거다. 자산 손실을 주장하려면 승인되지 않은 상태 변경, 잘못된 output root, bridge 계약의 비정상 인출, 확정된 reorg 같은 추가 증거가 필요하다. ‘거래 불가’와 ‘잔액 훼손’을 같은 문장으로 쓰지 않는다.
반대로 운영자가 ‘funds are safe’라고 공지한 문장만으로 모든 개별 거래의 최종 상태가 확인되는 것도 아니다. 독자는 자신의 거래가 어느 block에 포함됐고 그 block이 safe 또는 finalized로 승격됐는지 확인해야 한다. 거래소 입출금 중단은 거래소의 위험 관리 결정일 수 있으므로 프로토콜 상태와 별도 표기한다.
복구 시각보다 정상 처리 범위를 확인한다
시퀀서가 블록 생성을 재개하면 unsafe head는 다시 움직일 수 있다. 그러나 batcher가 L1 게시를 따라잡았는지, safe head 격차가 줄었는지, 출금·deposit 대기열이 처리됐는지까지 봐야 정상화 범위를 말할 수 있다. 장애 동안 제출된 거래가 재전송을 요구하는지도 nonce와 receipt로 확인한다.
이 글의 블록 높이는 판독법을 위한 가정이다. 실시간 상태는 공식 status와 체인 데이터를 다시 조회해야 한다. 장애를 특정 L2 토큰의 가격 전망이나 매매 권유로 연결하지 않고, 관측된 컴포넌트와 시간 범위만 보도한다.
자주 묻는 질문
시퀀서가 멈추면 L2 자산이 없어지나요?
일반적인 가용성 장애만으로 확정된 과거 상태가 사라지지는 않는다. 잔액 훼손을 말하려면 reorg, 잘못된 state root나 bridge 인출 같은 별도 증거가 필요하다.
블록이 다시 나오면 완전히 복구된 건가요?
unsafe 블록 생성만 재개됐을 수 있다. L1 batch 게시, safe·finalized head, deposit·withdrawal 대기열까지 확인해야 한다.
L1 강제 포함으로 바로 거래할 수 있나요?
롤업의 공식 deposit 경로와 sequencing window가 적용되므로 일반 sequencer와 같은 즉시성은 보장되지 않는다. 실제 deposit 이벤트와 L2 반영을 확인해야 한다.
