Офчейн-метаданные: Что такое офчейн-метаданные?Офчейн-метаданные — это описательная информация о криптоактиве, NFT, токене, смарт-контракте, игровом предмете, записи цифровой идентификации или токенизированном активе реОфчейн-метаданные: Что такое офчейн-метаданные?Офчейн-метаданные — это описательная информация о криптоактиве, NFT, токене, смарт-контракте, игровом предмете, записи цифровой идентификации или токенизированном активе ре

Офчейн-метаданные

2026/10/14 17:55

#Intermediate

H$0.05638+1.32%

PX$0.0117-2.50%

NFT$0.0000002393-0.04%

ID$0.03057+0.13%

DATA$0.1529-4.79%

Что такое офчейн-метаданные?

Офчейн-метаданные — это описательная информация о криптоактиве, NFT, токене, смарт-контракте, игровом предмете, записи цифровой идентификации или токенизированном активе реального мира. Она хранится вне блокчейна, но на нее ссылается запись в блокчейне.

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

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

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

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

Стандарт ERC-721 определяет необязательное расширение для метаданных, в котором tokenURI может указывать на JSON-файл с описанием NFT.

Стандарт ERC-1155 также определяет правила работы URI метаданных для контрактов с несколькими токенами, включая подстановку идентификаторов токенов в URI.

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

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

Главное об офчейн-метаданных

- Офчейн-метаданные — это сведения об активе, хранящиеся вне блокчейна и доступные по URI, хешу, указателю или функции контракта в блокчейне.
- Их широко применяют для NFT, игровых активов, логотипов токенов, профилей контрактов, токенизированных активов реального мира, учетных данных и предметов коллекционирования.
- Для хранения часто используют HTTPS-серверы, IPFS, Arweave, хранилища на базе Filecoin, облачные сервисы и частные базы данных.
- Офчейн-метаданные снижают затраты на блокчейн: большие JSON-файлы, изображения, видео и документы не нужно хранить непосредственно в хранилище контракта.
- К основным рискам относятся неработающие ссылки, отключение серверов, потеря домена, несанкционированное редактирование, ненадежное закрепление файлов, цензура, утечки конфиденциальных данных и вводящие в заблуждение метаданные.
- Хранение с адресацией по содержимому, например IPFS, может повысить целостность: при изменении содержимого меняется его идентификатор.
- Постоянство хранения — не то же самое, что адресация по содержимому: файл должен оставаться доступным благодаря закреплению, хостингу или постоянному хранению.
- Динамические метаданные могут быть полезны для игр, развивающихся NFT, членских программ и токенизированных активов, но для их обновления необходим строгий контроль.
- Метаданные сами по себе не подтверждают авторские права, юридическое владение, подлинность или стоимость актива.
- Пользователям всегда следует проверять, где хранятся метаданные, кто может их изменять и доступны ли медиафайлы для получения.

Как работают офчейн-метаданные

Обычно работа офчейн-метаданных начинается со смарт-контракта, который хранит или возвращает URI.

URI может указывать на JSON-файл на сайте, CID в IPFS, транзакцию Arweave, объект в децентрализованном хранилище или другое внешнее место размещения данных.

Кошелек, обозреватель блокчейна, маркетплейс, игра или аналитический сервис считывает URI из блокчейна.

Затем приложение получает метаданные из внешнего источника.

Файл метаданных сообщает приложению, как отображать актив.

Например, tokenURI может возвращать ссылку на JSON-файл с названием токена, описанием, URI изображения, URI анимации и атрибутами.

Кошелек использует этот JSON-файл, чтобы показать пользователю изображение и характеристики NFT.

Блокчейн подтверждает владение токеном с определенным идентификатором.

Офчейн-метаданные объясняют, что должен представлять этот токен.

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

Офчейн-метаданные и ончейн-метаданные

Офчейн-метаданные хранятся вне блокчейна.

Ончейн-метаданные хранятся непосредственно в смарт-контракте или транзакции блокчейна либо формируются ими.

Офчейн-метаданные обычно дешевле, их проще обновлять, и они лучше подходят для больших файлов.

Ончейн-метаданные, как правило, долговечнее и прозрачнее и в меньшей степени зависят от внешней инфраструктуры.

