Розробка децентралізованої CDN

Розробка децентралізованої CDN

Класична CDN — це мережа PoP (points of presence) під управлінням одного провайдера: Cloudflare, Fastly, Akamai. Вони розв'язують задачу добре, але з централізованими ризиками: один CDN може заблокувати ресурс (це трапляється під тиском регуляторів й правоволодільців), один провайдер — точка відказу при DDoS або технічних проблемах, одна компанія — зберігає логи доступу.

Децентралізована CDN розв'язує іншу задачу: цензуроустійчива доставка контенту, економічні інцентиви для операторів узлів, відсутність єдиної точки контролю. Це не замісна Cloudflare для корпоративного сайту — це інфраструктура для Web3 приложень, де decentralization є вимогою, не опцією.

Існуючі протоколи й їхня архітектура

Перед розробкою кастомної dCDN, розумійте, що уже існує — й де цього недостатньо.

Filecoin + IPFS базова комбінація. IPFS забезпечує content-addressed зберігання, Filecoin — економічні інцентиви для довгострокового зберігання. Проблема CDN-перспективи: latency. IPFS retrieval без спеціалізованого шару — повільно. Saturn (Filecoin Saturn) намагається створити retrieval network поверх Filecoin з кешуванням на edge вузлах.

Arweave — permanent storage, один платіж назавжди. AR.IO network будує Gateway layer поверху, дозволяючи операторам заробляти ARIO токени за обслуговування трафіку. Підходить для immutable контенту (NFT metadata, архіви).

Theta Network спеціалізується на доставці відео. Edge nodes кешують та доставляють відео, заробляють TFUEL. Якщо контент — у першу чергу відео, це робочий варіант.

KYVE — data lake з верифікацією. Зберігає й валідує дані від різних джерел (включаючи blockchain дані), забезпечує історичну доступність.

Якщо жоден з існуючих протоколів не підходить — будуйте кастомну dCDN.

Архітектура кастомної dCDN

Компоненти системи

Origin layer — джерело контенту. Для Web3 зазвичай IPFS/Arweave для статики, або off-chain зберігання з on-chain commitment (IPFS CID в контракті).

Edge node network — оператори, які кешують й розповсюджують контент. P2P мережа з discovery через DHT (Kademlia або libp2p). Кожен edge node:

• Реєструється on-chain (staking для входу)
• Оголошує доступний контент й пропускну здатність
• Доставляє контент клієнтам
• Звітує про доставку для отримання награди

Routing layer — клієнт вибирає оптимальний edge node. Критерії: географічна близькість (latency), наявність потрібного контенту, reputation score.

Verification layer — центральна проблема dCDN: як доказати, що edge node дійсно доставив контент?

Proof of Delivery: механізми верифікації

Це найнетривіальніша частина. Кілька підходів:

Optimistic з fisherman challenge — edge node заявляє про доставку, публікує commitment. Будь-хто може оспорити, надавши proof недоставки. При успішному challenge — узел втрачає stake. Проблема: складно доказати недоставку криптографічно.

Proof of Retrievability (PoR) — клієнт періодично посилає challenge до edge node: надай блок даних з такими індексами + merkle proof. Відповідь верифікується проти відомого commitment. Доказує, що дані зберігаються (й доступні), але не факт доставки.

Watchtower network — незалежні спостерігачі періодично тестують edge nodes, вимірюють latency й доступність, публікують результати on-chain. Edge nodes з поганими метриками отримують зменшену награду. Практичний підхід — використовується у Theta.

ZK-based Proof of Delivery — клієнт отримує дані, генерирует zk-proof того, що дані були отримані (commitment до контенту + timestamp + клієнтський nonce). Надсилає proof до контракту, edge node отримує оплату. Проблема: генерація proof на клієнті додає latency й вимагає ресурсів.

Реалістична комбінація: PoR для верифікації зберігання + Watchtower для репутації + Optimistic challenge для економічного захисту.

On-chain механіка

