Sumber artikel: Xianrang GodRealmX

Penulis: Shew, Xianrang GodRealmX

Hyperliquid yang baru-baru ini menjadi perhatian pasar adalah salah satu bursa buku pesanan terdesak yang paling berpengaruh, dengan TVL melebihi 2 miliar dolar, dinilai oleh Messari sebagai 'Binance di atas rantai', bahkan membawa kembali narasi Layer3 dan rantai aplikasi yang sudah memudar dari pandangan publik ke sorotan. Dengan peluncuran token dalam satu bulan mencapai FDV 30 miliar dolar, Hyperliquid mendapatkan perhatian luas dari pengguna biasa hingga profesional, sementara itu juga muncul banyak laporan penelitian tentang Hyperliquid di pasar, tetapi artikel-artikel ini sebagian besar berfokus pada fitur produk buku pesanan dan mekanisme transaksinya, tanpa menyelidiki lebih dalam struktur teknis dan potensi risikonya.

Penulis artikel ini bertujuan untuk mengisi kekosongan ini, murni dari sudut pandang konstruksi teknis dan keamanan untuk meneliti Hyperliquid, membantu lebih banyak orang memahami struktur dan prinsip proyek bintang ini. Kami akan menjelaskan dua sudut pandang, yaitu konstruksi dan risiko kontrak jembatan Hyperliquid, serta konstruksi double chain HyperEVM dan HyperL1, membantu semua orang memahami lebih dalam tentang arsitektur teknis dan cara implementasinya.

(Saat ini Hyperliquid menguasai 67% dari total pasokan USDC di Arbitrum)

Analisis Jembatan Lintas Rantai HyperLiquid

Karena HyperLiquid tidak memiliki komponen inti yang bersifat sumber terbuka, tetapi telah mengeluarkan kontrak jembatan terkait, kami memiliki pemahaman yang lebih baik tentang risiko di sisi kontrak jembatan. Hyperliquid telah menerapkan kontrak jembatan di Arbitrum untuk menyimpan aset USDC yang disetor pengguna, dan kami dapat melihat sebagian perilaku node Hyperliquid di dalam komponen Jembatan.

Kumpulan Validator

Dari sudut pandang pembagian identitas node, Hyperliquid memiliki 4 kelompok validator, yaitu hotValidatorSet, coldValidatorSet, serta finalizers dan lockers, yang masing-masing memiliki fungsi yang berbeda. Di mana hotValidatorSet digunakan untuk merespons operasi penarikan pengguna dan perilaku frekuensi tinggi lainnya, biasanya menggunakan dompet panas untuk merespons permintaan penarikan pengguna Hyperliquid kapan saja.

Sementara coldValidatorSet terutama digunakan untuk mengubah konfigurasi sistem, seperti mengubah daftar hotValidatorSet atau lockers, serta menangani status penguncian kontrak jembatan, coldValidatorSet berhak langsung membatalkan permintaan penarikan tertentu.

Sementara lockers adalah sekumpulan validator dengan izin khusus, mirip dengan 'komite keamanan' yang umum digunakan di Layer2, yang akan memutuskan dengan suara apakah jembatan lintas rantai harus dihentikan dalam situasi darurat. Saat ini, kumpulan lockers dari jembatan Hyperliquid mencakup 5 alamat, hanya memerlukan 2 locker untuk memberikan suara agar kontrak jembatan dihentikan.

Sebagai catatan, finalizers juga merupakan sekumpulan validator khusus, yang terutama digunakan untuk mengonfirmasi perubahan status jembatan lintas rantai, dari sisi kontrak, yang terutama dikonfirmasi adalah setoran dan penarikan pengguna. Jembatan lintas rantai Hyperliquid menggunakan mekanisme 'pengajuan-konfirmasi', misalnya, setelah pengguna mengajukan penarikan, transaksi tidak akan dieksekusi segera, tetapi perlu menunggu beberapa waktu (waktu ini disebut periode kontroversi). Setelah periode kontroversi berakhir, anggota dalam finalizers mengeksekusi transaksi penarikan, dan penarikan baru dapat dieksekusi secara normal.

