Экономия дискового пространства в Bitcoin

[uanix-2]

В разделе 7 Reclaiming Disk Space своего знаменитого доклада Bitcoin: A Peer-to-Peer Electronic Cash System Сатоши Накамото излагает идею уменьшения дискового пространства для хранения блокчейна:

Once the latest transaction in a coin is buried under enough blocks, the spent transactions beforeit   can   be   discarded   to   save   disk   space.     To   facilitate   this   without   breaking   the   block's   hash,transactions are hashed in a Merkle Tree [7][2][5], with only the root included in the block's hash.Old blocks can then be compacted by stubbing off branches of the tree.   The interior hashes donot need to be stored.
A  block   header   with   no   transactions   would   be   about   80   bytes.     If   we   suppose   blocks   aregenerated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year.  With computer systemstypically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of1.2GB   per   year,   storage   should   not   be   a   problem   even   if   the   block   headers   must   be   kept   inmemory.

В переводе:

Как только последняя транзакция в монете-цепочке окажется внутри достаточно старого блока, все предшествующие ей транзакции в цепочке могут быть удалены в целях очистки дискового пространства. Чтобы хэш блока остался неизменным, все транзакции в блоке хранятся в виде хэш-дерева Меркла[7][2][5] и лишь его корень включается в хэш блока. Размер старых блоков может быть уменьшен за счет удаления ненужных ветвей этого дерева, хранить промежуточные хэши необязательно.
Заголовок пустого блока будет составлять около 80 байт. Из расчета скорости генерации блока раз в десять минут получаем 80*6*24*365=4,2 Мб в год. Для среднестатистического на 2008 год компьютера с 2 Гб оперативной памяти с учетом закона Мура, предсказывающего рост на 1,2 Гб в год, хранение данных не будет проблемой, даже если все заголовки блоков будут находиться в памяти.

Другими словами, с целью экономии дискового пространства он предложил отсекать старые транзакции (не имеющие неиспользованных выходов), а подтверждения их существования в прошлом хранить в виде хэшей дерева Меркла. Это, разумеется, приведет к потере истории транзакций, но при этом текущее состояние владения биткоинами будет всегда актуально.

А теперь вопрос: Почему этот механизм так и не был принят?
Это связано с какими-то технологическими проблемами или просто пока нет необходимости?

[uanix-2]

Разобрался сам...

Такая возможность (block file pruning, режим prune — обрезать, усекать) появилась только в июле 2015 года в биткоин-клиенте Bitcoin Core версии 0.11.0. И то, это сделано опционально , на усмотрение пользователя ,— он сам решал, включать эту функцию или нет. Операцию усечения блокчейна называют прунинг (от анг. pruning — обрезка, усечение).

[madnessteat]

Может кто-то пояснить. Какой в этом смысл, если узел сначала должен будет скачать всю цепочку блоков и проверить ее полностью на соблюдение правил системы биткоина, только после этого будет удалена ненужная информация? (ведь если скачать всю цепочку блоков, то места под нее явно хватает) Будет ли узел полноценно работать в системе после усечения цепочки блоков?

[kzv]

Может кто-то пояснить. Какой в этом смысл, если узел сначала должен будет скачать всю цепочку блоков и проверить ее полностью на соблюдение правил системы биткоина, только после этого будет удалена ненужная информация? (ведь если скачать всю цепочку блоков, то места под нее явно хватает) Будет ли узел полноценно работать в системе после усечения цепочки блоков?

В режиме "prune", узел качает последовательно блок за блоком всю цепочку до тех пор, пока блокчейн не начнет занимать на диске места больше, чем прописано в параметре "prune=xxx". Как только блокчейн станет занимать больше места, узел начнет стирать те блоки, информация из которых уже проверена. Это если коротко...

[igor72]

Будет ли узел полноценно работать в системе после усечения цепочки блоков?

Смотря что вкладывать в понятие "полноценно". Валидацию блоков делать будет, раздавать архив новым нодам - нет.

[uanix-2]

В режиме "prune", узел качает последовательно блок за блоком всю цепочку до тех пор, пока блокчейн не начнет занимать на диске места больше, чем прописано в параметре "prune=xxx". Как только блокчейн станет занимать больше места, узел начнет стирать те блоки, информация из которых уже проверена. Это если коротко...

Стирать целые блоки или удалять информацию о транзакциях с потраченными выходами в блоках?
Ведь Сатоши Накамото предлагает делать именно это — отсекать «старые транзакции», т.е. транзакции у которых нет UTXO (непотраченных выходов).

[kzv]

В режиме "prune", узел качает последовательно блок за блоком всю цепочку до тех пор, пока блокчейн не начнет занимать на диске места больше, чем прописано в параметре "prune=xxx". Как только блокчейн станет занимать больше места, узел начнет стирать те блоки, информация из которых уже проверена. Это если коротко...

