2 записи с тегом "децентрализованное хранилище"

Децентрализованные сети хранения данных призваны решить проблемы непостоянства данных, цензуры и централизации путем распределения данных по одноранговым сетям. Традиционный веб-контент удивительно эфемерный – например, исследования показывают, что более 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 использует Bundling (объединение множества небольших файлов в одну транзакцию) для обработки большого объема данных (например, один раз бандлер Arweave сохранил 47 ГБ данных в одной транзакции). Механизм Wildfire ранжирует узлы по скорости отклика, чтобы стимулировать быстрое распространение данных по сети. В целом, Arweave действует как децентрализованный жесткий диск — постоянно хранит данные в блокчейне, с ожиданием, что затраты на хранение будут продолжать снижаться, чтобы майнеры могли получать оплату вечно из первоначального фонда.

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

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

Storj: Storj — это распределенная облачная сеть объектного хранения, которая не использует блокчейн для консенсуса, а вместо этого координирует хранение через децентрализованную сеть узлов и службу метаданных-спутников. Когда файл загружается в Storj (через их службу, называемую Storj DCS – Decentralized Cloud Storage), он сначала шифруется на стороне клиента, а затем кодируется с исправлением ошибок в 80 фрагментов (по умолчанию), так что для восстановления файла требуется только подмножество (например, 29 из 80 фрагментов). Эти зашифрованные фрагменты распределяются по различным узлам хранения по всему миру (каждый узел хранит только случайные фрагменты, а не полезные данные сам по себе). Это обеспечивает Storj чрезвычайно высокую долговечность (заявленная долговечность 11×9s – 99,999999999% выживаемости данных), а также параллелизм при загрузке – пользователь, извлекающий файл, может получать фрагменты с десятков узлов одновременно, часто улучшая пропускную способность. Storj использует концепцию доказательства извлекаемости (узлы хранения периодически проверяют, что у них все еще есть их фрагменты). Сеть работает по модели нулевого доверия со сквозным шифрованием: только владелец файла (который хранит ключ дешифрования) может читать данные. Архитектура не имеет центрального центра обработки данных — вместо этого она использует существующую избыточную дисковую емкость, предоставляемую операторами узлов, что повышает устойчивость и глобальное распределение (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 предоставлял адресацию контента (через «skylinks») и веб-порталы для легкого извлечения контента, размещенного на Sia, фактически действуя как децентрализованный CDN для файлов Sia. Таким образом, архитектура Sia — это облачное хранилище, защищенное блокчейном, с высокой избыточностью и конфиденциальностью, подходящее для «горячих» данных (быстрое извлечение) децентрализованным способом.

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

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

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

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

• Ценообразование Arweave: Arweave требует единовременной предоплаты в токенах AR для хранения данных *навсегда*. Пользователи платят за хранение данных в течение как минимум 200 лет, и протокол помещает ~86% этой платы в фонд пожертвований. Накопления фонда (за счет процентов и роста стоимости AR) предназначены для бессрочной оплаты майнеров хранения, исходя из предположения, что затраты на оборудование со временем снижаются (исторически ~30% дешевле в год). На практике цена колеблется в зависимости от рыночной цены AR, но по состоянию на 2023 год она составляла около $3500 за 1 ТБ однократно (примечание: это покупает постоянное хранение, тогда как традиционное облачное хранение является периодической стоимостью). Модель Arweave переносит бремя на предоплату: пользователи платят больше изначально, но затем ничего. Это может быть дорого для больших объемов данных, но гарантирует постоянство без необходимости доверять поставщику в будущем.

• Ценообразование Pinata (IPFS): Pinata использует модель подписки (фиатное ценообразование), распространенную в Web2 SaaS. Она предлагает бесплатный уровень (до 1 ГБ хранилища, 10 ГБ/месяц пропускной способности, 500 файлов) и платные тарифы. Популярный тариф «Pinata **Picnic**» стоит $20/месяц и включает 1 ТБ закрепленного хранилища и 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/ТБ/год для часто используемого хранилища) и даже другие децентрализованные варианты. Однако эта ставка не фиксирована — клиенты размещают заявки, а майнеры предлагают свои услуги; рыночная цена может варьироваться. Сделки хранения Filecoin также имеют указанную продолжительность (например, 1 год); если вы хотите хранить данные дольше этого срока, вы должны продлить (снова заплатить) или заключить долгосрочные сделки заранее. Существует также концепция Filecoin Plus (FIL+), программа стимулирования, которая предоставляет «проверенным» клиентам (хранящим полезные общедоступные данные) бонус для привлечения майнеров по более низкой эффективной стоимости. В дополнение к платам за хранение, пользователи могут платить небольшие суммы FIL за извлечение на основе каждого запроса, хотя рынки извлечения все еще развиваются (многие пока полагаются на бесплатное извлечение через IPFS). Важно отметить, что токеномика Filecoin (вознаграждения за блоки) сильно субсидирует майнеров — вознаграждения за блоки в FIL дополняют комиссии, уплачиваемые пользователями. Это означает, что сегодняшние низкие цены отчасти обусловлены инфляционными вознаграждениями; со временем, по мере сокращения вознаграждений за блоки, платы за хранение могут увеличиться. Таким образом, ценообразование Filecoin динамично и основано на токенах, как правило, очень низкая стоимость за байт, но пользователи должны управлять продлениями и валютным риском FIL.

