비트코인 업그레이드

비트코인은 그동안 다양한 업그레이드를 진행했습니다. 그 중 사용자 경험 관점에서 가장 크게 변화된 업그레이드로는 세그윗(SegWit)과 탭루트(Taproot)가 있습니다. 근데 업그레이드...어떻게 되는지 궁금하시지 않나요? 가장 탈중앙화된 블록체인인 비트코인은 어떤 식으로 체인을 업그레이드 할까요?

비트코인 업그레이드? 소프트포크?

저 또한 그랬지만 많은 이들이 비트코인은 변하지 않는다고 생각합니다. 하지만 비트코인은 참여 주체인 노드의 합의에 따라 조금씩 변화되고는 합니다. 이전 글에서 다룬 비트코인 스크립트도 그 예시 중 하나입니다.

다만 비트코인은 다른 목적이 있는 알트코인 업그레이드와 다르게 원칙이 있습니다. 이전 버전과 호환이 되도록 업그레이드하는 "소프트포크(Soft Fork)" 방식을 사용합니다. 이유는 단순합니다. 이전 버전과 호환이 되지 않으면 모든 참여 노드가 동시에 새로운 규칙을 채택해야 하고, 이 과정에서 분열이 이뤄질 수 있으며, 보안에 위협이 될 수 있기 때문입니다. 그래서 비트코인 업그레이드는 노드가 이전 버전의 규칙을 사용하더라도 네트워크에 계속 참여할 수 있게 되어 있습니다.

BIP(Bitcoin Improvement Proposal)

BIP는 직역하면 "비트코인 개선 제안"으로 비트코인 네트워크 개선을 제안하는 포맷 중 하나입니다. 커뮤티티 주도 네트워크인만큼 온라인 아고라라고 생각하시면 됩니다.

제안은 쉽습니다. 가장 중요한 것은 참여자 간의 합의입니다. (다른 블록체인과 마찬가지로) 소수만이 해당 규칙을 채택할 때, 다른 참여자가 해당 트랜잭션이 포함된 블록에 대해 합의를 거부할 수 있기 때문입니다.

💡
참고로 BIP 번호는 꼭 순서대로 이루어지지는 않습니다. 본문에서는 시간 순서인 BIP-34, BIP-9 순서대로 설명을 진행합니다.

BIP-34, 합의를 위한 기준

BIP-34: Block v2, Height in Coinbase 는 원래는 합의에 관련된 내용이 주는 아닙니다. 주요 제안은 coinbase 거래 (비트코인 마이너가 새로운 블록을 생성할 때 첫 거래로 여기서 보상과 수수료를 얻게 됨)에 블록 높이를 넣는 제안입니다. 기존에 coinbase 거래에 다른 데이터가 없었기에 블록 높이를 포함시켜 동기화와 식별 차원에서 개선을 하는 게 목표였습니다.

근데 여기서 합의와 관련된 재밌는 제안이 있습니다.

  1. 75% rule: 생성되는 1000개의 블록 중 750개가 version 2 이상이라면, 유효하지 않은 버전 2는 모두 거절합니다.
  2. 95% rule: 생성되는 1000개의 블록 중 950개가 version 2 이상이라면, 유효하지 않은 버전 1은 "앞으로" 모두 거절합니다.

즉 최신 95%가 동의하는 순간부터 이전 버전에 대해서는 동의하지 않고 version 2로 합의되었음을 간주하는 것입니다. 여기서 처음으로 소프트포크 합의의 임계값 95%가 정해졌습니다.

BIP-9, 소프트포크 합의의 고도화

초반에는 합의를 이뤄내는 프로세스가 명확하지 않았고, 이에 대해 명확하게 정해진 것이 BIP-9: Version bits with timeout and delay 입니다. 과거에는 버전에 번호를 매겨 이에 대해 채굴하는 정도를 측정하여 소프트포크를 진행해습니다. 다만 이 방식은 소프트포크를 여러 개 동시에 제안 및 조정이 어려웠습니다. 즉, 병렬적인 소프트포크에 대해 제안할 수 없었으며 이는 시간 관점의 기회 비용 측면에서 매우 손해입니다. 이런 여러 문제점을 해결하기 위해 Pieter Wuille와 일부 비트코인 컨트리뷰터는 BIP-9에서 소프트포크와 관련된 몇 가지 사항을 제안했습니다.

