Traducción al español de “Time handling on Cardano, part 2: use cases”
Publicado por Arnaud Bailly en el blog de IOHK el 7 de Diciembre de 2022
Cómo abordan Plutus, Marlowe y Hydra el cronometraje en Cardano
Este artículo ha sido escrito por Arnaud Bailly, Michael Peyton Jones, Sebastian Nagel, Polina Vinogradova y Brian Bush.
La entrada anterior hablaba de cómo Ouroboros gestiona el tiempo en Cardano y explicaba la importancia del determinismo. Aquí hay más sobre casos de uso específicos para el tiempo en Cardano.
¿Cómo manejan el tiempo los scripts Plutus?
Los scripts Plutus tienen acceso al rango de validez de la transacción, definido por su creador. Al definir el rango de validez, un creador puede decidir que una transacción es válida desde el slot X a el slot Y, o dejar uno o ambos de los límites sin definir. Esto impone restricciones sobre en qué slot se puede incluir una transacción, lo que es muy útil en la cadena para definir varios “contratos”.
El script puede asumir que el tiempo real de validación está en este rango. De lo contrario, la transacción fallará en la fase 1 antes de la ejecución del script. Esto asegura el determinismo ya que el script siempre verá la misma pieza de información (el intervalo de validez) independientemente de cuándo se valide el script, por lo que el comportamiento será el mismo.
Los límites del intervalo de validez se expresan en tiempo real (POSIXTime), en lugar de slots, y la conversión de slots a tiempo real se realiza por consenso, como se discutió en el post anterior. Usar tiempo real en lugar de slots es importante porque la longitud de los slots puede cambiar en un hard fork, por lo que las suposiciones basadas en contar slots son generalmente poco fiables. El hecho de que los scripts vean el rango de validez permite a los scripts hacer afirmaciones como ‘el tiempo actual es antes/después de un tiempo dado’, pero no permite a un script hacer ningún otro tipo de afirmación (‘el segundo en el que esta transacción es validada es par’, por ejemplo.)
En el diseño original de Alonzo, el rango de validez cubría todos los usos conocidos del tiempo, al tiempo que encajaba perfectamente con el campo existente de tiempo de vida (TTL). En teoría, es posible aplicar los mismos principios a otros tipos de aserciones, por ejemplo, dejar que la secuencia de comandos se base en las aserciones comprobadas en la fase 1. Sin embargo, esto no sería fácil, ya que implica una profunda estructuración de la secuencia de comandos. Sin embargo, esto no sería fácil ya que implica cambios estructurales profundos en varias partes de la red Cardano. Y como las comprobaciones de la fase 1 tienen que ser válidas para todos los nodos de la red, esto excluye cualquier tipo de aserción que dependa de alguna condición local, como “Hora actual”.
Casos de uso de la hora
El tiempo tiene diferentes aplicaciones en el ecosistema Cardano.
Hydra
El protocolo Hydra depende del tiempo para calcular y hacer cumplir la fecha límite de impugnación, que es una parte crítica del mecanismo de seguridad del protocolo. La máquina de estado Hydra Head rastrea el paso del tiempo utilizando UTCTime, pero el tick procede de la cadena, basándose en el número de slot observado a partir de los bloques producidos por la cadena. La razón de utilizar UTCTime responde a las limitaciones inherentes a la conversión de slot a tiempo que impone la ventana de validez. No se puede convertir un slot demasiado lejos en el futuro, lo que significa que es más sencillo utilizar UTCTime fuera de la cadena y sólo hacer conversiones cuando se envían/reciben 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. Utilizando esta medida de tiempo, Hydra está disponible para reaccionar al cruce de la fecha límite de impugnación relevante para el protocolo.
Lo importante es que el tiempo local en la cabeza de Hydra (y en los nodos) está ligado al tiempo en la cadena manejado por Ouroboros (véase la parte 1 para más detalles). Dado que Hydra es un protocolo isomórfico, es deseable procesar “transacciones cronometradas” también en la capa 2 (véase la cuestión nº 196). Sin embargo, Hydra no produce bloques, por lo que el consenso en sí no necesita una noción de tiempo (todavía).
Para ello es necesario comprender la precisión y el proceso de discretización del tiempo en un libro mayor de capa 2. Aunque las complejidades de la gestión del tiempo en la cadena también se aplican a la capa 2, ésta puede ofrecer mejores soluciones, ya que estas redes son mucho más pequeñas, tienen una vida útil más corta y no necesitan escalarse globalmente.
Si estás interesado en participar en los debates y compartir los tipos de aplicaciones que tienes y el tiempo de resolución que requerirían, únete a este canal Discord de Hydra.
Marlowe
Marlowe es un lenguaje de dominio específico (DSL) para escribir contratos financieros y transaccionales, casi todos los cuales implican tiempo. Una amplia variedad de contratos financieros estándar se han escrito en Marlowe, incluyendo la mayoría de los contratos estándar ACTUS (por ejemplo, préstamos, swaps, opciones y derivados). Además, Marlowe admite una gran variedad de tipos de contratos no financieros, como subastas, intercambios de tokens e incluso juegos. Los mecanismos existentes en Cardano para trabajar con el tiempo encajan a la perfección con la semántica de Marlowe y proporcionan a las transacciones de Marlowe la localidad y el determinismo heredados de Plutus.
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 del tiempo de espera es necesaria en un contrato de préstamo, por ejemplo, para manejar la situación en la que se incumple el pago de un préstamo: entonces es necesario ejecutar una lógica diferente para imponer una penalización, ajustar el calendario de pagos futuros, etc. Los contratos también pueden utilizar directamente los extremos temporales del intervalo de validez en cálculos numéricos, quizás para ajustar los importes de pagos futuros en función de cuándo se recibió un pago anticipado. El hecho de que el tiempo aparezca como un intervalo tiene poco impacto práctico en Marlowe, ya que el intervalo puede ser tan corto como el tiempo que transcurre desde que se envía una transacción hasta que aparece en un bloque de la red de Cardano: sólo unos minutos.
Soluciones
Cardano podría proporcionar datos más precisos relacionados con el tiempo durante la validación de la transacción, como la marca de tiempo del productor del bloque en el que se acuñó el bloque, convertida desde su slot, o incluso la marca de tiempo real en UTC con precisión de milisegundos. Sin embargo, esto rompería el determinismo prospectivo (véase la parte 1) como ocurre en los protocolos que no incluyen esta característica: un usuario ya no podría saber si una transacción puede aplicarse definitivamente al libro mayor o no, porque eso dependería de la marca de tiempo exacta que el productor del bloque utilizó al crear el bloque.
Otra opción es añadir varios tipos de aserción a los cuerpos de las transacciones más allá del intervalo de validez. Esto es posible, pero difícil, como ya se ha señalado, por lo que es necesario que exista un caso de uso para que estos tipos de aserción sean útiles.
Por último, las redes de capa 2, como Hydra, pueden proporcionar una mayor precisión gracias a una “longitud de slot” y un intervalo de validez más cortos, junto con una menor latencia en la finalidad de las transacciones. Obsérvese que la implementación actual de Hydra Head aún no proporciona ese nivel de flexibilidad.
Conclusión
El tiempo es un tema complejo, especialmente en un entorno blockchain descentralizado. Estas entradas de blog muestran que existe una noción clara de tiempo en la cadena en Cardano con restricciones específicas y opciones de mejora disponibles a largo plazo.
El tiempo en la cadena se comporta de forma algo diferente al tiempo en el software tradicional. Esta divergencia se define de forma coherente para hacer frente a las limitaciones del sistema, garantizando al mismo tiempo la seguridad y la facilidad de uso para los usuarios finales y los operadores de stake pool. Además, la medida del tiempo de Cardano parece ser lo suficientemente buena como para cubrir múltiples casos de uso, incluso en comparación con los usos tradicionales de las finanzas.
Únete a los canales de la comunidad de Discord para más discusiones sobre el manejo del tiempo en Cardano y los posibles casos de uso que no se mencionaron en estos posts.