Полностью ончейн-NFT может возвращать все ключевые метаданные непосредственно из контракта.

Типичный NFT с офчейн-метаданными может хранить в блокчейне только tokenURI, а JSON-файл — в другом месте.

Гибридный NFT может хранить важные неизменяемые характеристики в блокчейне, а медиафайлы или расширенные метаданные — вне его.

Оптимальная модель зависит от назначения актива.

Для генеративного искусства, рассчитанного на постоянное хранение, могут подойти ончейн-метаданные.

Для игрового предмета, который часто обновляется, могут быть удобны контролируемые офчейн-метаданные.

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

Зачем криптопроектам нужны офчейн-метаданные

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

Изображения, видео, аудиофайлы, 3D-модели, юридические документы и игровые данные могут быть намного объемнее обычных данных транзакций.

Прямое хранение этих данных в блокчейне может сделать выпуск и обновление токенов дорогими.

Офчейн-хранилища позволяют проектам уменьшить размер транзакций в блокчейне.

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

Офчейн-метаданные могут поддерживать и динамические сценарии использования.

Игра может обновлять уровень персонажа.

NFT членской программы может менять статус.

В токенизированном активе может обновляться оценочный документ.

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

Преимущество — гибкость, но за нее приходится платить дополнительным доверием к системе хранения и обновления.

Распространенные поля офчейн-метаданных

Самое распространенное поле метаданных — название актива.

Поле описания объясняет, что представляет собой актив.

Поле изображения указывает на визуальный файл для отображения.

Поле animation_url может указывать на видео, аудио, HTML-страницу или интерактивный контент, если приложения поддерживают такой формат.

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

Поле external_url может указывать на страницу проекта или актива.

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

В проекте стандарта ERC-7572 contractURI предлагается передавать метаданные контракта с помощью функции contractURI.

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

Некачественные метаданные затрудняют отображение, проверку и сравнение активов.

Офчейн-метаданные и tokenURI

tokenURI — одна из важнейших функций для метаданных NFT.

В ERC-721 функция tokenURI возвращает отдельный URI для конкретного идентификатора токена.

Этот URI может указывать на JSON-файл с описанием NFT.

Во многих коллекциях tokenURI указывает на внешний файл, а не возвращает метаданные непосредственно из контракта.

Такая схема удешевляет выпуск токенов и дает больше гибкости при хранении медиафайлов.

Но она также создает зависимость от места хранения JSON-файла.

Если сервер перестанет работать, токен может остаться в блокчейне, но изображение и описание могут перестать загружаться.

Если JSON-файл изменится, отображаемый NFT может измениться, хотя идентификатор токена останется прежним.

При оценке долгосрочного качества NFT пользователям следует проверять tokenURI.

URI может показать, использует ли проект обычный сервер, IPFS, Arweave или другой способ хранения.

Офчейн-метаданные и подстановка URI в ERC-1155

ERC-1155 — это стандарт для нескольких токенов, позволяющий управлять множеством типов токенов в одном контракте.

В шаблоне URI метаданных ERC-1155 в качестве заполнителя может использоваться строка {id}.

Клиентское программное обеспечение заменяет этот заполнитель фактическим идентификатором токена в стандартизированном шестнадцатеричном формате.

Так один шаблон URI может обслуживать множество идентификаторов токенов.

Например, один базовый путь может вести к множеству JSON-файлов с метаданными.

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

При этом разработчикам необходимо правильно структурировать внешние файлы.

Если схема именования файлов неверна, кошельки могут не найти нужные метаданные.

Если внешнюю папку переместить или изменить, одновременно могут перестать работать многие токены.

Метаданные ERC-1155 эффективны, но требуют тщательного управления хранилищем.

Офчейн-метаданные и IPFS

IPFS — один из наиболее распространенных вариантов хранения внешних метаданных и медиафайлов NFT.

В рекомендациях IPFS по данным NFT предлагается использовать URI IPFS для связывания смарт-контрактов с внешними данными в IPFS.

В IPFS для идентификации файлов по их содержимому используются идентификаторы контента — CID.

Если содержимое меняется, CID тоже меняется.

Поэтому IPFS лучше обычного веб-URL подходит для обнаружения подмены данных.

URI IPFS позволяет понять, что адресация файла основана на его содержимом, а не привязана к местоположению на одном сервере.

