Ce este Provably Fair și cum să testați integritatea jocului

Ce este Probably Fair (PF)

Dovedably Fair este un protocol care vă permite să verificați criptografic că rezultatul rundei a fost aleatoriu și nu a putut fi înlocuit de operator după pariu.

Ideea: mai întâi se publică un angajament (hash al seminței de server ascunse), apoi după pariu este dezvăluit un revil (însăși semința serverului) și oricine poate verifica hash-ul și reproduce RNG-ul, având în vedere semințele clientului și identificatorii rotunzi ai jucătorului.

Protocolul de bază: angajați → pariați → dezvăluiți

1. Comite: înainte de începerea rundelor, serverul generează un „server _ seed” aleatoriu și publică hash-ul:


commit = SHA-256 (server_seed        sare )//sau Keccak-256

Angajamentul poate fi afișat în istorie/blockchain/jurnal.

2. Pariu: jucătorul selectează sau confirmă 'client _ seed' (din UI sau propriu), trimite un pariu cu:


client_seed, roundId, nonce

3. Dezvăluie: după închiderea pariurilor, serverul dezvăluie „server _ seed” (și „sare” dacă a existat), astfel încât toată lumea să poată verifica:


SHA-256 (server_seed        sare) = = comite//verificare integritate

4. RNG: numărul aleatoriu este determinist și reproductibil:


rng = HMAC-SHA256 (key = server _ seed, msg = client _ seed        roundId        nonce)
//sau rng =  (          client_seed        roundId        nonce)

5. Maparea rezultatului: convertiți „rng” în intervalul jocului fără deplasare (vedeți mai jos).

💡 De ce nonce? Astfel, cu un singur „server _ seed” puteți cheltui mai multe runde fără riscul de predictibilitate: incremente „nonce” în fiecare rundă/pariu.

Cum să obțineți un număr fără prejudecăți

Este greșit să luați „rng% N” - acest lucru oferă un decalaj modular dacă 2 ^ k nu este un multiplu de N. Este corect - eșantionare de respingere:

pseudo
// rng_bytes = 32 bytes hash → uint256 x = uint256 (rng_bytes)

limită = etaj (2 ^ 256/N) N în timp ce x> = limită:
rng_bytes = SHA-256 (rng_bytes )//” mix„ din nou deterministic x = uint256 (rng_bytes)

rezultat = x% N

Deci, vom obține o distribuție uniformă peste rezultatele N (celule de ruletă, simboluri tambur, etc.).

Mini Exemplu (Verificare pas jucător)

Să presupunem:


server_seed = "b2c6... e9 "//dezvăluit după rundă (hex/utf8)
client_seed = „my-client-seed „//Am selectat roundId = ”R-2025-10-17-001„
nonce = 42 commit = "c9a1... f3 "//publ. în avans

1) Verificați angajamentul

Numără 'SHA-256 (server_seed)' şi asigură-te că se potriveşte cu 'comite'.

2) Deterministic RNG

Număr:


rng = HMAC-SHA256 (key = server _ seed, msg = client_seed         ":"         roundId         ":"         nonce)

3) Conversia la rezultat

Pentru ruletă (37 numere) → N = 37, se aplică eșantionarea de respingere și se ia „x% 37”.

Pentru un slot, folosește mai multe bucăți RNG pentru a defini role/simboluri în funcție de tabelul de alocare.

4) Verificați rezultatul în istorie

Site-ul ar trebui să afișeze aceleași intrări care au fost utilizate în calcul: 'server _ seed', 'client _ seed', 'roundId',' nonce ',' hashAlgo ',' rngAlgo ',' mappingVersion '.

Alternativă/câștig: VRF (funcție aleatorie verificabilă)

În loc de un angajament, operatorul poate (sau opțional) utiliza VRF:

1. Un contract inteligent sau un registru public solicită furnizorului „VRF (sămânță)”.

2. Publicat de '(aleatoriu, dovada)'.

3. Oricine poate verifica „dovada” de aceeași pereche de chei VRF publice.

4. Apoi, aceiași pași de cartografiere RNG în rezultat.

Pro: Mai puțină încredere în operator. Dezavantaje: dependența de furnizorul/lanțul VRF și costul posibil.

Cum un cazinou ar trebui să implementeze corect PF

Contract (contract de date PF)

Marje în istoria rotundă:

'serverSeedHash', 'serverSeedReveal', 'clientSeed', 'roundId',' nonce ',' hashAlgo ',' rngAlgo ',' mappingVer ',' proofUrl' (опц.) „CalcVer”.
Valori - în depozitarea WORM (imuabilă), cu timbre de timp (UTC).

Generarea semințelor

'server _ seed' este generat de criptografic PRNG (OS CSPRNG/HSM).

Sids nu trebuie repetate între serii (rotație).

'client _ seed' - selectat de jucător sau generat pe client și confirmat.

Angajamente de publicare

