בלאק ג'ק על השרשרת: ארכיטקטורה, VRF והוכחת הוגנות

דמיינו שאתם רוצים להשיק קזינו בלאק ג'ק מקוון על הבלוקצ'יין. הבעיה היא כיצד להבטיח אקראיות של קלפים מבלי לסמוך על שרת מרכזי? בקזינו מחוץ לשרשרת, השרת מחלק קלפים אבל השחקן לא רואה את החפיסה. על השרשרת, הכל שקוף — כל אחד יכול לקרוא את אחסון החוזה. אם נצור מראש חפיסה ונאחסן אותה, השחקן יכול לראות את כל הקלפים העתידיים. הפתרון הוא commit-reveal עם VRF או Mental Poker. אנו משתמשים ב-Chainlink VRF, אבל עם אופטימיזציה: צור את כל החפיסה בבקשה אחת, ואז הקלפים נחשפים בהדרגה ללא קריאות VRF נוספות. לצוות שלנו יש ניסיון של 7+ שנים ב-Web3 ויישמנו 20+ משחקי בלוקצ'יין ופרויקטי DeFi. צרו קשר לייעוץ ארכיטקטוני וביקורת.

כיצד Chainlink VRF מבטיח אקראיות?

Chainlink VRF מייצר מספר אקראי ניתן לאימות מחוץ לשרשרת עם הוכחה קריפטוגרפית שמאומתת על השרשרת. אף אחד — לא השחקן ולא המפעיל — לא יכול לחזות את התוצאה. זה פי 10 יותר אמין מאחסון seed בחוזה.

זרימה עבור בלאק ג'ק:

1. השחקן מניח הימור, החוזה מבקש VRF
2. מימוש VRF (באמצעות callback) — החוזה מקבל אקראיות, יוצר חפיסה או קלפים ראשונים
3. השחקן מחליט: hit או stand
4. אם hit — בקשת VRF חדשה לקלף הבא

בעיה עם "אם hit": כל בקשת VRF מציגה עיכוב (1-3 בלוקים) ועלות LINK נוספת. לא נוח למשחק בזמן אמת.

אופטימיזציה: בקש את כל החפיסה בבת אחת — קזינו בלאק ג'ק על השרשרת

contract Blackjack is VRFConsumerBaseV2Plus {
    struct Game {
        address player;
        uint256 bet;
        uint8[] deck; // все 52 карты в зашифрованном порядке
        uint8 playerIdx; // текущий индекс в деке
        uint8 dealerIdx;
        bool active;
    }

    mapping(uint256 => Game) public games; // requestId -> game
    mapping(address => uint256) public playerGame; // player -> gameId

    function startGame() external payable {
        require(msg.value >= MIN_BET, "Below minimum bet");
        uint256 requestId = s_vrfCoordinator.requestRandomWords(
            VRFV2PlusClient.RandomWordsRequest({
                keyHash: KEY_HASH,
                subId: subscriptionId,
                requestConfirmations: 3,
                callbackGasLimit: 300000,
                numWords: 1, // одно большое число для shuffle
                extraArgs: VRFV2PlusClient._argsToBytes(
                    VRFV2PlusClient.ExtraArgsV1({nativePayment: false})
                )
            })
        );
        games[requestId] = Game({
            player: msg.sender,
            bet: msg.value,
            deck: new uint8[](0),
            playerIdx: 0,
            dealerIdx: 4, // дилер берёт карты с позиции 4
            active: false // станет true после fulfillment
        });
        playerGame[msg.sender] = requestId;
    }

    function fulfillRandomWords(uint256 requestId, uint256[] calldata randomWords) internal override {
        Game storage game = games[requestId];
        // Fisher-Yates shuffle детерминированный из одного seed
        uint8[52] memory deck;
        for (uint8 i = 0; i < 52; i++) deck[i] = i;
        uint256 seed = randomWords[0];
        for (uint8 i = 51; i > 0; i--) {
            seed = uint256(keccak256(abi.encodePacked(seed)));
            uint8 j = uint8(seed % (i + 1));
            (deck[i], deck[j]) = (deck[j], deck[i]);
        }
        // Первые 4 карты сразу сдаются: player, dealer, player, dealer
        game.deck = new uint8[](52);
        for (uint8 i = 0; i < 52; i++) game.deck[i] = deck[i];
        game.active = true;
        emit GameStarted(requestId, game.player, deck[0], deck[2]); // видимые карты игрока
        // deck[1] и deck[3] - карты дилера, deck[1] скрыта до конца
    }
}

לאחר המימוש החפיסה מעורבבת וקבועה. מהלכים הבאים (hit) שולפים קלפים מהחפיסה שנוצרה כבר — ללא בקשות VRF חדשות. מהיר וזול.

