Mengapa PerpDex "mati"? Lighter down selama 4 jam, ulasan lengkap

Pada 11 Oktober, pasar aset kripto mengalami peristiwa dilikuidasi terbesar dalam sejarah, dengan total jumlah likuidasi sekitar 19 miliar dolar. Dalam ujian pasar yang ekstrem ini, beberapa platform perdagangan futures desentralisasi (Perp Dex) mengalami gangguan, di mana Lighter mengalami masalah terparah, menyebabkan kerugian pada kolam dana penyedia likuiditas (LLP) yang memicu diskusi luas di pasar tentang platform PerpDex.

Sebagai perusahaan keamanan Web3 yang telah mengaudit banyak Perp Dex seperti Surf Protocol dan Tifo.trade, Beosin dalam artikel ini akan membantu semua orang untuk memahami lebih dalam tentang penyebab kejadian mati total Lighter melalui pengalaman akumulasi teknologi dan analisis data on-chain selama bertahun-tahun.

Kerangka Teknologi Lighter

Lighter menonjol dalam gelombang PerpDex dengan karakteristik nol biaya transaksi, menarik banyak pengguna untuk melakukan perdagangan di platformnya. Lighter dibangun di atas zkLight, L2 ZK Rollup tertentu, untuk meningkatkan kinerja transaksi dan efisiensi pencocokan buku pesanan. Mekanisme operasional inti-nya ditunjukkan pada gambar di bawah ini:

Sorter: Sebagai titik interaksi pengguna yang pertama, bertanggung jawab untuk menerima instruksi perdagangan, serta mengurutkan dan mengemas perdagangan menjadi Batch (paket data batch perdagangan).

Mesin pencocokan: Menerima Batch dari penyortir dan secara ketat mengikuti logika pencocokan “Prioritas harga, prioritas waktu”. Setiap pencocokan yang berhasil akan menyiapkan data untuk menghasilkan bukti tanpa pengetahuan, memastikan siapa pun dapat memverifikasi keadilan proses pencocokan setelahnya, menghindari kemungkinan manipulasi.

Penyedia Bukti (Prover): Menghasilkan operasi mesin pencocokan menjadi bukti ZK-SNARK yang ringkas, yang digunakan untuk memverifikasi kebenaran pelaksanaan pencocokan dan transisi status selanjutnya.

Kontrak mainnet: bertanggung jawab untuk memverifikasi bukti nol yang diajukan oleh penyedia bukti. Setelah verifikasi berhasil, akar status akan diperbarui, dan hasil transaksi akan mendapatkan konfirmasi final di Ethereum.

Selain desain di atas, Lighter menyediakan fungsi treasury bagi pengguna, di mana pengguna dapat menyimpan dana ke dalam Lighter Liquidity Pool (LLP). Kolam likuiditas ini menjalankan tiga fungsi: penyediaan likuiditas, pembentukan penawaran, dan pengambilan risiko. Peserta LLP dapat membagikan keuntungan platform dan pendapatan yang dihasilkan dari kerugian pihak lawan, sambil mengambil sebagian risiko saat pengguna dilikuidasi, berkolaborasi dengan sistem likuidasi Lighter untuk membentuk mekanisme penyangga risiko.

Lighter Pemulihan dari Downtime

Pada tanggal 11 Oktober 2025, ukuran likuidasi kontrak di pasar enkripsi mencetak rekor sejarah. Dalam kondisi pasar yang ekstrem ini, Lighter mengalami beberapa jam gangguan layanan yang menyebabkan pengguna tidak dapat mengelola posisi, kerugian LLP sekitar 5,35%.

Beosin melalui analisis data on-chain pada periode utama kejadian ini (waktu Beijing 11 Oktober 2025 00:17-05:08) menemukan bahwa Lighter telah kehilangan 3 Batch sejak Batch#55661, dan mulai memproduksi Batch kembali pada 00:17 (pada 00:23 Lighter mengumumkan bahwa pesanan pengguna tidak dapat diproses atau dijalankan).

Volume transaksi yang diproses secara normal oleh platform Lighter sebelum downtime adalah sekitar 4005 transaksi/menit, mulai pukul 00:17 volume transaksi meningkat pesat, Batch#55665 berisi 560 blok, jumlah transaksi yang diproses adalah 196913, rata-rata perlu memproses sekitar 65638 transaksi per menit, sekitar 16 kali lipat dari periode biasa.

