Схема метаданных токена

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

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

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

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

, , , и ссылки на медиафайлы.

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

Официальный стандарт ERC-721 указывает, что URI токена может вести к JSON-файлу, соответствующему ERC-721 Metadata JSON Schema.

Официальный стандарт ERC-1155 определяет ERC-1155 Metadata URI JSON Schema для мульти-токен-контрактов.

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

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

Новичку проще всего представить Token Metadata Schema как формат этикетки для криптоактива.

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

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

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

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

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

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

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

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

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

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

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

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

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

Схема метаданных токена и Token URI

Token URI — это ссылка или идентификатор, указывающий на метаданные токена.

Token Metadata Schema — это структура данных, находящихся по этой ссылке или в закодированном ответе.

Например, контракт ERC-721 может вернуть

из .

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

Token URI — это адрес метаданных.

Token Metadata Schema — это формат метаданных.

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

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

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

Хороший дизайн NFT требует как надежного Token URI, так и понятной схемы метаданных токена.

Схема метаданных токена в ERC-721

ERC-721 — классический стандарт уникальных NFT в сетях типа Ethereum.

Расширение метаданных ERC-721 включает

, и .

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

, и .

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

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

Каждый ID токена может иметь собственный файл метаданных.

Это означает, что Token ID 1 может иметь другое изображение, название и атрибуты, чем Token ID 2.

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

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

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

Схема метаданных токена в ERC-1155

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

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

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

Стандарт ERC-1155 позволяет URI содержать заполнитель

.

Клиентское программное обеспечение заменяет

фактическим ID токена перед получением метаданных.

Официальная документация OpenZeppelin по ERC-1155 Metadata URI поясняет, что расширение URI метаданных направляет каждый токен к JSON-файлу, соответствующему ERC-1155 Metadata URI JSON Schema.

Метаданные ERC-1155 могут включать такие поля, как

, , , и другие данные конкретного токена.

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

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

Надежный дизайн метаданных ERC-1155 делает каждый ID токена понятным для интерпретации и надежного получения данных.

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

Наиболее распространенное поле —

, задающее понятное человеку название токена.

Следующее распространенное поле —

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

Поле

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

Поле

может указывать на более насыщенный медиаконтент, например видео, аудио, 3D-объекты или интерактивный контент, если он поддерживается клиентом.

Поле

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

Поле

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

Поле

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

Поле

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

Некоторые проекты добавляют такие поля, как

, , , или .

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

Пример базовой схемы метаданных NFT

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

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

Схема достаточно проста для обработки кошельками и dApp.

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

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

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

Лучшие метаданные одновременно машиночитаемы и понятны людям.

Поле Name

Поле

задает отображаемое название токена.

Для NFT-коллекции распространенный подход — использовать название коллекции и номер токена.

Например:

.

Игровой предмет может иметь название

или .

Токен членства может иметь название

.

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

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

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

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

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

Поле Description

Поле

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

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

Для художественных NFT описание может объяснять концепцию или тему коллекции.

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

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

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

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

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

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

Описание не является независимой проверкой качества или легитимности токена.

Поле Image

Поле

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

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

Изображение может храниться в IPFS, Arweave, на HTTPS-серверах или быть закодировано непосредственно в метаданных.

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

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

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

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

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

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

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

Поле Attributes

Поле

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

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

и .

Например, значением

может быть , а значением — .

Для игрового предмета значением

может быть , а значением — .

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

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

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

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

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

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

Поле Properties

Поле

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

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

.

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

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

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

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

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

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

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

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

Схема метаданных токена и IPFS

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

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

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

Если JSON-метаданные изменяются, CID также должен измениться.

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

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

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

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

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

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

Схема метаданных токена и HTTP-хранилище

Некоторые проекты хранят метаданные на стандартных HTTPS-серверах.

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

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

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

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

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

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

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

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

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

Схема метаданных токена и ончейн-метаданные

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

Это может уменьшить зависимость от внешних систем хранения.

Контракт может возвращать URI

, содержащий закодированные метаданные.

Метаданные могут включать ончейн-изображение SVG или логику генеративного искусства.

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

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

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

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

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

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

Схема метаданных токена и динамические NFT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Схема метаданных токена и метаданные уровня контракта

