Разве биткойн не выиграет от распределения частичных блокчейнов по каждому узлу?

Почему каждый узел не хранит только часть блокчейна?

Например, если у вас есть 100 узлов, каждый узел будет хранить 10% блокчейна. Это привело бы к значительному перекрытию каждого аспекта блокчейна, и по мере того, как узлы приходили и уходили, совместное использование блокчейна увеличивалось или уменьшалось.

Это невыполнимо? Если да, то почему? Я заинтересован в реализации этого проекта, потому что я думаю, что он может решить многие проблемы масштабируемости/децентрализации биткойнов.

Исходя из моего понимания блокчейна, давайте предположим, что конкретный узел начинается с генезис-блока. Предположим, что другой узел хранит 1% блокчейна после генезисного блока. Не могли бы несколько узлов проверять хэши блоков для своих общих 9% со скоростью один раз в 10 минут? На самом деле это не будет использовать так много данных — вы можете хэшировать 9% блокчейна до определенного значения, создать открытый ключ и посмотреть, могут ли другие узлы сопоставить закрытый ключ с указанным открытым ключом.

Связанный с этим вопрос: это то, что делает Электрум? Или Electrum просто хранит всю цепочку блоков на нескольких серверах, к которым вы можете подключиться?

Ответы (2)

Почему каждый узел не хранит только часть блокчейна?

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

Проблема возникает, когда вы решаете, какие части хранить, и сообщаете другим людям в сети, что у вас есть определенное подмножество блоков. Вы не можете объявить список хэшей, так как это было бы массивно и неэффективно (много мегабайт для каждого узла), а сделать детерминированный случайный выбор чрезвычайно проблематично. Выбор диапазонов блоков не идеален, потому что размеры не совпадают, 1000 блоков в начале цепочки — это серверы на порядки меньше, чем блоки в конце. В наивной реализации случайного выбора одноранговым узлам, пытающимся синхронизироваться с сетью, может потребоваться установить тысячи подключений, чтобы найти одного однорангового узла, имеющего определенный блок, что, очевидно, невозможно.

Исходя из моего понимания блокчейна, давайте предположим, что конкретный узел начинается с генезис-блока. Предположим, что другой узел хранит 1% блокчейна после генезисного блока. Не могли бы несколько узлов проверять хэши блоков для своих общих 9% со скоростью один раз в 10 минут? На самом деле это не будет использовать так много данных — вы можете хэшировать 9% блокчейна до определенного значения, создать открытый ключ и посмотреть, могут ли другие узлы сопоставить закрытый ключ с указанным открытым ключом.

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

Вы можете прочитать о том, как работает патч autoprune, и лучше понять модели угроз, с которыми необходимо справиться здесь. Вы немного пропустили часть операции, обратите внимание, что удаление узлов не работает так, как описано в официальном документе, UTXO — это новая концепция, добавленная в биткойн-ядро 0.8.0.

Связанный с этим вопрос: это то, что делает Электрум?

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

«Проблема» — я не думаю, что это действительно проблема, а просто выбор дизайна, который еще не сделан. Вы можете легко разделить блок-цепочку на куски примерно по 50-100 МБ и идентифицировать их, хэшируя весь кусок.
Это не проверка, вам нужно убедиться, что в остальной информации нет ничего недействительного.
Да, я не говорил о проверке. Я говорил об обмене информацией о том, какие части блокчейна у вас есть в наличии. В ответ на ваш второй абзац
Я думаю, что, возможно, я не совсем отвечаю в полном контексте ОП.

Нечто подобное было реализовано и выпущено в версии 0.11.0 в клиенте Bitcoin Core. Это называется сокращением, и теперь вы можете использовать параметр -prune, чтобы указать, сколько данных блокчейна вы хотите сохранить.

-prune=N: where N is the number of MB to allot for raw block & undo data

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

Однако это не означает, что узлы хранят разные части блокчейна.

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

Насколько я понимаю, это будет обновлено для поддержки использования кошелька в режиме обрезки в будущем. РЕДАКТИРОВАТЬ: По-видимому, основная ветвь ядра биткойн уже поддерживает использование кошелька в режиме обрезки.

Master, по крайней мере, поддерживает кошелек и базовый режим обрезки.
Этот ответ неверен. Сокращение — это забвение старых, нерелевантных данных, и оно было описано еще в технической документации. Вопрос касался распределения нагрузки соответствующих данных между разными узлами, что потребовало бы значительных алгоритмических инноваций.
@MeniRosenfeld Стоит отметить, что клиентские режимы, описанные в техническом документе, на самом деле совсем не работают так в реальном мире, я не уверен, что больше не стоит указывать людям на эту информацию.