Verificador provably fair — confira rodadas de crash, Mines e Plinko

Compromisso, revelação, verificação

Os sistemas provably fair funcionam em três etapas. Primeiro, o compromisso: antes de você jogar, o operador publica o hash de uma seed do servidor que já escolheu mas ainda não revelou — geralmente SHA-256, registrado em algum lugar para onde você (ou qualquer pessoa) pode apontar depois. Segundo, a jogada: cada rodada combina essa seed do servidor escondida com uma seed do cliente (sua, ou gerada para você) e um nonce que sobe de um em um a cada rodada, produzindo o resultado por uma fórmula fixa. Terceiro, revelação e verificação: mais tarde, normalmente quando você troca para uma nova seed de servidor, a antiga é publicada. Calcular o hash dela deve reproduzir o compromisso do primeiro passo, e rodar a fórmula de novo deve reproduzir cada rodada que você jogou.

Uma checagem que falha — um hash calculado ou um resultado que não bate — é uma divergência, não prova automática de fraude: pode vir tanto de um erro de digitação numa seed quanto do nonce errado, de um hash que nunca foi de fato publicado com antecedência, ou de conferir uma rodada de outro esquema (layout de bytes ou fórmula diferentes) com esta ferramenta. Trate uma divergência como motivo para conferir de novo as entradas e o esquema primeiro, e só depois como indício de manipulação, quando essas causas já tiverem sido descartadas — idealmente contra um compromisso que você (ou um terceiro independente) consiga mostrar que foi registrado antes da rodada acontecer.

A seed do servidor é a metade que só o operador conhece até a revelação — é ela que impede resultados previsíveis com antecedência. A seed do cliente pode impedir o operador de escolher silenciosamente uma seed de servidor favorável à casa para um jogador específico, mas só sob duas condições: o compromisso de hash precisa estar registrado em algum lugar conferível antes da rodada, e a seed do cliente precisa ser escolhida por você (ou de outra forma que o operador não controle nem consiga prever) depois que o hash já está público, e não fornecida ou sobrescrita pelo operador. O nonce é um contador de rodadas: cada novo nonce alimenta uma mensagem diferente na etapa de HMAC abaixo, produzindo um resultado separado com as mesmas duas seeds — ele sozinho não torna os resultados imprevisíveis, e reutilizar as mesmas seeds com o mesmo nonce sempre reproduz o mesmo resultado (essa repetição é esperada, não um defeito).

O que o HMAC-SHA256 faz

O HMAC-SHA256 pega uma chave secreta (a seed do servidor) e uma mensagem (seedDoCliente:nonce:contador) e produz um bloco de 32 bytes que é determinístico mas parece ruído, a menos que você conheça a chave. O verificador monta essa mensagem com contador 0, calcula o HMAC e converte os bytes para hex no passo mostrado acima. No Crash, os primeiros 13 caracteres hexadecimais do bloco 0 são lidos como um inteiro de 52 bits; no Mines e no Plinko, o bloco (e mais blocos, se uma rodada precisar de mais bytes, com o contador aumentando) é lido como inteiros de 32 bits big-endian — cada um alimenta a fórmula de resultado do próprio jogo. Nada aqui fica escondido ou sorteado além da própria seed do servidor.

Esquema de referência cashoutodds v1 (documentado)

Como os provedores reais raramente publicam especificações completas, este verificador implementa e documenta o próprio esquema aberto para que cada etapa seja conferível:

• Crash: pega os primeiros 13 caracteres hex do bloco 0 como um inteiro de 52 bits h, depois bust = max(1, floor(100·(1−e)·2^52 / (2^52 − h)) / 100), em que e é a vantagem da casa — este verificador sempre usa e = 3% (0,03), o mesmo valor dos nossos simuladores. Valores maiores de h empurram o multiplicador para cima; a fórmula usa aritmética inteira exata, não ponto flutuante.
• Mines: as posições das minas são sorteadas com Fisher–Yates por amostragem por rejeição sobre as casas restantes — cada inteiro de 32 bits do fluxo só é aceito se cair abaixo do maior múltiplo do número de casas, então toda casa restante mantém a mesma chance e não há viés de módulo.
• Plinko: cada linha consome um inteiro de 32 bits e lê só o bit mais significativo dele — 1 significa direita, 0 significa esquerda — porque um intervalo de 32 bits se divide em duas metades exatamente iguais, de novo sem viés.

Cada uma dessas regras é determinística e reproduzível: com a seed do servidor revelada, a seed do cliente, o nonce, esta versão do esquema de referência e os mesmos parâmetros do jogo (tamanho do tabuleiro e número de minas no Mines, número de linhas no Plinko, vantagem da casa no Crash), você (ou qualquer pessoa) pode recalcular exatamente o mesmo multiplicador, layout de minas ou caminho do Plinko mostrado acima — é isso que esta ferramenta faz, inteiramente no seu navegador. As seeds podem ser digitadas direto ou passadas pelo fragmento da URL (a parte depois do #), que o navegador nunca envia a um servidor — nada é transmitido a lugar nenhum.

O que a verificação prova — e o que não prova

Um hash que confere só mostra que a seed informada gera o hash de compromisso informado — e o exemplo padrão calcula esse hash na hora, então ele demonstra consistência, não um compromisso histórico. Esta ferramenta recalcula, separadamente, um resultado do esquema de referência a partir das mesmas seeds e do mesmo nonce; comparar esse resultado recalculado com o resultado que o seu jogo realmente mostrou é algo que você faz por conta própria, contra entradas e um hash de compromisso registrados antes da rodada acontecer. Fazer essa comparação descarta a possibilidade de o servidor trocar silenciosamente a seed do servidor por uma mais favorável à casa depois de já saber a sua aposta — desde que o hash do compromisso tenha sido de fato registrado em algum lugar antes da rodada (não apenas alegado depois). Isso sozinho não garante a consistência total do resultado: também é preciso conferir a seed do cliente, o nonce e os parâmetros efetivamente usados naquela rodada contra o que foi registrado. Uma checagem que falha é uma divergência, não prova de manipulação por si só — uma entrada errada, um nonce digitado errado ou a conferência de uma rodada de terceiro contra o esquema errado podem produzir o mesmo resultado de "não confere" que uma fraude de verdade produziria. Isso não remove a vantagem da casa, não significa que a tabela de pagamento é generosa, e não é garantia de ganhar — um jogo pode ser perfeitamente provably fair e ainda devolver menos do que arrecada, por design. Se a pergunta é se um jogo de marca específica está "manipulado", a checagem provably fair (quando um provedor a implementa corretamente, e quando você a confere contra o esquema do próprio provedor) responde à pergunta estreita de consistência entre resultado e seed, não à pergunta mais ampla de retorno esperado — que você pode estimar com a nossa calculadora de perda esperada ou o simulador de crash.

Vetores de teste

Três entradas fixas e suas saídas do motor, para você conferir uma implementação independente contra a nossa:

Mais ferramentas: simulador de crash · calculadora de chances do Mines · distribuição do Plinko · calculadora de risco de ruína · metodologia.