Qué hace que una lotería Web3 sea verificablemente justa

Una lotería puede utilizar buena aleatoriedad y excluir entradas válidas. También puede registrar a todos los participantes y cambiar el método de selección después de conocer el valor aleatorio.

Incluso puede identificar correctamente al ganador mientras el premio anunciado sigue siendo una promesa.

Por eso, «registrado en una blockchain» no significa «justo». La red puede conservar datos producidos por un proceso débil o manipulado.

Una revisión útil pregunta qué decisiones se fijaron antes de la participación, quién podía cambiarlas y qué datos permiten reproducir el resultado.

Reglas y plazo

La elegibilidad, el precio de entrada, los límites de boletos, el plazo, el número de ganadores y las condiciones del premio deben conocerse de antemano.

También deben explicarse los cambios permitidos y las condiciones de cancelación.

Conjunto de participantes

El sistema necesita reglas claras para aceptar entradas y un momento definido para cerrar el conjunto.

Después del cierre, el operador no debería poder añadir, eliminar o reordenar entradas en secreto cuando eso afecte al resultado.

Condiciones y custodia del premio

Los participantes deben saber cuál es el premio y quién lo controla. Un activo custodiado por un contrato, otro en poder del organizador y una promesa futura requieren pruebas distintas.

El registro de un ganador muestra quién fue seleccionado. No demuestra por sí solo que un premio externo exista o vaya a entregarse.

Solicitud de aleatoriedad

La solicitud debe estar vinculada al evento correcto y al conjunto de participantes fijado. El resultado debe ser impredecible antes de generarse y verificable después.

Método de selección

La regla que relaciona la salida aleatoria con un boleto o participante debe fijarse antes de conocerla.

El escalado, los reintentos y los valores no válidos también necesitan reglas para impedir que se conserve solo un resultado favorable.

Resultado y entrega del premio

Los datos publicados deben conectar las reglas, las entradas, la respuesta aleatoria, el método de selección y el ganador.

La entrega del premio debe mostrarse por separado para no presentar selección y entrega como una sola prueba.

1. Publicar las reglas, el plazo, las condiciones del premio y el método de selección.
2. Aceptar entradas según esas reglas.
3. Cerrar la participación y conservar el conjunto definitivo.
4. Solicitar aleatoriedad vinculada al evento correcto.
5. Verificar la respuesta en lugar de confiar en un número proporcionado por el operador.
6. Aplicar la regla de selección fijada de antemano.
7. Publicar el resultado y mostrar la entrega del premio como un estado separado.

Distintos sistemas pueden implementar este proceso de forma diferente. Lo importante es mantener unida la cadena de pruebas desde la primera entrada hasta el resultado final.

Una VRF produce un resultado acompañado de una prueba que se comprueba con una clave pública y unos datos de entrada definidos. RFC 9381 describe los algoritmos de verificación y las propiedades de unicidad de las VRF.

El estándar RTS 7 de la Comisión de Juego británica no es una regla universal para Web3, pero ofrece una referencia externa útil. Exige reglas disponibles antes del juego, resultados impredecibles y una relación coherente entre las entradas aleatorias y el resultado.

Una prueba VRF válida no muestra si el conjunto de participantes era correcto, si el premio existe o si el método de selección se eligió de forma justa. Esas afirmaciones necesitan pruebas separadas.

Conviene desconfiar cuando:

• un servidor elige al ganador y publica solo la dirección final;
• las entradas pueden modificarse después del plazo;
• el operador puede descartar una respuesta aleatoria y pedir otra;
• el método de selección no está publicado o cambia después de la respuesta;
• el premio se describe sin aclarar quién lo controla;
• los permisos administrativos permiten cambiar datos importantes sin dejar un rastro visible;
• la interfaz muestra el resultado, pero no los datos necesarios para reproducirlo.

Guardar el valor final en un contrato inteligente no corrige por sí solo ninguno de estos problemas.

Antes de considerar que una lotería es verificablemente justa, pregunta:

• ¿Se publicaron las reglas y el plazo antes de la participación?
• ¿Puedo determinar qué entradas se incluyeron?
• ¿Se cerró el conjunto antes de solicitar aleatoriedad?
• ¿Está identificado el premio y queda claro quién lo controla?
• ¿La respuesta aleatoria está vinculada al evento correcto?
• ¿La respuesta puede verificarse de forma independiente?
• ¿El método de selección se fijó de antemano?
• ¿Alguien puede descartar un resultado desfavorable y repetir la solicitud?
• ¿La selección y la entrega del premio aparecen como estados distintos?

Una respuesta poco clara no siempre demuestra fraude. Sí indica dónde la afirmación de justicia todavía depende de la confianza.

ElyxS utiliza Supra dVRF para la aleatoriedad de los sorteos. Antes de calcular el resultado, el contrato inteligente verifica la respuesta y la vincula con la solicitud, el sorteo y la ronda esperados.

Este ejemplo cubre una sola parte del modelo: una respuesta aleatoria se rechaza si no corresponde a la solicitud registrada. La prueba VRF no sustituye los datos sobre participantes o premios.

Consulta Verificar resultados de sorteos para el recorrido de usuario y Contratos inteligentes para el modelo conceptual de los contratos.

• Comisión de Juego británica: RTS 7 — reglas previas, impredecibilidad, método de selección y presentación del resultado.
• RFC 9381 sobre las VRF — algoritmos y propiedades de seguridad de las funciones aleatorias verificables.
• Consideraciones de seguridad de Solidity — dificultad de la aleatoriedad cuando el constructor del bloque puede influir en el proceso.
• Descripción general de Supra dVRF — modelo general de aleatoriedad verificable utilizado en el ejemplo de ElyxS.