El algoritmo provably fair por dentro: seeds, hashes y resultados verificables

El algoritmo provably fair es la respuesta criptográfica a la pregunta más antigua del juego online: ¿cómo sabe un jugador que el operador no ha manipulado el resultado? La respuesta no es una promesa ni un documento de políticas. Es un esquema de compromiso construido con funciones hash estándar, en el que el resultado queda fijado antes de la apuesta y cualquiera puede recalcularlo después. Este es un recorrido de nivel técnico por el funcionamiento de ese esquema: los seeds, las funciones hash, el flujo commit-reveal y los pasos que sigue un jugador para verificar una ronda de forma independiente.

El problema de la confianza en el juego online

En un casino físico, la física es el árbitro. Una ruleta, una baraja o una bola producen un resultado que ni el jugador ni la casa pueden manipular fácilmente a posteriori. Online, esa restricción física desaparece: el resultado es un número en una base de datos, y el operador escribe la base de datos. El juego puede ser perfectamente honesto, pero el jugador no tiene forma directa de confirmarlo. Es una brecha de confianza estructural, no personal, y existe incluso con operadores bien regulados.

Hay dos formas establecidas de cerrar esa brecha. La primera es la certificación independiente: un laboratorio de pruebas acreditado audita el generador de números aleatorios y las matemáticas del juego, y un regulador concede la licencia al operador. La segunda es la verificabilidad criptográfica, en la que cada ronda individual puede ser comprobada por el jugador con datos publicados. Las implementaciones más sólidas hacen ambas cosas. Provably fair es el segundo enfoque, y para entenderlo necesitas entender dos primitivas que son anteriores a la industria del casino: el hashing criptográfico y el hashing con clave.

Esas primitivas están estandarizadas y son públicas. SHA-256 se especifica en el FIPS 180-4, Secure Hash Standard del NIST, y HMAC se define en la RFC 2104 del IETF. Nada en un sistema provably fair es magia propietaria; es criptografía aplicada con un protocolo específico a su alrededor.

Commit-reveal: cómo se fija el resultado antes de la apuesta

Commit-reveal es un protocolo de dos fases. En la fase de compromiso (commit), el operador genera un valor secreto llamado server seed y publica solo su hash. En la fase de revelación (reveal), una vez terminada la ronda (o cuando se rota el seed), el operador publica el server seed original. Entonces el jugador puede calcular el hash del seed revelado y confirmar que coincide con el compromiso publicado antes.

¿Por qué esto ata al operador? Porque una función hash criptográfica es determinista y resistente a la preimagen. La misma entrada produce siempre la misma salida, de modo que un seed revelado coincide con el compromiso o no coincide. Y, dado el hash, es computacionalmente inviable encontrar una entrada distinta que produzca el mismo hash, así que el operador no puede esperar a ver la entrada del jugador y sustituirla por un seed favorable. En la práctica, el operador firma un sobre sellado antes de la ronda y no puede cambiar su contenido después.

Es importante señalar que el hash también impide el abuso opuesto. Como el server seed está oculto en el momento del compromiso, el jugador no puede calcular de antemano el resultado que viene y apostar solo cuando le favorezca. El esquema protege a ambas partes: el operador queda atado a su seed y el jugador queda excluido del resultado hasta que la ronda se resuelve.

Server seed, client seed y nonce

Un solo secreto no basta para producir un resultado justo, porque si el operador controlara por sí solo toda la aleatoriedad podría probar seeds hasta encontrar los que le convienen. Por eso los sistemas provably fair combinan entradas de ambas partes más un contador. El modelo estándar de tres variables es:

Entrada	Quién la controla	Cuándo se revela	Forma habitual
Server seed	Operador	Solo después de rotar el seed	32 bytes aleatorios (64 caracteres hexadecimales)
Hash del server seed (compromiso)	Operador	De inmediato, antes de jugar	Digest SHA-256 (64 caracteres hexadecimales)
Client seed	Jugador	Siempre visible; editable por el jugador	Cadena definida por el jugador
Nonce	Sistema	Siempre visible	Entero que se incrementa en cada ronda

