Topic: Экономия дискового пространства в Bitcoin - page 2. (Read 661 times)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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



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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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