레이어2 위험은 ‘이더리움 위에 있다’는 한 문장으로 판단할 수 없습니다. 핵심 계약을 누가 얼마나 빨리 바꿀 수 있는지, 시퀀서가 멈추거나 검열할 때 사용자가 L1으로 거래·출금을 강제할 수 있는지, 상태 복구 데이터가 공개되는지를 함께 확인해야 합니다.
위험 지도를 네 층으로 나눈다
L2를 볼 때 상태 검증, 데이터 가용성, 거래 순서, 자산 보관을 분리하면 모호한 ‘탈중앙화’ 논쟁을 실제 질문으로 바꿀 수 있다. 상태 검증은 잘못된 전이를 막는 방식, 데이터 가용성은 재구성 재료의 위치, 거래 순서는 시퀀서 권한, 자산 보관은 브리지 계약과 출금 규칙이다.
L2BEAT Risk Analysis는 프로젝트별로 상태 검증과 데이터, 업그레이드, 시퀀서 실패, 제안자 실패 같은 위험을 구분한다. 등급은 유용한 출발점이지만 특정 날짜의 분석이므로 공식 계약과 문서를 다시 열어 현재 상태를 확인한다.
| 영역 | 핵심 질문 | 확인 증거 |
|---|---|---|
| 상태 검증 | 잘못된 상태를 누가 막나 | 증명 계약·가동 상태 |
| 데이터 | 상태를 독립 재구성할 수 있나 | blob/calldata/외부 DA |
| 순서·검열 | 시퀀서 우회가 가능한가 | 강제 포함 함수·지연 |
| 업그레이드 | 누가 얼마나 빨리 코드를 바꾸나 | 프록시 관리자·타임록 |
| 출금 | 운영자 없이 L1 탈출 가능한가 | 강제 출금 절차·테스트 |
업그레이드 가능성은 버그 수정과 권한 위험을 함께 만든다
프록시 계약은 저장 상태를 유지한 채 구현 코드를 바꿀 수 있어 긴급 수정에 유리하다. 동시에 관리자 키가 탈취되거나 거버넌스가 장악되면 보안 규칙 자체가 바뀔 수 있다. 멀티시그라는 이름만으로 충분하지 않고 소유자 수, 임계값, 주체 중복, 타임록을 본다.
업그레이드 지연이 있으면 사용자가 변경 내용을 보고 출금할 시간이 생길 수 있다. 그러나 지연을 우회하는 비상 권한이 있거나 출금 자체가 같은 관리자 통제 아래라면 보호가 약해진다. 핵심 계약별 관리자 주소와 실제 Upgraded 이벤트를 탐색기에서 확인한다.
시퀀서 다운과 검열은 다른 실패다
시퀀서 다운은 새 L2 거래가 지연되는 가용성 문제다. 검열은 특정 사용자의 거래를 의도적으로 포함하지 않는 문제다. L1 강제 포함 경로가 있어도 대기 시간, 호출 비용, 필요한 데이터가 달라 실제 사용 가능성이 좌우된다.
Optimistic rollups는 사용자가 L1에서 거래를 제출해 시퀀서가 일정 시간 안에 포함하도록 하는 설계를 설명한다. 모든 L2가 같은 인터페이스를 쓰는 것은 아니므로 공식 장애 문서와 계약 함수로 확인한다.
출금 경로는 정상·강제·비상으로 나눠 본다
정상 출금은 공식 UI와 시퀀서가 동작하는 흐름이다. 강제 출금은 운영자가 협조하지 않아도 L1 계약과 게시 데이터로 자산을 회수하는 흐름이다. 비상 모드는 위원회나 거버넌스가 시스템을 정지·복구하는 별도 권한일 수 있다.
문서에 ‘escape hatch’가 있다고 끝이 아니다. 활성화 조건과 대기 기간, 필요한 상태 증명, 지원 클라이언트, 수수료를 기록한다. 빠른 브리지나 제3자 유동성 출금은 상대방·유동성 위험이 추가되므로 네이티브 출금과 분리한다.
- 공식 문서에서 핵심 L1 계약 주소 수집
- 탐색기에서 프록시 구현·관리자·타임록 확인
- 시퀀서 장애 시 L1 강제 포함 절차 확인
- 네이티브 출금과 유동성 브리지 구분
- 최근 업그레이드 이벤트와 공지 대조
데이터가 없으면 증명을 만들거나 출금하기 어렵다
사기 증명은 잘못된 계산을 재현할 데이터가 필요하고, 사용자 출금 증명도 상태 재구성이 필요하다. 유효성 증명이 상태의 옳음을 보여도 사용자가 운영자 없이 자신의 상태를 이어 가려면 공개 데이터가 중요하다.
데이터가 이더리움 blob 또는 calldata에 있는지, 별도 DA 네트워크나 위원회에 있는지 확인한다. 외부 DA는 비용과 처리량 이점이 있을 수 있지만 실패·검열·재구성 주체의 가정이 달라진다. 홍보상의 ‘모듈형’보다 실제 게시 위치를 본다.
L2의 안전성은 정상 속도가 아니라 운영자 없이 남는 권리로 측정한다.
JOBCOIN 해설
점수보다 변경 이력을 보관한다
위험 대시보드는 복잡한 구조를 비교하기 좋지만 색상 하나가 모든 사용 목적을 대신하지 않는다. 소액 결제와 장기 보관, 개발 배포는 허용 가능한 실패가 다르다. 자신에게 중요한 열을 먼저 정하고 근거 링크를 붙인다.
L2는 빠르게 업그레이드되므로 확인 날짜와 계약 버전을 남긴다. 한 달 뒤 구현 주소, 타임록, 증명 가동 상태가 달라졌는지 재검사하면 ‘언젠가 탈중앙화될 계획’과 현재 보호를 분리할 수 있다.
권한 주소가 멀티시그라면 소유자 목록과 임계값뿐 아니라 모듈·가드·대리 실행 권한을 확인한다. 명목상 5명 중 3명 서명이라도 세 키가 같은 조직의 동일 인프라에 있으면 독립 실패를 줄이지 못한다. 공개 정보만으로 키 보관 방식을 알 수 없다면 확인 불가로 남겨야 한다.
점검 결과는 위험의 존재와 현재 사고를 구분해 쓴다. 업그레이드 키가 있다는 사실은 곧 악용됐다는 뜻이 아니며, 시퀀서가 하나라는 사실도 현재 검열의 증거는 아니다. 구조상 가능한 실패와 관측된 사건을 다른 열에 적어 과장과 안심을 모두 피한다.
자주 묻는 질문
L2BEAT 점수가 높으면 안전이 보장되나요?
아닙니다. 공개 기준에 따른 비교 자료이며 목적별 위험과 최신 계약 상태를 대신하지 않습니다. 항목별 근거와 확인 날짜를 보세요.
멀티시그 관리자면 단일 키보다 무조건 안전한가요?
키 하나의 실패를 줄일 수 있지만 임계값, 소유자 독립성, 모듈 권한, 타임록에 따라 위험이 달라집니다. 온체인 구성과 변경 절차를 확인해야 합니다.
시퀀서가 멈추면 자산도 사라지나요?
즉시 자산 소실을 뜻하지는 않지만 거래·출금이 지연될 수 있습니다. L1 강제 포함과 강제 출금 경로가 실제로 작동하는지가 핵심입니다.
