Erlay

트랜잭션 공지는 노드 대역폭에서 가장 큰 단일 사용처를 차지하며, 비용은 피어를 추가할 때마다 증가합니다. Gleb Naumenko와 Pieter Wuille는 이 설계를 BIP330으로 작성했으며, 여전히 초안 상태입니다: Bitcoin Core의 어떤 릴리스도 이 기능을 켜지 않습니다. 이 설계가 중요한 이유는 자신의 노드를 운영하는 비용이 얼마나 저렴해질 수 있는지를 결정하기 때문입니다.

작동 방식

Erlay는 세어 보면 금방 드러나는 중복을 공략합니다: 현재 노드는 듣게 되는 모든 트랜잭션을 모든 피어에게 알리며, 그 피어 대부분은 이미 그 트랜잭션을 알고 있습니다.

현재 방식은 플러딩입니다. 각각의 새 트랜잭션은 유형 코드와 32바이트 식별자를 담은 inv 메시지로 광고되므로, 피어 하나당 광고 하나에 36바이트가 듭니다. Bitcoin Core는 기본적으로 트랜잭션 중계를 위해 아웃바운드 연결 8개를 열고, 수신 피어를 총 125개까지 받아들입니다. 따라서 연결이 잘 된 기계는 어차피 알게 될 정보를 두고 같은 짧은 메시지를 수십 번씩 주고받습니다. 이 낭비는 연결 수에 비례하며, 이는 네트워크를 분할하기 어렵게 만드는 바로 그 행동에 불이익을 줍니다.

Erlay는 플러딩을 일부만 남기고 나머지를 집합 조정으로 대체합니다. 피어 쌍마다 상대와 아직 교환하지 않은 공지 목록을 추적합니다. 주기적으로 한쪽이 그 집합의 스케치를 요청합니다. 스케치는 크기가 고정된 대수적 요약으로, 그 길이는 어느 한쪽이 보유한 트랜잭션 수가 아니라 예상되는 차이의 수에 따라 정해집니다. 두 스케치를 결합하면 한쪽 피어에는 있고 다른 쪽에는 없는 항목이 정확히 나옵니다. minisketch 라이브러리는 이 구성과 디코딩을 구현하며, Bitcoin Core는 주변의 중계 프로토콜이 병합되지 않은 채로 수년간 이를 소스 트리에 포함해 왔습니다.

스케치 크기를 잘못 추측해도 치명적이지 않습니다. 차이가 추정보다 커서 디코딩이 실패하면, 피어는 처음부터 다시 시작하는 대신 스케치를 확장해 다시 시도합니다. 따라서 잘못된 추정은 완전한 재동기화가 아니라 약간의 추가 대역폭만을 초래합니다.

확인할 수 있는 곳

Erlay는 아직 볼 수 없으며, 노드 대시보드에서 이를 찾는 사람에게는 이것이 정직한 답변입니다.

볼 수 있는 것은 Erlay가 겨냥하는 문제입니다. 자신의 노드에서 getnettotals를 호출하면 바이트 카운터는 체인의 최초 다운로드를 제외한 모든 것을 중계 트래픽이 압도하고 있음을 보여 줍니다. 종량제 연결을 쓰는 운영자는 이미 maxuploadtarget으로 업로드를 제한하거나 유지하는 피어 수를 줄이는 방식으로 대응하며, 두 선택 모두 요금을 낮추기 위해 네트워크를 조금 약화시킵니다.

이것이 Erlay가 해소하려는 상충 관계입니다. 대역폭이 연결 수에 따라 늘어나지 않게 되면, 노드는 훨씬 더 많은 피어를 안전하게 유지할 수 있으며, 조밀하게 연결된 네트워크는 분할하거나 이클립스 공격으로 고립시키기가 훨씬 어렵습니다. 탐색기를 신뢰하는 대신 자신의 코인을 검증하는 것에만 관심이 있는 사람에게, 그 약속은 좁지만 실질적입니다: 더 저렴한 연결로 같은 검증을 하는 것입니다.

Erlay vs 컴팩트 블록 중계

Erlay는 채굴되기 전의 트랜잭션을 다루고, 컴팩트 블록 중계는 채굴된 후의 블록을 다룹니다. 둘은 서로 다른 병목을 해결하며 서로 다른 시계로 평가되어 왔습니다. 블록 전파는 지연 시간 문제입니다. 블록이 전송 중에 보내는 1초는 채굴업자가 더 이상 존재하지 않는 체인 끝에서 채굴하며 보내는 1초이기 때문이며, 해결책은 2016년에 출시되었습니다. 트랜잭션 공지는 밀리초가 아니라 한 달에 걸쳐 기가바이트로 측정되는 용량 문제이므로 아무도 서두르지 않았고, 그래서 이 제안은 수년째 초안으로 남아 있습니다.