Erlay

Объявление транзакций является самой крупной отдельной статьей расхода пропускной способности узла, и затраты растут с каждым добавленным пиром. Gleb Naumenko и Pieter Wuille оформили проект как BIP330, где он остается черновиком: ни один выпуск Bitcoin Core его не включает. Это важно, потому что от него зависит, насколько дешевым может стать запуск собственного узла.

Как это работает

Erlay устраняет избыточность, которая становится очевидной, если ее посчитать: сейчас узел сообщает каждому своему пиру о каждой транзакции, о которой узнает, а большинство этих пиров уже о ней знали.

Текущий метод представляет собой лавинную рассылку. Каждая новая транзакция объявляется в сообщении inv, которое несет код типа и идентификатор размером 32 байта, то есть 36 байт на объявление на каждого пира. Bitcoin Core по умолчанию открывает 8 исходящих соединений для ретрансляции транзакций и принимает входящих пиров до общего числа 125, поэтому хорошо связанная машина отправляет и получает одно и то же короткое сообщение десятки раз ради того, о чем она все равно узнала бы. Потери пропорциональны числу соединений, а это наказывает именно то поведение, которое затрудняет разделение сети.

Erlay сохраняет небольшую часть лавинной рассылки, а остальное заменяет согласованием множеств. Каждая пара пиров отслеживает объявления, которыми она еще не обменялась с другой стороной. Периодически одна сторона запрашивает эскиз этого множества. Эскиз представляет собой алгебраическую сводку фиксированного размера, длина которой зависит от того, сколько различий ожидается, а не от того, сколько транзакций хранит любая из сторон, и объединение двух эскизов дает ровно те записи, которые есть у одного пира и отсутствуют у другого. Библиотека minisketch, которую Bitcoin Core годами несет в дереве исходного кода, пока протокол ретрансляции вокруг нее оставался неинтегрированным, реализует построение и декодирование.

Ошибка в оценке размера эскиза не является фатальной. Когда декодирование не удается, потому что различие оказалось больше предполагаемого, пиры расширяют эскиз и пытаются снова, а не начинают с нуля, поэтому плохая оценка стоит немного дополнительной пропускной способности, а не полной ресинхронизации.

Где это видно

Erlay пока не видно, и это честный ответ для того, кто ищет его на панели узла.

Что видно, так это проблему, на которую он нацелен. Вызовите getnettotals на своем узле, и счетчики байтов покажут, что трафик ретрансляции преобладает над всем, кроме начальной загрузки цепочки. Операторы на тарифицируемых соединениях уже реагируют, ограничивая отдачу с помощью maxuploadtarget или сокращая число пиров, которых они держат, и оба решения немного ослабляют сеть, чтобы снизить счет.

Это та дилемма, которую Erlay призван устранить. Если бы пропускная способность перестала расти с числом соединений, узел мог бы без риска держать гораздо больше пиров, а плотно связанную сеть гораздо труднее разделить или изолировать атакой eclipse. Для того, кто заинтересован только в проверке собственных биткоинов, а не в доверии обозревателю блоков, обещание узкое и реальное: та же проверка через более дешевое соединение.

Erlay vs ретрансляция компактных блоков

Erlay касается транзакций до того, как они включены в блок; ретрансляция компактных блоков касается блоков после этого. Эти два механизма устраняют разные узкие места, и судили о них по разным часам. Распространение блоков является проблемой задержки, потому что каждая секунда, которую блок проводит в пути, является секундой, которую какой-то майнер тратит на работу над вершиной цепочки, которой больше не существует, и исправление вышло в 2016 году. Объявление транзакций является проблемой объема, который измеряется гигабайтами за месяц, а не миллисекундами, поэтому никто не торопился, и именно поэтому предложение годами остается черновиком.