Однако IPFS автоматически не гарантирует, что контент будет доступен всегда.

Данные по-прежнему нужно закреплять, размещать на хостинге или сохранять на узлах, которые хранят копию.

В рекомендациях IPFS поясняется, что полученные копии могут быть временными и со временем удаляться, если их не закрепить.

Именно поэтому IPFS повышает целостность данных, но для постоянного хранения все равно нужен отдельный план.

Офчейн-метаданные и Arweave

Arweave — еще одна сеть хранения, используемая для криптовалютных метаданных и медиафайлов.

В документации Arweave сеть описывается как хранилище информации с постоянным доступом и децентрализованная сеть внутри открытого реестра.

Некоторые проекты используют Arweave, если хотят хранить метаданные или медиафайлы с более надежной моделью постоянного хранения.

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

С точки зрения другого блокчейна Arweave по-прежнему остается внешним уровнем хранения.

Если контракт NFT в одном блокчейне ссылается на данные Arweave, право владения записано в одном блокчейне, а медиафайлы или метаданные хранятся через Arweave.

По отношению к основному блокчейну NFT это все равно офчейн-метаданные.

Такая схема может быть надежной, если ссылка стабильна, а данные сохраняются.

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

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

Офчейн-метаданные и хранилища на базе Filecoin

Хранилища на базе Filecoin можно использовать для обеспечения постоянного доступа к офчейн-метаданным и медиафайлам.

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

Проект может использовать CID в IPFS для адресации контента, а хранилище Filecoin — для его долгосрочного сохранения.

Это помогает устранить разницу между целостностью и доступностью данных.

Целостность означает, что файл можно проверить по его идентификатору контента.

Доступность означает, что файл действительно можно получить, когда он нужен пользователям.

Для офчейн-метаданных важны оба свойства.

Идеальный CID бесполезен, если файл никто не хранит.

Высокая доступность сервера недостаточна, если файл можно незаметно изменить.

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

Метаданные HTTPS

Метаданные HTTPS хранятся по обычному веб-URL.

Такой способ удобен для разработчиков, а приложениям легко получать данные.

Он также совместим с обычными браузерами и веб-инфраструктурой.

Проблема в том, что метаданные HTTPS обычно зависят от домена, сервера, облачного аккаунта, политики доступа и оператора проекта.

Если срок регистрации домена истечет, метаданные могут исчезнуть.

Если сервер взломают, метаданные могут подменить.

Если проект отключит API, кошельки могут перестать отображать активы.

Если оператор изменит JSON-файл, отображение NFT может поменяться без обновления в блокчейне.

Хранение по HTTPS может быть приемлемым для временных или динамических активов, но хуже подходит для активов, для которых заявлено постоянное хранение.

Пользователям следует проявлять осторожность, если ценные NFT или токенизированные активы зависят только от обычных веб-URL.

Офчейн-метаданные и риск централизации

Риск централизации — один из основных недостатков офчейн-метаданных.

Исследования централизации метаданных NFT показали, что многие системы метаданных NFT используют централизованное хранение. Это может создавать риски цензуры, утечки данных, административных изменений и потери контроля.

Централизованный сервер может работать быстро и быть удобным, но одновременно стать единой точкой отказа.

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

Если облачный сервис заблокирует аккаунт, метаданные могут перестать загружаться.

Если злоумышленник получит доступ к серверу, пользователи могут увидеть вредоносные ссылки или поддельные изображения.

Если проект исчезнет, вместе с ним могут пропасть и файлы.

Это не означает, что все офчейн-метаданные плохи.

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

Проект, заявляющий о постоянном хранении, не должен полагаться только на ненадежный централизованный хостинг.

Офчейн-метаданные и динамические NFT

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

Персонаж игры может повышать уровень.

У спортивного предмета коллекционирования могут обновляться статистические данные.

У членского токена может меняться уровень доступа.

У токена реального актива может обновляться статус документов.

Генеративное произведение искусства может открывать новые состояния при выполнении определенных условий.

Офчейн-метаданные упрощают такие обновления: JSON-файл или API можно изменить без развертывания нового контракта.

Риск заключается в том, что полномочия на обновление могут оказаться слишком широкими.

Если эмитент может в любой момент изменить любые характеристики, покупатель может не понимать, чем именно он владеет.

