Напомни, чего я там обещал? Я еще не протрезвел после НГ
Topic: Будущее базы данных цепи Bitcoin - page 2. (Read 4717 times)
Теоретически можно сделать распределенную базу цепи по принципу схожему с DHT с некоторыми допилами в сторону защиты от Sybill. Но никто пока не чешет задницу в этом направлении.
Напомни, чего я там обещал? Я еще не протрезвел после НГ
Напомни, чего я там обещал? Я еще не протрезвел после НГ
Простите за мой ламеризм, но нельзя ли так сделать, ну, мне для того что бы скачать фильм из торрента, вовсе не нужно что бы он полностью был у каждого сида. Часть с одного, часть с другого, по частям скачался весь.. Невыполнимо?
П\с. Будет обещанная статья о "сырой" транзакции, как делать?
Спасибо.
П\с. Будет обещанная статья о "сырой" транзакции, как делать?
Спасибо.
Из официального документа Сатоши:
Как известно, в блоке львиную долю места занимает тело блока.
То есть, типа не обязательно хранить тела блоков все время. Для того, чтобы стереть тело блока с диска, достаточно, чтобы выстроилась некая большая цепь над ним.
Но хидеры хранить обязательно. Однако здесь есть проблема.
Во-первых, кто то обязательно должен хранить всю цепь - хоть убей. Для разрешения угрозы форков цепи, дабы возможно было проследить историю каждой монетки вплоть до ее генерации. То есть, часть сети, обязательно должна хранить вот эту почти экспоненциально растущую базу: http://blockchain.info/ru/charts/blocks-size
Во-вторых, полная цепь с телами блоков - это железная защита каждого клиента. Пока она есть у него локально, он может отличить правду от лжи, получаемую из сети. Текущая сеть состоит преимущественно из ванильных клиентов, хранящих полную цепь локально. И если в сети кто то балуется и начинает слать левые транзакции, этот индивидум жестко банится сетью ванильных клиентов.
Если на клиенте не будет полной цепи - он будет гораздо более уязвим к Sybill и DoS атакам злых анонимусов. Ну представьте себе клиента только с хидерами. Он получает новую транзакцию из сети. Как ему проверить предыдущие Ouput'ы этой транзакции, если их просто нет? А если он не может проверить, он не может знать, верна ли транзакция или нет. Но по протоколу он обязан сохранить ее. Получается, его можно просто завалить левыми транзами. А если он еще их и брокастнет, то ванильные клиенты его жестко побанят.
Другими словами, клиент только с хидерами блоков - вещь весьма стремная.
Конечно лайт клиенты возможны, но они не должны составлять бОльшую часть сети, чтобы сеть была устойчива к проискам злых анонимусов.
А что насчет фулл клиентов с полноценной базой? А Сатоши в оф документе ничего не говорил о проблемах полной базы.
А ведь они уже есть и выходят за рамки использования ванильного клиента на среднестатистическом пользовательском ПК.
Я кое что знаю о высоких нагрузках. В частности, о высоких нагрузках на базу данных. И эта история не про нехватку места, а про нехватку пропускной способности шины винта.
Пока индекс помещается в размер ОЗУ - проблем особо нет. Или беркли-бекенд его кеширует, или буфера OS. В любом случае, поиск по такому индексу не является проблемой.
Но как только индекс начинает превышать объем ОЗУ, особенно, в 2-5 раз, то все методы кеширования данных оказываются бесполезны. И тогда при поиске ключа, комп начинает лопатить очень много гигабайт данных на винте. А ведь клиенту при получении транзакции надо найти все предыдущие аутпуты, а при получении нового блока - повторить тоже самое для всех транзакций блока. Я уж молчу про процесс синхронизации.
Мое мнение - в недалеком будущем, ванильный клиент Bitcoin выйдет за рамки возможностей стационарного домашнего/офисного ПК. Главный боттлнек - пропускная способность шины SATA и скорость позиционирования головки. Твердотельные накопители конечно могут немного облегчить эту проблему, но не намного и не надолго. Если учитывать что Биткоин - это быстро растущая сеть, объем информации обещает экспоненциальный рост.
Quote
Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it 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 do not need to be stored.
A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.
A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.
Как известно, в блоке львиную долю места занимает тело блока.
То есть, типа не обязательно хранить тела блоков все время. Для того, чтобы стереть тело блока с диска, достаточно, чтобы выстроилась некая большая цепь над ним.
Но хидеры хранить обязательно. Однако здесь есть проблема.
Во-первых, кто то обязательно должен хранить всю цепь - хоть убей. Для разрешения угрозы форков цепи, дабы возможно было проследить историю каждой монетки вплоть до ее генерации. То есть, часть сети, обязательно должна хранить вот эту почти экспоненциально растущую базу: http://blockchain.info/ru/charts/blocks-size
Во-вторых, полная цепь с телами блоков - это железная защита каждого клиента. Пока она есть у него локально, он может отличить правду от лжи, получаемую из сети. Текущая сеть состоит преимущественно из ванильных клиентов, хранящих полную цепь локально. И если в сети кто то балуется и начинает слать левые транзакции, этот индивидум жестко банится сетью ванильных клиентов.
Если на клиенте не будет полной цепи - он будет гораздо более уязвим к Sybill и DoS атакам злых анонимусов. Ну представьте себе клиента только с хидерами. Он получает новую транзакцию из сети. Как ему проверить предыдущие Ouput'ы этой транзакции, если их просто нет? А если он не может проверить, он не может знать, верна ли транзакция или нет. Но по протоколу он обязан сохранить ее. Получается, его можно просто завалить левыми транзами. А если он еще их и брокастнет, то ванильные клиенты его жестко побанят.
Другими словами, клиент только с хидерами блоков - вещь весьма стремная.
Конечно лайт клиенты возможны, но они не должны составлять бОльшую часть сети, чтобы сеть была устойчива к проискам злых анонимусов.
А что насчет фулл клиентов с полноценной базой? А Сатоши в оф документе ничего не говорил о проблемах полной базы.
А ведь они уже есть и выходят за рамки использования ванильного клиента на среднестатистическом пользовательском ПК.
Я кое что знаю о высоких нагрузках. В частности, о высоких нагрузках на базу данных. И эта история не про нехватку места, а про нехватку пропускной способности шины винта.
Пока индекс помещается в размер ОЗУ - проблем особо нет. Или беркли-бекенд его кеширует, или буфера OS. В любом случае, поиск по такому индексу не является проблемой.
Но как только индекс начинает превышать объем ОЗУ, особенно, в 2-5 раз, то все методы кеширования данных оказываются бесполезны. И тогда при поиске ключа, комп начинает лопатить очень много гигабайт данных на винте. А ведь клиенту при получении транзакции надо найти все предыдущие аутпуты, а при получении нового блока - повторить тоже самое для всех транзакций блока. Я уж молчу про процесс синхронизации.
Мое мнение - в недалеком будущем, ванильный клиент Bitcoin выйдет за рамки возможностей стационарного домашнего/офисного ПК. Главный боттлнек - пропускная способность шины SATA и скорость позиционирования головки. Твердотельные накопители конечно могут немного облегчить эту проблему, но не намного и не надолго. Если учитывать что Биткоин - это быстро растущая сеть, объем информации обещает экспоненциальный рост.
Jump to: