비트 코인 블록 체인 헤더 이해

블록 헤더의 구성은 복잡하고 매우 결과적인 프로세스입니다. 비트 코인이 살아 숨 쉬는 유기체라면 블록 헤더는 전체 기계의 핵심입니다. 비트 코인 블록 체인의 “블록”은 10 분마다 블록에서 수백만 달러의 가치를 이동하고 결제하는 것입니다. 블록 헤더는 블록의 자금을 공증하고 합의 결정에 투표하며 궁극적으로 비트 코인 거래의 이동과 정당성을 지시하고 정의합니다.

버전 번호는 네트워크 소프트 포크 업그레이드를위한 수단을 제공합니다. 이전 블록 해시는 현재 블록을 상위 블록에 연결하여 “블록 체인”에 체인을 생성합니다. Merkle 루트는 블록의 모든 트랜잭션을 관련 헤더에 암호화 방식으로 연결합니다. 타임 스탬프는 검증 가능한 타임 스탬프 시스템 역할을하는데 이는 비트 코인 외부의 많은 애플리케이션에서 유용합니다. 인코딩 된 목표 난이도는 광부가 네트워크가 유효한 것으로 받아들이는 것을 알 수있게합니다. 마지막으로 nonce는 채굴자가 채굴 할 전용 검색 공간을 제공하여 네트워크를 발전시킵니다.

이 게시물은 비트 코인 블록 헤더에 대한 기술 참조가되기 위해 이러한 각 필드에 대한 기술 개요를 제공하는 것을 목표로합니다.

소개

비트 코인의 블록 체인은 블록으로 구성되어 있습니다. 블록 (및 트랜잭션)은 버전이 지정된 이진 데이터 구조입니다. 블록에는 트랜잭션 블록 (모든 블록의 트랜잭션이 전체적으로 존재하는)과 블록 헤더의 두 부분이 있습니다. 블록 헤더는 모든 블록 앞에 추가되는 짧고 엄격한 형식의 데이터 필드입니다. 여기에는 모두 기능이 다른 6 개의 필드가 포함되어 있으며 이러한 필드의 SHA256d 해시는 블록의 식별자 역할을합니다. 블록 헤더는이 게시물의 초점이며 계속해서 자세히 살펴볼 것입니다. 먼저 트랜잭션 블록에 대해 간단히 살펴 보겠습니다.

네트워크 참여자가 네트워크에 새 트랜잭션을 제출하면 확인되지 않은 다른 모든 트랜잭션 목록에 추가됩니다. 이 목록을 mempool 이라고합니다. 채굴자는 다음 블록에 포함될 mempool에서 확인되지 않은 트랜잭션을 선택하는 네트워크 참여자입니다. 이 다음 블록을 후보 블록 이라고합니다. 유효한 블록을 만드는 것은 광부의 책임입니다. 유효한 블록은 블록 헤더가 대상 이라고하는 비트 코인 네트워크에서 설정 한 숫자보다 작거나 같은 숫자로 해시되는 블록입니다.

광부는 목표 요구 사항을 충족하는 유효한 블록 해시를 찾기 위해 많은 수의 해시를 수행합니다. 동일한 블록 데이터에서 새 해시를 생성하기 위해 nonce 필드라는 헤더의 필드는 유효한 블록을 찾는 과정에서 고유 한 해시를 생성하기 위해 광부가 빠르게 변경되도록 전용됩니다. . 추가로 논의되는 바와 같이 nonce 필드는 변경할 수있는 4 바이트 (2³² 비트) 만 제공합니다. 따라서 검색 공간 은 2³² 비트입니다. 즉, nonce 값을 제외하고 아무것도 변경되지 않으면 블록에 대해 최대 4,294,967,296 개의 고유 해시가 생성 될 수 있습니다. 이것은 많은 검색 공간처럼 보일 수 있지만 오늘날 사용 가능한 Bitcoin ASIC 하드웨어를 고려할 때 실제로는 매우 작습니다. 예를 들어 Bitmain의 Antminer S19 Pro ASIC 채굴 기는 110 Th / s로 성능을 발휘합니다. 즉, 초당 ~ 2⁴⁶ 해시입니다. 따라서이 시스템은 nonce 필드에서 제공하는 검색 공간을 1 밀리 초 이내에 완전히 소모합니다.

검색 공간이 소진되면 채굴자는 새로운 트랜잭션 세트에서 새 블록을 만들어야합니다. 이 새로운 블록을 구성하는 것은 계산 비용이 많이 들고 대역폭 집약적 일 수 있습니다. 따라서 채굴자는 전용 4 바이트 임시 값 외부에서 검색 공간을 확장하는 방법을 찾는 인센티브가 있습니다. 검색 공간을 확장하는 방법에는 여러 가지가 있습니다. 채굴자는 (1) 사용되지 않은 버전 필드 비트, (2) 시간 필드 비트의 일부, (3) 코인베이스 트랜잭션의 스크립트 서명에 몇 가지 추가 비트를 사용할 수 있습니다. 후자는 비트 코인 프로토콜에서 공식적으로 정의 된 필드가 아니지만 일반적으로 엑스트라 노 런스라고합니다.