למה אי אפשר לאחסן את החפיסה בגלוי?

אבל כל החפיסה מאוחסנת ב-contract Blackjack is VRFConsumerBaseV2Plus { struct Game { address player; uint256 bet; uint8[] deck; // все 52 карты в зашифрованном порядке uint8 playerIdx; // текущий индекс в деке uint8 dealerIdx; bool active; } mapping(uint256 => Game) public games; // requestId -> game mapping(address => uint256) public playerGame; // player -> gameId function startGame() external payable { require(msg.value >= MIN_BET, "Below minimum bet"); uint256 requestId = s_vrfCoordinator.requestRandomWords( VRFV2PlusClient.RandomWordsRequest({ keyHash: KEY_HASH, subId: subscriptionId, requestConfirmations: 3, callbackGasLimit: 300000, numWords: 1, // одно большое число для shuffle extraArgs: VRFV2PlusClient._argsToBytes( VRFV2PlusClient.ExtraArgsV1({nativePayment: false}) ) }) ); games[requestId] = Game({ player: msg.sender, bet: msg.value, deck: new uint8[](0), playerIdx: 0, dealerIdx: 4, // дилер берёт карты с позиции 4 active: false // станет true после fulfillment }); playerGame[msg.sender] = requestId; } function fulfillRandomWords(uint256 requestId, uint256[] calldata randomWords) internal override { Game storage game = games[requestId]; // Fisher-Yates shuffle детерминированный из одного seed uint8[52] memory deck; for (uint8 i = 0; i < 52; i++) deck[i] = i; uint256 seed = randomWords[0]; for (uint8 i = 51; i > 0; i--) { seed = uint256(keccak256(abi.encodePacked(seed))); uint8 j = uint8(seed % (i + 1)); (deck[i], deck[j]) = (deck[j], deck[i]); } // Первые 4 карты сразу сдаются: player, dealer, player, dealer game.deck = new uint8[](52); for (uint8 i = 0; i < 52; i++) game.deck[i] = deck[i]; game.active = true; emit GameStarted(requestId, game.player, deck[0], deck[2]); // видимые карты игрока // deck[1] и deck[3] - карты дилера, deck[1] скрыта до конца } } — בפומבי! טכנית, השחקן יכול לקרוא את כל הקלפים העתידיים מהאחסון.

פתרון: אחסן רק את ה-seed, חשב קלפים דטרמיניסטית רק כשהם "נחשפים":

// Не храним deck, только seed
    mapping(uint256 => uint256) private gameSeeds;

    function getCard(uint256 gameId, uint8 position) private view returns (uint8) {
        // Детерминированно вычисляем карту из seed и позиции
        // Карта не в storage — нельзя прочитать заранее
        return uint8(uint256(keccak256(abi.encodePacked(gameSeeds[gameId], position))) % 52);
    }

זה לא פותר את הבעיה לחלוטין: טכנית, אפשר לדמות את game.deck עבור כל המיקומים באותו בלוק. פתרון מלא הוא פרוטוקול Mental Poker עם הצפנה של כל קלף, אבל זה משמעותית יותר מורכב.

כיצד ליישם לוגיקת בלאק ג'ק בחוזה חכם?

ערכי קלפים: Ace = 1 או 11, קלפי פנים = 10, אחרים לפי דרגה:

function cardValue(uint8 card) internal pure returns (uint8) {
    uint8 rank = card % 13; // 0-12: туз, 2-10, валет, дама, король
    if (rank == 0) return 11; // туз (мягкое значение)
    if (rank >= 10) return 10; // картинки
    return rank + 1;
}

function handScore(uint8[] memory cards) internal pure returns (uint8) {
    uint8 score = 0;
    uint8 aces = 0;
    for (uint i = 0; i < cards.length; i++) {
        uint8 val = cardValue(cards[i]);
        if (val == 11) aces++;
        score += val;
    }
    // Мягкий туз становится жёстким (1) если bust
    while (score > 21 && aces > 0) {
        score -= 10;
        aces--;
    }
    return score;
}

לוגיקת דילר על השרשרת: הדילר שולף קלפים כל עוד הניקוד < 17, עוצר ב-17+ (כולל soft 17 בהתאם לחוקים).

כיצד לנהל bankroll באמצעות קריטריון קלי?

החוזה חייב להחזיק ETH לתשלומים. יתרון הבית בבלאק ג'ק הוא ~0.5% עם אסטרטגיה אופטימלית — זה המרווח האמיתי. אבל השונות גבוהה, ולכן יש צורך ב-bankroll מספק.

קריטריון קלי להימור מקסימלי: עם יתרון // Не храним deck, только seed mapping(uint256 => uint256) private gameSeeds; function getCard(uint256 gameId, uint8 position) private view returns (uint8) { // Детерминированно вычисляем карту из seed и позиции // Карта не в storage — нельзя прочитать заранее return uint8(uint256(keccak256(abi.encodePacked(gameSeeds[gameId], position))) % 52); } ו-bankroll getCard, הימור מקסימלי ≈ function cardValue(uint8 card) internal pure returns (uint8) { uint8 rank = card % 13; // 0-12: туз, 2-10, валет, дама, король if (rank == 0) return 11; // туз (мягкое значение) if (rank >= 10) return 10; // картинки return rank + 1; } function handScore(uint8[] memory cards) internal pure returns (uint8) { uint8 score = 0; uint8 aces = 0; for (uint i = 0; i < cards.length; i++) { uint8 val = cardValue(cards[i]); if (val == 11) aces++; score += val; } // Мягкий туз становится жёстким (1) если bust while (score > 21 && aces > 0) { score -= 10; aces--; } return score; } . עבור בלאק ג'ק עם יתרון 0.5% ושונות ~1.3 — הימור מקסימלי ≈ 0.38% מה-bankroll. בפועל: הגבל הימור מקסימלי ל-1-2% מה-bankroll.

uint256 public constant MAX_BET_PERCENT = 200; // 2% = 200/10000

function maxBet() public view returns (uint256) {
    return address(this).balance * MAX_BET_PERCENT / 10000;
}

modifier validBet() {
    require(msg.value >= MIN_BET && msg.value <= maxBet(), "Invalid bet");
    _;
}

למה UX קריטי עבור בלאק ג'ק על השרשרת?

בלאק ג'ק על הבלוקצ'יין דורש UX זהיר עבור אסינכרוניות. מימוש VRF אינו מיידי. השחקן לוחץ על "Deal" — ממתין 1-3 בלוקים שהקלפים יופיעו.

זרימה בממשק המשתמש:

1. Stake → e → סטטוס "Dealing..." (המתן לאירוע B)
2. קלפים מופיעים → השחקן רואה את 2 הקלפים שלו, קלף דילר אחד
3. Hit/Stand → מיידי, מהחפיסה המעורבבת
4. Stand → הדילר חושף קלפים → תוצאה → תשלום

לבדיקת אירועים: B * e / variance עם uint256 public constant MAX_BET_PERCENT = 200; // 2% = 200/10000 function maxBet() public view returns (uint256) { return address(this).balance * MAX_BET_PERCENT / 10000; } modifier validBet() { require(msg.value >= MIN_BET && msg.value <= maxBet(), "Invalid bet"); _; } או חיבור WebSocket לצומת.

מחסנית טכנולוגית

ביקורת חוזה: אבטחה קריטית

החוזה מחזיק ETH ומשלם זכיות — שגיאות בלוגיקת התשלום או ביצירת אקראיות מובילות להפסדים ישירים. אנו משתמשים ב-Slither ו-Mythril לניתוח סטטי, וגם ממליצים על ביקורת חיצונית על ידי שותפים. האבטחה שלכם היא הערובה שלנו. למדו עוד על ביקורת חוזה חכם ב-תיעוד Chainlink.

מה כלול בפיתוח בלאק ג'ק על השרשרת?

• תיעוד ארכיטקטוני ובחירת פרוטוקול (VRF לעומת Mental Poker)
• חוזה חכם בלאק ג'ק עם לוגיקת משחק וניהול bankroll
• בדיקות עם Foundry (יחידה, fuzz, אינטגרציה)
• אינטגרציית Chainlink VRF (v2.5) עם מנוי
• פרונטאנד על React + wagmi + viem עם תמיכה בארנקים (MetaMask, WalletConnect)
• פריסה ל-testnet ו-mainnet (Polygon/Arbitrum לפי בחירתכם)
• סקירת קוד ותיקון באגים
• הדרכת הצוות שלכם על תפעול החוזה
• תמיכה טכנית במהלך ההשקה

השוואה: VRF לעומת Mental Poker

לוחות זמנים משוערים

בלאק ג'ק עובד על השרשרת (חוזה חכם, בדיקות, פרונטאנד בסיסי): מ-4 עד 5 שבועות. עם ממשק משתמש מלא, אנימציות, סטטיסטיקות והתאמה למובייל: מ-8 עד 10 שבועות. העלות מחושבת באופן אישי לאחר ניתוח דרישות. הזמינו פיתוח — נכין תוכנית מפורטת. צרו קשר כדי לדון בפרויקט שלכם.