El client seed es la aportación del jugador a la aleatoriedad y puede cambiarse en cualquier momento, lo que impide que el operador conozca de antemano la entrada del jugador. El nonce garantiza la unicidad: aunque el server seed y el client seed no cambien, incrementar el nonce produce un resultado distinto en cada ronda. Juntos, estos tres valores son la receta completa y reproducible de un resultado. El proyecto de código abierto provably-fair-app en GitHub documenta este modelo exacto de tres variables y ofrece un ejemplo resuelto con dados, lo que lo convierte en una implementación de referencia útil para leer junto con este artículo.

Cómo el algoritmo provably fair aplica el hash con SHA-256

La derivación típica es un hash con clave. El server seed se usa como clave HMAC, y el client seed y el nonce forman el mensaje. HMAC, estandarizado en la RFC 2104, es una construcción que combina una clave secreta con una función hash para producir una etiqueta de autenticación. En el contexto de un juego se usa como una función pseudoaleatoria determinista con clave: sin el server seed nadie puede reproducir la salida, y una vez revelado el server seed cualquiera puede.

Intervienen dos usos distintos del hash, y conviene mantenerlos separados:

• SHA-256 para el compromiso. El hash del server seed publicado antes de jugar demuestra que el operador no cambió su seed después.
• HMAC-SHA256 para el resultado. El hash con clave del client seed y el nonce, usando el server seed como clave, genera los bytes en bruto que se traducen en un resultado de juego. Algunas implementaciones usan HMAC-SHA512 en su lugar, pero la estructura es la misma.

El digest resultante es un flujo de bytes. Después, un juego consume esos bytes y los asigna a su espacio de resultados: una tirada de dados dentro de un rango, un orden de cartas, posiciones de minas, un recorrido izquierda/derecha en Plinko o un multiplicador en los juegos crash y de estilo Aviator. La función de asignación difiere según el juego, pero la fuente de aleatoriedad es idéntica, por lo que una sola librería de verificación suele poder dar soporte a muchos tipos de juego.

Vídeo: cómo SHA-256 convierte una entrada en un digest fijo de 256 bits, paso a paso (fuente: YouTube / RedBlockBlue).

Ejemplo paso a paso con una ronda real

Lo que sigue es un ejemplo ilustrativo calculado a partir de las entradas mostradas, para que puedas reproducir cada línea con herramientas estándar. No es una ronda de producción de nuestra plataforma; es una demostración de la aritmética.

Entradas:

• Server seed: d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2
• Client seed: player-chosen-seed
• Nonce: 0

Paso 1 — compromiso. Calcula el hash del server seed con SHA-256:

SHA256("d1e2f3...d1e2")
= e2885f2c8169688374d0c54d6431a85b1c6dc0112259142f1e7674516abdde30

Este digest de 64 caracteres es lo que el operador publicaría antes de la ronda. No revela nada sobre el seed, pero lo deja fijado.

Paso 2 — derivación. Calcula HMAC-SHA256 con el server seed como clave y el client seed y el nonce como mensaje, usando el formato client_seed:nonce:

HMAC_SHA256(
  key     = "d1e2f3...d1e2",
  message = "player-chosen-seed:0"
)
= a103c485fcfe5c659e57f296a3a5074a98595b4c68c4d6db53d0d9ca41e27407

Paso 3 — asignación. Toma los primeros ocho caracteres hexadecimales, a103c485, conviértelos en un entero (2701378693) y divídelo entre 2³² (4.294.967.296) para obtener un valor entre 0 y 1: aproximadamente 0.62896374. Después, un juego escalaría ese número a su espacio de resultados. Para un coinflip, por ejemplo, el valor podría compararse con un umbral; para un multiplicador crash podría transformarse con la fórmula de pago del juego.

