Co jest Provably Fair i jak sprawdzić integralność gry

Co jest rzetelnie (PF)

Provably Fair to protokół, który pozwala na kryptograficzne sprawdzenie, czy wynik rundy był losowy i nie mógł zostać zastąpiony przez operatora po zakładzie.

Pomysł: najpierw publikowane jest zatwierdzenie (hash ukrytego ziarna serwera), następnie po ujawnieniu zakładu (samo ziarno serwera), a każdy może sprawdzić hash i odtworzyć RNG, biorąc pod uwagę ziarno i okrągłe identyfikatory klienta gracza.

Protokół bazowy: commit → bet → reveal

1. Commit: przed rozpoczęciem rund serwer generuje losowe 'server _ seed' i publikuje hash:


commit = SHA-256 (server_seed        sól )/lub Keccak-256

Commit może być wyświetlany w historii/blockchain/journal.

2. Zakład: gracz wybiera lub potwierdza swoje 'client _ seed' (z interfejsu użytkownika lub własnego), wysyła zakład zawierający:


client_seed, roundId, nonce

3. Ujawnij: po zamknięciu zakładów serwer ujawnia 'server _ seed' (i 'salt' if był), aby każdy mógł sprawdzić:


SHA-256 (server_seed        sól) = = kontrola popełnienia//integralności

4. RNG: liczba losowości jest deterministyczna i odtwarzalna:


rng = HMAC-SHA256 (key = server _ seed, msg = client _ seed        rundId        nonce)
//lub rng = SHA-256 (server_seed        client_seed        rundId        nonce)

5. Odwzorowanie do wyniku: konwersja 'rng' do zakresu gry bez przesunięcia (patrz poniżej).

💡 Dlaczego nonce? Tak, że z jednym 'server _ seed' można spędzić wiele rund bez ryzyka przewidywalności: 'nonce' przyrosty każdej rundy/zakładu.

Jak uzyskać numer bez uprzedzeń

Źle jest wziąć 'rng% N' - to daje przesunięcie modułowe, jeśli 2 ^ k nie jest wielokrotnością N. To prawda - próba odrzucenia:

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

limit = podłoga (2 ^ 256/N) N, natomiast x> = granica:
rng_bytes = SHA-256 (rng_bytes )//” mix„ ponownie deterministycznie x = uint256 (rng_bytes)

wynik = x% N

Mamy więc równomierny rozkład na wyniki N (komórki ruletki, symbole bębna itp.).

Mini przykład (weryfikacja kroków gracza)

Przypuśćmy:


server_seed = "b2c6... e9 "//ujawnione po rundzie (hex/utf8)
client_seed = „my-client-seed „//I selected roundId = ”R-2025-10-17-001„
nonce = 42 commit = "c9a1... f3 "/publ. z wyprzedzeniem

1) Zatwierdzenie czeku

Policz 'SHA-256 (server_seed)' i upewnij się, że pasuje do 'commit'.

2) RNG deterministyczny

Liczba:


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

3) Konwersja na wynik

W przypadku ruletki (37 numerów) → N = 37 należy zastosować próbki odrzucenia i pobrać 'x% 37'.

Dla gniazda użyj wielu kawałków RNG do zdefiniowania bębnów/symboli zgodnie z tabelą alokacji.

4) Sprawdź wynik w historii

Witryna powinna pokazywać te same dane wejściowe, które zostały użyte w obliczeniach: 'server _ seed', 'client _ seed', 'roundId',' nonce ',' hashAlgo ',' rьAlgo ',' mappingVersion '.

Alternatywa/zyski: VRF (weryfikowalna funkcja losowa)

Zamiast zobowiązania operator może (lub opcjonalnie) używać VRF:

1. Inteligentny kontrakt lub rejestr publiczny zwraca się do dostawcy o'VRF (materiał siewny) '.

2. Opublikowany przez „(losowy, dowód)”.

3. Każdy może sprawdzić 'zabezpieczenie' przez tę samą publiczną parę kluczy VRF.

4. Następnie, te same kroki mapowania RNG do wyniku.

Plusy: Mniejsze zaufanie do operatora. Wady: zależność od dostawcy/łańcucha VRF i możliwe koszty.

Jak kasyno powinno prawidłowo wdrożyć PF

Umowa (umowa o dane PF)

Marginesy w historii okrągłej:

'serverاHash', 'server, Reveal', 'clientSeed', 'roundId',' nonce ',' hashAlgo ',' rě Algo ',' mappingVer ',' Url' (оВ,.) „calcVer”.
Wartości - w magazynie WORM (niezmiennym), ze znaczkami czasu (UTC).

Wytwarzanie nasion

„server _ seed” jest wytwarzany przez kryptograficzny PRNG (OS CSPRNG/HSM).

Sidy nigdy nie powinny być powtarzane pomiędzy seriami (obrót).

„client _ seed” - wybrany przez gracza lub wygenerowany na kliencie i potwierdzony.

Zobowiązania wydawnicze

Commits są dostępne przed zakładami (historia, RSS, on-chain-kotwica).

Dla wielu, można użyć drzewa commit merkley z korzeniem opublikowanym codziennie.

Ujawnienie

