---
title: "Архітектура вузла"
description: "Вступ до того, як організовані вузли Етеріуму."
lang: uk
---

Вузол Етеріуму складається з двох клієнтів: [клієнта виконання](/developers/docs/nodes-and-clients/#execution-clients) та [клієнта консенсусу](/developers/docs/nodes-and-clients/#consensus-clients). Щоб вузол міг запропонувати новий блок, він також повинен запускати [клієнт валідатора](#validators).

Коли Етеріум використовував [доказ виконання роботи (PoW)](/developers/docs/consensus-mechanisms/pow/), клієнта виконання було достатньо для запуску повного вузла Етеріуму. Однак після впровадження [доказу частки (PoS)](/developers/docs/consensus-mechanisms/pos/), клієнт виконання повинен використовуватися разом з іншим програмним забезпеченням, яке називається [клієнтом консенсусу](/developers/docs/nodes-and-clients/#consensus-clients).

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

![Diagram of Ethereum node architecture showing execution and consensus layers](node-architecture-text-background.png)

_Існує кілька варіантів клієнта виконання, зокрема Ерігон, Незермайнд та Besu_.

Щоб ця двокомпонентна структура працювала, клієнти консенсусу повинні передавати пакети транзакцій клієнту виконання. Клієнт виконання виконує транзакції локально, щоб перевірити, чи не порушують вони жодних правил Етеріуму та чи є запропоноване оновлення стану Етеріуму правильним. Коли вузол обирається виробником блоку, його екземпляр клієнта консенсусу запитує пакети транзакцій у клієнта виконання, щоб включити їх у новий блок і виконати для оновлення глобального стану. Клієнт консенсусу керує клієнтом виконання через локальне RPC-з'єднання за допомогою [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md).

## Що робить клієнт виконання? {#execution-client}

Клієнт виконання відповідає за перевірку, обробку та поширення транзакцій, а також за управління станом і підтримку Віртуальної машини Етеріуму ([EVM](/developers/docs/evm/)). Він **не** відповідає за створення блоків, їх поширення або обробку логіки консенсусу. Це входить до компетенції клієнта консенсусу.

Клієнт виконання створює корисне навантаження виконання — список транзакцій, оновлене дерево стану та інші дані, пов'язані з виконанням. Клієнти консенсусу включають корисне навантаження виконання в кожен блок. Клієнт виконання також відповідає за повторне виконання транзакцій у нових блоках, щоб переконатися в їхній дійсності. Виконання транзакцій здійснюється на вбудованому комп'ютері клієнта виконання, відомому як [Віртуальна машина Етеріуму (EVM)](/developers/docs/evm).

Клієнт виконання також пропонує користувацький інтерфейс до Етеріуму через [методи RPC](/developers/docs/apis/json-rpc), які дозволяють користувачам робити запити до блокчейну Етеріуму, надсилати транзакції та розгортати смарт-контракти. Зазвичай RPC-виклики обробляються бібліотекою, такою як [Web3js](https://docs.web3js.org/), [Web3py](https://web3py.readthedocs.io/en/v5/), або користувацьким інтерфейсом, наприклад, браузерним гаманцем.

Підсумовуючи, клієнт виконання — це:

- користувацький шлюз до Етеріуму;
- середовище для Віртуальної машини Етеріуму, стану Етеріуму та пулу транзакцій.

## Що робить клієнт консенсусу? {#consensus-client}

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

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

## Валідатори {#validators}

Стейкінг і запуск програмного забезпечення валідатора роблять вузол придатним для вибору з метою пропозиції нового блоку. Оператори вузлів можуть додати валідатор до своїх клієнтів консенсусу, внісши 32 ETH у депозитний контракт. Клієнт валідатора постачається в комплекті з клієнтом консенсусу і може бути доданий до вузла в будь-який час. Валідатор обробляє атестації та пропозиції блоків. Він також дозволяє вузлу накопичувати винагороди або втрачати ETH через штрафи чи слешинг.

[Більше про стейкінг](/staking/).

## Порівняння компонентів вузла {#node-comparison}

| Клієнт виконання                                   | Клієнт консенсусу                                                                                                                                          | Валідатор                    |
| -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- |
| Поширює транзакції у своїй P2P-мережі              | Поширює блоки та атестації у своїй P2P-мережі                                                                                                             | Пропонує блоки               |
| Виконує/повторно виконує транзакції                | Запускає алгоритм вибору форка                                                                                                                            | Накопичує винагороди/штрафи  |
| Перевіряє вхідні зміни стану                       | Відстежує вершину ланцюга                                                                                                                                 | Створює атестації            |
| Керує деревами стану та квитанцій                  | Керує станом Beacon (містить інформацію про консенсус і виконання)                                                                                        | Вимагає 32 ETH для стейкінгу |
| Створює корисне навантаження виконання             | Відстежує накопичену випадковість у RANDAO (алгоритм, що забезпечує перевірену випадковість для вибору валідатора та інших операцій консенсусу)           | Може бути підданий слешингу  |
| Надає JSON-RPC API для взаємодії з Етеріумом       | Відстежує обґрунтування та фіналізацію                                                                                                                    |                              |

## Подальше читання {#further-reading}

- [Доказ частки (PoS)](/developers/docs/consensus-mechanisms/pos)
- [Пропозиція блоку](/developers/docs/consensus-mechanisms/pos/block-proposal)
- [Винагороди та штрафи валідатора](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)