느린 전파와 느린 검증은 같은 문제가 아닙니다.
새로운 블록이 생성되면 다른 노드들은 해당 블록의 트랜잭션을 가져와 검증해야 합니다. 만약 노드의 멤풀에 이미 대부분의 트랜잭션이 저장되어 있다면, 모든 트랜잭션을 반복적으로 다운로드하는 것은 대역폭을 낭비하는 행위입니다. 컴팩트 블록은 이러한 중복을 활용하여 필요한 재구성 정보를 먼저 전송합니다. 이는 데이터 전파를 최적화하지만, 노드가 트랜잭션 검사를 건너뛸 수 있다는 의미는 아니며, 매번 전체 전송보다 빠른 전송 속도를 보장하는 것도 아닙니다.
짧은 식별자가 재구성에 도움이 되는 방법
BIP152에 설명된 컴팩트 블록에는 블록 헤더, 짧은 식별자를 생성하는 데 사용되는 난수, 미리 채워진 트랜잭션, 그리고 다른 트랜잭션에 대한 짧은 식별자가 포함됩니다. 수신 노드는 로컬 멤풀에서 트랜잭션을 찾아 순차적으로 블록을 재구성합니다. 단축 식별자는 완전한 거래 식별자도 아니고 잔액 증명도 아닙니다. 이는 전파 프로세스를 위해 설계된 간결한 단서이며, 거래의 진위 여부를 독립적으로 검증하는 데 사용할 수 없습니다.
로컬 거래가 누락된 경우 발생하는 상황
수신 노드에서 거래가 누락되었거나, 일치 여부에 대한 모호성이 발생했거나, 블록을 재구성할 수 없는 경우, 피어 노드에 누락된 부분을 요청합니다. 네트워크 정책, 멤풀 차이, 노드 시작 시점과 같은 요인들이 적중률에 영향을 미칠 수 있습니다. "완료된 거래 요청" 로그를 확인했다고 해서 상대방이 악의적이거나 소프트웨어 오류가 있다고 단정해서는 안 됩니다. 누락된 거래 비율, 연결 품질, 그리고 후속 검증이 완료되었는지 여부를 고려해야 합니다.
재구성 프로세스 예시
새로운 블록에 여러 트랜잭션이 포함되어 있고, 노드가 이미 멤풀에서 대부분의 트랜잭션을 확인했다고 가정해 보겠습니다. 압축된 블록을 수신한 후, 노드는 이미 알려진 위치를 직접 채운 다음 나머지 트랜잭션을 다운로드할 수 있습니다. 노드가 동기화를 완료한 직후이고 멤풀 크기가 작다면, 데이터 완료 비용이 증가할 수 있습니다. 이 예시는 메커니즘을 설명하기 위한 것이며, 실제 네트워크 통계로 간주하거나 마이닝 풀의 전파 지연을 보장하는 데 사용해서는 안 됩니다.
노드 운영자가 관찰해야 할 사항
소프트웨어 버전, 피어 연결 유형, 블록 수신 시간, 재구성 실패 횟수, 완료 상태를 기록하고, 정상 기간과 재시작 후의 성능을 비교하십시오. 로그 시간은 로컬 클록과 네트워크의 영향을 받습니다. 단일 장치의 데이터만으로는 전체 네트워크를 대표할 수 없습니다. 문제 해결 시에는 먼저 공식 버전 문서와 네트워크 연결 상태를 확인하고, 그 다음 로컬 리소스를 고려하십시오. 속도 향상을 위해 중요한 검증을 비활성화하거나 알 수 없는 설정을 복사하지 마십시오.
관련 뉴스를 읽을 때 오해를 피하는 방법
"블록 압축" 또는 "2단계 동기화"와 같은 제목을 접할 경우, 해당 보고서가 블록 전파, 이력 동기화 또는 합의 확정성을 의미하는지 확인하십시오. 압축된 블록은 원장 내 거래 검증 요구 사항을 줄이거나 확정된 거래를 절대적으로 재구성 불가능하게 만들지는 않습니다. 작성자의 결론과 비교할 수 있도록 BIP 버전, 소프트웨어 구현 및 테스트 환경을 저장하십시오. 이러한 조건이 충족되지 않은 속도 수치는 직접 비교해서는 안 됩니다.
