Некоторые размышления по поводу размера block

[Mohnaty Bulrathi]

Некоторые размышления по поводу размера blockchain

Допустим, что на планете будет 10 миллиардов людей (к середине 21-го века).

Это вполне в рамках прогноза ООН
https://www.un.org/esa/population/publications/longrange2/WorldPop2300final.pdf



Каждому человеку нужно несколько номеров счетов для разных нужд.
Сколько именно - можно прикинуть, посмотрев на типовой план счетов бухгалтерского учета
пусть 100 штук на человека.

На каждом счете может лежать какая-то сумма денег, которая займет 8 байтов
(21 000 000 биткоинов по 100 000 000 частей -> =LOG(21000000*100000000;2) =50,8993107512 битов >7 байтов).

значит, всего нужно места как минимум (без учета индексов и прочей вспомогательной информации)
8 TB

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


Можно посчитать по другому - пронумеровать всех людей (надо 33 бита. 4 байта не хватит, поэтому 8 байт),
и для каждой монеты отметить кому она принадлежит - это менее экономный способ хранения чем предыдущий.

---

Что по этому поводу думают западные коллеги?
http://bitcoinforums.net/threads/the-blockchain-a-blessing-or-a-flaw.68/

они подходят с практической стороны, исследуя текущую реализацию. 126MB of actual data for 50,000 people - это по 2520 байт на человека.
если на счет по 8 байт, то 315 счетов на человека (т.е. текущий используемый вариант хранения примерно в трое хуже одного из моих)

в расчете на 7 миллиардов людей они получили размер базы = almost 18 terabytes (что сравнимо по порядку величин с моим расчетом)

---

Проблема ограничения на размер одного блока в 1 мегабайт (там же обсуждена)
дело в том, что количество блоков в сутки = 6 * 24 часа (каждые 10 минут) => ограничено общее количество возможных транзакций

---

Проблема пропускной способности каналов связи
it would also be impossible for most people to download such a large blockchain

---

Проблема уменьшения времени проверки цепочки
http://bitcoinmedia.com/fat-blockchain/

Blocks take time to be checked for correctness when we download then.
That is why the blockchain is slow. Not because downloading blocks takes time.
Downloading the entire blockchain can be done in a matter of minutes on a good internet connection.
It is the checking that takes time.

---

Английская ветка с прогнозом объема цепочки до конца 2012 года:
https://bitcointalk.org/index.php?topic=90871.0


(size of both the blk00001.dat plus blkindex.dat combined)

Еще один график на ту же тему:
https://blockchain.info/charts/blocks-size?timespan=1year&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=



---

некоторые пути уменьшения размера цепочки на диске приведены здесь:
http://bitcoin.stackexchange.com/questions/478/how-do-i-reduce-the-size-of-the-block-chain-data-on-my-machine

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

---

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

Вот тут говорят про гиигабайтные блоки в цепочке (и как следствие в оперативной памяти):
http://bitcoin.stackexchange.com/questions/2798/are-there-any-studies-into-the-size-of-the-blockchain-scaling-over-time
но как уже выше упоминалось, сделали ограничение по размеру в 1 мегабайт

---

Если это всё все и так знают, зачем нужна эта ветка обсуждения?
- можно обсудить параллельные алгоритмы проверки цепочки, которые бы сокращали время необходимое для её полной проверки
- можно обсудить способы кодирования транзакций на диске с целью уменьшения размера цепочки на диске
- можно обсудить способы удаления транзакций, монеты из которых были использованы позднее

[1714168841]

1714168841

[1714168841]

1714168841

[1714168841]

1714168841

[1714168841]

1714168841

[1714168841]

1714168841

[1714168841]

1714168841

[Azrace]

такое ощущение что Арсен Шнурков писал. извиняюсь перед топикстартером

[naima53]

такое ощущение что Арсен Шнурков писал. извиняюсь перед топикстартером

тоже первая мысль...

- можно обсудить способы удаления транзакций, монеты из которых были использованы позднее

Кстати, возможно ли это? И если это не принесет неприятностей, то почему давно уже это не сделали? Насколько я понимаю, если вдруг все начнут дико использовать BTC , (ну мало ли, Штаты принимают закон о обязательности к приему BTC ) то bitcoin-qt вообще перестанет запускаться на обычных компьютерах...

[tenzor]

Хмм. Не понимаю, к чему паника. 18 ТБ относительно не много. К 21 году и жесткие подрастут и ссд с процессорами вырастут. Выделятся доверенные железки, которые будут хранить весь блокчейн, ибо мало ли что. А юзеры будут хранить последние N блоков, ну или только те блоки, в которых остались непотраченные BTC. опять же, не все человеки на Земле будут пользоваться биткойнами, не всем нужно 100 кошельков и т.п.

