Manipulação de tempo no Cardano, parte 2: casos de uso

Blog > 2022 > Dezembro > Controle de tempo em Cardano, parte 2: casos de uso

Manipulação de tempo no Cardano, parte 2: casos de uso

Como Plutus, Marlowe e Hydra abordam a cronometragem em Cardano

7 de dezembro de 2022 - Arnaud Bailly - 6 minutos de leitura

Esta postagem no blog foi escrita por Arnaud Bailly, Michael Peyton Jones, Sebastian Nagel, Polina Vinogradova e Brian Bush.

O post anterior discutiu como Ouroboros lida com o tempo em Cardano e explicou a importância do determinismo. Aqui está mais sobre casos de uso específicos para o tempo na Cardano.

Como os scripts Plutus lidam com o tempo?

Os scripts Plutus têm acesso ao intervalo de validade da transação, definido pelo seu criador. Ao definir o intervalo de validade, um criador pode decidir que uma transação é válida do slot X ao slot Y ou deixar um ou ambos os limites indefinidos. Isso impõe restrições em qual slot uma transação pode ser incluída, o que é muito útil na cadeia para definir vários ‘contratos’.

O script pode assumir que o tempo real de validação está neste intervalo. Caso contrário, a transação falhará na fase 1 antes da execução do script. Isso garante o determinismo, pois o script sempre verá a mesma informação (o intervalo de validade), independentemente de quando o script for validado, portanto, o comportamento será o mesmo.

Os limites do intervalo de validade são expressos em tempo real (POSIXTime), ao invés de slots, e a conversão de slots para tempo real é feita por consenso, conforme discutido no post anterior. Usar tempo real em vez de slots é importante porque os comprimentos dos slots podem mudar em um hard fork, então suposições baseadas na contagem de slots geralmente não são confiáveis. O fato de os scripts verem o intervalo de validade permite que os scripts façam afirmações como ‘o horário atual é antes/depois de um determinado horário’, mas não permite que um script faça qualquer outro tipo de afirmação (‘o segundo em que esta transação é validado é par’, por exemplo.)

No projeto original de Alonzo, o intervalo de validade cobria todos os usos conhecidos do tempo, ao mesmo tempo em que se ajustava perfeitamente ao campo de tempo de vida (TTL) existente. Em teoria, é possível aplicar os mesmos princípios a outros tipos de asserções, por exemplo – deixar o roteiro contar com asserções verificadas na fase 1. No entanto, isso não seria fácil, pois implica em profundas mudanças estruturais em várias partes da Cardano rede. E como as verificações da fase 1 precisam ser válidas para todos os nós da rede, isso exclui qualquer tipo de afirmação que dependa de alguma condição local, como ‘Hora atual’.

Casos de uso para tempo

O tempo tem diferentes aplicações no ecossistema Cardano.

Hydra

O protocolo Hydra depende do tempo para calcular e aplicar o prazo de contestação, que é uma parte crítica do mecanismo de segurança do protocolo. A máquina de estado Hydra Head rastreia a passagem do tempo usando UTCTime, mas o tick vem da cadeia, com base no número do slot observado nos blocos produzidos pela cadeia. A razão para usar o UTCTime aborda as limitações inerentes à conversão de slot para time que a janela de validade impõe. Não se pode converter um slot muito longe no futuro, o que significa que é mais simples usar UTCTime fora da cadeia e fazer conversões apenas ao enviar/receber transações para ou da cadeia.

Isso implica que a granularidade do tick é de aproximadamente 20s, pois essa é a frequência esperada na qual os blocos são produzidos. Usando essa medida de tempo, a Hydra está disponível para reagir ao cruzamento do prazo de contestação relevante para o protocolo.

