Разработка системы кеширования контента на блокчейне

Как построить децентрализованное кеширование контента?

Представьте: 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 в месяц.