Разработка omnichain-NFT (ONFT) под ключ: интеграция LayerZero

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Разработка omnichain-NFT (ONFT) под ключ: интеграция LayerZero
Средний
~3-5 дней
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1361
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    957
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1189
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929

Разработка omnichain-NFT (ONFT)

NFT, привязанный к одному чейну — это актив с ограниченной ликвидностью. Коллекция на Ethereum имеет доступ к OpenSea и Blur, но отрезана от экосистемы Polygon, Arbitrum, Solana. Владелец, который хочет использовать NFT в игре на Immutable X или как collateral в DeFi-протоколе на Arbitrum — просто не может. В нашей практике ONFT позволяет проектам увеличить аудиторию до 5 раз, давая пользователям свободу перемещения между сетями. Мы разрабатываем ONFT под ключ, чтобы ваша коллекция была доступна на всех ведущих L2.

ONFT (Omnichain Non-Fungible Token) — стандарт LayerZero для NFT с нативным кросс-чейн трансфером. Не бридж с lock-and-mint рисками, а единый контракт, развёрнутый на нескольких чейнах, который атомарно перемещает NFT между ними без потери metadata и ownership истории.

Как ONFT работает на уровне протокола

LayerZero: endpoints и Ultra Light Node

LayerZero не является отдельным блокчейном. Это messaging protocol с Endpoint контрактами на каждом поддерживаемом чейне (~50+: Ethereum, Polygon, Arbitrum, Optimism, BSC, Solana, Aptos и другие).

Отметим: когда NFT отправляется из Ethereum в Arbitrum:

  1. sendFrom() на Ethereum вызывает Endpoint.send() с encoded payload (tokenId, recipient)
  2. LayerZero Oracle (Chainlink, Sequencer или Google Cloud) фиксирует block header на Arbitrum
  3. LayerZero Relayer передаёт proof транзакции
  4. Endpoint на Arbitrum верифицирует proof через Ultra Light Node (ULN) — не полная верификация блока, только нужный storage proof
  5. lzReceive() на ONFT контракте Arbitrum вызывается с payload, минтит NFT получателю

На исходном чейне NFT сжигается (или лочится в зависимости от реализации). На целевом — минтится. Общий supply не изменяется.

ONFT721 vs. собственная реализация

LayerZero предоставляет ONFT721 base contract в @layerzerolabs/solidity-examples. Это ERC-721 с добавленными функциями sendFrom и lzReceive. Простейшая ONFT реализация — наследование от ONFT721 с добавлением кастомной логики.

Ключевые параметры при деплое:

constructor(
    string memory name,
    string memory symbol,
    uint256 _minGasToTransfer, // минимальный газ для lzReceive на destination
    address _lzEndpoint        // LayerZero Endpoint адрес для данного чейна
) ONFT721(name, symbol, _minGasToTransfer, _lzEndpoint) {}

_minGasToTransfer критичен: если указать слишком мало — lzReceive на destination ревертится из-за out-of-gas, NFT «застревает» между чейнами. Рекомендация LayerZero: 200 000 gas для базового ONFT721, больше если lzReceive содержит дополнительную логику.

Проблемы, которые нужно решить при разработке

Синхронизация metadata при кросс-чейн трансфере

Metadata NFT хранится на IPFS или Arweave — это не проблема, URI одинаков на всех чейнах. Проблема с динамической metadata: если NFT имеет on-chain attributes (уровень персонажа в игре, накопленные очки), эти данные хранятся в storage контракта. При переносе на другой чейн on-chain state не переносится автоматически.

Решение: включить state в LayerZero payload. Кастомная _debitFrom на source упаковывает state, кастомная _creditTo на destination восстанавливает. Это увеличивает gas стоимость трансфера, но сохраняет полное состояние.

function _debitFrom(address _from, uint16, bytes memory, uint _tokenId)
    internal override returns(bytes memory) {
    // Собираем state токена
    TokenState memory state = tokenStates[_tokenId];
    _burn(_tokenId); // или lock
    return abi.encode(_tokenId, state); // включаем в payload
}

function _creditTo(uint16, address _toAddress, bytes memory _payload)
    internal override returns(uint) {
    (uint tokenId, TokenState memory state) = abi.decode(_payload, (uint, TokenState));
    _mint(_toAddress, tokenId);
    tokenStates[tokenId] = state; // восстанавливаем state
    return tokenId;
}

Оценка и оплата LayerZero fee

Трансфер через LayerZero не бесплатен: пользователь платит нативной валютой source чейна за:

  • Gas на source чейне (Endpoint.send)
  • Оракул и relayer fee (уходит в LayerZero)
  • Оценка газа на destination чейне (prepaid)

Клиентская часть обязана вызвать estimateSendFee() перед трансфером и передать результат как msg.value. Если msg.value меньше оценки — транзакция ревертится.

