Розробка блокчейн-слотів: смарт-контракти, VRF, бонуси

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1305 послуг
Розробка блокчейн-слотів: смарт-контракти, VRF, бонуси
Середній
~1-2 тижні
Часті запитання

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

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

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1351
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    951
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1186
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    642
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    922

Гравці не довіряють онлайн-слотам: алгоритм на сервері можна підкрутити, RTP змінюється за одну ніч. Блокчейн-слоти вирішують цю проблему — кожен спін записується в смарт-контракт, і результат незмінний. Але розробка такого контракту вимагає врахування газу, швидкості VRF і бонусних механік. Розглянемо, як ми будували класичний 5-барабанний слот із 20 лініями виплат. Замовте розробку блокчейн-слоту, щоб залучити довірливих гравців.

Чому блокчейн змінює правила в слотах?

Звичайний слот — серверний софт із закритим генератором випадкових чисел. Гравець вірить на слово. Блокчейн-слот публікує контракт, кожен спін викликається, результат фіксується. Але з'являються проблеми: вартість газу, затримка VRF, складність бонусних механік. Ми вирішуємо їх комбінацією оптимізації контракту та вибору L2.

Як працює смарт-контракт Slots?

contract BlockchainSlots is VRFConsumerBaseV2Plus {
    // Віртуальні стріпи барабанів
    // Індекс = позиція на стріпі, значення = символ (0-8)
    uint8[64] public reel1Strip;
    uint8[64] public reel2Strip;
    uint8[64] public reel3Strip;
    uint8[64] public reel4Strip;
    uint8[64] public reel5Strip;
    
    // Pay table: symbol combination -> multiplier (у basis points)
    mapping(bytes32 => uint256) public payTable;
    
    struct SpinRequest {
        address player;
        uint256 betAmount;
        uint256 lines; // кількість активних paylines
    }
    
    mapping(uint256 => SpinRequest) public pendingSpins;
    
    function spin(uint256 lines) external payable returns (uint256 requestId) {
        require(lines >= 1 && lines <= 20, "Invalid lines");
        require(msg.value >= MIN_BET * lines, "Insufficient bet");
        
        requestId = _requestRandomWords(3); // 3 random words
        
        pendingSpins[requestId] = SpinRequest({
            player: msg.sender,
            betAmount: msg.value,
            lines: lines
        });
    }
    
    function fulfillRandomWords(uint256 requestId, uint256[] calldata randomWords) internal override {
        SpinRequest memory spinReq = pendingSpins[requestId];
        delete pendingSpins[requestId];
        
        // Визначаємо позиції барабанів із random числа
        uint8[5] memory reelPositions;
        reelPositions[0] = uint8(randomWords[0] % 64);
        reelPositions[1] = uint8((randomWords[0] >> 8) % 64);
        reelPositions[2] = uint8((randomWords[0] >> 16) % 64);
        reelPositions[3] = uint8(randomWords[1] % 64);
        reelPositions[4] = uint8((randomWords[1] >> 8) % 64);
        
        // Отримуємо символи для 3 рядів кожного барабана
        uint8[5][3] memory grid = _buildGrid(reelPositions);
        
        // Рахуємо виграш за всіма активними paylines
        uint256 totalPayout = _calculatePayout(grid, spinReq.betAmount, spinReq.lines);
        
        if (totalPayout > 0) {
            payable(spinReq.player).transfer(totalPayout);
        }
        
        emit SpinResult(spinReq.player, reelPositions, grid, totalPayout, requestId);
    }
    
    function _buildGrid(uint8[5] memory positions) internal view returns (uint8[5][3] memory grid) {
        // Для кожного барабана беремо 3 послідовних символи (wrap-around)
        for (uint i = 0; i < 5; i++) {
            uint8 pos = positions[i];
            grid[i][0] = _getSymbol(i, (pos + 63) % 64);  // рядок вище
            grid[i][1] = _getSymbol(i, pos);               // середній рядок
            grid[i][2] = _getSymbol(i, (pos + 1) % 64);   // рядок нижче
        }
    }
    
    function _calculatePayout(
        uint8[5][3] memory grid,
        uint256 betAmount,
        uint256 activeLines
    ) internal view returns (uint256 payout) {
        uint256 betPerLine = betAmount / activeLines;
        
        // Перевіряємо кожну payline
        for (uint l = 0; l < activeLines; l++) {
            uint8[5] memory line = _getPayline(l, grid);
            uint256 lineMultiplier = _getLineMultiplier(line);
            
            if (lineMultiplier > 0) {
                payout += (betPerLine * lineMultiplier) / 100;
            }
        }
    }
}

