[Из песочницы] Как работает Эфириум?

image


Введение


Наверняка некоторые из вас знают, что такое блокчейн Эфириум (с англ. Ethereum), другие, напротив, не имеют даже малейшего представления о нем. Так или иначе, и первые и вторые что-нибудь да слышали о данной платформе. В последнее время этой теме было посвящено множество статей в различных крупных журналах, однако для тех людей, кто мало что слышал об Эфириуме, все статьи на эту тему представляются чем-то мистическим и совершенно непонятным. Тогда, что же собой представляет данная платформа? Если вкратце: Эфириум — это общедоступная база данных с возможностью хранения цифровых транзакций в течение неограниченного времени. Важно также отметить, что для обслуживания и защиты такой базы данных не требуется каких-либо систем управления ключами. Вместо этого данная платформа работает как «беззащитная» транзакционная система — фреймворк, в котором физические лица могут совершать одноранговые транзакции, при этом ни одна из сторон не несет перед другой или третьей сторонами каких-либо обязательств.

Я не удивлюсь, если вы мало что поняли. Собственно, цель данной статьи — объяснить, каким образом блокчейн Эфириум функционирует на техническом уровне, не прибегая для этого к сложным математическим расчетам или ужасающим своей величиной формулам. Даже если вы и не программист, у меня есть полная уверенность в том, что данная статья поможет вам понять принципы технологии Эфириума. И даже если некоторые части данной статьи будут напичканы техническими определениями, которые могут показаться вам чересчур сложными для восприятия, вам не стоит отчаиваться, ведь ее цель — донести до вас понимание данной платформы в целом, не вдаваясь в технические и математические тонкости.
Многие из тем, затронутых в данной статье, представляют собой разжевывание тех основных понятий, с которыми вы, вероятно, уже не раз сталкивались, читая yellow paper (от англ. «желтая бумага» — официальная спецификация для Эфириума). Мною были добавлены собственные пояснения и диаграммы для того, чтобы вы как можно быстрей разобрались с данной технологией. Ну, а для самых храбрых и технически подкованных я могу посоветовать прочтения Ethereum yellow paper.

Давайте уже начнем!

Что такое блокчейн


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

  • «Криптографически безопасный» означает, что безопасность криптовалюты обеспечивается сложными математическими алгоритмами, которые практически невозможно обойти. Защита, выстроенная с помощью данных алгоритмов, представляет собой подобие файрвола: благодаря используемым алгоритмам обход системы безопасности практически невозможен (например, невозможно создание поддельных транзакций, уничтожение транзакций и т. д.).
  • «Транзакционная одноэлементная система» означает, что существует только одно заданное состояние системы, благодаря которому происходят все транзакции, создаваемые в данной системе. Другими словами, для данной системы предусмотрено только одно состояние, которое является единственно верным.
  • «С общим состоянием» означает, что состояние, заданное в системе, является общим и открытым для всех.


Таким образом, в платформе Эфириум реализуется приведенная выше парадигма блокчейна.

Парадигма блокчейна платформы Эфириум


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

image
Состояние Эфириума имеет миллионы транзакций. Эти транзакции сгруппированы в «блоки». Блок содержит ряд транзакций, при этом каждый последующий блок соединен с предыдущим, благодаря чему обеспечивается своеобразная цепочка блоков.
image
Транзакция должна быть корректной, для того чтобы вызвать ее переход из одного состояния в другое. Транзакция считается корректной только тогда, когда она прошла процесс проверки — так называемый «майнинг». Майнинг — это когда группа узлов (компьютеров) расходует свои вычислительные ресурсы для создания блока корректных транзакций.

Любой узел в сети, объявляющий себя майнером, может попытаться создать и проверить блок транзакций. Распространенным опытом является попытки множества майнеров одновременного создания и проверки блока транзакций. Каждый майнер предоставляет свое математическое «доказательство» при отправке блока в блокчейн, и это доказательство выступает в роли своеобразной гарантии: в случае если доказательство существует, транзакции в блоке считаются корректными.

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

Майнер, который обосновывает новый блок, получает определенное вознаграждение за выполнение этой работы. О каком вознаграждении идет речь? В блокчейне Эфириума используется встроенный цифровой токен, который носит название «эфир» (от англ. ether— «эфир»). Каждый раз, когда майнер обосновывает свой блок транзакций, создается новый токен или новый эфир, а майнер получает вознаграждение за его создание.

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