모든 데이터와 마찬가지로 트랜잭션은 일련의 바이트로 요약됩니다. 다른 리소스 제약으로 인해 너무 많은 바이트가 있거나 너무 “무거운”블록을 갖는 것은 바람직하지 않습니다. 두 가지 일반적인 제약 조건은 (1) 업 링크 관련 (대역폭 / 대기 시간) 및 (2) 검증 관련 (CPU가 트랜잭션을 확인할 수있는 속도)입니다. 스토리지 관련 제약은 스토리지가 다소 저렴 해지고 노드가 정리 될 수 있기 때문에 지금은 그다지 문제가되지 않습니다. 그러나 더 큰 블록은 공간이 제한된 개인이 전체 노드를 실행하는 것을 막아 네트워크 분산화를 손상시킬 수 있습니다. 또한 블록 크기 제한이 없으면 네트워크는 낮은 가치의 트랜잭션을 네트워크에 스팸으로 보내는 악의적 인 공격자의 DDoS 공격에 취약 해집니다. 이러한 문제를 해결하기 위해 블록 가중치 라고하는 블록 크기 제한에 대해 합의가 부과 한 한도가 있습니다.

광부가 블록을 채굴하는 동기는 무엇입니까? 그들은 두 가지 수익원을 가지고 있습니다 : 블록 보조금 (다음에 논의 될 것임)과 거래 수수료. 채굴자가 후보 블록에 가능한 한 많은 트랜잭션을 포함하고 블록 무게를 4MB 미만으로 유지하여 트랜잭션 수수료 수익을 극대화하는 것은 미묘한 균형입니다. 이러한 유형의 문제는 배낭 문제와 유사하며 거래 선택이 매력적인 문제가 아니라 매력적인 문제라는 것이 저자의 의견입니다.

블록 헤더에 대한 논의와 관련된 coinbase 거래 라는 특별한 유형의 거래가 있습니다. 코인베이스 거래는 모든 블록의 첫 번째 거래로 포함되며 새로운 비트 코인 (블록 보조금)을 채굴하고 채굴 자의 보상을 지급합니다. 앞서 언급했듯이 코인베이스 거래의 가단성 비트는 채굴 자의 검색 공간을 늘리기 위해 활용됩니다.

블록 헤더

이제 비트 코인 블록 헤더에 대해 논의 할 준비가되었습니다. 헤더는 80 바이트이며 각각 리틀 엔디안 형식

으로 된 6 개의 서로 다른 데이터 필드를 포함합니다.

블록 헤더와 트랜잭션 내용을 파싱하고 이해할 수 있으려면 이진수, 16 진수, 엔디안을 이해해야합니다. 이를 설명하기 위해 진행중인 하위 섹션에서 빠르게 우회합니다. 독자가 이미 이러한 개념에 익숙하다면이 섹션을 건너 뛸 수 있습니다.

해당 숫자 체계 & amp; 엔디안

2 진수, 10 진수 및 16 진수 시스템

정수는 일반적으로 10 진법이라고하는 10 진법으로 표현됩니다. 그러나 다른 염기에서도 동등하게 표현할 수 있습니다. 이러한 낮은 수준의 비트 코인 개념을 이해하는 데 유용한 두 가지 다른 숫자 체계는 이진수 (기본 2)와 16 진수 (기본 16)입니다. 밑수를 10에서 2 또는 16 (또는 해당 문제에 대한 임의의 숫자)로 변경해도 정수 값은 변경되지 않고 표현 방식 만 변경됩니다.

이진수는 밑이 2이므로 정수의 전체 범위를 표현하는 데 두 개의 값만 필요합니다. 이 값은 0과 1입니다. 예를 들어 u8 유형 숫자를 고려하면 (각 숫자는 8 비트 길이) :

십진수에 비해 얼마나 더 자세한 이진수가 있는지 확인하세요.

이진수 앞에 “ b “문자를 추가하는 것이 일반적입니다. 예를 들어, 밑이 10 인 숫자 4에 해당하는 이진수는 b0100 로 표기됩니다.

예를 들어 이진수 b0000 0001 과 같이 4 자리 숫자가 왜 사용되는지 궁금 할 것입니다. b1 이 아닌 이유는 무엇입니까? 이는 컴퓨터 메모리에서 정수에 필요한 비트 수를 미리 선택해야하기 때문입니다. 따라서 정수가 최대 b1111 1111 까지의 숫자를 나타내야 할 수 있다면, 모든 숫자를 항상 사용하지 않더라도 메모리에서 정수는 항상 8 자리를 차지해야합니다. .

이진수의 4 개의 0 사이에 공백을 추가하면 읽기가 더 쉬워 지지만 다른 의미는 없습니다.

16 진수는 16 진법이므로 전체 숫자 범위를 표현하려면 16 개의 값이 필요합니다. 이 값은 0–9 및 A — F입니다.

이 경우 십진수 시스템이 16 진수 시스템보다 더 장황합니다.

