Cos'è Provably Fair e come verificare l'onestà del gioco

Cos'è Provably Fair (FCA)

Provably Fair è un protocollo che consente di verificare crittograficamente che il risultato del round è stato casuale e non può essere sostituito dall'operatore dopo la puntata.

Idea: prima viene pubblicato il commit (hash server nascosto seed), poi dopo la puntata viene svelato (server seed) e chiunque può incrociare l'hash e riprodurre RNG, considerando client seed del giocatore e gli ID del round.

Protocollo base: commit bet reveal

1. Commit: prima dell'inizio dei round, il server genera un server _ seed casuale e ne pubblica l'hash:


commit = SHA-256(server_seed         salt )//o Keccak-256

Il commit può essere inserito nella cronologia/blockchain/registro.

2. Puntata: il giocatore sceglie o conferma il suò client _ seed "(da UI o proprio), invia la puntata da:


client_seed, roundId, nonce

3. Reveal: dopo la chiusura delle scommesse, il server svela «server _ seed» (e «salt», se c'era) in modo che tutti possano verificare:


SHA-256(server_seed         salt) = = commit//controllo integrità

4. RNG: numero di casualità determinata e riprodotta:


rng = HMAC-SHA256(key=server_seed, msg=client_seed          roundId          nonce)
//o rng = SHA-256 (server _ seed         client_seed          roundId          nonce)

5. Mapping a risultato: convertiamo'rng'in un intervallo di gioco senza offset (vedi qui sotto).

💡 Perché nonce? In modo che con un solo server _ seed si possano fare molti round senza rischi di prevedibilità: 'nonce', ogni round/puntata viene incrementato.

Per ottenere un numero senza offset (bias-free)

Non è corretto prendere «rng% N», che dà uno spostamento modulare se 2 ^ k non è multiplo N. Corretto - rejection sampling:

pseudo
//rng _ byties = 32 byte hash → uint256 x = uint256 (rng _ byties)

limit = floor(2^256 / N) N while x >= limit:
rng _ byties = SHA-256//« miscelare »di nuovo x = uint256 (rng _ byties)

result = x % N

In questo modo si ottiene una distribuzione uniforme degli esiti N (celle della roulette, simboli del tamburo, ecc.).

Mini-esempio (verifica passo passo del giocatore)

Supponiamo:


server _ seed = «b2c6... e9 »/aperto dopo il round (hex/utf8)
client _ seed = «my-client-seed »//scelto da me =« R-2025-10-17-001 »
nonce = 42 commit = «c9a1... f3 »//opble. in anticipo

1) Controlla commit

Calcola SHA-256 (server _ seed) e assicurati che corrisponda a commit.

2) RNG determinata

Calcola:


rng = HMAC-SHA256(key=server_seed,          msg= client_seed          ":"          roundId          ":"          nonce)

3) Conversione in esito

Per la roulette (37 numeri) → N = 37, applicare il rejection sampling e prendere «x% 37».

Per lo slot, utilizzare più porzioni RNG per definire rulli/simboli in base alla tabella di distribuzione.

4) Incrocia il risultato nella storia

Il sito deve mostrare gli stessi input usati nel calcolo: server _ seed, client _ seed, roundId, nonce, hashAlgo, rngAlgo, mappingVersion.

Alternativa/rafforzamento: VRF (Verifiable Random Function)

Al posto del commit, l'operatore può (o opzionale) utilizzare VRF:

1. Un contratto smart o un registro pubblico richiede al provider «VRF (seed)».

2. Viene pubblicato «(random, proof)».

3. Chiunque può controllare «proof» con la stessa coppia chiave pubblica VRF.

4. Poi, gli stessi passi del mapping RNG verso l'esito.

Meno fiducia nell'operatore. Contro - Dipendenza dal provider/catena VRF e il costo possibile.

Come il casinò deve implementare l'FBI correttamente

Contratto (Contratto Dati FCA)

Campi nella cronologia del round:

`serverSeedHash`, `serverSeedReveal`, `clientSeed`, `roundId`, `nonce`, `hashAlgo`, `rngAlgo`, `mappingVer`, `proofUrl` (опц.) , `calcVer`.
I valori sono in un archivio WORM (immutable), con timbri UTC (UTC).

Generazione di sedili

'server _ seed'è generato da PRNG crittografico (OS CSPRNG/HSM).

I sedili non devono mai ripetersi tra le serie (rotazione).

«client _ seed» è selezionato dal giocatore o generato sul client e viene confermato.

Pubblicazione di commit

I commit sono disponibili prima delle scommesse (storia, RSS, on-chain-ancor).