[LZ]

Да, похоже на Арсена. Но в белый список все-таки добавил.

tenzor, полностью согласен.

[kimmeriets]

такое ощущение что Арсен Шнурков писал. извиняюсь перед топикстартером

мабуть это форк. карочи, с дебютом.

[Mohnaty Bulrathi]

можно обсудить способы удаления транзакций, монеты из которых были использованы позднее

Кстати, возможно ли это?

Ну вот смотри, были сгенерированы 50 монет для адреса A, потом они целиком переведены на другой адрес B при помощи второй транзакции.
После этого первая транзакция больше не нужна
для проверки при переводе на адрес C (т.к. вторая транзакция находится в проверенном и подписанном блоке)

Другое дело, что непонятно, насколько это уменьшит размер цепочки, потому что если сумма переведена не полностью,
то первая транзакция будет нужна для проверки остатка. Т.е. надо проверять процент таких транзакций.


Тут вообще интересно разобраться, как запись на диск происходит.
Может можно писать более экономно, например заменив длинные адреса на их короткие индексы.

Первое, с чем прийдется разобраться, это фанатские макросы
IMPLEMENT_SERIALIZE
READWRITE
FLATDATA

кто, например, может сказать, в чем смысл строчки

IMPLEMENT_SERIALIZE
(
        READWRITE(this->nVersion);
        nVersion = this->nVersion;
        READWRITE(vin);
        READWRITE(vout);
        READWRITE(nLockTime);
)

?
Всегда ли она там была?
Если нет, то что пишут по поводу её появления?

Я предполагаю, что там меняется значение локальной переменной и последующие поля записываются/считываются из другой версии.
Но как версии учитываются в базе?

эти макросы находятся в файле serialize.h
инклюдится он так: main.h <- bignum.h <- util.h <- netbase.h <- serialize.h (правда, совершенно очевидным образом?)

там шаблоны по типу потока (template<typename Stream>),

// Templates for serializing to anything that looks like a stream,
// i.e. anything that supports .read(char*, int) and .write(char*, int)

поэтому, чтобы выяснить, проходит запись через движек СУБД или идет в файл,
надо найти эти потоки и понять, как они работают.

Так как на странице описания директории данных написано, что

The data, index and log files are used by Oracle Berkeley DB, the embedded key/value data store that Bitcoin uses

то ясно, что используется Berkley DB

Есть функции
bool CBlock::WriteToDisk(unsigned int& nFileRet, unsigned int& nBlockPosRet) и
bool CBlock::ReadFromDisk(unsigned int nFile, unsigned int nBlockPos, bool fReadTransactions=true)

Blocks are appended to blk0001.dat files on disk.
Откуда же вызывается сериализация блоков? Пока непонятно.

Вот где неподтвержденные транзакции записываются - понятно:
/** Access to the wallet database (wallet.dat) */
class CWalletDB : public CDB

Сухой остаток:
1) Размер базы можно уменьшить пропорционально константе, если записывать блоки более компактно (возможно, отказавшись от Berkley DB)
2) Размер базы можно уменьшить, если не сохранять переиспользованные транзакции

И если это не принесет неприятностей, то почему давно уже это не сделали?

Вероятно из соображений универсальности, потенциальной расширяемости, стандартизации интерфейса доступа (интерфейс Berkley DB)

[Yurock]

На сегодняшний день, официальный клиент плохо справляется с обработкой цепочки блоков. Объём дисковых операций при сохранении блока в разы превышает, собственно, размер блока. Когда сами блоки в сумме весят более 2 гектар, "расточительство" BDB выливается в адский труд для компа. Например, если новый пользователь решит скачать всю цепочку из сети Bitcoin, а не с сайта, то средненький комп будет подтормаживать несколько часов. Скорее всего, придётся почти полностью переделывать механизм работы с цепочкой.

Теперь о транзакциях. Обычно, если с какого-то адреса снимаются монеты, то снимается вся сумма. Например, имеем адрес А, на котором 6.3 BTC и адрес Б, на котором 7.2 BTC. Надо перевести 10 BTC на адрес В. Создаём новый адрес Г. Создаём транзакцию: А + Б → В(10), Г(3.4). Майнер проверяет адреса А и Б по предыдущим транзакциям и вычисляет сумму "входов": 13.5 BTC. Затем вычисляет сумму "выходов" В и Г: 13.4 BTC. Убеждается, что на выходе не больше, чем на входе. Записывает транзакцию в блок и отправляет 0.1 BTC себе в качестве комиссионного сбора. После этого на счетах А и Б 0 BTC. Информацию о том, откуда монеты попали на адреса А и Б можно удалить, так как она не будет использоваться для проверки будущих транзакций. В вики написано, что цепочка блоков содержит более 70% такой ненужной информации.

