Настройка приема ставок в Ethereum для казино

Настройка приёма ставок в Ethereum для казино

Ключевая проблема интеграции Ethereum в онлайн-казино — это не "как принимать ETH", это "как обеспечить честность и мгновенность при том что блокчейн медленный и публичный". Клиент нажимает "поставить" — и не может ждать 12 секунд подтверждения. А использовать blockhash как источник рандомности — это приглашение для майнеров манипулировать результатом.

Архитектура для онлайн-казино

Два фундаментально разных подхода:

On-chain казино — смарт-контракт управляет всей логикой: приём ставки, определение результата, выплата. Полностью прозрачно и trustless. Проблемы: latency (12 сек на блок), gas стоимость каждого действия, ограниченность рандомности. Подходит для poker/blackjack с медленным темпом или slot machines через VRF.

Hybrid казино — депозиты и выводы on-chain, игровые сессии off-chain. Самый распространённый подход для casino: пользователь депонирует ETH/USDC в смарт-контракт, получает внутренние кредиты, играет мгновенно off-chain, выводит on-chain. Баланс доказывается через Merkle proof или ZK proof.

Большинство практических реализаций — hybrid.

Смарт-контракт для депозитов и выводов

// 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 первоначального состояния сессии.

Приём USDC/USDT вместо ETH

Большинство игроков предпочитают стейблкоины — нет волатильности. Добавить поддержку 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 (Base, Arbitrum) — gas в 50-100x дешевле.

L2-оптимизация

Оптимальная инфраструктура для казино в 2024 году — Base или Arbitrum One:

• Gas депозита/вывода: $0.01-0.10 (vs $2-10 на mainnet)
• Скорость подтверждения: 1-2 сек (L2 финальность достаточна для казино)
• USDC от Circle нативно доступен на Base и Arbitrum

Развернуть контракт на Base — то же самое что на Ethereum mainnet, просто меняется --rpc-url в foundry deploy script.

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

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