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

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

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