В самом начале данной статьи мы уже приводили такое понятие как «транзакционная одноэлементная система с общим состоянием». Исходя из такого определения можно сделать вывод, что не бывает двух и более корректных текущих состояний — оно является единственным в своем роде. Таким образом, каждый, кто принимает участие в процессе обоснования новых блоков, должен принять это утверждение за истину. Наличие нескольких состояний (или цепей) разрушило бы всю систему, потому что было бы невозможно договориться о том, какое из состояний является корректным. Например, представим, что существовало бы несколько цепочек блоков. Тогда, в теории, вы могли бы собрать 10 монет на одной цепочке, на другой — 20 монет, на третьей — 40 монет и т.д. В таком случае было бы невозможно определить, какая цепь является наиболее «корректной».

Всякий раз, когда генерируются несколько путей, возникает «разветвление». Зачастую, разветвления очень нежелательны, поскольку они нарушают целостность системы, а пользователям приходится выбирать одну из возможных цепочек.
image
Чтобы определить, какой из возможных путей является корректным, и предотвратить образования множества цепей, в Эфириуме применяется метод, называемый «протокол GHOST».

GHOST — «Жадное-и-Самое-Весомое-из-Известных-Дочерних-Деревьев» (Greedy Heaviest Observed Subtree)

Попробую объяснить простыми словами: протокол GHOST объявляет, что мы должны выбрать только тот путь, на котором было выполнено наибольшее число вычислений. Для определения такого пути можно использовать номер того блока, который был определен последним («листовой блок»). Благодаря такому подходу можно определить общее число блоков, находящихся в текущем пути (без учета блока первоначального состояния). Чем выше находится блок, тем длиннее путь и тем больше обоснований должны предоставить майнеры. Исходя из таких соображений, принимается единственно верная версия для текущего состояния.

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

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


Небольшое отступление перед тем, как мы начнем: при упоминании хэша X имеется ввиду хэш KECCAK-256, используемый в Эфириуме.

Учетные записи


Глобальное общее состояние платформы Эфириум состоит из множества небольших объектов — учетных записей, которые взаимодействуют между собой за счет парадигмы обмена сообщениями. У каждой учетной записи есть определенное состояние и 20-байтовый адрес. Адресом в Эфириум является 160-битный идентификатор, используемый для идентификации любой из учетных записей.

Всего существует два вида учетных записей:

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


image

Внешние и контрактные учетные записи


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

С помощью контрактных учетных записей, в отличие от внешних, самостоятельно инициировать новые транзакции невозможно. Вместо этого с помощью контрактных учетных записей можно только запускать транзакции в ответ на другие полученные транзакции (например, полученные из внешней учетной записи или из другой контрактной учетной записи). Более подробно о вызовах между контрактными учетными записями мы остановимся в разделе «Транзакции и сообщения».

image

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

image

Состояние учетных записей


Состояние каждой из учетных записей, вне зависимости от их типа, может принимать одно из четырех значений:

  • nonce: Если настоящая учетная запись соответствует внешней учетной записи, то полученное число представляет собой количество транзакций, которые были отправлены с адреса учетной записи. Если учетная запись является контрактной учетной записью, то элемент nonce — это количество контрактов, созданных в данной учетной записи.
  • balance: общее количество wei, приобретенных данной учетной записью. Например, каждый эфир, который является обменной единице Эфириума, содержит 1018 wei — дробных частей эфира.
  • storageRoot: хэш корневого узла префиксного дерева Меркла (что собой представляет дерево Меркла мы рассмотрим немного позже). Дерево Меркла кодирует хэш содержимого данной учетной записи, при этом по умолчанию оно является пустым.
  • codeHash: хэш EVM-кода (от англ. Ethereum Virtual Machine; что это такое я расскажу немного позже) учетной записи. Для контрактных учетных записей данное поле является кодом, который хэшируется и хранится в виде codeHash.


image

Общее состояние системы


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

Дерево Меркла (или «Merkle trie») представляет собой тип двоичного файла, состоящего из набора узлов, которые включают:

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


image

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

image

Для каждого значения, хранящегося внутри данного дерева, вам потребуется ввести определенный ключ. Для получения соответствующего значения, хранящегося в листовых узлах, вы должны получить команду ключа: цепочки какого дочернего узла необходимо придерживаться. Что касается Эфириума, то отображение ключа/значения, необходимого для дерева состояний, находится между адресами и связанными с ними учетными записями, в том числе balance, nonce, codeHash, а также storageRoot для каждой из учетных записей, при этом storageRoot является деревом.

image

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

  • Состояние префиксного дерева
  • Транзакции префиксного дерева
  • Страницы приема оплаты для префиксного дерева


image

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

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

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

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

image

Любой узел, для которого требуется проверка какой-либо части данных, использует так называемое «доказательством Меркла». Последнее состоит из:

  • Фрагмента данных, который должен быть проверен
  • Корневого хэша дерева
  • Так называемой «ветви» — всех хэшей, от проверяемого фрагмента данных до корня.


image

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

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

Горючее и вознаграждение