Angajamentele sunt disponibile înainte de pariuri (istoric, RSS, on-chain-ancoră).

Pentru o mulțime, puteți utiliza arborele merkley comite cu rădăcina publicată zilnic.

Dezvăluie

Înainte de a publica rezultatul, „server _ seed” este extins și logat.

Pentru o serie de runde pe un singur scaun - dezvăluirea după sfârșitul seriei (indicați politica în avans).

Cartografiere transparentă

Versiunea algoritmului de cartografiere ('mappingVer') este fixă.

Orice modificare ('mappingVer '/' rngAlgo') - numai cu un anunț și o nouă serie de comisioane.

Audit și litigii

Intrări brute + înregistrări de calcul salvate; atunci când se argumentează, se generează un raport: intrările → RNG → cartografierea rezultatului →.

Fluxuri/Live: magazin CV/RFID eveniment hash ancore, video în WORM.

Cum poate un jucător să verifice onestitatea (lista de verificare)

1. Deschideți istoricul rundei și copiați: 'serverSeedReveal', 'clientSeed', 'roundId',' nonce ',' hashAlgo ',' rngAlgo ',' mappingVer '.

2. Numărați hash 'serverSeedReveal' și comparați cu 'serverSeedHash'.

3. Calculați RNG în funcție de algoritmul specificat (intrări HMAC/Hash +).

4. Aplicați cartografierea „imparțială” (eșantionare de respingere) la numărul de rezultate.

5. Asigurați-vă că rezultatul este același cu cel arătat.

6. Dacă VRF este declarat, verificați „dovada” („Verifică” buton sau independent script/bloc explorer).

Erori tipice (anti-modele)

'rng% N' fără eșantionarea respingerii → probabilități părtinitoare.

Ascuns sau schimbat 'client _ seed' (generat de server fără participarea jucătorului).

Re-generarea 'server _ seed' după pariu (comite modificări retroactive).

Algoritmul opac se modifică fără versiune/publicare.

Reluarea laturilor între serii.

Lipsa ștampilelor WORM/timp - ordinea evenimentelor nu poate fi dovedită.

Amestecarea PF și logica de afaceri (de exemplu, bonusul este aplicat astfel încât să schimbe spațiul rezultat, dar acest lucru nu este descris în „mappingVer”).

Întrebări frecvente (scurt)

Este posibil pentru a verifica sloturi, nu doar ruleta?

Da, am făcut-o. PF se aplică secvenței de selecție (de exemplu, indicele simbolului de pe role). Este important ca tabelele de probabilitate RNG și ordinea de citire să fie documentate.

Și dacă am intrat meu 'client _ seed', operatorul poate încă „ridica” 'server _ seed'?

Nu și dacă angajamentul a fost postat înainte de ofertă. Acesta stabilește "server _ seed 'și nu permite înlocuirea retroactivă a acestuia.

De ce dezvăluie uneori laturi în loturi?

Astfel încât nu a fost posibil să se „sorteze” sămânța din serie. Acest lucru este acceptabil dacă angajamentul este publicat în prealabil, iar politica de informare este transparentă.

Mini-formate de referință

Hash-uri: SHA-256 sau Keccak-256.

RNG: HMAC-SHA256 sau SHA-256 de concatenare.

Identificatori: 'roundId' (UTC-stamp + game + increment),' nonce '(contorul de pariuri din serie).

Версии: 'rngAlgo = HMAC-SHA256 @ 1', 'mappingVer = ruletă. v2 ',' calcVer = portofel-7. 2`.

Lista de verificare a implementării operatorului PF

Criptografie și Sids

CSPRNG/HSM; unic 'server _ seed', rotație documentată.
'client _ seed' - controlat de jucător, salvat în istorie.

Publicații și depozitare

Se angajează la pariuri, acces la istorie/canal de publicare/ancoră.
Depozitare WORM, ștampile UTC, loturi Merkley pentru cântare.

Algoritmi

RNG și cartografiere fără părtinire; versioning 'rngAlgo/mappingVer'.
Script/pagină „Verificați onestitatea” (open-source este de dorit).

Live și hibrid

CV/RFID/ancore hash faza rotundă, jurnal „când fereastra de pariere a fost închisă”.
Proceduri de dispută (raport vkhodov→iskhod, link-uri către angajamente/VRF).

Securitate și audit

Audit independent al protocolului PF, recompensă pentru erori.
Jurnalele decizionale sunt imuabile; teste regulate de reluare.

Dovedably Fair transformă "încredere în noi" în "verifică-l singur. "Cu comite/revil sau VRF, deterministic RNG, și corecta cartografiere non-offset, orice rundă devine reproductibilă și verificabilă. Pentru un jucător, este transparență și încredere. Pentru operator - mai puține controverse, o marcă mai puternică și respectarea cerințelor de reglementare. Principalul lucru este disciplina: publica comite în avans, fixa versiuni de algoritmi, stoca dovezi invariabil și să dea utilizatorului un instrument simplu de verificare.