Jika terjadi masalah dengan jembatan lintas rantai, misalnya, pernyataan penarikan tertentu ingin menarik lebih banyak aset daripada saldo yang sebenarnya dimiliki pengguna, node Hyperliquid dapat menggunakan locker untuk memberikan suara untuk menghentikan operasi kontrak jembatan selama periode kontroversi, atau coldValidatorSet dapat langsung membatalkan permintaan penarikan yang bermasalah.

Saat ini Hyperliquid hanya memiliki 4 node validator, jadi hotValidatorSet dan coldValidatorSet hanya sesuai dengan 4 alamat di rantai. Hyperliquid secara otomatis mendaftarkan alamat di dalam hotValidatorSet sebagai anggota lockers dan finalizers saat inisialisasi, sementara coldValidatorSet dikendalikan oleh pihak resmi Hyperliquid sendiri, menggunakan dompet dingin untuk menyimpan kunci.

Setoran

Kontrak jembatan Hyperliquid menggunakan metode Permit dari EIP-2612 untuk menangani operasi setoran pengguna, dan kontrak jembatan hanya mengizinkan pengguna untuk menyetor satu aset, yaitu USDC. Permit lebih ringkas dibandingkan dengan metode tradisional Approve-Transfer, dan lebih mudah untuk mendukung operasi massal.

Kontrak jembatan Hyperliquid menggunakan fungsi batchedDepositWithPermit untuk memproses beberapa setoran secara massal, tindakan setoran di sini cukup sederhana, tidak ada risiko keamanan dana, dan prosesnya sangat sederhana, hanya menggunakan metode Permit untuk mengoptimalkan UX.

Penarikan

Dibandingkan dengan setoran, penarikan adalah operasi yang sangat berbahaya, jadi logika penarikan jauh lebih kompleks dibandingkan setoran. Ketika pengguna mengajukan permintaan penarikan, node Hyperliquid akan memanggil fungsi batchedRequestWithdrawals dalam kontrak jembatan. Saat itu, kontrak jembatan akan mengharuskan setiap permintaan penarikan untuk mengumpulkan bobot tanda tangan 2/3 dari hotValidatorSet, perlu dicatat bahwa banyak dokumen di sini menggambarkan sebagai 'mengumpulkan 2/3 tanda tangan', tetapi sebenarnya kontrak jembatan memeriksa '2/3 bobot tanda tangan'. Saat ini, HyperLiquid hanya memiliki 4 node dengan bobot yang sama, jadi memeriksa bobot tanda tangan dan memeriksa jumlah tanda tangan saat ini konsisten, tetapi di masa depan, HyperLiquid mungkin akan memperkenalkan node dengan bobot tinggi.

Setelah mengajukan permintaan penarikan, jembatan lintas rantai tidak langsung mentransfer USDC yang dikelola kontrak, tetapi ada periode 'kontroversi', mirip dengan periode 'tantangan' dalam protokol bukti penipuan. Saat ini, periode kontroversi kontrak jembatan Hyperliquid adalah 200 detik, selama periode ini mungkin ada dua situasi:

1. Jika locker menganggap bahwa permintaan penarikan saat ini memiliki masalah serius, mereka dapat langsung memberikan suara untuk menghentikan/membekukan kontrak;

2. Node menganggap bahwa beberapa tindakan penarikan memiliki masalah, saat ini anggota coldValidatorSet dapat memanggil fungsi invalidateWithdrawals untuk membatalkan penarikan tersebut.

Jika tidak ada masalah yang muncul selama periode kontroversi, setelah periode kontroversi berakhir, anggota di dalam finalizers dapat memanggil fungsi batchedFinalizeWithdrawals dalam kontrak jembatan untuk menyelesaikan status akhir, hanya setelah fungsi ini dipicu, USDC akan ditransfer ke alamat dompet pengguna di Arbitrum.

Oleh karena itu, dari sudut pandang model keamanan, jika ada penyerang jahat yang ingin berbuat curang dalam proses penarikan Hyperliquid, mereka perlu melewati tiga lapisan pertahanan:

1. Memperoleh bobot tanda tangan 2/3 di dalam hotValidatorSet, dengan kata lain, perlu mendapatkan sejumlah kunci privat tertentu atau berkolusi; saat ini HyperLiquid hanya memiliki 4 validator, kemungkinan kontrol atau kolusi oleh penyerang tidak rendah;

