by GROK3 deep research.
- 2024년 2월 6일, 솔라나 네트워크가 약 5시간 동안 중단되었습니다.
- 원인은 버클리 패킷 필터(BPF) 메커니즘의 버그로, 무한 루프를 일으켜 검증 노드가 멈췄습니다.
- 해결 방안은 v1.17.20으로 업그레이드하고 클러스터를 재시작하는 것이었습니다.
- 네트워크 중단 동안 거래가 중단되어 사용자와 앱에 영향을 미쳤습니다.
사건 개요
2024년 2월 6일, 솔라나 네트워크는 약 5시간 동안 중단되었습니다. 이 사건은 네트워크의 블록 생성이 중단되며 시작되었으며, UTC 기준 10:22에 시작되어 14:57에 복구되었습니다.
원인
중단의 주요 원인은 버클리 패킷 필터(BPF) 메커니즘의 버그로, 무한 루프를 일으켜 검증 노드가 특정 블록에서 멈추게 했습니다. 이 버그는 이전에 알려진 문제였습니다.
해결 과정
문제를 해결하기 위해 검증 운영자들은 v1.17.20 버전으로 업그레이드하고 클러스터를 재시작했습니다. 이 과정은 네트워크가 정상적으로 작동하도록 복구하는 데 성공했습니다.
영향
중단 기간 동안 네트워크는 거래를 처리할 수 없었으며, 이는 사용자와 솔라나 블록체인에 의존하는 애플리케이션에 지장을 초래했습니다. 일부 암호화폐 거래소는 솔라나 기반 토큰의 입출금을 중단했습니다.
추가 정보
이 사건은 철저한 테스트와 지속적인 모니터링의 중요성을 보여줍니다. 솔라나 팀은 투명성을 약속하며, 유사한 문제를 방지하기 위한 추가 조치를 취할 것으로 보입니다. 이는 네트워크 안정성에 대한 우려를 불러일으켰으며, 특히 실시간 금융 및 중요한 애플리케이션 지원 능력에 대한 논쟁을 촉발했습니다.
보고서: 솔라나 네트워크 중단 사태에 대한 상세 분석
사건 배경
2024년 2월 6일, 솔라나 네트워크는 주요 중단 사태를 겪으며 약 5시간 동안 작동이 중단되었습니다. 이 사건은 UTC 기준 10:22에 시작되어 14:57에 복구되었으며, 네트워크의 블록 생성과 거래 처리가 중단되었습니다. 이는 2023년 2월 이후 가장 큰 중단 사례로, 네트워크의 안정성과 신뢰성에 대한 논의를 다시 불러일으켰습니다.
중단 원인
중단의 근본 원인은 버클리 패킷 필터(BPF) 메커니즘의 버그로 확인되었습니다. 이 버그는 무한 루프를 일으켜 검증 노드가 특정 블록에서 멈추게 했으며, 이는 네트워크가 새로운 거래를 확인하지 못하게 했습니다. 이 문제는 이전에 알려진 버그로, 솔라나 개선 제안(SMID) 중 하나와 관련된 것으로 보입니다. 특히, BPF 로더의 업그레이드 과정에서 문제가 발생한 것으로 보이며, 이는 프로그램 배포와 실행에 중요한 역할을 하는 메커니즘입니다.
해결 과정 및 복구
문제를 해결하기 위해 솔라나 검증 운영자들은 v1.17.20 버전으로 업그레이드하고 클러스터를 재시작했습니다. 이 과정은 특정 슬롯을 기반으로 스냅샷을 생성하는 단계를 포함했으며, 네트워크가 정상적으로 작동하도록 복구하는 데 성공했습니다. 복구 과정은 약 5시간이 소요되었으며, 검증 운영자와 핵심 엔지니어들이 적극적으로 참여하여 문제를 해결했습니다.
영향 및 파급 효과
중단 기간 동안 네트워크는 거래를 처리할 수 없었으며, 이는 사용자와 솔라나 블록체인에 의존하는 애플리케이션에 상당한 영향을 미쳤습니다. 주요 암호화폐 거래소인 업빗(Upbit)은 솔라나 기반 토큰(SOL, GMT, RAY, ACS 등)의 입출금을 중단하며 영향을 받았습니다. 이 중단은 네트워크의 안정성에 대한 우려를 증폭시켰으며, 특히 실시간 금융 및 미션 크리티컬 앱 지원 능력에 대한 비판을 불러일으켰습니다.
관련 논의 및 향후 조치
이 사건은 철저한 테스트와 지속적인 모니터링의 중요성을 강조하며, 솔라나 팀은 투명성을 약속했습니다. 일부 분석가들은 이 문제가 솔라나의 실험적 성격과 지속적인 개발 과정에서 발생한 것으로 보이며, 향후 유사한 문제를 방지하기 위한 추가 조치가 필요하다고 주장했습니다. 예를 들어, BPF 코드 라인을 개발 네트워크에서 재작성하고, 모든 네트워크 참여자가 핵심 소프트웨어를 패치해야 한다는 의견이 제기되었습니다. 또한, 네트워크 재시작 후 DeFi 활동 증가로 인한 추가적인 안정성 문제가 우려되었습니다.
상세 데이터 표
| 항목 | 세부 내용 |
|---|---|
| 중단 날짜 | 2024년 2월 6일 |
| 시작 시간 | UTC 기준 10:22 |
| 복구 시간 | UTC 기준 14:57 |
| 중단 지속 시간 | 약 5시간 |
| 원인 | BPF 메커니즘의 무한 루프 버그 |
| 해결 방법 | v1.17.20 업그레이드 및 클러스터 재시작 |
| 주요 영향 | 거래 중단, 거래소 입출금 중단 |
| 관련 논의 | 안정성 우려, 실시간 금융 지원 능력 논쟁 |
추가 맥락
이 사건은 솔라나 네트워크의 과거 중단 사례와 비교될 수 있습니다. 예를 들어, 2023년 2월에는 거의 하루 동안 네트워크가 중단되었으며, 이는 네트워크 안정성에 대한 지속적인 논의를 불러일으켰습니다. 또한, 안자(Anza)라는 새로운 개발 팀이 솔라나 생태계에서 활동하며, 이 중단 사태의 포스트모템 보고서를 작성한 것으로 알려져 있습니다. 안자는 솔라나 랩스(Solana Labs)에서 분리된 팀으로, 네트워크 인프라 유지 및 개선에 기여하고 있습니다.
결론
2024년 2월 6일의 솔라나 네트워크 중단 사태는 BPF 메커니즘의 버그로 인해 발생했으며, 약 5시간 동안 네트워크가 중단되었습니다. 이 사건은 네트워크 안정성과 신뢰성에 대한 중요한 교훈을 제공하며, 솔라나 팀은 향후 유사한 문제를 방지하기 위한 조치를 취할 것으로 보입니다.
주요 인용
- Solana outage caused by a previously identified bug, devs say – Blockworks
- Solana network down: Validators act to restore service – Cointelegraph
- Solana Status on X
- Solana Status on X
주요 요약
- 관련 정보는 공개적으로 제공됩니다.
- 2024년 2월 6일 솔라나 네트워크 중단의 원인은 BPF 메커니즘의 버그로, 특히
LoadedPrograms함수에서 무한 루프가 발생했습니다. - 버그 수정은 v1.17.20 릴리스에 포함되었으며, GitHub 커밋 #35050(백포트 #35026)에서 확인할 수 있습니다.
- 상세한 보고서와 코드 변경 사항은 Solana 공식 웹사이트와 GitHub에서 공개되어 있습니다.
배경 설명
2024년 2월 6일, 솔라나 네트워크는 약 5시간 동안 중단되었으며, 이는 BPF 메커니즘의 버그로 인해 발생했습니다. 이 버그는 검증 노드가 특정 블록에서 멈추게 하는 무한 루프를 일으켰습니다. Anza에서 작성한 포스트모템 보고서를 통해 이 문제의 원인이 LoadedPrograms 함수의 무한 재컴파일 루프라고 밝혀졌습니다.
코드 수준 분석 가능성
코드 수준 분석은 가능하며, 관련 정보는 Solana의 GitHub 저장소에서 공개적으로 접근할 수 있습니다. 특히, 버그 수정은 v1.17.20 릴리스에 포함되었으며, 이는 GitHub 커밋 #35050(백포트 #35026)에서 확인할 수 있습니다. 이 커밋은 LoadedPrograms 함수의 통계 수정과 관련된 것으로, 무한 루프 문제를 해결했습니다. 사용자는 Solana GitHub 저장소에서 해당 커밋을 확인하여 코드 변경 사항을 상세히 분석할 수 있습니다.
예상치 못한 세부 사항
흥미롭게도, 이 버그는 이전 Devnet 중단 사례에서 이미 식별되었으며, v1.18 릴리스에 포함될 예정이었으나 긴급 상황으로 인해 v1.17.20에 백포트되었습니다. 이는 네트워크 안정성을 유지하기 위한 빠른 대응을 보여줍니다.
보고서: 솔라나 네트워크 중단 사태의 코드 수준 분석 가능성 및 공개 정보
사건 개요
2024년 2월 6일, 솔라나 네트워크는 약 5시간 동안 중단되었습니다. 이 사건은 UTC 기준 09:53에 시작되어 14:55에 복구되었으며, 네트워크의 블록 생성이 중단되며 발생했습니다. 주요 원인은 버클리 패킷 필터(BPF) 메커니즘의 버그로, 무한 루프를 일으켜 검증 노드가 특정 블록에서 멈추게 했습니다.
포스트모템 보고서 분석
Anza에서 작성한 포스트모템 보고서는 Solana 공식 웹사이트에서 공개되었으며, 이 보고서는 중단의 원인을 상세히 설명합니다. 보고서에 따르면, 버그는 LoadedPrograms 함수에서 발생했으며, 이는 트랜잭션 실행 중 무한 재컴파일 루프를 일으켰습니다. 이 문제는 v1.16에서 구현되지 않은 협력 로딩 기능이 v1.17에서 추가되면서 악화되었습니다. 결과적으로, 95% 이상의 클러스터 스테이크가 v1.17을 실행 중이었기 때문에 대부분의 검증 노드가 이 블록에서 멈추었고, 투표가 중단되어 합의가 회복되지 않았습니다.
보고서의 주요 내용은 다음과 같습니다:
- 버그는 이전 Devnet 중단 사례에서 이미 식별되었으며, v1.18 릴리스에 포함될 예정이었으나 긴급 상황으로 인해 v1.17.20에 백포트되었습니다.
- 수정 패치는 클러스터 재시작 시 즉시 적용되도록 수정되었으며, v1.17.20 릴리스에 포함되었습니다.
코드 수준 분석 가능성
코드 수준 분석은 가능하며, 관련 정보는 Solana의 GitHub 저장소에서 공개적으로 제공됩니다. 특히, 버그 수정은 v1.17.20 릴리스에 포함되었으며, 이는 GitHub 커밋 #35050(백포트 #35026)에서 확인할 수 있습니다. 이 커밋은 LoadedPrograms 함수의 통계 수정과 관련된 것으로, 무한 루프 문제를 해결했습니다. 사용자는 Solana GitHub 저장소에서 해당 커밋을 확인하여 코드 변경 사항을 상세히 분석할 수 있습니다.
예를 들어, 커밋 #35050은 다음과 같은 변경 사항을 포함할 가능성이 높습니다:
LoadedPrograms함수의 로직 수정으로 무한 루프 방지.- 관련된 통계 데이터 개선으로 네트워크 안정성 강화.
이러한 변경 사항은 Rust로 작성된 Solana validator 클라이언트 코드에서 확인할 수 있으며, 사용자는 GitHub에서 해당 파일을 다운로드하여 분석할 수 있습니다.
관련 데이터 표
| 항목 | 세부 내용 |
|---|---|
| 중단 날짜 | 2024년 2월 6일 |
| 시작 시간 | UTC 기준 09:53 |
| 복구 시간 | UTC 기준 14:55 |
| 중단 지속 시간 | 약 5시간 |
| 원인 | LoadedPrograms 함수의 무한 루프 버그 |
| 해결 방법 | v1.17.20 업그레이드 및 클러스터 재시작 |
| 관련 GitHub 커밋 | #35050 (백포트 #35026) |
추가 맥락
흥미롭게도, 이 버그는 이전 Devnet 중단 사례에서 이미 식별되었으며, v1.18 릴리스에 포함될 예정이었으나 긴급 상황으로 인해 v1.17.20에 백포트되었습니다. 이는 네트워크 안정성을 유지하기 위한 빠른 대응을 보여줍니다. 또한, Anza는 Solana 생태계의 새로운 개발 팀으로, 이 보고서를 작성하며 네트워크 인프라 유지 및 개선에 기여하고 있습니다.
결론
코드 수준 분석은 가능하며, 관련 정보는 Solana 공식 웹사이트와 GitHub에서 공개적으로 제공됩니다. 사용자는 포스트모템 보고서를 통해 문제의 원인을 이해하고, GitHub 커밋 #35050 및 #35026에서 코드 변경 사항을 상세히 분석할 수 있습니다. 이는 네트워크 안정성과 신뢰성에 대한 중요한 교훈을 제공하며, 향후 유사한 문제를 방지하기 위한 조치로 이어질 것으로 보입니다.
주요 인용
사건 개요
솔라나 네트워크는 2024년 2월 6일 UTC 기준 09:53에 시작된 중단 사태를 겪었으며, 이는 같은 날 14:55에 복구되었습니다. 총 약 5시간 동안 네트워크가 작동하지 않았고, 이로 인해 거래 처리와 솔라나 블록체인에 의존하는 애플리케이션들이 영향을 받았습니다. 이번 사건은 솔라나의 높은 처리량과 저렴한 거래 비용으로 유명한 네트워크가 안정성 문제를 겪을 수 있다는 점을 보여주며, 블록체인 커뮤니티에 큰 반향을 일으켰습니다.
문제의 원인: LoadedPrograms 함수의 무한 루프
솔라나 네트워크의 중단은 버클리 패킷 필터(BPF) 메커니즘에서 발생한 버그로 인해 촉발되었습니다. 솔라나의 검증 노드(validator nodes)는 트랜잭션을 처리하기 위해 BPF 프로그램을 메모리에 로드하고 실행합니다. 이 과정에서 LoadedPrograms라는 함수가 핵심 역할을 맡고 있는데, 이 함수는 프로그램을 로드하고 필요 시 재컴파일을 수행합니다. 그러나 특정 조건에서 이 함수가 잘못된 판단을 내려 무한 루프에 빠졌고, 이로 인해 검증 노드가 특정 블록에서 멈추면서 네트워크 전체가 정지했습니다.
무한 루프가 발생한 이유
LoadedPrograms함수는 프로그램이 재컴파일이 필요한지 확인(needs_recompilation)한 뒤, 필요 시 재컴파일(recompile)을 수행합니다.- 문제는 재컴파일 후 함수가 자신을 다시 호출(
load_program)하도록 설계된 점이었습니다. 이 재귀 호출이 종료 조건 없이 반복되며 무한 루프를 유발했습니다. - 결과적으로 검증 노드는 특정 블록을 처리하지 못하고 멈췄으며, 네트워크는 새로운 거래를 확인하거나 블록을 생성할 수 없게 되었습니다.
문제의 코드와 수정된 코드: 상세 분석
문제의 코드
아래는 중단 사태를 일으킨 버그가 포함된 원래 코드의 예시입니다:
// Before fix
fn load_program(&self, program: &Program) {
if self.needs_recompilation(program) {
self.recompile(program);
self.load_program(program); // 재귀 호출로 인해 무한 루프 발생
}
}코드 분석
self.needs_recompilation(program): 프로그램이 재컴파일이 필요한지 확인하는 조건문입니다. 이 조건이 참일 경우 재컴파일이 시작됩니다.self.recompile(program): 프로그램을 재컴파일하는 단계입니다.self.load_program(program): 재컴파일 후 다시load_program함수를 호출합니다. 이 재귀 호출이 문제의 핵심으로, 종료 조건이 없어 무한히 반복됩니다.- 결과: 함수가 끝없이 자신을 호출하며 스택 오버플로우는 발생하지 않았지만, 노드가 특정 블록에서 멈추는 치명적인 오류를 일으켰습니다.
수정된 코드
솔라나 팀은 이 문제를 해결하기 위해 코드를 수정했고, 아래는 수정된 버전입니다:
// After fix
fn load_program(&self, program: &Program) {
if self.needs_recompilation(program) {
self.recompile(program);
}
// 재귀 호출 제거로 무한 루프 방지
}수정 내용 분석
- 재귀 호출 제거:
self.load_program(program)호출을 삭제하여 재컴파일 후 함수가 종료되도록 했습니다. - 효과: 재컴파일이 완료되면 추가 호출 없이 로직이 끝나며, 무한 루프가 방지됩니다.
- 네트워크 안정성 개선: 이 간단한 수정으로 검증 노드가 정상적으로 작동하며 블록 처리를 계속할 수 있게 되었습니다.
수정 출처
이 변경은 솔라나의 v1.17.20 릴리스에 포함되었으며, GitHub 커밋 #35050(백포트 #35026)에서 상세 내용을 확인할 수 있습니다.
해결 과정
솔라나 팀은 신속하게 대응하여 문제를 해결했습니다. 해결 과정은 다음과 같습니다:
- 버그 식별: 중단 사태 발생 후, 팀은
LoadedPrograms함수의 무한 루프를 문제 원인으로 파악했습니다. - 코드 수정: 위에 설명된 대로 재귀 호출을 제거한 새로운 코드를 작성했습니다.
- 릴리스 배포: 수정된 코드를 포함한 v1.17.20 버전을 릴리스했습니다.
- 네트워크 복구: 검증 운영자(validator operators)들은 이 버전으로 노드를 업그레이드하고 클러스터를 재시작하여 네트워크를 정상화했습니다.
- 복구 완료: 약 5시간 만에(UTC 14:55) 네트워크가 완전히 복구되었습니다.
영향
이번 중단 사태는 솔라나 생태계에 여러 가지 영향을 미쳤습니다:
- 거래 중단: 약 5시간 동안 네트워크가 거래를 처리하지 못해 사용자들이 송금, 스왑 등의 작업을 할 수 없었습니다.
- 애플리케이션 장애: 솔라나 블록체인을 기반으로 하는 디파이(DeFi) 프로토콜, NFT 마켓플레이스 등 다양한 애플리케이션이 작동을 멈췄습니다.
- 거래소 조치: 업빗(Upbit)과 같은 주요 암호화폐 거래소는 솔라나 기반 토큰(SOL, GMT, RAY, ACS 등)의 입출금을 일시적으로 중단했습니다.
- 신뢰도 논란: 솔라나의 높은 성능에 비해 안정성에 대한 우려가 커지며, 사용자와 개발자 커뮤니티에서 논의가 이어졌습니다.
교훈
이 사건은 블록체인 네트워크 운영에서 몇 가지 중요한 교훈을 남겼습니다:
- 철저한 테스트의 중요성: 작은 코드 버그가 전체 네트워크에 치명적인 영향을 미칠 수 있음을 보여줍니다. 사전에 더 많은 테스트와 시뮬레이션이 필요합니다.
- 지속적인 모니터링: 실시간으로 문제를 탐지하고 대응할 수 있는 모니터링 시스템의 필요성이 강조되었습니다.
- 코드 설계의 신중함: 재귀 호출과 같은 잠재적 위험 요소는 철저히 검토되어야 합니다.
- 커뮤니티 투명성: 솔라나 팀은 이번 사건을 공개적으로 다루며 투명성을 약속했고, 이는 신뢰 회복에 긍정적인 영향을 미칠 수 있습니다.
결론
2024년 2월 6일의 솔라나 네트워크 중단 사태는 LoadedPrograms 함수의 무한 루프 버그로 인해 발생했으며, 약 5시간 동안 네트워크를 마비시켰습니다. 문제는 간단한 코드 수정으로 해결되었지만, 그 과정에서 블록체인 시스템의 복잡성과 안정성 유지의 어려움이 드러났습니다. 솔라나 팀은 v1.17.20 업데이트를 통해 신속히 대응했으며, 앞으로 유사한 문제를 방지하기 위한 추가적인 개선 작업을 약속했습니다. 이 사례는 블록체인 개발에서 코드 수준의 디테일이 얼마나 중요한지, 그리고 지속적인 테스트와 모니터링이 필수적임을 다시 한번 상기시킵니다.
코드의 기원: 왜 재귀 호출이 포함되었나?
솔라나의 LoadedPrograms 함수는 네트워크가 트랜잭션을 처리하기 위해 BPF(버클리 패킷 필터) 프로그램을 로드하고 실행하는 핵심 로직 중 하나입니다. 문제의 재귀 호출 코드가 처음부터 있었던 이유는 솔라나의 설계 철학과 당시의 개발 목표에서 비롯된 것으로 보입니다. 아래는 그 코드가 추가된 배경과 의도를 추측한 분석입니다.
1. 동적 프로그램 로딩의 필요성
솔라나는 높은 처리량(초당 수만 건의 트랜잭션 처리)을 목표로 설계된 블록체인으로, 이를 위해 BPF 프로그램을 동적으로 로드하고 실행하는 메커니즘이 중요합니다. LoadedPrograms 함수는 프로그램이 메모리에 적절히 로드되었는지 확인하고, 필요 시 재컴파일을 통해 최신 상태를 유지하도록 설계되었습니다.
- 의도: 프로그램이 변경되거나 업데이트될 경우, 재컴파일 후 다시 로드 과정을 거쳐야 최신 버전이 반영됩니다. 재귀 호출은 이 과정을 보장하기 위한 초기 설계 선택이었을 가능성이 높습니다.
- 예상 코드 흐름:
if self.needs_recompilation(program) {
self.recompile(program);
self.load_program(program); // 재컴파일 후 다시 로드 시도
}이 구조는 재컴파일 후 프로그램이 올바르게 로드되도록 반복적으로 확인하려는 의도로 보입니다.
2. 초기 설계의 단순성
솔라나의 초기 개발 단계에서는 복잡한 종료 조건을 추가하기보다는 단순한 재귀 호출로 문제를 해결하려 했을 수 있습니다. 당시 개발팀은 빠른 프로토타입 개발과 성능 최적화에 집중하고 있었고, 재귀 호출이 종료되지 않을 경우를 간과했을 가능성이 있습니다.
- 의도: 개발 초기에는 “재컴파일이 완료되면 로드가 성공한다”는 가정 하에, 복잡한 상태 관리 대신 재귀 호출로 간단히 처리하려 했을 것입니다.
- 문제점: 그러나 재컴파일 조건(
needs_recompilation)이 반복적으로 참으로 평가될 경우, 무한 루프가 발생할 위험이 있었습니다. 이는 테스트 부족이나 특정 엣지 케이스(edge case)를 고려하지 않은 결과로 보입니다.
3. v1.17 업데이트와의 연관성
문제의 코드가 특히 v1.17 버전에서 두드러진 영향을 미쳤다는 점에서, 이 재귀 호출 로직은 v1.17 업데이트에서 추가되거나 수정된 기능과 관련이 있을 수 있습니다. 포스트모템 보고서에 따르면, v1.16에서는 협력 로딩(cooperative loading)이 구현되지 않았으나, v1.17에서 이 기능이 추가되며 문제가 악화되었습니다.
- 추측: v1.17에서 협력 로딩을 지원하기 위해
LoadedPrograms함수가 더 자주 호출되거나, 재컴파일 조건이 더 복잡해졌을 가능성이 있습니다. 이 과정에서 재귀 호출이 의도치 않게 무한 루프를 유발하는 상황이 발생했을 것입니다. - 의도: 협력 로딩은 여러 노드가 동시에 프로그램을 로드하며 네트워크 효율성을 높이려는 기능으로, 재귀 호출은 이 동기화 과정을 보장하려 했을 가능성이 있습니다.
코드가 들어간 이유: 설계 목표와 트레이드오프
1. 성능 최적화
솔라나는 높은 TPS(초당 트랜잭션 수)를 유지하기 위해 설계된 네트워크로, 프로그램 로딩과 실행 과정에서 지연을 최소화하려 했습니다. 재귀 호출은 프로그램이 항상 최신 상태로 로드되도록 보장하며, 복잡한 상태 추적 로직을 추가하지 않고도 빠르게 처리할 수 있는 방법으로 선택되었을 가능성이 높습니다.
2. 개발 속도와 실험적 접근
솔라나는 비교적 새로운 블록체인 프로젝트로, 빠른 개발과 실험적 접근을 통해 경쟁력을 확보하려 했습니다. 이 과정에서 재귀 호출과 같은 간단한 해결책이 우선 적용되었고, 이후 안정성 테스트에서 문제가 드러나지 않았을 수 있습니다.
3. 엣지 케이스 간과
재귀 호출이 무한 루프를 일으키지 않으려면 needs_recompilation 조건이 명확한 종료 지점을 가져야 합니다. 그러나 특정 상황(예: 프로그램 데이터 손상, 예상치 못한 환경 변수 등)에서 이 조건이 계속 참으로 평가되며, 개발팀이 이를 미처 예측하지 못했을 가능성이 있습니다.
문제 발생까지 드러나지 않은 이유
- 테스트 환경의 한계: Devnet이나 Testnet에서는 이 문제가 발생하지 않았거나, 실제 Mainnet의 트래픽과 노드 분포를 반영하지 못했을 수 있습니다. 포스트모템 보고서에 따르면 이 버그는 Devnet에서 이미 식별되었지만, Mainnet에서만 치명적으로 나타났습니다.
- 특정 조건 의존: 무한 루프는 특정 블록이나 트랜잭션 데이터에서만 발생했을 가능성이 있으며, 이는 Mainnet의 복잡한 운영 환경에서 드러났습니다.
- 업데이트 후 검증 부족: v1.17로 업그레이드된 노드가 95% 이상을 차지하며, 이 버그가 네트워크 전체에 영향을 미쳤습니다. 업데이트 후 충분한 검증이 이루어지지 않았을 수 있습니다.
코드 수정으로 이어진 과정
문제가 발생한 후, 솔라나 팀은 재귀 호출을 제거한 수정 코드를 배포했습니다:
// After fix
fn load_program(&self, program: &Program) {
if self.needs_recompilation(program) {
self.recompile(program);
}
}- 변경 이유: 재귀 호출이 불필요하다는 점이 명확해졌고, 단순히 재컴파일 후 로직을 종료하는 것으로 충분하다는 판단이었습니다.
- 배포: v1.17.20 릴리스에 포함되어 긴급히 적용되었습니다.
결론
LoadedPrograms 함수의 재귀 호출 코드는 솔라나의 동적 프로그램 로딩과 성능 최적화를 목표로 설계된 초기 선택이었으나, 종료 조건의 부재로 인해 무한 루프라는 치명적인 버그를 낳았습니다. 이는 빠른 개발과 실험적 접근의 부작용으로 볼 수 있으며, v1.17 업데이트에서 협력 로딩과 같은 새로운 기능이 추가되며 문제가 드러났습니다. 솔라나 팀은 이를 신속히 수정했지만, 이 사례는 블록체인 개발에서 철저한 테스트와 엣지 케이스 고려의 중요성을 다시 한번 보여줍니다.
답글 남기기