Hard Fork

안나와 파벨은 Bitcoin 규칙을 독립적으로 확인하는 컴퓨터인 Full Node를 각각 운영합니다. 안나는 더 큰 블록을 허용하는 소프트웨어를 설치하고, 파벨은 원래 한도를 유지합니다. 새 조건은 충족하지만 기존 한도를 넘는 블록이 도착합니다. 안나는 받아들이고 파벨은 거부합니다. 연결 고장이 아닙니다. 공동 기록에 무엇을 포함할 수 있는지 두 프로그램의 판단이 다른 것입니다. 이것이 Hard Fork의 실제 의미입니다. ‘업그레이드’라는 이름이 파벨의 컴퓨터에 자기 규칙을 무시하도록 만들지는 못합니다. 각각에 블록을 만드는 사람이 있고 이용자가 있다면 두 분기가 계속될 수 있습니다. 참여자들이 한 규칙으로 옮겨 가면 두 활성 네트워크가 남지 않을 수도 있습니다. [1]

오래된 노드는 비호환 블록과 그 위에 쌓인 분기를 거부합니다. 그렇다고 영원히 멈추는 것은 아닙니다. 채굴자가 기존 규칙에 따라 다른 분기를 계속 만들면 그 블록들을 받아들일 수 있습니다. 그런 후속 블록이 없으면 자신이 유효하다고 보는 마지막 블록에 머뭅니다. 중요한 것은 변경을 지지하는 사람 수가 아니라 소프트웨어의 규칙입니다. 비호환 분기를 따르려면 운영자가 의식적으로 규칙을 바꿔야 합니다. [1]

Bitcoin Cash는 2017년 8월 1일 블록 높이 478559에서 Bitcoin과 분리됐습니다. 당시 Bitcoin 노드가 받아들이는 한도보다 큰 블록을 허용하는 규칙을 채택하고 자체 체인을 이어 갔습니다. Bitcoin 노드는 BCH 규칙에서만 유효한 블록을 거부했고, BCH 노드는 자신들의 규칙에 따른 기록을 따랐습니다. 이는 같은 네트워크 안에서 Bitcoin을 업데이트로 대체한 것이 아니라 별도 네트워크를 만든 Hard Fork의 사례입니다. [3] [4]

지갑으로 받았지만 아직 쓰지 않은 금액을 생각해 보세요. Bitcoin은 이런 미사용 출력을 UTXO로 기록합니다. 과거가 같은 분기들은 이 기록을 물려받은 뒤 각자 관리합니다. 필요한 키를 직접 관리하고 두 네트워크가 모두 출력을 계속 인정한다면, 보통 양쪽에서 해당 코인을 쓸 수 있습니다. 가치가 두 배가 된다는 뜻은 아닙니다. 수요가 각기 다른 별개 자산입니다. 거래소에 맡긴 자금이라면 다른 네트워크의 코인을 받는지는 거래소의 지급 정책에도 달려 있습니다. [4] [6]

양쪽 분기에 코인이 있어도 한쪽에서만 지급하고 싶을 수 있습니다. 보호가 없으면 누군가 서명된 거래를 복사해 다른 네트워크에도 전송할 수 있고, 그곳에서도 유효할 수 있습니다. 이것이 replay 위험입니다. 해당 네트워크의 보호 기능과 지갑 지원을 확인해야 합니다. 예를 들어 서명이 포함하는 데이터를 정하는 sighash 규칙을 바꾸면 거래를 특정 체인에 묶을 수 있습니다. 주소 모양이 다르면 구분에는 도움이 되지만, 그 자체로 암호학적 재전송 방지를 제공하지는 않습니다. [3]

활성화는 새 규칙을 적용하기로 정한 시점입니다. 블록 높이는 체인에서 블록의 위치를 뜻합니다. 정해진 날짜, 블록 높이, 채굴자 신호는 업데이트를 받아들인 참여자들의 전환 시점을 맞추는 데 도움이 됩니다. 그러나 업데이트를 받아들이지 않은 노드의 소프트웨어까지 바꾸지는 못합니다. 두 규칙 집합 각각에 경제적으로 중요한 참여자가 남으면 두 체인 모두 이어질 수 있습니다. 따라서 Hard Fork 전환 계획에서는 네트워크가 갈라질 위험도 고려해야 합니다. [1]

