Soft Fork

안나와 파벨이 각각 자기 컴퓨터로 Bitcoin을 검증한다고 해 보겠습니다. 안나는 소프트웨어를 업데이트했고 파벨은 아직 하지 않았습니다. 이제 BIP66과 비슷한 변경이 도입됩니다. 특정 비트코인을 사용할 권한을 증명하는 디지털 서명은 더 엄밀하게 정해진 형식을 따라야 합니다. 이전에 허용되던 일부 인코딩은 더 이상 쓸 수 없게 됩니다. 유효한 서명이 새로 요구되는 형식으로 작성된 지급은 두 컴퓨터 모두에서 이 검사를 통과합니다. 반면 예전에는 허용됐지만 이제 금지된 인코딩을 사용하면 안나는 거부하고 파벨은 여전히 받아들일 수 있습니다. 여기서는 거래가 나머지 모든 규칙을 충족한다고 가정합니다. 바로 이 차이가 Soft Fork의 핵심입니다. 새 규칙은 기존에 금지된 것을 허용하지 않으면서, 금지되는 경우를 추가합니다. 채굴자가 강화된 규칙에 맞는 블록을 만든다면 둘 다 그 체인을 계속 따라갈 수 있습니다. 그러나 파벨은 추가 조건을 직접 검사하지 않습니다. 따라서 Soft Fork는 모든 노드를 동시에 업데이트하지 않고도 Bitcoin을 바꿀 수 있게 합니다. 그렇다고 오래된 소프트웨어가 새 소프트웨어만큼 검증하는 것은 아니며, 그 자체로 두 번째 통화가 생기지도 않습니다. [1] [6]

Full Node는 Bitcoin의 규칙을 독립적으로 검사하는 컴퓨터입니다. 유효한 분기들 가운데 선택할 때는 지지자의 표가 아니라 채굴로 입증된 누적 작업량을 비교합니다. 업데이트된 채굴자가 기존 규칙에도 맞는 블록을 만들면 오래된 노드도 체인을 따라갈 수 있습니다. 다만 추가된 조건은 검사하지 않습니다. 새 규칙을 어긴 분기의 누적 작업량이 더 많다면 오래된 노드는 받아들이고 업데이트된 노드는 거부할 수 있습니다. 새로운 보장을 직접 확인하려면 검증 소프트웨어를 업데이트해야 합니다. 지갑이 지급을 받거나 새 주소 형식을 인식할 수 있다고 해서 네트워크의 모든 규칙을 검사하는 것은 아닙니다. [1] [12]

BIP는 번호가 붙은 기술 제안입니다. 발표만으로 네트워크가 바뀌지는 않습니다. 소프트웨어를 개발하고 검증해야 하며, 사용할지는 이용자가 결정합니다. Mainnet은 실제 비트코인을 전송하는 주 네트워크입니다. 활성화는 업데이트된 노드가 언제부터 새 규칙을 요구하는지 정합니다. 따라서 프로그램 안에 코드가 있는 것과 블록 검증에 그 코드를 사용하는 것은 다릅니다. 여기서 설명하는 절차에서 lock-in은 이후 활성화에 필요한 조건이 충족됐다는 뜻이며, 규칙 자체는 아직 적용되지 않을 수 있습니다. 노드는 ACTIVE 상태에 이르러야 이 규칙을 검사합니다. 상태는 자신이 따르는 분기의 이전 블록들로 계산합니다. 활성화 경계 부근에서 재구성이 일어나 이력이 바뀌면 계산 결과도 달라질 수 있습니다. 그래서 활성화 설정이 다른 두 프로그램은 같은 시점에도 서로 다른 블록을 받아들일 수 있습니다. [2] [15]

채굴자는 이전 블록에 이어 새 블록을 만듭니다. 이 이전 블록을 부모 블록이라고도 합니다. 부모를 검증하지 않으면 다른 노드가 거부하는 분기에 작업을 낭비할 수 있습니다. 2015년 7월 BIP66 활성화 당시 일부 채굴자는 새 버전을 표시하면서도 부모 블록을 충분히 검증하지 않았습니다. 이들은 무효 블록 위에 채굴을 이어 가 7월 4일에는 6블록 길이의 무효 분기를 만들었고, 다음 날에도 더 짧은 분기가 생겼습니다. 업데이트된 검증 노드는 두 분기를 모두 거부했습니다. 버전 번호나 비트는 채굴자의 주장이며, 준비한 블록과 부모 블록, 포함된 거래를 실제로 검증했다는 증거는 아닙니다. [6] [14]

