Осознание заголовков блоков в блокчейне Биткойна

Составление заголовка блока — достаточно трудно устроенный и в высшей степени весомый процесс. Если Биткойн — жив дышащий организм, то заголовок блока — это сердечко всей машинки. Любые 10 минут в блоках Биткойна передвигаются и рассчитываются миллионы баксов капитала. Заголовок блока как как будто заверяет нотариально перемещение средств в транзакциях, говорит о поддержке предложений о изменении сети и в конечном счете описывает движение и правомерность биткойн-транзакций.

Номер версии предоставляет возможность для обновления сети средством софт-форков. Хеш предшествующего блока связывает текущий блок с родительским, создавая цепочку из блоков — блокчейн. Корень Блекла криптографически связывает все транзакции в блоке с его заголовком. Метки времени действуют как верифицируемая система, нужная для работы почти всех приложений на базе Биткойна. Закодированная мотивированная сложность дает майнерам знать, какой хеш сеть воспримет как валидный. В конце концов, nonce обеспечивает выделенное место для поиска валидного хеша, чтоб майнеры могли делать свою работу, обеспечивая работу сети.

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

Введение

Блокчейн Биткойна состоит из блоков. Блоки (и транзакции) представляют собой версионированные двоичные структуры данных. Блок состоит из 2-ух частей: блока транзакций (в каком содержатся все включенные в блок транзакции) и заголовка блока. Заголовок — это куцее и строго форматированное поле данных, предваряющее любой блок. Он содержит в себе 6 полей, все с разными многофункциональными способностями, и SHA256d-хеш этих полей действует как идентификатор блока. В центре внимания данной нам статьи находится конкретно заголовок блока, и мы продолжим в него углубляться, но поначалу давайте коротко коснемся блока транзакций.

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

Майнер делает огромное количество операций хеширования в поисках допустимого хеша, отвечающего этому условию. Для сотворения новейших хешей из числа тех же данных блока, употребляется поле заголовка, называемое nonce, которое майнер может стремительно изменять, чтоб генерировать неповторимые хеши в поиске первого валидного. Как еще будет описано ниже, nonce содержит лишь четыре б (2³² бита), которые можно изменять. Таковым образом, место поиска составляет 2³² бита, другими словами через изменение лишь поля nonce для блока быть может сгенерировано до 4 294 967 296 неповторимых хешей. Это может показаться огромным местом для поиска, но по сути оно достаточно не достаточно, беря во внимание мощности доступного сейчас ASIC-оборудования. К примеру, производительность Antminer S19 Pro от Bitmain составляет 110 Тхеш/сек. Это около 2⁴⁶ хешей за секунду. Другими словами эта машинка стопроцентно исчерпывает место поиска, предоставляемое полем nonce, наименее чем за одну миллисекунду.

Если место поиска оказывается исчерпано, а валидный хеш не найден, то майнеру придется сформировывать новейший блок из новейшего набора транзакций. Сбор новейшего блока быть может вычислительно накладным и интенсивным исходя из убеждений пропускной возможности. Потому у майнеров есть стимул отыскивать методы к расширению места поиска за границы выделенного четырехбайтового nonce. Есть несколько методов расширить место поиска: применять (1) вольные биты поля версии, (2) часть битов поля времени, (3) несколько доп битов в подписи скрипта coinbase-транзакции. Крайнее нередко именуют extranonce, хоть в протоколе Биткойна это и не является формально определенным полем.

