Сколько времени занимает проверка блока?

Здесь есть несколько вопросов.

Пожалуйста, поправьте меня, если я ошибаюсь: майнер проверяет только что полученный блок, прежде чем использовать его самостоятельно и отправить другим своим подключенным партнерам.

Да и нет. Обратите внимание, что под майнерами мы подразумеваем людей, которые сами строят блоки, включая соло-майнеров, операторов пулов и пользователей p2pool. Хэшеры, которые только подключаются к пулу и выполняют работу, не являются частью этой группы.

Майнеры могут — и иногда так и делают — строить новый блок до того, как они полностью обработают предыдущий (даже если он их собственный), чтобы не тратить время на майнинг. К сожалению, поскольку они еще не знают, какие UTXO потрачены в только что полученном блоке, они не знают, какие последующие транзакции действительны, и поэтому не могут включать какие-либо новые транзакции. Из-за этого эти блоки будут пустыми, кроме монетной базы.

На практике у этих майнеров будет два механизма для обновления предложенного блока, над которым работают их хэшеры:

1. Новый лучший хэш блока объявляется в их собственной сети (или обнаруживается в сети другого пула — например, путем прослушивания интерфейса их пула или по соглашению об отправке информации друг другу). Когда это происходит, всем хэшерам предлагается начать работу с пустым блоком.
2. Новый блок принимается через их bitcoind(через протокол P2P, через команду submitblockRPC для их блоков или через отдельные ретрансляционные сети типа FIBER ). bitcoindзатем строит новый набор допустимых транзакций сверху (через getblocktemplateRPC), и они обновляют свои хэшеры, чтобы начать работать над блоком с этими блоками.

Предполагается, что когда произойдет (1), тот же блок вскоре пройдет через (2), и мы переключимся с работы с пустым блоком сверху на обычный блок сверху. Однажды был случай, когда этого не произошло.

Когда BIP66 активировался, некоторые майнеры, использующие версии с поддержкой BIP66 bitcoind, прослушивали блоки, отправленные пулами до BIP66. Майнер до BIP66 создал несовместимый с BIP66 блок (неправильные номера версий), а майнеры с поддержкой BIP66 прослушали его и начали создавать пустые блоки сверху. Конечно, они bitcoindникогда не принимали полный блок, так как он был недействителен в соответствии с новыми правилами — правилами, с которыми согласились сами майнеры. Результатом стала последовательность множества пустых блоков сверху, при этом многие майнеры строили поверх предыдущих недействительных блоков, и все они не были приняты сетью.

Итак, чтобы ответить на ваш вопрос:

Так зачем продолжать майнинг поверх предыдущего блока?

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

Сколько времени обычно занимает этот процесс? От чего это зависит?

В вашем процессе вы учитываете только проверку блока. Но весь процесс состоит из всего, что находится между (А) созданием действительного блока в сети и (Б) переключением хэшеров на построение блока поверх него. Это включает:

• Предыдущий создатель блока передает блок в сеть . Здесь могут быть непреднамеренные задержки или даже преднамеренные задержки (например, атака Selfish Mining).

• Блоки должны распространяться по сети . Обычные bitcoindузлы распространяются только после полной проверки и требуют всплесков высокой пропускной способности для передачи всех блоков. Более современные технологии, такие как компактные блоки (BIP152) и FIBER, позволяют избежать полной повторной отправки или даже ожидания завершения проверки.

• Блоки должны быть проверены .

• Необходимо создать новый набор действительных транзакций сверху .

Валидация зависит от многих факторов:

• Версия ПО . Постоянно улучшаются скорости проверки.
• Размер кэша UTXO . Чем больше кэш, тем меньше требуется доступа к базе данных для получения информации о потраченных выходах. В результате просто получение входных данных может занять от нескольких миллисекунд до нескольких секунд.
• Размер кэша подписи и скорость процессора . Чем больше кэш, тем больше проверок подписи можно избежать. Эти проверки - в зависимости от версии программного обеспечения и аппаратного обеспечения варьируются от 0,01 мс до 0,6 мс на подпись (от 45 мс до 2,7 с для блока).
• Корреляция между пулом памяти и новым блоком . Если блок содержит транзакции, которые узел раньше не видел, его входные данные и подписи с меньшей вероятностью будут кэшироваться ранее.
• Пропускная способность . До Bitcoin Core 0.13 блоки всегда передавались полностью между узлами, что могло вызвать большие всплески во время объявления нового блока.
• Сетевая задержка . В более изолированных частях мира, даже при хорошей пропускной способности, время, необходимое сетевому пакету для достижения внешнего мира, может быть значительным. В зависимости от протокола для отправки блока требуется от 1 до 3 циклов. Если задержка между двумя одноранговыми узлами составляет 200 мс, это уже может означать 1,2 с, потраченных впустую на переход туда и обратно.
• Количество подключений . Если у узла много подключений, он будет пытаться транслировать новый блок одновременно всем, вызывая всплеск работы сетевой активности. Это может быть слишком большой нагрузкой для ЦП, сетевого оборудования или полосы пропускания, что приводит к замедлению работы при наличии большого количества подключений.

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

Это делается на специализированном оборудовании для майнинга или на процессоре общего назначения?

Насколько мне известно, специального оборудования для проверки или построения блоков не существует.

Верно ли, что время, необходимое для проверки блока, линейно зависит от размера блока + свидетеля, если активируется segwit?

В основном. В текущем алгоритме хеширования подписи существует неэффективность, которая может составлять O (n ^ 2) по размеру транзакций. Это может привести к отдельным транзакциям, которым требуется несколько минут, чтобы просто вычислить хэш подписи. Это исправлено в BIP144, который всегда используется внутри транзакционных входов SegWit, что делает его в худшем случае O(n) (менее 10 мс для блока в худшем случае на обычном оборудовании).

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

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

Это сложно. Это, конечно, не пропорционально скорости хеширования, а больше связано с топологией сети и используемой технологией. На веб-сайте FIBER есть некоторая статистика, но часто передача менее чем на 20 мс превышает минимальную теоретическую задержку сети (скорость света при длинных соединениях) по всему миру. Это возможно только в том случае, если вы являетесь частной сетью, которая предполагает, что ее участники не будут участвовать в DoS-атаках в сети. Общедоступная сеть гораздо более надежна, но часто требуется много секунд, чтобы распространить блок на большую часть узлов, и десятки секунд, чтобы достичь менее подключенных узлов.

Я думаю, что все крупные майнеры имеют собственное разработанное программное обеспечение для управления процессом майнинга и могут переключаться на недавно полученный заголовок блока до завершения проверки. Процесс проверки блока не должен занимать много времени, так как большинство транзакций из блока уже находятся в мемпуле и уже проверены. Задачей проверки является проверка пропущенных транзакций, проверка coinbase, проверка вознаграждения за блок, проверка merkleroot. Таким образом, проверка блока должна завершиться через несколько секунд. Блок, распространяемый по сети, зависит от скорости соединения.

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

Вот почему вы иногда видите только что сгенерированный блок только с одной транзакцией (транзакция coinbase). Примером этого является следующий блок: https://blockchain.info/block/00000000000000000a06dbd18a15a452c4dd50f662044e654f83066da2775ed8 .

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