2 поста с тегом "decentralized storage"

Децентрализованные сети хранения данных призваны решить проблемы недолговечности данных, цензуры и централизации путем распределения информации по пиринговым (P2P) сетям. Традиционный веб-контент на удивление эфемерен — например, исследования показывают, что более 98% интернет-контента становится недоступным через 20 лет, что подчеркивает необходимость в надежном долгосрочном хранении. Такие поставщики, как Arweave и Pinata (построенный на IPFS), предложили решения для постоянного или распределенного хранения, наряду с другими проектами, такими как Filecoin, Storj, Sia, Ceramic и лежащий в их основе протокол IPFS. В данном отчете эти сервисы анализируются по следующим критериям: (1) техническая архитектура и возможности, (2) модели ценообразования, (3) опыт разработчиков, (4) принятие пользователями, (5) зрелость экосистемы и (6) ключевые сценарии использования (например, хостинг метаданных NFT, бэкенды dApp, архивные данные, доставка контента). Для наглядности приведены сравнительные таблицы и примеры. Все источники ссылаются на официальную документацию или авторитетные аналитические материалы.

1. Технические возможности и архитектура​

Arweave: Arweave — это блокчейноподобная сеть постоянного хранения, построенная на основе новой структуры данных Blockweave. В отличие от традиционных блокчейнов, которые связывают блоки линейно, Blockweave в Arweave связывает каждый блок с его непосредственным предшественником и случайным более ранним блоком, создавая структуру, похожую на паутину. Такой дизайн (в сочетании с консенсусом Succinct Proof of Random Access (SPoRA)) означает, что майнеры должны проверять случайные старые данные для добычи новых блоков, что стимулирует их хранить как можно большую часть архива. Результатом является высокая избыточность — фактически, в настоящее время по всему миру распределено примерно 200 полных реплик всего набора данных Arweave. Данные, загруженные в Arweave, становятся частью этого «Permaweb», являются неизменяемыми и постоянными. Для повышения производительности и масштабируемости Arweave использует бандлинг (объединение множества мелких файлов в одну транзакцию) для обработки больших объемов данных (например, бандлер Arweave однажды сохранил 47 ГБ данных в одной транзакции). Механизм Wildfire ранжирует узлы по скорости отклика, чтобы стимулировать быстрое распространение данных в сети. В целом, Arweave действует как децентрализованный жесткий диск — хранит данные постоянно в блокчейне с расчетом на то, что стоимость хранения будет продолжать снижаться, что позволит вечно платить майнерам из авансового целевого фонда (endowment).

IPFS и Pinata: Межпланетная файловая система (IPFS) представляет собой пиринговую файловую систему с адресацией по контенту для распределенного хранения и обмена данными. Данные в IPFS идентифицируются по хешу контента (CID) и извлекаются через глобальную распределенную хеш-таблицу (DHT). По своей сути IPFS — это инфраструктура для обмена файлами, она не гарантирует сохранность данных, если узлы не продолжают явно размещать («пинить») контент. Сервисы вроде Pinata расширяют возможности IPFS, предоставляя пиннинг и пропускную способность: Pinata запускает узлы IPFS, которые закрепляют ваши данные для обеспечения их доступности, и предлагает быстрый HTTP-шлюз с интеграцией CDN для оперативного извлечения (часто называемый «горячим хранилищем» для часто запрашиваемых данных). Технически архитектура Pinata — это централизованная облачная инфраструктура, поддерживающая децентрализованную сеть IPFS: ваши файлы распределяются через IPFS (адресуются по контенту и могут быть получены любым пиром IPFS), но Pinata гарантирует высокую доступность, сохраняя копии на своих серверах и кэшируя их через выделенные шлюзы. Pinata также предлагает частные сети IPFS (для изолированного использования), хранилище данных key-value на базе IPFS и другие инструменты для разработчиков. Вкратце, IPFS+Pinata предоставляет протокол децентрализованного хранения (IPFS) с уровнем управляемого сервиса (Pinata) для обеспечения надежности и производительности.

Filecoin: Filecoin часто рассматривают как стимулирующий слой для IPFS. Это децентрализованная сеть хранения на базе блокчейна, где поставщики хранилищ (майнеры) сдают в аренду дисковое пространство на открытом рынке. Filecoin использует инновационный механизм Proof-of-Replication (PoRep), чтобы гарантировать, что майнер сохранил уникальные копии данных клиента, и Proof-of-Spacetime (PoSt) для непрерывной проверки того, что данные остаются сохраненными в течение долгого времени. Эти доказательства, основанные на доказательствах с нулевым разглашением, записываются в блокчейн Filecoin, давая криптоэкономическую гарантию того, что данные хранятся в соответствии с договоренностями. Сеть Filecoin построена на технологии IPFS для адресации контента и передачи данных, но добавляет смарт-контракты («сделки по хранению»), исполняемые в блокчейне. В рамках сделки по хранению пользователь платит майнеру в токенах Filecoin (FIL) за хранение данных в течение определенного срока. Майнеры вносят залог (collateral), который может быть списан (слэшинг), если они не смогут доказать наличие данных, что гарантирует надежность. Filecoin не делает данные автоматически публичными; пользователи обычно комбинируют его с IPFS или другими сетями доставки для распространения контента. Система масштабируема и гибка — большие файлы можно разделять и хранить у нескольких майнеров, а клиенты могут выбирать уровень избыточности, заключая сделки с несколькими провайдерами для защиты от сбоев узлов. Этот дизайн ориентирован на массовое хранение: майнеры оптимизируют работу под большие наборы данных, а скорость извлечения может зависеть от отдельных «майнеров извлечения» или использования кэшей IPFS. По сути, Filecoin — это децентрализованный аналог Amazon S3 + Glacier: рынок хранения данных с проверяемой долговечностью и определяемой пользователем избыточностью.

Storj: Storj — это распределенная сеть облачного объектного хранения, которая не использует блокчейн для достижения консенсуса, а координирует хранение через децентрализованную сеть узлов и спутниковую службу метаданных. Когда файл загружается в Storj (через сервис под названием Storj DCS — Decentralized Cloud Storage), он сначала шифруется на стороне клиента, а затем разделяется на 80 фрагментов (по умолчанию) с использованием избыточного кодирования (erasure coding) так, что для восстановления файла требуется лишь часть из них (например, 29 из 80). Эти зашифрованные фрагменты распределяются по различным узлам хранения по всему миру (каждый узел хранит только случайные фрагменты, которые сами по себе бесполезны). Это обеспечивает Storj чрезвычайно высокую долговечность (заявлена надежность 11×9s — 99.999999999%) и параллелизм при загрузке — пользователь может получать фрагменты файла с десятков узлов одновременно, что часто повышает пропускную способность. Storj использует концепцию proof-of-retrievability (узлы хранения периодически подтверждают наличие своих фрагментов). Сеть работает по модели с нулевым доверием с оконечным шифрованием: только владелец файла (имеющий ключ дешифрования) может прочитать данные. В архитектуре нет центрального дата-центра — вместо этого используются избыточные мощности дисков, предоставляемые операторами узлов, что повышает устойчивость и глобальное распределение (Storj отмечает, что это обеспечивает производительность на уровне CDN и гораздо меньший углеродный след). Координация (метаданные файлов, платежи) осуществляется «спутниками», управляемыми Storj Labs. Таким образом, технический подход Storj — это зашифрованное, шардированное и распределенное объектное хранилище, обеспечивающее высокую избыточность и скорость загрузки, сравнимую с традиционными CDN или превосходящую их, без консенсуса в блокчейне, но с криптографическим аудитом хранения.

Sia: Sia — еще одна децентрализованная облачная платформа хранения, использующая собственный блокчейн и криптовалюту (Siacoin) для формирования контрактов на хранение. Sia разделяет файлы на 30 зашифрованных шардов с использованием избыточного кодирования Рида — Соломона и требует любые 10 из этих шардов для восстановления файла (обеспечивая встроенную 3-кратную избыточность). Эти шарды хранятся на независимых хостах по всей сети. Блокчейн Sia работает на алгоритме Proof-of-Work и используется для исполнения смарт-контрактов между арендаторами и хостами. В контракте Sia арендатор блокирует Siacoin на определенный период, а хост вносит залог; хост должен периодически предоставлять доказательства хранения (похожие по смыслу на доказательства Filecoin), подтверждающие наличие данных, иначе он теряет залог. По окончании контракта хостам выплачиваются средства из эскроу-счета (небольшая часть идет держателям Siafund в качестве комиссии протокола). Этот механизм гарантирует, что у хостов есть экономический стимул и риск штрафов для надежного хранения данных. Дизайн Sia подчеркивает конфиденциальность (все данные зашифрованы; хосты не видят файлы пользователей) и устойчивость к цензуре (отсутствие центрального сервера). Как и Storj, Sia обеспечивает параллельную загрузку фрагментов файлов с нескольких хостов, повышая скорость и аптайм. Однако Sia требует от пользователей периодического продления контрактов (обычно раз в 3 месяца) для поддержания хранилища, что означает, что данные не являются «постоянными», если пользователь не продолжает платить. Ранее Sia представила уровень под названием Skynet для веб-ориентированного использования: Skynet обеспечивал адресацию контента (через «скайлинки») и веб-порталы для легкого извлечения контента, фактически выступая в роли децентрализованного CDN для файлов Sia. В целом, архитектура Sia — это защищенное блокчейном облачное хранилище с сильной избыточностью и приватностью, подходящее для «горячих» данных в децентрализованной среде.

Ceramic: Ceramic стоит особняком — это децентрализованная сеть для изменяемых потоков данных, а не для массового хранения файлов. Она ориентирована на такие сценарии, как динамические JSON-документы, профили пользователей, идентификаторы (DID), социальный контент и т. д., которые должны храниться децентрализованно, но при этом часто обновляться. Протокол Ceramic использует криптографически подписанные события (обновления), которые привязываются (anchored) к блокчейну для упорядочивания. На практике данные в Ceramic хранятся в виде «потоков» (streams) или смарт-документов — каждый фрагмент контента живет в потоке, который может быть обновлен владельцем (с проверяемой историей версий). «Под капотом» Ceramic использует IPFS для хранения контента каждого обновления, а лог событий поддерживается для того, чтобы все узлы могли согласовать последнее состояние документа. Консенсус достигается путем привязки обновлений потока к базовому блокчейну (изначально Ethereum) для получения неизменяемой временной метки и порядка. У Ceramic нет нативного токена; узлы просто реплицируют данные для dApp, использующих сеть. Технические особенности включают интеграцию DID (децентрализованной идентификации) для аутентификации обновлений и глобальные схемы (модели данных) для обеспечения совместимости форматов. Ceramic спроектирован как масштабируемый (состояние каждого потока поддерживается независимо, поэтому нет общего «реестра» всех данных, что позволяет избежать узких мест). В итоге, Ceramic предоставляет децентрализованные базы данных и изменяемое хранилище для Web3-приложений — это дополнение к сетям хранения файлов, сосредоточенное на структурированных данных и управлении контентом (в то время как Arweave/Filecoin/Storj фокусируются на статических файлах).

Резюме по архитектурам: В таблице ниже сравниваются ключевые технические аспекты этих систем:

2. Модели ценообразования​

Несмотря на схожие цели децентрализованного хранения, эти сервисы используют различные модели ценообразования и экономические модели:

• Ценообразование Arweave: Arweave требует единовременного авансового платежа в токенах AR для хранения данных *вечно*. Пользователи оплачивают как минимум 200 лет хранения данных, и протокол направляет около 86 % этой платы в целевой фонд (endowment fund). Накопления фонда (за счет процентов и роста стоимости AR) предназначены для выплат майнерам хранилища бессрочно, исходя из предположения, что стоимость оборудования со временем снижается (исторически на ~30 % дешевле в год). На практике цена колеблется в зависимости от рыночной стоимости AR, но по состоянию на 2023 год она составляла около $ 3 500 за 1 ТБ единоразово (примечание: это покупка бессрочного хранения, в то время как традиционное облако — это регулярные расходы). Модель Arweave переносит финансовую нагрузку на начало: пользователи платят больше изначально, но затем ничего не платят. Это может быть дорого для больших объемов данных, но это гарантирует перманентность без необходимости доверять провайдеру в будущем.
• Ценообразование Pinata (IPFS): Pinata использует модель подписки (фиатное ценообразование), распространенную в Web2 SaaS. Она предлагает бесплатный уровень (до 1 ГБ хранилища, 10 ГБ/месяц пропускной способности, 500 файлов) и платные тарифы. Популярный план «Pinata Picnic» стоит $20 в месяц** и включает 1 ТБ закрепленного (pinned) хранилища и 500 ГБ пропускной способности, с **тарифами за превышение** около$ 0,07 за ГБ хранилища и $0,10 за ГБ трафика. Более высокий план **«Fiesta» за$ 100 в месяц увеличивает лимиты до 5 ТБ хранилища и 2,5 ТБ пропускной способности с еще более дешевым превышением. Все платные уровни включают такие функции, как пользовательские шлюзы, увеличенные лимиты API-запросов и совместная работа (многопользовательские рабочие пространства) за дополнительную плату. Также существует корпоративный уровень с индивидуальным ценообразованием. Таким образом, расходы на Pinata — это предсказуемые ежемесячные платежи, аналогичные облачным провайдерам, и они не основаны на токенах — сервис превращает IPFS в привычную структуру ценообразования (хранилище + пропускная способность с бесплатным CDN-кэшированием в шлюзах).
• Ценообразование Filecoin: Filecoin работает как открытый рынок, поэтому цены определяются спросом и предложением майнеров хранилища, обычно выраженными в нативном токене FIL. На практике, благодаря избыточному предложению, хранение в Filecoin стало чрезвычайно дешевым. По состоянию на середину 2023 года хранение данных в Filecoin стоит около **$2,33 за 1 ТБ в год** — значительно дешевле централизованных альтернатив (AWS S3 стоит ~$ 250/ТБ/год для часто запрашиваемых данных) и даже других децентрализованных вариантов. Однако эта ставка не является фиксированной — клиенты размещают ставки (bids), а майнеры предлагают свои условия (asks); рыночная цена может варьироваться. Сделки по хранению в Filecoin также имеют определенную длительность (например, 1 год); если вы хотите сохранить данные дольше этого срока, вы должны продлить сделку (заплатить снова) или сразу заключить долгосрочный контракт. Существует также концепция Filecoin Plus (FIL+) — программа стимулирования, которая дает «верифицированным» клиентам (хранящим полезные публичные данные) бонус для привлечения майнеров по более низкой эффективной стоимости. Помимо платы за хранение, пользователи могут платить небольшие суммы в FIL за извлечение (retrieval) данных на основе каждого запроса, хотя рынки извлечения все еще развиваются (многие сейчас полагаются на бесплатное извлечение через IPFS). Важно отметить, что токеномика Filecoin (вознаграждения за блок) сильно субсидирует майнеров — вознаграждения в FIL дополняют сборы, уплачиваемые пользователями. Это означает, что сегодняшние низкие цены частично обусловлены инфляционными вознаграждениями; со временем, по мере сокращения вознаграждений за блок, плата за хранение может вырасти. В итоге ценообразование Filecoin является динамичным и основанным на токенах, как правило, с очень низкой стоимостью за байт, но пользователи должны управлять продлениями и валютными рисками FIL.
• Ценообразование Storj: Цены Storj указаны в традиционной валюте (хотя платежи можно производить в фиате или токенах STORJ). Сервис следует модели облачного ценообразования на основе использования: в настоящее время это $4,00 за ТБ-месяц хранения** и **$ 7,00 за ТБ исходящего трафика (egress). В более детальном выражении это $0,004 за ГБ-месяц сохраненных данных и$ 0,007 за каждый скачанный ГБ. Также взимается крошечная плата за каждый сохраненный объект (сегмент) для учета затрат на метаданные (около $ 0,0000088 за сегмент в месяц), что имеет значение только при хранении миллионов очень маленьких файлов. Примечательно, что входящий трафик (ingress) бесплатен, и у Storj есть политика отмены платы за исходящий трафик, если вы решите перенести данные (чтобы избежать привязки к поставщику). Ценообразование Storj прозрачное и фиксированное (без аукционных рынков) и существенно подрывает традиционные облака (они заявляют об ~80 % экономии по сравнению с AWS благодаря отсутствию необходимости в региональной репликации или больших накладных расходах на дата-центры). Конечным пользователям не обязательно взаимодействовать с токенами, если они этого не хотят — можно просто оплачивать счета в долларах США. Storj Labs затем компенсирует работу операторов узлов токенами STORJ (предложение токенов фиксировано, и операторы несут определенную волатильность цен). Эта модель делает Storj удобным для разработчиков в плане цены, при этом используя токен для децентрализованных выплат «под капотом».
• Ценообразование Sia: Рынок хранения Sia также является алгоритмическим и выражен в токенах, используя Siacoin (SC). Как и в Filecoin, арендаторы и хосты договариваются о ценах через рыночную сеть, и исторически Sia была известна своими крайне низкими затратами. В первые годы Sia рекламировала хранение по цене **~$2 за ТБ в месяц**, хотя фактические цены зависят от предложений хостов. Один расчет сообщества Reddit в 2020 году показал, что реальная стоимость составляет около$ 1–3 за ТБ в месяц для арендаторов без учета затрат на избыточность (с избыточностью эффективная стоимость может быть в несколько раз выше, например, $ 7/ТБ в месяц при учете 3-кратной избыточности) — все равно очень дешево. По состоянию на 3 квартал 2024 года цены на хранение в Sia выросли на ~22 % по сравнению с предыдущим кварталом из-за повышенного спроса и колебаний токена SC, но остаются значительно ниже цен централизованных облаков. Арендаторам в Sia также необходимо выделять некоторое количество SC для пропускной способности (загрузка/выгрузка) и залога (collateral). Экономика такова, что хосты конкурируют, предлагая низкие цены (так как хотят привлечь контракты и заработать SC), а арендаторы выигрывают от этой конкуренции. Однако, поскольку использование Sia требует управления кошельком с Siacoin и настройки контрактов, рассчитывать затраты немного сложнее, чем в Storj или Pinata. Вкратце: затраты Sia зависят от рынка токенов и очень низки в расчете на ТБ, но пользователь должен постоянно платить (в SC) для продления контрактов. Нет единовременной суммы за вечное хранение — это модель оплаты по мере использования в криптоформе. Многие пользователи приобретают SC через биржу и затем могут фиксировать контракты на месяцы хранения по заранее определенным ставкам.
• Ценообразование Ceramic: Ceramic не взимает плату за использование на уровне протокола; здесь нет нативного токена или комиссии за создание/обновление потоков, помимо незначительной стоимости газа за привязку (anchoring) обновлений в блокчейне Ethereum (которая обычно обрабатывается инфраструктурой Ceramic и ничтожна для каждого обновления при пакетной обработке). Запуск узла Ceramic — это открытая деятельность: любой может запустить его для индексации и обслуживания данных. 3Box Labs (команда разработчиков Ceramic) предлагала хостинговый сервис для разработчиков (Ceramic Cloud), который может вводить корпоративные тарифы для удобства, но сама сеть бесплатна для использования, не считая усилий по запуску узла. Таким образом, «цена» Ceramic — это в основном операционные расходы, которые несут разработчики при самостоятельном хостинге узлов, или стоимость доверия при использовании стороннего узла. По сути, модель Ceramic больше похожа на децентрализованную базу данных или блокчейн-сервис RPC — монетизация (если она есть) осуществляется через дополнительные услуги, а не через микроплатежи за данные. Это делает ее привлекательной для разработчиков, экспериментирующих с динамическим хранением данных без необходимости в токенах, но также требует обеспечения долгосрочной поддержки узлов (так как хранение обеспечивается альтруистичными узлами или узлами на грантах).

Сводка по ценам: В таблице ниже приведена сводка моделей ценообразования и оплаты:

3. Опыт разработчиков (Developer Experience)​

Ключевым фактором внедрения является то, насколько легко разработчики могут интегрировать эти решения для хранения данных — через API, SDK, документацию и инструменты:

• Опыт разработчиков Arweave: Arweave предоставляет GraphQL API-эндпоинт (по адресу arweave.net/graphql), который позволяет отправлять запросы к пермавебу (permaweb) для поиска транзакций и данных — разработчики могут искать сохраненный контент по тегам, адресам кошельков и т. д. Существуют официальные SDK, такие как Arweave.js для браузера и Node.js, которые упрощают загрузку файлов и отправку транзакций в сеть. Например, разработчик может использовать Arweave SDK для связки (bundle) и загрузки файла всего несколькими строками кода. Поскольку каждая загрузка является ончейн-транзакцией, UX для крупномасштабных загрузок исторически был сложным, но внедрение Bundlr (Bundlr Network) значительно улучшило пропускную способность. Bundlr (теперь переименованный в «Iris» для масштабирования Arweave) — это, по сути, сеть узлов агрегации, которые позволяют разработчикам платить один раз и загружать множество файлов вне сети, а затем периодически фиксировать их в Arweave оптом. Это позволяет dApps (особенно NFT-платформам) быстро загружать тысячи файлов, не перегружая чейн, при этом обеспечивая итоговую неизменяемость. Экосистема инструментов Arweave также включает CLI Arweave Deploy и ArDrive (удобное приложение для управления файлами в Arweave). Концепция Permaweb распространяется и на хостинг веб-приложений — разработчики могут развертывать HTML/JS в Arweave с помощью таких инструментов, как Ardor или бандлер Web3, и делать их доступными по постоянному URL. Документация Arweave обширна и охватывает вопросы ценообразования загрузок (есть даже калькулятор), извлечения данных (через шлюзы или запуск легкого узла) и созданные сообществом «сборники рецептов» (cookbooks) для типичных задач. Одной из сложностей является работа с ключом кошелька для подписания транзакций; Arweave использует ключи на базе RSA, которыми управляют разработчики (хотя существуют веб-кошельки и решения для управления ключами в облаке). В целом, опыт разработчиков улучшается по мере созревания Arweave благодаря надежным SDK, простому REST-подобному интерфейсу (GraphQL) и инструментам сообщества. Примечательный аспект: так как пользователи платят в AR, разработчики должны интегрировать поток криптоплатежей — некоторые решают это путем предоплаты за пользователей или использования сторонних сервисов, которые принимают кредитные карты и конвертируют их в AR.
• Опыт разработчиков Pinata (IPFS): Pinata создана с учетом потребностей разработчиков — ее слоган «Добавьте загрузку и извлечение файлов IPFS за считанные минуты», и она предоставляет простой REST API и надежный JavaScript SDK. Например, используя Node.js, разработчик может выполнить npm install @pinata/sdk, а затем использовать методы pinata.pinFileToIPFS(file) или новые методы pinata.upload для хранения файлов в IPFS через сервис Pinata. SDK берет на себя аутентификацию (Pinata использует API-ключи или JWT) и избавляет от необходимости запускать собственный узел IPFS. Документация Pinata ясна, содержит примеры загрузки файлов, закрепления (pinning) по CID (если контент уже находится в IPFS) и управления пинами (открепление, статус пина и т. д.). Она также поддерживает шлюз контента: разработчики могут использовать собственный поддомен (например, myapp.mypinata.cloud) для предоставления контента через HTTP со встроенным CDN и даже оптимизацией изображений. Это означает, что разработчики могут работать с изображениями, хранящимися в IPFS, почти так же, как в Cloudinary или Imgix (оптимизатор изображений Pinata может изменять размер или обрезать изображения на лету с помощью параметров URL). Недавно Pinata представила такие функции, как «Pinata KV» (хранилище «ключ-значение» для JSON или метаданных, полезное наряду с хранилищем файлов) и Access Controls (для настройки контента как общедоступного или ограниченного). Эти функции более высокого уровня упрощают создание полноценных приложений. Кроме того, поскольку Pinata — это просто интерфейс для IPFS, разработчики сохраняют гибкость ухода — они всегда могут взять CID, закрепленный через Pinata, и закрепить его в другом месте (или на собственном узле), так как IPFS интероперабельна. Поддержка Pinata (руководства, сообщество) высоко ценится, и они даже сотрудничают с Protocol Labs в таких инициативах, как миграция NFT.Storage (предоставляя руководства, помогающие пользователям перемещать данные между сервисами). Для тех, кто не хочет вообще касаться криптовалют, Pinata идеальна — не нужно интегрировать блокчейн, только простые вызовы API и кредитная карта. Обратной стороной является меньшая децентрализация самой интеграции, так как вы полагаетесь на доступность и качество обслуживания Pinata (хотя ваш контент по-прежнему имеет адресацию по хешу и может быть реплицирован в IPFS). В итоге, Pinata предлагает отличный DX: простую настройку, исчерпывающую документацию, SDK и функции (шлюз, CDN, аналитика), которые абстрагируют сложности IPFS.
• Опыт разработчиков Filecoin: Прямое использование Filecoin может быть сложным — традиционно оно требовало запуска узла Filecoin (например, Lotus) и понимания таких концепций, как секторы, сделки (deals), майнеры и т. д. Однако экосистема создала множество ориентированных на разработчиков сервисов и библиотек, чтобы упростить этот процесс. Примечательно, что web3.storage и NFT.storage (от Protocol Labs) позволяют разработчикам хранить данные в IPFS с резервным копированием в Filecoin без необходимости работать с токенами FIL или механикой сделок. Эти сервисы предоставляют простой API (аналогичный API Pinata) — например, NFT-проект может вызвать API NFT.storage для загрузки изображения и метаданных; NFT.storage закрепит их в IPFS и заключит сделки Filecoin с несколькими майнерами для долгосрочного хранения, и все это бесплатно (субсидируется PL). Это кардинально изменило ситуацию с внедрением среди разработчиков в сфере NFT. Кроме того, существуют такие инструменты, как Estuary, Powergate (от Textile) и Glacier, которые предлагают удобные для разработчиков шлюзы к хранилищу Filecoin. Также растет экосистема вокруг виртуальной машины Filecoin (FVM), запущенной в 2023 году, которая позволяет использовать смарт-контракты в Filecoin — теперь разработчики могут писать программы, работающие в блокчейне Filecoin, что открывает возможности для дата-центричных dApps (например, автоматическое продление сделок по хранению или стимулирование извлечения данных). Для базового хранения и извлечения большинство разработчиков будут использовать либо уровень IPFS поверх (рассматривая Filecoin как «холодное» резервное хранилище), либо хостинговое решение. Стоит отметить, что, поскольку Filecoin является открытой сетью, существует множество сторонних сервисов: например, Lighthouse.storage предлагает услугу «плати один раз, храни вечно» на базе Filecoin (взимается авансовый платеж и используется концепция эндаумента, во многом похожая на Arweave, но реализованная через сделки Filecoin). Для разработчиков, которым нужен больший контроль, документация Filecoin предоставляет библиотеки (на Go, JavaScript и т. д.) для взаимодействия с сетью, также существуют фреймворки, такие как Slate (для создания пользовательских приложений хранения) и Space (SDK для пользовательского хранения Filecoin + IPFS от Fleek). Порог вхождения выше, чем у Pinata или Storj, особенно при работе на низком уровне — разработчики должны понимать адресацию по контенту (CID), жизненный цикл сделки и, возможно, запускать узел IPFS для быстрого извлечения. В документации IPFS подчеркивается, что IPFS и Filecoin дополняют друг друга; действительно, разработчик, использующий Filecoin, почти всегда будет сочетать его с IPFS для фактического доступа к данным в своем приложении. Таким образом, опыт разработчика Filecoin часто превращается в опыт разработчика IPFS с дополнительными шагами для обеспечения сохранности. Экосистема огромна: по состоянию на 2022 год на базе Filecoin/IPFS было создано более 330 проектов, охватывающих NFT, Web3-игры, хранение метавселенных, видео и многое другое. Это означает наличие множества примеров и поддержки сообщества. В целом, DX Filecoin варьируется от готовых решений (NFT.storage) до высоконастраиваемых (Lotus и FVM) — это мощно, но может быть сложно, хотя наличие бесплатных сервисов хранения IPFS + Filecoin облегчило внедрение для многих распространенных сценариев использования.
• Опыт разработчиков Storj: Storj DCS позиционирует себя как полноценную замену традиционным объектным хранилищам. Он предлагает S3-совместимый API — это означает, что разработчики могут использовать привычные AWS S3 SDK или инструменты (boto3 и т. д.), просто указав эндпоинт на шлюз Storj. Это радикально снижает порог вхождения, так как практически любое программное обеспечение, работающее с S3 (инструменты резервного копирования, файловые менеджеры и т. д.), может работать со Storj с минимальными изменениями конфигурации. Для тех, кто предпочитает нативные интерфейсы Storj, предоставляются библиотеки (на Go, Node, Python и т. д.) и CLI под названием uplink. Документация на storj.io и storj.dev является исчерпывающей и включает примеры кода для типичных задач (загрузка, скачивание, совместное использование, настройка прав доступа). Уникальной особенностью являются токены предоставления доступа (access grant tokens) — механизм безопасности, который инкапсулирует ключи шифрования и разрешения, обеспечивая доверие на стороне клиента: разработчик может создать токен с ограниченными правами (например, доступ только для чтения к определенному бакету) для встраивания в приложение без раскрытия корневых ключей. Это удобно для создания ссылок общего доступа или загрузки файлов непосредственно в сеть на стороне клиента. Дашборд Storj помогает отслеживать использование, а их ресурсы поддержки (форум сообщества, Slack/Discord) активны как для разработчиков, так и для операторов узлов. Существуют руководства по интеграции со сторонними сервисами — например, FileZilla (FTP-клиент) интегрировала Storj, чтобы пользователи могли перетаскивать файлы в Storj так же, как на любой сервер. Rclone, популярный инструмент синхронизации для командной строки, также поддерживает Storj «из коробки», что упрощает интеграцию Storj в конвейеры данных (data pipelines). Поскольку Storj обрабатывает шифрование автоматически, разработчикам не нужно внедрять его самостоятельно — но это также означает, что в случае потери ключей Storj не сможет восстановить данные (компромисс ради безопасности с нулевым доверием). С точки зрения производительности разработчики могут заметить, что загрузка множества крошечных файлов влечет за собой накладные расходы (из-за платы за сегменты и избыточного кодирования), поэтому лучшей практикой является упаковка мелких файлов вместе или использование многосоставной загрузки (multipart upload), аналогично работе с любым облачным хранилищем. Порог вхождения очень низок для всех, кто знаком с концепциями облачного хранения, коих много: Storj намеренно копирует опыт разработчиков AWS, где это возможно (SDK, документация), но предлагает децентрализованный бэкенд. По сути, Storj предоставляет привычный DX (S3 API, хорошо документированные SDK) с преимуществами шифрования и децентрализации, что делает его одним из самых плавных процессов онбординга среди вариантов децентрализованного хранения.
• Опыт разработчиков Sia: Исторически Sia требовала запуска клиента Sia (демона) на вашей машине, который открывает локальный API для загрузки и скачивания. Это было выполнимо, но не так удобно, как облачные API — разработчикам приходилось включать узел Sia в свой стек. Команда и сообщество Sia работали над улучшением удобства использования: например, Sia-UI — это десктопное приложение для ручной загрузки файлов, а библиотеки типа sia.js существуют для взаимодействия с локальным узлом. Однако более значительное улучшение DX произошло с появлением Skynet в 2020 году. Skynet позволил разработчикам использовать публичные веб-порталы (такие как siasky.net, skyportal.xyz и т. д.) для загрузки данных без запуска узла; эти порталы берут на себя взаимодействие с Sia и возвращают Skylink (хеш/ID контента), который можно использовать для извлечения файла с любого портала. Это сделало использование хранилища Sia таким же простым, как HTTP API — можно было отправить файл на портал Skynet через curl и получить ссылку. Кроме того, Skynet позволял размещать веб-приложения (аналогично пермавебу Arweave) — разработчики создавали такие dApps, как SkyID (децентрализованная идентификация), SkyFeed (социальная лента) и даже целые маркетплейсы приложений на Skynet. С точки зрения разработчика, появление Skynet означало, что вам не нужно беспокоиться о Siacoin, контрактах или запуске узлов; вы могли полагаться на поддерживаемые сообществом порталы (некоторые бесплатные, некоторые коммерческие), которые брали на себя тяжелую работу. Также существовали SDK (SkyNet JS и т. д.) для интеграции этого в веб-приложения. Проблема, однако, заключается в том, что основной спонсор Skynet (Skynet Labs) закрылся в 2022 году из-за проблем с финансированием, и сообщество вместе с Sia Foundation работают над тем, чтобы сохранить концепцию (открытие исходного кода порталов и т. д.). По состоянию на 2025 год опыт разработчиков Sia разделен: если вам нужна максимальная децентрализация, вы запускаете узел Sia и работаете с SC и контрактами — это мощно, но относительно низкоуровнево. Если вам нужна простота использования, вы можете использовать шлюзовой сервис, такой как Filebase, или порталы Skynet (если они доступны), чтобы абстрагироваться от этого. Filebase, к примеру, — это сервис, предоставляющий S3-совместимый API, но фактически хранящий данные в Sia (а теперь и в других сетях); таким образом, разработчик может использовать Filebase так же, как Storj или AWS, а под капотом он берет на себя механику Sia. Что касается документации, Sia улучшила ее, и у проекта есть активный канал сообщества. Они также предлагают рейтинг хостов (HostScore) и сетевую статистику (SiaStats/SiaGraph), чтобы разработчики могли оценивать состояние сети. Еще одна новая инициатива в Sia — проект S5, который нацелен на представление хранилища Sia способом с адресацией по контенту, подобно IPFS (также с совместимостью с S3) — это указывает на продолжающиеся усилия по оптимизации взаимодействия с разработчиками. В целом, DX Sia исторически отставал от некоторых других из-за необходимости работать с блокчейном и валютой, но со Skynet и сторонними интеграциями он стал проще. Разработчики, ценящие конфиденциальность и контроль, могут использовать Sia, приложив некоторые усилия, в то время как другие могут использовать сервисы поверх Sia для более гладкой работы.
• Опыт разработчиков Ceramic: Ceramic нацелен на разработчиков Web3 dApps, особенно тех, кто создает социальные функции, идентификаторы или динамический контент. Разработчики взаимодействуют с Ceramic, запуская узел Ceramic или используя хостинговый узел (предлагаемый 3Box Labs или провайдерами сообщества). Ключевой концепцией является «ComposeDB» — семантический уровень данных для Ceramic: разработчики могут определить модель данных (схему) для данных своего приложения (например, модель профиля с именем, аватаром и т. д.), а затем использовать запросы GraphQL для хранения и извлечения этих данных из Ceramic. По сути, работа с Ceramic напоминает использование базы данных, которая является глобальной и децентрализованной. Команда Ceramic предоставляет CLI и SDK для помощи в запуске приложений — например, glaze/JS для управления моделями данных и self.id (SDK для идентификации) для аутентификации пользователей с помощью их криптокошельков/DID для управления своими данными. Поскольку технология относительно новая, инструменты все еще развиваются, но есть солидная документация и растущий набор примеров приложений (для социальных сетей, блоговых платформ, хранения учетных данных и т. д.). Важной частью DX Ceramic является интеграция DID (децентрализованных идентификаторов): каждое обновление данных подписывается DID, часто с использованием IDX (Identity Index), который 3Box Labs создала для управления данными идентификации пользователей в потоках. Для разработчиков это означает, что вы часто подключаете библиотеку типа did-js для аутентификации пользователей (обычно через их кошелек Ethereum, который дает DID с использованием метода Ceramic did:3). После аутентификации вы можете читать/записывать данные этого пользователя в потоках Ceramic так же, как в любой базе данных. Порог вхождения здесь — понимание децентрализованной идентификации и концепции потоков (streams) в сравнении с таблицами. Тем не менее, те, кто знаком с веб-разработкой, обнаружат, что абстракции GraphQL в ComposeDB выглядят вполне естественно — вы можете запросить у Ceramic все посты в приложении для блогов, например, используя GraphQL-запрос, который узел Ceramic разрешает, просматривая соответствующие потоки. Документация Ceramic описывает «Как это работает» и подчеркивает, что она не предназначена для больших файлов — скорее, вы храните ссылки на IPFS или Arweave для тяжелого медиаконтента, а Ceramic используете для метаданных, индексов и пользовательского контента. На практике dApp может использовать Ceramic для таких вещей, как профили пользователей или комментарии (чтобы их можно было обновлять и использовать на разных платформах), а Filecoin/IPFS — для больших файлов, таких как изображения или видео. Сообщество вокруг Ceramic активно, проводятся хакатоны и выдаются гранты, а такие инструменты, как Orbis (децентрализованный протокол, похожий на Twitter, построенный на Ceramic), предоставляют SDK более высокого уровня для социальных функций. В итоге, Ceramic предлагает высокоуровневый, Web3-нативный DX: разработчики работают с DID, моделями и GraphQL, что сильно отличается от низкоуровневого управления хранилищем — это больше похоже на создание приложения на базе децентрализованного Firebase или MongoDB. Для тех сценариев использования, где требуются изменяемые, интероперабельные данные, опыт разработчика является передовым (хотя и несколько экспериментальным), а для других он может оказаться излишне сложным.

4. Метрики принятия пользователями и использования​

Оценка принятия децентрализованных хранилищ носит многогранный характер: мы учитываем объем хранимых данных, количество пользователей/разработчиков, значимые примеры использования или партнеров, а также долю рынка. Ниже приведены ключевые метрики принятия и примеры для каждой сети:

• Принятие Arweave: Сеть Arweave, запущенная в 2018 году, хранит меньший общий объем данных по сравнению с Filecoin, но заняла критически важную нишу в области перманентного хранения. По состоянию на начало 2023 года в пермавебе (permaweb) Arweave было сохранено около 140 ТБ данных. Хотя это на несколько порядков меньше, чем у Filecoin, Arweave подчеркивает, что за эти данные полностью заплачено и они сохраняются навечно. Темпы роста остаются стабильными — разработчики и архивные проекты вносят данные, варьирующиеся от веб-страниц (например, Arweave используется сообществом «архивистов» для архивирования веб-страниц, наподобие децентрализованной Wayback Machine) до истории блокчейнов (например, блокчейн Solana использует Arweave для выгрузки своих исторических данных). Значимой вехой в принятии стала интеграция Arweave компанией Meta (Facebook) в 2022 году для постоянного хранения NFT-медиафайлов Instagram, что сигнализирует о доверии гиганта Web2 к долговечности Arweave. (Хотя позже Meta приостановила инициативу с NFT, факт остается фактом — они выбрали Arweave для неизменяемого хранения). В мире блокчейна NFT-платформа Solana Metaplex использует Arweave для хранения метаданных и активов NFT — популярный стандарт Candy Machine от Solana автоматически загружает медиафайлы в Arweave для обеспечения их сохранности. Это привело к тому, что миллионы NFT ссылаются на URI Arweave (часто через arweave.net). Другой пример: KYVE, проект архивирования Web3, запустил свою основную сеть на Arweave и к концу 2023 года загрузил в Arweave более 2 000 ТБ (2 ПБ) данных — это огромный объем, включающий моментальные снимки других блокчейнов и наборов данных. Экосистема Arweave насчитывает сотни разработчиков; официальный сайт Ar.io отмечает эндаумент в размере более 44 000 AR, накопленный к январю 2023 года для поддержания хранилища. Что касается социальных метрик, сообщество Arweave сильно среди создателей NFT и энтузиастов архивирования — термин «permaweb» стал синонимом сохранения NFT-арта, веб-контента (например, mirror.xyz использует Arweave для постоянного хранения децентрализованных постов в блогах) и даже приложений на базе пермавеба (электронная почта, форумы). Arweave получила поддержку от крупных венчурных криптофондов, а ее основатель Сэм Уильямс является видным деятелем, выступающим за постоянство данных. Несмотря на то, что Arweave не так велика в сырых байтах, ее принятие является высокоэффективным: она используется везде, где требуется гарантированная долговечность. Она также косвенно интегрирована во многие стеки Web3 (например, аппаратный кошелек Ledger использует Arweave для хранения некоторых данных о происхождении NFT, а протокол индексации The Graph может использовать Arweave для хранения данных сабграфов). В целом, принятие Arweave сильно в пространстве NFT и метаданных блокчейнов, в постоянных веб-архивах и вызывает растущий интерес со стороны корпораций для ведения долгосрочных записей. Текущее использование сети (140+ ТБ) может показаться небольшим, но каждый байт предназначен для вечного хранения, и использование ускоряется.
• Принятие Pinata и IPFS: IPFS, пожалуй, является самой широко распространенной технологией децентрализованного хранения по чистому количеству пользователей, так как она бесплатна и открыта для всех. Трудно измерить объем «хранилища» IPFS, так как любой может запустить узел и добавить контент, но эта технология повсеместно распространена в мире Web3. Pinata, как один из ведущих сервисов пиннинга IPFS, дает представление об использовании IPFS разработчиками. Сайт Pinata заявляет: «Нам доверяют более 600 000 разработчиков» — это огромное число, отражающее ее популярность, вероятно, подстегнутую бумом NFT в 2021 году, когда многие проекты использовали Pinata для хостинга NFT-активов. От независимых художников, использующих бесплатный уровень Pinata, до крупных NFT-маркетплейсов, интегрирующих Pinata для доставки контента, сервис стал отраслевым стандартом. Команда NFT.Storage отметила в 2023 году, что «Pinata является доверенным именем в сообществе IPFS с 2018 года, обеспечивая работу многих топовых проектов и маркетплейсов». Сюда входят известные NFT-платформы, разработчики игр и даже некоторые DeFi-проекты, которым требовалось предоставлять фронтенд-активы через IPFS. Например, OpenSea (крупнейший NFT-маркетплейс) использует IPFS для многих хранимых активов и иногда рекомендует создателям NFT использовать сервисы пиннинга, такие как Pinata, для обеспечения доступности их контента. Многие коллекции NFT с профильными изображениями (от производных CryptoPunks до бесчисленных генеративных наборов на Ethereum) используют CID-идентификаторы IPFS для изображений, и в метаданных токенов часто встречаются URL-адреса шлюзов Pinata. Pinata не публиковала статистику по общему объему закрепленных данных, но, по неофициальным данным, она отвечает за пиннинг петабайт данных NFT. Другое измерение: IPFS интегрирована в веб-браузеры (Brave, Opera) и имеет глобальную одноранговую сеть; роль Pinata в этом заключается в том, что она является надежной основой для хостинга контента. Поскольку IPFS бесплатна для самостоятельного использования, большое количество пользователей Pinata указывает на то, что многие разработчики предпочитают удобство и производительность, которые она добавляет. У Pinata также есть корпоративные пользователи в сфере медиа и развлечений (например, некоторые музыкальные NFT-платформы использовали Pinata для управления аудиоконтентом). Стоит отметить, что принятие IPFS выходит за рамки Pinata: конкуренты, такие как сервис IPFS от Infura, шлюз IPFS от Cloudflare и другие (Temporal, Crust и т. д.), также вносят свой вклад, но Pinata является одной из самых заметных. В итоге, IPFS вездесуща в Web3, и принятие Pinata отражает эту вездесущность — это основа для контента NFT и dApp с сотнями тысяч пользователей и интеграцией в рабочие приложения по всему миру.
• Принятие Filecoin: Filecoin продемонстрировала наибольший рост с точки зрения чистого объема хранилища. Сообщается, что ее сеть располагает 22 экзабайтами (22 000 000+ ТБ) доступного хранилища, из которых к середине 2023 года было использовано около 3% (660+ ПБ). (Для сравнения: этот объем используемого хранилища на три порядка превышает объем Arweave, что подчеркивает ориентацию Filecoin на большие данные). Большая часть этой емкости поступает от крупномасштабных майнеров; однако объем полезных хранимых данных также значительно вырос благодаря таким программам, как Filecoin Plus. К началу 2022 года было сохранено 45 ПиБ (~45 000 ТБ) реальных данных, и с тех пор этот показатель, вероятно, значительно вырос по мере того, как крупные архивы загружали свои данные. Что касается пользователей, принятие Filecoin поддерживается проектами экосистемы: например, в NFT.storage (который использует Filecoin «под капотом») по состоянию на 2023 год загружено более 150 миллионов NFT-активов. Многие NFT-маркетплейсы полагаются на NFT.storage или аналогичные сервисы, что косвенно делает Filecoin бэкендом для этих NFT. Web3.storage (общее хранилище IPFS/Filecoin для приложений) имеет десятки тысяч пользователей и хранит данные для таких приложений, как игры Web3 и контент метавселенных. Примечательно, что Filecoin привлекла корпоративных и институциональных партнеров: она сотрудничает с Калифорнийским университетом в Беркли для хранения исследовательских данных, с правительством Нью-Йорка для сохранения открытых наборов данных, а также с такими компаниями, как Seagate (производитель жестких дисков, изучающий Filecoin для корпоративных решений по резервному копированию) и Ernst & Young (EY) для децентрализованного хранения в бизнес-кейсах. OpenSea также стала клиентом Filecoin, используя ее для резервного копирования данных NFT. Эти высокопрофильные клиенты демонстрируют доверие к модели Filecoin. Более того, по количеству проектов: к концу 2022 года на базе Filecoin/IPFS было создано более 600 проектов и dApp, включая всё — от видеоплатформ (например, VideoCoin, Huddle01) до архивов данных оракулов DeFi и репозиториев научных данных (архивы Холокоста фонда Shoah через проект Starling). Блокчейн Filecoin имеет широкое сообщество из более чем 3 900 поставщиков хранилищ по всему миру, что делает его одной из самых децентрализованных инфраструктур с точки зрения географии. Однако принятие Filecoin пользователями иногда сдерживается сложностью системы; многие пользователи взаимодействуют с ней через более простой уровень IPFS. Тем не менее, с появлением FVM и стремлением сделать Filecoin полноценной облачной платформой (хранение + вычисления), интерес со стороны разработчиков и предприятий ускоряется. В итоге, Filecoin лидирует по емкости и взаимодействию с корпорациями: это самая крупная децентрализованная сеть хранения с точки зрения масштаба, и хотя большая часть этой емкости пока недоиспользуется, существуют инициативы по ее заполнению ценным контентом (открытые научные данные, архивы Web2, данные приложений Web3). Ее доказанная способность справляться с экзабайтными масштабами делает ее сильным претендентом на замену традиционных облачных хранилищ, если спрос возрастет.
• Принятие Storj: Storj стабильно растет, ориентируясь на гибридные сценарии использования Web2/Web3 (особенно медиа). Сеть состоит примерно из 13 000+ узлов хранения (отдельных операторов, запускающих программное обеспечение Storj дома или в центрах обработки данных) в более чем 100 странах, что обеспечивает сильную децентрализацию. Со стороны клиентов Storj заключила корпоративные партнерства в сфере медиа и ИТ: например, Videon LivePeer (видеостриминг) использует Storj для распределения сегментов живого видео по всему миру, Fastly Compute@Edge стала партнером Storj для хранения активов, и, как указано на их сайте, Storj доверяют такие организации, как Cloudwave, Caltech, TrueNAS, Vivint и несколько студий медиапроизводства. Присутствие Caltech (ведущего исследовательского университета) предполагает использование в хранении научных данных, а Vivint (компания в сфере умного дома) подразумевает хранение данных Интернета вещей (IoT) или записей с камер — разнообразные реальные применения. Storj получила отраслевое признание, например, звание «Продукт года 2025» на NAB (Национальная ассоциация вещателей) за свое решение для рабочих процессов в медиа. Они выделяют тематические исследования: например, Inovo, экономично транслирующая видео миллионам пользователей, Treatment Studios, использующая Storj для глобальной совместной работы над видео, и Ammo Content, транслирующая более 30 миллионов часов контента через сеть Storj. Эти примеры показывают, что Storj способна справляться с высокой пропускной способностью и большими объемами доставки контента — это критически важное доказательство. Принятие разработчиками также значительно: более 20 000+ разработчиков имели учетные записи в Storj DCS к 2022 году (согласно статистическому отчету Storj). Сообщество открытого исходного кода внедрило Storj во многие интеграции (как уже упоминалось, FileZilla, ownCloud, Zenko и т. д.). Интерес операторов узлов высок, так как Storj выплачивает вознаграждения в токенах; время от времени возникали очереди на то, чтобы стать оператором узла из-за высокого спроса. Что касается объема хранимых данных, Storj в последнее время публично не объявляла общий объем ПБ, но известно, что он составляет несколько петабайт и быстро растет, особенно с учетом недавних усилий в пространстве Web3. Она может не соперничать с Filecoin по «сырым» цифрам (потому что Storj фокусируется на активных данных, а не просто на емкости), но, вероятно, является крупнейшей сетью зашифрованного облачного хранения по количеству данных. Мультирегиональная производительность Storj, напоминающая CDN, привлекла пользователей Web2 исключительно благодаря преимуществам в соотношении цена-качество (некоторых даже не волнует децентрализация, им просто нравится экономия в 80%). Этот «троянский конь» в традиционные отрасли означает, что принятие может расти за пределами типичных крипто-кругов. В целом, принятие Storj сильно в сфере медиастриминга, резервного копирования и инструментов для разработчиков. Это доказывает, что децентрализованный сервис может соответствовать корпоративным SLA (что отражено в их отказоустойчивости 11 девяток и партнерстве с такими фирмами, как Evergreen для решений по резервному копированию). Благодаря повороту в сторону предложения децентрализованных облачных GPU, Storj позиционирует себя как более широкий провайдер децентрализованных облачных услуг, что может еще больше подстегнуть принятие.
• Принятие Sia: Sia — один из старейших проектов в этом списке (запущен в 2015 году), но траектория его принятия была более скромной. По состоянию на 3 квартал 2024 года в сети Sia хранилось 2 310 ТБ (2,31 ПБ) данных, что составило ~17% квартального роста, указывая на стабильное увеличение использования, хотя и с меньшей базы. Коэффициент использования Sia относительно емкости также улучшился, что говорит о том, что хосты получают больше заказов. Исторически сеть Sia имела много индивидуальных пользователей, использующих ее для личного резервного копирования из-за низкой стоимости — технически подкованные пользователи хранили там коллекции фотографий или использовали Sia как более дешевую альтернативу «Backblaze». Со стороны корпораций Sia не видела такого уровня публичных партнерств, как Filecoin или Storj. Отчасти это связано с UX на ранних этапах и тем фактом, что материнская компания Sia, Nebulous, переключилась на Skynet (который был нацелен на dApp в Web3 и хостинг контента). Принятие Skynet было многообещающим в 2020–2021 годах: на нем работала экосистема социальных сетей Web3 (например, у SkyFeed были тысячи пользователей), и даже некоторые NFT-проекты использовали Skynet для размещения произведений искусства (ссылки Skylinks появляются в некоторых метаданных NFT как альтернатива IPFS). Audius, децентрализованная музыкальная платформа, экспериментировала со Skynet для доставки некоторого контента. Однако закрытие основного портала Skynet передало часть этого импульса в руки сообщества. Фонд Sia (основанный в 2021 году) теперь руководит разработкой, и они представили Sia v2 (хардфорк в 2025 году) с улучшениями в производительности и, возможно, экономике, что может подстегнуть принятие в будущем. Экосистема меньше: статистика Sia показывает 32 проекта, построенных на Sia (не считая пользовательских приложений), и в общей сложности 3,2 миллиона долларов в виде грантов, выделенных к 2025 году для стимулирования роста. Сюда входят такие проекты, как Filebase (использующий Sia как один из бэкендов), SiaStream (для хранения медиастриминга на Sia) и инструменты сообщества, такие как HostScore и SiaFS. Сообщество Sia, хотя и небольшое, очень активно — например, была проведена заметная операция силами пользователей по хранению публичных данных Библиотеки Конгресса на Sia. Количество хостов в Sia исчисляется сотнями (а не тысячами, как в Storj), и многие из них предоставляют установки корпоративного уровня (узлы в дата-центрах), так как прибыльность хостинга невелика, если у вас нет очень дешевого хранилища. В итоге, принятие Sia является нишевым, но стабильным: она используется основным сообществом для недорогого облачного хранения и некоторыми Web3-проектами для хостинга децентрализованного веб-контента. Ее использование (2+ ПБ данных) не является тривиальным, но значительно отстает от Filecoin; однако Sia выделяется тем, что является некоммерческой и управляемой сообществом, что находит отклик у тех, кто ставит в приоритет этику децентрализации. Текущие улучшения (Sia v2) и фокус на звании «самого безопасного облака в мире» могут привлечь больше пользователей, обеспокоенных суверенитетом данных.
• Принятие Ceramic: Поскольку Ceramic является специализированной сетью для данных и компонуемого контента, ее принятие измеряется количеством разработчиков и приложений, а не чистым объемом хранилища. Согласно веб-сайту Ceramic (2025), на базе Ceramic построено более 400 приложений и сервисов, управляющих примерно 10 миллионами потоков контента. Это указывает на растущий интерес к децентрализованным данным среди разработчиков приложений Web3. Среди заметных проектов, использующих Ceramic, можно назвать Orbis (децентрализованный протокол социальных сетей, аналог Twitter на Ceramic), CyberConnect (протокол социального графа, изначально построенный на Ceramic DID), Gitcoin (который изучал Ceramic для децентрализованных профилей пользователей) и Self.ID (идентификационный хаб для управления профилями пользователей в разных dApp). Кроме того, принятие DID через Ceramic 3ID было значительным — например, многие приложения на базе Ethereum использовали Ceramic для хранения профилей пользователей (так что ваш профиль мог переноситься, скажем, между Uniswap, Boardroom и Snapshot для DAO). Были и партнерства, такие как интеграция Ceramic в NEAR Protocol для кросс-чейн идентификации, что показывает, что блокчейны первого уровня (Layer-1) видят в Ceramic решение для внесетевых (off-chain) пользовательских данных. Другая область — DeSci (децентрализованная наука): проекты используют Ceramic для хранения метаданных исследований, лабораторных заметок и т. д., где данными нужно делиться и верифицировать их, но они не являются неизменяемыми (требуются обновления). Тот факт, что 3Box Labs (команда-основатель Ceramic) недавно объединилась с Textile (командой, известной инструментами для IPFS/Filecoin), также показателен — это говорит о стремлении объединить усилия и, возможно, расширить охват Ceramic в сфере инфраструктуры данных. Количество активных узлов Ceramic не является публичным, но многие приложения запускают свои собственные или используют узлы сообщества. В целом, Ceramic — проект более новый, и его концепция «dataverse» всё еще приживается; у него пока нет широко известных корпоративных пользователей, но наблюдается низовое принятие в Web3 в тех областях, которые существующие сети хранения обслуживают плохо (например, контент социальных сетей и функциональная совместимость данных между приложениями). В качестве ориентира: если рассматривать каждый поток как единицу данных, то 10 миллионов потоков — это существенно, хотя многие потоки крошечные (например, документ профиля пользователя или один пост). Метрика, за которой стоит следить, — это то, сколько конечных пользователей принесут эти 400 приложений; потенциально это сотни тысяч, если приложения вроде децентрализованных соцсетей масштабируются. В итоге, принятие Ceramic является многообещающим в сообществе разработчиков Web3 (сотни приложений, интеграция в различные экосистемы Web3), но оно по своей природе ограничено специфическими случаями использования и не конкурирует по размеру хранилища или пропускной способности с такими гигантами, как Filecoin или Arweave.

