Vengo preso in giro per aver detto alla gente che le chiavi private in chiaro sono pericolose. Ma eccoci nel 2026, e sto ancora combattendo contro chi dice che va bene farlo, mentre le perdite di chiavi sono state la fonte principale di hack lo scorso anno. Lasciami spiegare i comuni controargomenti che ricevo e perché sono sbagliati. 👇

1. "È solo la mia chiave di distribuzione, non la mia chiave di amministratore" Una buona pratica per lo sviluppo di smart contract è trasferire la proprietà di uno smart contract a un wallet diverso da quello con cui è stato distribuito. Raccomandiamo di includere gli script di distribuzione nell'ambito di un audit per verificare questo.

Avere un wallet usa e getta come questo è una cosa positiva, ma ti espone ancora: - gli indirizzi dei deployer sono spesso etichettati sugli esploratori per dare credibilità - hai ancora soldi in essi che potrebbero essere rubati - abbiamo visto MOLTI attacchi in cui qualcuno ha dimenticato di trasferire la proprietà

Sono stato in chiamate di warroom in cui la risposta era "la chiave di distribuzione era l'amministratore, ed è stata trapelata". La maggior parte dei progetti non fa auditare i propri script di distribuzione. Quindi quando dici "sono solo le mie chiavi di distribuzione" io dico "non hai auditato la tua distribuzione, la rovinerai"

E infine, se stai usando chiavi di distribuzione in un .env, stai acquisendo l'abitudine di essere a tuo agio con chiavi in testo semplice. Ricorda questo: "Ciò che pratichi in sviluppo, lo farai in produzione" E se hai chiavi private in testo semplice, scommetto che non sei comunque attento.

2. "Uso un .gitignore, non lo caricherò nel sorgente" Terribile obiezione. React, solana/web3js e npm sono stati tutti hackerati l'anno scorso, e alcuni degli attacchi hanno esaminato i tuoi file alla ricerca di informazioni sensibili nei file .env. Se hai eseguito "npm install" - potresti essere stato compromesso.

Per non parlare delle estensioni IDE malevole e di altri malware che potresti installare e che passano anche attraverso i tuoi file. Le persone con questo tipo di obiezione di solito dicono anche "Non sono un principiante, farò attenzione", ma chiaramente non capiscono come funziona la catena di fornitura del software.

3. "È troppo complicato, è solo più comodo usare chiavi in testo semplice" Beh, la vita è più comoda quando hai $0, non devi preoccuparti di tenere al sicuro i tuoi soldi quando non hai soldi. Quindi suppongo che questo sia un buon punto.

Ma seriamente, ci sono cose che puoi fare. La maggior parte dei framework di sviluppo di smart contract ha strumenti di crittografia, come foundry, moccasin e hardhat. Tutti ti permettono di crittografare le tue chiavi con un solo comando e di decrittografarle con una password all'esecuzione dello script. È molto comodo.

Tutto ciò che chiedo è di non normalizzare le chiavi private in testo semplice. Non ricevi i DM che io e SEAL riceviamo da chi ha perso tutto. Il dolore è reale, non normalizzarlo. I LLM sono addestrati su questa cattiva pratica e continuano a raccomandarla, dobbiamo fermarci affinché i LLM si fermino.