Paso 4 — revelación. Tras rotar el seed, publica el server seed. Cualquier tercero puede ahora ejecutar los pasos 1 y 2 y confirmar tanto que el compromiso coincide como que el resultado registrado se deriva del cálculo. Distintos juegos y operadores pueden usar delimitadores, desplazamientos de bytes o funciones de asignación diferentes, así que verifica siempre con la especificación publicada concreta; pero el esqueleto commit-reveal es universal.

Cómo verifican los jugadores un resultado de forma independiente

La verificación es un proceso de dos comprobaciones, y ambas son necesarias. La primera es la comprobación del compromiso: calcula el hash del server seed revelado y confirma que es igual al hash publicado antes de jugar. Si no coincide, el operador cambió los seeds y la ronda no es válida. La segunda es la comprobación de recálculo: introduce el server seed revelado, el client seed y el nonce en el algoritmo documentado para ese juego y confirma que la salida coincide con el resultado registrado. Si el compromiso se cumple pero el recálculo falla, el operador no tocó el seed, pero informó mal del resultado.

Un sistema que solo realiza una de estas comprobaciones es provably fair solo en parte. El compromiso por sí solo demuestra que el seed estaba fijado, pero no dice nada sobre si el resultado comunicado se deriva de él; el recálculo por sí solo da por hecho que el seed es genuino. Juntas cubren las dos superficies de ataque realistas: la sustitución de seeds y la falsificación de resultados.

Herramientas de verificación y qué comprobar

Como verificar cientos de apuestas a mano no es práctico, la mayoría de las plataformas provably fair incluyen un verificador, y existen verificadores independientes de código abierto para los algoritmos habituales. Ya construyas uno o uses una herramienta existente, la lista de comprobación es la misma:

• Confirma que el algoritmo y el delimitador coinciden con la especificación publicada por el operador (por ejemplo client_seed:nonce frente a client_seed-nonce).
• Confirma la función hash usada para el compromiso (normalmente SHA-256) y para la derivación (HMAC-SHA256 o HMAC-SHA512).
• Confirma cómo se asignan los bytes a los resultados en el juego concreto, incluido cualquier desplazamiento de bytes o cursor.
• Confirma que el seed se rotó y que se reveló el server seed correcto para las rondas que se están comprobando.
• Ejecuta el verificador en el lado del cliente, de modo que la comprobación use solo entradas públicas y no dependa de los servidores del operador.

Para los operadores, tratar el verificador como una función de producto de primer nivel (documentada, determinista e independiente) es lo que convierte el «confía en nosotros» en «compruébanos».

Casos límite: rotación de seeds, reutilización del nonce y quién controla qué

La mayoría de las disputas reales provienen de casos límite y no de las matemáticas básicas. La rotación de seeds es el más común: el server seed solo puede revelarse con seguridad una vez retirado, porque publicar un seed activo permitiría a los jugadores calcular resultados futuros. Eso significa que la verificación es retrospectiva por naturaleza: verificas una cadena completada de apuestas después de rotar a un nuevo seed. Un sistema bien diseñado muestra el compromiso del seed actual y permite a los jugadores revelar y comprobar los anteriores.

La gestión del nonce es la siguiente trampa. Si alguna vez se reutiliza un nonce con el mismo server seed y client seed, la misma entrada produce la misma salida, lo que es un problema tanto de equidad como de transparencia. Los nonces deben incrementarse de forma fiable y, en un sistema concurrente, de forma atómica; una condición de carrera que reutilice un nonce es un error genuino, no cosmético. Los client seeds son la tercera variable que considerar: los jugadores deben poder cambiarlos libremente, y al hacerlo se inicia una nueva cadena de resultados para ese par de seeds.

Por último, hay que ser preciso sobre quién controla qué. El operador elige el server seed y no puede cambiarlo tras el compromiso. El jugador elige o acepta un client seed y puede rotarlo. El sistema incrementa el nonce. Ninguna parte controla por sí sola la entrada completa, y ese es el objetivo de todo el esquema. Cualquier implementación en la que se pueda ignorar la entrada del jugador, o en la que el server seed pueda regenerarse después de ver el client seed, no es provably fair, con independencia de cómo se comercialice.