2. Selama periode kontroversi, penyerang harus menghindari agar transaksi jahat mereka terdeteksi; jika terdeteksi, kemungkinan besar locker akan mengunci kontrak. Kami akan membahas bagian ini secara khusus di bawah.

3. Mendapatkan setidaknya satu kunci privat anggota finalizers, agar tindakan penarikan sendiri dapat dikonfirmasi secara final. Saat ini, anggota finalizers dan anggota hotValidatorSet hampir identik, jadi jika penyerang memenuhi syarat kondisi 1 di atas, maka secara otomatis memenuhi syarat kondisi 3.

Penguncian kontrak jembatan

Kami telah berulang kali menyebutkan bahwa Hyperliquid telah menyiapkan fungsi untuk mengunci kontrak jembatan lintas rantai. Secara khusus, untuk mengunci jembatan lintas rantai, anggota lockers perlu memanggil fungsi voteEmergencyLock dalam kontrak jembatan untuk memberikan suara, saat ini setelah 2 lockers memanggil fungsi tersebut dan memberikan suara, kontrak jembatan akan terkunci dan dihentikan.

Namun, perlu diperhatikan bahwa jembatan lintas rantai HyperLiquid juga menyediakan fungsi unvoteEmergencyLock, yang memungkinkan anggota lockers untuk menarik kembali suara. Setelah kontrak jembatan lintas rantai berhasil dikunci, hanya dapat dibuka kuncinya melalui fungsi yang disebut emergencyUnlock, yang memerlukan pengumpulan lebih dari 2/3 bobot tanda tangan anggota coldValidatorSet.

Fungsi emergencyUnlock akan memasukkan alamat baru untuk hotValidatorSet dan coldValidatorSet serta segera memperbarui.

Pembaruan Kumpulan Validator

Dibandingkan dengan berusaha keras untuk mencoba melanggar pertahanan yang ada dalam proses penarikan, cara serangan yang lebih baik adalah langsung menggunakan fungsi updateValidatorSet untuk memperbarui kumpulan validator hotValidatorSet dan coldValidatorSet. Ini mengharuskan pemanggil untuk memberikan tanda tangan dari semua anggota hotValidatorSet, dan operasi ini memiliki periode kontroversi 200 detik.

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

Sejauh ini, kami telah memperkenalkan sebagian besar detail tentang jembatan lintas rantai Hyperliquid. Artikel ini tidak membahas logika pembaruan locker dan finalizer, yang keduanya memerlukan tanda tangan hotValidatorSet, sedangkan penghapusan salah satu anggota memerlukan tanda tangan coldValidatorSet.

Ringkasnya, kontrak jembatan Hyperliquid mengandung risiko berikut:

1. Peretas yang mengendalikan coldValidatorSet dapat mengabaikan segala penghalang untuk mencuri aset pengguna. Karena coldValidatorSet memiliki hak akses ke fungsi emergencyUnlock, yang dapat membuat tindakan penguncian kontrak oleh lockers menjadi tidak valid, dan dapat segera memperbarui daftar node. Saat ini, Hyperliquid hanya memiliki 4 node validator, kemungkinan pencurian kunci privat cukup tinggi;

2. Finalizers menolak untuk melakukan konfirmasi akhir terhadap transaksi penarikan pengguna dan melakukan serangan pemeriksaan; dalam hal ini, aset pengguna tidak akan dicuri, tetapi mungkin tidak dapat ditarik dari kontrak jembatan;

3. Jika lockers berbuat curang pada jembatan lintas rantai, semua transaksi penarikan tidak dapat dieksekusi, hanya dapat menunggu coldValidatorSet untuk membuka kunci;

Arsitektur Interaksi HyperEVM dan Dual Chain

Untuk membuat perdagangan buku pesanan menjadi dapat diprogram, misalnya, memperkenalkan perdagangan privasi dan skenario lain yang perlu diimplementasikan dengan kontrak pintar, Hyperliquid meluncurkan solusi bernama HyperEVM. Dibandingkan dengan EVM tradisional, HyperEVM memiliki dua keuntungan khusus: pertama, HyperEVM dapat membaca status buku pesanan HyperLiquid, kedua, kontrak pintar di dalam HyperEVM dapat berinteraksi dengan sistem buku pesanan Hyperliquid, yang sangat memperluas skenario aplikasi Hyperliquid.

