Nonce

Anna의 채굴 장비는 거래를 담은 새 블록을 만들려고 합니다. 블록에 관한 정보를 간결하게 모은 헤더에서 SHA-256으로 숫자 지문인 해시를 계산합니다. Bitcoin은 이 계산을 두 번 수행하므로 double-SHA-256이라고 합니다. 결과가 허용 한계값보다 크면 장비는 예를 들어 Nonce를 10에서 11로 바꾸고 다시 계산합니다. Anna가 손으로 숫자를 추측하는 것이 아니라 장비가 엄청난 횟수의 시도를 자동으로 합니다. Nonce가 커진다고 해시가 작아지거나 성공에 가까워지는 것은 아닙니다. 완전히 같은 헤더는 항상 같은 해시를 내므로 다시 계산해도 새로운 기회가 생기지 않습니다. [1] [2]

Nonce에는 4바이트, 즉 32비트가 배정됩니다. 0부터 4,294,967,295까지 양 끝을 포함해 총 4,294,967,296개의 정수를 담을 수 있으며, 이를 2^32로 나타냅니다. 사람에게는 엄청난 수이지만 전용 채굴 장비인 ASIC은 이 범위를 매우 빠르게 확인합니다. 모든 값을 시도해도 성공이 보장되지는 않습니다. 다른 헤더 데이터가 그대로라면 처음부터 다시 시작해도 이전 결과만 반복합니다. 그래서 소프트웨어는 다른 헤더도 준비해야 합니다. [1] [5]

한 가지 방법은 Extranonce를 바꾸는 것입니다. 이름이 비슷하지만 추가 헤더 필드는 아닙니다. 채굴 보상을 배정하는 블록의 첫 거래인 coinbase 거래 안에 들어 있는 데이터입니다. 이를 바꾸면 거래 식별자인 txid가 바뀌고, 이어 헤더에 저장되는 거래 전체의 지문인 Merkle root도 바뀝니다. 장비에는 새로운 입력이 생깁니다. 같은 Nonce 값을 다시 쓰더라도 이번에는 다른 헤더의 해시를 계산합니다. 새로 생긴 2^32개의 가능성 역시 블록 발견을 보장하지는 않습니다. [2] [3]

블록 탐색기에서는 어떤 블록의 Nonce는 작고 다른 블록의 값은 클 수 있습니다. 숫자만으로는 블록을 찾기 얼마나 어려웠는지, 어느 블록이 더 좋은지 알 수 없습니다. Full Node는 Bitcoin 규칙에 따라 블록과 거래를 독립적으로 검증하는 프로그램입니다. 이 프로그램은 헤더 전체를 해싱하고 유효한 target과 비교합니다. target의 압축 표현은 nBits에 저장됩니다. 중요한 것은 해시가 이 한계값보다 작거나 같다는 점이지 Nonce의 크기가 아닙니다. 노드는 거래와 나머지 블록 유효성 규칙도 검증해야 합니다. [1] [8]

거래 서명 설명에서도 nonce를 만납니다. 이때는 지출을 승인하는 비밀 키인 Private Key와 함께 서명 알고리즘이 사용하는 비밀 보조 숫자를 뜻할 수 있습니다. 전문적으로는 스칼라라고 합니다. 이 값을 서로 다른 메시지에 잘못 재사용하면 키가 노출될 수 있습니다. 채굴 Nonce는 다릅니다. 공개 값이며 같은 숫자가 다른 헤더에 나타나도 됩니다. 서명의 공개 부분도 이 비밀 보조 값과는 별개입니다. 따라서 한 용도의 규칙을 맥락 없이 다른 용도에 적용하면 안 됩니다. [9]

많은 장비가 Mining Pool에서 함께 채굴할 때 모두 같은 헤더를 계산하면 새로운 시도가 늘어나지 않습니다. 그래서 조정자는 coinbase나 Extranonce 등에 서로 다른 데이터를 배정합니다. Stratum 같은 프로토콜이 작업을 전달하며, 연결된 채굴 단위는 workers라고도 합니다. BIP23은 Nonce 범위를 지정하는 선택적 매개변수 noncerange도 설명합니다. 모든 풀이 이를 반드시 사용해야 한다는 뜻은 아니며, 풀이 블록 유효성 규칙을 바꿀 수 있다는 뜻도 아닙니다. [4] [2]

Merkle Tree는 거래의 지문을 단계적으로 결합해 하나의 공통 지문인 Merkle root를 만드는 구조입니다. Coinbase 거래의 식별자인 txid는 트리의 잎 하나로 계산에 들어갑니다. 따라서 Extranonce를 바꾸면 새로운 txid를 거쳐 새로운 Merkle root가 만들어집니다. 채굴자는 다른 거래와 이전 블록 참조를 그대로 두면서도 다른 헤더를 얻을 수 있습니다. 이미 확인된 블록을 고쳐 쓰는 것이 아니라, 아직 유효한 Proof of Work를 찾는 중인 새 블록 후보를 수정하는 것입니다. [1] [2]

소프트웨어는 허용 범위 안에서 시간 nTime을 바꾸거나 허용된 버전 비트를 바꿔 더 많은 헤더를 만들 수 있습니다. 두 번째 방법은 version rolling이라고 합니다. BIP320은 일부 nVersion 비트의 범용 사용을 제안하지만, 제안 자체가 모든 비트를 마음대로 바꿀 권한을 주지는 않습니다. 네트워크 규칙과 배정된 채굴 작업의 규칙은 계속 적용됩니다. 어떤 방법도 최종 해시가 유효한 target을 충족해야 한다는 조건을 없애지 못합니다. 새로운 BIP323은 더 많은 비트를 제안하지만 아직 Draft(초안) 상태입니다. [4] [5] [10]

기술 문서를 읽으려면 형식도 알아 두면 좋습니다. 헤더는 80바이트이며 버전, 이전 블록 해시, Merkle root, 시간, nBits, 4바이트 Nonce를 담습니다. Nonce는 uint32 타입의 부호 없는 32비트 정수입니다. 가장 낮은 자리의 바이트가 먼저 오는 little-endian 순서로 기록됩니다. Nonce만 바꾸면 헤더와 double-SHA-256 해시가 달라지지만 거래 목록은 그대로입니다. 소프트웨어에는 정확한 표현이 필요하지만, 채굴의 의미를 이해하기 위해 이를 직접 조립할 필요는 없습니다. [1]

심화 확인을 원한다면 Bitcoin Core의 getblockheader 명령에 특정 블록의 해시를 넣을 수 있습니다. 기본 상세 출력에는 nonce, bits, time 등이 나옵니다. verbose 매개변수를 false로 설정하면 정확한 80바이트 헤더가 16진수로 반환됩니다. 이 데이터로 double-SHA-256을 계산하고 숫자 결과를 유효한 target과 비교할 수 있습니다. 직접 구현할 때는 Bitcoin의 바이트 순서를 지켜야 합니다. 바이트를 잘못 뒤집으면 비교가 달라집니다. 탐색기에서 Nonce만 읽는 것은 이러한 검증을 대신하지 못합니다. [1] [6] [8]