눈사태처럼 쏟아지는 합의: Avalanche 구조와 51% 공격 방어
“한 번의 합의가 아니다.
네트워크 전체가 계속해서 의견을 맞춰가는 과정이다.”
1편에서 우리는 블록체인이 왜 본질적으로 느려질 수밖에 없는 구조인지,
그리고 그 핵심에 엔트로피(혼돈)와 합의(정렬) 문제가 있다는 것을 살펴봤습니다.
이제 2편에서는 본격적으로 Avalanche 합의 구조와
그 안에 숨겨진 51% 공격 방어 메커니즘을 다룹니다.
- “샘플링 합의가 뭐길래 이렇게들 난리지?”
- “해시파워가 더 많으면 무조건 이기는 거 아닌가?”
- “비트코인에서 말하는 51% 공격, eCash에선 어떻게 되나?”
이 질문에 한 번에 정리해서 답하는 편이라고 보시면 됩니다.
1. 전통적인 합의 vs Avalanche 합의: 관점부터 다르다
먼저 기준점을 하나 잡고 가야 합니다.
🧱 비트코인식 합의
- 블록 발견 시점에만 네트워크가 “한번에” 합의
- 그 사이(10분)는 각자 다른 현실을 보고 있음
- 합의는 이산적인 이벤트(discrete event)
🧊 Avalanche식 합의
- 블록이 없을 때도 노드끼리 계속 상호 질의·응답
- 네트워크가 시간이 지날수록 한 방향으로 수렴
- 합의는 연속적인 과정(continuous process)
비트코인은
“블록이 나왔을 때, 다 같이 ‘이걸로 하자’라고 정하는 구조”
라면,
Avalanche는
“계속 서로에게 의견을 물어보면서, 자연스럽게 한 방향으로 정렬되는 구조”
입니다.
2. Avalanche 합의 구조 한 번에 이해하기
기본 아이디어는 놀랍도록 단순합니다.
“모든 노드에게 물어볼 필요는 없다.
매번 소수의 무작위 노드에게만 물어봐도
이 과정을 계속 반복하면 전체 네트워크가 같은 결론에 도달한다.”
🔄 아주 단순화한 과정
- 내 노드가 두 개의 상충하는 선택지를 본다
- 예: 두 개의 경쟁하는 트랜잭션 / 두 개의 경쟁하는 블록
- 네트워크의 일부 노드를 무작위로 샘플링해서 묻는다
- “너희는 A랑 B 중에 뭘 선호하니?”
- 응답의 다수가 A를 고르면
- 나도 A 쪽으로 내 의견을 맞춘다
- 이 행동을 수십 번 반복
- 매 라운드마다 “다수 의견” 쪽으로 더 많은 노드가 따라 붙음
- 어느 순간부터는 네트워크의 거의 모든 노드가 같은 방향을 가리킴
- 이 상태가 일정 횟수 이상 유지되면
- “이제 이 선택은 Final(최종) 이라고 본다”
이게 바로 Avalanche가 말하는 확률적 최종성(Probabilistic Finality)입니다.
즉, 수학적으로 “거의 0에 가까운 확률로 뒤집히지 않는다”고 보장 가능한 상태까지 간다는 뜻입니다.
3. 왜 “눈사태(Avalanche)”라는 이름일까?
눈사태를 떠올려 보면 이해가 쉽습니다.
- 처음에는 작은 눈덩이 하나가 굴러가기 시작합니다
- 내려가면서 주변 눈을 계속 붙이면서 점점 더 커지고, 더 빠르게 미끄러져 내려갑니다
- 어느 순간부터는 멈출 수 없는 거대한 흐름이 됩니다
Avalanche 합의도 똑같습니다.
- 처음엔 서로 의견이 다를 수 있습니다
- 하지만 매 라운드마다 다수 의견 쪽으로 노드들이 조금씩 이동합니다
- 한 방향으로 기울기 시작하면,
그 기울기가 점점 더 강화되는 구조입니다 - 결국엔 반대 방향으로 되돌리는 것이 사실상 불가능해집니다
이 “되돌릴 수 없을 정도의 수렴 상태”가 바로
합의의 Finality(최종성)입니다.
4. 51% 공격, 먼저 비트코인 관점에서 짚고 가자
이제 많은 사람들이 궁금해 하는 51% 공격 얘기로 가봅시다.
💣 비트코인에서의 51% 공격 시나리오
- 공격자가 전체 해시파워의 51% 이상을 장악
- 공개 체인에서는 정상적으로 거래하는 척 하면서
- 비공개 체인(숨겨진 체인) 을 따로 캅니다
- 비공개 체인에서는
- 자신에게 유리한 트랜잭션만 포함
- 혹은 특정 거래를 롤백할 수 있는 구조로 블록을 쌓음
- 어느 순간
- 비공개 체인이 공개 체인보다 “더 긴 체인(더 많은 작업)”이 되었을 때
- 이 체인을 한 번에 네트워크에 공개
- 규칙상 “더 긴 체인이 진짜” 이므로
- 전체 노드가 공격자의 체인으로 갈아탐 → 리오그(reorg) 발생
- 기존에 확정된 줄 알았던 거래가 사라지거나 되돌려짐
이게 전통적으로 말하는 51% 공격입니다.
해시파워가 더 많은 쪽이 “사실을 덮어쓸 수 있는 구조”죠.
5. Avalanche + eCash는 어떻게 막는가?
핵심은 한 줄입니다.
“체인이 얼마나 ‘길어졌는지’만 보지 않고,
그 체인이 ‘언제부터 네트워크의 합의 대상이었는지’를 함께 본다.”
조금 풀어서 설명해 볼게요.
🧱 예시 상황
- 블록 1, 2, 3까지는 모두가 동일하게 공유하고 있는 상태
- Honest 체인: 1 → 2 → 3 → 4 → 5 …
- 공격자 체인: 1 → 2 → 3 → 4’ → 5’ → 6’ … (비공개로 따로 캔다가 나중에 공개)
비트코인은
- “어느 쪽이 더 많은 작업(해시)을 포함했나?”만 보고
- 더 긴 쪽(공격자 체인)으로 갈아타게 됩니다.
🔍 Avalanche가 추가로 보는 것
eCash + Avalanche에서는
각 노드가 단순히 “블록을 받는 것”을 넘어서,
계속 서로에게 묻고 있습니다.
“너희가 보는 체인의 마지막 블록(Tip)은 뭐야?”
- 모든 노드가 어느 시점에
“우리는 블록 3까지를 공식 상태로 인정한다”라는
공통 인식을 형성했다면,
이게 Avalanche 합의 기준에서 하나의 Final 상태로 기록됩니다.
그 다음에
- 갑자기 어디선가
3 다음에 오지도 않은
4’, 5’, 6’이 한꺼번에 튀어나오면,
노드들은 이렇게 판단합니다.
“이건 우리가 알고 있던 정상 합의 흐름에서 나온 게 아니다.
네트워크가 공유하지 않던 ‘뒤늦게 등장한 체인’이다.
→ 공격일 가능성이 매우 높다.”
그리고 그 체인을 통째로 거부할 수 있습니다.
설령 그 체인이 작업량(Proof-of-Work)이 더 많더라도 말이죠.
이게 바로 Avalanche를 활용한 Post-Consensus(사후 합의)가
51% 공격의 주요 클래스를 막아내는 원리입니다.
6. 왜 “나 혼자”는 판단할 수 없는가?
여기서 중요한 포인트가 하나 있습니다.
“내 노드 혼자만 봐서는,
이게 공격인지 네트워크 문제인지 절대 확신할 수 없다.”
예를 들어 내 노드 입장에서 보면:
- “혹시 내 쪽 네트워크가 잠깐 끊겨서
예전에 나왔던 블록을 이제야 받은 걸 수도 있잖아?” - “내 라우터, 내 ISP가 잠깐 끊겼다가 다시 붙었을 수도 있고…”
그러니까 혼자만의 시점으로는
이게 정상적인 리오그인지,
악의적인 51% 공격인지 구분이 안 됩니다.
그래서 Avalanche는
반드시 네트워크 전체의 의견을 묻는 구조를 씁니다.
- 내 노드가 새 체인을 본다
- 주변 노드들에게 무작위로 묻는다
- “너희는 이 체인을 정상적인 현재 체인으로 보고 있었니?”
- 다수의 응답이
- “우리도 3에서 합의 보고 있었고,
방금 처음 4’, 5’, 6’을 본다”라면 → 공격 의심
- “우리도 3에서 합의 보고 있었고,
- 이 투표가 반복되면서
- 전체 네트워크가 “이건 받아들일 수 없다”는 쪽으로 수렴
- 결과적으로
- 더 긴 체인이라도
- 모든 노드가 이미 합의했던 “정상 체인”을 뒤엎으려 하면
- 그 체인은 버려진다
즉, eCash의 합의는
“길이가 긴 체인”을 무조건 따라가는 방식이 아니라,
“네트워크가 이미 Final이라고 인정한 상태를
나중에 뒤집으려는 시도”를 거부하는 구조입니다.
7. Heartbeat: 사용자 입장에서 느껴지는 안정성
Avalanche는 51% 공격 방어뿐 아니라,
“체감 안정성”도 크게 올려줍니다.
그 중 하나가 Heartbeat(하트비트) 메커니즘입니다.
📡 Heartbeat가 하는 일
- 네트워크에 이상하게 자주 블록이 몰리거나,
- 반대로 너무 오랜 시간 블록이 안 나오면,
- 각 노드는 “이 블록을 바로 연결할지 말지”를 주관적으로 판단할 수 있습니다.
예를 들어:
- “이전 블록 이후 1초 만에 또 블록이 들어왔다”
→ 내 시계 기준으로 너무 빠르다고 판단되면
→ 일단 그 블록을 ‘Parked(보류)’ 상태로 옆에 세워 둠 - 완전히 버리는 게 아니라,
“유효하긴 한데 지금 당장은 체인에 연결하지 않겠다”는 의미입니다.
그리고 난 뒤, Avalanche 합의로
다른 노드들에게 계속 묻습니다.
“너희도 이 블록 이상하다고 느꼈니?
아니면 정상이라고 보고 바로 체인에 붙였니?”
- 다수의 노드가 “정상”이라고 판단했다면
→ 나도 ‘Parked’ 상태에서 꺼내서 체인에 연결 - 다수의 노드가 “이건 아닌 것 같다”고 판단했다면
→ 나 역시 끝까지 그 블록을 거부
이 구조 덕분에:
- 블록 간격이 더 규칙적으로 유지되고
- 사용자 입장에서는
- 가끔 “순식간에 4개 블록, 한참 동안 0개 블록” 같은
널뛰기 현상이 줄어듭니다.
- 가끔 “순식간에 4개 블록, 한참 동안 0개 블록” 같은
즉, 기술 내부에 있는 ‘불규칙성’을 UX 레벨에서 완화시키는 역할을 한다고 볼 수 있습니다.
8. 요약: Avalanche 구조 & 51% 방어 포인트 정리
이번 2편에서 다룬 핵심만 다시 뽑아보면:
- Avalanche 합의는 ‘계속되는 합의’다.
- 매 라운드마다 소수 샘플링 → 다수 의견에 맞추는 투표 반복
- 네트워크 전체가 눈사태처럼 한 방향으로 수렴
- 51% 공격을 보는 관점이 다르다.
- 단순히 “더 긴 체인”이 아니라
- “네트워크가 이미 Final로 합의한 상태를 뒤집으려는 시도”를 차단
- 비공개 체인(숨겨진 체인) 공격을 막을 수 있다.
- 공격자가 나중에 긴 체인을 공개해도
- 노드들은 “우린 3까지를 공식 상태로 합의했었다”는 기록을 가진다
→ 한 번 합의된 현실을 나중에 덮어씌우는 걸 거부
- Heartbeat로 UX도 함께 개선된다.
- 이상하게 촘촘하거나 비어 있는 블록 간격을
주관적 판단 + Avalanche 합의로 정리 - 사용자 입장에서는 “안정적인 체인”으로 체감
- 이상하게 촘촘하거나 비어 있는 블록 간격을
다음 편 예고:
“3초 안에 결제를 확정한다는 말, 정확히 무슨 뜻인가?”
3편에서는 드디어
Pre-Consensus(사전 합의)를 다루게 됩니다.
- “노드들이 트랜잭션 수준에서 미리 합의한다는 건 어떤 의미인가?”
- “블록에 들어가기 전인데, 어떻게 ‘사실상 최종 확정’이라고 말할 수 있나?”
- “Double Spend는 이 구조에서 어떻게 원천 차단되는가?”
- “사용자는 실제로 2~3초 안에 무엇을 보게 되나?”
즉,
‘3초 결제’가 홍보 문구가 아니라
어느 수준까지 ‘안전한 확정’인지
를 구체적인 사용자 경험 관점에서 풀어볼 예정입니다.
About the Author
