Percayalah atau tidak, Uniswap v4 akan segera memenuhi semua orang!

Kali ini, tim Uniswap telah menetapkan tujuan ambisius dan berencana untuk memperkenalkan banyak fitur baru, termasuk jumlah kolam likuiditas yang tak terbatas dan biaya dinamis untuk setiap pasangan perdagangan, desain singleton, akuntansi cepat, Hook, dan dukungan untuk standar token ERC1155. Dengan memanfaatkan penyimpanan sementara yang diperkenalkan oleh EIP-1153, Uniswap v4 diharapkan akan dirilis setelah upgrade Ethereum Cancun. Di antara banyak inovasi, mekanisme Hook telah mendapatkan perhatian luas karena potensi yang kuat. Mekanisme Hook memungkinkan kode spesifik untuk dieksekusi pada titik-titik spesifik dalam siklus hidup kolam likuiditas, sangat meningkatkan skalabilitas dan fleksibilitas kolam. Namun, mekanisme Hook juga dapat menjadi pisau bermata dua. Meskipun kuat dan fleksibel, penggunaan Hook dengan aman juga merupakan tantangan signifikan. Kompleksitas Hook tak terelakkan membawa potensi vektor serangan baru. Oleh karena itu, kami berharap untuk menulis serangkaian artikel untuk secara sistematis memperkenalkan isu keamanan dan risiko potensial terkait mekanisme Hook, untuk mempromosikan pengembangan keamanan komunitas. Kami yakin wawasan ini akan membantu membangun Uniswap v4 Hooks yang aman. Sebagai artikel pembuka dari seri ini, artikel ini memperkenalkan konsep-konsep terkait mekanisme Hook dalam Uniswap v4 dan menguraikan risiko keamanan yang terkait dengan mekanisme Hook.

- 1 - Mekanisme Uniswap V4

Sebelum menyelam lebih dalam, kita memerlukan pemahaman dasar tentang mekanisme di balik Uniswap v4. Menurut pengumuman resmi [1] dan whitepaper [2], Hooks, arsitektur singleton, dan akuntansi kilat adalah tiga fitur penting yang memungkinkan kolam likuiditas yang disesuaikan dan routing yang efisien di sejumlah kolam.

1.1 Hook

Hooks mengacu pada kontrak yang berjalan pada berbagai tahap siklus keberlangsungan pool likuiditas. Tim Uniswap berharap dapat memungkinkan siapa pun untuk membuat keputusan tradeoff dengan memperkenalkan Hooks. Dengan cara ini, dukungan asli untuk biaya dinamis, pesanan batas on-chain, atau time-weighted average market makers (TWAMMs) untuk membagi pesanan besar bisa diimplementasikan. Saat ini, ada delapan callback Hooks, dibagi menjadi empat pasang (setiap pasang berisi satu callback sebelum dan satu sesudah):

• beforeInitialize/afterInitialize
• sebelumModifikasiPosisi/setelahModifikasiPosisi
• sebelumSwap/setelahSwap
• sebelumDonasi/setelahDonasi

Di bawah ini adalah alur swap Hook yang diperkenalkan dalam whitepaper [2].

Gambar 1: Alur Swap Hook

Tim Uniswap mendemonstrasikan metodologi dengan beberapa contoh (mis. TWAMM Hook [3]), dan peserta komunitas juga telah memberikan kontribusi. Dokumentasi resmi [4] juga menghubungkan ke repositori Awesome Uniswap v4 Hooks [5], yang mengumpulkan lebih banyak contoh Hook.

1.2 Singleton, Flash Accounting, dan Mekanisme Kunci

Arsitektur singleton dan akuntansi 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. Pada versi-versi sebelumnya dari protokol Uniswap, operasi seperti pertukaran atau penambahan likuiditas melibatkan transfer token langsung. Versi 4 berbeda dalam hal memperkenalkan akuntansi kilat dan mekanisme kunci.

👇🏻 Mekanisme kunci berfungsi sebagai berikut: 1. Kontrak pengunci meminta kunci dari PoolManager. 2. PoolManager menambahkan alamat kontrak pengunci ke antrian lockData dan memanggil callback lockAcquired-nya. 3. Kontrak pengunci menjalankan logikanya di dalam callback. Interaksi dengan pool selama eksekusi dapat mengakibatkan penambahan mata uang non-nol. Namun, pada akhir eksekusi, semua penambahan harus nol bersih. Selain itu, jika antrian lockData tidak kosong, hanya kontrak pengunci terakhir yang dapat menjalankan operasi. 4. PoolManager memeriksa status antrian lockData dan penambahan mata uang. Setelah verifikasi, PoolManager menghapus kontrak pengunci.

