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

Розробка 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 проєкту

Порівняння ONFT та звичайного NFT з бриджем

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 тижні. Вартість розраховується індивідуально.

Чому ONFT краще звичайного NFT з бриджем?

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

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