Для динамических метаданных нужны четкие правила, события обновления, средства контроля доступа и общедоступная документация.

Гибкость не должна превращаться в скрытый контроль.

События обновления метаданных

События обновления метаданных помогают приложениям понять, когда нужно обновить кешированные данные.

В расширении ERC-4906 для обновления метаданных для токенов ERC-721 добавляются события MetadataUpdate и BatchMetadataUpdate.

Это полезно, поскольку кошельки и индексаторы часто кешируют метаданные, а не загружают их каждый раз заново.

Если метаданные изменятся, но сигнал об обновлении не будет отправлен, пользователи могут видеть старые изображения или атрибуты.

В ERC-4906 также отмечается важность контроля разрешений при изменении офчейн-метаданных.

Это важно, потому что функция обновления метаданных может стать чувствительным административным полномочием.

Если обновлениями может управлять неправильный аккаунт или он может их запускать, доверие пользователей может пострадать.

Проектам с динамическими офчейн-метаданными следует сделать механизм обновления предсказуемым.

Также следует документировать, кто и по каким причинам может обновлять метаданные.

Пользователям стоит проверять, могут ли метаданные измениться после выпуска или покупки токена.

Офчейн-метаданные уровня контракта

Метаданные уровня контракта описывают контракт или коллекцию, а не отдельный идентификатор токена.

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

В ERC-7572 предлагается использовать contractURI, чтобы контракты могли возвращать метаданные уровня контракта.

Возвращаемая строка contractURI может указывать на внешний ресурс или возвращать ончейн-данные в формате JSON.

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

Метаданные уровня контракта могут повысить удобство использования, но при злонамеренном изменении также могут вводить пользователей в заблуждение.

Поддельный или взломанный файл метаданных контракта может отображать знакомый логотип или название.

Пользователям не следует доверять только метаданным контракта.

Важны также адрес контракта, исходный код, история эмитента и официальные каналы связи.

Отображаемые данные должны помогать проверке, а не заменять ее.

Офчейн-метаданные и новые ончейн-стандарты

Новые стандарты метаданных показывают, что разработчики пытаются снизить некоторые риски, связанные с внешним хранением.

В проекте предложения ERC-8049 определяется стандарт хранения метаданных уровня контракта в блокчейне.

В предложении объясняется, что метаданные контрактов часто зависят от внешних URL или IPFS, что может создавать риски, связанные с доверием и доступностью.

ERC-8049 не является универсальной заменой всем офчейн-метаданным.

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

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

Другие проекты могут перенести в блокчейн основные данные об идентичности, оставив вне его только объемные медиафайлы.

Вероятное направление развития — гибридные метаданные.

Критически важные сведения об идентичности могут стать более проверяемыми в блокчейне.

Большие медиафайлы, конфиденциальные документы и часто меняющиеся данные могут остаться вне блокчейна, но с более надежными доказательствами целостности.

Офчейн-метаданные и механика раскрытия

Во многих коллекциях NFT используется механика раскрытия.

До раскрытия все токены могут указывать на одни и те же метаданные-заполнитель.

После раскрытия каждый токен получает уникальные метаданные.

Такой подход может вызвать интерес и затруднить ранний отбор редких характеристик.

Но если процесс раскрытия непрозрачен, он требует доверия.

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

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

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

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

Условия честного раскрытия должны быть понятны пользователям до выпуска NFT.

Офчейн-метаданные и заморозка метаданных

Заморозка метаданных означает запрет на дальнейшее изменение метаданных после определенного момента.

После раскрытия проект может заморозить метаданные, чтобы пользователи знали: актив не изменится неожиданно.

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

Заморозка может повысить доверие коллекционеров, поскольку отображаемый актив становится более стабильным.

Однако она также может закрепить ошибки.

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

Перед заморозкой проектам следует тщательно проверять метаданные.

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

Публичное обещание слабее технического механизма, который нельзя обойти.

Контракт и система хранения должны соответствовать обещаниям проекта.

Офчейн-метаданные и токенизированные активы реального мира

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

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

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

Некоторая информация может быть общедоступной.

Для доступа к другой информации могут потребоваться ограничения.

Размещение конфиденциальных юридических документов непосредственно в публичном блокчейне может создать проблемы с конфиденциальностью и соблюдением требований.

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

