Assumeutxo

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

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

Assumeutxo разделяет один узел на два состояния цепи (chainstate) и запускает их одновременно.

Вы передаете файл снимка вызову RPC loadtxoutset. Bitcoin Core создает второе состояние цепи, в которое его загружает, сохраняя исходное активным, пока содержимое читается и проверяется. Как только состояние цепи снимка загружено и проверено, оно становится активным, в каталоге данных появляется каталог chainstate_snapshot, и узел начинает синхронизацию от базового блока снимка к вершине сети. Внутри этого каталога лежит небольшой файл base_blockhash, в котором записано, на каком блоке был сделан снимок, поэтому такая конфигурация сохраняется после перезапуска.

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

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

Очистка происходит при следующем перезапуске, а не сразу. Core переименовывает chainstate_snapshot в chainstate, удаляет фоновые данные, и с этого момента узел неотличим от узла, построенного традиционным способом. Файл base_blockhash остается как запись о том, с чего он начал.

Почему это важно при покупке биткоина

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

Из 41 кошелька, рассмотренных на этом сайте, Bitcoin Core единственный, который сам скачивает и проверяет всю цепь, поэтому в нашем обзоре ему поставлена оценка 4,7 и при этом первым недостатком указано, что первая синхронизация скачивает и проверяет всю цепь, что требует многих часов и большого объема дискового пространства. Эта фраза и есть причина, по которой большинство людей никогда не пробует. Снимок не делает затраты исчезнувшими, он их переносит: часы все равно уходят, просто они уходят после того, как ваш кошелек уже работает, а не до этого.

Момент, когда это окупается, наступает при выводе. Вы покупаете на одной из 63 бирж, записанных здесь, отправляете биткоины на ключи, которые контролируете, и затем хотите знать, что они пришли. Без собственного узла спросить можно только две стороны: биржу, только что отправившую их, и публичный обозреватель блоков, который теперь знает ваш адрес. С собственным узлом ответ дает арифметика, выполненная вашей собственной машиной.

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

Практический пример: создание снимка с помощью dumptxoutset

Создание снимка assumeutxo представляет собой намеренную операцию на узле, которому вы уже доверяете, а не файл, который вы идете и скачиваете.

Его создает вызов RPC dumptxoutset, либо на текущей вершине с типом "latest", либо на недавней высоте с типом "rollback". Большую часть времени работы узел находится во временном состоянии, которое не отражает реальность, помечая недействительными блоки, о которых знает, что они в порядке, и из-за этого состояния сетевая активность отключается и все пиры отключаются. Документация Core рекомендует -rpcclienttimeout=0, потому что выгрузка занимает немало времени при любом оборудовании и при любом выбранном типе, и не советует трогать узел для чего-либо еще в это время.

Два обстоятельства застают людей врасплох. Снимок можно использовать, только если для его высоты уже указан хеш в параметрах цепи, поэтому выбор любой другой высоты означает изменение этого кода и повторную компиляцию, а тип "rollback" служит также способом проверить жестко зашитый хеш, создав снимок заново и сравнив. И Bitcoin Core 28.0 изменила сериализацию: выгрузки в старом формате больше не поддерживаются, и их нужно создать заново на узле 28.0 или более поздней версии, прежде чем loadtxoutset их примет.

Bitcoin Core 29.0 добавила связанный инструмент contrib/utxo-tools/utxo_to_sqlite.py, который преобразует снимок в компактной сериализации в базу данных SQLite3. Это не имеет отношения к синхронизации узла и полностью связано с тем, чем на самом деле является снимок: полной, самодостаточной картиной того, кому что принадлежит на одной высоте, что, как оказывается, полезно запрашивать.

Assumeutxo vs начальная загрузка блоков

Assumeutxo не заменяет начальную загрузку блоков, он меняет порядок, в котором выполняется работа.

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

Assumeutxo vs прунинг узла

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

Прунинг касается диска после проверки: прунинг-узел проверяет каждый блок, а затем удаляет необработанные файлы, которые больше не нужны. Assumeutxo касается времени до проверки: он откладывает проверки, которые все равно выполнит. Эти два подхода сочетаются, и Core ради этого смягчает одно из своих собственных правил. Обычный минимум для -prune составляет 550 MiB, а узел, загружающий снимок, игнорирует этот минимум и использует вместо него не менее 1100 MiB. Место не единственная статья расходов: пока идет фоновая синхронизация, временно существуют два каталога состояния цепи, каждый размером в несколько гигабайт и, вероятно, растущий больше скачанного вами снимка.

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