Почему каждый узел не хранит только часть блокчейна?
Например, если у вас есть 100 узлов, каждый узел будет хранить 10% блокчейна. Это привело бы к значительному перекрытию каждого аспекта блокчейна, и по мере того, как узлы приходили и уходили, совместное использование блокчейна увеличивалось или уменьшалось.
Это невыполнимо? Если да, то почему? Я заинтересован в реализации этого проекта, потому что я думаю, что он может решить многие проблемы масштабируемости/децентрализации биткойнов.
Исходя из моего понимания блокчейна, давайте предположим, что конкретный узел начинается с генезис-блока. Предположим, что другой узел хранит 1% блокчейна после генезисного блока. Не могли бы несколько узлов проверять хэши блоков для своих общих 9% со скоростью один раз в 10 минут? На самом деле это не будет использовать так много данных — вы можете хэшировать 9% блокчейна до определенного значения, создать открытый ключ и посмотреть, могут ли другие узлы сопоставить закрытый ключ с указанным открытым ключом.
Связанный с этим вопрос: это то, что делает Электрум? Или Electrum просто хранит всю цепочку блоков на нескольких серверах, к которым вы можете подключиться?
Почему каждый узел не хранит только часть блокчейна?
Это предлагалось ранее и возможно с биткойнами, но неясно, как это будет реализовано. Блоки не являются важной частью работающего узла, для большинства людей вы можете выбросить их, как только обработаете их в своей базе данных UTXO.
Проблема возникает, когда вы решаете, какие части хранить, и сообщаете другим людям в сети, что у вас есть определенное подмножество блоков. Вы не можете объявить список хэшей, так как это было бы массивно и неэффективно (много мегабайт для каждого узла), а сделать детерминированный случайный выбор чрезвычайно проблематично. Выбор диапазонов блоков не идеален, потому что размеры не совпадают, 1000 блоков в начале цепочки — это серверы на порядки меньше, чем блоки в конце. В наивной реализации случайного выбора одноранговым узлам, пытающимся синхронизироваться с сетью, может потребоваться установить тысячи подключений, чтобы найти одного однорангового узла, имеющего определенный блок, что, очевидно, невозможно.
Исходя из моего понимания блокчейна, давайте предположим, что конкретный узел начинается с генезис-блока. Предположим, что другой узел хранит 1% блокчейна после генезисного блока. Не могли бы несколько узлов проверять хэши блоков для своих общих 9% со скоростью один раз в 10 минут? На самом деле это не будет использовать так много данных — вы можете хэшировать 9% блокчейна до определенного значения, создать открытый ключ и посмотреть, могут ли другие узлы сопоставить закрытый ключ с указанным открытым ключом.
Это не обязательно и очень уязвимо для атак Sybil, вам не нужно проверять блоки после того, как вы их увидели. Обрезанные узлы работают так и сегодня, только они выбрасывают каждый блок и не хранят абсолютно ничего, кроме того, что указано для боли. Они не афишируют, какие блоки у них есть, потому что для этого нет механизма.
Вы можете прочитать о том, как работает патч autoprune, и лучше понять модели угроз, с которыми необходимо справиться здесь. Вы немного пропустили часть операции, обратите внимание, что удаление узлов не работает так, как описано в официальном документе, UTXO — это новая концепция, добавленная в биткойн-ядро 0.8.0.
Связанный с этим вопрос: это то, что делает Электрум?
Вовсе нет, серверы Electrum представляют собой полный узел и чрезвычайно тяжелый адресный индекс, почти вдвое увеличивающий размер хранилища. Клиент легкий, но сервер определенно не такой. Не существует разумного способа поддерживать эти индексы в виде сегментов, хотя вы можете разбить адреса на несколько пулов и надеяться, что люди поддерживают достаточное количество каждого сегмента, чтобы клиенты могли запрашивать подписки для всех своих адресов. В идеале должны быть разработаны системы, не требующие полных индексов, поскольку они становятся все более громоздкими для работы.
Нечто подобное было реализовано и выпущено в версии 0.11.0 в клиенте Bitcoin Core. Это называется сокращением, и теперь вы можете использовать параметр -prune, чтобы указать, сколько данных блокчейна вы хотите сохранить.
-prune=N: where N is the number of MB to allot for raw block & undo data
Это пока не работает с точки зрения кошелька, поэтому при обрезке вы не можете использовать кошелек в основном клиенте. Это также останавливает ретрансляцию, хотя они работают над тем, чтобы включить это, чтобы позволить узлам по-прежнему ретранслировать блоки.
Однако это не означает, что узлы хранят разные части блокчейна.
Обратите внимание, что новый узел в режиме обрезки по-прежнему будет загружать и работать со всеми блоками, но не сохранит все старые блоки.
Насколько я понимаю, это будет обновлено для поддержки использования кошелька в режиме обрезки в будущем. РЕДАКТИРОВАТЬ: По-видимому, основная ветвь ядра биткойн уже поддерживает использование кошелька в режиме обрезки.
БТ
Кларис
БТ
БТ