Kebenaran mengejutkan di balik bot kripto yang memprioritaskan pencuri untuk "menyelamatkan" dana — tetapi mereka yang memutuskan siapa yang akan dibayar kembali

Sumber: CryptoNewsNet Judul Asli: Kebenaran Meledak di balik bot crypto yang front-run pencuri untuk “menyelamatkan” dana — tetapi mereka memutuskan siapa yang akan dibayar kembali Tautan Asli:

Insiden Makina Finance

Makina Finance kehilangan 1.299 ETH, sekitar $4,13 juta, dalam eksploit manipulasi pinjaman kilat dan oracle.

Penyerang menguras dana protokol dan menyiarkan transaksi ke mempool publik Ethereum, di mana seharusnya validator akan menangkapnya dan memasukkannya ke dalam blok berikutnya.

Sebaliknya, seorang pembangun MEV yang diidentifikasi dengan alamat 0xa6c2 melakukan front-run terhadap transaksi pengurasan tersebut, mengalihkan sebagian besar dana ke kustodi yang dikendalikan pembangun sebelum hacker dapat memindahkannya secara off-chain.

Transaksi hacker gagal. Dana tersebut mendarat di dua alamat yang terkait dengan pembangun MEV.

Pesan utama yang langsung terlihat adalah bahwa pengguna Makina menghindari kerugian total. Sinyal yang lebih dalam adalah siapa yang akhirnya memegang uang tersebut dan apa artinya bagi arsitektur respons darurat crypto yang sedang berkembang.

Aktor terpenting dalam cerita ini bukanlah penyerang atau protokol, tetapi rantai pasokan pembangunan blok yang menyela eksploit dan sekarang mengendalikan apakah pengguna mendapatkan dana mereka kembali, dengan syarat apa, dan seberapa cepat.

Bot dan pembangun MEV menjadi garis pertahanan terakhir crypto, bukan karena dirancang tetapi karena posisi strukturalnya. Itu adalah masalah, karena kapasitas penyelamatan terkonsentrasi di tangan perantara yang memaksimalkan keuntungan dengan akuntabilitas yang tidak jelas.

MEV sebagai cadangan sudah menjadi pola

Insiden Makina bukanlah kejadian tunggal. Chainalysis mendokumentasikan dinamika serupa selama eksploit Curve dan Vyper 2023, mencatat bahwa hacker topi putih dan operator bot MEV membantu memulihkan dana, yang mengurangi kerugian yang direalisasikan di bawah perkiraan awal.

Polanya mekanis: selama eksploit atau upaya penyelamatan terlihat di saluran transaksi publik, pencari dan pembangun yang canggih dapat bersaing untuk mengatur ulang transaksi.

Kadang mereka menyelamatkan dana. Kadang mereka menangkapnya. Bagaimanapun, mereka bertindak sebagai lapisan respons darurat de facto.

Ketika transaksi eksploit masuk ke mempool publik, pencari MEV memantau peluang yang menguntungkan. Jika hacker menguras protokol dan menyiarkan transaksi secara publik, pencari dapat membangun transaksi bersaing yang dieksekusi terlebih dahulu, mengalihkan dana ke alamat berbeda.

Pencari menggabungkan transaksi tersebut dan mengirimkannya ke pembangun blok, yang memasukkannya jika keuntungan melebihi tawaran bersaing. Jika blok pembangun dipilih oleh validator, transaksi pencari dieksekusi, dan transaksi hacker gagal.

Ini adalah ekstraksi keuntungan dengan efek samping yang menguntungkan daripada murni altruistik. Tetapi ini juga mekanisme paling andal yang dikembangkan crypto untuk menyela eksploit secara waktu nyata, karena beroperasi di lapisan pengurutan transaksi daripada mengandalkan circuit breaker protokol atau intervensi tata kelola.

Mengapa ketergantungan pada pembangun MEV tidak nyaman

Masalah dengan penyelamatan berbasis MEV adalah bahwa mereka mengkonsentrasikan kapasitas respons darurat dalam jalur yang sangat terintermediasi.

Di Ethereum, MEV-Boost mendominasi produksi blok. Lanskap relay Rated menunjukkan sekitar 93,5% blok terbaru dialihkan melalui MEV-Boost, dibandingkan sekitar 6% menggunakan produksi blok vanilla.

Dalam MEV-Boost, pangsa pasar Relay lebih terkonsentrasi: Ultra Sound Money menyumbang sekitar 29,84% lalu lintas relay, dan Titan sekitar 24,24%, yang berarti dua relay terbesar bersama-sama menangani lebih dari 54% produksi blok.

Jika sebagian besar blok mengalir melalui MEV-Boost dan sebagian besar lalu lintas MEV-Boost melalui dua relay, lapisan penyelamatan secara struktural bergantung pada sejumlah kecil perantara. Itu dengan cepat menciptakan masalah tata kelola.

Jika seorang pembangun akhirnya memegang dana yang diselamatkan, siapa yang mengotorisasi kustodi? Siapa yang menentukan bounty? Apa yang mencegah pemerasan atau tuntutan tebusan? Bagaimana jika pembangun berada di luar negeri, anonim, atau beroperasi di yurisdiksi dengan penegakan hukum yang lemah?

Kasus Makina menggambarkan masalah ini. Dana berada di kustodi pembangun, tetapi tidak ada SLA publik, bounty yang telah ditentukan sebelumnya, atau mekanisme yang jelas untuk mengembalikan dana ke Makina atau penggunanya.

