💻 computer science

Formal Verification of Imperative First-Class Functions in Move

Questo documento presenta un'estensione al Move Prover che abilita la verifica formale di funzioni imperative di prima classe nel linguaggio Move introducendo predicati comportamentali, etichette di stato e una strategia di codifica SMT che sfrutta la separazione statica della memoria di Move per una verifica efficiente e l'inferenza automatizzata delle specifiche.

Autori originali: Wolfgang Grieskamp, Teng Zhang, Vineeth Kashyap, Jake Silverman

Pubblicato 2026-05-14

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Wolfgang Grieskamp, Teng Zhang, Vineeth Kashyap, Jake Silverman

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Il Quadro Generale: La Fabbrica dei "Contratti Intelligenti"

Immagina che Aptos sia una fabbrica ad alta sicurezza che costruisce asset digitali (come denaro o biglietti) utilizzando un linguaggio speciale chiamato Move. Per assicurarsi che questi asset non vengano rubati o danneggiati, la fabbrica utilizza un ispettore robot chiamato Move Prover (MVP). Questo robot legge i progetti (il codice) e dimostra matematicamente che tutto funzionerà correttamente prima che la fabbrica venga mai avviata.

Per molto tempo, questo robot è stato eccellente nel controllare istruzioni semplici. Ma recentemente, la fabbrica ha aggiunto una nuova e complessa funzionalità: le Funzioni di Prima Classe.

Pensa a queste nuove funzioni come a bacchette magiche.

Vecchio metodo: Dovevi tenere la bacchetta tu stesso per lanciare un incantesimo. Il robot sapeva esattamente quale incantesimo stavi lanciando.
Nuovo metodo: Puoi mettere la bacchetta in una scatola, consegnare la scatola a un amico, riporre la scatola in una cassaforte o passarla a una macchina che non sa cosa c'è dentro. La macchina sa solo: "Devo agitare una bacchetta", ma non sa quale bacchetta fino all'ultimo istante.

Questo si chiama Dispatch Dinamico. È potente, ma rompe l'ispettore robot perché non può vedere il futuro per sapere quale incantesimo specifico viene lanciato.

Il Problema: Il Dilemma della "Scatola Nera"

Il documento spiega come gli autori abbiano aggiornato l'ispettore robot (MVP) per gestire queste bacchette magiche senza andare in panico.

In precedenza, se una funzione era una "scatola nera" (una variabile che contiene una funzione), il robot doveva indovinare o controllare ogni singola possibilità contemporaneamente, il che faceva esplodere la matematica e rallentava il robot.

Gli autori hanno introdotto due nuovi strumenti per risolvere il problema:

1. Predicati Comportamentali: La "Scheda di Garanzia"

Invece di guardare dentro la bacchetta magica per vedere come funziona, il robot ora guarda la Scheda di Garanzia attaccata alla bacchetta.

Il Vecchio Modo: "Devo sapere esattamente come funziona questa bacchetta calculate_price, fino all'ultima riga di codice, prima di lasciartela usare."
Il Nuovo Modo: "Non mi importa come funziona la bacchetta all'interno. Mi basta leggere la sua Scheda di Garanzia. La scheda dice: 'Se mi dai 5 monete, ti restituirò 3 monete e non si romperà mai.'"

Il documento chiama questi Predicati Comportamentali. Sono come un contratto che descrive:

Pre-condizioni: Cosa deve essere vero prima di agitare la bacchetta.
Post-condizioni: Cosa sarà vero dopo averla agitata.
Condizioni di Aborto: Quando la bacchetta potrebbe esplodere (fallire).

Questo permette al robot di controllare la promessa della bacchetta senza bisogno di conoscere la ricetta segreta al suo interno.

2. Etichette di Stato: La "Fotocamera con Timestamp"

A volte, si verifica una sequenza di eventi. Immagina una linea di produzione in cui un robot dipinge un'auto e poi un altro robot monta le ruote.

Se vuoi provare che l'auto è sicura, devi conoscere lo stato dell'auto dopo la verniciatura ma prima che le ruote siano montate.

Gli autori hanno introdotto le Etichette di Stato. Immagina queste come Fotocamere con Timestamp posizionate in punti specifici del processo.

Fotocamera A (Inizio): L'auto è metallo nudo.
Fotocamera B (Metà): L'auto è verniciata.
Fotocamera C (Fine): Le ruote sono montate.

Il robot può ora dire: "So che la verniciatura è avvenuta tra la Fotocamera A e la Fotocamera B, e le ruote sono state aggiunte tra la Fotocamera B e la Fotocamera C." Questo aiuta il robot a ragionare su sequenze complesse di eventi senza confondersi su com'era il mondo in un dato momento.

Come Funziona Davvero il Robot (La "Centralina")

Il documento descrive come il robot traduca queste idee in matematica (logica SMT) che un computer può risolvere.

Immagina che il robot abbia una Centralina.

