Integrar números aleatorios verificables en contratos inteligentes es uno de los desafíos más interesantes del desarrollo en Solidity. Aquí se pone en práctica todo el código construido previamente para conectarse con la red de Chainlink VRF, desde la preparación de fondos hasta la ejecución real de una partida con turnos aleatorios en la testnet de Sepolia.
¿Cómo preparar fondos y suscripción en Chainlink para Sepolia?
Antes de hacer deploy del contrato, es necesario contar con fondos en la billetera. El faucet de Chainlink [1:00] es la herramienta recomendada porque entrega dos cosas a la vez:
- ETH de la testnet de Sepolia para pagar gas.
- LINK, el token nativo de Chainlink, que se utiliza para cubrir el costo de cada consulta de números aleatorios.
En redes de prueba este costo no es real, así que se puede experimentar sin riesgo.
Una vez que la billetera tiene saldo, el siguiente paso es crear una suscripción en Chainlink VRF [1:38]. La suscripción funciona como una cuenta prepagada que agrupa los contratos autorizados a solicitar aleatoriedad. Al crearla se obtiene un ID de suscripción (por ejemplo, el 531), dato indispensable para el constructor del contrato.
¿Qué son los consumers y por qué importan?
Dentro de la suscripción existe un apartado llamado consumers [2:15]. Ahí se registran las direcciones de los contratos que van a consumir números aleatorios con cargo a esa suscripción. Como el contrato aún no está desplegado, este paso se completa después del deploy.
También es fundamental cargar balance de LINK [2:40] presionando «add funds». Sin saldo suficiente, las solicitudes de aleatoriedad fallarán.
¿Cómo hacer deploy e interactuar con el contrato en Remix?
En la pestaña de implementación de Remix hay que seleccionar Injected Provider - MetaMask [3:05] para conectarse a Sepolia a través de la billetera. Los datos de la red deben coincidir con la configuración de MetaMask.
El constructor del contrato pide varios parámetros [3:30]:
- La dirección del contrato de achievement.
- La dirección del contrato de moneda.
- El coordinator, una dirección fija que se encuentra en la documentación de Chainlink.
- El ID de suscripción creado en el paso anterior.
Tras confirmar la transacción y esperar la confirmación en la cadena, el contrato aparece desplegado en el panel izquierdo de Remix. En ese momento se copia la dirección y se agrega como consumer en la suscripción de Chainlink [4:15]. Cada escritura en la cadena equivale a una transacción, por lo que hay que confirmar en MetaMask y esperar unos segundos.
¿Cómo funciona la partida con turnos aleatorios?
Con el contrato registrado como consumer, se crea una partida cargando dos direcciones de jugadores [4:55]. La generación del número aleatorio no es instantánea: requiere varias confirmaciones en la red, así que es normal esperar algunos minutos.
Al intentar mover con el jugador uno, el contrato rechaza la transacción [5:25]. Esto indica que la restricción del turno está funcionando correctamente: el número aleatorio favoreció al jugador dos para mover primero. Al cambiar de cuenta en MetaMask al jugador dos, la transacción sí se acepta [5:50].
Después, al volver con el jugador uno y ejecutar un segundo movimiento, la partida avanza sin problemas [6:10]. El flujo queda claro: Chainlink VRF determinó aleatoriamente que el jugador dos arrancaba y luego alternaron turnos.
¿Por qué usar eventos para registrar la aleatoriedad?
Cuando no se controlan ambas cuentas, puede ser difícil saber qué número aleatorio se generó. La solución es el manejo de eventos [6:40], una buena práctica que consiste en emitir información hacia el log del contrato cada vez que se recibe un resultado de Chainlink. Así, cualquier participante puede consultar el evento y verificar el número que determinó el orden de turnos.
Los eventos en Solidity no modifican el estado del contrato, pero quedan registrados de forma permanente en la blockchain, lo que los convierte en una herramienta ideal para trazabilidad y transparencia.
Si todo esto te resultó interesante, un buen ejercicio para profundizar es modificar el contrato para que, cuando un usuario gane, en lugar de recibir una sola moneda, reciba un número aleatorio entre uno y cinco. Comparte tu solución en los comentarios.
