Список потерянных (не связанных) блоков

Блок-сирота — это блок, у которого нет известного родителя в самой длинной цепочке блоков.

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

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

Итак, я извлекаю все хэши блоков из необработанных файлов данных. Затем я извлекаю все данные «предыдущего хэша блока» из необработанных файлов данных. В результате у меня есть 2 массива: хэши блоков (массив A) и родительские ссылки (массив B). Затем, если я вычту B из A, я получу список потерянных блоков.

Это правильный способ получить потерянный черный список или нет?

PS Я получаю такие результаты после парсинга dat файлов от blk00000.datдо blk00953.dat(я выбрал два блока из скомпилированного списка):

000000000000000003D57B69D1AC77F64287C893C16ADBC1816C6D7386CCC3C0 – orphaned 0000000000000000011523D7477DD274B7E0DCC2C616B2E2F584FFDEC20237D3 - main chain

main chainи orphanedявляются статусом, основанным на сайтах обозревателя блоков.

В этих двух блоках нет ссылок на «предыдущие» в необработанных файлах данных. Я в замешательстве - "почему?"

Термин «сиротский блок» обычно использовался по крайней мере для двух совершенно разных вещей: см . bitcoin.stackexchange.com/a/5869/208 . Кажется, вы имеете в виду второе значение здесь, которое больше не актуально. С момента введения синхронизации заголовков таких сирот больше не существует.
@PieterWuille спасибо за помощь) Но первый блок из моего примера был добыт 29.11.2016 (после выпуска bitcoin core v0.10) и этот блок находится в dat файле, который находится на диске\каталоге блоков
Веб-сайты обозревателя блоков используют термин «осиротевший» для обозначения «больше не в основной цепочке», а не «неизвестный родитель».
здесь речь идет о блоках, после которых нет ссылок. Я получил их.

Ответы (1)

В результате у меня есть 2 массива: хэши блоков (массив A) и родительские ссылки (массив B). Затем, если я вычту B из A, я получу список потерянных блоков.

Нет, это даст вам список устаревших блоков (которые обычно называют блоками-сиротами). Что вы делаете, так это получаете все блоки, которые не являются родителями чего-либо, а не блоки, у которых нет родителей.

000000000000000003D57B69D1AC77F64287C893C16ADBC1816C6D7386CCC3C0 – orphaned 

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

0000000000000000011523D7477DD274B7E0DCC2C616B2E2F584FFDEC20237D3 - main chain

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

Я думаю, что мой английский не так хорош. Я имею в виду, что каждый блок имеет ссылку на предыдущий, но, например, в blk00234.dat присутствует блок, на который нет ссылки во всей базе данных. Этот блок вызывает осиротевшие. Это правда?
блоки могут поступать на ваш узел не в правильном порядке, поэтому в вашем локальном хранилище может быть блок без родителя
Да, блок, у которого нет дочерних элементов, обычно называют осиротевшим. Но это не то определение сироты, которое вы используете.
(...но например в blk00234.dat...) основная цепочка одинакова на всех узлах, но blk-файлы не побайтно равны друг другу. в вашей версии есть сиротский блок в файле № 234, в моей нет
@amaclin, так вы говорите, что полная база данных биткойнов ( \blocks\blk*.datфайлы) не одинакова для всех, кто устанавливает биткойн-клиент?
да. мой файл отличается от вашего. а у моего экземпляра нет 000000000000000003D57B69D1AC77F64287C893C16ADBC1816C6D7386CCC3C0
Но я думаю, что основной принцип блокчейна — хранить одну и ту же базу данных на каждом узле.
@Denis Цель состоит в том, чтобы у всех был один и тот же блокчейн. Однако сама по себе цепочка блоков не является базой данных, и не у всех будут одинаковые блоки в точно таком же порядке. Но программное обеспечение узла сможет анализировать данные блокчейна и определять, какие блоки использовать, чтобы все узлы в конечном итоге использовали один и тот же блокчейн. Узлы могут иметь разные данные блокчейна, но подавляющее большинство из них будут одинаковыми. Единственные отличия от потерянных блоков, поскольку новые узлы не будут знать о них, и эти потерянные блоки могут распространяться медленно.
@AndrewChow, вы имеете в виду, что локальная база данных не одинакова для всех узлов?
Да, базы данных не одинаковы для всех узлов.
@AndrewChow, пожалуйста, почувствуйте основной принцип технологии p2p) База данных одинакова для каждого узла. Это правда. Специально для сети Биткойн. Итак -1.
@Денис, нет, это совсем не так. Пожалуйста, поймите, как работает протокол P2P, прежде чем делать такие выводы. Вся система является асинхронной, что означает, что одноранговые узлы будут получать блоки в разное время и завершать проверку блоков в разное время. В блочной ретрансляции есть задержка, из-за которой узлы не соглашаются.
Например, два майнера (майнер А и майнер Б) могут найти блок на одной высоте примерно в одно и то же время. Когда блок передается в широковещательном режиме, одноранговые узлы получают один блок раньше, чем другой. Это означает, что у некоторых одноранговых узлов сначала будет блок A, а затем блок B. Их базы данных теперь расходятся. Если какой-то другой майнер добывает блок поверх блока А и в это время нет гонки, блок А становится частью основной цепи, а блок Б становится осиротевшим.
Теперь предположим, что C решает создать новый полный узел. Он будет загружать блоки только в основной цепочке, поэтому его база данных будет содержать только блок A, а не блок B, так как блок B был потерян и больше не актуален. C по-прежнему использует тот же блокчейн, что и все остальные, но его база данных будет отличаться от базы данных других людей.
Но файлы blk*.datв каталоге blocksодинаковы для всех, кто подключен к биткойну?
Нет, они не. Блоки не загружаются и не сохраняются на диск по порядку, поэтому файлы блоков, скорее всего, будут отличаться только из-за порядка. Кроме того, как в моем примере выше, если у вас есть новый узел, вы не загрузите и не сохраните на диск потерянный блок, но другие узлы, которые были в сети во время добычи блока, загрузят и сохранят потерянный блок. . Это сделает ваши блочные файлы отличными от других узлов.
База данных @AndrewChow одинакова для каждого узла, байт за байтом.
@ Денис, нет. Почему ты продолжаешь настаивать на том, что они есть? Я поддерживаю несколько узлов и могу доказать, что у них разные блочные файлы и базы данных. Если у вас есть нода, то я могу доказать, что у моих нод файлы блоков и базы данных отличаются от ваших.
@AndrewChow, если это так, то рушится основной принцип блокчейна.