Lista di controllo per l'integrazione dei token

Segui questa lista di controllo quando interagisci con token arbitrari. Assicurati di comprendere i rischi associati a ciascun elemento e giustifica eventuali eccezioni a queste regole.

Per comodità, tutte le utilità (opens in a new tab) di Slither possono essere eseguite direttamente su un indirizzo del token, come ad esempio:

Tutorial sull'utilizzo di Slither

slither-check-erc 0xdac17f958d2ee523a2206206994597c13d831ec7 TetherToken

Per seguire questa lista di controllo, ti servirà questo output di Slither per il token:

- slither-check-erc [target] [contractName] [optional: --erc ERC_NUMBER]
- slither [target] --print human-summary
- slither [target] --print contract-summary
- slither-prop . --contract ContractName # richiede configurazione, e l'uso di Echidna e Manticore

Considerazioni generali

• Il contratto ha una revisione di sicurezza. Evita di interagire con contratti privi di una revisione di sicurezza. Controlla la durata della valutazione (nota anche come "livello di impegno"), la reputazione dell'azienda di sicurezza e il numero e la gravità dei problemi riscontrati.
• Hai contattato gli sviluppatori. Potresti dover avvisare il loro team di un incidente. Cerca i contatti appropriati su blockchain-security-contacts (opens in a new tab).
• Hanno una mailing list di sicurezza per gli annunci critici. Il loro team dovrebbe avvisare gli utenti (come te!) quando vengono rilevati problemi critici o quando si verificano aggiornamenti.

Conformità ERC

Slither include un'utilità, slither-check-erc (opens in a new tab), che esamina la conformità di un token a molti standard ERC correlati. Usa slither-check-erc per verificare che:

• Transfer e transferFrom restituiscano un booleano. Diversi token non restituiscono un booleano su queste funzioni. Di conseguenza, le loro chiamate nel contratto potrebbero fallire.
• Le funzioni name, decimals e symbol siano presenti se utilizzate. Queste funzioni sono opzionali nello standard ERC-20 e potrebbero non essere presenti.
• decimals restituisca un uint8. Diversi token restituiscono erroneamente un uint256. In tal caso, assicurati che il valore restituito sia inferiore a 255.
• Il token mitighi la nota race condition di ERC-20 (opens in a new tab). Lo standard ERC-20 ha una nota race condition che deve essere mitigata per impedire agli aggressori di rubare token.
• Il token non sia un token ERC-777 e non abbia chiamate a funzioni esterne in transfer e transferFrom. Le chiamate esterne nelle funzioni di trasferimento possono portare a rientranze (reentrancy).

Slither include un'utilità, slither-prop (opens in a new tab), che genera test unitari e proprietà di sicurezza in grado di scoprire molti difetti comuni degli ERC. Usa slither-prop per verificare che:

• Il contratto superi tutti i test unitari e le proprietà di sicurezza di slither-prop. Esegui i test unitari generati, quindi controlla le proprietà con Echidna (opens in a new tab) e Manticore (opens in a new tab).

Infine, ci sono alcune caratteristiche che sono difficili da identificare automaticamente. Controlla manualmente queste condizioni:

• Transfer e transferFrom non dovrebbero prelevare una commissione. I token deflazionistici possono portare a comportamenti imprevisti.
• I potenziali interessi guadagnati dal token sono presi in considerazione. Alcuni token distribuiscono interessi ai possessori dei token. Questi interessi potrebbero rimanere bloccati nel contratto se non vengono presi in considerazione.

Composizione del contratto

• Il contratto evita complessità inutili. Il token dovrebbe essere un contratto semplice; un token con codice complesso richiede uno standard di revisione più elevato. Usa lo strumento human-summary printer (opens in a new tab) di Slither per identificare il codice complesso.
• Il contratto utilizza SafeMath. I contratti che non utilizzano SafeMath richiedono uno standard di revisione più elevato. Ispeziona manualmente il contratto per verificare l'uso di SafeMath.
• Il contratto ha solo poche funzioni non correlate al token. Le funzioni non correlate al token aumentano la probabilità di un problema nel contratto. Usa lo strumento contract-summary printer (opens in a new tab) di Slither per esaminare a grandi linee il codice utilizzato nel contratto.
• Il token ha un solo indirizzo. I token con punti di ingresso multipli per gli aggiornamenti del saldo possono interrompere la contabilità interna basata sull'indirizzo (ad es., balances[token_address][msg.sender] potrebbe non riflettere il saldo effettivo).

Privilegi del proprietario

• Il token non è aggiornabile. I contratti aggiornabili potrebbero cambiare le loro regole nel tempo. Usa lo strumento human-summary printer (opens in a new tab) di Slither per determinare se il contratto è aggiornabile.
• Il proprietario ha capacità di conio limitate. I proprietari malintenzionati o compromessi possono abusare delle capacità di conio. Usa lo strumento human-summary printer (opens in a new tab) di Slither per esaminare le capacità di conio e valuta la possibilità di rivedere manualmente il codice.
• Il token non può essere messo in pausa. I proprietari malintenzionati o compromessi possono intrappolare i contratti che si basano su token che possono essere messi in pausa. Identifica manualmente il codice che può essere messo in pausa.
• Il proprietario non può inserire il contratto in una lista nera (blacklist). I proprietari malintenzionati o compromessi possono intrappolare i contratti che si basano su token con una lista nera. Identifica manualmente le funzionalità di inserimento in lista nera.
• Il team dietro al token è noto e può essere ritenuto responsabile per eventuali abusi. I contratti con team di sviluppo anonimi o che risiedono in paradisi legali dovrebbero richiedere uno standard di revisione più elevato.

Scarsità del token

Le revisioni per i problemi di scarsità del token richiedono una revisione manuale. Controlla queste condizioni:

• Nessun utente possiede la maggior parte dell'offerta. Se pochi utenti possiedono la maggior parte dei token, possono influenzare le operazioni in base alla ripartizione del token.
• L'offerta totale è sufficiente. I token con una bassa offerta totale possono essere facilmente manipolati.
• I token si trovano in più di qualche exchange. Se tutti i token si trovano in un solo exchange, una compromissione dell'exchange può compromettere il contratto che si basa sul token.
• Gli utenti comprendono i rischi associati a fondi ingenti o ai prestiti lampo (flash loan). I contratti che si basano sul saldo del token devono prendere attentamente in considerazione gli aggressori con fondi ingenti o gli attacchi tramite prestiti lampo.
• Il token non consente il conio lampo (flash minting). Il conio lampo può portare a oscillazioni sostanziali nel saldo e nell'offerta totale, il che necessita di controlli di overflow rigorosi e completi nel funzionamento del token.