EIP-6969: Новые идеи для построения метаданных ERC и NFT

По мере того, как NFT и токенизированные активы становятся все более компонуемыми и динамичными, метаданные превратились в узкое место для масштабируемости, постоянства и интероперабельности. Современные практики работы с метаданными — чаще всего JSON, передаваемый по HTTP — хрупки, их сложно версионировать и они подвержены сбоям. Новое направление, неофициально названное «EIP-6969», исследует, как метаданные ERC и NFT могут быть построены на следующее десятилетие: с адресацией по содержимому, проверяемые, обновляемые и разработанные с учетом специфики блокчейна.

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

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

Исходные стандарты NFT, включая основополагающий ERC‑721 и мультитокен ERC‑1155, определяют tokenURI, который обычно разрешается в оффчейн JSON. Хотя это и просто, разработчики и маркетплейсы регулярно сталкиваются с:

• Хрупкостью и «битыми ссылками» при использовании централизованных HTTP-конечных точек.
• Отсутствием надежного версионирования и происхождения для развивающихся коллекций.
• Сложностью сигнализирования обновлений метаданных индексаторам и пользовательским интерфейсам.
• Непоследовательным разрешением на нескольких цепочках в экосистемах L1/L2.
• Неоднозначными сигналами о роялти и лицензировании для создателей.

Несколько EIP уже решают часть этой головоломки. Например, ERC‑4906 добавляет событие для сигнализирования обновлений метаданных индексаторам; EIP‑2981 стандартизирует информацию о роялти; EIP‑3668 (CCIP‑Read) обеспечивает минимально доверительное чтение оффчейн данных; а EIP‑1014 (CREATE2) позволяет создавать детерминированные адреса контрактов для реестров и резолверов. Тем временем, обновление Ethereum Cancun‑Deneb (с EIP‑4844) существенно улучшило доступность данных для L2, открыв двери для большего количества ончейн или полуончейн подходов к метаданным.

Как могут выглядеть метаданные «в стиле EIP‑6969»

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

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

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

• По умолчанию — хранилище с адресацией по содержимому

  • Ссылайтесь на метаданные по хэшу, а не по изменяемому URL; разрешайте через адресацию содержимого IPFS или Arweave Permaweb.
  • Опциональные HTTP-зеркала для производительности, но всегда привязанные к проверяемому дайджесту.

• Обновляемые, сигнализированные метаданные

  • Генерируйте события ERC‑4906 при изменении метаданных на уровне токена или коллекции, обеспечивая надежное обновление.
  • Используйте семантическое версионирование в реестре для обозначения изменений схемы или обновлений резолвера.

• Проверяемое оффчейн разрешение

  • Принимайте CCIP‑Read для минимально доверительных оффчейн запросов, когда данные не могут храниться ончейн.
  • Подписывайте дайджесты метаданных с помощью типизированных данных EIP‑712; кошельки и маркетплейсы могут проверять подписи с помощью EIP‑1271 для контрактных аккаунтов.

• Цепно-осведомленные, мультиресурсные URI

  • Включайте идентификаторы цепочек CAIP-2 в URI и записи реестра для различения вариантов L1 и L2, в соответствии с CAIP‑2.
  • Предпочитайте «мультиресурсный» дизайн: основной адрес содержимого плюс опциональные зеркала (например, CID IPFS + шлюз HTTPS + транзакция Arweave).

• Компонуемая схема для NFT и взаимозаменяемых ERC

  • Публикуйте JSON Schema или JSON‑LD для структуры признаков, атрибутов и связей с медиа, чтобы уменьшить неоднозначность для индексаторов; см. рекомендации маркетплейсов, такие как стандарты метаданных OpenSea.
  • Поддерживайте представления, учитывающие роли (создатель, держатель, маркетплейс), сохраняя при этом единый канонический дайджест для каждого состояния токена.

• Опциональное участие аккаунтов

  • Интегрируйте управление метаданными с модульными смарт-аккаунтами через EIP‑6900 (модульные аккаунты) или контроллеры, связанные с токенами (например, EIP‑6551), когда создателям нужны программируемые политики для обновлений, лицензионных гейтов или логики, специфичной для токенов.

Как это реализовать сегодня с использованием существующих EIP

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

1. Разверните Реестр метаданных с помощью CREATE2

   • Хранить:
     • schemaHash (схема с адресацией по содержимому)
     • resolver (контракт или конечная точка CCIP)
     • version (строка semver)
     • fallbacks (массив мультиресурсных URI)
   • Обнаружение интерфейса через ERC‑165.

2. Разрешайте метаданные токенов через CCIP-Read

   • Ончейн-метод возвращает селектор, инструктирующий клиента получить оффчейн-данные из разрешенного источника.
   • Оффчейн-полезная нагрузка возвращает метаданные плюс подпись EIP‑712; клиенты проверяют против публичного ключа EOA или контракта EIP‑1271.

3. Генерируйте события ERC‑4906 при обновлениях

   • Для коллекций NFT с эволюцией признаков или динамическим искусством запускайте MetadataUpdate(tokenId) или BatchMetadataUpdate(fromTokenId, toTokenId).

