ГЛАВНАЯ / ИНСТРУКЦИИ / ONCHAIN И OFFCHAIN METADATA NFT: РАЗЛИЧИЯ ХРАНЕНИЯ
Onchain и offchain metadata NFT: различия хранения
Метаданные NFT могут храниться в блокчейне, в IPFS или на обычном сервере, а одна карточка может сочетать несколько схем. Оценивайте по отдельности JSON, изображение, адрес tokenURI и права на обновление – слово onchain само по себе не описывает весь объект.
Сначала разделите контрактные данные и внешние файлы
TokenURI – результат функции контракта, но URI часто указывает на внешний JSON. JSON может в свою очередь ссылаться на картинку или анимацию. Поэтому данные блокчейна, указатель на них и медиа могут иметь разные места и режимы обновления.
Под onchain metadata обычно подразумевают данные, которые контракт хранит или формирует из состояния блокчейна. Offchain означает, что для получения части сведений клиент обращается за пределы состояния сети. Возможны гибридные схемы: фиксированный URI и внешняя картинка либо JSON с onchain-атрибутами.
- найдите источник tokenURI;
- разберите JSON и поля media отдельно;
- определите, какие данные реально записаны в транзакции или состоянии контракта.
Onchain повышает автономность проверки, offchain упрощает большие файлы
Запись данных в блокчейн увеличивает объём состояния или данных транзакции и может быть дороже для создателя. Зато часть контента доступна из самой сети и не зависит от отдельного HTTP-сервера. Конкретные расходы и модель исполнения зависят от сети и контракта.
Offchain JSON и медиа подходят для более крупных объектов, но становятся зависимыми от хранения и доставки. IPFS адресует данные по содержимому, однако требует, чтобы узлы продолжали предоставлять блоки. Обычный HTTP URL может меняться или перестать отвечать. Эти варианты не сводятся к рейтингу «безопаснее/опаснее» без учёта проекта.
| Модель | Преимущество | Проверяемое ограничение |
|---|---|---|
| Onchain | Часть данных читается из сети | Размер, стоимость и права контракта |
| IPFS CID | Адрес привязан к содержимому | Pinning и наличие провайдеров |
| HTTP | Совместимость с обычным браузером | Зависимость от домена и сервера |
| Гибридная | Разделение указателя и файлов | У каждой части собственная модель |
Неизменный файл не исключает изменяемого tokenURI
CID указывает на конкретный контент, но контракт может позже вернуть другой CID. И наоборот, tokenURI может оставаться прежним HTTP URL, ответ которого меняется на сервере. Проверяйте неизменность указателя и неизменность файла как разные свойства.
EIP-721 допускает изменение URI, а EIP-4906 описывает события уведомления о метаданных для совместимых контрактов. Если изменение поддерживается контрактом или сервером, клиент может показать новую версию. Исследуйте функции владельца, роли, proxy, журнал обновлений и режим хранения целевых данных.
- запишите текущий tokenURI;
- проверьте функцию и события обновления;
- сверьте, ведёт ли постоянный URI к mutable DNS или HTTP;
- не приравнивайте event о metadata к блокировке обновлений.
Любое хранение требует проверки пути восстановления данных
Onchain данные читаются пока доступна соответствующая сеть и инструменты чтения, однако приложение может перестать их индексировать или отображать. Внешние данные требуют работающего сервера, IPFS-провайдера или другого хранилища.
Для offchain схем выясните, кто закрепляет IPFS-контент, где лежат копии, включены ли все вложенные файлы и поддерживает ли проект перенос данных. Несколько gateway помогают отличить сбой HTTP-шлюза от недоступности контента, но не гарантируют архивную сохранность.
Описывайте модель по каждому элементу и правилу обновления
Составьте цепочку: сеть и контракт, tokenId, tokenURI, JSON и URI каждого медиафайла. Для каждого звена укажите его расположение, кто им управляет и какая проверка подтверждает содержимое.
Для коллекции важно не только где файл хранится, но и может ли создатель заменить указатель, остаётся ли доступным корневой JSON, как клиент получает события обновления и существуют ли копии у независимых операторов. Не обещайте абсолютную неизменяемость по одному признаку.
- место хранения определено для JSON и медиа отдельно;
- изменяемость URI и файла описана раздельно;
- доступность проверена через независимые источники;
- права на изменение установлены по контракту;
- подлинность и права автора не выводятся из хэширования.
Частые вопросы
IPFS – это onchain хранение?
Нет. IPFS является отдельной сетью хранения; контракт может содержать только URI или CID.
Если metadata размещена onchain, изображение тоже onchain?
Не обязательно. Поле может указывать на внешний файл.
Постоянный CID исключает замену NFT-метаданных?
Нет. Контракт может вернуть другой URI, а внешний указатель может вести к изменяемому адресу.
Какая модель лучше?
Зависит от размера файлов, требований доступности, стоимости и того, кто поддерживает хранение.
Чек-лист: onchain и offchain metadata nft: различия хранения
- сеть, контракт и tokenId подтверждены;
- tokenURI проверен;
- JSON и медиа разобраны отдельно;
- место хранения каждого звена установлено;
- указатель и содержимое оценены на изменяемость независимо;
- pinning и копии проверены для offchain данных;
- обновляющие роли и события изучены;
- неизменяемость не обещана по одному атрибуту.
Материал подготовлен редакцией сайта и проверен 22 октября 2026 года. Условия бирж, кошельков и блокчейн-сетей могут меняться. Перед операцией сверяйте данные в интерфейсе выбранного сервиса.