Мережа Portal
Останні оновлення сторінки: 23 лютого 2026 р.
Ethereum — це мережа, що складається з комп’ютерів, на яких запущено клієнтське програмне забезпечення Ethereum. Кожен із цих комп'ютерів називається «вузлом». Клієнтське програмне забезпечення дозволяє вузлу надсилати та отримувати дані в мережі Ethereum, а також перевіряє дані на відповідність правилам протоколу Ethereum. Вузли зберігають велику кількість історичних даних у своєму дисковому сховищі та доповнюють їх, коли отримують нові пакети інформації, відомі як блоки, від інших вузлів мережі. Це необхідно для постійної перевірки того, що вузол має інформацію, яка узгоджується з рештою мережі. Це означає, що для запуску вузла може знадобитися багато дискового простору. Деякі операції вузла також можуть вимагати багато оперативної пам'яті.
Щоб обійти цю проблему з дисковим сховищем, було розроблено «легкі» вузли, які запитують інформацію у повних вузлів, а не зберігають її самостійно. Однак це означає, що легкий вузол не перевіряє інформацію самостійно, а натомість довіряє іншому вузлу. Це також означає, що повні вузли повинні виконувати додаткову роботу для обслуговування цих легких вузлів.
Мережа Portal — це новий мережевий дизайн для Ethereum, який має на меті вирішити проблему доступності даних для "легких" вузлів без необхідності довіряти або створювати додаткове навантаження на повні вузли шляхом розподілу необхідних даних невеликими частинами по всій мережі.
Докладніше про вузли та клієнти
Навіщо нам потрібна мережа Portal
Вузли Ethereum зберігають власну повну або часткову копію блокчейну Ethereum. Ця локальна копія використовується для перевірки транзакцій та забезпечення того, що вузол дотримується правильного ланцюжка. Ці локально збережені дані дозволяють вузлам незалежно перевіряти, що вхідні дані є дійсними та правильними, без необхідності довіряти будь-якій іншій сутності.
Ця локальна копія блокчейну та пов'язані з нею дані про стан і квитанції займають багато місця на жорсткому диску вузла. Наприклад, для запуску вузла з використанням Geth (opens in a new tab) у парі з клієнтом консенсусу рекомендується жорсткий диск об'ємом 2 ТБ. Використовуючи швидку синхронізацію (snap sync), яка зберігає лише дані ланцюга з відносно недавнього набору блоків, Geth зазвичай займає близько 650 ГБ дискового простору, але зростає приблизно на 14 ГБ/тиждень (ви можете періодично очищати вузол, щоб повернути його до 650 ГБ).
Це означає, що запуск вузлів може бути дорогим, оскільки велика кількість дискового простору має бути виділена для Ethereum. У плані розвитку Ethereum є кілька рішень цієї проблеми, зокрема завершення терміну дії історії, завершення терміну дії стану та відсутність стану. Однак до їх впровадження, ймовірно, ще кілька років. Існують також легкі вузли, які не зберігають власну копію даних ланцюга, а запитують потрібні дані у повних вузлів. Однак це означає, що легкі вузли повинні довіряти повним вузлам у наданні чесних даних, а також це створює навантаження на повні вузли, які повинні обслуговувати дані, необхідні легким вузлам.
Мережа Portal має на меті надати альтернативний спосіб для легких вузлів отримувати свої дані, який не вимагає довіри або значного збільшення роботи, яку повинні виконувати повні вузли. Це буде зроблено шляхом впровадження нового способу обміну даними між вузлами Ethereum у мережі.
Як працює мережа Portal?
Вузли Ethereum мають суворі протоколи, які визначають, як вони взаємодіють один з одним. Клієнти виконання взаємодіють за допомогою набору підпротоколів, відомих як DevP2P, тоді як клієнти консенсусу використовують інший стек підпротоколів під назвою libP2P. Вони визначають типи даних, які можуть передаватися між вузлами.
Вузли також можуть надавати певні дані через JSON-RPC API, за допомогою якого програми та гаманці обмінюються інформацією з вузлами Ethereum. Однак жоден із цих протоколів не є ідеальним для надання даних легким клієнтам.
Наразі легкі клієнти не можуть запитувати певні фрагменти даних ланцюга через DevP2P або libP2P, оскільки ці протоколи призначені лише для синхронізації ланцюга та розповсюдження блоків і транзакцій. Легкі клієнти не хочуть завантажувати цю інформацію, оскільки це завадить їм бути "легкими".
JSON-RPC API також не є ідеальним вибором для запитів даних легких клієнтів, оскільки він покладається на з'єднання з певним повним вузлом або централізованим постачальником RPC, який може надавати дані. Це означає, що легкий клієнт повинен довіряти цьому конкретному вузлу/постачальнику щодо чесності, а також повний вузол може обробляти безліч запитів від багатьох легких клієнтів, що збільшує вимоги до пропускної здатності.
Суть мережі Portal полягає в тому, щоб переосмислити весь дизайн, створюючи його спеціально для полегшення, поза рамками обмежень дизайну існуючих клієнтів Ethereum.
Основна ідея мережі Portal полягає в тому, щоб взяти найкраще з поточного мережевого стека, дозволивши надавати інформацію, необхідну легким клієнтам, таку як історичні дані та ідентичність поточної голови ланцюга, через легку децентралізовану мережу в стилі peer-to-peer DevP2P, використовуючи DHT (opens in a new tab) (подібно до Bittorrent).
Ідея полягає в тому, щоб додати до кожного вузла невеликі частини загальних історичних даних Ethereum та деякі специфічні обов’язки вузла. Потім запити обслуговуються шляхом пошуку вузлів, які зберігають конкретні запитані дані, та отримання їх.
Це перевертає звичайну модель, коли легкі вузли знаходять один вузол і просять його відфільтрувати та надати великі обсяги даних; натомість вони швидко фільтрують велику мережу вузлів, кожен з яких обробляє невеликі обсяги даних.
Мета полягає в тому, щоб дозволити децентралізованій мережі легких клієнтів Portal:
- відстежувати голову ланцюга
- синхронізувати останні та історичні дані ланцюга
- отримувати дані про стан
- транслювати транзакції
- виконувати транзакції за допомогою EVM
Переваги такого дизайну мережі:
- зменшити залежність від централізованих постачальників
- Зменшити використання пропускної здатності Інтернету
- Мінімізована або нульова синхронізація
- Доступно для пристроїв з обмеженими ресурсами (<1 ГБ оперативної пам’яті, <100 МБ дискового простору, 1 процесор)
У таблиці нижче наведено функції існуючих клієнтів, які може надавати мережа Portal, що дозволяє користувачам отримувати доступ до цих функцій на пристроях з дуже обмеженими ресурсами.
Мережі Portal
| Легкий клієнт Beacon | Мережа стану | Розповсюдження транзакцій | Мережа історії |
|---|---|---|---|
| Легкий Beacon Chain | Зберігання облікових записів та контрактів | Полегшений мемпул | Заголовки |
| Дані протоколу | Тіла блоків | ||
| Квитанції |
Різноманітність клієнтів за замовчуванням
Розробники мережі Portal також прийняли дизайнерське рішення створити чотири окремі клієнти мережі Portal з першого дня.
Клієнтами мережі Portal є:
- Trin (opens in a new tab): написано на Rust
- Fluffy (opens in a new tab): написано на Nim
- Ultralight (opens in a new tab): написано на Typescript
- Shisui (opens in a new tab): написано на Go
Наявність кількох незалежних реалізацій клієнтів підвищує стійкість та децентралізацію мережі Ethereum.
Якщо один клієнт стикається з проблемами або вразливостями, інші клієнти можуть продовжувати працювати без збоїв, запобігаючи єдиній точці відмови. Крім того, різноманітні реалізації клієнтів сприяють інноваціям та конкуренції, стимулюючи вдосконалення та зменшуючи ризик монокультури в екосистемі.