Últimamente me he estado preguntando acerca de establecer retrasos después de la inicialización y resolución para evitar que ocurra más de una sola transacción.
Todavía tengo que darle a los documentos una lectura lo suficientemente completa, pero estoy pensando en algo como
contract GameStake {
adress public playerOne;
address public playerTwo;
delay(15) {
//delayed execution, sends payment after 15 blocks of initialization.
...
}
}
Gracias.
Sería técnicamente posible incluir retrasos utilizando el número de bloque o la marca de tiempo. Es innecesariamente incómodo hacer que el contrato "despierte" en el futuro. Los clientes pueden retirar ganancias y el contrato puede verificar su derecho, posiblemente con un ojo en el reloj.
Hablar en abstracto hace que sea un poco complicado ser preciso, así que hablemos de piedra, papel o tijera. Supongamos que cada jugador coloca una apuesta para cada ronda.
La siguiente descripción se basa en la suposición de que hay un Dapp fácil de usar que oculta todos los detalles de la transacción de los usuarios... para que puedan jugar el juego.
El sistema puede saber que hay un ganador después de realizar dos apuestas. Un problema no obvio es que todo en la cadena de bloques es visible para un adversario determinado . Significa que un jugador puede hacer trampa a menos que el "piedra, papel o tijera" se almacene de forma encriptada. Durante la fase de apuestas, todo está oculto.
Cuando se hayan realizado todas las apuestas, la ronda entraría en la fase de liquidación.
Los clientes revelaban los secretos que usaban para codificar sus apuestas (para la ronda 123, mi secreto era 0x123). El contrato verificaría que el secreto sea correcto y que la información registrada se descifre correctamente en "piedra, papel o tijera".
El contrato determinaría al ganador inmediatamente.
El ganador deberá reclamar su premio. De esa manera, proporcionan el gas para la transmisión. Esta función comprobaría la legitimidad de la reclamación.
En la fase de liquidación, es posible que un mal perdedor decidido (y barato) se abstenga del exiguo costo de la gasolina para registrarse si pudiera determinar que perdió (factible). Eso se puede resolver con una regla que estipula que pierden la ronda si no se registran después de unos pocos bloques.
Podemos imaginar una interfaz de usuario que juega el juego de forma continua, con rondas anteriores en estados establecidos o de espera. Generalmente, el pago sería inmediato. Cuando participan jugadores deshonestos, causan un breve retraso en la resolución de rondas específicas; siempre finalmente resuelto.
Espero eso ayude.
El contrato Ethereum Alarm Clock le permite programar llamadas de función para un bloque específico en el futuro. No depende de un oráculo externo para hacerlo, aunque sí requiere que conozca todos los detalles de la transacción en el momento de la programación.
La documentación, con ejemplos, está aquí . Si prefiere usar la biblioteca de JavaScript , puede encontrar un tutorial aquí.
El principio básico es que una función de contrato solo puede ejecutarse si alguna parte externa la llama. Los retrasos son administrados hoy por oráculos (parte externa que observa eventos específicos y llama a su contrato a través de una interfaz predefinida que usted implementa. Esto solo existe en la cadena de bloques pública y no en la privada. A menos que los vuelva a implementar)
No existe (hasta donde yo sé) un mecanismo para que una función de contrato envíe una transacción de forma asíncrona y la extraiga en un bloque futuro. Eso habría permitido llamar a su propio contrato y hasta que no se alcance el número de bloque, llamar asíncrono nuevamente). Tal vez en una versión posterior de Ethereum del EVM
Entonces, por el momento, la forma más sencilla es inicializar su contrato con las apuestas, los participantes y la marca de tiempo futura. Y desde el exterior, llame al contrato regularmente para verificar si se alcanza el tiempo y luego llame al código de demora posterior.
Buena suerte
Rob Hitchens
dakota quint