4. Используйте URI с адресацией по содержимому везде

   • Закрепите канонический JSON на IPFS или Arweave; встройте CID/TX в записи реестра.
   • Зеркала могут улучшить задержку, но клиенты должны доверять дайджесту.

5. Опубликуйте схему

   • Документируйте атрибуты, связи с медиа, анимацию и издание в машиночитаемой схеме (например, JSON Schema) и опубликуйте хэш схемы в реестре.
   • Согласуйтесь с полями данных, ожидаемыми маркетплейсами, такими как руководство по метаданным OpenSea.

6. Сигналы о роялти и лицензировании

   • Реализуйте EIP‑2981 для роялти и предоставьте ссылки на лицензии как часть схемы, чтобы юридические метаданные были переносимыми и проверяемыми.

Паттерны проектирования, которые окупаются

• Двухэтапное разрешение

  • Этап 1: Чтение данных ончейн-реестра для версии, резолвера и дайджеста содержимого.
  • Этап 2: Выполнение CCIP-Read или оффчейн-запроса, проверка подписи против ожидаемого подписанта резолвера и сравнение дайджестов.

• Согласованность на нескольких цепочках

  • Используйте идентификаторы CAIP-2 наряду с адресами реестров, специфичными для цепочки. Маркетплейсы и кошельки могут различать, к какому варианту цепочки принадлежит токен, улучшая кросс-чейн UX.

• Управление и восстановление

  • Обновления реестра должны контролироваться четко определенными политиками, в идеале через модульные аккаунты (EIP‑6900) или роли с временной блокировкой. Рассмотрите поэтапные обновления, когда новый резолвер или схема становится активной после задержки.

• Кэширование и повторная проверка

  • Клиенты кэшируют полезные нагрузки с адресацией по содержимому; повторно проверяют события ERC‑4906 или изменения версий. Это снижает нагрузку на пропускную способность, сохраняя данные свежими.

Вопросы безопасности

• Границы доверия

  • Четко разделите «кто может подписывать метаданные» от «кто может обновлять резолверы». Используйте отдельные ключи и публикуйте их в реестре.

• Гигиена подписей

  • Предпочитайте EIP‑712 с разделением доменов, идентификаторами цепочек, сроком действия и nonce для предотвращения повторных атак и путаницы между доменами.

• Шлюзы и зеркала

  • Если используете HTTPS-зеркала, принудительно проверяйте дайджесты на стороне клиента. Не полагайтесь на доступность шлюза для аутентификации; полагайтесь на адресацию по содержимому.

• Обратная совместимость

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

Что это значит для пользователей и маркетплейсов

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

Конвергенция стандартов также помогает инструментам. Индексаторы могут полагаться на события ERC‑4906. Кошельки могут проверять подписи с помощью EIP‑1271. Мультичейн-dapps могут согласовываться по CAIP‑2 для представления согласованных кросс-чейн коллекций. А адресация содержимого через IPFS или Arweave сохраняет каноническую запись, защищенную от несанкционированного доступа.

Дорожная карта, готовая к 2025 году

• Начните миграцию коллекций на URI с адресацией по содержимому и опубликуйте хэш схемы.
• Добавьте простой контракт реестра CREATE2 и генерируйте ERC‑4906 при обновлениях.
• Реализуйте CCIP-Read для динамических данных, которые не могут полностью храниться ончейн; подписывайте полезные нагрузки с помощью EIP‑712.
• Для новых минтов на L2 используйте доступность данных, активированную Кан («обзор» https://blog.ethereum.org/2024/03/13/cancun-deneb-upgrade), для хранения большего количества метаданных ончейн или в блобах, и привязывайте оффчейн полезные нагрузки к состоянию цепочки.
• Изучите управление модульными аккаунтами (EIP‑6900), если вам нужны программируемые политики обновления.

Заключительные мысли и практический совет

Даже по мере того, как метаданные движутся к проверяемым, адресуемым по содержимому и модульным дизайнам, одно остается постоянным: подпись — это корень доверия. Независимо от того, являетесь ли вы создателем, публикующим изменение схемы, или маркетплейсом, проверяющим полезные нагрузки CCIP-Read, безопасная подпись EIP-712 и изоляция ключей имеют решающее значение.

Если вы предпочитаете аппаратный кошелек для более надежной безопасности ключей, OneKey предоставляет прошивку с открытым исходным кодом, надежную защиту с помощью безопасного элемента и плавную поддержку современных потоков подписи, таких как EIP-712, в популярных dapps. Поскольку архитектуры метаданных все больше полагаются на четкие, проверяемые подписи — особенно с CCIP-Read и контрактной проверкой через EIP-1271 — наличие надежной, аудируемой подписи в вашем рабочем процессе является практическим улучшением как для создателей, так и для коллекционеров.

Принимая эти паттерны «в стиле EIP-6969» сегодня, экосистема может сделать метаданные ERC и NFT более долговечными, интероперабельными и готовыми к будущему — готовыми к многоцепочечному миру с высокой пропускной способностью, который Ethereum и его L2 неуклонно предоставляют.