Налаштування прийому ставок в Ethereum: архітектура та реалізація

Налаштування прийому ставок в Ethereum: архітектура та реалізація

Уявіть: гравець робить ставку, а транзакція підтверджується 12 секунд. За цей час він встигає передумати або втратити інтерес. А якщо ви використовуєте blockhash як джерело випадковості — ви добровільно віддаєте ключі від казино майнерам. Ми стикалися з проектами, де reentrancy у vault призводив до втрати всієї ліквідності, а помилки в розрахунку fee-on-transfer токенів — до збитків у десятки тисяч доларів. Наш досвід — 5 років в Ethereum та 15+ інтеграцій для гемблінгу — дозволяє побудувати надійну архітектуру під ключ з аудитом. Розповімо, як уникнути типових проблем і обрати оптимальне рішення для вашого казино.

Єдине доказово безпечне джерело випадковості — Chainlink VRF, як зазначено в документації.

Ethereum casino: гібридна архітектура під ключ

Два фундаментально різні підходи — on-chain та hybrid. Вибір визначає швидкість, вартість і прозорість. On-chain підходить для повільних ігор (покер, блекджек), де кожен хід фіксується в блокчейні. Hybrid — для масових швидких ігор (слоти, рулетка): депозит та виведення on-chain, а ігрова логіка off-chain з криптографічним доказом балансу.

Порівняння підходів

Як вибрати між on-chain та hybrid?

Якщо ваша аудиторія — хардкорні криптоентузіасти, готові платити за повну децентралізацію, обирайте on-chain. Для масового користувача, звиклого до миттєвих слотів, потрібен hybrid: депозити та виведення on-chain, ігрова логіка off-chain з операторськими підписами. У hybrid-архітектурі ви економите до 95% на транзакційних витратах порівняно з on-chain. Це дозволяє зекономити понад $10,000 на рік при середньому обсязі ставок.

Смарт-контракт Vault: прийом ETH та ERC-20

Ключовий елемент — контракт Vault, який приймає ETH та ERC-20 токени. Використовуємо паттерн operator signature: оператор підписує право гравця на виведення, що дозволяє авторизовувати виплати без on-chain транзакції на кожен хід.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract CasinoVault is ReentrancyGuard, Ownable {
    mapping(address => uint256) public ethBalances;
    mapping(address => mapping(address => uint256)) public tokenBalances;

    // Авторизовані оператори для off-chain виплат
    mapping(address => bool) public operators;

    event Deposited(address indexed user, address indexed token, uint256 amount);
    event Withdrawn(address indexed user, address indexed token, uint256 amount);

    function depositETH() external payable {
        require(msg.value > 0, "Zero deposit");
        ethBalances[msg.sender] += msg.value;
        emit Deposited(msg.sender, address(0), msg.value);
    }

    function depositToken(address token, uint256 amount) external nonReentrant {
        IERC20(token).transferFrom(msg.sender, address(this), amount);
        tokenBalances[msg.sender][token] += amount;
        emit Deposited(msg.sender, token, amount);
    }

    // Виведення з підписом оператора (off-chain баланс верифіковано)
    function withdrawWithSignature(
        address token,
        uint256 amount,
        uint256 nonce,
        bytes calldata signature
    ) external nonReentrant {
        bytes32 hash = keccak256(abi.encodePacked(
            msg.sender,
            token,
            amount,
            nonce,
            address(this),
            block.chainid
        ));
        bytes32 ethHash = MessageHashUtils.toEthSignedMessageHash(hash);
        address signer = ECDSA.recover(ethHash, signature);
        require(operators[signer], "Invalid operator signature");
        require(!usedNonces[nonce], "Nonce used");
        usedNonces[nonce] = true;
        // виплата...
    }

    mapping(uint256 => bool) public usedNonces;
}

Паттерн operator signature дозволяє off-chain системі авторизувати виведення. Оператор підписує "користувач X має право вивести Y токенів" — це не вимагає on-chain транзакції для кожного ігрового ходу.

Верифікований рандом: Chainlink VRF v2.5

Для on-chain ігор (slots, dice, roulette) єдине надійне джерело рандомності на EVM — Chainlink VRF. Використання block.prevrandao (колишній blockhash) небезпечне: валідатори Ethereum можуть впливати на значення RANDAO.

import "@chainlink/contracts/src/v0.8/vrf/dev/VRFConsumerBaseV2Plus.sol";