function estimateSendFee(
    uint16 _dstChainId,
    bytes calldata _toAddress,
    uint _tokenId,
    bool _useZro,
    bytes calldata _adapterParams
) public view returns (uint nativeFee, uint zroFee);

Типичная стоимость трансфера ETH → Arbitrum: $0.50–2.00 в ETH в зависимости от congestion.

Trusted Remote конфигурация

Каждый ONFT контракт на каждом чейне должен знать адреса своих «собратьев» на других чейнах. Это trustedRemote — авторизованный список. Без этого любой контракт мог бы минтить ONFT через LayerZero message.

// Выполняется после деплоя на каждом чейне
function setTrustedRemoteAddress(
    uint16 _remoteChainId,   // LayerZero chain ID
    bytes calldata _remoteAddress
) external onlyOwner;

Ошибка: забыть установить trusted remote bidirectionally. Трансфер Ethereum→Polygon работает, Polygon→Ethereum нет — потому что Polygon контракт не добавил Ethereum в trusted remote.

nonce и ordering гарантии

LayerZero v1 гарантирует ordered delivery: сообщения между двумя чейнами доставляются в порядке отправки. Если транзакция с nonce N застряла (релейер не доставил) — все последующие с nonce N+1, N+2 ждут. Это может заблокировать все трансферы из конкретного чейна.

LayerZero v2 переходит на unordered delivery с application-level ordering — более гибкая модель, не блокирует очередь.

Какие риски при разработке ONFT?

Основные риски связаны с конфигурацией trusted remote (необходимо установить двунаправленно) и выбором _minGasToTransfer (слишком малый газ приводит к зависанию трансфера). Также важно протестировать кастомную логику state через LZEndpointMock, чтобы избежать потери данных. В нашей практике мы всегда используем формальную верификацию для контрактов.

Стек для полноценного ONFT проекта

Компонент Инструменты
Контракты Solidity 0.8.x, @layerzerolabs/lz-evm-oapp-v2 (LZ v2) или @layerzerolabs/solidity-examples (LZ v1), OpenZeppelin ERC721
Тестирование Foundry с LZEndpointMock (mock LayerZero endpoint для локального тестирования кросс-чейн вызовов)
Frontend wagmi/viem для мультичейн поддержки, отображение estimated fee через estimateSendFee
Деплой Foundry scripts для параллельного деплоя на несколько чейнов + скрипт установки trustedRemote для всех пар

Сравнение ONFT и обычного NFT с бриджем

Параметр ONFT Обычный бридж
Механизм Атомарное сжигание/минтинг Lock-and-mint
Безопасность Единый supply, нет копий Риск подделки, централизация
Скорость ~30 секунд (зависит от L2) До 10 минут (подтверждение на мосте)
Стоимость трансфера $0.5–$2 $1–$5
Совместимость Любые чейны с LayerZero Только пара чейнов моста

LayerZero Protocol обеспечивает атомарность, а OpenZeppelin — стандартные контракты.

Что входит в работу

  • Анализ требований и выбор чейнов (Ethereum, Polygon, Arbitrum, BSC, Optimism, Base и др.)
  • Разработка ONFT-контрактов с кастомной логикой (state, fee, access control)
  • Написание полных тестов (unit + integration с LZEndpointMock)
  • Создание frontend-компонента для бриджа (выбор сети, fee estimation, статус)
  • Деплой на все целевые чейны и конфигурация trusted remote
  • Документация по эксплуатации и поддержка после запуска
  • Аудит смарт-контрактов (опционально)

Процесс и сроки

Проектирование (1 день): список целевых чейнов, наличие on-chain state для синхронизации, кастомная логика в _debitFrom/_creditTo.

Разработка контрактов (2–3 дня): ONFT721 с кастомной логикой, тесты через LZEndpointMock.

Frontend компонент (1 день): бридж-интерфейс с выбором destination chain, fee estimation, статус трансфера.

Деплой и конфигурация (0.5 дня): деплой на все чейны, установка trustedRemote.

Итого: 3–5 дней для базового ONFT без on-chain state. С синхронизацией сложного state — 1–2 недели. Стоимость рассчитывается индивидуально.

Подробнее о trusted remoteTrusted remote — это список адресов контрактов ONFT на других чейнах, которым разрешено отправлять сообщения. Установка bidirectional обязательна, иначе трансфер будет работать только в одну сторону.

Почему ONFT лучше обычного NFT с бриджем?

ONFT превосходит классические бриджи в 3 раза по безопасности благодаря атомарной передаче без lock-and-mint. Кроме того, скорость трансфера в 2 раза выше, так как не требуется ожидание подтверждения нескольких блоков на мосте. Для пользователя это означает единый токен с историей на всех чейнах. Экономия на газовых затратах при межсетевых операциях достигает 40%.