Для визуализации принятия в таблице ниже выделены некоторые метрики и известные участники:

5. Зрелость и активность экосистемы​

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

• Экосистема Arweave: Экосистема Arweave весьма надежна для своего масштаба. Со стороны инфраструктуры ряд проектов расширяет функциональность Arweave: Bundlr (Iris), как уже упоминалось, управляет сетью узлов бандлинга и привлек собственные средства для масштабирования пропускной способности Arweave (обработав более 1 миллиарда пакетных транзакций к концу 2023 года). ArDrive — популярное пользовательское приложение, предлагающее опыт в стиле Dropbox на базе Arweave; в 2023 году оно стало полностью децентрализованным и запустило версию 2.0 с такими функциями, как поддержка больших файлов. EverPay и Warp обеспечивают мгновенные транзакции в стиле второго уровня (layer-2) и функциональность, подобную смарт-контрактам, на Arweave, используя пермавеб в качестве базового слоя (сама Arweave не поддерживает традиционные смарт-контракты, но эти проекты хранят состояния контрактов и позволяют взаимодействовать с ними). В 2024 году Arweave представила «Atomic Oasis (AO) Compute» — сеть вычислений над данными (compute-over-data), которая работает поверх Arweave, обеспечивая параллельные ончейн-вычисления при использовании Arweave для обеспечения доступности данных. Это фактически переводит Arweave в сферу предоставления облачных вычислений (аналогично тому, как Filecoin добавляет вычисления с помощью FVM) и указывает на перспективный план развития. В плане финансирования Arweave имеет сильную поддержку: она привлекла 37,3 млн $ от a16z, Union Square Ventures и других, что обеспечивает ресурсы для дальнейшей разработки. Сообщество вовлечено через систему токенов распределения прибыли (PST) — разработчики могут создавать PST для своих приложений в пермавебе, которые дают владельцам право на долю комиссионных сборов, что стимулирует разработку приложений. Запущено множество приложений для пермавеба: от Decent.land (децентрализованные социальные профили на Arweave) до CommunityXYZ (платформа DAO для PST на Arweave). Arweave также имеет похожее на DAO управление своим фондом (endowment), вовлекая сообщество в процесс принятия решений. Сеть успешно прошла основные обновления (например, обновление консенсуса SPoRA в 2022 году). Что касается интеграции, Arweave была интегрирована с другими блокчейнами: смарт-контракты на Ethereum, Polkadot, Avalanche использовали Arweave для хранения больших данных или метаданных (часто через мост Arweave ↔ Ethereum и через индексацию The Graph). Lens Protocol (Web3 социальная сеть на Polygon) предлагает Arweave в качестве опции для постоянного хранения постов. Сотрудничество Arweave с Solana является глубоким: по сути, это архивный уровень Solana, а с выходом нового телефона Solana (Saga) упоминалось об использовании Arweave для постоянного хранения контента мобильных dApps. В целом, экосистема Arweave активна и растет, имея специализированные приложения для хранения, кроссчейн-интеграции и даже исследуя новые вертикали, такие как вычисления. Культура сообщества сосредоточена на миссии «пермавеба», о чем свидетельствуют такие инициативы, как Arweave Boost (программа, субсидирующая расходы на хранение ценных наборов данных) и партнерства по сохранению культурных данных (например, архивы документов о войне в Украине были сохранены на Arweave активистами). Все эти признаки указывают на зрелую, ориентированную на миссию экосистему, хотя и меньшую по размеру, чем у Filecoin.
• Экосистема Pinata/IPFS: Pinata сама по себе является продуктом одной компании, но она находится в рамках более широкой экосистемы IPFS, которая весьма обширна. Активность экосистемы Pinata включает партнерства (как в случае с NFT.storage — у них есть реферальное соглашение, поддерживающее миссию NFT.storage) и интеграции в платформы для авторов (например, некоторые платформы для минтинга NFT имеют встроенную загрузку в Pinata для удобства пользователей). Pinata расширила функциональность своих продуктов (хранилище KV, приватный IPFS, плагины для шлюзов и т. д.), что указывает на стремление предоставлять больше, чем базовый пиннинг. Между тем, IPFS в целом имеет огромное сообщество разработчиков открытого ПО: процветают такие проекты, как IPFS-Cluster (для оркестрации собственной сети пиннинга), Textile (создавший ThreadsDB и другие инструменты на IPFS), Fleek (предоставляющий хостинг на IPFS для веб-приложений) и многие другие. Экосистема Protocol Labs, к которой принадлежит IPFS, также включает libp2p (сетевой уровень) и Filecoin — разработки в этих областях часто приносят пользу IPFS (например, кэширование извлечения IPFS через Filecoin Saturn — новая инициатива). Зрелость технологии такова, что IPFS находится в версии 0.15+ и прошла проверку в реальных условиях. Появляется корпоративное использование IPFS за пределами криптосферы: например, НФЛ (американская футбольная лига) использовала IPFS для распространения видеохайлайтов среди болельщиков (для снижения затрат на пропускную способность). Шлюз IPFS от Cloudflare демонстрирует интерес игроков Web2 к интеграции с IPFS. Регулярно выпускаются даже RFC по IPFS и академические исследования, что подтверждает статус устоявшегося протокола. В плане поддержки существует бесчисленное множество библиотек (реализации IPFS на Go, JS, Python, Rust). IPFS, по сути, является стандартом de facto для контентной адресации на сегодняшний день. Pinata извлекает выгоду из этой зрелости, предлагая удобный для пользователя слой. Одной из проблем исторически была обнаруживаемость в IPFS (контентная адресация не обеспечивает поиск) — были созданы инструменты экосистемы, такие как поисковые системы IPFS и индексы сервисов пиннинга, и Pinata, вероятно, участвует в этих сетях (они могут делиться данными о пинах, если пользователи согласны, для обеспечения долговечности). Переход Pinata к поддержке именно NFT (с выделенными руководствами и кейсами для разработчиков NFT) демонстрирует адаптацию к потребностям пользователей. Они также активно участвуют в мероприятиях сообщества (спонсирование хакатонов и т. д.). Итог: экосистема IPFS очень зрелая (более 8 лет, широкое внедрение), а Pinata является ключевым коммерческим игроком в этом пространстве, хорошо интегрированным с другими. Собственная экосистема Pinata больше ориентирована на ее клиентскую базу (разработчиков и авторов), которая велика и растет, а не на сторонних разработчиков, строящих на базе Pinata (поскольку это не открытый исходный код). Но учитывая открытость IPFS, затраты на переход невелики — Pinata остается конкурентоспособной, предлагая надежность и простоту. В этой конкурентной среде присутствуют Infura, web3.storage и др., что стимулирует непрерывное совершенствование. Таким образом, IPFS настолько зрела, насколько это возможно для децентрализованного хранения, а Pinata надстраивается над ней, фокусируясь на пользовательском опыте разработчиков и добавляя функции, чтобы оставаться востребованным сервисом в процветающей интероперабельной экосистеме.
• Экосистема Filecoin: Экосистема Filecoin, пожалуй, самая активная и хорошо финансируемая в сфере децентрализованного хранения. С момента запуска Protocol Labs и Filecoin Foundation организовали многочисленные хакатоны (HackFS, Space Race и др.) и акселерационные программы (например, Filecoin Launchpad совместно с Tachyon) для поддержки стартапов. К 2022 году, как было отмечено, на базе Filecoin строилось более 330 проектов, а к 2025 году это число стало еще выше, особенно благодаря FVM, позволяющей использовать DeFi и новые примитивы в Filecoin. Значительным событием стал запуск Виртуальной машины Filecoin (FVM) в 2023 году, которая привнесла общую программируемость (смарт-контракты) в Filecoin. Это породило такие проекты, как Filecoin DeFi (маркетплейсы для сделок по хранению, токенизированное хранилище и т. д.), DAO данных (децентрализованные организации, объединяющие средства для оплаты хранения ценных данных) и кроссчейн-мосты для использования хранилища Filecoin в dApps на Ethereum. Кроме того, создаются рынки извлечения (такие как Lighthouse и др.), чтобы контент, хранящийся на Filecoin, мог эффективно доставляться стимулируемыми узлами (дополняя IPFS). Что касается корпоративного сектора, как уже упоминалось, партнерство Filecoin с крупными компаниями (Seagate и др.) подразумевает развитие экосистемы инструментов для предприятий — например, ведутся разговоры об интеграции Filecoin с облаком IBM или другими поставщиками хранилищ для гибридных решений. Управление и сообщество Filecoin также примечательны: существует Filecoin DAO (предложения по управлению), а Filecoin Plus управляется выбранными сообществом нотариурами, которые верифицируют реальные данные — уникальная для этого пространства система социального доверия, демонстрирующая зрелый процесс управления. Токеномика сети, хотя и сложна, стабильно поддерживается участием тысяч майнеров, что указывает на здоровое предложение. Еще одним компонентом экосистемы являются L2-решения на Filecoin: такие проекты, как Polybase или Tableland (децентрализованные базы данных), рассматривают возможность использования Filecoin для обеспечения доступности данных, а Estuary предоставляет API поверх Filecoin для упрощения хранения. Существуют даже сайдчейны Filecoin (один из них под названием Filecoin Saturn фокусируется на доставке контента, используя Filecoin в качестве оплаты). Исследовательская группа Protocol Labs продолжает активно совершенствовать технологию (например, повышая производительность доказательств, изучая новые схемы кодирования для долговечности). Мероприятия сообщества, такие как встречи Filecoin Orbit и ежегодный саммит Sustainable Blockchain Summit (который часто подчеркивает роль Filecoin в открытых данных и устойчивом развитии), еще больше укрепляют динамичность экосистемы. С точки зрения финансирования, помимо ICO, в 2022 году был запущен огромный Фонд экосистемы Filecoin (100 млн $ +) для инвестирования в проекты, строящиеся на базе Filecoin. Заметные инвестиции получили такие компании, как ChainSafe (создание инструментов для Filecoin), Open Forest Protocol (использование Filecoin для хранения климатических данных) и др. Резюмируя, экосистема Filecoin велика, хорошо капитализирована и быстро развивается — она стала чем-то большим, чем просто хранилищем, стремясь стать полноценным децентрализованным облаком (хранение, извлечение, вычисления, возможно, даже базы данных). Такая широта является признаком зрелости, но также означает, что ей приходится бороться на нескольких фронтах (конкурируя со специализированными сетями в каждой области). Однако синергия с IPFS и поддержка Protocol Labs обеспечивают мощный импульс.
• Экосистема Storj: Экосистема Storj, хотя и не так «популярна в Web3», как Filecoin, весьма зрела с точки зрения интеграции и готовности к корпоративному использованию. Со стороны предложения Storj имеет стабильную базу операторов узлов благодаря последовательным выплатам в токенах. Программное обеспечение узлов (сейчас в третьей основной версии) хорошо документировано, а у операторов есть инструменты сообщества (например, дашборды Grafana и др.) для мониторинга своих узлов. Storj Labs также творчески подходит к стимулированию внедрения: они предложили бесплатное хранилище для проектов с открытым исходным кодом, поощряя сообщества пробовать Storj для таких задач, как хостинг бинарных файлов релизов или наборов данных. Со стороны спроса фокус Storj на рабочих процессах с медиа и большими данными привел к интеграциям: например, Iconik (ПО для управления медиа-активами) поддерживает Storj в качестве бэкенда, альтернатива Gsuite Skiff Mail/Drive использует Storj для хранения зашифрованных вложений электронной почты и файлов, а партнерство с ownCloud позволяет предприятиям подключать Storj без изменения своих рабочих процессов. Экосистема библиотек с открытым исходным кодом растет: например, проект Terrarium от Fastly использует Storj для пограничного кэширования. Storj также делает упор на разработчиков сообщества: у них есть активный форум, где сторонние разработчики делятся проектами (например, плагин для WordPress для выгрузки медиа в Storj, интеграция резервного копирования Veeam и т. д.). Одним из признаков зрелости являются сторонние сервисы поверх Storj: например, Filebase не только использует Sia, но и добавил Storj в качестве бэкенда в 2021 году — это означает, что пользователи Filebase могут выбирать Storj через тот же интерфейс S3. Это показывает, что Storj стабилен и достаточно привлекателен, чтобы быть включенным в сервис хранения с несколькими бэкендами. Токен Storj, хотя и используется для выплат, в значительной степени абстрагирован для клиентов, что может ограничивать компонуемость в стиле DeFi, но увеличивает традиционное внедрение. В 2022–2023 годах Storj перепозиционировала себя не просто как хранилище, а как часть платформы распределенного облака, запустив Storj Next с планами на вычисления и базы данных. Действительно, их продукт Cloud GPUs (находящийся в бета-версии по состоянию на 2025 год) расширяет экосистему до граничных вычислений — аренды GPU у децентрализованных провайдеров. В случае успеха это создаст мини-экосистему провайдеров и пользователей GPU под эгидой Storj, еще больше укрепляя их платформу. Сама Storj Labs остается основным управителем сети (несколько более централизованное управление по сравнению с Filecoin или Sia, у которых есть отдельные фонды), но они сделали код открытым и приветствуют вклад сообщества. Они также прошли сторонние аудиты (безопасность, соответствие таким стандартам, как SOC2), что важно для доверия корпораций. В итоге, экосистема Storj зрела в плане интеграций и корпоративных функций, хотя и меньше представлена в среде чистого сообщества разработчиков Web3. Она занимает нишу, где децентрализованные технологии продаются за их преимущества (стоимость, безопасность), а не за идеологию, что может оказаться устойчивым подходом.
• Экосистема Sia: Экосистема Sia переживала как взлеты, так и падения. После закрытия Skynet Labs управление взял на себя фонд Sia Foundation и с тех пор реализует дорожную карту Sia v2 (кодовое название хардфорка часто — «Nebulous»). Они провели ребрендинг некоторых компонентов (код портала Skynet перерабатывается в Sia v2, который объединит протокол «арендатор-хост» с улучшенной производительностью и, возможно, встроенной функциональностью портала). Текущая экосистема включает центральные приложения Sia, такие как Sia-UI и ПО для хостов, а также общественные проекты, такие как HostScore (бенчмаркинг хостов) и SiaStats/SiaGraph (сайты со статистикой сети). Грантовая программа, запущенная Sia Foundation (с выделенными 3,2 млн $ к 2025 году), стимулирует создание новых инструментов: например, SiaFS (файловая система FUSE для Sia), Décentral (децентрализованные фронтенды на Sia) и S5 (слой с контентной адресацией на Sia, имитирующий функциональность IPFS). Это указывает на признание того, в чем Sia нужно было догнать конкурентов (например, упрощение ссылок на контент и его совместного использования). Сообщество, хотя и меньше, остается преданным — сабреддит r/siacoin активен, и многие давние пользователи придерживаются Sia по идеологическим соображениям (истинная децентрализация, отсутствие сильного влияния венчурного капитала и т. д.). Токеномика Sia (с Siafunds) остается стабильной; Siafunds даже торгуются как своего рода токены, «приносящие дивиденды» от контрактов — уникальный аспект финансовой модели экосистемы Sia. Конкуренция внутри экосистемы: несколько компаний, созданных на базе Sia, таких как дочерние компании Skynet, не выжили, что замедлило рост экосистемы. Но появляются новые: например, Cloudless — недавний стартап, создающий удобное приложение для хранения в Sia; PixelSlime использует Sia для хранения игровых активов NFT и т. д. Интеграция с Filebase (мультисетевая) означает, что Sia косвенно является частью более широкой экосистемы. Sia Foundation публикует ежемесячные отчеты «State of Sia», что повышает прозрачность и способствует доверию к прогрессу разработки — здоровый признак вовлеченности сообщества. Одной из проблем является то, что Sia не достигла такой популярности в Web3, как IPFS или Filecoin — некоторые разработчики, нуждающиеся в децентрализованном хранилище, не рассматривают Sia просто потому, что о ней меньше говорят. Однако те, кто ее использует, часто хвалят ее надежность и низкую стоимость, что предполагает потенциал для роста за счет «сарафанного радио», если барьеры для разработчиков (DX) будут снижены. Итог: экосистема Sia находится в фазе восстановления и роста под руководством Фонда. Она меньше и более низовая по сравнению с другими, но обладает долгой историей и некоторыми отличительными особенностями (такими как отсутствие зависимости от других протоколов, альтруистический этос). Следующий год или два (с запуском Sia v2) будут критически важными, чтобы увидеть, ускорится ли ее развитие.
• Экосистема Ceramic: Ceramic, будучи относительно новой сетью (запущена около 2021 года), продемонстрировала хорошую динамику экосистемы среди создателей децентрализованных приложений. 3Box Labs обеспечила значительное финансирование (от таких фирм, как Coinbase Ventures, Multicoin и др.) для разработки Ceramic и ее инструментов. Экосистема включает саму Сеть Ceramic плюс ComposeDB в качестве флагманского продукта для разработчиков. Они развивают сообщество через Discord и регулярные звонки разработчиков. Одним из интересных аспектов являются стандарты компонуемости данных: у Ceramic есть «маркетплейс моделей данных», где разработчики могут публиковать и повторно использовать схемы друг друга (например, модель профиля, модель поста в блоге), что способствует формированию экосистемы интероперабельных данных. Это уникальный подход — он побуждает приложения строиться на общих структурах данных (подобно тому, как многие dApps используют стандарт токенов ERC-20, приложения Ceramic могут использовать общую модель «SocialPost» или «Profile»). Это означает, что по мере того, как все больше приложений принимают эти модели, профиль или контент пользователя могут быть перенесены в множество сервисов (настоящий сетевой эффект Web3). Экосистема также взаимодействует с другими сетями: например, Ceramic по умолчанию использует Ethereum для анкоринга (закрепления), поэтому улучшения в Ethereum L1 или L2 (у них есть планы использовать решения для масштабирования для более дешевого анкоринга) приносят прямую пользу Ceramic. Они также интегрировали Chainlink (для временных меток в нескольких сетях) и IDX, который может связывать идентификаторы Ceramic с адресами блокчейна. Еще одна синергия наблюдается с кошельками: поскольку аутентификация пользователей Ceramic часто происходит через криптокошельки, поставщики кошельков в некотором смысле являются партнерами. Например, MetaMask Snaps со временем могут включать интеграцию с Ceramic для управления пользовательскими данными, а идентификационные кошельки, такие как Spruce или IDen3, могут стать мостом к идентификации в Ceramic. Слияние с Textile (присоединение к «семье Textile») предполагает согласованность с другими проектами по работе с данными и хранением (Textile изначально строился на IPFS/Filecoin; их концепция Threads DB дополняет потоки Ceramic). Это может привести к новым гибридным решениям (например, бесшовное использование IPFS для контента и Ceramic для метаданных). Что касается проектов сообщества, мы видим победителей хакатонов, использующих Ceramic для таких вещей, как продажа билетов в виде NFT (хранение метаданных билетов, которые обновляются в Ceramic) или профили участников DAO. Основная сеть Ceramic еще молода, но у нее уже есть несколько провайдеров шлюзов (подобно Infura для Ethereum, существуют хостинговые узлы Ceramic, которые можно использовать) — включая один от 3Box и другие от сообщества, — что показывает, что вопрос децентрализации доступа решается. Дорожная карта включает такие функции, как «анкоринг Ceramic в нескольких сетях», «легкие узлы» для более простого участия и т. д., что является признаками зрелости технологии. Подводя итог, экосистема Ceramic динамична и ориентирована на разработчиков, с акцентом на интероперабельность и интеграцию с более широким стеком Web3. Это не экосистема хранения общего назначения, а скорее экосистема компонуемых данных, чего она, по-видимому, и достигает при участии сотен разработчиков и этике сотрудничества (маркетплейс моделей данных). Ее успех будет зависеть от того, привлекут ли эти 400 приложений крупные пользовательские базы, но инфраструктурный фундамент и почва для сообщества активно закладываются.