내 노드가 실제로 어떤 규칙을 적용하는지 확인하려면 소프트웨어 버전과 노드 자체가 반환하는 정보부터 살펴보면 됩니다. 버전에 따라 getdeploymentinfo와 getblockchaininfo는 도입된 변경 사항과 체인 정보를 제공합니다. 해당 버전의 문서, 활성화 높이, 로그를 함께 보면 준비된 규칙과 이미 적용 중인 규칙을 구분할 수 있습니다. 웹의 블록 탐색기는 다른 서비스가 보는 상태를 보여 줄 뿐, 내 컴퓨터가 무엇을 검증하는지는 증명하지 않습니다. Hashrate는 채굴의 계산 능력을 나타냅니다. 채굴자가 내 노드의 규칙을 무시할 권한을 주지는 않습니다. ACTIVE 상태의 업데이트된 노드는 새 조건을 위반한 블록을 채굴 능력의 다수가 지지하더라도 거부합니다. 체인 분리가 지속될지는 각 분기의 누적 작업량과 경제적 사용에도 달려 있습니다. 적용 중인 제한을 단순히 없애면 현재 무효인 블록을 다시 허용하므로 Hard Fork에 해당합니다. 활성화 전에는 조율된 소프트웨어 배포로 설정을 바꿀 수 있지만, 그 변경도 다른 사람의 노드에 저절로 설치되지는 않습니다. [1] [15] [16]

업데이트 이전 규칙으로 받아들이는 모든 블록을 V(기존)이라고 하겠습니다. Soft Fork가 되려면 V(신규)가 그 안에 있어야 합니다. 새 노드는 추가적인 경우를 거부하지만, 새 규칙을 충족하는 블록은 기존 검사도 통과합니다. 이 이름은 규칙 사이의 호환 관계를 나타낼 뿐, 변경이 작거나 안전하거나 사회적 합의를 얻었다는 뜻은 아닙니다. 오래된 노드에 보이는 한도를 높이거나 이전에 무효였던 지출을 허용하면 허용 범위가 넓어지므로 일반적으로 Hard Fork가 필요합니다. [1] [17]

규칙을 강화하면서 새 기능을 도입할 수도 있습니다. BIP66은 서명 데이터의 인코딩 형식인 DER을 엄격히 정했습니다. BIP65와 BIP112는 이전에 아무 조건도 강제하지 않던 일부 NOP 명령에 지출 시간 조건을 추가했습니다. SegWit은 witness 프로그램과 서명 등을 담는 witness 검증 데이터를 도입했습니다. 이후 Taproot가 예약된 버전 1을 사용했습니다. 오래된 노드는 해당하는 새 조건을 검사하지 않습니다. Anyone-can-spend는 이런 제한된 관점을 가리킬 뿐, 업데이트된 노드를 우회해 남의 코인을 쓸 수 있다는 뜻이 아닙니다. 또한 SegWit은 witness commitment로 witness 데이터를 블록에 암호학적으로 연결합니다. 이 연결은 채굴자 보상을 포함하는 첫 번째 거래인 coinbase 거래에 기록되며, 기존 기본 블록 규칙과의 호환성을 유지합니다. [6] [5] [7] [8] [12]

비트의 값은 0 또는 1입니다. 블록 헤더의 버전 필드인 nVersion에서 각각의 비트는 채굴자의 준비 상태를 알리는 데 쓰일 수 있습니다. BIP9는 각 도입에 이름, 특정 비트, 시작 시각과 기한을 지정합니다. 초기의 mainnet 절차는 2016블록 단위로 평가합니다. STARTED 상태에서 최소 1916블록, 즉 95 %가 신호를 보내면 다음 기간은 LOCKED_IN이 됩니다. 한 기간을 더 기다린 뒤 ACTIVE로 넘어갑니다. 기한 전에 조건을 충족하지 못하면 FAILED로 끝날 수 있습니다. 시작 전의 초기 상태는 DEFINED입니다. 각 노드는 이전 블록들로 이 상태 변화를 계산합니다. 따라서 어떤 블록 자체의 nVersion이 그 블록에 새 규칙을 적용할지 결정하지는 않습니다. 신호는 전환을 조율하는 수단이며, 개별 블록의 유효성을 투표하는 수단이 아닙니다. lock-in 이후의 신호는 이 절차의 결과를 바꾸지 않습니다. [2]