Одним из важных моментов в системе Эфириума является процесс оплаты. За любое вычисление, осуществляющееся в результате проведения операций с транзакциями внутри сети Эфириума, берется определенная плата. Номинал данной оплаты носит название «горючее» (от англ. gas).

Горючее — это единица измерения, которая используется для определения размера оплаты по конкретному вычислению. Цена на горючее — это количество «эфира», которое вы способны потратить на каждую единицу горючего. Измеряется цена на горючее в «gwei». Wei является самой маленькой единицей эфира, где 1018 Wei –это всего 1 эфир. Один gwei равен 1 000 000 000 Wei.

Для проведения любой транзакции отправитель должен установить лимит горючего, а также цену на горючее. Цена на горючее и лимит горючего — это максимальная сумма в Wei, которую отправитель готов заплатить за проведение транзакции.

Давайте представим, что отправитель устанавливает лимит горючего в 50 000 gwei, а цену на горючее — в 20 gwei. Это значит, что отправитель готов потратить не более 50 000×20 gwei = 1 000 000 000 000 000 Wei или 0,001 эфира для проведения данной транзакции.

image

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

image

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

image

«Куда именно я отправляю горючее?» — спросите вы. Итак, все деньги, которые были потрачены на приобретение отправителем горючего, отправляются на адрес бенефициария, который в большинстве случаев является адресом майнера. Поскольку майнеры выполняют расчеты и проверку транзакций, то именно они получают плату за горючее в качестве вознаграждения.

image

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

Оплата за использование хранилища


Горючее используется не только для оплаты тех или иных вычислений, но также и для оплаты за использование хранилища. Общая плата за использование хранилища составляет 32 используемых байта.

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

Для чего предусмотрена оплата?


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

В Эфириуме используется полный по Тьюрингу язык. Если вкратце: машина Тьюринга — это машина, имитирующая любой компьютерный алгоритм. Для тех, кто впервые слышит о машине Тьюринга, предлагаю прочитать эту и вот эту статьи. Благодаря такой особенности в Эфириуме появляется возможность использовать циклы, и это делает его восприимчивым к проблеме остановки — проблеме, в случае возникновения которой, вы не можете определить, будет ли программа функционировать бесконечно или нет. Например, в том случае если бы в Эфириуме не была бы предусмотрена система оплаты, то злоумышленники могли бы попытаться сорвать работу сети, выполнив бесконечный цикл внутри транзакции, при этом не понеся каких-либо убытков. Таким образом, система оплаты была введена именно для ее защиты от преднамеренных атак.

Вполне вероятно, что вы подумаете: «А я-то тут причем? Зачем я буду платить за использование хранилища?» Ну, что вам сказать, вся сеть Эфириума берет на себя плату как за вычисления, так и за использования хранилища…как-то так.

Транзакции и сообщения


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

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

Всего существует два типа транзакций: отправка сообщений и создание контракта (другими словами, такие транзакции создают новые контракты в сети Эфириума).

Все транзакции содержат следующие элементы, вне независимости от типа первых:

  • nonce — количество транзакций, которые были отправлены отправителем.
  • gasPrice — количество Wei, которое отправитель готов отдать за единицу горючего, необходимую для совершения сделки.
  • gasLimit — максимальное количество горючего, которое отправитель готов заплатить за проведение данной транзакции. Такая сумма задается и оплачивается заранее, прежде чем какие-либо вычисления будут проведены.
  • to — адрес получателя. На момент выполнения транзакции, связанной с созданием контракта, адреса учетной записи контракта еще не существует, поэтому вместо него используется пустое значение.
  • value — количество Wei, которые будут переданы от отправителя к получателю. В транзакциях, связанных с созданием контрактов, данная величина является стартовым балансом для вновь созданной учетной записи.
  • v, r, s — данные обозначения, используемые для создания подписи, которая идентифицирует отправителя транзакции.
  • init — предназначен только для транзакций, связанных с созданием контрактов. Фрагмент EVM-кода, используемый для инициализации вновь созданной учетной записи контракта. init запускается только единожды и в дальнейшем не используется. Когда init запускается в первый раз, данный элемент возвращает тело кода учетной записи, которое представляет собой часть кода, постоянно связанную с учетной записью контракта.
  • data — это входные данные (параметры) для вызова сообщения (data является необязательным элементом, который предназначен только для вызовов сообщений). Например, если смарт-контракт играет роль службы регистрации домена, то вызов этого контракта может ожидать поля ввода (например, домен и IP-адрес).


image

Из информации, приведенной в разделе «Учетные записи», мы выяснили, что транзакции — как для вызовов сообщений, так и для создания контрактов –инициируются внешними учетными записями, а затем перенаправляются в блокчейн. Другими словами, транзакции — это своеобразный мост, соединяющий внешний мир и внутреннее состояние платформы Эфириума.

