Мережевий рівень

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

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

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

Передумови

Для розуміння цієї сторінки будуть корисними деякі знання про вузли та клієнти Ethereum.

Рівень виконання

Мережеві протоколи рівня виконання поділяються на два стеки:

• стек виявлення: побудований на основі UDP і дозволяє новому вузлу знаходити однорангові вузли для підключення

• стек DevP2P: працює поверх TCP і дозволяє вузлам обмінюватися інформацією

Обидва стеки працюють паралельно. Стек виявлення додає нових учасників до мережі, а стек DevP2P забезпечує їхню взаємодію.

Виявлення

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

Протокол, що використовується для взаємодії між вузлами та початковими вузлами, є модифікованою формою Kademlia (opens in a new tab), яка використовує розподілену геш-таблицю (opens in a new tab) для обміну списками вузлів. Кожен вузол має версію цієї таблиці, що містить інформацію, необхідну для підключення до найближчих однорангових вузлів. Ця «близькість» не є географічною — відстань визначається схожістю ідентифікатора вузла. Таблиця кожного вузла регулярно оновлюється в цілях безпеки. Наприклад, у протоколі виявлення Discv5 (opens in a new tab) вузли також можуть надсилати «оголошення», які показують підпротоколи, що підтримуються клієнтом, дозволяючи одноранговим вузлам домовлятися про протоколи, які вони обидва можуть використовувати для зв'язку.

Виявлення починається з гри в PING-PONG. Успішний PING-PONG "зв'язує" новий вузол з початковим вузлом. Початковим повідомленням, яке сповіщає початковий вузол про появу нового вузла в мережі, є PING. Цей PING містить гешовану інформацію про новий вузол, початковий вузол і мітку часу закінчення терміну дії. Початковий вузол отримує PING і повертає PONG, що містить геш PING. Якщо геші PING і PONG збігаються, з'єднання між новим вузлом і початковим вузлом перевіряється, і вважається, що вони "зв'язані".

Після зв'язування новий вузол може надіслати запит FIND-NEIGHBOURS до початкового вузла. Дані, що повертаються початковим вузлом, включають список однорангових вузлів, до яких може підключитися новий вузол. Якщо вузли не зв'язані, запит FIND-NEIGHBOURS не вдасться, тому новий вузол не зможе увійти в мережу.

Як тільки новий вузол отримує список сусідів від початкового вузла, він починає обмін PING-PONG з кожним із них. Успішні PING-PONG зв'язують новий вузол із його сусідами, уможливлюючи обмін повідомленнями.

1запустити клієнт --> підключитися до початкового вузла --> зв'язатися з початковим вузлом --> знайти сусідів --> зв'язатися з сусідами

Наразі клієнти виконання використовують протокол виявлення Discv4 (opens in a new tab), і докладаються активні зусилля для переходу на протокол Discv5 (opens in a new tab).

ENR: Записи вузла Ethereum

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

Чому виявлення побудовано на UDP?

UDP не підтримує перевірку помилок, повторне надсилання невдалих пакетів або динамічне відкриття та закриття з'єднань — натомість він просто надсилає безперервний потік інформації до цілі, незалежно від того, чи буде він успішно отриманий. Ця мінімальна функціональність також означає мінімальні накладні витрати, що робить цей тип з'єднання дуже швидким. Для виявлення, коли вузол просто хоче заявити про свою присутність, щоб потім встановити формальне з'єднання з одноранговим вузлом, UDP є достатнім. Однак для решти мережевого стеку UDP не підходить для цієї мети. Обмін інформацією між вузлами є досить складним і тому вимагає більш повнофункціонального протоколу, який може підтримувати повторне надсилання, перевірку помилок тощо. Додаткові накладні витрати, пов'язані з TCP, варті додаткової функціональності. Тому більшість стеку P2P працює через TCP.

DevP2P

DevP2P — це цілий стек протоколів, які Ethereum реалізує для встановлення та підтримки однорангової мережі. Після того, як нові вузли входять в мережу, їхня взаємодія регулюється протоколами стеку DevP2P (opens in a new tab). Усі вони працюють поверх TCP і включають транспортний протокол RLPx, дротовий протокол і кілька підпротоколів. RLPx (opens in a new tab) — це протокол, що регулює ініціювання, автентифікацію та підтримку сеансів між вузлами. RLPx кодує повідомлення за допомогою RLP (префікс рекурсивної довжини), що є дуже ефективним з точки зору простору методом кодування даних у мінімальну структуру для надсилання між вузлами.

