Base가 지난주 발생했던 2번의 메인넷 중단 사고Postmortem을 공개했습니다.
sose · 2026.07.01 · Forwarded
Base가 지난주 발생했던 2번의 메인넷 중단 사고Postmortem을 공개했습니다. 결론부터 말하면 해킹도 아니고 합의(Consensus)가 깨진 것도 아니었습니다. 문제는 시퀀서(Sequencer)의 버그였습니다. 하나의 잘못된 트랜잭션이 실패 처리되는 과정에서 내부 메모리(journal state)가 제대로 초기화되지 않았고, 그 다음 정상 트랜잭션
Base가 지난주 발생했던 2번의 메인넷 중단 사고Postmortem을 공개했습니다. 결론부터 말하면 해킹도 아니고 합의(Consensus)가 깨진 것도 아니었습니다. 문제는 시퀀서(Sequencer)의 버그였습니다. 하나의 잘못된 트랜잭션이 실패 처리되는 과정에서 내부 메모리(journal state)가 제대로 초기화되지 않았고, 그 다음 정상 트랜잭션이 오염된 상태에서 실행되면서 잘못된 블록이 생성됐습니다. 다른 노드들은 당연히 이 블록을 거부했고, 결국 체인이 멈췄습니다. 흥미로운 점은 이 버그가 단순히 "트랜잭션 하나가 실패했다"가 아니라, 실패 이후의 상태를 얼마나 깔끔하게 복구하느냐에서 발생했다는 것입니다. EVM은 트랜잭션이 실패하면 이전 상태로 완전히 롤백되어야 하는데, 내부적으로 접근했던 계정과 스토리지 정보가 일부 남아 있었습니다. 그 결과 다음 트랜잭션의 gas 계산이 달라졌고, validator들이 계산한 결과와 sequencer가 만든 블록이 서로 달라지게 됐습니다. 복구 과정도 쉽지 않았습니다. 버그 자체는 패치했지만, 시퀀서를 재시작하는 과정에서 또 다른 race condition이 발견돼 복구가 예상보다 오래 걸렸고, 결국 다음 날 비슷한 문제가 한 번 더 발생했습니다. 첫 번째 장애는 약 116분, 두 번째는 20분 동안 지속됐습니다. 이번 사고는 "롤업은 중앙화되어서 위험하다"는 이야기보다는 오히려 왜 상태 관리(State Management)가 블록체인에서 가장 어려운 문제 중 하나인지를 잘 보여주는 사례였습니다. 잘못된 블록을 만든 것은 sequencer였지만, validator들은 이를 받아들이지 않았고 체인은 안전하게 멈췄습니다. Base도 이번 사고를 계기로 fuzz testing, 적대적 트랜잭션 테스트, 복구 절차를 대폭 강화하겠다고 밝혔습니다. https://blog.base.dev/postmortem-june-25th-block-production-outage