잘못된 블록 하나가 Base의 109.5억달러 체인을 110분 멈췄다

외부 공격자 누구도 해내지 못한 일을, 형식이 잘못된 블록 하나가 해냈다. 약 109억5천만 달러 규모의 가치를 보호하던 체인이 거의 두 시간 동안 멈춰 선 것이다. 2026년 6월 25일, Coinbase가 인큐베이팅한 이더리움 레이어2 네트워크 Base는 단순히 블록 생성을 멈췄다.

2026년 6월 25일, Base는 왜 멈췄나?

Base가 멈춘 이유는 컨센서스 문제가 유효하지 않은 블록의 시퀀싱으로 이어지면서, 이후 모든 블록 생성이 약 108분 동안 중단됐기 때문이다. 메인넷 블록 생성은 16:03 UTC에 "unhealthy" 상태가 됐고, 시퀀싱은 17:51 UTC가 되어서야 재개됐다 . 이는 라이브니스 실패, 즉 체인이 멈춘 사건이었지 안전성 실패는 아니었다. 사용자 자금은 위험에 처하지 않았고, 이더리움 L1은 그동안에도 Base 아래에서 계속 정산을 처리했다 .

Quick Answer: Base는 2026년 6월 25일 유효하지 않은 블록(47,806,542)이 단일 시퀀서에서 컨센서스 정지를 일으킨 뒤 약 108분 동안 블록 생성을 중단했다. 이는 안전성 실패가 아니라 라이브니스 실패였으며, 이더리움 L1은 계속 정산을 처리했고 약 109억5천만 달러 규모의 가치를 담은 체인에서 모든 자금은 안전하게 유지됐다.

Base는 17:21 UTC에 원인을 확인하며, 진단 범위를 "유효하지 않은 블록이 시퀀싱되도록 만든 컨센서스 문제"로 좁혔다. 이 문제로 블록 47,806,542 이후 새 블록이 생성되지 못했다 . OP Stack 용어로는 이것이 "unsafe head stall"이다. 아직 이더리움 L1에서 최종 확정되지 않은, 시퀀서가 생성한 최신 블록이 더 이상 전진하지 못한 상태를 뜻한다 . 이는 2026년 Base 체인에서 발생한 가장 중대한 신뢰성 사고였다 .

독립 모니터링도 이 정지를 확인했다. L2BEAT의 라이브니스 추적기는 16:05부터 17:23 UTC까지 Base의 이더리움 트랜잭션 데이터 제출이 0건이었다고 기록했다. 정상 제출 간격이 약 46초인 것과 비교하면 1시간 18분 12초짜리 이상 현상이었다 . 이 제3자 데이터가 중요한 이유는, 정지가 운영자의 상태 페이지 공지에 그친 것이 아니라 온체인에서도 관측됐음을 보여주기 때문이다.

트레이더에게 가장 중요한 포인트는 라이브니스와 안전성의 차이다. unsafe head stall은 블록이 이더리움 L1에 정산되기 전에 발생하므로, 영구 손실이나 체인 재구성에 대한 노출은 없다. L2 상태는 보존됐고, 잔액은 그대로 유지됐으며, L1 탈출 경로도 계속 열려 있었다 . Base도 X에서 "all funds are secure"라고 분명히 밝혔지만, 예치, 출금, 온체인 활동은 그 시간 동안 멈춰 있었다 .

결국 중단된 것은 소유권이 아니라 접근성이었다. 새로운 Base 블록에 의존하는 앱, 지갑, 거래소, 브리지 서비스는 모두 그 시간 동안 멈췄고, 영향을 받은 상태 구성요소는 메인넷 예치, 출금, 블록 생성, 클라이언트 소프트웨어였다 . 이어지는 섹션에서는 블록 47,806,542가 정확히 어떻게 컨센서스를 깨뜨렸는지, 타임라인이 분 단위로 어떻게 전개됐는지, 그리고 단일 시퀀서 구조가 왜 하나의 잘못된 블록을 네트워크 전체 중단으로 키웠는지 살펴본다.

근본 원인: 블록 47,806,542가 Base 합의를 무너뜨린 과정

