Глоссарий / Справочник разработчика
MSG_BLOCK
- Что такое MSG_BLOCK?
- MSG_BLOCK является типом инвентаря 2, кодом, который узел помещает в сообщение getdata, чтобы запросить у пира целый блок по его хешу.
Четыре байта тега типа решают, какой из нескольких форматов блока придет. Тип 2 означает исходный: заголовок размером 80 байт, за которым следуют все транзакции целиком, без данных свидетеля, в пределах четырех миллионов весовых единиц, которые может вместить блок. Узел, догоняющий цепочку, отправляет тысячи таких запросов и почти ничего больше.
Как это работает
MSG_BLOCK является числом, а не сообщением, и имеет смысл только внутри записей размером 36 байт, из которых строятся сообщения inv и getdata.
Запись состоит из типа в четыре байта и хеша в 32 байта, и тип сообщает получателю, что именно обозначает хеш. Отправка getdata с записью типа 2 означает: у меня есть хеш этого блока, пришлите мне блок. Пир отвечает одним сообщением block или сообщением notfound, если не может его предоставить. Пруненный узел возвращает notfound для всего, что уже удалил, поэтому от пруненного пира нет пользы тому, кто синхронизируется с нуля.
Сам по себе тип 2 теперь означает более узкую вещь, чем раньше. С момента активации segregated witness в 2017 году запрошенный так блок приходит в старой сериализации без данных свидетеля, что было необходимо, чтобы по-прежнему обслуживать старое программное обеспечение. Любому узлу, который намерен проверить блок, нужны эти свидетели, поэтому он устанавливает бит 0x40000000 и запрашивает вместо этого вариант со свидетелем. Между двумя современными пирами простой код встречается в основном в запросах от программного обеспечения, которое никто не обновлял.
Анонсирование тоже изменилось. BIP130 ввел прямой анонс заголовков, и с версии Bitcoin Core 0.12.0 новый блок обычно анонсируется сообщением headers, а не сообщением inv, поэтому этот код типа теперь живет в основном на запрашивающей стороне разговора.
Bitcoin Core не забегает вперед без ограничений во время загрузки. Он держит окно в 1024 блока после последнего проверенного, поэтому один застрявший пир не может оставить узел с неограниченной очередью блоков, которые тот не в состоянии присоединить.
Где это видно
Запросы блоков преобладают в трафике узла ровно один раз, во время первой синхронизации, а затем почти никогда.
Цепочка перешагнула 840 000 блоков на халвинге 20 апреля 2024 года и растет примерно на 144 блока в день, поэтому машина, начинающая с нуля, загружает около миллиона блоков, прежде чем догонит ее. Это можно наблюдать с помощью getpeerinfo, который считает байты по каждому типу сообщений для каждого пира, или в журнале с параметром -debug=net. Когда узел достигает вершины цепочки, эти счетчики замолкают, и трафик компактных блоков берет верх.
MSG_BLOCK vs MSG_CMPCT_BLOCK
MSG_BLOCK и MSG_CMPCT_BLOCK различаются как местом, где они допустимы, так и тем, что они загружают. Тип 2 допустим в сообщении inv и в getdata, может отправляться любому пиру без предварительной договоренности и работает для блока любого возраста. Тип 4 допустим только в getdata, может отправляться только пиру, который уже предложил компактные блоки сообщением sendcmpct, и в Bitcoin Core обслуживается только для пяти последних блоков. Запросите что-то более глубокое с типом 4, и полноценное сообщение block все равно придет в ответ.