이더리움 머클 패트리샤 트라이: 상태 루트가 네트워크를 증명하는 법

이더리움 블록은 계속 바뀌는 수많은 계정과 컨트랙트 값을 단 하나의 32바이트 상태 루트(State Root)에 연결합니다. 마법 같은 압축으로 보이지만, 실제로는 정교한 해시 인덱스예요. **이더리움 머클 패트리샤 트라이(Ethereum Merkle Patricia Trie)**는 잔액·논스·컨트랙트 저장값이 바뀌면 루트도 달라지게 만듭니다. 독립 검증을 가능하게 하는 블록체인 기초의 핵심 구조죠.

교육 목적이며 투자 조언이 아닙니다(NFA). 데이터 구조를 이해해도 스마트 컨트랙트·지갑·시장 위험이 사라지지는 않아요. 최신 구현과 프로토콜 문서를 직접 확인하고(DYOR), 잃어도 되는 범위의 자금만 사용하세요.

이더리움 머클 패트리샤 트라이란?

트라이(Trie)는 키의 경로를 따라가는 키-값 인덱스예요. 16진수 표지판이 붙은 창고를 떠올려 보세요. 모든 선반을 훑는 대신 주소의 숫자를 하나씩 따라가 원하는 상자를 찾습니다.

이더리움은 여기에 두 가지 아이디어를 더해요. **패트리샤 압축(Patricia Compression)**은 갈림길이 없는 긴 경로를 건너뛰어 불필요한 노드를 줄입니다. **머클 해싱(Merkle Hashing)**은 노드를 암호학적 해시로 연결해 루트가 아래의 모든 값에 의존하게 만들어요. 저장값 하나만 바뀌어도 그 경로의 해시와 최종 루트가 달라집니다.

공식 머클 패트리샤 트라이 문서는 이 구조를 결정적이고 암호학적으로 검증 가능하다고 설명해요. 같은 상태는 같은 루트를 만들고, 올바른 노드 경로는 특정 키와 값이 알려진 루트에 포함됐음을 증명할 수 있습니다.

조회 경로는 어떻게 루트에 연결되나요?

수정 머클 패트리샤 트라이는 4비트짜리 16진수 한 자리인 니블(Nibble)을 따라갑니다. 논리적 노드는 네 종류예요.

• 빈 노드(Empty): 해당 경로에 값이 없어요.
• 브랜치 노드(Branch): 최대 16개 자식 경로와 선택적 값을 가집니다.
• 확장 노드(Extension): 다음 갈림길 전까지 공통 경로를 압축해요.
• 리프 노드(Leaf): 남은 경로와 최종 값을 저장합니다.

두 계정 경로가 긴 앞부분을 공유한다고 해보죠. 일반 라딕스 트라이(Radix Trie)는 공통 숫자마다 노드를 만들 수 있습니다. 확장 노드는 급행 엘리베이터처럼 공통 구간을 한 번만 기록하고 다음 실제 갈림길로 바로 이동해요. 이후 브랜치 노드가 방향을 나누고 리프 노드에서 값에 도착합니다.

노드는 재귀 길이 접두부(RLP)로 인코딩돼요. 충분히 큰 자식 노드는 keccak256(rlp(node)) 해시로 참조하고, 짧은 노드는 직접 포함할 수 있습니다. 증명자는 리프에서 신뢰하는 루트까지 필요한 인코딩 노드만 제공해요. 검증자는 전체 데이터베이스를 받지 않고도 해시 연결을 다시 계산할 수 있습니다.

이더리움에서 만나는 네 가지 트라이

‘상태 트라이’라는 말을 넓게 쓰기도 하지만, 실행 블록 헤더는 목적이 다른 세 루트에 커밋하고 컨트랙트 계정은 별도의 중첩 트라이를 가집니다.