6. Сравнение цен​

7. Сценарии использования и приложения​

Децентрализованные сети хранения данных могут обслуживать самые разные сценарии использования, каждый из которых имеет свои требования (постоянство, изменяемость, скорость и т. д.). Ниже мы рассмотрим некоторые основные варианты использования и то, как каждый из обсуждаемых провайдеров в них вписывается:

a. Метаданные NFT и хостинг медиафайлов: Пожалуй, «хитовым приложением» (killer app) 2021 года для децентрализованного хранения стали NFT. NFT в таких сетях, как Ethereum и Solana, обычно хранят ончейн только ID токена, в то время как метаданные JSON (содержащие атрибуты, название, описание) и медиафайл (изображение, видео, аудио) хранятся вне сети (off-chain). Децентрализованное хранение здесь критически важно, чтобы NFT не ссылались на исчезающие ссылки.

• IPFS + Pinata стали стандартом для большинства NFT на Ethereum — создатели загружают свои медиафайлы в IPFS и используют хеш (CID) в URI токена. Pinata часто используется для того, чтобы контент был постоянно закреплен (pinned) и быстро доступен через шлюзы IPFS. Таким образом, даже если создатель исчезнет, контент NFT может быть получен любым пользователем по CID. Например, известные коллекции, такие как Bored Ape Yacht Club, использовали IPFS для изображений. Роль Pinata заключалась в том, чтобы десятки тысяч изображений были надежно доступны без необходимости запуска создателями собственной инфраструктуры IPFS. Маркетплейсы (OpenSea и др.) извлекают метаданные по этим ссылкам IPFS для отображения NFT. Преимущество: контентная адресация повышает доверие (покупатели могут проверить, что хеш актива соответствует тому, что выставлено на продажу) и устойчивость к цензуре (нет единого сервера, на котором хранятся изображения). Проблема: если никто не закрепляет (pin) данные, они все равно могут исчезнуть — поэтому на помощь пришли такие сервисы, как Pinata или NFT.storage, для поддержания доступности.
• Arweave зарекомендовал себя как мощное решение для постоянного хранения NFT. Проекты, которые хотели гарантировать, что активы NFT будут жить вечно, выбрали Arweave, несмотря на более высокую стоимость. Экосистема NFT на Solana — яркий пример: Candy Machine (программа минтинга) напрямую интегрируется с Arweave для загрузки медиа и метаданных, возвращая URL с TXID Arweave (часто через прокси arweave.net) для URI токена NFT. Это означает, что после минтинга JSON и изображение NFT навсегда остаются в пермавебе Arweave (оплачено минтером). MetaPlex на Solana утверждает, что такой дизайн гарантирует коллекционерам, что их NFT-арт не исчезнет и не изменится. Даже на Ethereum некоторые проекты использовали Arweave для ценных арт-объектов или генеративных произведений (например, Async Art хранил компоненты программируемого искусства на Arweave). Кроме того, возможность пакетной загрузки Arweave позволила эффективно хранить тысячи изображений для NFT-дропов.
• Filecoin (через NFT.storage) также стал популярным бэкендом для NFT, особенно после середины 2021 года, когда NFT.storage запустил бесплатное хранилище. NFT.storage использует гибридную модель: закрепляет данные в IPFS (для быстрого извлечения) и одновременно сохраняет эти данные у нескольких майнеров Filecoin для долгосрочной надежности. Многие NFT-проекты (включая проекты на Ethereum, Polygon и Flow) используют NFT.storage, доверяя Protocol Labs поддержание доступности своего контента (что обеспечивается сделками Filecoin). Выгода здесь в том, что проекты получают децентрализованную избыточность без необходимости платить (субсидируется токеномикой Filecoin). Некоторым проектам также нравится идея хранения данных в сети на базе блокчейна (Filecoin) с криптографическими доказательствами. Также разрабатывается концепция «NFT Checkers» для проверки статуса сохранности.
• Storj и Sia реже используются для NFT. Однако они вполне способны хостить медиафайлы NFT; вопрос скорее в наличии готовых интеграций. У Skynet (на базе Sia) были некоторые интеграции с NFT (например, SkyNFT, позволявший минтить NFT на базе Sia со ссылками Skylinks в качестве URI токена). Storj, ориентированный на корпоративный сектор, не нацеливался на NFT напрямую, но теоретически маркетплейс мог бы использовать Storj для хостинга контента (пользуясь производительностью CDN). Тот факт, что IPFS / Arweave доминируют в хранении NFT, во многом объясняется сетевым эффектом и инструментарием: IPFS имеет широкую поддержку в библиотеках для минтинга NFT, а Arweave предложил четкое ценностное предложение «вечного хранения», которое нашло отклик у коллекционеров. Напротив, использование Storj потребовало бы кастомной интеграции (хотя технически можно использовать ссылку Storj или URL шлюза как URI токена — это просто не принято). Преимущество Sia — стоимость; NFT-проект, заботящийся о бюджете, мог бы незаметно использовать Sia через Filebase для недорогого хранения активов, но это было бы необычно, так как это не стандартный подход.
• Ceramic вступает в игру для NFT в контексте динамических или развивающихся NFT. Если метаданные NFT должны обновляться (скажем, игровой предмет, уровень которого повышается), Ceramic может хранить эти изменяющиеся свойства, так как он позволяет создавать изменяемые потоки (mutable streams). Также Ceramic может использоваться для отслеживания владения NFT вне сети или привязки NFT к профилю пользователя. Но для самих медиафайлов Ceramic обычно просто хранит ссылки (например, CID или ссылки Arweave), так как он не предназначен для больших бинарных объектов.

