Uniswap v4 menggunakan Hook untuk likuiditi yang boleh diprogramkan, tetapi menjadi sasaran serangan utama akibat kelemahan dalam kod pengurusan kebenaran dan kawalan akses, perlu berhati-hati terhadap risiko penyalahgunaan Hook Async dan logik akaun.

Penulis artikel, sumber: Beosin

Selepas pelancaran utama Uniswap v4, mekanisme Hook menjadi salah satu inovasi paling diperhatikan dalam DeFi. Platform pelancaran memecoin di rantai Base, Flaunch, menggunakan Hook untuk mencapai harga pra-jual tetap dan mekanisme pelancaran automatik; protokol likuiditi Bunni v2 menggunakan Hook untuk membina model likuiditi boleh program dan semula jaminan; pada tahun ini, token-token seperti SATO, uPEG (Unipeg), dan Slonks yang berpusat pada permainan Hook juga mencatatkan kenaikan puluhan kali ganda dalam tempoh singkat.

Di sebalik kemakmuran ekosistem Hook, serangan terhadap kelemahan pelaksanaan Hook juga meningkat secara ketara. Artikel ini akan bermula dengan mekanisme Hook Uniswap v4, menganalisis secara bertahap stak pemanggilan utamanya, membantu pihak projek memahami kelemahan yang mungkin wujud.

Keselamatan Uniswap v4 Hook

Perubahan arsitektur paling ketara Uniswap v4 berbanding v3 ialah pengenalan mekanisme Hook: membenarkan pembangun memasang kontrak tersuai pada peristiwa kitaran hidup kolam likuiditi, serta menyuntik logik apa sahaja pada titik-titik seperti swap, menambah atau mengurangkan likuiditi, dan inisialisasi.

Perubahan utama dalam v4 adalah seperti berikut:

Pola Singleton: Semua status kolam dikelola secara terpusat oleh kontrak PoolManager tunggal, tanpa perlu menerapkan kontrak terpisah untuk setiap kolam

- Akuntansi kilat: Perubahan saldo sementara semasa proses transaksi hanya dicatat dalam penyimpanan sementara, dan hanya dijumlahkan sekali pada akhir transaksi

Mekanisme Hook: Setiap kolam boleh dikaitkan dengan kontrak Hook, dan PoolManager akan memanggil semula kontrak tersebut pada titik-titik penting (beforeInitialize, beforeSwap, afterAddLiquidity, dsb.)

- Hook tidak boleh ditukar: Setelah inisialisasi kolam selesai, alamat Hook yang dipautkan tetap tetap (alamat Hook yang dipautkan kepada kolam tidak boleh diubah, tetapi sama ada kontrak Hook itu sendiri boleh ditingkatkan bergantung pada cara ia dilaksanakan)

Pada masa v3, pembangun hanya perlu mempercayai protokol Uniswap itu sendiri; manakala pada masa v4, keselamatan setiap pasangan bergantung kepada Hook yang dilekatkan padanya. Hook mengembangkan AMM daripada satu primitif kewangan tetap menjadi satu infrastruktur kewangan yang boleh diprogramkan, tetapi model keselamatan telah terpecah daripada “peringkat protokol” kepada “peringkat pasangan”.

2. Struktur Hook 2.1 PoolManager dan model unlock/callback

Kontrak inti v4 adalah PoolManager yang merupakan singleton. Sebarang operasi perubahan status kolam (swap, tambah/kurangkan likuiditi) mesti memanggil PoolManager.unlock() terlebih dahulu untuk mendapatkan kebenaran panggilan balik sekali sahaja, kemudian menyelesaikan tindakan spesifik di dalam unlockCallback(). Semasa proses selesai, PoolManager akan mengesahkan sama ada buku besar seimbang:

Bila NonzeroDeltaCount != 0, teruskan revert; ini adalah batasan utama dalam akuntansi flash v4. Sebarang Hook boleh sementara menyebabkan ketidakseimbangan akaun semasa pelaksanaan, tetapi mesti menyelesaikannya sendiri sebelum penghujung transaksi, jika tidak, keseluruhan transaksi akan dipulihkan.

Setiap kolam dikenal secara unik oleh struktur PoolKey, yang mengandung medan hooks:

