교육 참고용이며 투자 조언이 아닙니다. 투자로 인해 손실이 발생할 수 있습니다.
직접 답변
상태 루트는 블록 처리가 끝난 뒤의 세계 상태에 대한 이더리움 블록 헤더의 32바이트 암호학적 커밋먼트입니다. 세계 상태는 주소를 계정에 대응시킵니다. 각 계정은 nonce, 잔액, 스토리지 루트, 코드 해시에 커밋하고, 각 컨트랙트의 스토리지 루트는 해당 계정의 스토리지 슬롯에 다시 커밋합니다.
루트는 다이제스트이지 다운로드 가능한 스냅샷이 아닙니다. 노드는 독립적으로 계산한 결과를 비교할 수 있고, 검증자는 신뢰할 수 있는 블록을 기준으로 계정 또는 스토리지 증명을 확인할 수 있습니다. 루트만으로는 상태를 복원하거나 상태 데이터의 가용성, 블록의 최종성, 컨트랙트의 경제적 안전성을 증명할 수 없습니다.
“상태 루트”는 프로토콜마다 의미가 다릅니다. 이더리움은 현재 수정된 Merkle-Patricia trie로 실행 레이어 상태에 커밋합니다. 다른 네트워크는 서로 다른 상태 모델, 인코딩, 해시 함수 또는 인증 데이터 구조를 사용할 수 있으므로, 명칭이 같아도 루트와 증명이 호환되는 것은 아닙니다.
작동 방식
실행 클라이언트는 부모 블록의 상태에서 시작해 현재 적용되는 프로토콜 규칙에 따라 새 블록을 검증하고 실행한 다음, 그 결과로 생긴 계정 및 스토리지 변경을 적용합니다. 개략적으로는 다음과 같습니다.
S_n = Υ(S_(n-1), B_n)
여기서 S_(n-1)은 부모 상태, B_n은 새 블록에 대해 프로토콜이 규정한 모든 처리, S_n은 결과 상태입니다. 클라이언트는 이 상태를 상태 트라이에 결정론적으로 인코딩하고 루트 해시를 계산합니다. 유효한 블록 헤더에는 같은 결과가 들어 있어야 하며, 일치하지 않으면 해당 클라이언트는 블록을 무효로 판단합니다.
이더리움 상태 트라이에서 계정 경로는 주소로부터 파생되고, 인코딩된 계정에는 nonce, 잔액, 스토리지 루트, 코드 해시가 들어갑니다. 컨트랙트 코드는 해시로 참조되며 각 컨트랙트에는 별도의 스토리지 트라이가 있습니다. 이 중첩 구조 때문에 스토리지 슬롯 하나의 변경도 컨트랙트 스토리지 루트, 인코딩된 계정, 최종적으로 전역 상태 루트를 바꿀 수 있습니다.
상태 루트는 같은 블록 헤더의 트랜잭션 루트 및 영수증 루트와 구별됩니다. 트랜잭션 루트는 순서가 있는 트랜잭션 데이터에, 영수증 루트는 실행 영수증에 커밋하며 서로 대체할 수 없습니다.
EIP-1186은 eth_getProof를 정의하며, 지정된 블록의 계정 증명과 요청한 스토리지 증명을 반환할 수 있습니다. 검증자에게는 여전히 인증된 블록 해시 또는 상태 루트, 정확한 trie 및 인코딩 규칙, 적절한 확인 또는 최종성 정책이 필요합니다.
예시
하나의 트랜잭션이 Alice에게서 Bob에게 ETH를 보낸다고 가정해 봅시다. 올바른 실행은 Alice의 nonce와 잔액, Bob의 잔액, 수수료 수령자의 잔액을 바꿀 수 있습니다. 트랜잭션이 컨트랙트를 호출하면 스토리지 슬롯과 컨트랙트의 스토리지 루트도 바뀔 수 있습니다. 대부분의 계정이 그대로여도 이러한 갱신으로 새 전역 상태 루트가 만들어집니다.
같은 부모 상태에서 시작해 같은 규칙으로 동일한 유효 블록을 처리하는 정직한 두 클라이언트는 같은 루트를 계산해야 합니다. 한 클라이언트가 잘못된 금액을 반영하거나 잘못된 trie 인코딩을 사용하면 루트가 헤더와 달라지며, 로컬 상태를 조용히 받아들이지 말고 블록을 거부해야 합니다.
세계 상태 전체를 다운로드하지 않고 Bob의 잔액을 확인하려면 블록 헤더와 계정 증명을 얻을 수 있습니다. 증명 경로를 다시 계산하면 인코딩된 계정이 헤더의 상태 루트와 일치하는지 알 수 있습니다. 선택한 헤더가 정규 체인에 있거나 최종 확정되었다는 사실까지 증명하지는 않으며, 이는 검증자의 체인 선택과 최종성 검사에서 확인해야 합니다.
위험
- 신뢰할 수 없는 루트: 공격자가 선택했거나 오래된 루트에 대한 유효한 증명은 잘못된 기준점을 입증합니다. 루트를 검증된 블록 해시, 체인 ID, 블록 번호에 결합해야 합니다.
- 재구성과 최종성: 나중에 정규 체인에서 제외되는 블록에 대해 증명이 정확할 수 있습니다. 확인 깊이 또는 최종성 기준을 애플리케이션의 손실 허용 수준에 맞춰야 합니다.
- 인코딩 오류: 주소 해싱, RLP 인코딩, nibble 경로, 내장 노드, 스토리지 키 처리는 정확한 프로토콜 규칙을 따라야 합니다. 일반 이진 Merkle 증명 라이브러리만으로는 충분하지 않습니다.
- 데이터 부재: 루트는 상태에 커밋하지만 trie 노드, 과거 상태 또는 증명 생성 서비스를 이용 가능하게 만들지는 않습니다. 프루닝된 노드는 오래된 증명을 제공하지 못할 수 있습니다.
- 과장된 보장: 루트 일치는 실행 결과 불일치를 감지하지만 컨트랙트 로직 감사, 오라클 입력 인증, RPC 엔드포인트 보안, 자산 가치 보장 또는 탈취된 키의 거래 승인을 막아 주지는 않습니다.
흔한 오해
- 상태 루트가 모든 계정 잔액을 저장한다. 인코딩된 trie에 대한 고정 크기 커밋먼트일 뿐이며, 기반 trie 데이터는 별도로 확보해야 합니다.
- 상태 루트가 같으면 두 노드의 데이터베이스도 동일하다. 프로토콜 규칙에 따른 논리적 세계 상태는 같지만 클라이언트는 이를 서로 다르게 저장, 인덱싱, 프루닝 또는 캐싱할 수 있습니다.
- 상태 루트가 다르면 잘못된 트랜잭션을 바로 알 수 있다. 최종 커밋 상태의 불일치만 보여 주며 분기가 시작된 지점은 알려 주지 않습니다. 진단하려면 실행을 추적해야 합니다.
- 유효한 계정 증명은 최종성과 안전성도 증명한다. 한 루트와의 일관성만 입증합니다. 체인 선택, 최종성, 데이터 최신성, 컨트랙트 동작, 경제적 위험은 별개의 문제입니다.
관련 주제
출처
- Ethereum Execution Specifications: Block Header - Ethereum Foundation (접근일: 2026-08-21)
- Merkle Patricia Trie - Ethereum Foundation (접근일: 2026-08-21)
- EIP-1186: RPC-Method to get Merkle Proofs - Ethereum Improvement Proposals (접근일: 2026-08-21)