Provably fair frente a RNG certificado: qué dice la regulación

Provably fair y el RNG certificado son complementarios, no sustitutivos. La certificación es una auditoría independiente: un laboratorio de pruebas revisa el código fuente del generador de números aleatorios, la generación de seeds y la salida estadística, y confirma que el juego se comporta según lo diseñado. El proceso de certificación de RNG de eCOGRA, por ejemplo, abarca la revisión del código fuente, el análisis estadístico de la distribución de la salida, la generación de seeds, la resistencia a la predicción y las pruebas periódicas. Laboratorios como iTech Labs realizan pruebas equivalentes de RNG y de matemáticas del juego en mercados regulados. Para ver cómo esas cifras de retorno certificadas se traducen en decisiones comerciales, lee nuestra guía para operadores sobre RTP, ventaja de la casa y volatilidad.

Provably fair añade encima una pista de auditoría a nivel de jugador. La certificación afirma que el sistema es estadísticamente sólido; commit-reveal permite que un jugador concreto demuestre que una apuesta específica no fue manipulada. Los reguladores suelen seguir exigiendo la capa de RNG certificado, porque la certificación es el mecanismo que reconocen y pueden hacer cumplir, mientras que provably fair refuerza la confianza y la resolución de disputas. Para un operador técnico, la arquitectura sensata es ambas: una base de RNG certificado para el cumplimiento normativo y una capa provably fair para la transparencia.

Esa transparencia también rinde en otras partes de la pila de cumplimiento. Un registro de resultados auditable y a prueba de manipulaciones respalda la monitorización de transacciones y los controles de cuenta descritos en nuestra guía sobre KYC y AML en juegos crash con cripto, porque cada ronda tiene un registro verificable en lugar de una entrada de log opaca. Si estás diseñando la infraestructura que lo rodea, nuestra explicación de qué es un servidor de juego remoto muestra dónde se ubican el RNG y la lógica de seeds, y el panorama completo está en nuestra guía de arquitectura de RGS. Para el vocabulario, consulta las entradas sobre aleatoriedad y hashing de nuestro glosario de iGaming.

Preguntas frecuentes

¿Es realmente aleatorio un algoritmo provably fair?

Es determinista dadas las entradas, lo que es una característica y no un defecto: el determinismo es lo que hace posible la verificación independiente. La salida es impredecible antes de la ronda porque el server seed es secreto y el client seed lo controla el jugador, y está distribuida de forma uniforme cuando se asigna correctamente. Las pruebas de RNG certificado siguen importando para la calidad estadística; provably fair añade verificabilidad encima.

¿Puede hacer trampas el servidor?

No sin ser detectado, siempre que el protocolo esté bien implementado y se realicen ambas comprobaciones. Cambiar el server seed después del compromiso rompe la comprobación del compromiso, y falsear un resultado rompe la comprobación de recálculo. Cualquier parte que controle todas las entradas podría sesgar los resultados, y por eso existen el client seed y un nonce que se incrementa de forma fiable.

¿Cómo verifico una ronda?

Una vez revelado el server seed, calcula su hash y confirma que el digest coincide con el compromiso publicado antes de jugar. Después, recalcula el resultado con el algoritmo documentado usando el server seed revelado, tu client seed y el nonce de la ronda, y confirma que coincide con el resultado registrado. Usa el verificador del operador o uno independiente de código abierto, idealmente ejecutándose en el lado del cliente.

Descubre cómo funciona nuestro motor provably fair

La equidad demostrable es un estándar de ingeniería, no un eslogan de marketing. Si quieres revisar el flujo commit-reveal, el ciclo de vida de los seeds y las herramientas de verificación que hay detrás de nuestros juegos, nuestro equipo puede guiarte por la documentación y el detalle a nivel de código.

Cómo funciona nuestro sistema provably fair · Explora Coinflip · Contacta con nosotros