♠️
RACE Protocol
NFT PresaleDiscord
  • ❤️Official Docs & Links
  • ⏳Progress Overview
  • RACE Protocol
    • 🏗️System Architecture
      • Components
      • On-chain Accounts
      • Synchronization
      • Randomization
      • Payment
    • 🎲Game Development
      • Game Handler
      • Effect
      • Event Handling
      • Race API
        • Arweave Integration
      • Race JS SDK
        • Installation and Setup
        • Key Components
          • AppClient
          • SubClient
          • Events
          • Game Context
          • Decryption Cache
        • Advanced Features
          • Getting Revealed Knowledge
          • Exiting and Detaching
          • Submitting Messages
          • Sub-game Interaction
        • Best Practices
        • API Reference
        • Troubleshooting
    • 🧪Testing
      • Race Test Kit
      • Unit Testing
      • Integration Testing
      • Additional Considerations
    • 🧱Modules & Features
      • Encryption Methods
      • Command-line Tools
      • Configuration Options
      • Blockchain Transport Implementations
    • 📃Smart Contract
      • Solana Program
    • 🔦Examples and Use Cases
      • Draw Card Game
      • Raffle Game
      • Other Examples
  • RACE Games
    • ♠️RACE Poker app
      • 🎮Start playing in minutes
        • 💰Cash and sit-n-go
        • 🏆Tournaments
      • 🎨Workshop
        • 🏆Create cash games
        • 🏨Create tourneys
      • 💡Concept introduction
      • 🏗️System architecture
      • 👾Game Flow
      • 🎲Cards shuffling
      • ☎️Communication
      • 🔐Key sharing/decryption
      • 💱Cash flow structure
    • ⚡Solfast
      • 🎲Game modes
  • RACE RESEARCH
    • 👾No-Code Development
      • Brainstorming
      • Implementation Approach
      • Project Status
    • 0️⃣Zero-Knowledge Proofs
      • Brainstorming
      • Integration steps
        • Verifiable Randomness Generation
        • Private Game State Updates
        • Verifiable Settlements
        • Private Player Actions
      • Project Status
    • 🛡️Security Audit Report
      • Executive summary
        • Introduction to Race Protocol
        • Audit Methodology
      • Findings
        • Smart Contract Security
        • WebAssembly Security
        • Client-side Security (Race SDK)
        • Server-side Security
        • Randomization and Encryption
        • On-chain Account Management
        • Synchronization Mechanisms
        • Payment Handling
      • Recommendations
      • Conclusion
  • RACE DAO
    • 😎About
    • 🫂Community
    • 🖼️NFT Collection [!]
Powered by GitBook
On this page
  • Mental Poker Algorithm
  • Ensuring Fairness
  1. RACE Protocol
  2. System Architecture

Randomization

Randomization is a crucial aspect of many games, particularly those involving hidden knowledge or chance elements. In Race Protocol, a variant of the mental poker algorithm is employed to generate randomness in a secure and verifiable manner. This ensures fairness and prevents manipulation, even in games with asymmetric information.

Mental Poker Algorithm

The mental poker algorithm allows multiple parties to shuffle and draw from a virtual deck of cards without revealing the order of the cards to each other. Race Protocol adapts this concept to generate randomness for various game elements, not just cards.

Here's a simplified overview of how the randomization process works in Race Protocol:

  1. Initialization: The Transactor initiates the process by creating a "deck" of possible outcomes (e.g., a list of cards or numbers). Each outcome is represented by a unique identifier.

  2. Masking: The Transactor and validator servers each generate a secret key and use it to encrypt the identifiers of the outcomes. This "masking" process ensures that the actual values remain hidden.

  3. Shuffling: The Transactor and validators engage in a series of coordinated steps to shuffle the encrypted identifiers. This shuffling process is designed to be verifiable, meaning that each participant can confirm that the shuffling was done correctly without revealing the secrets or the order of the outcomes.

  4. Assignment and Revealing: Once the shuffling is complete, the Transactor can assign specific outcomes to players or reveal them publicly. This is done by sharing the corresponding secret keys with the designated recipients or with everyone in the game.

  5. Decryption: Players and validators use the shared secrets to decrypt the assigned or revealed outcomes, allowing them to see the actual values.

Ensuring Fairness

The mental poker algorithm in Race Protocol ensures fairness in games with hidden knowledge by:

  • Preventing Manipulation: The use of secret keys and verifiable shuffling makes it difficult for any single entity, including the Transactor, to manipulate the outcome of the randomization process.

  • Verifiability: Each participant can independently verify that the shuffling was done correctly, ensuring the integrity of the randomness generation.

  • Hidden Knowledge: The encryption of outcome identifiers ensures that the actual values remain hidden until they are assigned or revealed, preventing players from gaining an unfair advantage by prematurely knowing the outcome.

By employing this secure and verifiable randomization process, Race Protocol guarantees fair play and builds trust among players, even in games where some information is hidden from certain participants.

This section has described the mental poker algorithm and its role in ensuring fair randomization within Race Protocol. The next section will discuss the specific roles and responsibilities of Transactor and validator servers in more detail.

PreviousSynchronizationNextPayment

Last updated 1 year ago

🏗️