Как и любые данные, транзакции сводятся к последовательностям байтов. Иметь очень «томные» блоки, «весящие» очень много байтов, не нужно из-за разных ресурсных ограничений. Два более всераспространенных из их соединены с (1) каналом исходящей связи (пропускная способность / задержка) и (2) проверкой (как стремительно CPU может инспектировать транзакции). Ограничения, связанные с хранением данных, на данный момент не представляют большенный препядствия, так как оно стоит сравнимо дешево, а ноды могут сжиматься. Но огромные блоки могут помешать людям с ограниченным местом для хранения данных запускать полную ноду, тем нанося вред децентрализации сети. Не считая того, без ограничения размера блока сеть становится восприимчивой к DDoS-атакам со стороны злоумышленников, транслирующих в нее большущее количество транзакции с малой стоимостью. Чтоб противостоять сиим явлениям, существует определенное консенсусом сети ограничение размера блока, именуемого весом блока.

Что вдохновляет майнеров майнить блоки? У майнеров есть два источника дохода: субсидия блока (о которой мы еще будем гласить позднее) и комиссии за транзакции. Им необходимо соблюсти узкий баланс: максимизировать прибыль от комиссий, включив в блок-кандидат как можно больше транзакций, но при всем этом сохранить вес блока ниже 4 Мб. Это сродни известной задачке о ранце.

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

Заголовок блока

Сейчас мы готовы перебегать к дискуссии заголовка блока в Биткойне. Заголовок имеет размер 80 б и содержит 6 разных полей данных, все в формате little-endian.

Для того чтоб рассматривать и осознавать заголовок блока и содержимое транзакции, необходимо владеть осознанием двоичных, шестнадцатеричных чисел и порядка следования байтов. Чтоб это разъяснить, я сделаю маленькое отступление в последующем подразделе. Те, кто уже знаком с этими понятиями, могут смело пропустить эту часть.

Системы счисления и порядок следования байтов Двоичная, десятичная и шестнадцатеричная системы счисления

Целые числа почаще всего выражаются в системе счисления с основанием 10, десятичной системе. Но в равной мере они могут быть выражены и в системе с хоть каким иным основанием. Две остальные системы счисления, полезные для осознания наиболее низкоуровневых концептов Биткойна, — это двоичная (с основанием 2) и шестнадцатеричная (с основанием 16). Изменение основания с 10 на 2 либо 16 (либо хоть какое другое число, если на то пошло) не меняет значение целого числа, лишь то, как оно выражается.

В двоичной системе числа имеют основание 2, и для выражения полного спектра целых чисел требуется лишь два значения: 0 и 1. Приведу в качестве примера последующие числа типа u8 (каждое число имеет длину 8 бит):

Сопоставление десятичных и двоичных чисел

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

Обычно к двоичным числам добавляется в качестве идентификатора знак b. К примеру, двоичный эквивалент десятичного числа 4 записывается как b0100.

Вы сможете спросить, почему для выражения, к примеру, двоичного числа b0000 0001 употребляется четыре числа. Почему не попросту b1? Это поэтому, что в памяти компа нужно заблаговременно избрать количество битов, требуемое для целого числа. Так что если целое число может представлять хоть какое число до b1111 1111, то в памяти целое число постоянно обязано занимать восемь цифр, даже если в реальности оно употребляет не все их.

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

В шестнадцатеричной системе числа имеют основание 16, потому для выражения полного спектра целых чисел требуется шестнадцать значений: 0–9 и A–F.

Сопоставление десятичных и шестнадцатеричных чисел

Заметьте, что в данном случае десятичная система владеет наиболее обширной записью, чем шестнадцатеричная.

Обычно к шестнадцатеричным числам добавляются в качестве идентификатора знаки 0x. К примеру, шестнадцатеричный эквивалент десятичного числа 3 735 928 559 записывается как 0xDEADBEEF.

Направьте внимание, что 0xDEADBEEF — это четырехбайтовое число. Любые два знака эквивалентны одному б: 0xDE — это один б, 0xAD — один б и так дальше.

Для полноты сопоставления, двоичный эквивалент десятичного числа 3 735 928 559 записывается как b1101 1110 1010 1101 1011 1110 1110 1111.

Порядок следования байтов