Сеанс RLPx між двома вузлами починається з початкового криптографічного рукостискання. Це передбачає надсилання вузлом повідомлення автентифікації, яке потім перевіряється одноранговим вузлом. Після успішної перевірки одноранговий вузол генерує повідомлення з підтвердженням автентифікації для повернення вузлу-ініціатору. Це процес обміну ключами, який дозволяє вузлам спілкуватися приватно та безпечно. Успішне криптографічне рукостискання змушує обидва вузли надсилати один одному повідомлення "hello" "по дроту". Дротовий протокол ініціюється успішним обміном повідомленнями hello.

Повідомлення hello містять:

• версія протоколу
• ідентифікатор клієнта
• порт
• ідентифікатор вузла
• список підтримуваних підпротоколів

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

Разом із повідомленнями hello дротовий протокол також може надсилати повідомлення "disconnect", яке попереджає одноранговий вузол про те, що з’єднання буде закрито. Дротовий протокол також включає повідомлення PING і PONG, які періодично надсилаються для підтримки сеансу відкритим. Таким чином, обміни за протоколами RLPx і дротовим протоколом закладають основи зв'язку між вузлами, забезпечуючи основу для обміну корисною інформацією відповідно до певного підпротоколу.

Підпротоколи

Дротовий протокол

Після підключення однорангових вузлів і запуску сеансу RLPx дротовий протокол визначає, як однорангові вузли спілкуються. Спочатку дротовий протокол визначав три основні завдання: синхронізація ланцюга, поширення блоків і обмін транзакціями. Однак, як тільки Ethereum перейшов на доказ частки володіння, поширення блоків і синхронізація ланцюга стали частиною рівня консенсусу. Обмін транзакціями все ще входить до компетенції клієнтів виконання. Обмін транзакціями означає обмін незавершеними транзакціями між вузлами, щоб конструктори блоків могли вибрати деякі з них для включення в наступний блок. Детальна інформація про ці завдання доступна тут (opens in a new tab). Клієнти, які підтримують ці підпротоколи, надають до них доступ через JSON-RPC.

les (полегшений підпротокол Ethereum)

Це мінімальний протокол для синхронізації полегшених клієнтів. Традиційно цей протокол використовувався рідко, оскільки повні вузли повинні обслуговувати дані для полегшених клієнтів без стимулювання. Поведінка за замовчуванням для клієнтів виконання — не обслуговувати дані полегшених клієнтів через les. Більше інформації доступно в специфікації (opens in a new tab) les.

Snap

Протокол snap (opens in a new tab) — це необов’язкове розширення, яке дозволяє одноранговим вузлам обмінюватися знімками останніх станів, що дозволяє їм перевіряти дані облікового запису та сховища без необхідності завантажувати проміжні вузли дерева Меркла.

Wit (протокол свідків)

Протокол свідків (opens in a new tab) — це необов’язкове розширення, яке дозволяє обмінюватися свідками стану між одноранговими вузлами, допомагаючи синхронізувати клієнтів з вершиною ланцюга.

Whisper

Whisper був протоколом, який мав на меті забезпечити безпечний обмін повідомленнями між одноранговими вузлами без запису будь-якої інформації в блокчейн. Він був частиною дротового протоколу DevP2P, але зараз застарів. Існують інші пов’язані проєкти (opens in a new tab) зі схожими цілями.

Рівень консенсусу

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

Виявлення

Подібно до клієнтів виконання, клієнти консенсусу використовують discv5 (opens in a new tab) через UDP для пошуку однорангових вузлів. Реалізація discv5 на рівні консенсусу відрізняється від реалізації клієнтів виконання лише тим, що вона включає адаптер, що підключає discv5 до стеку libP2P (opens in a new tab), що робить DevP2P застарілим. Сеанси RLPx рівня виконання є застарілими на користь рукостискання безпечного каналу noise від libP2P.

ENR

ENR для вузлів консенсусу включає публічний ключ вузла, IP-адресу, порти UDP і TCP і два специфічні для консенсусу поля: бітове поле підмережі атестації та ключ eth2. Перше поле полегшує вузлам пошук однорангових вузлів, які беруть участь у конкретних підмережах поширення атестацій. Ключ eth2 містить інформацію про те, яку версію форку Ethereum використовує вузол, гарантуючи, що однорангові вузли підключаються до правильного Ethereum.