PoolId dihitung menggunakan keccak256(PoolKey), oleh itu, alamat hooks yang berbeza akan menghasilkan pasaran yang berbeza. Ini juga bermakna, PoolManager tidak akan mengesahkan sama ada alamat Hook tertentu pernah digunakan untuk pasaran lain, dan kontrak Hook yang sama boleh diikat secara serentak oleh beberapa pasaran.

2.2 Kod bit kebenaran Hook dalam alamat

Satu reka bentuk yang tidak intuitif pada v4 ialah: kebenaran Hook bukan ditentukan oleh pemboleh ubah tertentu di dalam kontrak, tetapi ditentukan oleh alamat penghantaran kontrak Hook.

PoolManager memeriksa 14 bit terendah alamat Hook untuk menentukan sama ada Hook tersebut perlu dipanggil pada titik siklus hidup tertentu:

Sebagai contoh, BEFORE_SWAP_FLAG = 1 << 7. Jika bit ke-7 alamat Hook adalah 1, PoolManager akan memanggil beforeSwap() dari Hook sebelum swap; jika tidak, walaupun kontrak Hook telah mengimplementasikan beforeSwap(), ia tidak akan pernah dipanggil oleh PoolManager.

Ini bermaksud bahawa alamat Hook mesti dikira menggunakan CREATE2 + salt untuk membina alamat dengan rendah yang serasi sepenuhnya dengan kebenaran sasaran. Uniswap menyediakan alat HookMiner untuk tujuan ini:

Ketika bit kebenaran tidak sejalan dengan pelaksanaan fungsi, ia akan menghasilkan dua jenis masalah:

(1) Telah melaksanakan fungsi hook tertentu, tetapi alamat tidak dikodkan dengan bit kebenaran yang sesuai—PoolManager tidak akan memanggil fungsi ini, logiknya tidak berfungsi

(2) Alamat mengkodekan bit kebenaran tertentu, tetapi hook tidak mengimplementasikan fungsi yang sesuai—PoolManager mungkin mengalami revert semasa panggilan balik, menyebabkan DOS atau kegagalan pengesahan nilai pulangan, yang mengakibatkan operasi berkaitan tidak dapat dilaksanakan.

Ini juga merupakan rintangan semula jadi kepada peningkatan Hook: jika Hook boleh ditingkatkan melalui proxy, alamat penghantaran tidak berubah semasa peningkatan, oleh itu selepas peningkatan, hanya implementasi fungsi Hook yang sedia ada yang boleh dimodifikasi, bukan menambah jenis Hook baru. Untuk menyediakan keupayaan kembangan masa depan, semua bit kebenaran yang mungkin digunakan mesti dijanakan semasa penghantaran awal.

2.3 BaseHook dan satu jebakan kawalan akses yang sering diabaikan

Kontrak abstrak BaseHook yang disediakan oleh periphery Uniswap v4 versi lama membolehkan pembangun mewarisi ia untuk mengimplementasikan Hook tersuai. Salah satu peranan penting BaseHook ialah menyediakan penyesuai onlyPoolManager untuk fungsi unlockCallback():

Namun—terdapat jebakan reka bentuk yang sangat mudah diabaikan—versi awal BaseHook hanya menambahkan onlyPoolManager kepada unlockCallback, tanpa perlindungan apa pun terhadap fungsi panggilan balik lain (beforeSwap, afterSwap, beforeAddLiquidity, dll.). Kawalan akses untuk fungsi-fungsi ini mesti ditambahkan secara eksplisit oleh pembangun Hook sendiri.

Sebagai contoh satu pertukaran exact-input, berikut adalah analisis penuh panggilan stak dari permulaan transaksi pengguna hingga penyelesaian.

3.1 Inisialisasi kolam dan ikatan Hook

Sesiapa sahaja boleh memanggil PoolManager.initialize() untuk mencipta kolam baru:

isValidHookAddress hanya mengesahkan kesesuaian bit keizinan alamat dengan bidang fee, tidak mengesahkan sama ada Hook telah digunakan dalam kolam lain, atau sama ada Hook tersebut "bersedia" menerima PoolKey ini. Jika Hook direka tanpa logik senarai putih atau pengikatan kolam tunggal dalam beforeInitialize, sesiapa sahaja boleh membina kolam baru yang menggunakan Hook yang sama tetapi pasangan token apa sahaja, dan memicu semua panggilan balik seterusnya oleh Hook.

3.2 beforeSwap dan BeforeSwapDelta

