Mekanisme Hook Uniswap v4: Potensi dan Risiko Bersamaan
Uniswap v4 akan segera diluncurkan, pembaruan kali ini memperkenalkan berbagai fitur baru, termasuk dukungan untuk jumlah tak terbatas pool likuiditas per pasangan perdagangan dan biaya dinamis, desain tunggal, pencatatan kilat, mekanisme Hook, serta dukungan untuk standar token ERC1155. Di antara fitur-fitur tersebut, mekanisme Hook menarik perhatian luas karena potensi kuatnya.
Mekanisme Hook memungkinkan eksekusi kode kustom pada titik tertentu dalam siklus hidup kolam likuiditas, yang secara signifikan meningkatkan skalabilitas dan fleksibilitas kolam. Namun, mekanisme Hook juga bisa menjadi pedang bermata dua. Meskipun kuat dan fleksibel, penggunaan Hook yang aman juga merupakan tantangan yang tidak kecil. Kompleksitas Hook secara tak terhindarkan membawa potensi vektor serangan baru.
Artikel ini akan memperkenalkan konsep terkait mekanisme Hook di Uniswap v4 dan merangkum risiko keamanan yang ada.
Mekanisme Inti Uniswap v4
Sebelum membahas lebih dalam, kita perlu memiliki pemahaman dasar tentang mekanisme Uniswap v4. Menurut pengumuman resmi dan buku putih, Hook, arsitektur tunggal, dan pembukuan kilat adalah tiga fungsi penting untuk mewujudkan kolam likuiditas yang disesuaikan dan routing yang efisien di antara beberapa kolam.
Mekanisme Hook
Hook merujuk pada kontrak yang beroperasi pada berbagai tahap siklus hidup kolam likuiditas, yang bertujuan untuk memungkinkan siapa saja membuat keputusan trade-off. Dengan cara ini, dukungan asli untuk biaya dinamis dapat dicapai, menambahkan order limit on-chain, atau melakukan pasar dengan rata-rata tertimbang waktu untuk mendiversifikasi order besar (TWAMM).
Saat ini ada delapan callback Hook, dibagi menjadi empat grup ( setiap grup berisi satu pasangan callback ):
sebelumInisialisasi/setelahInisialisasi
sebelumUbahPosisi/setelahUbahPosisi
sebelumTukar/setelahTukar
sebelumDonasi/setelahDonasi
Singleton, pencatatan kilat, dan mekanisme kunci
Arsitektur singleton dan pencatatan kilat bertujuan untuk meningkatkan kinerja dengan mengurangi biaya dan memastikan efisiensi. Ini memperkenalkan kontrak singleton baru, di mana semua kolam likuiditas disimpan dalam kontrak pintar yang sama. Desain singleton ini bergantung pada PoolManager untuk menyimpan dan mengelola status semua kolam.
Versi v4 memperkenalkan pencatatan kilat dan mekanisme penguncian. Cara kerja mekanisme penguncian adalah sebagai berikut:
Kontrak locker meminta lock di PoolManager.
PoolManager menambahkan alamat kontrak locker tersebut ke dalam antrean lockData, dan memanggil callback lockAcquired-nya.
Kontrak locker menjalankan logikanya dalam callback. Interaksi dengan kolam selama proses eksekusi mungkin menyebabkan peningkatan mata uang yang tidak nol, tetapi pada akhir eksekusi, semua peningkatan harus diselesaikan menjadi nol.
PoolManager memeriksa status antrean lockData dan peningkatan mata uang. Setelah verifikasi, hapus kontrak locker tersebut.
Secara umum, mekanisme penguncian mencegah akses bersamaan dan memastikan bahwa semua transaksi dapat diselesaikan. Metode ini berarti bahwa penyesuaian operasi adalah pada saldo bersih internal, bukan melakukan transfer instan. Setiap modifikasi akan dicatat dalam saldo internal kolam, sedangkan transfer yang sebenarnya dilakukan pada akhir operasi.
Karena adanya mekanisme penguncian, semua akun eksternal (EOA) tidak dapat berinteraksi langsung dengan PoolManager. Semua interaksi harus dilakukan melalui kontrak. Terdapat dua skenario interaksi kontrak yang utama:
kontrak locker berasal dari repositori kode resmi atau dikerahkan oleh pengguna. Situasi ini dapat dianggap sebagai interaksi melalui router.
kontrak locker dan Hook diintegrasikan ke dalam kontrak yang sama, atau dikontrol oleh entitas pihak ketiga. Situasi ini dapat dianggap sebagai interaksi melalui Hook.
Model Ancaman
Sebelum membahas masalah keamanan yang relevan, kita perlu menentukan model ancaman. Dua situasi utama yang perlu dipertimbangkan adalah:
Model ancaman I: Hook itu sendiri bersifat baik, tetapi terdapat celah.
Model ancaman II: Hook itu sendiri bersifat jahat.
Masalah keamanan dalam model ancaman I
Model ancaman I berfokus pada kerentanan yang terkait dengan Hook itu sendiri. Model ancaman ini mengasumsikan bahwa pengembang dan Hook mereka tidak berniat jahat. Namun, kerentanan yang diketahui dari kontrak pintar yang ada juga dapat muncul di Hook.
Kami memilih untuk fokus pada potensi kerentanan yang khas dari versi v4, terutama memperhatikan dua jenis Hook berikut:
Hook yang menyimpan dana pengguna. Penyerang mungkin akan menyerang Hook ini untuk memindahkan dana, menyebabkan kerugian aset.
Hook untuk menyimpan data status kunci yang bergantung pada pengguna atau protokol lain. Penyerang mungkin mencoba untuk mengubah status kunci, yang dapat menimbulkan risiko potensial ketika pengguna atau protokol lain menggunakan status yang salah.
Setelah diteliti, kami menemukan beberapa kerentanan serius yang terutama berasal dari interaksi risiko antara Hook, PoolManager, dan pihak ketiga eksternal, yang dapat dibagi menjadi dua kategori: masalah kontrol akses dan masalah validasi input.
Masalah kontrol akses
Fungsi callback dalam v4 dapat menyebabkan masalah, termasuk 8 Hook callback dan lock callback. Fungsi-fungsi ini seharusnya hanya dapat dipanggil oleh PoolManager, dan tidak boleh dipanggil oleh alamat lain. Untuk Hook, sangat penting untuk membangun mekanisme kontrol akses yang kuat, terutama karena mereka dapat dipanggil oleh pihak lain selain kolam itu sendiri.
Masalah verifikasi input
Meskipun ada mekanisme penguncian, masih ada kemungkinan skenario serangan, yaitu panggilan eksternal yang tidak tepercaya yang disebabkan oleh validasi input yang tidak tepat dalam beberapa implementasi Hook yang rentan:
Hook tidak memverifikasi pool dana yang ingin diinteraksi oleh pengguna. Ini bisa menjadi pool dana jahat yang mengandung token palsu dan menjalankan logika yang merugikan.
Beberapa fungsi Hook kunci memungkinkan panggilan eksternal yang sembarangan.
Panggilan eksternal yang tidak tepercaya sangat berbahaya, dapat menyebabkan berbagai jenis serangan, termasuk serangan reentrancy.
Tindakan pencegahan
Untuk menghindari masalah keamanan terkait Hook, sangat penting untuk melakukan kontrol akses yang diperlukan pada fungsi eksternal/publik yang sensitif dengan baik dan memverifikasi parameter input, sehingga interaksi dapat divalidasi. Selain itu, perlindungan reentrancy dapat membantu memastikan bahwa Hook tidak dijalankan berulang kali dalam alur logika standar.
masalah keamanan dalam model ancaman II
Dalam model ancaman ini, kami mengasumsikan bahwa pengembang dan Hook mereka bersifat jahat. Kuncinya adalah apakah Hook yang diberikan dapat menangani transfer atau otorisasi aset kripto pengguna.
Menurut metode akses Hook, kami membagi Hook menjadi dua kategori:
Hook Terkelola: Hook bukan titik masuk. Pengguna harus berinteraksi dengan Hook melalui router.
Hook Mandiri: Hook adalah titik masuk yang memungkinkan pengguna berinteraksi langsung.
Hook Tipe Custodian
Aset kripto pengguna telah ditransfer atau diberikan otorisasi kepada router. Karena PoolManager melakukan pemeriksaan saldo, Hook jahat tidak mudah mencuri aset ini secara langsung. Namun, masih ada potensi permukaan serangan, misalnya mekanisme manajemen biaya pada versi v4 dapat dimanipulasi oleh penyerang melalui Hook.
Hook Independen
Ketika Hook digunakan sebagai titik masuk, situasinya menjadi lebih kompleks. Hook mendapatkan lebih banyak kekuatan, secara teoritis dapat melakukan operasi apa pun yang diinginkan melalui interaksi ini.
Dalam versi v4, verifikasi logika kode sangat penting. Masalah utama adalah apakah logika kode dapat dimanipulasi. Jika Hook dapat diperbarui, ini berarti Hook yang tampaknya aman dapat menjadi jahat setelah diperbarui, sehingga menimbulkan risiko besar. Risiko ini termasuk:
Proksi yang dapat ditingkatkan ( dapat diserang secara langsung )
Memiliki logika penghancuran diri. Dapat diserang dalam kasus pemanggilan bersamaan selfdestruct dan create2.
Tindakan pencegahan
Poin yang sangat penting adalah mengevaluasi apakah Hook bersifat jahat. Secara khusus, untuk Hook yang dikelola, kita harus memperhatikan perilaku manajemen biaya; sedangkan untuk Hook independen, fokus utamanya adalah apakah mereka dapat ditingkatkan.
Kesimpulan
Artikel ini memberikan gambaran singkat tentang mekanisme inti yang terkait dengan masalah keamanan Hook pada Uniswap v4, serta mengusulkan dua model ancaman dan risiko keamanan terkait. Meskipun mekanisme Hook sangat kuat, ia juga membawa tantangan keamanan baru. Baik pengembang maupun pengguna perlu sepenuhnya menyadari risiko potensial ini dan mengambil langkah-langkah pencegahan yang tepat untuk memastikan keamanan aset saat menggunakan Uniswap v4.
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Uniswap v4 Hook mekanisme: tantangan keamanan di balik fitur yang kuat
Mekanisme Hook Uniswap v4: Potensi dan Risiko Bersamaan
Uniswap v4 akan segera diluncurkan, pembaruan kali ini memperkenalkan berbagai fitur baru, termasuk dukungan untuk jumlah tak terbatas pool likuiditas per pasangan perdagangan dan biaya dinamis, desain tunggal, pencatatan kilat, mekanisme Hook, serta dukungan untuk standar token ERC1155. Di antara fitur-fitur tersebut, mekanisme Hook menarik perhatian luas karena potensi kuatnya.
Mekanisme Hook memungkinkan eksekusi kode kustom pada titik tertentu dalam siklus hidup kolam likuiditas, yang secara signifikan meningkatkan skalabilitas dan fleksibilitas kolam. Namun, mekanisme Hook juga bisa menjadi pedang bermata dua. Meskipun kuat dan fleksibel, penggunaan Hook yang aman juga merupakan tantangan yang tidak kecil. Kompleksitas Hook secara tak terhindarkan membawa potensi vektor serangan baru.
Artikel ini akan memperkenalkan konsep terkait mekanisme Hook di Uniswap v4 dan merangkum risiko keamanan yang ada.
Mekanisme Inti Uniswap v4
Sebelum membahas lebih dalam, kita perlu memiliki pemahaman dasar tentang mekanisme Uniswap v4. Menurut pengumuman resmi dan buku putih, Hook, arsitektur tunggal, dan pembukuan kilat adalah tiga fungsi penting untuk mewujudkan kolam likuiditas yang disesuaikan dan routing yang efisien di antara beberapa kolam.
Mekanisme Hook
Hook merujuk pada kontrak yang beroperasi pada berbagai tahap siklus hidup kolam likuiditas, yang bertujuan untuk memungkinkan siapa saja membuat keputusan trade-off. Dengan cara ini, dukungan asli untuk biaya dinamis dapat dicapai, menambahkan order limit on-chain, atau melakukan pasar dengan rata-rata tertimbang waktu untuk mendiversifikasi order besar (TWAMM).
Saat ini ada delapan callback Hook, dibagi menjadi empat grup ( setiap grup berisi satu pasangan callback ):
Singleton, pencatatan kilat, dan mekanisme kunci
Arsitektur singleton dan pencatatan kilat bertujuan untuk meningkatkan kinerja dengan mengurangi biaya dan memastikan efisiensi. Ini memperkenalkan kontrak singleton baru, di mana semua kolam likuiditas disimpan dalam kontrak pintar yang sama. Desain singleton ini bergantung pada PoolManager untuk menyimpan dan mengelola status semua kolam.
Versi v4 memperkenalkan pencatatan kilat dan mekanisme penguncian. Cara kerja mekanisme penguncian adalah sebagai berikut:
Kontrak locker meminta lock di PoolManager.
PoolManager menambahkan alamat kontrak locker tersebut ke dalam antrean lockData, dan memanggil callback lockAcquired-nya.
Kontrak locker menjalankan logikanya dalam callback. Interaksi dengan kolam selama proses eksekusi mungkin menyebabkan peningkatan mata uang yang tidak nol, tetapi pada akhir eksekusi, semua peningkatan harus diselesaikan menjadi nol.
PoolManager memeriksa status antrean lockData dan peningkatan mata uang. Setelah verifikasi, hapus kontrak locker tersebut.
Secara umum, mekanisme penguncian mencegah akses bersamaan dan memastikan bahwa semua transaksi dapat diselesaikan. Metode ini berarti bahwa penyesuaian operasi adalah pada saldo bersih internal, bukan melakukan transfer instan. Setiap modifikasi akan dicatat dalam saldo internal kolam, sedangkan transfer yang sebenarnya dilakukan pada akhir operasi.
Karena adanya mekanisme penguncian, semua akun eksternal (EOA) tidak dapat berinteraksi langsung dengan PoolManager. Semua interaksi harus dilakukan melalui kontrak. Terdapat dua skenario interaksi kontrak yang utama:
kontrak locker berasal dari repositori kode resmi atau dikerahkan oleh pengguna. Situasi ini dapat dianggap sebagai interaksi melalui router.
kontrak locker dan Hook diintegrasikan ke dalam kontrak yang sama, atau dikontrol oleh entitas pihak ketiga. Situasi ini dapat dianggap sebagai interaksi melalui Hook.
Model Ancaman
Sebelum membahas masalah keamanan yang relevan, kita perlu menentukan model ancaman. Dua situasi utama yang perlu dipertimbangkan adalah:
Masalah keamanan dalam model ancaman I
Model ancaman I berfokus pada kerentanan yang terkait dengan Hook itu sendiri. Model ancaman ini mengasumsikan bahwa pengembang dan Hook mereka tidak berniat jahat. Namun, kerentanan yang diketahui dari kontrak pintar yang ada juga dapat muncul di Hook.
Kami memilih untuk fokus pada potensi kerentanan yang khas dari versi v4, terutama memperhatikan dua jenis Hook berikut:
Hook yang menyimpan dana pengguna. Penyerang mungkin akan menyerang Hook ini untuk memindahkan dana, menyebabkan kerugian aset.
Hook untuk menyimpan data status kunci yang bergantung pada pengguna atau protokol lain. Penyerang mungkin mencoba untuk mengubah status kunci, yang dapat menimbulkan risiko potensial ketika pengguna atau protokol lain menggunakan status yang salah.
Setelah diteliti, kami menemukan beberapa kerentanan serius yang terutama berasal dari interaksi risiko antara Hook, PoolManager, dan pihak ketiga eksternal, yang dapat dibagi menjadi dua kategori: masalah kontrol akses dan masalah validasi input.
Masalah kontrol akses
Fungsi callback dalam v4 dapat menyebabkan masalah, termasuk 8 Hook callback dan lock callback. Fungsi-fungsi ini seharusnya hanya dapat dipanggil oleh PoolManager, dan tidak boleh dipanggil oleh alamat lain. Untuk Hook, sangat penting untuk membangun mekanisme kontrol akses yang kuat, terutama karena mereka dapat dipanggil oleh pihak lain selain kolam itu sendiri.
Masalah verifikasi input
Meskipun ada mekanisme penguncian, masih ada kemungkinan skenario serangan, yaitu panggilan eksternal yang tidak tepercaya yang disebabkan oleh validasi input yang tidak tepat dalam beberapa implementasi Hook yang rentan:
Hook tidak memverifikasi pool dana yang ingin diinteraksi oleh pengguna. Ini bisa menjadi pool dana jahat yang mengandung token palsu dan menjalankan logika yang merugikan.
Beberapa fungsi Hook kunci memungkinkan panggilan eksternal yang sembarangan.
Panggilan eksternal yang tidak tepercaya sangat berbahaya, dapat menyebabkan berbagai jenis serangan, termasuk serangan reentrancy.
Tindakan pencegahan
Untuk menghindari masalah keamanan terkait Hook, sangat penting untuk melakukan kontrol akses yang diperlukan pada fungsi eksternal/publik yang sensitif dengan baik dan memverifikasi parameter input, sehingga interaksi dapat divalidasi. Selain itu, perlindungan reentrancy dapat membantu memastikan bahwa Hook tidak dijalankan berulang kali dalam alur logika standar.
masalah keamanan dalam model ancaman II
Dalam model ancaman ini, kami mengasumsikan bahwa pengembang dan Hook mereka bersifat jahat. Kuncinya adalah apakah Hook yang diberikan dapat menangani transfer atau otorisasi aset kripto pengguna.
Menurut metode akses Hook, kami membagi Hook menjadi dua kategori:
Hook Terkelola: Hook bukan titik masuk. Pengguna harus berinteraksi dengan Hook melalui router.
Hook Mandiri: Hook adalah titik masuk yang memungkinkan pengguna berinteraksi langsung.
Hook Tipe Custodian
Aset kripto pengguna telah ditransfer atau diberikan otorisasi kepada router. Karena PoolManager melakukan pemeriksaan saldo, Hook jahat tidak mudah mencuri aset ini secara langsung. Namun, masih ada potensi permukaan serangan, misalnya mekanisme manajemen biaya pada versi v4 dapat dimanipulasi oleh penyerang melalui Hook.
Hook Independen
Ketika Hook digunakan sebagai titik masuk, situasinya menjadi lebih kompleks. Hook mendapatkan lebih banyak kekuatan, secara teoritis dapat melakukan operasi apa pun yang diinginkan melalui interaksi ini.
Dalam versi v4, verifikasi logika kode sangat penting. Masalah utama adalah apakah logika kode dapat dimanipulasi. Jika Hook dapat diperbarui, ini berarti Hook yang tampaknya aman dapat menjadi jahat setelah diperbarui, sehingga menimbulkan risiko besar. Risiko ini termasuk:
Tindakan pencegahan
Poin yang sangat penting adalah mengevaluasi apakah Hook bersifat jahat. Secara khusus, untuk Hook yang dikelola, kita harus memperhatikan perilaku manajemen biaya; sedangkan untuk Hook independen, fokus utamanya adalah apakah mereka dapat ditingkatkan.
Kesimpulan
Artikel ini memberikan gambaran singkat tentang mekanisme inti yang terkait dengan masalah keamanan Hook pada Uniswap v4, serta mengusulkan dua model ancaman dan risiko keamanan terkait. Meskipun mekanisme Hook sangat kuat, ia juga membawa tantangan keamanan baru. Baik pengembang maupun pengguna perlu sepenuhnya menyadari risiko potensial ini dan mengambil langkah-langkah pencegahan yang tepat untuk memastikan keamanan aset saat menggunakan Uniswap v4.