여기서 거버넌스는 참여자들이 변경을 결정하는 방식을 뜻합니다. 티커는 BTC나 BCH 같은 자산의 거래 기호입니다. 개발자는 코드를 공개하고, 채굴자는 채굴 성능을 투입할 곳을 바꾸며, 기업은 거래 기호와 입금 정책을 선택하고, 사용자는 소프트웨어를 선택할 수 있습니다. 하지만 그런 선택만으로 다른 노드가 블록을 검사하는 규칙이 바뀌지는 않습니다. 충분한 수의 독립적인 참여자가 두 규칙 집합을 자발적으로 유지하고 가치를 인정하면 분리가 이어질 수 있습니다. 그렇다고 모든 비호환 변경이 두 개의 장기 운영 네트워크를 만드는 것은 아닙니다. 한 분기를 ‘업데이트’라고 부르는 것은 사회적인 명칭이며, 블록을 검증하는 규칙은 아닙니다. [1]

새 통화를 만들려는 의도가 없어도 네트워크는 갈라질 수 있습니다. 2013년 3월에는 일부 구형 노드가 거래 입력 수가 유난히 많은 블록을 처리하지 못했습니다. 동시에 실행되는 작업들이 같은 데이터를 바꾸지 못하도록 하는 데이터베이스 잠금의 개수 제한에 걸렸기 때문입니다. 새 버전 0.8은 다른 데이터베이스를 사용해 이 블록을 받아들였습니다. 채굴 풀 BTC Guild와 Slush는 버전 0.7로 돌아가 구형 노드도 받아들이는 분기에서 채굴했습니다. 그 분기에 더 많은 작업량이 쌓이자 새 노드들도 그쪽으로 전환했습니다. 이는 의도하지 않은 소프트웨어의 판단 차이를 해결한 일이었으며, Bitcoin Cash처럼 별도 네트워크를 장기간 유지하려는 시도는 아니었습니다. [2]

Soft Fork는 기존 규칙을 더 엄격하게 만듭니다. 따라서 새 제한을 충족하는 블록은 기존 규칙도 충족합니다. 구형 노드는 추가 제한을 직접 검사하지 않아도 그 블록을 받아들일 수 있습니다. Hard Fork에는 이런 호환성이 없습니다. 새 소프트웨어가 받아들이는 블록이 기존 규칙에는 어긋날 수 있습니다. 이를 받아들이려면 구형 노드 운영자가 소프트웨어의 규칙을 바꿔야 합니다. Soft Fork도 네트워크가 갈라지지 않는다고 보장하지는 않습니다. 채굴자가 새 제한을 위반하는 블록을 만들면 구형 노드와 새 노드가 서로 다르게 판단할 수 있습니다. [1]

기존 규칙이 받아들이는 모든 블록을 V(old), 새 규칙이 받아들이는 모든 블록을 V(new)라고 하겠습니다. 새 소프트웨어가 V(old) 밖의 블록을 하나라도 받아들이면 그 변경은 Hard Fork입니다. 즉, V(new)는 V(old)의 부분집합이 아닙니다. 유효한 범위가 넓어지는 경우도 많지만 판단 기준은 호환성입니다. 새 노드가 받아들이는 블록을 구형 노드가 거부할 수 있다면, 구형 노드는 규칙을 바꾸지 않고 새 체인을 계속 따라갈 수 없습니다. [1]

Chainwork는 한 분기의 모든 블록을 채굴하며 입증한 누적 작업량입니다. 반면 Hashrate는 채굴 계산의 속도를 나타냅니다. 노드는 자신의 규칙을 충족하는 체인들 중에서만 누적 작업량이 가장 많은 분기를 선택합니다. 어떤 블록이 규칙을 위반한다면 작업량이 더 쌓여도 받아들일 수 없습니다. 따라서 앞의 예에서 파벨은 대다수 채굴자가 그 위에 블록을 쌓고 있다는 이유만으로 너무 큰 블록을 받아들이지 않습니다. Proof of Work는 유효한 분기들 사이의 선택을 결정할 수 있지만, 노드 운영자를 대신해 규칙을 고를 수는 없습니다. [1]

먼저 네트워크, 지원 지갑, 재전송 방지를 확인하세요. 익숙한 코인 이름이나 비슷한 주소만으로는 부족합니다. 포크 코인을 받아 준다는 알 수 없는 서비스에 지갑 복구 단어인 Seed Phrase를 입력하지 마세요. 직접 운영하는 노드에서는 소프트웨어 버전, 연결된 노드, 마지막으로 받아들인 블록, 분리 지점 블록의 지문도 확인할 수 있습니다. 이 지문을 해시라고 합니다. 해당 네트워크 문서와 대조하세요. 웹 블록 탐색기는 직접 수행하는 규칙 검증을 대신하지 못합니다. [5] [6]