Manipulação de Tempo no Cardano

O tempo é necessariamente relativo para cada participante no sistema blockchain e é crucialmente importante para apoiar e manter as propriedades de segurança do protocolo de consenso Ouroboros. Os blocos emitidos devem ser propagados para todos os nós do sistema de forma oportuna, então o tempo requer a construção de uma representação globalmente aceitável para que o consenso seja alcançado.

Manipulação de Tempo com Ouroboros

Localmente, um nó calcula a passagem do tempo usando um sistema de 'relógio de parede'. O código para este relógio é complicado porque o comprimento do slot pode variar em um limite de hard fork, então o tempo deve ser calculado cuidadosamente levando isso em consideração.

O código executa quatro etapas para obter o currentSlot:

1. Espera por algum atraso correspondente ao tempo restante até o próximo slot, ou um atraso arbitrário de 60s se o slot atual for desconhecido, o que acontece durante a sincronização.
2. Obtém o tempo atual do sistema e o traduz para um número de slot de acordo com o comprimento do slot para a era atual.
3. Se o novo slot for maior que o anterior, ele 'tiqueta' um novo slot atual.
4. Se o acima não for verdadeiro, ele espera um pouco mais ou relata um erro se o tempo atual tiver retrocedido muito longe.

O currentSlot local é comparado com o slot relatado pela ponta do livro-razão do nó. Se este último for mais antigo, ele é ignorado porque isso significa que o nó está sincronizando seu estado com a cadeia.

Como o comprimento do slot pode mudar em um hard fork, o consenso só pode converter slots em tempo até um ponto fixo no futuro - a 'janela de estabilidade' - na qual nenhum hard fork pode ocorrer. Na prática, a janela de estabilidade é essencial, pois fornece uma medida de tempo necessária para garantir a finalidade da transação e a imutabilidade do estado da cadeia. Durante a janela de estabilidade, a rede deve produzir pelo menos k blocos, onde k é o número de blocos após os quais a cadeia se torna imutável. A janela de estabilidade pode levar até 3k/f, que é 36 horas com os parâmetros atuais, ou aproximadamente um dia.

Desafios Atuais

Há uma limitação física fundamental para a velocidade com que as informações podem viajar: a velocidade da luz. Isso implica que sincronizar o tempo em uma rede de nós leva tempo.

O Protocolo de Tempo de Rede (NTP) existe para fornecer um mecanismo de sincronização, que aborda as limitações de tempo e as diferenças de medição. Por outro lado, o NTP não garante um aumento monotônico: o tempo às vezes pode avançar e retroceder alguns segundos ou até horas. Os sistemas existentes que fornecem relógios precisos, precisos e confiáveis em escala global são centralizados, como o relógio global fornecido pelo Spanner, por exemplo.

Atualmente, no Cardano:

1. Os parâmetros de rede são definidos de forma que a granularidade dos intervalos de tempo observáveis (por exemplo, tempo de bloco) na cadeia seja de 20s, que é igual ao comprimento do slot (1s) dividido pelo coeficiente de bloco f (a frequência de bloco esperada, 0.05). Esses parâmetros provavelmente não mudarão no futuro próximo.
2. Esses 20 segundos foram determinados como o orçamento ótimo para garantir a segurança do protocolo, dadas as restrições para replicar novas transações e blocos pela rede (atraso TCP de 300ms em todo o mundo, com milhares de nós). Embora a taxa de transferência de blocos possa aumentar no futuro, é improvável que reduza a granularidade do tempo observável na cadeia.
3. A finalidade da transação pode ser alcançada em aproximadamente um dia, e não pode ocorrer em menos de um dia, de acordo com o design de consenso Ouroboros. Note que, embora um alto nível de confiança já seja alcançado em questão de minutos ou horas, a probabilidade de um bloco ser descartado definitivamente diminui exponencialmente com sua profundidade e o número de nós que precisam adotar esse bloco.

Finalmente, a longo prazo, o atual protocolo Ouroboros está planejado para ser substituído por Ouroboros Chronos. Ouroboros Chronos aborda os desafios de manutenção do tempo, fornecendo a primeira fonte de tempo criptográfica de alta resiliência baseada em blockchain.