Pembangun bisa mengembalikan dana secara sukarela, bernegosiasi bounty, menuntut biaya lebih tinggi dari norma industri, atau menolak mengembalikan dana sama sekali.

Routing pribadi memperburuk masalah

Makalah akademik tahun 2025 berjudul “Sandwiched and Silent” mendokumentasikan routing transaksi pribadi yang luas dan menemukan bahwa banyak korban bermigrasi ke saluran pribadi setelah disandwiched oleh bot MEV.

Namun, routing pribadi tidak menghilangkan MEV, melainkan memindahkannya dari mempool publik ke saluran urutan pribadi yang dikendalikan oleh pembangun dan relay.

Bagi protokol, itu berarti penyelamatan di mempool publik menjadi kurang andal karena transaksi eksploit semakin banyak dialihkan melalui saluran pribadi yang hanya dapat diakses oleh sebagian pembangun.

Upaya untuk menertibkan kekacauan

Safe Harbor adalah kerangka kerja yang dikembangkan oleh SEAL yang bertujuan menggantikan model “pembangun MEV sebagai kustodian tidak sengaja” dengan responden yang diberi wewenang, SLA yang eksplisit, dan insentif terbatas.

SEAL menggambarkan Safe Harbor sebagai kerangka hukum dan teknis yang memungkinkan protokol memberi wewenang sebelumnya kepada topi putih untuk campur tangan selama eksploit aktif.

Aturan operasional inti adalah dana yang diselamatkan harus dikirim ke alamat pemulihan resmi dalam waktu 72 jam, dengan bounty yang telah ditentukan sebelumnya dan dapat ditegakkan.

SEAL mengatakan Safe Harbor terinspirasi oleh peretasan Nomad, di mana topi putih bersedia membantu tetapi dibatasi oleh ketidakjelasan hukum tentang apakah pengembalian dana dapat dituntut sebagai akses komputer yang tidak sah.

Safe Harbor menghilangkan ketidakjelasan itu dengan memberi protokol cara untuk memberi wewenang sebelumnya untuk intervensi dan menetapkan syarat yang jelas. SEAL mengklaim Safe Harbor sudah melindungi lebih dari $16 miliar di berbagai protokol utama, termasuk DEX tertentu, Pendle, solusi layer-2 tertentu, dan zkSync.

Immunefi, platform bug bounty, telah mengoperasionalkan Safe Harbor dengan syarat yang lebih ketat.

Immunefi menggambarkan Safe Harbor sebagai kerangka kerja yang dikembangkan oleh SEAL yang mengarahkan dana ke vault yang dikendalikan protokol di platform Immunefi. Pada halaman program Safe Harbor Immunefi, tertulis: “Anda memiliki 6 jam untuk mentransfer dana kembali.”

Kegagalan memenuhi jendela enam jam merupakan pelanggaran material. Itu empat kali lebih cepat dari persyaratan dasar SEAL selama 72 jam.

Safe Harbor tidak menghilangkan ketergantungan pada infrastruktur MEV. Sebaliknya, ini berusaha memformalkan saja.

Jika seorang pembangun melakukan front-run terhadap eksploit dan protokol telah mengadopsi Safe Harbor, pembangun diharapkan mengenali intervensi sebagai yang diberi wewenang dan mengarahkan dana ke alamat pemulihan yang ditunjuk protokol dalam SLA.

Tapi itu mengasumsikan pembangun memantau registri Safe Harbor, menghormati syarat, dan memprioritaskan kepatuhan daripada keuntungan.

Rentang skenario

Tingkat pemulihan pengguna yang diharapkan dalam sebuah eksploit dapat dimodelkan sebagai: perkiraan pemulihan sama dengan probabilitas intervensi, dikalikan satu dikurangi persentase bounty, dikalikan satu dikurangi persentase kegagalan atau kebocoran.

Safe Harbor bertujuan meningkatkan kemungkinan intervensi dengan mengurangi ketidakjelasan hukum dan membatasi persentase bounty di muka.

Dalam kasus dasar, adopsi Safe Harbor meningkat selama 12 bulan ke depan. Lebih banyak protokol menambahkan syarat Safe Harbor ke kerangka tata kelola mereka, dan lebih banyak topi putih mendaftar sebagai responden yang diberi wewenang.

Probabilitas intervensi meningkat karena responden memiliki kejelasan hukum dan syarat bounty tetap. Tingkat pemulihan membaik, terutama untuk protokol yang mengadopsi SLA yang lebih ketat, seperti jendela enam jam Immunefi.

Dalam kasus optimis, lapisan penyelamatan menjadi profesional. Protokol membangun alamat vault yang ketat, memperkecil SLA ke jam satu digit, dan bernegosiasi sebelumnya jadwal bounty dengan tim topi putih yang dikenal.

Pembangun mengintegrasikan registri Safe Harbor ke dalam algoritma pengurutan transaksi mereka, secara otomatis mengarahkan dana yang diselamatkan ke alamat yang ditunjuk tanpa intervensi manual.

Dalam kasus pesimis, ketergantungan pembangun semakin keras. Saluran urutan pribadi dan konsentrasi relay membuat penyelamatan menjadi kurang transparan dan lebih oligopolistik. Protokol yang belum mengadopsi Safe Harbor akhirnya bernegosiasi dengan pembangun setelah kejadian, tanpa kekuatan tawar atau SLA yang jelas.

Tata kelola menjadi bergantung pada perantara yang memegang dana dan menetapkan syarat secara sepihak.