Зачем нужен FILECOIN (FIL) и причем тут zk-SNARK?

Filecoin — крупнейшая в мире сеть zk-SNARK-доказательств, генерирующая 6–7 миллионов криптографических доказательств ежедневно. Эта децентрализованная система хранения данных использует технологию доказательств с нулевым разглашением не для обеспечения приватности (распространённое заблуждение), а для сжатия массивных криптографических доказательств до размера, пригодного для записи в блокчейн. Понимание этой архитектуры раскрывает, почему ZK-технологии стали критически важным элементом экономически устойчивых децентрализованных систем.

Архитектура хранения данных: от IPFS к гарантированной персистентности

Filecoin решает фундаментальную проблему IPFS — отсутствие экономических стимулов для долгосрочного хранения данных. IPFS обеспечивает контентную адресацию через CID (Content Identifiers), но файлы доступны только пока хотя бы один узел их хранит. Filecoin добавляет уровень верифицируемых гарантий и экономических стимулов.

Модель хранения построена на концепции секторов — фиксированных блоков размером 32 GiB или 64 GiB. Клиент инициирует storage deal, проходящую четыре фазы: обнаружение провайдеров, off-chain переговоры о цене, on-chain публикация сделки и передача данных. Провайдер хранения (Storage Provider) размещает данные в секторе, «запечатывает» его через процесс sealing и затем непрерывно доказывает, что данные хранятся.

Процесс sealing — критически важная операция, состоящая из шести этапов:

Участники сети делятся на Storage Providers (хранят данные, предоставляют залог, генерируют доказательства), клиентов (оплачивают хранение), full nodes (валидируют блокчейн) и retrieval providers (обслуживают запросы на получение данных).

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

Криптографические доказательства хранения: PoRep и PoSt

Proof-of-Replication доказывает создание уникальной копии

PoRep криптографически связывает три элемента: исходные данные, идентификатор конкретного провайдера и временну́ю метку блокчейна. Результат — уникальная физическая копия, которую невозможно воспроизвести другим провайдером или в другое время.

Алгоритм SDR (Stacked Depth Robust) использует комбинацию двух графов: Depth Robust Graph обеспечивает последовательность вычислений (нельзя распараллелить), а Bipartite Expander Graph предотвращает атаки сжатия. Каждый из ~1 миллиарда 32-байтовых узлов сектора проходит через 11 слоёв последовательного кодирования, где каждый узел зависит от 13–14 родительских узлов.

Три ключевых коммитмента:

• CommD — корень Merkle-дерева исходных данных (SHA-256)
• CommC — коммитмент столбцов SDR, подтверждающий корректность репликации (Poseidon)
• CommR — коммитмент запечатанной реплики, записываемый в блокчейн

Преднамеренная медленность sealing — ключевой элемент безопасности: процесс занимает часы, тогда как ответ на challenge должен поступить за секунды.

Proof-of-Spacetime подтверждает непрерывное хранение

PoSt доказывает, что данные продолжают храниться с течением времени. Существует два типа:

WinningPoSt используется для права создания блока. Каждые 30 секунд (одна эпоха) блокчейн выбирает лидеров пропорционально их storage power. Выбранный провайдер должен за эти 30 секунд доказать хранение случайно выбранного сектора (66 случайных листьев Merkle-дерева). Пропуск не штрафуется — провайдер просто теряет награду за блок.

WindowPoSt — механизм аудита всех секторов. Каждые 24 часа делятся на 48 окон по 30 минут. Каждый сектор закреплён за конкретным окном навсегда. Провайдер должен доказать хранение всех секторов в своём окне (10 случайных позиций на сектор). Секторы группируются в партиции до 2349 секторов, каждая партиция — один SNARK-proof.

Экономическая необходимость доказательств

Без PoRep возможны три атаки:

• Sybil-атака: создание множества идентичностей для получения многократной оплаты за одну копию
• Атака аутсорсинга: обещание хранения без реального выделения места, с планом получить данные от других при challenge
• Атака генерации: хранение маленькой программы вместо данных с генерацией по требованию

Без PoSt провайдер мог бы удалить данные после однократного доказательства или выборочно хранить только часть сектора.

