Sicurezza Blockchain: come comprendere gli audit Blockchain per rimanere al sicuro in DeFi

L'anno scorso è stato un periodo piuttosto oscuro per le criptovalute. Non solo abbiamo assistito al crollo catastrofico di Luna, alla degenerazione di 3 Arrows Capital, problemi di insolvenza e bancarotta con BlockFi, Celsius, Voyager, VAULD e altro, condizioni macroeconomiche che ci hanno fatto precipitare nelle profondità di un inverno crittografico, ma è stato anche un anno enormemente disastroso per gli hack e gli exploit blockchain e DeFi, che ha portato le persone a scappare dalla DeFi più velocemente dei nuotatori che fuggono dalle acque infestate dagli squali.

Ora probabilmente stai pensando a te stesso, “wow, grazie per l'introduzione deprimente. Crypto suona come un campo minato!

E non ti sbagli lì, le criptovalute hanno sicuramente la loro giusta quota di rischi. Ma prima di lasciare che tutto questo destino ti faccia venir voglia di abbandonare le criptovalute per sempre e nasconderti sotto il tuo letto, non temere, perché questo articolo ti aiuterà a insegnarti come navigare nelle acque della DeFi nel modo più sicuro possibile e a mostrarti cosa è necessario conoscere gli audit di sicurezza blockchain.

Anche se questo non aiuterà a proteggere da ogni rischio in criptovalute, non c'è modo di proteggere qualcuno che decide di "YOLO" i propri risparmi di una vita nel prossimo memecoin, le informazioni in questo articolo ti aiuteranno almeno a fornirti un'altra freccia nella tua faretra che puoi implementare per migliorare notevolmente la tua navigazione sicura complessiva dello spazio DeFi.

Solo per dissipare alcune paure all'inizio, non preoccuparti che questo articolo sia troppo tecnico. Questa guida utile sarà così facile da capire che anche mio padre che si riferisce all'intera industria delle criptovalute come "Quella roba di Bitcoin" sarà in grado di capirla.

E poiché sono esperto nelle abilità di sviluppo della blockchain quanto una roccia è nel tagliare i capelli, ho deciso di ottenere un aiuto professionale e consigli utili per questo articolo. Ho contattato i nostri amici all'indirizzo Accetta Blockchain per aiutare a insegnare a me stesso, e al Joe medio, cosa diavolo sono questi audit blockchain.

Voglio fare un grande ringraziamento al team di Ackee per aver dedicato del tempo ad aiutare noi e la nostra comunità insegnandoci i fondamenti degli audit blockchain e per aver collaborato con noi a questo articolo. I rapporti di audit Blockchain e DeFi sono un aspetto così importante delle criptovalute e sono qualcosa che pochissimi di noi capiscono davvero.

Quando eseguiamo la nostra due diligence nel determinare la sicurezza di un protocollo DApp o DeFi, molti di noi cercheranno qualcosa che dica che la piattaforma è stata verificata e potrebbero pensare "va bene, abbastanza buono". So di esserne stato colpevole in passato, ma cosa significa in realtà essere stato sottoposto a audit? Come possiamo verificarlo? E come imparerai in questo articolo, solo perché qualcosa è stato verificato, ciò non significa che dovrebbe ottenere automaticamente il via libera.

Per iniziare, diamo un'occhiata a cosa fanno effettivamente le società di auditing blockchain.

Cosa fanno le società di auditing Blockchain?

Quando sentiamo il termine "revisione", molti di noi immaginano automaticamente un vecchio tipo soffocante con un vestito che lavora per il governo che verrà a bussare e esaminerà tutti i nostri dati finanziari e gli estratti conto con un pettine a denti fini. Nel tradizionale settore finanziario avresti ragione, ma i revisori blockchain non potrebbero essere più lontani da questo.

I revisori Blockchain non sono contabili per alcuno sforzo di immaginazione, sono esperti in capacità di programmazione e sviluppatori che cercano bug, errori e codice dannoso nel codice sorgente di un progetto blockchain, smart contract o token crittografico.

