O que é Provably Fair e como verificar a honestidade do jogo

O que é Provably Fair (PF)

Provably Fair é um protocolo que permite verificar criptograficamente que o resultado da rodada foi acidental e não pode ter sido substituído pela operadora após a aposta.

Ideia: primeiro é publicado o hash (hash server seed oculto), depois da aposta é exposto o revezamento (o próprio server seed), e qualquer um pode cruzar o hash e reproduzir o RNG, considerando o cliente seed do jogador e os identificadores da rodada.

Protocolo básico: commit → bet → reveal

1. Commit: Antes das rodadas, o servidor gera um 'server _ seed' aleatório e publica seu hash:


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

A Comit pode ser colocada em histórico/blockchain/diário.

2. Aposta: O jogador escolhe ou confirma seu 'cliente _ seed' (de UI ou seu próprio), envia a aposta com:


client_seed, roundId, nonce

3. Reveal: após fechar as apostas, o servidor divulga 'server _ seed' (e 'salt', se for) para que todos possam verificar:


SHA-256(server_seed         salt) = = commit//verificação de integridade

4. RNG: O número de acidentalidade é determinado e reproduzido:


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

5. Mapping em desfecho: Convertamos 'rng' em uma faixa de jogo sem deslocamento (veja abaixo).

💡 Por que não? Para que, com um 'server _ seed', você possa realizar muitas rodadas sem risco de previsibilidade: 'nonce' é incorporada a cada rodada/aposta.

Como obter um número sem deslocamento (bias-free)

Não é correto pegar 'rng% N' - isso dá um deslocamento modular, a menos que 2 ^ k seja múltiplo de N. Certo - rejation sampling:

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

limit = floor(2^256 / N) N while x >= limit:
rng _ bytes = SHA-256 (rng _ bytes )//« misturar »novamente determinada x = uint256 (rng _ bytes)

result = x % N

É assim que se faz uma distribuição uniforme em N do resultado (células de roleta, símbolos de tambor, etc).

Mini-exemplo (verificação passo a passo por jogador)

Digamos:


server _ seed = «b2c6... e9 »//revelado após a rodada (hex/utf8)
cliente _ seed = «my-cliente-seed »//escolhido por mim roundId =« R-2025-10-17-001 »
nonce = 42 commit = «c9a1... f3 »//opble. com antecedência

1) Verificar Comit

Contar 'SHA-256 (server _ seed)' e certificar-se de que corresponde a 'commit'.

2) RNG determinado

Contar:


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

3) Conversão em desfecho

Para uma roleta (37 números) → N = 37, aplicar rejempresarial sampling e pegar 'x% 37'.

Para slot, use várias porções de RNG para definir tambores/caracteres de acordo com a tabela de distribuição.

4) Verificar com o resultado da história

O local deve exibir as mesmas entradas usadas no cálculo: 'server _ seed', 'cliente _ seed', 'roundId', 'nonce', 'hashAlgo', 'rngAlgo', 'mappingVersion'.

Alternativa/reforço: VRF (Verificable Random Funcition)

Em vez de uma comitiva, o operador pode (ou opcional) usar o VRF:

1. Um contrato inteligente ou um registro público é solicitado pelo provedor de serviços 'VRF (seed)'.

2. É publicado '(random, proof)'.

3. Qualquer um pode verificar 'proof' com o mesmo par-chave público da KRF.

4. A seguir, os mesmos passos do mapping RNG para o desfecho.

Vantagem: menos confiança no operador. Contras: Dependência do provedor/cadeia de VRF e custo possível.

Como o casino deve implementar a PF corretamente

Contrato (contrato de dados da PF)

Campos no histórico da rodada:

`serverSeedHash`, `serverSeedReveal`, `clientSeed`, `roundId`, `nonce`, `hashAlgo`, `rngAlgo`, `mappingVer`, `proofUrl` (опц.) , `calcVer`.
Os valores são no armazenamento WORM (imutable), com carimbos de tempo (UTC).

Geração de assentos

'server _ seed' é gerado por PRNG (OS CSPRNG/HSM).

Os cidos nunca devem ser repetidos entre as séries (rotação).

'cliente _ seed' é selecionado pelo jogador ou gerado no cliente e confirmado.

Publicar Kammits

As empresas estão disponíveis até as apostas (histórico, RSS, on-chain-âncora).