Понятие «порядок следования байтов» можно наглядно показать на последующем примере: в российском языке мы говорим «23», а, к примеру, в германском это число произносится как «3 и 20». Это одно и то же число, лишь выраженное по-разному. Порядок следования байтов — подобная теория: при прямом порядке (от старшего к младшему) поначалу считываются самые большие значения, при оборотном порядке (от младшего к старшему), напротив, поначалу считываются меньшие. Английские определения, применяемые для обозначения порядка байтов — big-endian (от большего к наименьшему) и little-endian (от наименьшего к большему), — являются отсылкой к «Путешествиям Гулливера» Джонатана Свифта. В романе Свифта были две враждующие группы людей: тупоконечники (Big Endian) и остроконечники (Little Endian). Одни разбивали и начинали чистить яичка с широкой части, остальные — с узенькой. В романе эта незначимая разница в методологии разбивания яиц в конечном итоге приводит к хаосу.

На базисном уровне порядок следования байтов относится к тому, как микропроцессор компа загружает значения в свои регистры (память), а конкретно, как упорядочиваются байты.

В формате big-endian поначалу считываются более важные байты. Конкретно так мы интуитивно читаем числа. Десятичное число 3 735 928 559 в шестнадцатеричном big-endian формате записывается как 0xDEADBEEF — совсем ожидаемым образом. В big-endian системе это число в двоичном формате хранится в памяти компа последующим образом (шестнадцатеричные значения тоже представлены для наглядности):

Двоичные и шестнадцатеричные числа в формате big-endian

Либо же число может сохраняться в памяти компа в формате little-endian (от младшего к старшему). В little-endian поначалу считываются менее важные байты числа. Это не то, как мы интуитивно читаем числа.

В little-endian системе это число в двоичном формате хранится в памяти компа последующим образом (шестнадцатеричные значения тоже представлены для наглядности):

Двоичные и шестнадцатеричные числа в формате little-endian

При сопоставлении big-endian и little-endian форматов (надеюсь) становится понятно, что единственное различие заключается в порядке байтов. В big-endian шестнадцатеричный эквивалент числа 3 735 928 559 записывается как 0xDEADBEEF. В little-endian он записывается как 0xEFBEADDE. Порядок следования байтов принципиально подразумевать, поэтому что в формате little-endian число 0xEFBEADDE как и раньше эквивалентно десятичному числу 3 735 928 559, а не 4 022 250 974.

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

В Биткойне (в главном) употребляется формат little-endian и это принципиально знать перед тем, как двигаться далее.

Ворачиваясь к заголовку блока

Вернемся к заголовку блока.

В шестнадцатеричном формате обычный заголовок блока смотрится последующим образом:

Заголовок блока Биткойна на высоте 645 536

Этот заголовок взят из блока на высоте 645 536, добытого Slushpool. Мы будем применять его в качестве примера в протяжении всей статьи.

Каждое поле, его тип данных и короткое описание поля приведены в последующей таблице.

Поля данных заголовка блока Как заголовок блока употребляется в процессе майнинга