image

Но это не значит, что одни контракты не могут взаимодействовать с другими: контракты, находящиеся в глобальном контексте состояния Эфириума, могут взаимодействовать друг с другом в пределах данного контекста. Их взаимодействие или общение происходит с помощью отправки сообщений или внутренних транзакций. Единственное отличие внутренних транзакций от обычных заключается в том, что первые не создаются внешними учетными записями –, но в результате создания контрактов. Они являются виртуальными объектами, которые, в отличие от транзакций, не упорядочиваются и могут существовать только в среде исполнения Эфириума.

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

image

Стоит также отметить, что для внутренних транзакций или сообщений gasLimit не предусмотрен, поскольку лимит горючего задает инициатор исходной транзакции (например, в какой-либо учетной записи). Лимит горючего, задаваемый внешней учетной записью, должен быть достаточно высокими для проведения транзакции, включая любые дополнительные действия, которые выполняются в результате проведения данной транзакции, например, передача сообщения от одного контракта к другому. В том случае если в цепочке транзакций и сообщений для выполнения одного из последних недостаточно горючего, то его выполнение, а также выполнение всех последующих сообщений, вызванных изначальным выполнением, будет возвращено.

Блоки


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

Такие блоки состоят из:

  • заголовка блока
  • информации о серии транзакций, включенных в данный блок
  • серии других заголовков блоков для текущих оммеров


Что такое «оммеры»?


Давайте разберемся с тем, что такое оммер (от англ. «ommer»). Оммер — это блок, родителем которого является родительский элемент текущего блока. В этой главе я вкратце опишу, для чего вообще нужны оммеры, а также из каких соображений в блоке содержится заголовки блоков для оммеров.

Их наличие, в первую очередь, обосновано тем, что время блокировки в Эфириуме намного ниже (примерно 15 секунд), чем для других блокчейнов, например, для биткоинов (примерно 10 секунд). Благодаря такой особенности скорость транзакций проведения увеличивается. С другой стороны, одной из негативных сторон более короткого времени блокировки является то, что борьба майнеров за очередное блочное решение только усиливается. Такие конкурирующие блоки еще называют «блоки без родителя» (т.е. такие блоки не входят в основную цепочку блоков).

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

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

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


Я уже упоминал ранее о том, что каждый блок имеет заголовок, но мы так толком и не разобрались, что это такое?

Заголовок блока — это часть блока, которая состоит из:

  • parentHash — является хэшем заголовка родительского блока (благодаря чему, собственно, блок попадает в цепочку блоков)
  • ommersHash — хэш текущего списка блоков оммеров
  • beneficiary — адрес учетной записи, на который поступает оплата за включение этого блока
  • stateRoot — хэш корневого узла состояния префиксного дерева (ранее я писал, что состояние префиксного дерева хранится в заголовке, тем самым для тонких клиентов упрощается процесс утверждения состояния)
  • transactionsRoot — хэш корневого узла префиксного дерева, содержащий все транзакции, которые перечислены в данном блоке
  • receiptsRoot — хэш корневого узла префиксного дерева, который содержит информацию об оплате для всех транзакций, перечисленных в данном блоке
  • logsBloom — Фильтр Блума (структура данных), состоящий из информации, содержащейся в журналах
  • difficulty — уровень сложности текущего блока
  • number — номер текущего блока (первоначальный блок имеет номер, равный нулю; номер блока увеличивается на единицу для каждого последующего блока)
  • gasLimit — текущий лимит горючего для текущего блока
  • gasUsed — общее количество горючего, используемого для транзакций в текущем блоке
  • timestamp — временная отметка, предназначенная для создания текущего блока
  • extraData — дополнительные данные, которые касаются текущего блока
  • mixHash — хэш, который в сочетании с элементом nonce утверждает, что для текущего блока выполняется достаточно вычислений
  • nonce — хэш, который в сочетании с элементом mixHash утверждает, что для текущего блока выполняется достаточно вычислений


image

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

  • состояния (stateRoot)
  • проведения транзакции (transactionsRoot)
  • получения информации об оплате (receiptsRoot)


Такие структуры префиксного дерева являются ничем иным, кроме как префиксным деревом Меркла, которое мы уже рассматривали выше.

Кроме того, для такого определения существует несколько терминов, которые, вероятно, должны вам показаться интересными.

Журналы


В платформе Эфириума предусмотрена возможность вести журналы, цель которых записывать информацию о различных транзакциях и сообщениях. Кроме того, для контракта также существует возможность открытого создания записи в таком журнале с помощью объявления «события», которое требуется записать.

Запись журнала включает:

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

    © Geektimes