Os lotes podem usar uma árvore de Kommits com a publicação diária da raiz.

Divulgação (reveal)

Antes de publicar o resultado, 'server _ seed' é exposto e logado.

Para uma série de rodadas em um único cido - divulgação após o fim da série (especifique a política com antecedência).

Mapping transparente

A versão do algoritmo de mapping ('mappingVer') é captada.

Qualquer alteração ('mappingVer '/' rngAlgo') é apenas com um anúncio e uma nova série de commites.

Auditoria e controvérsia

Entradas crus + gravação de cálculos são salvas; A disputa gera um relatório: entradas RNG maping para o resultado.

Stream/Live: Armazenando as âncoras de hash dos eventos de CVM/RFID, vídeo em WORM.

Como um jogador verificar honestidade (folha de cheque)

1. Abra o histórico da rodada e copie: « », « », « », « », « ».

2. Conte «serverSeedReveal» e compare com «serverSeedHash».

3. Conte o RNG com o algoritmo especificado (HMAC/Hash + entradas).

4. Aplique o mapping «indefectível» ao número de resultados.

5. Verifique se o resultado corresponde ao exibido.

6. Se a VRF for declarada, verifique «proof» (botão «Verify» ou script independente/exposição).

Erros típicos (anti-pattern)

'rng% N' sem rejation sampling → as probabilidades deslocadas.

«cliente _ seed» oculto ou em mudança (gerado por um servidor sem a participação de um jogador).

Superestimação de 'server _ seed' após a aposta (a comita muda para trás).

Alterações opacas de algoritmos sem versão/publicação.

Repetição de assentos entre os episódios.

Sem carimbos de tempo WORM - Não é possível comprovar a ordem dos eventos.

Mistura PF e lógica de negócios (por exemplo, o bónus é aplicado de modo a alterar o espaço dos resultados, mas isso não está descrito em 'mappingVer').

FAQ (breve)

Podemos verificar as slots, não apenas a roleta?

Sim, sim. A PF é aplicada à seqüência de eleições (por exemplo, índice de caracteres no tambor). É importante que as tabelas de probabilidade e a ordem de leitura de RNG sejam documentadas.

E se eu introduzir o meu 'cliente _ seed', a operadora ainda pode 'selecionar' 'server _ seed'?

Não se a empresa tiver sido publicada antes da aposta. Ele capta 'server _ seed' e impede que ele seja substituído retroativamente.

Porque é que, às vezes, abrem os assentos com sacos?

Para que não seja possível «desligar» o sebo na série. Isso é aceitável se a comitiva for publicada com antecedência e a política de divulgação é transparente.

Formatos de minirreforma

Hashi: SHA-256 ou Keccak-256.

RNG: HMAC-SHA256 ou SHA-256 de concatenação.

Identificadores: 'roundId' (carimbo UTC + jogo + incenso), 'nonte' (contador de apostas da série).

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

Folha de cheque de implementação da PF para o operador

Criptografia e cidos

CSPRNG/HSM; exclusivo 'server _ seed', rotação documentada.
'cliente _ seed' - controlado por um jogador, é preservado na história.

Publicações e armazenamento

Comitas antes das apostas, acesso ao histórico/canal de publicação/âncora.
Armazenamento WORM, carimbos UTC, batches merkli para escala.

Algoritmos

RNG e maping sem deslocamento; versionização de 'rngAlgo/mappingVer'.
O script/página «Testar honestidade» é desejável.

Live e híbrido

Hash-âncora CV/RFID/fase da rodada, revista «quando a janela de apostas foi fechada».
Procedimentos de litígio (relatório vkhodov→iskhod, referências a comitas/ERRF).

Segurança e auditoria

Auditoria independente do protocolo da PF, erro-bounty.
Os logs de soluções são imutáveis; testes regulares de reprodução.

Provably Fair transforma «acredite» em «verifique você mesmo». Com o commit/revil ou o VRF, o RNG determinado e o mapping correto sem deslocamento, qualquer rodada se torna reproduzível e verificável. Para um jogador, é transparência e confiança. Para o operador, menos disputas, marca mais forte e conformidade com os reguladores. O principal é a disciplina: publicar as comitivas com antecedência, capturar versões de algoritmos, armazenar provas invariavelmente e dar ao usuário uma ferramenta simples de verificação.