본문으로 이동
Financial Context Wiki

하드포크와 소프트포크: 규칙 호환성, 활성화, 체인 분리

하드포크와 소프트포크는 이전 및 신규 합의 규칙 사이의 서로 다른 호환 관계를 뜻한다. 유효 블록 집합, 활성화, 노드의 규칙 집행, 채굴자 또는 검증자 행동, 애플리케이션 준비, 재생 위험과 실제 체인 분리를 각각 분석한다.

업데이트

프로토콜 교육을 위한 분석일 뿐 투자 조언이 아닙니다. 제안되었거나 활성화된 포크는 검증, 입출금, 수탁, 계약, 가격, 유동성, 세무 처리와 운영 보안을 방해할 수 있으며, 지속 가능한 두 번째 자산의 생성을 보장하지 않습니다.

핵심 답변

하드포크와 소프트포크는 업그레이드한 노드와 하지 않은 노드가 블록을 어떻게 판단하는지에 따라 합의 규칙 변경을 분류한다. 이전 규칙이 허용하는 블록 집합을 V_old, 새 규칙이 허용하는 집합을 V_new라고 하자. 소프트포크는 유효 범위를 제한해 V_new subset V_old가 되게 한다. 즉, 새 규칙에서 유효한 모든 블록은 이전 규칙에서도 유효하지만 이전 노드는 추가 제약을 집행하지 않는다. 하드포크는 이전 노드가 거부하는 새 규칙 유효 블록을 하나 이상 허용한다: exists b: b in V_new and b not in V_old. 하드포크 규칙 집합은 확장일 수도, 서로 포함되지 않을 수도 있으며, ’하드’가 단순히 더 큰 블록이나 더 급진적인 기능을 뜻하지는 않는다.

호환성은 비대칭이다. 소프트포크가 성공하면 미업그레이드 노드는 업그레이드한 채굴자나 검증자가 만든 블록을 받아들이므로 같은 체인에 남을 수 있다. 그러나 업그레이드 노드가 거부하는 대상을 유효하다고 볼 수 있어 보증 수준이 낮다. 하드포크에서는 업그레이드한 생산자가 이전 유효 집합 밖의 블록을 만드는 순간 이전 노드가 이를 따라갈 수 없다. 경제적으로 중요한 참여자가 두 규칙 집합을 계속 지원하면 두 개의 지속적인 네트워크가 생길 수 있지만, 한쪽에 실질적 지원이 없다면 두 자산이 오래 남는 것은 아니다.

이 용어들은 규칙을 설명할 뿐 거버넌스의 정당성, 안전성, 경제적 지지나 활성화 방식을 말하지 않는다. 제안은 활성화 전에도 하드포크라 부를 수 있고, 활성화된 변경이 영구적 분리를 만들지 않을 수도 있다. 의도하지 않은 구현 비호환성이 거버넌스 투표 없이 체인을 분리할 수도 있다. 채굴자나 검증자 신호는 준비 상태를 조율할 수 있지만, 자체 규칙으로 무효인 블록을 풀 노드가 받아들이게 만들 수는 없다.

합의 포크를 동일 규칙 아래의 일시적 포크, 체인 재구성, 소프트웨어 저장소 포크, 애플리케이션 업그레이드와 혼동하면 안 된다. 운영상 핵심 질문은 각 노드, 지갑, 거래소, 수탁자, 오라클과 계약이 정확히 어느 네트워크, 규칙 집합, 활성화 조건과 체인 이력을 인정하는가이다.