ZK-SNARKs: сжатие доказательств для масштабируемости

Почему необходимы доказательства с нулевым разглашением

Без zk-SNARKs одно доказательство PoRep занимало бы ~100 МБ. При 6–7 миллионах доказательств в день блокчейн был бы неработоспособен. Groth16 сжимает каждое доказательство до 192 байт (3 элемента группы: 2 в G1, 1 в G2) с константным временем верификации через 3 операции спаривания.

Каждый PoRep включает 10 отдельных SNARK-доказательств (1920 байт суммарно), поскольку полная схема превышает максимальный размер контура в ~134 миллиона ограничений.

Выбор Groth16 и его компромиссы

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

Powers of Tau ceremony проводилась в ноябре–декабре 2019 года с ~19 участниками и сгенерировала параметры для контуров до 2^27 (~134 миллионов) ограничений — в 64 раза больше, чем церемония Zcash. Использовалась кривая BLS12-381. Phase 2 (circuit-specific) прошла в июне–июле 2020 года с ~33 участниками для 6 контуров mainnet.

SnarkPack: агрегация для масштабирования

В июне 2021 года (upgrade HyperDrive, v13) внедрена система SnarkPack, позволяющая агрегировать до 819 секторных доказательств в одно. Схема основана на Inner Pairing Product и обеспечивает логарифмический размер агрегированного доказательства:

Критически важно: SnarkPack не требует новой trusted setup — используется комбинация существующих церемоний Filecoin и Zcash.

Программируемость через FVM и FEVM

Filecoin Virtual Machine запущена 14 марта 2023 года (эпоха 2,683,348, upgrade nv18 Hygge), превратив Filecoin из статичного хранилища в программируемую платформу. Нативный runtime — WebAssembly (WASM).

Одновременно запущен FEVM — виртуализация EVM поверх FVM через интерпретаторы SputnikVM и Revm. Это обеспечивает полную совместимость с Solidity, Vyper и Yul, поддержку инструментов (Hardhat, Remix, Foundry, MetaMask) и Ethereum JSON-RPC API.

Ключевые use cases смарт-контрактов:

• Data DAOs: управление доступом к данным и их монетизация (Lagrange DAO)
• Perpetual storage: автоматическое продление сделок хранения (NFT.Storage Forever)
• DeFi-протоколы: GLIF (>$250M TVL), liquid staking через iFIL-токен
• Автоматизация DataCap-аллокации и репликации данных

Экономическая модель и Filecoin Plus

Storage deals имеют минимальную длительность 180 дней и максимальную 540 дней. Провайдеры вносят залог (Initial Pledge Collateral), рассчитываемый как ~20 дней ожидаемых блок-ревардов. При пропуске WindowPoSt секторы объявляются faulty с начислением штрафов; при 14+ днях простоя — принудительная терминация с потерей залога.

Filecoin Plus — социальный слой верификации полезности данных. Allocators (ранее notaries) выдают DataCap верифицированным клиентам. Сделки с DataCap дают провайдеру 10x Quality Adjusted Power, увеличивая вероятность выигрыша блок-реварда, но требуя 10x залог.

Текущая ёмкость сети: ~4.2 EiB (Q4 2024, снижение с пика ~17 EiB в 2022), ~1900 активных провайдеров, ~1500 PiB активных storage deals.

ZK в Filecoin НЕ означает приватность данных

Критически важное уточнение: термин «zero-knowledge» в контексте Filecoin относится к свойству доказательства, а не к конфиденциальности данных. ZK-SNARKs доказывают корректность вычислений (sealing выполнен правильно) без раскрытия деталей вычислений — но сами данные хранятся незашифрованными.

Из официальной документации: «Протокол Filecoin не обеспечивает шифрование, хотя вы можете использовать его для хранения зашифрованных данных» и «Загрузка незашифрованного файла позволит провайдеру читать файлы, которые вы храните, и пересылать копии третьим лицам».

Storage Provider имеет полный доступ к unsealed-данным во время и после sealing. Sealing — это детерминированное кодирование для доказательств, не шифрование. Для приватности клиент обязан шифровать данные перед загрузкой и самостоятельно управлять ключами.

Заключение: ZK как инфраструктурный слой

