Cardano propõe remover a verificação de escopo do Plutus

A proposta CIP-0205 do Cardano eliminaria uma das etapas usadas para preparar scripts Plutus para execução. O autor Jacco Krijnen propõe tratar erros de variáveis não vinculadas durante a execução em vez de verificar todo o programa antecipadamente. Submetida em 25 de setembro, a proposta permanece em análise.

O custo de preparar scripts Plutus

Antes de executar um script, um nó verifica se suas variáveis estão devidamente definidas dentro do programa. Conhecida como verificação de escopo, essa verificação ocorre durante a segunda fase da validação de transações.

Benchmarks anteriores citados pela proposta constataram que a verificação respondeu por cerca de 20% do tempo de preparação do script, incluindo decodificação e verificação de versão. Em benchmarks de validação completa, representou aproximadamente 3% do tempo total de validação. Esses números medem a parcela da verificação no tempo de processamento nessas cargas de teste.

Removê-la reduziria o trabalho de processamento para scripts elegíveis. Qualquer redução resultante nas taxas de transação dependeria de ajustes subsequentes nos parâmetros de taxas, segundo a proposta.

Como o Plutus lidaria com erros de variáveis

Plutus Core é a linguagem usada para executar scripts de contratos inteligentes no Cardano. Seu mecanismo de execução, a máquina CEK, já lida com tentativas de usar variáveis sem um valor vinculado.

Na discussão de revisão da proposta, o desenvolvedor Seungheon Oh observou que a CEK não depende da verificação de escopo preliminar. Tentar avaliar uma variável não vinculada resulta em uma falha de execução comum.

Sob as regras propostas, um programa pode ter sucesso se uma variável não vinculada aparecer apenas em código que nunca é executado. Programas com escopo adequado manteriam os mesmos resultados de execução.

Linguagens de desenvolvimento como Aiken, Plinth e Plutarch já impõem o escopo de variáveis por meio de seus verificadores de tipos antes que os scripts cheguem à blockchain, observa a proposta.

Uma nova versão da linguagem e hard fork

O rascunho vincula a mudança à versão 1.2.0 da linguagem Plutus Core, o que exigiria um hard fork. A implementação incluiria atualizações da especificação, do código de execução, do modelo formal e dos testes de conformidade.

A proposta recebeu o número CIP-0205 em 29 de setembro. O editor de CIP Robert Phair solicitou uma circulação mais ampla entre os grupos de trabalho antes que a revisão prossiga, citando a amplitude da mudança.

Segundo o rascunho atual, scripts existentes que usam as versões 1.0.0 e 1.1.0 da linguagem manteriam seu comportamento. Após a ativação, novos scripts que declararem a versão 1.2.0 poderão ser executados sem a verificação de escopo preliminar separada.