Diverse società di revisione possono anche specializzarsi in aree diverse, motivo per cui è sempre bello vedere una piattaforma che è stata verificata da più di una società. Ogni audit condotto riduce il rischio e un'azienda può raccogliere qualcosa che l'altra azienda ha perso.

1inch ne è un ottimo esempio. 1inch è un aggregatore DEX che è stato verificato da più società diverse, che aumenta la fiducia degli utenti nella piattaforma e sottolinea che il team di 1inch ha un forte impegno nel garantire la sicurezza della sua comunità.

Le società di auditing blockchain avranno un team di ingegneri in grado di svolgere attività come:

• Security Audit
• Analisi degli strumenti
• Revisione manuale del codice
• Esegui e scrivi test automatizzati
• Conduci concorsi Bug Bounty

Mentre altre società di revisione come Ackee Blockchain possono anche soddisfare requisiti più "servizio completo" e aiutare in aree aggiuntive come:

• Creazione di contratti intelligenti sicuri su solidità o ruggine
• Aiuta a costruire un ecosistema completo, gestendo UX, design, frontend, backend e DevOps

Ackee Blockchain contribuisce anche all'industria blockchain nel suo insieme, il che è fantastico da vedere. Hanno sviluppato strumenti di sicurezza open source che chiunque può utilizzare e sono appassionati di insegnamento e di opportunità per aspiranti sviluppatori blockchain. In passato, hanno ospitato corsi online per sviluppatori che vogliono lavorare in blockchain e hanno persino ricevuto una sovvenzione dalla Fondazione Solana per gestire un scuola estiva per Solana.

Il team offre scuole estive online dove insegna Solidity e, nell'autunno del 2022, il CEO e co-fondatore di Ackee Blockchain Josef Gattermayer, Ph.D. insegnerà argomenti sullo sviluppo della blockchain al Università tecnica ceca di Praga. Vale sicuramente la pena contattare il team di Ackee, iscrizione ai corsi sul loro sito e seguirli se sei interessato a un futuro nello sviluppo e nella sicurezza della blockchain.

Come puoi vedere, l'auditing blockchain può essere qualcosa di più di un semplice nerd in una stanza buia e setacciare il codice, c'è un intero ecosistema incapsulato all'interno della nicchia.

Perché il controllo blockchain è importante?

Se gli esseri umani fossero perfetti, non ci sarebbe bisogno di società di auditing blockchain poiché ogni riga di codice sarebbe scritta in modo impeccabile e completamente impermeabile a exploit, errori e attacchi.

Ciò che è anche peggio degli errori degli umani è che le persone possono essere corrotte e maliziose. Un evento abbastanza frequente è che i malintenzionati inseriscano intenzionalmente codice dannoso nel loro protocollo che consentirà loro di sfruttare una piattaforma che hanno creato per rubare i fondi degli utenti.

Tra errore umano e intento dannoso, i contratti intelligenti e le applicazioni blockchain/DApp sono soggetti ai seguenti rischi:

• Attacchi Denial of Service che rendono il protocollo inutilizzabile.
• Rug pulls/furto backdoor in cui i fondatori inseriscono codice dannoso che consente loro di prelevare fondi inseriti in uno smart contract.
• Sfruttare il codice in modi che avvantaggiano l'hacker e danneggiano gli utenti, come coniare nuovi token al di fuori dei metodi previsti o drenare i fondi dei clienti dai contratti intelligenti.
• Alcuni hacker vogliono semplicemente "guardare il mondo bruciare" e sfrutteranno qualsiasi errore che riescono a trovare per danneggiare una piattaforma.

Molti utenti DeFi considerano una delle cose più importanti da cercare in una piattaforma DeFi è se il codice è open-source o meno. Questo è un ottimo primo passo poiché molti progetti pubblicheranno il codice su un sito pubblico come Github, dove chiunque può entrare e controllare/verificare il codice da solo.

