El truco, en un párrafo
Una función hash criptográfica convierte cualquier entrada en una huella digital de longitud fija con dos propiedades que importan aquí: no puedes trabajar hacia atrás desde la huella hasta la entrada, y no puedes encontrar dos entradas con la misma huella. Así que si alguien te muestra la huella de un secreto hoy y el secreto mañana, puedes hashear el secreto y comprobar que coincide. Si coincide, el secreto que te mostraron es el que tenían ayer. No podrían haberlo cambiado en el ínterin, porque un secreto diferente tendría una huella diferente, y no podrían haber elegido el secreto para que encajara con la huella, porque eso significaría revertir el hash.
Eso es un esquema de compromiso, y es todo el contenido criptográfico de “provably fair”. La casa genera una semilla del servidor (server seed), publica su hash SHA-256, juega rondas derivadas de la semilla y revela la semilla cuando el par se retira. Todo lo demás es fontanería.
VERIFICADO POR EL MOTOR_shared/seedApi.ts: getRandomKey devuelve {serverSeedHashed, clientSeed, nonce}; renewRandomKey devuelve un par nuevo junto con previousServerSeed y previousServerSeedHashed, la revelación. _shared/SeedPanel.tsx etiqueta el campo como “server seed (compromiso sha-256)”. _shared/rng.ts: sha256Hex() calcula la huella y hmacSha256Utf8() el hash por ronda, con el comentario de que el motor de demostración “GENERA resultados con las mismas primitivas que usa el verificador para COMPROBARLOS — una sola implementación, para que la demo nunca pueda desviarse de lo que acepta el verificador”.
Tres cosas que demuestra
| AFIRMACIÓN | POR QUÉ SE SOSTIENE | LA COMPROBACIÓN |
|---|---|---|
| La semilla del servidor se fijó antes de tus apuestas | Cualquier cambio en la semilla cambiaría su hash, y el hash se mostró antes de la primera ronda | Anota el compromiso en el panel de semillas antes de jugar |
| La semilla revelada es la que se comprometió | Una semilla diferente no puede producir la misma huella SHA-256 | Hashea la semilla revelada; compárala con el compromiso que anotaste |
| Cada resultado se deriva del par de semillas y del número de ronda | El resultado es HMAC-SHA256(server seed, “client seed-nonce-cursor”) pasado por la derivación publicada del juego | Recalcula la ronda en tu navegador a partir de las cuatro entradas; el panel lo hace por ti |
Las tres comprobaciones son locales: necesitan la semilla revelada, tu semilla de cliente, el nonce y el código de derivación, y nada de la casa en el momento de la comprobación.
La tercera afirmación es la que hace el trabajo para un jugador, y depende de que la derivación sea pública. Un hash de la semilla no te dice nada sobre cómo la semilla se convirtió en una tirada de dados o una carta. Aquí esa función viene en el cliente, el mismo código que usa la demo para generar resultados y que usa el verificador para comprobarlos, así que una ronda recalculada es un recálculo real y no una petición al servidor para que se confirme a sí mismo.
VERIFICADO POR EL MOTOR_shared/demoLocal.ts: uAt() deriva el número de cada ronda como u64(hmacSha256Utf8(serverSeed, `${clientSeed}-${nonce}-${cursor}`)), descrito como equivalente a RandomUtils.generateHash en el servidor; _shared/rng.ts convierte los primeros siete bytes del HMAC en un número uniforme en [0, 1) “que coincide bit a bit con el redondeo Long→Double del servidor”. El módulo de derivación de cada juego mapea luego ese número a una tirada, una carta o un multiplicador.
El recorrido de verificación hace los tres pasos sobre una ronda real. Si nunca lo has hecho, hazlo una vez; el punto del esquema no es que revises cada ronda, sino que podrías revisar cualquiera de ellas, y la casa no puede saber de antemano cuál.
Tres cosas que no puede probar
No puede probar que la semilla fue aleatoria. Un compromiso fija una semilla; no dice nada sobre cómo se eligió. Si la casa conocía tu semilla de cliente cuando generó la semilla del servidor, en principio podría generar semillas hasta encontrar una cuyas primeras rondas le gustaran, y comprometerse con esa. El hash coincidiría perfectamente. La defensa estándar es el orden: la semilla del servidor se compromete primero, y la semilla del cliente se fija después, de modo que, sea lo que sea a lo que la casa se comprometió, no sabía con qué se combinaría.
Ese orden es donde el panel de este sitio tiene un límite que vale la pena señalar claramente. Establecer una semilla de cliente aquí no deja intacta la semilla de servidor actual; rota el par, y la nueva semilla de servidor se genera con la misma solicitud que lleva tu nueva semilla de cliente. Desde el cliente no es posible demostrar que la nueva semilla se fijó antes de que se leyera la solicitud. Si el servidor pregenera la siguiente semilla, como hacen algunos operadores publicando el siguiente compromiso por adelantado, no es visible en la API del cliente, y no hay ningún campo de “hash de la próxima semilla del servidor” contra el cual comprobar. Esto se ha planteado al equipo del juego, y la solución es pequeña: comprometer la próxima semilla del servidor antes de aceptar la semilla del cliente con la que se emparejará, y mostrar ese compromiso en el panel.
VERIFICADO POR EL MOTOR_shared/seedApi.ts: setClientSeed(clientSeed) llama a renewRandomKey con la nueva semilla de cliente y devuelve un par nuevo en nonce 0; rotate() llama al mismo endpoint sin semilla. IHouseSeed lleva serverSeedHashed, clientSeed y nonce, más el par anterior en la rotación; no hay ningún compromiso de próxima semilla presente en el tipo.
Hasta entonces, la versión práctica de la defensa es la que el esquema ya te da en cualquier otro aspecto: la revelación. Una casa que buscara semillas contra tu semilla de cliente aún tendría que revelar cada semilla en la rotación, y cada ronda bajo ella puede recalcularse. Lo que significa el límite es que una racha sospechosa en las primeras rondas tras un cambio de semilla no puede descartarse solo con el hash; solo puede examinarse, ronda por ronda, después de la revelación.
No puede probar que el juego sea justo en el otro sentido. “Provably fair” significa que la aleatoriedad fue honesta, no que las probabilidades sean equitativas. Un juego de dados puede ser perfectamente verificable y aun así devolver un 99% por diseño; el margen vive en la tabla de pagos, que es un número publicado y una promesa separada. La ética del margen de la casa trata sobre esa promesa. El compromiso guarda silencio al respecto.
No prueba nada sobre las rondas que nadie revisa. El esquema es un disuasivo, no una garantía. Una ronda que nunca recalculas es una ronda que has aceptado por confianza, exactamente igual que en cualquier otro lugar; lo que cambia es que la confianza es opcional, y la casa no puede saber cuándo la ejercerás. Eso es una gran mejora sobre una máquina barajadora en la que no puedes ver por dentro, y una mejora menor de lo que la palabra “prueba” sugiere.
El hash es un recibo de la aleatoriedad. No es un certificado del juego.la frase para recordar
Lo que probaría más
- Una siguiente semilla precomprometida. Publicar el hash de la próxima semilla del servidor antes de que se pueda emparejar con ninguna semilla de cliente cierra el hueco de orden mencionado arriba. Es el único cambio que permitiría al panel probar que la semilla se fijó antes de que se conociera tu entrada.
- Una fuente pública de aleatoriedad. Mezclar una baliza que nadie controla, como la red drand, elimina por completo la pregunta de quién eligió la semilla; dentro de drand describe cómo funciona eso y qué cuesta.
- Una derivación publicada, mantenida pública. Ya es el caso aquí, y la parte que más fácilmente se pierde cuando se reescribe un cliente. El verificador es tan honesto como el código que ejecuta.
Nada de esto cambia lo que es un hash. Cambia de qué es huella dactilar el hash, y cuándo. El esquema es lo bastante simple como para que sus límites también lo sean, y un jugador que conoce las tres cosas que prueba está en mejor posición que uno al que se le ha dicho que lo prueba todo.
Preguntas frecuentes
¿Qué es un compromiso hash en un casino provably fair?
La huella SHA-256 de la semilla secreta del servidor de la casa, mostrada antes de jugar y comprobada contra la semilla cuando se revela. Prueba que la semilla se fijó antes de tus apuestas y que la semilla revelada es la que se comprometió.
¿Un hash coincidente prueba que el juego fue justo?
Prueba que la aleatoriedad no se alteró después del compromiso y, con una derivación publicada, que cada resultado se deriva del par de semillas. No prueba que la semilla se eligiera al azar, y no dice nada sobre el margen de la casa, que es un número publicado separado.
¿Puede la casa elegir una semilla del servidor que la favorezca?
Solo si conoce la semilla del cliente con la que se emparejará la semilla del servidor en el momento de elegirla. La defensa consiste en comprometer la semilla del servidor antes de que se fije la semilla del cliente. En este sitio, un cambio de semilla del cliente rota el par en la misma solicitud, por lo que ese orden no se puede confirmar desde el cliente; el artículo describe el límite y la solución que se ha propuesto.
¿Cómo verifico una ronda yo mismo?
Rota la semilla para revelar la semilla del servidor retirada, calcula su hash para confirmar que coincide con el compromiso que se te mostró, luego vuelve a calcular HMAC-SHA256 de la semilla del servidor sobre tu semilla de cliente, el nonce y el cursor, y pasa el resultado por la derivación publicada del juego. El panel de semillas realiza este recálculo en tu navegador.
¿Por qué es importante el código de derivación?
Porque el hash solo fija la semilla. Convertir la semilla en una tirada o una carta es una función, y a menos que esa función sea pública, un hash coincidente no te dice nada sobre si el resultado fue el que implicaba la semilla. Aquí el cliente incluye la misma derivación que usa la demo para generar resultados.
¿Es el provably fair mejor que una auditoría de RNG licenciada?
Responden preguntas distintas. Una auditoría certifica el comportamiento estadístico de un generador a lo largo de muchas tiradas; un compromiso te permite verificar una ronda específica después de que ocurra. Ninguno reemplaza al otro, y ninguno cambia la ventaja de la casa.
FUENTES Y REFERENCIAS
- Wikipedia — Esquema de compromiso: ocultamiento y vinculación, y compromisos basados en hash
- Wikipedia — HMAC: hashing con clave y su uso como función pseudoaleatoria
- Código fuente del motor Betkyo: _shared/seedApi.ts (compromiso, revelación y rotación), _shared/rng.ts (sha256Hex, hmacSha256Utf8, el uniforme de 7 bytes), _shared/demoLocal.ts (derivación uAt), _shared/SeedPanel.tsx
LOS JUEGOS EN ESTE ARTÍCULODice — reglas y juego gratis →Limbo — reglas y juego gratis →