노드 저장 공간 절반으로 줄이기
Kaia v2.1은 어떻게 2TB의 용량을 확보했을까?
과도한 노드 운영 비용
블록체인 노드를 운영하려면 대용량의 저장 공간이 필요하죠. 체인이 자라고 트랜잭션이 누적되면서, 단순히 과거 기록을 보관하기만 해도 저장 공간 요구량이 수 테라바이트에 달합니다. 솔라나 아카이브 노드는 400TB를 소모하고, 이더리움 아카이브 노드에는 거의 14TB가 필요합니다. 최적화된 체인조차도 이 문제에서 예외가 될 수 없습니다.
저장 공간에 대한 비용은 통상 노드 운영자가 부담합니다. 우리의 RPC 서비스 제공업체 (특히 아카이브 노드 운영자) 입장에서도 이 디스크 요구 사항이 주요 운영 과제입니다. 어쨌든 블록체인 데이터는 필연적으로 계속 늘어날 수 밖에 없습니다. 문제는 저장 공간을 어떻게 관리 가능한 수준으로 유지할 것인가입니다.
Kaia는 2021년 스테이트 마이그레이션을 통해 저장 공간 문제 해결에 착수했습니다. 스테이트 마이그레이션은 운영자가 노드를 오프라인으로 전환하지 않고도 오래된 스테이트를 삭제할 수 있게 해주는 일괄 정리 기능입니다. 이후 다운타임을 줄인 효율적인 마이그레이션 프로세스가 등장했습니다. 2023년에는 StateDB 라이브 프루닝 기능이 도입되어 오래된 상태 데이터를 실시간으로 자동 삭제할 수 있게 되었습니다.
Kaia v2.1.0은 이전과는 좀 다른 접근법을 취합니다. 데이터를 삭제하는 대신 블록 데이터를 압축하여 풀 노드 저장 공간을 절반으로 줄이는 것입니다.
반복적인 블록 데이터 문제
2025년 7월 기준 Kaia 메인넷 풀 노드는 4.2TB 이상의 공간을 차지합니다. 이 공간은 다음과 같이 사용되고 있습니다:

블록 데이터(헤더, 트랜잭션 바디, 영수증)가 3.6TB 이상을 차지합니다. 이 데이터는 반드시 보관해야 합니다. 노드가 이 데이터를 이용해 과거 트랜잭션을 검증하고 쿼리에 응답하기 때문입니다.
하지만 여기서 간과한 부분이 있는데 블록 데이터가 자주 반복된다는 점입니다.
어떤 EVM 트랜잭션이든 살펴보세요. 솔리디티의 ABI 인코딩은 특정 바이트 길이를 맞추기 위해 모든 것을 0으로 채웁니다. 트랜잭션 콜 데이터는 결국 긴 0 시퀀스로 가득 차게 됩니다.

영수증(receipts) 파트도 마찬가지입니다. 이벤트 로그, 반환 값, 상태 코드 — 모두 반복적인 바이트로 가득 차 있습니다.
Kaia는 저장소 압축 기술로 Google의 LevelDB를 사용하고 있습니다. 하지만 기본적으로 활성화되어 있지 않아, 수없이 반복되는 0들이 공간을 차지한 채 그대로 남아 있었습니다.
효과적으로 압축하기
이제 Kaia v2.1은 LevelDB의 Snappy 압축을 활성화합니다. 하지만 모든 영역이 아닌 압축 효과가 높은 곳에만 선별적으로 적용합니다.
— db.leveldb.compression 플래그로 이를 제어할 수 있습니다.
0: 압축 없음
1: 영수증만 압축
2: 헤더, 본문, 영수증 (권장)
3: 상태 트라이 포함 모든 것
테스트 결과, 옵션 2의 결과가 가장 좋았습니다. 옵션 3은 상태 데이터(잔액, 컨트랙트 저장소, 암호화 해시)가 무작위의 성격을 지니기 때문에 효과면에서 가장 적었습니다. 무작위 데이터는 압축 효율이 낮기 때문입니다.

테스트에는 2024년 12월 31일자 Kairos 테스트넷 스냅샷이 사용되었습니다. 상태 마이그레이션된 풀 노드 결과, 상태 트라이(statetrie)는 압축해도 효과가 미미합니다. 즉, 그만한 CPU 자원을 추가로 소모할 만한 가치가 없다는 얘기입니다.
2TB를 절감하다
메인넷 풀 노드에서 압축과 수동 압축을 병행했고 용량 감소 효과는 상당했습니다.

저장 용량이 4,215GB에서 2,016GB로 줄었습니다. 이는 2.2TB 절감으로 약 52% 축소된 수치입니다. 특히 반복적인 바이트가 많은 바디(Body) 테이블과 영수증(Receipts) 테이블이 가장 크게 줄었습니다.
이제부터 압축은 모든 신규 데이터에 적용됩니다. 즉, v2.1.0부터는 새로운 데이터가 자동으로 압축되어 추가된다는 의미입니다. 앞으로 저장 공간은 더 더디게 늘어날 것입니다.
10시간, 그리고 높은 디스크 I/O
압축에는 비용이 따릅니다. 일단 압축 과정에서 기존 데이터 다시 기록하기 때문에 시간이 필요하죠. 메인넷 풀 노드를 압축하는데 약 10시간이 소요되었습니다. 이 기간 동안 디스크 I/O 또한 급격히 증가합니다.

디스크 처리량은 읽기 시 200MiB/s 이상, 쓰기 시 250MiB/s 이상으로 정점을 찍으며, IOPS는 초당 2,000회 이상을 빈번히 초과합니다.
그렇다고 블록 동기화가 멈추지는 않습니다. 즉, 압축으로 디스크 사용량이 많이 늘어나지만 노드는 여전히 새 블록을 처리합니다.
저장 공간을 줄이는 이유
저장 공간에 대한 요구 사항이 줄어들면 여러 이점이 있습니다. 더 많은 운영자가 노드를 운영할 수 있게 됩니다.
- 노드 운영자와 RPC 제공자의 비용이 절감됩니다
- 더 많은 사람들이 풀 노드를 운영할 수 있음
- 노드 운영 비용이 낮아지면 네트워크의 탈중앙화가 유지됩니다
- 체인 데이터 스냅샷의 크기가 줄어들므로, 신규 노드 배포 속도 향상됩니다
압축 기능 사용하기
Kaia v2.1.0은 기본적으로 옵션 2(상태 트리 제외 모든 블록 데이터)로 압축을 활성화되어 있습니다. 노드 운영자라면 다음 단계를 수행하십시오:
- (구버전에만 해당) Config 파일에 — db.leveldb.compression 2를 추가합니다.
- 노드를 재시작합니다. 새 데이터는 자동으로 압축됩니다.
- 기존 데이터는 RPC를 통해 수동으로 압축을 진행합니다: debug.chaindbCompact({ “preset”: “allbutstate” })
- 아니면 향후 제공되는 압축된 체인 데이터 스냅샷을 이용할 수도 있습니다.
압축은 스토리지 최적화 계획의 일부입니다. 압축 외에도 풀 노드에는 스테이트 프루닝 기능이 있고, 아카이브 노드에는 플랫 트리(FlatTrie) 방식의 최적화가 적용될 예정입니다. 이 모두는 노드 운영자의 비용을 절감하기 위해 설계되었습니다.
상세한 지침은 Kaia 문서의 노드 저장소 최적화 가이드를 참조하십시오.