Data Availability — одна из наименее понятых, но критически важных проблем для любого rollup. Блок-продюсер может опубликовать заголовок, но утаить данные транзакций. Полные ноды не увидят данные, light-клиенты не смогут верифицировать блок. Мы предлагаем интеграцию с Avail — специализированным модульным DA-слоем, который гарантирует доступность данных с помощью DAS. Наши инженеры реализовали DA-подключение для нескольких rollup-проектов: валидиумов и суверенных чейнов. Более 20 успешных интеграций DA-слоёв. Получите консультацию по вашему кейсу — оценим проект под ключ.
Чем Avail отличается от Ethereum blobs
Ethereum использовался как DA layer через calldata (до EIP-4844) и теперь через blob transactions. Но у Ethereum как DA layer есть ограничения:
- Стоимость: даже после EIP-4844, Ethereum DA дорог по сравнению со специализированными DA-решениями. Target 3 blobs per block (~375 KB), max 6 blobs — недостаточно для масштабного роста rollup.
- Отсутствие DAS: Ethereum пока не реализовал полноценный Data Availability Sampling. Без DAS light-ноды не могут самостоятельно верифицировать доступность данных.
| Параметр | Ethereum Blobs (EIP-4844) | Avail |
|---|---|---|
| Архитектура | DA + Execution | DA-only |
| DAS | Нет (в roadmap) | Да, реализован |
| Throughput | ~375 KB/block target | Значительно выше |
| Стоимость | Выше | Ниже |
| Finality | ~12 мин (L1) | ~20 сек |
| KZG commitments | Да | Да (Kate commitments) |
Экономия на DA-стоимости достигает 5–10 раз по сравнению с Ethereum blobs. Erasure Coding в Avail — ключевой механизм. Данные расширяются 2× через Reed-Solomon кодирование, разбиваются на ячейки, формируется 2D-матрица. KZG polynomial commitments для каждой строки и колонки. Light-нода может с высокой вероятностью верифицировать доступность, скачав только случайно выбранные ячейки (~30–50 из тысяч). Это и есть DAS.
Как работает DAS в Avail?
DAS (Data Availability Sampling) — это процесс, при котором light-нода не скачивает весь блок, а запрашивает случайные ячейки. Если хотя бы одна ячейка недоступна, нода обнаруживает атаку сокрытия данных. Вероятность пропустить скрытые 50% данных при 30 запросах — менее 10⁻⁹. Под капотом лежит решетка Reed-Solomon и KZG commitment для каждой строки. Дополнительно используется 2D-кодирование: данные раскладываются в матрицу, каждую строку и колонку кодируют отдельно. Это обеспечивает устойчивость к ошибкам и экономит ресурсы лёгких нод.
Архитектура интеграции
Случай 1: Rollup использует Avail как DA
Стандартная схема для суверенного rollup или валидиума:
Rollup Sequencer → batch transactions → encode → submit to Avail
↓
Avail block включает данные
↓
Avail light clients верифицируют DAS
↓
Rollup settlement layer получает DA attestation
Avail DA submission через официальный SDK:
import { initialize } from 'avail-js-sdk';
async function submitBatchToAvail(batchData: Uint8Array): Promise<SubmitResult> {
const api = await initialize(AVAIL_RPC_URL);
const account = new Keyring({ type: 'sr25519' });
const keyPair = account.addFromMnemonic(AVAIL_MNEMONIC);
// app_id идентифицирует ваш rollup/application
// данные индексируются по app_id для эффективного retrieval
const result = await api.tx.dataAvailability
.submitData(batchData)
.signAndSend(keyPair, { app_id: YOUR_APP_ID });
return {
blockHash: result.blockHash,
txHash: result.txHash,
dataRoot: await getBlockDataRoot(api, result.blockHash)
};
}
App ID — критический концепт в Avail. Каждый rollup или application регистрирует уникальный App ID. Данные фильтруются по App ID при retrieval. Это позволяет light-ноде вашего rollup делать DAS только по своим данным, не скачивая весь блок.
Случай 2: Validium с Ethereum settlement
Validium — это ZK rollup, где данные хранятся off-chain (не на Ethereum). Вместо Ethereum calldata используется Avail. Settlement (proof verification) остаётся на Ethereum.
User transactions → Prover (zkEVM/zkVM) → ZK proof
↓
Avail ← batch data Ethereum ← ZK proof + data root
↓ ↓
DAS verification State transition verified
Для Ethereum settlement контракт нужно верифицировать, что данные действительно в Avail. Avail предоставляет Avail Bridge — набор смарт-контрактов на Ethereum для on-chain верификации Avail attestations:
// Упрощённо: верификация DA attestation на Ethereum
interface IAvailBridge {
struct MerkleProofInput {
bytes32[] dataRootProof;
bytes32[] leafProof;
bytes32 rangeHash;
uint256 dataRootIndex;
bytes32 blobRoot;
bytes32 bridgeRoot;
bytes32 leaf;
uint256 leafIndex;
}
function verifyBlobLeaf(MerkleProofInput calldata input) external view returns (bool);
}
// В settlement контракте rollup:
function finalizeBlock(
bytes32 stateRoot,
bytes calldata zkProof,
IAvailBridge.MerkleProofInput calldata daProof
) external {
// 1. Верифицируем что данные блока в Avail
require(availBridge.verifyBlobLeaf(daProof), "DA not available");
// 2. Верифицируем ZK proof state transition
require(verifier.verifyProof(zkProof, stateRoot), "Invalid proof");
// 3. Обновляем state root
currentStateRoot = stateRoot;
emit BlockFinalized(stateRoot);
}
Случай 3: Sovereign Rollup
Суверенный rollup использует Avail для DA и ordering, но settlement и fork choice — собственные. Нет зависимости от Ethereum или другого settlement layer. Rollup light-ноды подписываются на Avail DA:
// Пример: Avail light client для sovereign rollup (Rust)
use avail_light::LightClient;
async fn sync_rollup_blocks(app_id: u32) -> Result<()> {
let light_client = LightClient::new(AVAIL_BOOTSTRAP_NODES).await?;
// DAS верификация: клиент сам верифицирует доступность данных
// скачивая только случайные ячейки, не весь блок
light_client.subscribe_app_data(app_id, |block_data| {
// Декодируем rollup транзакции из Avail блока
let txs = decode_rollup_transactions(&block_data)?;
// Применяем к rollup state machine
rollup_state_machine.apply_transactions(txs)?;
Ok(())
}).await?;
Ok(())
}
Avail Nexus и Fusion
Avail развивает экосистему за пределы base DA layer:
Avail Nexus — proof aggregation layer. Собирает ZK proofs от разных rollup, агрегирует их через recursive proofs (Plonky2/SuperNova), отправляет один агрегированный proof на Ethereum. Снижает стоимость L1 settlement для каждого отдельного rollup.
Avail Fusion — механизм restaking. ETH и другие активы могут обеспечивать экономическую безопасность Avail через restaking. Цель — унаследовать security от более капитализированных активов.
Для интеграции: если строите rollup сейчас — Nexus интересен для снижения settlement costs, но находится в ранней стадии.
Практические аспекты интеграции
Data Retrieval
Отправить данные в Avail — половина задачи. Нужно уметь их получать:
// Получение данных по app_id и block range
async function retrieveRollupData(
api: ApiPromise,
appId: number,
fromBlock: number,
toBlock: number
): Promise<AppData[]> {
const results: AppData[] = [];
for (let blockNum = fromBlock; blockNum <= toBlock; blockNum++) {
const blockHash = await api.rpc.chain.getBlockHash(blockNum);
const block = await api.rpc.chain.getBlock(blockHash);
// Фильтрация extrinsics по app_id
const appExtrinsics = block.block.extrinsics.filter(ext => {
const appId = extractAppId(ext);
return appId === appId;
});
if (appExtrinsics.length > 0) {
results.push({
blockNumber: blockNum,
blockHash: blockHash.toString(),
data: appExtrinsics.map(ext => ext.method.args[0] as Bytes)
});
}
}
return results;
}
Производительность и стоимость
Block submission latency — Avail блоки ~20 секунд. Это acceptable для большинства rollup use cases, но если rollup хочет sub-second UX, нужна soft confirmation от sequencer до DA finality.
Batch size optimization — Avail лимит на extrinsic size. Нужно батчить rollup транзакции оптимально: слишком маленькие батчи → высокая стоимость per transaction, слишком большие → задержка.
Стоимость в AVAIL токенах — нужен механизм оплаты. Опции: rollup сам держит AVAIL и платит, пользователи rollup платят в native token который конвертируется, или fee abstraction через газ-спонсорство.
Мониторинг DA
// Верификация что данные действительно доступны после submission
async function verifyDataAvailability(
blockHash: string,
appId: number
): Promise<boolean> {
// Запрашиваем confidence от Avail light client network
const confidence = await getDAConfidence(blockHash, appId);
// Confidence > 99.99% означает что данные доступны с высокой вероятностью
// (математически: злоумышленник не может скрыть данные если DAS прошёл)
return confidence > 99.99;
}
Почему стоит выбрать Avail для DA?
Подходит:
- Строите валидиум: хотите Ethereum-level security для proof verification, но дешевле хранить данные off-chain.
- Суверенный rollup без зависимости от Ethereum.
- Нужна полная реализация DAS (Ethereum пока не имеет).
- Высокий throughput данных, где Ethereum blobs будут узким местом.
Не подходит:
- Небольшой rollup с низким throughput — overhead интеграции не оправдан, EIP-4844 blobs достаточно.
- Нужна Ethereum-native security для данных (Ethereum AS DA, не только settlement).
- Команда незнакома с Substrate-based экосистемой (Avail built on Substrate).
Этапы интеграции
| Фаза | Содержание | Срок |
|---|---|---|
| Protocol design | Выбор DA scheme (validium/sovereign), App ID регистрация | 1–2 нед |
| SDK integration | Avail submission/retrieval в sequencer | 2–3 нед |
| Settlement contracts | Avail Bridge интеграция (для Ethereum settlement) | 2–3 нед |
| Light client | DA verification для rollup nodes | 2–4 нед |
| Testing | Тестнет полный цикл | 2–3 нед |
| Production | Mainnet deployment + мониторинг | 1–2 нед |
Что входит в интеграцию
- Анализ архитектуры rollup и выбор схемы DA.
- Настройка Avail SDK для submission и retrieval.
- Интеграция Avail Bridge (если требуется settlement на Ethereum).
- Разработка и деплой light-клиента для DAS.
- Тестирование в тестнете (Goldberg testnet) и миграция в мейннет.
- Документация и обучение команды.
- Мониторинг производительности DA после запуска.
Оцените ваш проект: свяжитесь с нами, чтобы обсудить детали. Более 5 лет опыта в блокчейн-разработке и свыше 20 интеграций DA-слоёв — мы поможем избежать типовых ошибок и ускорить выход на мейннет. Получите консультацию по вашему кейсу.