Як працюють моделі виконання: Stateful vs Stateless архітектури

TL;DR

Безстанова (stateless) модель виконання: валідатори не зберігають повний стан; вони лише перевіряють переходи за допомогою криптографічних свідків (witnesses).
Станова (stateful) модель виконання: кожен валідатор зберігає та оновлює весь світовий стан (традиційна модель основної мережі Ethereum).
Stateless покладається на компактні докази (Verkle-дерева, STARK) та потужні шари DA.
Основний компроміс: значно нижчі вимоги до обладнання + краща децентралізація проти більшого розміру доказів та навантаження на bandwidth.
Реальність сьогодні: чистий stateless трапляється рідко; більшість модульних стеків використовують stateless-виконання + stateful DA/settlement (гібрид).
Провідні приклади: Ethereum Verge (Verkle), Polygon AggLayer, ролапи на Celestia та lazy bridging.

Чому моделі виконання важливі у 2025 році

Спосіб, яким вузол блокчейну отримує доступ та оновлює стан, давно перестав бути деталлю реалізації — він став одним із головних важелів масштабування та суверенітету в модульних дизайнах. З поширенням ролапів, appchains та суверенних L2 архітекторам доводиться вирішувати: чи зберігатимуть валідатори терабайти історичного стану, чи перевірятимуть переходи стану, ніколи не зберігаючи його локально.

Вибір між безстановим та становим виконанням безпосередньо впливає на децентралізацію, бар’єри обладнання, витрати на доступність даних та крос-чейн компонуємість.

Визначення двох моделей

Станова модель виконання — класичний підхід

У становій моделі кожен повний вузол підтримує повну, актуальну копію всього світового стану (баланси акаунтів, сховище смарт-контрактів, хеші коду тощо). Коли пропонується блок:

Продюсер блока включає транзакції та новий корінь стану.
Кожен валідатор повторно виконує всі транзакції на своїй локальній копії стану.
Якщо отриманий корінь стану збігається з вказаним у блоці, блок приймається.

Так працюють Ethereum, Solana, BNB Chain та практично всі монолітні L1. Перевага — простота та миттєва фінальність запитів стану: будь-який вузол може відповісти «який баланс у адреси X?» без звернення до когось іншого.

Недолік очевидний у 2025 році: повний архівний вузол Ethereum вже перевищує 14 ТБ і продовжує зростати. Навіть обрізані повні вузли вимагають ~1 ТБ SSD та 32+ ГБ RAM, що робить їх недоступними для більшості індивідуальних операторів.

Безстанова модель виконання

У безстановій моделі валідатори не зберігають світовий стан локально. Натомість кожна транзакція (або батч) супроводжується даними-свідками — криптографічними доказами доступу до потрібних зрізів стану (наприклад, гілки Merkle в Patricia-деревах або Verkle-докази).

Процес валідації стає таким:

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

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

Технічні компроміси на масштабі

Вимоги до обладнання та децентралізація

Тут stateless перемагає з великим відривом. Тестований сьогодні stateless-клієнт Ethereum на тестнетах Verge комфортно працює на міні-ПК за 300 доларів або навіть на кластерах висококласних Raspberry Pi 5. Навпаки, запуск станового вузла виконання на більшості L1 чи L2 вимагає обладнання enterprise-рівня.

Реальні докази: легкі вузли доступності даних Celestia вже працюють без стану з <8 ГБ RAM, тоді як вузли виконання Ethereum страждають від роздування стану.

Bandwidth та розмір доказів

Головний недолік чистого stateless-виконання завжди полягав у роздуванні свідків. З застарілим Merkle–Patricia Trie Ethereum один переказ ERC-20 зазвичай вимагає 1–3 КБ даних-свідків. Навіть при 1000 TPS це перетворюється на десятки мегабіт на секунду лише доказів, вже наближаючись до межі практичності для stateless-клієнтів.

Саме тому весь екосистемний забіг зараз спрямований на Verkle-дерева та рекурсію STARK: обидва скорочують свідків у 20–30 разів і роблять stateless-клієнти практичними при реальній пропускній здатності.

Гарантії доступності даних

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

Тому stateless-виконання майже завжди поєднується з виділеним шаром DA (Celestia, Ethereum DAS після Prague, Avail). Сам шар DA залишається становим — він мусить зберігати та обслуговувати дані, але валідатори виконання залишаються легкими та безстановими.

Синхронна vs асинхронна компонуємість

Станові ролапи (наприклад, Arbitrum One до Atlas, ланцюги OP Stack) пропонують синхронну компонуємість: токен на одному ролапі можна використовувати на іншому в тому ж блоці, якщо вони ділять один шар settlement.

Безстанові дизайни схиляються до асинхронної компонуємості, бо генерація та поширення доказів стану вимагає часу. Проєкти на кшталт Polygon AggLayer та мостів Succinct SP1 вирішують це механізмами пре-конфірмацій та спільними stateless-мостами.

Реальні реалізації

Ethereum — roadmap The Verge (Verkle Trees)

Майбутнє оновлення Ethereum «The Verge» замінює Patricia Merkle-дерева на Verkle-дерева, скорочуючи розмір свідків з кілобайт до ~30–50 байт на слот сховища. EIP-6800 та EIP-7691 закладають основу для повністю stateless-клієнтів до 2026–2027 років. Після запуску будь-хто зможе запускати повний валідуючий вузол на ноутбуці, при цьому перевіряючи весь ланцюг.

Celestia + ролапи — DA stateless, виконання змішане

Сама Celestia повністю безстанова для сэмплінгу доступності даних. Ролапи, що публікуються в Celestia (наприклад, Doma, Movement), сьогодні зазвичай запускають станові вузли виконання, але проєкти на кшталт Eclipse та Citrus (SVM-ролап на Celestia) переходять до stateless SVM-клієнтів з використанням STARK-доказів та DA Celestia.

Polygon AggLayer — уніфікований stateless-мост

AggLayer реалізує спільний агрегатор stateless-доказів. Окремі ланцюги можуть залишатися становими всередині, але крос-чейн повідомлення доводяться через stateless ZK-докази відносно уніфікованого кореня стану. Це дає безпеку єдиного спільного шару settlement без вимоги до кожного валідатора зберігати стан усіх ланцюгів.

Гібридні підходи — практична середина

Чисте stateless-виконання в продакшені досі рідкість. Більшість команд обирають один із трьох гібридних патернів:

Станове виконання + безстанова верифікація (наприклад, boojum-прувер zkSync Era генерує докази, які може перевірити будь-який stateless-вузол).
Stateless-клієнти виконання + станові DA/settlement (модель Ethereum + Celestia).
Stateless-шар мостів поверх станових ланцюгів (AggLayer, Chain Signatures Near).

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

Погляд у майбутнє

До 2027 року стандартним припущенням у модульній архітектурі, ймовірно, стане: «виконання безстанове, доступність даних та settlement — мінімально станові». Прогрес у Verkle-деревах, рекурсії STARK та розподіленому розповсюдженні свідків (наприклад, Portal Network, Helios stateless light client) усуває останні серйозні перешкоди.

Для будівельників, які обирають модель виконання сьогодні:

Якщо пріоритет — максимальна децентралізація та довгостроковий суверенітет → обирайте stateless з першого дня (поєднуйте з Celestia/Avail/Ethereum DAS).
Якщо потрібна синхронна компонуємість і ви готові до вищих вимог до обладнання → станове виконання з агресивною обрізкою та плановим шляхом міграції на stateless.

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

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

Джерело перекладу: https://www.altiuslabs.xyz/learn/deterministic-execution-why-its-essential-for-smart-contracts