Base의 6월 25일 중단은 단 하나의 잘못된 블록, 즉 47,806,542번 블록에서 비롯됐다. 이 블록은 유효하지 않았는데도 시퀀싱됐고, 이후 이어지는 모든 블록 생성 시도를 오염시켰다. 17:21 UTC까지 Base는 원인을 “유효하지 않은 블록이 시퀀싱되도록 만든 합의 문제”로 좁혔으며, 이로 인해 해당 높이 이후 새 블록이 형성되지 못했다 . 두 조사 흐름 모두 이것이 하나의 잘못된 L2 블록을 둘러싼 합의/클라이언트 결함이었다는 데 의견을 같이한다. 이더리움 L1 장애도 아니었고, 공개된 익스플로잇도 아니었다 .

OP Stack 용어로 이 사건은 “unsafe head stall”로 분류된다. unsafe head는 시퀀서가 생성했지만 아직 이더리움 L1에서 최종 확정되지 않은 최신 블록을 뜻한다. 6월 25일에는 유효하지 않은 블록이 들어온 뒤 이 head가 더 이상 앞으로 나아가지 못했다 . 이 장애 양상이 중요한 이유는 멈춤이 정산 레이어 위에서 발생했기 때문이다. 라이브 팁은 멈췄지만, 그 아래에서는 이더리움이 이전 Base 배치들을 계속 최종 확정하고 있었다 .

문제의 핵심은 연쇄 반응이었다. Base의 자체 사고 업데이트에 따르면, 합의 레이어가 블록 47,806,542를 받아들이자 그 블록이 “이후 모든 블록 생성에 간섭”했다. 모든 후속 블록은 유효한 이전 블록에 의존하므로, 하나의 손상된 연결고리가 전체 생산 파이프라인을 얼려버린 것이다 . 잘못된 블록을 우회하는 자동 결함 감지나 페일오버는 없었다. 복구에는 Base가 시퀀서를 수동으로 조치해야 했고, 이후 생태계의 노드 운영자들도 동기화를 재개하려면 각자 노드를 재시작해야 했다. Base는 17:51 UTC에 노드 운영자들에게 재시작을 명시적으로 안내했고, 19:22 UTC에는 여전히 블록 47,806,542에서 멈춘 노드는 재시작과 재동기화 이후에야 복구된다고 다시 밝혔다 .

이처럼 수동적이고 운영자에게 의존한 복구 경로 자체가 구조적 신호다. 체인은 스스로 회복하지 못했다. 블록 생산이 정상 상태로 돌아오기 전까지 시퀀서에 대한 사람의 개입과 생태계 전반의 노드 재시작 조율이 필요했다 . 다음 섹션에서는 그 조치가 시간대별로 어떻게 진행됐는지 살펴본다.

확인된 사실만큼이나 아직 알려지지 않은 점도 중요하다. Base는 근본 원인을 찾았고 수정 사항을 검증 중이며, 유효하지 않은 블록이 시퀀싱 파이프라인에 어떻게 들어왔는지와 어떤 검증 절차가 바뀔지를 설명하는 전체 사후 분석(RCA)을 공개하겠다고 밝혔다 . 6월 26일 기준, 공개 기록에는 아직 다음 내용이 드러나지 않았다.

• 유효하지 않은 블록이 시퀀싱될 수 있게 한 정확한 버그와 영향을 받은 코드 경로 .
• 모든 클라이언트가 같은 유효하지 않은 블록을 일관되게 수용했거나 거부했는지, 아니면 클라이언트 간에 분기가 있었는지 .
• 관측된 중단 외에 어떤 트랜잭션이 누락, 지연, 또는 재정렬됐는지 여부 .

RCA가 공개되기 전까지 기술적 결론은 좁지만 분명하다. 높이 47,806,542의 단일 유효하지 않은 블록이 Base의 합의를 무너뜨렸고, 체인은 이를 자동으로 격리하거나 우회하지 못했으며, 완전한 복구는 수동 시퀀서 조치와 생태계 전반의 노드 재시작에 달려 있었다 .

사고 타임라인: 16:03 UTC부터 19:22 UTC까지

