솔라나가 8월 12일 초기 보도가 시사했던 것보다 더 심각한 네트워크 장애 위기에 근접했다. 인프라 업체 테라스위치(Teraswitch)의 라우팅 오류로 스테이킹된 SOL 중 28.83%가 약 33분 동안 오프라인 상태가 됐고, 이는 솔라나가 트랜잭션 확정을 완전히 멈추는 임계치인 33.34%까지 단 4.51%포인트, SOL 약 1990만 개 차이로 좁혀진 수치다. 장애 기간 내내 솔라나 네트워크는 블록 생성을 이어갔고, 위임 프로그램(Delegation Program) 소속 검증인들은 영향을 받지 않았다. 다만 실제 정지까지의 여유폭은 처음 퍼졌던 '검증인 699곳 중 102곳'이라는 표현이 주던 인상보다 훨씬 얇았다.

마리네이드 파이낸스(Marinade Finance)의 분석은 이 수치 뒤에 깔린 더 깊은 구조적 문제를 짚었다. 단일 자율시스템(AS) 하나가 스테이킹된 SOL 전체의 4분의 1이 넘는 약 1억1890만 개를 호스팅하고 있었고, 이 집중된 물량의 약 94%가 테라스위치의 라우팅 장애와 함께 한꺼번에 오프라인이 됐다. 네트워크를 정지 직전까지 몰아붙인 진짜 원인은 단순한 검증인 개수보다 이 집중도였다.

Solana Came Within 4.5 Points of Losing Finality in a Routing Outage
Image via @WuBlockchain on X

같이 보면 좋은 기사: 헤데라, 타우러스 풀스택 통합 완료... 은행 40곳 이상 접근권 확보

실제로 무엇이 고장났나

테라스위치 자체 장애 상태 페이지에 따르면 문제의 근원은 마이애미(MIA1) 시설에서 발표된 잘못된 형식의 기본 라우트였다. 이 라우트는 암스테르담의 라우트 리플렉터를 거쳐 테라스위치 백본 전역으로 퍼졌고, 유럽과 아시아태평양 지역 12개 사이트에서 동시 접속 장애를 일으켰다. 엔지니어들은 10분 만에 이 잘못된 라우트를 찾아내 백본에서 마이애미 사이트를 제거해 확산을 막았다. 영향을 받은 사이트들은 이후 정상 로컬 라우트로 재수렴했고, 서비스는 UTC 기준 04시16분15초에 완전히 복구됐다.

33분의 대가

영향을 받은 검증인 약 90곳은 장애 기간 동안 보상 333 SOL을 합쳐서 잃었다. 네트워크가 더 심각한 장애에 얼마나 가까이 다가섰는지를 생각하면 직접적인 비용 자체는 비교적 크지 않은 편이다. 테라스위치는 이후 비슷한 형태의 잘못된 라우트가 다시 트래픽 전달을 막는 일을 방지하기 위한 글로벌 설정 변경을 전체 컴퓨트 사이트에 적용했다고 밝혔다. 다만 회사는 완전한 근본 원인 분석 보고서는 아직 나오지 않았다고 덧붙였다.