[Balthazar]

Она не ненужная. О монете должна быть доступна вся история вплоть до момента ее создания. Иначе система потенциально ненадежна.

[Yurock]

Она не ненужная.

Потенциально вся инфа может понадобиться для каких-нибудь исследований, например. Но практически – часть инфы не нужна. Когда заполняется винт, приходится что-то стирать. Вот эти > 70% и можно легко пустить в расход.

[Balthazar]

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

[Yurock]

в системе появляется потенциальная брешь

Какая?

[Balthazar]

Сейчас у клиента есть возможность убедиться, что использованные монеты действительно были когда-то созданы, а не появились из вакуума.

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

[Yurock]

Сейчас у клиента есть возможность убедиться, что использованные монеты действительно были когда-то созданы, а не появились из вакуума.

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

После удаления транзакций в блоках их потребуется переподписать

Обоснуй.

[Balthazar]

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

Недостаточно, потому что это вообще ничего не означает. Я, к примеру, могу сгенерировать и подписать блок с абсолютно любым содержимым, хоть с матерными словами. Если клиент не будет проверять историю монет (что он делает для _каждой_ точки выхода при загрузке blockchain), результатом будет то, что он примет такой блок за правильный. Это дырка.

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

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

Обоснуй.

SHA256(SHA256(a)) != SHA256(SHA256(a - x))

[Yurock]

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

Удаление ненужной информации не предполагает отказ от каких-либо проверок. Удаляется лишь та информация, которая не может быть использована для успешной проверки будущих транзакций. Такой информации в цепочке более 70%.

SHA256(SHA256(a)) != SHA256(SHA256(a - x))

Из неравенства результатов не следует необходимость повторного расчёта. Обоснование не принимается.

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

[Balthazar]

Удаление ненужной информации не предполагает отказ от каких-либо проверок.

Предполагает, потому что делает такие проверки невозможными.

Из неравенства результатов не следует необходимость повторного расчёта. Обоснование не принимается.

Вы шутите? Или действительно не понимаете, на каком принципе базируется система?

[Yurock]

Предполагает, потому что делает такие проверки невозможными.

Предположим, я удалю с диска информацию о транзакции 9fc6f6a792c466d91c9192a8deeef799a011ce510e0ea56114ff9dfc2027aa84. Объясните, какую проверку нельзя будет произвести и покажите код в текущей версии клиента, который выполняет такую проверку. Учтите, что транзакции ba25b0f163930dc00008220f76a9fd12a0a31b80dab5a65c5bedc41717c11553 и 6609eee16acd2b91c0ac5c3ec8a7039d10f6a4e618756a7cf0ee81396681058e были проверены и сохранены моим клиентом до удаления информации о транзакции 9fc6f6a792c466d91c9192a8deeef799a011ce510e0ea56114ff9dfc2027aa84.

Вы шутите?

Не шучу. Математическое неравенство само по себе не доказывает, что кому-то вообще необходимо что-то подписывать. Должно быть показано, для чего будет использована новая подпись, и почему это важно. Напоминаю исходное утверждение.

После удаления транзакций в блоках их потребуется переподписать, и все зависящие от них блоки тоже.

А также поясняю: транзакции, как таковые, не отменяются. Лишь удаляется (за ненадобностью) информация о них с узла сети Bitcoin.

[Balthazar]

Не шучу. Математическое неравенство само по себе не доказывает, что кому-то вообще необходимо что-то подписывать. Должно быть показано, для чего будет использована новая подпись, и почему это важно. Напоминаю исходное утверждение.

После удаления транзакций в блоках их потребуется переподписать, и все зависящие от них блоки тоже.

А также поясняю: транзакции, как таковые, не отменяются. Лишь удаляется (за ненадобностью) информация о них с узла сети Bitcoin.

Если не шутите, значит просто не понимаете о чем речь. При старте клиента от проверяет хэши блоков на диске на соответствие nBits, хранящемуся в заголовке, и не только это. Если что-то поменять даже незначительно в блоке, у него будет совсем другой хэш, не соответствующий nBits, и он будет отвергнут клиентом с сообщением "Incorrect Proof-of-Work". Это даже если забыть о том, что хэш блока-родителя сохраняется в заголовке последующего блока, что делает невозможным изменение содержимого предыдущего блока без переподписывания обоих путем подбора nNonce таким образом, чтобы оно соответствовало сохраненному в заголовке nBits.