• Ценообразование Storj: Storj оценивается в традиционных валютных терминах (хотя платежи могут производиться в фиате или токенах STORJ). Он следует модели ценообразования облачных услуг на основе использования: в настоящее время $4,00 за ТБ-месяц за хранение и $7,00 за ТБ исходящего трафика. В более детальном выражении это $0,004 за ГБ-месяц для хранимых данных и $0,007 за ГБ загруженных данных. Также взимается небольшая плата за объект (сегмент) для учета накладных расходов на метаданные (около $0,0000088 за сегмент в месяц), что имеет значение только при хранении миллионов очень маленьких файлов. Примечательно, что входящий трафик (загрузки) бесплатен, и 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 для пропускной способности (загрузка/скачивание) и залога. Экономика такова, что хосты конкурируют, предлагая низкие цены (поскольку они хотят привлекать контракты и зарабатывать SC), а арендаторы выигрывают от этой конкуренции. Однако, поскольку использование Sia требует работы с кошельком Siacoin и заключения контрактов, рассчитывать затраты немного менее удобно, чем, скажем, в Storj или Pinata. Короче говоря, затраты Sia определяются рынком токенов и очень низки за ТБ, но пользователь должен постоянно платить (в SC) для продления контрактов. Нет единовременной предоплаты за бессрочное хранение — это оплата по мере использования в криптоформе. Многие пользователи получают SC через биржу, а затем могут заключать контракты на месяцы хранения по заранее определенным ставкам.

• Ценообразование Ceramic: Ceramic не взимает плату за использование на уровне протокола; нет собственного токена или комиссии за создание/обновление потоков, помимо незначительной стоимости газа за привязку обновлений к блокчейну Ethereum (которая обычно обрабатывается инфраструктурой Ceramic и незначительна за обновление при пакетной обработке). Запуск узла Ceramic — это открытая деятельность — любой может запустить его для индексации и обслуживания данных. 3Box Labs (команда, стоящая за Ceramic) предлагала хостинговую услугу для разработчиков (Ceramic Cloud), которая могла бы ввести корпоративное ценообразование для удобства, но сама сеть бесплатна для использования, за исключением усилий по запуску узла. Таким образом, «цена» Ceramic — это в основном операционные расходы, которые несут разработчики, если они самостоятельно размещают узлы, или стоимость доверия, если используется сторонний узел. По сути, модель Ceramic больше похожа на децентрализованную базу данных или службу RPC блокчейна — монетизация (если таковая имеется) осуществляется через дополнительные услуги, а не микроплатежи за данные. Это делает ее привлекательной для разработчиков, желающих экспериментировать с динамическим хранением данных без необходимости использования токена, но это также означает обеспечение долгосрочной поддержки узлов (поскольку альтруистические или грантовые узлы предоставляют хранилище).

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

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

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