Quando si guarda la pagina GitHub di un progetto, questa è spesso una delle cose che gli utenti che stanno considerando di utilizzare una DApp cercano, usando di nuovo 1 pollice come esempio:

Questo è un buon approccio iniziale da adottare quando si verifica l'autenticità di un protocollo poiché è qui che i membri della comunità o chiunque altro può entrare e verificare che non vi sia codice dannoso nascosto.

È anche utile sapere che chiunque può pubblicare qualsiasi cosa su GitHub. Il codice pubblicato in GitHub non conferma automaticamente che si tratta dello stesso codice che esegue lo smart contract. Fortunatamente, gli utenti possono verificarlo accedendo a un block explorer come Etherscan e verificando che il codice in GitHub sia effettivamente distribuito e utilizzato. Ecco il Gettone da 1 pollice in Etherscan, Per esempio. Tendo ad essere d'accordo con l'idea che la pubblicazione open source su GitHub sia un buon segno, ma per me, quando faccio clic su GitHub per dare un'occhiata, tutto ciò che vedo è:

Quindi, invece del mio cervello che frigge come un uovo su un marciapiede caldo cercando di capirlo, mi piace vedere che un team di professionisti di una società di auditing blockchain ha perlustrato tutto questo e gli ha dato il pollice in su.

È importante chiarire una cosa, ed è che solo perché un protocollo è stato verificato, ciò non significa che sia sicuro al 100%. Nessun codice può mai essere considerato completamente impermeabile ai tentativi di hackeraggio poiché gli strumenti e le abilità degli hacker stanno diventando sempre più sofisticati. Proprio come gli hacker white-hat (bravi) e gli sviluppatori blockchain stanno migliorando e si evolvono continuamente, così sono i cattivi.

Puoi pensarlo come un gioco del gatto e del topo, scrivere codice è essenzialmente come costruire un puzzle creativo e risolvere problemi, e gli hacker sono alla ricerca di modi per risolvere o attaccare il puzzle in modi sempre più intelligenti e sofisticati, quindi ci sarà rimanere sempre un elemento di rischio.

Perché il 2022 è stato particolarmente negativo per gli exploit crittografici

Quando vediamo titoli come questo:

Può essere abbastanza straziante. L'industria delle criptovalute ha ricevuto un serio occhio nero poiché ogni settimana sembra esserci un altro enorme hack o exploit con conseguente perdita di milioni di fondi.

Questo non è solo triste in quanto si tratta di persone normali che perdono i loro soldi, ma anche preoccupanti poiché questi attacchi stanno sottoponendo l'intera industria delle criptovalute a critiche sempre più dure, rallentando l'adozione, tenendo lontani gli investitori e fornendo ai governi le scuse di cui hanno bisogno per aumentare la loro autorevolezza controllo per “proteggere” gli investitori, spesso imponendo misure draconiane che molti di noi si sono rivolti alle criptovalute per sfuggire.

La ragione principale di ciò si riduce alla sciatta ingegnerizzazione degli sviluppatori.

Quando mi sono seduto con Josef di Ackee, ho chiesto la sua opinione sul motivo per cui ci sono stati numeri record di exploit, la sua spiegazione aveva senso.

Parafrasando pesantemente, Josef ha continuato spiegandomi che l'industria delle criptovalute sta crescendo rapidamente e c'è una corsa feroce tra i team per lanciare i loro prodotti. Mancano sviluppatori blockchain qualificati ed esperti in grado di soddisfare la domanda, con il risultato che molti progetti assumono sviluppatori alle prime armi e hanno un atteggiamento "abbastanza buono", lanciando DApp senza che vengano eseguiti i controlli e gli audit adeguati.

Josef ha anche spiegato che la necessità di servizi di auditing blockchain è alle stelle e non ci sono abbastanza società di auditing blockchain per soddisfare la domanda dei progetti. Ciò ha portato i team di progetto a non voler aspettare che un team di auditing diventi disponibile, quindi vanno avanti e lanciano o rilasciano un aggiornamento, senza un audit o facendo affidamento su un audit scaduto che non copre la nuova versione o iterazione di una piattaforma.

