---
title: "Риск комитета доступности данных (DAC)"
description: "Руководство с приоритетом проверки аттестаций DAC, правил принятия q-of-n, фактического владения и извлечения данных, коррелированных доменов отказа, ротации ключей, хранения, резервных путей и выхода."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Риск комитета доступности данных (DAC)

> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

<a id="answer"></a>

## Краткий ответ

Комитет доступности данных представляет собой ограниченный набор участников, чьи подписи или аттестации могут удовлетворить правило протокола для принятия утверждения о доступности данных вне сети. Сертификат доказывает только то, что настроенные набор ключей и порог приняли конкретный подписанный объект по этим правилам. Он не доказывает независимо, что каждый подписант получил полные байты, сохранил долговечную копию, обслуживает пользователей сейчас, проверил исполнение или сделал расчет финальным.

Безопасность и живучесть различаются. Если контракт принимает подписи `q-of-n`, контроль над `q` действительными ключами может удовлетворить правило принятия для недоступного объекта, если это не предотвращает другая проверка. Менее `q` готовых и доступных подписантов обычно не могут создать новый сертификат, поэтому обновления останавливаются либо переходят на документированный резервный путь. Фактическое восстановление также зависит от честных проверок до подписи, независимых копий, хранения, пропускной способности выдачи, истории ключей и управления, исполнимого ПО реконструкции и выхода.

<a id="mechanism"></a>

## Как это работает

1. Зафиксируйте развертывание: сеть, режим и версию протокола, расчетный контракт и верификатор доступности, пакет и объект данных, кодирование, обязательство, набор ключей, порог `q`, число участников `n`, обязательных подписантов, активацию, истечение, отзыв и полномочия управления.
2. Точно восстановите подписанное утверждение и логику принятия. Проверьте привязку к домену, сети и контракту, ID пакета, обязательство или корень состояния, срок, битовую карту или агрегацию подписантов, защиту от повтора и реальный расчет порога в контракте. Логотип участника или ответ API не является правилом принятия.
3. Требуйте, чтобы каждый участник до подписи получил полный объект, проверил его обязательство и кодирование, декодировал и сохранил данные для независимого вывода состояния или выхода пользователя. Запишите предмет аттестации и может ли протокол доказать выполнение этих проверок.
4. Описывайте независимые домены отказа, а не считайте названия. Определите юридические лица, бенефициарный контроль, облачные аккаунты и регионы, DNS и сети, программные и СУБД-стеки, хранение ключей, хранилища, операции и юрисдикции. Зеркала или узлы за одним уровнем управления не являются независимыми участниками.
5. Проверьте владение и извлечение. Получите свежие и исторические пакеты от нескольких участников без API оператора, проверьте хеши и корни, восстановите состояние или доказательство вывода, измерьте хранение и исходящий трафик; разделяйте выпуск сертификата, текущую извлекаемость, валидность исполнения, финальность консенсуса и долговечность архива.
6. Проверьте жизненный цикл и восстановление: ротацию участников и ключей, исторические наборы ключей, истечение и отзыв, доступность ниже порога, компрометацию пороговых ключей, избирательную выдачу, сбой оператора, резервную публикацию полных данных, заморозку или escape mode, принудительное включение, независимые архивы и реальные газ и время выхода.
7. Отслеживайте принятые битовые карты подписантов, задержку сертификатов, успех извлечения, целостность байтов, возраст хранилища, изменения набора ключей и порога, обновления, паузы и емкость резервного пути. Архивируйте сертификаты, данные и состояние контрактов и прекращайте увеличивать экспозицию, если сертификаты принимаются, а независимое извлечение или восстановление уже не работает.

<a id="example"></a>

## Разбор примеров

