저자: willcl-ark, l0rinc, hodlinator
출처: https://bitcoinmagazine.com/print/the-core-issue-outrunning-entropy-why-bitcoin-cant-stand-still
블록 다운로드 초기화
새로운 노드를 네트워크의 최신 상태와 동기화하려면 여러 단계를 거쳐야 합니다.
- 피어 검색 및 블록체인 선택: 노드는 무작위로 선택된 피어 그룹에 연결되고, 그 후 가장 많은 작업증명을 보유한 블록체인이 결정됩니다.
- 블록 헤더 다운로드: 노드는 이러한 피어 노드로부터 블록 헤더를 가져온 다음, 이를 연결하여 완전한 블록 헤더 체인을 형성합니다.
- 블록 다운로드: 노드가 여러 피어 노드로부터 해당 체인에 속하는 블록을 동시에 요청하는 것을 말합니다.
- 블록 및 거래 검증: 한 블록에 포함된 거래는 다음 블록에 포함된 거래가 검증된 후에만 검증됩니다.
블록 검증은 본질적으로 순차적입니다. 각 블록은 이전 블록에서 생성된 상태에 의존하기 때문입니다. 그러나 많은 주변 작업은 병렬로 처리될 수 있습니다. 블록 헤더 동기화, 블록 다운로드 및 스크립트 검증은 모두 서로 다른 스레드에서 독립적으로 실행될 수 있습니다. 이상적인 초기 블록 다운로드 프로세스는 가능한 한 모든 하위 시스템을 활용해야 합니다. 네트워크 스레드는 데이터를 다운로드하고, 검증 스레드는 서명을 검증하며, 데이터베이스 스레드는 생성된 상태를 기록합니다.
지속적인 성능 개선이 없다면, 구성이 불량한 노드는 향후 네트워크에 참여하지 못할 수도 있습니다.
소개
비트코인의 "신뢰할 필요 없이 검증 가능한" 문화는 누구든 원장을 처음부터 다시 재구성할 수 있어야 한다는 것을 의미합니다. 모든 과거 거래를 처리한 후, 각 사용자는 네트워크상의 다른 모든 사용자와 마찬가지로 자신의 자금 상태에 대한 동일한 결과를 받아야 합니다.
이러한 재현성은 비트코인의 신뢰 최소화 설계의 핵심이지만, 엄청난 대가를 치러야 합니다. 비트코인 블록체인이 탄생한 지 17년이 지난 지금, 끊임없이 확장되는 이 데이터베이스를 사용하기 위해서는 신규 참여자들이 이전 참여자들보다 더 많은 자원을 소모해야 합니다.
새로운 노드를 처음부터 시작하려면 제네시스 블록부터 현재 체인의 최상단까지 모든 블록을 다운로드하고 검증하고 저장해야 합니다. 이러한 리소스 대량 동기화 프로세스를 "IBD(초기 블록 다운로드)"라고 합니다.
소비자용 하드웨어가 지속적으로 업그레이드되는 가운데, 초기 블록 다운로드 프로세스의 부담을 최소화하는 것은 중앙 집중화에 매우 중요합니다. 이는 저전력 기기(예: 라즈베리 파이)부터 고성능 서버에 이르기까지 모든 기기에서 비트코인 블록체인을 검증할 수 있도록 보장하기 위함입니다.
벤치마킹
성능 최적화는 소프트웨어 구성 요소, 데이터 패턴, 하드웨어 및 네트워크 환경, 그리고 이러한 요소들의 상호 작용이 어떻게 성능 병목 현상을 일으키는지 이해하는 것에서 시작됩니다. 이를 위해서는 대량 테스트가 필요하지만, 대부분의 테스트는 별다른 성과를 내지 못합니다. Bitcoin Core 개발자는 속도, 메모리 사용량, 유지보수성 사이의 균형을 맞추는 것 외에도 리스크 적고 보상이 큰 변경 사항을 선택해야 합니다. 효과적이지만 사소한 최적화는 리스크 이점보다 크기 때문에 종종 거부됩니다.
기존 기능의 성능 저하를 방지하기 위해 중요한 소규모 벤치마크 테스트들을 진행하고 있습니다. 이는 회귀 효과(예: 특정 코드 조각에서의 성능 저하)를 파악하는 데 매우 유용하지만, 초기 블록 다운로드의 전반적인 성능을 반드시 나타내는 것은 아닙니다.
제안된 최적화 방안에 참여한 사람들은 운영 체제, 컴파일러, 스토리지 유형(SSD vs. HDD), 네트워크 속도, 데이터베이스 캐시 크기, 노드 구성(가지치기 모드 vs. 아카이브 모드), 인덱스 조합 등 다양한 환경에서 재현성과 성능 지표를 제공했습니다. 우리는 단일 목적의 벤치마크를 작성하고 컴파일된 브라우저를 사용하여 특정 시나리오(예: 블록 간 중복 트랜잭션 검사에 해시 세트/정렬된 세트/정렬된 벡터 사용)에서 어떤 설정이 더 나은 성능을 보이는지 검증했습니다.
또한 초기 블록 다운로드에 대한 벤치마크 테스트를 정기적으로 실행합니다. 테스트 방법에는 로컬 블록 파일에서 블록체인 상태(체인 상태)를 재인덱싱하는 방법(이 과정에서 블록 재인덱싱이 필요할 수 있음) 또는 인트라넷 피어나 대규모 P2P 네트워크에서 초기 블록을 완전히 다운로드하는 방법이 포함됩니다(인트라넷 피어를 사용하면 느린 피어 연결로 인한 시간 지연 영향을 방지할 수 있습니다).
초기 블록 다운로드 벤치마크 테스트에서 나타나는 개선 효과는 마이크로 벤치마크에서 나타나는 효과보다 작은 경우가 많은데, 이는 네트워크 대역폭이나 하드 드라이브 읽기/쓰기 속도가 병목 현상을 일으키는 주요 원인입니다. 전 세계 평균 네트워크 속도를 기준으로 할 때, 전체 블록체인을 다운로드하는 데만 약 16시간이 소요됩니다.
재현성을 극대화하기 위해 일반적으로 최적화 전후의 메모리 및 CPU 사용량을 보여주는 체인 상태를 재인덱싱하는 테스트 방식을 선호하며, 이러한 변경 사항이 다른 기능에 어떤 영향을 미치는지 검증합니다.
과거 및 현재 진행 중인 최적화
Bitcoin Core 초기 버전은 훨씬 작은 블록 크기를 위해 설계되었습니다. 사토시 나카모토 작성한 최초의 프로토타입은 단지 기초를 다진 것에 불과했으며, Bitcoin Core 개발자들의 지속적인 혁신이 없었다면 네트워크의 전례 없는 규모에 대처할 수 없었을 것입니다.
초기에 블록 인덱스에는 모든 과거 거래 내역과 해당 거래가 사용되었는지 여부가 저장되었습니다. 그러나 2012년 Ultraprune 개발사(PR #1677)는 사용되지 않은 거래 출력(UTXO)을 추적하는 전용 데이터베이스를 구축하여 "UTXO 세트"라는 개념을 정립했습니다. 이 데이터베이스는 사용 가능한 모든 펜슬의 초기 상태를 미리 캐시하여 블록 검증을 위한 통합된 관점을 제공합니다. 또한 데이터베이스 구현이 Berkeley DB에서 LevelDB로 이전되면서 검증 속도가 크게 향상되었습니다.
하지만 이러한 데이터베이스 마이그레이션은 BIP50 1 체인 포크 초래하기도 했습니다. 많은 트랜잭션 입력이 포함된 블록이 업그레이드된 노드에서는 승인되었지만, 업데이트되지 않은 노드에서는 거부되었습니다(블록이 너무 복잡했기 때문입니다). 이는 Bitcoin Core 개발과 일반 소프트웨어 엔지니어링의 차이점을 보여줍니다. 순전히 성능 최적화조차도 예상치 못한 체인 분할을 초래할 수 있다는 것입니다.
이듬해 (PR #2060) 멀티스레드 서명 검증이 가능해졌습니다. 거의 같은 시기에 전용 암호화 라이브러리인 libsecp256k1이 개발되어 2014년 Bitcoin Core 에 통합되었습니다. 이후 10년간 지속적인 최적화를 통해 범용 OpenSSL 라이브러리의 동일 기능보다 최대 8배 빠른 속도를 달성했습니다.
"헤더 우선 동기화"(PR #4468, 2014)는 초기 블록 다운로드 프로세스를 재구성합니다. 먼저 누적 작업량이 가장 많은 체인의 블록 헤더를 다운로드한 다음, 여러 피어 노드에 동시에 블록을 요청합니다. 이는 IBD(Initial Block Download) 속도를 높일 뿐만 아니라, 노드가 메인 체인에 속하지 않는 고아 블록에 대역폭을 낭비하는 것을 방지합니다.
2016년, PR #9049는 불필요해 보이는 중복 입력 검사를 제거하여 인플레이션을 허용하는 합의 버그를 발생시켰습니다. 다행히 이 버그는 악용되기 전에 발견되어 패치되었습니다. 이 사건을 계기로 테스트 리소스에 대한 대규모 투자가 이루어졌습니다. 이제 차등 퍼징 ( Differential Fuzzing ), 광범위한 코드 커버리지, 그리고 더욱 엄격한 감사 규율을 통해 Bitcoin Core 문제를 훨씬 빠르게 발견하고 해결하며, 이후 이와 같은 심각도의 합의 취약점은 보고되지 않았습니다.
2017년에 도입된 -assumevalid 런처 태그(PR #9484)는 일반적인 블록 유효성 검사와 비용이 많이 드는 서명 검증을 분리하여 대부분의 IBD(인공 블록 생성)에서 서명 검증을 선택 사항으로 만듦으로써 IBD 시간을 약 절반으로 줄였습니다. 블록 생성, 작업 증명 및 비용 규칙은 여전히 완벽하게 검증되며, -assumevalid 모드는 특정 높이에 도달하기 전까지 서명 검증을 완전히 건너뜁니다.
2022년 PR #25325는 Bitcoin Core 의 표준 메모리 할당자를 코인 캐싱에 최적화된 맞춤형 풀 기반 할당자로 교체했습니다. 비트코인의 할당 모델에 맞춰 특별히 설계함으로써 메모리 낭비를 줄이고 캐싱 효율성을 향상시켜 IBD 속도를 약 21% 향상시켰으며, 동일한 메모리 용량에 더 많은 코인을 저장할 수 있게 했습니다.
코드 자체는 변하지 않지만, 코드가 존재하는 시스템은 끊임없이 변화합니다. 비트코인의 상태는 10분마다 바뀌며, 사용 패턴이 바뀔 때마다 병목 현상도 달라집니다. 유지 관리와 최적화는 선택 사항이 아닙니다. 지속적인 개선 없이는 비트코인은 정적인 코드베이스가 견딜 수 있는 속도보다 훨씬 빠르게 취약점을 축적하게 되고, 하드웨어가 계속 발전하더라도 초기 블록 다운로드 성능은 급격히 저하됩니다.
UTXO 세트의 지속적인 확장과 평균 블록 가중치의 증가는 이러한 변화를 더욱 증폭시켰습니다. 이전에는 CPU 집약적인 작업(예: 서명 검증)이었던 것이 이제는 체인 상태 접근 증가(디스크에서 UTXO 세트를 확인해야 함)로 인해 디스크 집약적인 작업이 되는 경우가 많습니다. 이러한 변화로 인해 메모리 캐싱 최적화, LevelDB 플러시 빈도 감소, 그리고 최신 멀티코어 CPU를 활용하기 위한 디스크 읽기 병렬화와 같은 새로운 우선순위가 생겨났습니다.
- 다양한 비트코인 코어 배포판의 IBD 날짜 목록 -
최근 최적화
소프트웨어 설계의 기본은 사용 패턴 예측인데, 네트워크가 진화함에 따라 이러한 예측은 필연적으로 현실과 차이가 발생합니다. 비트코인의 결정론적 워크로드는 실제 동작을 측정하고 시의적절하게 수정할 수 있도록 해주며, 이를 통해 성능이 네트워크 성장에 발맞춰 유지되도록 보장합니다.
저희는 실제 사용 패턴에 더욱 잘 맞도록 소프트웨어의 기본 설정을 지속적으로 조정합니다. 몇 가지 예를 들면 다음과 같습니다.
- PR #30039는 LevelDB의 최대 파일 크기를 늘렸습니다. 이 단일 매개변수 변경으로 IBD 속도가 거의 30% 향상되었는데, 이는 체인 상태 데이터베이스(UTXO 세트)에 실제로 액세스하는 패턴과 더 잘 일치했기 때문입니다.
- PR #31645는 쓰기 배치 크기를 두 배로 늘리고, 초기 블록 다운로드의 가장 집중적인 쓰기 단계 동안 디스크 조각화 쓰기를 줄이며, 초기 블록 다운로드가 중단될 때 진행 상황 저장 속도를 높였습니다.
- PR #32279는 내부 프리벡터(주로 메모리 내 스크립트 저장에 사용됨)의 저장 크기를 조정합니다. 기존의 분리된 위트 프리벡터 임계값은 최신 스크립트 템플릿보다 오래된 스크립트 템플릿에 편향을 주었습니다. 최신 스크립트 크기를 고려하여 크기를 조정함으로써 단편화된 할당을 방지하고 메모리 단편화를 줄이며, 더 나은 캐시 위치를 통해 스크립트 실행 속도를 향상시킬 수 있습니다.
이 모든 것들은 사소한 변화였지만, 상당한 영향을 미쳤습니다.
매개변수 조정 외에도 일부 변경 사항은 기존 설계를 재고해야 할 필요가 있습니다.
- PR #28280은 디스크 공간을 절약하기 위해 오래된 블록을 버리는 가지치기 노드(pruned nodes)가 빈번한 메모리 캐시 플러시를 처리하는 방식을 개선합니다. 기존 설계에서는 캐시 전체를 버리거나 수정된 항목을 검색하는 방식이었습니다. 수정된 항목을 선택적으로 추적하는 방식을 도입한 결과, 최대 캐시(
dbcache)를 사용하는 가지치기 노드에서 30% 이상의 속도 향상을, 기본 설정에서는 약 9%의 속도 향상을 얻었습니다. - PR #31551에서는 블록 파일 읽기/쓰기에 대한 배치 처리 기능이 도입되어 많은 소규모 파일 시스템 작업의 오버헤드가 감소했습니다. 블록 파일 읽기 속도가 4~8배 향상되어 초기 블록 다운로드뿐만 아니라 다른 RPC 작업에도 도움이 됩니다.
- PR #31144는 기존의 선택적 블록 파일 난독화(데이터가 디스크에 평문으로 저장되지 않도록 보장하는 데 사용됨)를 최적화하여 데이터를 바이트 단위가 아닌 64비트 블록 단위로 처리함으로써 IBD(인공 디스크 저장) 가속을 한층 더 향상시킵니다. 난독화에 드는 비용이 사실상 무료가 됨에 따라 사용자는 더 이상 안전한 저장과 성능 사이에서 선택할 필요가 없습니다.
PR #32487과 같은 기타 사소한 캐싱 최적화를 통해 PR #32638에서 비용이 너무 많이 든다고 판단했던 추가 보안 검사를 수행할 수 있습니다.
마찬가지로, 이제 캐시를 디스크에 더 자주 플러시할 수 있습니다(PR #30611). 이를 통해 노드가 다운타임 동안 1시간 이상의 검증 작업을 손실하지 않도록 할 수 있습니다. 초기 블록 다운로드 속도가 이미 최적화를 통해 크게 향상되었기 때문에 이러한 약간의 오버헤드는 허용 가능합니다.
PR #32043은 현재 IBD 관련 성능 개선을 추적하는 스레드입니다. 디스크 및 캐시 최적화부터 동시성 향상에 이르기까지 10개 이상의 진행 중인 프로젝트를 요약하고, 각 변경 사항이 실제 시나리오에서 성능에 미치는 영향을 측정하는 프레임 제공합니다. 이러한 접근 방식을 통해 기여자들은 코드뿐만 아니라 재현 가능한 벤치마크, 사용 데이터, 다양한 하드웨어 간의 비교 자료도 제공할 수 있습니다.
향후 최적화 방안 제안
PR #31132는 블록 유효성 검사 중 트랜잭션 입력 가져오기를 병렬화합니다. 현재는 각 입력이 UTXO 세트에서 순차적으로 가져와지는데, 캐시에 없으면 디스크 통신이 필요하여 읽기/쓰기 병목 현상이 발생합니다. 이 PR은 여러 워커 스레드에 걸쳐 병렬 가져오기를 도입하여 -reindex-chanstate 옵션을 사용했을 때 약 30%의 속도 향상을 달성합니다(450MB 데이터베이스 캐시를 가진 Raspberry Pi 5에서 약 10시간 소요). 또한, ` -dbcache 설정에 따른 성능 격차가 줄어들어 메모리가 적은 노드도 메모리가 많은 노드만큼 빠르게 동기화할 수 있게 됩니다.
PR #26966은 블록 다운로드 초기화 외에도 구성 가능한 작업자 스레드를 사용하여 블록 필터링 및 트랜잭션 인덱스 컴파일을 병렬화합니다.
영구 저장소 UTXO 세트를 간결하게 유지하는 것은 노드 경제성에 매우 중요합니다. PR #33817에서는 선택적 LevelDB 기능(비트코인 애플리케이션에는 필요하지 않을 수 있음)을 제거하여 UTXO 세트를 약간 줄이는 효과를 실험했습니다.
SwiftSync 3 는 과거 블록 데이터를 활용하는 실험적인 접근 방식입니다. 실제 결과를 알고 있기 때문에 목표 블록 높이에서의 최종 상태를 기준으로 각 코인을 분류할 수 있습니다. 즉, 아직 사용되지 않은 코인(저장 대상)과 목표 블록 높이 이전에 이미 사용된 코인(무시 대상, 특정 위치와 관계없이 생성/사용 쌍에 존재하는지만 확인하면 됨)으로 구분합니다. 미리 생성된 힌트에 이러한 분류를 인코딩할 수 있으므로 노드는 수명이 짧은 코인에 대한 UTXO 작업을 완전히 건너뛸 수 있습니다.
비트코인은 누구에게나 열려 있습니다.
합성 벤치마크 외에도 최근 실험 4 에서는 클럭 속도를 낮춘 Raspberry Pi 5에서 Swiftsync 프로토타입을 실행했습니다. 단일 배터리 팩으로 구동되고 WiFi로 연결된 이 Raspberry Pi 5는 888,888개 블록의 체인 상태를 3시간 14분 만에 재인코딩했습니다. 동일한 구성을 사용한 실험에서는 최신 Bitcoin Core 버전 5 에서 전체 검증 속도가 250% 향상되는 것을 보여주었습니다.
수년간 축적된 노력이 엄청난 성과로 이어졌습니다. 거의 백만 개의 블록이 완벽하게 검증되었으며, 이는 저렴한 하드웨어로 하루 만에 완료할 수 있습니다. 블록체인은 지속적인 성장에도 불구하고 경제성을 유지하고 있습니다.
자치 통치는 그 어느 때보다 쉬워졌습니다.
참고 자료
1. https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
2. https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
3. https://delvingbitcoin.org/t/swiftsync-speeding-up-ibd-with-pre-generated-hints-poc/1562
4. https://x.com/L0RINC/status/1972062557835088347 ↩
5. https://x.com/L0RINC/status/1970918510248575358 ↩
이 글에 나열된 모든 풀 리퀘스트(PR)는 다음 링크에서 번호를 통해 확인할 수 있습니다: https://github.com/bitcoin/bitcoin/pulls