O que é importante é que a hora local no Hydra Head (e nós) está ligada ao tempo on-chain manipulado por Ouroboros (veja a parte 1 para mais detalhes). Como Hydra é um protocolo isomórfico, é desejável processar ‘transações cronometradas’ também na camada 2 (consulte o problema #196 ). No entanto, Hydra não produz blocos, então o consenso em si não precisa de uma noção de tempo (ainda).

Isso requer uma compreensão da precisão e do processo de discretização do tempo em um registro de camada 2. Embora as complexidades de lidar com o tempo na cadeia também se apliquem à camada 2, a camada 2 pode fornecer soluções melhores, pois essas redes são muito menores, têm uma vida útil mais curta e não precisam ser dimensionadas globalmente.

Se você estiver interessado em se envolver em discussões e compartilhar os tipos de aplicativos que você possui e o tempo de resolução que eles exigem, participe deste canal Hydra Discord .

Marlowe

Marlowe é uma linguagem específica de domínio (DSL) para redigir contratos financeiros e transacionais, quase todos envolvendo tempo. Uma grande variedade de contratos financeiros padrão foi escrita em Marlowe, incluindo a maioria dos contratos padrão ACTUS (por exemplo, empréstimos, swaps, opções e derivativos). Além disso, a Marlowe suporta uma variedade de tipos de contratos não financeiros, como leilões, trocas de tokens e até mesmo jogos. Os mecanismos existentes da Cardano para trabalhar com o tempo se encaixam perfeitamente na semântica de Marlowe e fornecem às transações de Marlowe localidade e determinismo herdados de Plutus.

Em Marlowe, o tempo do contrato normalmente aparece nos deadlines e timeouts que condicionam a evolução da execução do contrato, e isso funciona perfeitamente com os intervalos de validade da Cardano. A lógica de tempo limite é necessária em um contrato de empréstimo, por exemplo, para lidar com a situação em que o pagamento de um empréstimo não é pago: então, uma lógica diferente precisa ser executada para impor uma penalidade, ajustar o cronograma de pagamentos futuros etc. usar diretamente os pontos finais de tempo do intervalo de validade em cálculos numéricos, talvez para ajustar valores de pagamentos futuros com base em quando um pagamento antecipado foi recebido.

Soluções

A Cardano poderia potencialmente fornecer dados relacionados ao tempo mais precisos durante a validação da transação, como o timestamp do produtor do bloco no qual o bloco foi cunhado, convertido de seu slot ou até mesmo o timestamp real em UTC com precisão de milissegundos. No entanto, isso quebraria o determinismo prospectivo (consulte a parte 1) como acontece com os protocolos que não incluem esse recurso: um usuário não poderia mais dizer se uma transação pode definitivamente se aplicar ao livro-razão ou não, porque isso dependeria do registro de data e hora exato que o produtor do bloco usou ao criar o bloco.

Outra opção é adicionar vários tipos de asserção aos corpos da transação além do intervalo de validade. Isso é possível, mas difícil como já descrito anteriormente, portanto, deve haver um caso de uso para que esses tipos de asserção sejam úteis.

Por fim, as redes da camada 2, como a Hydra, podem fornecer maior precisão por meio de um ‘comprimento de slot’ mais curto e um intervalo de validade mais curto, juntamente com a diminuição da latência na finalização das transações. Observe que a implementação atual do Hydra Head ainda não fornece esse nível de flexibilidade.

Conclusão

O tempo é um tópico complexo, especialmente em uma configuração de blockchain descentralizada. Essas postagens de blog mostram que há uma noção clara de tempo on-chain em Cardano com restrições específicas e opções de melhoria disponíveis a longo prazo.

O tempo on-chain se comporta de maneira um pouco diferente do tempo no software tradicional. Essa divergência é definida de maneira consistente para atender às restrições do sistema, garantindo a segurança e a usabilidade para usuários finais e operadores de grupos de participação. Além disso, a medida de tempo de Cardano parece ser boa o suficiente para cobrir vários casos de uso, mesmo quando comparada aos usos financeiros tradicionais.

Junte -se aos canais da comunidade Discord para mais discussões sobre gerenciamento de tempo na Cardano e possíveis casos de uso que não foram mencionados nessas postagens.