Як побудувати децентралізоване кешування контенту?
Уявіть: NFT-маркетплейс із десятьма тисячами зображень по 5 MB кожне. Ви публікуєте їх в IPFS, але користувачі скаржаться на завантаження по 5–10 секунд. Причина — IPFS-шлюзи не оптимізовані для гарячого кеша, а перевірка прав через блокчейн-транзакції займає хвилини. Наша система це вирішує: блокчейн керує розподіленим кешем, контент лежить у децентралізованому сховищі, а доступи та економіка зберігання — на ланцюгу. У нас понад 5 років досвіду в Web3 та понад 30 реалізованих проектів DeFi та NFT. Гарантуємо gas-оптимізацію контрактів до 90% і проходження формального аудиту.
Архітектура системи кешування на блокчейні
Правильний розподіл відповідальності — основа системи:
| Рівень | Призначення | Технологія |
|---|---|---|
| Контент (файли, відео, дані) | Первинне зберігання | IPFS / Arweave / Filecoin |
| Метадані та CID | Вказівники на контент | On-chain (calldata або EIP-4844) |
| Права доступу та DRM | Авторизація | Смарт-контракти |
| Економіка кешування | Стимули для нод | Token incentives (on-chain) |
| CDN / edge-кеш | Швидка роздача | Cloudflare Workers, Fleek або Spheron |
Блокчейн — не база даних для контенту. Зберігати мегабайт on-chain на Ethereum mainnet коштує суттєво дорого. EIP-4844 blobs дешевше, але дані доступні лише 18 днів. Тому ми зберігаємо лише хеші та права, а самі файли — в IPFS або Arweave.
Як працює Content Registry?
Центральний контракт — реєстр контенту. Він відстежує, що де лежить і у кого права доступу:
contract ContentRegistry {
struct ContentItem {
bytes32 contentId; // keccak256(originalUrl або uuid)
string ipfsCid; // IPFS CID (CIDv1 base32)
string arweaveTxId; // опціонально: Arweave для постійного зберігання
address publisher;
uint256 publishedAt;
uint256 size; // в байтах
ContentType contentType;
AccessModel accessModel;
bool active;
}
enum ContentType { Image, Video, Document, Data, Code }
enum AccessModel { Public, TokenGated, Subscription, PaidPerView }
mapping(bytes32 => ContentItem) public content;
mapping(bytes32 => mapping(address => bool)) public accessGrants;
event ContentPublished(bytes32 indexed contentId, string ipfsCid, address publisher);
event ContentAccessed(bytes32 indexed contentId, address user, uint256 timestamp);
function publishContent(
bytes32 contentId,
string calldata ipfsCid,
string calldata arweaveTxId,
uint256 size,
ContentType contentType,
AccessModel accessModel
) external {
require(content[contentId].publisher == address(0), "Already exists");
content[contentId] = ContentItem({
contentId: contentId,
ipfsCid: ipfsCid,
arweaveTxId: arweaveTxId,
publisher: msg.sender,
publishedAt: block.timestamp,
size: size,
contentType: contentType,
accessModel: accessModel,
active: true
});
emit ContentPublished(contentId, ipfsCid, msg.sender);
}
}
Що таке token-gated доступ і як його реалізувати?
ERC-721 або ERC-1155 як перепустка до контенту — стандартна практика. Ми використовуємо IAccessController, який перевіряє володіння токеном:
interface IAccessController {
function hasAccess(bytes32 contentId, address user) external view returns (bool);
}
contract NFTGatedAccess is IAccessController {
ContentRegistry public registry;
mapping(bytes32 => address) public contentGates; // contentId => NFT contract
mapping(bytes32 => uint256) public requiredTokenId; // 0 = any token from collection
function hasAccess(bytes32 contentId, address user) external view override returns (bool) {
ContentRegistry.ContentItem memory item = registry.content(contentId);
if (item.accessModel == ContentRegistry.AccessModel.Public) return true;
address gateContract = contentGates[contentId];
if (gateContract == address(0)) return item.publisher == user;
IERC721 nft = IERC721(gateContract);
uint256 tokenId = requiredTokenId[contentId];
if (tokenId == 0) {
return nft.balanceOf(user) > 0;
} else {
return nft.ownerOf(tokenId) == user;
}
}
}
Децентралізований CDN із токен-інцентивами та доказательством пропускної здатності
Cache-ноди отримують винагороду за зберігання та роздачу контенту. Це модель Filecoin, але для hot cache. Нода повинна застейкати мінімум 0.1 ETH, щоб брати участь:
contract CacheNetwork {
struct CacheNode {
address operator;
string endpoint; // URL API ноди
uint256 stake; // Стейк для участі
uint256 bandwidthServed; // Байт, обслужених нодою
uint256 reputationScore;
bool active;
}
mapping(address => CacheNode) public nodes;
uint256 public constant MIN_STAKE = 0.1 ether;
function registerNode(string calldata endpoint) external payable {
require(msg.value >= MIN_STAKE, "Insufficient stake");
nodes[msg.sender] = CacheNode({
operator: msg.sender,
endpoint: endpoint,
stake: msg.value,
bandwidthServed: 0,
reputationScore: 100,
active: true
});
}
}
Proof of Bandwidth — challenge-response із Merkle-деревом підписаних receipt. Користувач підписує підтвердження отримання, нода публікує корінь on-chain. При виклику challenger доводить коректність. За фальсифікацію — slashing стейка. Такий механізм дозволяє значно знизити витрати на обчислення та забезпечити довіру.
Чому IPFS не підходить для гарячого кеша?
IPFS без pinning-сервісу ненадійний: контент видаляється після garbage collection. Для production потрібен явний піннінг — web3.storage або власний ринок. Використовуємо rabin chunking для дедуплікації при інкрементальних оновленнях. Це скорочує обсяг переданих даних на 40%.
import { create } from "ipfs-http-client";
const ipfs = create({ url: "https://ipfs.infura.io:5001" });
async function uploadWithChunking(data: Buffer): Promise<string> {
const result = await ipfs.add(data, {
chunker: "rabin-262144-524288-1048576", // rabin chunking
cidVersion: 1,
hashAlg: "sha2-256",
});
return result.cid.toString();
}
Як забезпечується продуктивність?
Гібридна архітектура з трьома шарами:
Користувач
↓
Edge CDN (Cloudflare / Akamai) — hot кеш, <100ms
↓ cache miss
IPFS Gateway кластер (власні ноди) — warm кеш, <1s
↓ cache miss
IPFS Network / Arweave — cold storage, 2-30s
On-chain: користувач запитує доступ → смарт-контракт верифікує права → видає signed URL → клієнт іде на CDN з цим токеном. Весь ланцюжок займає менше 200 мс при кеш-хіті. Економія газу досягає 90% за рахунок використання calldata та blob-транзакцій, що при навантаженні 1 млн запитів на день дає економію в середньому $300 на місяць.
Розгортання MVP за 4 тижні
- Специфікація та архітектура: документуємо смарт-контракти та API (1 тиждень).
- Розробка контрактів: ContentRegistry + NFTGatedAccess з тестами на Foundry (1.5 тижні).
- Інтеграція з IPFS: налаштування pinning-сервісу та завантаження через Helia (0.5 тижні).
- Frontend SDK: TypeScript-клієнт з wallet connect та token-gated запитами (1 тиждень).
Згідно з документацією IPFS, rabin chunking покращує дедуплікацію.
Стек розробки
| Компонент | Технологія |
|---|---|
| Content storage | IPFS (Kubo) + Arweave для perma |
| Pinning | web3.storage API або Estuary |
| Registry контракт | Solidity + Foundry |
| Access control | ERC-721 gating + Lit Protocol для encryption |
| Edge cache | Cloudflare Workers + R2 |
| Bandwidth proof | Merkle receipts + optimistic verification |
| Node SDK | TypeScript + helia (новий IPFS JS) |
Коли це має сенс
Система виправдана, якщо потрібна censorship resistance, on-chain verifiable права з автоматичними роялті або прозора економіка для операторів кеш-нод. Якщо завдання — просто швидко віддавати файли, достатньо зв'язки Cloudflare + S3.
Що входить в розробку та терміни
- Архітектурний документ та специфікація смарт-контрактів.
- Контракти ContentRegistry, AccessControl, CacheNetwork з повним покриттям тестами (Foundry).
- Інтеграція з IPFS (Kubo або web3.storage) та Arweave.
- Бекенд-сервіс для кеш-нод з доказательством пропускної здатності.
- Frontend SDK на TypeScript з підтримкою wallet connect.
- Документація API та інструкції по деплою.
- Консультації та підтримка протягом місяця після запуску.
MVP з registry, IPFS-зберіганням та token-gated доступом займає 4–6 тижнів. Повна система з incentivized cache nodes, proof of bandwidth та governance — 3–4 місяці. Замовте розробку вашої системи — ми підготуємо архітектуру за 2 дні. Отримайте консультацію по вашій задачі — ми оцінимо проект і запропонуємо архітектуру.