2026년 6월 25일 장애의 공개 기록은 16:03 UTC 첫 상태 페이지 알림부터 19:22 UTC 정상화 선언까지 3시간 19분에 걸쳐 있지만, 실제로 눈에 보인 블록 생성 중단은 첫 조사부터 17:51 UTC 시퀀싱 재개까지 약 1시간 48분 동안 이어졌다 . Base의 사고 페이지는 여섯 개 체크포인트를 거치며, 모호한 "unhealthy" 상태에서 단일 블록 높이의 합의 결함으로 진단 범위를 좁혀 갔다 .

흐름은 16:03 UTC Base 공식 사고 페이지가 열리면서 시작됐다. 당시 페이지는 메인넷 블록 생성이 "unhealthy" 상태이며 조사가 진행 중이라고 밝혔다 . 16:52 UTC에는 이후 블록 생성을 적극적으로 방해하는 문제가 있는 블록을 팀이 확인했고, 17:21 UTC에는 더 좁은 진단을 내놓았다. 합의 문제가 유효하지 않은 블록을 시퀀싱하게 만들었고, 그 결과 블록 47,806,542 이후 새 블록 생성이 멈췄다는 설명이었다 .

복구 체크포인트는 빠르게 이어졌다. 17:51 UTC에 시퀀싱이 재개됐고, Base는 생태계 노드 운영자들에게 동기화 복구를 위해 노드를 재시작하라고 안내했다. 17:58 UTC에는 블록 생성이 정상 상태임을 확인하면서 Beryl 하드포크가 예정대로 활성화될 것으로 여전히 예상한다고 밝혔다. 19:22 UTC에는 Base가 시퀀서와 지원 시스템이 안정적이라고 선언했으며, 블록 47,806,542에 여전히 멈춰 있는 노드는 재시작과 재동기화 후 복구될 것이라고 설명했다 .

독립적인 확인도 이 시간대의 온체인 영향을 뒷받침한다. L2BEAT의 라이브니스 트래커는 16:05부터 17:23 UTC까지 Base의 트랜잭션 데이터 제출이 없었다고 기록했다. 일반적인 제출 간격이 약 46초인 것과 비교하면 1시간 18분 12초짜리 이상 구간이었다 . 이 제3자 관측 공백은 Base 자체 타임라인과 맞아떨어지며, 이번 정지가 상태 페이지의 보고상 착시가 아니라 실제 데이터 제출 중단이었다는 점을 확인해 준다 .

라이브니스 실패와 안전성 실패는 어떻게 다른가

Base 장애는 안전성 실패가 아니라 라이브니스 실패였다. 체인은 블록 생성을 멈췄지만, 자금이 사라지거나 잔액이 다시 쓰인 것은 아니었다. 이 차이는 트레이더가 이번 사건에서 가장 먼저 이해해야 할 지점이다. "unsafe head stall"은 체인의 unsafe head, 즉 아직 Ethereum에서 최종 확정되지 않은 가장 최근의 시퀀서 생성 블록이 더 이상 전진하지 않을 때 발생한다. 중요한 점은 이것이 해당 블록들이 Ethereum L1에 정산되기 전에 일어난다는 것이다 . 영향을 받은 블록들이 아직 정산 레이어에 기록되지 않았기 때문에 영구적인 상태 변경은 없었고, 의미 있는 체인 재구성도 가능하지 않았다 .

약 110분 동안 중단이 이어지는 동안에도 Ethereum L1은 Base 아래에서 계속 정산을 진행했다. 계정 잔액과 컨트랙트 상태는 정산 레이어에 보존됐고, Ethereum은 이미 보유한 데이터를 계속 최종 확정했으며, 시퀀싱이 재개됐을 때 L2 상태는 온전했다 . Base는 X에서 "all funds are secure"라고 명확히 밝혔다 . 이번 사건은 분명히 라이브니스 쪽의 문제였다. 체인은 멈췄지만 자금이 사라지거나 순서가 바뀌지는 않았다 .

