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 и передавать дальше.