La certificación de un RNG y la verificación provably fair responden a preguntas de confianza diferentes. La certificación analiza si una versión definida del juego y su proceso aleatorio cumplen un estándar de ensayo. La verificación provably fair comprueba si un resultado concreto puede recalcularse con datos comprometidos antes de la apuesta.
La diferencia amplía la guía de FairDealer sobre resultados RNG, en vivo e híbridos y la explicación de RTP, ventaja de la casa y volatilidad. La aleatoriedad determina la ruta del resultado y la tabla de pagos determina su valor. Ni un informe de laboratorio ni un cálculo criptográfico coincidente alteran la ventaja matemática ni prometen ganar.
El resultado recorre varias capas
Un juego de software no suele mostrar el número bruto producido por el generador. El sistema crea datos, los escala al rango necesario, los transforma en cartas, posiciones de rodillos u otro suceso y aplica las reglas y la tabla. Un fallo puede aparecer en cualquiera de esas capas. El generador puede producir buenos datos mientras un mapeado incorrecto introduce sesgo, o una versión certificada puede ser sustituida después por otra distinta.
La especificación técnica española establece que las salidas deben ser independientes, ocupar el intervalo conforme a la distribución prevista, resistir la predicción y no repetir secuencias. El escalado tampoco puede añadir patrones o sesgos. Los sucesos de azar no deben correlacionarse entre jugadas ni ser manipulados para sostener un retorno mínimo.
El RTS 7 de la Gambling Commission sigue la misma ruta desde la salida del RNG hasta el resultado del juego. Exige que las probabilidades observadas correspondan a las teóricas, que la salida futura sea computacionalmente impredecible sin algoritmo y semilla, que las instancias no se sincronicen y que el escalado conserve esas propiedades.
Una muestra breve con números variados no demuestra todo eso. Un generador débil puede parecer mezclado durante un rato y un generador sólido puede estar conectado a una lógica errónea. La evidencia debe alcanzar la implementación utilizada en producción.
La certificación identifica una versión concreta
La prueba independiente parte de un alcance definido. La estrategia británica de ensayos asigna a laboratorios aprobados el análisis estadístico previo al lanzamiento y, según el requisito, la revisión de matemáticas, código fuente, escalado, mapeado y funcionamiento conforme a las reglas.
El estándar GLI-19 describe la revisión del código que controla aleatoriedad, escalado y barajado para buscar sesgos, errores de implementación, código malicioso y comportamientos que corrompan la selección final. También contempla pruebas estadísticas y exige resistencia criptográfica frente a un atacante informado con recursos modernos.
La estadística es una parte del dictamen. Los requisitos de presentación de GLI separan el análisis en revisión del código, análisis estadístico y verificación del software. La conclusión solo se aplica al RNG identificado durante esa verificación. Las firmas de los archivos permiten distinguir la versión ensayada de otra diferente.
La norma española de certificación pide documentar el algoritmo, las bibliotecas utilizadas, el resemillado, el espacio de valores y las pruebas estadísticas. También exige describir tests, simulaciones, parámetros e intervalo de confianza, además de las configuraciones que puedan afectar al funcionamiento.
Por eso un sello sin referencia al informe dice poco. Conviene identificar producto, versión, jurisdicción o estándar, laboratorio, fecha y alcance. Los cambios en el generador, el hardware, la plataforma o un uso no cubierto pueden requerir una nueva revisión.
Provably fair combina compromiso y revelación
Provably fair designa una familia de esquemas criptográficos, no un estándar universal de casino. Un diseño habitual comienza con una semilla secreta del servidor. Antes de jugar, el operador publica un hash que compromete esa semilla sin revelarla. Una semilla de cliente controlada o editable por el jugador y un nonce de la apuesta se combinan con la entrada del servidor. Cuando la semilla se rota y se revela, el jugador puede comprobar el hash y recalcular la salida.
Un ejemplo publicado actualmente es la documentación de implementación de Stake. Indica que sus apuestas verificables utilizan semilla de servidor, semilla de cliente, nonce y cursor con HMAC-SHA256 para generar bytes. El hash previo de la semilla del servidor se contrasta después con la semilla revelada y el nonce cambia en cada apuesta. Es un ejemplo de un operador y no implica que todos los productos con esa etiqueta usen la misma codificación.
HMAC es una herramienta criptográfica estandarizada. NIST FIPS 198-1 la define como un mecanismo de autenticación con clave construido sobre una función hash. El nombre del algoritmo no basta. También deben publicarse la codificación exacta de los datos, el orden de las entradas, el cursor, las reglas de descarte y la conversión de bytes al suceso del juego.
La verificación necesita el registro completo
La comprobación útil comienza antes de apostar. Se necesita el hash comprometido de la semilla del servidor, la semilla del cliente, el nonce y la versión exacta del juego. Cuando el operador revela la antigua semilla, se calcula su hash y se compara con el compromiso previo. Después se ejecuta el algoritmo publicado con las mismas entradas y se aplica la conversión del juego. El suceso recalculado debe coincidir con el historial.
La calculadora del operador es cómoda, aunque por sí sola no aporta independencia. El código abierto o un verificador separado permiten repetir el cálculo sin confiar en la interfaz que mostró la apuesta. Una discrepancia puede proceder de una semilla cambiada, un nonce incorrecto, otra codificación, un cursor no documentado, una regla de conversión o un error al copiar. Conviene conservar el historial original antes de investigar.
La coincidencia del hash demuestra que la semilla revelada corresponde al compromiso anterior, siempre que el hash y el compromiso mostrados sean auténticos. El recálculo demuestra que la transformación publicada produce el resultado registrado con esas entradas. Son comprobaciones precisas, pero limitadas.
Lo que el cálculo no demuestra por sí solo
Una coincidencia no establece automáticamente que la semilla del servidor tuviera entropía suficiente, que todas las apuestas usaran la ruta visible o que la interfaz nunca sustituyera datos. No examina saldos, retiradas, controles de acceso, gestión de cambios ni situación legal. Tampoco demuestra que la tabla de pagos ofrezca una expectativa favorable.
La descripción del propio operador presenta el objetivo como permitir que el resultado se verifique mediante un esquema de compromiso y hashing. Eso delimita la prueba del registro. La garantía más amplia sigue dependiendo de la implementación, el despliegue y los controles operativos. La palabra demostrable debe leerse junto a la proposición exacta que se demuestra.
Un esquema también puede ser reproducible y convertir mal los bytes. Si el mapeado introduce sesgo, descarta valores sin explicarlo o no coincide con las reglas visibles, el verificador reproducirá fielmente el mismo defecto. Publicar la conversión permite revisarla, mientras una certificación puede contrastarla con probabilidades y obligaciones de información.
Las dos formas de evidencia se complementan
La certificación aporta una revisión especializada de un producto acotado. Puede examinar código fuente, comportamiento estadístico, matemáticas, identidad de versión y controles de plataforma que un jugador normalmente no ve. Su límite cotidiano es que el jugador no puede repetir el trabajo completo del laboratorio para una apuesta concreta.
Provably fair ofrece una comprobación estrecha y accesible de un registro concreto. Puede hacer detectable la sustitución posterior de una semilla o un cálculo incoherente cuando el esquema es completo. Su límite es el alcance, porque observa la ruta publicada y no todas las propiedades regulatorias y operativas del juego.
La lectura más sólida no sustituye una etiqueta por la otra. Hay que identificar la versión certificada, comprobar que laboratorio e informe existen, leer algoritmo y conversión, guardar el compromiso previo y verificar un ciclo de semilla terminado con código independiente cuando sea posible. Si faltan entradas esenciales o la revelación, la prueba anunciada no puede completarse.
Ningún método anticipa el siguiente resultado. La certificación respalda la confianza en un sistema ensayado y la verificación criptográfica puede revelar incoherencias en un cálculo registrado. Sirven para revisar el proceso, no para vencer la probabilidad ni recuperar pérdidas.
