Предложение блока

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

Предварительные условия

Предложение блока — часть протокола доказательства владения. Чтобы лучше понять эту страницу, мы рекомендуем вам прочитать о доказательстве владения (proof-of-stake) и архитектуре блоков.

Кто предлагает блоки? Кто создает блоки?

Аккаунты валидаторов предлагают блоки. Аккаунты валидаторов управляются операторами узлов, которые запускают программы валидаторов в рамках своих клиентов исполнения и консенсуса. Также для этого операторы узлов должны иметь не менее 32 ETH, внесённых в депозитный контракт. Однако каждый валидатор лишь периодически предлагает блок. Эфириум измеряет время в ячейках и эпохах. Каждая ячейка длится 12 секунд, а 32 ячейки (6,4 минуты) составляют одну эпоху. Каждая ячейка является возможностью добавить новый блок в сеть.

Случайный выбор

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

Хотя валидаторы и делают дополнения к значению RANDAO в каждой ячейке, глобальное значение RANDAO обновляется лишь раз за эпоху. Чтобы вычислить индекс следующего инициатора блока, значение RANDAO смешивается с номерами ячеек для получения уникального значения в каждой из них. Вероятность того, что будет выбран отдельный валидатор, не равна 1/N (где N = общее количество активных валидаторов). Вместо этого, она является взвешенной для каждого валидатора в соответствии с его эффективным балансом ETH. Максимальный эффективный баланс составляет 32 ETH (это означает, что balance < 32 ETH приводит к меньшему весу, чем balance == 32 ETH, но balance > 32 ETH не приводит к большему весу, чем balance == 32 ETH).

Только один инициатор блока выбирается в каждой ячейке. При нормальных условиях, один производитель блока создаёт и выпускает один блок в свою выделенную ячейку. Создание двух блоков для одной и той же ячейки является нарушением, известным как "неоднозначность", из-за которого может пройти наказание валидатора.

Как создаётся блок?

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

Инициатор блока создаёт блок, собирая данные из своей локальной базы данных и просматривая сеть. Содержимое блока показано во фрагменте ниже:

1class BeaconBlockBody(Container):
2    randao_reveal: BLSSignature
3    eth1_data: Eth1Data
4    graffiti: Bytes32
5    proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
6    attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]
7    attestations: List[Attestation, MAX_ATTESTATIONS]
8    deposits: List[Deposit, MAX_DEPOSITS]
9    voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
10    sync_aggregate: SyncAggregate
11    execution_payload: ExecutionPayload
Показать все

Поле randao_reveal принимает проверяемое случайное значение, которое инициатор блока получает, подписывая номер текущей эпохи. eth1_data — это голос за представление инициатора блока о депозитном контракте, включающий корень дерева Меркла депозитов и общее количество депозитов, которое позволяет проверять новые депозиты. graffiti — это необязательное поле, которое можно использовать для добавления сообщения в блок. proposer_slashings и attester_slashings — это поля, содержащие доказательство того, что определённые валидаторы совершили наказуемые нарушения, в соответствии с представлением инициатора о цепочке. deposits — это список новых депозитов валидаторов, о которых известно инициатору блока, а voluntary_exits — это список валидаторов, желающих выйти, о чём инициатор блока узнал в gossip-сети уровня консенсуса. sync_aggregate — это вектор, показывающий, какие валидаторы были ранее назначены в комитет синхронизации (подмножество валидаторов, обслуживающее данные легких клиентов) и участвовали в подписи данных.

execution_payload позволяет передавать информацию о транзакциях между клиентом исполнения и клиентом консенсуса. execution_payload — это блок данных исполнения, который вкладывается в Beacon-блок. Поля внутри execution_payload отражают структуру блоков, описанную в Жёлтой книге Ethereum, за исключением того, что в ней нет оммеров и prev_randao существует вместо difficulty. Клиент-исполнитель имеет доступ к локальному пулу транзакций, о которых он узнал из собственной сети gossip. Эти транзакции выполняются локально для генерации обновленного состояния, известного как post-state. Транзакции включены в execution_payload в виде списка с названием transactions, а пострезультативное состояние предоставляется в поле state-root.

Все эти данные собираются в блоке beacon, подписываются и передаются узлам-соседям инициатора, которые распространяют их своим соседям и т. д.

Узнайте больше об анатомии блоков.

Что происходит с блоком?

Блок добавляется на локальную базу данных инициатора и передаётся соседним узлам через gossip сеть консенсус-леера. Когда валидатор получает блок, он проверяет данные внутри него, включая проверку правильности родителя блока, принадлежности к правильной ячейке, корректности индекса инициатора, правильности раскрытия RANDAO и того, что инициатор не наказан сокращением. execution_payload распаковывается, и клиент исполнения валидатора повторно выполняет транзакции из списка, чтобы проверить предложенное изменение состояния. Если блок проходит все эти проверки, каждый валидатор добавляет его в свою собственную каноническую цепочку. Затем процесс начинается снова в следующей ячейке.

Награды за блок

Инициатор блока получает плату за свою работу. Существует base_reward, рассчитываемая как функция от количества активных валидаторов и их эффективных балансов. Затем инициатор блока получает долю от base_reward за каждую действительную аттестацию, включенную в блок; чем больше валидаторов подтверждают блок, тем больше вознаграждение инициатора блока. Также существует вознаграждение за сообщение о валидаторах, подлежащих слэшингу, равное 1/512 * effective balance за каждого валидатора, подвергнутого слэшингу.

Подробнее о вознаграждениях и штрафах