트라이	범위	키	값 또는 커밋 대상
상태 트라이(State Trie)	전역, 블록 실행 때 갱신	계정 주소의 해시	논스·잔액·저장소 루트·코드 해시
저장소 트라이(Storage Trie)	컨트랙트 계정마다 하나	32바이트 저장 슬롯의 해시	RLP로 인코딩한 저장값
트랜잭션 트라이	블록마다 하나	RLP 트랜잭션 인덱스	타입형 또는 레거시 트랜잭션 인코딩
영수증 트라이(Receipts Trie)	블록마다 하나	RLP 트랜잭션 인덱스	상태·누적 가스·로그 블룸·로그를 담은 영수증

실행 블록 헤더에는 stateRoot, transactionsRoot, receiptsRoot가 들어갑니다. 전역 상태 트라이에 모든 컨트랙트 변수가 계정 잔액과 나란히 들어가는 건 아니에요. 계정 레코드가 storageRoot를 담고, 이 루트가 해당 컨트랙트의 저장소 트라이 전체에 커밋합니다. 공식 이더리움 계정 문서에서 네 가지 계정 필드와 중첩 저장 구조를 확인할 수 있어요.

트랜잭션이 실행되면 무엇이 바뀌나요?

이더리움 실행 모델은 이전 상태와 유효한 트랜잭션을 받아 새 상태를 만드는 과정입니다. 이더리움 가상 머신(EVM) 문서는 이를 Y(S, T) = S'로 표현해요.

어떤 트랜잭션이 ETH를 전송하고 컨트랙트도 호출한다고 가정해 보세요. 실행 클라이언트는 발신자를 확인하고 논스를 올리며 잔액을 조정하고 컨트랙트 저장소를 바꿀 수 있습니다. 변경된 리프마다 위쪽 해시를 다시 계산해요. 완성된 전역 상태 루트가 트랜잭션 실행 후 상태의 작은 식별자가 됩니다.

검증자는 이 값을 그대로 믿지 않아요. 실행 클라이언트가 트랜잭션을 독립적으로 실행하고 계산한 루트를 블록 헤더와 비교합니다. 그래서 블록은 단순한 트랜잭션 목록이 아니에요. 실행 결과에도 커밋합니다. 다른 루트를 계산한 클라이언트는 입력·실행·상태 중 어딘가에 불일치가 있다는 사실을 발견한 셈이죠.

머클 증명이 알려주는 것과 알려주지 않는 것

신뢰할 수 있는 루트가 있다면 증명은 특정 경로에 인코딩된 값이 포함됐음을 보여줄 수 있어요. 경로가 적절히 끝난다면 비포함(Non-inclusion)도 뒷받침할 수 있습니다. 전체 이더리움 계정을 받을 필요 없이 관련 경로의 노드만 검증하면 돼요.

하지만 증명의 범위를 구분해야 합니다.

• 특정 루트에 대한 데이터 일관성을 증명할 뿐, 그 루트가 든 블록이 정식 체인인지까지 증명하지 않아요.
• 컨트랙트의 비즈니스 로직이 안전하다고 보장하지 않습니다.
• 클라이언트가 루트를 독립 검증하지 않는다면 RPC 제공자의 정직성까지 보장하지 못해요.
• 모든 풀 노드가 과거 상태 전체를 보관하게 만들지는 않습니다.

합의와 블록체인 완결성(Finality)은 어떤 루트가 받아들여진 체인에 속하는지 답합니다. 트라이 증명은 데이터가 그 루트와 일치하는지 답해요. 서로 다른 질문입니다.

풀 노드와 아카이브 노드는 왜 다른가요?

풀 실행 노드는 블록을 검증하고 최신 상태를 따라가지만 오래된 상태 데이터를 정리(Pruning)할 수 있어요. 아카이브 노드(Archive Node)는 먼 과거 블록의 계정 잔액 같은 질문에 바로 답하도록 역사적 상태를 유지합니다. 최신 노드와 클라이언트 가이드도 체인 검증과 과거 상태 보관을 구분해요. 모든 과거 상태를 즉시 조회할 수 있게 저장하지 않아도 풀 노드는 체인을 검증할 수 있습니다.

