Qué es una VRF en blockchain y por qué la aleatoriedad suele ser poco fiable sin ella

Los nodos deben producir el mismo estado cuando procesan la misma operación. Un generador local que devolviera un valor distinto a cada nodo rompería ese acuerdo.

Por eso, un contrato inteligente necesita una fuente de aleatoriedad externa o integrada en el protocolo. El resultado debe ser suficientemente impredecible antes de revelarse y verificable después.

Las propiedades públicas de un bloque no deben considerarse automáticamente una fuente segura.

La guía de seguridad de Solidity advierte de que la aleatoriedad es difícil cuando el constructor del bloque puede influir en el proceso.

Aplicar un hash a datos públicos tampoco crea impredecibilidad. Si las direcciones, los números de bloque y las demás entradas se conocen de antemano, cualquiera puede repetir el cálculo y evaluar el resultado.

Un servidor puede generar un número aleatorio de buena calidad, pero sin una prueba verificable los usuarios deben confiar en el operador. El problema no es el servidor en sí, sino la falta de verificación independiente.

RFC 9381 describe una VRF como la versión con clave pública de un hash criptográfico con clave. Solo quien posee la clave secreta puede calcular el resultado, pero cualquiera con la clave pública puede verificarlo.

El flujo simplificado es el siguiente:

1. La aplicación fija los datos de entrada para un evento concreto.
2. El titular de la clave o una red distribuida calcula un resultado y una prueba.
3. La parte verificadora comprueba la clave pública, los datos de entrada y la prueba.
4. La aplicación acepta el resultado solo si la verificación es correcta.

Para una clave pública y unos datos de entrada fijos, una VRF correcta vincula una prueba válida con un único resultado. Obtener otro resultado con una prueba válida debería ser computacionalmente inviable.

Para quien no conoce la clave secreta, el resultado parece aleatorio bajo los supuestos del esquema elegido. El titular de la clave puede calcularlo, así que la impredecibilidad no es absoluta para todos los participantes.

Sin una prueba, la aplicación recibe un número y la promesa de que se eligió de forma justa. Con una VRF, recibe un número, una prueba y un procedimiento formal para verificarlo.

La prueba solo se aplica a una entrada y una clave concretas. La aplicación debe definir qué solicitud se verifica y cómo se transforma el valor aleatorio en la selección final.

Por ejemplo, la regla para elegir al ganador debe fijarse antes de recibir la aleatoriedad y no debe introducir un sesgo sistemático. Una VRF no corrige un algoritmo defectuoso o modificable.

Una VRF distribuida, o dVRF, reparte el cálculo entre varios participantes.

La guía de arquitectura de Supra dVRF describe un diseño de umbral que combina cálculos parciales.

Este modelo reduce la dependencia de un único titular de la clave dentro de los supuestos criptográficos y de red declarados. A cambio, requiere más coordinación y complejidad de cálculo.

Una VRF protege una capa del sistema: la generación y verificación de un resultado aleatorio. No demuestra automáticamente que un sorteo u otro proceso sea justo en su conjunto.

También hay que comprobar:

• si las reglas se fijaron antes de que comenzara la participación;
• quién eligió los datos de entrada y cuándo;
• si el conjunto de participantes respeta las condiciones publicadas;
• cómo se transforma el valor aleatorio en una selección;
• si alguien puede ocultar una respuesta y solicitar otra;
• si el premio prometido existe;
• si se cumplen las reglas de custodia y entrega.

Incluso una prueba válida no impide manipular los datos de entrada, elegir estratégicamente el momento de la solicitud u ocultar una respuesta desfavorable. El diseño de la aplicación debe limitar esos riesgos.

Imagina una máquina de sorteo que entrega un número y un recibo criptográfico. El recibo permite comprobar que el número está vinculado a la entrada y la clave acordadas.

No demuestra que la lista de participantes estuviera completa, que el premio existiera o que las reglas no cambiaran. Una VRF hace verificable el resultado aleatorio, pero no sustituye la verificación del resto del proceso.

En ElyxS, la aleatoriedad del resultado de un sorteo llega mediante Supra dVRF. Antes de utilizarla, el contrato inteligente verifica la respuesta y la vincula con la solicitud, el sorteo y la ronda esperados.

Es un ejemplo de rechazo de una respuesta no verificada. No significa que la VRF demuestre por sí sola el conjunto de participantes, las condiciones del premio, la custodia del activo o su entrega al ganador.

La ruta práctica se explica en Verificar resultados de sorteos. El modelo general de los contratos se describe en Contratos inteligentes.

La aleatoriedad verificable importa cuando un resultado distribuye valor o derechos y los participantes tienen incentivos para influir en él:

• loterías y sorteos;
• atributos y rareza de NFT;
• recompensas y emparejamiento en juegos;
• selección aleatoria de participantes o solicitudes;
• protocolos donde la aleatoriedad afecta al acceso o al orden de las acciones.

Cuanto más valioso sea el resultado, más importante es verificar no solo la fuente de aleatoriedad, sino también los datos de entrada, la regla de selección y la ejecución posterior.

• RFC 9381 sobre las VRF — definición, algoritmos de verificación y propiedades de seguridad.
• Consideraciones de seguridad de Solidity — por qué la aleatoriedad en los contratos inteligentes exige precaución.
• Descripción general de Supra dVRF — objetivo de Supra dVRF y modelo general de verificación.
• Guía de arquitectura de Supra dVRF — arquitectura de umbral, verificación y costes de cálculo.