contract DiceGame is VRFConsumerBaseV2Plus {
    uint256 s_subscriptionId;
    bytes32 s_keyHash = 0x787d74...; // VRF key hash для Ethereum mainnet

    mapping(uint256 => address) public requestIdToPlayer;
    mapping(uint256 => uint256) public requestIdToBet;

    function rollDice(uint256 betAmount) external payable returns (uint256 requestId) {
        require(msg.value >= betAmount, "Insufficient bet");

        requestId = s_vrfCoordinator.requestRandomWords(
            VRFV2PlusClient.RandomWordsRequest({
                keyHash: s_keyHash,
                subId: s_subscriptionId,
                requestConfirmations: 3, // чекаємо 3 блоки для безпеки
                callbackGasLimit: 100000,
                numWords: 1,
                extraArgs: VRFV2PlusClient._argsToBytes(
                    VRFV2PlusClient.ExtraArgsV1({nativePayment: false})
                )
            })
        );

        requestIdToPlayer[requestId] = msg.sender;
        requestIdToBet[requestId] = betAmount;
    }

    function fulfillRandomWords(uint256 requestId, uint256[] calldata randomWords) internal override {
        uint256 result = (randomWords[0] % 6) + 1; // 1-6
        address player = requestIdToPlayer[requestId];
        uint256 bet = requestIdToBet[requestId];

        if (result >= 4) { // виплата 2x
            payable(player).transfer(bet * 2);
        }
        // інакше ставка залишається в контракті
    }
}

VRF має latency ~1-2 блоки (12-24 сек). Для швидких ігор це неприйнятно — потрібен hybrid підхід: гра продовжується off-chain, VRF використовується лише для seed початкового стану сесії.

Чому потрібен аудит смарт-контракту?

Навіть невелика помилка в контракті Vault може призвести до втрати всіх коштів. Типові вразливості: reentrancy при виплатах, некоректний розрахунок балансу fee-on-transfer токенів, маніпуляція з nonce. Ми включаємо аудит у кожен проект — використовуємо Slither, Mythril та ручний код-рев'ю. Це гарантія, що ваш контракт безпечний і готовий до продакшену. Аудит запобігає втраті ліквідності, яка може обчислюватися сотнями тисяч доларів. За оцінками аудиторських фірм, до 70% вразливостей у гемблінг-контрактах пов'язані з reentrancy.

Прийом USDC/USDT: нюанси fee-on-transfer

Більшість гравців надають перевагу стейблкоїнам — немає волатильності. Додати підтримку ERC-20 у vault контракт тривіально (див. depositToken вище). Важливі нюанси:

USDT має комісію на transfer (fee-on-transfer) в теорії (хоча зараз 0%), потрібно перевіряти фактично отриманий amount. Патерн:

function depositToken(address token, uint256 amount) external {
    uint256 balanceBefore = IERC20(token).balanceOf(address(this));
    IERC20(token).transferFrom(msg.sender, address(this), amount);
    uint256 actualAmount = IERC20(token).balanceOf(address(this)) - balanceBefore;
    tokenBalances[msg.sender][token] += actualAmount; // враховуємо реально отримане
}

Gas для ERC-20 транзакцій дорожче за ETH transfers (~65K gas vs ~21K). На Ethereum mainnet це ~$1-3 при помірному gas. Для казино з дрібними ставками краще працювати на L2 — gas в 50-100x дешевше, що економить близько $0.50 за депозит.

L2-оптимізація: Base vs Arbitrum

Оптимальна інфраструктура для казино — Base або Arbitrum One. Порівняємо:

Розгорнути контракт на Base — те саме, що на Ethereum mainnet, просто змінюється --rpc-url у foundry deploy script. Перехід на L2 знижує транзакційні витрати на 95%.

Як розгорнути контракт казино: покрокова інструкція

1. Виберіть мережу — Base або Arbitrum залежно від вподобань аудиторії.
2. Напишіть контракти — Vault, VRF-споживач, логіка виплат.
3. Протестуйте в Foundry — використовуйте fuzzing та unit-тести.
4. Проведіть аудит — замовте у спеціалізованої фірми або використовуйте автоматичні аналізатори.
5. Розгорніть — налаштуйте скрипти деплою з безпечним управлінням ключами.

Що входить у нашу роботу

Ми надаємо комплексну інтеграцію під ключ:

• Проектування архітектури (on-chain/hybrid) під ваш тип ігор
• Розробка смарт-контрактів Vault, VRF, логіки виплат
• Розгортання на обраній мережі (mainnet/L2) з оптимізацією газу
• Аудит безпеки зі звітом
• Документація щодо інтеграції з вашим бекендом
• Навчання вашої команди роботі з контрактами
• Технічна підтримка після запуску

Зв'яжіться з нами для попередньої оцінки проекту — ми проаналізуємо вимоги та запропонуємо рішення у строк від 2 тижнів. Замовте інтеграцію під ключ — від контрактів до аудиту.

Регуляторні аспекти

Смарт-контракт казино повинен підтримувати: геоблокування на рівні фронтенду (IP-фільтрація), можливість blacklist адрес (OFAC санкції), механізм паузи (emergency stop). Аудит контракту обов'язковий до launch — вразливість у casino vault з ліквідністю означає повний loss of funds. Наш досвід у реалізації регуляторних вимог гарантує відповідність стандартам.