Erlay — запропонований спосіб поширення непідтверджених транзакцій у P2P-мережі Bitcoin. Він поєднує звичайні оголошення з порівнянням множин ідентифікаторів — set reconciliation. Це заощаджує трафік, але не змінює консенсусу чи обов’язку перевіряти кожну отриману транзакцію.
За звичайного поширення з’єднані вузли надсилають повідомлення INV з 32-байтовими ідентифікаторами транзакцій. Сусід часто вже знає транзакцію. Більша кількість з’єднань збільшує трафік, хоча різноманітні з’єднання допомагають захистити вузол від ізоляції, а мережу — від розділення. [1]
Erlay зберігає швидкі оголошення на невеликій частині з’єднань. На інших пари вузлів регулярно порівнюють множини транзакцій, які ще не оголосили один одному. Різницю можна знайти за компактним математичним зведенням, яке називають sketch, не передаючи повних списків. BIP 330 описує потрібне розширення P2P-протоколу. [1]
Кожне з’єднання має окрему множину, а кожен раунд працює з її незмінним знімком. Обидві сторони надають salt — допоміжне значення для отримання коротких 32-бітових ідентифікаторів із wtxid. PinSketch дає змогу порівнювати множини цих ідентифікаторів. Повідомлення sendtxrcncl, reqrecon, sketch, reqsketchext і reconcildiff узгоджують підтримку, передають зведення та визначають відсутні оголошення. [1]
Знайшовши різницю, вузол усе одно запитує повну транзакцію та перевіряє її за власними правилами. Salt ускладнює попереднє обчислення колізій коротких ідентифікаторів; це не пароль і не шифрування транзакції. Якщо місткості зведення недостатньо, можна запросити розширення. У разі невдачі протокол повертається до звичайних оголошень. Реалізація має обмежувати обчислення й пам’ять, щоб сусідній вузол не міг легко виснажити ці ресурси. [1]
Під час перевірки в жовтні 2026 року BIP 330 мав статус Draft і описував переглянутий щодо початкового дослідження порядок роботи. Обговорення Bitcoin Core № 34542 заново оцінювало економію трафіку, затримку та складність коду. Саме по собі це не доводить, що певний випуск Bitcoin Core використовує Erlay. Важливі примітки до випуску, реалізація та узгоджена між обома вузлами підтримка. [4]
Дослідження 2019 року за своїх експериментальних умов повідомляє про приблизно 40% економії загального трафіку та 84% економії на оголошеннях транзакцій. Це результати моделювання і прототипу, а не обіцянка для будь-якої сучасної мережі. Очікування наступного раунду може збільшувати затримку; вузол, який приймає транзакції, але не передає їх далі, може додатково сповільнити поширення. Економію та швидкість слід вимірювати разом. [2]
Erlay скорочує повторні оголошення непідтверджених транзакцій. Compact Blocks натомість зменшує обсяг даних для відтворення нового блока з транзакцій, які вузол переважно вже знає. Механізми доповнюють один одного, але жоден сам по собі не приховує мережевої ідентичності вузла. Кожному потрібні власні дії на випадок невдачі та захист від виснаження ресурсів. [3]
Почніть із версії BIP 330 та коду, який вузол справді виконує. Перевірте узгодження підтримки, отримання коротких ідентифікаторів і salt, розклад раундів, межі зведень та поведінку reqsketchext. Також перевірте повернення до звичайних оголошень і подальшу валідацію повної транзакції. Сама назва Erlay нічого не доводить про досягнуту економію чи затримку. [1]
Для повної картини прочитайте також Mempool, Bitcoin Core, Compact Blocks, Full Node, Sybil Attack, Eclipse Attack. На цю статтю також посилаються Block Propagation.
01Чи означає BIP 330, що мій Bitcoin Core вже використовує Erlay?+
Ні. Сама специфікація цього не гарантує. Перевірте конкретний випуск, його реалізацію та чи узгодили обидва вузли підтримку. Експериментальний код або дослідження — не те саме, що ввімкнена на вашому вузлі функція.
02Чи замінює Erlay перевірку транзакцій?+
Ні. Він допомагає визначити, яких оголошень бракує іншій стороні. Вузол і далі запитує повну транзакцію та за власними правилами вирішує, чи прийняти її до свого mempool і передати далі.