Мы специализируемся на разработке ONFT уже более 5 лет и выполнили свыше 10 проектов с интеграцией LayerZero. Закажите разработку ONFT под ключ — мы подберем оптимальную архитектуру и сроки. Пишите для оценки вашего проекта.

Почему разработка NFT маркетплейсов требует комплексного подхода?

Мы видим, что на первый взгляд NFT-контракт выглядит просто: ERC-721, mint(), IPFS для метаданных, всё. На практике именно в этой «простоте» прячется большинство проблем — от ботов, скупающих весь mint в первый блок, до сломанных royalties на вторичном рынке. Типовой запрос: «Сделайте коллекцию как у других за неделю», а через месяц выясняется, что газ вырос втрое из-за неоптимизированного for-цикла, а OpenSea не видит метаданные после reveal. Мы знаем каждый из этих граблей и строим процессы так, чтобы их избежать.

За 5 лет работы с блокчейнами мы реализовали 40+ NFT-проектов, включая маркетплейсы с динамическими атрибутами и cross-chain мостами. Накопили библиотеку проверенных шаблонов — часть из них разберём ниже.

Какой стандарт выбрать: ERC-721 или ERC-1155?

ERC-721 — каждый токен уникален, один owner. Подходит для коллекций, где каждый NFT имеет индивидуальные атрибуты и прямую привязку owner → tokenId.
ERC-1155 — multi-token стандарт: один контракт хранит и fungible, и non-fungible токены. Использует balanceOf(address, tokenId) вместо ownerOf(tokenId). Одна транзакция может передать несколько разных токенов через safeBatchTransferFrom. Это экономит газ при массовых операциях — важно для игровых айтемов, тикетов, edition-коллекций.

Критерий ERC-721 ERC-1155
Уникальность токена Каждый токен уникален Один tokenId может иметь несколько копий
Баланс пользователя Только ownerOf (один) balanceOf(address, tokenId)
Газ на transfer ~25 000 gas ~18 000 gas (batch — ещё ниже)
Batch operations Нет нативной поддержки safeBatchTransferFrom
Идеальный сценарий Art-коллекции, PFPs Игры, тикеты, editions

Конкретный кейс: игровой проект с 50 видами айтемов, каждый в тираже 10 000. ERC-721 — 500 000 уникальных токенов, огромный overhead на маппинги. ERC-1155 — 50 tokenId, balanceOf на каждого игрока. Газ на transfer ниже в 2–3 раза, деплой контракта дешевле. Для таких задач мы используем OpenZeppelin ERC-1155 с кастомными модификациями.

Метаданные: on-chain vs IPFS vs centralized

Стандартный путь — tokenURI() возвращает ссылку на JSON с полями name, description, image, attributes. Три варианта хранения:

  • Centralized server — самый дешёвый и гибкий. Риск: сервер падает, компания закрывается — NFT теряет метаданные. Не подходит для коллекций с претензией на долгосрочную ценность.
  • IPFS + Pinning — контентно-адресуемое хранилище, ссылка привязана к хешу содержимого. Pinata или NFT.Storage обеспечивают pinning. Важно: IPFS не гарантирует доступность сам по себе — нужен активный pinning service. Если он закроется, данные могут исчезнуть, если никто не хранит копию.
  • On-chain metadata — base64-encoded SVG или JSON прямо в tokenURI. Максимальная надёжность, но дорого: для коллекции из 10 000 токенов затраты на газ могут превысить $5000. Подходит для generative art проектов, где визуал генерируется из on-chain атрибутов (Nouns, Loot).

Для большинства коллекций мы выбираем IPFS с Pinata для images + on-chain атрибуты для трейтов — хороший баланс. Файлы перед загрузкой проверяем через валидатор JSON Schema; типичная ошибка — неэкранированные кавычки, из-за чего маркетплейсы показывают пустой экран.

Dynamic NFT: метаданные, которые меняются

Dynamic NFT обновляет метаданные в ответ на внешние события — результаты матчей, уровень персонажа, реальные данные через Chainlink. Архитектурно это связка: смарт-контракт хранит state → tokenURI() генерирует метаданные из state on-chain. Проблема с кешированием: OpenSea и другие маркетплейсы агрессивно кешируют. Стандартный механизм инвалидации — MetadataUpdate(tokenId) event из ERC-4906. OpenSea слушает этот event и сбрасывает кеш. Без него обновлённые метаданные могут не отображаться неделями.

Chainlink Automation (бывший Keepers) для автоматического обновления state на контракте по расписанию или по условию — стандартное решение для динамики.

Как защитить mint от ботов?