Sebagai contoh sederhana, jika pengguna perlu memastikan privasi dalam operasi pemesanan, mereka dapat menggunakan kontrak pintar serupa Tornado Cash di HyperEVM untuk menambahkan lapisan privasi, lalu memicu tindakan pemesanan di sistem buku pesanan HyperLiquid melalui antarmuka tertentu.

Sebelum memperkenalkan HyperEVM, kami perlu memperkenalkan arsitektur khusus yang disiapkan Hyperliquid untuk HyperEVM. Karena Hyperliquid memiliki sistem buku pesanan berkinerja tinggi yang disesuaikan, sementara kecepatan pemrosesan transaksi di lingkungan EVM jauh lebih lambat. Untuk menghindari penurunan kecepatan kerja sistem buku pesanan, Hyperliquid menggunakan 'solusi dual chain', yang pada dasarnya memungkinkan perangkat node Hyperliquid untuk menjalankan dua blockchain secara bersamaan di tingkat perangkat lunak, di mana setiap node menyimpan data dari kedua rantai secara lokal dan memproses transaksi dari kedua rantai secara terpisah.

Hyperliquid telah menyiapkan sebuah rantai khusus untuk sistem buku pesanan kustomnya, sementara juga menambahkan sebuah rantai yang kompatibel dengan EVM (HyperEVM). Data dari kedua rantai ini disebarkan di antara kelompok node melalui protokol konsensus yang sama, ada sebagai satu status yang terintegrasi, tetapi dijalankan dalam lingkungan eksekusi yang berbeda. Kami menyebut rantai khusus buku pesanan sebagai Hyperliquid L1 (L1), rantai ini bersifat terikat izin; sedangkan rantai yang digunakan untuk HyperEVM adalah HyperEVM (EVM), rantai ini tidak terikat izin, siapa pun dapat menerapkan kontrak, dan kontrak tersebut dapat mengakses informasi di L1 melalui kode pra-kompilasi.

Perlu diperhatikan bahwa kecepatan blok Hyperliquid L1 lebih cepat daripada rantai EVM, tetapi blok-blok ini tetap akan dieksekusi secara berurutan. Kontrak di rantai EVM dapat membaca data dari blok L1 sebelumnya dan menulis data ke blok L1 di masa depan. Seperti pada gambar di bawah:

Untuk mewujudkan interaksi antara HyperL1 dan HyperEVM, Hyperliquid memanfaatkan dua teknik, yaitu Precompiles dan Events.

Pra-kompilasi

Apa yang disebut pra-kompilasi (Precompiles), intinya adalah memindahkan beberapa operasi yang sulit diimplementasikan dalam kontrak pintar, yang memiliki kompleksitas tinggi, langsung ke lapisan bawah, memindahkan proses perhitungan yang tidak ramah terhadap Solidity dan merepotkan ke luar kontrak pintar konvensional untuk diolah, jenis kode pra-kompilasi ini dapat diimplementasikan menggunakan bahasa seperti C, C++ yang lebih dekat dengan perangkat keras.

Metode pra-kompilasi memungkinkan EVM mendukung fungsi yang lebih tinggi dan lebih kompleks, memudahkan untuk memenuhi kebutuhan pengembang kontrak pintar. Dalam bentuknya, pra-kompilasi pada dasarnya adalah sekumpulan kontrak pintar khusus, di mana kontrak pintar lain dapat langsung memanggil kontrak khusus ini, mengirimkan parameter dan mendapatkan hasil pengembalian dari eksekusi pra-kompilasi. Saat ini, EVM asli telah menggunakan metode pra-kompilasi untuk mengimplementasikan perintah ecRecover, yang dapat memeriksa keakuratan tanda tangan secp256k1 di dalam EVM, dan perintah tersebut terletak di alamat 0x01.

Menggunakan pra-kompilasi untuk menambah beberapa fitur khusus adalah praktik umum saat ini, misalnya Base telah menambahkan kode pra-kompilasi P256 untuk memudahkan pengguna melakukan operasi otentikasi identitas WebAuth.

(Gambar ini diambil dari situs Rollup Codes)

