BTC
ETH
HTX
SOL
BNB
시장 동향 보기
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

一条公链为什么会停?从 Cosmos 停摆 25 小时,真正理解区块链共识

imToken
特邀专栏作者
이 기사는 약 5647자로, 전체를 읽는 데 약 9분이 소요됩니다
去中心化从来不意味着网络永远在线,链的运行,取决于是否有足够多的参与者达成共识。
AI 요약
펼치기
  • 핵심 관점: Cosmos Hub는 Neutron 거버넌스 공격 사건으로 인해 3분의 1 이상의 검증인이 자발적으로 블록 생성을 중단하여 해커 자금의 이동을 차단했으며, 약 하루 후 검증인 조율 업그레이드를 통해 복구되었습니다. 이 사건은 퍼블릭 체인의 탈중앙화가 영구적인 가동 중단이 없음을 의미하지 않으며, 합의 메커니즘이 Safety와 Liveness 사이에서 트레이드오프에 직면한다는 것을 보여줍니다.
  • 핵심 요소:
    1. 공격자는 Neutron 체인 수준 거버넌스 권한을 악용하여 wasmd 특권 명령을 통해 Astroport 등 애플리케이션 컨트랙트 관리자를 변조했고, 약 170만 ATOM이 크로스체인으로 Cosmos Hub에 전송되었습니다.
    2. 3분의 1 이상의 voting power를 보유한 검증인이 운영을 중단하면서 Cosmos Hub는 Liveness를 상실했고, 블록 높이 33,086,740에서 정지되어 사용자의 ATOM 전송이 확인되지 않았습니다.
    3. 복구 방안: Gaia v28.3.0이 복구 높이에서 일회성 상태 수정을 실행하여 공격자 주소의 1,227,121 ATOM을 4-of-6 멀티시그 주소로 이전했습니다. 67% 이상의 검증 권한이 패치를 설치한 후 약 6분 만에 블록 생성이 재개되었습니다.
    4. BFT 합의 하에서 블록 커밋에는 3분의 2 이상의 voting power가 필요하며, 부족할 경우 네트워크는 일관성을 희생하고 블록 생성을 계속하기보다 Safety를 유지하기 위해 일시 중단하는 것을 선택합니다.
    5. 역사적 비교: Bitcoin 2013년 클라이언트 규칙 불일치, Ethereum 2016년 The DAO 하드포크, Solana 2021년 메모리 고갈로 인한 중단은 모두 합의 불일치 또는 Liveness 상실의 다양한 장애 경로를 반영합니다.
    6. 개인 키 자율권은 자산 통제를 보장하지만, 기반 합의 권한은 체인이 거래를 처리할 수 있는지 및 상태가 집단적으로 수정될 수 있는지를 결정하며, 이 둘은 같은 것이 아닙니다.

9월 22일 밤, 한 사용자가 ATOM 전송을 실행했습니다.

하룻밤이 지나도 거래는 여전히 '확인 대기' 상태에 머물러 있었습니다.

개인키를 잃어버린 것도 아니고, 지갑에 서명 이상이 발생한 것도 아니었습니다. 다음 날 다시 확인해 보니 여러 공개 RPC 모두 Cosmos Hub가 블록 높이 33,086,740에서 멈춰 있음을 보여주었습니다.

새로운 블록이 생성되지 않으니, 당연히 이 거래를 담아낼 곳도 어디에도 없었습니다.

약 하루가 지나서야 Cosmos Hub가 블록 생성을 재개했고, 그제서야 계속 대기 상태에 있던 이 ATOM 전송이 최종적으로 성공했습니다.

일반 사용자에게 이 사건은 블록체인 합의를 이해하는 가장 직관적인 수업이 될 수 있습니다.

우리는 흔히 '어떤 중앙 기관도 퍼블릭 체인을 끌 수 없다'고 말하지만, 현실은 분명 훨씬 복잡합니다. 충분히 탈중앙화된 블록체인에는 확실히 서버실에 있는 그 '전원 버튼'이 존재하지 않지만, 그럼에도 멈출 수는 있습니다.

이번 Cosmos Hub의 중단은 평소에는 저층에 숨어 있던 이 메커니즘을 일반 사용자 앞에 완전히 드러냈습니다.

1. Cosmos는 왜 갑자기 '블록 생성이 중단'되었나?

먼저 혼동하기 쉬운 문제 하나를 명확히 할 필요가 있습니다. 이번에 직접 공격받은 것은 Cosmos Hub가 아닙니다.