16 진수 앞에 “ 0x “문자를 추가하는 것이 일반적입니다. 예를 들어, 기본 10 자리 숫자 3,735,928,559 에 해당하는 16 진수는 0xDEADBEEF 로 작성됩니다.

또한 0xDEADBEEF 는 4 바이트 숫자입니다. 모든 두 문자는 1 바이트에 해당합니다. 0xDE 는 1 바이트, 0xAD 는 1 바이트 등입니다.

완벽 성을 위해 10 진수 3,735,928,559 이진수는 b1101 1110 1010 1101 1011 1110 1110 1111 입니다.

리틀 엔디안 vs 빅 엔디안

엔디안 개념을 맛보기 위해 영어로 ’23’이라고 말하지만 독일어로는 ‘3과 20’이라고 말합니다. 같은 숫자이고 다르게 표현됩니다. 엔디안은 유사한 개념이며 빅 엔디안은 최상위 자릿수를 먼저 정렬하고 리틀 엔디안은 최하위 자릿수를 먼저 정렬합니다. “빅 엔디안”과 “리틀 엔디안”이라는 용어는 Jonathon Swift의 Gulliver ’s Travels 책을 참조한 것입니다. 이야기에는 Big
Endian과 Little Endian의 두 그룹이있었습니다. Big Endian 그룹은 위쪽에서 알을, Little Endian 그룹은 아래쪽에서 부러졌습니다. 혼란은 계란을 깨는 방법론의이 터무니없고 사소한 차이를 뒤 따릅니다.

낮은 수준에서 엔디안은 컴퓨터 프로세서가 레지스터 (메모리)에 값을로드하는 방식과 관련이 있습니다. 즉, 바이트 순서입니다.

빅 엔디안 형식에서는 가장 중요한 바이트가 먼저 읽 힙니다. 이것이 우리가 직관적으로 숫자를 읽는 방법입니다. 빅 엔디안 16 진수 형식으로 작성된 10 진수 3,735,928,559 는 정확히 예상되는 0xDEADBEEF 입니다. 빅 엔디안 형식의 시스템에서이 숫자는 컴퓨터 메모리에 다음과 같이 바이너리로 저장됩니다 (명확성을 위해 16 진수 값도 표시됨).

또는 리틀 엔디안 형식을 사용하여 숫자를 컴퓨터 메모리에 저장할 수 있습니다. 리틀 엔디안 형식에서는 숫자의 최소 유효 바이트를 먼저 읽습니다. 이것은 숫자를 직관적으로 읽는 방식이 아닙니다 .

리틀 엔디안 형식의 시스템에서이 숫자는 컴퓨터 메모리에 다음과 같이 바이너리로 저장됩니다 (명확성을 위해 16 진수 값도 표시됨).

빅 엔디안과 리틀 엔디안 형식을 비교할 때 유일한 차이점은 바이트 순서라는 것이 분명합니다. 빅 엔디안에서 3,735,928,559 에 해당하는 16 진수는 0xDEADBEEF 입니다. 리틀 엔디안에서 16 진수는 0xefbeadde입니다. 리틀 엔디안 형식의 숫자 0xEFBEADDE 는 여전히 10 진수 아니라 10 진수 3,735,928,559 를 나타내므로 엔디안을 인식하는 것이 중요합니다.> 4,022,250,974 .

이 숫자는 모두 동일하며 다른 방식으로 표현됩니다. 대부분의 경우 시스템이나 프로그램이 빅 엔디안을 사용하는지 리틀 엔디안을 사용하는지는 중요하지 않습니다. 중요한 것은 일관성입니다 .

비트 코인 (대부분)은 리틀 엔디안 형식을 사용하며 앞으로 나아가는 것을 염두에 두는 것이 중요합니다.

블록 헤더로 돌아 가기

블록 헤더로 돌아 가기

16 진수 형식에서 일반적인 블록 헤더는 다음과 같습니다.

이 블록 헤더는 645,536 높이의 블록에서 가져온 것이며 Slushpool에서 채굴했습니다. 이 게시물 전체에서 예제로 사용됩니다.

각 필드, 해당 데이터 유형 및 매우 간단한 설명은 다음 표에 자세히 설명되어 있습니다.

마이닝 프로세스에서 블록 헤더를 사용하는 방법

고급 적으로 채굴 과정은 다음 단계로 요약됩니다.

1. 적절한 버전 번호와 현재 epoch 시간을 선택하십시오. 네트워크에서 가장 긴 체인 및 대상에있는 최신 블록의 이전 블록 해시를
검색합니다.

2. mempool에서 확인되지 않은 트랜잭션을 선택하여 후보 블록에 포함합니다.

3. 코인베이스 거래를 구축하세요.

4. 코인베이스 거래 및 선택한 거래에서 Merkle 루트를 계산합니다.

5. 이러한 값을 연결하여 차단 메시지 를 만듭니다.

6. nonce 번호를 선택하고 블록 메시지에 추가하여 전체 후보 블록 헤더를 만듭니다.