이 안전성 보장은 구조적인 것이며, 마지막 안전장치도 있다. L1 탈출 경로가 존재하므로 Base 시퀀서가 꺼지더라도 사용자는 Ethereum을 통해 직접 트랜잭션을 셀프 시퀀싱할 수 있다. 다만 L2BEAT는 이 경로에 최대 12시간의 지연이 따를 수 있다고 설명한다 . 다시 말해 탈출 경로는 자산을 결국 이동할 수 있음을 보장하는 안전망이지, 장애 중에도 거래나 결제가 계속 흐르게 해 주는 실시간 우회로는 아니다.

"All funds are secure," — 6월 25일 사고 당시 Base 팀이 공식 X 채널을 통해 밝힌 내용 (source: crypto.news).

그렇다고 이번 장애가 무해했다는 뜻은 아니다. 실제 피해는 지급능력이 아니라 가용성에 있었다. 약 110분 동안 입금, 출금, 브리지 서비스, 그리고 최신 Base 블록에 의존하는 모든 앱이나 지갑이 멈췄다 . 트레이더는 담보를 입금할 수 없었고, 마켓메이커는 포지션을 재조정할 수 없었으며, 스테이블코인으로 정산되는 결제는 단순히 확정되지 않았다. 자금 손실이 전혀 없더라도 이는 경제적으로 큰 차질이다. 기회비용, 놓친 청산, 지연된 정산, 평판 부담이 모두 정지 시간 동안 쌓인다. Base 위에서 구축하거나 정산하는 이들에게 남은 교훈은 혼동하기 쉬운 두 가지 리스크를 분리해야 한다는 점이다. Ethereum L1에서 물려받은 자산 보안 보장은 완벽히 유지됐지만, 연속적인 블록 생성이라는 운영상 보장은 지켜지지 않았다.

단일 시퀀서의 함정: 아키텍처, 지연 시간, 거래상대방 리스크

그 운영상의 공백은 Base의 설계 방식과 직접 맞닿아 있다. Base는 트랜잭션 순서를 정하고 블록을 생성하는 구성 요소인 단일 시퀀서로 운영되며, 이 시퀀서는 Coinbase가 운영한다. 바로 이 설계 때문에 잘못 만들어진 블록 하나가 장애를 우회하지 못하고 전체 네트워크를 멈출 수 있다 . 중복 경로는 없다. 47,806,542번 블록이 합의 검증에 실패했을 때 유효한 블록 생성을 이어갈 백업 시퀀서가 없었고, 결국 팀이 개입할 때까지 체인은 그대로 멈췄다 .

불편한 지점은 이와 같은 아키텍처가 Base의 핵심 성능 지표를 만들어낸다는 점이다. Base 문서는 메인넷 블록 생성 구조를 정식 L2 블록이 2초마다 생성되는 위에 200ms마다 Flashblocks가 얹히는 방식으로 설명하며, 포함 단계는 약 200ms Flashblock 포함, 약 2초 L2 블록 포함, 약 2분 L1 배치 포함, 약 20분 L1 배치 최종성으로 제시한다 . 이 보장은 모두 하나의 조율된 시퀀서가 계속 유효한 블록을 생성한다는 전제 위에 있다. 지연 시간상의 이점과 장애 양상은 같은 뿌리에서 나온다. 중앙화된 정렬은 여러 생성자 간 합의 조율이 없기 때문에 빠르고, 바로 그 이유 때문에 단일 클라이언트나 합의 결함 하나가 전체를 멈춘다 .

"단일 시퀀서 제어는 소프트웨어나 합의 문제가 발생할 경우 팀이 조치를 취할 때까지 전체 블록체인 네트워크가 멈춘다는 뜻이다"라고 한 사고 분석은 요약했다 (source: Bitcoin.com News).

독립 추적 사이트 L2BEAT는 구조적 상황을 명확하게 보여준다. L2BEAT는 Base를 Stage 1 Optimistic Rollup, 체인 ID 8453으로 분류하며, 캡처된 페이지 기준 총 예치 가치가 109억5,000만 달러라고 표시한다. 또한 시퀀서 장애를 잔여 리스크로 지적한다. 사용자는 Ethereum L1을 통해 자체 시퀀싱할 수 있지만, 최대 12시간의 지연이 발생할 수 있다 . L2BEAT는 또 다른 중앙화 지점인 거버넌스도 지적한다. Base의 컨트랙트는 출구 기간 없이 즉시 업그레이드할 수 있으며, Base Coordinator Multisig와 Base Security Council의 승인만 필요하다 . 시퀀싱 중앙화와 업그레이드 중앙화는 서로 다른 리스크지만, 둘 다 운영자가 보유한 키에 통제권을 집중시킨다.

