Пропозиція блоку

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

Передумови

Пропозиція блоку є частиною протоколу доказу частки (PoS). Щоб краще зрозуміти цю сторінку, ми рекомендуємо вам прочитати про доказ частки (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 за кожного валідатора, що піддався слешингу.

Більше про винагороди та штрафи