버전 번호와 버전 비트

블록 버전을 번호에 버전 비트(version bits)를 추가합니다. 과거에 수로만 한정되었던 버전에 비트로 더 다양한 소프트포크를 추적할 수 있게 되었습니다. 기본적으로 컴퓨터 언어의 데이터 표준은 4바이트(32비트)로 구성됩니다. 포함 여부에 따라 0과 1로 구분하면 되기에 0000...0000 ~ 1111...1111까지 2^32가지의 케이스를 표현할 수 있습니다.

채굴자의 대규모 프로토콜 업데이트 반영 여부와 소프트포크 지원 사항에 대해 이 32개의 [0, 1]을 통해 나타냅니다. 앞에 비트 3개 (29, 30, 31번째)는 버전 번호를 표현합니다. 이진수로 나타내면 0~7까지 총 8개의 버전을 표현할 수 있습니다. 그리고 나머지 29개의 비트(0, 1, ... 28번째)는 각 비트당 하나씩 소프트포크 제안에 대해 추적할 수 있게 되어 있습니다.

예시로 아래 우측 라인의 상단 3번째 줄을 보면 version 0x20000002라고 표기된 것을 확인할 수 있습니다. 여기서 우측의 2는 0010을 표현한 것으로 여기서 1이 세그윗 지원을 의미하고 있습니다. 그리고 좌측의 2는 010 으로 위에서 언급한 BIP-34에서 제안한 version 2를 의미합니다.

첫 세그윗 활성화를 위한 BIP-141이 적용된 첫 블록: 링크

합의 상태 프로세스

BIP-9의 가장 큰 기여는 소프트포크 제안 상태에 대해 좋은 멘탈 모델을 만들고 커뮤니티 합의를 이뤄낸 것입니다. 제안을 하면 어떤 식으로 활성화 될까요?

  1. DEFINED: BIP에서 제안은 되었으나 활성화되지 않은 상태입니다.
  2. STARTED:활성화 시그널링이 된 상태. 지정된 시간부터 해당 소프트포크에 대해 마이너들의 지지 상태에 대해 추적합니다.
  3. LOCKED_IN: 약 2주간 2016개 블록에 대해 소프트포크 지지율이 95% 이상일 때 해당 소프트포크는 활성화가 확정됩니다.
  4. ACTIVE: 위 상태에서 다시 2016개의 블록이 생성되면 자동으로 active 상태가 되며, 모든 노드가 새로운 소프트포크 규칙을 적용해야 합니다.
  5. FAILED: started -> locked_in 상태 전환이 지정된 시간 내에 이뤄지지 않으면 해당 소프트포크 제안은 실패한 제안으로 간주됩니다. 일반적으로 1년 정도로 설정됩니다.

참고로 세그윗(BIP-141)은 2016년 11월에 started로 시작하여 2017년 8월 25일에 active가 되었으며, 탭루트(BIP-341)는 2021년 5월 1일에 started로 시작되어 2021년 11월 14일에 active 되었습니다.

💡
다만 세그윗과 탭루트 모두 이렇게 BIP-9만으로 업그레이드 된 것은 아닙니다. 각 관련된 업그레이드에 얽힌 스토리는 다음 컨텐츠에서 계속...
BIP의 상태 전환 도표

마치며

비트코인은 과연 불변일까요? 저는 앞으로도 무수히 많은 변경이 있을 것이라 생각합니다. 그리고 기술과 스토리텔링이 결합되며 다양한 기회들이 나타날 것이라 생각합니다. 다음 글에서는 세그윗과 탭루트의 기술적인 구현 방식과 합의 과정에 대해 알아보도록 하겠습니다.

Future Reading