MSG_CMPCT_BLOCK

Компактные блоки согласуются, а не анонсируются. Пир один раз отправляет sendcmpct, чтобы сообщить, что будет их принимать, и только после этого другая сторона может ответить на новый блок типом 4 вместо типа 2. BIP152 появился вместе с Bitcoin Core 0.13.0 в августе 2016 года, и экономия составляет весь смысл: шесть байтов, чтобы назвать транзакцию, которая у получателя уже есть, вместо двухсот и более байтов, которые нужны, чтобы передать ее дважды.

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

MSG_CMPCT_BLOCK запрашивает описание блока вместо самого блока, и такое описание имеет смысл, только когда у двух узлов похожие пулы памяти.

Сначала идет согласование. Сообщение sendcmpct несет флаг и номер версии: версия 1 идентифицирует транзакции по txid, версия 2 по witness txid, и она единственная используется после segregated witness. Узел не должен никогда помещать тип 4 в getdata пиру, который не отправлял sendcmpct, потому что такой пир не обязан его понимать.

Ответ представляет собой сообщение cmpctblock, содержащее заголовок из 80 байтов, восьмибайтовый nonce, один шестибайтовый короткий идентификатор на каждую транзакцию и несколько транзакций, переданных полностью, всегда включая coinbase, которую получатель никак не мог видеть раньше. Короткие идентификаторы создаются с помощью SipHash с ключом из заголовка и этого nonce, поэтому они различаются для каждого блока и каждого запроса. Рандомизация служит защитой: фиксированная схема позволила бы атакующему заранее вычислить две транзакции с коллизией и разом сорвать реконструкцию по всей сети.

Получатель сопоставляет идентификаторы со своим пулом памяти, запрашивает недостающее с помощью getblocktxn и собирает блок локально. Последующая проверка обычная, и ни одно правило консенсуса не затрагивается.

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

Где это видно

Нагляднее всего MSG_CMPCT_BLOCK виден в собственном журнале Bitcoin Core, который сообщает, насколько успешно прошла каждая реконструкция.

Запустите узел с -debug=cmpctblock, и каждый новый блок будет порождать строку с указанием того, сколько транзакций было предзаполнено, сколько найдено в пуле памяти и сколько пришлось загрузить. На машине, которая работает уже несколько часов, число загруженных обычно равно нулю, и блок приходит размером в десятки килобайт, а не в полтора мегабайта. Блоку с 3000 транзакциями нужно 18 000 байтов коротких идентификаторов плюс заголовок и coinbase.

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

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