Allowlist через merkle tree — стандарт. Список адресов хешируется в merkle root, хранится в контракте. При mint пользователь предоставляет merkle proof — контракт проверяет без хранения полного списка. Используем OpenZeppelin MerkleProof library.

Reveal механика — при mint выдаётся placeholder, реальные трейты reveal-ятся после окончания продажи. Иначе боты могут сканировать pending транзакции и снайперить редкие трейты через frontrunning. Но reveal требует commitment scheme — случайный seed должен быть зафиксирован до mint или использовать Chainlink VRF.

Chainlink VRF для честной рандомизации трейтов. VRF request в момент mint → callback с verifiable random number → assign traits. Это добавляет ~2 транзакции и latency, но гарантирует честность. Ссылка на Chainlink VRF v2.5.

Rate limitingrequire(mintedPerWallet[msg.sender] < maxPerWallet). Не защищает от мульти-кошельков, но поднимает стоимость атаки. Для премиум-проектов часто добавляем proof-of-work прямо в контракт (через EIP-2612 signatures).

Royalties: реальное состояние рынка

ERC-2981 — on-chain стандарт royalties. Контракт возвращает (recipient, amount) для любой sale price через royaltyInfo(tokenId, salePrice). Маркетплейсы опрашивают это при каждой продаже. Проблема: соблюдение royalties — добровольное решение маркетплейса. Blur запустился с нулевыми royalties, что вызвало волну других платформ. Сейчас ситуация частично стабилизировалась: OpenSea поддерживает ERC-2981, Blur добавил опциональные.

Попытки enforce royalties on-chain через ограничение transfers только на approved маркетплейсы (operator filtering) OpenSea предлагал через OperatorFilterRegistry. Это ломает composability — нельзя передать NFT через кастомный контракт. Большинство серьёзных проектов отказались от этого подхода. Для проектов, где royalties критичны, мы строим кастомный маркетплейс внутри экосистемы + incentive structure для пользователей торговать именно там.

Lazy minting и gas-free mint

Gas-free mint через подпись: создатель подписывает voucher (tokenId, tokenURI, price, signature), покупатель предоставляет voucher в mint() — контракт верифицирует подпись через ECDSA.recover() и минтит. Работает на OpenSea через их Seaport протокол. Seaport — оптимизированный контракт с минимальным gas usage. Понимание его механики важно при интеграции custom marketplace логики.

Стек для NFT-проектов

  • Контракты: Solidity 0.8.x, OpenZeppelin ERC721Enumerable или ERC721A (Azuki) для gas-оптимизированного batch mint, ERC1155 от OpenZeppelin
  • VRF и автоматизация: Chainlink VRF v2.5, Chainlink Automation
  • Хранение: Pinata (IPFS pinning), NFT.Storage, Arweave для постоянного хранения
  • Маркетплейс: OpenSea Seaport protocol, кастомная интеграция
  • Фронтенд: wagmi v2 + viem, RainbowKit для wallet connection, React + TypeScript

Процесс разработки

  1. Проектирование mint-механики — allowlist, public sale, price curve (Dutch auction или фиксированная), limits per wallet
  2. Контракты — с Foundry fuzz-тестами на mint limits, merkle proof-верификацию, royalty calculations
  3. IPFS деплой — загрузка метаданных и images до reveal, pinning на минимум двух сервисах
  4. Reveal — если используется Chainlink VRF, тест на testnet обязателен: VRF subscription должен быть funded LINK токенами
  5. Маркетплейс-интеграция — верификация коллекции на OpenSea, настройка royalties, тест MetadataUpdate events
  6. Деплой и мониторинг — Tenderly для отлова reentrancy, Etherscan API для верификации контракта, настройка оповещений по событиям

Что входит в работу (deliverables)

  • Исходный код смарт-контрактов (Solidity, Rust для Solana) с комментариями
  • Тест-сьют (Foundry/Hardhat) с покрытием ≥90%
  • Документация развёртывания и инструкции по интеграции
  • Доступы к pinning-сервисам (Pinata/Pinfluence)
  • Скрипты для генерации метаданных (Python/JS)
  • Поддержка при верификации на маркетплейсах
  • 30 дней технической поддержки после деплоя

Сроки

Тип задачи Примерный срок
Базовый ERC-721 без reveal от 2 недель
NFT-коллекция с allowlist, reveal, VRF от 5 недель
ERC-1155 с marketplace и royalties от 6 недель
Dynamic NFT с внешними данными от 8 недель

Стоимость рассчитывается индивидуально после аудита вашей задачи. Пришлите brief с описанием проекта — оценим прозрачно в течение 3 рабочих дней. Для постоянных клиентов действует гибкая система скидок на пакетные заказы. Свяжитесь с нами для детального обсуждения вашего NFT-проекта. Получите консультацию по архитектуре маркетплейса — оставьте заявку, и мы оценим проект за три дня.