7. 블록 헤더에서 SHA256 해시 (2 회)를 수행하고 그 결과를 네트워크 대상과 비교합니다.

8. 블록 헤더 해시가 대상보다 작거나 같으면
블록이 유효하며 채굴자는 피어의 확인을 위해
네트워크에 전파합니다. 그런 다음 1 단계로 돌아가서
다음 후보 블록에서 채굴을 시작합니다.

9. 블록 헤더 해시가 목표를 충족하지 않으면 블록이 유효하지 않으며 채굴자는 6 단계로 돌아가서 nonce를 증가시키고 운을 다시 시도합니다.

이 단계는 아래 순서도에 자세히 설명되어 있습니다.

블록 헤더가 정의되고 비트 코인에서 그것이 수행하는 중요한 역할이 표현되었으므로 각 매개 변수를 더 자세히 살펴볼 수 있습니다.

버전

버전 필드는 일반적으로 int32 유형으로 해석되는 4 바이트 빅 엔디안 번호로 처리되며 채굴자가 소프트 포크 제안 및 추가 검색 공간 2¹⁶에 대한 준비 상태를 알리는 데 사용할 수있는 추가 비트를 포함합니다. .

그러한 가정하지 않는 필드의 경우 블록의 버전 번호와 관련하여 압축을 풀어야 할 것이 많습니다. 버전 번호는 광부가 네트워크 소프트 포크 업그레이드 준비 상태를 알릴 수있는 수단을 제공합니다. 채굴자가 활성화 한 소프트 포크 제안의 성공 또는 실패는 충분한 수신 블록이 준비 상태를 신호했는지 여부에 달려 있습니다. 여기서 “준비”는 광부가 제안 된 변경 사항이 포함 된 비트 코인 클라이언트 릴리스와 호환되도록 소프트웨어를 업데이트했음을 의미합니다. 소프트 포크 제안의 예는 segwit 소프트 포크입니다.

버전 필드의 가장 중요한 세 비트는 향후 가능한 메커니즘 업그레이드를 위해 예약되어 있습니다. 현재 3 개의 최상위 비트는 b001로 설정되어야합니다. 이는 빅 엔디안에서 허용되는 최소 버전 번호가 0x2000000 ( b0010 0000 0000 0000 0000 0000 0000 0000 )임을 의미합니다. 그리고 빅 엔디안의 최대 버전 번호는 0x3FFFFFF ( b0011 1111 1111 1111 1111 1111 1111 1111 )입니다.

이 게시물을 작성할 당시 버전 번호는 BIP9 사양에 따라 작동합니다. BIP9에 대해 자세히 알아보기 전에 네트워크 탄생 이후 버전 번호가 어떻게 발전했는지 살펴 보겠습니다.

블록 헤더 버전 필드의 간략한 역사

버전 1은 2009 년 제네시스 블록으로 시작되었습니다. 2012 년 9 월까지이 기간 동안 의미있는 신호가 발생하지 않았습니다.

2012 년 9 월 비트 코인 코어 v0.7.0은 버전 1 블록을 비표준으로 렌더링 한 BIP34를 도입했습니다. 구체적으로이 BIP는 두 가지 작업을 수행했습니다.

1. 광부에게 소프트 포크 제안을 수락 할 준비가되었음을 알릴 수있는 구조화 된 방법을 제공하십시오. 이는 IsSuperMajority () 라고도하는 이중 임계 값 전환 메커니즘에 의해 달성되었습니다. 95 % 규칙. 75 % 규칙은 마지막 1,000 개 블록 중 750 개가 버전 2 이상을 설정하여 준비 상태를 알리면 블록 헤더에서 버전 2를 지정하는 모든 새 블록이 소프트 포크 제안 사양을 준수해야한다고 명시합니다. 그렇지 않으면 블록이 버전 1 표준에 의해 유효하더라도 네트워크에서 거부됩니다. 이 문제가 발생한 후 95 % 규칙에 따르면 마지막 1,000 개 블록 중 950 개가 버전 2 이상이면 모든 버전 1 블록이 거부됩니다.

2.모든 버전 2 이상의 블록이 코인베이스 트랜잭션의 스크립트 서명에 첫 번째 항목으로 블록 높이를 포함하도록 요구하는 실제 소프트 포크 제안을 지정합니다.

버전 2 블록이 표준이 될 때까지 약 6 개월이 걸렸습니다. 마지막 버전 1 블록의 높이는 2013–03–24 15:49:13 GMT에 227,835 타임 스탬프가 찍혔습니다.

버전 3을 정의하는 소프트 포크 제안은 BIP66에 지정되어 있으며 2015 년 2 월 Bitcoin Core v0.10.0에 도입되었습니다. 버전 3 블록은 서명을 엄격한 DER 인코딩으로 제한합니다. 준비 상태를 알리는 방법은 BIP34를 따랐습니다.

버전 4를 정의하는 소프트 포크 제안은 BIP65에 명시되어 있으며 2015 년 11 월 Bitcoin Core v0.11.2에 도입되었습니다. 버전 4 블록은 비트 코인 스크립팅 시스템의 새로운 op 코드 인 OP_CHECKLOCKTIMEVERIFY 를 인식하여 UTXO를 일정 시간 동안 사용할 수 없게합니다.

