Menyelami Struktur Teknologi dan Risiko Keamanan Hyperliquid

Hyperliquid yang baru-baru ini menarik perhatian luas adalah salah satu bursa perdagangan buku pesanan on-chain yang paling berpengaruh, dengan total nilai terkunci telah melampaui 2 miliar dolar AS, dan dinilai oleh industri sebagai "versi on-chain dari bursa terpusat terkenal tertentu", sekaligus juga memicu diskusi baru tentang Layer3 dan rantai aplikasi. Dengan penampilan yang mencolok di mana valuasi proyek mencapai 30 miliar dolar AS dalam waktu satu bulan setelah peluncuran, Hyperliquid memperoleh perhatian yang luas. Saat ini, sudah ada banyak laporan analisis tentang Hyperliquid di pasar, tetapi sebagian besar berfokus pada fungsi produk dan mekanisme perdagangan, kurang mendalami analisis arsitektur teknologinya dan potensi risiko keamanan.

Artikel ini bertujuan untuk mengisi kekosongan ini, menganalisis Hyperliquid murni dari sudut pandang teknis dan keamanan, membantu pembaca memahami lebih baik tentang struktur dan prinsip internal proyek bintang ini. Kami akan fokus pada analisis desain dan risiko kontrak jembatan lintas rantai Hyperliquid, serta arsitektur dual-chain HyperEVM dan HyperL1, menyelami cara implementasi teknis di baliknya.

Analisis Jembatan Lintas Rantai Hyperliquid

Karena Hyperliquid tidak mengopen source komponen intinya, tetapi telah mengopen source kontrak jembatan yang relevan, kami memiliki pemahaman yang lebih baik tentang risiko terkait kontrak jembatan. Hyperliquid telah menerapkan kontrak jembatan di jaringan Layer2 tertentu, yang digunakan untuk menyimpan aset USDC yang disimpan oleh pengguna, kami dapat mengamati beberapa perilaku node Hyperliquid melalui komponen Bridge.

Kumpulan Validator

Dari perspektif pembagian identitas node, Hyperliquid memiliki 4 grup validator, yaitu hotValidatorSet, coldValidatorSet, serta finalizers dan lockers, yang masing-masing memiliki tanggung jawab yang berbeda. hotValidatorSet bertanggung jawab untuk merespons operasi frekuensi tinggi pengguna seperti penarikan, biasanya menggunakan dompet panas untuk memproses permintaan pengguna dengan cepat.

coldValidatorSet terutama digunakan untuk mengubah konfigurasi sistem, seperti memperbarui daftar koleksi validator lainnya, atau menangani status kunci kontrak jembatan, dan memiliki hak untuk langsung membatalkan beberapa permintaan penarikan.

lockers adalah sekumpulan validator dengan hak istimewa khusus, mirip dengan "komite keamanan" yang umum di Layer2, yang dapat memberikan suara untuk memutuskan apakah akan menghentikan operasi jembatan lintas rantai dalam situasi darurat. Saat ini, kumpulan lockers dari jembatan Hyperliquid mencakup 5 alamat, dan hanya perlu 2 locker untuk memberikan suara agar kontrak jembatan dihentikan.

finalizers juga merupakan sekelompok validator khusus, yang terutama digunakan untuk mengkonfirmasi perubahan status jembatan lintas rantai, seperti operasi setoran dan penarikan pengguna. Jembatan lintas rantai Hyperliquid mengadopsi mekanisme "pengajuan-konfirmasi", setelah pengguna mengajukan penarikan, mereka harus menunggu selama "periode sengketa", setelah periode berakhir, finalizers mengeksekusi transaksi penarikan.

Jika terjadi masalah, seperti permohonan penarikan yang melebihi saldo aktual pengguna, node Hyperliquid dapat memilih untuk menangguhkan kontrak jembatan melalui pemungutan suara di locker selama periode sengketa, atau oleh coldValidatorSet secara langsung membatalkan penarikan yang bermasalah.