- **Пороговые живучесть и безопасность не совпадают.** В условном комитете `5-of-7` два недоступных участника оставляют `5` подписантов, и новый сертификат еще можно сформировать; три оставляют `4`, поэтому `4 < 5` и выпуск сертификатов прекращается без документированного резервного пути. И наоборот, контроль над `5` принятыми ключами может удовлетворить пороговое правило; сертификат все равно не доказывает текущую извлекаемость байтов или валидность исполнения.
- **Модель независимой доступности.** Только для условной IID-модели предположим, что каждый из `7` участников независимо доступен с вероятностью `0.95`, а сертификату нужно минимум `5`. Тогда `P(quorum) = sum(C(7,k) * 0.95^k * 0.05^(7-k), k=5..7) = 0.9962429570`, а расчетная вероятность остановки равна `1 - 0.9962429570 = 0.0037570430`. Общие облачные, программные, операторские, правовые или ключевые зависимости делают эту биномиальную оценку недействительной.
- **Копии хранения и выдача разделены.** Размер пакета `120 MB`. Семь полных независимых копий занимают `120 * 7 = 840 MB`; если фактически сохраняют только три участника, хранится `120 * 3 = 360 MB`, даже если подписали пять ключей. Однократная выдача объекта `100 clients` передает `120 * 100 = 12,000 MB`, поэтому число подписей не равно ни числу копий, ни пропускной способности выдачи.
- **Порог реконструкции.** Условный объект содержит `1,024 records`, разделенные на `16 chunks` по `64 records`, а заявленный порог восстановления равен `12 chunks`. Одиннадцать фрагментов раскрывают `11 * 64 = 704 records`, но `11 < 12`, поэтому объект нельзя реконструировать по этому правилу. Валидный сертификат комитета не заменяет отсутствующий фрагмент и не меняет порог восстановления.

<a id="risks"></a>

## Риски

- Проверка неверной сети, контракта, развертывания, пакета или версии протокола.
- Неверное восстановление подписанного утверждения, домена, обязательства или срока.
- Принятие повтора между сетями, контрактами, версиями или историческими наборами ключей.
- Использование недействительного, устаревшего, истекшего или отозванного набора ключей.
- Неверное толкование `q`, `n`, обязательных подписантов, битовых карт или агрегированных подписей.
- Эксплуатация ошибки реализации подписанта или контрактной проверки.
- Подписание до полной загрузки, проверки целостности и сохранения.
- Принятие частичных, поврежденных или неправильно кодированных данных.
- Потеря безопасности из-за компрометации или сговора пороговых ключей.
- Потеря живучести из-за числа подписантов ниже порога.
- Принятие коррелированных организаций, облаков, регионов или операторов за независимые.
- Общие DNS, TLS, ПО, базы данных или уровни управления хранилищем.
- Eclipse-атаки, избирательная выдача или зависимость от частного шлюза.
- Удаление данных после подписи или до конца окна выхода.
- Нарушение исторического извлечения из-за смены участников или ротации ключей.
- Замена участников, снижение порога или обход задержки управлением.
- Ссылка на устаревшее, небезопасное или реорганизованное расчетное обязательство.
- Принятие доказательства валидности или финального корня за текущую извлекаемость данных.
- Неисполнимость резервного пути, заморозки, принудительного включения или выхода.
- Недооценка стоимости хранения, трафика, восстановления, резерва, комиссий и емкости.

<a id="misconceptions"></a>

## Распространенные заблуждения

- Больше участников автоматически означает больше независимых доменов отказа.
- `q` подписей доказывают существование `q` долговечных полных и публично извлекаемых копий.
- Доказательство валидности отменяет необходимость проверять доступность данных DAC.
- Старый действительный сертификат гарантирует текущее извлечение и постоянный архив.
- Один честный или официальный участник гарантирует, что каждый пользователь всегда сможет выйти.

<a id="related"></a>

## Связанные темы

- [Доступность данных](/ru/crypto/data-availability/)
- [Роллап](/ru/crypto/rollup/)
- [Финальность](/ru/crypto/finality/)

<a id="sources"></a>

## Источники

- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (дата обращения: 2026-08-13)
- [Validium](https://ethereum.org/developers/docs/scaling/validium/) - Ethereum.org (дата обращения: 2026-08-13)
- [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [Data availability](https://docs.starkware.co/starkex/con_data_availability.html) - StarkEx Documentation (дата обращения: 2026-08-13)
- [starkex-data-availability-committee](https://github.com/starkware-libs/starkex-data-availability-committee) - StarkWare Industries Ltd. (дата обращения: 2026-08-13)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (дата обращения: 2026-08-13)
- [SequencerInbox.sol](https://github.com/OffchainLabs/nitro-contracts/blob/main/src/bridge/SequencerInbox.sol) - Offchain Labs (дата обращения: 2026-08-13)

Source: https://wiki.fcontext.com/ru/crypto/data-availability-committee-risk/index.mdx