탈중앙화 시퀀서 세트는 Base의 로드맵에 올라와 있고, 여러 다른 OP Stack 체인에도 포함돼 있지만 아직 프로덕션에 적용된 사례는 없다 . 탈중앙화 시퀀서나 대체 시퀀서가 실제로 가동되기 전까지, 모든 단일 시퀀서 장애는 Base를 통해 결제를 라우팅하는 프로토콜이나 기관에 거래상대방 리스크로 작용한다. 특히 스테이블코인과 토큰화된 실물자산 흐름에서는 연속적인 블록 생성이 몇 시간 멈추는 일이 직접적인 결제 결과로 이어진다 . Ethereum에서 물려받은 자산 보안 보장은 하나의 문제이고, 누가 체인을 멈출 수 있으며 얼마나 오래 멈출 수 있는지는 이제 개인 및 기관 사용자 모두가 가격에 반영해야 할 별개의 문제다.

Beryl 하드포크 시점: 실제 증거가 보여주는 것

Beryl 하드포크는 2026년 6월 25일 18:00:00 UTC에 활성화될 예정이었다. 시퀀싱이 17:51 UTC에 재개된 지 불과 9분 뒤였다 . 이처럼 시간이 맞물렸다는 점이 업그레이드 창이 이번 사안의 일부로 다뤄지는 핵심 이유다. Beryl은 스테이블코인과 토큰화된 실물자산에 대한 새로운 표준을 도입하며, 온체인 활성화 시각도 1782410400으로 정확히 지정돼 있었다 . 예정된 컨센서스 변경을 몇 시간 앞둔 시점에 유효하지 않은 블록이 체인을 멈춰 세웠다면 당연히 면밀히 따져봐야 할 우연이다. 하지만 우연과 원인은 같은 것이 아니며, 현재까지의 공개 기록은 전자만 뒷받침한다.

업그레이드 전에 필요한 소프트웨어는 base/node v1.1.1 이상이었고, 여기에는 실행 클라이언트(base-reth-node)와 컨센서스 클라이언트(base-consensus)가 모두 포함됐다 . 해당 릴리스는 사고 약 일주일 전인 6월 18~19일에 공개돼, 노드 운영자들이 활성화 시각 전에 업그레이드할 시간이 있었다 .

v1.1.1 릴리스 노트에서 주목할 만한 변경 사항은 두 가지다:

• "Beryl Support for Mainnet" — 예정된 시각에 하드포크를 실행하는 데 필요한 컨센서스 규칙과 클라이언트 로직 .
• Flashblocks 수정 — BLOCKHASH opcode에 의존하는 트랜잭션이 Flashblocks 처리와 표준 블록 처리에서 서로 다른 실행 결과를 내는 문제를 다룬 수정 .

두 항목 모두 유효하지 않은 블록의 원인으로 확인된 것은 아니다. BLOCKHASH 불일치는 겉으로 보기에는 그럴듯한 의심 대상이다. 한 클라이언트는 받아들이고 다른 클라이언트는 거부하는 블록을 만들 수 있는, 정확히 그런 유형의 실행 불일치이기 때문이다. 하지만 릴리스 노트는 6월 25일의 유효하지 않은 블록이 BLOCKHASH, Flashblocks, 또는 다른 특정 변경 때문에 발생했다고 밝히지 않는다 . 이 릴리스 노트를 결정적 증거로 보는 것은 증거가 아니라 추론이다.