Questo tema era particolarmente presente durante la corsa al rialzo del 2021, ma le cose sono molto più rilassate ora che siamo in un mercato ribassista. I progetti non hanno fretta di essere lanciati e ci sono meno progetti nel collo di bottiglia dell'auditing. È vero che i mercati ribassisti sono il momento di costruire e i team tendono ad adottare un approccio più diligente durante i periodi di mercato più lenti.

Abbiamo esaminato due specifici attacchi riusciti che sono accaduti per indagare esattamente su cosa è successo, per aiutare a mettere tutto questo in prospettiva.

L'hack di Ethereum DAO del 2016

In sostanza, quello che è successo qui è stato qualcosa di noto come bug di rientro. Per dirla semplicemente, il codice esegue due istruzioni:

1. Ritirare
2. Aggiorna saldo

Se eseguito cronologicamente, funziona come dovrebbe. Ma poiché Ethereum è un sistema distribuito (a differenza dei programmi web2), il contratto può essere chiamato da un altro contratto che offre un'opzione per implementare una funzione di callback personalizzata che viene chiamata dall'istruzione di ritiro.

E questa funzione di callback implementata dall'hacker richiama il contratto ancora e poi ancora più volte prima che l'istruzione di aggiornamento del saldo venga finalmente eseguita. Ciò consente all'attaccante di ritirarsi più volte.

Questo è un errore frequente commesso dagli sviluppatori web3 alle prime armi. Anche 5 anni dopo questo attacco, il problema continua a sorgere dal fatto che gli sviluppatori non si sono presi il tempo di imparare da questo caso. La soluzione è abbastanza semplice in questo caso, e cioè mettere queste due righe di codice nell'ordine opposto. Primo aggiornamento, poi ritiro.

Gli auditor cercano problemi noti come questo durante l'audit di un protocollo.

Attacco al tunnel spaziale di Solana 2022

Il 2022 non è iniziato bene con il primo grande attacco avvenuto a Solana all'inizio di febbraio. L'attaccante ha aggirato una verifica della firma in un programma Rust, quindi sembrava che i guardiani avessero firmato un deposito di 120 ETH in Wormhole su Solana, anche se non l'avevano fatto. L'attaccante ha quindi coniato 120k di ETH avvolto su Solana.

Prima di questo attacco wormhole, molti nella comunità delle criptovalute pensavano che lo sviluppo di Solana e Rust fosse troppo difficile da imparare per attirare sviluppatori dilettanti. Ciò ha portato alla convinzione che solo i migliori sviluppatori lavorassero su Solana, il che significa che non c'era un forte bisogno di audit. Dopo questo attacco, Josef ha affermato che lui e il suo team hanno visto un aumento significativo delle richieste di audit per le DApp e i protocolli Solana.

Dopo tutto questo, potresti pensare che se gli esseri umani sono la fonte di errori e intenzioni dannose, non avrebbe senso avere solo computer e macchine di intelligenza artificiale che difficilmente commettono errori e incapaci di intenzioni dannose, basta scrivere tutto questo codice per noi?

Questa è un'ottima domanda e, a causa di articoli come quello sopra, anche questo è qualcosa che mi è passato per la testa. Lo tratteremo nella prossima sezione.

Il futuro della sicurezza blockchain

È evidente che ci stiamo muovendo verso un futuro in cui molti dei nostri lavori saranno esternalizzati a computer e programmi di intelligenza artificiale che possono svolgere il lavoro degli esseri umani molto meglio di noi.

Lo vediamo già con i cassieri automatizzati e le fabbriche di produzione di automobili che hanno più robot che umani. I computer stanno anche assumendo lavori altamente specializzati come medici e farmacisti, poiché un robot può essere più preciso con un bisturi e un programma per computer può perlustrare l'intero database di medicinali e in pochi secondi compilare rapporti su quali medicinali possono e non possono mescolarsi con altre sostanze chimiche e medicinali, un compito impossibile per un essere umano.