A Importância do Determinismo em um Ambiente Blockchain

No contexto atual, determinismo significa que uma transação dada tem um 'efeito fixo' no estado do livro-razão. Mas é importante distinguir entre os conceitos de determinismo histórico e prospectivo.

As blockchains são baseadas no princípio de replicar uma sequência fixa de transações (agrupadas em blocos) para alcançar um consenso sobre o estado do mundo. Todas as blockchains têm determinismo histórico, o que significa que transações na cadeia têm um efeito fixo, caso contrário, os resultados da validação da cadeia seriam não determinísticos, o que quebraria o consenso.

Mas poucas blockchains têm determinismo prospectivo, o que significa que uma transação que ainda não foi adicionada à cadeia tem um efeito fixo (ou não se aplica). O Cardano possui determinismo prospectivo (com a exceção atual dos endereços de ponteiro, que são propostos para serem removidos neste CIP). Você também pode descobrir mais sobre o determinismo do custo da transação do Cardano aqui.

Em blockchains que não possuem determinismo prospectivo, os usuários não podem saber quanto precisam pagar de taxas de gás para transações, o que resulta em tais usuários pagando em excesso por transações. A falta de determinismo prospectivo também é a razão pela qual existe o risco de uma transação nessas blockchains falhar enquanto consome muitos gases.

O poder do determinismo prospectivo

O determinismo prospectivo é uma característica muito poderosa do Cardano, por várias razões:

• Os usuários sabem, antecipadamente, o que uma transação fará, então não há surpresas. Isso é particularmente relevante para scripts porque os usuários sabem exatamente:

  • como os scripts se comportarão, e
  • quanto orçamento de execução é necessário.

• As transações propostas podem ser processadas com segurança em paralelo. Esse paralelismo é uma das razões para a velocidade do Hydra.

• Como os usuários sabem antecipadamente se uma transação falhará ou não, falhas de script podem ser punidas severamente (porque nunca acontecerão com usuários não maliciosos)

• De modo geral, torna a interação com e a evolução da blockchain mais fácil e previsível.

O determinismo prospectivo de transações requer que cada parte da validação da transação, incluindo a execução do script, seja completamente determinística. É por isso, em última análise, que o Cardano não pode ter operações não determinísticas em scripts.

Uma das formas de obter determinismo prospectivo é fazendo com que o efeito de uma transação seja inteiramente determinado pela própria transação e pelas saídas que ela referencia. No contexto do Cardano, isso é chamado de localidade. A localidade também é de grande benefício para os usuários, pois significa que qualquer pessoa pode saber o que uma transação faz apenas olhando para a transação.

Como os scripts Plutus lidam com o tempo?

Os scripts Plutus têm acesso ao intervalo de validade da transação, definido por 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 sobre 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, já que o script sempre verá a mesma informação (o intervalo de validade), independentemente de quando o script for validado, então o comportamento será o mesmo.

Os limites do intervalo de validade são expressos em tempo real (POSIXTime), em vez de slots, e a conversão de slots para tempo real é feita por consenso, como discutido no post anterior. Usar o tempo real em vez de slots é importante porque o comprimento do slot pode mudar em um hard fork, então suposições baseadas na contagem de slots geralmente são pouco confiáveis. O fato de os scripts verem o intervalo de validade permite que os scripts façam afirmações como 'o tempo atual está antes/depois de algum tempo dado', mas não permite que um script faça qualquer outro tipo de afirmação ('o segundo no qual esta transação é validada é par', por exemplo).

No design original do Alonzo, o intervalo de validade cobria todos os usos conhecidos do tempo, enquanto também se encaixava perfeitamente com o campo de tempo para viver (TTL) existente. Em teoria, é possível aplicar os mesmos princípios a outros tipos de afirmações, por exemplo - deixe o script depender de afirmações verificadas na fase 1. No entanto, isso não seria fácil, pois implica mudanças estruturais profundas em várias partes da rede Cardano. E porque as verificações da fase 1 precisam ser válidas para cada nó em toda a rede, isso exclui qualquer tipo de afirmação que dependa de alguma condição local, como 'Tempo 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 impor o prazo de contestação, que é uma parte crítica do mecanismo de segurança do protocolo. A máquina de estado do Hydra Head rastreia a passagem do tempo usando UTCTime, mas o tick vem da cadeia, com base no número de slot observado nos blocos produzidos pela cadeia. O motivo de usar UTCTime aborda as limitações inerentes à conversão de slot para tempo que a janela de validade impõe. Não é possível converter um slot muito 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 é aproximadamente de 20s, já que essa é a frequência esperada na qual os blocos são produzidos. Usando essa medida de tempo, o Hydra está disponível para reagir à travessia relevante para o protocolo do prazo de contestação.