사건은 가장 먼저 Neutron에서 발생했습니다.

9월 22일, 'AIATO: AI Agent Takeover'라는 Neutron 거버넌스 제안이 통과되었고, 공격자는 체인 수준 거버넌스 권한의 허점을 파고들어 wasmd 프레임워크가 기본 제공하는 특권 명령어를 이용해 Astroport, Drop 등의 애플리케이션 컨트랙트 관리자를 공격자가 통제하는 주소로 변경했습니다.

이는 우리가 흔히 이해하는 그런 '코드 취약점'이나 '프로토콜 결함'이 아닙니다.

간단히 말해, 애플리케이션 자체에도 '문 잠금장치'가 있지만 Neutron의 체인 수준 거버넌스는 그보다 더 높은 권한의 '마스터 키'를 쥐고 있었고, 공격자가 거버넌스 결과를 통제하게 되면서 이 키를 얻은 것과 마찬가지가 되어 관리자를 재지정하고 컨트랙트를 마이그레이션하며 그 안의 자산을 추가로 이전할 수 있게 되었습니다.

그런데 실제로 Cosmos Hub를 휘말리게 만든 것은 그 뒤에 발생한 크로스체인 자금 이동이었습니다.

Cosmos Labs의 사후 분석에 따르면, Neutron이 운영을 중단하기 전에 공격자는 이미 일부 자산을 여러 네트워크로 옮겼으며, 그중 약 170만 개의 ATOM이 Cosmos Hub로 전송되어 크로스체인 유동성을 통해 환전되기 시작했습니다.

즉, Cosmos Hub 자체는 직접 공격을 받지 않았고, 일반 Hub 사용자의 자금도 Neutron 취약점 때문에 직접 도난당하지는 않았습니다.

하지만 공격으로 얻은 ATOM이 이미 Hub에 들어왔고, 남은 ATOM이 계속 유출되는 것을 막기 위해 일부 Cosmos Hub 검증인이 노드 운영을 중단하기 시작했습니다.

9월 22일 19:18경(SGT)에는 운영을 중단한 검증인이 전체 voting power의 3분의 1을 넘게 차지했고, 이로 인해 Cosmos Hub는 더 이상 새 블록을 형성할 수 없게 되어 결국 33,086,740에서 멈췄습니다.

이 단계는 매우 중요합니다.

이는 Cosmos Hub에 어떤 회사가 직접 누를 수 있는 'Pause' 버튼이 존재하지 않으며, 온체인 거버넌스 투표를 먼저 거친 것도 아니라는 점을 의미합니다. 실제로 네트워크를 멈추게 한 것은 충분히 많은 검증인이 더 이상 합의 형성에 참여하지 않았다는 사실이었습니다.

하지만 더 주목할 만한 것은 사실 그 이후의 복구 과정입니다.

체인이 멈춘 지 약 4시간 후, 검증인들은 완전한 복구 방안을 받았습니다. 체인 중단 높이를 대상으로 일회성 상태 수정을 실행해, 공격자 주소에 남아 있는 ATOM을 커뮤니티 검증인들이 공동 관리하는 멀티시그 주소로 이전하는 것이었습니다.

이후 Cosmos Labs는 검증인들이 이미 합의한 방안에 따라 Gaia v28.3.0 패치를 제작하고, 이를 테스트한 뒤 검증인들에게 배포했습니다.

이 버전의 Gaia는 지정된 복구 높이에서 일회성 상태 변경을 실행해, 공격자 주소에 있던 1,227,121 ATOM을 Nansen, Keplr, Enigma, Silknodes, Kiln, Polkachu 6개 주체로 구성된 4-of-6 멀티시그 주소로 이전합니다.

9월 23일 새벽까지 v28.3.0 설치를 확인한 검증인이 전체 voting power의 67%를 넘었고, 따라서 같은 날 12:00 UTC에 Cosmos Hub가 조정 재시작되었으며, 약 6분 후 이 일회성 상태 수정이 블록 높이 33,086,741에서 실행되어 네트워크가 정상적으로 블록 생성을 재개했습니다.

결국 Cosmos가 블록 생성을 중단한 뒤 복구되기까지의 전체 과정은, 검증인들이 먼저 네트워크의 Liveness를 상실하게 만들고, 그다음 3분의 2를 초과하는 voting power가 새로운 상태 전환 규칙을 받아들여 최종적으로 이 규칙이 복구 후의 canonical state가 되게 한 것입니다.

