[해석서]Bitcoin: A Peer-to-Peer Electronic Cash System - 8. 지불 입증 간소화

비트코인에서 거래가 발생했을 때, 이에 대한 입증을 하려면, 원칙적으로는 거래정보를 담고 있는 모든 블록들을 가지고 있어야 합니다. 이렇게 모든 정보를 가진 노드를 풀 노드(Full Node)라고 합니다. 1번블록에 거래 A->B가,  5번 블록에 B->C가 있을 때, B->C에 대한 거래가 올바른 지를 검증하기 위해서는, B에게로의 거래였던 선행거래가 담겨있는 1번블록을 봐야하는 것입니다.

풀 노드와 달리, 블록내 거래정보가 없는 블록헤더로만 구성된 블록들을 가지고 있는 '가벼운 노드'인 라이트 노드(Light Node)들도 있습니다. 스마트 폰 등 저장 메모리를 적게 써야하는 기기들이 이런 라이트 노드들이 되는데, 이 노드들이 어떤 거래에 대한 검증을 하려면 풀 노드의 도움을 받아야 합니다, 이 때 앞 절에서 얘기했던 '머클트리'가 유용하게 쓰입니다.     

이러한 내용이 논문내 "8. 지불 입증 간소화" 부분에서 설명됩니다.

 

8. 간소화된 지불 검증

전체 네트워크 노드를 사용하지 않고도 지불에 대한 검증이 가능하다. 사용자가 가장 긴 작업증명 체인의 헤더블록에 대한 복사본을 가지고 있기만 하면 된다. 사용자는 해당 체인이 가장 길다고 확신될 때까지 네트워크 노트에 질의를 보내 그 복사본을 얻을 수 있고, 그 거래에 대한 타임스탬핑이 되어 있는 블록과 연결시키면서 머클트리의 가지를 얻을 수 있다. 이를 통해 거래에 대한 직접 검증은 할 수 없으나, 체인상에 연결해봄으로써, 네트워크 노드가 그 거래를 받아들였고, 해당 블록 다음에 다른 블록들이 추가되어 이어지고 있다는 사실로부터, 네트워크가 그 거래를 승인했다는 것을 확인할 수 있다.

 

  

   

 

블록헤더 정보만을 가지고 있는 라이트 노드가 어떻게 거래에 대한 검증을 할 수 있을까요?

예를 들어, 위 논문 내 '거래3'에 대한 검증이 필요하다고 합시다. 이 경우 라이트 노드는 풀노드에게 거래3의 검증에 필요한 정보를 요청합니다. 이 때 필요한 정보는 '해시2', '해시23', '해시01', '머클트리 루트' 입니다.

이 정보를 가지고, 라이트노드가 직접 해시를 계산해봅니다.

   해시3 = hash(거래3)

   해시23 = hash(해시2, 해시3)

   머클트리 루트 = hash(해시01, 해시23)

 

위와같이 계산했을 때 나온 머클트리 루트값이, 자신(라이트 노드)이 이미 가지고 있었던 해당 블록의 머클트리 루트값과 같다면(머클트리 루트값은 블록헤더에 있는 값), 거래3이 위조되지 않았음이 보증되는 것입니다.

 

이처럼, 거래내역을 가지고 있는 헤비한 블록들을 가지고 있지 않더라도, 블록헤더만을 가지고 있고 풀노드로부터 몇 개의 머클트리 정보만 받으면, 라이트 노드도 거래에 대한 검증을 할 수 있는 것입니다. 그렇지만, 라이트 노드에 의한 검증은 풀노드에 의한 검증보다 취약합니다. 아래 논문에서 그 내용을 얘기하고 있습니다.

이러한 검증방식은 네트워크가 정직한 노드들에 의해 통제되는 경우에는 신뢰할 수 있지만, 공격자에 의한 파워가 더 큰 경우에는 더 취약하다. 네트워크 노드들은 스스로 거래들을 검증할 수 있는 반면 간소화된 방법은, 공격자들이 네트워크를 계속 과점하고 있으면서 만들어내는 조작된 거래에 의해 농락당할 수 있다. 이를 막는 한 가지 전략은, 네트워크 노드들이 잘못된 블록을 발견했을 경고를 보내고, 이 경고를 받은 사용자의 소프트웨어는 전체 블록과 경고된 거래를 다운로드 받아 불일치를 확인하게 하는 것이다. 빈번하게 거래를 받아야하는 사업의 경우에는, 보다 독립적인 보안성과 빠른 검증을 위해서, 자체 노드를 운영하는 것을 선호할 것이다.

 

라이트 노드들은 자신이 가지고 있는 블록 정보 -블록 헤더만을 가지고 있기에 거래정보는 없음-를 가지고, 어떤 거래가 유효한 것인지 자체 검증할 수 없습니다. 풀노드의 도움을 받아야하는 것입니다. 이 경우, 네트웍들이 정직한 풀 노드들로만 구성되어 있다면 문제없습니다. 그러나, 불순한 의도를 가진 공격자가 네트웍을 과점하고 있을 때는 위험합니다. 라이트 노드가 요청한 정보에 대해 공격자가 잘못된 정보를 줄 수 있기 때문입니다.

이를 막는 방법은, 사용자들이 블록전체를 다운로드 받을 때, 블록에 대한 유효성 검사를 하고, 만약 이상한 블록이 발결되었을 경우에 모든 네트웍 노드에게(라이트 노드 포함) 그 사실을 알리게 하는 것입니다.

 

빈번한 거래를 하는 사용자의 경우는, 안전하게 모든 거래정보를 가지고 있는 풀 노드가 되어서, 거래가 이뤄질때마다 스스로 검증하는 것이 현명할 것입니다.

 

-계속-

 

[전체 목차] 1. 서론   2. 거래(1/2)   2. 거래 (2/2) 3. 타임스탬프 서버  4. 작업 증명  5. 네트워크  6. 인센티브  7. 디스크공간 회수  8. 지불 입증 간소화  9. 금액의 결합과 분할