Предложение блоков
Блоки — это фундаментальные единицы блокчейна. Блоки представляют собой дискретные единицы информации, которые передаются между узлами, согласовываются и добавляются в базу данных каждого узла. На этой странице объясняется, как они создаются.
Предварительные требования
Предложение блоков является частью протокола доказательства доли владения (PoS). Чтобы лучше понять эту страницу, мы рекомендуем вам прочитать о доказательстве доли владения и архитектуре блоков.
Кто создает блоки?
Аккаунты валидаторов предлагают блоки. Аккаунты валидаторов управляются операторами узлов, которые запускают программное обеспечение валидатора как часть своих клиентов исполнения и консенсуса и внесли не менее 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).
В каждом слоте выбирается только один предлагающий блок. В нормальных условиях один производитель блока создает и выпускает один блок в выделенном ему слоте. Создание двух блоков для одного и того же слота является нарушением, за которое предусмотрен слэшинг, часто называемым «эквивокация».
Как создается блок?
Ожидается, что предлагающий блок будет транслировать подписанный блок сигнальной цепи, который строится поверх самой последней головы цепи в соответствии с представлением его собственного локально запущенного алгоритма выбора форка. Алгоритм выбора форка применяет любые поставленные в очередь аттестации, оставшиеся от предыдущего слота, а затем находит блок с наибольшим накопленным весом аттестаций в своей истории. Этот блок является родительским для нового блока, созданного предлагающим.
Предлагающий блок создает блок, собирая данные из своей локальной базы данных и представления цепи. Содержимое блока показано во фрагменте ниже:
class BeaconBlockBody(Container):
randao_reveal: BLSSignature
eth1_data: Eth1Data
graffiti: Bytes32
proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]
attestations: List[Attestation, MAX_ATTESTATIONS]
deposits: List[Deposit, MAX_DEPOSITS]
voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
sync_aggregate: SyncAggregate
execution_payload: ExecutionPayload
Поле randao_reveal принимает проверяемое случайное значение, которое предлагающий блок создает путем подписания номера текущей эпохи. eth1_data — это голос за представление предлагающего блок о депозитном контракте, включая корень дерева Меркла депозитов и общее количество депозитов, что позволяет проверять новые депозиты. graffiti — это необязательное поле, которое можно использовать для добавления сообщения в блок. proposer_slashings и attester_slashings — это поля, содержащие доказательства того, что определенные валидаторы совершили нарушения, за которые предусмотрен слэшинг, согласно представлению предлагающего о цепи. deposits — это список новых депозитов валидаторов, о которых известно предлагающему блок, а voluntary_exits — это список валидаторов, желающих совершить выход, о которых предлагающий блок узнал в gossip-сети уровня консенсуса. sync_aggregate — это вектор, показывающий, какие валидаторы были ранее назначены в комитет синхронизации (подмножество валидаторов, обслуживающих данные для легких клиентов) и участвовали в подписании данных.
execution_payload позволяет передавать информацию о транзакциях между клиентами исполнения и консенсуса. execution_payload — это блок данных исполнения, который вкладывается внутрь блока сигнальной цепи. Поля внутри execution_payload отражают структуру блока, описанную в желтой книге Эфириума, за исключением того, что в ней нет оммеров (ommers), а prev_randao существует вместо difficulty. Клиент исполнения имеет доступ к локальному пулу транзакций, о которых он узнал в своей собственной gossip-сети. Эти транзакции выполняются локально для создания обновленного дерева состояний, известного как пост-состояние (post-state). Транзакции включаются в execution_payload в виде списка под названием transactions, а пост-состояние предоставляется в поле state-root.
Все эти данные собираются в блок сигнальной цепи, подписываются и транслируются пирам предлагающего блок, которые распространяют его дальше своим пирам и т. д.
Узнайте больше об анатомии блоков.
Что происходит с блоком?
Блок добавляется в локальную базу данных предлагающего блок и транслируется пирам по gossip-сети уровня консенсуса. Когда валидатор получает блок, он проверяет данные внутри него, включая проверку того, что блок имеет правильного родителя, соответствует правильному слоту, что индекс предлагающего является ожидаемым, что раскрытие RANDAO действительно и что предлагающий не подвергся слэшингу. execution_payload распаковывается, и клиент исполнения валидатора повторно выполняет транзакции из списка, чтобы проверить предложенное изменение состояния. При условии, что блок проходит все эти проверки, каждый валидатор добавляет блок в свою собственную каноническую цепь. Затем процесс начинается снова в следующем слоте.
Вознаграждения за блок
Предлагающий блок получает оплату за свою работу. Существует base_reward, рассчитываемое как функция от количества активных валидаторов и их эффективных балансов. Затем предлагающий блок получает часть base_reward за каждую действительную аттестацию, включенную в блок; чем больше валидаторов аттестуют блок, тем больше вознаграждение предлагающего блок. Также существует вознаграждение за сообщение о валидаторах, которые должны быть подвергнуты слэшингу, равное 1/512 * effective balance за каждого валидатора, подвергнутого слэшингу.
Подробнее о вознаграждениях и штрафах