시퀀서 장애는 대개 빠른 L2 거래 접수와 블록 생성이 멈추는 가용성 문제입니다. 이미 L1에 게시되어 safe·finalized 단계에 이른 상태까지 자동으로 무효가 되거나 자산이 사라진다는 뜻은 아닙니다. 마지막 unsafe·safe·finalized 헤드, L1 배치 제출, 입금·출금 경로, 장애 시작·복구 시각을 각각 확인해야 안전 문제와 단순 지연을 가를 수 있습니다.
시퀀서는 빠른 순서 결정과 L1 게시를 맡는다
OP Stack 명세에서 시퀀서(sequencer)는 사용자의 L2 거래를 받아 블록을 만들고, 배처(batcher)를 통해 그 거래 묶음을 데이터 가용성 계층인 L1에 제출합니다. 사용자는 L1 확인 전에도 시퀀서가 퍼뜨린 최신 블록을 빠르게 볼 수 있습니다. 이 최신 상태는 지연이 짧은 대신, 아직 L1 데이터로 다시 구성된 safe 상태와는 구분됩니다.
그래서 시퀀서가 멈추면 가장 먼저 영향을 받는 것은 새 거래 접수와 새 L2 블록 생성입니다. 이미 확정성(finality)을 얻은 과거 블록과 계약 잔액이 곧 사라진다는 뜻은 아닙니다. 다만 시퀀서, 배처, 제안자, RPC 가운데 무엇이 고장 났는지에 따라 새 블록, safe 승격, 출금 증명, 화면 조회가 늦어지는 조합이 달라집니다.
시퀀서 장애에서 던질 첫 질문은 자산이 사라졌느냐가 아니라, 어느 헤드가 마지막으로 앞으로 나아갔느냐입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 시퀀서는 빠른 순서 결정과 L1 게시를 맡는다
OP Stack 명세에서 시퀀서(sequencer)는 사용자의 L2 거래를 받아 블록을 만들고, 배처(batcher)를 통해 그 거래 묶음을 데이터 가용성 계층인 L1에 제출합니다.
- 세 개의 head로 멈춘 지점을 찾는다
OP Stack의 파생(derivation) 과정은 시퀀서가 p2p로 보낸 블록 데이터를 unsafe 블록으로 먼저 처리하고, L1에 게시된 배치와 입금 거래를 다시 읽어 safe 체인을 만듭니다.
- 증상별로 다른 운영 구성요소를 의심한다
상태 페이지 공지와 RPC 관측값을 아래처럼 맞춰 보면 ‘체인이 멈췄다’는 막연한 표현을 줄일 수 있습니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
세 개의 head로 멈춘 지점을 찾는다
OP Stack의 파생(derivation) 과정은 시퀀서가 p2p로 보낸 블록 데이터를 unsafe 블록으로 먼저 처리하고, L1에 게시된 배치와 입금 거래를 다시 읽어 safe 체인을 만듭니다. finalized 헤드는 L1의 확정성까지 반영한 더 느린 기준입니다. unsafe는 가장 빠르지만 재구성 과정에서 바뀔 가능성이 상대적으로 크고, safe와 finalized는 더 강한 확인 단계를 거칩니다.
설명을 위해 장애 직전 unsafe 헤드가 10,050, safe가 10,020, finalized가 10,000이었다고 해 보겠습니다. 새 블록이 멈추면 세 값이 모두 고정될 수 있고, 시퀀서만 복구되면 unsafe가 먼저 늘어날 수 있습니다. 10,021~10,050 구간의 거래를 확정된 거래라고 부르면 안 됩니다. 반대로 10,000 이하의 상태까지 잃었다고 쓰려면 별도의 체인 재편성(reorg)이나 유효성 결함 증거가 있어야 합니다.
증상별로 다른 운영 구성요소를 의심한다
상태 페이지 공지와 RPC 관측값을 아래처럼 맞춰 보면 ‘체인이 멈췄다’는 막연한 표현을 줄일 수 있습니다.
| 관측 | 가능한 영향 범위 | 추가 증거 |
|---|---|---|
| unsafe 헤드 정지 | 새로 순서가 정해진 블록 지연 | 시퀀서 상태와 최근 블록 시각 |
| unsafe 증가·safe 정지 | L1 배치 게시 또는 파생 지연 | 배치 수신함의 최근 제출 |
| 블록 증가·RPC 오류 | 특정 제공자의 조회 장애 | 다른 공식 RPC·노드와 비교 |
| L1 입금 지연 | 강제 포함 경로 대기 | 입금 거래와 순서 결정 기간 |
| 출금 화면 지연 | 증명·이의 제기·전달 단계 문제 | 출금 메시지 상태 |
강제 포함 경로도 즉시 대체재는 아니다
OP Stack 명세는 L1 입금 거래가 L2 파생 과정에 반드시 들어가도록 설계하고, 순서 결정 기간(sequencing window)이 시퀀서의 검열을 제한한다고 설명합니다. 표준 구성 문서는 이 기간을 3,600 L1 블록, Ethereum의 12초 블록을 가정하면 약 12시간으로 제시합니다. 그렇다고 시퀀서 장애 때 모든 일반 L2 거래가 곧바로 L1에서 같은 속도로 처리된다는 뜻은 아닙니다.
L1 경로를 쓰려면 해당 롤업의 공식 브리지·포털 절차와 비용, 반영 지연을 확인해야 합니다. 장애 중에 비공식 ‘긴급 RPC’나 서명 요청에는 응하지 않습니다. 강제 포함 경로가 있다는 구조적 사실과, 특정 거래가 언제 L2에 반영됐는지는 입금 이벤트와 파생된 블록으로 따로 검증합니다.
- 공식 장애 공지의 시작 시각과 영향받은 구성요소를 저장합니다
- 마지막 unsafe·safe·finalized 블록을 각각 기록합니다
- L1 배치 수신함의 마지막 정상 제출을 확인합니다
- L1 입금 거래와 L2에 반영된 블록을 연결합니다
- 출금은 증명·이의 제기 기간·최종 처리 단계를 구분합니다
- 복구 뒤 밀린 처리량과 재편성 공지를 확인합니다
자산 안전 주장은 더 강한 증거가 필요하다
화면의 잔액이 갱신되지 않거나 거래가 대기 중으로 남는 현상은 가용성이 떨어졌다는 증거입니다. 자산 손실을 주장하려면 승인되지 않은 상태 변경, 잘못된 출력 루트, 브리지 계약의 비정상 인출, 확정된 재편성 같은 추가 증거가 필요합니다. ‘거래 불가’와 ‘잔액 훼손’을 한 문장에 섞어 쓰지 않습니다.
반대로 운영자가 ‘자금은 안전하다(funds are safe)’고 공지했다고 해서 개별 거래의 최종 상태가 모두 확인되는 것도 아닙니다. 독자는 자기 거래가 어느 블록에 들어갔는지, 그 블록이 safe나 finalized로 승격됐는지 확인해야 합니다. 거래소의 입출금 중단은 거래소 자체의 위험 관리 결정일 수 있으므로 프로토콜 상태와 따로 표기합니다.
복구 시각보다 정상 처리 범위를 확인한다
시퀀서가 블록 생성을 다시 시작하면 unsafe 헤드는 다시 움직일 수 있습니다. 그러나 배처가 L1 게시를 따라잡았는지, safe 헤드와의 격차가 줄었는지, 출금·입금 대기열이 처리됐는지까지 봐야 어디까지 정상화됐는지 말할 수 있습니다. 장애 중에 보낸 거래를 다시 보내야 하는지도 논스와 영수증으로 확인합니다.
이 글의 블록 높이는 읽는 법을 설명하기 위한 가정입니다. 실시간 상태는 공식 상태 페이지와 체인 데이터를 다시 조회해야 합니다. 장애를 특정 L2 토큰의 가격 전망이나 매매 권유로 연결하지 않고, 관측된 구성요소와 시간 범위만 보도합니다.
자주 묻는 질문
시퀀서가 멈추면 L2 자산이 없어지나요?
일반적인 가용성 장애만으로 확정된 과거 상태가 사라지지는 않습니다. 잔액이 훼손됐다고 말하려면 재편성, 잘못된 상태 루트, 브리지 인출 같은 별도 증거가 필요합니다.
블록이 다시 나오면 완전히 복구된 건가요?
unsafe 블록 생성만 다시 시작됐을 수 있습니다. L1 배치 게시, safe·finalized 헤드, 입금·출금 대기열까지 확인해야 합니다.
L1 강제 포함으로 바로 거래할 수 있나요?
롤업의 공식 입금 경로와 순서 결정 기간이 적용되므로, 일반 시퀀서만큼 즉시 처리된다는 보장은 없습니다. 실제 입금 이벤트와 L2 반영 여부를 확인해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
