- Cardano está trabajando para aportar una solución eficaz a la gestión del tiempo en la cadena basada en el rango de validez y el rango de ranura.
- Así es como los contratos inteligentes y las soluciones de escalabilidad como Plutus, Marlowe e Hydra pueden gestionar esto de forma eficaz.
La cadena de bloques Cardano publicó recientemente informes detallados sobre la gestión del tiempo realizada por el protocolo de consenso Ouroboros. El protocolo propaga los bloques acuñados a todos los nodos del sistema, de manera oportuna. Como resultado, el tiempo requiere la construcción de una representación globalmente aceptable para el consenso.
En la última entrada del blog, el grupo matriz de Cardano, Input Output Global (IOHK), explica cómo los scripts de Plutus pueden gestionar el tiempo de forma eficaz. Los scripts Plutus tendrán acceso al rango de validez de la transacción definido por su creador.
El creador obtiene la flexibilidad para definir el rango de validez de tal manera que cualquier transacción será válida desde la ranura X a la ranura Y. Dejará uno o ambos límites sin definir. Pero también conlleva las restricciones de incluir una transacción en una ranura concreta. El anuncio oficial señala:
El script puede asumir que el tiempo real de validación está en este rango. En caso contrario, la transacción fallará en la fase 1 antes de la ejecución del script. Esto garantiza el determinismo, ya que el script siempre verá la misma información (el intervalo de validez) independientemente de cuándo se valide, por lo que el comportamiento será el mismo.
Los límites del intervalo de validez ocurren en tiempo real (POSIXTime), en lugar de ranuras. Además, la conversión de slots a tiempo real se produce a través de un consenso. Cardano explica que el uso de tiempo real en lugar de ranuras es importante ya que la longitud de las ranuras puede cambiar en un hardfork. Por lo tanto, las suposiciones basadas en ranuras son más o menos poco fiables.
Casos de uso de la gestión del tiempo en Hydra y Marlowe
Para calcular y hacer cumplir su plazo de impugnación, el protocolo Hydra depende del mecanismo de seguridad. Mediante UTCTime, la máquina de estado de la cabeza de Hydra realiza un seguimiento del paso del tiempo. Sin embargo, el tick final procede de la cadena basado en el número de ranura observado a partir de los bloques producidos por la cadena.
Al utilizar UTCTime, Hydra aborda las limitaciones inherentes a la conversión de ranura a tiempo impuesta por la ventana de validez. El anuncio señala:
No se puede convertir una ranura demasiado lejos en el futuro, lo que significa que es más sencillo utilizar UTCTime fuera de la cadena y sólo hacer conversiones al enviar/recibir transacciones hacia o desde la cadena. Esto implica que la granularidad del tick es de aproximadamente 20s, ya que ésta es la frecuencia esperada con la que se producen los bloques.
Como resultado, Hydra puede reaccionar al cruce de la fecha límite de impugnación relevante para el protocolo.
Por otro lado, Marlowe es un lenguaje específico de dominio encargado de escribir contratos financieros y transaccionales. También admite tipos de contratos no financieros, como intercambios de tokens, subastas e incluso juegos. El mecanismo de gestión del tiempo de Cardano encaja perfectamente con la semántica de Marlowe. Ofrece transacciones Marlowe con localidad combinada con el determinismo heredado de Plutus.
Notas de Cardano: En Marlowe, el tiempo del contrato suele aparecer en los plazos y tiempos de espera que limitan cómo evoluciona la ejecución del contrato, y esto funciona perfectamente con los intervalos de validez de Cardano. La lógica de tiempo de espera es necesaria en un contrato de préstamo, por ejemplo, para manejar la situación en la que un pago del préstamo se pierde: entonces se necesita ejecutar una lógica diferente para imponer una penalización, ajustar el calendario de pagos futuros, etc.
La solución
Durante la validación de las transacciones, Cardano busca proporcionar datos más precisos relacionados con el tiempo, que incluyen la marca de tiempo del productor del bloque en el que se acuñó el bloque. También puede mostrar la marca de tiempo real en UTC con una precisión de milisegundos.
Pero esto rompería el determinismo de protección en protocolos que ya no incluyen esta característica. Otra opción sería añadir varios tipos de aserción a los cuerpos de las transacciones más allá del intervalo de validez. Aunque es posible, sería difícil de implementar.
En última instancia, las redes de capa 2 como Hydra pueden proporcionar la máxima precisión mediante un intervalo de validez y un intervalo de ranura más cortos. Esto ocurriría junto con la disminución de la latencia en la finalidad de las transacciones.
