스토리지 최적화
카이아 블록체인이 성장함에 따라 체인 데이터를 저장하는 데 필요한 스토리지도 증가하고 있습니다. Kaia는 증가하는 스토리지 요구 사항을 관리하기 위해 두 가지 주요 기술을 구현합니다:
상태 일괄 가지치기(상태 마이그레이션)
상태 마이그레이션은 실행 중인 노드를 중단하지 않고 기존 노드에 적용할 수 있는 일괄 가지치기 기능입니다.
동기 부여
블록 상태 또는 스테이트DB는 온체인 계정과 컨트랙트를 트라이 데이터 구조에 저장합니다. 트라이 데이터 구조는 사용되지 않는 상태와 최근 상태를 모두 저장하도록 설계되어 머클 해시를 사용하여 확인할 수 있습니다. 트랜잭션이 상태 변경을 수행하면 상태 트라이가 무한정 증가합니다. 현재(2024년 8월) 카이아 메인넷 아카이브 노드 크기는 20TB가 넘고, 풀 노드도 10TB가 넘습니다.
개념
상태 마이그레이션은 새 블록을 처리하는 데 필요하지 않은 이전 블록 상태를 삭제합니다. 상태 트라이를 "이전"에서 "새"로 복사합니다. 모든 트라이 노드가 복사되는 것은 아닙니다. 선택적 블록의 상태 루트에서 도달할 수 있는 블록이 복사됩니다. 복사 후에는 이전 디렉터리가 삭제되므로 선택한 블록의 상태만 남게 됩니다.
더 자세한 기술적인 내용은 다음 블로그 글을 참조하세요: 상태 마이그레이션: 노드 스토리지 절약, 카이아 상태 마이그레이션: 블록체인 데이터를 줄이는 효율적인 방법
일괄 가지치기를 수행하는 방법은 상태 마이그레이션 가이드를 참조하세요.
상태 라이브 가지치기
상태 라이브 가지치기는 증가하는 상태 데이터베이스 크기 문제에 대한 새로운 솔루션입니다. 배치 가지치기(상태 마이그레이션)와 달리 라이브 가지치기는 노드 프로세스가 블록화되면서 오래된 상태를 조금씩 자동으로 삭제합니다.
동기 부여
블록 상태 또는 스테이트DB는 온체인 계정과 컨트랙트를 트라이 데이터 구조에 저장합니다. 트라이 데이터 구조는 사용되지 않는 상태와 최근 상태를 모두 저장하도록 설계되어 머클 해시를 사용하여 확인할 수 있습니다. 트랜잭션이 상태 변경을 수행하면 상태 트라이가 무한정 증가합니다. 현재(2025년 8월) 카이아 메인넷 아카이브 노드 크기는 20TB가 넘고, 풀 노드도 10TB가 넘습니다.
이전에는 상태 마이그레이션을 통해 최근 상태만 선택적으로 복사하고 나머지는 삭제하여 이전 상태를 삭제함으로써 이 문제를 완화했습니다. 이렇게 하면 전체 노드 크기를 5TB 미만으로 줄일 수 있습니다.
그럼에도 불구하고 상태 마이그레이션에는 단점이 있습니다. 전체 주 트라이를 통과하는 데 며칠이 걸릴 수 있는 높은 오버헤드가 발생합니다. 또한 상태 마이그레이션은 수동으로 트리거해야 합니다. 이러한 한계를 극복하기 위해 라이브 가지치기 기법이 도입되었습니다.
개념
트라이 노드가 오래되었는지 여부를 알 수 없기 때문에 트라이 가지치기가 어렵습니다. 원래 상태 트라이 구조에서 트라이 노드는 각각 다른 블록을 구성하는 여러 트라이의 일부가 될 수 있습니다. 트라이 노드(예: 계정 잔액)가 다른 값으로 업데이트되더라도 다른 부모 노드에서 여전히 필요할 수 있으므로 트라이 노드를 삭제할 수 없습니다. 이 문제를 해시 중복 문제라고 합니다.
라이브 가지치기는 동일한 콘텐츠를 가진 트라이 노드를 의도적으로 복제합니다. 라이브 가지치기에서 트라이 노드는 해시로 참조되지 않고, 그 대신 ExtHash로 참조됩니다. ExtHash는 콘텐츠의 32바이트 해시에 7바이트 직렬 인덱스를 더한 값입니다. 직 렬 인덱스는 단조롭게 증가하므로 모든 트라이 노드는 고유합니다.
Hash: 32-byte Keccak256ExtHash: 32-byte Keccak256 + 7-byte Serial index
이렇게 하면 트라이 노드의 콘텐츠가 변경될 때마다 해당 트라이 노드가 더 이상 사용되지 않는다고 가정해도 안전합니다. 머클 해시는 직렬 인덱스를 무시하는 것만으로도 동일한 방식으로 계산할 수 있으며, 합의 측면에서 비라이브 프루닝 노드와 호환됩니다.
자세한 기술적인 내용은 이 블로그 글을 참조하세요: StateDB 라이브 프루닝을 통한 블록체인 데이터 용량의 효율적인 관리.
실시간 가지치기를 활성화하는 방법은 실시간 가지치기 가이드를 참조하세요.
데이터 압축
데이터 압축은 선택한 데이터베이스 테이블에 LevelDB의 내장된 Snappy 압축 알고리즘을 적용하여 블록 데이터의 저장 크기를 줄입니다.
동기 부여
헤더, 트랜잭션 본문, 영수증으로 구성된 블록 데이터는 EVM 트랜잭션의 ABI 인코딩 표준으로 인해 매우 반복적인 바이트 시퀀스를 포함하는 경우가 많습니다. 예를 들어 솔리디티의 ABI 인코딩은 32바이트 단어 정렬을 충족하기 위해 제로 패딩을 사용하므로 트랜잭션 호출 데이터에 0이 길게 나열되는 결과를 초래합니다. 트랜잭션 영수증은 이벤트 로그와 반환 값에서 비슷한 패턴을 보입니다.
이러한 자연스러운 중복성에도 불구하고 Kaia의 기본 LevelDB 스토리지 엔진은 기본적으로 압축을 활용하지 않아 반복적인 데이터가 불필요하게 디스크 공간을 소비하게 했습니다. 2025년 7월 기준, 카이아 메인넷의 전체 노드는 4.2TB 이상의 스토리지를 차지했으며, 이 중 약 3.6TB가 압축되지 않은 블록 데이터에 할당되었습니다.
개념
Kaia v2.1.0은 데이터베이스 테이블에 선택적으로 적용하여 LevelDB의 Snappy 압축 알고리즘을 활성화합니다. db.leveldb.compression` 플래그를 사용하면 세분화된 제어가 가능합니다:
- 헤더, 본문 및 영수증 압축(높은 중복성, 상당한 비용 절감)
- 상태 테스트 데이터는 제외됨(무작위로 표시, 최소한의 압축 혜택)
기존 노드의 경우 데이터베이스 압축을 수동으로 트리거하면 압축되지 않은 오래된 데이터가 압축된 형식으로 다시 작성됩니다. 이 '하우스키핑' 프로세스는 SSTables를 병합하고, 삭제를 조정하고, 부작용으로 압축을 적용합니다.
**결과: 메인넷 전체 노드에서 총 스토리지가 약 50% 감소(약 2TB 절감)했으며, 본체와 영수증 테이블에서 대부분 증가했습니다. 이 프로세스는 약 10시간이 소요되며 일반 블록 처리와 동시에 실행할 수 있습니다.
자세한 기술적인 내용은 이 블로그 글을 참조하세요: Kaia v2.1이 압축을 통해 2TB를 회수한 방법.
압축을 활성화하는 방법은 노드 스토리지 최적화 가이드를 참조하세요.
플랫트리 상태 체계(실험적)
FlatTrie는 과거 계정 상태 저장 방식을 재구성하여 아카이브 노드 상태 데이터베이스 크기를 대폭 줄이는 실험적인 상태 저장 방식입니다.
동기 부여
아카이브 노드는 모든 블록 높이의 모든 계정에 대한 완전한 기록 상태 데이터를 보유하여 시간 여행 쿼리와 포괄적인 블록체인 분석을 가능하게 해야 합니다. 2025년 8월 현재 카이아 메인넷 아카이브 노드에는 35TB 이상의 디스크 공간이 필요하며, 이 중 31TB(89%)는 스테이트 데이터베이스가 차지합니다.
기존의 머클 패트리샤 트리(MPT) 구조는 계정 데이터(리프)와 머클 트리를 구성하는 중간 지점 노드를 모두 저장합니다. 아카이브 노드는 역사적으로 여러 블록 높이에 대해 완전한 MPT를 유지했기 때문에 계정 데이터 자체를 전달하지 않는 중간 노드가 무한정 누적되는 문제가 발생했습니다.
상태 마이그레이션](https://medium.com/klaytn/klaytn-v1-5-0-state-migration-saving-node-storage-1358d87e4a7a)(일괄 가지치기)과 상태DB 라이브 가지치기와 같은 기존 스토리지 최적화는 기본적으로 기록 데이터를 삭제해야 하므로 전체 기록을 보존해야 하는 아카이브 노드에는 적용이 불가능합니다.
개념
플랫트리는 에리곤 이더리움 클라이언트에서 채택한 실험적인 상태 저장 방식입니다. 상태 저장소를 재구성하는 기준은 다음과 같습니다:
- 플랫 키-값 테이블에 과거 계정 상태 저장(단순 주소 → 계정 데이터 매핑)
- 모든 중간 지점 노드와 함께 최신 블록의 전체 MPT만 유지 관리
- 필요한 분기 노드만 임시로 구축하여 온디맨드 방식으로 과거 머클 루트를 재구성합니다.
이 접근 방식은 전체 계정 상태 기록과 모든 블록에 대한 머클 루트를 확인할 수 있는 기능을 보존하면서 과거 중간 노드의 영구적인 저장을 제거합니다.
적응 과제: 에리곤의 구현은 이더리움의 계정 구조를 가정합니다. Kaia는 사 람이 읽을 수 있는 주소 및 여러 키 유형과 같은 고유한 기능을 지원하기 위해 다른 RLP 인코딩을 사용합니다. 통합을 위해서는 계정을 불투명한 바이트 문자열로 처리하도록 Erigon의 Merkle 해싱 모듈을 수정하고, Kaia의 멀티스레드 Trie 인터페이스와 Erigon의 싱글스레드 MDBX 데이터베이스 요구 사항을 연결하기 위해 3개의 어댑터 계층(DomainsManager, WriteBuffer, DeferredContext)을 만들어야 했습니다.
결과: 카이로스 테스트넷 실험에서 FlatTrie 아카이브 노드는 기존 아카이브 노드보다 총 스토리지 사용량이 약 75% 적었으며, 상태 데이터베이스 크기는 80% 이상 감소했습니다. 메인넷 아카이브 노드에서도 비슷한 절감 효과가 있을 것으로 예상됩니다(~35TB에서 ~10TB).
제한 사항: 실험적인 v2.1.0 구현은 블록 되돌리기(debug_setHead API), 머클 증명 생성(eth_getProof API), 상태 가지치기 기능을 지원하지 않습니다. 이러한 제한은 과거 브랜치 노드를 버리기로 한 FlatTrie의 설계 선택에서 비롯된 것입니다.
자세한 기술적 내용은 이 블로그 글을 참조하세요: 카이아의 아카이브 노드를 위한 실험적 FlatTrie.
FlatTrie를 활성화하는 방법은 노드 스토리지 최적화 가이드를 참조하세요.