주목할 점은 Base가 업그레이드를 중단하거나 일정을 다시 잡지 않았다는 것이다. 블록 생성이 다시 정상이라고 선언한 지 몇 분 뒤인 17:58 UTC, 팀은 여전히 Beryl이 예정대로 활성화될 것으로 본다고 확인했고, 하드포크는 직전의 장애에도 불구하고 일정대로 진행됐다 . 이 결정은 팀이 해결된 컨센서스 결함과 예정된 업그레이드가 같은 문제가 아니라고 확신했음을 시사한다. 다만 확신에 찬 운영 판단이 곧 공개된 포렌식 결론은 아니다.

정직하게 요약하면 이렇다. 공개 기록은 유효하지 않은 블록과 업그레이드 전 소프트웨어 적용 기간 사이의 시간적 상관관계는 보여주지만, 인과관계까지 입증하지는 않는다. Base는 유효하지 않은 블록이 어떻게 시퀀싱 파이프라인에 들어왔는지, 어떤 검증 절차를 바꿀 것인지 자세히 설명하는 전체 사후 분석을 공개하겠다고 밝혔다 . 6월 26일 기준으로, 그 기록은 아직 정확한 버그, 영향을 받은 코드 경로, 또는 모든 클라이언트가 해당 유효하지 않은 블록을 동일하게 처리했는지를 공개하지 않았다 . 해당 RCA가 나오기 전까지는, 앞으로 공개될 사후 분석만이 Beryl 관련 코드가 실제로 관여했는지 아니면 단지 일정상 가까이 있었을 뿐인지 가려낼 수 있는 유일한 근거다. Base 결제 리스크를 평가하는 독자라면 어느 쪽으로든 단정하기보다 그 결과를 기다리는 편이 맞다.

Base 장애 이력: 10개월 사이 세 차례 사고

Base는 약 10개월 동안 서로 다른 세 건의 안정성 사고를 기록했으며, 6월 25일 중단은 약 110분으로 2026년 들어 가장 긴 블록 생성 중단이었다 . 앞선 두 사건은 장애 양상의 양끝에 놓여 있었다. 하나는 짧은 합의 정체였고, 다른 하나는 며칠에 걸친 출금 장애였다. 하지만 세 사건 모두 결국 같은 방식으로 마무리됐다. 사람이 문제 구성 요소를 찾아내고 수동으로 개입한 것이다. Base 결제 위험을 가격에 반영하려는 독자라면, 개별 버그보다 이 반복되는 대응 방식에 더 주목해야 한다.

첫 공개 사례는 2025년 8월에 나왔다. 당시 Base는 약 33분 동안 정체를 겪었고, 정상 상태의 시퀀서로 수동 전환해 해결했다 . 문제 블록을 식별하고, 수작업으로 조치한 뒤, 블록 생성을 복구하는 이 절차는 이후 Base가 반복하게 될 틀이 됐다. 2026년 5월에는 다른 형태의 장애가 드러났다. 약 30시간 동안 이어진 출금 장애였는데, 체인은 계속 블록을 생성하는 동안 특정 출구 경로만 성능이 저하됐다는 점에서 전체 블록 생성 중단과는 달랐다 .

6월 25일 사건은 보도에서 약 90일 만에 발생한 Base 메인넷의 첫 전면적 블록 생성 중단으로 설명됐다 . 2025년 8월과 마찬가지로 복구의 핵심은 수동 조치였다. Base 인프라를 운영하는 노드 운영자들이 동기화를 재개하려면 노드를 재시작해야 했다 .

세 사건의 공통점은 자동 장애 감지나 자동 전환으로 해결된 것이 하나도 없었다는 점이다. 모두 단일 시퀀서 장애에 대해 사람이 개입하는 대응이 필요했다 . 이것이 탈중앙화 시퀀서 로드맵과 실제 운영 인프라 사이의 현실적인 간극이다. 대체 경로나 탈중앙화된 시퀀서 세트가 출시되기 전까지는, 복구 속도를 좌우하는 것은 프로토콜 자체가 아니라 운영팀이 얼마나 빨리 진단하고 개입하느냐다 .

Base에서 정산하는 DeFi 사용자와 빌더가 알아야 할 점