Berikut adalah grafik statistik jumlah transaksi yang diproses pada setiap titik waktu pengajuan Batch dari 11 Oktober 00:17-05:08:

Dibuat oleh Beosin

Pada 11 Oktober pukul 04:56, Batch#55743 memproses jumlah transaksi mencapai batas maksimum, menyelesaikan 639370 transaksi dalam 2 menit, yang merupakan 79,8 kali jumlah transaksi yang diproses per menit pada waktu biasa. Dengan menganalisis data dari kejadian Lighter ini, kami menemukan bahwa Batch Lighter dapat menampung hingga 1600 blok, di mana setiap blok dapat menampung hingga 500 transaksi, sehingga jumlah transaksi teoritis yang dapat diproses adalah 800000/Batch, sedangkan pengukuran tertinggi yang teramati adalah 639370.

Di atas adalah transaksi yang berhasil diproses oleh platform Lighter, masih banyak pengguna yang tidak dapat menyesuaikan posisi mereka karena pengiriman transaksi gagal (dilikuidasi) dan tidak dapat tercatat di blockchain. Dari sudut pandang arsitektur teknis, ada 2 alasan utama untuk kegagalan ini dan kerugian LLP yang diakibatkan:

1. Selain masalah akses dan pengajuan pesanan di halaman depan, ZK Rollup Lighter bergantung pada penyortir tunggal untuk penyortiran dan pengemasan transaksi. Meskipun hasil verifikasi dicapai melalui ZK Proof, sentralisasi penyortir menyebabkan risiko kegagalan titik tunggal. Pada periode penurunan tajam, penyortir dan database tidak dapat menangani beban mendadak, yang mungkin mengakibatkan kerusakan indeks dan pemblokiran transaksi pada database, langsung menyebabkan gangguan koneksi antara mesin pencocokan dan pengguna. 2. Proses pembuatan dan pengajuan bukti ZK-SNARK menjadi kendala ketika volume transaksi melonjak. Dalam situasi ekstrem, pencocokan transaksi yang melonjak secara bersamaan dengan operasi likuidasi mengajukan permintaan ke node pembuatan bukti ZK. Platform mungkin tidak mengatur mekanisme cadangan sumber daya untuk operasi prioritas tinggi seperti likuidasi, sehingga terjadi persaingan sumber daya antara permintaan pembuatan bukti transaksi biasa dan likuidasi, yang semakin memperburuk keterlambatan respons sistem, sehingga proses likuidasi tidak dapat dilaksanakan tepat waktu, memperbesar kerugian pengguna. Di tingkat operasional, CEO Lighter Vladimir Novakovski menyatakan, “Lighter awalnya merencanakan peningkatan database pada akhir pekan saat penurunan ini terjadi untuk menyesuaikan dengan permintaan transaksi yang terus meningkat”. Dari kejadian ini, “kesalahan pemilihan jendela peningkatan” adalah akibat dari kurangnya persiapan tim terhadap risiko pasar, yang tidak dapat menyelesaikan peningkatan infrastruktur tepat waktu selama proses ekspansi cepat platform, akhirnya menyebabkan kegagalan sistemik platform dalam situasi ekstrem. Kejadian ini mengungkapkan tantangan inti yang dihadapi PerpDex: bagaimana menjaga operasi platform yang normal dalam situasi ekstrem. Dalam aspek keamanan kontrak pintar, tim proyek di jalur Perp Dex harus melakukan audit keamanan kontrak yang komprehensif dan profesional. Beosin sebelumnya telah menyediakan layanan audit keamanan untuk Surf Protocol, Tifo.trade, dan Perp Dex lainnya, mencakup keamanan kode kontrak pintar, kebenaran logika implementasi bisnis (perdagangan margin, likuidasi, manajemen kumpulan likuiditas, dll.), optimasi gas kode kontrak, serta penemuan dan perbaikan potensi kerentanan dari berbagai aspek, berhasil membantu tim proyek memperbaiki beberapa kerentanan dengan risiko menengah hingga tinggi.

Selain itu, tim proyek Perp Dex juga perlu mempertimbangkan redundansi arsitektur dan mekanisme darurat. Di masa depan, dengan penerapan teknologi seperti multi-sorter dan penjadwalan sumber daya dinamis, Perp Dex diharapkan dapat mengatasi kendala ini saat ini, melayani lebih banyak pengguna, dan menjadi infrastruktur dasar inti dalam keuangan enkripsi.