b. Бэкенды децентрализованных приложений (dApp): Многим децентрализованным приложениям требуется хранить данные, которые слишком велики или не подходят для блокчейна (из-за стоимости или потому что это пользовательский контент). Децентрализованные сети хранения заполняют этот пробел, выступая в роли «бэкенда» или базы данных для dApps:

• Хостинг фронтенда Web3: Распространенный паттерн — размещение кода фронтенда (HTML / JS / CSS) децентрализованного приложения в децентрализованной сети хранения, чтобы доступ к приложению можно было получить децентрализованным способом (часто через шлюзы IPFS или URL Arweave). IPFS (через такие сервисы, как Fleek или Pinata) широко используется для хостинга статических сайтов DeFi-приложений, NFT-маркетплейсов и т. д., гарантируя, что даже если основной сайт выйдет из строя, пользователи смогут получить доступ к интерфейсу через IPFS. Arweave также используется для хостинга фронтендов, которым требуется устойчивость к цензуре — например, интерфейсы многих DeFi-проектов на Ethereum загружены в Arweave и привязаны к ENS-ссылкам. В одном примечательном случае, когда в Турции заблокировали определенные криптосайты, пользователи делились ссылками Arweave на интерфейс Uniswap, чтобы к нему по-прежнему можно было получить доступ. Skynet позволял аналогичный распределенный веб-хостинг (SkyLive и SkyPages хостили видео и персональные страницы). Storj также может обслуживать веб-активы, хотя обычно IPFS / Arweave являются приоритетными для фронтендов из-за более простого связывания и контентной адресации. Используя децентрализованное хранилище для фронтендов, проекты снижают зависимость от централизованных серверов — при полной реализации пользователь может взаимодействовать с dApp, загружая интерфейс из IPFS / Arweave, который затем подключается к смарт-контрактам ончейн, достигая полностью децентрализованного стека.
• Данные пользователей и социальные приложения: Децентрализованным социальным сетям или приложениям для совместной работы необходимо хранить посты, сообщения и информацию профилей. Здесь блистает Ceramic — он предоставляет схемы для распространенных типов социальных данных и позволяет вносить обновления. Например, такое приложение, как Lens Protocol (децентрализованная соцсеть на Polygon), использует IPFS для хранения контента постов (часто через шлюз IPFS), но может использовать Ceramic для профилей пользователей или индекса постов, обеспечивая кросс-платформенную социальную идентичность. Orbis использует Ceramic для хранения твитов и комментариев, чтобы несколько фронтендов могли отображать один и тот же контент. Arweave может использоваться для социального контента, который должен быть постоянным (кто-то может решить опубликовать через Arweave нечто вроде «неизменяемого твита»), но социальным сетям обычно нужна изменяемость (редактирование / удаление), чего Arweave не позволяет. У Sia / Skynet было демо социальной сети (SkyFeed), в которой посты хранились в Skynet (отчасти изменяемые путем обновления записи в реестре, указывающей на последнюю ленту). Для чат-приложений Matrix (открытый децентрализованный протокол чата) может быть настроен на хранение медиафайлов в IPFS или Sia для по-настоящему децентрализованного обмена файлами — такие эксперименты проводились сообществами, озабоченными владением данными. Storj может служить бэкендом для приложений, которым требуется безопасное хранение пользовательских файлов (например, приложение типа децентрализованного Dropbox может использовать Storj для хранения файлов с шифрованием на стороне клиента, пользуясь отказоустойчивостью сети). Сообщество Holochain даже рассматривало возможность использования Storj или Sia в качестве уровня хранения файлов для больших данных, которые не вписываются в модель одноранговой базы данных Holochain.
• Децентрализованная идентификация (DID) и учетные данные: Это сценарий, где Ceramic и IPFS играют ключевые роли. Документы DID (небольшие JSON-документы, описывающие публичные ключи пользователя и прочее) могут храниться в IPFS (некоторые методы DID так и делают). Метод DID в Ceramic (did:3) фактически хранит события документа DID в потоках Ceramic. Кроме того, проверяемые учетные данные (verifiable credentials) — криптографически подписанные утверждения размером в пару КБ — могут храниться и распространяться через IPFS или Ceramic, а не в блокчейне, и затем использоваться протоколами идентификации. Arweave может использоваться для архивирования публичных учетных данных или аттестаций для потомков.
• Бэкенд-данные для DeFi и DAO: Многие DeFi-протоколы генерируют большой объем данных (торговые записи, аналитика), которые слишком дороги для хранения ончейн. Некоторые проекты используют Filecoin / IPFS для хранения истории торгов или резервных копий состояний. The Graph (индексирующий блокчейн-данные) недавно ввел поддержку Arweave в качестве хранилища для запрашиваемых данных — узлы Graph могут сохранять данные подграфов в Arweave, используя его постоянство. DAO часто нужно хранить предложения, уставы, снапшоты данных голосования — такие сервисы, как Snapshot, используют IPFS для хранения JSON-файлов предложений, а ссылки IPFS внедряются ончейн при голосованиях. Aragon (платформа для DAO) хранит некоторые конфигурационные файлы DAO в IPFS. DAO, работающие с большими файлами (например, исследовательские DAO, хранящие наборы данных), могут использовать Filecoin для массового хранения и делиться CID внутри DAO.

c. Архивное сохранение данных: Основное обещание децентрализованного хранения — это сохранение информации неограниченно долго и с избыточностью, будь то исторические записи, открытые данные, научные знания или культурные артефакты:

• Arweave позиционирует себя именно для архивирования. Термин «пермавеб» (permaweb) означает создание постоянного архива человеческих знаний. Мы видели, как Arweave использовался для хранения архивов веб-сайтов (например, Интернет-архив сотрудничал с Arweave для хранения данных, существует расширение для браузера «ArweaveSave» для архивирования веб-страниц в Arweave). Сообщества Arweave с разделением прибыли также финансировали такие проекты, как ArweaveNews (для неизменяемого архивирования новостных статей). И учитывая, что данные в Arweave практически не подлежат цензуре и вечны, он идеален для сохранения важных документов (например, журналисты использовали Arweave для хранения документов из зон военных действий или протестов, чтобы их нельзя было стереть). Arweave даже описывали как «Александрийскую библиотеку, которая не может сгореть». Организации с большими потребностями в архивировании (библиотеки, музеи, академические учреждения) проявляют интерес, хотя стоимость является барьером для очень больших наборов данных, если они не обеспечены финансированием.
• Filecoin также нацелен на архивные сценарии. Он известен использованием для хранения научных наборов данных с открытым доступом и открытых государственных данных через программу Filecoin Discover (где люди, хранившие определенные утвержденные данные, получали преимущества в майнинге). Starling Lab (партнерство USC Shoah Foundation и Стэнфорда) использует Filecoin для архивирования чувствительных исторических медиаматериалов (например, свидетельств выживших в Холокосте) с подтверждением подлинности. Инициатива Filecoin Archives включает общественные группы, которые выбирают и загружают важные публичные данные (например, данные о пандемии или массивные литературные корпуса). Поскольку хранилище Filecoin дешево, оно практично для хранения многотерабайтных архивов, таких как целые репозитории общедоступных данных. Одной из проблем является извлечение — если к этим архивам не обращаются часто, они могут находиться у майнеров и требовать определенных усилий для получения (например, оформление сделки на извлечение или закрепление в IPFS при необходимости). Однако такие проекты, как Filecoin Saturn, нацелены на кеширование популярных архивных данных в IPFS для быстрого доступа.
• Storj может удовлетворять архивные потребности благодаря высокой надежности и автоматическому географическому распределению. Например, медицинские или медиа-архивы могут храниться в Storj для снижения риска потери и избавления от необходимости поддерживать несколько копий в разных регионах (Storj делает это автоматически). Это также финансово выгодно для архивов, которые сейчас платят огромные счета облачным провайдерам, так как Storj дешевле. Одной из ниш, которую продвигает Storj, является хранение резервных копий — компании могут использовать Storj как цель для бэкапов (у него даже есть интеграции с популярным ПО для резервного копирования). Таким образом, не только новые архивы, но и бэкапы существующих важных данных можно размещать в Storj, используя его избыточность и безопасность (с бонусом в виде шифрования, что полезно для конфиденциальных данных).
• Sia по своей природе хороша для архивирования благодаря низкой стоимости и избыточности. Если кто-то хочет хранить личный архив документов или фотографий в течение десятилетий, Sia может сделать это с минимальными затратами (при условии продления контрактов). Известен случай, когда кто-то архивировал всю Википедию в Sia, воспользовавшись её доступностью. Полностью приватная природа Sia (шифрование по умолчанию) привлекательна для архивов с требованиями к конфиденциальности (например, личные медицинские записи). Недостатком для организаций является сложность управления Siacoin и контрактами в течение длительных периодов — но сервис Filebase снова может заполнить этот пробел, предоставляя модель подписки поверх Sia.
• Ceramic меньше подходит для архивирования (так как он предназначен для динамических данных). Он не стал бы использоваться для архивирования больших файлов или Big Data; скорее, его можно использовать для архивирования небольших фрагментов исторических данных проверяемым способом (например, официального документа или текста политики, версии которых можно отслеживать в Ceramic). Но если что-то должно быть по-настоящему постоянным и неизменным, лучше выбрать Arweave или аналоги.

d. Доставка контента и стриминг: Децентрализованное хранилище также может выполнять функцию доставки контента конечным пользователям, иногда даже для стриминга в реальном времени или по запросу:

• Storj сделал особый акцент на этом сценарии. Благодаря своей архитектуре контент фактически находится в распределенной CDN — узлы по всему миру могут отдавать видеосегменты пользователям из ближайшего / самого быстрого узла, обеспечивая низкую задержку. Партнерство Storj с платформами потокового видео (как в примере с 30 миллионами часов просмотренного контента) показывает, что он может справляться с высокой пропускной способностью. Он подходит для видео по запросу (VOD) — сохраните видеофайлы, и когда пользователь нажимает play, плеер загружает фрагменты параллельно (у Storj даже было демо, где они сравнивались с Cloudflare Stream и показали конкурентоспособную производительность). Для прямых трансляций само децентрализованное хранилище обычно не используется, так как лайв требует немедленной ретрансляции, но после эфира записи могут распространяться через Storj или Filecoin. Storj также хорош для дистрибуции ПО (он может быстро доставлять пользователям большие бинарные файлы или файлы игр, работая как децентрализованный Akamai).
• IPFS может использоваться для доставки контента, если он достаточно популярен, чтобы его раздавали (seed) многие узлы. Проводились эксперименты с использованием IPFS для прямых трансляций (например, Livepeer в своих ранних версиях использовал IPFS для распределения видеосегментов от вещателей к зрителям). Проблема IPFS — обеспечение доступности: для популярного контента его могут иметь несколько пиров (особенно если настроено роение в стиле BitTorrent), но для менее популярного контента требуется откат к шлюзу, где он закреплен (например, Pinata). IPFS также представил IPFS Cluster для закрепления контента на нескольких узлах, что может помочь с балансировкой нагрузки при обслуживании множества пользователей.
• Filecoin на данный момент больше предназначен для хранения, чем для оперативной доставки, но обсуждалась концепция Filecoin как CDN (использование географии майнеров для обслуживания контента). Вероятный сценарий заключается в том, что данные Filecoin будут кешироваться в более быстрых сетях при необходимости (например, IPFS или специализированные провайдеры извлечения). Также ведется работа над Beta Storage Providers (которые могут держать популярные наборы данных всегда онлайн и близко к пользователям).
• Sia / Skynet имели уникальный подход: порталы Skynet действительно работали как узлы CDN. Если к Skylink часто обращались, портал Skynet кешировал его и быстро отдавал другим. Поскольку существовало несколько порталов, они коллективно обеспечивали избыточность и производительность. Skynet также позволял децентрализованным веб-приложениям загружать контент с любого самого быстрого портала. Однако после закрытия основного портала производительность теперь зависит от тех, что поддерживаются сообществом.
• Arweave не проектировался для высокоскоростной доставки контента — извлечение большого файла из Arweave означает запрос к сети (часто через шлюз), и майнеры собирают фрагменты из «плетения» (weave), что может быть медленнее, чем выделенная CDN. Тем не менее, протокол Wildfire в Arweave стимулирует майнеров быстро обмениваться данными между собой, что сокращает время извлечения при следующем запросе. Для умеренно популярного контента (например, изображения, которое запрашивают несколько человек) шлюзы часто его кешируют. Существуют также поддерживаемые сообществом шлюзы Arweave (аналогичные шлюзам IPFS), которые могут быть распределены по всему миру для повышения производительности. Для стриминга, критичного к задержкам, Arweave не является приоритетным выбором; но для доставки контента, где допустима задержка в секунду-две и важно постоянство (например, публичный документ или сайт), Arweave вполне подходит.