여기서 겉보기에는 단순한 질문 하나가 떠오릅니다. 탈중앙화 퍼블릭 체인이라면, 왜 3분의 1을 넘는 검증 권한만으로 멈출 수 있고, 네트워크 복구에는 다시 충분히 많은 검증인이 함께 같은 소프트웨어를 받아들이고 실행해야 하는가?

그 답은 사실 '합의'라는 두 글자 안에 숨어 있습니다.

2. 이른바 합의는 애초에 '절대 멈추지 않음'이 아니다

블록체인에서 가장 쉽게 오해되는 것 중 하나는 '탈중앙화'와 '절대 다운되지 않음'을 등호로 놓는 것입니다.

실제로 합의 메커니즘이 진정으로 해결하는 문제는 중앙 기록자가 없는 상황에서 많은 노드가 거래 순서와 원장 상태에 대해 어떻게 일치된 의견을 형성하는가입니다.

다만 이를 구현하는 방식은 체인마다 다릅니다.

예를 들어 Bitcoin의 가장 고전적인 방식은 PoW, 즉 작업증명입니다. 채굴자는 해시파워 경쟁을 통해 블록을 생성하고, 네트워크에 단기간 두 개의 유효한 분기가 나타나면 노드는 누적 작업량에 따라 그중 하나를 선택해 계속 구축합니다.

그래서 Bitcoin에는 명확한 '67% 투표 후 이 블록은 영원히 Finalized'라는 시점이 존재하지 않습니다. 그것은 확률적 최종성에 더 가깝습니다. 이후 블록이 많아질수록 앞선 거래를 재구성하려면 점점 더 높은 해시파워 비용을 치러야 합니다.

이 때문에 과거에는 Bitcoin 거래를 6개 블록 확인까지 기다리는 것이 좋다고 흔히 말했습니다. 아무리 해시파워가 높아도 노드가 실행 중인 합의 규칙을 단순히 우회할 수는 없기 때문입니다.

물론 이것이 Bitcoin의 상태가 어떤 경우에도 '절대 수정 불가능'하다는 뜻은 아닙니다. 이론적으로 전체 생태계가 새로운 클라이언트와 새로운 합의 규칙을 받아들인다면 Hard Fork를 통해 과거 규칙에서는 무효였던 상태 변경을 유효하게 만들 수도 있습니다.

하지만 문제는 바로 여기에 있습니다. 누가 충분히 많은 채굴자, Full Node, 거래소, 지갑, 사용자를 설득해 이런 새 규칙을 함께 받아들이게 할 수 있을까요?

거의 없습니다.

개발팀이 전체 Bitcoin 네트워크를 대신해 합의 규칙을 결정할 수 없고, 채굴자와 거래소도 어렵습니다. 넘어야 할 합의 문턱이 매우 높기 때문입니다. 과거 바이낸스에서 7000 BTC가 도난당했을 때 누군가 CZ에게 대형 채굴자들과 연락해 조치하라고 제안했지만 결국 흐지부지되었습니다.

이더리움은 또 다른 매우 고전적인 표본을 제공합니다.

PoS로 전환한 이후 현재 이더리움은 Casper FFG와 LMD-GHOST가 함께 구성하는 Gasper 합의를 사용합니다. 간단히 이해하면, 일부 메커니즘은 '현재 어느 체인을 따라가야 하는가'를 판단하고, 다른 일부는 블록이 진정한 의미의 Finality를 얻도록 합니다.

최소 3분의 2의 스테이킹된 ETH를 대표하는 검증인이 해당 checkpoint에 합의해야 블록이 최종 확정으로 나아갈 수 있습니다. 반대로 3분의 1을 초과하는 stake가 장시간 올바른 투표에 참여하지 않으면 네트워크는 일시적으로 Finality를 형성하지 못할 수 있습니다. 다만 Ethereum은 inactivity leak도 설계해, 장시간 finalizing이 불가능할 때 오프라인 검증인의 유효 가중치를 점진적으로 낮춤으로써 네트워크가 결국 Finality를 회복할 기회를 갖도록 합니다.

이런 결과를 실제로 바꾸려면 마찬가지로 프로토콜 규칙과 클라이언트를 바꿔야 합니다.

2016년 The DAO 사건에서 이더리움 커뮤니티는 결국 Hard Fork를 통해 블록 1,920,000에서 Ethereum Foundation이 당시 직접 irregular state change라고 부른 특수 상태 수정을 실행해 관련 ETH를 복구 컨트랙트로 이전했습니다.