Sama seperti solusi utama saat ini, HyperEVM juga telah menambahkan serangkaian kode pra-kompilasi untuk memungkinkan EVM membaca status sistem buku pesanan Hyperliquid. Saat ini, salah satu alamat kode pra-kompilasi Hyperliquid yang diketahui adalah 0x0000000000000000000000000000000000000800, alamat pra-kompilasi ini dapat membaca situasi posisi kontrak berjangka pengguna di blok L1 terbaru.

Acara

Seperti yang telah disebutkan sebelumnya, HyperEVM dapat menulis data ke dalam blok HyperL1, dan perilaku penulisan bergantung pada Events yang diimplementasikan. Events adalah konsep asli dalam EVM, yang memungkinkan kontrak pintar mengirim informasi log ke eksternal (seperti aplikasi frontend atau pendengar) selama proses eksekusi, memudahkan pihak luar untuk memantau keadaan eksekusi kontrak pintar.

Misalnya, ketika pengguna menggunakan fungsi transfer token dari kontrak ERC-20, kontrak akan melemparkan Event yang sesuai dengan Transfer, agar pemindai blok dan aplikasi frontend lainnya dapat mengetahui status transfer token. Informasi Events ini akan disertakan dalam blok, dan ada banyak solusi matang untuk mendengarkan dan mengambil log Events.

Saat ini banyak skenario terkait lintas rantai yang menggunakan Events untuk menyampaikan parameter lintas rantai, misalnya, kontrak jembatan yang diterapkan di jaringan utama Ethereum oleh Arbitrum, pengguna dapat memanggil fungsi terkait untuk melemparkan acara yang memicu transaksi di Arbitrum.

Informasi yang diketahui menunjukkan bahwa node HyperLiquid akan mendengarkan

0x3333333333333333333333333333333333333333 (alamat acara) melemparkan Events, berdasarkan informasi yang terkandung dalam Events untuk mengetahui niat pengguna, dan mengubah niat tersebut menjadi tindakan transaksi, menulisnya ke dalam blok Hyperliquid L1 di masa depan.

Misalnya, alamat acara di atas akan menyediakan sebuah fungsi, ketika pengguna memanggil fungsi ini, alamat acara akan melemparkan sebuah Event bernama IocOrder. Ketika blok Hyper L1 dihasilkan, node HyperLiquid akan terlebih dahulu memeriksa acara yang dilemparkan oleh alamat acara di HyperEVM, dan ketika menemukan acara IocOrder baru, itu akan mengubahnya menjadi operasi pesanan di Hyper L1.

HyperBFT

Di tingkat protokol konsensus, Hyperliquid menggunakan protokol yang disebut HyperBFT, yang merupakan metode turunan dari HotStuff. Saat ini HutStuff-2 sudah menjadi salah satu protokol konsensus dengan kompleksitas terendah.

Menurut data yang ditunjukkan, pada awalnya HyperLiquid menggunakan algoritma konsensus Tendermint, yang merupakan algoritma konsensus default dalam sistem Cosmos, tetapi algoritma tersebut memiliki efisiensi yang rendah, setiap tahap memerlukan pertukaran pesan All-to-All, setiap node harus mengirim pesan ke semua node lainnya, dengan kompleksitas komunikasi O(n²), di mana n adalah jumlah node.

Jika menggunakan Tendermint, Hyperliquid dapat memproses hingga 20.000 pesanan per detik. Untuk mencapai kecepatan bursa terpusat, tim HyperLiquid mengembangkan algoritma HyperBFT berdasarkan HotStuff, dan diimplementasikan dalam Rust, secara teori dapat memproses hingga 2 juta pesanan per detik.

Gambar di bawah ini menunjukkan cara penyampaian pesan dalam konsensus HyperBFT dalam keadaan non-paralel, dapat dilihat bahwa semua pesan dirangkum oleh Leader dan disiarkan secara seragam, menghilangkan langkah-langkah pertukaran pesan antar node, secara signifikan mengurangi kompleksitas.

Sederhananya, HyperBFT adalah protokol konsensus di mana pemimpin saat ini melakukan pemblokiran, semua node berpartisipasi dalam pemungutan suara dan mengirimkan hasil pemungutan suara secara seragam kepada pemimpin, lalu memutar pemimpin berikutnya. Sebenarnya, detail spesifik yang terlibat dalam Hotstuff dan Tendermint jauh lebih kompleks, dan artikel ini dibatasi oleh panjang dan fokus yang tidak akan dibahas di sini.

