Data availability sampling, или DAS, отвечает на узкий, но важный вопрос: опубликованы ли данные блока так, чтобы участники сети могли их получить? Для ответа лёгкому узлу не обязательно скачивать блок целиком. Он запрашивает небольшие случайные фрагменты и проверяет доказательства, связанные с обязательством в заголовке блока. Если множество независимых запросов успешно, вероятность скрытого крупного участка становится очень малой.
Это не способ выполнить все транзакции и не архив на вечное хранение. DAS подтверждает доступность данных в нужный момент. Чтобы понять его роль, полезно отделять публикацию данных от исполнения и доказательства состояния. Такое разделение лежит и в основе модульной архитектуры Celestia, и в планах масштабирования Ethereum.
Почему одного обязательства в заголовке недостаточно
Производитель блока может поместить в заголовок криптографическое обязательство, которое однозначно связано с набором данных. Однако само обязательство не доказывает, что все данные действительно разосланы сети. Если часть содержимого скрыта, другие участники не смогут восстановить состояние, проверить транзакции или построить доказательство нарушения.
Полный узел решает проблему напрямую: скачивает весь набор и сверяет его с обязательством. Такой подход надёжен, но создаёт предел пропускной способности. Чем больше блоки или объём blob-данных, тем выше требования к каналу, памяти и диску каждого проверяющего узла. Если для проверки всегда приходится получать всё, масштабирование быстро вытесняет домашних операторов.
DAS меняет эту связь. Сеть кодирует исходные данные с избыточностью, делит расширенный набор на небольшие части и даёт возможность запросить произвольную часть вместе с доказательством корректности. Благодаря избыточности производителю недостаточно спрятать один незаметный байт: чтобы помешать восстановлению, ему нужно скрыть заметную долю расширенного набора. Именно такую потерю уже хорошо ловят случайные выборки.
Как работает проверка по случайным частям
Сначала данные разбивают на элементы и расширяют кодом исправления стираний. Упрощённо это похоже на мозаику с резервными плитками: полный рисунок можно восстановить, даже если часть плиток недоступна. Затем для строк, столбцов или отдельных ячеек создаются криптографические обязательства. Корень этих обязательств попадает в заголовок блока.
Лёгкий узел выбирает случайные координаты, запрашивает соответствующие части и проверяет их доказательства. Успешный ответ говорит, что конкретная часть соответствует обязательству. Серия независимых ответов повышает уверенность, что производитель не удержал достаточно данных для атаки. Это вероятностная гарантия: один ответ ничего не говорит обо всём массиве, но десятки корректно распределённых запросов резко уменьшают шанс пропустить крупную недоступную область.
Сила схемы растёт, когда выборки делают многие узлы. Их запросы покрывают разные координаты, а полученные части распространяются между участниками. Некоторые реализации могут восстанавливать отсутствующие фрагменты из доступной половины расширенного набора и снова раздавать их сети. Так выборка становится не только проверкой, но и механизмом восстановления доступности.
Чем отличаются подходы Ethereum и Celestia
В Celestia лёгкие узлы применяют DAS к расширенной двумерной матрице данных. Они получают случайные shares с доказательствами строк и столбцов. Сеть специализируется на упорядочивании и доступности blob-данных, оставляя исполнение приложениям и rollup-системам. При этом архивная извлекаемость старых данных зависит от узлов и сервисов, которые продолжают их хранить.
В Ethereum PeerDAS развивает blob-модель EIP-4844. Blob делится на ячейки, а узлы отвечают за хранение определённых колонок и делают выборки у пиров. Валидатор должен убедиться в доступности данных, прежде чем голосовать за блок. Это позволяет увеличивать объём blob-пространства без требования, чтобы каждый узел скачивал каждый blob целиком. Связь этой схемы с rollup проще увидеть после разбора того, кто упорядочивает транзакции based rollup.
Что DAS гарантирует, а что остаётся за рамками
Успешная выборка подтверждает, что опубликованный набор, вероятнее всего, можно получить и восстановить. Она не доказывает правильность вычислений внутри rollup, честность секвенсора или отсутствие цензуры. Эти свойства обеспечивают другие механизмы: повторное исполнение, fraud proof, validity proof, правила включения транзакций и социальный слой сети.
DAS также не превращает blob в постоянное хранилище. Данные могут быть доступны в период, необходимый протоколу, а затем удаляться обычными узлами. Приложение, которому нужна многолетняя история, должно отдельно организовать архивирование. По этой причине понятия data availability и data retrievability нельзя считать полными синонимами.
Наконец, вероятностная проверка зависит от случайности выборки, числа запросов, разнообразия пиров и сетевой модели. Если узел спрашивает части у одного контролируемого источника или атакующий заранее знает все координаты, реальная гарантия слабее расчётной. Протоколы уменьшают этот риск распределением обязанностей, выбором разных пиров и правилами, связывающими голосование с успешной проверкой.
Как читать заявления о масштабировании через DAS
Обещание «проверять блок, не скачивая его» не означает бесплатную бесконечную пропускную способность. Нужно узнать размер выборки, схему кодирования, долю данных для восстановления, требования к полным или суперузлам и поведение при недостатке ответов. Ещё важнее понять, кто хранит старые данные и сколько времени приложение может рассчитывать на их получение.
Для rollup-пользователя эффект проявляется косвенно. Большее пространство данных снижает дефицит ресурса, но итоговая комиссия зависит от загрузки L1, сжатия пакета, исполнения в L2 и настроек оператора. Поэтому DAS полезно рассматривать на примере модульной архитектуры Eclipse, а не как самостоятельную гарантию дешёвых переводов.
Главная идея DAS проста: сеть заменяет обязательное полное скачивание множеством небольших непредсказуемых проверок, а кодирование делает серьёзное сокрытие данных заметным. Это позволяет большему числу лёгких узлов участвовать в проверке доступности, сохраняя возможность для полного восстановления данных специализированными участниками.
