교육 목적으로만 제공되며 투자 조언이 아닙니다. 투자로 손실이 발생할 수 있습니다.
핵심 답변
Verkle 트리는 내부 노드에 벡터 커밋먼트를 쓰는 인증 키-값 트리입니다. 이름은 “vector commitment”와 “Merkle tree”를 합친 말입니다. 여러 값을 하나의 루트에 커밋하면서도, 일반 해시 기반 Merkle 트리와 달리 모든 형제 값을 제시하지 않고 지정 위치의 자식을 증명할 수 있습니다.
이 성질은 높은 분기 수와 여러 opening의 집계를 가능하게 해, 상태 증인을 동등한 Merkle-Patricia Trie 증인보다 작게 만듭니다. 그래도 증인에는 실행에 필요한 값과 그 값을 인증된 상태 루트에 연결하는 암호학적 근거가 들어가야 합니다.
작은 증인은 노드가 현재 상태 전체를 로컬에 보관하지 않고 블록에 제공된 증인으로 재실행하게 합니다. “무상태”는 아무도 상태를 저장하지 않거나 합의가 필요 없다는 뜻이 아닙니다. 2026-08-22 현재 Ethereum 로드맵은 테스트넷과 미완료 클라이언트 작업을 명시하며 EIP-6800은 Stagnant 상태입니다.
작동 원리
프로토콜은 결정적 키·값 인코딩, 벡터 커밋먼트 방식, 빈 노드 규칙을 정합니다. 각 내부 노드는 순서가 있는 자식 벡터에 커밋하고, 이를 위로 반복해 위치와 내용을 구속하는 루트를 만듭니다.
증명자는 각 단계의 관련 위치를 opening합니다. 여러 키의 multiproof는 opening을 집계하고 공통 경로를 재사용할 수 있습니다. 검증자는 키, 값, 경로 커밋먼트와 증명을 받아 신뢰하는 루트에 확인한 뒤 상태 전이를 실행하거나 검증합니다.
EIP-6800 설계의 32-byte 키는 31-byte stem과 1-byte suffix로 구성되고 내부 노드 너비는 256입니다. 같은 stem의 값은 증명 자료를 더 공유합니다. 이는 제안 고유의 배치입니다. 너비가 크면 경로가 짧지만 커밋·갱신·검증에 특수 타원곡선 연산과 사전 계산이 필요합니다.
예시
하나의 31-byte stem에 256개 suffix 위치가 있다고 가정합니다. 블록이 같은 stem의 값 2개를 읽으면, 증인은 독립된 Merkle 형제 해시 2세트 대신 공통 경로와 집계 opening을 쓸 수 있습니다. 그래도 두 키와 값, 증명, 프로토콜이 선택한 루트를 모두 확인해야 합니다.
값이 바뀌면 suffix 그룹 커밋먼트부터 루트까지 갱신해야 합니다. 이전 루트 증명은 이전 상태에는 맞아도 새 루트를 증명하지 않습니다. 절감량은 접근 패턴에 달렸으며 작은 증명이 대역폭, 증명 비용, 데이터 가용성을 영으로 만들지는 않습니다.
위험
구현 오류는 binding을 깨거나 정직한 증명을 거부하게 합니다. 키 유도, byte order, 위치 binding, domain separation, 곡선점 검증, scalar 변환, 빈 위치와 저장된 영의 구분을 테스트 벡터와 교차 클라이언트 시험으로 맞춰야 합니다.
작은 증명은 데이터 가용성과 liveness를 해결하지 않습니다. 제안자가 값이나 증인을 보류하면 실행할 수 없고, 루트 인증이나 finality 오류는 잘못된 이력을 받아들이게 합니다. 증명 생성도 자원 병목이나 검열 지점이 될 수 있습니다.
라이브 체인 마이그레이션은 상태 배치, 동기화, 증명 형식, 데이터베이스, Gas 회계와 과거 상태 증명 가정을 바꿉니다. 제안이나 devnet은 운영 준비의 증거가 아닙니다. 관련 타원곡선 커밋먼트는 일반적으로 post-quantum secure로 보지 않으며, 작은 크기가 모든 위협 모델에서 더 강한 보안을 뜻하지 않습니다.
흔한 오해
오해 1: Verkle 트리는 자식이 더 많은 Merkle 트리일 뿐이다
짧은 경로보다 핵심적인 차이는 모든 형제 값을 나열하지 않고 선택한 자식을 opening하는 벡터 커밋먼트입니다.
오해 2: 어떤 workload에서도 전체 증명 크기는 일정하다
opening은 작고 집계 가능하지만 증인은 접근 값, 별도 경로, metadata에 따라 커집니다.
오해 3: 무상태 검증이면 아무도 상태를 저장하지 않는다
완전한 로컬 상태 대신 증인으로 검증할 뿐이며 누군가는 상태를 보존·복원해 전달해야 합니다.
오해 4: Ethereum mainnet은 이미 Verkle 트리를 쓴다
자료는 연구·사양·테스트넷을 다루며, 사실 확인일 현재 EIP-6800은 Stagnant입니다.
관련 주제
출처
- Verkle Trees - MIT PRIMES (확인일: 2026-08-22)
- EIP-6800: Ethereum state using a unified verkle tree - Ethereum Improvement Proposals (확인일: 2026-08-22)
- Verkle tree structure - Ethereum Foundation (확인일: 2026-08-22)
- Verkle trees - Ethereum.org (확인일: 2026-08-22)