Хеш помогает проверить, не изменился ли документ.

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

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

Офчейн-метаданные и игры

В блокчейн-играх часто используются офчейн-метаданные, поскольку игровые активы могут часто меняться.

Меч может стать мощнее.

Персонаж может повысить уровень.

Характеристики земельного участка могут измениться после строительства игрока.

Для облика персонажа могут открыться новые визуальные состояния.

Частые ончейн-обновления могут быть дорогими и медленными, поэтому игровые студии могут хранить изменяемые метаданные вне блокчейна.

Это может сделать игровой процесс более плавным.

Но игрокам придется доверять правилам обновления, установленным игрой.

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

Качественные игровые метаданные должны четко отделять постоянное владение от изменяемого состояния предмета в игре.

Игроки должны знать, какие характеристики неизменны, а какие могут меняться.

Офчейн-метаданные и цифровая идентификация

В системах цифровой идентификации могут использоваться офчейн-метаданные для защиты конфиденциальности.

Учетные данные могут подтверждать статус, членство, лицензию или достижение пользователя.

Исходные персональные данные, на которых основано подтверждение, обычно следует хранить вне блокчейна.

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

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

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

Такая схема может одновременно обеспечивать проверку и конфиденциальность.

В то же время она может создавать зависимость от эмитентов учетных данных, провайдеров хранения и систем доступа.

При работе с метаданными идентификации следует руководствоваться принципом минимизации данных.

В блокчейне следует размещать только те сведения, которые действительно необходимо проверять публично.

Офчейн-метаданные и конфиденциальность

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

Однако хранение вне блокчейна не означает автоматической защиты конфиденциальности.

Файл метаданных HTTPS все равно может быть общедоступным.

Любой, кто знает CID файла IPFS, может получить к нему доступ, если контент доступен.

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

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

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

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

Удаление исходного файла с сервера может не привести к удалению всех копий.

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

Офчейн-метаданные и авторские права

Офчейн-метаданные сами по себе не подтверждают право собственности на авторские права.

В файле метаданных может утверждаться, что NFT представляет известное изображение, песню, игровой предмет или объект реального мира.

Это утверждение может быть ложным.

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

В поле изображения метаданных может находиться ссылка на скопированное произведение.

В поле описания могут содержаться вводящие в заблуждение формулировки о лицензии.

Сайт проекта может исчезнуть после того, как покупатели на него положились.

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

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

Метаданные фиксируют утверждения, но не делают каждое из них истинным.

Офчейн-метаданные и безопасность

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

Вредоносный файл метаданных может содержать фишинговые ссылки.

Взломанный сервер может заменить безопасное изображение вредоносным призывом к действию.

Поддельная коллекция может скопировать название, изображение и описание настоящего актива.

Кошелек может показывать знакомую символику, хотя адрес контракта неверный.

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

Приложениям следует считать метаданные недоверенными входными данными.

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

Пользователям следует проверять адреса контрактов и с осторожностью переходить по ссылкам в описаниях активов.

Если отображение актива зависит от внешних файлов, безопасность не ограничивается смарт-контрактом.

Офчейн-метаданные и индексаторы

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

Когда метаданные хранятся вне блокчейна, индексаторы обычно получают tokenURI или contractURI и кешируют возвращенный JSON.

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

Но если метаданные меняются, а индексатор не обновляет их, данные могут устареть.

События обновления, например ERC-4906, помогают индексаторам понять, когда нужно повторно получить метаданные.

Без таких событий приложения могут отображать старые изображения или характеристики.

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

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

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

Если что-то выглядит неправильно, может помочь проверка исходного URI.

Офчейн-метаданные и отображение в кошельке

Кошельки активно используют метаданные, чтобы сделать токены понятными пользователям.

На основе офчейн-метаданных кошелек может отображать название токена, изображение, символ, коллекцию, характеристики и описание.

Если метаданные отсутствуют, кошелек может показать пустое изображение или неизвестный актив.

Если метаданные загружаются медленно, отображение актива может задержаться.

Если метаданные изменятся, кошелек может показать новое изображение или новые характеристики.

Если метаданные вредоносны, кошелек может отображать вводящую в заблуждение информацию.

