Cardano propone di rimuovere il controllo dell'ambito di Plutus

La proposta CIP-0205 di Cardano eliminerebbe una delle fasi utilizzate per preparare gli script Plutus all'esecuzione. L'autore Jacco Krijnen propone di gestire gli errori di variabili non legate durante l'esecuzione invece di controllare in anticipo l'intero programma. Presentata il 25 settembre, la proposta è ancora in revisione.

Il costo della preparazione degli script Plutus

Prima di eseguire uno script, un nodo verifica che le sue variabili siano correttamente definite all'interno del programma. Conosciuto come controllo dell'ambito, questo avviene durante la seconda fase della validazione delle transazioni.

Benchmark precedenti citati dalla proposta hanno rilevato che il controllo rappresentava circa il 20% del tempo di preparazione dello script, includendo la decodifica e il controllo della versione. Nei benchmark di validazione completa, rappresentava approssimativamente il 3% del tempo totale di validazione. Queste cifre misurano la quota del tempo di elaborazione imputabile al controllo in quei carichi di test.

La sua rimozione ridurrebbe il lavoro di elaborazione per gli script idonei. Qualsiasi conseguente riduzione delle commissioni di transazione dipenderebbe da successivi adeguamenti ai parametri delle commissioni, secondo la proposta.

Come Plutus gestirebbe gli errori di variabile

Plutus Core è il linguaggio utilizzato per eseguire gli script di smart contract su Cardano. Il suo motore di esecuzione, la CEK machine, già gestisce i tentativi di usare variabili senza un valore associato.

Nella discussione di revisione della proposta, lo sviluppatore Seungheon Oh ha osservato che CEK non dipende dal controllo preliminare dell'ambito. Il tentativo di valutare una variabile non legata produce un normale errore di esecuzione.

Secondo le regole proposte, un programma potrebbe avere esito positivo se una variabile non legata compare solo in codice che non viene mai eseguito. I programmi con ambito corretto conserverebbero gli stessi risultati di esecuzione.

I linguaggi di sviluppo tra cui Aiken, Plinth e Plutarch già impongono l'ambito delle variabili tramite i rispettivi controllori di tipo prima che gli script raggiungano la blockchain, osserva la proposta.

Una nuova versione del linguaggio e un hard fork

La bozza associa la modifica a Plutus Core, versione 1.2.0 del linguaggio, che richiederebbe un hard fork. L'implementazione includerebbe aggiornamenti alla specifica, al codice di esecuzione, al modello formale e ai test di conformità.

La proposta ha ricevuto il numero CIP-0205 il 29 settembre. L'editor dei CIP Robert Phair ha richiesto una circolazione più ampia tra i gruppi di lavoro prima di procedere con la revisione, citando l'ampiezza della modifica.

Secondo l'attuale bozza, gli script esistenti che utilizzano le versioni del linguaggio 1.0.0 e 1.1.0 manterrebbero il loro comportamento. Dopo l'attivazione, i nuovi script che dichiarano la versione 1.2.0 potrebbero essere eseguiti senza il controllo preliminare dell'ambito separato.