Стирать целые блоки или удалять информацию о транзакциях с потраченными выходами в блоках?
Ведь Сатоши Накамото предлагает делать именно это — отсекать «старые транзакции», т.е. транзакции у которых нет UTXO (непотраченных выходов).

Это технические моменты. Совершенно не интересные.
Технически есть как минимум две базы данных: в одной хранятся блоки, в другой хранятся непотраченные выходы. В принципе, если есть проверенная база UTXO, то база блоков наверное и не нужна вовсе. Ну или на всякий пожарный, на мой взгляд, вполне достаточно хранить только шесть последних блоков на случай длинного орфана которого в истории пока не случалось.
Однако для каких-то внутренних технических причин, минимальный размер базы блоков ограничен константой в 500 Мб, то есть с учетом что максимальный размер блока 3 Мб, то в обрезанном блокчейне должно быть не менее 166 блоков, что примерно равно среднему количеству блоков которые находятся за сутки.

[uanix-2]

Это технические моменты. Совершенно не интересные.

Ну, мне, как автору топика, интересны как раз технические моменты.

Технически есть как минимум две базы данных: в одной хранятся блоки, в другой хранятся непотраченные выходы.

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

Однако для каких-то внутренних технических причин, минимальный размер базы блоков ограничен константой в 500 Мб, то есть с учетом что максимальный размер блока 3 Мб, то в обрезанном блокчейне должно быть не менее 166 блоков, что примерно равно среднему количеству блоков которые находятся за сутки.

Во-первых, максимальный размер блока пока 1 Mb. Если, конечно, речь не идет о Bitcoin Cash. Но это отдельная история и меня этот форк не интересует.
Во-вторых, смысла хранить только последние блоки нет никакого. Поскольку в новом блоке может появиться транзакция с UTXO из более старых блоков.

Единственно разумная схема усечения блокчейна — эта та, которую предложил Сатоши Накамото и которую я упоминаю в стартовом сообщении. А именно — отсечение из блоков информации о транзакциях с полностью использованными выходами и сохранение информации только о транзакциях с UTXO.

[kzv]

Технически есть как минимум две базы данных: в одной хранятся блоки, в другой хранятся непотраченные выходы.

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

За рамками какого протокола?
В статье Сатоши Накомото протокол не описан, там только базовые принципы.
В первых версиях клиента тоже кроме запакованного в рар архив экзешника ничего не было. База блоков изначально хранилась в формате berkeley db, потом ее перевели в формат LevelDB.
Протокол обмена информацией между p2p нодами описан в вики. В этом протоколе вообще никаких баз данных нет.

Так что непонятно, что вы подразумеваете под "протоколом", но так или иначе, а у клиента Bitcoin Core есть две базы данных. Противоречит этот факт чему-то или нет это уже вопрос к разработчикам клиента.

Во-первых, максимальный размер блока пока 1 Mb. Если, конечно, речь не идет о Bitcoin Cash. Но это отдельная история и меня этот форк не интересует.
Во-вторых, смысла хранить только последние блоки нет никакого. Поскольку в новом блоке может появиться транзакция с UTXO из более старых блоков.

Во-первых, после принятия сегвит, максимальный размер блока стал ограничен 3 Мб, но если вы в этом путаетесь - не расстраивайтесь вы не одиноки ) Сами разработчики клиента чтобы не путаться, кроме размера блока ввели в обиход новую сущность которая называется "вес блока". Сути это не меняет, потому что по факту вес это и есть размер который считается по новым правилам.
Во-вторых, смысл хранить последние блоки есть. Смысл в том, что если появится длинная орфан-цепочка, а у вас нет последних блоков, то для актуализации UTXO вам придется опять синхронизироваться с нуля.

Кстати, задолго до появления прунинга в Bitcoin Core, была реализована схема SPV в так называемых "легких кошельках". В этой схеме клиент хранит только заголовки блоков и только свои собственные транзакции.

[A-Bolt]

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

Протокол - это язык на котором ноды общаются между собой. То как нода внутри себя хранит данные - это её личное дело.

Во-первых, максимальный размер блока пока 1 Mb.

Вот жеж заебали с этим максимальным размером блока.

kzv имел в виду максимальный размер сериализованного блока, который не может превышать 4МБ. А вы всё цепляетесь за константу в коде MAX_BLOCK_SIZE = 1000000, которую из исходников Биткойна уже давно выпилили.

Походите по блокчейну да посмотрите: сколько реальные блоки места занимают.

[igor72]

А есть ли смысл в установке параметра -prune больше минимального 550 Mb (что тоже избыточно, имхо)? То, что нода сможет поделиться инфой о большем кол-ве блоков, это понятно. Еще есть плюсы?