Pensavo per certo che la programmazione e lo sviluppo sarebbero stati uno dei primi lavori sostituiti dai computer. Se sono tutte lettere e numeri su uno schermo costruito in modo da completare determinati compiti, allora sicuramente un computer potrebbe farlo meglio di un essere umano, con meno errori, giusto?

Pensavo che le società di auditing blockchain avrebbero seguito la strada dell'uccello Dodo (estinto), poiché una volta che i computer inizieranno a svilupparsi autonomamente, non ci saranno errori da trovare. Ciò ha evidenziato quanto poco sapevo sullo sviluppo poiché il team di Ackee ha spiegato alcuni concetti che non avevo apprezzato.

Gran parte dello sviluppo della blockchain consiste nella risoluzione dei problemi e nella visione a 360 gradi di un problema. Ci vuole una grande quantità di creatività e pensare "fuori dagli schemi" che i computer non sono in grado di fare. Non è così semplice come "quando accade 'X', esegui 'Y'".

Dobbiamo anche considerare che molte di queste DApp e applicazioni stanno cercando di risolvere problemi "umani" e come interagiamo con sistemi, protocolli e procedure. Scusa piccolo Butter Bot, ma non sei tagliato per capire i problemi umani e fornire soluzioni umane.

Non solo i lavori nello sviluppo della blockchain e nella sicurezza stanno salendo alle stelle, ma sembra che ci sarà bisogno di questi ruoli negli anni a venire.

Questo non vuol dire che non ci sia automazione nello spazio di sviluppo web3 però. Ci sono molti strumenti gratuiti per gli sviluppatori che forniscono loro un feedback sulla sicurezza e aiutano a scaricare parte del lavoro in modo che gli sviluppatori possano concentrarsi su altre attività.

Ad esempio, su Ethereum è presente un buon analizzatore di codice statico denominato Strisciare questo è molto popolare e Ackee Blockchain sta lavorando sul proprio analizzatore statico open source chiamato Woke, che rileva le cose in modo diverso rispetto a Slither, riducendo l'onere di dover analizzare manualmente il codice.

Il team di Ackee ha anche scoperto una tendenza su Solana per quanto riguarda un problema con i test. Gli sviluppatori non ne scrivevano abbastanza perché è piuttosto laborioso, con la necessità di scrivere molto codice standard. Quindi, Ackee Blockchain ha guidato un progetto in cui hanno scritto un framework di test open source per Solana chiamato Trdelnik che consentirà agli sviluppatori di scrivere test più facilmente. La squadra ha ricevuto una menzione d'onore e ha vinto un premio Marinade durante a hackathon a Praga per Trdelnik.

Tutto ciò ci mostra che è probabile che l'automazione e i computer svolgano un ruolo sempre più importante nell'assistere gli sviluppatori blockchain e gli auditor della sicurezza, ma è improbabile che li sostituiscano presto.

Il sentimento generale tra gli sviluppatori blockchain è che molti di questi hack ed exploit sono il risultato di questo settore ancora giovane e inesperto. Poiché l'industria blockchain continua ad evolversi e maturare, dovrebbero esserci sempre meno exploit, con il risultato che lo spazio crittografico generale diventa più sicuro e facile da usare.

Bene, ora entriamo nelle cose buone, il principale asporto di questo articolo.

Come verificare che una piattaforma sia stata controllata

Il primo passo è assicurarsi effettivamente che ci sia un audit da trovare. Questi possono essere trovati nel repository GitHub del progetto e qualsiasi audit condotto dovrebbe essere chiaramente menzionato nei documenti del progetto o sul sito Web della piattaforma stessa. Se non riesci a trovare alcuna menzione di un audit, me ne starei lontano.

Nessun audit disponibile al pubblico probabilmente significa che:

• Non è stato condotto alcun audit
• C'è stato un audit fallito che il progetto non vuole essere conosciuto
• L'audit ha rilevato problemi che il team non ha affrontato
• Il codice contiene percorsi backdoor dannosi che potrebbero portare al furto

Come accennato in precedenza, è anche bello vedere che il codice è open source essendo etichettato come "pubblico" su GitHub. Questo non è un requisito, ma è comunque un bonus. Tuttavia, ci sono ragioni per non aprire il codice, quindi non è sempre un rompicapo. I motivi per non aprire il codice possono essere cose come:

• Aziende che desiderano mantenere un vantaggio competitivo. Non appena un'azienda rende open source il proprio codice, chiunque può creare lo stesso protocollo e competere. Questo è il motivo per cui Coca-Cola mantiene segreta la sua ricetta e KFC ha notoriamente le sue "11 erbe e spezie Top Secret".
• Una volta che un codice è pubblico, gli hacker possono utilizzare le informazioni per cercare exploit. Sebbene le buone pratiche facciano il contrario, se un progetto è sicuro del suo codice, lo pubblicheranno.
• I primi progetti potrebbero non voler rendere immediatamente open source il loro codice fino a quando non avranno creato una vasta comunità e un numero sufficiente di utenti, creando un ostacolo per potenziali concorrenti.

Di recente ho incontrato un team di progetto che si è pentito subito di aver aperto la propria piattaforma, poiché un'azienda concorrente ha semplicemente copiato il codice e il modello di business e aveva più fondi per pagare gli influencer e i follower. Ciò ha fatto sembrare che l'azienda concorrente fosse la piattaforma migliore sin dal lancio poiché dava l'impressione di più utenti e un seguito più ampio. L'azienda concorrente è ora significativamente in vantaggio rispetto al team fondatore originale che ha scelto di crescere in modo più organico ed etico.

Ecco un'ottima visuale da Ponte globale che riassume alcune delle differenze generalizzate tra software open-source e closed-source:

Confrontando i portafogli hardware più diffusi, è possibile trovare due approcci interessanti al codice sorgente aperto e chiuso Trezor. ed Ledger. Trezor ha scelto di pubblicare il 100% del suo codice sorgente al pubblico affinché chiunque possa verificarlo, mentre Ledger ha scelto di giocare le sue carte più vicino al petto e di rendere open source del codice, ma mantenere il suo firmware chiuso.

Ciò ha portato molti elitisti blockchain a scegliere Trezor su Ledger poiché sentivano che Ledger avrebbe dovuto creare codice open source, chiedendosi cosa stessero cercando di nascondere. Personalmente non lo vedo come un motivo di preoccupazione poiché Ledger ha dimostrato la propria esperienza e dedizione allo spazio ed è cresciuto fino a diventare uno dei più grandi fornitori di portafogli hardware al mondo, creando alcuni dei più alti sistemi di archiviazione sicura per criptovalute dispositivi.

Una volta che un audit è stato condotto e localizzato, purché sia ​​stato reso pubblico, chiunque può aprire il documento e trovare i risultati dell'audit. Invece di scorrere l'intero documento di revisione, per il nostro semplice scopo, tutto ciò che dobbiamo cercare è la pagina "Riepilogo esecutivo", che spesso assomiglia a questa:

Questa pagina si troverà all'inizio o alla fine del rapporto. È una pagina che mostra i risultati dell'audit in un formato semplice che la persona media può capire. Immergiamoci nelle informazioni che questo ci sta mostrando.

L'audit è recente? Gli audit dovrebbero essere un servizio continuo e dovrebbe esserci sicuramente un nuovo audit in corso per OGNI aggiornamento, versione o nuova funzionalità/funzione introdotta. Se è stata avviata una nuova funzionalità o versione, i risultati dell'audit precedente non sono più validi poiché è probabile che la base di codice sia cambiata.

