Unità 2 / 11

Supporto per la scrittura di contratti intelligenti: Solidity/Vyper Draft e generazione di codice sicuro

Guadagni:

  • Capacità di utilizzare l'intelligenza artificiale per produrre framework, test e rivedere bozze basate su librerie comprovate (ad esempio OpenZeppelin) e comprendere che gli esseri umani garantiscono la sicurezza della produzione
  • Capacità di verificare la versione del codice, il pattern e il controllo degli accessi prodotti dall'intelligenza artificiale attraverso compilazione, testing e testnet
  • Essere in grado di distinguere che la compilazione non significa essere sicuri e che testnet e auditing sono essenziali.

Scrivere un contratto intelligente è diverso dal software ordinario: il codice che scrivi è pubblico, immutabile ed è un programma che muove direttamente il denaro. In questa unità imparerai come utilizzare l'intelligenza artificiale come assistente allo sviluppo di contratti intelligenti; Impareremo dalla produzione della bozza alla scrittura del test, dal richiamo del modello all'ottimizzazione del gas (commissione di transazione). Ma siamo chiari fin dall'inizio: l'intelligenza artificiale produce progetti; Gli esseri umani garantiscono la sicurezza del codice che entra in produzione.

Il terreno innanzitutto: lingua e ambiente

Il linguaggio dei contratti intelligenti più comune è Solidity (il linguaggio di Ethereum e EVM — Ethereum Virtual Machine, la macchina virtuale su cui vengono eseguiti i contratti — catene compatibili). L'alternativa è Vyper (un linguaggio simile a Python che mira a essere più limitato e leggibile). Il tuo codice consuma gas (il costo di ogni transazione sulla blockchain); Il codice inefficiente è costoso. Mantenere questi termini chiari nel contesto fornito all’IA è fondamentale per ottenere risultati accurati.

Il punto in cui l'intelligenza artificiale è più preziosa non è "scrivere da zero", ma produrre la struttura + un buon stampo: un inizio conforme agli standard, un progetto su cui aggiungere la propria esperienza.

Livelli di utilizzo dell'intelligenza artificiale nella codifica

1. Generazione di scheletri. L'intelligenza artificiale estrae rapidamente lo scheletro di un token standard (ERC-20) o NFT (ERC-721: uno standard unico per le risorse digitali). Ma assicurati di fare in modo che l'intelligenza artificiale utilizzi una libreria collaudata: ad esempio OpenZeppelin (la libreria contrattante standard affidabile e verificata della comunità). La regola è utilizzare il blocco testato anziché scrivere la sicurezza da zero.

2. Descrizione e revisione delle funzioni. Spiegare una funzione esistente all'intelligenza artificiale consente di individuare tempestivamente gli errori logici.

3. Generazione di test. L'intelligenza artificiale è efficace nel generare casi di test per casi limite: input zero, numero molto elevato, chiamante non autorizzato, chiamata ripetuta. Questo ricorda uno degli scenari che si saltano.

4. Gas e leggibilità. L'intelligenza artificiale segnala modelli costosi come scritture di archiviazione non necessarie e suggerisce alternative.

Suggerimento: istruire l'intelligenza artificiale a "basare sui contratti controllati di OpenZeppelin, riscrivere la sicurezza da zero". È molto più rischioso per un’intelligenza artificiale scrivere il codice di sicurezza originale piuttosto che utilizzare una libreria testata.

Prompt debole / Prompt forte

Suggerimento debole:

Scrivimi un contratto simbolico.

Questa sollecitazione è pericolosa: non è chiaro quale standard, quale catena, quale libreria, quale requisito di sicurezza. L'intelligenza artificiale genera codice casuale, forse obsoleto o non sicuro.

Suggerimento potente:

Il tuo ruolo: sviluppatore senior di Solidity. Genera una bozza di token ERC-20 per una catena compatibile con EVM. Regole: - Basato sui contratti ERC20 e Ownable controllati da OpenZeppelin. - Scrivi esplicitamente la versione di Solidity e la riga di licenza (SPDX). - Solo il proprietario ha il permesso di coniare; aggiungere un tappo contro la pressione infinita. - Aggiungi il commento NatSpec a ciascuna funzione. - Scrivere la sicurezza da zero; Usa il blocco standard. - Aggiungere un avvertimento alla fine: "Questa è una bozza; sono necessari audit e test". Contrassegna le aree di cui non sei sicuro con // TODO.

