Qué es Provably Fair y cómo comprobar la integridad del juego

Qué es Provably Fair (PF)

Provably Fair es un protocolo que permite verificar criptográficamente que el resultado de la ronda fue aleatorio y no pudo ser reemplazado por el operador después de la apuesta.

Idea: primero se publica un commit (hash de seed del servidor oculto), luego después de la apuesta se revela el rugido (seed del servidor en sí), y cualquiera puede conciliar el hash y reproducir el RNG dado el client seed del jugador y los identificadores de la ronda.

Protocolo básico: commit → bet → reveal

1. Commit: antes de que comiencen las rondas, el servidor genera un 'server _ seed' aleatorio y publica su hash:


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

El commit se puede llevar a la historia/blockchain/registro.

2. Apuesta: el jugador selecciona o confirma su 'client _ seed' (de IU o propio), envía la apuesta con:


client_seed, roundId, nonce

3. Reveal: después de cerrar las apuestas, el servidor revela 'server _ seed' (y 'salt' si lo hubiera) para que todos puedan comprobar:


SHA-256(server_seed         salt) = = commit//verificación de integridad

4. RNG: el número de aleatoriedad es determinista y reproducible:


rng = HMAC-SHA256(key=server_seed, msg=client_seed          roundId          nonce)
//o rng = SHA-256 (server_seed         client_seed          roundId          nonce)

5. Mapping a éxodo: convertimos 'rng' en un rango de juego sin desplazamiento (ver más abajo).

💡 ¿Por qué nonce? Para que con un 'server _ seed' se puedan realizar muchas rondas sin riesgo de previsibilidad: 'nonce' se incorpora cada ronda/apuesta.

Cómo obtener un número sin desplazamiento (bias-free)

No es correcto tomar 'rng% N' - esto da un desplazamiento modular si 2 ^ k no es múltiplo de N. Correcto - rejection sampling:

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

limit = floor(2^256 / N) N while x >= limit:
rng_bytes = SHA-256 (rng_bytes )//« mezclar »una vez más determinista x = uint256 (rng_bytes)

result = x % N

Así obtenemos una distribución uniforme sobre los resultados N (celdas de ruleta, símbolos de tambor, etc.).

Mini ejemplo (verificación paso a paso por el jugador)

Supongamos:


server_seed = «b2c6... e9 »//revelado después de la ronda (hex/utf8)
client_seed = «my-client-seed »//seleccionado por mí roundId =« R-2025-10-17-001 »
nonce = 42 commit = «c9a1... f3 »//opuble. De antemano

1) Comprobar commit

Contar 'SHA-256 (server_seed)' y asegurarse de que coincide con 'commit'.

2) RNG determinista

Contar:


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

3) Conversión a resultado

Para la ruleta (37 números) → N = 37, aplique sampling de rejección y tome 'x% 37'.

Para ranura: utilice varias porciones de RNG para definir los carretes/caracteres según la tabla de distribución.

4) Conciliar con el resultado en la historia

La plataforma debe mostrar las mismas entradas utilizadas en el cálculo: 'server _ seed', 'client _ seed', 'roundId', 'nonce', 'hashAlgo', 'rngAlgo', 'mappingVersion'.

Alternativa/Refuerzo: VRF (Función de Random Verificable)

En lugar de commit, el operador puede (o opcionalmente) utilizar VRF:

1. El contrato inteligente o registro público solicita al proveedor 'VRF (seed)'.

2. Se publica '(random, proof)'.

3. Cualquiera puede comprobar 'proof' por la misma pareja clave pública del VRF.

4. A continuación, los mismos pasos de mapeo de RNG en el resultado.

Ventajas: menos confianza en el operador. Contras: dependencia del proveedor/circuito VRF y posible costo.

Cómo el casino debe implementar PF correctamente

Contrato (contrato de datos PF)

Campos en la historia de la ronda:

`serverSeedHash`, `serverSeedReveal`, `clientSeed`, `roundId`, `nonce`, `hashAlgo`, `rngAlgo`, `mappingVer`, `proofUrl` (опц.) , `calcVer`.
Valores: en almacenamiento WORM (immutable), con sellos de tiempo (UTC).

Generación de asientos

'server _ seed' es generado por un PRNG a prueba de cifrado (OS CSPRNG/HSM).

Los sides nunca deben repetirse entre series (rotación).

'client _ seed': es seleccionado por el jugador o generado en el cliente y confirmado.

Publicación de commits

Los commits están disponibles antes de las apuestas (historial, RSS, on-chain-ancla).

