Ultimo aggiornamento il 27 ottobre 2025 da Cesare Fikson
Uno strumento di verifica dimostrabilmente equo è adatto agli utenti che possono immettere il seed del server e il seed del client di un gioco per verificare l'equità dello shuffle; ciò attrae i giocatori di cripto-casinò e rafforza l'autorevolezza nel gioco blockchain.
Strumento gratuito di verifica dell'equità dimostrabile
Verifica dimostrabilmente corretta (HMAC-SHA256):
Verificare i semi, riprodurre i risultati, dimostrare l'integrità
Questa pagina consente ai giocatori, ai revisori e ai team di conformità verificare giochi dimostrabilmente equi controllando il commit del seed del server (SHA-256), combinandolo con il seme del cliente and noncee ricalcolare il risultatoNessuna scatola nera, nessuna vibrazione, solo HMAC-SHA256 deterministico e riproducibile RNG.
Cosa significa realmente “dimostrabilmente equo”
- Commit del seed del server (pre-partita): l'operatore pubblica l'hash SHA-256 di un seed del server segreto.
- Giocare: il risultato è derivato da HMAC-SHA256(server_seed, pattern(client_seed, nonce)).
- Rivelazione (post-partita): l'operatore rivela il seed del server; il il commit deve corrispondere.
- Convalida: chiunque può riprodurre risultati con gli stessi input. Se non corrispondono, non è giusto.
Tags: casinò dimostrabile equo, Commit HMAC-SHA256, rivelazione del seed del server, seme del cliente, nonce, RNG deterministico, strumento di verifica dell'equità.
Giochi supportati e intervalli di output
| Gioco | Fonte di casualità | Campo di uscita | Note |
|---|---|---|---|
| Dadi | Interi imparziali dal flusso HMAC | 0–99 o 0–99.99 | Precisione selezionabile. |
| Roulette (UE) | Mod int imparziale 37 | 0-36 | Ruota a zero singolo. |
| Roulette (Stati Uniti) | Mod int imparziale 38 | 0–36 + 00 | 37 mappe a “00”. |
| Crash (generico) | Primi 52 bit → r; mult=(1−edge)/(1−r) | ≥ 1.00× | Bordo e decimali configurabili. |
| Mescolamento delle carte | Fisher-Yates deterministico | permutazione di 52 carte | Emetti le prime N carte. |
Come verificare (passo dopo passo)
- Incolla seed del server (rivelato) e hash di commit fornito prima del gioco.
- Incolla seme del cliente and nonce iniziale; scegliere conteggio dei round.
- Scegli il giocoRegolare la precisione/il bordo se necessario.
- Clicchi Verifica e genera.
- Confronta i risultati dello strumento con il registro di gioco dell'operatore. Il commit deve corrispondere and le uscite rotonde devono essere allineate di preciso.
Perché l'impegno è importante
Senza un hash pre-commesso, l'operatore potrebbe scambiare i seed del server post-factum per adattarli a risultati favorevoli. Un SHA-256 commettere → rivelare garanzie impegno preventivo: il seme rivelato esegue l'hash del commit originale (onesto) oppure no (catturato).
Modello di sicurezza: cosa è garantito (e cosa no)
- Garantito: Nessuna manomissione post-partita se il commit corrisponde e i risultati vengono ricalcolati bit per bit.
- Non garantito: politiche di pagamento, RTP, regole di arrotondamento, integrazioni di terze parti o salt off-chain non pubblicati da un operatore. Verificare sempre modello esatto del messaggio (per esempio,
{client}:{nonce}) e qualsiasi sali i documenti dell'operatore.
Insidie comuni
- Wrong modello di messaggio (ordine dei token, separatori).
- Usando il nonce sbagliato (basato su 0 vs basato su 1).
- Confronto errato tra roulette UE e USA (gestione 00).
- I decimali/edge di crash non corrispondono alle regole della casa.
- Confusione tra esadecimale e UTF-8 per i seed (gli operatori dovrebbero usare semi di testo, non blob esadecimali: questo strumento si aspetta stringhe UTF-8).
Vantaggi di conformità e fiducia
- Pista di controllo: Riproduci round storici per indagini KYC/RG.
- Soluzione della disputa: La prova crittografica è migliore degli screenshot.
- Risorsa degna di un link: Gli affiliati e i blog sulla conformità citano naturalmente verifica dimostrabilmente equa pagine con strumenti.
Lista di controllo per la risoluzione dei problemi
- Le normative
SHA256(server_seed)uguale al commit pubblicato? - E 'la tua seme del cliente identico (maiuscole/minuscole/spazi vuoti)?
- È il nonce lo stesso del registro di gioco?
- Se la modello di messaggio corrispondono alle specifiche dell'operatore?
- Per i round batch, i risultati si allineano round per round?
FAQ (per i rich snippet)
Cos'è un hash di commit dimostrabilmente equo?
A Hash SHA-256 del seed del server viene pubblicato prima della riproduzione. Dimostra che il seed esisteva e non poteva essere modificato in seguito senza rompere l'hash.
Quale hash/HMAC utilizza questo strumento?
SHA-256 per i commit e HMAC-SHA256 (seed del server come chiave) per la casualità per round, un approccio standard del settore.
Posso verificare i moltiplicatori di crash?
Sì. Lo strumento deriva r dai primi 52 bit dell'output HMAC e calcola mult = (1 − edge) / (1 − r). Configura bordo della casa and decimali per abbinare l'operatore.
Cosa succede se un operatore utilizza un formato diverso?
Utilizzare "Avanzate" per impostare modello di messaggio (per esempio, {client}|{nonce}) e includere eventuali sali extra documentati dall'operatore.
Questo dimostra l'RTP?
No. Lo dimostra integrità del risultato, non la matematica dei pagamenti. L'RTP è statistico e dipende dalla politica.
