Система децентралізованого кешування контенту на блокчейні

Як побудувати децентралізоване кешування контенту?

Уявіть: NFT-маркетплейс із десятьма тисячами зображень по 5 MB кожне. Ви публікуєте їх в IPFS, але користувачі скаржаться на завантаження по 5–10 секунд. Причина — IPFS-шлюзи не оптимізовані для гарячого кеша, а перевірка прав через блокчейн-транзакції займає хвилини. Наша система це вирішує: блокчейн керує розподіленим кешем, контент лежить у децентралізованому сховищі, а доступи та економіка зберігання — на ланцюгу. У нас понад 5 років досвіду в Web3 та понад 30 реалізованих проектів DeFi та NFT. Гарантуємо gas-оптимізацію контрактів до 90% і проходження формального аудиту.

Архітектура системи кешування на блокчейні

Правильний розподіл відповідальності — основа системи:

Блокчейн — не база даних для контенту. Зберігати мегабайт 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 на місяць.