Проект Bitcoin Core полностью принял BIP152 под названием Compact Block Relay - обновление, которое уменьшит объем информации, используемой для распространения новых блоков полными узлами. Это позволит сократить количество времени, необходимое блоку для распространения по всей сети биткоина.
Обновление содержит несколько методов для уменьшения времени распространения блока по сети. Общая идея заключается в возможности воспользоваться тем, что полные узлы имеют схожие данные в пулах памяти (mempool), хранящих неподтвержденные транзакции. Таким образом, узел может отправить только эскиз блока своим пирам, которые затем создают его заново у себя, что позволит сэкономить полосу пропускания, так как блок не должен передаваться в полном виде. Эскиз будет содержать 80-байтовый заголовок нового блока и укороченные идентификаторы транзакций.
Команда Bitcoin Core пишет в FAQ по BIP152:
"Преимущество этого подхода состоит в том, что операции необходимо провести только один раз, обеспечив значительное увеличение общей пропускной способности."
Контрольные показатели перехода
Обновление также имеет новую функцию - режим с высокой пропускной способностью, в котором узлы могут запросить тот же блок в нескольких аналогах в сети, чтобы уменьшить время ожидания за счет более высокой пропускной способности канала.
Контрольные показатели этого нового метода выставлены так, что типичный полный блок в 1 МБ, содержащий в среднем 2500 транзакций, может быть передан всего с 15 KB данных, то есть 86% объема этих блоков будет распространяться сразу без необходимости второго запроса для любых других недостающих операций.
Команда Core говорит, что это улучшение принесет пользу всей сети:
"Уменьшение времени распространения блока в сети P2P создает более здоровую сеть с базовым запасом прочности."
BIP152 уже имеет рабочую реализацию и в настоящее время тестируется сообществом разработчиков. Будущие планы по улучшению BIP152 могут включать в себя замену протокола TCP на UDP, а также с использованием механизма коррекции ошибок для обработки пропущенных пакетов. В целом, эти улучшения всегда приветствуются, поскольку они помогут биткоину быть более надежным.
Эскизы блоков включают следующую информацию:
- 80-байтовый заголовок нового блока
- Укороченные идентификаторы транзакций (txids), которые предназначены для предотвращения отказа в обслуживании (DoS) атаки
- Некоторые полные транзакции
Принимающая сторона затем восстанавливает весь блок, используя полученную информацию, но уже в своем пуле памяти. Если у него по-прежнему не хватает каких-либо операций, он будет запрашивать их у передающего партнера.
Кроме того, предложение Compact Block Relay обеспечивает второй режим работы, где принимающий узел запрашивает некоторые из узлов отправить новые блоки непосредственно, не спрашивая разрешения, что может увеличить пропускную способность и уменьшает время, которое требуется на передачу блоков в соединениях с высокой пропускной способностью.
На приведенной ниже диаграмме показано, каким образом узлы в настоящее время отправляют блоки по сравнению с Compact Block Relay.
Ретрансляция с высокой пропускной способностью
Узел B использует sendcmpt (1), чтобы сообщить узлу А, что он хочет получить блоки как можно скорее. Когда приходит новый блок, узел выполняет некоторую базовую проверку (например, проверку заголовка блока), а затем автоматически начинает посылать заголовок, укорачивая txids, на узел B. Узел B пытается реконструировать блок и запрашивает некоторые транзакции из блока. На заднем плане оба узла завершают полную проверку блока перед добавлением его в свои локальные копии блокчейна, сохраняя полную консистентность узла, как и прежде.
Ретрансляция с низкой пропускной способностью
Узел B используетsendcmpt (0) для сообщения узлу А, что он хочет свести к минимуму использование полосы пропускания. Когда приходит новый блок, узел полностью проверяет его (поэтому он не ретранслирует недопустимые блоки). Затем он запрашивает узел B, хочет ли он получить блок, и если узел В уже получил блок от другого партнера, он может избежать повторной загрузки.
Если узел B действительно хочет получить блок, он запрашивает об этом в компактном режиме (GetData (CMPCT)) и узел А отправляет заголовок, короткие txids и предсказывает недостающие транзакции. Узел B пытается восстановить блок, запрашивает некоторые транзакции, и узел А посылает их. Узел B затем полностью проверяет блок в обычном режиме.
Средний полный блок в 1МБ может быть восстановлен с помощью эскиза, плюс 9 Кбайт накладных расходов для каждой операции в блоке, который не находится в mempool принимающего узла.
