Erlay

일반적인 중계에서는 연결된 노드가 INV 메시지로 32바이트 거래 식별자를 보냅니다. 이웃 노드가 이미 아는 거래일 때도 많습니다. 연결이 늘면 이 통신량도 늘지만, 다양한 연결은 노드의 고립과 네트워크 분할에 대응하는 데 도움이 됩니다. [1]

Erlay는 소수의 연결에서 빠른 알림을 유지합니다. 나머지 연결에서는 두 노드가 아직 상대에게 알리지 않은 거래 집합을 주기적으로 비교합니다. 전체 목록 대신 sketch라는 간결한 수학적 요약으로 차이를 찾을 수 있습니다. BIP 330은 이에 필요한 P2P 확장을 명시합니다. [1]

연결마다 별도의 집합을 관리하고 각 라운드에서는 고정된 스냅샷을 사용합니다. 양쪽은 각각 salt를 제공합니다. 이는 wtxid에서 짧은 32비트 식별자를 도출하는 데 쓰는 보조 입력입니다. PinSketch로 이 식별자 집합들을 비교할 수 있습니다. sendtxrcncl, reqrecon, sketch, reqsketchext, reconcildiff 메시지는 지원 협상, 요약 교환, 빠진 알림 확인을 담당합니다. [1]

차이를 찾은 뒤에도 노드는 완전한 거래를 요청하고 자신의 규칙으로 검증합니다. Salt는 짧은 식별자의 충돌을 미리 계산하기 어렵게 만드는 값이며, 비밀번호나 거래 암호화가 아닙니다. 요약의 용량이 부족하면 확장을 요청할 수 있습니다. 비교에 실패하면 기존 알림 방식으로 돌아갑니다. 상대 노드가 자원을 쉽게 소진시키지 못하도록 구현에서 계산량과 메모리도 제한해야 합니다. [1]

2026년 10월 확인 당시 BIP 330은 Draft 상태였으며 원래 논문에서 수정된 절차를 설명했습니다. Bitcoin Core의 논의 #34542는 통신량 절약, 지연, 코드 복잡성을 다시 평가하고 있었습니다. 이것만으로 특정 Bitcoin Core 버전이 Erlay를 사용한다고 볼 수는 없습니다. 해당 버전의 출시 설명, 구현, 두 노드 사이에서 협상된 지원 여부를 확인해야 합니다. [4]

2019년 논문은 실험 조건에서 전체 통신량을 약 40%, 거래 알림 통신량을 84% 줄였다고 보고합니다. 시뮬레이션과 시제품의 결과이지 모든 현재 네트워크에 대한 보장은 아닙니다. 다음 라운드를 기다리면 지연이 늘 수 있습니다. 거래를 받기만 하고 전달하지 않는 노드는 전파를 더 늦출 수 있습니다. 절감량과 속도를 함께 측정해야 합니다. [2]

Erlay는 미확인 거래의 반복 알림을 줄입니다. Compact Blocks는 노드가 대부분 이미 아는 거래를 이용해 새 블록을 복원할 때 필요한 데이터를 줄입니다. 두 방식은 서로 보완하지만, 어느 쪽도 단독으로 노드의 네트워크상 식별 정보를 숨기지 않습니다. 각각 실패 시 처리 절차와 자원 소진 방어가 필요합니다. [3]

BIP 330 버전과 노드가 실제 실행하는 코드부터 확인합니다. 지원 협상, 짧은 식별자와 salt의 도출, 라운드 간격, 요약의 한도, reqsketchext의 동작을 살펴봅니다. 기존 알림으로 돌아가는 절차와 이후 완전한 거래의 검증도 확인해야 합니다. Erlay라는 이름만으로 실제 절감량이나 지연을 알 수는 없습니다. [1]