Secara ringkas, mekanisme kunci mencegah akses bersamaan dan memastikan semua transaksi dapat diselesaikan. Kontrak Locker meminta kunci secara berurutan, kemudian menjalankan perdagangan melalui panggilan lockAcquired. Panggilan Hook yang sesuai dipicu sebelum dan setelah setiap operasi kolam. Akhirnya, PoolManager memeriksa status. Ini berarti operasi menyesuaikan saldo bersih internal (yaitu delta) daripada melakukan transfer instan. Setiap modifikasi dicatat dalam saldo internal kolam, dengan transfer aktual terjadi ketika operasi (yaitu kunci) selesai. Proses ini menjamin tidak ada token yang tertunda, menjaga integritas dana. Karena mekanisme kunci, akun milik eksternal (EOA) tidak dapat berinteraksi langsung dengan PoolManager. Sebaliknya, setiap interaksi harus melalui kontrak. Kontrak ini bertindak sebagai pengunci perantara, meminta kunci sebelum melakukan operasi kolam apa pun.

👇🏻 Ada dua skenario interaksi kontrak utama:

• Kontrak loker berasal dari kode sumber resmi, atau dideploy oleh pengguna. Dalam hal ini, kita dapat melihat interaksi tersebut sebagai melalui router.
• Kontrak loker dan Hook terintegrasi ke dalam kontrak yang sama, atau dikendalikan oleh entitas pihak ketiga. Untuk kasus ini, kita dapat melihat interaksi sebagai melalui Hook. Di sini, Hook memainkan peran baik kontrak loker maupun menangani panggilan balik.

- 2 -Model Ancaman

Sebelum membahas isu keamanan terkait, kita perlu menetapkan model ancaman. Kita utamanya mempertimbangkan dua kasus berikut:

• Model Ancaman I: Hook itu sendiri tidak berbahaya tetapi mengandung kerentanan.
• Model Ancaman II: Hook itu sendiri bersifat jahat.

Dalam bagian-bagian berikut, kami akan membahas masalah keamanan potensial sesuai dengan dua model ancaman ini.

2.1 Masalah Keamanan dalam Model Ancaman I

Model Ancaman I berfokus pada kerentanan yang terkait dengan Hook itu sendiri. Model ancaman ini mengasumsikan pengembang dan Hook mereka tidak jahat. Namun, kerentanan yang diketahui ada pada kontrak pintar juga dapat muncul pada Hook. Sebagai contoh, jika sebuah Hook diimplementasikan sebagai kontrak yang dapat diupgrade, mungkin akan mengalami isu terkait kerentanan seperti OpenZeppelin UUPSUpgradeable. Mengingat faktor-faktor di atas, kami memilih untuk fokus pada kerentanan potensial yang unik untuk versi 4. Di Uniswap v4, Hook adalah kontrak pintar yang dapat menjalankan logika kustom sebelum atau setelah operasi inti kolam (termasuk inisialisasi, modifikasi posisi, pertukaran, dan pengumpulan). Meskipun diharapkan Hook mengimplementasikan antarmuka standar, mereka juga memungkinkan logika kustom. Oleh karena itu, diskusi kami akan terbatas pada logika yang melibatkan antarmuka Hook standar. Kami kemudian akan mencoba mengidentifikasi sumber-sumber kerentanan potensial, misalnya bagaimana Hook mungkin menyalahgunakan fungsi Hook standar tersebut.

👇🏻 Secara khusus, kami akan fokus pada dua jenis Hooks berikut:

• Jenis kait pertama menahan dana pengguna. Dalam kasus ini, penyerang mungkin menyerang kait ini untuk mentransfer dana, menyebabkan kerugian aset.
• Jenis kedua dari hook menyimpan data status kritis yang dibutuhkan oleh pengguna atau protokol lainnya. Dalam kasus ini, penyerang mungkin mencoba untuk mengubah status kritis. Ketika pengguna atau protokol lain menggunakan status yang salah, mungkin ada risiko potensial.

Perhatikan bahwa hooks di luar dua cakupan ini tidak dibahas di sini. Karena tidak ada kasus penggunaan Hook dunia nyata pada saat penulisan ini, kami akan mengambil beberapa informasi dari repositori Awesome Uniswap v4 Hooks. Setelah studi mendalam repositori Awesome Uniswap v4 Hooks (hash commit 3a0a444922f26605ec27a41929f3ced924af6075), kami mengidentifikasi beberapa kerentanan serius. Kerentanan ini terutama berasal dari interaksi berisiko antara hook, PoolManager, dan pihak ketiga eksternal, dan dapat dibagi menjadi dua kategori: masalah kontrol akses dan masalah validasi input. Temuan khusus ditunjukkan dalam tabel di bawah ini:

Secara ringkas, kami mengidentifikasi 22 proyek yang relevan (tidak termasuk yang tidak terkait dengan Uniswap v4). Di antara proyek-proyek ini, kami percaya 8 (36%) memiliki kerentanan. Dari 8 proyek yang rentan, 6 memiliki masalah kontrol akses dan 2 rentan terhadap panggilan eksternal yang tidak terpercaya.

Masalah Kontrol Akses 2.1.1

Pada bagian diskusi ini, kami terutama fokus pada masalah fungsi panggilan kembali dalam v4, termasuk 8 panggilan kembali dan panggilan kunci. Tentu saja ada kasus lain yang perlu diverifikasi tetapi mereka bervariasi menurut desain dan saat ini di luar cakupan. Fungsi-fungsi ini hanya boleh dipanggil oleh PoolManager, bukan alamat lain (termasuk EOAs dan kontrak). Sebagai contoh, dalam kasus di mana imbalan didistribusikan dari kunci pool, imbalan tersebut dapat salah klaim jika fungsi-fungsi yang sesuai dapat dipanggil oleh akun sembarangan. Oleh karena itu, membangun mekanisme kontrol akses yang kuat sangat penting untuk hook karena mereka dapat dipanggil oleh pihak lain selain pool itu sendiri. Dengan ketat mengatur izin akses, kolam likuiditas dapat signifikan mengurangi risiko yang terkait dengan interaksi yang tidak sah atau berbahaya dengan hook.

2.1.2 Masalah Validasi Input

Pada Uniswap v4, karena mekanisme kunci, pengguna harus memperoleh kunci melalui kontrak sebelum mengeksekusi operasi kolam apa pun. Hal ini memastikan kontrak yang sedang berinteraksi saat ini adalah kontrak pengunci terbaru. Namun, masih ada skenario serangan potensial dari panggilan eksternal yang tidak dipercayai karena validasi input yang tidak tepat dalam beberapa implementasi Hook yang rentan:

• Pertama, kait tidak memverifikasi kolam renang yang ingin digunakan pengguna. Ini bisa menjadi kolam renang jahat dengan token palsu yang menjalankan logika berbahaya.
• Kedua, beberapa fungsi kait kunci memungkinkan panggilan eksternal sembarangan.

Panggilan eksternal yang tidak dipercayai sangat berbahaya karena dapat menyebabkan berbagai jenis serangan termasuk serangan reentrancy yang terkenal. Untuk menyerang hook yang rentan ini, penyerang dapat mendaftarkan pool jahat dengan token palsu untuk diri mereka sendiri, kemudian memanggil hook untuk menjalankan operasi pada pool. Saat berinteraksi dengan pool, logika token jahat mencuri alur kontrol untuk tindakan yang tidak benar.

2.1.3 Tindakan Perlawanan untuk Model Ancaman I

Untuk mengelakkan isu keselamatan yang berkaitan dengan hook tersebut, adalah penting untuk melaksanakan kawalan akses yang diperlukan pada fungsi-fungsi luar/dalam yang sensitif dan mengesahkan input untuk mengesahkan interaksi. Selain itu, penjaga reentransi mungkin membantu memastikan hook tidak dimasuki semula semasa aliran logik standard. Dengan melaksanakan perlindungan keselamatan yang betul, pool boleh mengurangkan risiko yang berkaitan dengan ancaman tersebut.

2.2 Masalah Keamanan dalam Model Ancaman II

Dalam model ancaman ini, kita mengasumsikan pengembang dan hook mereka bersifat jahat. Mengingat cakupan yang luas, kita hanya fokus pada masalah keamanan yang terkait dengan versi 4. Kuncinya terletak pada apakah hook yang disediakan dapat menangani transfer pengguna atau otorisasi kripto. Karena metode mengakses hook menentukan izin yang mungkin diberikan kepada hook, kita mengkategorikan hook ke dalam dua jenis berdasarkan ini:

• Managed Hooks: Hook bukanlah titik masuk. Pengguna harus berinteraksi dengan hook melalui router (mungkin disediakan oleh Uniswap).
• Standalone Hooks: Hook adalah titik masuk, memungkinkan pengguna berinteraksi langsung dengannya.