libP2P

Стек libP2P підтримує всі комунікації після виявлення. Клієнти можуть набирати та прослуховувати IPv4 та/або IPv6, як визначено в їх ENR. Протоколи на рівні libP2P можна розділити на домени поширення та запит/відповідь.

Поширення

Домен поширення включає всю інформацію, яка повинна швидко поширюватися по мережі. Сюди входять блоки Beacon, докази, атестації, виходи та слешинги. Це передається за допомогою libP2P gossipsub v1 і покладається на різні метадані, що зберігаються локально на кожному вузлі, включаючи максимальний розмір корисних даних поширення для отримання та передачі. Детальна інформація про домен поширення доступна тут (opens in a new tab).

Запит-відповідь

Домен запит-відповідь містить протоколи для клієнтів, які запитують конкретну інформацію у своїх однорангових вузлів. Приклади включають запит конкретних блоків Beacon, що відповідають певним кореневим гешам або в межах діапазону слотів. Відповіді завжди повертаються у вигляді байтів, закодованих за допомогою SSZ і стиснутих за допомогою snappy.

Чому клієнт консенсусу віддає перевагу SSZ над RLP?

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

Підключення клієнтів виконання та консенсусу

Клієнти консенсусу та виконання працюють паралельно. Вони повинні бути з'єднані, щоб клієнт консенсусу міг надавати інструкції клієнту виконання, а клієнт виконання міг передавати пакети транзакцій клієнту консенсусу для включення в блоки Beacon. Зв'язок між двома клієнтами може бути реалізований за допомогою локального RPC-з'єднання. API, відомий як 'Engine-API' (opens in a new tab), визначає інструкції, що надсилаються між двома клієнтами. Оскільки обидва клієнти знаходяться за єдиною мережевою ідентичністю, вони спільно використовують ENR (запис вузла Ethereum), який містить окремий ключ для кожного клієнта (ключ eth1 і ключ eth2).

Нижче наведено зведення потоку керування з відповідним мережевим стеком у дужках.

Коли клієнт консенсусу не є виробником блоків:

• Клієнт консенсусу отримує блок через протокол поширення блоків (консенсус p2p)
• Клієнт консенсусу попередньо перевіряє блок, тобто переконується, що він надійшов від дійсного відправника з правильними метаданими
• Транзакції в блоці надсилаються на рівень виконання як корисне навантаження виконання (локальне з'єднання RPC)
• Рівень виконання виконує транзакції та перевіряє стан у заголовку блоку (тобто перевіряє збіг гешів)
• Рівень виконання передає дані перевірки назад на рівень консенсусу, блок тепер вважається перевіреним (локальне з'єднання RPC)
• Рівень консенсусу додає блок до вершини свого власного блокчейну та атестує його, транслюючи атестацію по мережі (консенсус p2p)

Коли клієнт консенсусу є виробником блоків:

• Клієнт консенсусу отримує повідомлення про те, що він є наступним виробником блоків (консенсус p2p)
• Рівень консенсусу викликає метод create block у клієнті виконання (локальний RPC)
• Рівень виконання отримує доступ до мемпулу транзакцій, який був заповнений протоколом поширення транзакцій (виконання p2p)
• Клієнт виконання об'єднує транзакції в блок, виконує транзакції та генерує геш блоку
• Клієнт консенсусу отримує транзакції та геш блоку від клієнта виконання та додає їх до блоку Beacon (локальний RPC)
• Клієнт консенсусу транслює блок через протокол поширення блоків (консенсус p2p)
• Інші клієнти отримують запропонований блок через протокол поширення блоків і перевіряють його, як описано вище (консенсус p2p)

Після того, як блок буде атестовано достатньою кількістю валідаторів, він додається до вершини ланцюга, обґрунтовується і врешті-решт фіналізується.

Схема мережевого рівня для клієнтів консенсусу та виконання, з ethresear.ch (opens in a new tab)

Додаткові матеріали

DevP2P (opens in a new tab) LibP2p (opens in a new tab) Специфікації мережі рівня консенсусу (opens in a new tab) від kademlia до discv5 (opens in a new tab) стаття про kademlia (opens in a new tab) вступ до p2p Ethereum (opens in a new tab) відносини eth1/eth2 (opens in a new tab) відео з деталями злиття та клієнта eth2 (opens in a new tab)