Titik masuk proses swap ialah PoolManager.swap(), yang memanggil Hooks.beforeSwap() sebelum melaksanakan logik swap utama:

Nilai balasan beforeSwap ialah satu tiga pasangan (bytes4, BeforeSwapDelta, uint24):

- bytes4: mesti sama dengan IHooks.beforeSwap.selector, jika tidak, PoolManager akan revert secara terus

- BeforeSwapDelta: Hook menyesuaikan delta bagi token yang ditentukan dan token yang tidak ditentukan dalam swap ini

- uint24: Nilai cakupan kadar LP dinamik (hanya berkuasa apabila kolam menghidupkan kadar dinamik)

BeforeSwapDelta ialas int256, 128 bit tertinggi ialah delta token yang ditentukan (iaitu token yang ditentukan pengguna), dan 128 bit terendah ialah delta token yang tidak ditentukan:

Perlu diperhatikan bahawa makna BeforeSwapDelta ialah Hook yang mengenakan caj harus mengembalikan nilai positif, manakala Hook yang mengembalikan token harus mengembalikan nilai negatif. Pembangun mudah tersilap tanda; selain itu, hubungan antara specified dan unspecified bergantung kepada params.zeroForOne dan tanda positif/negatif amountSpecified, di mana penulisan yang sedikit salah boleh menyebabkan token tersilap.

PoolManager akan menambahkan specifiedDelta yang dikembalikan oleh beforeSwap secara langsung ke amountToSwap:

Baris ini mengandungi makna penting: Hook boleh menahan jumlah swap. Apabila hookDeltaSpecified sama dengan -params.amountSpecified, amountToSwap secara langsung menjadi sifar, yang bererti Hook mengambil alih sepenuhnya swap ini—ini dikenali sebagai Async Hook atau Custom Curve Hook.

Async Hook adalah salah satu corak reka bentuk paling berisiko dalam v4: ia pada dasarnya menggantikan logik swap Uniswap dengan logik Hook sendiri. Jika Hook mengandungi lubang keamanan atau secara intrinsik jahat, dana pengguna tidak lagi dilindungi oleh logik penetapan harga asli Uniswap, tetapi bergantung terutamanya pada kebetulan pelaksanaan Hook itu sendiri.

3.3 Penyelesaian Delta dan NonzeroDeltaCount

delta yang dikembalikan oleh beforeSwap dan afterSwap tidak akan memicu pemindahan dana secara langsung, tetapi dicatat ke dalam buku besar dalaman PoolManager:

Apabila delta terkumpul bagi sebarang token berubah daripada sifar kepada bukan sifar, NonzeroDeltaCount bertambah; apabila kembali kepada sifar, ia berkurang. Seperti yang dinyatakan dalam 2.1, apabila unlock() selesai, jika NonzeroDeltaCount != 0, keseluruhan transaksi akan revert.

Hook menyeimbangkan deltanya melalui dua tindakan: settle() (mentransfer ke PoolManager) dan take() (mengambil dari PoolManager):

Mekanisme ini membawa makna keselamatan yang jelas: semua pihak akhirnya harus menutup akaun mereka. Namun, ia hanya menjamin “kekalahan akaun”, bukan “kebenaran akaun”. Jika Hook mengembalikan delta yang sengaja dirakamkan semasa beforeSwap, PoolManager akan setia mencatatkan delta tersebut, selagi ia akhirnya ditutup semasa settle, transaksi dianggap berjaya—walaupun ini bermakna Hook boleh memalsukan keadaan perniagaan, menyebabkan sistem salah menganggap penyerang memiliki hak aset tertentu, dan PoolManager tidak mampu mengenal pasti kesalahan perniagaan ini.

Peristiwa keselamatan Cork Protocol sebelum ini berlaku kerana terdapat lubang pada Hook-nya, dan ia telah melalui audit oleh empat syarikat audit sebelum diserang. Selepas kejadian, kami mendapati:

Dari empat audit, tiga daripadanya tidak merangkumi kontrak CorkHook

- Satu-satunya pihak yang mengaudit CorkHook mengenal pasti beberapa masalah kod dan mengemukakan cadangan penambahbaikan, tetapi tidak merangkumi sepenuhnya masalah kawalan akses