Saat ini Hyperliquid hanya memiliki 4 node validator, sehingga hotValidatorSet dan coldValidatorSet masing-masing memiliki 4 alamat on-chain. Pada saat inisialisasi, Hyperliquid secara otomatis mendaftarkan alamat dalam hotValidatorSet sebagai anggota lockers dan finalizers, sementara coldValidatorSet dikendalikan oleh pihak resmi, menggunakan dompet dingin untuk menyimpan kunci.

Setoran

Kontrak jembatan Hyperliquid menggunakan metode Permit EIP-2612 untuk mengelola setoran pengguna, dan hanya mendukung satu aset yaitu USDC. Dibandingkan dengan mode Tradisional Approve-Transfer, Permit lebih ringkas dan memudahkan operasi massal.

Kontrak jembatan menggunakan fungsi batchedDepositWithPermit untuk memproses beberapa setoran secara batch, prosesnya sederhana dan tanpa risiko keamanan dana, terutama memanfaatkan metode Permit untuk mengoptimalkan pengalaman pengguna.

Penarikan

Dibandingkan dengan penyimpanan, penarikan adalah operasi berisiko tinggi, sehingga logikanya lebih kompleks. Setelah pengguna mengajukan permohonan penarikan, node Hyperliquid memanggil fungsi batchedRequestWithdrawals dari kontrak jembatan. Pada saat ini, setiap permohonan penarikan diharuskan untuk mendapatkan 2/3 bobot tanda tangan dari hotValidatorSet, perlu dicatat bahwa ini adalah "2/3 bobot tanda tangan" dan bukan "2/3 jumlah tanda tangan". Saat ini, Hyperliquid hanya memiliki 4 node dengan bobot yang sama, jadi pemeriksaan bobot tanda tangan dan jumlah tanda tangan sementara konsisten, tetapi di masa depan mungkin akan memperkenalkan node dengan bobot tinggi.

Setelah mengajukan permintaan penarikan, jembatan lintas rantai tidak akan segera mentransfer USDC, melainkan ada "periode sengketa" selama 200 detik. Selama periode ini, dua situasi mungkin terjadi:

1. lockers menganggap bahwa permintaan penarikan memiliki masalah serius, dapat langsung memberikan suara untuk membekukan kontrak;

2. Node menganggap bahwa beberapa penarikan bermasalah, anggota coldValidatorSet dapat memanggil fungsi invalidateWithdrawals untuk membuat penarikan tersebut tidak valid.

Jika tidak ada kejanggalan selama periode sengketa, setelah periode berakhir, anggota finalizers dapat memanggil fungsi batchedFinalizeWithdrawals untuk mengonfirmasi status akhir, pada saat itu USDC akan ditransfer ke alamat dompet pengguna di Layer2.

Dari sudut pandang model keamanan, jika penyerang jahat ingin berbuat jahat dalam proses penarikan Hyperliquid, mereka perlu melewati tiga garis pertahanan:

1. Kuasai 2/3 dari bobot tanda tangan hotValidatorSet, yaitu mendapatkan kunci privat yang cukup atau berkolusi. Saat ini hanya ada 4 validator, kemungkinan untuk dikendalikan atau berkolusi tidak rendah;

2. Hindari transaksi jahat yang terdeteksi selama periode sengketa, jika tidak, dapat memicu penguncian kontrak oleh lockers.

3. Dapatkan setidaknya satu kunci pribadi anggota finalizers, konfirmasi penarikan. Saat ini, anggota finalizers hampir sama dengan anggota hotValidatorSet, memenuhi syarat 1 sudah cukup untuk memenuhi syarat 3.

Penguncian Kontrak Jembatan

Hyperliquid menetapkan fungsi penguncian kontrak jembatan lintas rantai. Secara khusus, anggota lockers perlu memanggil fungsi voteEmergencyLock untuk memberikan suara, saat ini 2 anggota lockers dapat memberikan suara untuk mengunci dan menghentikan kontrak jembatan.

