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

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

Уявіть: 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 на місяць.