여기서 흔한 오해가 생겨요. 프로토콜의 블록 기록은 이어지지만, 모든 과거 상태를 편리하게 무작위 조회하려면 추가 저장 공간이나 재생성 과정이 필요합니다. 상태 루트는 그때의 상태를 증명하는 커밋이지, 상태 데이터 전체의 복사본은 아니에요.

현재 트라이의 한계와 다음 구조

현재의 16진 머클 패트리샤 구조는 오래 검증됐지만 복잡합니다. 경로 인코딩, RLP 규칙, 중첩된 계정 저장소 트라이, 데이터베이스 접근, 큰 증명 데이터가 구현 부담을 만들어요. 상태가 커져도 루트는 32바이트로 유지되지만 노드가 처리할 실제 데이터 부담은 늘어납니다.

이더리움 연구는 증명을 줄이고 무상태 검증(Stateless Validation)을 현실화하기 위한 대체 구조를 다뤄 왔어요. 현재 버클 트리(Verkle Tree) 로드맵이 그 방향을 설명하고, EIP-7864는 통합 이진 트리(Unified Binary Tree)를 제안합니다. 다만 로드맵과 제안 문서가 현재 실행 상태의 전환 완료를 뜻하지는 않아요. 실제 배포를 말하기 전에 최신 명세와 네트워크 업그레이드 상태를 확인해야 합니다.

자주 묻는 질문

머클 패트리샤 트라이는 머클 트리와 같은가요?

같지 않아요. 머클 해시 커밋, 경로 기반 라딕스 트라이, 패트리샤 경로 압축을 결합한 구조입니다. 기본 이진 머클 트리는 더 단순하며 같은 키 조회 구조를 자동으로 제공하지 않아요.

상태 루트에 모든 잔액이 들어 있나요?

아니요. 상태 루트는 상태 트라이에서 계산한 32바이트 커밋입니다. 특정 계정 값을 복구하고 검증하려면 기초 트라이 데이터나 유효한 증명이 필요해요.

모든 컨트랙트가 자체 트라이를 갖나요?

각 컨트랙트 계정에는 저장소 트라이에 커밋하는 저장소 루트 필드가 있어요. 빈 저장소는 프로토콜의 빈 루트를 사용합니다. 컨트랙트 바이트코드는 별도의 코드 해시로 식별해요.

모든 풀 노드가 과거 트라이를 전부 저장하나요?

아니요. 풀 노드는 체인을 검증하지만 과거 상태를 정리할 수 있습니다. 과거 상태를 직접 조회하도록 유지하는 아카이브 노드는 훨씬 많은 저장 공간이 필요해요.

이더리움은 이미 머클 패트리샤 트라이를 교체했나요?

로드맵이나 제안서만 보고 배포 완료를 추정하면 안 됩니다. 인용한 최신 이더리움 문서는 여전히 실행 상태에 머클 패트리샤 트라이를 설명해요. 미래 구조를 전제로 하기 전 최신 네트워크 명세를 확인하세요.

핵심 정리

이더리움 상태 루트가 작은 이유는 훨씬 큰 경로 기반 구조 전체에 커밋하기 때문이에요. 패트리샤 압축은 듬성듬성한 경로를 줄이고, 머클 해시는 변경을 드러내며, 상태·저장소·트랜잭션·영수증 트라이는 서로 다른 데이터를 정리합니다. 이 구조 덕분에 클라이언트는 한 데이터베이스 운영자를 절대적 진실로 믿지 않고 실행 결과를 비교하고 일부 데이터를 검증할 수 있어요.

루트는 증거이지 만능 안전 인증이 아닙니다. 체인 합의, 올바른 클라이언트 실행, 정직한 인터페이스, 안전한 스마트 컨트랙트 로직이 모두 필요해요. 각 층을 구분하고 최신 1차 문서를 확인하며 DYOR하세요. 이 글은 교육 목적이며 투자 조언이 아닙니다.