Perlu dicatat bahwa jembatan Hyperliquid juga menyediakan fungsi unvoteEmergencyLock, yang memungkinkan para pengunci untuk menarik suara. Setelah kontrak jembatan terkunci, hanya dapat dibuka kuncinya melalui fungsi emergencyUnlock, yang memerlukan pengumpulan lebih dari 2/3 bobot tanda tangan anggota coldValidatorSet.

emergencyUnlock akan memperbarui hotValidatorSet dan coldValidatorSet alamat validator secara bersamaan, dan akan segera berlaku.

Pembaruan kumpulan validator

Dibandingkan dengan melewati proses penarikan, menggunakan fungsi updateValidatorSet untuk memperbarui himpunan validator adalah metode serangan yang lebih efektif. Ini memerlukan tanda tangan dari semua anggota hotValidatorSet dan memiliki periode sengketa selama 200 detik.

Setelah periode sengketa berakhir, anggota finalizers perlu memanggil fungsi finalizeValidatorSetUpdate untuk menyelesaikan pembaruan akhir.

Ringkasan risiko yang ada pada kontrak jembatan Hyperliquid adalah:

1. Setelah hacker mengendalikan coldValidatorSet, mereka dapat mengabaikan hambatan untuk mencuri aset pengguna. Karena coldValidatorSet memiliki hak emergencyUnlock, hal ini dapat membuat lockers tidak terkunci dan segera memperbarui daftar node. Saat ini hanya ada 4 node validator, risiko pencurian kunci pribadi tidak rendah;

2. finalizers menolak untuk mengonfirmasi transaksi penarikan pengguna, melakukan serangan pemeriksaan. Pada saat ini, aset pengguna aman tetapi mungkin tidak dapat ditarik;

3. locker secara jahat mengunci jembatan lintas rantai, mencegah semua transaksi penarikan dieksekusi, hanya bisa menunggu coldValidatorSet untuk dibuka.

HyperEVM dan Arsitektur Interaksi Dua Rantai

Untuk mewujudkan perdagangan buku pesanan yang dapat diprogram, seperti memperkenalkan perdagangan privasi dan skenario lain yang memerlukan dukungan kontrak pintar, Hyperliquid meluncurkan solusi HyperEVM. Ini memiliki dua keunggulan dibandingkan EVM tradisional: dapat membaca status buku pesanan Hyperliquid, dan kontrak pintar internal dapat berinteraksi dengan sistem buku pesanan, secara signifikan memperluas skenario aplikasi.

Misalnya, jika pengguna perlu memastikan privasi order yang dihasilkan, mereka dapat menambahkan lapisan privasi melalui kontrak seperti Tornado Cash di HyperEVM, kemudian memicu order di sistem buku pesanan Hyperliquid melalui antarmuka tertentu.

Hyperliquid merancang arsitektur khusus untuk HyperEVM. Mengingat bahwa kinerja sistem order book kustom jauh lebih baik daripada lingkungan EVM, untuk menghindari penurunan kecepatan, Hyperliquid mengadopsi "skema dual-chain": setiap node menjalankan dua rantai secara bersamaan, menyimpan data kedua rantai secara lokal dan memproses transaksi secara terpisah.

Hyperliquid menetapkan rantai khusus untuk sistem buku pesanan ( HyperL1, berbasis izin ), sekaligus menambahkan rantai yang kompatibel dengan EVM ( HyperEVM, tanpa izin ). Data dari kedua rantai disebarkan melalui protokol konsensus yang sama, sebagai status yang terintegrasi, tetapi berjalan di lingkungan yang berbeda. Kecepatan pembuatan blok HyperL1 lebih cepat dibandingkan HyperEVM, tetapi blok tetap dieksekusi secara berurutan. Kontrak di rantai EVM dapat membaca data blok L1 sebelumnya dan menulis data ke blok L1 di masa depan.

Interaksi antara HyperL1 dan HyperEVM terutama dilakukan melalui Precompiles dan Events.

Precompiles