6월 25일의 실질적인 교훈은 단일 시퀀서 체인에서 "자금 손실 없음"과 "비용 없음"은 같은 말이 아니라는 점입니다. UTC 16:03에 첫 공개 조사가 시작된 뒤 19:22에 시퀀서가 안정화되기까지 110분 동안 영구적인 손실은 없었습니다 . 하지만 새 Base 블록이 필요한 모든 시간 민감형 온체인 작업은 그동안 실행될 수 없었습니다 . Beryl 이후 Base가 스테이블코인과 토큰화된 실물자산(RWA) 정산 물량을 더 많이 흡수할수록, 이 가용성 공백 자체가 경제적으로 중요해집니다. 놓친 청산, 실패한 차익거래 구간, 강제된 브리지 지연은 잔고가 그대로 유지되더라도 실제 비용으로 누적됩니다.

Beryl의 방향성 때문에 부담은 더 커집니다. 이번 하드포크는 스테이블코인과 토큰화된 RWA를 위한 새 표준을 도입합니다 . 이는 Base가 정산 레일로 끌어들이려는 기관들이 Ethereum L1에서 물려받는 자산 보안 보장만이 아니라, 체인의 가용성 서비스 수준까지 평가하게 된다는 뜻입니다. 토큰화 자산을 정산하는 트레저리 데스크는 장기 보유자처럼 2시간의 블록 생성 중단을 아무 일도 아닌 것으로 볼 수 없습니다.

이 위험을 얼마나 진지하게 봐야 할지는 두 가지 신호가 좌우합니다.

• 단기 — 사후 분석. Base는 잘못된 블록이 시퀀싱 파이프라인에 어떻게 들어갔는지, 어떤 검증 절차를 바꿀 것인지 설명하는 전체 RCA를 공개하겠다고 밝혔습니다 . 6월 26일 기준으로는 해당 기록이 정확한 버그나 영향을 받은 코드 경로를 아직 공개하지 않았습니다 . 수정이 좁은 범위의 일회성 패치라면 잔여 위험은 낮습니다. 반대로 잘못된 블록 47,806,542가 통과되도록 만든 구조적인 클라이언트 검증 공백이 드러난다면, 두 경우의 위험 프로필은 실질적으로 달라집니다.
• 중기 — 탈중앙화 시퀀서. Base는 여전히 Coinbase가 운영하는 단일 시퀀서에 의존하고 있으며, 탈중앙화 시퀀서나 대체 시퀀서 세트는 출시된 인프라가 아니라 로드맵 항목으로 남아 있습니다 . 이것이 출시되기 전까지 Base를 통해 시간 민감형 트랜잭션을 보내는 모든 프로토콜이나 펀드는 단일 시퀀서 거래상대방 위험을 떠안습니다. L1을 통한 자체 시퀀싱은 가능하지만 최대 12시간 지연이 따릅니다 .

개인 트레이더에게 적용할 실무적 관점은 단순합니다. 가용성 이벤트가 발생해도 자산은 안전하지만, 전략은 안전하지 않습니다. LP 리밸런싱, 청산 트리거, 크로스체인 차익거래는 시퀀서 중단이 이어지는 동안 완전한 실행 공백에 놓입니다. Base의 일반적인 최종성도 시퀀서가 유효한 블록을 계속 생성한다는 전제 위에 있으며, L1 배치 최종성도 약 20분으로 안내됩니다 . 이를 염두에 두고 Base 네이티브 프로토콜의 포지션 크기를 정해야 합니다. 중단 없는 블록 생성을 전제로 하는 얇은 마진의 시간 민감형 레버리지나 자동화 전략은 피하고, 계획 안에 L1 출구 경로를 유지하세요.

핵심 결론은 이렇습니다. Base는 Ethereum 정산으로 자금을 보호하면서 109.5억 달러를 확보한 Stage 1 Optimistic Rollup으로 남아 있습니다 . 하지만 이제 지배적인 운영 리스크는 자산 보안이 아니라 가용성입니다. 앞으로 나올 RCA와 탈중앙화 시퀀서 출시일을 신뢰도를 움직일 두 지표로 보고, 대체 시퀀서가 실제로 가동되기 전까지 Base에서 정산하는 모든 것에 단일 시퀀서 거래상대방 위험을 반영해야 합니다.