BIP34에 지정된 IsSuperMajority () 시그널링 방법이 작동하는 동안 몇 가지 문제가있었습니다. 즉, (1) 타임 아웃 부족 및 (2) 시그널링을위한 비트가 아닌 정수 값 사용 (아래에서 자세히 설명). BIP9는이 두 가지 문제를 모두 해결했습니다.

BIP9 버전 필드 개선

BIP9는 현재 사용되는 버전 번호 동작을 정의합니다. 각 소프트 포크 제안에는 4 개의 매개 변수가 있어야합니다.

1. 구별되는 이름.

2. 뒤집었을 때 광부 준비 상태를 나타내는 버전 필드의 비트. 비트 위치의 수는 N으로 표시됩니다.

3. 선택한 비트가 의미를 얻는시기를 지정하는 시작 시간

4. 제안이 X 날짜까지 잠기지 않은 경우 실패한 것으로 간주되는 시간 초과.

필드를 특정 정수 (BIP34에서와 같이)로 설정하는 대신 버전 필드에서 단일 비트를 뒤집어 여러 제안을 한 번에 활성화 할 수 있습니다.

Rusty Russell의 “BIP9 : versionbits In a Nutshell”블로그 게시물은 버전 필드의 개발 및 중요성을 설명하는 탁월한 작업을 수행합니다. 이 게시물을 작성하고 계속해서 버전 필드를 자세히 살펴볼 것입니다. BIP9에 지정된 비트 플립이 어떻게 작동하는지 정확히 살펴 보겠습니다.

0x20000000 의 일반적인 빅 엔디안 버전 번호의 전체 32 비트 바이너리 표현은 다음과 같이 표현됩니다.

이것은 최상위 비트가 b001 이상이어야한다는 BIP9의 규칙 세트를 따릅니다.

이제 준비 비트 위치를 0 (N = 0)으로 설정하는 BIPN₀이라는 새로운 소프트 포크 제안이 있다고 가정 해 보겠습니다. 채굴자가 준비 상태를 나타 내기 위해 0ᵗʰ 비트를 1로 설정해야합니다. 빅 엔디안의 버전 번호는 0x20000001 또는

가됩니다.

이 광부는 이제 BIPN₀에 대한 준비 상태를 알 렸습니다.

이제 동시에 두 개의 추가 소프트 포크 제안이 활성화되어 있다고 가정 해 보겠습니다. BIPN₁ (N = 1) 및 BIPN₂ (N = 2). 아마도이 광부는 BIPN₁이 아닌 BIPN₀ 및 BIPN₂에만 준비되어있을 것입니다. BIP9 메커니즘에서는 이것은 문제가되지 않습니다. 광부는 0ᵗʰ 및 2ⁿᵈ 비트를 1로 설정하고 1ˢᵗ 비트를 0으로 두어 BIPN₀ 및 BIPN₂에 대한 준비 상태를 나타냅니다. 빅 엔디안의 버전 번호는 0x20000005 또는

가됩니다.

주어진 시간에 여러 소프트 포크 제안을 활성화 할 수있는 기능은이 메커니즘을 BIP34의 정수 값 사용보다 우수하게 만듭니다.

광부는이 버전 필드를 사용하여 추가 검색 공간을 확보 할 수 있습니다. 이를 버전 롤링을 통한 명백한 ASIC 부스트라고합니다. BIP9가 도입 된 후 처음에는 채굴 자들이 모든 버전 비트를 사용하여 명백한 ASIC 부스트를 수행했습니다. 그러나 이로 인해 노드가 비트를 존재하지 않는 소프트 포크 제안에 대한 신호로 해석하려고 할 때 경고를 생성했습니다. BIP320은 명백한 ASIC 부스트를 위해 16 비트를 지정하고 소프트 포크 제안 신호를 위해 13 비트를 열어 두어이 문제를 해결했습니다. 이를 통해 광부에게 2¹⁶의 검색 공간이 제공되고 동시에 13 개의 소프트 포크 제안을위한 공간이 남습니다.

이전 블록 해시

이전 블록 해시 필드는 이전 블록의 해시 인 char [32] 유형으로 해석되는 리틀 엔디안 형식의 32 바이트 값입니다. 이 필드는 네트워크의 현재 블록과 이전 블록 사이의 링크를 제공합니다.

머클 루트

Merkle 루트 필드는 char [32] 유형으로 해석되는 리틀 엔디안 형식의 32 바이트 값입니다. 머클 트리 구조는 컴퓨터 과학 분야에서 다양한 목적으로 사용됩니다. 비트 코인에서 머클 트리는 트랜잭션 블록에있는 각 트랜잭션을 간결한 32 바이트의 블록 헤더에 암호화 방식으로 연결하는 데 사용됩니다.

