메인넷을 멈출 수 있는 네 개의 원인
왜 텐더민트 기반 체인이 멈추는 것은 정상인가?
현재 시장에 있는 블록체인 대부분은 ‘생존성’(liveness)을 우선하는 모델을 사용합니다. 하지만 다수의 연구자료에 따르면, 지분증명(PoS, Proof-of-Stake) 시스템에서 가장 긴 체인(longest chain)의 합의를 따르는 모델은 안전하지 않다고 경고하고 있습니다.
텐더민트 기반 체인(예, BFT 기반 체인)은 생존성보다 안전성(safety)에 중점을 둡니다. BFT 기반 체인은 네트워크 상태가 과도하게 비동기화(asynchronous) 되거나, 네트워크 분열이 발생하거나, 다수의 검증인이 오프라인된 경우 체인 가동이 멈추게 됩니다. 또한, 코스모스 허브는 블록체인 스테이트 머신에서 에러를 감지할 경우 체인 가동을 멈추도록 설계되었습니다. 이런 디자인적 선택은 지분증명 시스템의 안전성이 보존될 수 있게 합니다. 아마 코스모스 테스트넷 과정을 꾸준히 지켜보신 분들은 에러가 발생하여 체인이 멈추는 사건들을 많이 목격하셨으리라 생각합니다.
하지만 네트워크가 멈춘다고 해서 체인에 큰 위기가 찾아왔다는 것은 아닙니다. 메인넷을 멈추게 할 수 있는 네 가지의 문제들을 살펴보고 각 문제를 어떻게 대처하는지 알아보겠습니다.
블록체인 결함의 형태
- Liveness fault — 생존성 결함 (네트워크 중단)
- Safety fault — 안전성 결함 (블록체인 포크)
- Censorship fault — 검열성 결함 (데이터 전파 유보)
- Hard fork failure — 하드포크 실패 (무효한 스테이트 변경)
생존성 결함 (네트워크 중단)
스테이킹된 물량의 ⅓ 이상이 동시에 오프라인일 경우
요약: 보팅 파워의 ⅓ 이상이 동시에 오프라인인 상황인 경우, 텐더민트 기반 체인은 새로운 블록을 생성하지 않습니다. 다시 블록체인 작동을 재개하기 위해서 네트워크는 오프라인 상태인 ⅓ 보팅 파워를 가진 검증인들이 다시 연결되는 것을 기다립니다. 만약 충분한 기간이 지났음에도 검증인들이 연결되지 않는 경우, 커뮤니티는 수동적으로 해당 검증인들을 포크할 수 있습니다.
과거 테스트넷에서 보팅 파워 +⅓가 오프라인 되었던 경우들:
- 텐더민트 코어 (TMC, Tendermint Core) 이슈 #3089: 보팅 파워 ⅓이 오프라인 되며 발생한 문제
- 게임 오브 스테이크에서 발생했던 생존성 결함
불변성 검증(invariant checker) 실패
요약: 코스모스 허브의 gaiad 데몬(daemon)은 런타임에서 네 가지 불변성 요소(invariance)를 확인합니다:
NonnegativeBalanceInvariant(추가 설명: 모든 계정이 플러스 값의 잔고를 가지고 있는지)NonnegativeOutstandingInvariant(추가 설명: 스테이킹 보상이 마이너스 값이 아닌지)SupplyInvariants(추가 설명: 총 토큰 수량(total supply)이 스테이킹 되지 않은 토큰, 스테이킹된 토큰, 그리고 언본딩 되고 있는 토큰의 합과 일치하는지)NonnegativePowerInvariant(추가 설명: 모든 검증인의 보팅 파워가 플러스 값인지)
만약 위 4개 검증 절차 중 단 하나의 값에서라도 오류가 생긴다면 gaiad를 운영하는 모든 노드는 자동으로 멈추게 됩니다. 불변성 검증으로 체인이 멈춘 경우, 버그의 원인을 찾고 수정한 후, 멈춘 체인의 상태(state)를 제거(dump)한 후 새로운 체인이 시작됩니다.
과거 테스트넷에서 불변성 검증이 체인을 멈춘 경우:
- 코스모스 SDK 이슈 #1197: 틀린 키 값이 연산된 후 삭제되어야 하는 기록이 남으면서 오류가 발생
- 코스모스 SDK 이슈 #3019: Gaia-9002 테스트넷 오류 로그
- Gaia-7003 테스트넷 ‘사망 진단서’
버그로 발생한 생존성 결함
요약: 텐더민트 코어에 있는 버그가 특정 메시지를 보내거나 받지 못하는 상황을 발생한 경우가 있습니다. 이 상태에서 체인은 (네트워크의 +2/3 보팅파워가 온라인인 경우에도) 비정상적인 합의 절차에 머무르며 블록 생성을 하지 못하게 된 경우가 있습니다. 이와 같은 문제들은 과거 테스트넷에서 몇 번 발생했으며, 해당 버그는 조치되었습니다.
만약 앞으로 비슷한 문제가 발생하는 경우, 문제를 해결한 소프트웨어를 배포하고 각 노드는 소프트웨어를 업데이트 하게 됩니다. 보통 텐더민트 버그는 기존 블록체인 상태를 덤핑하고 새로 불러와 재시작(dump-state-and-import restart)할 필요가 없지만, 특이한 사례에서는 덤핑이 필요할 수 있습니다.
과거 테스트넷에서 텐더민트 문제가 체인을 멈춘 경우:
- 텐더민트 코어 이슈 #3302
- 텐더민트 코어 이슈 #3199
- 텐더민트 코어 이슈 #3003
- 텐더민트 버전
v0.28.1은 과도한 증거(evidence)를 포함하여 블록을 제안할 때 합의 중단이 되는 문제를 수정했습니다.
안전성 결함 (블록체인 포크)
텐더민트 기반 체인이 포크를 발생하는 경우는 총 3개가 있습니다. 텐더민트 기반 체인은 근본적으로 포크를 허용하지 않기 때문에, 포크가 발생할 경우 일종의 안전성 결함으로 간주하게 됩니다. 이런 경우, 프로토콜 외부의 수동 조치(manual intervention)가 필요합니다.
본딩 물량의 ⅓ 이상의 악의적 행동
요약: 보팅 파워의 ⅓ 이상이 비잔틴(악의적, Byzantine) 행동을 하며 더블 스펜딩을 할 경우, 수동적 복구 절차를 통해 네트워크를 복원해야 합니다. 이 사례에서는 결함 원인 추적이 가능하며, 각 검증인은 본인이 확인한 모든 ‘표’(votes they have seen)를 전파해야 합니다.
해당 검증인이 확인한 표를 검증하기 위해서 검증인은 노드의 컨센서스 WAL 로그 파일을 가지고 있어야 합니다. 만약 블록체인이 포크하는 경우, 새로운 건전한 체인에 참여하기 위해 검증인들은 본인의 WAL 파일을 제출해야 할 수 있습니다. 본인의 WAL 로그를 제출하지 못하는 검증인은 부분적 슬래싱을 받을 수 있습니다. [참고: 만약 ≤⅔의 보팅 파워가 악의적인 경우, 현재까지 커밋된 블록체인의 상태를 변경할 수는 없습니다]
블록체인 상태와 표에 대한 분석이 끝난 후, 더블 사이닝을 한 키들에 대한 증거가 제출되면 해당 검증인들은 새로운 체인에서 제외되고 네트워크가 재시작됩니다.
본딩 물량의 ⅔ 이상의 악의적 행동
요약: 이 시나리오는 블록체인에 있을 수 있는 최악의 시나리오입니다. 만약 메인넷에서 이런 상황이 발생할 경우, 체인의 건전성이 완전하게 손상되었다고 간주할 수 있습니다.
예를 들어 4명의 ‘장군(검증인)’이 있는 상황에서, 4명 중 3명(⅔ 이상의 보팅파워)의 장군들이 공모하는 경우 그들은 어떤 정보를 ‘진실(truth)’로 취급하는지 결정할 수 있게 됩니다. 장군들의 무리 중 한 명의 선의적인 장군이 있다고 해도, 3명의 장군은 본인들의 정보를 전파하기 때문에 정보의 완결성이 완벽하게 사라지게 됩니다.
만약 4명의 장군 중 2명이 공모하는 경우, 위에 언급된 ‘보팅 파워 ⅓ 이상의 악의적 행동’ 시나리오와 같이 서로 일치하지 않은 정보를 전파하며 체인의 분리가 일어나게 됩니다(2개의 ‘진실’이 동시에 존재하는 상황).
보팅 파워의 ⅓ 이상의 악의적인 행동과는 달리, ⅔ 이상의 악의적 행동은 문제의 원인을 찾을 수 없습니다. ⅔ 이상이 공모하는 경우, 그들은 실제 블록체인의 상태를 임의로 변경할 수 있기 때문입니다.
이런 상황에서 체인을 복구하는 절차는 위에 논의된 ‘⅓ 이상 담합’ 시나리오와 비슷합니다. 우선 체인의 재배열(chain re-org)을 통해 악의적인 행동을 한 검증인들을 슬래싱 할 수 있습니다. 단 블록체인의 완결성을 결함 전의 상태로 되돌릴 수 있는 여부는 프로토콜 밖에서 주관적으로 결정되어야 할 사항들이 많기 때문에 이런 상황은 최대한 피해야 할 것입니다.
버그로 발생한 안전성 결함
요약: 텐더민트 코어의 버그로 같은 블록 높이에 두 개의 블록이 커밋되거나, 코스모스 SDK의 버그로 두개의 상태 루트(state root)가 같은 블록에서 연산될 수 있는 경우가 있습니다. 만약 이런 결함이 원인인 경우, 버그는 빠르게 수정되고 블록체인은 결함 발생 직전의 상태로 롤백 됩니다.
검열성 결함
요약: 한 검증인 또는 검증인 카르텔이 ⅓ 이상의 보팅 파워를 보유하는 경우, 체인 내에서 검열 공격이 발생할 수 있습니다. 위에 논의된 악의적 행동 공격(equivocation attack)은 원인 추적이 가능하지만, 검열 공격을 수행하는 검증인은 특정 합의 절차의 프로포절과 프리커밋이 실제 커밋되는 것을 막을 수 있습니다. 이런 경우에는 블록체인의 건전성을 위해 수동적인 조치가 필요합니다.
하드포크 실패 (무효한 스테이트 변경)
하드 포크 업그레이드
요약: 메인넷의 1단계에서 3단계 사이에는 다수의 하드포크가 거버넌스 절차를 통해 합의되고 진행될 수 있습니다. 이런 하드 포크는 스테이트 머신과 텐더민트 소프트웨어 개선등의 이유로 주요 변경 사항이 포함될 수 있습니다.
하드 포크 업그레이드는 순수 기술적으로 ‘무효한 스테이트 변경(invalid state transition)’으로 보일 수 있으나, ‘업그레이드’라는 악의적이지 않은 목적을 가지기 때문에 ‘합의된 하드 포크’로 간주하게 됩니다.
결론
위에 설명된 시나리오 같은 결함이 코스모스 허브 메인넷에서 발생하는 경우, 관련 업데이트와 실행 사항은 다음 코스모스 공식 채널을 통해 전달됩니다:
- 코스모스 트위터 (twitter.com/cosmos)
- 코스모스 깃허브 (github.com/cosmos)
- 코스모스 블로그 (blog.cosmos.network)
코스모스 포럼, 코스모스 라이엇 채팅 그리고 코스모스 텔레그램은 코스모스 공식 소식을 전달하는 채널이 아니라는 점을 인지하시기 바랍니다.
앞으로 코스모스 네트워크의 건전성과 안전성은 코스모스 블록체인의 운영자, 개발자 그리고 유저에 의해서 유지될 수 있습니다. 꼭 모든 위험에 유의하시고 언제나 신중하게 행동하시기 바랍니다. 추가적인 유의사항은 다음 블로그 글에서 확인하실 수 있습니다.
Cøsmos Korea 🇰🇷
참고: 이 글은 정보 제공을 위하여 번역된 글입니다. 내용/해석에 차이가 있을 수 있으며, 이 경우 영문 원문이 상위 권한을 가집니다.
원문: ‘The 4 Classes of Faults on Mainnet’ by Chjango Unchained / Cosmos Blog
원문날짜: 2019/3/12
