Перейти до основного контенту
Change page

Блоки

Останні оновлення сторінки: 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 від ліміту газу попереднього блоку. У результаті валідатори можуть змінювати ліміт газу блоку через консенсус. Загальна кількість газу, витраченого усіма транзакціями в блоці, повинна бути меншою за ліміт блочного газу. Це важливо, оскільки це гарантує, що блоки не можуть мати довільний розмір. Якби блоки могли бути довільно великими, то менш продуктивні повні вузли поступово перестали б йти в ногу з мережею через вимоги до простору та швидкості. Чим більший блок, тим більша обчислювальна потужність потрібна, щоб обробити їх вчасно для наступного слота. Ця сила є централізованою, яку потрібно протиставити за розмірами блоків.

Для подальшого читання

Знайшли ресурс, який допоміг з цією темою? Відредагуйте цю сторінку і додайте його!

Чи була ця стаття корисною?