• Опыт разработчиков Arweave: Arweave предоставляет конечную точку API GraphQL (по адресу arweave.net/graphql), которая позволяет запрашивать permaweb на предмет транзакций и данных — разработчики могут искать хранимый контент по тегам, адресам кошельков и т. д. Существуют официальные SDK, такие как Arweave.js для браузеров и Node.js, которые упрощают загрузку файлов и отправку транзакций в сеть. Например, разработчик может использовать Arweave SDK для объединения и загрузки файла всего несколькими строками кода. Поскольку каждая загрузка является транзакцией в блокчейне, пользовательский опыт для крупномасштабных загрузок исторически был сложным, но внедрение Bundlr (Bundlr Network) значительно улучшило пропускную способность. Bundlr (теперь переименованный в «Iris» для масштабирования Arweave) — это, по сути, сеть узлов объединения, которая позволяет разработчикам платить один раз и загружать множество файлов вне блокчейна, а затем периодически массово фиксировать их в Arweave. Это позволяет dApp (особенно платформам NFT) быстро загружать тысячи файлов без спама в блокчейне, при этом получая в конечном итоге постоянство. Экосистема инструментов Arweave также включает CLI Arweave Deploy и ArDrive (удобное приложение для управления файлами в Arweave). Концепция Permaweb распространяется на хостинг веб-приложений — разработчики могут развертывать HTML/JS в Arweave с помощью таких инструментов, как Ardor или Web3-бандлер, и делать их доступными по постоянному URL-адресу. Документация Arweave обширна, охватывает вопросы ценообразования загрузок (есть даже калькулятор), извлечения данных (через шлюзы или запуск легковесного узла) и созданные сообществом «кулинарные книги» для общих задач. Одна из сложностей обучения — это работа с ключом кошелька для подписи транзакций; 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 ясна, с примерами загрузки файлов, закрепления по CID (если контент уже находится в IPFS) и управления закреплениями (открепление, статус закрепления и т. д.). Она также поддерживает шлюз контента: разработчики могут использовать пользовательский поддомен (например, myapp.mypinata.cloud) для обслуживания контента по HTTP, со встроенным CDN и даже оптимизацией изображений. Это означает, что разработчики могут обрабатывать изображения, хранящиеся в IPFS, почти так же, как они делали бы это с Cloudinary или Imgix (оптимизатор изображений Pinata может изменять размер/обрезать на лету с помощью параметров URL). Pinata недавно представила такие функции, как «Pinata KV» (хранилище ключ-значение для JSON или метаданных, полезное наряду с хранением файлов) и контроль доступа (для установки контента как общедоступного или ограниченного). Эти функции более высокого уровня упрощают создание полноценных приложений. Кроме того, поскольку Pinata просто взаимодействует с IPFS, разработчики сохраняют гибкость в выборе — они всегда могут взять CID, закрепленный через Pinata, и закрепить его в другом месте (или на своем собственном узле), поскольку IPFS совместим. Поддержка Pinata (руководства, сообщество) хорошо зарекомендовала себя, и они даже сотрудничают с Protocol Labs в таких инициативах, как миграция NFT.Storage (предоставляя руководства, чтобы помочь пользователям перемещать данные между сервисами). Для тех, кто вообще не хочет иметь дело с криптовалютой, Pinata идеальна — нет блокчейна для интеграции, только простые вызовы API и кредитная карта. Обратная сторона — меньшая децентрализация самой интеграции, поскольку вы полагаетесь на доступность и качество обслуживания Pin

Конфиденциальность становится общественной инфраструктурой. В 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 и начните экспериментировать с примерами из этого руководства. Децентрализованная сеть ждет приложений, которые ставят конфиденциальность и безопасность на первое место.