Невзаимозаменяемый токен: сравнение ERC-721, 1155 и 6551
ERC-721, он же EIP-721, принят в 2018 году и остаётся базовым слоем для уникальных цифровых активов. Каждый токен в контракте получает собственный tokenId — 256-битное беззнаковое целое, которое и обеспечивает невзаимозаменяемость.
Фундамент цифрового владения: архитектура ERC-721
ERC-721, он же EIP-721, принят в 2018 году и остаётся базовым слоем для уникальных цифровых активов. Каждый токен в контракте получает собственный tokenId — 256-битное беззнаковое целое, которое и обеспечивает невзаимозаменяемость. Два токена с разными tokenId — разные активы по определению, даже если их метаданные совпадают побайтно.
Архитектура проста и жёстка. Контракт хранит маппинг owner → balanceOf для быстрого учёта и маппинг tokenId → owner для разрешения передач. Каждый минт — отдельная транзакция, каждый transferFrom — отдельная транзакция. Никаких пакетных операций на уровне протокола не предусмотрено. Это работает для коллекций из сотен или тысяч предметов, но при массовом минтинге — игровые ассеты, билеты на мероприятия, серийные доменные имена — газовый оверхед становится неприемлемым.
Дополнительные требования зашиты в самом интерфейсе. safeTransferFrom обязывает получателя-контракт реализовать коллбэк onERC721Received и вернуть magic value 0x150b7a02. Если контракт-получатель эту проверку не реализует, транзакция ревертится, а наивная реализация через обычный transferFrom без проверки приводит к классической уязвимости: NFT уходит в контракт без обработчика и блокируется навсегда. События Transfer и Approval обязаны индексировать поля from, to, tokenId — иначе ломается вся инфраструктура маркетплейсов и оффчейн-индексации.
ERC-721 — это не «стандарт NFT», а минимальный интерфейс владения уникальным активом. Всё остальное — надстройка.
Стандарт решает одну задачу: учёт уникальных идентификаторов. Всё, что выходит за пределы этой задачи — пакетные переводы, мультитокеновые модели, логика владения активами — требует других стандартов или собственных надстроек. Слабость ERC-721 не в дизайне, а в попытках использовать его за пределами исходной задачи.
Оптимизация транзакций и мультитокеновая модель ERC-1155
ERC-1155, он же EIP-1155, — ответ на газовый оверхед ERC-721 в сценариях массовых операций. Стандарт введён командой Enjin в 2018 году. Ключевое отличие: один контракт управляет множеством идентификаторов, и каждый идентификатор может быть либо взаимозаменяемым, либо невзаимозаменяемым — в зависимости от того, задан ли supply равным единице или больше.
Структура хранения вместо отдельного маппинга для каждого tokenId использует двухуровневый маппинг (id, owner) → balance. Это позволяет хранить миллионы типов токенов в рамках одного контракта без раздувания storage. Главный выигрыш — пакетные операции. Интерфейс safeBatchTransferFrom принимает массивы uint256[] ids и uint256[] amounts, позволяя передавать несколько типов токенов в одной транзакции. Один колл вместо десяти.
Экономия газа при правильной упаковке запросов — порядка 60–80% по сравнению с серией одиночных transferFrom в ERC-721. Минтинг 100 единиц одного типа актива через ERC-721 требует 100 транзакций; через ERC-1155 — одну. Для блокчейн-игр с тысячами типов предметов это разница между экономически нецелесообразным продуктом и работающей экономикой.
Пакетный transfer в ERC-1155 — не косметическая фича, а архитектурный сдвиг. Один контракт, одна транзакция, десятки типов активов.
Оверхед тоже присутствует. ERC-1155 сложнее в реализации: разработчику нужно аккуратно работать с packed arrays, валидировать их длину на каждом шаге, следить за reentrancy в batch-операциях — внешний вызов внутри цикла по ids остаётся классической ловушкой. Газ при одиночной передаче одного токена выше, чем у ERC-721, из-за дополнительной логики определения типа операции и проверки ERC1155Received (0xf23a6e61).
Сценарии безоговорочного выигрыша ERC-1155: блокчейн-игры с тысячами типов предметов, платформы для выпуска билетов и сертификатов, системы цифровых коллекций с серийными тиражами. ERC-721 в этих случаях экономически нецелесообразен.
Token Bound Accounts: как ERC-6551 превращает NFT в смарт-аккаунты
ERC-6551, он же EIP-6551, принят в 2023 году. Это самый нестандартный слой в стеке: он не про хранение токенов, а про то, чтобы NFT стал самостоятельным субъектом в сети. Стандарт описывает Token Bound Accounts (TBA) — каждый ERC-721 получает собственный смарт-аккаунт, способный владеть другими активами и взаимодействовать с dApps от своего имени.
Архитектура решения — отдельный Registry-контракт, развёрнутый на конкретном chainId. При создании аккаунта вызывается createAccount(implementation, salt, chainId, tokenContract, tokenId). Registry детерминированно вычисляет адрес через CREATE2 и деплоит минимальный прокси-контракт с логикой аккаунта. Ключевой момент: адрес аккаунта жёстко привязан к кортежу (tokenContract, tokenId, salt, chainId). Один и тот же NFT всегда порождает один и тот же TBA — без отдельной транзакции регистрации, без хранения лишнего состояния.
Важнейшее свойство обратной совместимости. ERC-6551 не требует изменений в исходном контракте NFT. Реестр работает как внешний слой: он знает, какому токену какой аккаунт соответствует, но сам токен об этом не подозревает. Это означает, что любой ранее выпущенный ERC-721 — хоть CryptoPunks 2017 года, хоть свежий PFP-проект — автоматически получает TBA-функциональность без миграции и без изменения байткода.
ERC-6551 — надстройка, а не замена. Базовый контракт ERC-721 остаётся нетронутым, Registry берёт всю работу на себя.
TBA радикально меняет модель владения. NFT перестаёт быть пассивным сертификатом и становится актором: он может держать ERC-20, владеть другими NFT, вызывать контракты, подписывать сообщения. Впервые невзаимозаменяемый токен получил полноценную идентичность в смысле суверенного цифрового субъекта. По сути, это превращение NFT в полноценный некастодиальный кошелёк — в разборе архитектуры некастодиальных кошельков по уязвимостям и контролю ключей тот же принцип суверенного владения рассматривается применительно к пользовательским приложениям; TBA реализует его на уровне самого актива.
Ограничения текущей реализации. TBA наследует все проблемы смарт-аккаунтов: зависимость от доверенной implementation-логики (апгрейд прокси — потенциальная уязвимость), reentrancy в executeCall, риски кроссчейн-интерпретации chainId. Долгосрочные риски безопасности в сложных DeFi-протоколах, использующих TBA как кошелёк для ликвидности, остаются открытым вопросом — это зона повышенного внимания для любого аудитора.
Сравнительный анализ: эффективность газа и сценарии применения
| Параметр | ERC-721 | ERC-1155 | ERC-6551 |
|---|---|---|---|
| Уникальность актива | Полная (уникальный tokenId) | Опциональная (через ограничение supply) | Наследует от базового ERC-721 |
| Пакетные операции | Нет | Да (safeBatchTransferFrom) | Через TBA как аккаунт |
| Газ при массовом минтинге | Высокий (транзакция на токен) | Низкий (один контракт, батч-вызовы) | Неприменимо (работает поверх базы) |
| Хранение данных | owner → balance + tokenId → owner | Двухуровневый (id, owner) → balance | Реестр аккаунтов + прокси |
| Газ одиночного transfer | Базовый | Выше из-за проверки типа | Через TBA executeCall |
| Владение другими активами | Только собственный контракт | Только собственный контракт | Любые активы через TBA |
| Обратная совместимость | — | Частичная с интерфейсом ERC-721 | Полная с любым существующим ERC-721 |
| Сложность аудита | Низкая | Средняя | Высокая (смарт-аккаунт + прокси + Registry) |
Таблица показывает очевидное: выбор стандарта — это не «какой лучше», а «какой подходит под задачу». ERC-721 остаётся оптимальным выбором для каталогов с десятками или сотнями уникальных предметов и высокой ликвидностью каждого — профильные PFP-коллекции, цифровое искусство, доменные имена, продаваемые поштучно. ERC-1155 выигрывает там, где тиражей много и они гомогенны — игровые ассеты, билеты, сертификаты. ERC-6551 добавляет слой композиции там, где NFT должен стать актором, а не просто сертификатом.
Ошибка разработчиков — пытаться выбрать один стандарт на все случаи. ERC-1155 для уникального предмета с высокой ликвидностью добавляет ненужный оверхед на каждый transfer. ERC-721 для игрового инвентаря — прямой путь к неподъёмным комиссиям. ERC-6551 как самостоятельный контракт — невозможен, это исключительно надстройка.
Взаимодействие стандартов: почему ERC-6551 не заменяет базу
ERC-6551 не конкурирует с ERC-721 — он компонуется поверх. Это принципиальное архитектурное решение, которое разработчики часто понимают неправильно. Стандарт не вводит новый тип токена, не изменяет интерфейс владения, не требует хардфорка или обновления существующих контрактов. Это чистая надстройка через Registry.
Логика компоновки работает в три слоя:
1. Базовый слой — ERC-721, обеспечивающий уникальность и учёт владения через tokenId.
2. Пакетный слой — ERC-1155, обеспечивающий экономию газа и мультитокеновость там, где уместно.
3. Акторный слой — ERC-6551, превращающий уникальный токен из слоя 1 в смарт-аккаунт с собственным адресом.
Между слоями 2 и 3 прямой совместимости нет. TBA создаётся для конкретного (tokenContract, tokenId) из ERC-721. Для ERC-1155 стандарт пока не адаптирован — мультитокеновый контракт не имеет единичного tokenId, к которому можно привязать аккаунт. Любое решение здесь потребует отдельного EIP.
Риски стека. Каждый дополнительный слой увеличивает площадь атаки. TBA поверх ERC-721 наследует уязвимости обоих компонентов: reentrancy в прокси-логике Registry, манипуляции с implementation-контрактом, фронтраннинг деплоя аккаунта, зависимость от корректности chainId в кроссчейн-сценариях. Аудит такого стека требует проверки взаимодействия трёх независимых контрактов — поверхностный анализ здесь недопустим.
Композиция стандартов — это не бесплатная мощность. Каждый слой платит свою цену в газе, сложности аудита и площади атаки.
Долгосрочная перспектива TBA остаётся неопределённой. Стандарт молод, и данные о реальных инцидентах в production ограничены. Протоколы, интегрирующие TBA как кошелёк для ликвидности или кроссчейн-логистики, обязаны проводить собственный аудит безопасности с фокусом на нестандартные пути выполнения кода. Наивное доверие к «проверенному стандарту» здесь не работает — композиция всегда порождает новые классы уязвимостей, которых нет в отдельных компонентах.
Технический вердикт
ERC-721, ERC-1155 и ERC-6551 — не конкуренты, а слои одного стека. Выбор стандарта диктуется задачей: ERC-721 для уникальных активов с высокой ликвидностью, ERC-1155 для массовых операций и экономии газа, ERC-6551 для превращения актива в самостоятельного актора. Архитектурная чистота ERC-6551 — в ненавязчивости: ни одного изменения в базовом контракте, полная обратная совместимость, детерминированная адресация через CREATE2. Это редкий случай, когда надстройка не ломает основу.
Используйте TBA там, где NFT должен действовать — владеть активами, участвовать в DAO, вызывать контракты. Не используйте — там, где задача решается простым ERC-721 без оверхеда смарт-аккаунта. Математика владения остаётся бинарной: либо актив пассивен, либо он актор. Промежуточных состояний стандарт не предусматривает. Разработчикам, выбирающим стек вслепую, стоит начать с честного ответа на один вопрос: какова реальная частота и сложность транзакций этого актива — десять в день или десять тысяч? Ответ диктует архитектуру.
