Блоки

Редагувати сторінку

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

Передумови

Блоки — це дуже зручна для новачків тема. Але щоб допомогти вам краще зрозуміти цю сторінку, ми рекомендуємо спочатку прочитати про акаунти, транзакції та наш вступ до Етеріуму.

Навіщо потрібні блоки?

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

Діаграма адаптована з Ethereum EVM illustrated (opens in a new tab)

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

Як працюють блоки

Щоб зберегти історію транзакцій, блоки суворо впорядковані (кожен новий створений блок містить посилання на свій батьківський блок), і транзакції всередині блоків також суворо впорядковані. За винятком рідкісних випадків, у будь-який момент часу всі учасники мережі погоджуються щодо точної кількості та історії блоків і працюють над тим, щоб об'єднати поточні активні запити на транзакції в наступний блок.

Щойно блок збирається випадково обраним валідатором у мережі, він поширюється на решту мережі; усі вузли додають цей блок у кінець свого блокчейну, і обирається новий валідатор для створення наступного блоку. Точний процес збирання блоку та процес фіксації/консенсусу наразі визначається протоколом Етеріуму «доказ частки (PoS)».

Протокол доказу частки (PoS)

Доказ частки (PoS) означає наступне:

Вузли-валідатори повинні стейкати 32 ETH у депозитний контракт як заставу проти недобросовісної поведінки. Це допомагає захистити мережу, оскільки доказово нечесна діяльність призводить до знищення частини або всього цього стейку.
У кожному слоті (з інтервалом у 12 секунд) випадковим чином обирається валідатор, який стає пропонувачем блоку. Він об'єднує транзакції разом, виконує їх і визначає новий «стан». Він загортає цю інформацію в блок і передає її іншим валідаторам.
Інші валідатори, які дізнаються про новий блок, повторно виконують транзакції, щоб переконатися, що вони згодні із запропонованою зміною глобального стану. Якщо блок дійсний, вони додають його до власної бази даних.
Якщо валідатор дізнається про два конфліктні блоки для одного слота, він використовує свій алгоритм вибору форку, щоб вибрати той, який підтримується найбільшою кількістю застейканих ETH.

Більше про доказ частки (PoS)

Що знаходиться в блоці?

У блоці міститься багато інформації. На найвищому рівні блок містить такі поля:

Поле	Опис
`slot`	слот, до якого належить блок
`proposer_index`	ID валідатора, який пропонує блок
`parent_root`	хеш попереднього блоку
`state_root`	кореневий хеш об'єкта стану
`body`	об'єкт, що містить кілька полів, як визначено нижче

Блок body містить кілька власних полів:

Поле	Опис
`randao_reveal`	значення, що використовується для вибору наступного пропонувача блоку
`eth1_data`	інформація про депозитний контракт
`graffiti`	довільні дані, що використовуються для позначення блоків
`proposer_slashings`	список валідаторів, до яких буде застосовано слешинг
`attester_slashings`	список атестаторів, до яких буде застосовано слешинг
`attestations`	список атестацій, зроблених для попередніх слотів
`deposits`	список нових депозитів у депозитний контракт
`voluntary_exits`	список валідаторів, що виходять з мережі
`sync_aggregate`	підмножина валідаторів, що використовується для обслуговування легких клієнтів
`execution_payload`	транзакції, передані від клієнта виконання

Поле attestations містить список усіх атестацій у блоці. Атестації мають власний тип даних, який містить кілька елементів даних. Кожна атестація містить:

Поле	Опис
`aggregation_bits`	список валідаторів, які брали участь у цій атестації
`data`	контейнер із кількома підполями
`signature`	сукупний підпис набору валідаторів для частини `data`

Поле data в attestation містить наступне:

Поле	Опис
`slot`	слот, якого стосується атестація
`index`	індекси валідаторів, що атестують
`beacon_block_root`	кореневий хеш блоку маяка, який розглядається як голова ланцюга
`source`	остання обґрунтована контрольна точка
`target`	останній граничний блок епохи

Виконання транзакцій у execution_payload оновлює глобальний стан. Усі клієнти повторно виконують транзакції в execution_payload, щоб переконатися, що новий стан збігається зі станом у полі state_root нового блоку. Саме так клієнти можуть визначити, що новий блок є дійсним і безпечним для додавання до їхнього блокчейну. Сам execution payload є об'єктом із кількома полями. Також існує execution_payload_header, який містить важливу зведену інформацію про дані виконання. Ці структури даних організовані таким чином:

execution_payload_header містить такі поля:

Поле	Опис
`parent_hash`	хеш батьківського блоку
`fee_recipient`	адреса акаунта для сплати комісій за транзакції
`state_root`	кореневий хеш для глобального стану після застосування змін у цьому блоці
`receipts_root`	хеш дерева квитанцій транзакцій
`logs_bloom`	структура даних, що містить журнали подій
`prev_randao`	значення, що використовується у випадковому виборі валідатора
`block_number`	номер поточного блоку
`gas_limit`	максимальна кількість газу, дозволена в цьому блоці
`gas_used`	фактична кількість газу, використаного в цьому блоці
`timestamp`	час блоку
`extra_data`	довільні додаткові дані у вигляді необроблених байтів
`base_fee_per_gas`	значення базової комісії
`block_hash`	хеш блоку виконання
`transactions_root`	кореневий хеш транзакцій у корисному навантаженні
`withdrawal_root`	кореневий хеш виведень у корисному навантаженні

Сам execution_payload містить наступне (зверніть увагу, що це ідентично заголовку, за винятком того, що замість кореневого хешу транзакцій він включає фактичний список транзакцій та інформацію про виведення):

Поле	Опис
`parent_hash`	хеш батьківського блоку
`fee_recipient`	адреса акаунта для сплати комісій за транзакції
`state_root`	кореневий хеш для глобального стану після застосування змін у цьому блоці
`receipts_root`	хеш дерева квитанцій транзакцій
`logs_bloom`	структура даних, що містить журнали подій
`prev_randao`	значення, що використовується у випадковому виборі валідатора
`block_number`	номер поточного блоку
`gas_limit`	максимальна кількість газу, дозволена в цьому блоці
`gas_used`	фактична кількість газу, використаного в цьому блоці
`timestamp`	час блоку
`extra_data`	довільні додаткові дані у вигляді необроблених байтів
`base_fee_per_gas`	значення базової комісії
`block_hash`	хеш блоку виконання
`transactions`	список транзакцій для виконання
`withdrawals`	список об'єктів виведення

Список withdrawals містить об'єкти withdrawal, структуровані таким чином:

Поле	Опис
`address`	адреса акаунта, з якого здійснено виведення
`amount`	сума виведення
`index`	значення індексу виведення
`validatorIndex`	значення індексу валідатора

Час блоку

Час блоку — це час, що розділяє блоки. В Етеріумі час поділяється на 12-секундні одиниці, які називаються «слотами». У кожному слоті обирається один валідатор, який пропонує блок. За умови, що всі валідатори перебувають у мережі та повністю функціонують, у кожному слоті буде блок, що означає, що час блоку становить 12 с. Однак іноді валідатори можуть бути не в мережі, коли їх викликають запропонувати блок, що означає, що слоти іноді можуть залишатися порожніми.

Ця реалізація відрізняється від систем на основі доказу виконання роботи (PoW), де час блоку є імовірнісним і налаштовується цільовою складністю майнінгу протоколу. Середній час блоку (opens in a new tab) Етеріуму є чудовим прикладом цього, завдяки чому перехід від доказу виконання роботи до доказу частки можна чітко простежити на основі стабільності нового 12-секундного часу блоку.

Розмір блоку

Останнє важливе зауваження полягає в тому, що самі блоки обмежені в розмірі. Кожен блок має цільовий розмір у 30 мільйонів газу, але розмір блоків буде збільшуватися або зменшуватися відповідно до потреб мережі, аж до ліміту блоку в 60 мільйонів газу (у 2 рази більше цільового розміру блоку). Ліміт газу блоку може бути скоригований у більшу або меншу сторону на коефіцієнт 1/1024 від ліміту газу попереднього блоку. У результаті валідатори можуть змінювати ліміт газу блоку через консенсус. Загальна кількість газу, витраченого всіма транзакціями в блоці, має бути меншою за ліміт газу блоку. Це важливо, оскільки гарантує, що блоки не можуть бути довільно великими. Якби блоки могли бути довільно великими, то менш продуктивні повні вузли поступово перестали б встигати за мережею через вимоги до простору та швидкості. Чим більший блок, тим більша обчислювальна потужність потрібна для його обробки вчасно до наступного слота. Це централізуюча сила, якій протидіють шляхом обмеження розмірів блоків.