Розробка ERC-1155 токена (мульти-токен)

ERC-721 хороший для унікальних активів, ERC-20 — для взаємозамінних. Але що робити, коли вашому проєкту потрібні обидва типи одночасно? Типова ситуація: в ігровому проєкті золото та ресурси — fungible токени, персонажі — NFT, зілля — semi-fungible (100 одиниць одного типу). До появи ERC-1155 для цього потрібно було деплоїти кілька контрактів — дорого та незручно. Ми розробляємо єдиний мульти-токен контракт на основі EIP-1155, який вирішує це завдання з суттєво меншим gas overhead. У цій статті розберемо технічні деталі: від проектування ID схеми до інтеграції з OpenSea. Наш досвід показує, що перехід на ERC-1155 знижує витрати на газ на 40–60%, що при активній торгівлі економить тисячі доларів на місяць. Зв'яжіться з нами для консультації — оцінимо ваш проєкт за 1 день.

Порівняння: ERC-1155 vs ERC-20+ERC-721

ERC-1155 виконує batch transfers у 3 рази швидше по газу порівняно з окремими ERC-20 та ERC-721 контрактами, що робить його ідеальним для high-volume ігор.

Як працює batch transfer в ERC-1155?

Головна перевага — можливість передавати кілька токенів різного типу за одну транзакцію. Замість N викликів transferFrom:

// ERC-721: N транзакцій for (uint i = 0; i < tokenIds.length; i++) { nft.transferFrom(from, to, tokenIds[i]); // N*gas } // ERC-1155: одна транзакція erc1155.safeBatchTransferFrom(from, to, ids, amounts, data); // ~gas 

Економія газу при batch transfer: 40–60% порівняно з роздільними транзакціями. Це критично для ігор з частими внутрішньоігровими переказами. В одному з кейсів для MMORPG з 10 000 щоденних транзакцій ми скоротили витрати на газ на $2 000 на місяць.

Чому варто використовувати OpenZeppelin для ERC-1155?

OpenZeppelin ERC1155 — перевірений та протестований базовий контракт. Він коректно реалізує callback-безпеку та включає корисні розширення. Ми завжди починаємо з нього:

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol"; import "@openzeppelin/contracts/token/ERC1155/extensions/ERC1155Burnable.sol"; import "@openzeppelin/contracts/token/ERC1155/extensions/ERC1155Supply.sol"; import "@openzeppelin/contracts/access/AccessControl.sol"; import "@openzeppelin/contracts/token/ERC1155/extensions/ERC1155URIStorage.sol"; contract GameItems is ERC1155, ERC1155Burnable, ERC1155Supply, AccessControl { bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE"); mapping(uint256 => string) private _tokenURIs; constructor() ERC1155("") { _grantRole(DEFAULT_ADMIN_ROLE, msg.sender); _grantRole(MINTER_ROLE, msg.sender); } function mint(address to, uint256 id, uint256 amount, bytes memory data) external onlyRole(MINTER_ROLE) { _mint(to, id, amount, data); } function mintBatch(address to, uint256[] memory ids, uint256[] memory amounts, bytes memory data) external onlyRole(MINTER_ROLE) { _mintBatch(to, ids, amounts, data); } } 

OpenZeppelin Contracts are audited by independent security firms and used in thousands of production contracts.

Проектування ID схеми: наш підхід на практиці

Для складних проєктів (наприклад, MMORPG з тисячами предметів) ми використовуємо bit-packed ID — різні частини uint256 кодують категорію, рідкість, тип та екземпляр. Це дозволяє фільтрувати токени без зберігання додаткових даних:

// Приклад: верхні 128 біт = тип, нижні 128 = instance ID uint256 constant TYPE_MASK = uint256(type(uint128).max) << 128; uint256 constant NF_INDEX_MASK = type(uint128).max; function getTokenType(uint256 id) internal pure returns (uint256) { return id & TYPE_MASK; } function isNonFungible(uint256 id) internal pure returns (bool) { return id & TYPE_MASK == id; // instance ID = 0 значить базовий тип } 

Така схема дає гнучкість: всередині одного контракту можна випускати як масові витратні матеріали, так і легендарні мечі з унікальними ID. Для проєктів з простою логікою підходить послідовна нумерація — дешевше на рівні обчислень, але складніше в аналітиці.

On-chain метадані для простих токенів

Для базових активів (ігрова валюта, ресурси) ми зберігаємо атрибути прямо в контракті, генеруючи JSON через uri():

function uri(uint256 id) public view override returns (string memory) { ItemDefinition memory item = itemDefinitions[id]; return string(abi.encodePacked( 'data:application/json;base64,', Base64.encode(bytes(abi.encodePacked( '{"name":"', item.name, '","description":"', item.description, '","attributes":[{"trait_type":"rarity","value":"', item.rarity, '"}]}' ))) )); } 

Це виключає залежність від зовнішнього API та знижує ризики цензурування.

Типові помилки та як їх уникнути

Що входить в роботу

• Проектування ID схеми під бізнес-логіку
• Розробка смарт-контракту на Solidity з модульними тестами (Foundry)
• Розгортання на Ethereum, Polygon, Arbitrum або BNB Chain
• Інтеграція з OpenSea через EIP-2981 (роялті)
• Повна документація та підтримка після запуску

Чому обирають нас

Ми займаємося Web3-розробкою з 2018 року, реалізували 30+ проєктів на Ethereum, Polygon та Solana. Кожен контракт проходить внутрішній аудит з використанням Slither та Mythril. Гарантуємо безпеку та відповідність стандартам.

Хочете обговорити розробку мульти-токен контракту? Напишіть нам — оцінимо проєкт за 1 день. Замовте розробку ERC-1155 токена з гарантією безпеки та аудитом.