프로토콜 포크 분석 방법

  1. 식별 정보와 범위를 고정한다. chain, network, client version, 활성화 제안, 제네시스 또는 최종 확정 체크포인트, 현재 블록 해시와 영향받는 계층을 기록한다. 같은 이름이라도 테스트넷, 메인넷, 실행 계층, 합의 계층 또는 애플리케이션에서 다른 규칙을 뜻할 수 있다.
  2. 합의 유효성을 비교한다. 변경된 블록, 거래, 서명, 상태 전이, 가스, 타임스탬프, 최종성 또는 포크 선택 규칙을 모두 열거한다. 대표 객체를 두 버전에서 각각 valid, invalid, unknown으로 분류하고 릴리스 노트만으로 호환성을 추정하지 않는다.
  3. 집합 관계를 입증한다. 새 규칙에서 유효한 모든 객체가 이전 규칙에서도 유효한지 검사한다. 그렇다면 소프트포크 호환이 가능하다. 새 규칙 유효·이전 규칙 무효인 블록이 하나라도 있으면 해당 노드에는 하드포크 전환이 필요하다. 이전 규칙 유효·새 규칙 무효인 객체도 검사한다.
  4. 활성화를 재현한다. 배포된 사양과 코드에서 높이, 에포크, 중간값 시간, 신호 임계값, 잠금 지연, 총 난이도 조건 또는 거버넌스 트리거를 확인한다. 신호, 잠금, 활성화와 집행은 서로 다른 상태다.
  5. 참여자 행동을 대응시킨다. 업그레이드한 블록 생산 가중치를 측정하고 각 진영의 풀 노드, 릴레이, 지갑, 거래소, 수탁자, 브리지, 스테이블코인 발행자, 오라클과 계약을 식별한다. 해시레이트나 지분만으로 경제적 수용을 결정할 수 없다.
  6. 분리와 거래 처리를 추적한다. 두 규칙 집합에서 부모 해시와 유효성을 따라간다. 확인 정책, 멤풀 차이, 재생 방지, 주소 형식, 체인 식별자, 서명 도메인, 출금 경로와 거래가 두 분기 모두에서 실행될 수 있는지 확인한다.
  7. 운영 통제를 설정한다. 조상 관계가 불명확하면 결제를 중지하거나 연장하고, 계획적으로 업그레이드와 백업을 수행한다. 분기별 잔액과 부채를 대조하고 서명 및 복구를 오프라인에서 시험하며, 명시한 체인·노드·거래상대방·최종성 기준을 충족한 뒤 재개한다.

이 방법은 흔히 ‘포크’ 한 단어로 묶는 네 사건, 즉 규칙 제안, 활성화 조건, 관측된 체인 분기, 이후 한 개 이상 분기의 경제적 생존을 분리한다. 어느 단계도 다음 단계를 자동으로 입증하지 않는다.

계산 예시

1. 유효 집합 호환성

이전 규칙이 100가지 후보 블록 형식을 허용하고 새 규칙은 그중 80가지만 허용한다고 하자. 그 80가지가 모두 이전 집합 안에 있으면 이 변경은 소프트포크 관계를 가지며, 나머지 20가지 이전 규칙 유효 형식은 업그레이드 노드가 거부한다. 이 숫자는 집합을 설명할 뿐 확률이나 투표 임계값이 아니다.

이제 새 규칙이 모든 이전 노드가 거부하는 블록 형식을 허용한다고 하자. 다른 대부분의 블록이 두 규칙에서 모두 유효하더라도 이 반례 하나면 하위 호환 수용 관계가 깨져 하드포크 비호환 전환이 된다. 실제 네트워크 분리가 지속되는지는 해당 블록 이후의 생산자, 사용자와 경제 인프라에 달려 있다.

2. BIP 34 활성화는 정의가 아니다

BIP 34는 코인베이스 거래에 블록 높이를 넣도록 하고 순환 준비 메커니즘을 사용했다. 직전 1,000개 블록 가운데 750 of 1,000개가 버전 2 이상이면 무효한 버전 2 블록을 거부했고, 950 of 1,000개에 도달하면 버전 1 블록을 거부했다. 이 BIP는 블록 227,835를 마지막 버전 1 블록으로 기록한다.

이 임계값은 배포를 조율했지만 변경을 소프트포크로 정의한 것은 아니다. 호환성은 업그레이드 노드가 수용 범위를 줄이는 동시에 이전 클라이언트가 새 규칙 준수 블록을 계속 받아들인 데서 왔다. 이후 BIP 9는 분리된 배포 상태와 버전 비트를 규정해 규칙 관계와 활성화 장치가 다른 문제임을 다시 보여 주었다.

3. Segregated Witness의 소프트포크 설계

BIP 141은 witness 데이터를 도입하고 코인베이스 거래를 통해 그 트리를 기존 블록 커밋 구조에 포함했다. 이 설계로 이전 노드는 새 witness 규칙을 이해하거나 검증하지 않아도 준수 블록을 받아들였고, 업그레이드 노드는 새 규칙을 집행했다.

이는 하위 호환 수용이지 동일한 검증이 아니다. 이전 노드는 새 규칙이 지배하는 출력을 업그레이드 노드보다 덜 제한적으로 볼 수 있으므로, 새 보안 속성에 의존하는 사용자는 업그레이드된 검증을 사용해야 한다. ’이전 소프트웨어가 계속 실행된다’는 말만으로는 위험 분석이 충분하지 않다.

4. 이더리움 DAO Fork

EIP-779는 메인넷 블록 1,920,000의 DAO Fork를 기록한다. 이는 지정 계정 목록 L의 잔액을 WithdrawDAO 계약으로 옮긴 비정규 상태 변경이며 EVM 연산 코드, 거래 형식과 블록 구조는 그대로 두었다.

