Блокчейн выглядит как двойной связанный список, и все транзакции хранятся в каждом блоке. Какой алгоритм использует биткойн для эффективного поиска конкретной транзакции, поскольку блокчейн становится все больше и больше?
Биткойн-сеть использует свои вычислительные мощности для обеспечения согласованности данных. Если мы упростим эту модель (однократная запись, многократное чтение, без обновлений, без обмана) и применим ее политику согласованности в географически распределенной файловой системе, сработает ли это?
Блокчейн представляет собой либо древовидную структуру (каждый блок просто ссылается на своего родителя), либо единственный путь через это дерево (односвязный список).
Внутри программного обеспечения (по крайней мере, в эталонной реализации), конечно, существуют индексы для поиска блоков (по высоте и по хешу).
Однако технически индексация транзакций вообще отсутствует. Они не нужны для проверки. Вместо этого поддерживается база данных только с выходными данными транзакций, которые еще не были потрачены (которые индексируются хэшем транзакций и ничем более). Каждый проверенный блок обновляет эту базу данных: добавляются его новые выходы, а потребляемые им выходы удаляются. Эта база данных крошечная по сравнению с блокчейном (400 МБ против 16 ГБ по состоянию на март 2014 года).
На самом деле сами более ранние блоки вообще не используются при валидации. Они нужны нам только для обслуживания других узлов, которые запускаются, иначе у них не было бы возможности узнать текущее состояние в режиме нулевого доверия.
Последний пункт важен для модели безопасности Биткойна: полные узлы никогда не доверяют данным, которые они не проверили сами. Вот почему мы не можем просто скопировать базу неизрасходованных выходов у кого-то и забыть о блоках до этого момента.
Что касается разделения данных между узлами: такие механизмы обычно имеют очень плохие свойства DoS, когда выход из строя нескольких сетевых узлов может означать, что некоторые данные становятся недоступными.
Для только блоков, конечно, возможно, что не каждый узел будет хранить и обслуживать каждый блок (и это, вероятно, будет реализовано где-то в будущем). Опять же, все, для чего они нужны, — это загрузка нового узла.
База данных неизрасходованных выходов также может быть сегментирована, а именно путем сохранения выходов транзакций только в пределах определенного диапазона хэшей. Однако для этого по-прежнему требуется, чтобы каждый узел проверял каждый блок, и результат технически не является полным узлом. Вам понадобится набор узлов, которые вместе проверяют весь диапазон хэшей, чтобы убедиться, что блоки полностью действительны.
Джори
Тинг
Питер Уилле