다만 업그레이드를 거부하고 기존 상태를 계속 유지하려는 일부 채굴자와 커뮤니티는 결국 Ethereum Classic(ETC)을 형성했고, 이는 널리 알려진 ETH와 ETC의 분기로 이어져 모든 사람이 이 규칙을 받아들인 것은 아니라는 점을 보여주었습니다.

Cosmos Hub는 또 다릅니다. 이는 CometBFT를 사용하며, 더 전형적인 BFT 합의에 가깝습니다.

더 전형적인 BFT 합의로 이해할 수 있습니다. 즉, 블록이 실제로 커밋되려면 3분의 2를 초과하는 voting power의 Commit이 필요합니다.

장점은 Finality가 매우 명확하다는 점입니다. 일단 충분한 검증 권한의 투표로 블록이 커밋되면, PoW처럼 점점 더 많은 블록을 기다리며 확률로 안전성을 얻을 필요가 없습니다.

하지만 다른 측면도 매우 직접적입니다. 3분의 1 이상의 voting power가 Commit 형성에 필요한 투표를 더 이상 제공하지 않으면, 나머지 검증인이 아무리 노력해도 3분의 2를 넘길 수 없습니다.

이때 네트워크의 가장 안전한 선택은 바로 이번의 '블록 생성 중단'입니다. 따라서 분산 시스템 관점에서 보면 이번 Cosmos Hub의 짧은 중단은 사실 그렇게 신비로운 일이 아닙니다.

한마디로, 충분한 voting power를 가진 검증인 집단이 참여를 멈추면, 합의 프로토콜은 자신의 규칙에 따라 가용성을 잃더라도 충분한 합의가 결여된 상황에서 새 블록을 계속 확정하지 않습니다.

이는 사실 일반 사용자들이 자주 혼동하는 분산 시스템의 두 개념과 대응합니다.

  • Safety: 서로 다른 노드가 서로 충돌하는 두 개의 최종 상태를 동시에 확정해서는 안 된다;
  • Liveness: 네트워크가 계속 앞으로 나아가며 새로운 거래를 처리할 수 있는가;

BFT 시스템에서는 합의에 참여하는 노드가 부족할 때, 중단이 때로는 Safety를 유지하기 위해 치르는 대가일 수 있습니다. 더 직설적으로 말하면, 이 탈중앙화 원장은 차라리 먼저 멈춰 있을지언정 남은 사람들이 각자 자기 장부를 기록하게 놔둘 수는 없습니다.

이 관점에서 다시 돌아보면, 퍼블릭 체인 역사상 겉보기에 전혀 달라 보이는 많은 사고가 사실은 같은 문제를 둘러싸고 전개되었음을 알 수 있습니다.

분산 노드들이 더 이상 '올바른 상태'에 대해 일치된 의견을 형성할 수 없을 때, 네트워크는 어떻게 해야 하는가?

3. Bitcoin에서 Solana까지, 퍼블릭 체인의 진짜 위험 경계는 어디인가?

이 문제를 수면 위로 올린 것이 Cosmos가 처음은 아닙니다.

이미 2013년에 Bitcoin은 매우 고전적인 체인 분기 사고를 겪었습니다.

당시 Bitcoin 0.8은 하위 데이터베이스를 Berkeley DB에서 LevelDB로 전환했고, 이후 대량의 거래 입력을 포함한 블록이 등장했습니다. 신버전 노드는 정상적으로 처리할 수 있었지만 일부 구버전 노드는 Berkeley DB의 잠금 수 제한 때문에 이 블록을 무효로 판단했습니다.

그래서 매우 난처한 장면이 벌어졌습니다. 모두가 Bitcoin을 실행하고 있는데도 신구 클라이언트가 '이 블록이 도대체 유효한가'에 대해 서로 다른 답을 내기 시작한 것입니다.

이로 인해 네트워크는 두 개의 체인으로 갈라졌고, 신버전 0.8 쪽은 한때 약 60%의 해시파워를 보유해 정상적인 해시파워 경쟁만으로 빠르게 수렴할 수 없었습니다.

결국 대형 마이닝풀들이 조율을 거쳐 구버전으로 되돌아가, 구규칙 쪽에서 다시 더 많은 해시파워를 확보한 뒤에야 네트워크가 다시 수렴했습니다. Bitcoin은 이후 BIP 50으로 이 사고를 별도로 복기하기도 했습니다.

2016년에는 이더리움의 The DAO 사건이 문제를 한 단계 더

퍼블릭 체인
Cosmos
Odaily 공식 커뮤니티에 가입하세요