[kzv]

А есть ли хоть какой-то смысл в установке параметра -prune больше минимального 550 Mb (что тоже избыточно, имхо)?

Смысл в поддержке сети Биткоина. Чем больше вы у себя храните блоков, тем более децентрализована сеть в целом.
Лично для конкретного пользователя смысла нет. Тут вопрос уходит в философскую область: "а есть ли смысл помогать общему делу, если это лично на мне почти никак не отразится"?

[igor72]

Ок, я так и думал. А раз зашла речь о помощи сети, такой вопрос. Есть ли разница для сети между нодой с полным блокчейном и кастрированной, если они показывают только 8 соединений (8/0) с сетью? Я думаю, эта ситуация сплошь и рядом, вряд ли многие имеют статический (или полноценный динамический) IP или возятся с настройкой через тор.

[kzv]

Ок, я так и думал. А раз зашла речь о помощи сети, такой вопрос. Есть ли разница для сети между нодой с полным блокчейном и кастрированной, если они показывают только 8 соединений (8/0) с сетью? Я думаю, эта ситуация сплошь и рядом, вряд ли многие имеют статический (или полноценный динамический) IP или возятся с настройкой через тор.

Если ноде нужен блок, она отправляет запрос к своему окружению. Если у окружения блока нет, тогда два варианта:
1. Либо нода должна подключиться к менее кастрированному узлу
2. Либо кастрироанные узлы должны выполнить функцию "прокси-сервера". То есть передать поступивший запрос к своему окружению, а потом передать ответ обратно к ноде

Это стандартная процедура работы поиска в одноранговой п2п сети. Полностью ли следует этой процедуре клиент биткоина - я не знаю.

[igor72]

Я хотел узнать, передает ли нода с закрытым 8333 портом информацию о блоках в сеть? Есть ли разница (для сети) в таком случае, полная эта нода или нет?

[uanix-2]

В первых версиях клиента тоже кроме запакованного в рар архив экзешника ничего не было. База блоков изначально хранилась в формате berkeley db, потом ее перевели в формат LevelDB.
Протокол обмена информацией между p2p нодами описан в вики. В этом протоколе вообще никаких баз данных нет.

Так что непонятно, что вы подразумеваете под "протоколом", но так или иначе, а у клиента Bitcoin Core есть две базы данных. Противоречит этот факт чему-то или нет это уже вопрос к разработчикам клиента.

Спасибо за разъяснение. Буду изучать работу клиента Bitcoin Core...

Во-вторых, смысл хранить последние блоки есть. Смысл в том, что если появится длинная орфан-цепочка, а у вас нет последних блоков, то для актуализации UTXO вам придется опять синхронизироваться с нуля.

Я имел ввиду хранить ТОЛЬКО последние блоки.

Кстати, задолго до появления прунинга в Bitcoin Core, была реализована схема SPV в так называемых "легких кошельках". В этой схеме клиент хранит только заголовки блоков и только свои собственные транзакции.

Ну, это как говорится, «совсем другая история».

[kzv]

Я хотел узнать, передает ли нода с закрытым 8333 портом информацию о блоках в сеть? Есть ли разница (для сети) в таком случае, полная эта нода или нет?

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

[igor72]

kzv, ну а зачем тогда открывать порт?
Смотрите. У меня на старом нетбуке крутится полная нода (для поддержки сети, так сказать, ну и электрум у меня к ней подключен). В связи с тем, что интернет у меня за провайдерским NAT-ом, я настроил ноду через тор. Так вот, исходящий трафик сейчас на порядки больше, чем без тора. Что это за трафик? Что-то отдается, что при закрытом порте не может. Но меня интересует другое (повторяться не буду).

[kzv]

kzv, ну а зачем тогда открывать порт?
Смотрите. У меня на старом нетбуке крутится полная нода (для поддержки сети, так сказать, ну и электрум у меня к ней подключен). В связи с тем, что интернет у меня за провайдерским NAT-ом, я настроил ноду через тор. Так вот, исходящий трафик сейчас на порядки больше, чем без тора. Что это за трафик? Что-то отдается, что при закрытом порте не может. Но меня интересует другое (повторяться не буду).

Если вы за NAT-ом, то открытие/закрытие порта никак не влияет на сеть в целом.

Если у вас публичный IP адрес и открытый порт, тогда вы помогаете другим участникам сети быстрее находить ноды для подключения (ибо являетесь одной из таких нод).

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

[igor72]

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

То есть, если та нода, к которой я, будучи за NAT-ом, подключился, открыта для сети, то она будет от меня ретранслировать другим архив блоков, даже если сама "pruned", так?