Узел Bitcoin: синхронизация, индексы и pruning
Собственный узел полезен библиотеке только при понятном состоянии синхронизации и хранения. В уроке разделим проверку истории, хранение старых блоков и дополнительные индексы. Это помогает выбрать профиль наблюдения и не считать любой локальный ответ полной историей кошелька.
Справочник в серии закреплён на Bitcoin Core 31.0. Мы не устанавливаем эту версию, не скачиваем цепочку и не измеряем требования машины. Численные оценки ресурсов зависят от сети и даты, поэтому вместо выдуманного объёма зададим функции, которые действительно нужны проекту.
Узел догоняет историю
После первого старта узел получает и проверяет данные. Пока он не достиг актуального состояния, ответ о вершине относится к имеющейся локальной истории. Отсутствие вчерашнего платежа на таком источнике не доказывает отсутствие платежа в сети.
Для библиотеки наблюдатель должен сохранять состояние синхронизации и время успешной сверки. В карточке счёта нельзя использовать старую вершину как свежую. Если источник догоняет сеть, показываем задержку данных и не переписываем принятые платежи ложным отсутствием.
Проверка цепочки и кошельковое сканирование также различаются. Узел может знать актуальные блоки, а недавно импортированный дескриптор ещё требует обработки старой истории. Эти процессы дают разные признаки готовности. Один зелёный индикатор соединения не описывает оба.
Что хранит полный архив
Архивный профиль сохраняет старые блоки в пределах выбранной конфигурации. Это полезно для повторного сканирования кошелька от ранней точки и для некоторых запросов. Однако наличие блоков само по себе не создаёт любой удобный поиск по адресам.
Для поиска произвольной транзакции может потребоваться соответствующий индекс либо известный блок и подходящий метод. Кошельковые RPC предоставляют историю конкретного набора, а не универсальный поиск всего блокчейна по любому адресу. Поэтому веб-приложение не должно обещать возможности, которых профиль не включает.
В библиотеке большинство задач связано с собственными назначениями. Кошельковый журнал и наблюдающий набор могут быть достаточны для этого маршрута. Дополнительный индекс выбирается по реальному запросу, а не потому, что слово «индекс» звучит полезно.
Pruning
Сокращённое хранение позволяет удалять часть старых блоковых данных после проверки, сохраняя необходимое состояние. Это не означает, что узел перестаёт проверять полученную историю по своей модели. Но возможности дальнейшего локального повторного обращения к удалённым блокам ограничиваются.
Для библиотеки ключевой вопрос — восстановление новых или расширенных дескрипторов. Если нужные старые блоки отсутствуют, простой rescan от давней точки может потребовать другого маршрута получения. Текущие известные UTXO не заменяют полную историю уже израсходованных поступлений.
| Потребность | Что нужно уточнить |
|---|---|
| Текущая вершина | Синхронизация и сеть |
| Собственные поступления | Кошелёк, диапазон, сканирование |
| Исторический повтор | Наличие блоков или восстановительный источник |
| Произвольный поиск | Поддержка метода и соответствующего индекса |
Не обещаем, что один переключатель prune совместим с любой заранее выбранной комбинацией индексов и исторических задач. Возможности и ограничения сверяем в конфигурации конкретной версии. Особенно опасно применять старую инструкцию с другими параметрами без чтения встроенной справки.
Отдельный каталог данных
Для будущей regtest-лаборатории нужен отдельный datadir. Он отделяет блоки, настройки, кошельки и журналы учебного окружения от других сетей. Явный параметр должен присутствовать как при запуске процесса, так и при обращении клиента, чтобы команда не попадала к неожиданному источнику.
Внутри досье сохраняем путь как организационный параметр, но не публикуем реальный домашний путь с секретным материалом. Для инструкций удобен относительный локальный каталог проекта. Доступ к нему ограничивается средствами операционной системы и процесса.
Открывать RPC наружу ради удобства браузера не требуется. Сайт использует внутренний адаптер, а браузер обращается к прикладному API. Хранение большого объёма блоков не меняет этой границы полномочий и не делает управление узлом общедоступным.
Готовность данных
Наблюдатель фиксирует сеть, вершину с хешем, состояние проверки и время ответа. Для кошелька дополнительно известны загруженные дескрипторы, диапазоны и этап исторической обработки. Для индексов — состояние их готовности, если приложение от них зависит.
После перезапуска возможны задержки загрузки и восстановления внутренних структур. Тайм-аут не должен обнулять денежные наблюдения. Сервис сохраняет последнюю успешную точку и отдельно сообщает, что новые сведения пока неизвестны.
Если два источника расходятся, сначала сравниваем сеть и хеши истории. Высота одинаковой цифры не гарантирует совпадение ветви. Не усредняем количество подтверждений как случайные измерения: речь идёт о конкретной выбранной цепочке.
План восстановления
Выбор хранения должен сопровождаться описанием того, откуда восстановить историю при потере узла. Для библиотеки сохраняются кошельковая политика и прикладная база независимо от блокового каталога. Переустановка узла способна вернуть сетевые данные, но не восстановит номер счёта по адресу без журнала приложения.
Уточнение исторического запроса
Если оператор хочет восстановить оплату, которая уже израсходована, проверка одного текущего gettxout может вернуть отсутствие выхода. Это не доказывает, что первоначального поступления не было. Нужен исторический контекст через кошелёк, доступный блок или соответствующий источник. Восстановительное требование сначала формулируется как вопрос: текущая доступность, факт получения или коммерческое решение. Затем выбирается метод. Иначе приложение пытается получить историю из интерфейса состояния и ошибочно обнуляет старые заказы.
По тому же принципу индекс не делает источник доверенным автоматически. Он облегчает поиск по проверенным данным выбранного узла. Сетевой контекст и свежесть результата всё равно сохраняются вместе с ответом.
Запишем конкретное требование источнику: показать поступление по адресу счёта и его положение в выбранной истории. Ответ только о текущем неизрасходованном выходе покрывает более узкий вопрос. В досье указываем этот пробел заранее, чтобы изменение способа хранения узла не оказалось неожиданной потерей функции сверки старых заказов.
Документация профиля приведена в репозитории Core 31.0, а данные состояния — в getblockchaininfo. Результат урока — перечень требований к источнику. Он позволяет осознанно выбрать архив, pruning и индексы, сохранив отдельные критерии готовности для платежного сервиса.