이전 블록 헤더 해시

각 블록은 뒤를 가리키며, 앞을 가리키지 않습니다. 이 포인터가 해시 대상인 80바이트 안에 있기 때문에, 오래된 블록의 내용을 조금이라도 고치면 그 블록의 해시가 바뀌고 그 위에 쌓인 모든 블록이 깨집니다. 따라서 1년 전의 결제를 되돌리려면 대략 52,000개 블록 분량의 작업 증명을 다시 해야 합니다. 사람들이 비트코인을 불변이라고 부를 때 뜻하는 것은 데이터 삭제에 관한 어떤 규칙이 아니라 바로 이것입니다.

작동 방식

이전 블록 헤더 해시는 부모 블록의 80바이트 헤더에 SHA-256을 두 번 적용해 만들어지며, 블록이 자기 바깥의 무언가를 가리키는 유일한 참조입니다.

부모 블록의 헤더에는 그 부모의 해시가 들어 있고, 이것이 시작까지 이어지기 때문에 32바이트 필드 하나가 그 뒤의 전체 역사를 확정합니다. 체인의 끝을 검증한 노드는 그 끝으로 이어지는 체인이 내부적으로 일관된다는 것도 암묵적으로 검증한 것입니다. 지난여름에 채굴된 블록의 트랜잭션 하나를 조작하면 그 블록의 헤더 해시가 바뀌고, 그러면 자식 블록이 보관한 사본이 더 이상 일치하지 않으며, 자식 블록은 무효가 되고 그 뒤의 모든 블록도 무효가 됩니다. 손상을 복구하려면 그 블록들을 하나하나 다시 채굴해야 하며, 이는 하루에 대략 144개 블록, 1년에 52,560개 블록에 해당합니다.

제네시스 블록은 예외이며, 그럴 수밖에 없습니다. 그 앞에는 아무것도 없으므로 이 필드는 영으로 채워진 32바이트입니다.

블록 안에서 앞을 가리키는 것은 아무것도 없습니다. Bitcoin Core가 nextblockhash를 보고할 때 그것은 블록이 아니라 자체 인덱스를 읽는 것이며, 바로 그렇기 때문에 이 값은 재편성 중에 바뀔 수 있지만 이전 블록 헤더 해시는 결코 바뀌지 않습니다. 두 블록이 같은 부모를 가리키는 것도 오류가 아닙니다. 그것이 데이터의 관점에서 본 포크의 모습이며, 네트워크는 어느 한쪽 포인터를 틀렸다고 선언하는 대신 누적 작업량이 가장 많은 가지를 선호함으로써 이를 해결합니다.

확인할 수 있는 곳

이전 블록 헤더 해시는 무엇을 보고 있느냐에 따라 조금씩 다른 이름으로 나타납니다.

Bitcoin Core는 getblockheader와 getblock에서 이를 previousblockhash로 반환합니다. 블록 0의 경우에는 이름 붙일 부모가 없기 때문에 응답에서 이 필드가 아예 없습니다. 블록 탐색기는 보통 이를 Previous Block으로 표시하고 링크로 만들어 주며, 이것이 클릭으로 역사를 거슬러 올라갈 수 있는 방식입니다.

이 필드는 헤더 체인 동기화의 핵심 전체이기도 합니다. 헤더를 내려받는 노드는 헤더마다 두 가지를 확인합니다. 하나는 이 헤더가 직전 헤더를 가리키는지, 다른 하나는 그 해시가 목표값을 충족하는지입니다. 그 체인이 온전히 이어진 뒤에야 노드는 블록 본문을 요청하기 시작합니다. 라이트 지갑은 여기서 더 나아가지 않으며, 연결과 작업량만 보관하고 그 밖의 것은 두지 않습니다.

이 필드를 직접 구성해 본다면 눈으로 보는 것과 논쟁을 벌이게 될 것입니다. 헤더 안의 바이트는 해시를 보통 인용하는 순서로 기록되어 있지 않기 때문입니다.

이전 블록 헤더 해시 vs 내부 바이트 순서

이전 블록 헤더 해시는 모두가 인용하는 순서와 반대 바이트 순서로 저장되며, 이 때문에 헤더를 직접 검증하려는 거의 모든 사람이 혼란을 겪습니다. 블록 1은 부모의 해시를 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000으로 담고 있습니다. 이것은 익숙한 제네시스 해시 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f를 한 바이트씩 거꾸로 쓴 것입니다. 작업 증명이 만들어 내는 앞쪽의 0들은 원시 필드에서는 뒤쪽에 놓입니다. 둘이 눈에 띄게 일치하지 않는다고 해서 잘못된 것은 아닙니다. 바이트를 뒤집으면 일치합니다.