Синхронизация blocks-first

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

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

Статус: синхронизация blocks-first была вытеснена синхронизацией headers-first в Bitcoin Core 0.10.0, выпущенном 16 февраля 2015 года. Использовавшиеся ею сообщения по-прежнему входят в одноранговый протокол и по-прежнему получают ответ, но ни один современный клиент не полагается на них, чтобы догнать сеть.

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

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

Синхронизация headers-first решила все три проблемы, отделив дешевые доказательства от дорогих. Сначала загрузите и проверьте цепочку заголовков, которая на декабрь 2014 года занимала 27 мегабайт для всей истории, и вы узнаете и форму лучшей цепочки, и ее длину еще до загрузки хотя бы одной транзакции. После этого тела блоков можно запрашивать сразу у многих пиров. Побочным следствием стало то, что блоки начали приходить не по порядку и записываться на диск не по порядку, поэтому каталог данных, созданный версией 0.10.0, не может прочитать ни одна более старая версия.

Где это встречается

Синхронизацию blocks-first вы встретите в документации, а не в программном обеспечении.

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

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

Синхронизация blocks-first vs синхронизация headers-first

Синхронизация blocks-first и синхронизация headers-first различаются тем, что запрашивают первым, а все остальное из этого следует. Синхронизация blocks-first запрашивала полные блоки по порядку и узнавала форму цепочки по ходу дела, поэтому она находила лучшую цепочку и загружала ее за один и тот же медленный проход. Синхронизация headers-first разделяет работу: сначала устанавливается, какая цепочка несет больше всего доказательств работы, по 80 байт на блок, а затем тела блоков собираются параллельно у всех, кто готов их отправить. Проверка, применяемая к каждому блоку, в обоих случаях одна и та же. Изменился порядок действий, и одного этого хватило, чтобы начальная синхронизация сократилась с недель до часов.