Блоки
Останні оновлення сторінки: 23 лютого 2026 р.
Блоки - це партії транзакцій з хешем попереднього блоку в ланцюжку. Це пов'язує блоки разом (у ланцюжку), оскільки хеші криптографічно виводяться з даних блоку. Це запобігає шахрайству, оскільки одна зміна будь -якого блоку в історії скасовує всі наступні блоки, оскільки всі наступні хеші змінюються, і всі, хто запускає блокчейн, помітять це.
Передумови
Блоки - це тема, дуже зручна для початківців. Але щоб допомогти вам краще зрозуміти цю сторінку, ми рекомендуємо вам спочатку прочитати Облікові записи, Транзакції та наш вступ до Ethereum.
Чому блоки?
Для того, щоб впевнитися, що всі учасники платформи "Ethereum" залишаються синхронізованими і погоджуються з точною історією транзакцій, ми поділяємо транзакції на блоки. Це означає, що десятки (або сотні) транзакцій фіксуються, узгоджуються та синхронізуються одночасно.
Діаграма адаптована з Ethereum EVM illustratedopens in a new tab
Розміщуючи коміти, ми даємо всім учасникам мережі достатньо часу для досягнення консенсусу: хоча запити на транзакції надходять десятки разів на секунду, блоки створюються і фіксуються в Ethereum лише раз на дванадцять секунд.
Як працюють блоки
Щоб зберегти історію транзакцій, блоки строго впорядковані (кожен новий створений блок містить посилання на свій батьківський блок), а також строго впорядковуються транзакції всередині блоків. За винятком рідкісних випадків, у будь-який момент часу всі учасники мережі погоджуються щодо точної кількості та історії блоків і працюють над пакетним пакетом поточних запитів на реальні транзакції в наступний блок.
Після того, як блок створений випадково обраним валідатором в мережі, він поширюється на решту мережі; всі вузли додають цей блок в кінець свого блокчейну, а для створення наступного блоку обирається новий валідатор. Точний процес збірки блоків і процес прийняття зобов'язань/консенсусу наразі визначений протоколом Ethereum "підтвердження частки".
Протокол доказу частки
Підтвердження частки означає наступне:
- Перевірка вузлів повинна забезпечити 32 ETH у депозитний контракт як заставу на випадок поганої поведінки. Це допомагає захистити мережу, оскільки доведено, що нечесна діяльність призводить до знищення частини або всієї цієї частки.
- У кожному слоті (з інтервалом у дванадцять секунд) випадковим чином обирається валідатор, який стає пропонентом блоку. Вони об'єднують транзакції разом, виконують їх і визначають новий "стан". Вони заносять цю інформацію в блок і передають його іншим валідаторам.
- Інші валідатори, які дізнаються про новий блок, повторно виконують транзакції, щоб переконатися, що вони згодні із запропонованою зміною глобального стану. Якщо блок дійсний, вони додають його до власної бази даних.
- Якщо валідатор чує про два суперечливих блоки на один і той же слот, він використовує свій алгоритм вибору вилки, щоб вибрати той, який підтримується найбільшою часткою ETH.
Що таке блок?
У блоці міститься багато інформації. На найвищому рівні блок містить наступні поля:
| Поле | Опис |
|---|---|
slot | слот, до якого належить блок |
proposer_index | ідентифікатор валідатора, який запропонував блок |
parent_root | хеш попереднього блоку |
state_root | кореневий хеш цільового об'єкта |
опис | об'єкт, що містить кілька полів, як визначено нижче |
Тіло (body) блоку містить кілька власних полів:
| Поле | Опис |
|---|---|
randao_reveal | значення, яке використовується для вибору наступного пропонента блоку |
eth1_data | інформація про депозитний договір |
graffiti | довільні дані для тегування блоків |
proposer_slashings | список валідаторів, що підлягають скороченню |
attester_slashings | список атестаторів, які підлягають скороченню |
attestations | список атестацій, зроблених для попередніх слотів |
депозити | список нових вкладів до депозитного договору |
voluntary_exits | список валідаторів, які виходять з мережі |
sync_aggregate | підмножина валідаторів, що використовуються для обслуговування легких клієнтів |
execution_payload | транзакції, передані від виконавчого клієнта |
Поле attestations містить список усіх атестацій у блоці. Атестації мають власний тип даних, який містить певну інформацію. Кожна атестація містить:
| Поле | Опис |
|---|---|
aggregation_bits | перелік валідаторів, які брали участь у цій атестації |
дані | контейнер з декількома підполями |
signature | агрегований підпис набору валідаторів для частини data |
Поле data в attestation містить таке:
| Поле | Опис |
|---|---|
slot | слот, до якого відноситься атестація |
index | показники для атестування валідаторів |
beacon_block_root | кореневий хеш блоку Beacon, що розглядається як голова ланцюга |
джерело | остання обґрунтована контрольна точка |
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 містить об'єкти withdrawal, структуровані таким чином:
| Поле | Опис |
|---|---|
адреса | адреса облікового запису, з якого було знято |
сума | сума зняття |
index | значення індексу зняття |
validatorIndex | значення індексу валідатора |
Час блоку
Час блоку - це час, що розділяє блоки. В Ethereum час поділено на 12 секундних одиниць під назвою "слоти". У кожному слоті обирається один валідатор, який пропонує блок. Якщо припустити, що всі валідатори онлайн і повністю функціонують, то в кожному слоті буде блок, а це означає, що час блоку становить 12 секунд. Однак іноді валідатори можуть бути офлайн, коли їх викликають, щоб запропонувати блок, а це означає, що слоти можуть бути порожніми.
Ця реалізація відрізняється від систем, заснованих на коректурах, де час блокування є імовірним і налаштовується в залежності від цільової складності майнінгу протоколу. Середній час блокуopens in a new tab в Ethereum є чудовим прикладом, оскільки перехід від доказу роботи до доказу частки можна чітко визначити на основі стабільності нового 12-секундного часу блоку.
Розмір блоку
Останнім важливим зауваженням є те, що самі блоки мають обмежений розмір. Кожен блок має цільовий розмір 30 мільйонів газу, але розмір блоків збільшуватиметься або зменшуватиметься відповідно до потреб мережі, аж до ліміту блоку в 60 мільйонів газу (2x цільовий розмір блоку). Ліміт газу блоку можна регулювати вгору або вниз на коефіцієнт 1/1024 від ліміту газу попереднього блоку. У результаті валідатори можуть змінювати ліміт газу блоку через консенсус. Загальна кількість газу, витраченого усіма транзакціями в блоці, повинна бути меншою за ліміт блочного газу. Це важливо, оскільки це гарантує, що блоки не можуть мати довільний розмір. Якби блоки могли бути довільно великими, то менш продуктивні повні вузли поступово перестали б йти в ногу з мережею через вимоги до простору та швидкості. Чим більший блок, тим більша обчислювальна потужність потрібна, щоб обробити їх вчасно для наступного слота. Ця сила є централізованою, яку потрібно протиставити за розмірами блоків.
Для подальшого читання
Знайшли ресурс, який допоміг з цією темою? Відредагуйте цю сторінку і додайте його!