Έλεγχος Uma – Φάση 6

Εισαγωγή

UMA είναι μια πλατφόρμα που επιτρέπει στους χρήστες να συνάπτουν οικονομικές συμβάσεις ελαχιστοποιημένες βάσει εμπιστοσύνης στο blockchain Ethereum. Ελέγχαμε προηγουμένως ο αποκεντρωμένος χρησμός, ένα συγκεκριμένο πρότυπο χρηματοοικονομικής σύμβασης, ορισμένα ad hoc αιτήματα έλξης, το πρότυπο Perpetual Multiparty, διάφορα αυξητικά αιτήματα έλξης για μεγαλύτερη αφοσίωση και την ασφαλισμένη γέφυρα.

Σε αυτόν τον έλεγχο εξετάσαμε μια νέα σύμβαση πρότασης διακυβέρνησης, έναν μηχανισμό επέκτασης του οικοσυστήματος UMA σε πολλαπλές αλυσίδες, έναν μηχανισμό διανομής ανταμοιβών στους κατόχους κουπονιών ERC721 σύμφωνα με μια προδιαγραφή εκτός αλυσίδας και μια ενημέρωση στην ασφαλισμένη γέφυρα για την υποστήριξη της WETH στην αλυσίδα της Αισιοδοξίας.

Η ελεγχόμενη δέσμευση είναι 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc και το αντικείμενο περιλαμβάνει τις ακόλουθες συμβάσεις:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (εξαιρουμένων των συμβολαίων δοκιμής και πολυγώνου)
• financial-templates/optimistic-rewarder/* (εξαιρουμένων των συμβολαίων δοκιμών)

Εξετάσαμε επίσης τις αλλαγές στα αρχεία solidity Αίτημα έλξης 3611.

Όλοι οι εξωτερικοί κώδικες και οι εξαρτήσεις της σύμβασης υποτίθεται ότι λειτουργούν όπως τεκμηριώνονται

Επισκόπηση Συστήματος

Η τρέχουσα Governance Η σύμβαση επιτρέπει στο Risk Labs Foundation να προτείνει νέες ενέργειες διακυβέρνησης που μπορούν να επικυρωθούν από τους κατόχους διακριτικών UMA. Το νέο Proposer Η σύμβαση προορίζεται να αναλάβει το ρόλο του προτείνοντος, επιτρέποντας σε οποιονδήποτε να κάνει νέες προτάσεις, αρκεί να παρέχει ένα δεσμό που θα θυσιαστεί εάν η πρόταση αποτύχει. Δεν υπάρχει συγκεκριμένο κίνητρο για την υποβολή προτάσεων. Στόχος είναι να διασφαλιστεί ότι θα προταθούν μόνο οι ενέργειες που είναι πολύ πιθανό να γίνουν αποδεκτές.

Ο νέος μηχανισμός cross-chain επιτρέπει τη μετάβαση της πρότασης διακυβέρνησης από το mainnet του Ethereum στις αλυσίδες Optimism και Arbitrum. Με αυτόν τον τρόπο, ο μηχανισμός διακυβέρνησης UMA στο επίπεδο 1 μπορεί να χρησιμοποιηθεί για τη ρύθμιση των συμβάσεων UMA στις υποστηριζόμενες αλυσίδες του επιπέδου 2. Ο μηχανισμός επιτρέπει επίσης την προώθηση των αιτημάτων τιμών και των αναλύσεων μεταξύ των επιπέδων, έτσι ώστε τα Optimistic Oracles στις αλυσίδες επιπέδου 2 να μπορούν να ασφαλιστούν από τον Μηχανισμό Επαλήθευσης Δεδομένων του mainnet με τον ίδιο τρόπο που ασφαλίζεται το επίπεδο 1 Optimistic Oracle από το DVM.

Αξίζει να σημειωθεί ότι αυτά τα μηνύματα αποστέλλονται χρησιμοποιώντας την εγγενή μηχανική γέφυρας, πράγμα που σημαίνει ότι περιορίζονται από τα χαρακτηριστικά των σχετικών αλυσίδων στρώματος 2. Συγκεκριμένα, τα μηνύματα από το επίπεδο 2 στο στρώμα 1 μπορεί να χρειαστούν μια εβδομάδα ή περισσότερο για να περάσουν από τη γέφυρα. Επιπλέον, ο μηχανισμός διακυβέρνησης UMA υποστηρίζει προτάσεις που περιλαμβάνουν πολλαπλές παραγγελθείσες συναλλαγές, αλλά αυτό περιορίζει απλώς τη σειρά με την οποία μπορούν να προστεθούν στη γέφυρα. Είναι πιθανό ορισμένες από αυτές τις συναλλαγές να εκτελεστούν με διαφορετική σειρά ή καθόλου, στο επίπεδο 2.

Το συμβόλαιο Optimistic Rewarder απλώς κόβει μάρκες ERC721 για όποιον τα ζητήσει. Επιτρέπει επίσης σε οποιονδήποτε να συσχετίσει αυθαίρετα δεδομένα με οποιοδήποτε διακριτικό και να καταθέσει διάφορα διακριτικά ERC20 που θα διανεμηθούν ως ανταμοιβές. Η ερμηνεία των αυθαίρετων δεδομένων και η αναμενόμενη κατανομή των ανταμοιβών μεταξύ των κατόχων διακριτικών καθορίζονται χρησιμοποιώντας μια απροσδιόριστη διαδικασία εκτός αλυσίδας. Οποιοσδήποτε μπορεί να ισχυριστεί ότι ένα συγκεκριμένο διακριτικό ERC721 οφείλει ένα σύνολο ανταμοιβών εάν είναι πρόθυμος να καταθέσει ένα ομόλογο. Ο τυπικός μηχανισμός Optimistic Oracle χρησιμοποιείται για να επιτρέψει σε κάποιον άλλο να αμφισβητήσει την αξίωση, η οποία θα επιλυθεί από το DVM. Οι αξιώσεις που δεν αμφισβητούνται εγκαίρως θεωρούνται έγκυρες και η σύμβαση κατανέμει τις ανταμοιβές αναλόγως. Ο μόνος περιορισμός (για την απλούστευση της λογιστικής) είναι ότι το token bond oracle δεν μπορεί να χρησιμοποιηθεί ως διακριτικό ανταμοιβής.

Τέλος, το PR3611 τροποποιεί τον μηχανισμό ασφαλισμένης γέφυρας για να αποφύγει την αποστολή WETH μέσω της γέφυρας διακριτικού Optimism, η οποία δεν υποστηρίζεται. Αντίθετα, κάθε L2 WETH που έχει κατατεθεί στο κουτί καταθέσεων Optimism ξετυλίγεται σε L2 ETH πριν περάσει από τη γέφυρα. Στο επίπεδο 1, το ETH μετατρέπεται σε WETH πριν προωθηθεί στην πισίνα γέφυρας WETH.

Κρίσιμη σοβαρότητα

[C01] Δεν είναι δυνατή η αμφισβήτηση της μη έγκυρης ανταμοιβής

Όταν αμφισβητείται ένα αίτημα ανταμοιβής, το OptimisticRewardBase σύμβαση πρώτα ενεργοποιεί μια πρόταση σχετικά με την SkinnyOptimisticOracle και στη συνέχεια αμφισβητεί την πρόταση αυτή. Ωστόσο, η πρόταση ορίζει το χρόνο λήξης ως αντιστάθμιση από την τρέχουσα (διαφορά) ώρα, ενώ η διαφορά καθορίζει τη λήξη ως αντιστάθμιση από τη στιγμή της αρχικής αίτησης ανταμοιβής. Στις περισσότερες περιπτώσεις, αυτή η ασυμφωνία θα εμποδίσει το μαντείο να προσδιορίσει την πρόταση προς αμφισβήτηση, πράγμα που σημαίνει ότι οι έγκυρες διαφορές δεν θα διεκπεραιώνονται και τα μη έγκυρα αιτήματα ανταμοιβής θα γίνονται δεκτά.

Εξετάστε το ενδεχόμενο ενημέρωσης της επίκλησης αμφισβήτησης για να προσδιορίσετε σωστά την πρόταση προς αμφισβήτηση.

Ενημέρωση: Διορθώθηκε από την δέσμευση 9e15557 in PR3690.

[C02] Επανειλημμένη επίλυση προτάσεων

Η resolveProposal λειτουργία του Proposer σύμβαση απλά επικυρώνει ότι ο χρησμός έχει επιλύσει, αλλά δεν ελέγχει αν το ομόλογο έχει διανεμηθεί. Αυτό σημαίνει ότι η ίδια πρόταση μπορεί να επιλυθεί πολλές φορές, με αποτέλεσμα διπλές πληρωμές ομολόγων. Εξετάστε το ενδεχόμενο να επισημάνετε ή να διαγράψετε υπάρχουσες προτάσεις όταν επιλυθούν.

Ενημέρωση: Διορθώθηκε από την δέσμευση b152718 in PR3689.

Υψηλή σοβαρότητα

Καμία.

Μέση σοβαρότητα

[M01] Λανθασμένες παράμετροι συμβάντος

Η OptimisticRewarderBase σύμβαση ορίζει α Requested συμβάν που εκπέμπεται από το requestRedemption λειτουργεί όταν ζητείται εξαργύρωση. Αυτό το συμβάν έχει οριστεί να εκπέμπει το χρόνος λήξης της εξαγοράς ως τελευταία του παράμετρος. Ωστόσο, όταν εκπέμπεται το συμβάν, η τελευταία του παράμετρος έχει οριστεί λανθασμένα στο τρέχουσα ώρα.

Ομοίως το Redeemed συμβάν διαβάζει το χρόνο λήξης μετά τη διαγραφή της εγγραφής, επομένως θα μηδενιστεί σωστά.

Δεδομένου ότι αυτό το συμβάν μπορεί να χρησιμοποιηθεί για την ενεργοποίηση υπολογισμών εκτός αλυσίδας, εξετάστε το ενδεχόμενο να ενημερώσετε κατάλληλα την τιμή που εκπέμπεται.

Ενημέρωση: Διορθώθηκε από την δέσμευση f04eef9 in PR3694.

Χαμηλή σοβαρότητα

[L01] Έλλειψη εκπομπής συμβάντος μετά την αμφισβήτηση μιας εξαργύρωσης

Η OptimisticRewarderBase σύμβαση ορίζει α Disputed συμβάν που προορίζεται να ενεργοποιηθεί εάν αμφισβητηθεί μια εξαγορά. Ωστόσο, αυτό το συμβάν δεν εκπέμπεται εντός ή εκτός του OptimisticRewarderBase σύμβαση.

Εξετάστε το ενδεχόμενο εκπομπής του συμβάντος αφού πραγματοποιηθούν ευαίσθητες αλλαγές στο dispute λειτουργία, για τη διευκόλυνση της παρακολούθησης και την ενημέρωση των πελατών εκτός αλυσίδας μετά τη δραστηριότητα των συμβολαίων.

Ενημέρωση: Διορθώθηκε από την δέσμευση c275e92 in PR3695.

[L02] Ασυνεπής φύλακας επανεισόδου

Η Optimism_ParentMessenger και Arbitrum_ParentMessenger συμβάσεις εφαρμόζουν ασυνεπώς την nonReentrant τροποποιητής. Εξετάστε το ενδεχόμενο να το συμπεριλάβετε σε όλες τις δημόσιες λειτουργίες.

Ενημέρωση: Διορθώθηκε από την δέσμευση 6275c39 in PR3677.

[L03] Παραπλανητικά σχόλια

Ακολουθούν ορισμένα παραπλανητικά σχόλια που εντοπίσαμε κατά την αξιολόγησή μας:

• ChildMessengerConsumerInterface.sol:
  • Γραμμή 5 λέει "γονικός αγγελιοφόρος" αντί για "παιδικός αγγελιοφόρος"
• GovernorSpoke.sol:
  • Γραμμές 49-51 συνδέσεις με α Gnosis αρχείο παρόλο που το σχόλιο λέει ότι το απόσπασμα αντιγράφηκε από Governor.sol. Επιπλέον, το απόσπασμα δεν είναι πανομοιότυπο με αυτό στο Governor.sol

Ενημέρωση: Διορθώθηκε από την δέσμευση cc350f9 in PR3678.

[L04] Λείπει η σφραγίδα βοηθητικών δεδομένων

Όταν ζητάτε μια τιμή για το OracleSpoke σύμβασης, τα παρεχόμενα παρεπόμενα στοιχεία είναι σφραγισμένο με το αναγνωριστικό της παιδικής αλυσίδας. Ωστόσο, το hasPrice και getPrice Οι λειτουργίες δεν σφραγίζουν τα βοηθητικά δεδομένα κατά τον προσδιορισμό του αιτήματος τιμής. Αυτό αναγκάζει τα συμβόλαια που καλούν να εφαρμόσουν τη σφραγίδα από μόνα τους, γεγονός που προκαλεί ασυνέπεια μεταξύ του αιτήματος τιμής και των μηχανισμών ανάκτησης τιμής. Εξετάστε το ενδεχόμενο να εφαρμόσετε τη σφραγίδα στο hasPrice και getPrice λειτουργίες.

Ενημέρωση: Διορθώθηκε από την δέσμευση fdb845d in PR3668.

[L05] Λείπει η παράμετρος NatSpec

Πολλές λειτουργίες στο OptimisticRewarderBase σύμβαση λείπουν οι @return παράμετρος στα σχόλια Φυσικών Προδιαγραφών τους. Σκεφτείτε να το συμπεριλάβετε για πληρότητα.

Ενημέρωση: Διορθώθηκε από την δέσμευση 8920f38 in PR3679.

[L06] Υπολειμματικό επίδομα

Προκειμένου να επικαλεστεί τον Αισιόδοξο Μαντείο, ο OptimisticRewarderBase σύμβαση του χορηγεί συμβολικό επίδομα, ώστε να μπορεί να τραβήξει τις πληρωμές ομολόγων. Εάν η πρόταση αποτύχει, η εξαργύρωση ανταμοιβής ακυρώνεται αλλά το επίδομα δεν επαναφέρεται. Επομένως, το Optimistic Oracle θα διατηρήσει μια περιττή υπολειπόμενη αποζημίωση μέχρι την επόμενη φορά που θα προκληθεί μια διαφωνία. Εξετάστε το ενδεχόμενο ανάκλησης του επιδόματος εάν η πρόταση αποτύχει.

Ενημέρωση: Διορθώθηκε από την δέσμευση c2d444b in PR3698.

[L07] Μη έγκυρη διεύθυνση επιστροφής χρημάτων

Η διεύθυνση L2 επιστροφής χρημάτων του Arbitrum_ParentMessenger αρχικοποιείται στον ιδιοκτήτη της σύμβασης, ο οποίος θα πρέπει να είναι ο Κυβερνήτης του L1. Ομοίως, το setRefundL2Address έχει ένα σχόλιο δηλώνοντας ότι πρέπει να τεθεί στον κυβερνήτη. Ωστόσο, όταν περνάτε μηνύματα πάνω από τη γέφυρα, αυτή η τιμή είναι οριστεί ως χρήστης L2, η οποία είναι η διεύθυνση στο Arbitrum που λαμβάνει επιπλέον χρήματα μετά την επίλυση του εισιτηρίου. Δεδομένου ότι η διεύθυνση του κυβερνήτη L1 δεν θα είναι προσβάσιμη στο Arbitrum, τυχόν χρήματα που αποστέλλονται σε αυτήν τη διεύθυνση θα χαθούν.

Εξετάστε το ενδεχόμενο να το ορίσετε σε μια έγκυρη διεύθυνση L2.

Ενημέρωση: Διορθώθηκε από την δέσμευση b3f2dd1 in PR3687.

[L08] Μηχανισμός αλλαγής παιδικών αγγελιοφόρων

Η GovernorSpoke και OracleSpoke ανάθεση σε κάθε αρχικοποίηση του θυγατρικού αγγελιοφόρου στον κατασκευαστή, χωρίς μηχανισμό ενημέρωσης. Αυτό σημαίνει ότι όταν το ο παιδικός αγγελιοφόρος έχει αλλάξει, και τα δύο συμβόλαια ακτίνων είναι παρωχημένα.

Δεδομένου ότι το συμβόλαιο ακτίνας είναι πιθανότατα πιο σταθερό από τους αγγελιοφόρους, εξετάστε το ενδεχόμενο να συμπεριλάβετε έναν μηχανισμό για την ενημέρωση του messenger στις ακτίνες.

Ενημέρωση: Διορθώθηκε από την δέσμευση 7c9e061 in PR3688.

Σημειώσεις και πρόσθετες πληροφορίες

[N01] Αλλαγή διακριτικού ομολόγου

Η Proposer η σύμβαση περιλαμβάνει ένας μηχανισμός για να αλλάξει ο ιδιοκτήτης το μέγεθος της εγγύησης της πρότασης. Σκεφτείτε εάν θα πρέπει επίσης να μπορούν να αλλάξουν το διακριτικό ομολόγου. Σημειώστε ότι αυτό θα απαιτούσε έναν μηχανισμό για τον προσδιορισμό του σωστού νομίσματος ομολόγων όταν επιλυθούν οι υπάρχουσες προτάσεις.

Ενημέρωση: Κανένα θέμα. Η δήλωση της UMA για αυτό το θέμα:

Το N01 συνιστά να επιτρέπεται στο συμβόλαιο του προτείνοντος να αλλάξει το διακριτικό ομολόγου σε κάτι διαφορετικό από το UMA. Δεν σκοπεύουμε να υποστηρίξουμε κανένα διακριτικό εκτός από το $UMA για αυτήν τη λειτουργία και επομένως επιλέξαμε να μην κάνουμε αλλαγές για αυτό το ζήτημα. Επιπλέον, ένα μόνο διακριτικό ανά συμβόλαιο διατηρεί αυτή τη λογική όσο το δυνατόν πιο απλή. Τέλος, εάν χρειαζόταν μια αλλαγή (για παράδειγμα, στην περίπτωση μετεγκατάστασης διακριτικού), θα μπορούσαμε απλώς να αναπτύξουμε ένα νέο συμβόλαιο με το άλλο διακριτικό και να ξεκινήσουμε μια πρόταση για μετεγκατάσταση του συστήματος για χρήση αυτού.

[N02] Ημιτελής διεπαφή

Η ChildMessengerInterface δεν προσδιορίζει α processMessageFromCrossChainParent λειτουργία, παρόλο που θεωρείται ότι υπάρχει από τους γονικούς αγγελιοφόρους. Σκεφτείτε να το συμπεριλάβετε για πληρότητα.

Ενημέρωση: Δεν φτιάχτηκε. Η δήλωση της UMA για αυτό το θέμα:

Επιλέξαμε σκόπιμα να αφήσουμε αυτήν τη διεπαφή ασυνεπής, καθώς η εφαρμογή αυτής εντός του ChildMessengerInterface διακόπτει τη συμβατότητα με το Polygon_ChildMessenger καθώς η μέθοδος του Polygon για την επεξεργασία μηνυμάτων από άλλες αλυσίδες απαιτεί κάπως προσαρμοσμένη λογική όπου μια εσωτερική μέθοδος ονομάζεται _processMessageFromRoot.

[N03] Λανθασμένη διεπαφή

Η GovernorSpoke λανθασμένη σύμβαση χρησιμοποιεί το ChildMessengerConsumerInterface τύπος για να το περιγράψω messenger μεταβλητός. Σκεφτείτε να χρησιμοποιήσετε το ChildMessengerInterface Αντιθέτως.

Ενημέρωση: Διορθώθηκε από την δέσμευση f31a527 in PR3680.

[N04] Τραβήξτε τα κουπόνια για αποθήκευση

Σε προηγούμενος έλεγχος αμφισβητήσαμε τον σκοπό του Store συμβόλαιο payOracleFeesErc20 λειτουργία (στο τεύχος L19). Η ομάδα του UMA επέλεξε να διατηρήσει τη λειτουργία για την τυποποίηση της διεπαφής για πιθανές μελλοντικές τροποποιήσεις. Δεδομένου ότι ο σκοπός της συνάρτησης δεν έχει καθοριστεί πλήρως, δεν είναι σαφές εάν θα πρέπει να ενεργοποιηθεί όταν Proposer σύμβαση κατάσχει ένα ομόλογο. Πιθανότατα θα πρέπει να χρησιμοποιείται όταν το OracleHub πληρώνει για ένα αίτημα τιμής. Σκεφτείτε εάν η συνάρτηση πρέπει να χρησιμοποιηθεί σε οποιοδήποτε σενάριο.

Ενημέρωση: Αναγνώρισε. Η δήλωση της UMA για αυτό το θέμα:

Το N04 συνιστά τη χρήση της μεθόδου payOracleFeeErc20 του Store για την πληρωμή τελών τόσο στις συμβάσεις του Proposer όσο και στο OracleHub, ώστε να είναι συνεπής με τη χρήση του Store. Επιλέξαμε να μην χρησιμοποιήσουμε αυτήν τη λειτουργία, καθώς θα σήμαινε ότι θα χρειαστεί να εισαγάγουμε μια πρόσθετη διεπαφή (για το κατάστημα) και θα απαιτούσαμε τη μεταφορά του ποσού της ομολογίας σε ένα FixedPoint (το οποίο θα απαιτούσε επίσης μια πρόσθετη εισαγωγή. Για να διατηρηθεί ο κώδικας απλός και καθαρός επιλέξαμε να μην το κάνουμε αυτό. Τα σχόλια του OZ για το payOracleFeeErc20 στη φάση ελέγχου 1 τον Απρίλιο του 2020 ήταν έγκυρα ότι αυτή η μέθοδος δεν είναι πραγματικά χρήσιμη, γεγονός που καθιστά δυσκολότερη την αιτιολογία αυτού του είδους της ενοποίησης.

[N05] TODO σε κωδικό

Υπάρχουν σχόλια «TODO» στη βάση κώδικα που θα πρέπει να παρακολουθούνται στο ανεκτέλεστο θέμα του έργου. Για παράδειγμα:

• γραμμή 37 of Arbitrum_ParentMessenger σύμβαση
• γραμμή 25 of Optimism_ChildMessenger σύμβαση
• γραμμές 83 και 146 of OracleHub σύμβαση.

Κατά τη διάρκεια της ανάπτυξης, η καλή περιγραφή των σχολίων «TODO» θα διευκολύνει τη διαδικασία παρακολούθησης και επίλυσής τους. Χωρίς αυτές τις πληροφορίες, αυτά τα σχόλια ενδέχεται να τείνουν να σαπίζουν και σημαντικές πληροφορίες για την ασφάλεια του συστήματος μπορεί να ξεχαστούν μέχρι τη στιγμή που θα κυκλοφορήσουν στην παραγωγή.

Αυτά τα σχόλια TODO θα πρέπει να έχουν μια σύντομη περιγραφή της εργασίας που εκκρεμεί και έναν σύνδεσμο προς το αντίστοιχο ζήτημα στο αποθετήριο του έργου.

Εξετάστε το ενδεχόμενο να ενημερώσετε τα σχόλια TODO για να προσθέσετε αυτές τις πληροφορίες. Για πληρότητα και ιχνηλασιμότητα, μπορεί να προστεθεί μια υπογραφή και μια χρονική σφραγίδα. Για παράδειγμα:

// TODO: point this at an interface instead.

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

// --mrice32 - 20211209

Ενημέρωση: Διορθώθηκε από την δέσμευση 5d57b5b in PR3684.

[N06] Τυπογραφικά λάθη

Η βάση κώδικα περιέχει τα ακόλουθα τυπογραφικά λάθη:

• Στο Admin_ChildMessenger σύμβαση, impleenting θα πρέπει να είναι implementing
• Στο OptimisticRewarderBase σύμβαση, timestap θα πρέπει να είναι timestamp.
• Στο OptimisticRewarderBase σύμβαση, liveness liveness θα πρέπει να είναι liveness.
• Στο GovernorSpoke σύμβαση, only called θα πρέπει να είναι only be called.
• Στο Optimism_ChildMessenger σύμβαση:

Ενημέρωση: Διορθώθηκε από την δέσμευση 9b92b0b in PR3681.

[N07] Αχρησιμοποίητες εισαγωγές

Για να βελτιώσετε την αναγνωσιμότητα του κώδικα, εξετάστε το ενδεχόμενο να καταργήσετε τις ακόλουθες αχρησιμοποίητες εισαγωγές:

Ενημέρωση: Διορθώθηκε από την δέσμευση 40b7221 in PR3682.

[N08] Παραγγελία συναλλαγής L2

Η Governor εξασφαλίζει οι συναλλαγές στο πλαίσιο μιας πρότασης εκτελούνται με τη σειρά. Ωστόσο, όταν αυτές οι συναλλαγές περιλαμβάνουν διασταυρούμενες συναλλαγές, αυτό απλώς εγγυάται ότι φθάνουν στη σύμβαση γέφυρας L1 με τη σωστή σειρά. Στην περίπτωση Arbitrum, ενδέχεται να παραγγελθούν εκ νέου πριν οριστικοποιηθούν στο L2. Ως εκ τούτου, οι προτάσεις διακυβέρνησης θα πρέπει να κατασκευαστούν ώστε να επιτρέπεται η δυνατότητα αναδιάταξης συναλλαγών L2.

Ενημέρωση: Διορθώθηκε από την δέσμευση 0fb2e7b in PR3703. ο GovernorHub μπορεί τώρα να αναμεταδώσει μια σειρά από συναλλαγές L2.

Συμπέρασμα

Βρέθηκαν δύο κρίσιμα ζητήματα στη βάση κώδικα. Εντοπίστηκε ένα πρόβλημα μέτριας σοβαρότητας και αρκετές μικρές ευπάθειες και έχουν προταθεί συστάσεις για επιδιορθώσεις.

Πηγή: https://blog.openzeppelin.com/uma-audit-phase-6/?utm_source=rss&utm_medium=rss&utm_campaign=uma-audit-phase-6