Scenario A (Bacchetta Nota): Se il robot vede una bacchetta specifica e nota (ad esempio, la funzione product), sposta l'interruttore su "Modalità Diretta". Ignora la scheda di garanzia e controlla semplicemente il codice effettivo di quella specifica bacchetta.
Scenario B (Bacchetta Sconosciuta): Se il robot vede una scatola generica (una variabile), sposta l'interruttore su "Modalità Astratta". Ignora completamente il codice e si affida solo alla Scheda di Garanzia (i predicati comportamentali) per provare che il sistema è sicuro.

Questo è efficiente perché il robot non deve cercare di aprire ogni scatola possibile. Apre solo quelle che conosce, e per il resto, si fida del contratto.

L'"Auto-Ispettore" (Inferenza delle Specifiche)

Una delle parti più interessanti del documento è che il robot ora può scrivere le proprie Schede di Garanzia.

Di solito, gli umani devono scrivere queste schede manualmente, il che è tedioso. Gli autori hanno aggiornato il robot in modo che possa guardare il codice, capire cosa dovrebbe dire la Scheda di Garanzia e scriverla per te.

Input: Un pezzo di codice disordinato con una bacchetta magica.
Azione del Robot: "Vedo che questo codice controlla se esiste una commissione. Scriverò una Scheda di Garanzia che dice: 'Questa bacchetta esploderà se la commissione manca'."
Risultato: Il robot controlla il proprio lavoro. Se il codice corrisponde alla scheda, supera il test.

Questo è dimostrato nel documento con un esempio di Market Maker Automatizzato (AMM). Questo è un sistema che scambia asset. Il robot ha dimostrato che anche se la regola di prezzo (la bacchetta magica) poteva essere modificata dall'utente, il sistema non si sarebbe mai bloccato o avrebbe perso denaro, a condizione che la nuova bacchetta seguisse le regole scritte sulla sua Scheda di Garanzia.

Riepilogo del Risultato

Il documento afferma di aver risolto un grosso grattacapo nella verifica dei contratti intelligenti:

Ha reso le "Bacchette Magiche" (funzioni) sicure da usare in modo che possano essere archiviate, scambiate e modificate dinamicamente.
Ha creato un nuovo linguaggio (Predicati Comportamentali + Etichette di Stato) che permette al robot di parlare di queste bacchette senza bisogno di vederne l'interno.
Ha reso il robot più veloce e intelligente utilizzando un approccio "a centralina" che passa dal guardare il codice al guardare il contratto.
Ha automatizzato la burocrazia permettendo al robot di generare i contratti necessari per te.

In breve, hanno insegnato all'ispettore robot come fidarsi della promessa di uno sconosciuto (il contratto) senza bisogno di conoscere i segreti dello sconosciuto, rendendo la fabbrica più sicura e più flessibile.

Riepilogo Tecnico: Verifica Formale di Funzioni Imperative di Prima Classe in Move

Enunciato del Problema
Il Move Prover (MVP) è uno strumento di verifica formale progettato per gli smart contract in Move, originariamente basato su uno stile di specifica modulare con dispatch statico. Una recente estensione del linguaggio Move ha introdotto le funzioni di ordine superiore, consentendo alle funzioni di essere valori di prima classe che possono essere passati come argomenti, memorizzati in strutture dati e persistiti nello storage globale. Questa capacità abilita il dispatch dinamico ma infrange le ipotesi di analisi statica su cui MVP si basava. Nello specifico, quando una funzione viene chiamata dinamicamente, le sue precondizioni e postcondizioni non possono essere risolte nel sito di chiamata. Il chiamante deve ragionare in modo astratto sul comportamento degli argomenti di tipo valore-funzione, mentre il verificatore deve riconciliare queste specifiche astratte con le funzioni concrete che possono raggiungere il sito di chiamata. Le soluzioni esistenti in altri linguaggi (ad esempio Dafny, F*, Verus) o mancano del supporto per le funzioni imperative di prima classe che modificano lo stato, oppure fanno affidamento sulla logica di separazione, il che può portare a codifiche SMT complesse. La sfida consiste nel supportare efficientemente queste funzionalità dinamiche, garantendo che la verifica rimanga rapida, completa per i casi rilevanti e libera dall'instabilità dei trigger SMT.

Metodologia
Gli autori estendono MVP e il linguaggio di specifica Move per supportare le funzioni di ordine superiore attraverso tre meccanismi principali:

Predicati Comportamentali: Il linguaggio di specifica è esteso con predicati che caratterizzano il comportamento dei valori-funzione ( $f$ ) su specifici argomenti ( $\bar{x}$ ) e risultati ( $\bar{y}$ ). Questi includono:
- requires_of<f>(x): Precondizioni.
- aborts_of<f>(x): Condizioni di aborto.
- ensures_of<f>(x, y): Postcondizioni.
  Questi predicati tracciano implicitamente le dipendenze di stato di lettura e lettura/scrittura, consentendo alle specifiche di riferirsi in modo astratto agli argomenti della funzione senza inserire inline i loro corpi.
