L2 Sequencer Uptime Feed는 시퀀서 상태를 answer로 제공하며 Chainlink 문서의 소비 예시는 0을 up, 1을 down으로 해석합니다. 소비자 계약은 latestRoundData에서 상태와 startedAt을 읽고 down이면 가격 의존 작업을 중단합니다. up으로 돌아온 직후에도 사용자가 L1 강제 거래나 담보 조정을 할 시간을 주기 위해 grace period가 지날 때까지 청산 같은 작업을 막아야 합니다.
시퀀서 중단은 사용자와 오라클의 접근 조건을 바꾼다
롤업 시퀀서는 사용자 거래를 받아 순서를 정하고 L2 블록을 빠르게 생산합니다. 시퀀서가 멈추면 일반 RPC와 빠른 포함 경로가 작동하지 않아 사용자가 담보를 추가하거나 부채를 갚기 어려울 수 있습니다. L1 강제 포함 경로가 있어도 지연과 복잡성이 큽니다.
가격 피드가 계속 갱신되거나 복구 직후 큰 가격 변화를 반영하면 대응하지 못한 사용자의 포지션이 즉시 청산될 수 있습니다. uptime feed는 프로토콜이 이 비대칭 상태를 감지해 가격 의존 작업을 잠시 멈추도록 돕습니다. 가용성 신호이지 자산 가격 피드의 대체물이 아닙니다.
| answer | startedAt 경과 | 권장 처리 |
|---|---|---|
| 1 down | 무관 | 민감 작업 중단 |
| 0 up | grace period 이내 | 청산·신규 위험 작업 보류 |
| 0 up | grace period 이후 | 가격 최신성 검사 뒤 진행 |
| 데이터 미초기화 | 불명확 | 안전 실패 처리 |
answer와 startedAt의 의미를 함께 읽는다
Chainlink의 L2 Sequencer Uptime Feed 안내는 latestRoundData의 answer가 0이면 up, 1이면 down인 소비 패턴을 제시합니다. startedAt은 현재 상태가 시작된 시각을 나타내므로 block.timestamp와의 차이를 계산해 복구 뒤 경과 시간을 구합니다.
예를 들어 grace period가 3,600초이고 answer가 0이어도 block.timestamp – startedAt이 900초라면 민감한 작업을 허용하지 않습니다. 3,600초를 넘긴 뒤에도 별도 가격 feed의 updatedAt과 answer를 검사해야 합니다. uptime 정상은 가격 최신성을 보증하지 않습니다.
시퀀서가 다시 켜진 시각과 사용자가 대응할 수 있게 된 시각은 같지 않을 수 있다.
JOBCOIN 해설
grace period는 시장과 탈출 경로에 맞춘다
grace period는 복구 뒤 사용자가 RPC에 접속하고 담보를 보충하거나 상환할 시간을 줍니다. 너무 짧으면 장애 중 불리해진 사용자를 보호하지 못하고, 너무 길면 정상 시장에서 청산이 지연돼 프로토콜 부실 위험이 커집니다. L2의 강제 포함 지연, 블록 시간, 자산 변동성과 운영 지원을 반영합니다.
모든 기능을 같은 방식으로 막을 필요는 없습니다. 위험을 늘리는 신규 차입과 청산은 제한하면서 부채 상환이나 담보 추가는 허용할 수 있습니다. pause 설계가 사용자의 위험 감소 행동까지 막지 않는지 시나리오로 검증합니다.
- 체인별 공식 uptime feed 주소를 확인한다.
- answer가 down이면 가격 의존 작업을 중단한다.
- up이면 startedAt 이후 grace period를 계산한다.
- 그 뒤 별도 가격 feed의 updatedAt과 범위를 검사한다.
초기화와 전달 지연을 안전하게 처리한다
일부 환경에서는 feed 초기화 직후 startedAt이나 round 값이 예상과 다를 수 있습니다. Chainlink 문서의 체인별 주의사항을 읽고 startedAt이 0이거나 미래 시각, answer가 허용 범위 밖이면 안전 실패합니다. 단순히 0을 up으로 간주하기 전에 round 데이터가 유효한지 확인합니다.
상태는 L1에서 감지돼 L2 feed로 전달될 수 있어 메시지 경로 지연이 존재합니다. 실제 시퀀서 장애 시작과 온체인 answer 전환 사이의 차이를 모니터링합니다. 피드가 down을 알리기 전 짧은 구간도 위험 모델에 포함합니다.
feed 주소와 프록시 변경을 운영 절차에 넣는다
uptime feed는 네트워크마다 주소가 다르며 지원 체인도 시간에 따라 바뀔 수 있습니다. 공식 주소 페이지에서 대상 L2를 확인하고 테스트넷 주소를 메인넷에 쓰지 않습니다. AggregatorV3Interface의 description, decimals, latestRoundData 반환을 배포 시 기록합니다.
프록시가 새 aggregator를 가리키거나 메시지 전달 계약이 바뀌면 이벤트와 운영 공지를 확인합니다. 하드코딩된 주소 변경에는 timelock과 테스트가 필요합니다. fallback으로 임의의 RPC 응답만 사용하면 합의된 온체인 상태와 달라질 수 있습니다.
장애·복구·가격 지연을 따로 시험한다
테스트에서는 down 전환, 장기 down, up 전환 직후, grace period 경계, 가격 feed stale 상태를 각각 만들고 어떤 함수가 revert하는지 확인합니다. block timestamp를 경계 앞뒤로 움직여 부등호 오류를 찾습니다. 청산 봇과 프런트엔드도 같은 정책을 표시해야 합니다.
운영 모니터링은 sequencer answer와 startedAt, 별도 가격 updatedAt, 중단된 함수 비율을 함께 봅니다. uptime feed가 장애를 알려도 프로토콜 상태가 자동 복구되는 것은 아닙니다. 누가 pause를 해제하고 미처리 포지션을 어떤 순서로 처리할지 런북을 준비합니다.
자주 묻는 질문
answer가 0이면 바로 청산을 재개해도 되나요?
복구 직후에는 grace period가 지나야 하며 그 뒤에도 가격 피드의 최신성과 범위를 별도로 확인해야 합니다.
uptime feed가 가격도 제공하나요?
아닙니다. 시퀀서 가용성 상태를 제공하며 자산 가격은 별도의 price feed에서 읽습니다.
시퀀서가 멈추면 L2 자산이 사라지나요?
자산이 사라지는 뜻은 아니지만 일반 거래 제출과 빠른 포함이 어려워질 수 있습니다. 체인별 L1 강제 경로와 지연을 확인하세요.