Gambar 2: Contoh kait jahat

2.2.1 Hook Dikelola

Dalam kasus ini, aset kripto pengguna (termasuk token asli dan token lainnya) ditransfer atau disetujui ke router. Karena PoolManager melakukan pemeriksaan saldo, perangkat jahat tidak dengan mudah mencuri aset-aset ini secara langsung. Namun, permukaan serangan potensial masih ada. Sebagai contoh, mekanisme pengelolaan biaya dalam versi 4 mungkin dimanipulasi oleh penyerang melalui hooks.

2.2.2 Hook Mandiri

Ketika kait digunakan sebagai titik masuk, situasinya menjadi lebih kompleks. Di sini, karena pengguna dapat berinteraksi langsung dengan kait, kait diberi lebih banyak kekuatan. Secara teori, kait dapat menjalankan operasi apa pun yang diinginkan melalui interaksi tersebut. Pada versi 4, verifikasi logika kode sangat penting. Masalah utamanya adalah apakah logika kode dapat dimanipulasi. Jika kait dapat ditingkatkan, ini berarti kait yang tampak aman dapat menjadi jahat setelah diupgrade, menghadirkan risiko signifikan. Risiko-risiko ini termasuk:

• Proksi yang dapat ditingkatkan (yang dapat diserang langsung)
• Logika dengan diri yang memusnahkan diri. Mungkin diserang bersamaan dengan memanggil selfdestruct dan create2.

2.2.3 Tindakan Pencegahan untuk Model Ancaman II

Titik penting adalah menilai apakah kaitannya bersifat jahat. Secara khusus, untuk kait yang dikelola kita harus waspada terhadap perilaku manajemen biaya; sedangkan untuk kait mandiri, fokus utamanya adalah apakah mereka dapat ditingkatkan.

- 3 - Kesimpulan

Dalam artikel ini, kami pertama-tama secara singkat menguraikan mekanisme inti yang terkait dengan masalah keamanan Uniswap v4 Hook. Kami kemudian mengusulkan dua model ancaman dan secara singkat menguraikan risiko keamanan yang terkait. Dalam artikel lanjutan, kami akan melakukan analisis mendalam tentang masalah keamanan di bawah masing-masing model ancaman. Tetap terhubung!

Referensi

[1] Visi Kami untuk Uniswap V4
https://blog.uniswap.org/uniswap-v4

Draf whitepaper Uniswap v4 [2]
https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf

[3] Kaitan TWAMM Uniswap v4
https://blog.uniswap.org/v4-twamm-hook

Contoh Hook [4]
https://docs.uniswapfoundation.org/hooks/hook-examples

[5] Kait Uniswap v4 yang Luar Biasa
https://github.com/fewwwww/awesome-uniswap-hooks

[6] Kerentanan Upgradeable UUPS Pasca-mortem
https://forum.openzeppelin.com/t/uupsupgradeable-vulnerability-post-mortem/15680

Tentang BlockSec BlockSec adalah perusahaan keamanan blockchain global terkemuka yang didirikan pada tahun 2021 oleh pakar terkemuka di industri keamanan. Perusahaan ini berdedikasi untuk meningkatkan keamanan dan kegunaan untuk dunia Web3 guna mempromosikan adopsi luas Web3. Untuk mencapai hal ini, BlockSec menyediakan layanan audit keamanan smart contract dan rantai EVM, sistem pengembangan, pengujian, dan intersepsi hacker yang disebut Phalcon untuk pemilik proyek, platform pelacakan dana dan investigasi yang disebut MetaSleuth, serta plugin efisiensi untuk pembangun web3 yang disebut MetaDock. Saat ini, perusahaan telah melayani lebih dari 300 klien, termasuk proyek-proyek ternama seperti MetaMask, Compound, Yayasan Uniswap, Forta, PancakeSwap, dan telah menerima dua putaran pendanaan dengan total lebih dari puluhan juta dolar dari lembaga investasi seperti Oasis Capital, IDG Capital, dan Distributed Capital. Beranda: www.blocksec.com

Twitter：https://twitter.com/BlockSecTeam

Phalcon: https://phalcon.xyz/

MetaSleuth: https://metasleuth.io/

MetaDock: https://blocksec.com/metadock

Penafian：

1. Artikel ini dicetak ulang dari [BlokSec]. Semua hak cipta milik penulis asli [BlokSec]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.
2. Penolakan Tanggung Jawab: Pandangan dan opini yang diungkapkan dalam artikel ini semata-mata milik penulis dan tidak menjadi saran investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.