각 트랜잭션은 Merkle 트리의 잎입니다. 트랜잭션은 토폴로지 순서로 포함되어야합니다. 즉, txₙ₊₁이 txₙ의 출력을 소비 할 때, txₙ₊₁은 블록에서 txₙ보다 나중 위치로 정렬되어야합니다. Merkle 트리의 맨 처음 잎입니다. 이 첫 번째 리프 인 tx₀은 코인베이스 트랜잭션 용으로 예약되어 있습니다.

머클 루트 찾기

광부가 후보 블록에 포함 할 트랜잭션을 선택하면
다음 단계를 수행하여 Merkle 루트를 도출합니다.

1. 두 쌍으로, 각 트랜잭션 ID (트랜잭션의 SHA256d 해시)가 함께 연결됩니다.

2. 연결된 트랜잭션 쌍은 SHA256d 해싱 알고리즘을 통해 해시됩니다. 이 해시의 다이제스트는 트리에서 새 분기가됩니다.

3. 다시, 두 쌍의 다이제스트가 함께 연결되고 SHA256d 알고리즘을 통해 해시되어 트리에서 새 분기를 생성합니다.

3 단계는 블록 헤더에 저장된 값인 Merkle 루트 해시가 하나만 남을 때까지 반복됩니다.

시간

시간 필드는 현재 블록의 에포크 타임 스탬프 인 uint32 유형으로 해석되는 리틀 엔디안 형식의 4 바이트 값입니다. 타임 스탬프의 역할은 네트워크가 블록이 확인되는 속도를 결정하는 수단을 제공하여 2,016 블록 (약 2 주)마다 난이도를 조정할 수 있도록하는 것입니다. 합의 규칙은 허용되는 타임 스탬프 값의 범위를 약 3 시간 범위로 제한하여 추가 검색 공간에 사용할 수있는 2¹³ 비트를 남겨 둡니다.

유효한 타임 스탬프는 이전 11 개 블록의 중간 타임 스탬프보다 커야합니다. 블록 당 10 분의 확인 률에서 후보 블록 제출 시간으로부터 1 시간입니다. 타임 스탬프는 네트워크 조정 시간에 2 시간을 더한 값보다 작아야합니다. 이 3 시간 창은 10,800 초로, 2¹³의 추가 검색 공간을 제공합니다.

네트워크 조정 시간은 노드 로컬 UTC에 연결된 모든 노드의 중앙 오프셋을 더한 값입니다. 네트워크 시간은 로컬 시스템 시간에서 70 분 이상 조정되지 않습니다.

건전한 분산 네트워크의 블록 헤더에 타임 스탬프 필드를 포함하는 의도하지 않았지만 유용한 결과는 비트 코인 블록 체인이 효과적인 타임 스탬프 도구로 사용될 수 있다는 것입니다.

비트

비트 필드는 소형 4 바이트 필드에서 현재 대상 임계 값을 인코딩하는 int32 유형으로 해석되는 리틀 엔디안 형식의 4 바이트 값입니다. 네트워크에서 유효한 솔루션으로 간주 되려면 결과 블록 해시가 대상 아래에 있어야합니다. 타겟은 2,016 블록 (약 2 주)마다 업데이트되므로 2,016 블록 시간 프레임 동안 제출 된 모든 블록 헤더는 헤더에 인코딩 된 동일한 타겟 값을 갖게됩니다.

아시다시피 블록 해시를 찾기 위해 블록 헤더 데이터 필드 (버전, 이전 블록 해시, Merkle 루트, 대상, 시간 및 임시 값)가 모두 연결되고 SHA256d 해싱 작업을 통해 함께 해시됩니다. 결과 해시는 후보 블록의 헤더 해시이며이 블록의 고유 식별자 역할을합니다. 유효한 것으로 간주 되려면 해시는 채굴자가 유효한 블록을 채굴하는 것이 얼마나 쉬운 지 또는 어려운지를 반영하는 현재 네트워크 대상보다 작거나 같아야합니다. 타겟이 없으면 유효한 블록을 쉽게 생성 할 수 있으며 네트워크가 분리되어 무너집니다.

SHA256d 해시에 의해 생성되는 최대 타겟은
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 또는 10 진수 인 26,959,946,667,150,639,794,667,015,087,019,630,673,637,019,630.673,637,144,422. 이것은 매우 큰 숫자입니다. 비트 코인은 대상을 부동 소수점 유형으로 저장하므로 사용되는 잘린 형식은 0x00000000FFFF0000000000000000000000000000000000000000000000000000 입니다. 여전히 엄청난 숫자입니다.

이 큰 숫자를 4 바이트 공간에 맞추기 위해 압축 형식을 사용합니다. 이 형식은 바이트 공간의 세분성을 희생합니다. 다음 단계는 비트 값에서 대상을 검색하는 방법을 자세히 설명합니다.

1. 블록 헤더의 리틀 엔디안 형식에서 엔디안을 빅 엔디안, 0x2F931D1A → 0x1A1D932F 로 바꿉니다. 궁극적으로 모든 것이 일관성을 유지하는 한 사용 된 엔디안은 중요하지 않습니다.