contract DCDNRegistry {
    struct EdgeNode {
        address operator;
        uint256 stake;
        bytes32 geolocationHash; // lat/lon захешовано для приватності
        uint256 bandwidthMbps;
        uint256 reputationScore;  // оновлюється watchtowers
        uint256 registeredAt;
        bool active;
    }

    struct ContentManifest {
        bytes32 contentCID;       // IPFS CID
        address publisher;
        uint256 replicationFactor; // скільки узлів повинні зберігати
        uint256 rewardPerGB;       // у стейблкоіні
        uint256 expiresAt;
    }

    mapping(address => EdgeNode) public edgeNodes;
    mapping(bytes32 => ContentManifest) public manifests;
    mapping(bytes32 => address[]) public contentReplicants; // CID => edge nodes

    function registerNode(uint256 bandwidthMbps, bytes32 geoHash) external payable {
        require(msg.value >= MIN_STAKE, "Insufficient stake");
        edgeNodes[msg.sender] = EdgeNode({
            operator: msg.sender,
            stake: msg.value,
            geolocationHash: geoHash,
            bandwidthMbps: bandwidthMbps,
            reputationScore: 100,
            registeredAt: block.timestamp,
            active: true
        });
    }

    function claimDeliveryReward(
        bytes32 contentCID,
        uint256 bytesDelivered,
        bytes calldata watchtowerAttestation
    ) external {
        require(_verifyAttestation(watchtowerAttestation, contentCID, msg.sender, bytesDelivered));
        uint256 reward = (bytesDelivered * manifests[contentCID].rewardPerGB) / 1e9;
        _transferReward(msg.sender, reward);
    }
}

Маршрутизація клієнта

Клієнт (браузер, мобільне приложение) повинен вибрати найближчий edge node з потрібним контентом:

class DCDNClient {
    async resolveContent(cid: string): Promise<string> {
        // 1. Запит до on-chain реєстру (через RPC або subgraph)
        const nodes = await this.registry.getNodesForContent(cid);
        
        // 2. Геолокація клієнта (IP-based або GPS)
        const clientLocation = await this.getClientLocation();
        
        // 3. Сортування по евристиці: distance + reputation + latency probe
        const ranked = await this.rankNodes(nodes, clientLocation);
        
        // 4. Спроба завантаження з топ-N узлів (паралельно, race)
        const content = await Promise.race(
            ranked.slice(0, 3).map(node => 
                this.fetchFromNode(node, cid, { timeout: 2000 })
            )
        );
        
        return content;
    }
    
    private async fetchFromNode(node: EdgeNode, cid: string, opts: FetchOpts): Promise<string> {
        const url = `https://${node.endpoint}/ipfs/${cid}`;
        const response = await fetch(url, { signal: AbortSignal.timeout(opts.timeout) });
        
        // Верифікація: хеш отриманого контенту повинен збігатися з CID
        const data = await response.arrayBuffer();
        const hash = await this.computeHash(data);
        if (hash !== cid) throw new Error('Content mismatch');
        
        return data;
    }
}

Token economics

Стійка dCDN вимагає продуманої економіки токена:

Demand side: видавці контенту платять за зберігання й доставку. Оплата у стейблкоіні або native токені з фіксованим курсом до GB.

Supply side: оператори edge nodes отримують награду за:

• Доставлений трафік (основний дохід)
• Зберігання рідко запитуваного контенту (менший дохід)
• Watchtower аттестації (невелика, але стабільна)

Staking і slashing: stake при реєстрації. Slashing за недоступність (нижче SLA) або мошенництво (доказана недоставка / фальсифікація метрик).

Replication incentives: контент з малим числом репілік → підвищена награда для перших зберігачів. Автоматична балансировка через ринковий механізм.

Розробка dCDN — це перетин P2P networking, cryptographic verification й token economics. Технічно складніше класичного CDN, але єдиний варіант для проектів, де censorship resistance є вимогою продукту, не маркетинговим тезисом.