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

Page last updated: 23 лютого 2026 р.

Відсутність стану, закінчення терміну дії стану й історії

Можливість запускати вузли Ethereum на обладнанні з незначною потужністю має вирішальне значення для справжньої децентралізації. Це пов’язано з тим, що запуск вузла дає користувачам можливість перевіряти інформацію, виконуючи криптографічні перевірки самостійно, замість того, щоб довіряти третій стороні, яка передає їм дані. Запуск вузла дозволяє користувачам надсилати транзакції безпосередньо в однорангову мережу Ethereum, а не довіряти посереднику. Децентралізація неможлива, якщо ці переваги доступні лише користувачам з дорогим обладнанням. Натомість вимоги до обчислювальної потужності та пам’яті вузлів мають бути надзвичайно скромними, щоб вони могли працювати на мобільних телефонах, мікрокомп’ютерах або непомітно на домашньому комп’ютері.

Сьогодні високі вимоги до дискового простору є основним бар’єром, що перешкоджає універсальному доступу до вузлів. Насамперед це пов’язано з необхідністю зберігати великі обсяги даних про стан Ethereum. Ці дані про стан містять важливу інформацію, необхідну для правильної обробки нових блоків і транзакцій. На момент написання статті, щоб запустити повноцінний вузол Ethereum, рекомендується використовувати швидкий SSD-накопичувач на 2 ТБ. Для вузла, який не видаляє старіші дані, потреба в пам’яті зростає приблизно на 14 ГБ/тиждень, а для архівних вузлів, які зберігають всі дані з моменту створення, вона наближається до 12 ТБ (на момент написання статті, у лютому 2023 року).

Щоб зберігати старі дані, можна використовувати дешевші жорсткі диски, але вони занадто повільні, щоб встигати за вхідними блоками. Збереження поточних моделей зберігання для клієнтів при одночасному здешевленні та спрощенні зберігання даних є лише тимчасовим і частковим розв’язанням проблеми, оскільки зростання статусу Ethereum є необмеженим, а це означає, що вимоги до зберігання даних можуть тільки зростати та технологічні вдосконалення завжди матимуть відповідати постійному збільшенню обсягу даних про стан. Натомість клієнти повинні знайти нові способи перевірки блоків і транзакцій, які не покладаються на пошук даних у локальних базах.

Зменшення сховища для вузлів

Є кілька способів зменшити обсяг даних, які повинен зберігати кожен вузол, кожен з яких потребує різного рівня оновлення основного протоколу Ethereum:

  • Закінчення терміну дії історії: дозволяє вузлам видаляти дані про стан, старші за X блоків, але не змінює спосіб обробки даних про стан клієнтами Ethereum.
  • Закінчення терміну дії стану: дозволяє даним про стан, які давно не використовуються, стати неактивними. Неактивні дані можуть ігноруватися клієнтами, доки їх не буде відновлено.
  • Слабка відсутність стану: лише виробники блоків потребують доступу до повних даних про стан, інші вузли можуть перевіряти блоки без локальної бази даних стану.
  • Сильна відсутність стану: жоден вузол не потребує доступу до повних даних про стан.

Закінчення терміну дії даних

Закінчення терміну дії історії

Закінчення терміну дії історії означає, що клієнти видаляють старі дані, які їм навряд чи знадобляться, тому вони зберігають лише невелику кількість історичних даних, видаляючи старі дані, коли надходять нові. Існує дві причини, чому клієнтам потрібні історичні дані: синхронізація та обслуговування запитів на дані. Спочатку клієнти повинні були синхронізуватися з блоку генезису, перевіряючи правильність кожного наступного блоку аж до голови ланцюжка. Сьогодні клієнти використовують "слабкі контрольні точки суб’єктивності", щоб дістатися до голови ланцюжка. Ці контрольні точки є надійними початковими точками, як, наприклад, блок генезису, який близький до теперішнього часу, а не до самого початку Ethereum. Завдяки цьому клієнти можуть скидати всю інформацію до останньої контрольної точки слабкої суб’єктивності, не втрачаючи можливості синхронізуватися з головою ланцюжка. Наразі клієнти обслуговують запити (що надходять через JSON-RPC) на історичні дані, отримуючи їх зі своїх локальних баз. Однак після закінчення терміну дії історії це буде неможливо, якщо запитувані дані було видалено. Обслуговування цих історичних даних потребує певних інноваційних рішень.

Один із варіантів полягає в тому, що клієнти запитують історичні дані у суб’єктів, використовуючи таке рішення, як Portal Network. Portal Network — це однорангова мережа, яка перебуває на стадії розробки, для обслуговування історичних даних, у якій кожен вузол зберігає невеликий фрагмент історії Ethereum, у такий спосіб, вся історія існує в розподіленому вигляді в усій мережі. Запити виконуються через пошук суб’єктів, які зберігають відповідні дані та запитують їх у них. Крім того, оскільки додатки зазвичай вимагають доступу до історичних даних, вони можуть узяти на себе відповідальність за їх зберігання. У просторі Ethereum також може бути достатньо суб’єктів-альтруїстів, які захочуть підтримувати історичні архіви. Це може бути DAO, яке створене для управління сховищем історичних даних, або в ідеалі це буде комбінація всіх цих варіантів. Ці провайдери можуть надавати дані різними способами, наприклад, через торент, FTP, Filecoin або IPFS.

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

