버전 2 블록

블록 버전 번호는 예전에는 단순한 의미였습니다. 1이 원래 형식이었고, 2가 규칙을 하나 추가했으며, 새 번호가 나올 때마다 이전 형식은 채굴할 수 없게 되었습니다. 버전 2는 BIP34와 함께 도입되었고, Bitcoin Core는 블록 227,931부터 이를 강제합니다. 구매자로서 하는 일 가운데 이에 의존하는 것은 없지만, 모든 탐색기에서 이 값을 표시하며, 코인베이스 스크립트가 숫자로 시작하는 이유를 설명해 줍니다.

작동 방식

상태: 버전 필드는 2016년에 카운터 역할을 멈췄습니다. BIP9가 상위 비트를 신호용 비트필드로 재정의했기 때문에, 현대의 블록은 2, 3, 4 대신 0x20000000 같은 값을 보여 줍니다. 버전 2가 도입한 BIP34 규칙은 영구적이며 모든 블록에서 여전히 검사됩니다.

버전 2 블록은 중복 식별 문제를 해결하기 위해 존재합니다. 코인베이스 트랜잭션에는 이를 고유하게 만드는 입력이 없으므로, 우연히 같은 출력 스크립트와 같은 임의의 코인베이스 바이트를 사용한 두 채굴업자가 동일한 트랜잭션 ID를 가진 바이트 단위로 동일한 트랜잭션을 만들 수 있었습니다. 이는 가정이 아닙니다. 블록 91,842와 블록 91,880에는 각각 이전 블록의 트랜잭션과 동일한 코인베이스 트랜잭션이 들어 있었고, 나중 사본이 미사용 출력 집합의 이전 항목을 덮어써 사용 가능한 코인을 소멸시켰습니다. BIP30은 임시 조치로 중복을 전면 금지했고, BIP34는 그 가능성을 근원에서 제거했습니다.

메커니즘은 작습니다. 버전 2 블록은 코인베이스 스크립트를 블록 자체의 높이로 시작해야 하며, 그 높이는 최소 인코딩된 스크립트 숫자로 기록합니다. 두 블록이 같은 높이를 공유하지 않으므로 두 코인베이스 트랜잭션은 다시는 충돌할 수 없습니다. 배포는 특정일이 아니라 임계값 방식을 사용했습니다. 최근 블록의 절대다수가 버전 2를 담은 뒤에는 버전 1 블록이 무효가 되었고, 네트워크는 2013년 3월에 그 지점을 넘었습니다.

같은 패턴이 두 번 더 반복되었습니다. 버전 3 블록은 블록 363,725에서 엄격한 DER 서명 인코딩을 의무화했고, 버전 4 블록은 블록 388,381에서 OP_CHECKLOCKTIMEVERIFY를 도입했습니다. 그 뒤로 이 연속은 멈췄습니다. 32비트 필드를 카운터로 취급하면 31개의 비트를 낭비하게 되는데, BIP9가 이를 병렬 업그레이드 신호로 바꾸었기 때문입니다.

확인할 수 있는 곳

버전은 모든 탐색기의 블록 페이지와 getblock RPC에서 version과 versionHex 두 값으로 나타납니다. 2011년의 블록을 보면 1이 보이고, 2013년 중반의 블록을 보면 2가 보이며, 오늘의 블록을 보면 비트필드가 보입니다.

BIP34의 높이는 버전 자체보다 찾기 쉽습니다. 최근 코인베이스 스크립트를 디코딩하면 첫 바이트가 높이이고, 보통 그 뒤에 채굴 풀의 식별 텍스트와 채굴 하드웨어가 순회하는 추가 논스 공간이 이어집니다. 탐색기는 흔히 그 뒷부분을 ASCII로 표시하는데, 이것이 바로 블록의 코인베이스가 어느 풀이 채굴했는지를 드러내는 방식입니다.

버전 2 블록 vs 버전 2 트랜잭션

버전 2 블록과 버전 2 트랜잭션은 숫자만 공유하고 그 밖의 것은 공유하지 않습니다. 트랜잭션 버전 2는 BIP68에서 나오며 상대적 잠금 시간을 켭니다. 이를 통해 입력은 자신의 부모 출력이 일정 기간 지난 뒤에만 사용될 것을 요구할 수 있습니다. 라이트닝 네트워크는 채널 타임아웃을 위해 이에 의존합니다. 블록 버전 2는 BIP34에서 나오며 코인베이스의 고유성에 관한 것입니다. 대상 객체도, BIP도, 연도도 다르며, 두 카운터가 모두 2에 도달했다는 우연 외에 아무런 관계도 없습니다.