Questo può essere verificato guardando la versione del progetto e/o l'hash del commit. La versione è qualcosa come quando vedi Uniswap "V2" (versione 2) e l'hash del commit identifica una revisione nel repository del codice sorgente. Quando esaminano la versione o l'hash di commit mostrato nell'audit, che può essere visto nell'immagine sopra nella tabella con l'intestazione "repository", gli utenti possono verificare che coincida con la versione o l'hash di commit mostrato in GitHub.

Sarà simile a questo:

Ecco un altro sguardo da uno degli Ackee Blockchain Audits:

Tuttavia, se l'hash del commit non corrisponde, ciò non significa necessariamente che ci sia una bandiera rossa. L'hash del commit sul GitHub del progetto cambierà ogni volta che viene apportata una nuova regolazione o iterazione. Ogni aggiustamento cambierà l'hash del commit e non dovrebbe essere motivo di preoccupazione se c'è stato solo un aggiustamento minore.

Se non vedi l'hash del commit dall'audit nella pagina principale di GitHub, puoi andare nella "Cronologia del commit" e cercare l'hash del commit e vedere di persona quanto è cambiato da quando è stato condotto l'audit.

Questo può essere fatto cliccando qui:

Allora facendo una ricerca qui:

Poiché un nuovo hash di commit viene compilato per ogni modifica, ciascuno con una data e un'ora, se c'è stato un numero significativo di nuovi commit tra il momento in cui è stato condotto l'audit e l'hash di commit su cui è attualmente attivo il progetto, puoi vogliono considerare di aspettare fino a quando non viene condotto un altro audit prima di essere coinvolti.

Se hai un occhio analitico e vuoi approfondire, puoi fare clic su ogni nuovo hash di commit e confrontare il vecchio codice mostrato in rosso con il nuovo codice mostrato in verde e verificare tu stesso cosa è cambiato esattamente:

Se noti un nuovo hash di commit diverso da quando è stato condotto l'audit e vedi qualcosa del genere:

Questa è una di quelle modifiche insignificanti che ho menzionato e, sebbene abbia popolato un nuovo hash di commit, non è nulla di cui preoccuparsi poiché si trattava di una semplice ridenominazione di un file. L'immagine GitHub sopra mostra 0 aggiunte e 0 eliminazioni.

Passiamo ora alla prossima cosa da cercare nell'Executive Summary:

Questioni - L'Executive Summary mostra tutti i problemi che sono stati scoperti durante l'audit e, soprattutto, se il team ha risolto i problemi. Questa sezione può essere vista nella parte inferiore dove mostra "Problemi totali", quindi li suddivide in gravità e se sono stati risolti o meno. La società di auditing prima identifica i problemi, li segnala al team di sviluppo, quindi controlla di nuovo il codice una volta che gli sviluppatori affrontano i problemi prima che il team di auditing segni il problema come "risolto".

Chiaramente, tutti i problemi contrassegnati come "Critici" o "Ad alto rischio" dovrebbero essere risolti. Anche se il rapporto mostra che tutti i problemi critici o ad alto rischio sono stati risolti, ciò va comunque notato con un certo scetticismo sul progetto. Se il team di auditing ha riscontrato un numero elevato di problemi critici per cominciare, ciò può evidenziare che il team di sviluppatori dietro il progetto potrebbe essere piuttosto alle prime armi, portando a ulteriori e ulteriori problemi lungo la strada.

I problemi a medio o basso rischio sono comuni e normalmente non sono motivo di preoccupazione. Il team di auditing può anche contrassegnare qualcosa come un problema a basso rischio se stanno semplicemente suggerendo un'alternativa o hanno una divergenza di opinioni su come affrontare qualcosa.

Ecco un riassunto del significato di ciascuna delle categorie:

critico – Qualsiasi cosa contrassegnata come critica significa che qualcosa è sfruttabile in questo momento.

