Audit Uma – Fase 6

Pengantar

UMA adalah platform yang memungkinkan pengguna untuk memasukkan kontrak keuangan yang diminimalkan kepercayaan pada blockchain Ethereum. Kami sebelumnya mengaudit oracle yang terdesentralisasi, templat kontrak keuangan tertentu, beberapa permintaan tarik ad hoc, template Multipartai Abadi, berbagai permintaan tarik tambahan untuk keterlibatan yang lebih lama dan jembatan yang diasuransikan.

Dalam audit ini kami meninjau kontrak proposal tata kelola baru, mekanisme untuk memperluas ekosistem UMA di beberapa rantai, mekanisme untuk mendistribusikan hadiah kepada pemegang token ERC721 sesuai dengan spesifikasi off-chain, dan pembaruan ke jembatan yang diasuransikan untuk mendukung WETH pada rantai Optimisme.

Komitmen yang diaudit adalah 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc dan ruang lingkupnya mencakup kontrak-kontrak berikut:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (tidak termasuk tes dan kontrak Polygon)
• financial-templates/optimistic-rewarder/* (tidak termasuk kontrak pengujian)

Kami juga meninjau perubahan pada file soliditas di Tarik Permintaan 3611.

Semua kode eksternal dan ketergantungan kontrak diasumsikan berfungsi seperti yang didokumentasikan.

Ikhtisar sistem

Arus Governance kontrak memungkinkan Risk Labs Foundation untuk mengusulkan tindakan tata kelola baru yang dapat diratifikasi oleh pemegang token UMA. Yang baru Proposer kontrak dimaksudkan untuk mengambil peran pengusul, memungkinkan siapa saja untuk membuat proposal baru selama mereka memberikan ikatan yang akan dikorbankan jika proposal gagal. Tidak ada insentif khusus untuk membuat proposal. Tujuannya adalah untuk memastikan bahwa hanya tindakan yang sangat mungkin diterima yang akan diusulkan.

Mekanisme lintas rantai baru memungkinkan proposal tata kelola diteruskan dari mainnet Ethereum ke rantai Optimisme dan Arbitrum. Dengan cara ini, mekanisme tata kelola UMA pada lapisan 1 dapat digunakan untuk mengatur kontrak UMA pada rantai lapisan 2 yang didukung. Mekanisme ini juga memungkinkan permintaan harga dan resolusi diteruskan antar lapisan, sehingga Oracle Optimis pada rantai lapisan 2 dapat diamankan dengan Mekanisme Verifikasi Data mainnet dengan cara yang sama seperti Oracle Optimis lapisan 1 diamankan oleh DVM.

Perlu dicatat bahwa pesan-pesan ini dikirim menggunakan mekanisme jembatan asli, yang berarti mereka dibatasi oleh karakteristik rantai lapisan 2 yang relevan. Secara khusus, pesan dari lapisan 2 ke lapisan 1 bisa memakan waktu seminggu atau lebih lama untuk melewati jembatan. Selain itu, mekanisme tata kelola UMA mendukung proposal yang mencakup beberapa transaksi yang dipesan, tetapi ini hanya membatasi urutan di mana mereka dapat ditambahkan ke jembatan. Mungkin saja beberapa transaksi tersebut dieksekusi dalam urutan yang berbeda, atau tidak sama sekali, pada lapisan 2.

Kontrak Optimis Rewarder hanya mencetak token ERC721 untuk siapa saja yang memintanya. Ini juga memungkinkan siapa pun untuk mengaitkan data sewenang-wenang dengan token apa pun, dan untuk menyimpan berbagai token ERC20 untuk didistribusikan sebagai hadiah. Interpretasi data arbitrer dan distribusi hadiah yang diharapkan di antara pemegang token ditentukan menggunakan prosedur off-chain yang tidak ditentukan. Siapa pun dapat mengajukan klaim bahwa token ERC721 tertentu berutang satu set hadiah jika mereka bersedia menyetorkan obligasi. Mekanisme Oracle Optimis standar digunakan untuk mengizinkan orang lain menyengketakan klaim, yang akan diselesaikan oleh DVM. Klaim yang tidak disengketakan pada waktunya dianggap sah, dan kontrak mendistribusikan imbalan sesuai dengan itu. Satu-satunya batasan (untuk menyederhanakan akuntansi) adalah bahwa token oracle bond tidak dapat digunakan sebagai token hadiah.

Terakhir, PR3611 memodifikasi mekanisme jembatan yang diasuransikan untuk menghindari pengiriman WETH melintasi jembatan token Optimism, yang tidak didukung. Sebagai gantinya, setiap L2 WETH yang disimpan di kotak deposit Optimism dibuka ke L2 ETH sebelum transit di jembatan. Pada layer 1, ETH diubah menjadi WETH sebelum diteruskan ke pool jembatan WETH.

Tingkat keparahan kritis

[C01] Tidak dapat membantah hadiah yang tidak valid

Saat memperdebatkan permintaan hadiah, OptimisticRewardBase kontrak dulu memicu proposal pada SkinnyOptimisticOracle lalu membantah proposal itu. Namun, usulan mengatur waktu kedaluwarsa sebagai penyeimbang dari waktu (sengketa) saat ini, sedangkan sengketa menentukan kedaluwarsa sebagai offset dari waktu permintaan hadiah asli. Dalam kebanyakan kasus, perbedaan ini akan mencegah oracle dari mengidentifikasi proposal yang akan disengketakan, yang berarti perselisihan yang valid tidak akan diproses dan permintaan hadiah yang tidak valid akan diterima.

Pertimbangkan untuk memperbarui permintaan sengketa untuk menentukan dengan benar proposal yang akan disengketakan.

Update: Diperbaiki pada komit 9e15557 in PR3690.

[C02] Berulang kali menyelesaikan proposal

Grafik resolveProposal fungsi dari Proposer kontrak hanya memvalidasi bahwa oracle telah diselesaikan, tetapi tidak memeriksa apakah ikatan telah didistribusikan. Ini berarti proposal yang sama dapat diselesaikan beberapa kali, menghasilkan pembayaran obligasi rangkap. Pertimbangkan untuk menandai atau menghapus proposal yang ada saat proposal tersebut diselesaikan.

Update: Diperbaiki pada komit b152718 in PR3689.

Keparahan tinggi

Tidak ada.

Keparahan sedang

[M01] Parameter acara salah

Grafik OptimisticRewarderBase kontrak mendefinisikan Requested peristiwa yang dipancarkan dari requestRedemption berfungsi ketika penebusan diminta. Peristiwa ini didefinisikan untuk memancarkan waktu kedaluwarsa penukaran sebagai parameter terakhirnya. Namun, saat peristiwa itu dipancarkan, parameter terakhirnya salah diatur ke waktu saat ini.

Demikian pula Redeemed peristiwa membaca waktu kedaluwarsa setelah catatan dihapus, sehingga akan salah diatur ke nol.

Mengingat bahwa peristiwa ini dapat digunakan untuk memicu komputasi off-chain, pertimbangkan untuk memperbarui nilai yang dipancarkan dengan tepat.

Update: Diperbaiki pada komit f04eef9 in PR3694.

Tingkat keparahan rendah

[L01] Kurangnya emisi acara setelah memperdebatkan penukaran

Grafik OptimisticRewarderBase kontrak mendefinisikan Disputed peristiwa yang dimaksudkan untuk dipicu jika penebusan diperselisihkan. Namun, peristiwa ini tidak dipancarkan di dalam atau di luar OptimisticRewarderBase kontrak.

Pertimbangkan untuk memancarkan acara setelah perubahan sensitif terjadi di dispute fungsi, untuk memfasilitasi pelacakan dan memberi tahu klien off-chain setelah aktivitas kontrak.

Update: Diperbaiki pada komit c275e92 in PR3695.

[L02] Penjaga masuk kembali tidak konsisten

Grafik Optimism_ParentMessenger dan Arbitrum_ParentMessenger kontrak tidak konsisten menerapkan nonReentrant pengubah. Pertimbangkan untuk memasukkannya ke semua fungsi publik.

Update: Diperbaiki pada komit 6275c39 in PR3677.

[L03] Komentar yang menyesatkan

Berikut adalah beberapa komentar menyesatkan yang kami identifikasi selama peninjauan kami:

• ChildMessengerConsumerInterface.sol:
  • Jalur 5 mengatakan "utusan orang tua" alih-alih "pembawa pesan anak"
• GovernorSpoke.sol:
  • Baris 49-51 link ke Gnosis file meskipun komentar mengatakan cuplikan itu disalin dari Governor.sol. Selain itu, cuplikannya tidak identik dengan yang ada di Governor.sol

Update: Diperbaiki pada komit cc350f9 in PR3678.

[L04] Stempel data tambahan hilang

Saat meminta harga di OracleSpoke kontrak, data tambahan yang disediakan dicap dengan pengidentifikasi rantai anak. Namun, hasPrice dan getPrice fungsi tidak mencap data tambahan saat mengidentifikasi permintaan harga. Ini memaksa kontrak pemanggil untuk menerapkan cap itu sendiri, yang menyebabkan inkonsistensi antara permintaan harga dan mekanisme pengambilan harga. Pertimbangkan untuk menerapkan stempel di hasPrice dan getPrice fungsi.

Update: Diperbaiki pada komit fdb845d in PR3668.

[L05] Parameter NatSpec tidak ada

Banyak fungsi dalam OptimisticRewarderBase kontrak kehilangan @return parameter dalam komentar Spesifikasi Alam mereka. Pertimbangkan untuk memasukkannya untuk kelengkapan.

Update: Diperbaiki pada komit 8920f38 in PR3679.

[L06] Sisa tunjangan

Untuk memanggil Oracle Optimis, the OptimisticRewarderBase kontrak memberikannya tunjangan token, sehingga dapat menarik pembayaran obligasi. Jika proposal gagal, penukaran hadiah dibatalkan tapi tunjangan tidak diatur ulang. Oleh karena itu, Oracle Optimis akan mempertahankan sisa penyisihan yang tidak perlu sampai sengketa dipicu lagi. Pertimbangkan untuk mencabut tunjangan jika proposal gagal.

Update: Diperbaiki pada komit c2d444b in PR3698.

[L07] Alamat pengembalian dana tidak valid

Alamat pengembalian dana L2 dari Arbitrum_ParentMessenger diinisialisasi kepada pemilik kontrak, yang seharusnya menjadi Gubernur L1. Demikian pula, setRefundL2Address punya komentar menyatakan hal itu harus ditetapkan kepada gubernur. Namun, saat menyampaikan pesan melalui jembatan, nilai ini adalah ditetapkan sebagai pengguna L2, yang merupakan alamat di Arbitrum yang menerima kelebihan dana setelah tiket diselesaikan. Karena alamat gubernur L1 tidak akan dapat diakses di Arbitrum, semua dana yang dikirim ke alamat ini akan hilang.

Pertimbangkan untuk menyetelnya ke alamat L2 yang valid.

Update: Diperbaiki pada komit b3f2dd1 in PR3687.

[L08] Mekanisme untuk mengubah utusan anak

Grafik GovernorSpoke dan OracleSpoke kontrak masing-masing menginisialisasi utusan anak di konstruktor, tanpa mekanisme untuk memperbaruinya. Ini berarti bahwa ketika utusan anak diubah, kedua kontrak bicara menjadi usang.

Karena kontrak bicara cenderung lebih stabil daripada pengirim pesan, pertimbangkan untuk menyertakan mekanisme untuk memperbarui pengirim pesan di jari-jari.

Update: Diperbaiki pada komit 7c9e061 in PR3688.

Catatan & Informasi Tambahan

[N01] Ganti token obligasi

Grafik Proposer kontrak termasuk sebuah mekanisme bagi pemilik untuk mengubah ukuran obligasi proposal. Pertimbangkan apakah mereka juga harus dapat mengubah token obligasi. Perhatikan bahwa ini memerlukan mekanisme untuk mengidentifikasi mata uang obligasi yang benar ketika proposal yang ada diselesaikan.

Update: Bukan masalah. Pernyataan UMA untuk masalah ini:

N01 merekomendasikan untuk mengaktifkan kontrak pengusul untuk mengubah token obligasi menjadi sesuatu selain UMA. Kami tidak bermaksud mendukung token apa pun selain $UMA untuk fungsi ini dan karenanya memilih untuk tidak membuat perubahan apa pun untuk masalah ini. Selain itu, satu token per kontrak membuat logika ini sesederhana mungkin. Terakhir, Jika perubahan diperlukan (dalam kasus migrasi token, misalnya), kami hanya dapat menerapkan kontrak pengusul baru dengan token lain dan memulai proposal untuk memigrasikan sistem untuk menggunakan yang itu.

[N02] Antarmuka tidak lengkap

Grafik ChildMessengerInterface tidak menentukan processMessageFromCrossChainParent fungsi, meskipun diasumsikan ada oleh utusan orang tua. Pertimbangkan untuk memasukkannya untuk kelengkapan.

Update: Tidak tetap. Pernyataan UMA untuk masalah ini:

Kami sengaja memilih untuk membiarkan antarmuka ini tidak konsisten karena mengimplementasikannya dalam ChildMessengerInterface merusak kompatibilitas dengan Polygon_ChildMessenger karena metode Polygon untuk memproses pesan dari rantai lain memerlukan logika khusus di mana metode internal disebut _processMessageFromRoot.

[N03] Antarmuka salah

Grafik GovernorSpoke kontrak salah menggunakan ChildMessengerConsumerInterface mengetik untuk menggambarkannya messenger variabel. Pertimbangkan untuk menggunakan ChildMessengerInterface sebagai gantinya.

Update: Diperbaiki pada komit f31a527 in PR3680.

[N04] Tarik token ke Store

Di sebuah audit sebelumnya kami mempertanyakan tujuan dari Store kontrak payOracleFeesErc20 fungsi (dalam edisi L19). Tim UMA memilih untuk mempertahankan fungsinya untuk menstandarisasi antarmuka untuk potensi modifikasi di masa depan. Karena tujuan fungsi tidak sepenuhnya ditentukan, tidak jelas apakah fungsi tersebut harus dipicu ketika Proposer kontrak menyita obligasi. Ini mungkin harus digunakan ketika OracleHub membayar permintaan harga. Pertimbangkan apakah fungsi tersebut harus digunakan dalam kedua skenario.

Update: Diakui. Pernyataan UMA untuk masalah ini:

N04 merekomendasikan penggunaan metode payOracleFeeErc20 Store untuk membayar biaya dalam kontrak Pengusul dan OracleHub agar konsisten dengan penggunaan Store. Kami telah memilih untuk tidak menggunakan fungsi ini karena itu berarti perlu mengimpor antarmuka tambahan (untuk toko) dan memerlukan penuangan jumlah obligasi ke FixedPoint (yang juga memerlukan impor tambahan. Untuk menjaga kode tetap sederhana dan bersih kami telah memilih untuk tidak melakukan ini Umpan balik OZ pada payOracleFeeErc20 dalam audit fase 1 pada April 2020 valid bahwa metode ini tidak terlalu berguna, membuat integrasi semacam ini lebih sulit untuk dipikirkan.

[N05] TODO dalam kode

Ada komentar “TODO” di basis kode yang harus dilacak di backlog masalah proyek. Sebagai contoh:

• baris 37 of Arbitrum_ParentMessenger kontrak
• baris 25 of Optimism_ChildMessenger kontrak
• Garis 83 dan 146 of OracleHub kontrak.

Selama pengembangan, memiliki komentar “TODO” yang dijelaskan dengan baik akan membuat proses pelacakan dan penyelesaiannya lebih mudah. Tanpa informasi itu, komentar ini mungkin cenderung membusuk dan informasi penting untuk keamanan sistem mungkin terlupakan pada saat dirilis ke produksi.

Komentar TODO ini harus memiliki deskripsi singkat tentang tugas yang tertunda, dan tautan ke masalah terkait di repositori proyek.

Pertimbangkan untuk memperbarui komentar TODO untuk menambahkan informasi ini. Untuk kelengkapan dan ketertelusuran, tanda tangan dan cap waktu dapat ditambahkan. Sebagai contoh:

// TODO: point this at an interface instead.

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

// --mrice32 - 20211209

Update: Diperbaiki pada komit 5d57b5b in PR3684.

[N06] Kesalahan tipografi

Basis kode berisi kesalahan ketik berikut:

• Dalam majalah Admin_ChildMessenger kontrak, impleenting seharusnya implementing
• Dalam majalah OptimisticRewarderBase kontrak, timestap seharusnya timestamp.
• Dalam majalah OptimisticRewarderBase kontrak, liveness liveness seharusnya liveness.
• Dalam majalah GovernorSpoke kontrak, only called seharusnya only be called.
• Dalam majalah Optimism_ChildMessenger kontrak:

Update: Diperbaiki pada komit 9b92b0b in PR3681.

[N07] Impor yang tidak digunakan

Untuk meningkatkan keterbacaan kode, pertimbangkan untuk menghapus impor yang tidak digunakan berikut ini:

Update: Diperbaiki pada komit 40b7221 in PR3682.

[N08] Pemesanan transaksi L2

Grafik Governor Memastikan transaksi dalam proposal dijalankan secara berurutan. Namun, ketika transaksi tersebut melibatkan transaksi lintas rantai, ini hanya menjamin bahwa mereka tiba di kontrak jembatan L1 dalam urutan yang benar. Dalam kasus Arbitrum, mereka dapat dipesan ulang sebelum diselesaikan pada L2. Oleh karena itu, proposal tata kelola harus dibuat untuk memungkinkan kemungkinan transaksi L2 yang dipesan ulang.

Update: Diperbaiki pada komit 0fb2e7b in PR3703. itu GovernorHub sekarang dapat menyampaikan larik transaksi L2.

Kesimpulan

Dua masalah kritis ditemukan dalam basis kode. Satu masalah tingkat keparahan sedang dan beberapa kerentanan kecil telah ditemukan, dan rekomendasi untuk perbaikan telah disarankan.

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