Як Chainlink VRF гарантує чесність?

Chainlink VRF — це оракул, який повертає випадкове число разом із криптографічним доказом. Доказ верифікується в контракті: ні розробник, ні гравець не можуть вплинути на результат. На відміну від традиційних PRNG, VRF повністю прозорий. На практиці ми використовуємо VRF v2, який дешевший і підтримує підписку на ліквідність. Як зазначено в документації Chainlink VRF v2, кожен запит включає доказ, який можна перевірити on-chain. Середня комісія за запит VRF v2 — близько 0.0001 LINK.

Які бонусні механіки можна реалізувати?

function _checkBonusFeatures(uint8[5][3] memory grid) internal pure 
    returns (bool hasFreeSpin, uint256 freeSpinCount, bool hasBonusGame) 
{
    uint256 scatterCount = 0;
    for (uint col = 0; col < 5; col++) {
        for (uint row = 0; row < 3; row++) {
            if (grid[col][row] == SCATTER_SYMBOL) scatterCount++;
        }
    }
    
    if (scatterCount >= 3) {
        hasFreeSpin = true;
        freeSpinCount = scatterCount == 3 ? 10 : scatterCount == 4 ? 15 : 20;
    }
    
    // Bonus game при 3+ bonus символах на payline 1
    hasBonusGame = _checkBonusLine(grid);
}

Slots без бонусних механік не конкурентоспроможні. Обов'язкові: Free Spins (scatter символи запускають серію безкоштовних спінів з підвищеним multiplier), Wild символи (замінюють будь-який символ для формування winning combination), Multiplier Wilds (з ×2, ×3 множником), Expanding Wilds (розширюються на весь барабан) та Bonus game (pick-me механіка). Всі ці механіки реалізовані на рівні смарт-контракту, що виключає маніпуляції.

Підсумкова таблиця: порівняння традиційних та блокчейн-слотів

Параметр Традиційний слот Блокчейн-слот
Генерація результату Сервер, PRNG On-chain VRF
Прозорість Ні Так (перевірка в блокчейні)
Захист від підкрутки Ні Математично гарантовано
Швидкість спіну Миттєво 3–15 секунд (залежить від мережі)
Комісія Ні (оплачує казино) Газ мережі (від $0.001 до $0.50)
Можливість інтеграції токенів Ні ERC-20/NFT

Приклад таблиці виплат для символів

Символ 3 в лінії 4 в лінії 5 в лінії
Wild 100 500 2500
7 50 200 1000
BAR 25 100 500
Вишня 10 40 150

Процес роботи над проєктом

  1. Аналітика та математика — узгодження RTP, таблиці виплат, ймовірностей.
  2. Проєктування смарт-контракту — вибір шаблону, VRF, бонусних механік.
  3. Розробка на Solidity — контракт з Foundry, покриття unit-тестами.
  4. Frontend-інтеграція — анімації (Pixi.js/Three.js) + Web3-гаманець.
  5. Тестування та аудит — статичний аналіз (Slither), fuzzing (Echidna), тестнет.
  6. Деплой та запуск — вибір L2 (Arbitrum/Polygon), верифікація контракту.
Оптимізація газу: як ми знижуємо вартість спіну

Головний виклик — gas cost. Ми використовуємо стріпи 64 позицій замість 32, пакуємо кілька випадкових чисел в один uint256, і застосовуємо payTable на mapping з keccak256 для швидкого пошуку. Це економить до 30% газу порівняно з наївною реалізацією. Деплой на L2 (наприклад, Polygon або Arbitrum) знижує комісію ще на порядок. За рахунок цих заходів середня вартість одного спіну на Polygon становить близько $0.01.

Що входить у результат

  • Смарт-контракт з VRF, pay table та бонусними функціями.
  • Frontend з анімацією спіну та інтеграцією користувацького гаманця.
  • Документація коду та інструкції з деплою.
  • Тестова документація та звіт про аудит.
  • Підтримка на етапі запуску.

Орієнтовні терміни

Розробка повноцінного Slots (5 барабанів, 20 ліній, Free Spins, Wild) займає від 4 до 6 тижнів на смарт-контракт і ще 4–8 тижнів на frontend. Час залежить від складності бонусних механік та обраної мережі.

Наша команда має багаторічний досвід у блокчейн-розробці, понад 20 випущених ігрових проєктів на Ethereum, BNB Chain та Polygon. Ми гарантуємо чесність закладених математичних розрахунків та прозорість контракту. Отримайте консультацію — оцінимо ваш проєкт і запропонуємо оптимальне рішення. Зв'яжіться з нами, щоб обговорити деталі вашого слоту та підібрати ефективну архітектуру.

