Блок-пропозиція

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

Передумови

Пропозиція блоку є частиною протоколу підтвердження частки. Щоб краще зрозуміти цю сторінку, радимо вам прочитати про доказ частки та архітектуру блоків.

Хто створює блоки?

Облікові записи валідаторів пропонують блоки. Облікові записи валідаторів управляються операторами вузлів, які використовують програмне забезпечення валідатора як частину своїх клієнтів виконання і консенсусу і внесли щонайменше 32 ETH в депозитний контракт. Однак кожен валідатор лише іноді відповідає за пропозицію блоку. Ефіріум вимірює час у слотах та епохах. Кожен слот містить 12 секунд, а 32 слоти (6,4 хвилини) складають епоху. Кожен слот - це можливість додати новий блок на Ethereum.

Випадковий вибір

Один валідатор вибирається псевдовипадковим чином, щоб запропонувати блок у кожному слоті. У блокчейні не існує такого поняття, як справжня випадковість, тому що якби кожен вузол генерував справді випадкові числа, вони не змогли б дійти до консенсусу. Натомість метою є зробити процес вибору валідатора непередбачуваним. Випадковість досягається в Ethereum за допомогою алгоритму під назвою RANDAO, який змішує хеш від пропонента блоку з першоджерелом, яке оновлюється кожного блоку. Це значення використовується для вибору конкретного валідатора із загального набору валідаторів. Вибір валідатора фіксується на дві епохи наперед, щоб захиститися від певних видів маніпуляцій з першоджерелом.

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

У кожному слоті обирається лише одна пропозиція блоку. За звичайних умов, один виробник блоків створює і випускає один блок у своєму виділеному слоті. Створення двох блоків для одного слоту є порушенням, яке можна вилучити, часто відомим як "двозначність".

Як відбувається створення блоку?

Очікується, що пропонент блоку транслюватиме підписаний блок-маяк, який будується поверх останньої голови ланцюжка відповідно до подання його власного локального алгоритму вибору розгалуження. Алгоритм вибору розгалуження застосовує будь-які атестації в черзі, що залишилися від попереднього слота, а потім знаходить блок із найбільшою накопиченою вагою атестацій у своїй історії. Цей блок є родоначальником нового блоку, створеного автором.

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

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 — це блок даних виконання, який вкладається всередину маякового блоку. Поля всередині execution_payload відображають структуру блоку, описану в Жовтій книзі Ethereum, за винятком того, що немає оммерів, а prev_randao існує замість difficulty. Клієнт виконання має доступ до локального пулу транзакцій, про які він дізнався з власної мережі пліток. Ці транзакції виконуються локально, щоб згенерувати оновлену трійку станів, відому як пост-стан. Транзакції включені в execution_payload як список під назвою transactions, а післястан надається в полі state-root.

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

Дізнайтеся більше про анатомію блоків.

Що відбувається з блоком?

Блок додається до локальної бази даних пропонента блоку і транслюється одноранговим користувачам через мережу пліток консенсусного рівня. Коли валідатор отримує блок, він перевіряє дані всередині нього, включаючи перевірку того, що блок має правильного родоначальника, відповідає правильному слоту, що індекс пропонента є очікуваним, що RANDAO-розкриття є дійсним і що пропонент не є зрізаним. execution_payload розпаковується, і клієнт-виконавець валідатора повторно виконує транзакції зі списку, щоб перевірити запропоновану зміну стану. Якщо блок проходить всі ці перевірки, кожен валідатор додає його до свого канонічного ланцюжка. Потім процес починається знову в наступному слоті.

Винагороди за блок

Автор блоку отримує виплату за свою роботу. Існує base_reward, яка розраховується як функція від кількості активних валідаторів та їхніх ефективних балансів. Потім пропонувач блоку отримує частку base_reward за кожну дійсну атестацію, включену в блок; що більше валідаторів атестують блок, то більша винагорода пропонувача блоку. Також існує винагорода за повідомлення про валідаторів, які підлягають слешингу, що дорівнює 1/512 * effective balance за кожного такого валідатора.

Докладніше про винагороди та штрафи