2. 첫 번째 바이트 0x1A 를 나머지 바이트 0x1D932F 에서 분리합니다. 이 첫 번째 바이트를 가수 ( 유효 값 이라고도 함)라고합니다. 가수는 유효 자릿수를 나타내는 부동 소수점 숫자의 일부입니다. 그런 다음 밑 수가 2 인 밑수를 곱한 다음 지수로 올려 숫자 값을 제공합니다.

따라서 대상 임계 값은 다음을 통해 비트 필드에서 추출됩니다.

이 방정식을 사용하여이 블록의 목표 임계 값은 다음과 같이 구합니다.

위 방정식에서 지수와 가수 길이의 차이에 8을 곱합니다. 이것은 1 바이트에 8 비트가 있다는 사실을 활용하는 약간의 지름길입니다. 따라서 각 매개 변수를 바이너리로 작성하는 대신 (훨씬 더 장황하게) 각 바이트를 전체로 가져옵니다.

3. 이제 2 단계의 결과를 헤더 해시와 비교할 수 있습니다. 헤더 해시가 목표 임계 값 이하이면 비트 코인 합의 규칙을 충족하고 체인에서 확인할 수 있습니다.

동등한 10 진수 형식으로 숫자를 쓰는 것은 다음과 같습니다.

따라서 헤더 해시 값이 대상보다 작으므로 유효한 헤더입니다.

이 공식이 선택된 이유와 작동 방식에 대해 좀 더 자세히 살펴 보겠습니다. 형식 자체는 컴퓨터가 부동 소수점 숫자를 저장하는 방법을 자세히 설명하는 부동 소수점 산술을위한 IEEE 754 표준에서 비롯되었습니다.

숫자 11을 포함하는 16 비트 레지스터를 고려하십시오.

16 비트 레지스터에는 16 비트를위한 공간 만 있습니다. 사용 가능한 비트 수 (16)만큼 비트를 이동하면 오버플로가 발생하고 수 11이 손실됩니다.

이를 방지하기 위해 사용 가능한 비트에서 유지하려는 비트 수를 뺀만큼만 이동할 수 있습니다. 이 경우에는 16 – 4 = 12 가됩니다.

그래서 목표를 계산할 때 지수에서 바이트 수를 빼는 것입니다. 지수가 오버플로를 일으키고 가수의 유효 자릿수를 잃게되는 경계 사례를 방지하기 위해

없음

nonce 필드는 현재 블록의 새 해시를 생성하기 위해 증가하는 int32 유형으로 해석되는 리틀 엔디안 형식의 4 바이트 값입니다. 표적. 2³² 비트의 검색 공간을 제공합니다.

nonce 매개 변수는 유효한 블록을 찾는 데 필수적인 역할을합니다. nonce가 없으면 채굴자가 네트워크 난이도를 충족하지 않는 블록을 구성 할 때마다 트랜잭션 세트를 수정하고, Merkle 루트를 다시 계산하고, 블록 헤더를 다시 빌드하고, 다시 해시해야합니다. 이를 위해서는 무시할 수없는 양의 계산 작업이 필요합니다. nonce는 채굴자가 블록 헤더 후보를 한 번만 구성하면되므로 nonce를 제외한 모든 변수를 일정하게 유지합니다. 채굴자는 nonce를 증가시킨 다음 (1) 블록 헤더 해시가 난이도 목표 (유효한 블록 헤더를 찾았 음)를 충족하거나 (2) 블록이 부실 (경쟁 채굴자가 유효한 블록 헤더를 찾았거나) 또는 (3)
검색 공간이 부족합니다.

Coinbase 거래

Coinbase 거래는 모든 비트 코인 블록에서 특별한 유형의 거래입니다. 기존 UTXO를 가리 키지 않고 대신 비트 코인 프로토콜 통화 정책에 따라 새로운 비트 코인을 발행하는 유일한 거래입니다.

코인베이스 거래는 (1) 새로운 UTXO 채굴을 담당하고, (2) 채굴 자에게 추가 검색 공간을 제공하고, (3) 채굴 자에게 수단을 제공합니다. 블록을 자신의 것으로 태그 지정합니다.

645,536 블록에 대한 코인베이스 거래는 다음과 같습니다 :

각 필드, 해당 데이터 유형 및 매우 간단한 설명은 다음 표에 자세히 설명되어 있습니다.

이 게시물의 목적 상 스크립트 서명은 광부가 추가 검색 공간을 확보하고 광부가 식별자를 입력 할 수있는 위치이기 때문에 중요한 필드입니다.

스크립트 서명 (스크립트 잠금 해제)

잠금 해제 스크립트 라고도하는 스크립트 서명 은 합의에 의해 제한되는 가변 바이트 길이입니다. 일반적으로 잠금 해제 스크립트에는 이전 트랜잭션의 UTXO 사용을 허용하는 조건이 포함되어 있습니다. 그러나 코인베이스 거래에서는 소비되는 UTXO가 없으며 새로운 UTXO 만 발행됩니다. 대신 스크립트 서명에는 블록 높이 (BIP34에 지정된대로)와 채굴자가 여기에 입력하기로 선택한 기타 정보가 포함됩니다. 매우 일반적으로 여기에는 광부가 선택적으로 포함 할 수있는 모든 외부 매개 변수 및 식별 "서명"이 포함됩니다.

