Стандарты метаданных

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

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

Метаданные — это данные, описывающие другой актив или объект данных.

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

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

Без общего стандарта одно приложение может использовать поле

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

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

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

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

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

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

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

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

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

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

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

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

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

Стандарт метаданных и метаданные

Метаданные — это фактическая описательная информация, связанная с активом.

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

Текст «Digital Access Pass» может быть названием токена, сохраненным в метаданных.

Стандарт может определять, что название токена нужно помещать в поле

и указывать в виде строки.

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

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

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

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

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

Схема может требовать, чтобы

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

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

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

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

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

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

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

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

Основные элементы стандартов криптометаданных

Идентификаторы

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

К примерам относятся идентификаторы сетей, адреса контрактов, ID токенов, децентрализованные идентификаторы, URL, URI и идентификаторы контента.

Названия полей

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

К распространенным полям относятся

, , , , , и .

Типы данных

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

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

Обязательные и необязательные поля

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

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

Правила URI

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

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

Правила обновления

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

Правила целостности

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

Правила проверки

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

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

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

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

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

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

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

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

Метаданные вне блокчейна

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

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

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

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

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

Гибридные метаданные

Гибридные метаданные сочетают информацию в блокчейне с файлами вне блокчейна.

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

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

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

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

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

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

Поле

содержит понятное название актива.

Поле

содержит сокращенное обозначение, похожее на тикер.

Значение

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

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

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

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

Метаданные о десятичных знаках

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

Отображаемый баланс токена = исходный баланс токена / 10^Decimals

Исходный баланс 250,000,000 при шести десятичных знаках отображается как 250 токенов.

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

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

Стандарт метаданных ERC-721

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

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

, и .

Функция

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

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

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

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

Распространенные поля метаданных ERC-721

Название

Поле

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

Описание

Поле

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

Изображение

Поле

содержит URI изображения, связанного с токеном.

URL анимации

Поле

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

Внешний URL

Поле

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

Атрибуты

Массив

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

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

Стандарт метаданных ERC-1155

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

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

Функция

возвращает URI метаданных для типа токена.

Стандарт допускает использование заполнителя

в значениях метаданных.

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

.

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

Схема ERC-1155 включает такие поля, как name, description, image, decimals и properties.

Метаданные ERC-721 и ERC-1155

ERC-721 обычно возвращает URI конкретного токена через

.

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

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

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

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

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

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

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

Событие

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

Событие

указывает на непрерывный диапазон затронутых идентификаторов токенов.

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

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

Новые стандарты ончейн-метаданных

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

ERC-8048 был представлен в сентябре 2025 года как проект предложения по хранению метаданных в формате «ключ — значение» непосредственно в реестрах мульти-токенов и NFT.

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

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

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

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

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

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

Стандарт JSON IETF определяет объекты, массивы, строки, числа, логические значения и значения null.

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

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

Корректный JSON не доказывает, что документ соответствует схеме метаданных токена.

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

Пример структуры метаданных NFT

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

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

JSON Schema

JSON Schema задает машиночитаемые правила проверки структуры и значений документа JSON.

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

В 2026 году официальная JSON Schema Draft 2020-12 остается последней опубликованной версией общей спецификации.

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

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

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

Метаданные JSON-LD

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

В действующей рекомендации JSON-LD 1.1 определен формат на основе JSON для совместимых связанных данных.

Свойство

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

Свойство

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

Свойство

указывает тип описываемой сущности.

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

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

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

Унифицированный идентификатор ресурса (URI) идентифицирует цифровой или физический ресурс с помощью стандартизированного набора символов.

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

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

, и .

URI HTTPS указывает на местоположение, контролируемое через веб-домен и сервер.

URI IPFS идентифицирует контент по его идентификатору.

URI данных включает содержимое непосредственно в сам URI.

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

Адресация по местоположению и адресация по содержимому

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

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

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

При одинаковых правилах кодирования и хеширования идентификатор содержимого меняется вместе с самим содержимым.

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

Метаданные IPFS

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

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

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

URI токена может иметь формат

и указывать на документ метаданных или файл.

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

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

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

Целостность метаданных

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

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

Целостность метаданных подтверждена, если вычисленный хеш = доверенному ожидаемому хешу

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

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

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

Подлинность метаданных

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

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

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

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

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

Неизменяемые метаданные

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

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

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

Неизменяемый документ JSON все еще может указывать на внешнее изображение, которое меняется.

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

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

Изменяемые метаданные

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

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

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

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

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

Замороженные метаданные

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

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

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

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

Версионирование метаданных

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

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

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

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

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

Межсетевые стандарты метаданных

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

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

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

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

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

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

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

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

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

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

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

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

Метаданные децентрализованных идентификаторов

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

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

5 марта 2026 года W3C опубликовала DID Core версии 1.1 как снимок проекта рекомендации (Candidate Recommendation Snapshot).

Поскольку версия 1.1 остается на этапе подготовки рекомендации, разработчикам следует отличать ее от окончательной рекомендации DID Core 1.0.

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

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

Метаданные верифицируемых учетных данных

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

