Artikel ini dari: @Ehsan1579
Kompilasi | Odaily Planet Daily (@OdailyChina); Penerjemah | Ethan(@ethanzhang_web 3)
Hanya dengan melihat judul peristiwanya, kemungkinan besar akan salah mengira ini adalah serangan eksploitasi kerentanan.
Inti peristiwanya adalah: seseorang akhirnya hanya menerima AAVE senilai 35,9 ribu dolar AS dari penukaran USDT senilai 50,4 juta dolar AS.
Saat pertama kali mendengarnya, saya benar-benar terkejut. Karena itu, saya menyelidiki seluruh peristiwa ini dari ujung ke ujung: pelacakan transaksi, jalur solver, panggilan kontrak, cadangan historis, data penyelesaian, alur adaptor, kode antarmuka Aave, SDK pinjaman kilat CoW, serta kode perutean yang menilai apakah penawaran "wajar".
Ini bukanlah peretasan. Protokol inti Aave tidak bermasalah. Penyelesaian CoW tidak bermasalah. Uniswap tidak bermasalah. SushiSwap tidak bermasalah. Transaksinya valid, tanda tangannya valid, semua kontrak dieksekusi secara ketat sesuai kode. Namun, hampir semua nilai ekonomi hancur, hanya karena diizinkan mengambil rute yang sangat tidak masuk akal.
Blockchain publik tidak bermasalah, yang bermasalah adalah peruteannya.
Menurut saya, menggampangkan hal ini dan mengategorikannya sebagai sekadar "kesalahan operasi pengguna" bukanlah sikap yang objektif dan ketat. Memang benar pengguna menyelesaikan penandatanganan pesanan, tetapi seluruh sistem perangkat lunak ini, yang mengizinkan operasi perputaran kolateral hampir 50 juta dolar, menyelesaikan penawaran, penandatanganan, perencanaan rute hingga eksekusi akhir, dan seluruh alurnya mengarah ke pool likuiditas rendah yang hanya memegang sekitar 331 AAVE. Seharusnya ini mustahil terjadi, setidaknya seharusnya ditolak dan dihentikan dengan tegas oleh sistem sebelum tahap penyelesaian dimulai.
Pelacakan Informasi Inti Transaksi
Hash transaksi abnormal ini adalah: 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f, dikonfirmasi pada 12 Maret 2026 di blok Ethereum utama dengan tinggi 24643151, indeks transaksi 1, mengonsumsi 3780570 unit Gas, eksekusi transaksi berhasil. Pesanan berasal dari dompet dengan alamat dimulai 0x98b9, pengirim transaksi sebenarnya (solver) adalah alamat dimulai 0x3980, ditandai sebagai tsolver dalam data kompetisi CoW.
Pertama-tama harus dipahami, ini bukanlah penukaran USDT ke AAVE sederhana di tingkat dompet. Token yang dijual adalah aEthUSDT, yaitu sertifikat simpanan USDT berbunga di platform Aave. Token yang dibeli adalah aEthAAVE, yaitu sertifikat simpanan AAVE berbunga di platform Aave. Jadi, ini sebenarnya adalah perputaran kolateral Aave yang dilakukan melalui sistem penyelesaian protokol CoW dan alur adaptor pinjaman kilatnya.
Sebelum transaksi, dompet ini memegang sekitar 50.432.693,075254 aEthUSDT dan 0 aEthAAVE. Setelah transaksi, hanya tersisa 4,980399 aEthUSDT, dan menerima 327,241335505966487788 aEthAAVE. Sebenarnya, dompet ini menjual hampir seluruh posisinya.
Metadata menunjukkan lebih jelas bahwa rute sudah "beracun" sebelum dieksekusi. Pesanan berasal dari alur aave-v3-interface-collateral-swap. API CoW menampilkannya sebagai pesanan jual yang ditandatangani, dan metadata aplikasi menandainya sebagai tukar kolateral tipe harga pasar dengan slipage pintar 121 basis points. Jumlah jual yang ditandatangani adalah 50.432.688,41618 aEthUSDT. Jumlah beli minimum) yang ditandatangani adalah 324,949260918413591035 aEthAAVE. Penyelesaian aktual membayar 327,241335505966487788 aEthAAVE.
Ini adalah detail yang sangat penting. Pesanan ini tidak pernah berharap mendapatkan ribuan AAVE yang kemudian entah bagaimana hancur di tengah jalan. Dari awal dibangun, pesanan ini sudah mengarah pada hasil sekitar tiga ratusan AAVE.
Rantai Lengkap Keruntuhan Rute
Begitu Anda mengikuti pelacakan transaksi, seluruh prosesnya langsung terlihat dengan kejam.
Inti aliran dana tingkat atas mengandalkan kontrak penyelesaian GPv2Settlement protokol CoW yang beralamat dimulai 0x9008. Pertama, kontrak HooksTrampoline beralamat dimulai 0x60bf menyelesaikan operasi otorisasi aEthUSDT, memungkinkan relayer brankar CoW menarik aset pengguna tanpa otorisasi transaksi terpisah; kemudian, kontrak GPv2VaultRelayer beralamat dimulai 0xc92e menarik 50.432.688,41618 keping aEthUSDT dari dompet pengguna ke dalam alur penyelesaian, hingga tahap ini, semua operasi sesuai logika normal.
Kontrak penyelesaian kemudian memberikan izin operasi aEthUSDT ke kontrak bantu tidak open-source beralamat dimulai 0xd524, dan memulai panggilan melalui selector fungsi 0x494b3137; kontrak bantu ini kemudian menyerahkan izin eksekusi ke kontrak eksekutor tidak open-source beralamat dimulai 0x699c, pada titik ini, gambaran lengkap rute transaksi abnormal sepenuhnya terbuka.
Panggilan efektif pertama mengarah ke kontrak pool dana Aave beralamat dimulai 0x87870, melalui fungsi withdraw (selector 0x69328dec) menghancurkan aEthUSDT, menebus USDT native yang mendasarinya; kemudian rute melompat ke pool perdagangan dalam USDT/WETH Uniswap V3 beralamat dimulai 0x4e68, menukar seluruh 50.432.688,41618 keping USDT menjadi 17.957,810805702142342238 keping WETH.
Tahap transaksi ini sepenuhnya normal: tingkat tukar sekitar 2808,4 USDT untuk 1 WETH, sesuai kondisi pasar saat itu, tidak ada masalah likuiditas tidak cukup, tidak ada deviasi perhitungan, lompatan pertama rantai transaksi tidak ada yang abnormal.
Masalahnya ada pada lompatan kedua, begitu Anda melihat cadangan likuiditas, sisa ceritanya tidak terhindarkan.
Eksekutor mendapatkan 17.957,810805702142342238 keping WETH, kemudian mentransfer semua dana ke pool perdagangan SushiSwap V2 AAVE/WETH di alamat 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.
Saya memeriksa data cadangan likuiditas historis pool ini sesaat sebelum transaksi abnormal terjadi (tinggi blok 24643150), pool hanya memegang:
331,631982538108027323 keping AAVE, 17,653276196397688066 keping WETH
Ini bukan kesalahan entri data, tetapi fakta yang tak terbantahkan.
Rute transaksi ini, menyuntikkan hampir 17.958 WETH ke dalam pool perdagangan mini yang hanya memiliki cadangan 17,65 WETH, dengan total persediaan AAVE hanya 331,63 keping. Volume WETH yang dimasukkan sekitar 1017 kali lipat cadangan WETH dalam pool.
Ini sama sekali bukan masalah "slipage agak tinggi" atau "likuiditas agak tipis" biasa, tetapi merupakan jalur eksekusi pesanan harga pasar yang sangat tidak masuk akal, memaksa pool AMM produk konstan yang sangat kecil menanggung transaksi besar dengan skala ribuan kali lipat dari dirinya sendiri.
Pool perdagangan AMM menjalankan operasi sesuai algoritma yang ditetapkan, hampir menghabiskan seluruh cadangan AAVE dalam pool.
Pasangan perdagangan SushiSwap memicu peristiwa Swap inti: eksekutor mentransfer masuk 17.957,810805702142342238 keping WETH, hanya mendapat 331,305315608938235428 keping AAVE sebagai gantinya. Setelah transaksi, likuiditas yang tersisa di pool ini sekitar:
0,326666929169791895 keping AAVE, 17.975,464081898540030304 keping WETH
Singkatnya, sekitar 99,9% persediaan AAVE dalam pool terkuras dalam satu lompatan.
Berdasarkan cadangan sebelum transaksi, harga implisit AAVE pool sekitar 149,50 dolar AS. Harga eksekusi aktual pengguna sekitar 154.114,66 USDT untuk 1 AAVE. Ini lebih dari 1000 kali lipat dari harga spot sebelum transaksi.
Kemudian, AAVE ini disuplai kembali ke pool dana Aave, menggunakan selector 0x617ba037, yaitu supply(address,uint256,address,uint16). Hasilnya adalah aEthAAVE yang baru dicetak dikirim kembali ke kontrak penyelesaian. Kontrak penyelesaian akhirnya mentransfer 327,241335505966487788 aEthAAVE ke pengguna. Sekitar 4,06398010297174764 aEthAAVE tersisa di kontrak penyelesaian sebagai surplus relatif terhadap jumlah yang dibayar pengguna.
Jadi, penyelesaian tidak tiba-tiba memutarbalikkan hasil eksekusi yang baik menjadi hasil yang buruk. Itu hanya memfinalisasi hasil yang sudah dihasilkan oleh rute sebelumnya.
Ini poin kunci, layak dikatakan dengan jelas: Hasil bencana sudah "diprogram" dalam rute sebelum eksekusi.
Dalam data panggilan kontrak bantu yang tertanam dalam rute, jumlah target sisi beli sekitar 331,272185078031026739 keping, jumlah beli minimum yang disepakati tanda tangan pengguna adalah 324,949260918413591035 keping, jumlah penyelesaian aktual adalah 327,241335505966487788 keping, semua nilai inti terkunci pada tingkat beberapa ratus AAVE sebelum penyelesaian.
Rute ini dari sananya sudah rusak.
Di Mana Kerentanannya?
Jawabannya: Setiap lapisan mekanisme pemeriksaan sistem memverifikasi dimensi yang salah.
Semua lapisan hanya memverifikasi apakah transaksi dapat dieksekusi, apakah tanda tangan valid, apakah jumlahnya bukan nol,namun hampir tidak ada lapisan inti yang memverifikasi apakah rute transaksi masuk akal secara ekonomi, ini adalah akar kegagalan mekanisme.
Cacat Kode Jalur Penawaran Adaptor Antarmuka Aave
Titik abnormal kode pertama yang jelas, muncul dalam alur penawaran adaptor CoW antarmuka Aave: fungsi yang awalnya digunakan untuk menyertakan data aplikasi khusus adaptor saat meminta penawaran, secara langsung dinonaktifkan secara paksa.
Sumber: rates.helpers.ts:93 dan adapters.helpers.ts:194
Ini berarti antarmuka Aave saat meminta penawaran ke CoW, tidak menyertakan metadata pinjaman kilat dan hook yang akan dilampirkan saat pesanan benar-benar diposting. Dengan kata lain, hal yang ditawarkan tidak sepenuhnya sama dengan hal yang akan dieksekusi. Komentar kode bahkan mengatakan tujuan fungsi pembantu ini adalah untuk membuat penawaran adaptor lebih akurat, tetapi fungsi ini justru dinonaktifkan secara keras.
Logika Kompetisi Penawaran CoW Terlalu Lemah dalam Menentukan Kelayakan (Kerentanan Inti)
Masalah kedua dan paling serius, terletak pada logika kompetisi penawaran protokol CoW: dalam kode layanan publiknya, selama biaya Gas penawaran positif, jumlah keluaran bukan nol, akan dinilai sebagai "penawaran yang wajar".
Sumber: quote.rs:31
Bagi sistem perutean yang menangani pesanan delapan digit, ini adalah definisi "kelayakan" yang sangat lemah dan mengejutkan.
Sistem tidak terintegrasi dengan oracle untuk pemeriksaan kesehatan harga, tidak ada mekanisme pencegahan untuk "penawaran menyimpang lebih dari 500 kali dari harga spot", tidak ada penilaian risiko "rute akan menguras habis pool likuiditas", tidak ada peringatan "likuiditas lompatan terakhir sangat tidak sesuai dengan ukuran pesanan"; hanya meminta solver mengembalikan skema rute yang dapat dieksekusi dan bukan nol, akan diterima oleh sistem, ini adalah kerentanan inti dari peristiwa ini.
Cacat Logika Pemodelan Likuiditas Gaya Uniswap V2
Masalah ketiga, terletak pada cara pemodelan pool likuiditas gaya Uniswap V2: kode hanya menggunakan algoritma produk konstan standar, hanya menolak situasi mustahil secara matematis seperti cadangan nol, underflow numerik, overflow cadangan, tidak melakukan pemeriksaan kelayakan ekonomi.
Sumber: pool_fetching.rs:118 dan pool_fetching.rs:153
Bagian kode ini tidak akan menilai apakah ukuran pool likuiditas cukup untuk menanggung transaksi rute yang sesuai, hanya menilai apakah operasi swap valid secara matematis. Oleh karena itu, bahkan pool mini yang hanya memiliki cadangan 331 AAVE, akan dinilai sebagai tempat yang valid untuk menerima permintaan beli 17.957 WETH, hanya karena algoritma produk konstan dapat menghitung hasil bukan nol, tetapi sepenuhnya mengabaikan bahwa hasil ini akan menyebabkan kerugian aset yang menghancurkan.
Kegagalan Sekunder SDK Pinjaman Kilat dan Mekanisme Validasi Pesanan
Kemudian, SDK pinjaman kilat langsung mengkonsolidasikan penawaran yang gagal ini ke dalam muatan eksekusi pesanan dan hook, tanpa melakukan pencegahan risiko sekunder apa pun.
Lalu:
Sumber: index.js:484 dan index.js:591
Inilah mengapa saya selalu mengatakan rute ini "dari sananya sudah rusak". Lapisan adaptor tidak "menemukan" jumlah yang buruk saat eksekusi. Itu mengserialisasi jumlah buruk yang sudah ditawarkan ke dalam data hook dan alamat instance yang ditentukan. Begitu penawaran buruk ada, mekanisme lainnya akan dengan setia meneruskannya.
Bahkan logika validasi pesanan CoW di sini tidak benar-benar melindungi pengguna, karena hanya memeriksa apakah pesanan melampaui harga pasar saat penawaran, tidak memeriksa apakah penawaran itu sendiri tidak masuk akal relatif terhadap likuiditas aktual.
Sumber: order_validation.rs:694
Ini adalah pemeriksaan konsistensi. Jika penawaran itu sendiri sudah omong kosong, pesanan masih bisa lolos.
Mekanisme Peringatan UI Depan Hanya Formalitas
Antarmuka Aave memang memiliki peringatan dampak harga tinggi, tetapi itu bukan saklar pemutus sirkuit yang keras. Ketika kerugian nilai melebihi 20%, itu berubah menjadi kotak centang konfirmasi.
Begitu pengguna mencentang kotaknya, hambatan dibersihkan:
Sumber: helpers.ts:24 dan HighPriceImpactWarning.tsx:35
Oleh karena itu, bahkan jika transaksi ini hampir mengosongkan seluruh nilai aset, sistem hanya menilainya sebagai operasi yang perlu dikonfirmasi pengguna, bukan transaksi berisiko tinggi yang harus ditolak keras oleh sistem, mekanisme peringatan sepenuhnya kehilangan fungsi pencegahan risiko.
Berdasarkan semua kegagalan mekanisme di atas, saya sama sekali tidak setuju dengan kesimpulan santai "ini hanya pengguna yang bodoh". Pengguna memang menyelesaikan penandatanganan, tetapi seluruh sistem perangkat lunak memiliki banyak kesempatan untuk mencegah bencana ini, namun setiap lapisan hanya melakukan pemeriksaan dasar, menilai "bukan nol, dapat dieksekusi, sudah ditandatangani" lalu langsung melepaskannya, akhirnya menyebabkan malapetaka.
Rute Tidak Dirusak
Tahap ini sangat penting, secara langsung mengesampingkan banyak tebakan salah: alur aave-v3-interface-collateral-swap yang sesuai dengan proses antarmuka resmi Aave, akan di file useSwapOrderAmounts.ts baris 139, menggabungkan penawaran, biaya jaringan, biaya mitra, biaya pinjaman kilat, menghitung jumlah beli yang disesuaikan slipage; baris 331 mengubahnya menjadi nilai buyAmountBigInt; kemudian di file CollateralSwapActionsViaCoWAdapters.tsx baris 191, menyelesaikan penandatanganan yang akurat untuk jumlah tersebut.
Kontrak adaptor berikutnya akan di file AaveV3BaseAdapter.sol baris 141, memverifikasi bahwa field pesanan tanda tangan cocok persis dengan nilai yang disimpan; kontrak penyelesaian CoW akan di file GPv2Settlement.sol baris 337, secara ketat menegakkan aturan batas yang disepakati tanda tangan. Oleh karena itu, hasil eksekusi on-chain tidak melampaui ruang lingkup yang diizinkan oleh pesanan tanda tangan, aset yang benar-benar diterima pengguna bahkan lebih tinggi dari batas minimum yang disepakati tanda tangan.
Ini cukup membuktikan: Bencana terjadi sebelum tahap penyelesaian, bukan selama proses penyelesaian, cacat fatal rute sudah menentukan akhirnya.
Ke Mana Nilai yang Hilang Pergi?
Transaksi berikutnya dalam blok yang sama (hash dimulai 0x45388b0f), menyelesaikan arbitrase balik terhadap pool SushiSwap AAVE/WETH yang rusak. Setelah transaksi abnormal membanjiri pool dengan WETH dalam jumlah besar dan menguras sebagian besar AAVE, arbitrase segera menjual kembali AAVE ke dalam pool, memanen nilai berlebih yang dihasilkan oleh ketidakseimbangan likuiditas.
Arbitrase balik ini mengekstrak total sekitar 17.929,770158685933 WETH, kemudian membayar sekitar 13.087,73 ETH ke pembangun blok, dan sekitar 4.824,31 ETH ke alamat eksekusi arbitrase.
Seluruh nilai ekonomi yang hilang oleh pengguna, akhirnya hampir instan diubah menjadi keuntungan arbitrase MEV dalam blok yang sama dan keuntungan pembangun blok.
Selain itu, memeriksa urutan waktu tingkat blok dapat dikonfirmasi: Sebelum transaksi, tidak ada yang sengaja memanipulasi pool perdagangan SushiSwap untuk menjebak pengguna, pasangan perdagangan AAVE/WETH ini pertama kali disentuh adalah transaksi abnormal ini (indeks transaksi 1); transaksi berikutnya (indeks transaksi 2), langsung menyelesaikan arbitrase balik pertama terhadap distorsi harga yang disebabkan oleh transaksi ini; indeks transaksi 3 juga menyentuh pasangan perdagangan ini selama proses perbaikan pasar. Garis waktu dengan jelas mengkonfirmasi: Transaksi abnormal ini menciptakan harga yang sangat terdistorsi, transaksi berikutnya langsung memanen keuntungan dari distorsi ini.
Lalu, Siapa yang Salah?
Jika Anda bertanya apakah protokol inti Aave V3 crash, jawabannya adalah tidak. Pool Aave mengeksekusi operasi sepenuhnya sesuai instruksi, normal menyelesaikan proses penebusan USDT dan penyimpanan AAVE.
Jika Anda bertanya apakah kontrak penyelesaian GPv2Settlement CoW crash, jawabannya adalah tidak. Penyelesaian menegakkan pesanan tanda tangan yang valid, dan membayar jumlah yang lebih tinggi dari batas minimum tanda tangan.
Jika Anda bertanya apakah kontrak pasangan perdagangan Uniswap V3 atau SushiSwap crash, jawabannya juga tidak. Kedua jenis pool perdagangan menetapkan harga sesuai aturan algoritma mereka sendiri.
Kegagalan sistemik yang sebenarnya, terjadi pada tingkat perutean dan kontrol risiko yang lebih tinggi:
Pihak yang bertanggung jawab utama adalah modul perutean, penawaran, dan solver protokol CoW: Seluruh sistem memiliki standar penilaian "rute wajar" yang terlalu lemah, mengizinkan pesanan besar jutaan dolar, akhirnya mengalir ke pool likuiditas rendah mini, asalkan rute dapat dieksekusi dan bukan nol akan diterima, sepenuhnya mengabaikan ketidakwajaran ekstrem secara ekonomi.
Pihak yang bertanggung jawab sekunder adalah antarmuka depan Aave: Saat meminta penawaran adaptor tidak menyertakan data aplikasi yang terkait hook, langsung memasukkan hasil yang salah ke dalam alur penandatanganan, dan hanya mengandalkan peringatan, tanpa mekanisme penolakan keras, untuk transaksi besar ekstrem seperti ini, tindakan kontrol risiko seperti ini sepenuhnya tidak cukup untuk mencegah risiko.
Ini adalah kegagalan ekstrem dalam kualitas rute transaksi dan pengaman kontrol risiko, yang langsung mengubah operasi perputaran kolateral yang sah dan sesuai aturan, menjadi peristiwa kerugian aset yang menghancurkan.
