Uma Audit – Fase 6

Introduzione

UMA è una piattaforma che consente agli utenti di stipulare contratti finanziari a fiducia ridotta sulla blockchain di Ethereum. Abbiamo precedentemente effettuato un audit l'oracolo decentralizzato, un particolare modello di contratto finanziario, alcune richieste pull ad hoc, il modello multipartitico perpetuo, varie richieste pull incrementali nel corso di un impegno più lungo ed il ponte assicurato.

In questo audit abbiamo esaminato un nuovo contratto di proposta di governance, un meccanismo per estendere l'ecosistema UMA su più catene, un meccanismo per distribuire i premi ai possessori di token ERC721 in conformità con una specifica off-chain e un aggiornamento al ponte assicurato per supportare WETH sulla catena dell'ottimismo.

Il commit controllato è 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc e l'ambito di applicazione comprende i seguenti contratti:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (esclusi i contratti test e Polygon)
• financial-templates/optimistic-rewarder/* (esclusi i contratti di prova)

Abbiamo anche esaminato le modifiche ai file di solidità in Richiesta pull 3611.

Si presumeva che tutto il codice esterno e le dipendenze del contratto funzionassero come documentato.

Panoramica del sistema

L'attuale Governance Il contratto consente alla Fondazione Risk Labs di proporre nuove azioni di governance che possono essere ratificate dai titolari dei token UMA. Il nuovo Proposer Il contratto è destinato ad assumere il ruolo di proponente, consentendo a chiunque di avanzare nuove proposte purché forniscano un vincolo che verrà sacrificato se la proposta fallisce. Non esiste alcun incentivo specifico per la presentazione delle proposte. L'intenzione è quella di garantire che vengano proposte solo le azioni che hanno maggiori probabilità di essere accettate.

Il nuovo meccanismo cross-chain consente di passare la proposta di governance dalla rete principale di Ethereum alle catene Optimism e Arbitrum. In questo modo, il meccanismo di governance UMA sul livello 1 può essere utilizzato per governare i contratti UMA sulle catene di livello 2 supportate. Il meccanismo consente inoltre di inoltrare richieste di prezzo e risoluzioni tra i livelli, in modo che gli oracoli ottimistici sulle catene di livello 2 possano essere protetti dal meccanismo di verifica dei dati della rete principale nello stesso modo in cui l'oracolo ottimistico di livello 1 è protetto dal DVM.

È interessante notare che questi messaggi vengono inviati utilizzando la meccanica del bridge nativo, il che significa che sono limitati dalle caratteristiche delle relative catene di livello 2. In particolare, i messaggi dal livello 2 al livello 1 potrebbero impiegare una settimana o più per attraversare il bridge. Inoltre, il meccanismo di governance dell’UMA supporta proposte che includono più transazioni ordinate, ma ciò limita semplicemente l’ordine in cui possono essere aggiunte al bridge. È possibile che alcune di queste transazioni vengano eseguite in un ordine diverso, o non vengano eseguite affatto, sul livello 2.

Il contratto Optimistic Rewarder conia semplicemente token ERC721 per chiunque ne faccia richiesta. Consente inoltre a chiunque di associare dati arbitrari a qualsiasi token e di depositare vari token ERC20 da distribuire come ricompensa. L'interpretazione dei dati arbitrari e la distribuzione prevista delle ricompense tra i possessori di token sono determinate utilizzando una procedura off-chain non specificata. Chiunque può affermare che a uno specifico token ERC721 è dovuta una serie di premi se è disposto a depositare un'obbligazione. Il meccanismo Optimistic Oracle standard viene utilizzato per consentire a qualcun altro di contestare il reclamo, che verrà risolto dal DVM. Si presuppone che i reclami non contestati in tempo siano validi e il contratto distribuisce i premi di conseguenza. L'unica restrizione (per semplificare la contabilità) è che il token Oracle Bond non può essere utilizzato come token di ricompensa.

Infine, PR3611 modifica il meccanismo del bridge assicurato per evitare di inviare WETH attraverso il token bridge Optimism, che non è supportato. Invece, qualsiasi L2 WETH depositato nella cassetta di deposito Optimism viene scartato in L2 ETH prima di transitare sul bridge. Sul livello 1, l'ETH viene convertito in WETH prima di essere inoltrato al bridge pool WETH.

Gravità critica

[C01] Impossibile contestare il premio non valido

Quando si contesta una richiesta di ricompensa, il OptimisticRewardBase contratto prima innesca una proposta sul SkinnyOptimisticOracle e poi contesta tale proposta. Tuttavia, la proposta imposta il tempo di scadenza come offset rispetto al tempo corrente (controversia), mentre la controversia specifica la scadenza come spostamento rispetto al momento della richiesta di ricompensa originale. Nella maggior parte dei casi, questa discrepanza impedirà all'oracolo di identificare la proposta da contestare, il che significa che le controversie valide non verranno elaborate e le richieste di ricompensa non valide verranno accettate.

Valuta la possibilità di aggiornare la richiesta di contestazione per specificare correttamente la proposta da contestare.

Aggiornare: Risolto al momento del commit 9e15557 in PR3690.

[C02] Risolvere ripetutamente le proposte

I resolveProposal funzione del Proposer contratto semplicemente convalida che l'oracolo ha risolto, ma non controlla se il vincolo è stato distribuito. Ciò significa che la stessa proposta può essere risolta più volte, con conseguente duplicazione dei pagamenti delle obbligazioni. Valuta la possibilità di contrassegnare o eliminare le proposte esistenti una volta risolte.

Aggiornare: Risolto al momento del commit b152718 in PR3689.

Elevata gravità

Nessuno.

Gravità media

[M01] Parametri evento errati

I OptimisticRewarderBase il contratto definisce a Requested evento che viene emesso dal requestRedemption funzione quando viene richiesto un riscatto. Questo evento è definito per emettere il file termine di scadenza del riscatto come ultimo parametro. Tuttavia, quando l'evento viene emesso, il suo ultimo parametro è impostato erroneamente su ora attuale.

Allo stesso modo il Redeemed evento legge l'ora di scadenza dopo che il record è stato cancellato, quindi verrà erroneamente impostato a zero.

Dato che questo evento può essere utilizzato per attivare calcoli fuori catena, valutare la possibilità di aggiornare il valore emesso in modo appropriato.

Aggiornare: Risolto al momento del commit f04eef9 in PR3694.

Bassa gravità

[L01] Mancata emissione di eventi dopo aver contestato un riscatto

I OptimisticRewarderBase il contratto definisce a Disputed evento che è destinato ad essere attivato in caso di contestazione di un rimborso. Tuttavia, questo evento non viene emesso all'interno o all'esterno del file OptimisticRewarderBase contrarre.

Valuta la possibilità di emettere l'evento dopo che si sono verificati cambiamenti sensibili nel file dispute function, per facilitare il tracciamento e avvisare i clienti off-chain in seguito all'attività dei contratti.

Aggiornare: Risolto al momento del commit c275e92 in PR3695.

[L02] Protezione di rientro incoerente

I Optimism_ParentMessenger ed Arbitrum_ParentMessenger i contratti applicano in modo incoerente il nonReentrant modificatore. Considera l'idea di includerlo in tutte le funzioni pubbliche.

Aggiornare: Risolto al momento del commit 6275c39 in PR3677.

[L03] Commenti fuorvianti

Ecco alcuni commenti fuorvianti che abbiamo identificato durante la nostra revisione:

• ChildMessengerConsumerInterface.sol:
  • Linea 5 dice "messaggero genitore" invece di "messaggero figlio"
• GovernorSpoke.sol:
  • Linee 49-51 collegamenti a un file Gnosis file anche se il commento dice che lo snippet è stato copiato da Governor.sol. Inoltre, lo snippet non è identico a quello in Governor.sol

Aggiornare: Risolto al momento del commit cc350f9 in PR3678.

[L04] Timbro dati accessori mancante

Quando si richiede un prezzo sul OracleSpoke contratto, i dati accessori forniti è timbrato con l'identificatore della catena figlio. comunque, il hasPrice ed getPrice le funzioni non stampigliano i dati accessori al momento dell'identificazione della richiesta di prezzo. Ciò costringe i contratti appaltanti ad applicare essi stessi il timbro, il che provoca un'incoerenza tra i meccanismi di richiesta del prezzo e di recupero del prezzo. Considera l'idea di applicare il timbro nel hasPrice ed getPrice funzioni.

Aggiornare: Risolto al momento del commit fdb845d in PR3668.

[L05] Parametro NatSpec mancante

Molte funzioni nel OptimisticRewarderBase contratto mancano i @return parametro nei loro commenti sulle specifiche naturali. Considera l'idea di includerlo per completezza.

Aggiornare: Risolto al momento del commit 8920f38 in PR3679.

[L06] Indennità residua

Per invocare l'Oracolo Ottimista, il OptimisticRewarderBase contratto gli concede un'indennità simbolica, in modo da poter ritirare i pagamenti delle obbligazioni. Se la proposta fallisce, il riscatto del premio viene annullato ma l'indennità non viene ripristinata. Pertanto, l'Oracolo Ottimista tratterrà un'indennità residua non necessaria fino alla successiva attivazione di una controversia. Considera la possibilità di revocare l'indennità se la proposta fallisce.

Aggiornare: Risolto al momento del commit c2d444b in PR3698.

[L07] Indirizzo per il rimborso non valido

L'indirizzo L2 del rimborso del file Arbitrum_ParentMessenger è inizializzato al titolare del contratto, che dovrebbe essere il Governatore della L1. Allo stesso modo, il setRefundL2Address ha un commento affermando che dovrebbe essere assegnato al governatore. Tuttavia, quando si passano messaggi sul bridge, questo valore è impostato come utente L2, che è l'indirizzo su Arbitrum che riceve i fondi in eccesso dopo la risoluzione del ticket. Poiché l'indirizzo del governatore L1 non sarà accessibile su Arbitrum, tutti i fondi inviati a questo indirizzo andranno persi.

Valuta la possibilità di impostarlo su un indirizzo L2 valido.

Aggiornare: Risolto al momento del commit b3f2dd1 in PR3687.

[L08] Meccanismo per cambiare i messaggeri dei bambini

I GovernorSpoke ed OracleSpoke ogni contratto inizializza il messenger figlio nel costruttore, senza alcun meccanismo per aggiornarlo. Ciò significa che quando il il messenger bambino è cambiato, entrambi i contratti diventano obsoleti.

Poiché i contratti dei raggi sono probabilmente più stabili dei messaggeri, valuta la possibilità di includere un meccanismo per aggiornare il messaggero sui raggi.

Aggiornare: Risolto al momento del commit 7c9e061 in PR3688.

Note e informazioni aggiuntive

[N01] Cambia gettone obbligazione

I Proposer contratto include un meccanismo affinché il proprietario possa modificare l'entità della cauzione proposta. Valuta se dovrebbero essere in grado di modificare anche il token obbligazionario. Si noti che ciò richiederebbe un meccanismo per identificare la valuta obbligazionaria corretta una volta risolte le proposte esistenti.

Aggiornare: Non un problema. Dichiarazione dell'UMA su questo problema:

N01 consiglia di consentire al contratto proponente di modificare il token obbligazionario in qualcosa di diverso da UMA. Non abbiamo intenzione di supportare alcun token diverso da $UMA per questa funzione e quindi abbiamo scelto di non apportare alcuna modifica per questo problema. Inoltre, un singolo token per contratto mantiene questa logica il più semplice possibile. Infine, se fosse necessaria una modifica (nel caso di una migrazione di token, ad esempio), potremmo semplicemente implementare un nuovo contratto del proponente con l'altro token e avviare una proposta per migrare il sistema per utilizzare quello.

[N02] Interfaccia incompleta

I ChildMessengerInterface non specifica a processMessageFromCrossChainParent funzione, anche se si presuppone che esista dai messaggeri principali. Considera l'idea di includerlo per completezza.

Aggiornare: Non riparato. Dichiarazione dell'UMA su questo problema:

Abbiamo scelto intenzionalmente di lasciare questa interfaccia incoerente poiché l'implementazione all'interno di ChildMessengerInterface interrompe la compatibilità con Polygon_ChildMessenger poiché il metodo di Polygon per l'elaborazione dei messaggi da altre catene richiede una logica in qualche modo personalizzata in cui viene chiamato un metodo interno chiamato _processMessageFromRoot.

[N03] Interfaccia errata

I GovernorSpoke contratto in modo errato utilizza l' ChildMessengerConsumerInterface Digitare per descriverlo messenger variabile. Considera l'utilizzo di ChildMessengerInterface anziché.

Aggiornare: Risolto al momento del commit f31a527 in PR3680.

[N04] Tira i token al negozio

In un verifica precedente abbiamo messo in dubbio lo scopo del Store contratto payOracleFeesErc20 function (nel numero L19). La squadra dell'UMA ha deciso di mantenere la funzione per standardizzare l'interfaccia per eventuali modifiche future. Poiché lo scopo della funzione non è completamente specificato, non è chiaro se debba essere attivata quando Proposer contratto confisca un vincolo. Probabilmente dovrebbe essere usato quando il OracleHub paga per una richiesta di prezzo. Valuta se la funzione deve essere utilizzata in entrambi gli scenari.

Aggiornare: Riconosciuto. Dichiarazione dell'UMA su questo problema:

N04 consiglia di utilizzare il metodo payOracleFeeErc20 dello Store per il pagamento delle commissioni sia nei contratti Proponente che OracleHub per essere coerenti con l'utilizzo dello Store. Abbiamo scelto di non utilizzare questa funzione poiché significherebbe la necessità di importare un'interfaccia aggiuntiva (per il negozio) e richiedere il trasferimento dell'importo del vincolo a un FixedPoint (che richiederebbe anche un'importazione aggiuntiva. Per mantenere il codice semplice e pulito abbiamo deciso di non farlo. Il feedback di OZ su payOracleFeeErc20 nella fase di audit 1 nell'aprile 2020 era valido e affermava che questo metodo non è realmente utile, rendendo questo tipo di integrazione più difficile su cui ragionare.

[N05] TODO nel codice

Ci sono commenti "TODO" nel codice base che dovrebbero essere tracciati nel backlog dei problemi del progetto. Per esempio:

• linea 37 of Arbitrum_ParentMessenger contratto
• linea 25 of Optimism_ChildMessenger contratto
• Linee 83 ed 146 of OracleHub contrarre.

Durante lo sviluppo, avere commenti “TODO” ben descritti renderà più semplice il processo di tracciamento e risoluzione degli stessi. Senza tali informazioni, questi commenti potrebbero tendere a marcire e informazioni importanti per la sicurezza del sistema potrebbero essere dimenticate nel momento in cui vengono rilasciate in produzione.

Questi commenti TODO dovrebbero contenere una breve descrizione dell'attività in sospeso da svolgere e un collegamento al problema corrispondente nel repository del progetto.

Valuta la possibilità di aggiornare i commenti TODO per aggiungere queste informazioni. Per completezza e tracciabilità è possibile aggiungere una firma e una marca temporale. Per esempio:

// TODO: point this at an interface instead.

// https://github.com/UMAprotocol/protocol/issues/XXXX

// --mrice32 - 20211209

Aggiornare: Risolto al momento del commit 5d57b5b in PR3684.

[N06] Errori tipografici

La codebase contiene i seguenti errori tipografici:

• Nel Admin_ChildMessenger contratto, impleenting dovrebbe essere implementing
• Nel OptimisticRewarderBase contratto, timestap dovrebbe essere timestamp.
• Nel OptimisticRewarderBase contratto, liveness liveness dovrebbe essere liveness.
• Nel GovernorSpoke contratto, only called dovrebbe essere only be called.
• Nel Optimism_ChildMessenger contrarre:

Aggiornare: Risolto al momento del commit 9b92b0b in PR3681.

[N07] Importazioni non utilizzate

Per migliorare la leggibilità del codice, valuta la possibilità di rimuovere le seguenti importazioni inutilizzate:

Aggiornare: Risolto al momento del commit 40b7221 in PR3682.

[N08] Ordinamento delle transazioni L2

I Governor assicura le transazioni all'interno di una proposta vengono eseguite in ordine. Tuttavia, quando tali transazioni coinvolgono transazioni cross-chain, ciò garantisce semplicemente che arrivino al contratto bridge L1 nell’ordine corretto. Nel caso dell'Arbitrum, possono essere riordinati prima di essere finalizzati su L2. Pertanto, le proposte di governance dovrebbero essere costruite per consentire la possibilità di transazioni L2 riordinate.

Aggiornare: Risolto al momento del commit 0fb2e7b in PR3703. GovernorHub ora può inoltrare una serie di transazioni L2.

Conclusione

Sono stati rilevati due problemi critici nel codice base. Sono stati rilevati un problema di media gravità e diverse vulnerabilità minori e sono state suggerite raccomandazioni per le correzioni.

Fonte: https://blog.openzeppelin.com/uma-audit-phase-6/?utm_source=rss&utm_medium=rss&utm_campaign=uma-audit-phase-6