Differenza: un forte suggerimento fornisce chiare aspettative su ruolo, standard, libreria, limite di sicurezza, documentazione e convalida.

Quattro modelli copiabili

1) Schema basato su standard:

Il tuo ruolo: sviluppatore di Solidity. Genera una struttura contrattuale [ERC-20 / ERC-721 / staking] basata sulla libreria controllata da OpenZeppelin. Scrivi la licenza SPDX e la versione pragma. Aggiungi il controllo degli accessi (chi può chiamare) a ciascuna funzione esterna. Reinventare la sicurezza; Usa blocchi standard. Questa è una bozza.

2) Revisione delle funzioni:

Esamina la seguente funzione come uno sviluppatore senior: cosa fa, quali stati cambia, chi può chiamarla? Contrassegnare possibili errori logici e rischi per la sicurezza come IPOTESI, collegandoli a una riga nel codice. Non dire apertamente "sicuro"; basta elencare i punti di attenzione.

3) Bozza dello scenario di prova:

Proporre casi di test per questo contratto (potrebbe essere una bozza per Foundry/Harhat). Copre in particolare i casi limite: zero input, numero molto grande, chiamata non autorizzata, chiamata rientrante, fondi insufficienti. Scrivi COSA conferma ogni test.

4) Revisione del gas e della leggibilità:

In questo contratto, segnare gli schemi che possono ridurre il costo del gas: scrittura di memoria non necessaria, chiamata esterna nel loop, calcolo ripetitivo. Spiega la differenza prima/dopo in ciascun suggerimento. Consigliare ottimizzazioni che compromettono la sicurezza; Se non è chiaro, di' "chiedi al revisore".

Tre mini custodie (in numeri)

Caso 1: lo scheletro ha risparmiato 4 ore. Un team ha estratto lo scheletro di un contratto di maturazione basato sulla verifica della biblioteca con l'intelligenza artificiale in 30 minuti; Ci sono volute circa 4 ore manualmente. Il team ha dedicato tempo alla sicurezza e ai test. Il vantaggio non è venuto dal trasferimento della sicurezza, ma dall’accelerazione del noioso quadro normativo.

Caso 2: trappola per versioni obsolete. L'intelligenza artificiale ha prodotto un modello che invia Ether grezzo tramite trasferimento, cosa che non è più consigliata perché i dati di addestramento sono obsoleti. Lo sviluppatore lo ha notato e lo ha modificato nell'attuale modello basato su chiamate e protetto dalla rientranza. Lezione: la libreria/modello dell'IA viene sempre confermato aggiornato; L'intelligenza artificiale non sa oltre la data limite dell'addestramento.

Caso 3: la bozza di prova ha riscontrato un bug nascosto. Il test "chiamante non autorizzato" prodotto dall'intelligenza artificiale ha rivelato che lo sviluppatore aveva dimenticato il controllo dell'accesso a una funzione. onlyOwner manca 1 riga, catturata in 5 minuti su testnet; Potrebbe essersi verificata una perdita di fondi sulla rete principale. Lezione: l'intelligenza artificiale copre i punti ciechi umani durante i test.

Ricordare i modelli di sicurezza con l’intelligenza artificiale

L’intelligenza artificiale è efficace nel ricordarti modelli di vulnerabilità noti come una lista di controllo. I modelli più comuni:

  • Rientro: effettuare una chiamata esterna senza aggiornare lo stato. Soluzione: ordine controlli-effetti-interazioni, guardia di rientro.
  • Mancanza di controllo degli accessi: chiunque può chiamare la funzione critica.
  • Overflow/underfall di numeri interi: Modern Solidity ne rileva la maggior parte, ma rappresenta comunque un rischio nel codice di basso livello.
  • Convalida dell'input inadeguata: indirizzo zero, controllo quantità zero.
  • Dipendenza da Oracle: fiducia cieca nei dati esterni (come il prezzo).
