Публичные блокчейны, примером которых являются Bitcoin и Ethereum, произвели революцию в децентрализованных системах, но сталкиваются с серьёзной критикой из-за своей ресурсоёмкости. В то время как энергопотребление консенсуса Proof-of-Work (PoW) широко обсуждается, значительные и растущие накладные расходы на хранение, требуемые полными узлами, привлекают сравнительно меньше внимания. Данная работа восполняет этот пробел, представляя первое эмпирическое исследование о том, как узлы блокчейна используют данные реестра для валидации транзакций и блоков. Основная цель — изучить и количественно оценить стратегии, которые могут радикально сократить объём хранилища блокчейнов PoW с сотен гигабайт до более управляемого масштаба, не требуя изменений в базовом сетевом протоколе.
Децентрализованная модель безопасности блокчейнов, таких как Bitcoin, требует, чтобы полные узлы хранили и проверяли всю историю транзакций. Это создаёт значительный барьер для входа, ограничивая децентрализацию сети.
На момент исследования блокчейн Bitcoin требовал более 370 ГБ памяти. Этот рост линейно зависит от уровня внедрения и времени, создавая долгосрочную проблему масштабируемости. Высокие требования к хранению отталкивают пользователей от запуска полных узлов, что потенциально ведёт к централизации среди небольшого числа обеспеченных ресурсами субъектов, что противоречит основополагающему принципу децентрализации.
Предыдущие подходы включают создание контрольных точек (checkpointing) и протоколы снимков состояния (snapshot), которые требуют хард-форков или изменений на уровне консенсуса. Bitcoin Core предлагает опцию обрезки (pruning), но ей не хватает интеллектуального руководства — пользователи должны произвольно выбирать порог хранения (в ГБ или по высоте блока), рискуя удалить всё ещё релевантные непотраченные выходы транзакций (UTXO) или хранить ненужные данные.
Исследование основано на анализе реальной работы узлов Bitcoin, основанном на данных.
Авторы модифицировали клиенты Bitcoin Core для мониторинга и записи всех операций чтения с диска во время стандартной работы узла в течение длительного периода. Это создало детальный профиль того, какие именно данные (старые блоки, транзакции) запрашиваются во время валидации новых блоков и транзакций.
Ключевой вывод заключается в том, что подавляющее большинство исторических данных блокчейна редко используется. Валидация в основном зависит от:
Эта модель выявляет значительную избыточность в локальном хранении всей цепи.
Основываясь на эмпирическом анализе, в работе предлагаются клиентские стратегии.
Наиболее непосредственная стратегия — интеллектуальный алгоритм обрезки. Вместо простого отсечения по высоте блока узел может динамически сохранять:
Этот подход полностью совместим с существующими пирами Bitcoin.
Для дальнейшего сокращения узлы могут использовать модель «ленивой загрузки» (lazy-fetch). Если необходимая историческая транзакция не хранится локально, узел может запросить её по требованию из одноранговой сети. Это обменивает незначительное увеличение задержки валидации (время загрузки) на существенную экономию хранилища. Криптографические доказательства, такие как доказательства Меркла, могут гарантировать целостность загруженных данных без доверия к пиру.
Исследование демонстрирует, что реализация интеллектуальной стратегии обрезки позволяет полному узлу Bitcoin сократить требования к локальному хранилищу примерно до 15 ГБ, сохраняя при этом полные возможности валидации. Это включает набор UTXO (~4-5 ГБ), все заголовки блоков (~50 МБ) и окно последних полных блоков.
Стратегия «ленивой загрузки» влечёт за собой незначительные вычислительные накладные расходы на генерацию или проверку доказательств Меркла. Основной компромисс — потенциальное увеличение времени валидации блока при необходимости сетевой загрузки, которое оценивается в порядке сотен миллисекунд при нормальных сетевых условиях — небольшая цена за возможность работы узлов на устройствах с ограниченными ресурсами.
Целостность обрезанных данных и транзакций, загружаемых по требованию, обеспечивается деревьями Меркла. Узел, запрашивающий транзакцию $tx$ из блока высоты $h$, может попросить пира предоставить транзакцию вместе с доказательством пути Меркла $\pi_{tx}$. Узел, который хранит заголовок блока, содержащий корень Меркла $root_h$, может проверить доказательство, пересчитав:
$\text{Verify}(tx, \pi_{tx}, root_h) = \text{true}$, если $\text{MerkleHash}(tx, \pi_{tx}) = root_h$
Это гарантирует, что транзакция действительно была частью канонической цепи, без необходимости иметь весь блок. Вероятность необходимости глубокой исторической транзакции моделируется как функция распределения возраста набора UTXO, которое, как выяснилось в исследовании, сильно смещено в сторону недавних выходов.
Сценарий: Новый стартап хочет запустить полностью валидирующий узел Bitcoin для платёжного сервиса, но имеет ограниченный бюджет на облачное хранилище.
Применение фреймворка:
Этот фреймворк позволяет им сохранить безопасность и суверенитет, сократив при этом затраты на хранение более чем на 95%.
Ключевая идея: Самым ценным вкладом работы является не просто новый алгоритм обрезки, а эмпирическая деконструкция догмы «полного узла». Она доказывает, что блокчейн на 370 ГБ — это в основном холодный архив; активный, критически важный для безопасности рабочий набор на порядок меньше. Это фундаментально ставит под сомнение представление о том, что экстремальный объём хранилища — это неизбежная цена суверенитета, подобно тому, как статья о CycleGAN переопределила преобразование изображений, показав, что парные данные не нужны. Оба примера демонстрируют выявление и использование скрытых, реальных асимметрий данных.
Логика: Аргументация убедительно проста: 1) Измерить, какие данные узлы фактически используют (а не хранят). 2) Обнаружить, что использование сильно сконцентрировано. 3) Следовательно, безопасно удалить неиспользуемый объём. 4) Предоставить механизмы для надёжной загрузки редких необходимых фрагментов. Это классический цикл инженерной оптимизации, применённый к системе, ранее считавшейся неизменной.
Сильные и слабые стороны: Её сила заключается в практичности и немедленной применимости. Она не требует изменений консенсуса, что делает её редким предложением «выигрыш-выигрыш» в часто конфликтном пространстве блокчейнов. Однако анализ имеет критический, неозвученный недостаток: он оптимизирован для установившегося состояния. Он недооценивает потребность в ресурсах во время реорганизации цепи (reorg). Глубокая реорганизация, хотя и редкая, может потребовать быстрой валидации многих старых блоков. Обрезанному узлу потребуется загрузить гигабайты данных на лету, что потенциально может привести к отставанию и неспособности вовремя проверить конкурирующую цепь — это риск для безопасности. Таким образом, компромисс в работе заключается не только в задержке против хранилища, но и в устойчивости к экстремальным сетевым событиям в обмен на повседневную эффективность.
Практические выводы: Для разработчиков вывод заключается в немедленной реализации настраиваемой интеллектуальной обрезки в программном обеспечении кошельков и узлов. Для исследователей следующий шаг — количественно оценить риск реорганизации и разработать протоколы загрузки, устойчивые к сетевым нагрузкам. Для инвесторов и проектов эта работа снижает операционные затраты на запуск безопасного узла, делая по-настоящему децентрализованные бизнес-модели более жизнеспособными. Это небольшой, но важный шаг в превращении инфраструктуры блокчейна из увлечения энтузиастов в масштабируемую утилиту, что согласуется с более широкими отраслевыми тенденциями, отслеживаемыми такими организациями, как Gartner, в сторону эффективных, устойчивых распределённых систем.