Модель данных верифицируемых учетных данных W3C 2.0 стала рекомендацией W3C 15 мая 2025 года.

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

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

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

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

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

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

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

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

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

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

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

Локализация метаданных

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

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

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

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

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

Доступность метаданных

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

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

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

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

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

Типы медиафайлов в криптометаданных

Тип медиафайла описывает формат связанного файла: например, JSON, PNG, SVG, MP4 или другой зарегистрированный формат.

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

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

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

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

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

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

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

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

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

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

Индексация метаданных

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

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

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

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

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

Проверка метаданных

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

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

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

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

Проверка целостности сравнивает хеши или идентификаторы контента.

Семантическая проверка оценивает, соответствует ли информация контексту блокчейна и актива.

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

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

Вредоносные ссылки

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

Вредоносные медиафайлы

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

Слишком большие файлы

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

Рекурсивные ссылки

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

Подмена с помощью Unicode

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

Замена метаданных

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

Манипуляции со схемой

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

Отслеживание для сбора данных

Уникальный URL медиафайла может раскрыть, когда конкретный кошелек или пользователь просматривает метаданные токена.

Ложные утверждения

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

Метаданные и фишинг с использованием кошельков

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

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

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

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

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

Риски для конфиденциальности метаданных

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

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

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

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

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

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

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

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

Определите уникальные идентификаторы

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

Выберите формат данных

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

Определите обязательные поля

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

Определите типы данных

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

Определите поведение URI

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

Определите изменяемость

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

Определите способы защиты целостности

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

Определите версионирование

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

Определите порядок действий при сбоях

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

Опишите вопросы безопасности

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

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

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

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

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

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

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

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

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

Если это поддерживается, отправляйте стандартизированные события обновления.

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

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

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

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

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

Не заявляйте о неизменности, если любую важную ссылку все еще можно изменить.

Как оценить метаданные токена

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

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

Если это технически возможно, считайте URI непосредственно из контракта.

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

При наличии проверьте идентификаторы контента или хеши.

Узнайте, кто может менять контракт, URI, метаданные, схему или ссылку на хранилище.

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

Осторожно проверяйте ссылки на медиафайлы и внешние URL.

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

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

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

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

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

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

Другие помещают CID IPFS в один документ, позволяя контракту заменить URI этого документа.

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

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

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

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

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

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

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

Как проще всего определить стандарты метаданных?

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

Что такое криптометаданные?

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

Зачем криптоактивам нужны метаданные?

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

Хранятся ли метаданные в блокчейне?

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

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

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

Что такое метаданные вне блокчейна?

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

Небезопасно ли хранить метаданные вне блокчейна?

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

Какие метаданные определяет ERC-20?

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

Уникальны ли названия и символы токенов?

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

Как следует идентифицировать взаимозаменяемый токен?

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

Что такое метаданные ERC-721?

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

Что такое метаданные ERC-1155?

Метаданные ERC-1155 используют интерфейс URI и JSON-схему, поддерживающие несколько типов токенов в одном контракте.

Что означает заполнитель

{id}

в ERC-1155?

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

.

Что такое ERC-4906?

ERC-4906 — окончательное расширение, определяющее события для уведомления приложений об обновлениях метаданных ERC-721.

Что такое ERC-8048?

ERC-8048 — проект предложения, представленный в 2025 году и посвященный метаданным в формате «ключ — значение», хранящимся непосредственно в реестрах мульти-токенов и NFT.

Является ли ERC-8048 окончательным стандартом?

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

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

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

Означает ли корректный JSON, что метаданные токена тоже корректны?

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

Что такое JSON Schema?

JSON Schema определяет машиночитаемые правила проверки документов JSON.

Что такое JSON-LD?

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

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

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

Что такое CID IPFS?

CID IPFS — это идентификатор контента, частично формируемый на основе криптографического хеша и кодирования контента.

Гарантирует ли CID IPFS постоянное хранение?

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

Что такое метаданные с адресацией по содержимому?

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

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

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

Доказывает ли совпавший хеш достоверность метаданных?

Нет. Он подтверждает соответствие ожидаемому содержимому, но не достоверность содержащихся в нем утверждений.

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

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

Что такое замороженные метаданные?

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

Всегда ли ончейн-метаданные остаются неизменными?

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

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

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

Что такое CAIP-19?

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

Почему важны межсетевые идентификаторы?

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

Что такое метаданные DID?

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

Что такое метаданные верифицируемых учетных данных?

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

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

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

Может ли получение NFT подвергнуть кошелек риску фишинга?

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

Может ли документ метаданных запрашивать фразу восстановления?

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

Могут ли метаданные раскрыть персональную информацию?

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

Как проверить криптометаданные?

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

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

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

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

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

Заключение

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

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

К основным системам криптометаданных относятся поля взаимозаменяемых токенов, URI токенов ERC-721, схемы метаданных ERC-1155, события обновления ERC-4906, JSON, JSON Schema, JSON-LD, идентификаторы контента и независимые от блокчейна идентификаторы активов.

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

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

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

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

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