Desember 1, 2021
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 dan berbagai permintaan tarik tambahan untuk keterlibatan yang lebih lama. Dalam audit ini kami meninjau mekanisme baru untuk mengirim token dengan cepat dari rantai layer 2 ke mainnet Ethereum, dan perubahan terkait ke Oracle Optimis. Peninjauan diselesaikan oleh 2 auditor selama 3 minggu.
Cakupan
Komitmen yang diaudit adalah f24ad501c8e813cf685f72217e7f13c8f3c366df
dan ruang lingkupnya mencakup kontrak-kontrak berikut:
- kontrak/insured-bridge/* (tidak termasuk kontrak uji coba)
- contract-ovm/insured-bridge/implementasi/*
- kontrak/umum/implementasi/AncillaryData.sol
- kontrak/Oracle/implementasi/SkinnyOptimisticOracle.sol
Kami juga meninjau perubahan pada file soliditas di Tarik Permintaan 3445.
Semua kode eksternal dan ketergantungan kontrak diasumsikan berfungsi seperti yang didokumentasikan.
Ikhtisar sistem
Rantai lapisan 2 (L2) yang didukung, Optimisme dan Arbitrum, menyediakan mekanisme untuk mentransfer dana ke mainnet Ethereum (L1). Namun, untuk alasan keamanan, ada penundaan yang signifikan sebelum transfer tersebut diselesaikan. Untuk mengatasi hal ini, pemegang token L2 dapat menyetor dana dalam kontrak UMA, Kotak Deposit, mengetahui bahwa token pada akhirnya akan ditransfer (sebagai batch) ke kontrak L1 UMA, Bridge Pool. Ada Bridge Pool terpisah untuk setiap token yang akan ditransfer.
Setelah deposit L2, siapa pun dapat menyampaikan detailnya ke Pool Bridge L1, yang menunggu beberapa saat jika seseorang ingin membantah informasi yang diteruskan. Semua perselisihan ditangani oleh Skinny Optimist Oracle (dijelaskan di bawah). Sebelum menerima relai, penyedia likuiditas harus mendanai terlebih dahulu kontrak Bridge Pool dengan imbalan token LP. Relai tak terbantahkan dianggap sah, dan Bridge Pool menyelesaikan transfer menggunakan cadangannya sendiri, di mana sebagian dari transfer dialihkan ke relai dan sebagian disimpan sebagai biaya likuiditas. Dana pada akhirnya akan diisi ulang ketika setoran L2 diselesaikan, dan biaya likuiditas diberikan kepada pemegang token LP.
Bridge Pool juga mengizinkan siapa pun untuk mendanai transfer secara individual (tanpa cadangan Bridge Pool) sebelum periode sengketa berakhir, dengan imbalan sebagian kecil dari jumlah transfer. Karena rele masih bisa disengketakan, dana tersebut akan hilang jika rele dianggap tidak benar. Diharapkan dalam banyak kasus, mekanisme ini akan memungkinkan pengguna untuk mengalami transfer token L2-ke-L1 langsung.
Oracle Optimis Skinny secara konseptual sangat mirip dengan Oracle Optimis yang ada. Ini memberikan mekanisme insentif bagi pengguna untuk hanya menegaskan hasil dari permintaan oracle, yang dianggap akurat jika tidak diperdebatkan. Sengketa diturunkan ke mekanisme DVM yang lebih lambat yang dijelaskan dalam laporan audit kami sebelumnya. Perbedaan utama adalah bahwa versi baru mengharuskan pengguna untuk memberikan semua informasi yang relevan saat menjalankan panggilan fungsi, sehingga nilai tidak perlu disimpan atau diambil dari penyimpanan. Ini juga menghilangkan kemampuan pemohon untuk mengubah parameter konfigurasi dalam permintaan aktif.
Kami sebelumnya telah meninjau kontrak Long-Short-Pair, yang menyediakan mekanisme umum untuk membuat berbagai instrumen keuangan. Kontrak-kontrak ini dapat diselesaikan ketika waktu kedaluwarsanya tercapai dan harga penyelesaiannya diketahui. Perubahan yang diperkenalkan oleh Pull Request 3445 memperkenalkan kemungkinan penyelesaian kontrak lebih awal jika harga penyelesaian diketahui sebelum waktu kedaluwarsa.
Peran Istimewa
Kotak penyimpanan L2 memiliki beberapa parameter konfigurasi, termasuk token yang didukung dan kecepatan maksimum untuk mengirim token batch melalui jembatan ke L1. Mereka juga harus dikonfigurasi untuk memastikan konsistensi antara kontrak token L1, kontrak token L2, dan Bridge Pool yang sesuai. Parameter ini ditetapkan oleh kontrak administrator pada L1, yang juga membuat parameter proses penyelesaian sengketa dari kumpulan jembatan. Kontrak diharapkan dikendalikan oleh mekanisme tata kelola UMA, sehingga pengguna harus mempercayai proses ini untuk mengelola sistem secara bijaksana dan adil.
Ketergantungan ekosistem
Semua komponen yang ditinjau menggunakan logika berbasis waktu, yang berarti mereka bergantung pada ketersediaan Ethereum. Khususnya, jika transaksi sengketa tertunda secara signifikan maka relai yang tidak valid atau proposal harga mungkin salah dikonfirmasi.
Selain itu, jembatan token secara implisit mengasumsikan bahwa semua dana yang dikirim ke kotak deposit L2 pada akhirnya akan ditransfer ke kumpulan jembatan L1 yang sesuai. Ini bergantung pada berfungsinya Optimisme dan Arbitrum secara benar dan berkelanjutan, serta mekanisme penyelesaian sengketanya.
Terakhir, token yang dikirim ke kotak deposit L2 ditugaskan ke kumpulan jembatan di L1, bukan penerima yang dituju. Untuk mengambil dana dari pool, pemegang token L1 harus terlebih dahulu mencocokkannya dengan token tambahan. Oleh karena itu, mekanismenya bergantung pada pasar token L1 yang cukup dalam untuk memastikan selalu ada likuiditas.
Masalah yang dilaporkan klien
Selama audit, tim UMA secara independen mengidentifikasi sejumlah masalah dan perilaku yang perlu disoroti:
Jika parameter Optimis Oracle atau Bridge Admin berubah selama periode tantangan relai, maka memperdebatkan relai akan menghapus relai tanpa bantuan tambahan baik bagi pengusul atau yang menyengketakan. Misalnya, bayangkan relai dikirim untuk token jaminan
TOKEN_A
, tapi di tengah relayTOKEN_A
dihapus dari daftar putih agunan. Sengketa sekarang akan dikembalikan karena Anda tidak dapat mengirimkan permintaan harga apa pun ke OO atau DVM untuk jaminan yang tidak masuk daftar putih. Karena kami tidak ingin memblokir permintaan sengketa yang valid,BridgePool
akan menghapus relai yang tertunda untukTOKEN_A
dalam kasus perselisihan. Konsekuensi dari keputusan desain ini adalah:
1. Kenaikan biaya akhir akan menyebabkan: Setiap relai yang belum diselesaikan pada token itu menjadi “dapat dibatalkan” melalui perselisihan apakah benar atau salah. Pembatalan tidak menguntungkan salah satu pihak, sehingga mengasumsikan adanya penentang jujur yang bersedia membunuh permintaan buruk (jarang) yang terjadi selama eksekusi perubahan biaya akhir. Ini juga berarti bahwa mungkin bagi seorang yang berduka untuk menghabiskan bensin untuk membatalkan relai dan memaksanya untuk direlai ulang.
2. Penghapusan daftar putih pengenal atau token, yang seharusnya tidak terjadi kecuali jika terjadi kesalahan besar akan menyebabkan:
3. Jangka waktu permintaan yang tak terbantahkan yang diperpanjang di mana permintaan apa pun dapat dibatalkan dan tidak ada insentif ekonomi untuk perselisihan. Ini tampaknya lebih baik daripada alternatif memblokir perselisihan sepenuhnya, tetapi memang cukup buruk, karena setiap orang yang berduka dapat memblokir relai tanpa batas dengan membayar gas atau mengirim relai buruk tanpa hukuman (selain biaya gas).Catatan: ini adalah alternatif untuk memiliki OO yang "membekukan" parameter seperti biaya akhir atau daftar putih jaminan untuk beberapa waktu, tetapi ini akan memerlukan panggilan tambahan ke OO, yang akan mahal untuk jalur bahagia.
Relay dapat dipercepat melalui
speedUpRelay()
setelah mereka melewati liveness. Meskipun kami tidak melihat risiko apa pun dengan ini, itu membuka kemungkinan untuk pinjaman flash + percepatan + penyelesaian setelah live, memberikan peminjam flash biaya relay instan untuk "gratis". Kami mencegah ini dalam usulan ini PR.
On
settle
, jikaBridgePool
adalahWETH
pool dan penerimanya adalah kontrak yang tidakpayable
(tidak dapat menerima ETH), lalusettle
akan gagal. Kami berencana untuk memperbaikinya dan mundur pada pengirimanWETH
, tetapi belum ada pekerjaan luar biasa yang dilakukan untuk ini.
In
relayDeposit
, kami memeriksa bahwaBridgePool
Saldo lebih besar dari jumlah untuk relay PLUS obligasi pengusul. Ini adalah cek usang dan terlalu konservatif karena ikatan pengusul ditarik dari pengguna setelah cek. Kami membahas ini dalam proposal ini PR.
Saya baru saja menangkap bug di mana
chainId
inBridgePool
, termasuk sebagai bagian dariDeposit
struct dan sebagai input fungsi ke semua fungsi terkait relai (misrelayDeposit
,speedUpRelay
,settle
) adalah tipeuint8
. Jenis ini terlalu kecil untuk ditangani Arbitrum misalnya dengan ID 421611. Kami sebenarnya menangkap bug ini dan memperbaikinya di sisi L2:BridgeDeposit
telah mengaturnyachainId
ketik keuint256
. PR ini akan membuatchainId
onBridgePool
cocok dengan jenisnyaBridgeDepositBox
: UMAprotokol/protokol#3463
Sebelumnya, fungsi sengketa tidak mengurangi jumlah setoran dari
pendingReserves
(ini adalah variabel yang melacak berapa banyak kumpulan cadangan yang terkunci karena relai yang belum diselesaikan). Hasilnya adalah bahwa setiap perselisihan tanpa batas waktu akan mengunci jumlah estafet di kolam. Itu tidak dapat ditarik oleh piringan hitam atau digunakan oleh relay masa depan. Perbaiki ada di sini: UMAprotokol/protokol#3473.
Kami menemukan bug di
BridgeDepositBox
dimanahasEnoughTimeElapsedToBridge
tidak memeriksa apakah auint256
nilainya sama dengan0
secara default: Diperbaiki di PR 3484
Metode nilai tukar (yang merupakan modifikasi status) dipanggil antara token yang ditransfer dan token LP yang dicetak dalam metode addLiquidity dari kontrak kumpulan jembatan. Perhitungan ini perlu dipindahkan ke atas metode. Ini menyebabkan nilai status yang sangat aneh. Lihat PR di sini memperbaiki.
Metode tampilan
liquidityUtilizationPostRelay
(yang hanya digunakan offchain), melaporkan nomor pemanfaatan yang salah. Penyebut pada garis ini seharusnya tidak adilliquidReserves
, seharusnya merupakan representasi dari cadangan yang belum dimanfaatkan dan dimanfaatkan. Tetap di sini.
Memperbarui
Selain perbaikan masalah, kami juga meninjau perubahan tambahan berikut:
- PR3500 menghapus parameter token yang berlebihan dari
BridgePool
acara. - PR3478 menambahkan biaya akhir DVM ke daftar variabel yang di-cache secara lokal.
- PR3460 memperhitungkan kemungkinan kasus tepi pemanfaatan likuiditas negatif (selain menangani N04)
- PR3482 menghapus file yang berlebihan dan memperbarui konstanta OVM sesuai dengan perubahan OVM 2.0.
- PR3585 memperbarui
BridgeDepositBox
antarmuka untuk konsistensi dan menggunakan OpenZeppelinSafeERC20
Perpustakaan.
Saat meninjau perbaikan, kami mengidentifikasi masalah lain. Dalam menentukan nilai BridgePool
Token LP, ada perhitungan menengah yang secara tak terduga dapat meluap negatif, yang untuk sementara akan menonaktifkan penambahan dan penghapusan likuiditas. Perhitungan harus disusun ulang untuk menambah cadangan yang digunakan sebelum mengurangi biaya yang tidak dibagikan.
Tingkat keparahan kritis
[C01] Hadiah Pengusul yang Terjebak
Grafik LongShortPair
kontrak mengambil hadiah pengusul dari alamat mana pun yang memicu kedaluwarsa, yang digunakan untuk memberi insentif pada proposal harga di Oracle Optimis. Namun, LongShortPairCreator
kontrak juga mengambil dan meneruskan dana dari alamat penyebar. Dana tambahan ini tidak diteruskan ke Oracle Optimis, dan malah tetap terjebak di dalam LongShortPair
kontrak.
Pertimbangkan untuk menghapus transfer duplikat.
Update: Diperbaiki pada komit 9bab1ff353a417952ba8c96a098773f340d9da17
in PR3523.
Keparahan tinggi
[H01] Relai konkuren menghabiskan cadangan
Grafik relayDeposit
fungsi dari BridgePool
kontrak memastikan kontrak memiliki dana yang cukup untuk melaksanakan transfer. Namun, itu tidak memperhitungkan cadangan yang tertunda, yang melacak dana yang dialokasikan untuk relai aktif. Oleh karena itu, beberapa relai simultan dapat mengandalkan dana yang sama, dan mungkin tidak semuanya dapat diselesaikan dengan segera. Khususnya, dengan aliran transfer yang stabil, pengembalian relai instan mungkin tertunda tanpa batas waktu.
Pertimbangkan untuk mencegah relai yang akan menyebabkan cadangan yang tertunda melebihi cadangan cairan.
Update: Diperbaiki pada komit 6290f3facbca8d878605a1d390ed59d4b6b6db02
in PR3501.
[H02] Batas parameter penghubung tidak cocok
Grafik deposit
fungsi dari BridgeDepositBox
kontrak, ditempatkan pada rantai lapisan 2, digunakan untuk menjembatani dana antara L2 dan L1. Secara khusus, relayer diberi insentif untuk menyampaikan detail transaksi pada L1 terkait BridgePool
. Namun, kotak deposit menggunakan batas inklusif untuk membatasi biaya estafet, sedangkan kolam jembatan menggunakan batas eksklusif. Ini berarti bahwa beberapa setoran (dengan biaya relai 25%) tidak dapat diteruskan, dan dana tidak dapat diakses di kedua lapisan.
Pertimbangkan untuk menyinkronkan validasi pada kedua lapisan untuk memastikan semua deposit yang valid dapat diteruskan.
Update: Tetap di komit 2345966b3a2ace0159379b3a13256cc1a4c5d52f
of PR3494. Ini awalnya diklasifikasikan sebagai tingkat keparahan Kritis tetapi diturunkan ketika tim UMA menunjukkan bahwa dana tidak akan benar-benar terperangkap dan dapat dilepaskan jika pemilih DVM setuju untuk menerima deskripsi relai yang dimodifikasi untuk deposito yang terkena dampak.
Keparahan sedang
[M01] Panggilan balik ke alamat yang salah
Grafik SkinnyOptimisticOracle
memanggil fungsi panggilan balik pada pemohon harga, jika ada, sehingga pemohon dapat merespons perubahan status yang signifikan. Namun, panggilan balik salah dipanggil pada pengusul harga, bukan pemohon harga di itu proposePriceFor
fungsi. Ini berarti pemohon harga tidak dapat menanggapi proposal harga.
Untungnya, fitur ini tidak digunakan dalam basis kode saat ini. Namun demikian, pertimbangkan untuk menggunakan priceProposed
panggilan balik pada pemohon.
Update: Tetap di komit 7bd3faeb6f3706132f77b9ba2dce192d1a151e74
in PR3531.
[M02] Fungsi penambahan yang salah
Grafik appendKeyValueBytes32
fungsi harus menggabungkan inputnya ke dalam format bytes
Himpunan. Namun, currentAncillaryData
is salah dibuang.
Karena data tambahan mempengaruhi proses resolusi Oracle, nilai yang salah dapat merusak hasil oracle. Untungnya, hanya ada satu panggilan ke appendKeyValueBytes32
di basis kode, dan menggunakan yang kosong currentAncillaryData
buffer, sehingga bug tidak mempengaruhi kasus ini.
Pertimbangkan untuk memperbarui appendKeyValueBytes32
berfungsi sehingga currentAncillaryData
disertakan dalam array byte yang dikembalikan.
Update: Tetap di komit 5609433c154f47e8ee9c52f9b6d7c787fbe3e455
of PR3532.
[M03] Validasi data tambahan tidak lengkap
Grafik LongShortPair
pembina menegaskan bahwa customAncillaryData
cukup kecil. Namun, itu tidak memperhitungkan bidang kedaluwarsa awal. Ini berarti Oracle Optimis mungkin tiba-tiba menolak permintaan harga kedaluwarsa awal, yang akan menonaktifkan fitur ini.
Pertimbangkan untuk memperbarui validasi untuk memperhitungkan bidang tambahan.
Update: Diperbaiki pada komit 4a56e66492f40e20254cebb145c2d91304f7cb43
in PR3524.
[M04] Stempel waktu nol yang salah ditangani
Dalam majalah LongShortPair
kontrak, stempel waktu kedaluwarsa awal nol adalah digunakan sebagai bendera untuk menunjukkan bahwa tidak ada yang memicu mekanisme kedaluwarsa awal. Namun, adalah mungkin untuk memicu mekanisme itu dengan stempel waktu nol. Dalam skenario ini, Oracle Optimis akan dipanggil tetapi perlindungan terhadap permintaan harga berikutnya tidak akan efektif. Untungnya, sekali harga penyelesaian dipilih, itu tidak akan ditimpa, jadi ini tidak akan mengarah pada penyelesaian yang tidak konsisten. Namun demikian, permintaan harga selanjutnya bisa ubah stempel waktu kedaluwarsa awal yang tercatat, bahkan jika stempel waktu nol digunakan untuk menentukan harga penyelesaian. Bisa juga memancarkan peristiwa yang menyesatkan.
Pertimbangkan untuk mencegah kedaluwarsa dini menggunakan stempel waktu nol.
Update: Diperbaiki pada komit 11d287c07c93c04f534b2ef3c869966d9f18ac60
in PR3526.
[M05] Kemungkinan ikatan nol
Grafik requestPrice
fungsi dari SkinnyOptimisticOracle
kontrak menggunakan biaya akhir sebagai obligasi jika ikatan tidak ditentukan. Namun, requestAndProposePriceFor
fungsi dapat menggunakan ikatan nol, yang bertentangan dengan @notice
dan @param
komentar. Ikatan nol melemahkan insentif terhadap proposal atau perselisihan yang tidak valid.
Untungnya, hanya memanggil fungsi ini di basis kode menetapkan ikatan pengusul. Namun demikian, pertimbangkan untuk menggunakan biaya akhir jika obligasi tidak ditentukan.
Update: Diperbaiki pada komit daaabfc342ba1395a577159b6eb26adb20fcd232
in PR3534.
[M06] Hak administrator yang tidak perlu
Grafik BridgePool
kontrak mewarisi dari ExpandedERC20
sehingga dapat menerbitkan token LP ke penyedia likuiditas. Ini mewarisi fungsionalitas OpenZeppelin ERC20
kontrak dan juga memberikan hak administrator ke penyebar kontrak, yang memungkinkan mereka untuk mencetak dan membakar token LP. Namun, kekuatan ini tidak diperlukan dan, jika dilakukan, dapat menghukum penyedia likuiditas secara tidak adil.
Pertimbangkan untuk memodifikasi BridgePool
untuk mewarisi langsung dari ERC20
alih-alih ExpandedERC20
.
Update: Tetap di komit 370e8b21b660543eadbd764fed984a5bdeddce24
in PR3492.
Tingkat keparahan rendah
[L01] Tidak dapat diselesaikan saat kedaluwarsa
Grafik settle
fungsi dari LongShortPair
kontrak mempertimbangkan kondisi pemukiman ketika waktu saat ini benar-benar sebelum atau setelah stempel waktu kedaluwarsa. Namun, itu salah kembali ketika waktu saat ini cocok dengan stempel waktu kedaluwarsa.
Pertimbangkan untuk menggunakan ikatan inklusif untuk mencocokkan postExpiration
pengubah.
Update: Tetap di komit f03cdaa50b16d29e8f42f000bf7cd50a042cf616
in PR3527.
[L02] Pesan kesalahan tidak ada dalam pernyataan yang diperlukan
Ada pernyataan yang membutuhkan dalam BridgePool
kontrak tanpa pesan kesalahan.
Pertimbangkan untuk menyertakan pesan kesalahan yang spesifik dan informatif dalam semua pernyataan yang diperlukan.
Update: Diperbaiki pada komit 67e60faa3a44c842c37211d2e903a983ff192e57
in PR3536.
[L03] Dokumen hilang
Ada beberapa contoh di seluruh basis kode di mana Spesifikasi Alami Ethereum tidak ada atau tidak lengkap. Contohnya meliputi:
Pertimbangkan untuk mendokumentasikan semua fungsi (dan parameternya) secara menyeluruh yang merupakan bagian dari API publik kontrak.
Update: Komentar yang disorot diperbaiki dalam komit e943e85a7dae60acd17a6d6aa027fbb1017c95ee
of PR3533. Kami tidak memvalidasi kelengkapan NatSpec di seluruh basis kode.
Catatan & Informasi Tambahan
[N01] Nilai pengembalian panggilan tidak dicentang
Dalam majalah deposit
fungsi dari L2 BridgeDepositBox
kontrak ada panggilan tingkat rendah ke l2Token
ketika l1Token
is l1Weth
. Panggilan tingkat rendah ini untuk deposit()
fungsi, yang termasuk dalam Weth antarmuka. Jika ini l2Token
berperilaku persis seperti WETH seharusnya tidak pernah gagal. Tetapi dalam kasus l2Token
berperilaku berbeda dan gagal, tidak akan ada pengembalian karena flag keberhasilan panggilan tingkat rendah ini tidak pernah diperiksa.
Pertimbangkan untuk memeriksa dan bereaksi dengan tepat terhadap nilai kembalian semua panggilan tingkat rendah.
[N02] Kurangnya parameter yang diindeks dalam acara
Banyak peristiwa yang didefinisikan dalam basis kode ini memiliki parameter yang harus diindeks:
Mempertimbangkan mengindeks parameter peristiwa untuk menghindari menghalangi tugas pencarian dan pemfilteran layanan off-chain untuk acara tertentu.
Update: Sebagian diperbaiki dalam komit d156b40b2ddb109806336c4d169dbdea91ed1c3e
of PR3535. itu chainId
parameter dari WhitelistToken
tidak diperbarui.
[N03] Inkonsistensi casting implisit
Grafik LongShortPair
kontrak umumnya memperlakukan stempel waktu sebagai uint64
nilai-nilai, yang secara implisit dilemparkan ke uint256
nilai ketika diteruskan ke Oracle Optimis. Namun, requestTimestamp
parameter dari itu _requestOraclePrice
fungsi sebelum waktunya dilemparkan ke a uint256
. Ini tidak memiliki konsekuensi fungsional.
Namun demikian, demi konsistensi, pertimbangkan untuk menggunakan a uint64
untuk parameter ini dan memungkinkannya untuk secara implisit dilemparkan ke a uint256
ketika diteruskan ke Oracle Optimis.
Update: Tetap di komit 1c3c5c000ef450f5e2da056e41caff468c3fcdcb
of PR3528. Stempel waktu sekarang secara eksplisit dilemparkan.
[N04] Jenis salah
Grafik sendMessage
fungsi dari iOptimism_CrossDomainMessenger
antarmuka menggunakan uint256
batas gas sedangkan Optimisme OVM_CrossDomainEnabled
menggunakan uint32
batas gas.
Untuk konsistensi dan prediktabilitas, pertimbangkan untuk memperbarui iOptimisim_CrossDomainMessenger
sendMessage
fungsi untuk menggunakan uint32
batas gas.
Update: Diperbaiki pada komit 381951aad988bbba6b2ef1b136ed5c48df50aa88
in PR3460.
[N05] Kurang validasi
Semua fungsi di BridgeAdmin
panggilan itu _relayMessage
asumsikan nilai transaksi cocok dengan l1CallValue
parameter, tetapi ini tidak diterapkan.
Pertimbangkan untuk memastikan yang benar msg.value
diatur.
Update: Diperbaiki pada komit f19b8d04c2343051ff2a8145abd41c39bd025063
in PR3537.
[N06] Keterbacaan
Grafik _getDepositHash
fungsi dari BridgePool
kontrak membuka gulungan depositData
struct untuk interstise the l1Token
sebagai argumen dalam komposisi keccak256
pada pengatur terkenal. Pengatur ini menawarkan bantuan hukum kepada traderapabila trader berselisih dengan broker yang terdaftar dengan mereka. abi
pengkodean. Ini membuat operasi tidak perlu bertele-tele dan dapat menyebabkan bug ketika diterapkan kembali pada lapisan lain.
Pertimbangkan untuk menyederhanakan argumen menjadi pasangan terurut depositData
dan l1Token
.
Update: Diperbaiki pada komit 31754be4a818109fa12131f854c3f70d6c72dba7
in PR3538.
[N07] Fungsi masuk kembali
Grafik requestAndProposePriceFor
fungsi dari SkinnyOptimisticOracle
kontrak membuat panggilan ke yang tidak dipercaya msg.sender
tapi tidak dijaga oleh nonReentrant
pengubah. Meskipun, dalam hal ini, hal ini tampaknya tidak menjadi masalah keamanan, hal ini dapat menimbulkan perilaku yang tidak diharapkan.
Pertimbangkan untuk menambahkan nonReentrant
pengubah ke semua fungsi yang membuat panggilan ke kontrak yang mungkin tidak tepercaya.
Update: Tetap di komit b744d24e7579b7afa2c778f4dd680f26117b3990
of PR3539.
[N08] seqNum
tidak masuk
Grafik relayMessage
fungsi dari Arbitrum_Messenger
kontrak tidak memancarkan peristiwa yang relevan setelah melakukan tindakan sensitif. Itu relayMessage
pemanggilan fungsi sebagai subrutin sentTxToL2NoAliasing
yang dengan sendirinya mengembalikan uint256
nilai seqNum
, tetapi nilai pengembalian ini tidak dicatat di relayMessage
fungsi.
Pertimbangkan untuk memancarkan peristiwa setelah perubahan sensitif terjadi, untuk memfasilitasi pelacakan dan memberi tahu klien off-chain setelah aktivitas kontrak.
Update: Diperbaiki pada komit 30343f33532a6c255dc4cc18c3b497d9b2767a7c
in PR3541.
[N09] Kesalahan tipografi
Basis kode berisi kesalahan ketik berikut:
Pertimbangkan untuk memperbaiki kesalahan ketik ini untuk meningkatkan keterbacaan kode.
Update: Diperbaiki pada komit 2dccbe1c2c82fe2a21c179ac06c2d4f0d911a2ca
in PR3540.
[N10] Persyaratan persetujuan ERC20 tidak berdokumen
Grafik requestEarlyExpiration
dan expire
fungsi dari LongShortPair
kontrak masing-masing menganggap bahwa penelepon telah memberikan kontrak tunjangan untuk tarik hadiah pengusul.
Demi prediktabilitas, pertimbangkan untuk mendokumentasikan persyaratan ini dalam komentar fungsi.
Update: Tetap di komit da3754f50284480df57b90b80002da06a1ce0d02
in PR3529.
[N11] Pengubah yang tidak digunakan
Dalam majalah BridgePool
kontrak, itu onlyFromOptimisticOracle
pengubah didefinisikan tetapi tidak pernah digunakan dalam basis kode dan karena itu harus dihapus.
Update: Tetap di komit 7abece6377637e8c4cd3bd07ab9adcfa051d4e94
in PR3542.
Kesimpulan
2 masalah kritis dan 1 masalah tingkat keparahan tinggi ditemukan. Beberapa perubahan diusulkan untuk mengikuti praktik terbaik dan mengurangi potensi serangan permukaan.
- &
- 7
- Akun
- Tindakan
- aktif
- Ad
- Tambahan
- alamat
- admin
- Keuntungan
- Semua
- Membiarkan
- api
- argumen
- Audit
- tersedianya
- makhluk
- TERBAIK
- Praktik Terbaik
- blockchain
- Kotak
- JEMBATAN
- Bug
- bug
- panggilan
- kasus
- tertangkap
- Menyebabkan
- menantang
- perubahan
- memeriksa
- kode
- komentar
- konfigurasi
- mengandung
- kontrak
- kontrak
- bisa
- terbaru
- data
- Terdesentralisasi
- menunda
- Mendesain
- menentukan
- MELAKUKAN
- Perselisihan
- Tidak
- Awal
- Ekonomis
- Tepi
- Efektif
- ERC20
- ETH
- ethereum
- Blockchain Ethereum
- Acara
- peristiwa
- contoh
- Pasar Valas
- diharapkan
- pengalaman
- Fitur
- Biaya
- keuangan
- Pertama
- Memperbaiki
- flash
- mengikuti
- ditemukan
- fungsi
- dana
- dana-dana
- masa depan
- GAS
- biaya gas
- Pemberian
- pemerintahan
- senang
- memiliki
- di sini
- High
- Disorot
- pemegang
- Seterpercayaapakah Olymp Trade? Kesimpulan
- HTTPS
- insentif
- termasuk
- Termasuk
- Meningkatkan
- informasi
- bunga
- Antarmuka
- masalah
- IT
- dikenal
- memimpin
- Perpustakaan
- Cair
- Likuiditas
- penyedia likuiditas
- Daftar
- Pinjaman
- lokal
- terkunci
- LP
- Piringan hitam
- Pasar
- Cocok
- paling
- Buka
- peramal
- Lainnya
- Platform
- kolam
- Kolam renang
- kekuasaan
- mencegah
- harga pompa cor beton mini
- proses
- usul
- memberikan
- menyediakan
- publik
- alasan
- menurunkan
- laporan
- ISTIRAHAT
- Hasil
- Pengembalian
- ulasan
- Risiko
- keamanan
- Layanan
- set
- penyelesaian
- Pendek
- penting
- mirip
- kecil
- So
- soliditas
- Seseorang
- sesuatu
- kecepatan
- menghabiskan
- Negara
- Pernyataan
- penyimpanan
- sukses
- Didukung
- Permukaan
- sistem
- uji
- Melalui
- di seluruh
- waktu
- token
- Token
- puncak
- Pelacakan
- .
- Transaksi
- Kepercayaan
- Memperbarui
- Pembaruan
- UPS
- Pengguna
- nilai
- View
- whitelist
- SIAPA
- dalam
- tanpa
- Kerja
- bernilai
- nol