Etichette di Stato: Per ragionare sulle transizioni sequenziali di stato e sugli stati intermedi della memoria, gli autori introducono etichette di stato (ad esempio, $S$ ). Queste etichette nominano punti specifici nell'esecuzione. I predicati possono essere a stato singolo ( $S \mid \sim p$ ) o a due stati ( $S.. \mid \sim q$ ), consentendo la composizione di predicati comportamentali per descrivere sequenze di operazioni (ad esempio, lo stato post-funzione di una funzione che diventa lo stato pre-funzione di un'altra).
Codifica SMT tramite Discriminazione delle Varianti: A livello SMT, i valori-funzione sono codificati utilizzando tipi di dati algebrici che rappresentano tutte le possibili origini di un valore-funzione (closure concrete, parametri di funzione o campi di struct). Quando un valore-funzione viene invocato:
- Se la funzione concreta è nota (ad esempio, una specifica closure), l'invocazione viene sostituita con l'effetto di quella funzione concreta.
- Se la funzione è sconosciuta (ad esempio, un parametro o una closure caricata dallo storage), l'invocazione è modellata utilizzando i predicati comportamentali associati al tipo di quel valore-funzione.
- La codifica utilizza costrutti "havoc" e "assume" per modellare le modifiche alla memoria e garantisce che le condizioni di frame siano rispettate distinguendo tra le mappe di memoria dello stato pre e post.

Contributi Chiave
Il documento dettaglia i seguenti contributi specifici:

Estensioni del Linguaggio: L'introduzione di predicati comportamentali ed etichette di stato nel linguaggio di specifica Move, rendendo le specifiche delle funzioni cittadini di prima classe capaci di tracciare le dipendenze di stato.
Implementazione in MVP: Una codifica basata su Boogie che discrimina le varianti dei valori-funzione nei siti di chiamata. Questo approccio evita la necessità di logica di separazione sfruttando la separazione statica della memoria di Move (modello delle risorse), portando a codifiche SMT più efficienti.
Inferenza delle Specifiche: Un'estensione dello strumento di analisi della precondizione debole (WP) di MVP per gestire il codice di ordine superiore. Questo strumento deriva semi-automaticamente specifiche basate su predicati comportamentali da bytecode Move arbitrario, riducendo il carico di annotazione manuale e fornendo una pipeline di validazione per i nuovi costrutti.
Gestione degli Effetti Collaterali Imperativi: A differenza di alcuni strumenti esistenti (ad esempio Dafny), questo approccio supporta le funzioni imperative di prima classe che modificano lo stato tramite riferimenti in stile Rust e variabili globali.

Risultati e Validazione
Gli autori dimostrano l'approccio utilizzando un esempio di Automated Market Maker (AMM) in cui una curva di prezzo è memorizzata come valore-funzione. Il sistema verifica con successo:

Invarianti: Proprietà come "la funzione non abortisce mai", "monotonia dell'output" e "preservazione del prodotto costante" sono verificate utilizzando predicati comportamentali ed etichette di stato.
Controllo di Conformità: Lo strumento di inferenza delle specifiche deriva automaticamente le condizioni di aborto per le funzioni di prezzo (ad esempio, rilevando che una funzione di prezzo basata su commissioni abortisce se manca una risorsa di commissione), consentendo controlli di conformità leggibili da macchina senza annotazioni manuali.
Suite di Test: Una suite di test completa che copre chiamate dirette, ricorsione reciproca, parametri di ordine superiore e dispatch di closure memorizzate conferma che la codifica è internamente coerente e che le specifiche inferite sono sufficientemente strette affinché il verificatore le soddisfi.

Significato
Il documento afferma che questo lavoro abilita la verifica routinaria e orientata alla produzione degli smart contract Move caratterizzati da dispatch dinamico e funzioni di ordine superiore. Preservando il modello dei costi di MVP—dove la verifica si completa in pochi secondi per funzione—l'estensione permette agli sviluppatori di utilizzare pattern complessi come flussi di asset basati su callback e gestori di asset estendibili con garanzie formali. L'approccio si distingue dagli strumenti basati sulla logica di separazione sfruttando la separazione statica della memoria intrinseca di Move per semplificare le codifiche SMT. Inoltre, l'integrazione dell'inferenza delle specifiche fornisce un percorso pratico per verificare la conformità dei valori-funzione, affrontando un ostacolo significativo all'adozione delle funzioni di ordine superiore negli smart contract critici per la sicurezza. Il lavoro riconosce che, sebbene la verifica lato applicazione sia ora comparabile a quella delle funzioni di primo ordine, la verifica lato conformità (dimostrare che una funzione passata soddisfa un contratto) potrebbe ancora richiedere suggerimenti di prova manuali o assunzioni affidate in casi complessi.