На высочайшем уровне процесс майнинга сводится к последующим шагам:

  • Выбор пригодного номера версии и времени в текущей эре. Из сети выходит хеш предшествующего блока (из крайнего блока в самой длинноватой ветке блокчейна) и целевое значение хеша.
  • Выбор неподтвержденных транзакций из мемпула для включения в блок-кандидат.
  • Создание coinbase-транзакции.
  • Вычисление корня Блекла из всех транзакций блока, включая coinbase-транзакцию.
  • Конкатенация этих значений для сотворения сообщения блока.
  • Выбор числа для nonce и добавление его к сообщению блока — окончание сотворения полного заголовка блока-кандидата.
  • Выполнение SHA256-хеширования заголовка блока (два раза) и сопоставление результата с мотивированным значением.
  • Если хеш заголовка блока меньше либо равен мотивированному значению, то блок валиден, и майнер передает его в сеть для доказательства иными участниками. Потом он ворачивается к шагу 1 и начинает майнинг последующего блока-кандидата.
  • Если хеш заголовка блока не удовлетворяет мотивированному значению, то блок невалиден, и майнер ворачивается к шагу 6, увеличивая значение nonce и опять испытывая фортуну.
  • Эти шаги показаны на схеме:

    Схема процесса майнинга для построения заголовка блока

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

    Версия Поле версии в блоке на высоте 645 536

    Поле версии обычно обрабатывается как четырехбайтовое число в формате big-endian, интерпретируемое как тип int32 и содержащее доп биты, которые майнеры могут применять для подачи сигнала о готовности поддержать софт-форк и для получения доп 2¹⁶ места поиска.

    На 1-ый взор беспритязательное, на поверку поле версии блока оказывается не так просто устроено. Номер версии предоставляет майнерам инструмент для сигнализации о собственной готовности поддержать те либо другие обновления сети средством софт-форка. Фуррор либо непринятие активируемого майнерами софт-форка зависит от того, достаточное ли количество поступающих в сеть валидных блоков сигнализировало о готовности принять предлагаемые конфигурации. «Готовность» тут значит, что майнер обновил применяемое ПО до сопоставимости с версией биткойн-клиента, содержащей предлагаемые конфигурации. Примером голосования по софт-форку и его фиксации может служить активация SegWit.

    Три бита с самым огромным значением в поле версии зарезервированы для вероятных будущих обновлений механизма. В текущее время три самых важных бита должны быть установлены в значение b001. Это означает, что мало допустимый номер версии в формате big-endian — это 0x2000000 (b0010 0000 0000 0000 0000 0000 0000 0000). Наибольший номер версии в big-endian формате — 0x3FFFFFF (b0011 1111 1111 1111 1111 1111 1111 1111).

    На момент написания данной нам статьи (декабрь 2020) номер версии записывается в согласовании со спецификацией BIP9. До этого чем углубиться в BIP9, давайте поглядим, как изменялся номер версии с момента основания сети.

    Короткая история поля версии в заголовке блока

    Версия 1 началась с блока генезиса в 2009 году. До сентября 2012 никакого важного сигнализирования не просматривается.

    В сентябре 2012 Bitcoin Core v0.7.0 представило BIP34, выводившее блоки версии 1 из эталона Биткойна. Это BIP предполагало введение 2-ух новшеств:

  • Структурированный метод для майнеров говорить о собственной готовности принять предлагаемый софт-форк. Это достигалось при помощи механизма переключения с двойным порогом, способа IsSuperMajority(), в каком определены два пороговых значения, именуемые правилом 75% и правилом 95%. Правило 75% говорит, что, как 750 из крайних 1000 блоков говорят о готовности принять конфигурации, установив номер версии на 2 либо выше, все новейшие блоки, в заголовке которых указана версия 2, должны соответствовать предлагаемым в софт-форке спецификациям. По другому блок будет отклонен сетью, даже будучи валидным по эталонам версии 1. Правило 95%, последующий шаг, говорит, что, как 950 из крайних 1000 блоков будут иметь версию 2 либо выше, все блоки с версией 1 будут отклоняться сетью как недействительные.
  • Животрепещущее предложение о софт-форке, требовавшее, чтоб все блоки версии 2 либо выше включали высоту блока как 1-ый элемент в подписи скрипта coinbase-транзакции.
  • На то, чтоб блоки версии 2 стали эталоном, ушло около 6 месяцев, а крайний блок версии 1 на высоте 227 835 имел метку времени 2013–03–24 15:49:13 GMT.

    Предложение софт-форка, определяющее версию 3, описано в BIP66 и было представлено в феврале 2015 в Bitcoin Core v0.10.0. Блоки версии 3 ограничивают подписи строго шифровкой DER. Способ подачи сигнала о поддержке софт-форка соответствовал BIP34.

    Предложение софт-форка, определяющее версию 4, описано в BIP65 и было представлено в ноябре 2015 в Bitcoin Core v0.11.2. Блоки версии 4 стали распознавать новейший опкод для системы скриптов Биткойна, OP_CHECKLOCKTIMEVERIFY, позволяющий перекрыть UTXO от расходования на данное время.

    Хотя способ подачи сигнала IsSuperMajority(), описанный в BIP34, работал, он имел некие недостатки. А конкретно (1) отсутствие таймаута и (2) внедрение для подачи сигнала целых числовых значений, а не битов (разъясняется ниже). BIP9 решил обе эти препядствия.

    Улучшения поля версии в BIP9

    BIP9 описывает поведение поля версии, используемое сейчас. Требуется, чтоб каждое предложение софт-форка имело четыре параметра:

  • Отличительное заглавие.
  • Бит в поле версии, изменение которого будет говорить о готовности майнера принять конфигурации. Номер позиции бита обозначается N.
  • Время старта: с какого момента определенный бит обретает животрепещущее сигнальное значение.
  • Тайм-аут: если предложение не будет принято к определенной дате X, оно будет считаться непрошедшим.
  • Изменение 1-го бита в поле версии, заместо записи в поле данного целого числа (как в BIP34), дозволяет подавать сигналы по нескольким предложениям сразу.

    В блогпосте (англ.) Расти Рассела непревзойденно разъясняется эволюция и значимость поля версии. Отталкиваясь от этого поста, тут я буду говорить о поле версии наиболее детально. Давайте начнем с того, как конкретно работает сигнализация при помощи битов, описанная в BIP9.

    Полное 32-битное двоичное представление обычного big-endian номера версии 0x20000000 смотрится так:

    b0010 0000 0000 0000 0000 0000 0000 0000

    Это соответствует правилам, установленным в BIP9, согласно которым самые верхние биты должны быть b001 либо больше.

    Сейчас представим, что есть новое предложение о софт-форке, называемое BIPN₀, которое устанавливает позицию сигнального бита на 0 (N = 0). Для сигнализации о поддержке предложения нулевой бит необходимо поменять на 1. Тогда номер версии в big-endian формате будет смотреться как 0x20000001, либо

    b0010 0000 0000 0000 0000 0000 0000 0001

    Сейчас этот майнер сигнализировал о собственной поддержке BIPN₀.

    Сейчас представим, что сразу активны еще два предложения по софт-форку: BIPN₁ (N = 1) и BIPN₂ (N = 2). Наш майнер готов поддержать лишь BIPN₀ и BIPN₂, но не BIPN₁. С механизмом BIP9 это не неувязка. Говорить о поддержке лишь BIPN₀ и BIPN₂ можно, установив значения нулевого и второго битов на 1, а бит на первой позиции бросить без конфигураций: 0. Тогда номер версии в big-endian формате будет смотреться как 0x20000005, либо

    b0010 0000 0000 0000 0000 0000 0000 0101

    Возможность в хоть какой момент времени иметь несколько активных предложений о софт-форке делает этот механизм наиболее совершенным в сопоставлении с внедрением целочисленных значений согласно BIP34.

    Также майнеры могут применять и употребляют поле версии для получения доп места поиска хеша. Сначало, опосля того как было представлено BIP9, майнеры как и раньше употребляли для расширения места поиска все вольные биты поля версии. Но это привело к тому, что ноды генерировали предупреждения, так как пробовали интерпретировать биты как сигнал по несуществующим предложениям о софт-форке. С BIP320 эта неувязка была решена методом выделения 16 бит для расширения места поиска и резервирования 13 бит для подачи сигналов по софт-форкам. Это дозволяет майнеру расширить место поиска на 2¹⁶ и оставляет пространство для подачи сигналов по 13 животрепещущим предложениям о софт-форке.

    Хеш предшествующего блока Поле хеша предшествующего блока в блоке на высоте 645 536

    Поле хеша предшествующего блока представляет собой 32-битное значение в формате little-endian, интерпретируемое как тип char[32], и является хешем предшествующего блока. Это поле обеспечивает связь меж текущим и предшествующим блоком в сети.

    Корень Блекла Поле корня Блекла в блоке на высоте 645 536

    Поле корня Блекла представляет собой 32-байтовое значение в формате little-endian, интерпретируемое как тип char[32]. Структура дерева Блекла употребляется в области компьютерных наук для почти всех целей. В Биткойне дерево Блекла употребляется для криптографической привязки каждой транзакции в блоке к заголовку этого блока в лаконичных 32 б.

    Любая транзакция — это лист дерева Блекла. Транзакции должны быть включены в блок в топологическом порядке. Другими словами, если txₙ₊₁ расходует выход txₙ, то txₙ₊₁ обязана быть отсортирована на наиболее позднюю позицию в блоке, чем txₙ. А самый 1-ый лист в дереве Блекла зарезервирован для coinbase-транзакции.

    Поиск корня Блекла

    Опосля того как майнер отобрал транзакции для включения в блок-кандидат, для получения корня Блекла производятся последующие шаги:

  • Id (SHA256d-хеш) каждой транзакции попарно конкатенируются в один.
  • Конкатенированная пара транзакций хешируется методом SHA256d. Получаемая хеш-сумма становится новейшей ветвью в дереве.
  • Хеш-суммы, снова же, попарно конкатенируются и хешируются методом SHA256d, создавая новейшую ветвь в дереве.
  • Шаг 3 повторяется, пока не остается лишь один хеш, корень Блекла. Это значение и сохраняется в заголовок блока.

    Мерклизация случайного набора данных Время Поле времени в блоке на высоте 645 536

    Поле времени представляет собой четырехбайтовое значение в формате little-endian, интерпретируемое как тип unit32, которое является меткой времени снутри эры для текущего блока. При помощи меток времени сеть может найти текущую скорость доказательства блоков, чтоб по мере необходимости временами ее корректировать (любые 2016 блоков, либо около 2 недель). Правила консенсуса ограничивают спектр допустимых значений временных меток приблизительно трехчасовым окном, оставляя вольными 2¹³ бит, которые можно применять для расширения места поиска.

    Валидная метка времени обязана быть больше, чем среднее значение временных меток прошлых 11 блоков. При скорости доказательства 10 минут на блок, это составляет один час с момента отправки блока-кандидата. Метка времени обязана быть также меньше времени, скорректированного по сети, плюс два часа. Это трехчасовое окно составляет 10 800 секунд, что дает доп 2¹³ бит для расширения места поиска хеша:

    2ˣ = 10 800 x = ln(10 800) / ln(2) x = 13,3987 => 13

    Скорректированное по сети время — это локальное время (UTC) ноды плюс медианное смещение всех присоединенных нод. Время сети никогда не корректируется наиболее чем на 70 минут от локального системного времени.

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

    Биты Поле битов в блоке на высоте 645 536

    Поле битов представляет собой четырехбайтовое значение в формате little-endian, интерпретируемое как тип int32, в каком кодируется текущий мотивированной порог для валидного хеша. Результирующий хеш блока, чтоб рассматриваться сетью как допустимое решение, должен быть меньше или равен этому мотивированному значению. Целевое значение обновляется любые 2016 блоков (около 2-ух недель), так что любой заголовок блока, транслированный в течение этого периода в 2016 блоков, будет иметь одно и то же целевое значение.

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

    Наибольшее целевое значение, создаваемое хешем SHA256d — это 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF либо в десятичной системе счисления 26 959 946 667 150 639 794 667 015 087 019 630 673 637 144 422 540 572 481 103 610 249 215. Это весьма огромное число. Биткойн хранит целевое значение в виде числа с плавающей точкой, потому употребляется усеченная форма 0x00000000FFFF0000000000000000000000000000000000000000000000000000, эквивалентная 26 959 535 291 011 309 493 156 476 344 723 991 336 010 898 738 574 164 086 137 773 096 960 в десятичной системе счисления. Это все еще большущее число.

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

    1. Изменение формата следования байтов с little-endian (применяемого в заголовке) на big-endian: 0x2F931D1A → 0x1A1D932F. В конечном счете принципиально не то, какой порядок байтов употребляется, но всепостоянство и последовательность подхода.

    2. Отделение первого б, 0x1A, от других, 0x1D932F. Этот 1-ый б именуется мантиссой. Мантисса — это часть числа с плавающей точкой, представляющая количество означающих цифр. Потом мантисса множится на основание (в этом случае 2) и возводится в степень, чтоб получить значение числа.

    Другими словами целевое значение [хеша] извлекается из поля битов при помощи последующей операции:

    Target = мантисса × основание(экспонент — длина мантиссы)

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

    Target = 0x1D932F × 2⁽⁸ˣ⁽⁰ˣ¹ᴬ ⁻ ³⁾⁾ = 0x1D932F × 2⁽⁸ ˣ ⁽²⁷ ⁻ ³⁾⁾ = 0x1D932F0000000000000000000000000000000000000000000000

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

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

    0x0000000000001D932F0000000000000000000000000000000000000000000000 0x00000000000016BF116FC90CF45AEC2DA4D13349358159D8B4EDDCB37EAB295B

    Запись тех же чисел с основанием 10 смотрится последующим образом:

    47525089675259291211422247200069659468817014361857087365971968 36551990950853533658225321687497789580066641734434828845787483

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

    Давайте разберемся незначительно поглубже, почему была выбрана эта формула и как она работает. Сам формат основан на эталоне IEEE 754 для математики с плавающей точкой, в каком тщательно описывается, как компы хранят числа с плавающей точкой.

    Разглядим 16-битный регистр, содержащий число 11:

    b0000 0000 0000 1011

    В 16-битном регистре, как вы уже додумались, есть пространство лишь для 16 бит. Если мы сместим биты на количество доступных битов (16), то столкнемся с переполнением и потеряем наше число 11:

    Lost Bits | Remaining Bits 1011 | 0000 0000 0000 0000

    Чтоб этого избежать, мы устанавливаем, что можем сдвигаться лишь на доступное количество битов минус то число битов, которые мы желаем сохранить. В этом случае, 16 – 4 = 12, что даст:

    Lost Bits | Remaining Bits |1011 0000 0000 0000

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

    Nonce Поле nonce в блоке на высоте 645 536

    Поле nonce представляет собой четырехбайтовое значение в формате little-endian, интерпретируемое как тип int32, которое пошагово возрастает для сотворения новейших хешей текущего блока, чтоб отыскать удовлетворяющий мотивированному значению. Оно обеспечивает 2³² бита доп места поиска хеша.

    Параметр nonce играет важную роль в поиске валидного блока. Без nonce, когда майнер делает блок, не соответственный трудности сети, для получения новейшего хеша ему пришлось бы изменять набор транзакций в блоке, пересчитывать корень Блекла и перестраивать заголовок блока. Таковой процесс просит большого размера вычислительной работы. С nonce же майнеру довольно один раз сделать заголовок блока-кандидата и сохранять неизменными все переменные, кроме nonce. Майнер пошагово наращивает значение nonce и пересчитывает хеш до того времени, пока или (1) хеш заголовка блока не будет соответствовать порогу трудности (найден валидный заголовок блока), или (2) блок станет устаревшим (конкурирующий майнер отыскал валидный заголовок блока), или (3) будет исчерпано место поиска снутри поля nonce.

    Coinbase-транзакция

    Coinbase-транзакция — это особенный тип транзакции в любом блоке Биткойна, единственная транзакция, которая не показывает на имеющийся UTXO, но заместо этого выпускает новейшие BTC в согласовании с монетарной политикой протокола.

    Coinbase-транзакции важны по трем главным причинам: (1) в их создаются новейшие UTXO, (2) они обеспечивают доп место для поиска хеша и (3) разрешают майнерам помечать блоки как собственные.

    Coinbase-транзакция для блока 645 536 смотрится последующим образом:

    Coinbase-транзакция в блоке на высоте 645 536

    Каждое поле, его тип данных и короткое описание поля приведены в таблице:

    Поля данных транзакции

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

    Подпись скрипта (скрипт разблокировки) Подпись скрипта в coinbase-транзакции блока на высоте 645 536

    Подпись скрипта, именуемая также скриптом разблокировки, имеет переменную длину в б, которая ограничивается консенсусом сети. Обычно скрипт разблокировки содержит условия, дозволяющие применять UTXO предшествующей транзакции. Но в coinbase-транзакции имеющиеся UTXO не употребляются, а лишь создаются новейшие. Заместо этого, подпись скрипта содержит высоту блока (в согласовании с BIP34) и всякую другую информацию, которую майнер решит тут расположить. Весьма нередко сюда врубаются характеристики extranonce, также любые идентифицирующие «подписи», которые майнер может располагать по собственному усмотрению.

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

    Разбирая подпись скрипта, 1-ые 1–9 байтов обозначают длину скрипта разблокировки, являющуюся переменной. В этом случае длина составляет 0x4B (десятичные 75) б.

    Последующий б обозначает длину последующей части coinbase-транзакции. В этом случае это 0x03, что гласит о том, что последующие три б, 0xA0D909, имеют значение. В эти б записана высота блока, 645 536, в шестнадцатеричном little-endian формате, в согласовании с BIP34. Последующие 64 б содержат extranonce и всякую другую информацию, которую майнер решит тут расположить. Размер параметра extranonce варьируется от пула к пулу.

    В конце концов, крайние семь байтов, 0x2F736C7573682F, — это необязательный идентификатор, применяемый SlushPool для пометки собственных блоков, /slush/. Снабжая блок сиим идентификатором, пул на публике докладывает, что этот блок был получен от него.

    Естественно, хоть какой иной субъект сети, добывший валидный блок, может включить в coinbase-транзакцию этот же текст и притвориться SlushPool либо каким-то иным майнером. И напротив, Slush (либо хоть какой иной майнер) может исключить из подписи скрипта собственный обыденный идентификатор и добыть блок анонимно.

    Большая часть майнеров обычно добавляют свое имя, чтоб показать, что они добывают блоки (это имеет смысл исходя из убеждений маркетинга, чтоб показать удачливость вашего пула), но буквально так же тут можно расположить любые остальные данные либо не располагать ничего. Чтоб составить представление о том, какой процент майнеров включают в coinbase-транзакцию собственный идентификатор, в четырехдневный период с 25 по 28 сентября 2020 года идентификатор находился в 77,7% блоков.

    Заключение

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

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

    Заголовок блока исключителен в собственной простоте, но при всем этом имеет огромное количество применений и вариантов использования. Существуя в таком формате уже наиболее 10 лет, он все еще довольно гибок, чтоб приспособиться по мере конфигурации и роста сети. То, как поля работают, может изменяться и изменяется к наилучшему, как видно на примере механизма сигнализации о софт-форках в поле версии. Изменяется и внедрение полей: к примеру, майнеры могут применять поля версии, метки времени и coinbase-транзакции для расширения места поиска хеша. Креативность разрабов и юзеров в использовании заголовка блока и его полей для заслуги новейших целей и сотворения новейших вариантов его внедрения впечатляет, и мне не терпится выяснить, что принесет нам последующее десятилетие нововведений. Но что бы это ни было, я уверен, что заголовок блока будет лежать в базе данной нам прелестной системы.

     

    Делитесь вашим воззрением о данной нам статье в комментах ниже.

    Author: Anonim