베이스 네트워크, 48시간 만에 두 번 멈췄다

블록 빌더의 '더러운 상태'가 부른 대참사

베이스 팀이 발표한 포스트모템에 따르면, 사고의 근본 원인은 시퀀서(sequencer)의 **블록 빌딩 로직(block-building logic)**에 존재한 결함이었다. 구체적으로는 트랜잭션 실행이 실패한 후, 시스템이 저널 상태(journal state)—계정 및 스토리지 슬롯 변경 사항의 내부 기록—를 제대로 정리하지 못해 '오래된(stale)' 혹은 '더러운(dirty)' 상태가 남아버린 것이다. 이후 정상적인 트랜잭션이 실행될 때 이 오래된 상태가 가스(gas) 계산에 비정상적인 영향을 미쳐, 결국 **무효한 상태 전이(invalid state transition)**를 포함한 블록이 생성됐다.

이 무효 블록은 합의 실패(consensus failure)를 촉발했다. 시퀀서가 블록 47,806,542 이후 무효 블록을 생성하면서, 네트워크는 더 이상 새로운 블록을 쌓지 못하게 됐다. 노드 운영자들은 문제가 해결될 때까지 정상적인 동기화를 진행할 수 없었다.

두 차례 중단 사고의 타임라인

6월 26일 발생한 두 번째 중단 사고는 첫 번째 사고와 동일한 근본 원인(블록 생산 실패)이 재발한 것으로 설명됐지만, 두 번째는 네트워크가 더 빠르게 복구됐다.

사고 기간 동안 새로운 블록은 생성되지 않았고, 온체인 트랜잭션 처리는 중단됐다. 다행히도 사용자 자금이 위험에 처한 사례는 보고되지 않았다.

배포된 수정 패치

베이스의 엔지니어링 팀은 실패한 트랜잭션 이후에도 저널 상태가 제대로 업데이트되도록 시퀀서에 패치를 적용했다. 해당 수정 사항은 공개된 GitHub 풀 리퀘스트(#3806)에서 확인할 수 있다.

패치 적용 후 정상 운영이 재개됐지만, 베이스는 **검증자 노드 운영자에게 노드를 재시작하거나 재동기화(resync)**할 것을 권고했다. 팀은 두 차례 사고 모두 동일한 버그에서 비롯됐으며, 두 번째 사고는 이와 관련된 또 다른 이슈(PR #3805)로 인해 재발했다고 밝혔다.

사고 여파로 베이스는 네트워크 안정화를 위해 예정됐던 Beryl 메인넷 업그레이드와 B20 토큰 표준 활성화를 하루 연기했다.

'단일 시퀀서' 아키텍처: 티타늄 발목

이틀 연속 블록체인 중단 사태는 베이스의 단일 시퀀서 설계에 대한 논란에 다시 불을 붙였다. 이는 많은 옵티미스틱 롤업(optimistic rollup)에서 흔히 볼 수 있는 구조이지만, 분명한 **단일 장애점(Single Point of Failure, SPOF)**을 내포하고 있다.

포스트모템과 업계의 보도를 통해 제기된 주요 우려 사항은 다음과 같다.

• 단일 장애점: 시퀀서 수준의 블록 빌딩 로직 버그 하나로 베이스 전체의 블록 생산이 중단될 수 있다는 점이 확인됐다.
• 수동 복구: 네트워크 복구 과정이 자동으로 이뤄지지 않고, 검증자 노드 운영자가 수동으로 노드를 재시작하거나 재동기화해야만 했다.
• 신뢰성 위험: 이틀 연속 발생한 장애는 빠르게 확장 중인 L2 생태계의 신뢰성, 특히 활동이 많거나 업그레이드가 예정된 기간 동안의 안정성에 대한 의문을 제기했다.
• 개선 계획: 베이스는 향후 재발 방지를 위해 퍼즈 테스트(fuzz tests), 부하 테스트(load tests), 모니터링(monitoring) 및 복구 도구를 강화할 것이라고 밝혔다.

이번 사건은 이더리움 최대 L2 네트워크 중 하나라도 단일 시퀀서의 상태 관리(state-management) 엣지 케이스(edge case) 하나로 오프라인이 될 수 있다는 점을 여실히 보여줬다. 그리고 자동 장애 조치(failover)와 복구 시스템은 여전히 롤업 생태계 전반에서 진행 중인 '숙제'임을 드러냈다.