Data Availability (DA, доступность данных) — это свойство блокчейна или L2-системы, которое гарантирует, что все необходимые данные транзакций доступны сети для проверки и восстановления состояния.
Если упрощать: недостаточно «согласиться о новом состоянии» — участники должны иметь возможность увидеть все входные данные, чтобы убедиться, что это состояние честное и его можно восстановить.
В контексте Layer-1 (L1), L2 и роллапов Data Availability — один из ключевых элементов безопасности наряду с консенсусом и финальностью (finality).
Зачем нужна доступность данных
В любом блокчейне есть два базовых шага:
- вычислить новое состояние (балансы, storage контрактов) на основе входных данных;
- убедиться, что это состояние корректно и все участники могут его проверить.
Если данные транзакций не доступны:
- честные узлы не могут сами воспроизвести вычисления;
- невозможно убедиться, что новое состояние не содержит скрытых манипуляций;
- пользователи L2/роллапа не могут «эвакуировать» свои активы, если оператор ведёт себя злоумышленно.
Отсюда ключевое требование:
Чтобы система считалась безопасной, честный участник должен иметь возможность получить все данные, достаточные для верификации и восстановления состояния.
Data Availability на уровне L1
В классическом L1 (например, Ethereum) вопрос DA решается относительно прямолинейно:
- транзакции и данные включаются в блоки;
- блоки распространяются по p2p-сети;
- каждый полный узел хранит (хотя бы временно) все данные, необходимые для проверки.
То есть сам протокол L1 гарантирует:
- пока вы запускаете полноценный узел, вы видите все данные блоков;
- вы можете самостоятельно проверить корректность состояния.
Подробнее об архитектуре см. Архитектура Ethereum и Layer-1 (L1).
Data Availability и роллапы/L2
С L2-системами и роллапами всё сложнее:
- транзакции исполняются вне L1;
- итоговое состояние или его сжатое представление публикуется в L1 (хеши, доказательства);
- пользователи должны доверять, что данные, породившие это состояние, доступны.
Именно здесь DA становится критичным:
- если оператор L2 публикует только хеши состояния, но не выкладывает сами данные, никто не может проверить честность вычислений;
- в случае злонамеренного поведения пользователи могут оказаться «заложниками» чёрного ящика.
Поэтому роллапы считаются «настоящими» L2 только если они:
- публикуют данные транзакций или их сжатое представление в L1 (on-chain DA);
- или используют проверяемый и устойчивый DA-слой с чётко описанными гарантиями.
Подробнее о типах L2 см. Layer-2 (L2) на Ethereum и Layer-2 и роллапы — технический хаб.
On-chain DA vs внешние DA-слои
По способу обеспечения доступности данных выделяют несколько подходов.
On-chain Data Availability
Данные (inputs L2) публикуются на Ethereum L1:
- через calldata в транзакциях;
- через специальные структуры данных (например, blob-данные после EIP-4844).
Плюсы:
- максимальные гарантии: пока жив Ethereum, данные можно восстановить;
- пользователи L2 теоретически могут самостоятельно пересчитать состояние и забрать активы через L1-контракты.
Минусы:
- дороже по gas (особенно до появления оптимизированных механизмов DA);
- ограничение по throughput L1.
Это модель «классического» rollup, на которой строится rollup-centric roadmap Ethereum.
Внешние DA-слои (off-chain / external DA)
Часть систем выносит хранение данных за пределы L1:
- специальные DA-сети;
- комитеты валидаторов DA;
- гибриды «validium»/«volition» (данные частично on-chain, частично off-chain).
Плюсы:
- ниже стоимость хранения и публикации;
- выше потенциальная пропускная способность.
Минусы:
- безопасность зависит от DA-слоя;
- при сбое DA или сговоре его операторов восстановить состояние может быть сложно или невозможно.
Обзор подходов см. Решения доступности данных для L2.
Атаки и риски, связанные с DA
Классический риск — атака скрытия данных (data withholding):
- оператор L2 публикует в L1 заголовок блока, хеш состояния или даже zk-доказательство;
- но не распространяет сами данные батча среди пользователей;
- формально L1 видит «корректный» блок, но пользователи не могут проверить, что произошло и какие активы у них на самом деле.
Последствия:
- пользователи не могут безопасно выходить из L2;
- протоколы не могут провести «честное» принудительное закрытие позиций;
- любая логика «escape hatch через L1» ломается без доступа к данным.
Поэтому проверка механизмов DA — не менее важная часть аудита L2/роллапа, чем анализ смарт-контрактов или консенсуса.
Как пользователю оценивать DA в L2
При выборе L2 или роллапа полезно задать несколько вопросов:
- Куда публикуются данные?
В Ethereum (on-chain DA) или во внешний DA-слой/комитет?
- Можно ли в теории пересчитать состояние только из данных L1?
Если да — это сильный плюс для безопасности.
- Какие есть гарантии против data withholding?
Есть ли механизмы, которые:
- заставляют sequencer публиковать данные;
- позволяют пользователям «наказать» оператора за скрытие;
- описаны ли в документации риски и процедуры аварийного выхода.
- Кто контролирует DA-слой?
Это открытая сеть валидаторов или ограниченный набор операторов?
Подробный обзор рисков см. Риски использования L2 и роллапов и Безопасность мостов и L2-роллапов.
Связь DA с fraud-proof и validity-proof
Механизмы проверки состояния L2 тесно связаны с DA:
- Fraud-proof в optimistic-роллапах:
- требуется доступ ко всем данным спорного окна;
- без DA честный участник не сможет корректно оспорить состояние.
- Validity-proof (SNARK/STARK) в zk-роллапах:
- даже при наличии криптодоказательства полезно иметь доступ к данным;
- иначе пользователи не могут самостоятельно реконструировать своё состояние (балансы, позиции) и проверить off-chain логику.
Иными словами: доказательства корректности вычислений не заменяют проблему DA, а дополняют её.