Где находится сервер обработки биткоин транзакций
Эта страница описывает, как и где Bitcoin Core хранит блокчейн-данные.
Общие сведения
Есть в основном четыре части данных. Которые поддерживаются:
blocks/blk*.dat: фактические Биткойн-блоки в сетевом формате сбрасываются в raw на диск. Они необходимы только для повторного сканирования отсутствующих транзакций в кошельке. Реорганизации в другую часть цепочки и передачи данных блока другим узлам. Которые синхронизируются. blocks/index/*: это база данных LevelDB. Которая содержит метаданные обо всех известных блоках и о том. Где их найти на диске. Без этого поиск блока будет очень медленным.
chainstate/*: это база данных LevelDB с компактным представлением всех в настоящее время неизрасходованных выходных данных транзакций и некоторыми метаданными о транзакциях. Из которых они исходят. Данные здесь необходимы для проверки новых входящих блоков и транзакций. Теоретически его можно перестроить из блочных данных (см. параметр командной строки-reindex). Но это занимает довольно много времени. Без него вы все еще могли бы теоретически провести валидацию. Но это означало бы полное сканирование блоков (7 ГБ по состоянию на май 2013 года) для каждого потраченного вывода. blocks/rev*.dat: они содержат данные Вы можете видеть блоки как Они необходимы для отката цепного состояния. Которое необходимо в случае реорганизации.
Обратите внимание, что базы данных LevelDB являются избыточными в том смысле. Что они могут быть перестроены из блочных данных. Но без них валидация и другие операции стали бы невыносимо медленными.
Необработанные блочные данные (blk*.dat)
Файлы блоков хранят необработанные блоки в том виде, в каком они были получены по сети.
Блочные файлы составляют около 128 МБ, выделенные в 16 МБ фрагментами. Чтобы предотвратить чрезмерную фрагментацию.
По состоянию на октябрь 2015 года цепочка блоков хранится примерно в 365 блочных файлах. В общей сложности около 45 ГБ.
Каждый блок-файл (blk1234.dat) имеет соответствующий файл отмены (rev1234.dat). Который содержит данные. Необходимые для удаления блоков из блокчейна в случае реорганизации (форка).
Информация о файлах блоков хранится в индексе блоков (LevelDB) в двух местах:
- Общая информация о самих файлах хранится в записях
- Количество блоков. Хранящихся в файле
- Размер файла (и соответствующий размер файла отмены)
- Самый низкий и самый высокий блок в файле
- Метки времени — более ранние и последние блоки в файле
- Информация о том. Где найти конкретный блок на диске. Находится в записи
- Каждый блок содержит указатель на блок. Находящийся на диске (номер файла и смещение)
Доступ к файлам данных блока из кода
Доступ к блочным файлам осуществляется через:
1) DiskBlockPos: структура. Которая является просто указателем на местоположение блока на диске (номер файла и смещение.)
2) vInfoBlockFiles: вектор объектов BlockFileInfo. Эта переменная используется для выполнения таких задач, как:
- Определите, могут ли новые блоки поместиться в текущий файл или необходимо создать новый файл
Блоки записываются на диск сразу же после их получения. В AcceptBlock. (Фактическая операция записи на диск находится в WriteBlockToDisk [main.cpp:1164]). Обратите внимание, что существует некоторое перекрытие кода. Который обращается к блочным файлам, с кодом. Который обращается и записывает в базу данных монет (/chainstate). Существует сложная система, когда нужно сбросить состояние на диск. Ни один из этих кодов не влияет на блочные файлы. Которые просто записываются на диск при получении.
После того, как они были получены и сохранены. Файлы блоков необходимы только для обслуживания блоков на других узлах.
Более подробная информация о файлах блоков
Индекс блока (leveldb)
Индекс блока содержит метаданные обо всех известных блоках, в том числе о том. Где блок хранится на диске.
Обратите внимание, что набор
Терминология здесь может быть немного запутанной, потому что в то время как люди обычно думают о
а) дерево блоков
Лучшим термином для набора известных блоков. Хранящихся на диске, является Действительно. Доступ к индексу блока LevelDB осуществляется через класс-оболочку src/txdb.h. Обратите внимание, что это совершенно нормально, действительно ожидается. Что разные узлы будут иметь немного разные деревья блоков; важно то. Что они согласуются в активной цепочке.
Внутри фактического LevelDB используемые пары ключ/значение:
Уровень Доступа К Данным
Доступ к базе данных осуществляется через класс-оболочку CBlockTreeDB. См. txdb.h.
Оболочка создается в глобальной переменной pblocktree, определенной в main.cpp.
Блоки, хранящиеся в базе данных, представляются в памяти как объекты CBlockIndex.
Объект этого типа сначала создается после получения заголовка; код не ждет получения полного блока. Когда заголовки принимаются по сети, они передаются в вектор CBlockHeaders. Которые затем проверяются. Каждый проверяемый заголовок вызывает создание нового CBlockIndex. Который сохраняется в базе данных.
Обратите внимание, что эти объекты имеют мало общего с /blocks LevelDB. CBlock содержит полный набор транзакций в блоке. Данные для которых хранятся в двух местах — в полном виде. В формате raw. В файлах blk. dat и в обрезанном формате в
базе данных UTXO. База данных индексов блоков не заботится о таких деталях. Поскольку она содержит только метаданные для блока.
Загрузка базы данных блоков в память
Вся база данных загружается в память при запуске. См. раздел LoadBlockIndexGuts (txdb.cpp). Это займет всего несколько секунд.
Блоки (ключи’b’) загружаются в глобальную переменную
mapBlockIndex более подробно описан в главе 6 — блокчейн.
Метаданные блочного файла (ключи’f’) загружаются в файлы vInfoBlockFiles.
Набор UTXO (chainstate leveldb)
База данных UTXO была введена в 2012 году в
Допустим, у вас есть транзакция T1, которая принимает два входа и отправляет на 3 выхода: O1,O2,O3. Два из этих выходов (O1, O2) были использованы в качестве входных данных в более поздней транзакции T2. как только T2 был добыт. T1 имеет только один предмет интереса (O3). Нет никаких причин держать T1 в полном объеме. Вместо этого будет достаточно уменьшенной версии T1, состоящей только из O3 (locking script и amount) и определенной базовой информации о T1 (высота. Является ли это coinbase и т. д.)
Описание ultraprune находится на конкретной фиксации
————- Это переключает логику проверки транзакций/блоков биткойна на использование
Название ultraprune происходит от того. Что вместо полного индекса транзакций мы только (должны) хранить индекс с неизрасходованными выходами. Пока что сами блоки хранятся как обычно, хотя они необходимы только для обслуживания. Повторного сканирования и реорганизации. Основными структурами данных являются CCoins (представляющие монеты одной транзакции) и CCoinsView (представляющие состояние базы данных монет). Существует несколько реализаций CCoinsView. Манекен, один из которых поддерживается базой данных монет (coins.dat), один-пулом памяти. А другой — добавлением кэша поверх него.
FetchInputs, ConnectInputs, ConnectBlock, DisconnectBlock. … теперь работают на универсальном CCoinsView. Логика переключения блоков теперь создает единый кэшированный CCoinsView с изменениями. Которые должны быть зафиксированы в базе данных до внесения каких-либо изменений. Это означает. Что незафиксированные изменения никогда не считываются из базы данных и должны облегчить переход на другой уровень базы данных. Который не поддерживает транзакции (но поддерживает атомарную запись). Например LevelDB. Для вызова getrawtransaction() RPC предпочтительнее доступ к индексу txid-to-disk.
Поскольку этот индекс не является необходимым или даже полезным для какой-либо другой части реализации. Он не предусмотрен. Вместо этого getrawtransaction() использует базу данных coin для поиска высоты блока. А затем сканирует этот блок для поиска запрошенной транзакции. Это медленно, но должно быть достаточно для отладки. ——————
В просторечии это называется По этой причине базу данных UTXO иногда называют
Эти термины более или менее синонимичны и используются взаимозаменяемо.
Доказуемо неоправданная монета может быть исключена из базы данных utxo независимо от ее количества.
Записи в базе данных chainstate levelDB следующие:
Уровень доступа к данным и кэширование
Доступ к базе данных UTXO значительно сложнее, чем к блочному индексу. Это происходит потому. Что его производительность имеет решающее значение для общей производительности Биткойн-системы. Индекс блоков не так критичен для производительности. Потому что существует всего несколько сотен тысяч блоков, и узел. Работающий на приличном оборудовании. Может получить и прокрутить их за несколько секунд (и не нужно делать это очень часто.) С другой стороны. В базе данных UTXO есть миллионы монет. И они должны быть проверены и изменены для каждого входа каждой транзакции. Входящей в mempool или включенной в блок.
Как сказал сипа в сверхпроводящем коммите:
Основными структурами данных являются CCoins (представляющие монеты одной транзакции) и CCoinsView (представляющие состояние базы данных монет). Существует несколько реализаций CCoinsView. Манекен, один из которых поддерживается базой данных монет (coins.dat), один-пулом памяти. А другой — добавлением кэша поверх него.
Однако это изложено не так ясно, как могло бы быть; по крайней мере. Не для текущего состояния кодекса.
В 0.11 экземпляры CoinsView являются:
- манекен
- База данных
- pCoinsTip (кэш, поддерживаемый базой данных)
Отдельно от этой цепочки кэшей находится CoinsView пула памяти. Который поддерживается базой данных.
Диаграмма классов (типы данных) для представлений:
Каждый класс имеет одну ключевую характеристику:
- View-это базовый класс, объявляющий методы проверки существования монет (HaveCoins). Извлечения монет (GetCoins) и т. д.
- ViewDB имеет код для взаимодействия с LevelDB.
- ViewBacked имеет указатель на другое представление; таким образом, он
- ViewCache имеет кэш (карту CCoins).
- ViewMempool связывает mempool с представлением.
Это определенные классы; в то время как объектная диаграмма:
Вот таблица. Суммирующая экземпляры представлений:
| Объект | Тип | При Поддержке? | Описание / Назначение |
|---|---|---|---|
| Вид БД | ViewDB | n/a | Представляет набор UTXO в соответствии с уровнем /chainstate LevelDB. Извлекает монеты и сбрасывает изменения в LevelDB. Creation в коде (создание экземпляра): см. init.cpp:1131 |
| pCoinsTip (блокчейн-кэш) | ViewCache | Вид БД | Удерживает набор UTXO. Соответствующий наконечнику активной цепи. Извлекает/сбрасывает в представление базы данных. Создание в коде: см. init.cpp:1133 |
| Кэш проверки | ViewCache | pCoinsTip | Срок службы этого кэша находится в пределах ConnectTip (или DisconnectTip). его цель состоит в том. Чтобы отслеживать изменения в наборе UTXO во время обработки блока. если блок проверяется. Кэш сбрасывается в pcoinsTip. если блок выходит из строя. Кэш отбрасывается. Создание в коде: см. main.cpp:2231: CCoinsViewCache view(pcoinsTip); |
| Вид Mempool | ViewMemPool | pCoinsTip | Этот объект выводит mempool в поле зрения. То есть он может видеть как набор UTXO. Так и mempool. Его цель-обеспечить валидацию цепочек транзакций. То есть транзакций с (Если цепочки сделок не допускаются. В mempool можете просто проверка в отношении pcoinsTip.) Таким образом. При запросе. Он может проверить. Является ли данный вход может быть найден либо в mempool (т. е. Обратите внимание, что этот объект не находится в кэше; скорее, это вид. Который используется объектов ниже. Которая содержит кэш. Создание в коде: его время жизни равно времени жизни AcceptToMemoryPool in main.cpp. |
| Кэш Mempool | ViewCache | Вид Mempool | Кэш для mempool. Он содержит кэш и устанавливает его бэкэнд в качестве представления mempool. Создание в коде: его время жизни также совпадает с временем жизни AcceptToMemoryPool в коде. main.cpp. |
Загрузка набора UTXO
Доступ к базе данных монет инициализируется в init.cpp: 1131-1133:
Код начинается с инициализации CoinsViewDB, который оснащен методами загрузки монет из LevelDB.
Ловец ошибок — это небольшой хак, который можно игнорировать.
Затем код инициализирует pCoinsTip, который является кэшем. Представляющим состояние активной цепочки. И поддерживается представлением базы данных.
Кэш против База данных
Функция FetchCoins в coins.cpp демонстрирует, как код использует кэш. база данных:
Во-первых, код ищет в кэше монеты для данного идентификатора транзакции. (строка 1)
если он найден. То возвращает (строки 2-3)
если нет. То он ищет в базе данных. (строка 5)
если он найден в базе данных. Он обновляет кэш. (строка 7)
Примечание: если бэкэнд кэша-это другой кэш, то термин
Очистка Кэша проверки в кэш блокчейна
Кэш проверки сбрасывается в кэш блокчейна после подключения блока, как раз перед тем. Как он выходит из области действия. Область действия захватывается в ConnectTip и, в частности, в блоке кода main.cpp: 2231-2243. В этом блоке кода происходит вызов ConnectBlock. Во время которого код сохраняет новые монеты в кэше проверки. (В частности, см. UpdateCoins() в разделе main.cpp.) В конце блока кода кэш проверки сбрасывается. Поскольку его (Полиморфизм в действии: позже. Когда кэш блокчейна будет сброшен в представление базы данных. Код запустит CoinsViewDB::BatchWrite, последняя строка которого записывается в LevelDB.)
Таким образом, использование кэша проверки является простым: он создается, используется. Сбрасывается и выходит за рамки вышеупомянутого блока кода.
Очистка Кэша блокчейна в базу данных
Очистка кэша проверки была простой. Потому что код только перетасовывал элементы между двумя кэшами в памяти (о которых никто не знает за пределами кода кэширования.) Очистка кэша блокчейна в базу данных немного сложнее. На самом низком уровне механика очистки кэша блокчейна (pcoinsTip) такая же. Как и кэш проверки: метод Flush() вызывает BatchWrite на своем бэкэнде (указатель Выше уровня Flush() вызывается из FlushStateToDisk (FSTD) — main.cpp:2098. FlushStateToDisk вызывается в нескольких разных точках с заданным режимом:
| Режим Промывки | Описание | Когда звонили |
|---|---|---|
| IF_NEEDED | Промыть только в том случае. Если кэш превышает свой предельный размер. | Сразу после подключения (или отключения) блока и промывки кэша проверки. См. Раздел ConnectTip / DisconnectTip. |
| ВСЕГДА | Смыть кэш. | Только во время инициализации. |
| Периодические | Здесь код рассматривает другие точки данных, чтобы решить. Следует ли сбрасывать их. Неужели код почти превысил свой предельный размер? Прошло много времени с тех пор, как тайник был смыт? Если да, то продолжайте. | В конце ActivateBestChain() (комментарий кода: |
Идея состоит в том. Чтобы часто очищать кэш блоков (чтобы избежать необходимости загружать большое количество блоков в случае сбоя программы). Но кэш монет нечасто (чтобы максимизировать выгоду от кэша монет.)
В частности, кэш блоков гарантированно очищается один раз в час. А кэш монет-один раз в день. (См. здесь: комментарий Sipa к PR 6102)
Код FlushStateToDisk хорошо прокомментирован. Так что для получения дополнительной информации любопытный читатель может проверить main.cpp.
Необработанные данные отмены (rev*.dat)
Данные отмены содержат информацию, необходимую для отключения или
Таким образом. Записываемые данные по существу представляют собой набор объектов CTxOut. (CTxOut-это просто сумма и скрипт — см. primitives/transaction.h:107-108).
Дело немного осложняется тем, что если монета является последней потраченной транзакцией, то данные отмены должны хранить метаданные транзакции (высота блока txn, будь то coinbase и ее версия.) Итак, если у вас есть транзакция T с выходами O1,O2,O3, потраченными в этом порядке. То для O1 и O2 все. Что будет записано в файл отмены. — это сумма и сценарий. Например, файл отмены будет содержать сумму, сценарий, а также высоту и версию T, а также то. Является ли T coinbase.
Данные отмены записываются в необработанный файл со следующим кодом:
Эта строка кода вызывает функцию сериализации на CBlockUndo. Которая в основном представляет собой просто вектор монет (CTX).) Наконец. Контрольная сумма записывается в файл отмены. Контрольная сумма используется во время инициализации, чтобы убедиться. Что все проверяемые данные отмены не повреждены. См. Тянуть 2145
Данные отмены используются при отключении блока. Код DisconnectBlock() обсуждается далее на этой вики-странице в блокчейне: реорганизации.
Использование LevelDB
LevelDB-это хранилище ключей и значений. Которое было введено для хранения индекса блока и набора UTXO (chainstate) в 2012 году в рамках комплекса Смотрите здесь: 27 коммитов на Ultraprune.
На вопрос о том, почему используется LevelDB. Основной разработчик Грег Максвелл заявил следующее в списке рассылки bitcoin-dev в октябре 2015 года:
Можно спросить. Могут ли разные узлы использовать разные базы данных — если они извлекают одни и те же данные. В чем разница? Проблема здесь заключается в совместимости
..[D]атабазы иногда имеют ошибки, которые приводят к тому. Что они не возвращают записи или возвращают устаревшие данные. И если они существуют, то необходимо поддерживать согласованность; и Например, до использования leveldb в Bitcoin Core у него была ошибка. Которая в редких случаях могла привести к тому. Что он постоянно возвращал не найденные записи. Которые действительно были там … Leveldb исправил эту серьезную ошибку в незначительном обновлении. Но развертывание такого исправления неконтролируемым образом в сети биткойна потенциально может вызвать развилку в консенсусном состоянии; поэтому любое такое исправление должно быть развернуто упорядоченным образом.
Источник