Last updated: 2026-06-26. Base의 공개 사고 페이지와 2026년 6월 26일 기준 L2BEAT 가용성 데이터를 검토했습니다. Base가 전체 근본 원인 분석을 공개하면 수치는 수정될 예정입니다.

자주 묻는 질문

2026년 6월 25일 Base 장애 때 사용자 자금이 위험했나요?

아니요. 6월 25일 사고는 안전성 장애(자금 손실이나 재구성 발생)가 아니라 라이브니스 장애(체인이 블록 생성을 멈춘 상황)였습니다. unsafe head 정지는 블록이 Ethereum L1에 정산되기 전에 발생하므로, Ethereum이 Base 아래에서 계속 정산되는 동안 잔액과 L2 상태는 보존됐고, 팀은 X에서 모든 자금이 안전하다고 밝혔습니다 . L1 탈출 경로는 존재하지만, L2BEAT는 L1을 통한 자체 시퀀싱에는 최대 12시간 지연이 따른다고 설명합니다 — 따라서 이는 정지 중 실시간 출구라기보다 자산 복구를 위한 안전망에 가깝습니다.

Base 블록체인이 정확히 왜 블록 생성을 멈췄나요?

합의 문제가 발생해 47,806,542번 블록이 유효하지 않은 블록으로 시퀀싱됐고, 그 결과 이후의 모든 블록 생성 과정에 영향을 주면서 새 블록 진행이 막혔습니다 . 이는 Ethereum L1 장애도 아니고 공개된 익스플로잇도 아니었습니다. 6월 26일 기준 Base는 전체 근본 원인 분석을 공개하겠다고 했지만, 구체적인 버그, 영향을 받은 코드 경로, 모든 클라이언트가 같은 유효하지 않은 블록을 거부했는지 여부는 아직 밝히지 않았습니다 .

Base 장애는 얼마나 오래 지속됐나요?

세 가지 구간이 각각 다른 대상을 측정합니다. 겉으로 드러난 블록 생성 중단은 UTC 16:03 첫 공개 조사부터 UTC 17:51 시퀀싱 재개까지 약 1시간 48분 동안 이어졌습니다 . L2BEAT의 독립 라이브니스 추적기는 더 좁은 1시간 18분 12초 구간을 기록했습니다. UTC 16:05부터 17:23까지였고, 평소 약 46초 간격으로 제출되던 트랜잭션 데이터 제출이 0건이었습니다 . 이후 더 넓은 사고 모니터링은 최소 UTC 19:22까지 계속됐으며, 이때 Base는 시퀀서와 지원 시스템이 안정적이라고 보고했습니다 .

Beryl 하드포크가 Base 장애의 원인이었나요?

확인되지 않았습니다. 시간적 연관성은 분명합니다. 정지는 6월 25일 Beryl의 예정된 UTC 18:00 활성화 전 업그레이드 준비 구간 안에서 발생했고, 필수 base/node v1.1.1 릴리스에는 BLOCKHASH에 의존하는 트랜잭션을 위한 Flashblocks 수정이 포함돼 있었습니다 . 그러나 Base는 Beryl을 원인으로 지목하지 않았고, 릴리스 노트도 유효하지 않은 블록을 특정 변경 사항과 연결하지 않았으며, Beryl은 복구 후 예정대로 활성화됐습니다 . 확정적인 답은 사후 분석을 기다려야 합니다.

OP Stack 체인에서 unsafe head stall은 무엇인가요?

unsafe head stall은 체인의 unsafe head, 즉 시퀀서가 생성했지만 아직 Ethereum L1에 정산되지 않은 최신 블록이 더 이상 앞으로 진행되지 않는 상황입니다. OP Stack 체인의 블록은 세 가지 최종성 단계를 거칩니다. unsafe(시퀀서 생성, 아직 L1 미포함), safe(L1 배치에 포함), finalized(L1 최종성으로 뒷받침됨)입니다. 정지는 L1 정산 전 unsafe 끝부분에만 영향을 주므로 L1 상태가 손상되지는 않습니다. 복구하려면 시퀀서를 수정하고 노드 운영자가 노드를 재시작해 동기화를 재개해야 합니다 .