Поэтому метаданные важны и для удобства, и для безопасности пользователей.

Отображение токена может повлиять на то, подпишет ли пользователь транзакцию, примет ли предложение или доверится ли коллекции.

По возможности кошелькам следует показывать адреса контрактов и предупреждения.

Пользователям не следует полагаться только на изображение, которое появляется в кошельке.

Офчейн-метаданные и DAO

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

Токен управления или NFT может указывать на метаданные, описывающие права голоса, роли участников или историю активности.

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

Хранение всех документов по управлению непосредственно в блокчейне может быть дорогим и раскрывать конфиденциальную информацию.

Офчейн-метаданные могут сделать управление DAO более практичным.

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

DAO могут снизить этот риск, сохраняя хеши документов, используя ссылки с адресацией по содержимому и архивируя окончательные материалы предложений.

Участники голосования должны знать, совпадает ли прочитанный ими документ с тем, который был одобрен.

Для управления важны четкие записи.

Удобство офчейн-хранения не должно снижать подотчетность.

Офчейн-метаданные и активы, созданные ИИ

Метаданные активов, созданных ИИ, могут содержать описания промптов, версий модели, дат создания, кошельков создателей, лицензий и сведений о происхождении.

Эта информация может быть слишком объемной или конфиденциальной для полного хранения в блокчейне.

Офчейн-метаданные позволяют хранить более подробную историю создания.

При ненадежной архитектуре хранения их также можно изменить или удалить.

В файле метаданных может утверждаться, что изображение создано определенной моделью или автором.

Это утверждение все равно требует проверки.

В метаданных NFT, созданных ИИ, следует различать фактические данные, утверждения создателя и юридические права.

Хеш исходного медиафайла или пакета промптов может помочь доказать, что файл не изменился.

Однако хеш не подтверждает, что контент создан законно, является оригинальным или не нарушает чужих прав.

Метаданные активов, созданных ИИ, должны быть прозрачными и не преувеличивать объем подтверждаемых ими сведений.

Преимущества офчейн-метаданных

Первое преимущество офчейн-метаданных — более низкая стоимость.

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

Второе преимущество — гибкость.

Метаданные подходят для динамических активов, игровых обновлений, раскрытия, исправлений и меняющихся записей.

Третье преимущество — поддержка мультимедийного контента.

Видео, аудиофайлы, 3D-модели и изображения высокого разрешения удобнее хранить вне блокчейна.

Четвертое преимущество — возможность управлять конфиденциальностью.

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

Пятое преимущество — более высокая производительность.

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

Шестое преимущество — простая интеграция.

Кошельки, обозреватели, игры и индексаторы широко поддерживают JSON-метаданные и стандартные URI.

Риски и ограничения офчейн-метаданных

Первый риск — неработающие ссылки.

Если URL метаданных перестанет работать, актив может отображаться некорректно.

Второй риск — несанкционированные изменения.

Если файл метаданных можно редактировать, актив может измениться после покупки.

Третий риск — централизация.

Единый сервер или облачный аккаунт может стать точкой отказа.

Четвертый риск — низкая доступность.

Контент IPFS может оказаться недоступным, если его никто не закрепляет и не размещает на хостинге.

Пятый риск — утечка конфиденциальной информации.

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

Шестой риск — вводящие в заблуждение утверждения.

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

Седьмой риск — несогласованность кешированных данных.

Разные кошельки или индексаторы могут показывать разные версии одного актива.

Распространенные ошибки при работе с офчейн-метаданными

Одна из распространенных ошибок — считать, что владение NFT означает хранение медиафайла в блокчейне.

Во многих NFT право владения записано в блокчейне, а метаданные хранятся вне его.

Другая ошибка — использовать обычный HTTPS-URL для коллекции, которая должна храниться постоянно.

Третья ошибка — использовать IPFS, но не обеспечивать надежное закрепление данных.

Четвертая ошибка — изменять метаданные, не отправляя события обновления.

Пятая ошибка — предоставлять одному административному кошельку неограниченные полномочия на изменение метаданных и не сообщать об этом.

Шестая ошибка — хранить личные данные пользователей в публичных метаданных.

Седьмая ошибка — воспринимать метаданные как юридическое доказательство авторских прав.

Восьмая ошибка — не создавать резервные копии медиафайлов перед выпуском токенов.

