[basic] 비트코인 백서 읽기 <6> Reclaming Disk Space, Simplified Payment Verification
지난 챕터들에선 선의를 가진 참여자들이 장부를 기록하는 과정을 살펴봤습니다. 이러한 장부는 모든 노드들이 공유하게 되는데요, 기록이 오랫동안 쌓이며 용량이 커지면 노드들에게 부담이 될 겁니다.
이번 챕터에선 비트코인 블록체인에서 어떻게 거래기록이 저장되며, 이를 통해 지불이 효율적으로 이뤄지는 과정을 살펴보겠습니다.
6. Reclaming Disk Space
Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. To facilitate this without breaking the block’s hash, transactions are hashed in a Merkle Tree [7][2][5], with only the root included in the block’s hash. Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored.
새롭게 생성된 거래가 새로운 블록에 포함되고 체인에 연결됩니다. 그리고 해당 블록을 포함한 체인 뒤로는 계속해서 블록이 붙습니다. 이렇게 충분히 체인이 길어지면, 특정 거래를 뒤집긴 불가능에 가깝습니다.
그렇다면, 지불이 된 거래들(the spent transcations before)은 삭제해도 되지 않을까요?(지불이 된 거래라는 개념은 추후 설명 드리도록 하겠습니다. 여기선 ‘쓸모가 없어진 거래기록’ 정도로 해석하시면 될 것 같습니다.)
그런데 블록 해시를 만드는 데이터엔 거래 기록이 포함되어 있습니다. 이런 거래 기록을 삭제하게 되면, 블록의 해시가 변할 거고(기억나시죠? 데이터가 변하면 해시는 무작위로 변합니다.), 그럼 다음 블록도, 그 다음 블록도… 엉망진창이 될 겁니다.
블록의 해시를 깨지 않으면서, 필요가 없어진 거래 기록을 삭제할 수 있도록 비트코인은 머클트리(Merkle Tree)라는 구조를 활용합니다. 그리고 이런 시스템을 통해 블록 헤더(블록 해시를 만드는 주요 데이터의 모음)엔 모든 거래기록 대신 Root Hash(이하 ‘루트해시’)만 들어가게 됩니다.
루트해시가 만들어지는 원리를 순서대로 설명드리자면:
- 블록에 거래기록(Tx0, Tx1, Tx2, Tx3)이 있다.
- 각 거래기록은 해싱을 통해 각각의 해시값을 구한다(Tx0 → Hash0, Tx1 → Hash0…).
- 인접한 거래의 해시(Hash0, Hash1)끼리 짝을 지어 다시 해싱하여 해시값(Hash01)을 구한다.
- 해시값이 하나만 남을 때까지 반복한다.
- 이렇게 남은 최종 해시값이 루트해시가 된다.
이렇게 루트해시만 남게 되면, 루트해시를 산출하기 위해 있었던 이전 데이터들은 삭제가 되어도 문제가 되지 않습니다.
쉽게 표현하자면 만약 루트해시 값이 3이라면(실제로는 긴 문자열입니다.), 3을 구하는 과정이 1+2=3 이었든 0+3=3 이었든 상관 없다는 겁니다. 블록 해시를 구성하기 위해 쓰는 데이터는 3이라는 결과값 뿐이거든요.
A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore’s Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.
거래기록이 없는 블록(루트해시만 있는 블록)의 용량은 80bytes쯤 됩니다. 블록이 매 10분마다 만들어지는 것을 가정했을 때, 1년에 4.2MB의 저장 공간만 필요한 셈입니다.
무어의 법칙(Moore’s Law)에 따라 매 년 1.2GB의 용량 증가가 예상되므로, 용량은 문제가 되지 않을 겁니다.
7. Simplified Payment Verification
It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he’s convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it’s timestamped in. He can’t check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
아마 ‘풀 노드’, ‘라이트 노드’에 대한 얘기를 많이 들어보셨을 겁니다. 이에 대한 자세한 설명은 나중에 하는 걸로 하고, 풀 노드는 장부 구성에 필요한 모든 정보를, 라이트 노드는 그 요약본-블록 전체의 요약본인 블록헤더 사본(a copy of block headers)-을 들고 있는 노드라고 간략하게 설명할 수 있을 것 같습니다.
아시다시피 노드들은 블록체인 기록을 보유하고, 블록을 생성하고, 블록에 포함된 거래를 검증하는 역할을 수행합니다. 라이트 노드는 여기서 블록에 포함된 거래를 검증(verify payments)하는 역할만을 수행합니다.
새로운 거래가 발생하기 위해선 이전에 발생한 거래를 참조해야 합니다. 이전에 누군가가 나에게 보낸 비트코인을 내가 사용하는 것이기 때문이죠. 이를 염두해두고 라이트 노드가 거래를 검증하는 방식을 살펴보겠습니다:
- 새롭게 생성된 거래가 사용하고자 하는 이전 거래(그림의 Tx3)의 정보를 받아온다.
- 풀 노드로부터 이전 거래가 포함된 블록의 머클루트 해시를 구하는데 필요한 머클트리의 해시들(Hash2, Hash23, Hash01)을 받아온다.
- 이전 거래의 해시를 받아 온 해시들과 해싱을 반복하여 머클루트 해시까지 도달한다.
- (풀 노드의 도움으로) 계산한 머클루트의 해시와, (라이트 노드가 보유하고 있는) 블록 헤더에 있는 머클루트 해시를 비교해서 일치하면 검증을 끝낸다.
이처럼 블록 헤더만 보유하고 있는 라이트 노드가 거래를 검증하는 과정을 Simplified Payment Verification(SPV)라 부르며, 해당 기술을 통해 누구라도 용량이나 연산력에 대한 부담 없이 블록체인 유지에 기여할 수 있습니다.
As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker’s fabricated transactions for as long as the attacker can continue to overpower the network. One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user’s software to download the full block and alerted transactions to confirm the inconsistency. Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.
이처럼 라이트 노드는 SPV를 위해 풀 노드로부터 머클 트리의 정보를 받아오는데요. 만약에 그 풀 노드가 악의를 갖고 잘못된 정보를 보낸다면 어떻게 될까요? 라이트 노드는 자체적으로 거래를 검증할 수는 없기 때문에 악의를 가진 풀 노드에 의해 영향을 받을 수 있습니다.
이를 방지하기 위해, 네트워크 노드(노드의 모든 기능을 갖춘 노드)는 비정상 블록(an invalid block)을 감지할 경우 라이트 노드가 정상적인 블록 전체를 다운 받도록 하고, 문제가 생긴 거래에 대해 검증을 하도록 합니다(confirm the inconsistency).
본 챕터를 보시면서 ‘거래’라는 개념에 대해 의문이 생기셨을겁니다. 사용된 거래, 이전 거래 참조 등 뭔가 걸리는 부분이 있으실 거란 생각이 드는데요. 다음 챕터에선 이 거래가 어떻게 이뤄지는 지에 대해 살펴보겠습니다.
👈🏻 이전 게시물: <5> Network, Incentive
👉🏻 다음 게시물: <7> Combining and Splitting Value, Privacy, Calculations
저는 다음 두 채널에서 활동하고 있습니다. 언제든 편하게 와서 소통해주세요.
Treasure Hunt: https://t.me/look4treasure
고로치 같이투자 소통방: https://t.me/gachi2job1
