Стандартная ретрансляция блоков

Два круга обмена сообщениями и мегабайт или больше на каждом шаге, причем ради данных, которые получатель по большей части уже имел. Измерение, проведенное в 2013 году, показало, что медианный узел узнает о новом блоке через 6,5 секунды после того, как блок найден, а среднее значение составляет 12,6 секунды. Bitcoin Core выпустил компактную ретрансляцию блоков в версии 0.13.0 23 августа 2016 года, и стандартная ретрансляция стала резервным вариантом.

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

Стандартная ретрансляция блоков использует три сообщения и ничего не предполагает о том, что уже есть у принимающего узла.

Нашедший блок отправляет сообщение inv с хешем нового блока или, с тех пор как в Bitcoin Core 0.12.0 появился BIP130, сообщение headers с 80-байтовым заголовком напрямую, что избавляет пира от отдельного круга обмена сообщениями getheaders. Получатель проверяет, есть ли у него этот блок. Если нет, он отвечает сообщением getdata. Затем отправитель передает сообщение block: заголовок, за которым следуют все транзакции в полной сериализации, в пределах бюджета в четыре миллиона весовых единиц, который ограничивает размер блока.

Потери очевидны, как только о них сказано. Узел, работающий уже несколько часов, держит в своем пуле памяти почти все транзакции этого блока, поскольку получал каждую из них по отдельности при ее рассылке. Стандартная ретрансляция отправляет их все второй раз. Для блока, заполненного обычными платежами, это заметно больше мегабайта избыточной передачи, на каждого пира и на каждый блок.

Последствия были не только эстетическими. Медленное распространение повышает долю устаревших блоков, потому что майнер, еще не узнавший о новом блоке, продолжает работать над прежней вершиной цепи. Устаревшие блоки обходятся мелким майнерам дороже, чем крупным, так как большой пул узнает о собственных блоках мгновенно. Поэтому более быстрая ретрансляция была аргументом в пользу децентрализации в той же мере, что и аргументом эффективности, и она дала толчок как BIP152, так и выделенным сетям ретрансляции, которые крупные пулы поддерживают между собой.

Стандартная ретрансляция никуда не исчезла. Она происходит, когда пир так и не согласовал компактные блоки, когда компактное восстановление не удается и недостающие транзакции нечем заполнить, а также на протяжении начальной загрузки блоков, когда синхронизирующийся узел запрашивает полные блоки сообщениями getdata у нескольких пиров одновременно, до шестнадцати запросов в работе на каждого пира в Bitcoin Core.

Где это видно

Стандартная ретрансляция блоков заметнее всего тогда, когда узел догоняет цепь, а не тогда, когда он уже догнал ее.

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

Стандартная ретрансляция блоков vs компактная ретрансляция блоков

Стандартная ретрансляция отправляет блок; компактная ретрансляция отправляет его описание и позволяет получателю восстановить остальное. Сообщение cmpctblock несет заголовок, nonce и шестибайтовый короткий идентификатор для каждой транзакции, поэтому блок с несколькими тысячами платежей можно описать менее чем в двадцать килобайт вместо более чем мегабайта. Получатель сопоставляет эти идентификаторы со своим пулом памяти, запрашивает недостающее сообщением getblocktxn и собирает блок локально. Последующая проверка остается такой же: компактная ретрансляция меняет то, как приходят байты, но никогда не меняет того, что считается действительным блоком.