GameFi розробка: ігрова економіка, контракти та on-chain механіка

Ми бачили цей сценарій не раз. Axie Infinity на піку мала великий дохід, але через 18 місяців токен різко знецінився, а аудиторія значно скоротилася. Причина — відсутність sink'ів: гравці заробляли SLP і виводили, а механізмів спалювання не вистачало. Ми пропонуємо GameFi розробку під ключ: від токеноміки до смарт-контрактів, щоб ваша економіка не повторила цю помилку. Оцінимо ваш проєкт на meetup або онлайн. Наш досвід — 5+ років, десятки реалізованих проєктів, включно з аудитом 15+ P2E ігор.

Чому ламається Play-to-Earn економіка?

Інфляційна токеноміка без sink'ів — головна причина смертельної спіралі. Гравець отримує токени за геймплей. Якщо sink'ів (механізмів спалювання або споживання) недостатньо — supply зростає швидше за demand. Ціна падає. Дохід гравця у fiat зменшується. Гравці йдуть.

Правильна конструкція — dual-token модель з чітким розподілом: governance/value token з обмеженим supply і utility/reward token для внутрішньоігрової економіки. Utility token має активно споживатися: крафтинг предметів, апгрейди, entry fees, breeding. Приклади: GODS/FLUX у Gods Unchained, AXS/SLP у Axie (хоча sink'ів там виявилося недостатньо). Ефективна економіка балансує mint та burn: типовий ratio — 1.2—1.5 burn на 1 mint для запобігання інфляції.

Які sink-механізми реально працюють?

Механізм Опис Приклад
Breeding / крафтинг Спалювання utility token за створення нового NFT Axie (але з правильним balancing)
Апгрейди персонажів Кожна еволюція вимагає спалювання токена Більшість P2E RPG
PvP entry fee Вхід у турнір спалює токени, частина йде в призовий пул Splinterlands
Дурабилити предметів Після N боїв предмет ламається, токен витрачається на ремонт Успадковано з MMORPG
Фінансові механіки Стейкінг з lock-up, що виводить токени з обігу на строк DeFi-шари

Наш досвід — десятки реалізованих проєктів у Web3, включно з аудитом 15+ P2E ігор. Ми знаємо, які sink'и працюють у довгостроковій перспективі. Наприклад, у проєкті з breeding RPG ми збільшили спалювання utility token на 300% за рахунок введення «ремеслу зношуваності» та обов'язкових апгрейдів.

On-chain vs Off-chain: де проходить межа

Всю ігрову логіку on-chain виносити не потрібно — кожна транзакція коштує газу і триває 12 секунд. Ігровий цикл — мілісекунди. Баланс:

Компонент On-chain Off-chain Приклади
Ownership активів + NFT предмети, land
Передача/торгівля + Маркетплейси
Фінанси (стейкінг, rewards) + Staking vaults, DAO
Random generation + (через VRF) Chainlink VRF
Ігровий процес + Бойова система, рух
State ігрового світу + Координати, health points
Матчмейкінг + Серверна логіка

Результати геймплею переносяться на блокчейн через signed message від сервера або ZK-proof. Verifiable off-chain з ZK: ігровий сервер генерує ZK-proof коректності сесії, контракт верифікує proof і нараховує винагороду. Реалізації: Cartridge (Starknet), zkSync game rollups.

Реалізація NFT ігрових предметів

Стандарт: ERC-1155 для взаємозамінних предметів (ресурси, consumables) + ERC-721 для унікальних (персонажі, land). ERC-1155 дає до 60% економії на газі при batch transfer у порівнянні з окремими ERC-721 переказами — для гри з сотнями предметів це економія сотень доларів на день.

Як реалізувати динамічні NFT без перевантаження блокчейна?

Характеристики предмета змінюються в процесі гри (experience, durability, upgrades). Два підходи:

  • Fully on-chain: атрибути зберігаються в mapping контракту, tokenURI генерується з атрибутів через SVG/JSON encoding. Дорого за газом при частому оновленні. Використовується для land і ключових активів.
  • Hybrid: атрибути зберігаються off-chain, в tokenURI — hash стану. Оновлення підписується сервером, верифікується on-chain при transfer або продажі. Дешевше, але вимагає довіри до сервера або ZK.

Breeding і crafting. Контракт: два батьківських NFT → оплата utility token (burn) → мінт нового NFT з атрибутами, що залежать від батьків + Chainlink VRF для випадковості. Без VRF майнери можуть маніпулювати рандомом через вибір блоку.

// Simplified breeding with Chainlink VRF
function breed(uint256 parent1Id, uint256 parent2Id) external {
    require(ownerOf(parent1Id) == msg.sender);
    require(ownerOf(parent2Id) == msg.sender);
    require(breedingToken.burnFrom(msg.sender, BREEDING_COST));

    uint256 requestId = vrfCoordinator.requestRandomWords(...);
    pendingBreeds[requestId] = BreedRequest(parent1Id, parent2Id, msg.sender);
}

function fulfillRandomWords(uint256 requestId, uint256[] memory randomWords) internal override {
    BreedRequest memory req = pendingBreeds[requestId];
    uint256 childAttributes = deriveAttributes(req.parent1Id, req.parent2Id, randomWords[0]);
    _mintWithAttributes(req.requester, childAttributes);
}

Маркетплейс і роялті

Вбудований маркетплейс дає контроль над fee структурою та кастомною логікою (заборона торгівлі предметами до певного рівня). Роялті за EIP-2981 — стандарт, але не enforceable: Blur та інші маркетплейси ігнорують on-chain роялті. Для enforcement — whitelist-only transfer (тільки через контракти, що платять роялті). Жертвуємо composability заради захисту прав.

Staking та розподіл винагород

Staking NFT — механіка для утримання гравців. Проблема: нарахування rewards при тисячах стейкерів вимагає постійних транзакцій (дорого). Рішення — reward-per-share паттерн (як у MasterChef від SushiSwap): глобальний accRewardPerShare, при claim або change state перераховується заборгованість за формулою pendingReward = stakedAmount * (accRewardPerShare - userRewardDebt). O(1) складність незалежно від кількості стейкерів. Економія газу — до 70% порівняно з поелементним нарахуванням.

Детальніше про reward-per-shape реалізацію

Алгоритм працює так: при кожному депозиті/знятті стейку або при оновленні глобального пулу (наприклад, додаванні нових токенів винагороди) контракт оновлює accRewardPerShare = totalPendingReward / totalStaked. Потім для конкретного користувача розраховується pending = user.staked * (accRewardPerShare - user.rewardDebt). Після виплати user.rewardDebt встановлюється рівним accRewardPerShare. Це дозволяє не зберігати історію внесків кожного користувача. На практиці ми використовуємо для GameFi проєктів версію з multiplier для врахування різних ваг стейку (наприклад, рідкісні NFT дають більше винагороди).

Процес та терміни

Починаємо з game economics документа: token flows, mint/burn механіки, projected supply schedule, sink analysis. До написання коду економіка моделюється (Cadence, Python simulation).

Як ми будуємо GameFi: 5 етапів

  1. Економічне моделювання — 1-2 тижні. Розробляємо dual-token модель, розраховуємо sink'и, прописуємо стимули для long-term holding.
  2. Розробка токен-контрактів — 2-3 тижні. ERC-20 для governance, ERC-20 для utility, з настроюваною політикою mint/burn.
  3. Смарт-контракти NFT — 3-5 тижнів. ERC-721 / ERC-1155 з dynamic metadata, breeding/crafting, Chainlink VRF.
  4. Staking + rewards — 2-3 тижні. Контракт на базі reward-per-share, інтерфейси для frontend.
  5. Маркетплейс (опціонально) — 2-4 тижні. Кастомний маркетплейс з enforced royalty.

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

  • Вихідний код усіх смарт-контрактів з тестами (Foundry/Hardhat)
  • Документація архітектури та економіки
  • Інтеграція з Chainlink, Tenderly для моніторингу
  • Аудит коду та формальна верифікація (Slither, Mythril, Echidna)
  • Навчання команди роботі з контрактами
  • Підтримка після деплою (3 місяці)

Базовий GameFi стек (токени + NFT + staking + маркетплейс) — від 8 до 16 тижнів. Повна гра з on-chain рандомом, breeding, dynamic NFT — 4-8 місяців. ZK-based verifiable gameplay — окремий проєкт від 6 місяців.

Зв'яжіться з нами для аудиту вашої токеноміки — оцінимо ризики та доопрацюємо sink-механізми. Замовте розробку GameFi проєкту — отримайте готовий продукт з перевіреною економікою. Наш досвід — десятки реалізованих проєктів у Web3, включно з аудитом 15+ P2E ігор. Гарантуємо стабільність контрактів і прозорість коду. Сертифіковані аудитори перевіряють кожен контракт на типові вразливості (reentrancy, flash loan, oracle manipulation).