Дослідники Ethereum Foundation попереджають про навантаження на зберігання через "state bloat" і пропонують шляхи для зменшення вузьких місць вузлів

Команда Stateless Consensus Фонду Ethereum окреслила низку ідей для обмеження “state bloat”, попереджаючи, що постійно зростаючий обсяг записів облікових записів, сховищ контрактів та байткоду в мережі стає дедалі складнішим для операторів вузлів щодо зберігання, обслуговування та синхронізації.

“State” Ethereum охоплює все, що наразі відомо мережі, включаючи баланси облікових записів, сховище контрактів та код, який забезпечує роботу додатків. Фонд зазначив, що система стала критично важливою частиною глобальної інфраструктури, яка “врегульовує мільярди доларів вартості” та координує тисячі додатків.

Однак дослідники EF зазначають, що її важливість тепер створила серйозну проблему: state лише зростає; він ніколи не зменшується.

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

Покращення масштабування, такі як розширення Layer 2, EIP-4844 (proto-danksharding) та збільшення ліміту gas, дозволили підвищити активність, але також прискорили зростання state.

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

Стейтлес-верифікація піднімає нове питання: хто зберігає дані?

Довгострокова дорожня карта Ethereum включає statelessness, що зосереджена на можливості для валідаторів перевіряти блоки без необхідності зберігати повний state.

Хоча це зменшує навантаження на валідаторів і відкриває шлях до більшої пропускної здатності, це також перекладає відповідальність за зберігання історичного state на меншу, більш спеціалізовану групу. Дослідники пишуть, що у stateless-дизайні “більшість state, ймовірно, зберігатиметься лише: block builders, RPC providers [та] іншими спеціалізованими операторами, такими як MEV searchers і block explorers.”

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

Три запропоновані шляхи

Команда Stateless Consensus запропонувала три потенційні підходи для полегшення зберігання та обслуговування state.

Перший, State Expiry, видаляє неактивні дані з активного набору, дозволяючи користувачам відновлювати їх за допомогою доказів. Команда зазначає, що приблизно “80% state не використовувалося понад 1 рік”, але всі вузли досі повинні його зберігати. Розглядаються два варіанти: “mark, expire, revive”, який позначає та видаляє рідко використовувані записи, і “multi-era expiry”, який групує дані в епохи та заморожує старіші.

Другий шлях, State Archive, відокремлює гарячий state від холодного. Гарячі дані залишаються обмеженими та швидкими для доступу, тоді як холодні зберігаються для історії та перевірки. Це дозволить продуктивності вузлів “залишатися приблизно стабільною з часом, замість того, щоб погіршуватися зі старінням ланцюга”, навіть якщо загальний state зростає.

Останній варіант, Partial Statelessness, дозволяє вузлам зберігати лише підмножини state, тоді як гаманці та легкі клієнти кешують дані, на які вони покладаються. Це може розширити участь, зменшуючи витрати на зберігання та знижуючи залежність від основних RPC providers.

У всіх трьох підходах мета — “зменшити state як вузьке місце продуктивності, знизити вартість його зберігання та полегшити його обслуговування.”

Що далі?

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

Згідно з публікацією, це включає розробку архівів, покращення інфраструктури RPC та спрощення запуску частково stateless вузлів. Команда також підкреслила, що ці ініціативи були обрані тому, що “вони є негайно корисними та сумісними з майбутніми оновленнями.”

У подальшому фонд запросив розробників, операторів вузлів та інфраструктурні команди до участі.

“Поки ми ітеруємо, ми будемо ділитися нашим прогресом і відкритими питаннями. Але ми не можемо вирішити це в ізоляції,” — пишуть дослідники. “Якщо ви розробник клієнтів, запускаєте вузол, керуєте інфраструктурою, будуєте на Layer 2 або просто дбаєте про довгострокове здоров’я Ethereum, ми запрошуємо вас долучитися: діліться відгуками щодо наших пропозицій, приєднуйтеся до обговорень на форумах і дзвінках, допомагайте тестувати нові підходи на практиці.”

Оновлення з’явилося на тлі того, як Ethereum Foundation активізував комунікацію щодо довгострокового розвитку протоколу.