Stateless-клиент Ethereum — это узел, который не хранит локально полное состояние сети (балансы, storage смарт-контрактов), но всё равно может проверять блоки и транзакции с теми же криптографическими гарантиями, что и полноценный узел. Вместо огромной базы данных такой клиент получает «свидетели состояния» (witnesses) — компактные доказательства того, что нужные куски состояния соответствуют корню состояния в заголовке блока.
Stateless-подход — важная часть долгосрочной дорожной карты архитектуры Ethereum: он должен снизить требования к ресурсам узлов и упростить запуск «полноценных» клиентов на обычных устройствах.
Почему текущая модель узлов не масштабируется
Сейчас большинство полноценных узлов Ethereum:
- хранят полное состояние: миллионы аккаунтов и контрактов, их storage и индексы;
- поддерживают сложную структуру Merkle Patricia Trie;
- обслуживают RPC-запросы кошельков и dApp’ов.
Это приводит к тому, что:
- требования к диску, памяти и I/O постоянно растут;
- меньше людей готовы запускать и обслуживать такой узел;
- пользователи и кошельки всё чаще опираются на централизованные RPC-провайдеры.
Stateless-подход предлагает разорвать зависимость между «полноценностью» клиента и полным локальным состоянием.
Идея stateless-клиента
В статической модели:
- текущий узел хранит состояние и при проверке блока просто читает нужные ключи из локальной БД;
- заголовок блока содержит корень состояния (state root), но клиент сам отвечает за соответствие БД этому корню.
В stateless-модели:
- блок (или пакет транзакций) сопровождается свидетелем состояния (witness):
- минимальный набор ключей/значений и ветвей дерева состояния;
- достаточно, чтобы проверить все чтения и записи, которые выполняет блок;
- stateless-клиент:
- берёт корень состояния из заголовка;
- применяет транзакции к состоянию, описанному в witness;
- проверяет, что результат приводит к новому корректному корню состояния.
Ключевая идея: клиент ничего не хранит «навсегда». Всё, что нужно ему для проверки блока «здесь и сейчас», приходит с блоком (или через специализированную сеть данных).
Роль свидетелей (witnesses) и Verkle-деревьев
Свидетель (witness) — это:
- набор аккаунтов и storage-слотов, которые затрагиваются транзакциями;
- плюс необходимые ветви дерева состояния (Merkle/Verkle), чтобы:
- доказать, что эти ключи входят в состояние;
- пересчитать корень состояния до и после применения транзакций.
Проблема классического Merkle Patricia Trie:
- доказательства включения (Merkle-пути) могут быть довольно крупными;
- для сложных транзакций свидетели получаются тяжёлыми.
Именно поэтому в дорожной карте Ethereum важны:
- переход к Verkle-деревьям;
- использование более эффективных KZG-коммитментов и других схем.
Verkle-деревья:
- позволяют сильно уменьшить размер доказательств включения;
- лучше подходят для модели, где клиенты не хранят состояние, а получают компактные свидетели.
Portal Network и распределённая сеть данных
Статлесс-клиенту нужно откуда-то брать свидетели. Это не обязательно должен быть один «толстый» RPC-провайдер.
Здесь появляется Ethereum Portal Network:
- набор overlay-сетей (history, state, tx), где узлы хранят небольшие фрагменты истории и состояния;
- любой лёгкий клиент может по контент-ключу запросить нужную часть состояния и доказательства;
- сеть строится так, чтобы даже узлы с маленьким диском и слабым железом могли участвовать в хранении и распространении данных.
В связке:
- Portal Network — распределённый источник данных и свидетелей;
- stateless-клиенты — потребители этих данных, которые проверяют всё сами, но ничего не хранят долго.
Это должно уменьшить зависимость от централизованных RPC и повысить децентрализацию доступа к данным.
Stateless-клиенты и дорожная карта Ethereum
Stateless-подход вписывается в более широкий набор инициатив:
- EIP-4444 и «исторический экспайри».
Возможность для узлов не хранить «очень старую» историю блоков локально, переложив её на специализированные решения и распределённые сети.
- Снижение требований к валидаторам.
Если в будущем валидатор сможет работать как stateless-клиент, требования к диску и БД заметно снизятся, упростив запуск валидирующих узлов.
- Многомерная модель газа и DA.
Масштабирование доступности данных через данктшардинг и блобы EIP-4844 создаёт инфраструктуру для более эффективного хранения и распределения состояния.
- Поддержка L2 и rollup-архитектур.
По мере роста L2-роллапов важно, чтобы клиенты могли работать с большим количеством цепочек без необходимости держать огромные локальные базы.
Преимущества и сложности stateless-подхода
Потенциальные плюсы:
- Снижение порога входа для узлов.
Запуск клиента без полной БД состояния делает участие в сети доступнее.
- Меньше доверия к RPC.
Кошельки и dApp могут сами проверять блоки и транзакции, вместо полного доверия «чёрным ящикам» с API.
- Гибкость архитектуры.
Проще разделять узлы на «исполнительные» и «хранилища», строить новые сетевые сервисы вокруг данных Ethereum.
Сложности:
- Размер и сложность свидетелей.
Нужно аккуратно проектировать структуры данных и протоколы, чтобы размер witnesses был приемлемым.
- Переходный период.
Некоторое время сеть будет жить в гибридном режиме: часть узлов — stateful, часть — stateless, множество реализаций клиента.
- Новый класс DoS-рисков.
Работа со свидетелями и распределённой сетью данных открывает новые атакующие поверхности, которые нужно учитывать в дизайне.