- Sebuah pihak audit lain dalam laporan mereka secara jelas mencadangkan: “an interesting follow-up engagement would be to prove the invariants for the CorkHook functions that are being invoked by different components verified within the scope of this engagement”. Cadangan ini mempunyai kejituan yang tinggi dari sudut tinjauan pasca-kejadian.

Ini mengungkapkan celah audit baru di era v4 Hook: pertumbuhan eksponensial dalam kompleksiti protokol menjadikan penentuan lingkup itu sendiri sebagai keputusan keselamatan. Rantai interaksi antara Hook dan kontrak lain protokol sangat panjang; hanya mengaudit kontrak Hook sahaja tidak cukup untuk mengesan masalah kombinasi antar-kontrak; sebaliknya, mengaudit kontrak sekitarnya sambil mengecualikan Hook daripada lingkup akan melewatkan permukaan serangan terbesar di era v4.

Dengan membandingkan mekanisme protokol dan serangan Cork, beberapa poin utama model keselamatan v4 Hook boleh diringkaskan:

(1) Jika fungsi panggilan balik Hook bergantung pada konteks panggilan yang disediakan oleh PoolManager, ia harus secara eksplisit dibatasi agar hanya boleh dipanggil oleh PoolManager. BaseHook tidak akan melakukan ini untuk pembangun, ini adalah perangkap reka bentuk yang paling bertentangan dengan pengalaman audit kontrak biasa di v4.

(2) Hubungan pengikatan Hook dengan kolam tidak dibatasi oleh PoolManager. Pembangun mesti mengimplementasikan senarai putih kolam atau pengikatan kolam tunggal secara sendiri dalam beforeInitialize.

(3) Kebenaran alamat Hook mesti serasi secara ketat dengan pelaksanaan fungsi. Alamat yang dikira harus mengandungi semua kebenaran yang mungkin diperluas di masa depan secara awal.

(4) Hook Kurva Asinkron / Khusus pada dasarnya adalah implementasi swap yang sepenuhnya disesuaikan. Ia tidak mempunyai perlindungan pada peringkat protokol Uniswap dan mesti diaudit mengikut piawaian "kontrak kewangan autonomi penuh".

(5) Delta akuntansi "konservasi" tidak sama dengan "betul". NonzeroDeltaCount == 0 hanya menjamin buku besar seimbang pada akhirnya, bukan menjamin kandungan buku besar tidak dimanipulasi secara jahat

(6) Kebingungan jenis token antar pasaran merupakan permukaan serangan baharu di era v4. Apabila protokol membenarkan pengguna mencipta pasaran, pengesahan semantik token adalah wajib dan tidak boleh bergantung semata-mata pada pemeriksaan antaramuka.

Setiap Hook adalah domain kepercayaan yang berasingan, dan keselamatan setiap kolam ditentukan oleh Hook yang terikat padanya. Oleh itu, kompleksiti audit keselamatan Hook bukan lagi “mengaudit satu kod”, tetapi “mengaudit satu protokol sampingan yang lengkap” — perubahan ini bermakna peningkatan metodologi bagi pihak projek dan pihak audit.

(1) Protokol Cork. “Post-Mortem Serangan 28 Mei 2025.” 2025-06-04. https://www.cork.tech/blog/post-mortem

(2) OWASP Smart Contract Security Top 10 2026, SC01: Kerentanan Kawalan Akses. https://scs.owasp.org/sctop10/SC01-AccessControlVulnerabilities/

(3) Whitepaper Uniswap v4. https://app.uniswap.org/whitepaper-v4.pdf

(4) Uniswap v4-core. https://github.com/Uniswap/v4-core

(5) Uniswap v4-periphery. https://github.com/Uniswap/v4-periphery

Beosin merupakan salah satu syarikat keselamatan blockchain pertama di dunia yang fokus pada pengesahan formal, menawarkan perniagaan ekosistem lengkap "keselamatan + kepatuhan". Syarikat ini mempunyai cawangan di lebih daripada 10 negara dan wilayah, dengan perkhidmatan yang merangkumi audit keselamatan kod sebelum pelancaran projek, pemantauan dan penghalangan risiko keselamatan semasa operasi projek, pemulihan aset yang dicuri, anti pencucian wang (AML) untuk aset maya, serta penilaian kepatuhan yang memenuhi keperluan peraturan setempat—semuanya sebagai produk dan perkhidmatan kepatuhan blockchain "sekali jalan". Sila klik kotak mesej di saluran kami untuk menghubungi kami.