머클 트리 (Merkle Tree)

2026-05-11T00:00:00+00:00

블록체인 L1 레이어에선 블록이 정상적인지 판별하기 위해 머클 트리를 이용해서 만든 트랜잭션 해시값을 대조한다.

위와 같이 각 트랜잭션들의 해시를 트리 형태로 합해서(H(L1 | L2)) 머클 루트를 만든다. 해시 특성상 1 바이트라도 바뀌면 트리 전체가 무너지기 때문에 정합성을 검증할 수 있다. 머클 트리 자체의 방식은 이게 끝이다. 설명할게 따로 없다. 그냥 해시 이어붙여서 또 해시하기, 그걸 올리기다.

중요한 부분은 이게 실제 블록체인에서 어떻게 사용되는지이다. 보통 일반적으로 블록의 형태는 다음과 같다.

type</span> Hash</span> =</span> [</span>u8</span>;</span> 32</span>]</span>;</span></span>
</span>
struct</span> BlockHeader</span> {</span></span>
    version</span>:</span> u32</span>,</span></span>
    prev_block_hash</span>:</span> Hash</span>,</span></span>
    merkle_root</span>:</span> Hash</span>,</span></span>
    timestamp</span>:</span> u64</span>,</span></span>
}</span></span>
</span>
struct</span> Block</span> {</span></span>
    header</span>:</span> BlockHeader</span>,</span></span>
    transactions</span>:</span> Vec</span><</span>Transaction</span>></span>,</span></span>
}</span></span></code></pre>블록체인이 머클 루트를 쓰는 시점#</a>
</h2>
크게 세 군데가 있는데,</p>


블록 생성: 블록 생성자(PoW면 마이너, PoS면 프로포저)는 멤풀에서 트랜잭션을 골라 머클 트리를 계산하고, 그 루트를 merkle_root</code>에 박는다. 이 시점부터 본문은 사실상 동결이다. 트랜잭션 하나만 바꿔도 루트가 바뀌고, 그 위에서 진행한 봉인 작업(PoW 해싱이든 PoS 서명이든)이 전부 무효가 된다.</p>
</li>

블록 검증: 풀노드는 본문 트랜잭션 전부로 머클 루트를 재계산해서 헤더의 merkle_root</code>와 대조한다. 일치하지 않으면 거부 처리된다. 트랜잭션 위변조나 누락은 여기서 잡힌다.</p>
</li>

풀노드 없이 검증할 때 (라이트 클라이언트): 32바이트 해시 하나가 본문 전체를 대표하니까, 헤더만 따라가도 체인 상태를 검증할 수 있다. 본문(MB 단위)은 필요할 때만 받는다. 모바일 지갑이 이 방식으로 동작한다.</p>
</li>
</ol>
그럼 라이트 클라이언트는 내 트랜잭션이 이 블록에 진짜 들어있다는 걸 어떻게 검증할까. 여기서 머클 증명이 나온다.</p>
머클 증명 (Merkle Proof)#</a>
</h2>
트리에서 잎부터 루트까지 올라가는 경로의 형제(sibling) 해시만 있으면 된다. 트랜잭션이 N개일 때 필요한 해시는 log₂(N)개이다.</p>
Tx1~Tx4 네 트랜잭션이 잎으로 있는 트리(L1 = hash(H1|H2)</code>, L2 = hash(H3|H4)</code>, root = hash(L1|L2)</code>)에서 Tx3이 들어있다는 걸 증명한다고 치자.</p>

클라이언특 가지고 있는 것: Tx3</li>
밸리데이터가 줘야 할 것: H4, L1</li>
검증:

H3 = hash(Tx3)</li>
L2' = hash(H3 | H4)</li>
root' = hash(L1 | L2')</li>
root'가 헤더의 merkle_root</code>와 같으면 끝</li>
</ol>
</li>
</ul>
이게 끝이다. 별 거 없어 보이지만 이 검증 단계 개수에 머클 증명의 효율성이 다 들어있다.</p>
트리 구조는 한 층 올라갈 때마다 노드 수가 절반이 되니까, 잎이 N개라면 루트까지 깊이는 log₂(N)이고, 각 층에서 형제 해시 하나씩만 받으면 위로 합쳐 올라갈 수 있다. 필요한 해시 개수도 결국 log₂(N)개가 된다.</p>
숫자로 보면 얼추 감이 잡히는데,</p>

