Здатність запускати вузли Етеріуму на скромному обладнанні є критично важливою для справжньої децентралізації. Це пов'язано з тим, що запуск вузла дає користувачам можливість перевіряти інформацію, виконуючи криптографічні перевірки незалежно, замість того, щоб довіряти третій стороні, яка надає їм дані. Запуск вузла дозволяє користувачам надсилати транзакції безпосередньо в однорангову мережу Етеріуму, замість того, щоб довіряти посереднику. Децентралізація неможлива, якщо ці переваги доступні лише користувачам із дорогим обладнанням. Натомість вузли повинні мати можливість працювати з надзвичайно скромними вимогами до обробки та пам'яті, щоб їх можна було запускати на мобільних телефонах, мікрокомп'ютерах або непомітно на домашньому комп'ютері.
Сьогодні високі вимоги до дискового простору є головною перешкодою, що заважає загальному доступу до вузлів. Це насамперед пов'язано з необхідністю зберігати великі обсяги даних стану Етеріуму. Ці дані стану містять критично важливу інформацію, необхідну для правильної обробки нових блоків і транзакцій. На момент написання статті для запуску повного вузла Етеріуму рекомендується швидкий SSD на 2 ТБ. Для вузла, який не видаляє старі дані, вимоги до сховища зростають приблизно на 14 ГБ на тиждень, а архівні вузли, які зберігають усі дані з генезис-блоку, наближаються до 12 ТБ (на момент написання статті, у лютому 2023 року).
Дешевші жорсткі диски можна використовувати для зберігання старих даних, але вони занадто повільні, щоб встигати за новими блоками. Збереження поточних моделей зберігання для клієнтів із одночасним здешевленням і спрощенням зберігання даних є лише тимчасовим і частковим вирішенням проблеми, оскільки зростання стану Етеріуму є «необмеженим», що означає, що вимоги до сховища можуть лише зростати, а технологічні вдосконалення завжди повинні будуть йти в ногу з постійним зростанням стану. Натомість клієнти повинні знайти нові способи перевірки блоків і транзакцій, які не покладаються на пошук даних у локальних базах даних.
Зменшення обсягу сховища для вузлів
Існує кілька способів зменшити обсяг даних, які повинен зберігати кожен вузол, і кожен з них вимагає оновлення базового протоколу Етеріуму різною мірою:
- Експірація історії: дозволяє вузлам відкидати дані стану, старіші за X блоків, але не змінює те, як клієнти Етеріуму обробляють дані стану.
- Експірація стану: дозволяє даним стану, які не використовуються часто, ставати неактивними. Неактивні дані можуть ігноруватися клієнтами, доки вони не будуть відновлені.
- Слабка безстановість: лише виробники блоків потребують доступу до повних даних стану, інші вузли можуть перевіряти блоки без локальної бази даних стану.
- Сильна безстановість: жоден вузол не потребує доступу до повних даних стану.
Експірація даних
Експірація історії
Експірація історії означає, що клієнти видаляють старі дані, які їм навряд чи знадобляться, тому вони зберігають лише невелику кількість історичних даних, відкидаючи старі дані під час надходження нових. Є дві причини, чому клієнтам потрібні історичні дані: синхронізація та обслуговування запитів на дані. Спочатку клієнтам доводилося синхронізуватися з генезис-блоку, перевіряючи правильність кожного наступного блоку аж до вершини ланцюга. Сьогодні клієнти використовують «контрольні точки слабкої суб'єктивності», щоб прискорити свій шлях до вершини ланцюга. Ці контрольні точки є довіреними початковими точками, ніби генезис-блок знаходиться ближче до сьогодення, а не на самому початку існування Етеріуму. Це означає, що клієнти можуть відкинути всю інформацію до останньої контрольної точки слабкої суб'єктивності, не втрачаючи можливості синхронізації з вершиною ланцюга. Наразі клієнти обслуговують запити (що надходять через JSON-RPC) на історичні дані, беручи їх зі своїх локальних баз даних. Однак з експірацією історії це буде неможливо, якщо запитані дані були видалені. Саме для обслуговування цих історичних даних потрібні деякі інноваційні рішення.
Один із варіантів полягає в тому, що клієнти запитують історичні дані в однорангових вузлів, використовуючи таке рішення, як Портал Нетворк. Портал Нетворк — це однорангова мережа для обслуговування історичних даних, що знаходиться на стадії розробки, де кожен вузол зберігає невелику частину історії Етеріуму, так що вся історія існує розподіленою по мережі. Запити обслуговуються шляхом пошуку однорангових вузлів, які зберігають відповідні дані, і запиту їх у них. З іншого боку, оскільки доступ до історичних даних зазвичай потрібен застосункам, їх зберігання може стати їхньою відповідальністю. У просторі Етеріуму також може бути достатньо альтруїстичних учасників, які були б готові підтримувати історичні архіви. Це може бути DAO, створена для управління зберіганням історичних даних, або, в ідеалі, це буде комбінація всіх цих варіантів. Ці провайдери могли б надавати дані багатьма способами, наприклад, через торрент, FTP, Filecoin або IPFS.
Експірація історії є дещо суперечливою, оскільки досі Етеріум завжди неявно гарантував доступність будь-яких історичних даних. Повна синхронізація з генезис-блоку завжди була можливою за замовчуванням, навіть якщо вона покладається на відновлення деяких старих даних зі знімків. Експірація історії переносить відповідальність за надання цієї гарантії за межі базового протоколу Етеріуму. Це може створити нові ризики цензури, якщо централізовані організації в кінцевому підсумку візьмуть на себе надання історичних даних.
EIP-4444 ще не готовий до випуску, але він активно обговорюється. Цікаво, що проблеми з EIP-4444 не стільки технічні, скільки здебільшого пов'язані з управлінням спільнотою. Для того, щоб це було випущено, потрібна підтримка спільноти, яка включає не лише згоду, але й зобов'язання зберігати та обслуговувати історичні дані від надійних організацій.
Це оновлення докорінно не змінює те, як вузли Етеріуму обробляють дані стану, воно лише змінює спосіб доступу до історичних даних.
Експірація стану
Експірація стану означає видалення стану з окремих вузлів, якщо до нього не було доступу останнім часом. Існує кілька способів реалізації цього, зокрема:
- Експірація за орендою: стягнення «орендної плати» з акаунтів та їх експірація, коли їхня орендна плата досягає нуля
- Експірація за часом: переведення акаунтів у неактивний стан, якщо протягом певного часу не відбувається читання/запису в цей акаунт
Експірація за орендою може бути прямою орендною платою, що стягується з акаунтів для збереження їх у базі даних активного стану. Експірація за часом може здійснюватися шляхом зворотного відліку від останньої взаємодії з акаунтом, або це може бути періодична експірація всіх акаунтів. Також можуть існувати механізми, які поєднують елементи моделей на основі часу та оренди, наприклад, окремі акаунти залишаються в активному стані, якщо вони сплачують невелику комісію до закінчення терміну дії за часом. У випадку з експірацією стану важливо зазначити, що неактивний стан не видаляється, він просто зберігається окремо від активного стану. Неактивний стан може бути відновлений в активний стан.
Ймовірно, це працюватиме так: буде дерево стану для певних періодів часу (можливо, ~1 рік). Щоразу, коли починається новий період, створюється абсолютно нове дерево стану. Лише поточне дерево стану може бути змінено, всі інші є незмінними. Очікується, що вузли Етеріуму зберігатимуть лише поточне дерево стану та попереднє. Це вимагає способу позначення адреси міткою часу з періодом, у якому вона існує. Існує кілька можливих способів (opens in a new tab) зробити це, але провідний варіант вимагає подовження адрес (opens in a new tab) для розміщення додаткової інформації з додатковою перевагою, що довші адреси є набагато безпечнішими. Пункт дорожньої карти, який це робить, називається розширенням адресного простору (opens in a new tab).
Подібно до експірації історії, за умови експірації стану відповідальність за зберігання старих даних стану знімається з окремих користувачів і перекладається на інші організації, такі як централізовані провайдери, альтруїстичні члени спільноти або більш футуристичні децентралізовані рішення, такі як Портал Нетворк.
Експірація стану все ще перебуває на стадії дослідження і ще не готова до випуску. Експірація стану цілком може відбутися пізніше, ніж впровадження безстанових клієнтів та експірації історії, оскільки ці оновлення роблять великі розміри стану легко керованими для більшості валідаторів.
Безстановість
Безстановість — це дещо неправильна назва, оскільки вона не означає усунення концепції «стану», але передбачає зміни в тому, як вузли Етеріуму обробляють дані стану. Сама безстановість буває двох видів: слабка безстановість і сильна безстановість. Слабка безстановість дозволяє більшості вузлів стати безстановими, покладаючи відповідальність за зберігання стану на декількох. Сильна безстановість повністю усуває необхідність для будь-якого вузла зберігати повні дані стану. Як слабка, так і сильна безстановість пропонують звичайним валідаторам такі переваги:
- майже миттєва синхронізація
- можливість перевіряти блоки не по порядку
- вузли можуть працювати з дуже низькими вимогами до обладнання (наприклад, на телефонах)
- вузли можуть працювати на дешевих жорстких дисках, оскільки не потрібне читання/запис на диск
- сумісність із майбутніми оновленнями криптографії Етеріуму
Слабка безстановість
Слабка безстановість передбачає зміни в тому, як вузли Етеріуму перевіряють зміни стану, але вона не повністю усуває потребу в зберіганні стану на всіх вузлах мережі. Натомість слабка безстановість покладає відповідальність за зберігання стану на пропоузерів блоків, тоді як усі інші вузли в мережі перевіряють блоки без зберігання повних даних стану.
При слабкій безстановості пропонування блоків вимагає доступу до повних даних стану, але перевірка блоків не вимагає жодних даних стану
Для того, щоб це сталося, дерева Веркла вже повинні бути реалізовані в клієнтах Етеріуму. Дерева Веркла — це структура даних для заміни зберігання даних стану Етеріуму, яка дозволяє передавати невеликі «свідки» фіксованого розміру для даних між одноранговими вузлами та використовувати їх для перевірки блоків замість перевірки блоків за локальними базами даних. Розділення пропоузера та білдера (PBS) також є необхідним, оскільки це дозволяє білдерам блоків бути спеціалізованими вузлами з потужнішим обладнанням, і саме вони потребують доступу до повних даних стану.
Безстановість покладається на те, що білдери блоків підтримують копію повних даних стану, щоб вони могли генерувати свідків, які можна використовувати для перевірки блоку. Іншим вузлам не потрібен доступ до даних стану, вся інформація, необхідна для перевірки блоку, доступна у свідку. Це створює ситуацію, коли пропонування блоку є дорогим, але перевірка блоку є дешевою, що означає, що менше операторів запускатимуть вузол, який пропонує блоки. Однак децентралізація пропоузерів блоків не є критичною, якщо якомога більше учасників можуть незалежно перевірити, що запропоновані ними блоки є дійсними.
Докладніше в нотатках Данкрада (opens in a new tab)Пропоузери блоків використовують дані стану для створення «свідків» — мінімального набору даних, які доводять значення стану, що змінюються транзакціями в блоці. Інші валідатори не зберігають стан, вони зберігають лише корінь стану (хеш усього стану). Вони отримують блок і свідка та використовують їх для оновлення свого кореня стану. Це робить вузол валідації надзвичайно легким.
Слабка безстановість перебуває на просунутій стадії дослідження, але вона покладається на те, що розділення пропоузера та білдера (PBS) і дерева Веркла вже реалізовані, щоб невеликі свідки могли передаватися між одноранговими вузлами. Це означає, що до впровадження слабкої безстановості в головній мережі Ethereum, ймовірно, залишилося кілька років.
zkEVM для перевірки рівня 1 (l1) — це додаткова технологія, яка може ще більше покращити безстанову перевірку. Замість того, щоб просто перевіряти свідків, валідатори могли б перевіряти доведення з нульовим розголошенням того, що весь блок був виконаний правильно, забезпечуючи криптографічну впевненість без повторного виконання транзакцій.
Сильна безстановість
Сильна безстановість усуває необхідність для будь-якого вузла зберігати дані стану. Натомість транзакції надсилаються зі свідками, які можуть бути агреговані виробниками блоків. Тоді виробники блоків несуть відповідальність за зберігання лише того стану, який необхідний для генерації свідків для відповідних акаунтів. Відповідальність за стан майже повністю перекладається на користувачів, оскільки вони надсилають свідків і «списки доступу», щоб оголосити, з якими акаунтами та ключами сховища вони взаємодіють. Це дозволило б створити надзвичайно легкі вузли, але існують компроміси, зокрема ускладнення транзакцій зі смарт-контрактами.
Сильна безстановість досліджувалася дослідниками, але наразі не очікується, що вона стане частиною дорожньої карти Етеріуму — більш імовірно, що слабкої безстановості буде достатньо для потреб масштабування Етеріуму.
Поточний прогрес
Слабка безстановість, експірація історії та експірація стану перебувають на стадії дослідження і, як очікується, будуть випущені через кілька років. Немає жодної гарантії, що всі ці пропозиції будуть реалізовані, наприклад, якщо спочатку буде реалізована експірація стану, можливо, не буде потреби також реалізовувати експірацію історії. Існують також інші пункти дорожньої карти, такі як дерева Веркла та розділення пропоузера та білдера (PBS), які потрібно завершити в першу чергу.
Додаткова література
- Що таке безстановий Етеріум? (opens in a new tab)
- AMA з Віталіком про безстановість (opens in a new tab)
- Теорія управління розміром стану (opens in a new tab)
- Обмеження стану з мінімізацією конфліктів відновлення (opens in a new tab)
- Шляхи до безстановості та експірації стану (opens in a new tab)
- Специфікація EIP-4444 (opens in a new tab)
- Алекс Стоукс про EIP-4444 (opens in a new tab)
- Чому так важливо перейти до безстановості (opens in a new tab)
- Оригінальні нотатки щодо концепції безстанового клієнта (opens in a new tab)
- Більше про експірацію стану (opens in a new tab)
- Ще більше про експірацію стану (opens in a new tab)
- Інформаційна сторінка про безстановий Етеріум (opens in a new tab)
Останнє оновлення сторінки: 6 червня 2026 р.
