Data Availability — одна з найменш зрозумілих, але критично важливих проблем для будь-якого rollup. Блок-продюсер може опублікувати заголовок, але приховати дані транзакцій. Повні вузли не побачать дані, легкі клієнти не зможуть верифікувати блок. Ми пропонуємо інтеграцію з 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 легкі вузли не можуть самостійно верифікувати доступність даних.
| Параметр | 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 для кожного рядка та колонки. Легкий вузол може з високою ймовірністю верифікувати доступність, завантаживши лише випадково вибрані комірки (~30–50 з тисяч). Це і є DAS.
Як працює DAS в Avail?
DAS (Data Availability Sampling) — це процес, при якому легкий вузол не завантажує весь блок, а запитує випадкові комірки. Якщо хоча б одна комірка недоступна, вузол виявляє атаку приховування даних. Ймовірність пропустити приховані 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. Це дозволяє легкому вузлу вашого 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 легкі вузли підписуються на 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).
- Розробка та деплой легкого клієнта для DAS.
- Тестування в тестнеті (Goldberg testnet) та міграція в мейннет.
- Документація та навчання команди.
- Моніторинг продуктивності DA після запуску.
Оцініть ваш проєкт: зв'яжіться з нами, щоб обговорити деталі. Понад 5 років досвіду в блокчейн-розробці та понад 20 інтеграцій DA-шарів — ми допоможемо уникнути типових помилок та прискорити вихід на мейннет. Отримайте консультацію щодо вашого кейсу.