Prekompilasi(Precompiles) melakukan operasi kompleks langsung di lapisan dasar, menggunakan bahasa seperti C/C++ untuk menangani perhitungan yang tidak ramah terhadap Solidity. Prekompilasi pada dasarnya adalah kontrak pintar khusus yang dapat dipanggil oleh kontrak lain dan mendapatkan hasil eksekusi. Saat ini, EVM asli telah menggunakan prekompilasi untuk mengimplementasikan instruksi ecRecover(0x01 alamat).

HyperEVM juga menambahkan kode pra-kompilasi untuk membaca status sistem buku pesanan Hyperliquid. Alamat pra-kompilasi yang diketahui adalah 0x0000000000000000000000000000000000000800, yang dapat membaca posisi kontrak permanen pengguna dalam blok L1 terbaru.

Acara

HyperEVM menulis data ke HyperL1 bergantung pada Events. Events adalah konsep asli EVM yang memungkinkan kontrak mengirim informasi log ke luar. Misalnya, saat transfer ERC-20, event Transfer akan dipicu untuk memudahkan pemantauan. Banyak skenario lintas rantai juga menggunakan Events untuk menyampaikan parameter.

Node HyperLiquid mendengarkan Events yang dilemparkan dari alamat 0x3333333333333333333333333333333333333333, berdasarkan informasi untuk mengetahui niat pengguna dan mengubahnya menjadi tindakan transaksi, ditulis ke dalam blok L1 di masa depan. Jika alamat tersebut menyediakan fungsi, saat dipanggil, akan melemparkan event IocOrder, ketika blok L1 dihasilkan, node akan menemukan event IocOrder baru dan mengubahnya menjadi operasi order tertunda di L1.

HyperBFT

Dalam hal protokol konsensus, Hyperliquid menggunakan protokol HyperBFT yang diturunkan dari HotStuff. Pada awalnya menggunakan algoritma Tendermint, tetapi kurang efisien, karena setiap tahap memerlukan pertukaran pesan All-to-All, dengan kompleksitas O(n²).

Untuk mencapai kecepatan bursa terpusat, tim mengembangkan HyperBFT dan mengimplementasikannya dengan Rust, yang secara teoritis dapat memproses 2 juta pesanan per detik. Semua pesan dalam HyperBFT dirangkum dan disiarkan oleh Leader, menghilangkan pertukaran pesan antar node, secara signifikan mengurangi kompleksitas.

Secara singkat, HyperBFT adalah protokol konsensus di mana pemimpin saat ini menghasilkan blok, semua node memberikan suara dan mengirimkan hasilnya secara bersamaan kepada pemimpin, lalu mengalihkan ke pemimpin berikutnya.

Catatan untuk Pengembang

1. Mekanisme pembacaan data berbasis Precompiles cukup baik, tetapi perlu diperhatikan masalah msg.sender. Ketika pengguna berinteraksi dengan kontrak sistem L1 yang secara tidak langsung memicu transaksi EVM, msg.sender di dalam EVM adalah alamat kontrak sistem L1, bukan alamat pengguna.

2. Masalah non-atomisitas dalam interaksi EVM dan L1. Misalnya, jika pengguna membuat pesanan di L1 melalui EVM tetapi aset tidak mencukupi, transaksi gagal tetapi tidak ada pesan kesalahan saat memanggil fungsi. Pengembang perlu menangani situasi kegagalan pesanan di sisi kontrak EVM dan menetapkan fungsi pengembalian dana.

3. Alamat kontrak EVM di L1 harus memiliki akun pemetaan. Setelah meng-deploy kontrak EVM, perlu mengirim sejumlah kecil USDC ke alamat pemetaan L1 untuk membuat akun.

4. Perhatikan situasi khusus seperti saldo token. L1 memiliki alamat khusus untuk lintas rantai aset, tetapi setelah lintas rantai EVM mungkin tidak segera memproduksi blok, pengguna sementara tidak dapat membaca saldo. Pengembang harus menangani situasi ini untuk menghindari kepanikan pengguna.