MSTR Cat

Blockchain/Nível IV · Protocolo a fundo/4.1 Script/Lição 4

Timelocks: CLTV e CSV

O relógio que não pode ser voltado para trás, e a mediana que o mantém honesto

MateriaisUm explorador de blocos com visualizações detalhadas das transações (por exemplo, mempool.space ou blockchain.com)Uma calculadora capaz de lidar com marcos de tempo do UnixOs documentos de especificação BIP65, BIP68 e BIP113

Curiosidade

  1. Por que existe um campo de transação para adiar os gastos se uma nova transação sempre pode contorná-lo?
  2. Como um único minerador pode mentir sobre o tempo sem quebrar o consenso para todos os outros?
  3. Qual é a diferença entre esperar até um ano específico e esperar dois anos a partir de agora?

Explorar

  1. Cada transação de Bitcoin possui um campo nLockTime, um valor de quatro bytes que impede que a transação seja minerada antes de um determinado momento. Se o valor for inferior a 500.000.000, ele representa a altura do bloco; se estiver igual ou acima desse limite, trata-se de uma marca de tempo Unix. No entanto, esse mecanismo aplica-se apenas a essa instância específica de transação. Um usuário pode sempre criar uma nova transação com os mesmos inputs e um nLockTime igual a zero, gastando as moedas imediatamente. O nLockTime por si só não oferece segurança para condições futuras, pois não vincula o próprio output.
  2. OP_CHECKLOCKTIMEVERIFY (CLTV), proposto por Peter Todd no BIP65 e ativado em dezembro de 2015, muda essa dinâmica. O CLTV é um opcode de script que compara o nLockTime da transação com um valor na pilha. Se o locktime for menor que o valor exigido, a execução falha. Como essa verificação ocorre dentro do script de bloqueio da saída, toda tentativa de gastar aquela específica Unspent Transaction Output (UTXO) precisa satisfazer essa condição. Isso cria um bloqueio temporal absoluto: as moedas não podem ser gastos até que seja atingido um ponto de consenso global em termos de tempo ou altura do bloco.
  3. Os “timelocks” relativos funcionam de maneira diferente, medindo a duração em vez de pontos absolutos. O BIP68 reinterpreta o campo nSequence das entradas de transação, que anteriormente não era utilizado para esse fim, a fim de codificar atrasos relativos. OP_CHECKSEQUENCEVERIFY (CSV), definido no BIP112 e ativado juntamente com o BIP68 em julho de 2016, compara o valor da sequência da entrada com um período de tempo exigido. Isso permite que os scripts imponham condições como “esta saída não pode ser gasta até 144 blocos após sua confirmação”. O atraso é relativo à confirmação específica daquele UTXO, o que o torna ideal para caminhos de recuperação baseados no tempo ou para o vencimento de canais de pagamento.
  4. Os bloqueios baseados em tempo também deram aos mineradores um incentivo para manipular as marcas de tempo. Eles podiam definir as marcas de tempo dos blocos até duas horas no futuro, a fim de incluir mais transações com bloqueio temporal antes do previsto. O BIP113, ativado simultaneamente com os bloqueios temporais relativos em julho de 2016, introduziu o Median Time Past (MTP). As verificações de bloqueio temporal agora comparam-se com a mediana das marcas de tempo dos onze blocos anteriores, em vez da marca de tempo do próprio bloco. Isso garante que nenhum minerador possa influenciar significativamente o “relógio”; o MTP geralmente está cerca de uma hora atrás do tempo real, fornecendo uma referência estável e verificável para todos os cálculos de bloqueio temporal.
  5. Esses mecanismos sustentam aplicações complexas como canais de pagamento e protocolos de herança. Nos canais Lightning, os pagamentos em trânsito utilizam bloqueios temporais absolutos (CLTV), de modo que um pagamento não reclamado possa ser reembolsado após um prazo determinado, enquanto atrasos relativos (CSV) nos próprios outputs de uma das partes dão à outra parte tempo para punir um estado do canal desatualizado. No caso da herança, scripts podem combinar requisitos de multisignatura com bloqueios temporais: talvez sejam necessárias duas chaves para acesso diário, mas após um ano de inatividade, uma terceira chave (um herdeiro) entra no quórum por meio de uma condição CSV. Esses parâmetros são definidos na criação da carteira e não podem ser alterados uma vez que os fundos são bloqueados.
  6. Timelocks são restrições permanentes; eles são desbloqueados em um horário definido, mas não oferecem mecanismo algum para serem rebloqueados ou para que os atrasos sejam estendidos após a ativação. Se um script codificar um valor de sequência de 100 blocos, as moedas ficam disponíveis exatamente quando essa altura relativa for alcançada a partir da confirmação. Erros na codificação podem tornar os fundos inacessíveis por mais tempo do que o pretendido ou, inversamente, desbloqueá-los prematuramente. Para verificação prática, abra qualquer transação recente em um explorador de blocos e inspecione o campo nLockTime. A maioria das carteiras define esse valor para a altura atual do bloco, de modo que a transação não possa ser inserida em um bloco com altura anterior; isso elimina um incentivo para os mineradores reescreverem o bloco mais recente a fim de coletar suas taxas (“fee sniping”).

Fatos-chave

  • Os valores de nLockTime abaixo de 500.000.000 são interpretados como alturas de bloco; os valores iguais ou acima disso são marcos temporais do Unix.
  • OP_CHECKLOCKTIMEVERIFY (BIP65) foi ativado em dezembro de 2015 e impõe bloqueios temporais absolutos no nível do script.
  • OP_CHECKSEQUENCEVERIFY (BIP112) e BIP68 foram ativados em julho de 2016, permitindo bloqueios temporais relativos por meio do campo nSequence.
  • O Median Time Past (MTP), introduzido pelo BIP113, utiliza a mediana dos onze blocos anteriores para evitar manipulação do tempo pelos mineiros.
  • Os atrasos no CSV são medidos em relação à altura ou ao momento da confirmação do específico UTXO que está sendo gasto.
  • As carteiras normalmente definem o nLockTime para a altura atual do bloco, a fim de mitigar os riscos de fee sniping.

Exercício nove, seis, três, um

9ReunirListe 9 usos de timelocks que podem ser encontrados descritos (Lightning, cofres, herança, custódia, trocas atômicas e outros), indicando se cada um utiliza um bloqueio absoluto ou relativo.
6AgruparAgrupe os 9 em 6 por finalidade: reembolso, período de penalidade, herança, bloqueio de poupança, prazo do contrato ou outro.
3DestilarReduza as 6 para 3 razões pelas quais um timelock deve existir no script de saída e não apenas na transação de gasto.
1CristalizarEscreva 1 frase explicando como o MTP transforma os timelocks de um modelo baseado em confiança nos mineradores para uma regra de consenso determinística.

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

Abrir na academia interativa →

EN ES ZH JA KO RU DE FR MS