Через три дня после ревила ваш токен всё ещё показывает заглушку. Коллекция, которую вы держите, вдруг показывает не те свойства, что на прошлой неделе. Ни то, ни другое не про сам токен. И то и другое про одну строку, которую держит контракт, и про то, что находится на её другом конце; заморозка и обновление — это два слова о том, что с этой строкой может и не может произойти.
Что хранит токен, а что нет
NFT — это идентификатор, который смарт-контракт записывает за адресом владельца. Названия, описания и изображения в этой записи нет.
Их убирает за одну функцию стандарт токенов ERC-721. По идентификатору токена tokenURI возвращает Uniform Resource Identifier, а спецификация добавляет, что этот URI может указывать на файл JSON, соответствующий ERC721 Metadata JSON Schema.
В этой схеме всего три свойства: name обозначает актив, который представляет NFT, description его описывает, а image — это URI, указывающий на ресурс с MIME-типом изображения. Значит, изображение — это второй переход: контракт указывает на документ, а документ указывает на файл.
Помимо идентификатора и владельца, всё, что показывает вам приложение, читается из этого документа, а не из цепочки. Та часть, на которую все смотрят, — это как раз та часть, которую цепочка не хранит.
Куда ведёт указатель, решает, что может измениться
Токен-URI — это строка, и она может быть несколькими разными вещами. Это может быть веб-адрес на сервере, которым кто-то управляет. Это может быть адрес IPFS, построенный вокруг идентификатора контента. Это может быть весь документ, встроенный прямо в строку, так что забирать вообще нечего.
Различие важно из-за того, чем каждый вариант способен стать. Веб-адрес называет место, а не содержимое: тот, кто управляет сервером, завтра может вернуть по тому же адресу другие байты, и в цепочке от этого ничего не изменится. Идентификатор контента ведёт себя иначе. Документация IPFS утверждает, что CID основаны на криптографическом хеше содержимого и что любое различие в содержимом даст другой CID. Поэтому CID не может разрешиться в отредактированное содержимое: отредактированное содержимое — это другой CID, и ему нужен другой указатель.
Встроенный документ идёт ещё на шаг дальше, потому что перехватывать больше нечего. Он стоит объёма, потому что каждый его байт лежит в хранилище контракта.
| Куда указывает токен-URI | Может ли дальний конец позже отдать другое содержимое | Что должно измениться, чтобы изменилось изображение |
|---|---|---|
| Веб-адрес на чужом сервере | Да | В цепочке ничего |
| Идентификатор контента IPFS | Нет | Контракт должен вернуть другой URI |
| Документ, закодированный в самом URI | Нет | Контракт должен вернуть другой URI |
Что на самом деле означает заморозка метаданных
Заморозка — это утверждение про два замка, и оно верно, только когда закрыты оба. Первый замок на дальнем конце: содержимое за указателем нельзя подменить другим содержимым. Второй на самом указателе: контракт нельзя заставить вернуть другой URI.
Коллекция может положить каждый файл в IPFS, опубликовать идентификаторы контента и при этом сохранить функцию, позволяющую деплоеру задать новый base URI. Адресация по содержимому закрывает первый замок и оставляет второй открытым. Коллекцию из 10 000 токенов можно обслуживать одним base URI, и тогда одна транзакция владельца меняет то, во что разрешается каждый идентификатор в ней.
Поэтому заморозку читают так же, как привилегии владельца в любом другом контракте. Вопрос не в том, что контракт делает сегодня, а в том, что тот, у кого ключ владельца, всё ещё способен заставить его сделать.
Почему вы видите кэшированную копию
Маркетплейсы и кошельки не вызывают tokenURI и не забирают документ каждый раз, когда вы прокручиваете страницу. Они читают его один раз, держат собственную копию JSON, скачивают изображение и отдают вам эту копию, потому что отрисовывать галерею иначе означало бы по одному внешнему запросу на плитку к серверам, которыми сайт не управляет.
Итого копий ответа три, и они могут расходиться: что контракт возвращает сейчас, что документ по этому URI говорит сейчас и что индексатор записал, когда смотрел в прошлый раз. Неверная картинка — это утверждение о третьей копии, а не доказательство того, что первые две неверны.
ERC-4906 существует именно из-за этого зазора. Он озаглавлен EIP-721 Metadata Update Extension и добавляет событие MetadataUpdate, чтобы, по его собственным словам, сторонние платформы вроде NFT-маркетплейсов могли вовремя обновлять изображения и связанные атрибуты NFT; событие BatchMetadataUpdate покрывает диапазон идентификаторов за одну эмиссию. Заявленная мотивация в том, что контракты и так уже испускали для этого собственные события, а строить отдельное решение под каждую коллекцию было лишним трудом для платформ, которые их читают.
Что на самом деле делает обновление
Обновление — это указание индексатору, а не цепочке. Оно велит платформе выбросить записанное и проделать всё чтение заново: вызвать tokenURI, забрать то, что вернулось, разобрать это и заново скачать файл, названный в поле image. Ничего не подписывается, комиссия не платится, и контракт не трогают.
Поэтому обновление помогает только в одной ситуации: сохранённая копия отстала от текущего ответа. Если контракт теперь возвращает новый URI или документ по старому URI теперь содержит другие байты, обновление приводит отображение в соответствие. Если ни то, ни другое не верно, оно заменяет сохранённую копию точно такой же.
Обновление — это ручная версия того, что автоматизирует ERC-4906: когда коллекция испускает событие обновления, следящий за ним индексатор перечитывает всё сам, без просьбы.
Когда обновление не поможет
Полезный вопрос не в том, обновлять ли, а в том, с каким сбоем вы имеете дело, потому что не связанные между собой сбои выглядят одинаково: картинка не та или картинки нет.
| Что вы видите | Что происходит на самом деле | Меняет ли это обновление |
|---|---|---|
| Заглушка после ревила | Контракт всё ещё возвращает URI до ревила | Нет, пока контракт не вернёт новый |
| Битое изображение, документ открывается | URI изображения мёртв или недоступен | Нет, чинить надо на хостинге |
| Не загружается ничего | Недоступен сам документ метаданных | Нет |
| Свойства расходятся с документом | Сохранённая копия устарела | Да |
| Картинка верная, страница коллекции нет | Вы смотрите на другой контракт | Нет |
Строки с мёртвым указателем как раз и читают как сбой платформы. Если токен-URI — это веб-адрес, сервер за ним можно выключить, и указатель продолжит указывать в пустоту. Если это идентификатор контента, тот же итог приходит другой дорогой: документация IPFS утверждает, что, хотя IPFS гарантирует обнаружимость любого содержимого в сети, он не гарантирует, что содержимое остаётся доступным постоянно, и что данные можно закрепить на одном или нескольких узлах IPFS, чтобы их не удалили при сборке мусора. CID, который не держит ни один узел, — это действительное и вечное имя для ничего.
Что проверить, прежде чем просить обновление
Три чтения разводят эти случаи, и ни одному из них не нужен работающий маркетплейс.
Сначала прочитайте контракт. В блокчейн-эксплорере откройте контракт коллекции и вызовите tokenURI со своим идентификатором токена. Вернувшаяся строка — это ответ из цепочки и единственная из трёх копий, которую цепочка удостоверяет.
Затем откройте то, что она вернула. Заберите этот URI и прочитайте JSON. Если в name, description и image лежит то, что вы ожидаете, сторона цепочки в порядке, а проблема ниже по течению. Если URI не открывается, никакое обновление не создаст документ, которого нет.
Затем пройдите по полю image, потому что документ может быть цел, а названный им файл исчезнуть, причём на другом хосте, чем тот, что отдаёт метаданные. Когда все три чтения верны, а маркетплейс всё равно показывает другое, вот тогда это случай для обновления, и только тогда.
Итог
Метаданные — это документ, на который цепочка указывает, а не вещь, которую цепочка хранит. Заморозка означает, что закрыты оба замка: дальний конец не может отдать другое содержимое, а контракт нельзя заставить указывать в другое место. Один замок без второго не заморозка, а адресация по содержимому сама по себе закрывает только первый.
Обновление ничего из этого не трогает. Оно перечитывает указатель и документ и перезаписывает кэшированную копию, поэтому чинит ровно один сбой: отставшее отображение. Прочитайте tokenURI, откройте то, что он вернул, пройдите по полю image. Эти три чтения отделяют индексатор, которому надо посмотреть ещё раз, от указателя, на конце которого уже ничего нет. Чтобы продолжать изучать основы, следите за материалами Bitbase Academy.
Похожие материалы
Другие материалы Bitbase по этой теме:
- Долевое владение NFT и где находится риск
- Минт NFT прошёл, а NFT не видно в кошельке
- Процесс ревила NFT: что меняется и когда
- Необязательные роялти NFT простыми словами
- Пересечения средних: золотой и мёртвый крест
Дисклеймер: эта статья — образовательный материал Bitbase Academy, только для информационных целей. Она не является инвестиционным, торговым, налоговым или финансовым советом. Криптоактивы волатильны — оценивайте риски самостоятельно. Написано в сентябре 2026 года; сверяйтесь с актуальной официальной информацией.
Источники
[1] Ethereum Improvement Proposals, ERC-721: Non-Fungible Token Standard eips.ethereum.org
[2] Ethereum Improvement Proposals, ERC-4906: EIP-721 Metadata Update Extension eips.ethereum.org
[3] Документация IPFS, Content Identifiers (CIDs) docs.ipfs.tech
[4] Документация IPFS, Persistence, permanence, and pinning docs.ipfs.tech