Attenzione: l'AI può richiamare questo elenco, ma non può garantire se un elemento nell'elenco è nel tuo codice specifico. La lista di controllo è un inizio; Non sostituisce il controllo dei contenitori.

Ottenere il contesto giusto: il segreto per un buon codice dell'intelligenza artificiale

La qualità del codice prodotto dall'intelligenza artificiale dipende direttamente dalla qualità del contesto che gli fornisci. In Web3 questo è particolarmente critico perché un piccolo dettaglio (quale catena, quale versione di Solidity, quale token standard) modifica l'intero output. Un buon contesto include:

  • Catena target e ambiente: mainnet Ethereum o Layer 2 (sidechain più economica che funziona sopra la mainchain)? Il costo del gas e alcune funzionalità variano in base alla catena.
  • Versione e libreria: quale versione di Solidity, quale versione di OpenZeppelin? Se non viene specificata alcuna versione, l'intelligenza artificiale potrebbe produrre modelli obsoleti e deprecati.
  • Requisiti di sicurezza: esiste un limite, può essere messo in pausa, può essere aumentato? Queste cose dovrebbero essere dette fin dall'inizio.
  • Vincoli: Limiti chiari come “non utilizzare assembramenti”, “evitare chiamate esterne”, “ottimizzare il gas ma mantenere la leggibilità”.

Un'altra tecnica potente è chiedere prima all'IA il piano, poi il codice: "Prima elenca le funzioni di questo contratto e cosa farà ciascuno; scrivi il codice una volta che lo avrò approvato". Ciò rileva presto l'IA che va nella direzione sbagliata e consente di mantenere la decisione architettonica.

Suggerimento: chiedi all'IA "perché hai scritto questo codice in questo modo?" chiedere. Spiegare la logica accelererà il tuo apprendimento e porterà in superficie eventuali errori logici (ad esempio un falso presupposto di sicurezza). Non fidarti dell'output di un'intelligenza artificiale che non può difendere il proprio codice.

Errori comuni

  • Mettere la sicurezza nell'intelligenza artificiale da zero. Utilizzare una libreria testata.
  • Non confermando la versione/modello prodotto dall'IA. I dati di allenamento potrebbero essere vecchi.
  • Bypassare la rete di test. Ogni bozza dovrebbe essere eseguita sulla rete di prova prima di essere pubblicata.
  • Non aggiungere NatSpec/documentazione. L'ispezione e la manutenzione diventano difficili.
  • "È compilato, quindi è sicuro" malinteso. Essere compilati non significa essere al sicuro.
  • Dimenticare il controllo degli accessi. È uno degli errori più comuni e costosi.

In sintesi

  • Nella scrittura dei contratti intelligenti, l’intelligenza artificiale produce strutture, test e bozze di revisione; Human garantisce la sicurezza della produzione.
  • Costruisci la sicurezza non da zero ma basandoti su librerie comprovate (ad esempio OpenZeppelin).
  • Si conferma sempre l'attualità delle versioni e dei modelli prodotti da YZ.
  • I test stub sono preziosi per individuare i punti ciechi umani (casi limite, controllo degli accessi).
  • Essere compilati non significa essere al sicuro; testnet e auditing sono indispensabili.

Compito dell'applicazione

Per un semplice token ERC-20, genera una bozza utilizzando il prompt "scheletro basato su standard" sopra. Quindi: (1) controlla se utilizza una libreria selezionata, (2) controlla i controlli di accesso, (3) genera test con il prompt "test case draft" ed esegui effettivamente almeno un test rogue-caller. Trova e annota almeno un punto di sicurezza mancato dall'IA.

lista di controllo

  • [] Ho indicato chiaramente lo standard e la catena nel prompt.
  • [ ] Volevo una produzione collaudata basata su libreria.
  • [ ] Licenza SPDX e versione pragma disponibili.
  • [] Esiste un controllo degli accessi in ogni funzione critica.
  • [] Ho creato ed eseguito test per casi limite.
  • [ ] Ho confermato che la libreria/modello è aggiornato.
  • [ ] Ho contrassegnato il codice per l'auditing e il testing; Non l'ho ottenuto senza supervisione su mainnet.