Filecoin демонстрирует нетривиальное применение ZK-технологий — не для приватности, а для верифицируемости и масштабируемости. Экономика децентрализованного хранения невозможна без криптографических доказательств: нужно доказать хранение, сжать доказательства для блокчейна и обеспечить экономические стимулы против читерства.

Ключевые технические решения — SDR-кодирование с преднамеренной последовательностью, двухуровневая система PoRep + PoSt, выбор Groth16 с его компромиссом trusted setup ради минимального размера, и SnarkPack для агрегации — образуют целостную систему, где каждый элемент решает конкретную проблему. Понимание этой архитектуры показывает, что «ZK» в современных блокчейн-системах часто означает «верифицируемые вычисления», а не «скрытые данные».

Дополнительно:

Почему ZK-rollups и ZK-блокчейны не нуждаются в Filecoin

Здесь ключевое — понять, что ZK-технологии решают разные задачи в разных системах:

ZK-rollups (zkSync Era, StarkNet, Polygon zkEVM, Scroll, Linea, Taiko) используют ZK-доказательства для сжатия вычислений. Они берут тысячи транзакций, выполняют их off-chain, а потом публикуют на Ethereum только компактное доказательство "все эти транзакции выполнены корректно" плюс минимальные данные для восстановления состояния.

Filecoin использует ZK-доказательства для подтверждения факта хранения файлов. Это совершенно другая задача.

Почему rollups не нужен Filecoin — простыми словами:

Представь две разные ситуации:

Ситуация 1 (ZK-rollup): Ты ведёшь бухгалтерию компании. Тебе нужно доказать налоговой, что все 10 000 операций за год были корректными. Ты не отправляешь им 10 000 документов — ты отправляешь аудиторское заключение на одной странице. Это ZK-rollup: "вот proof, что всё посчитано правильно".

Ситуация 2 (Filecoin): Ты отдал архив документов на хранение в склад. Тебе нужно доказательство, что склад реально хранит твои коробки, а не выбросил их. Это Filecoin: "вот proof, что данные физически существуют".

Конкретные ZK-системы, которым Filecoin не нужен:

Все основные ZK L2 в экосистеме Ethereum:

• zkSync Era — данные публикуются на Ethereum L1
• StarkNet — использует собственный DA или Ethereum
• Polygon zkEVM — данные на Ethereum
• Scroll — данные на Ethereum
• Linea (ConsenSys) — данные на Ethereum
• Taiko — данные на Ethereum

А также ZK L1 блокчейны:

• Mina Protocol — хранит только proof, не хранит историю
• Aleo — приватные вычисления, но данные внутри самой сети

Три причины, почему им не нужен Filecoin:

1. Объём данных совершенно другой. ZK-rollup публикует килобайты на блок (сжатые данные транзакций). Filecoin нужен для терабайтов и петабайтов. Это как сравнивать SMS и видеоархив Netflix.

2. Data Availability уже решена. Rollups публикуют данные либо на Ethereum (calldata, а после EIP-4844 — blobs), либо используют специализированные DA-слои (Celestia, EigenDA, Avail). Эти данные нужны "здесь и сейчас" для верификации, а не для долгосрочного архива.

3. Разная модель угроз. Rollup доказывает: "я правильно посчитал". Filecoin доказывает: "я реально храню". Первому не нужно доказывать хранение — его данные и так видны на L1.

Когда Filecoin МОЖЕТ пригодиться ZK-системам:

Есть пограничные случаи, где комбинация имеет смысл:

• Архивация исторических данных rollup — когда нужно хранить полную историю транзакций за годы, а не только последнее состояние
• NFT и медиа на rollups — сами изображения/видео хранить на rollup дорого, можно хранить на Filecoin, а на rollup — только CID
• Резервное копирование state — для возможности восстановления после катастрофы

Но это опциональные use cases, а не архитектурная необходимость.

Итог одним предложением:

ZK-rollups используют ZK для сжатия вычислений и публикуют результат на Ethereum, где данные и так доступны — поэтому отдельный слой "доказательства хранения" им не нужен. Filecoin нужен там, где хранятся большие объёмы данных вне блокчейна и требуется криптографическая гарантия, что они реально существуют.