Стандарт EIP-4444 ще не готовий до запуску, але його активно обговорюють. Цікаво, що проблеми з EIP-4444 не стільки технічні, скільки здебільшого пов’язані з керуванням спільнотою. Щоб запустити його, необхідна підтримка спільноти, яка включає не лише згоду, але й зобов’язання зберігати та надавати історичні дані від надійних суб’єктів, що заслуговують на довіру.

Це оновлення суттєво не змінює те, як вузли Ethereum обробляють дані про стан, воно лише змінює спосіб доступу до історичних даних.

Закінчення терміну дії стану

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

  • Закінчення терміну за орендною платою: нарахування «орендної плати» на облікові записи та закінчення терміну їхньої дії, коли їхня орендна плата досягає нуля
  • Закінчення за часом: робить облікові записи неактивними, якщо протягом певного часу не відбувається читання або запис до цього облікового запису

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

Імовірно, щоб це працювало, потрібно мати дерево станів для певних проміжків часу (можливо, ~1 рік). Щоразу, коли починається новий період, з’являється повністю нове дерево стану. Лише поточне дерево станів можна змінювати, усі інші залишаються незмінними. Очікується, що вузли Ethereum зберігатимуть лише поточне дерево станів і наступне найновіше. Для цього потрібен спосіб позначити адресу, указавши період, у якому вона існує. Існує кілька можливих способівopens in a new tab це зробити, але провідний варіант вимагає збільшення довжини адресopens in a new tab для розміщення додаткової інформації, з додатковою перевагою, що довші адреси є набагато безпечнішими. Пункт плану розвитку, який це реалізує, називається розширенням адресного просторуopens in a new tab.

Як і у випадку із закінченням терміну дії історії, коли закінчується термін дії стану, відповідальність за зберігання старих даних стану знімається з окремих користувачів і перекладається на інших суб’єктів, як-от централізованих провайдерів, членів-альтруїстів спільноти або більш футуристичні децентралізовані рішення, як-от Portal Network.

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

Відсутність стану

Відсутність фіксації стану — це трохи неправильна назва, оскільки вона не означає видалення поняття стану, а передбачає зміни в обробці даних про стан у вузлах Ethereum. Саме відсутність фіксації стану буває двох видів: слабка та сильна. Слабка відсутність фіксації стану дозволяє більшості вузлів не фіксувати стан, покладаючи відповідальність за зберігання стану на кількох. Сильна відсутність фіксації стану усуває необхідність для будь-якого вузла зберігати повні дані про стан. Як слабка, так і сильна відсутність фіксації стану має такі переваги для звичайних валідаторів:

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

Слабка відсутність стану

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

У цій моделі пропонування блоків вимагає доступу до повних даних про стан, але перевірка блоків не вимагає жодних даних про стан

Щоб це сталося, дерева Веркла вже мають бути впроваджені в клієнтах Ethereum. Дерева Веркла є заміною структури даних для зберігання даних про стан Ethereum, які дозволяють передавати між одноранговими вузлами невеликі фіксованого розміру "свідки" даних і використовувати їх для перевірки блоків замість перевірки блоків на локальних базах даних. Розділення пропонувальника та конструктора також необхідне, оскільки це дозволяє конструкторам блоків бути спеціалізованими вузлами з потужнішим апаратним забезпеченням, і саме ці вузли потребують доступу до повних даних стану.

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

Слабка відсутність фіксації стану перебуває на глибокій стадії дослідження, але вона покладається на розділення вузлів створення і пропонування і впровадження дерев Веркла, щоб невеликі свідки могли передаватись між одноранговими вузлами. Це означає, що слабку відсутність фіксації стану, імовірно, буде впроваджено в основній мережі Ethereum через кілька років.

Сильна відсутність стану

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

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

Поточний прогрес

Слабка відсутність фіксації стану, термін дії історії та термін дії стану — усі вони перебувають на стадії дослідження, їх запуск очікується через кілька років. Немає гарантії, що всі ці пропозиції буде реалізовано, наприклад, якщо спочатку буде реалізовано закінчення терміну дії стану, може не знадобитися реалізувати закінчення терміну дії історії. Також існують інші пункти плану розвитку, як-от дерева Веркла та розділення пропонувальника та конструктора, які необхідно завершити в першу чергу.

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

Останні оновлення сторінки: 23 лютого 2026 р.

mnelsonBTmopens in a new tab
pete-vielhaberpopens in a new tab
corwintinescopens in a new tab
+10

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