Формат JSON-метаданных

Что такое формат JSON-метаданных?

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

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

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

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

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

В официальной спецификации JSON IETF RFC 8259 JSON описан как легковесный формат обмена данными с небольшим набором правил форматирования переносимых структурированных данных.

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

Почему формат JSON-метаданных важен для криптоиндустрии

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

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

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

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

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

Разработчики используют JSON, потому что этот формат прост, широко поддерживается, легко читается и обрабатывается программами.

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

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

Как работает формат JSON-метаданных

В формате JSON-метаданных информация организуется в пары «ключ — значение».

Ключ — это название поля, например

, , или .

Значение — это информация, связанная с ключом.

Например, ключу

может соответствовать значение .

Ключ

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

Смарт-контракт может возвращать URI — идентификатор ресурса, указывающий на файл JSON с метаданными.

Кошелёк или dApp считывает этот URI, получает JSON, обрабатывает его поля и отображает пользователю информацию об активе.

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

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

Пример JSON-метаданных

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

Пример метаданных в стиле NFT может выглядеть так внутри файла JSON.

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

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

Описание дает контекст.

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

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

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

Формат JSON-метаданных и NFT

Чаще всего обычные пользователи криптовалют сталкиваются с форматом JSON-метаданных именно при работе с NFT.

В официальном стандарте токенов ERC-721 предусмотрено необязательное расширение для метаданных с функциями

, и .

Схема JSON-метаданных ERC-721 включает распространенные поля, такие как

, и .

Обычно смарт-контракт не хранит полный файл JSON для каждого NFT.

Вместо этого контракт предоставляет URI токена, указывающий на метаданные каждого идентификатора токена.

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

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

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

Формат JSON-метаданных и ERC-1155

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

В официальном стандарте токенов ERC-1155 предусмотрена логика URI метаданных и описана схема JSON-метаданных ERC-1155.

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

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

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

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

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

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

Распространенные поля в JSON-метаданных криптоактивов

Поле

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

Поле

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

Поле

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

Поле

часто используют NFT-проекты для ссылки на видео, аудио, 3D-, HTML- или интерактивный контент, если приложение его поддерживает.

Поле

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

Поле

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

Поле

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

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

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

Формат JSON-метаданных и стандарты токенов

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

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

В ERC-721 функция

может указывать на метаданные отдельного NFT.

В ERC-1155 функция

может указывать на метаданные типов токенов.

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

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

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

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

Формат JSON-метаданных и JSON Schema

JSON Schema — это способ описать структуру корректного документа JSON.

На официальной странице спецификации JSON Schema описаны схемы для проверки и определения структуры JSON-документов.

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

Например, схема может требовать, чтобы

было строкой, а — массивом.

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

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

JSON Schema не доказывает, что информация правдива.

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

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

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

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

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

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

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

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

Ни один из этих подходов не является лучшим во всех случаях.

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

Формат JSON-метаданных и IPFS

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

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

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

Если файл метаданных изменится, CID обычно тоже изменится.

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

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

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

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

Формат JSON-метаданных и Arweave

Еще один вариант хранения метаданных и медиафайлов для криптопроектов — Arweave.

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

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

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

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

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

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

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

Централизованные URL в JSON-метаданных

В некоторых файлах метаданных содержатся ссылки

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

Это может быть просто и быстро, но создает риск централизации.

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

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

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

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

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

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

Изменяемые и неизменяемые JSON-метаданные

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

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

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

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

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

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

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

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

Формат JSON-метаданных и динамические NFT

В динамических NFT метаданные могут меняться со временем.

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

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

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

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

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

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

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

Формат JSON-метаданных и токенизированные активы реального мира

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

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

Однако JSON-метаданные не равнозначны юридическому праву собственности.

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

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

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

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

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

Формат JSON-метаданных и децентрализованная идентификация

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

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

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

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

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

Однако при плохом проектировании метаданные идентификации могут раскрывать конфиденциальную информацию.

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

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

Формат JSON-метаданных и отображение в кошельках

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

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

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

Это не всегда означает, что актив исчез.

Возможно, сервер метаданных не работает, файл JSON некорректен, URI указан неверно или кошелёк не поддерживает этот формат.

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

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

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

Формат JSON-метаданных и обозреватели блокчейна

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

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

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

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

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

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

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

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

Формат JSON-метаданных и редкость NFT

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

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

Оценка редкости во многом зависит от точности и единообразия метаданных.

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

Например, программное обеспечение может считать

, и разными значениями.

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

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

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

Формат JSON-метаданных и игровые активы

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

Метаданные игры могут быть статическими или динамическими — это зависит от ее устройства.

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

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

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

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

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

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

Формат JSON-метаданных и безопасность

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

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

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

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

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

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

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

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

Формат JSON-метаданных и конфиденциальность

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

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

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

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

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

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

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

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

Формат JSON-метаданных и подлинность

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

Мошенник может создать JSON-файл с названием, изображением и описанием настоящего проекта.

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

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

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

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

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

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

Формат JSON-метаданных и доступность данных

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

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

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

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

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

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

Пользователям следует проверить, используют ли метаданные централизованный URL, CID IPFS, транзакцию Arweave, ончейн-кодирование или другую систему хранения.

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

Формат JSON-метаданных и их фиксация

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

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

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

Однако при фиксации могут сохраниться и ошибки.

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

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

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

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

Распространенные ошибки разработчиков при работе с форматом JSON-метаданных

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

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

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

Четвертая — изменение метаданных без уведомления пользователей.

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

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

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

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

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

Распространенные заблуждения пользователей о формате JSON-метаданных

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

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

Другое заблуждение — изображение NFT всегда хранится ончейн.

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

Третье заблуждение — метаданные нельзя изменить.

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

Четвертое заблуждение — знакомое изображение подтверждает подлинность актива.

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

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

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

Рекомендации разработчикам

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

Проверяйте файлы JSON до выпуска токенов или публикации активов.

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

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

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

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

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

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

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

Рекомендации пользователям криптовалют

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

Узнайте, где хранятся метаданные: на централизованном сервере, в IPFS, Arweave, блокчейне или другой системе.

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

Не подключайте кошелёк к неизвестным ссылкам из описаний активов.

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

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

Помните: поврежденные метаданные не всегда означают потерю права владения.

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

Часто задаваемые вопросы

Что такое формат JSON-метаданных?

Это структурированный способ описывать криптоактивы, NFT, токены, dApp или записи идентификации с помощью пар «ключ — значение» в формате JSON.

Формат JSON-метаданных — это криптовалюта?

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

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

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

Подтверждают ли JSON-метаданные право владения NFT?

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

Можно ли изменить JSON-метаданные после выпуска токена?

Да. Метаданные можно изменить, если они связаны с изменяемым URI, централизованным сервером или контрактом, допускающим обновления.

Какие поля часто встречаются в JSON-метаданных NFT?

Часто используются поля

, , , , и иногда поля, связанные с медиафайлами, например .

Чем отличаются ончейн- и офчейн-метаданные?

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

Метаданные в IPFS хранятся постоянно?

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

Подходит ли Arweave для JSON-метаданных?

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

Могут ли JSON-метаданные быть опасными?

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

Стоит ли доверять NFT, если его метаданные выглядят убедительно?

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

Как лучше всего хранить JSON-метаданные?

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

Заключение

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

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

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

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

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

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

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

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

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

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

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