Разработка децентрализованной сети хранения

Разработка децентрализованной сети хранения

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

Архитектура сети хранения: ключевые решения

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

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

1. Data availability layer — гарантирует, что данные доступны для скачивания. Не путать с persistence (данные хранятся долго) — это разные свойства.

2. Proof of Storage — механизм верификации того, что нода действительно хранит данные, а не только заявляет об этом. Это центральная техническая задача.

3. Retrieval network — как клиенты находят и скачивают данные. Libp2p DHT, centralized index, или hybrid.

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 сек
• Provider record churn: записи в DHT требуют периодического переиздания (republish), иначе исчезают
• Eclipse attacks: злоумышленник может изолировать ноды в DHT, контролируя соседство

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

Hybrid подход — что мы реализуем в большинстве проектов:

Hot retrieval: centralized index (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 gas. Для масштабирования используют batching: один challenge транзакция верифицирует N нод через агрегированный proof.

Сравнение с существующими решениями

Если задача — интеграция с готовой сетью хранения для вашего приложения, разработка собственной сети нецелесообразна. Собственная сеть имеет смысл при венчурном финансировании и команде с опытом распределённых систем.

Этапы и сроки

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