이 상태 전이를 적용한 노드와 거부한 노드는 경계 뒤에 서로 다른 상태를 계산했다. 이 사례는 하드포크에 블록 확대나 연산 코드 추가가 필요하지 않고, 일회성 상태 전이 규칙도 비호환성을 만들며, 두 이력에 대한 지원이 지속되면 별도 네트워크가 존속할 수 있음을 보여 준다.

위험과 검토 오류

분류 및 사양 오류

  • 모든 노드가 같은 규칙을 쓰고 일반 포크 선택으로 해소되는 일시적 경쟁 체인 끝까지 하드포크라고 부른다.
  • 실제 유효 블록 집합을 검사하지 않고 모든 규칙 완화를 하드포크, 모든 제한을 소프트포크로 정의한다.
  • 하위 호환 수용을 완전한 하위 호환 보안으로 본다. 이전 노드는 새 소프트포크 제약을 집행하지 않는다.
  • 배포 코드와 체인 매개변수가 아니라 브랜드명, 로드맵, 릴리스 노트나 저장소 분기에서 합의 행동을 추론한다.
  • 메인넷, 테스트넷, 실행 계층, 합의 계층, 브리지, 롤업과 애플리케이션 계층 업그레이드를 혼합한다.
  • 제안, 클라이언트 릴리스, 신호 임계값, 잠금과 활성화를 같은 사건으로 본다.
  • 채굴자나 검증자 신호를 사용자, 거래소, 수탁자 또는 풀 노드를 구속하는 투표로 본다.

분리 및 거래 위험

  • 활성화가 반드시 분리를 만들거나 분리가 반드시 유동성과 지속성이 있는 두 자산을 만든다고 가정한다.
  • 같은 높이의 분기에 다른 블록이 있을 수 있는데 높이만 사용하고 해시와 조상 관계를 검증하지 않는다.
  • 재생 방지, 체인 식별자, 서명 도메인과 분기 전용 거래 구성을 확인하지 않고 분리 중 송금한다.
  • 한 분기의 입금을 인정하면서 다른 분기에서 부채나 출금을 결제한다.
  • 제공자가 다른 규칙을 따르거나 전환에 뒤처질 수 있는데 단일 탐색기, RPC 엔드포인트나 수탁 표시만 믿는다.
  • 재구성, 최종성 중단, 피어 분할, 소수 채굴, 검증자 이중 투표나 데이터 비가용성을 무시한다.
  • 토큰 기호, 계약 주소, 스테이블코인 잔액, 오라클 가격이나 브리지 청구권이 두 분기에서 같은 발행자 보장을 받는다고 가정한다.

거버넌스 및 운영 위험

  • 프로토콜 호환성을 변경의 정당성, 탈중앙성, 안전성 또는 경제적 지지의 증거로 설명한다.
  • 재현 가능한 바이너리, 백업, 롤백 한계, 데이터베이스 이전 시험과 독립 해시 확인 없이 운영 노드를 업그레이드한다.
  • 새 상태 데이터, 지갑 형식이나 슬래싱 조건 도입 뒤에도 다운그레이드가 항상 안전하다고 본다.
  • 비밀을 노출하거나 서명을 재생할 수 있는 검증되지 않은 소프트웨어로 개인 키를 옮기거나 ’포크 코인을 청구’한다.
  • 만기, 잠금, 계약 상태와 수탁 정책을 확인하지 않고 스냅샷 잔액을 즉시 쓸 수 있다고 본다.
  • 분기 소유권, 통제, 유동성과 현지 규칙이 확정되기 전에 세무, 회계나 가치평가 결론을 낸다.

흔한 오해

  • 하드포크는 항상 새 코인을 만든다. 두 번째 자산이 지속되려면 계속되는 블록 생산, 사용자, 인프라와 시장이 필요하며 많은 업그레이드는 하나의 인정된 이력으로 수렴한다.
  • 이전 노드가 작동하므로 소프트포크는 무위험이다. 체인을 따를 수는 있지만 추가 규칙을 집행하지 않아 검증 보장이 약해질 수 있다.
  • 과반 해시레이트나 지분만으로 어떤 규칙이든 바꿀 수 있다. 풀 노드는 자체 규칙에서 무효인 블록을 거부하고 생산 가중치는 수용한 블록 사이에서만 작용한다.
  • 하드는 논쟁적이고 소프트는 만장일치라는 뜻이다. 이 용어는 호환성을 분류할 뿐 사회적 합의, 거버넌스 품질이나 논쟁 여부를 나타내지 않는다.
  • 탐색기에 보이는 모든 포크가 프로토콜 업그레이드다. 동일 규칙의 경쟁 블록과 체인 재구성은 합의 규칙 변경 없이도 발생한다.

관련 주제

출처

탐색

위키 검색...