Розробка децентралізованої мережі зберігання

Розробка децентралізованої мережи хранения

Типична ситуація: NFT-проект зберігає метадані на централізованому S3. Контракт вказує на https://api.yourproject.com/token/1. Команда розходиться через два роки, домен не продовжується — 10,000 NFT перетворюються у битих посилання. Це не гіпотетичний сценарій, це сталося з десятками проектів. Децентралізоване зберігання вирішує проблему persistence та censorship resistance, але збір собственной мережи зберігання — принципово іншу задачу, ніж просто використання Filecoin або IPFS.

Архітектура мережи зберігання: ключові рішення

Перш ніж писати код, потрібно відповісти: ви будуєте coordination layer поверх існуючих мереж (агрегуєте IPFS-ноди, Filecoin, Arweave) або власну storage мережу з незалежним консенсусом? Більшість проектів ошибочно вибирає другое, коли первого достатньо. Власна мережа оправдана лише при: специфічних вимогах до приватності даних, domain-specific retrieval (наприклад, мережа для відео з adaptive bitrate), або при геополітичній чутливості контенту.

Компоненти storage мережи

1. Data availability layer — гарантує, що дані доступні для скачування. Не плутати з persistence (дані зберігаються довго) — це різні властивості.

2. Proof of Storage — механізм верифікації того, що нода дійсно зберігає дані, а не просто заявляє про це. Центральна технічна задача.

3. Retrieval network — як клієнти знаходять та скачують дані. Libp2p DHT, централізований индекс, або гібрид.

4. Payment layer — як зберігачі отримують компенсацію. Payment channels (мікроплатежі за bandwidth) або periodic settlements.

Proof of Storage: детали реалізації

Proof of Replication (PoRep) — підхід Filecoin

Filecoin використовує Groth16 zk-SNARK для доказательства що нода зберігає унікальну копію (не просто посилання на загальний кластер). Процес:

1. Sealing: дані через PreCommit1 → PreCommit2 → Commit1 → Commit2. На потужному сервері sealing 32GB сектора займає 1.5–3 години
2. Proof generation: нода періодично генерує WindowPoSt (Proof of Spacetime) доказуючи що дані присутні у конкретний момент часу
3. On-chain verification: proof публікується у блокчейн кожні 24 години (WindowPost deadline window)

Реалізовувати PoRep з нуля — завдання на порядок складніше ніж розробка DeFi протоколу. У production використовується rust-fil-proofs (бібліотека Filecoin). Якщо ваша мережа не вимагає сумісності з Filecoin, використовуйте більш легкі schemes.

Proof of Data Possession (PDP) / Provable Data Possession

Більш lightweight підхід, не вимагаючий sealing:

1. Клієнт розбиває файл на блоки B₁, B₂, ..., Bₙ
2. Для кожного блоку обчислюється тег τᵢ = f(Bᵢ, sk_client)
3. Теги публікуються on-chain або в commitment
4. Верифікатор випадково запитує C блоків
5. Нода повертає агреговане доказательство P(B_{i1}, ..., B_{ic}, τ_{i1}, ..., τ_{ic})
6. Верифікатор перевіряє P без скачування всього файлу

Сучасна реалізація використовує BLS signatures для агрегації доказів — верифікація O(1) по розміру файлу незалежно від кількості запрошених блоків.

Erasure coding для fault tolerance

Дані не зберігаються у однієї ноди — вони кодуються через Reed-Solomon або більш сучасні schemes (LT codes, Raptor codes) з надлишковістю:

# Приклад: (k, n) = (10, 16) — дані можна восстановити з будь-яких 10 з 16 шардів
import zfec

k, m = 10, 6  # k data blocks, m redundancy blocks
encoder = zfec.Encoder(k, k + m)
shares = encoder.encode(blocks)

# Для восстановлення достатньо будь-яких k=10 шардів з 16
decoder = zfec.Decoder(k, k + m)
recovered = decoder.decode(available_shares, available_indices)

Параметри (k, m) визначають trade-off між storage overhead та fault tolerance. Для production мережи: (10, 6) — 60% overhead, виходить потерю 6 з 16 нод.

Retrieval Network: DHT vs централізований индекс

libp2p Kademlia DHT — standard choice для decentralized retrieval. IPFS використовує його. Проблеми:

• Lookup latency: пошук у DHT вимагає O(log N) hops, кожен hop — мережевий запит. При 10k нодах — 13+ hops, latency 1–5 sec
• Provider record churn: записи у DHT вимагають периодичного переиздання, інакше зникають
• Eclipse attacks: зловмисник може ізолювати ноди у DHT, контролюючи сусідство

Для content-addressed даних (CID у IPFS/Filecoin) DHT підходить. Для mutable data з version history — потрібен додатковий coordination layer.

Hybrid підхід — що ми реалізуємо у більшості проектів:

Hot retrieval: централізований индекс (Redis cluster) → sub-100ms latency
Cold retrieval: DHT fallback → секунди
Availability guarantee: on-chain content registry → trustless

Централізований індекс — не протиріччя з decentralization ідеологією, якщо він не trusted custodian. Будь-хто може поднять власний індекс, дані content-addressed — верифікація завжди можлива.

Smart contract слой: payments та slashing

Payment channels для мікроплатежів

При retrieval за bandwidth платити за кожен пакет on-chain неможливо. Стандартний паттерн — payment channels (аналог Lightning Network):

contract StoragePaymentChannel {
    struct Channel {
        address client;
        address provider;
        uint256 deposit;
        uint256 nonce;
        uint256 expiry;
    }
    
    mapping(bytes32 => Channel) public channels;
    
    // Клієнт відкриває канал з депозитом
    function openChannel(address provider, uint256 expiry) 
        external payable returns (bytes32 channelId);
    
    // Провайдер закриває з підписаним чеком від клієнта
    function closeChannel(
        bytes32 channelId,
        uint256 amount,
        uint256 nonce,
        bytes calldata clientSignature
    ) external;
}

Off-chain: клієнт підписує чек на все більшу суму по мірі скачування. Провайдер закриває канал у зручний момент, представивши останній чек.

Slashing mechanism

Механізм штрафів за некоректне зберігання. Ключовой параметр — slashing severity: достатньо ли великий штраф щоб зробити мошенництво нерентабельним?

contract StorageSlashing {
    uint256 public constant SLASH_RATIO = 200; // 200% від вартості зберігання
    
    function submitFaultProof(
        address provider,
        bytes32 sectorId,
        bytes calldata proof
    ) external {
        require(verifyFaultProof(proof, sectorId), "Invalid proof");
        uint256 stake = providerStakes[provider];
        uint256 slashAmount = (stake * SLASH_RATIO) / 100;
        
        providerStakes[provider] -= slashAmount;
        // 50% → treasury, 50% → challenger reward
        _distributSlash(slashAmount, msg.sender);
        emit ProviderSlashed(provider, sectorId, slashAmount);
    }
}

Важливий нюанс: fault proof повинен бути gas-efficient. Верифікація on-chain BLS proof коштує ~300-500k газу. Для масштабування використовуйте batching: одна challenge транзакція верифікує N нод через агреговане proof.

Порівняння з існуючими рішеннями

Якщо завдання — інтеграція з готовою мережею зберігання для вашого приложення, розробка власної мережи нецілесообразна. Власна мережа має сенс при венчурному фінансуванні та команді з досвідом розподілених систем.

Етапи та сроки

Повний цикл до production-grade децентралізованої мережи зберігання: 12–18 місяців. Ноди пишуться на Rust (performance critical path) або Go (ecosystem зрілість). JavaScript/Python — тільки для клієнтських SDK.