Para los lotes, puede utilizar un árbol merckley de commits con la publicación diaria de la raíz.

Divulgación (reveal)

Antes de publicar el resultado, 'server _ seed' se abre y se lógica.

Para una serie de rondas en un solo asiento - revelación después del final de la serie (especificar la política con antelación).

Mapping transparente

La versión del algoritmo mapping ('mappingVer') está fijada.

Cualquier cambio ('mappingVer '/' rngAlgo') es solo con el anuncio y una nueva serie de commits.

Auditorías y disputas

Se guardan las entradas crudas + la entrada de cálculo; en caso de disputa, se genera un informe: las entradas → RNG → mapping → el resultado.

Streams/Live: almacenar anclas hash de eventos CV/RFID, vídeo en WORM.

Cómo comprobar la honestidad del jugador (lista de verificación)

1. Abra el historial de la ronda y copie: 'serverSeedReveal', 'clientSeed', 'roundId', 'nonce', 'hashAlgo', 'rngAlgo', 'mappingVer'.

2. Cuente el hash 'serverSeedReveal' y compárelo con 'serverSeedHash'.

3. Calcule el RNG según el algoritmo especificado (HMAC/Hash + entradas).

4. Aplique el mapping «sin desplazamiento» (rejection sampling) al número de resultados.

5. Asegúrese de que el resultado es el mismo que se muestra.

6. Si el VRF está declarado, compruebe 'proof' (botón 'Verify' o script/block explorer independiente).

Errores de tipo (anti-patrones)

'rng% N' sin rejection sampling → probabilidades sesgadas.

'client _ seed' oculto o cambiante (generado por el servidor sin la participación del jugador).

La sobregeneración de 'server _ seed' después de la apuesta (el commit cambia retroactivamente).

Cambios opacos de algoritmos sin versión/publicación.

Repetición de asientos entre series.

No hay sellos de tiempo/WORM - no se puede probar el orden de los eventos.

Mezcla de PF y lógica empresarial (por ejemplo, el bono se aplica para cambiar el espacio de resultados, pero esto no se describe en 'mappingVer').

Preguntas frecuentes (breves)

¿Se pueden comprobar las ranuras, no sólo la ruleta?

Sí. PF se aplica a la secuencia de elección (por ejemplo, el índice de caracteres en el tambor). Es importante que se documenten las tablas de probabilidad y el orden de lectura del RNG.

¿Y si escribí mi 'client _ seed', el operador todavía puede 'seleccionar' 'server _ seed'?

No, si el commit fue publicado antes de la apuesta. Fija 'server _ seed' y evita que se reemplace con retroactividad.

¿Por qué a veces se abren los asientos por lotes?

Para que no haya forma de «repasar» el led en la serie. Esto es admisible si el commit se publica de antemano y la política de divulgación es transparente.

Mini referencia de formatos

Hashi: SHA-256 o Keccak-256.

RNG: HMAC-SHA256 (servidor led como clave) o SHA-256 de concatenación.

Identificadores: 'roundId' (sello UTC + juego + incremento), 'nonce' (contador de apuestas de la serie).

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

Lista de comprobación de implementación de PF para el operador

Criptografía y asientos

CSPRNG/HSM; 'server _ seed' único, rotación documentada.
'client _ seed' es un jugador controlado, guardado en la historia.

Publicaciones y almacenamiento

Commits antes de las apuestas, acceso al historial/canal de publicaciones/ancla.
Almacenamiento WORM, matrices UTC, batches Merckley para escalas.

Algoritmos

RNG y mapping sin desplazamiento; versionar 'rngAlgo/mappingVer'.
Script/página «Comprobar honestidad» (código abierto deseable).

Live e Híbrido

Hash anclas CV/RFID/fase ronda, revista «cuando se cierra la ventana de apuestas».
Procedimientos contenciosos (informe vkhodov→iskhod, referencias a commits/VRF).

Seguridad y auditoría

Auditoría independiente del protocolo PF, bug bounty.
Los registros de decisiones son inmutables; pruebas de reproducción regulares.

Provably Fair convierte «créenos» en «compruebe usted mismo». Con commit/rugido o VRF, RNG determinista y mapping correcto sin desplazamiento, cualquier ronda se vuelve reproducible y verificable. Para el jugador, es transparencia y confianza. Para el operador, hay menos disputas, una marca más fuerte y el cumplimiento de los reguladores. Lo principal es la disciplina: publicar commits con antelación, fijar versiones de algoritmos, almacenar pruebas invariablemente y dar al usuario una herramienta de verificación sencilla.