O que é importante é que o tempo local no Hydra Head (e nós) está vinculado ao tempo na cadeia gerenciado pelo Ouroboros. Como o Hydra é um protocolo isomórfico, é desejável processar 'transações cronometradas' também na camada 2 (consulte issue #196). No entanto, o 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 razão na camada 2. Embora as complexidades de lidar com o tempo on-chain também se apliquem à camada 2, a camada 2 pode fornecer melhores soluções, uma vez que essas redes são muito menores, têm um período de vida útil mais curto e não precisam escalar globalmente.

Se você estiver interessado em se envolver em discussões e compartilhar os tipos de aplicativos que possui e o tempo de resolução deles que exigiriam, junte-se a este canal do Discord do Hydra.

Marlowe

Marlowe é uma linguagem de domínio específico (DSL) para escrever contratos financeiros e transacionais, quase todos os quais envolvem tempo. Uma ampla variedade de contratos financeiros padrão foram escritos em Marlowe, incluindo a maioria dos contratos padrão ACTUS (por exemplo, empréstimos, swaps, opções e derivativos). Além disso, Marlowe suporta uma variedade de tipos de contrato não financeiro, como leilões, trocas de tokens e até jogos. Os mecanismos existentes do Cardano para trabalhar com tempo se encaixam perfeitamente com a semântica do Marlowe e fornecem transações do Marlowe com localidade e determinismo herdado do Plutus.

No Marlowe, o tempo do contrato geralmente aparece nos prazos e timeouts que restringem como a execução do contrato evolui, e isso funciona perfeitamente com os intervalos de validade do Cardano. A lógica de timeout é necessária em um contrato de empréstimo, por exemplo, para lidar com a situação em que um pagamento de empréstimo é perdido: então, uma lógica diferente precisa ser executada para impor uma penalidade, ajustar o cronograma de pagamentos futuros, etc. Contratos também podem usar diretamente os pontos finais de tempo do intervalo de validade em cálculos numéricos, talvez para ajustar os valores de pagamento futuros com base em quando um pagamento antecipado foi recebido. O fato de o tempo aparecer como um intervalo tem pouco impacto prático no Marlowe porque o intervalo pode ser tão curto quanto o tempo levado desde a submissão de uma transação até sua aparição em um bloco na rede Cardano - apenas alguns minutos.

Soluções

O Cardano poderia potencialmente fornecer dados relacionados ao tempo mais precisos durante a validação de transações, como o carimbo de data/hora do produtor de blocos no qual o bloco foi criado, convertido de seu slot, ou até mesmo o carimbo de data/hora real em UTC com precisão de milissegundos. No entanto, isso quebraria o determinismo prospectivo como faz em protocolos que não incluem esse recurso: um usuário não poderia mais saber se uma transação pode definitivamente se aplicar ao livro-razão ou não, porque isso dependeria do carimbo de data/hora exato que o produtor de bloco usou ao criar o bloco.

Outra opção é adicionar vários tipos de afirmações aos corpos de transação além do intervalo de validade. Isso é possível, mas difícil, como já foi descrito anteriormente, portanto, precisa haver um caso de uso para esses tipos de afirmações serem úteis.

Finalmente, redes de camada 2, como Hydra, podem fornecer maior precisão por meio de 'comprimento de slot' mais curto e intervalo de validade mais curto, ao lado de latência reduzida na finalidade das transações. Observe que a implementação atual do Hydra Head ainda não fornecerá esse nível de flexibilidade.

Conclusão

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

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

Junte-se aos canais da comunidade Discord para discussões adicionais sobre manipulação de tempo no Cardano e casos de uso potenciais que não são mencionados aqui.