Девятая ошибка — использовать нестандартные поля, которые кошельки не могут прочитать.

Десятая ошибка — не проверять отображение метаданных в разных кошельках и обозревателях блокчейна.

Когда полезны офчейн-метаданные

Офчейн-метаданные полезны, если файлы слишком велики для эффективного хранения в блокчейне.

Они подходят для активов с изображениями высокого разрешения, видео, аудио, 3D-моделями или интерактивным контентом.

Они полезны, когда метаданные должны меняться в зависимости от состояния игры, статуса членства или событий реального мира.

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

Они подходят проектам, которым важны быстрая загрузка и широкая поддержка приложений.

Они полезны, если адресация по содержимому или постоянное хранение позволяют обеспечить надежную целостность и доступность.

Их применяют для NFT, игровых предметов, токенизированных активов, учетных данных, записей DAO и данных для отображения контрактов.

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

Они менее полезны, если правила обновления неясны или предоставляют слишком широкие полномочия.

Их опасно использовать, если публичные файлы метаданных раскрывают конфиденциальную информацию.

Офчейн-метаданные: кратко

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

FAQ

Что означает «офчейн-метаданные»?

Это описательная информация об активе, которая хранится вне блокчейна, но связана с токеном, контрактом, URI, хешем или указателем в блокчейне.

Офчейн-метаданные — это плохо?

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

Почему NFT используют офчейн-метаданные?

Изображения, видео, JSON-файлы и атрибуты могут быть слишком объемными или дорогими для прямого хранения в блокчейне.

Что такое tokenURI?

tokenURI — распространенная функция NFT, которая возвращает URI, по которому можно найти метаданные конкретного идентификатора токена.

В чем риск метаданных HTTPS?

Метаданные HTTPS могут перестать работать или измениться, если сервер, домен, облачный аккаунт или оператор проекта выйдет из строя либо будет скомпрометирован.

Метаданные IPFS относятся к офчейн-данным?

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

Гарантирует ли IPFS постоянную доступность?

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

Можно ли изменить офчейн-метаданные?

Да. Если проект или сервер контролирует файл, метаданные можно изменить, если только в системе не предусмотрены неизменяемые ссылки, заморозка метаданных или надежные обязательства по содержимому.

Что такое динамические метаданные?

Это метаданные, которые меняются со временем в зависимости от обновлений, состояния игры, достижений, данных оракулов, статуса членства или правил эмитента.

Подтверждают ли метаданные право собственности на авторские права?

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

Как пользователям проверить офчейн-метаданные?

Можно проверить tokenURI и способ хранения, сверить хеши или CID, изучить разрешения на обновление и убедиться, что метаданные и медиафайлы доступны.

Какая архитектура офчейн-метаданных наиболее надежна?

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

Заключение

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

Без метаданных токен может представлять собой лишь адрес, идентификатор и баланс.

С метаданными пользователи видят название, изображение, описание, характеристики, документы, медиафайлы и контекст.

Широкое распространение офчейн-метаданных объясняется практическими причинами.

Хранение больших файлов в блокчейне обходится дорого.

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

Это упрощает разработку и отображение NFT, токенизированных активов, игр, учетных данных и профилей контрактов.

Однако офчейн-метаданные меняют модель доверия.

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

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

Обычные веб-серверы просты в использовании, но ненадежны для долгосрочного хранения криптоактивов.

IPFS повышает целостность благодаря адресации по содержимому, но для доступности файлов по-прежнему необходимо закрепление и планирование хранения.

Arweave и другие системы постоянного хранения могут улучшить долгосрочный доступ, но пользователям все равно следует проверять, что именно хранится и на что указывают ссылки.

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

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

Используйте стандарты, понятные кошелькам и индексаторам.

Если важна целостность, используйте хранение с адресацией по содержимому.

Если внешние документы требуют проверки, храните их хеши или обязательства.

При изменении метаданных отправляйте события обновления.

Контролируйте разрешения на обновление.

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

Пользователям безопаснее изучить способ хранения, прежде чем доверять активу.

Красивого изображения в кошельке недостаточно.

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

Сами по себе офчейн-метаданные не являются недостатком.

Это компромисс.

При грамотном использовании они делают криптоактивы более выразительными, доступными и полезными.

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