Przed opublikowaniem wyniku 'server _ seed' jest rozszerzany i rejestrowany.

Dla serii rund na jednym miejscu - ujawnienie po zakończeniu serii (wskazać politykę z wyprzedzeniem).

Przejrzyste odwzorowanie

Wersja algorytmu mapowania ('mappingVer') jest naprawiona.

Każda zmiana ('mappingVer '/' rЧАЛА') - tylko z ogłoszeniem i nową serią zatwierdzeń.

Audyt i spory

Zapisane dane wejściowe surowe + rekord obliczeniowy; podczas kłótni generowany jest raport: wejścia → RNG → mapowanie → wynik.

Strumienie/Live: sklep CV/RFID event kotwice hash, wideo w WORM.

Jak gracz może sprawdzić uczciwość (lista kontrolna)

1. Otwórz historię rundy i skopiuj: 'Serwer', 'KlientSeed', 'RoundId',' nonce ',' hashAlgo ',' rьAlgo ',' mappingVer '.

2. Policz hash 'serverW' i porównaj z 'serverZ'.

3. Obliczyć RNG zgodnie z określonym algorytmem (wejścia HMAC/Hash +).

4. Użyj „bezstronnego” odwzorowania (próbkowania odrzucenia) do liczby wyników.

5. Upewnij się, że wynik jest taki sam jak pokazano.

6. Jeśli VRF jest zadeklarowane, należy sprawdzić 'default' (przycisk 'Verify' lub niezależny skrypt/block explorer).

Typowe błędy (anty-wzory)

'rng% N' without próba odrzucenia → stronnicze prawdopodobieństwo.

Ukryte lub zmieniające 'client _ seed' (generowane przez serwer bez udziału gracza).

Ponowne wytworzenie 'server _ seed' po zakładzie (popełnić zmiany z mocą wsteczną).

Nieprzezroczyste zmiany algorytmu bez wersji/publikacji.

Powtórka boków między seriami.

Brak znaczników WORM/czasu - kolejności zdarzeń nie można udowodnić.

Mieszanie logiki PF i biznesowej (na przykład premia jest stosowana w taki sposób, że zmienia przestrzeń wyniku, ale nie jest to opisane w 'mappingVer').

Najczęściej zadawane pytania (krótkie)

Czy można sprawdzić szczeliny, a nie tylko ruletkę?

Tak, zrobiłem to. PF stosuje się do sekwencji wyboru (np. indeks symbolu na bębnie). Ważne jest, aby udokumentowano tabele prawdopodobieństwa RNG i kolejność odczytu.

A jeśli wprowadzę 'client _ seed', operator nadal może 'odebrać' '' server _ seed '?

Nie, jeśli commit został opublikowany przed ofertą. Naprawia 'server _ seed' i nie pozwala na jego wymianę z mocą wsteczną.

Dlaczego czasami ujawniają strony w partiach?

Tak, że nie było możliwe „uporządkowanie” nasienia z serii. Jest to dopuszczalne, jeśli zobowiązanie zostanie opublikowane z wyprzedzeniem, a polityka ujawniania informacji będzie przejrzysta.

Formaty mini-referencyjne

Hashes: SHA-256 lub Keccak-256.

RNG: HMAC-SHA256 lub SHA-256 konkatenacji.

Identyfikatory: 'roundId' (UTC-stamp + gra + przyrost),' nonce '(licznik stawek w serii).

Версий: 'rьAlgo = HMAC-SHA256 @ 1', 'mappingVer = ruletka. v2 ',' calcVer = portfel-7. 2`.

Lista kontrolna wdrożenia PF operatora

Kryptografia i sidy

CSPRNG/HSM; unikalny 'server _ seed', udokumentowany obrót.
„client _ seed” - kontrolowany przez gracza, zapisany w historii.

Publikacje i przechowywanie

Zobowiązuje się do zakładów, dostęp do historii/kanału publikacji/kotwicy.
Magazyn WORM, znaczki UTC, partie merkley do wagi.

Algorytmy

RNG i odwzorowanie bez uprzedzeń; versioning 'rng Algo/mappingVer'.
Skrypt/strona „Sprawdź uczciwość” (otwarte źródło jest pożądane).

Żywo i hybryda

CV/RFID/kotwice hash fazy okrągłej, log „kiedy okno bukmacherskie zostało zamknięte”.
Procedury sporne (vkhodov → raport iskhod, linki do commits/VRF).

Bezpieczeństwo i audyt

Niezależny audyt protokołu PF, nagroda za błędy.
Dzienniki decyzji są niezmienne; regularne testy powtórne.

Provably Fair zmienia "zaufaj nam" w "sprawdź to sam. "Przy mapowaniu commit/revil lub VRF, deterministycznym RNG i prawidłowym odwzorowaniu bez offsetu, każda runda staje się odtwarzalna i weryfikowalna. Dla gracza to przejrzystość i zaufanie. Dla operatora - mniej kontrowersji, silniejsza marka i zgodność z wymogami regulacyjnymi. Najważniejszą rzeczą jest dyscyplina: publikować z wyprzedzeniem zobowiązania, naprawiać wersje algorytmów, przechowywać dowody niezmiennie i dać użytkownikowi proste narzędzie weryfikacji.