저자: 제임슨 롭
출처: https://blog.lopp.net/running-bitcoin-core-v0-7-and-earlier/
이 기사는 모든 비트코인 코어 배포판의 역사적 동기화 성능에 대한 연구 결과 중 하나이며, 아주 오래된 버전(컴파일된 바이너리를 찾기가 어렵습니다)을 구축하는 데 따른 어려움 도 있습니다.
이러한 버전의 Bitcoin Core를 사용하여 블록체인을 동기화하려는 경우 어려움을 겪게 될 것입니다. 나는 이 문제를 처음으로 조사한 사람이 아닙니다. 연구 중에 Sjors Provoost가 2017년에 유사한 실험을 실행하고 이를 문서화했다는 사실을 발견했습니다.
기존 비트코인 코어 클라이언트의 성능 – Sjors Provoost
동기화 중 오류 탐색
v0.8.0 이전 버전은 여러 가지 이유로 현재 체인의 최상위와 동기화될 수 없습니다.
v 0.3 : 블록 높이 12 4275에서 동기화가 중지되어 다음 오류가 전송됩니다.
ERROR: ConnectInputs() : fb0a1d8d34 VerifySignature failedInvalidChainFound: invalid block=0000000000004939267fheight=124276 work=6613870563198902508언뜻보기에 이것은 특별히 이상한 거래가 아닙니다. 그러나 이 비트코인 주소 의 지출 내역을 살펴보면 지출자가 수백 개의 "0 값" 출력으로 여러 이상한 거래를 구성했음을 알 수 있습니다. 이것이 네트워크를 방해하려는 기술자라고 가정하는 것은 무리가 아닙니다.
마지막으로 제가 놀랐던 점은 이 입력 시그니처의 크기였습니다. 서명의 최대 한도는 75바이트이며, 대부분의 P2PKH 트랜잭션의 서명은 71~73바이트입니다.
다음 기사에서 비트코인 거래 서명의 내역을 읽을 수 있습니다. 온체인 나타난 서명을 따르기 위해 최신 버전의 OpenSSL(1.0.0p/1.0.1k)을 사용하려고 하면 DER 유효성 검사 가 더 엄격하고 특정 유형의 인코딩을 거부하기 때문에 오류가 발생합니다.
해결 방법은 이전 버전의 OpenSSL을 사용하여 Bitcoin Core를 빌드하거나 빌드를 시작하기 전에 이 코드 패치를 수동으로 적용하는 것 입니다. gitian builder는 Ubuntu 10.04 가상 머신을 빌드 환경으로 사용하기 때문에 처음에는 약간 혼란스러웠고, OpenSSL의 이전(호환) 버전과 페어링되어야 한다고 생각했습니다... 그러나 Andrew Chow 는 이를 백포트했다고 지적했습니다. 2015년(백포트) 이 OpenSSL 패치 .
v0.4와 v0.5 모두 블록 높이 25 8354에서 동기화가 중지되어 오류가 발생했습니다.
EXCEPTION: 11DbExceptionDb::put: Cannot allocate memorybitcoin in ProcessMessage()ProcessMessage(block, 901212 bytes) FAILEDreceived block 0000000000000023e872REORGANIZE이는 25 8355가 900KB 크기에 도달한 첫 번째 블록인 것으로 나타나기 때문에 주목할 만합니다. 그 전에는 거의 모든 채굴된 블록이 기본 "소프트 캡"인 250KB에 도달했습니다.
v0.6은 블록 높이 36 4670에서 동기화를 중지하고 오류를 발생시킵니다.
EXCEPTION: 11DbExceptionDb::put: Cannot allocate memorybitcoin in ProcessMessages()ProcessMessage(block, 999787 bytes) FAILEDreceived block 000000000000000001d3블록 36 4671이 1MB에 도달한 첫 번째 블록이라는 점에서 유사점이 있습니다.
v0.7은 동일한 블록에서 동기화를 중지하지만 오류 로그는 다릅니다.
received block 00000000000000000221ERROR: ConnectBlock() : UpdateTxIndex failedInvalidChainFound: invalid block=00000000000000000221 height=364671ERROR: SetBestChain() : SetBestChainInner failedERROR: AcceptBlock() : AddToBlockIndex failedERROR: ProcessBlock() : AcceptBlock FAILED v0.4~v0.7까지 모두 같은 이유로 중단된 것 같은데, 그 이유는 무엇이었나요? "BDB 잠금 문제"(2013년에 예상치 못한 체인 분할을 일으킨 문제)입니까?이 지침에 따라 ~/.bitcoin/DB_CONFIG 파일을 생성하려고 합니다.
set_lg_dir databaseset_lk_max_locks 537000 그러나 모든 버전은 여전히 동일한 블록 높이에 머물러 있습니다. set_lk_max_objects 도 구성해야 하며 초기 권장 값(537000)이 충분히 높지 않은 것으로 나타났습니다 (블록 70 0000에 동기화하려는 경우). 다음 ~/.bitcoin/DB_CONFIG 값은 내 컴퓨터에서 작동합니다.
set_lg_dir databaseset_lk_max_locks 1000000set_lk_max_objects 1000000성과 결과
대략적인 동기화 결과를 볼 수 있습니다.
v0.3에 대한 데이터는 v0.4, v0.5와 거의 동일하기 때문에 거의 볼 수 없으며, 결국 블록 높이 12 4000에서 충돌이 발생합니다. 아래는 좀 더 명확하게 보기 위한 로그 버전입니다.
v0.4가 v0.5보다 더 나은 성능을 발휘하기 시작하는 블록 19 0000에 전환점이 있다는 점은 언급할 가치가 있습니다. 내 추측으로는 이것이 "체크포인트"의 결과인 것 같습니다. 비트코인 0.3.2에는 "체크포인트"라는 메커니즘을 도입하여 새로운 전체 노드가 초기 블록 다운로드 중에 온체인 없는 경쟁 블록을 확인하는 데 대량 시간을 소비하지 않도록 함으로써 서비스 거부 공격을 방지합니다.
비트코인 0.5.0은 이러한 체크포인트를 기반으로 구축되어 가장 최근 체크포인트 이전에 블록체인 온체인 서명 확인을 건너뛰어 동기화 속도를 높입니다. "당신이 착각한 것이 아닌가요? assumevalid=0 을 구성하여 노드가 모든 서명을 확인하도록 강제할 수는 없나요?"라고 말할 수 있습니다. 사실이지만 이 설정은 v0.14 이전의 Bitcoin Core에는 영향을 미치지 않습니다. (v0.14는 이 구성 매개변수가 처음 도입된 버전 입니다.)
따라서 v0.5는 v0.4에 비해 전반적으로 느리고, 초기 동기화 성능 테스트는 실제로는 부정행위/불공정한 비교라고 생각합니다.
이전 버전과 새 버전
그렇다면 최신 v22 버전은 이전 버전에 비해 얼마나 성능이 향상되었을까요?
블록 12 4000에 동기화:
- v22는 v0.3보다 17배 빠릅니다.
이 블록들은 모두 비어 있기 때문에 성능 차이는 그다지 눈에 띄지 않지만, 더 많은 블록체인이 동기화되면 눈에 띄게 됩니다.
블록 높이 25 8000으로 동기화됨:
- v22는 v0.4보다 77배 빠릅니다.
- v22는 v0.5보다 83배 빠릅니다.
블록 36 4000에 동기화:
- v22는 v0.6보다 40배 빠릅니다.
- v22는 v0.7보다 38배 빠릅니다.
향후 호환성이 어렵습니다.
매우 오래된 버전의 비트코인 소프트웨어를 실행할 수 있으며 여전히 현재 네트워크와 호환된다는 말을 자주 듣게 될 것입니다. 물론 실제 대답은 훨씬 더 복잡하고 미묘합니다. 아주 오래된 버전의 비트코인 소프트웨어를 현재 체인의 최상위 버전과 동기화하려면 소프트웨어를 일부 변경해야 합니다. 또 다른 까다로운 점은 이를 줄이면 합의에 중요한 코드가 모두 비트코인 개발자가 작성하는 것이 아니라는 점입니다. 때로는 타사 라이브러리일 수도 있고 이러한 라이브러리도 시간이 지남에 따라 변경되어 소프트웨어가 구축된 프로세스 자체가 가능한 원인이 됩니다. 합의 실패!
(위에)