Il team di Ackee Blockchain mi ha raccontato la storia di un audit che stavano conducendo in cui hanno riscontrato un problema critico su un protocollo che era già stato lanciato. Hanno svegliato il team di sviluppo del progetto alle 5 del mattino in un'emergenza "tutte le mani sul ponte" per riparare il codice il prima possibile. Fortunatamente, hanno individuato il problema in tempo prima che gli hacker fossero in grado di identificare la vulnerabilità.

Gravità elevata – Problemi che non sono sfruttabili ora, ma potrebbero esserlo se alcune sequenze specifiche sono soddisfatte.

Da medio a basso – Si tratta spesso di piccole modifiche necessarie o raccomandazioni e non necessariamente di minacce alla sicurezza.

Diverse società di revisione scriveranno anche riepiloghi esecutivi in ​​formati diversi. L'executive summary sopra riportato è stato redatto dalla società di revisione Quantistamp. Ackee Blockchain fornisce il PDF con l'audit e un riepilogo web che combina i risultati iniziali e di follow-up in un formato più semplice da leggere. Puoi trovarne un esempio nel loro Riepilogo audit.

Altre cose da cercare:

• Un audit è stato completato da più di una società? Più occhi cercano problemi, minori sono le possibilità che esista un difetto nel codice.
• La società di auditing blockchain è professionale e rispettata nella comunità? Se non hai mai sentito parlare della società di revisione prima, dai un'occhiata al loro sito Web e cerca altri progetti su cui hanno lavorato. Alcune delle piattaforme che hanno verificato sono affidabili? Verificare se una delle piattaforme è stata sfruttata dopo che l'azienda ha eseguito un audit, questo potrebbe evidenziare un track record di scarse capacità di auditing. Cerca cose come hackathon vinti e supporto/sovvenzioni dalle basi di rete di livello 1.

Un buon esempio di ciò è Ackee Blockchain, a cui sono state assegnate sovvenzioni ufficiali per lo sviluppo/comunità da quattro fondazioni chiave: Coinbase Giving, Ethereum Foundation, Solana Foundation e Tezos Foundation.

Se sei una persona che è diventata comprensibilmente diffidente in questa epoca di disinformazione, se vedi un'affermazione come l'immagine sopra tratta dal sito Web di Ackee Blockchain, invece di crederci sulla parola, puoi sempre navigare sui siti delle fondazioni menzionato e verificare personalmente le affermazioni.

Il motivo per cui lo dico è perché, nei miei anni in cui ho scritto recensioni, il numero di siti Web che affermano "In primo piano su Forbes o Yahoo Finance", quando non lo sono mai stati, è schiacciante. Vorrei che ci fosse una qualche forma di polizia di Internet che potesse trascinare le aziende in prigione per Internet per affermazioni ingannevoli e fuorvianti del genere. Ecco perché nelle criptovalute c'è un detto "non fidarti, verifica". Non preoccuparti, Ackee controlla e in realtà è considerato affidabile dalle basi di cui sopra, ho controllato 😉

Pensieri di chiusura

Beh, il gioco è fatto. Alcune informazioni sulla sicurezza blockchain che spero tu abbia trovato utili. Spero che questo articolo ti aiuti a sentirti più sicuro di avventurarti nel mondo delle criptovalute con un ulteriore strato di armatura e di essere in grado di navigare nelle acque delle criptovalute in modo più sicuro di prima. So che sarò diligente nel verificare queste informazioni la prossima volta che selezionerò quali DApp e protocolli scelgo di affidare alle mie risorse crittografiche.

Come si suol dire, "in cripto, non conta quanto guadagni, ma quanto tieni", poiché sfortunatamente molti di noi vecchi veterani della criptovaluta hanno perso più della nostra giusta quota di Satoshi in una miriade di hack, truffe, furti, fallimenti, ecc. Maggiore è la conoscenza che abbiamo, meglio possiamo proteggerci da molti dei gravi rischi che esistono in questo nuovo e bizzarro mondo delle criptovalute in erba.

Disclaimer: queste sono le opinioni dello scrittore e non dovrebbero essere considerate un consiglio di investimento. I lettori dovrebbero fare le proprie ricerche.