Poin penting yang perlu diperhatikan oleh pengembang

Mekanisme pembacaan data berbasis Precompiles di atas cukup sempurna, pengembang Solidity tidak perlu menulis kode yang sesuai saat membaca status Hyper L1, tetapi perlu memperhatikan masalah msg.sender. Seperti banyak lapisan kedua Ethereum lainnya, HyperLiquid juga memungkinkan pengguna untuk berinteraksi langsung dengan kontrak sistem di Hyper L1, secara tidak langsung memicu tindakan transaksi di rantai HyperEVM; saat ini jika kontrak pintar membaca bidang msg.sender dalam transaksi tersebut, mereka akan menemukan bahwa msg.sender sesuai dengan alamat kontrak sistem HyperL1, bukan alamat pengguna yang awalnya memulai transaksi di HyperL1.

Bagi interaksi EVM dan L1, pengembang perlu memperhatikan serangkaian masalah. Masalah pertama adalah masalah non-atomisitas interaksi. Jika pengguna membuat pesanan secara tidak langsung di L1 melalui alamat acara yang disebutkan sebelumnya di HyperEVM, tetapi tidak ada aset yang cukup di L1, maka transaksi tersebut pasti akan gagal, tetapi tidak akan ada pesan kesalahan yang dikembalikan saat pengguna memanggil fungsi alamat acara. Masalah non-atomisitas interaksi dapat menyebabkan kerugian pada aset pengguna. Dalam hal ini, pengembang perlu menangani secara manual situasi kegagalan pesanan di sisi kontrak pintar EVM. Selain itu, kontrak pintar di dalam EVM harus memiliki fungsi untuk mengembalikan dana secara final, untuk menghindari aset pengguna tidak dapat ditarik dari L1 selamanya.

Selain itu, alamat kontrak yang sesuai dengan EVM di L1 harus memiliki akun pemetaan. Setelah pengguna menyelesaikan penerapan kontrak pintar di EVM, mereka perlu mentransfer sejumlah kecil USDC ke alamat pemetaan di L1, memaksa L1 untuk membuat akun untuk alamat kontrak. Bagian ini mungkin terkait dengan konsensus dasar HyperLiquid, dan ada persyaratan yang jelas dalam dokumentasi Hyperliquid.

Akhirnya, pengembang perlu memperhatikan beberapa situasi khusus, terutama terkait saldo token. Hyper L1 memiliki alamat khusus untuk perpindahan aset, tetapi ketika pengguna mengirim aset ke alamat khusus tersebut, aset akan berpindah dari L1 ke rantai HyperEVM. Karena node HyperLiquid sebenarnya menjalankan rantai EVM dan rantai L1 secara bersamaan, mungkin setelah pengguna memindahkan aset, HyperEVM tidak menghasilkan blok untuk waktu yang lama, saat itu pengguna di rantai EVM tidak dapat membaca saldonya.

Sederhananya, aset pengguna saat ini terjebak di jembatan lintas rantai, tidak dapat diperiksa baik di L1 maupun di rantai EVM, protokol yang dibangun oleh pengembang harus menangani situasi khusus di atas untuk menghindari pengguna merasa panik.

Secara ringkas, HyperEVM mirip dengan lapisan kedua yang berbasis Hyperliquid L1, HyperEVM bergantung pada kode pra-kompilasi untuk membaca status L1, juga bergantung pada Events untuk berinteraksi dengan Hyper L1. L1 juga memiliki beberapa sistem kontrak untuk membantu pengguna memicu transaksi dalam HyperEVM, atau melakukan lintas rantai aset. Namun, berbeda dengan arsitektur Layer1—Layer2 pada umumnya, Hyperliquid menyediakan interoperabilitas yang lebih tinggi untuk HyperEVM.

Referensi

Hyperliquid: Buku Pesanan Hyperoptimized L1

hyperliquid-dex/contracts

Panduan Tidak Sangat Definitif untuk Pra-kompilasi Hyperliquid.

Apa perbedaan antara PBFT, Tendermint, HotStuff, dan HotStuff-2?