На практике решения могут быть многоуровневыми: например, приложение может хранить контент постоянно в Arweave или Filecoin, но использовать IPFS или Storj для его быстрой доставки конечным пользователям. Или использовать Ceramic для индекса и ссылок, Arweave для бэкапа и IPFS для «горячего» доступа.

Резюме по соответствию сценариям использования: Каждое решение имеет свои сильные стороны в определенных областях:

• Arweave: Лучший выбор для постоянного веб-контента, NFT-медиа, которые должны жить вечно, и защищенных от несанкционированного доступа архивов. Часто используется для метаданных NFT, архивирования истории блокчейна, сохранения веб-страниц / постов в блогах и отказоустойчивого хостинга сайтов. Менее подходит для часто меняющихся данных или стриминга с высокой пропускной способностью.
• Pinata / IPFS: Идеально подходит для контентной адресации и дистрибуции. Используется для NFT (повсеместно), хостинга веб-активов для dApps, общего обмена файлами в Web3-приложениях и любого сценария, требующего быстрой децентрализованной CDN. При правильном закреплении подходит для полупостоянного хранения, хотя не гарантирует вечность, если кто-то не продолжает закреплять файлы (поэтому часто комбинируется с Filecoin). Отлично подходит для совместной работы с данными (несколько человек могут загружать и повторно хостить контент). Менее идеально, если вам нужна гарантия долгосрочной сохранности без обслуживания.
• Filecoin: Отлично подходит для долгосрочного хранения в масштабе, особенно в сочетании с IPFS для извлечения. Используется для архивирования больших наборов данных, резервного копирования активов NFT (многие NFT негласно поддерживаются Filecoin через NFT.storage, даже если фронтенд использует URI IPFS), корпоративного «холодного» хранения и всё чаще для ресурсоемких Web3-сервисов (например, видео, где Filecoin может дешево хранить исходники или транскодированные файлы, пока отдельный слой занимается стримингом). Также тестируется для Data DAO (сообщества, финансирующие хранение ценных данных, таких как OpenStreetMap, геномные данные и т. д.). Обычно не используется для данных в реальном времени или частых мелких записей из-за накладных расходов на сделки, но развивается в этом направлении с новыми инструментами.
• Storj: Превосходит других в безопасном и производительном облачном хранении, ориентированном на разработчиков и предприятия, которым нужно готовое децентрализованное решение. Используется для платформ видеостриминга, бэкендов приложений, которым нужен S3 API (например, блокчейн-обозреватели могут использовать Storj для хранения контента, загруженного пользователями), совместной работы с файлами, доступными по всему миру (например, видеопродакшены, обменивающиеся огромными исходниками через Storj вместо Dropbox для получения преимуществ в скорости и цене). Также подходит для хранения данных IoT (множество мелких записей из разных локаций — Storj хорошо справляется с параллельной записью). Возможно, реже используется в чисто крипто-контексте (например, NFT) просто из-за популярности IPFS там, но технологически он может выполнять многие из тех же задач с потенциально лучшей производительностью.
• Sia: Хороша для бюджетного децентрализованного хранения и тех, кто приоритезирует приватность. Часто выбирается для личных бэкапов (криптоэнтузиастами), избыточного резервного копирования для бизнеса (некоторые могут запускать Sia наряду с традиционным хранилищем, чтобы иметь дополнительную зашифрованную копию вне офиса) и как уровень, стоящий за удобными сервисами вроде Filebase. Skynet расширил её возможности до веб-хостинга и данных приложений, что имело кратковременный расцвет и может вернуться с выходом Sia v2. Sia также используется в некоторых VPN или облачных сервисах как зашифрованное хранилище данных (были проекты по использованию Sia в качестве децентрализованного Dropbox для конечных пользователей, например Pixeldrain). В целом — надежный бэкенд общего назначения при правильной настройке, но с меньшим количеством готовых интеграций, чем у Storj или IPFS.
• Ceramic: Создан специально для данных dApp и идентичностей. Используется для профилей пользователей в Web3 (один профиль доступен во многих dApps), социального контента (посты, комментарии, которые требуют обновлений и удалений, например аналоги Twitter или Reddit), предложений и дискуссий в DAO (чтобы их можно было редактировать и создавать ветки без перегрузки блокчейна), данных игровых состояний (например, отслеживание статистики или достижений ончейн-игры вне сети в изменяемом виде) и реестров метаданных (например, NFT-проект может использовать Ceramic, чтобы владельцы токенов могли добавлять инфо или заметки о происхождении к своему NFT, которые затем привязываются к токену). По сути, везде, где вам нужна база данных в децентрализованном контексте (но данные не огромны). Он совсем не предназначен для хранения файлов — вместо этого он дополняет сети хранения файлов, беря на себя аспекты реляционных / структурированных данных.

В заключение можно сказать, что ландшафт провайдеров децентрализованного хранения предлагает взаимодополняющие возможности. Сложное dApp может использовать сразу несколько из них: например, NFT-маркетплейс может использовать IPFS + Pinata для быстрой отдачи активов, Filecoin для долгосрочного бэкапа активов, Ceramic для профилей пользователей и комментариев к NFT и, возможно, Arweave для своего сайта и постоянного реестра всех метаданных NFT. Каждый проект — Arweave, Pinata / IPFS, Filecoin, Storj, Sia, Ceramic — вносит свой вклад в формирующуюся инфраструктуру децентрализованного веба, балансируя между дизайном протокола, стоимостью, производительностью и долговечностью.

Источники:

• Reflexivity Research (2024) — Arweave Overview
• Gate.io Research (2023) — Arweave: Pay Once, Store Forever
• FiveT Investment (2023) — Decentralized Storage: Filecoin vs Arweave
• Pinata Cloud — Официальный сайт и цены
• NFT.storage Blog (2023) — Partnerships with Pinata and Lighthouse
• Storj Docs — Цены и архитектура; ownCloud — интеграция со Storj
• Messari (2024) — State of Sia Q3 2024
• Ceramic Network — Официальный сайт (2025); LogRocket — Managing data with Ceramic
• IPFS Docs — Сравнения
• The Block (2022) — Meta использует Arweave для Instagram NFT

Конфиденциальность становится общественной инфраструктурой. В 2025 году разработчикам нужны инструменты, которые сделают шифрование таким же простым, как хранение данных. Seal от Mysten Labs предоставляет именно это — децентрализованное управление секретами с контролем доступа в блокчейне. Это руководство научит вас создавать безопасные Web3-приложения, используя шифрование на основе идентификаторов, пороговую безопасность и программируемые политики доступа.

Введение: Почему Seal важен для Web3​

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

Seal полностью меняет эту парадигму. Разработанный Mysten Labs для блокчейна Sui, Seal — это децентрализованный сервис управления секретами (DSM), который обеспечивает:

• Шифрование на основе идентификаторов, при котором контент защищается до того, как покинет вашу среду
• Пороговое шифрование, которое распределяет доступ к ключам между несколькими независимыми узлами
• Контроль доступа в блокчейне с временными блокировками, токен-гейтингом и настраиваемой логикой авторизации
• Независимый от хранилища дизайн, который работает с Walrus, IPFS или любым другим решением для хранения

Независимо от того, создаете ли вы безопасные приложения для обмена сообщениями, платформы с ограниченным доступом к контенту или переводы активов с временной блокировкой, Seal предоставляет необходимые криптографические примитивы и инфраструктуру контроля доступа.

Начало работы​

Предварительные требования​

Прежде чем приступить к работе, убедитесь, что у вас есть:

• Установленный Node.js 18+
• Базовое знакомство с TypeScript/JavaScript
• Кошелек Sui для тестирования (например, Sui Wallet)
• Понимание концепций блокчейна

Установка​

Установите SDK Seal через npm:

npm install @mysten/seal

Вам также понадобится Sui SDK для взаимодействия с блокчейном:

npm install @mysten/sui

Настройка проекта​

Создайте новый проект и инициализируйте его:

mkdir seal-tutorial
cd seal-tutorial
npm init -y
npm install @mysten/seal @mysten/sui typescript @types/node

Создайте простую конфигурацию TypeScript:

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

Основные концепции: Как работает Seal​

Прежде чем писать код, давайте разберемся в архитектуре Seal:

1. Шифрование на основе идентификаторов (IBE)​

В отличие от традиционного шифрования, где вы шифруете данные с помощью публичного ключа, IBE позволяет шифровать данные для идентификатора (например, адреса электронной почты или адреса Sui). Получатель может расшифровать данные только в том случае, если он может доказать, что контролирует этот идентификатор.

2. Пороговое шифрование​

Вместо того чтобы доверять одному серверу ключей, Seal использует t-из-n пороговые схемы. Вы можете настроить 3 из 5 серверов ключей, что означает, что любые 3 сервера могут сотрудничать для предоставления ключей дешифрования, но 2 или меньше не могут.

3. Контроль доступа в блокчейне​

Политики доступа обеспечиваются смарт-контрактами Sui. Прежде чем сервер ключей предоставит ключи дешифрования, он проверяет, соответствует ли запрашивающий требованиям политики в блокчейне (владение токенами, временные ограничения и т. д.).

4. Сеть серверов ключей​

Распределенные серверы ключей проверяют политики доступа и генерируют ключи дешифрования. Эти серверы управляются различными сторонами для обеспечения отсутствия единой точки контроля.

Базовая реализация: Ваше первое приложение Seal​

Давайте создадим простое приложение, которое шифрует конфиденциальные данные и контролирует доступ через политики блокчейна Sui.

Шаг 1: Инициализация клиента Seal​

// src/seal-client.ts
import { SealClient } from "@mysten/seal";
import { SuiClient } from "@mysten/sui/client";

export async function createSealClient() {
  // Initialize Sui client for testnet
  const suiClient = new SuiClient({
    url: "https://fullnode.testnet.sui.io",
  });

  // Configure Seal client with testnet key servers
  const sealClient = new SealClient({
    suiClient,
    keyServers: [
      "https://keyserver1.seal-testnet.com",
      "https://keyserver2.seal-testnet.com",
      "https://keyserver3.seal-testnet.com",
    ],
    threshold: 2, // 2-of-3 threshold
    network: "testnet",
  });

  return { sealClient, suiClient };
}

Шаг 2: Простое шифрование/дешифрование​

// src/basic-encryption.ts
import { createSealClient } from "./seal-client";

async function basicExample() {
  const { sealClient } = await createSealClient();

  // Data to encrypt
  const sensitiveData = "This is my secret message!";
  const recipientAddress =
    "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  try {
    // Encrypt data for a specific Sui address
    const encryptedData = await sealClient.encrypt({
      data: Buffer.from(sensitiveData, "utf-8"),
      recipientId: recipientAddress,
      // Optional: add metadata
      metadata: {
        contentType: "text/plain",
        timestamp: Date.now(),
      },
    });

    console.log("Encrypted data:", {
      ciphertext: encryptedData.ciphertext.toString("base64"),
      encryptionId: encryptedData.encryptionId,
    });

    // Later, decrypt the data (requires proper authorization)
    const decryptedData = await sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientAddress,
    });

    console.log("Decrypted data:", decryptedData.toString("utf-8"));
  } catch (error) {
    console.error("Encryption/decryption failed:", error);
  }
}

basicExample();

Контроль доступа с помощью смарт-контрактов Sui​

Настоящая мощь Seal заключается в программируемом контроле доступа. Давайте создадим пример шифрования с временной блокировкой, где данные могут быть расшифрованы только по истечении определенного времени.

Шаг 1: Развертывание контракта контроля доступа​

Сначала нам нужен смарт-контракт Move, который определяет нашу политику доступа:

// contracts/time_lock.move
module time_lock::policy {
    use sui::clock::{Self, Clock};
    use sui::object::{Self, UID};
    use sui::tx_context::{Self, TxContext};

    public struct TimeLockPolicy has key, store {
        id: UID,
        unlock_time: u64,
        authorized_user: address,
    }

    public fun create_time_lock(
        unlock_time: u64,
        authorized_user: address,
        ctx: &mut TxContext
    ): TimeLockPolicy {
        TimeLockPolicy {
            id: object::new(ctx),
            unlock_time,
            authorized_user,
        }
    }

    public fun can_decrypt(
        policy: &TimeLockPolicy,
        user: address,
        clock: &Clock
    ): bool {
        let current_time = clock::timestamp_ms(clock);
        policy.authorized_user == user && current_time >= policy.unlock_time
    }
}

Шаг 2: Интеграция с Seal​

// src/time-locked-encryption.ts
import { createSealClient } from "./seal-client";
import { TransactionBlock } from "@mysten/sui/transactions";

async function createTimeLocked() {
  const { sealClient, suiClient } = await createSealClient();

  // Create access policy on Sui
  const txb = new TransactionBlock();

  const unlockTime = Date.now() + 60000; // Unlock in 1 minute
  const authorizedUser =
    "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  txb.moveCall({
    target: "time_lock::policy::create_time_lock",
    arguments: [txb.pure(unlockTime), txb.pure(authorizedUser)],
  });

  // Execute transaction to create policy
  const result = await suiClient.signAndExecuteTransactionBlock({
    transactionBlock: txb,
    signer: yourKeypair, // Your Sui keypair
  });

  const policyId = result.objectChanges?.find(
    (change) => change.type === "created",
  )?.objectId;

  // Now encrypt with this policy
  const sensitiveData = "This will unlock in 1 minute!";

  const encryptedData = await sealClient.encrypt({
    data: Buffer.from(sensitiveData, "utf-8"),
    recipientId: authorizedUser,
    accessPolicy: {
      policyId,
      policyType: "time_lock",
    },
  });

  console.log("Time-locked data created. Try decrypting after 1 minute.");

  return {
    encryptedData,
    policyId,
    unlockTime,
  };
}

Практические примеры​

Пример 1: Приложение для безопасного обмена сообщениями​

// src/secure-messaging.ts
import { createSealClient } from "./seal-client";

class SecureMessenger {
  private sealClient: any;

  constructor(sealClient: any) {
    this.sealClient = sealClient;
  }

  async sendMessage(
    message: string,
    recipientAddress: string,
    senderKeypair: any,
  ) {
    const messageData = {
      content: message,
      timestamp: Date.now(),
      sender: senderKeypair.toSuiAddress(),
      messageId: crypto.randomUUID(),
    };

    const encryptedMessage = await this.sealClient.encrypt({
      data: Buffer.from(JSON.stringify(messageData), "utf-8"),
      recipientId: recipientAddress,
      metadata: {
        type: "secure_message",
        sender: senderKeypair.toSuiAddress(),
      },
    });

    // Store encrypted message on decentralized storage (Walrus)
    return this.storeOnWalrus(encryptedMessage);
  }

  async readMessage(encryptionId: string, recipientKeypair: any) {
    // Retrieve from storage
    const encryptedData = await this.retrieveFromWalrus(encryptionId);

    // Decrypt with Seal
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientKeypair.toSuiAddress(),
    });

    return JSON.parse(decryptedData.toString("utf-8"));
  }

  private async storeOnWalrus(data: any) {
    // Integration with Walrus storage
    // This would upload the encrypted data to Walrus
    // and return the blob ID for retrieval
  }

  private async retrieveFromWalrus(blobId: string) {
    // Retrieve encrypted data from Walrus using blob ID
  }
}

Пример 2: Платформа контента с токен-гейтингом​