Метаданные на уровне токена описывают конкретный ID токена.

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

Официальный стандарт метаданных уровня контракта ERC-7572 стандартизирует

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

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

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

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

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

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

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

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

Схема метаданных токена и ERC-1046

ERC-1046 расширяет идеи Token URI за пределы базовых вариантов использования NFT.

Официальное предложение совместимости tokenURI ERC-1046 добавляет поддержку URI токенов для ERC-20 и расширяет совместимость метаданных между разными типами токенов.

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

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

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

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

Мошеннический токен может иметь красивый логотип и описание.

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

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

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

Схема метаданных токена и ERC-5625

ERC-5625 — предлагаемое расширение метаданных, связанное с информацией о децентрализованном хранении NFT.

Официальное расширение dStorage для NFT Metadata JSON Schema ERC-5625 добавляет в метаданные NFT свойство децентрализованного хранилища, чтобы яснее описывать информацию о хранении активов.

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

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

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

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

Метаданные о хранении сами по себе не гарантируют постоянства.

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

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

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

Валидация схемы

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

Валидатор может проверить, действителен ли JSON.

Он может проверить наличие обязательных полей.

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

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

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

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

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

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

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

Схема метаданных и редкость

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

в метаданных NFT.

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

Например,

, и некоторые инструменты могут считать разными значениями.

Если один токен использует

, а другой — , инструменты оценки редкости могут разделить категорию характеристики.

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

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

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

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

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

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

Схема метаданных и игровые активы

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

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

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

Некоторые из этих полей могут меняться в ходе игры.

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

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

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

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

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

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

Схема метаданных и активы реального мира

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

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

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

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

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

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

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

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

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

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

Схема метаданных и риски безопасности

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

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

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

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

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

Кошелькам и dApp следует считать метаданные недоверенным входным материалом.

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

Им следует по возможности очищать внешние ссылки и медиаконтент.

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

Чистая на вид схема метаданных не доказывает безопасность токена.

Схема метаданных и изменяемость

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

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

Другие проекты обещают, что метаданные будут постоянными и неизменными.

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

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

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

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

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

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

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

Схема метаданных и кэширование

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

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

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

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

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

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

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

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

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

Надежная схема метаданных лучше всего работает в сочетании с корректным обновлением кэша.

Схема метаданных и индексаторы

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

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

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

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

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

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

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

Поэтому согласованность схем помогает всей экосистеме Web3.

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

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

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

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

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

, , и .

Возвращайте действительный JSON из каждого Token URI.

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

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

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

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

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

Валидируйте метаданные до их постоянной публикации.

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

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

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

Проверяйте, хранятся ли метаданные токена в IPFS, на сервере, в Arweave или ончейн.

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

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

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

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

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

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

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

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

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

Распространенные ошибки в схемах метаданных токенов

Первая ошибка — публикация недействительного JSON.

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

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

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

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

Шестая ошибка — забыть о требованиях подстановки

в ERC-1155.

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

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

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

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

FAQ

Что означает Token Metadata Schema?

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

Схема метаданных токена используется только для NFT?

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

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

Распространенные поля включают

, , , , и .

В чем разница между Token URI и Token Metadata Schema?

Token URI указывает на метаданные, а Token Metadata Schema определяет структуру метаданных, находящихся по этому адресу.

Что такое ERC-721 Metadata JSON Schema?

Это базовая схема метаданных, описанная ERC-721 для метаданных NFT, возвращаемых через URI токена.

Что такое ERC-1155 Metadata URI JSON Schema?

Это схема метаданных, используемая токенами ERC-1155, включая поддержку подстановки ID токена через

.

Можно ли хранить метаданные токена в IPFS?

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

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

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

Могут ли метаданные токена измениться после минтинга?

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

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

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

Для чего используется ERC-4906?

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

Для чего используется ERC-7572?

ERC-7572 стандартизирует

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

Могут ли метаданные быть вредоносными?

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

Почему характеристики NFT иногда отображаются некорректно?

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

Что делает схему метаданных токена качественной?

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

Заключение

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

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

ERC-721 и ERC-1155 определяют шаблоны метаданных, помогающие приложениям последовательно находить и отображать информацию о токенах.

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

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

Важные поля включают

, , , , и свойства конкретного проекта.

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

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

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

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

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