Per i lotti è possibile utilizzare l'albero merckley dei commiti con la pubblicazione giornaliera della radice.

Espansione (reveal)

Prima di pubblicare il risultato, «server _ seed» viene visualizzato e copiato.

Per una serie di round su un solo sedile - rivelazione dopo la fine della serie (indicare la politica in anticipo).

Mupping trasparente

La versione dell'algoritmo di mapping ('mappingVer') viene registrata.

Qualsiasi modifica («mappingVer »/« rngAlgo») è solo con un annuncio e una nuova serie di commiti.

Controllo e controversie

Gli ingressi crudi e la registrazione dei calcoli vengono salvati. durante la discussione viene generato un rapporto: gli ingressi RNG mapping sono risultati.

Striam/Live - Memorizzare le ancelle hash degli eventi CV/RFID, video in WORM.

Come controllare l'onestà del giocatore (assegno-foglio)

1. Aprite la storia del round e copiate « », « », « », «nonce», « », « ».

2. Contate «serverSeedReveal» e paragonate «serverSeedHash».

3. Calcola RNG in base all'algoritmo specificato (HMAC/Hash + ingressi).

4. Applicate il mapping «senza scrittura» (rejection sampling) al numero di esiti.

5. Verificare che il risultato corrisponda a quello visualizzato.

6. Se è stato dichiarato VRF, verificare proof (pulsante Verify o script/blocco-esploratore indipendente).

Errori tipici (anti-pattern)

'rng% N'senza rejection sampling, le probabilità offuscate.

«client _ seed» nascosto o modificato (generato dal server senza la presenza del giocatore).

Sovrapposizione dì server _ seed "dopo la puntata (il commit cambia a posteriori).

Modifiche opache agli algoritmi senza versione/pubblicazione.

Ripetizione dei sedili tra le serie.

Nessun timbro WORM - Impossibile provare l'ordine degli eventi.

Miscelare la logica aziendale (ad esempio, il bonus è applicato in modo da cambiare lo spazio degli esiti, ma non è descritto in «mappingVer»).

FAQ (breve)

Possiamo controllare le slot, non solo la roulette?

Sì, sì. I FP vengono applicati alla sequenza di selezione (ad esempio, l'indice del simbolo sul rullo). È importante che le tabelle delle probabilità e l'ordine di lettura di RNG siano documentati.

E se ho inserito il mio client _ seed, l'operatore può comunque "scegliere" server _ seed "?

Non se è stato pubblicato prima della puntata. Registra server _ seed e non permette di sostituirlo a posteriori.

Perché a volte si aprono i sedili a pacco?

Così non potrò più usare la serie. È accettabile se il commit viene pubblicato in anticipo e la politica di divulgazione è trasparente.

Formati minigiornali

Hash: SHA-256 o Keccak-256.

RNG: HMAC-SHA256 (side server come chiave) o SHA-256 concatenazione.

Identificatori: «roundId» (timbro UTC + gioco + ingrandimento), «nonce» (contatore scommesse nella serie).

Версии: `rngAlgo=HMAC-SHA256@1`, `mappingVer=roulette. v2`, `calcVer=wallet-7. 2`.

Foglio di assegno per l'implementazione del FP per l'operatore

Crittografia e sidi

CSPRNG/HSM; unici'server _ seed ', rotazione documentata.
'client _ seed' - gestito da un giocatore, viene salvato nella storia.

Pubblicazioni e conservazioni

Commit prima delle scommesse, accesso alla cronologia/canale di pubblicazione/ancoraggio.
Lo storage WORM, i timbri UTC, il merckley-batch per la scala.

Algoritmi

RNG e mapping senza offset; versione' rngAlgo/mappingVer '.
Script/pagina Verifica onestà (open-source).

Live e ibrido

Adesioni hash CV/RFID/fase del round, registro quando la finestra delle scommesse è stata chiusa.
Procedure di contenzioso (rapporto vkhodov→iskhod, link a committenti/VRF).

Sicurezza e controllo

Ispezione indipendente del protocollo dell'FBI, bug bounty.
I loghi decisionali sono invariati; test di riproduzione regolari.

Provably Fair trasforma «credeteci» in «controllate voi». Con un commit/revisile o VRF, un RNG determinato e un mapping corretto senza offset, qualsiasi round diventa riproduttivo e verificabile. Per un giocatore è trasparenza e fiducia. Per l'operatore, meno controversie, più forte marchio e conformità ai regolatori. La disciplina principale è pubblicare i committenti in anticipo, fissare le versioni degli algoritmi, conservare le prove in modo permanente e dare all'utente uno strumento di verifica semplice.