Erlay to proponowany sposób przekazywania niepotwierdzonych transakcji w sieci P2P Bitcoina. Łączy zwykłe ogłoszenia z porównywaniem zbiorów identyfikatorów, czyli set reconciliation. Zmniejsza ilość przesyłanych danych, ale nie zmienia konsensusu ani obowiązku sprawdzenia każdej odebranej transakcji.
Przy zwykłym przekazywaniu połączone węzły wysyłają wiadomości INV z 32-bajtowymi identyfikatorami transakcji. Sąsiad często zna już daną transakcję. Więcej połączeń zwiększa ruch, choć zróżnicowane połączenia pomagają chronić węzeł przed izolacją, a sieć przed podziałem. [1]
Erlay zachowuje szybkie ogłoszenia na niewielkiej części połączeń. Na pozostałych pary węzłów okresowo porównują zbiory transakcji, których jeszcze sobie nie ogłosiły. Różnice można znaleźć za pomocą zwięzłego matematycznego podsumowania, zwanego sketch, bez przesyłania całych list. BIP 330 opisuje potrzebne rozszerzenie P2P. [1]
Każde połączenie ma osobny zbiór, a każda runda korzysta z jego niezmiennego obrazu. Obie strony przekazują salt: pomocniczą wartość do wyprowadzania krótkich, 32-bitowych identyfikatorów z wtxid. PinSketch pozwala porównać zbiory tych identyfikatorów. Wiadomości sendtxrcncl, reqrecon, sketch, reqsketchext i reconcildiff służą do uzgodnienia obsługi, wymiany podsumowań i wykrycia brakujących ogłoszeń. [1]
Po wykryciu różnicy węzeł nadal pobiera pełną transakcję i sprawdza ją według własnych reguł. Salt utrudnia wcześniejsze przygotowanie kolizji krótkich identyfikatorów; nie jest hasłem ani szyfrowaniem transakcji. Jeśli pojemność podsumowania jest niewystarczająca, można poprosić o rozszerzenie. Nieudane porównanie prowadzi do powrotu do zwykłych ogłoszeń. Implementacja musi ograniczać obliczenia i pamięć, aby inny węzeł nie mógł łatwo wyczerpać tych zasobów. [1]
Podczas kontroli w październiku 2026 r. BIP 330 miał status Draft i opisywał procedurę zmienioną względem pierwotnej publikacji. Dyskusja Bitcoin Core nr 34542 ponownie oceniała oszczędność danych, opóźnienia i złożoność kodu. Nie dowodzi to, że konkretna wersja Bitcoin Core używa Erlay. Trzeba sprawdzić jej informacje o wydaniu, implementację i uzgodnioną obsługę po obu stronach połączenia. [4]
Publikacja z 2019 r. podaje w swoich warunkach badawczych około 40% mniej całkowitego ruchu oraz 84% mniej danych na ogłoszenia transakcji. To wyniki symulacji i prototypu, a nie obietnica dla każdej dzisiejszej sieci. Czekanie na kolejną rundę może zwiększać opóźnienie. Węzeł, który odbiera transakcje, ale ich nie przekazuje, może dodatkowo je opóźniać. Oszczędność i szybkość należy mierzyć łącznie. [2]
Erlay ogranicza powtarzane ogłoszenia niepotwierdzonych transakcji. Compact Blocks zmniejsza natomiast ilość danych potrzebną do odtworzenia nowego bloku z transakcji w większości już znanych węzłowi. Mechanizmy uzupełniają się, ale żaden sam nie ukrywa tożsamości sieciowej węzła. Każdy potrzebuje własnej obsługi błędów i ochrony przed wyczerpaniem zasobów. [3]
Zacznij od wersji BIP 330 i kodu faktycznie uruchomionego na węźle. Sprawdź uzgadnianie obsługi, wyprowadzanie krótkich identyfikatorów i salt, czas między rundami, ograniczenia podsumowań oraz działanie reqsketchext. Sprawdź też powrót do zwykłych ogłoszeń i późniejszą weryfikację pełnej transakcji. Sama nazwa Erlay nie dowodzi osiągniętej oszczędności ani opóźnienia. [1]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Mempool, Bitcoin Core, Compact Blocks, Full Node, Sybil Attack, Eclipse Attack. Do tego hasła prowadzą również odsyłacze z Block Propagation.
01Czy BIP 330 oznacza, że mój Bitcoin Core już używa Erlay?+
Nie. Sama specyfikacja tego nie gwarantuje. Sprawdź konkretne wydanie, jego implementację i to, czy oba węzły uzgodniły obsługę. Kod eksperymentalny lub publikacja naukowa to nie to samo co funkcja włączona na twoim węźle.
02Czy Erlay zastępuje weryfikację transakcji?+
Nie. Pomaga ustalić, jakich ogłoszeń brakuje drugiej stronie. Węzeł nadal pobiera pełną transakcję i według własnych reguł decyduje, czy przyjąć ją do mempoolu oraz przekazać dalej.