// src/gated-content.ts
import { createSealClient } from "./seal-client";

class ContentGating {
  private sealClient: any;
  private suiClient: any;

  constructor(sealClient: any, suiClient: any) {
    this.sealClient = sealClient;
    this.suiClient = suiClient;
  }

  async createGatedContent(
    content: string,
    requiredNftCollection: string,
    creatorKeypair: any,
  ) {
    // Create NFT ownership policy
    const accessPolicy = await this.createNftPolicy(
      requiredNftCollection,
      creatorKeypair,
    );

    // Encrypt content with NFT access requirement
    const encryptedContent = await this.sealClient.encrypt({
      data: Buffer.from(content, "utf-8"),
      recipientId: "nft_holders", // Special recipient for NFT holders
      accessPolicy: {
        policyId: accessPolicy.policyId,
        policyType: "nft_ownership",
      },
    });

    return {
      contentId: encryptedContent.encryptionId,
      accessPolicy: accessPolicy.policyId,
    };
  }

  async accessGatedContent(
    contentId: string,
    userAddress: string,
    userKeypair: any,
  ) {
    // Verify NFT ownership first
    const hasAccess = await this.verifyNftOwnership(userAddress, contentId);

    if (!hasAccess) {
      throw new Error("Access denied: Required NFT not found");
    }

    // Decrypt content
    const decryptedContent = await this.sealClient.decrypt({
      encryptionId: contentId,
      recipientId: userAddress,
    });

    return decryptedContent.toString("utf-8");
  }

  private async createNftPolicy(collection: string, creator: any) {
    // Create Move contract that checks NFT ownership
    // Returns policy object ID
  }

  private async verifyNftOwnership(user: string, contentId: string) {
    // Check if user owns required NFT
    // Query Sui for NFT ownership
  }
}

Пример 3: Передача активов с временной блокировкой​

// src/time-locked-transfer.ts
import { createSealClient } from "./seal-client";

async function createTimeLockTransfer(
  assetData: any,
  recipientAddress: string,
  unlockTimestamp: number,
  senderKeypair: any,
) {
  const { sealClient, suiClient } = await createSealClient();

  // Create time-lock policy on Sui
  const timeLockPolicy = await createTimeLockPolicy(
    unlockTimestamp,
    recipientAddress,
    senderKeypair,
    suiClient,
  );

  // Encrypt asset transfer data
  const transferData = {
    asset: assetData,
    recipient: recipientAddress,
    unlockTime: unlockTimestamp,
    transferId: crypto.randomUUID(),
  };

  const encryptedTransfer = await sealClient.encrypt({
    data: Buffer.from(JSON.stringify(transferData), "utf-8"),
    recipientId: recipientAddress,
    accessPolicy: {
      policyId: timeLockPolicy.policyId,
      policyType: "time_lock",
    },
  });

  console.log(`Asset locked until ${new Date(unlockTimestamp)}`);

  return {
    transferId: encryptedTransfer.encryptionId,
    unlockTime: unlockTimestamp,
    policyId: timeLockPolicy.policyId,
  };
}

async function claimTimeLockTransfer(
  transferId: string,
  recipientKeypair: any,
) {
  const { sealClient } = await createSealClient();

  try {
    const decryptedData = await sealClient.decrypt({
      encryptionId: transferId,
      recipientId: recipientKeypair.toSuiAddress(),
    });

    const transferData = JSON.parse(decryptedData.toString("utf-8"));

    // Process the asset transfer
    console.log("Asset transfer unlocked:", transferData);

    return transferData;
  } catch (error) {
    console.error("Transfer not yet unlocked or access denied:", error);
    throw error;
  }
}

Интеграция с децентрализованным хранилищем Walrus​

Seal бесшовно работает с Walrus, децентрализованным решением для хранения данных от Sui. Вот как интегрировать оба:

// src/walrus-integration.ts
import { createSealClient } from "./seal-client";

class SealWalrusIntegration {
  private sealClient: any;
  private walrusClient: any;

  constructor(sealClient: any, walrusClient: any) {
    this.sealClient = sealClient;
    this.walrusClient = walrusClient;
  }

  async storeEncryptedData(
    data: Buffer,
    recipientAddress: string,
    accessPolicy?: any,
  ) {
    // Encrypt with Seal
    const encryptedData = await this.sealClient.encrypt({
      data,
      recipientId: recipientAddress,
      accessPolicy,
    });

    // Store encrypted data on Walrus
    const blobId = await this.walrusClient.store(encryptedData.ciphertext);

    // Return reference that includes both Seal and Walrus info
    return {
      blobId,
      encryptionId: encryptedData.encryptionId,
      accessPolicy: encryptedData.accessPolicy,
    };
  }

  async retrieveAndDecrypt(
    blobId: string,
    encryptionId: string,
    userKeypair: any,
  ) {
    // Retrieve from Walrus
    const encryptedData = await this.walrusClient.retrieve(blobId);

    // Decrypt with Seal
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData,
      encryptionId,
      recipientId: userKeypair.toSuiAddress(),
    });

    return decryptedData;
  }
}

// Usage example
async function walrusExample() {
  const { sealClient } = await createSealClient();
  const walrusClient = new WalrusClient("https://walrus-testnet.sui.io");

  const integration = new SealWalrusIntegration(sealClient, walrusClient);

  const fileData = Buffer.from("Important document content");
  const recipientAddress = "0x...";

  // Store encrypted
  const result = await integration.storeEncryptedData(
    fileData,
    recipientAddress,
  );

  console.log("Stored with Blob ID:", result.blobId);

  // Later, retrieve and decrypt
  const decrypted = await integration.retrieveAndDecrypt(
    result.blobId,
    result.encryptionId,
    recipientKeypair,
  );

  console.log("Retrieved data:", decrypted.toString());
}

Пороговое шифрование: Расширенная конфигурация​

Для производственных приложений вам потребуется настроить пользовательское пороговое шифрование с несколькими серверами ключей:

// src/advanced-threshold.ts
import { SealClient } from "@mysten/seal";

async function setupProductionSeal() {
  // Configure with multiple independent key servers
  const keyServers = [
    "https://keyserver-1.your-org.com",
    "https://keyserver-2.partner-org.com",
    "https://keyserver-3.third-party.com",
    "https://keyserver-4.backup-provider.com",
    "https://keyserver-5.fallback.com",
  ];

  const sealClient = new SealClient({
    keyServers,
    threshold: 3, // 3-of-5 threshold
    network: "mainnet",
    // Advanced options
    retryAttempts: 3,
    timeoutMs: 10000,
    backupKeyServers: [
      "https://backup-1.emergency.com",
      "https://backup-2.emergency.com",
    ],
  });

  return sealClient;
}

async function robustEncryption() {
  const sealClient = await setupProductionSeal();

  const criticalData = "Mission critical encrypted data";

  // Encrypt with high security guarantees
  const encrypted = await sealClient.encrypt({
    data: Buffer.from(criticalData, "utf-8"),
    recipientId: "0x...",
    // Require all 5 servers for maximum security
    customThreshold: 5,
    // Add redundancy
    redundancy: 2,
    accessPolicy: {
      // Multi-factor requirements
      requirements: ["nft_ownership", "time_lock", "multisig_approval"],
    },
  });

  return encrypted;
}

Лучшие практики безопасности​

1. Управление ключами​

// src/security-practices.ts

// GOOD: Use secure key derivation
import { generateKeypair } from "@mysten/sui/cryptography/ed25519";

const keypair = generateKeypair();

// GOOD: Store keys securely (example with environment variables)
const keypair = Ed25519Keypair.fromSecretKey(process.env.PRIVATE_KEY);

// BAD: Never hardcode keys
const badKeypair = Ed25519Keypair.fromSecretKey(
  "hardcoded-secret-key-12345", // Don't do this!
);

2. Проверка политики доступа​

// Always validate access policies before encryption
async function secureEncrypt(data: Buffer, recipient: string) {
  const { sealClient } = await createSealClient();

  // Validate recipient address
  if (!isValidSuiAddress(recipient)) {
    throw new Error("Invalid recipient address");
  }

  // Check policy exists and is valid
  const policy = await validateAccessPolicy(policyId);
  if (!policy.isValid) {
    throw new Error("Invalid access policy");
  }

  return sealClient.encrypt({
    data,
    recipientId: recipient,
    accessPolicy: policy,
  });
}

3. Обработка ошибок и запасные варианты​

// Robust error handling
async function resilientDecrypt(encryptionId: string, userKeypair: any) {
  const { sealClient } = await createSealClient();

  try {
    return await sealClient.decrypt({
      encryptionId,
      recipientId: userKeypair.toSuiAddress(),
    });
  } catch (error) {
    if (error.code === "ACCESS_DENIED") {
      throw new Error("Access denied: Check your permissions");
    } else if (error.code === "KEY_SERVER_UNAVAILABLE") {
      // Try with backup configuration
      return await retryWithBackupServers(encryptionId, userKeypair);
    } else if (error.code === "THRESHOLD_NOT_MET") {
      throw new Error("Insufficient key servers available");
    } else {
      throw new Error(`Decryption failed: ${error.message}`);
    }
  }
}

4. Проверка данных​

// Validate data before encryption
function validateDataForEncryption(data: Buffer): boolean {
  // Check size limits
  if (data.length > 1024 * 1024) {
    // 1MB limit
    throw new Error("Data too large for encryption");
  }

  // Check for sensitive patterns (optional)
  const dataStr = data.toString();
  if (containsSensitivePatterns(dataStr)) {
    console.warn("Warning: Data contains potentially sensitive patterns");
  }

  return true;
}

Оптимизация производительности​

1. Пакетные операции​

// Batch multiple encryptions for efficiency
async function batchEncrypt(dataItems: Buffer[], recipients: string[]) {
  const { sealClient } = await createSealClient();

  const promises = dataItems.map((data, index) =>
    sealClient.encrypt({
      data,
      recipientId: recipients[index],
    }),
  );

  return Promise.all(promises);
}

2. Кэширование ответов сервера ключей​

// Cache key server sessions to reduce latency
class OptimizedSealClient {
  private sessionCache = new Map();

  async encryptWithCaching(data: Buffer, recipient: string) {
    let session = this.sessionCache.get(recipient);

    if (!session || this.isSessionExpired(session)) {
      session = await this.createNewSession(recipient);
      this.sessionCache.set(recipient, session);
    }

    return this.encryptWithSession(data, session);
  }
}

Тестирование вашей интеграции Seal​

Модульное тестирование​

// tests/seal-integration.test.ts
import { describe, it, expect } from "jest";
import { createSealClient } from "../src/seal-client";

describe("Seal Integration", () => {
  it("should encrypt and decrypt data successfully", async () => {
    const { sealClient } = await createSealClient();
    const testData = Buffer.from("test message");
    const recipient =
      "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

    const encrypted = await sealClient.encrypt({
      data: testData,
      recipientId: recipient,
    });

    expect(encrypted.encryptionId).toBeDefined();
    expect(encrypted.ciphertext).toBeDefined();

    const decrypted = await sealClient.decrypt({
      ciphertext: encrypted.ciphertext,
      encryptionId: encrypted.encryptionId,
      recipientId: recipient,
    });

    expect(decrypted.toString()).toBe("test message");
  });

  it("should enforce access control policies", async () => {
    // Test that unauthorized users cannot decrypt
    const { sealClient } = await createSealClient();

    const encrypted = await sealClient.encrypt({
      data: Buffer.from("secret"),
      recipientId: "authorized-user",
    });

    await expect(
      sealClient.decrypt({
        ciphertext: encrypted.ciphertext,
        encryptionId: encrypted.encryptionId,
        recipientId: "unauthorized-user",
      }),
    ).rejects.toThrow("Access denied");
  });
});

Развертывание в продакшене​

Конфигурация среды​

// config/production.ts
export const productionConfig = {
  keyServers: [
    process.env.KEY_SERVER_1,
    process.env.KEY_SERVER_2,
    process.env.KEY_SERVER_3,
    process.env.KEY_SERVER_4,
    process.env.KEY_SERVER_5,
  ],
  threshold: 3,
  network: "mainnet",
  suiRpc: process.env.SUI_RPC_URL,
  walrusGateway: process.env.WALRUS_GATEWAY,
  // Security settings
  maxDataSize: 1024 * 1024, // 1MB
  sessionTimeout: 3600000, // 1 hour
  retryAttempts: 3,
};

Мониторинг и логирование​

// utils/monitoring.ts
export class SealMonitoring {
  static logEncryption(encryptionId: string, recipient: string) {
    console.log(`[SEAL] Encrypted data ${encryptionId} for ${recipient}`);
    // Send to your monitoring service
  }

  static logDecryption(encryptionId: string, success: boolean) {
    console.log(
      `[SEAL] Decryption ${encryptionId}: ${success ? "SUCCESS" : "FAILED"}`,
    );
  }

  static logKeyServerHealth(serverUrl: string, status: string) {
    console.log(`[SEAL] Key server ${serverUrl}: ${status}`);
  }
}

Ресурсы и дальнейшие шаги​

Официальная документация​

• Seal Documentation: https://seal-docs.wal.app/
• GitHub Repository: https://github.com/MystenLabs/seal
• Sui Documentation: https://docs.sui.io/
• Walrus Documentation: https://docs.wal.app/

Сообщество и поддержка​

• Sui Discord: Присоединяйтесь к каналу #seal для поддержки сообщества
• GitHub Issues: Сообщайте об ошибках и запрашивайте функции
• Форумы для разработчиков: Форумы сообщества Sui для обсуждений

Расширенные темы для изучения​

1. Пользовательские политики доступа: Создавайте сложную логику авторизации с помощью контрактов Move
2. Кросс-чейн интеграция: Используйте Seal с другими блокчейн-сетями
3. Управление ключами для предприятий: Настройте собственную инфраструктуру серверов ключей
4. Аудит и соответствие требованиям: Внедрите логирование и мониторинг для регулируемых сред

Примеры приложений​

• Приложение для безопасного чата: Сквозное шифрование сообщений с помощью Seal
• Управление документами: Обмен корпоративными документами с контролем доступа
• Управление цифровыми правами: Распространение контента с политиками использования
• Аналитика, сохраняющая конфиденциальность: Рабочие процессы обработки зашифрованных данных

Заключение​

Seal представляет собой фундаментальный сдвиг в сторону превращения конфиденциальности и шифрования в инфраструктурные проблемы в Web3. Объединяя шифрование на основе идентификаторов, пороговую безопасность и программируемый контроль доступа, он предоставляет разработчикам мощные инструменты для создания по-настоящему безопасных и децентрализованных приложений.

Основные преимущества использования Seal включают:

• Отсутствие единой точки отказа: Распределенные серверы ключей устраняют центральные органы
• Программируемая безопасность: Политики доступа на основе смарт-контрактов обеспечивают гибкую авторизацию
• Удобство для разработчиков: SDK TypeScript легко интегрируется с существующими инструментами Web3
• Независимость от хранилища: Работает с Walrus, IPFS или любым другим решением для хранения
• Готовность к продакшену: Создан Mysten Labs с учетом корпоративных стандартов безопасности

Независимо от того, защищаете ли вы пользовательские данные, внедряете модели подписки или создаете сложные многосторонние приложения, Seal предоставляет криптографические примитивы и инфраструктуру контроля доступа, необходимые для уверенного создания.

Начните создавать сегодня и присоединяйтесь к растущей экосистеме разработчиков, которые делают конфиденциальность фундаментальной частью общественной инфраструктуры.

Готовы начать создавать? Установите @mysten/seal и начните экспериментировать с примерами из этого руководства. Децентрализованная сеть ждет приложений, которые ставят конфиденциальность и безопасность на первое место.