트랜잭션 4개 → 해시 2개</strong></li>
트랜잭션 1,024개 → 해시 10개</strong></li>
트랜잭션 100만 개 → 해시 20개</strong></li>
트랜잭션 10억 개 → 해시 30개</strong></li>
</ul>
가 된다. 본문은 O(N)으로 늘어나는데 증명은 O(log N)로만 자란다. 트랜잭션을 1000배로 늘려도 해시는 10개 더 받으면 끝인 것이다.</p>
enum</span> Direction</span> {</span></span>
    Left</span>,</span></span>
    Right</span>,</span></span>
}</span></span>
</span>
struct</span> MerkleProof</span> {</span></span>
    leaf</span>:</span> Hash</span>,</span></span>
    siblings</span>:</span> Vec</span><</span>(</span>Hash</span>,</span> Direction</span>)</span>></span>,</span></span>
}</span></span>
</span>
fn</span> verify</span>(</span>proof</span>:</span> &</span>MerkleProof</span>,</span> root</span>:</span> &</span>Hash</span>)</span> -></span> bool</span> {</span></span>
    let</span> mut</span> acc</span> =</span> proof</span>.</span>leaf</span>;</span></span>
    for</span> (</span>sibling</span>,</span> dir</span>)</span> in</span> &</span>proof</span>.</span>siblings </span>{</span></span>
        acc</span> =</span> match</span> dir</span> {</span></span>
            Direction</span>::</span>Left</span>  =></span> hash_pair</span>(</span>sibling</span>,</span> &</span>acc</span>)</span>,</span></span>
            Direction</span>::</span>Right</span> =></span> hash_pair</span>(</span>&</span>acc</span>,</span> sibling</span>)</span>,</span></span>
        }</span>;</span></span>
    }</span></span>
    &</span>acc</span> ==</span> root</span></span>
}</span></span></code></pre>
방향이 필요한 이유는 hash(A|B) ≠ hash(B|A)</code>이기 때문이다. (문자열을 앞뒤로 단순히 붙이기 때문) 형제가 왼쪽인지 오른쪽인지 모르면 다른 루트가 나온다.</p>
이 구조의 안전성은 결국 해시 함수의 충돌 저항성에 기대는데 공격자가 hash(X | H4) = hash(H3 | H4)</code>인 가짜 X</code>를 만들 수 있다면 변조가 가능하겠지만.. SHA-256 같은 함수에선 확률적으로 불가능하다.</p>
다른 곳에서도 쓰인다#</a>
</h2>
해시 트리 자체는 블록체인 전용 자료구조가 아니라서 곳곳에 박혀있다.</p>

Git: 객체 저장소가 머클 DAG다. 커밋 해시 하나가 트리 전체를 대표한다.</li>
Certificate Transparency: TLS 인증서 발급 로그</li>
이더리움: 상태(state)까지 머클로 박는 Merkle Patricia Trie를 쓴다</li>
ZK 시스템: 상태 커밋먼트로 머클 루트 사용</li>
</ul>
내부 구조 까보면 해시 묶어서 트리 쌓고 루트만 들고 다니기가 전부인데 의외로 응용 폭이 넓은 자료구조다.</p>

위 과정 반복</li> </ol> 이건 모든 노드들이 '착하다' 라는 전제이다. 만약 악의적인 노드가 있다고 하고, 해당 노드가 리더가 되면 잘못된 로그를 줘서 시스템을 붕괴시킬 수도 있다. 위의 예시들은 내부 시스템에서 사용하고 있기 때문에 (물론 요새 Zero-Trust로 얼추 방어한다) 이런 경우가 많지 않겠지만, 블록체인은 다르다. 누구나 참여할 수 있기 때문에 악의적인 노드가 있을 확률이 존재한다. 이를 해결하기 위해 고안된 것이 비잔틴 장애 허용(Byzantine Fault Tolerance, BFT) 알고리즘이다. 비잔틴 장애 허용 알고리즘#</a> </h2> 알고리즘을 알기 전 배경적으로 알아야 할 딜레마적 개념이 있는데, 비잔틴 장군 문제이다. 배경은 이렇다: 비잔틴 제국의 장군들이 적의 도시를 포위하고 있다. 해당 전투에서 이기려면 양자택일을 해야한다: 모든 장군이 전부 공격하거나, 모든 장군이 전부 후퇴하거나 현실적인 제약은 다음과 같다: - 장군들끼리는 전령을 통해서만 소통 가능하다. - 장군들 중에서 배신자가 몇몇 섞여있다. 예를 들어, 이런식으로: 몇몇 장군들에게는 후퇴하라고하고 몇몇 장군들에게는 공격하라고 한다. 이 상황에서 어떻게 배신자들을 뚫고 승리할 수 있을까?</code></pre> 위 내용을 해결하기 위한 여러 합의 이론들이 존재한다. 크게 두가지로 나눌 수 있는데 PoW: 연산력 기반 합의 (메세지에 이어진 체인이 가장 긴 게 진실로 합의됨)</li> BFT: 메세지들 던지면 2/3 노드들이 검증 후 메세지를 합의함</li> </ul> 와 같이 나눌 수 있다. 여기까지가 백서 내용이다. 백서 자체도 장황하지만.. 분산 시스템이 다 그렇듯 엣지케이스 처리를 엄청나게 해줘야 하기 때문에 구현체 내부 동작도 중요하다. 현재 공부중인 내용이라 부족한 부분이 존재할 수 있다. 여러가지 엣지케이스가 생각나는데, 다음 글에서 어떻게 핸들링하는지 알아보도록 하겠다.

CWLog - blockchain

머클 트리 (Merkle Tree)

Consensus Engine (합의 엔진) 이해하기