비트코인(BTC) 코어의 선택적 트랜잭션 인덱스인 txindex 저장 구조가 바뀌면서 재구축된 인덱스 용량이 약 66GB에서 26GB로 줄어든 것으로 나타났다. 업그레이드만으로 기존 노드의 디스크 사용량이 자동으로 줄어드는 것은 아니다.
비트코인 코어 PR #35531은 txid 전체 32바이트를 키로 쓰던 기존 방식을 5바이트 salted SipHash 프리픽스와 6바이트 압축 위치 정보로 바꾸는 내용을 담았다. 해당 변경은 마스터 브랜치에 병합됐고, 비트코인 옵테크(Bitcoin Optech)는 21일 뉴스레터에서 완전히 다시 만든 인덱스 기준으로 용량과 인덱싱 시간이 줄었다고 설명했다.
txindex는 비트코인 코어에서 -txindex=1 옵션을 켰을 때 작동하는 LevelDB 기반 선택 인덱스다. 모든 과거 트랜잭션을 바로 찾는 데 쓰이며, getrawtransaction 계열 조회와 연결된다. 비트코인 코어 파일 문서는 이 인덱스의 저장 위치를 indexes/txindex/로 분류한다.
이번 변경의 핵심은 기능 추가보다 운영 부담 축소다. PR 작성자는 메인넷 테스트에서 재구축된 txindex가 약 66GB에서 26GB로 줄었고, 인덱싱 시간도 약 1시간 50분에서 1시간 19분으로 단축됐다고 밝혔다. 다만 같은 논의 안에는 약 29GB와 'roughly half'라는 표현도 남아 있어, 절감 폭은 체인 높이와 저장장치, 빌드 환경에 따라 달라질 수 있다.
새 구조는 짧아진 키 때문에 충돌 가능성을 전제로 한다. 그러나 설계상 충돌은 잘못된 트랜잭션 반환으로 이어지지 않는다. 비트코인 코어는 같은 프리픽스를 가진 후보를 훑고, 블록 인덱스로 위치를 찾은 뒤 디스크에서 트랜잭션을 읽어 전체 txid를 다시 확인한다.
충돌이 생기면 추가 디스크 읽기 비용이 붙는 구조다. 즉 저장공간을 줄이되 조회 정확성은 전체 txid 검증으로 확보하는 방식이다. 리뷰 과정에서도 legacy fallback, reorg, downgrade 경로가 함께 점검됐다.
운영자가 실제 절감 효과를 얻으려면 기존 indexes/txindex/ 데이터를 지우고 인덱스를 다시 만들어야 한다. 기존 txindex 데이터베이스는 업그레이드 뒤에도 읽을 수 있지만, 그 상태로는 과거 엔트리의 큰 저장 구조가 남는다. 공간 절감은 재생성 이후에 반영된다.
다운그레이드도 별도 고려 대상이다. compact format으로 다시 만든 뒤 이전 비트코인 코어 릴리스로 되돌리면 구버전은 새 엔트리를 읽지 못한다. 이 경우 운영자는 txindex를 다시 재구축해야 한다.
프루닝 노드와의 관계도 남아 있다. 비트코인 코어 문서는 현재 프루닝 모드가 -txindex와 호환되지 않는다고 적고 있다. 비트코인 코어 개발 IRC에서는 20일 PR #35531 병합 사실과 함께 프루닝 노드 지원 후속 작업이 언급됐지만, 공식 문서 기준으로는 아직 별도 운영 선택으로 보는 것이 맞다.
프루닝은 오래된 블록 데이터를 지워 저장공간을 줄이는 운영 방식이다. 반대로 txindex는 과거 모든 트랜잭션을 빠르게 찾기 위해 별도 인덱스를 유지한다. 저장공간을 아끼는 노드와 전체 거래 조회용 노드는 통상 운영 목적이 다르다.
이번 변경은 가격이나 시장 수급보다 인프라 운영비와 노드 관리 절차에 가까운 사안이다. 탐색기, 지갑 백엔드, 라이트닝 관련 운영자처럼 과거 거래 조회가 필요한 주체에게는 디스크 사용량과 재구축 시간이 직접 비용으로 연결된다.
비트코인 코어 관련 논의는 최근 네트워크 운영과 보안 영역에서 잇따라 이어지고 있다. 본지는 앞서 비트코인 코어 개발진이 암호화 라우팅 네트워크 CJDNS 지원을 계속 둘지 공개 논의에 들어갔다고 보도했다. 이번 txindex 변경도 이용자 기능보다 노드 운영자가 감당해야 하는 저장공간과 호환성 문제에 초점이 맞춰져 있다.
공개 반응은 주로 깃허브 PR 토론과 비트코인 코어 개발 IRC에서 확인됐다. 개발 논의에서는 디스크 절감 자체를 긍정적으로 보면서도, 재구축·재동기화·reorg 처리·향후 블록 수 증가에 따른 문서화를 명확히 해야 한다는 요구가 붙었다.
정식 릴리스에 포함되는 시점은 아직 명시되지 않았다. 노드 운영자는 릴리스 반영 시점, 재구축 여부, 다운그레이드 가능성을 함께 확인한 뒤 적용 절차를 정해야 한다.