extranonce 매개 변수는 비트 코인 프로토콜에 의해 정의 된 엄격한 필드가 아니라 채굴자가 검색 공간을 늘리기 위해 선택적으로 사용할 수있는 일부 비트입니다. 많은 풀이 extranonce 매개 변수를 지원하고 길이에 제한을 둡니다. 8 바이트 이상을 보는 것이 일반적입니다.

스크립트 서명을 분석하면 처음 1 ~ 9 바이트는 가변적 인 잠금 해제 스크립트의 길이를 나타냅니다. 이 경우 길이는 0x4B (10 진수 75 ) 바이트입니다.

다음 바이트는 코인베이스 거래의 다음 부분의 길이를 나타냅니다. 이 경우 0x03 은 다음 3 바이트 인 0xA0D909 가 중요 함을 나타냅니다. 이 바이트는 BIP34에 따른 리틀 엔디안 16 진수 형식의 블록 높이 645,536입니다. 다음 64 바이트에는 여분의 매개 변수와 광부가 선택하는 기타 정보가 포함됩니다. extranonce 매개 변수의 크기는 일반적으로 풀마다 다릅니다.

마지막으로 마지막 7 바이트 인 0x2F736C7573682F 는 Slushpool이 블록에 사용하는 선택적 식별자 인 / slush / 입니다. 이 식별자를 제공함으로써 Slush는이 블록이 자신의 풀에서 나왔다는 것을 공개적으로 알립니다.

물론 모든 엔티티는이 동일한 텍스트를 코인베이스 트랜잭션에 넣고 Slushpool (또는 다른 채굴 자) 인 척할 수 있습니다. 반대로 Slush (또는 다른 채굴 자)는 코인베이스 스크립트 서명에서 일반적인 식별자를 제외하고 익명으로 블록을 채굴 할 수 있습니다.

이 식별자는 광부가 디자인 된 문자를 입력 할 때 선택 사항입니다. 그들 대부분은 일반적으로 자신이 채굴 블록임을 나타 내기 위해 이름을 입력하지만 (마케팅 관점에서 풀이 얼마나 성공적인지 보여주기 위해 의미가 있음) 채굴자는 원하는 것을 넣거나 비워 둘 수 있습니다. 코인베이스 트랜잭션의 스크립트 서명에 식별자를 포함하는 채굴 자 수를 파악하기 위해 블록의 77.7 %가 2020 년 9 월 25 일부터 2020 년 9 월 28 일까지 4 일 동안 식별자를 포함했습니다.

결론

블록 헤더를 이해하는 것은 채굴과 비트 코인을 전체적으로 이해하는 데 필수적입니다. 블록 헤더는 비트 코인 프로토콜에서 많은 중요한 역할을하며, 6 개 필드 각각이 함께 작동하여 네트워크의 백본을 형성합니다.

블록 헤더는 블록의 모든 트랜잭션이 Merkle 루트를 통해 함께 연결되고 해당 블록을 이전 블록 해시가있는 상위 블록에 추가로 연결하여 체인을 생성하는 방법입니다. 버전 번호는 채굴자가 프로토콜 업그레이드 지원 및 준비 신호를 위해 사용합니다.인코딩 된 타겟 난이도를 통해 채굴자는 네트워크가 유효한 것으로 받아 들일 수있는 것을 알 수 있으며 nonce는 유효한 해시를위한 전용 검색 공간을 제공합니다.

블록 헤더는 단순성면에서 탁월하지만 애플리케이션과 사용 사례로 가득합니다. 그 형식은 현재 10 년 이상 유지되었지만 네트워크가 변화하고 성장함에 따라 적응할 수있을만큼 유연합니다. 버전 필드에 정의 된 소프트 포크 업그레이드 메커니즘에서 볼 수 있듯이 필드 작동 방식은 더 나은 방향으로 변경 될 수 있습니다. 채굴자가 버전, 타임 스탬프 및 코인베이스 트랜잭션을 통해 더 많은 검색 공간을 수용하기 위해 비 전통적 필드를 사용하는 방법에서 볼 수 있듯이 필드 사용 방법도 변경됩니다. 블록 헤더 및 관련 필드를 활용하여 더 많은 것을 달성하고 새로운 사용 사례를 가능하게하는 비트 코인 개발자 및 사용자의 창의성은 놀랍고, 다음 10 년의 혁신이 우리에게 가져다주는 것을 기대할 수 없습니다. 그러나 그것이 무엇이든, 우리는 블록 헤더가이 아름다운 시스템의 중추가 될 것이라고 확신합니다.

957560.1.0

특별 감사합니다

모든 피드백과 도움을 주신 Amanda Fabiano, Juri Bulovic, Brian Wright, Val Wallace, Carl Dong, Rusty Russell, Sam Abbassi, Mark (Murch) Erhardt, Nicole Dodes에게 특별한 감사를드립니다.