Versionbits는 채굴자가 준비 상태를 알리게 하지만, 다른 노드의 규칙을 바꿀 권한을 주지는 않습니다. BIP8은 시간 경계 대신 블록 높이를 사용합니다. lockinontimeout이 true이고 아직 lock-in에 도달하지 않았다면 마지막 기간은 신호를 의무화하는 MUST_SIGNAL로 넘어갈 수 있습니다. BIP148은 참여 노드가 SegWit 신호가 없는 블록을 거부하도록 요구했습니다. BIP91은 더 낮은 채굴자 신호 임계치로 이 전환을 조율했습니다. 규칙 적용, hashrate, 경제적 수용이 엇갈리면 체인이 분열될 수 있습니다. 따라서 활성화 방식을 선택할 때는 보안상의 이점과 위험을 함께 검토해야 합니다. [11] [9] [10] [17]

P2SH (BIP16)는 나중에 자금을 사용할 조건을 담은 프로그램, 즉 스크립트의 해시로 자금을 보낼 수 있게 합니다. 2012년 도입 당시 coinbase 거래의 신호는 채굴자의 준비 상태를 판단하는 데 도움이 됐습니다. 하지만 새 검사는 정해진 블록 타임스탬프 경계부터 적용됐으며, 신호가 검증을 대신하지는 않았습니다. Coinbase는 채굴자 보상이 담긴 블록의 첫 거래입니다. 이후 변경은 블록 버전과 신호 임계치를 사용했습니다. BIP34는 체인에서의 위치인 블록 높이를 coinbase에 기록하도록 했습니다. BIP66은 DER 서명 형식을 엄격하게 만들었고, BIP65는 지출이 가능한 가장 이른 시각이나 높이를 확인하는 CHECKLOCKTIMEVERIFY를 도입했습니다. 버전 번호를 차례로 높이는 방식은 독립적인 변경을 병렬로 도입하기 어렵게 했습니다. 그래서 BIP9는 별도의 비트를 도입했습니다. 2016년 높이 419328에서 BIP68, BIP112, BIP113이 함께 활성화됐지만, 각각 다른 시간 조건을 다룹니다. BIP68은 지출할 출력이 확인된 뒤부터 계산하는 상대적 대기를 도입합니다. BIP112는 스크립트에서 CHECKSEQUENCEVERIFY, 줄여서 CSV로 이 대기를 요구할 수 있게 합니다. 반면 BIP113은 절대 시간 잠금의 기준을 바꿉니다. 평가 중인 블록의 시각 대신 이전 11블록의 타임스탬프 중앙값인 Median Time Past를 사용합니다. 함께 활성화됐다고 해서 세 제안 모두 같은 상대적 잠금을 도입한 것은 아닙니다. [3] [4] [5] [6] [7] [18] [19] [20]

SegWit은 2017년 8월 높이 481824에서 활성화됐습니다. 서명 같은 witness 검증 데이터를 거래 식별자 txid 계산에 쓰는 부분에서 분리했습니다. 왜 중요할까요? 이전 인코딩에서는 수취인과 금액은 그대로 두면서 서명 표현을 바꿔 거래 식별자를 바꿀 수 있었습니다. 이런 가능성을 가변성, malleability라고 합니다. witness 데이터만 바꾸면 txid는 바뀌지 않습니다. 다만 이 방식으로 여전히 구형 형식을 쓰는 입력까지 해결되는 것은 아닙니다. 오래된 노드는 witness 없는 거래를 보고 witness v0 프로그램을 anyone-can-spend로 취급합니다. 업데이트된 노드는 witness와 함께 서명 대상 데이터의 지문인 서명 다이제스트도 검사합니다. Coinbase 출력의 witness commitment는 witness 데이터를 블록과 암호학적으로 연결하여 완전한 검증으로 변경이나 누락을 발견하게 합니다. Weight는 블록 용량을 계산할 때 데이터에 적용하는 가중치입니다. 이를 통해 실효 용량을 늘리면서도 오래된 노드에 보이는 기본 블록은 원래의 1메가바이트 한도 안에 유지했습니다. [8]

Key-path는 출력 키에 해당하는 서명으로 지출하고, script-path는 공개하는 스크립트의 조건을 충족하여 지출합니다. Schnorr는 서명 방식이고 Tapscript는 해당 스크립트의 언어입니다. BIP341과 BIP342는 네이티브 SegWit 출력의 32바이트 witness v1 프로그램에 대해 Schnorr 서명과 Tapscript를 사용하는 이 두 지출 경로의 규칙을 정합니다. 오래된 노드는 예약된 프로그램을 anyone-can-spend로 보므로 호환성은 유지되지만 검증 범위는 같지 않습니다. Mainnet의 Speedy Trial은 수정된 BIP9, 1815/2016(90 %) 임계치, 최소 활성화 높이 709632를 사용했습니다. Taproot는 2021년 11월 14일 그 높이에서 활성화됐습니다. 규칙의 내용과 활성화 절차는 각각 따로 검토할 문제입니다. [12] [13] [16]