🚀 Pendahuluan: para pro SOLANA mengadakan pertemuan
Baru-baru ini, terjadi sesuatu yang sangat menarik di ekosistem Solana. Termasuk Solana Foundation, Anza, Jito Labs, dan sejumlah pro berkumpul bersama untuk merilis sebuah peta jalan teknologi yang bernama “Internet Capital Markets (Internet Capital Markets, ICM )”. Ide inti dari peta jalan ini adalah “Application Controlled Execution (Application Controlled Execution, ACE )”, secara sederhana, ini berarti memberikan aplikasi di chain hak penyortiran transaksi secara mandiri dalam milidetik, menciptakan sebuah “Wall Street di chain” yang terdesentralisasi.
Namun yang menarik adalah, setelah membaca seluruh peta jalan, meskipun tidak menyebutkan Hyperliquid secara langsung, desain di dalamnya hampir di setiap tempat ditujukan untuk kekuatan Hyperliquid. Ini seperti Solana yang mengatakan: “Kami juga ingin memiliki apa yang kamu miliki di Hyperliquid, dan kami ingin melakukannya dengan lebih baik!”
Perlu diketahui bahwa Hyperliquid mendominasi pasar kontrak berjangka permanen di blockchain, dengan volume perdagangan yang pernah mencapai sekitar 65% dari seluruh pasar berjangka terdesentralisasi. Jelas, menghadapi pesaing seperti itu, Solana tentu tidak mau tertinggal oleh pendatang baru, sehingga meluncurkan peta jalan ICM ini.
Jadi, apa sebenarnya “pertunjukan tiruan” ini? Apakah Solana benar-benar bisa mengejar atau bahkan melampaui Hyperliquid? Hari ini kita akan membahas topik ini lebih dalam.
📋 Latar Belakang dan Konten ICM
Siapa yang memimpin perubahan ini?
Pertama, mari kita lihat siapa yang menyusun peta jalan ini. Yang terlibat adalah pemain-pemain besar dalam ekosistem Solana:
Solana Foundation/Labs: Ini tidak perlu dijelaskan lagi, “ayah kandung” Solana, bertanggung jawab untuk koordinasi keseluruhan dan pengembangan protokol inti.
Anza: sebuah perusahaan pengembang yang didirikan oleh mantan anggota Solana Labs, mirip dengan ConsenSys dari Ethereum. Mereka mengambil banyak pekerjaan inti dalam roadmap ini, seperti protokol konsensus baru Alpenglow.
Jito Labs: Penyedia infrastruktur MEV di Solana yang sangat berpengaruh, hampir mengendalikan “hak hidup dan mati” semua aliran MEV di Solana. Kali ini mereka memimpin penyediaan solusi pengurutan transaksi seperti Block Assembly Marketplace (BAM).
Multicoin Capital: lembaga investasi kripto terkenal dan juga pendukung awal Solana. Karena memiliki banyak SOL dan kepentingan dalam proyek ekosistem, mereka memiliki pengaruh yang cukup besar dalam arah teknologi.
DoubleZero: Tim yang fokus pada percepatan komunikasi jaringan, menyediakan solusi jaringan serat optik khusus untuk meningkatkan kecepatan komunikasi antara node validasi Solana.
Drift: Proyek DEX kontrak berjangka terkemuka di Solana. Sebelumnya, Drift menggunakan mode pencocokan off-chain, yang terasa cukup sulit dalam menghadapi Hyperliquid yang sepenuhnya on-chain. Kali ini terlibat dalam perumusan peta jalan, jelas berharap bisa bangkit dengan bantuan upgrade dasar.
Masalah inti yang harus diselesaikan
Peta jalan berfokus pada perbaikan struktur mikro pasar, yang secara sederhana adalah mekanisme perdagangan on-chain saat ini tidak cukup ramah bagi pembuat pasar. Artinya, Taker yang secara aktif memulai perdagangan mendapatkan keuntungan, sementara Market Maker yang menunggu untuk menyelesaikan pesanan menderita kerugian. Ini karena Taker sering kali menguasai informasi terbaru dan secara aktif meningkatkan biaya transaksi untuk memastikan bahwa perdagangan mereka dieksekusi terlebih dahulu, sementara Maker sering kali tidak punya waktu untuk membatalkan pesanan dan terpaksa menyelesaikan transaksi pada harga yang merugikan.
Beberapa arbitrase frekuensi tinggi akan memanfaatkan asimetri ini untuk melakukan serangan “traffic beracun”. Misalnya, ketika harga di blockchain belum diperbarui, tetapi harga di luar blockchain sudah berubah, para arbitrase dapat mengambil pesanan dari pembuat pasar dengan harga lama, menyebabkan pembuat pasar menanggung kerugian. Akibatnya, Maker untuk melindungi diri, harus memperlebar selisih harga beli dan jual, atau mengurangi jumlah pesanan yang dipasang, yang mengakibatkan likuiditas pasar secara keseluruhan menjadi lebih buruk.
Peta jalan ICM adalah untuk menyeimbangkan pola ini, menarik likuiditas berkualitas tinggi kembali ke rantai.
Tiga langkah ICM
Solana membagi rencana besar ini menjadi tiga tahap:
Jangka Pendek (1-3 Bulan): Utamanya adalah mengoptimalkan pengalaman transaksi on-chain yang ada, membuat aplikasi jenis buku pesanan lebih mudah digunakan, dan mengurangi gangguan MEV yang merugikan. Secara spesifik mencakup:
Modul Block Assembly Marketplace (BAM) dari Jito Labs telah diluncurkan di jaringan utama. Modul ini bertujuan untuk menyediakan sistem tambahan sementara sebelum peluncuran ACE (Application Controlled Execution) yang memungkinkan kontrak pintar di Solana memiliki hak pengurutan transaksi yang mandiri.
Tim Anza mengoptimalkan “masuk ke Slot yang sama” untuk meningkatkan tingkat keberhasilan, sehingga mengurangi slippage dan kerugian MEV.
Perbaikan ini diharapkan akan dilaksanakan secara bertahap pada bulan Juli hingga September 2025.
Jangka Menengah (3-9 Bulan): Memperkenalkan jaringan cepat yang khusus dan konsensus versi baru, secara signifikan mengurangi latensi dan meningkatkan throughput:
Menerapkan jaringan serat optik khusus DoubleZero, menyediakan komunikasi berkecepatan tinggi dengan hampir tidak ada jitter, dan mengurangi latensi hingga 100ms.
Meluncurkan protokol konsensus Alpenglow, mengurangi waktu konfirmasi akhir dari sekitar 12,8 detik menjadi sekitar 0,15 detik.
Mengembangkan Eksekusi Program Asynchronous ( Asynchronous Program Execution, APE ), mengurangi pemblokiran eksekusi transaksi terhadap konsensus.
Jangka Panjang (9-30 bulan): Melakukan peningkatan revolusioner pada arsitektur inti Solana, dengan target untuk mencapainya sekitar tahun 2027:
Pemimpin Konkurensi Ganda (Multiple Concurrent Leaders, MCL): Memungkinkan beberapa validator untuk mengusulkan transaksi secara bersamaan di pipeline masing-masing, kemudian mengurutkan blok paralel ini berdasarkan biaya prioritas. Dengan cara ini, monopoli dari satu pengemas dapat dilemahkan, meningkatkan ketahanan terhadap sensor.
Aplikasi asli dapat mengendalikan eksekusi (Application Controlled Execution, fungsi ACE): memberikan kekuasaan nyata kepada kontrak pintar di blockchain untuk mengontrol urutan eksekusi transaksi.
Analisis sampai di sini, penulis berpendapat bahwa pengajuan peta jalan ICM kali ini, cerita di baliknya seharusnya seperti ini: DEX lama di Solana, Drift, dikalahkan oleh pendatang baru Hyperliquid dengan pengalaman “Binance on-chain” yang unggul. Drift sendiri tidak mampu bersaing, jadi terpaksa meminta bantuan dari Solana Labs, Anza, Jito, dan “pro” lainnya. “Pro” tersebut mengajukan rencana perombakan teknis ICM, mengklaim akan mereplikasi semua keahlian utama Hyperliquid untuk Drift, membantu mereka kembali bersaing di pasar DEX. Namun, “pro” tersebut juga mengatakan bahwa perombakan teknis kali ini sangat sulit, sehingga rencana teknis dibagi menjadi strategi tiga langkah, dan perlengkapan yang dapat diberikan kepada Drift dalam waktu dekat hanya BAM dari Jito, agar Drift dapat bertahan dan berkompetisi dengan Hyperliquid.
Setelah menjelaskan latar cerita, penulis akan menganalisis secara rinci keahlian apa saja yang ditiru dan direplikasi oleh ICM dari Hyperliquid di bab-bab berikutnya.
🎭 Imitasi Satu: Mekanisme Pengurutan Transaksi
Masalahnya: Seperti yang disebutkan sebelumnya, rantai saat ini lebih menguntungkan taker, maker menanggung “aliran beracun”. Pengguna yang secara aktif mengambil order dapat berdasarkan harga terbaru di luar rantai, segera memulai transaksi terhadap order yang dipasang di dalam rantai, dan dengan meningkatkan biaya transaksi agar dapat diproses lebih cepat. Sementara itu, pembuat pasar sering kali tidak memiliki waktu untuk memperbarui atau membatalkan order. Hasilnya adalah, pembuat pasar harus memperlebar spread atau bahkan menarik likuiditas, membuat kedalaman pasar menjadi lebih buruk.
Solusi akhir ICM: Aplikasi eksekusi terkendali (ACE)
Peta jalan ICM mengusulkan konsep ACE (Application Controlled Execution), yaitu mendelegasikan hak pengurutan transaksi kepada aplikasi yang ada di setiap rantai, di mana aplikasi sendiri memutuskan bagaimana urutan eksekusi transaksi yang terkait dengan aplikasi tersebut. Sebagai contoh, di Solana yang akan menerapkan ACE di masa depan, kontrak DeFi dapat menerapkan aturan pengurutan transaksi yang dikustomisasi sebagai berikut:
Pembaruan Harga Oracle: Aplikasi DeFi dapat terlebih dahulu menyisipkan sebuah transaksi untuk mendapatkan harga terbaru dari oracle sebelum melakukan pencocokan transaksi besar, memastikan bahwa pesanan dicocokkan dengan harga wajar terbaru, dan mencegah penawaran pembuat pasar berdasarkan harga yang sudah usang untuk dieksploitasi.
Prioritas Pembatalan Pesanan: Aplikasi dapat mengatur agar “permintaan pembatalan” memiliki prioritas lebih tinggi daripada “transaksi pemesanan baru” untuk dieksekusi, memberi kesempatan bagi maker untuk menarik kembali pesanan saat kondisi pasar tidak menguntungkan.
Lelang di Belakang Tim: Misalnya, setelah munculnya satu pesanan beli besar yang mendorong harga naik, aplikasi DeFi akan mengadakan lelang untuk kesempatan “yang mengikuti”; siapa pun yang bersedia mengembalikan paling banyak keuntungan kepada protokol (atau pengguna), protokol DeFi akan membiarkan transaksi mereka dieksekusi tepat setelah pesanan besar. Aplikasi DeFi dapat mengembalikan pendapatan lelang kepada pengguna, sehingga mengubah aliran MEV yang beracun menjadi pendapatan yang baik.
BAM JITO: Rencana Transisi
Sebelum ACE resmi diluncurkan, Jito Labs meluncurkan solusi transisi yang disebut Block Assembly Marketplace (BAM). Alur kerja BAM adalah:
Pengguna mengirimkan transaksi ke node yang menjalankan perangkat lunak BAM (bukan langsung ke Leader saat ini).
Node BAM mengumpulkan transaksi lokal dan menjalankan berbagai plugin (plugin) untuk melakukan pengurutan ulang pada paket transaksi (Bundle) di bawah perlindungan privasi (plugin dijalankan di lingkungan TEE yang aman, menyembunyikan isi transaksi sebelum eksekusi). Melalui plugin, pengembang aplikasi dapat menyesuaikan berbagai aturan pengurutan untuk kontrak mereka, seperti prioritas pembatalan, memperbarui harga oracle sebelum pencocokan, bahkan menjalankan lelang dalam aplikasi yang kompleks.
Bundle transaksi yang sudah diurutkan kemudian dikirim ke Pemimpin Solana untuk dikemas dan dimasukkan ke dalam rantai.
BAM dapat dianggap sebagai ladang percobaan sebelum ACE di blockchain, fungsinya sangat dekat dengan ACE yang terakhir, hanya saja ia berjalan di jaringan independen di luar, bukan di dalam protokol utama Solana.
Perlu dicatat bahwa Jito sebelumnya menyediakan infrastruktur yang ditujukan untuk ekstraksi MEV (seperti Jito Block Engine), di mana model bisnisnya adalah dengan mengoptimalkan urutan transaksi untuk menciptakan peluang bagi para arbiter dan membagikan keuntungan. Ini dalam beberapa hal berdiri di sisi berlawanan dari pengguna biasa dan mereka yang dieksploitasi, sebagai “mata panah”. Namun, Jito pada awal 2024 menutup fungsi mempool publik (mempool) yang ditujukan untuk robot arbitrase, untuk mengurangi eksternalitas negatif seperti serangan sandwich. Langkah ini menunjukkan bahwa komunitas Solana cenderung untuk menekan MEV yang merugikan dan menjaga keadilan pengguna.
Peluncuran BAM juga sejalan dengan pemikiran ini: pada dasarnya, ia mengubah mekanisme pemeringkatan yang awalnya digunakan untuk arbitrase MEV menjadi sebuah “perisai”, untuk melindungi penyedia likuiditas seperti pembuat pasar, misalnya dengan memprioritaskan pembatalan paksa untuk menghindari kerugian bagi pembuat pasar, serta memperkenalkan insentif lelang untuk mengurangi keuntungan dari pelarian. Pencari MEV yang sebelumnya ingin menghasilkan uang harus mengubah peran, menulis plugin BAM untuk melayani protokol DeFi, dan memperoleh keuntungan dari biaya plugin.
Belajar dari HYPERLIQUID
Gagasan ACE/BAM di atas sebenarnya dapat dilihat sebagai upaya untuk mengejar mekanisme pencocokan di blockchain Hyperliquid. Hyperliquid adalah sebuah rantai khusus (Appchain), yang secara alami dirancang untuk melayani DEX. Selain itu, HLP Vault yang dioperasikan secara resmi oleh Hyperliquid sebenarnya adalah salah satu pembuat pasar terbesar di platform tersebut, jadi tidak sulit untuk memahami bahwa aturan rantai Hyperliquid lebih memihak kepada penyedia likuiditas, dan telah menerapkan banyak desain yang melindungi pembuat pasar di tingkat rantai, seperti:
Prioritas Perlindungan Pihak yang Memasang Order: Pembatalan order dan hanya melakukan order maker diproses terlebih dahulu, menghindari para pembuat pasar dari transaksi yang merugikan tanpa sepengetahuan mereka. “Prioritas Eksekusi Pembatalan” yang disebutkan oleh Solana ACE sudah dipraktikkan oleh Hyperliquid selama bertahun-tahun.
Jaminan Harga Terbaru: Proses likuidasi dan pencocokan Hyperliquid menekankan penggunaan harga terbaru dan status margin untuk melakukan “pemeriksaan ganda”. Misalnya, ketika ada order yang dipenuhi, sistem akan menarik harga oracle terbaru untuk menilai margin kedua belah pihak, memastikan bahwa tidak ada risiko yang disebabkan oleh keterlambatan harga. Ini mirip dengan ACE yang memasukkan pembaruan oracle sebelum eksekusi perdagangan.
Perlindungan Transaksi Sendiri: Jika alamat yang sama melakukan pembelian dan penjualan secara bersamaan, Hyperliquid secara otomatis membatalkan daripada mencocokkan, untuk mencegah peningkatan volume atau biaya yang tidak perlu.
Solana ICM’s ACE/BAM, tanpa diragukan lagi, adalah “belajar” dari Hyperliquid. Hyperliquid sebagai pemimpin CLOB on-chain telah mewujudkan berbagai mekanisme yang ramah bagi pembuat pasar dengan menggunakan rantai eksklusif. Sekarang Solana berharap untuk menggunakan rantai umum dengan modul plugin untuk meniru efek ini—yakni memberikan setiap aplikasi kontrol serupa Hyperliquid dalam pengurutan transaksi.
⚡ Meniru Dua: Finalitas Instan
Perbandingan konsensus yang ada
Solana saat ini menggunakan Tower BFT, konfirmasi dan finalitas bersifat probabilistik dan bertahap: sebuah blok yang mendapatkan 2/3 suara dianggap sebagai “konfirmasi (Confirmed)”, tetapi perlu akumulasi sekitar 32 blok lanjutan di blockchain (biasanya sekitar 13 detik) untuk dipastikan sebagai “finalisasi (Finalized)”. Untuk beberapa aplikasi (seperti perdagangan frekuensi tinggi), waktu konfirmasi akhir yang beberapa detik masih terlalu lama.
HyperBFT adalah algoritma konsensus yang dikembangkan sendiri oleh Hyperliquid, terinspirasi oleh konsensus HotStuff, menggunakan dua putaran pemungutan suara untuk mengonfirmasi blok, mencapai “finalitas instan.”
Putaran Pertama: Prabola (Prevote): Validator menerima blok kandidat yang disiarkan oleh Proposer, lalu melakukan verifikasi cepat. Jika verifikasi berhasil, setiap validator akan memberikan satu “prabola” (Prevote) untuk blok ini dan menyiarkannya ke seluruh jaringan. Tiket ini mewakili: “Saya sudah melihat secara awal, blok ini tidak ada masalah.”
Putaran Kedua: Precommit(Precommit): Begitu seorang validator mengumpulkan Prevote dari lebih dari dua pertiga validator untuk blok kandidat yang sama, ia mendapatkan cukup kepercayaan, percaya bahwa mayoritas anggota jaringan mengakui blok ini. Maka, validator tersebut akan memberikan suara “precommit”(Precommit) yang lebih memiliki bobot, dan menyiarkannya. Suara ini mewakili: “Saya melihat bahwa mayoritas jaringan setuju, saya siap untuk secara resmi menulis blok ini ke dalam buku besar.”
Ketika seorang validator mengumpulkan Precommit dari lebih dari dua pertiga validator untuk blok kandidat yang sama, konsensus tercapai! Blok tersebut dianggap finalisasi (Finalized). Itu akan ditambahkan secara permanen dan tidak dapat diubah ke dalam blockchain.
Ini berarti setiap blok Hyperliquid adalah blok final dan tidak ada kemungkinan rollback fork, dengan keterlambatan pembuatan blok yang sangat rendah - secara resmi diungkapkan bahwa rata-rata keterlambatan konfirmasi sekitar 0,2 detik, dan tidak lebih dari 0,9 detik dalam 99% kasus. Kepastian final dalam skala milidetik ini sangat ideal untuk perdagangan frekuensi tinggi, karena begitu transaksi dikirim, transaksi tersebut dapat segera dikonfirmasi dan tidak dapat direorganisasi, yang secara signifikan meningkatkan efisiensi modal.
ALPENGLOW mewujudkan finalitas instan
Alpenglow adalah protokol konsensus baru yang akan diluncurkan oleh Solana, dengan tujuan untuk mempercepat konfirmasi akhir blok menjadi 1-2 slot (sekitar 150ms), mencapai finalitas instan yang mirip dengan HyperBFT. Komponen yang menggantikan TowerBFT untuk konsensus dalam Alpenglow disebut Votor, yang merupakan sistem pemungutan suara ganda:
Jalur Cepat: Jika dalam putaran pertama pemungutan suara untuk sebuah blok, lebih dari atau sama dengan 80% dari “hak suara” jaringan (yang dapat dipahami sebagai jumlah SOL yang dipertaruhkan oleh validator yang mewakili bobot suara) memberikan suara setuju bahwa blok ini adalah valid, maka blok ini akan segera dikonfirmasi sebagai “finalitas” (Finalize).
Saluran Lambat: Jika dalam putaran pertama pemungutan suara, persentase hak suara yang menyetujui tidak mencapai 80%, tetapi setidaknya 60%, Votor akan memulai putaran pemungutan suara kedua. Jika setelah putaran kedua pemungutan suara, persentase hak suara yang menyetujui blok tersebut tetap 60% atau lebih, maka blok ini juga akan dikonfirmasi secara final.
Votor sama dengan mengatakan: “Kami secara default melakukan satu ronde pemungutan suara untuk mengonfirmasi, tetapi jika kondisinya tidak sempurna, kami akan memulai proses pemungutan suara dua ronde yang hampir sama dengan HyperBFT sebagai asuransi.” Sebenarnya ini adalah tiruan dari mekanisme pemungutan suara Hyperliquid.
Biaya dan strategi finalitas instan
Hyperliquid dapat melakukan dua putaran pemungutan suara, dengan satu syarat penting: ia menggunakan kumpulan validator yang sangat ramping, di mana pada awalnya sebenarnya kurang dari 5 entitas yang mengendalikan sebagian besar node validator, jaringan yang berskala terbatas dapat secara signifikan mengurangi overhead komunikasi konsensus BFT.
Namun, jika jumlah node diperluas menjadi puluhan atau ratusan, kompleksitas proses pemungutan suara akan meningkat dengan cepat, karena kompleksitas setiap putaran pemungutan suara sebanding dengan kuadrat jumlah node yang terlibat dalam komunikasi. Solana memiliki ribuan node validator, dan untuk mencapai dua putaran pemungutan suara sambil mempertahankan tingkat desentralisasi yang tinggi, kesulitan teknisnya jauh lebih besar dibandingkan Hyperliquid. Oleh karena itu, Solana perlu melakukan banyak pekerjaan dalam komunikasi jaringan. Beberapa langkah telah disebutkan dalam peta jalan:
Di Alpenglow terdapat komponen Rotor yang menggantikan protokol distribusi data lama Turbine. Berbeda dengan Turbine yang memerlukan beberapa tingkat perantara, Rotor menggunakan mode “relay satu lompatan” yang memungkinkan blok data mencapai validator target dengan kecepatan yang lebih cepat, secara signifikan mengurangi latensi transmisi. Selain itu, dalam mekanisme Turbine yang ada, posisi node dalam pohon distribusi data terutama diurutkan berdasarkan bobot stake, di mana node dengan stake lebih besar ditempatkan pada tingkat yang lebih tinggi dan menerima potongan data (shreds) lebih dulu, namun juga harus menanggung lebih banyak tugas perantara downstream, sehingga konsumsi bandwidth lebih besar. Asumsi di balik desain ini adalah: node dengan stake lebih banyak sering kali adalah “pro”, dipastikan memiliki perangkat keras yang lebih kuat dan sumber bandwidth yang lebih memadai. Rotor memperbarui logika ini, tidak lagi hanya bergantung pada ukuran stake, tetapi mempertimbangkan secara komprehensif bandwidth aktual dan kinerja komunikasi setiap node. Node yang menunjukkan kinerja lebih baik dalam jaringan waktu nyata akan diatur secara dinamis ke posisi kunci, sehingga merencanakan jalur penyebaran data yang optimal untuk seluruh jaringan, mewujudkan layanan “kurir” yang cepat dan stabil.
Jaringan Berkecepatan Tinggi DoubleZero berbasis pada jaringan serat optik khusus + teknologi multicast, menyediakan komunikasi berlatensi rendah yang lebih cepat satu orde dibandingkan dengan internet publik. Ini mengurangi latensi dan jitter pesan bolak-balik antara node yang terdistribusi secara geografis, menjadikan dasar jaringan fisik untuk konsensus cepat lebih solid.
Meskipun demikian, Solana masih menghadapi tantangan besar untuk mencapai “decentralisasi tinggi + finalitas dalam milidetik” secara bersamaan. Itulah sebabnya Alpenglow memperkirakan bahwa masih diperlukan lebih dari satu tahun pengembangan, dan diperkirakan akan diluncurkan awal tahun 2026 (semoga demikian).
🔄 Meniru Tiga: Eksekusi Asinkron Jalur
Jalur aliran asinkron HYPERLIQUID
Blockchain tradisional adalah single-threaded, sebuah blok harus dieksekusi dan diverifikasi sepenuhnya sebelum blok berikutnya dapat mulai diproses. Tujuannya adalah untuk menghilangkan ketidakpastian yang ditimbulkan oleh multi-threading, memastikan semua node mendapatkan hasil yang sama dalam urutan yang sama. Namun, kelemahannya adalah membatasi kinerja CPU multi-core modern.
Dan Hyperliquid secara tidak tradisional memperkenalkan multithreading, memisahkan alur kerja menjadi dua jalur paralel yaitu “penyortiran (konsensus)” dan “eksekusi”. Proses eksekusinya adalah sebagai berikut:
Titik waktu T1:
Pipa Konsensus: Para validator mencapai kesepakatan tentang konten dan urutan transaksi dari blok N-1.
Titik waktu T2 (tempat dimulainya sihir) :
Jalur Konsensus: Mulai memproses blok N. Ini akan mengemas, mengurutkan transaksi di jaringan, dan melakukan pemungutan suara serta mencapai kesepakatan tentang urutan ini. Ini sama sekali tidak peduli dengan hasil eksekusi blok N-1.
Menjalankan Jalur: Mengambil blok N-1 yang telah mencapai konsensus pada waktu T1, dan mulai mengeksekusi transaksi di dalamnya.
Titik waktu T3 (jalur produksi berjalan terus):
Pipeline Konsensus: Telah menyelesaikan konsensus untuk blok N dan mengirimkan hasil konsensus (sebuah daftar transaksi yang terurut) ke pipeline eksekusi. Kemudian, ia segera mulai memproses blok N+1.
Eksekusi Pipeline: Telah menyelesaikan eksekusi blok N-1 dan akhirnya mengonfirmasi statusnya. Kemudian, ia terhubung dengan mulus, langsung mengambil blok N yang baru saja diselesaikan oleh pipeline konsensus, dan mulai mengeksekusi transaksinya.
Dalam mode Pipeline ini, inti CPU yang berbeda dapat dimanfaatkan secara efektif. Beberapa inti dapat secara khusus menangani pesan jaringan dan pemungutan suara konsensus (pengurutan), sementara inti lainnya dapat sepenuhnya melakukan perhitungan status (eksekusi), dengan dua jalur pipa yang bekerja secara bersamaan, memaksimalkan efisiensi perangkat keras.
Rencana APE ICM
eksekusi
Namun, mewujudkan eksekusi paralel/asinkron yang aman di rantai terdesentralisasi adalah tantangan rekayasa yang sangat sulit: Untuk memastikan semua node di seluruh dunia mencapai kesepakatan penuh tentang hasil transaksi, semua faktor yang dapat menyebabkan hasil yang berbeda akibat urutan eksekusi yang berbeda harus dihilangkan.
Alasan mengapa skema saluran asinkron dapat berhasil di Hyperliquid adalah karena Hyperliquid sebagai appchain dengan fungsi tunggal, model statusnya sederhana dan jelas (terutama buku pesanan dan posisi pengguna di berbagai pasar perdagangan). Tim pengembang dapat dengan jelas membagi operasi mana yang dapat dilakukan secara paralel, mana yang memiliki ketergantungan, dan merancang saluran yang efisien berdasarkan hal tersebut.
Namun, sebagai rantai umum, ketergantungan dalam transaksi di Solana jauh lebih kompleks dibandingkan dengan sistem order book. Oleh karena itu, untuk mereproduksi kinerja Hyperliquid dalam lingkungan umum, tantangan teknik yang dihadapi Solana jauh lebih berat, memerlukan pengembangan ulang banyak kode, dan tidak dapat dicapai dalam jangka pendek. Oleh karena itu, dalam peta jalan ICM, ini juga hanya bisa dikategorikan sebagai perencanaan jangka menengah. Meskipun demikian, peluncuran APE yang sebenarnya masih harus mengatasi serangkaian tantangan:
Kompleksitas Kode yang Ekstrem: Membuat sistem terdistribusi mendukung eksekusi paralel asinkron memerlukan banyak perubahan di tingkat dasar. Begitu multithreading paralel diperkenalkan, kompleksitas perangkat lunak klien node validasi Solana akan meningkat secara eksponensial, dan risiko bug yang tidak diketahui juga akan melonjak. Satu kondisi balapan yang tidak ditangani dengan baik bisa menyebabkan kesalahan konsensus, dan hasilnya akan menjadi bencana.
Peningkatan Persyaratan Perangkat Keras: Eksekusi paralel memerlukan CPU multi-core yang kuat dan lebih banyak memori untuk menjalankan beberapa utas eksekusi secara bersamaan, memelihara beberapa status sementara dan titik pemulihan. Ambang batas untuk node Solana sudah tinggi, dan jika ditingkatkan lebih lanjut, akan mempengaruhi desentralisasi jaringan.
Penanganan Kasus Terburuk: Kasus terburuk dari eksekusi paralel adalah ketika banyak transaksi bersaing untuk status yang sama. Misalnya, ketika menghadapi kontrak-kontrak populer tertentu (seperti DEX yang populer atau kontrak pembelian cepat) yang menyebabkan semua transaksi membaca dan menulis ke akun yang sama, maka penjadwal paralel akan terus mendeteksi konflik, melakukan rollback, dan replay, yang mungkin malah lebih lambat dibandingkan eksekusi serial. Bagaimana cara menurunkan dengan elegan dalam kasus terburuk ini, tanpa membuat sistem terjebak dalam keadaan alive lock atau penurunan kinerja yang drastis, merupakan tantangan dalam desain arsitektur.
Kesulitan Pengembangan dan Audit: Verifikasi keamanan di bawah kondisi asinkron dan multi-threading sangat sulit. Komunitas Solana perlu menginvestasikan sumber daya tambahan untuk mengaudit model eksekusi baru, untuk mencegah eksploitasi celah konsensus yang disebabkan oleh paralel.
🤔 Apakah pertunjukan tiruan ini bisa berhasil?
Berdasarkan analisis di atas, peta jalan Solana ICM sebenarnya adalah sebuah “pertunjukan tiruan” yang mendalam terhadap arsitektur teknologi Hyperliquid. Tim inti Solana berencana untuk meniru semua keahlian andalan Hyperliquid satu per satu, dan kemudian melengkapinya untuk Drift, membantu mereka berkompetisi di pasar DEX melawan Hyperliquid. Namun, saya tidak optimis tentang prospek pertunjukan tiruan ini.
Peningkatan kesulitan teknis secara eksponensial
Keberhasilan Hyperliquid sebagian besar dibangun di atas kondisi bawaan yang menguntungkan:
Sebagai rantai khusus, ia dapat mengoptimalkan konsensus dan eksekusi di sekitar aplikasi tunggal, dirancang tanpa perlu mempertimbangkan berbagai kebutuhan kontrak pintar yang berbeda;
Sebagai rantai yang baru muncul, ia bahkan dapat mengorbankan tingkat desentralisasi tertentu demi mendapatkan kinerja (validator awal dikendalikan oleh tim, dan sebagian besar pengguna juga mengizinkan hal ini).
Melihat Solana, sangat sulit secara teknis untuk mencapai tingkat Hyperliquid sambil mempertahankan universalitas dan desentralisasi dari blockchain publik. Sebagai contoh, konsensus HyperBFT dari Hyperliquid dapat menghasilkan latensi 0,2 detik dengan kurang dari 5 node, sementara Solana harus melampaui batas komunikasi jaringan untuk mencapai latensi yang sama dengan 2000 node; mesin pemesanan Hyperliquid hanya melayani logika bursa mereka sendiri, sementara ACE/BAM Solana harus disesuaikan dengan berbagai protokol DeFi.
Bisa dikatakan, Solana sedang mengejar ketertinggalan Hyperliquid, dan tingkat kesulitannya jauh lebih tinggi dibandingkan dengan yang dialami Hyperliquid saat itu yang “tidak tahu sudah tinggi kemana”. Peta jalan ICM membagi tugas-tugas ini hingga 2027, menunjukkan bahwa pihak resmi juga menyadari bahwa ini bukan pekerjaan yang bisa selesai dalam sehari.
Kontradiksi antara desentralisasi dan efisiensi
Perbedaan lain antara Solana dan Hyperliquid terletak pada tata kelola dan ritme peningkatan. Tim Hyperliquid kecil, keputusan terpusat, dan tidak memiliki pengawasan tata kelola eksternal, sehingga bergerak sangat cepat. Pada bulan Maret tahun ini, ketika Hyperliquid mengalami insiden manipulasi kontrak JELLY, tim dengan cepat mengambil keputusan untuk menghentikan pasar terkait dalam beberapa jam, melindungi keamanan dana, menunjukkan bahwa meskipun “secara politik tidak benar”, keputusan terpusat memang efektif dan berguna pada saat-saat krusial.
Solana sebagai blockchain publik, memiliki yayasan, pengembang inti, dan berbagai pihak di komunitas yang berperan dalam pengambilan keputusan. Proses pembaruan relatif lambat dan konservatif. Misalnya, Firedancer yang sangat dinantikan (klien Solana berkinerja tinggi yang dikembangkan oleh Jump) telah dimulai sejak 2022 hingga sekarang (pertengahan 2025) masih dalam tahap pengujian dan penyempurnaan, belum sepenuhnya diluncurkan; setiap perubahan yang melibatkan konsensus memerlukan waktu lama untuk audit dan pengoperasian testnet. Perubahan dalam perencanaan roadmap ICM bahkan lebih signifikan: harus mengganti algoritma konsensus inti, memperkenalkan eksekusi paralel yang sepenuhnya baru, dan mendistribusikan kekuasaan kunci, yang pasti memiliki kesulitan dan risiko yang lebih tinggi. Dapat diperkirakan, dalam dua atau tiga tahun ke depan, tim Solana perlu secara bertahap melaksanakan pembaruan ini, di mana setiap langkah mungkin menghadapi tantangan teknis yang tidak terduga atau resistensi dari komunitas.
Misalnya, BAM yang diluncurkan oleh Jito, agar benar-benar menguntungkan pengguna, sebagian besar validator harus beralih ke klien yang mendukung BAM. Jika tidak, transaksi pengguna kadang-kadang akan melalui BAM dan kadang-kadang tidak, yang akan menyebabkan pengalaman yang tidak konsisten bahkan celah arbitrase. Masalahnya adalah, Solana tidak dapat memaksa node validator untuk memperbarui klien. Oleh karena itu, meskipun BAM berhasil dikembangkan, kecepatan promosinya juga sulit diprediksi. Jadi, jadwal di ICM hanyalah perencanaan optimis, realisasinya kemungkinan akan ditunda berkali-kali, dan untuk mencapai semua tujuan, mungkin kita harus menunggu hingga tahun monyet dan tahun kuda.
Bahkan jika semuanya berjalan lancar, pada tahun 2027 Solana akan mencapai implementasi ACE dan lainnya, itu hanya “berhasil mengejar ketertinggalan” — mengejar fitur yang sudah disediakan oleh Hyperliquid pada tahun 2023-2024. Dan Hyperliquid sendiri tidak akan berhenti: misalnya, proposal HIP-3 akan diluncurkan pada paruh kedua tahun 2025, yang memungkinkan komunitas untuk secara mandiri meluncurkan pasar kontrak berkelanjutan. Berbagai inovasi akan semakin memperluas cakupan pasar Hyperliquid. Saat Solana akhirnya berhasil mengimplementasikan fitur-fitur yang ada di Hyperliquid sekarang, mungkin Hyperliquid sudah membuka keunggulan baru yang memimpin.
Melampaui persaingan teknologi
Meskipun artikel ini berfokus pada perbandingan antara Solana dan Hyperliquid dalam pertempuran jalur teknologi, kita juga harus melihat bahwa keberhasilan Hyperliquid tidak hanya bergantung pada faktor teknis. Hyperliquid memiliki banyak hal positif dalam operasi dan ekosistemnya:
Misalnya, dalam ekonomi token, Hyperliquid tidak memiliki pendanaan VC, lebih dari 76% token didistribusikan kepada komunitas. Keuntungan biaya yang diperoleh platform dapat digunakan untuk membeli kembali token HYPE, benar-benar berbagi kepentingan dengan pengguna, dan tidak ada masalah eksploitasi berlebihan terhadap pengguna oleh pihak modal. Hal ini telah memenangkan reputasi baik dari banyak pengguna setia untuk Hyperliquid.
Selain itu, tim Hyperliquid sangat peka terhadap permintaan pasar: ketika NFT sedang populer, mereka meluncurkan indeks NFT; ketika SocialFi naik daun, mereka memperkenalkan indeks FriendTech; HIP-2 mengatasi masalah “sulitan peluncuran dingin untuk token baru, kekurangan likuiditas awal”; Hyperps menyelesaikan tantangan untuk menyediakan perdagangan berjangka untuk aset yang belum resmi diluncurkan; dan rencana upgrade HIP-3 tahun ini mendukung proyek mana pun untuk menerbitkan pasar kontrak berkelanjutan secara mandiri. Inovasi produk datang silih berganti, berbagai jenis perdagangan yang kaya dan cara bermain yang inovatif ini sangat meningkatkan daya tarik Hyperliquid sebagai platform perdagangan—pengguna datang ke sini bukan hanya karena kecepatan, tetapi juga karena peluang menghasilkan uang yang tidak ada di tempat lain.
Melihat jalur DEX Solana, DEX asli Solana seperti Drift saat ini tidak memiliki keunggulan yang jelas dalam desain produk dan mekanisme insentif. Hanya dengan meniru teknologi Hyperliquid dan menyamakan kinerja rantai, jika tidak ada fitur khas yang menyelesaikan masalah pengguna, tidak akan secara otomatis membawa pengguna kembali dalam skala besar, mengingat perpindahan pengguna juga memiliki biaya.
Oleh karena itu, jika hanya meniru langkah Hyperliquid, maka akan selamanya hanya bisa mengikuti dan tertinggal. Peluang nyata dari peta jalan Solana ICM tidak terletak di bidang kontrak berkelanjutan atau buku pesanan. Masih banyak bidang dalam ekosistem Solana yang belum dijelajahi oleh Hyperliquid, seperti peluncuran MEME, protokol pinjaman, dan lain-lain, yang juga dapat memanfaatkan perbaikan yang dibawa oleh ICM untuk menciptakan pengalaman pengguna yang lebih lancar. Jika Solana dapat menginovasi fitur di bidang-bidang ini dan menyelesaikan masalah pengguna, maka bahkan jika di pasar kontrak berkelanjutan tidak dapat segera membalikkan keadaan, tetap saja dapat memperkuat pencapaian visi “pasar modal internet”-nya. Bagaimanapun juga, sekuat apa pun Hyperliquid, itu hanyalah sebuah aplikasi rantai di bidang vertikal, sementara Solana memiliki peta aplikasi yang luas dan beragam, yang merupakan modal terbesarnya untuk jangka panjang.
🏁 Kesimpulan: Meniru itu mudah, melampaui itu sulit
Peta jalan ICM Solana menunjukkan tekad komunitas Solana untuk tidak kalah dan berjuang maju. Dari ACE ke Alpenglow hingga APE, masing-masing terkait dengan fitur khas Hyperliquid, memang ada makna “tiruan yang ditargetkan”.
Namun, meniru itu mudah, melampaui itu sulit. Solana perlu berusaha keras dalam penguasaan teknologi, kolaborasi ekosistem, dan strategi pasar untuk berhasil dalam pertunjukan peniruan ini. Dalam jangka pendek, Solana mungkin dapat meningkatkan pengalaman transaksi di blockchain melalui BAM dan sebagian memulihkan beberapa pengguna. Namun, untuk benar-benar mengguncang posisi terdepan Hyperliquid, mungkin dibutuhkan waktu yang lebih lama dan lebih banyak inovasi.
Setidaknya saat ini, Hyperliquid terus memperluas wilayahnya dengan keunggulan pangsa pasarnya, sementara Solana masih dalam proses mempercepat modifikasi mesinnya, dan mungkin proses modifikasi ini akan berlangsung cukup lama.
Peta jalan ICM menggambarkan masa depan yang menggairahkan, tetapi apakah bisa mencapai “menyalip di tikungan”, masih perlu diuji oleh waktu. Sebagai pengguna biasa, kita dapat berharap bahwa persaingan ini akan membawa pengalaman transaksi on-chain yang lebih baik—terlepas dari siapa yang akhirnya menang, pengguna adalah pihak yang diuntungkan.
Artikel ini didasarkan pada analisis informasi publik dan tidak merupakan saran investasi. Investasi cryptocurrency memiliki risiko yang besar, mohon berhati-hati dalam mengambil keputusan, DYOR.
Jika Anda menyukai artikel ini, silakan ikuti, suka, dan bagikan dukungan!
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Tinjauan tajam tentang peta jalan "Pasar Kapital Internet" Solana: sebuah "pertunjukan tiruan" yang mengejar Hyperliquid
🚀 Pendahuluan: para pro SOLANA mengadakan pertemuan
Baru-baru ini, terjadi sesuatu yang sangat menarik di ekosistem Solana. Termasuk Solana Foundation, Anza, Jito Labs, dan sejumlah pro berkumpul bersama untuk merilis sebuah peta jalan teknologi yang bernama “Internet Capital Markets (Internet Capital Markets, ICM )”. Ide inti dari peta jalan ini adalah “Application Controlled Execution (Application Controlled Execution, ACE )”, secara sederhana, ini berarti memberikan aplikasi di chain hak penyortiran transaksi secara mandiri dalam milidetik, menciptakan sebuah “Wall Street di chain” yang terdesentralisasi.
Namun yang menarik adalah, setelah membaca seluruh peta jalan, meskipun tidak menyebutkan Hyperliquid secara langsung, desain di dalamnya hampir di setiap tempat ditujukan untuk kekuatan Hyperliquid. Ini seperti Solana yang mengatakan: “Kami juga ingin memiliki apa yang kamu miliki di Hyperliquid, dan kami ingin melakukannya dengan lebih baik!”
Perlu diketahui bahwa Hyperliquid mendominasi pasar kontrak berjangka permanen di blockchain, dengan volume perdagangan yang pernah mencapai sekitar 65% dari seluruh pasar berjangka terdesentralisasi. Jelas, menghadapi pesaing seperti itu, Solana tentu tidak mau tertinggal oleh pendatang baru, sehingga meluncurkan peta jalan ICM ini.
Jadi, apa sebenarnya “pertunjukan tiruan” ini? Apakah Solana benar-benar bisa mengejar atau bahkan melampaui Hyperliquid? Hari ini kita akan membahas topik ini lebih dalam.
📋 Latar Belakang dan Konten ICM
Siapa yang memimpin perubahan ini?
Pertama, mari kita lihat siapa yang menyusun peta jalan ini. Yang terlibat adalah pemain-pemain besar dalam ekosistem Solana:
Masalah inti yang harus diselesaikan
Peta jalan berfokus pada perbaikan struktur mikro pasar, yang secara sederhana adalah mekanisme perdagangan on-chain saat ini tidak cukup ramah bagi pembuat pasar. Artinya, Taker yang secara aktif memulai perdagangan mendapatkan keuntungan, sementara Market Maker yang menunggu untuk menyelesaikan pesanan menderita kerugian. Ini karena Taker sering kali menguasai informasi terbaru dan secara aktif meningkatkan biaya transaksi untuk memastikan bahwa perdagangan mereka dieksekusi terlebih dahulu, sementara Maker sering kali tidak punya waktu untuk membatalkan pesanan dan terpaksa menyelesaikan transaksi pada harga yang merugikan.
Beberapa arbitrase frekuensi tinggi akan memanfaatkan asimetri ini untuk melakukan serangan “traffic beracun”. Misalnya, ketika harga di blockchain belum diperbarui, tetapi harga di luar blockchain sudah berubah, para arbitrase dapat mengambil pesanan dari pembuat pasar dengan harga lama, menyebabkan pembuat pasar menanggung kerugian. Akibatnya, Maker untuk melindungi diri, harus memperlebar selisih harga beli dan jual, atau mengurangi jumlah pesanan yang dipasang, yang mengakibatkan likuiditas pasar secara keseluruhan menjadi lebih buruk.
Peta jalan ICM adalah untuk menyeimbangkan pola ini, menarik likuiditas berkualitas tinggi kembali ke rantai.
Tiga langkah ICM
Solana membagi rencana besar ini menjadi tiga tahap:
Jangka Pendek (1-3 Bulan): Utamanya adalah mengoptimalkan pengalaman transaksi on-chain yang ada, membuat aplikasi jenis buku pesanan lebih mudah digunakan, dan mengurangi gangguan MEV yang merugikan. Secara spesifik mencakup:
Perbaikan ini diharapkan akan dilaksanakan secara bertahap pada bulan Juli hingga September 2025.
Jangka Menengah (3-9 Bulan): Memperkenalkan jaringan cepat yang khusus dan konsensus versi baru, secara signifikan mengurangi latensi dan meningkatkan throughput:
Jangka Panjang (9-30 bulan): Melakukan peningkatan revolusioner pada arsitektur inti Solana, dengan target untuk mencapainya sekitar tahun 2027:
Analisis sampai di sini, penulis berpendapat bahwa pengajuan peta jalan ICM kali ini, cerita di baliknya seharusnya seperti ini: DEX lama di Solana, Drift, dikalahkan oleh pendatang baru Hyperliquid dengan pengalaman “Binance on-chain” yang unggul. Drift sendiri tidak mampu bersaing, jadi terpaksa meminta bantuan dari Solana Labs, Anza, Jito, dan “pro” lainnya. “Pro” tersebut mengajukan rencana perombakan teknis ICM, mengklaim akan mereplikasi semua keahlian utama Hyperliquid untuk Drift, membantu mereka kembali bersaing di pasar DEX. Namun, “pro” tersebut juga mengatakan bahwa perombakan teknis kali ini sangat sulit, sehingga rencana teknis dibagi menjadi strategi tiga langkah, dan perlengkapan yang dapat diberikan kepada Drift dalam waktu dekat hanya BAM dari Jito, agar Drift dapat bertahan dan berkompetisi dengan Hyperliquid.
Setelah menjelaskan latar cerita, penulis akan menganalisis secara rinci keahlian apa saja yang ditiru dan direplikasi oleh ICM dari Hyperliquid di bab-bab berikutnya.
🎭 Imitasi Satu: Mekanisme Pengurutan Transaksi
Masalahnya: Seperti yang disebutkan sebelumnya, rantai saat ini lebih menguntungkan taker, maker menanggung “aliran beracun”. Pengguna yang secara aktif mengambil order dapat berdasarkan harga terbaru di luar rantai, segera memulai transaksi terhadap order yang dipasang di dalam rantai, dan dengan meningkatkan biaya transaksi agar dapat diproses lebih cepat. Sementara itu, pembuat pasar sering kali tidak memiliki waktu untuk memperbarui atau membatalkan order. Hasilnya adalah, pembuat pasar harus memperlebar spread atau bahkan menarik likuiditas, membuat kedalaman pasar menjadi lebih buruk.
Solusi akhir ICM: Aplikasi eksekusi terkendali (ACE)
Peta jalan ICM mengusulkan konsep ACE (Application Controlled Execution), yaitu mendelegasikan hak pengurutan transaksi kepada aplikasi yang ada di setiap rantai, di mana aplikasi sendiri memutuskan bagaimana urutan eksekusi transaksi yang terkait dengan aplikasi tersebut. Sebagai contoh, di Solana yang akan menerapkan ACE di masa depan, kontrak DeFi dapat menerapkan aturan pengurutan transaksi yang dikustomisasi sebagai berikut:
BAM JITO: Rencana Transisi
Sebelum ACE resmi diluncurkan, Jito Labs meluncurkan solusi transisi yang disebut Block Assembly Marketplace (BAM). Alur kerja BAM adalah:
BAM dapat dianggap sebagai ladang percobaan sebelum ACE di blockchain, fungsinya sangat dekat dengan ACE yang terakhir, hanya saja ia berjalan di jaringan independen di luar, bukan di dalam protokol utama Solana.
Perlu dicatat bahwa Jito sebelumnya menyediakan infrastruktur yang ditujukan untuk ekstraksi MEV (seperti Jito Block Engine), di mana model bisnisnya adalah dengan mengoptimalkan urutan transaksi untuk menciptakan peluang bagi para arbiter dan membagikan keuntungan. Ini dalam beberapa hal berdiri di sisi berlawanan dari pengguna biasa dan mereka yang dieksploitasi, sebagai “mata panah”. Namun, Jito pada awal 2024 menutup fungsi mempool publik (mempool) yang ditujukan untuk robot arbitrase, untuk mengurangi eksternalitas negatif seperti serangan sandwich. Langkah ini menunjukkan bahwa komunitas Solana cenderung untuk menekan MEV yang merugikan dan menjaga keadilan pengguna.
Peluncuran BAM juga sejalan dengan pemikiran ini: pada dasarnya, ia mengubah mekanisme pemeringkatan yang awalnya digunakan untuk arbitrase MEV menjadi sebuah “perisai”, untuk melindungi penyedia likuiditas seperti pembuat pasar, misalnya dengan memprioritaskan pembatalan paksa untuk menghindari kerugian bagi pembuat pasar, serta memperkenalkan insentif lelang untuk mengurangi keuntungan dari pelarian. Pencari MEV yang sebelumnya ingin menghasilkan uang harus mengubah peran, menulis plugin BAM untuk melayani protokol DeFi, dan memperoleh keuntungan dari biaya plugin.
Belajar dari HYPERLIQUID
Gagasan ACE/BAM di atas sebenarnya dapat dilihat sebagai upaya untuk mengejar mekanisme pencocokan di blockchain Hyperliquid. Hyperliquid adalah sebuah rantai khusus (Appchain), yang secara alami dirancang untuk melayani DEX. Selain itu, HLP Vault yang dioperasikan secara resmi oleh Hyperliquid sebenarnya adalah salah satu pembuat pasar terbesar di platform tersebut, jadi tidak sulit untuk memahami bahwa aturan rantai Hyperliquid lebih memihak kepada penyedia likuiditas, dan telah menerapkan banyak desain yang melindungi pembuat pasar di tingkat rantai, seperti:
Solana ICM’s ACE/BAM, tanpa diragukan lagi, adalah “belajar” dari Hyperliquid. Hyperliquid sebagai pemimpin CLOB on-chain telah mewujudkan berbagai mekanisme yang ramah bagi pembuat pasar dengan menggunakan rantai eksklusif. Sekarang Solana berharap untuk menggunakan rantai umum dengan modul plugin untuk meniru efek ini—yakni memberikan setiap aplikasi kontrol serupa Hyperliquid dalam pengurutan transaksi.
⚡ Meniru Dua: Finalitas Instan
Perbandingan konsensus yang ada
Solana saat ini menggunakan Tower BFT, konfirmasi dan finalitas bersifat probabilistik dan bertahap: sebuah blok yang mendapatkan 2/3 suara dianggap sebagai “konfirmasi (Confirmed)”, tetapi perlu akumulasi sekitar 32 blok lanjutan di blockchain (biasanya sekitar 13 detik) untuk dipastikan sebagai “finalisasi (Finalized)”. Untuk beberapa aplikasi (seperti perdagangan frekuensi tinggi), waktu konfirmasi akhir yang beberapa detik masih terlalu lama.
HyperBFT adalah algoritma konsensus yang dikembangkan sendiri oleh Hyperliquid, terinspirasi oleh konsensus HotStuff, menggunakan dua putaran pemungutan suara untuk mengonfirmasi blok, mencapai “finalitas instan.”
Ini berarti setiap blok Hyperliquid adalah blok final dan tidak ada kemungkinan rollback fork, dengan keterlambatan pembuatan blok yang sangat rendah - secara resmi diungkapkan bahwa rata-rata keterlambatan konfirmasi sekitar 0,2 detik, dan tidak lebih dari 0,9 detik dalam 99% kasus. Kepastian final dalam skala milidetik ini sangat ideal untuk perdagangan frekuensi tinggi, karena begitu transaksi dikirim, transaksi tersebut dapat segera dikonfirmasi dan tidak dapat direorganisasi, yang secara signifikan meningkatkan efisiensi modal.
ALPENGLOW mewujudkan finalitas instan
Alpenglow adalah protokol konsensus baru yang akan diluncurkan oleh Solana, dengan tujuan untuk mempercepat konfirmasi akhir blok menjadi 1-2 slot (sekitar 150ms), mencapai finalitas instan yang mirip dengan HyperBFT. Komponen yang menggantikan TowerBFT untuk konsensus dalam Alpenglow disebut Votor, yang merupakan sistem pemungutan suara ganda:
Votor sama dengan mengatakan: “Kami secara default melakukan satu ronde pemungutan suara untuk mengonfirmasi, tetapi jika kondisinya tidak sempurna, kami akan memulai proses pemungutan suara dua ronde yang hampir sama dengan HyperBFT sebagai asuransi.” Sebenarnya ini adalah tiruan dari mekanisme pemungutan suara Hyperliquid.
Biaya dan strategi finalitas instan
Hyperliquid dapat melakukan dua putaran pemungutan suara, dengan satu syarat penting: ia menggunakan kumpulan validator yang sangat ramping, di mana pada awalnya sebenarnya kurang dari 5 entitas yang mengendalikan sebagian besar node validator, jaringan yang berskala terbatas dapat secara signifikan mengurangi overhead komunikasi konsensus BFT.
Namun, jika jumlah node diperluas menjadi puluhan atau ratusan, kompleksitas proses pemungutan suara akan meningkat dengan cepat, karena kompleksitas setiap putaran pemungutan suara sebanding dengan kuadrat jumlah node yang terlibat dalam komunikasi. Solana memiliki ribuan node validator, dan untuk mencapai dua putaran pemungutan suara sambil mempertahankan tingkat desentralisasi yang tinggi, kesulitan teknisnya jauh lebih besar dibandingkan Hyperliquid. Oleh karena itu, Solana perlu melakukan banyak pekerjaan dalam komunikasi jaringan. Beberapa langkah telah disebutkan dalam peta jalan:
Meskipun demikian, Solana masih menghadapi tantangan besar untuk mencapai “decentralisasi tinggi + finalitas dalam milidetik” secara bersamaan. Itulah sebabnya Alpenglow memperkirakan bahwa masih diperlukan lebih dari satu tahun pengembangan, dan diperkirakan akan diluncurkan awal tahun 2026 (semoga demikian).
🔄 Meniru Tiga: Eksekusi Asinkron Jalur
Jalur aliran asinkron HYPERLIQUID
Blockchain tradisional adalah single-threaded, sebuah blok harus dieksekusi dan diverifikasi sepenuhnya sebelum blok berikutnya dapat mulai diproses. Tujuannya adalah untuk menghilangkan ketidakpastian yang ditimbulkan oleh multi-threading, memastikan semua node mendapatkan hasil yang sama dalam urutan yang sama. Namun, kelemahannya adalah membatasi kinerja CPU multi-core modern.
Dan Hyperliquid secara tidak tradisional memperkenalkan multithreading, memisahkan alur kerja menjadi dua jalur paralel yaitu “penyortiran (konsensus)” dan “eksekusi”. Proses eksekusinya adalah sebagai berikut:
Titik waktu T1:
Titik waktu T2 (tempat dimulainya sihir) :
Titik waktu T3 (jalur produksi berjalan terus):
Dalam mode Pipeline ini, inti CPU yang berbeda dapat dimanfaatkan secara efektif. Beberapa inti dapat secara khusus menangani pesan jaringan dan pemungutan suara konsensus (pengurutan), sementara inti lainnya dapat sepenuhnya melakukan perhitungan status (eksekusi), dengan dua jalur pipa yang bekerja secara bersamaan, memaksimalkan efisiensi perangkat keras.
Rencana APE ICM
eksekusi
Namun, mewujudkan eksekusi paralel/asinkron yang aman di rantai terdesentralisasi adalah tantangan rekayasa yang sangat sulit: Untuk memastikan semua node di seluruh dunia mencapai kesepakatan penuh tentang hasil transaksi, semua faktor yang dapat menyebabkan hasil yang berbeda akibat urutan eksekusi yang berbeda harus dihilangkan.
Alasan mengapa skema saluran asinkron dapat berhasil di Hyperliquid adalah karena Hyperliquid sebagai appchain dengan fungsi tunggal, model statusnya sederhana dan jelas (terutama buku pesanan dan posisi pengguna di berbagai pasar perdagangan). Tim pengembang dapat dengan jelas membagi operasi mana yang dapat dilakukan secara paralel, mana yang memiliki ketergantungan, dan merancang saluran yang efisien berdasarkan hal tersebut.
Namun, sebagai rantai umum, ketergantungan dalam transaksi di Solana jauh lebih kompleks dibandingkan dengan sistem order book. Oleh karena itu, untuk mereproduksi kinerja Hyperliquid dalam lingkungan umum, tantangan teknik yang dihadapi Solana jauh lebih berat, memerlukan pengembangan ulang banyak kode, dan tidak dapat dicapai dalam jangka pendek. Oleh karena itu, dalam peta jalan ICM, ini juga hanya bisa dikategorikan sebagai perencanaan jangka menengah. Meskipun demikian, peluncuran APE yang sebenarnya masih harus mengatasi serangkaian tantangan:
🤔 Apakah pertunjukan tiruan ini bisa berhasil?
Berdasarkan analisis di atas, peta jalan Solana ICM sebenarnya adalah sebuah “pertunjukan tiruan” yang mendalam terhadap arsitektur teknologi Hyperliquid. Tim inti Solana berencana untuk meniru semua keahlian andalan Hyperliquid satu per satu, dan kemudian melengkapinya untuk Drift, membantu mereka berkompetisi di pasar DEX melawan Hyperliquid. Namun, saya tidak optimis tentang prospek pertunjukan tiruan ini.
Peningkatan kesulitan teknis secara eksponensial
Keberhasilan Hyperliquid sebagian besar dibangun di atas kondisi bawaan yang menguntungkan:
Melihat Solana, sangat sulit secara teknis untuk mencapai tingkat Hyperliquid sambil mempertahankan universalitas dan desentralisasi dari blockchain publik. Sebagai contoh, konsensus HyperBFT dari Hyperliquid dapat menghasilkan latensi 0,2 detik dengan kurang dari 5 node, sementara Solana harus melampaui batas komunikasi jaringan untuk mencapai latensi yang sama dengan 2000 node; mesin pemesanan Hyperliquid hanya melayani logika bursa mereka sendiri, sementara ACE/BAM Solana harus disesuaikan dengan berbagai protokol DeFi.
Bisa dikatakan, Solana sedang mengejar ketertinggalan Hyperliquid, dan tingkat kesulitannya jauh lebih tinggi dibandingkan dengan yang dialami Hyperliquid saat itu yang “tidak tahu sudah tinggi kemana”. Peta jalan ICM membagi tugas-tugas ini hingga 2027, menunjukkan bahwa pihak resmi juga menyadari bahwa ini bukan pekerjaan yang bisa selesai dalam sehari.
Kontradiksi antara desentralisasi dan efisiensi
Perbedaan lain antara Solana dan Hyperliquid terletak pada tata kelola dan ritme peningkatan. Tim Hyperliquid kecil, keputusan terpusat, dan tidak memiliki pengawasan tata kelola eksternal, sehingga bergerak sangat cepat. Pada bulan Maret tahun ini, ketika Hyperliquid mengalami insiden manipulasi kontrak JELLY, tim dengan cepat mengambil keputusan untuk menghentikan pasar terkait dalam beberapa jam, melindungi keamanan dana, menunjukkan bahwa meskipun “secara politik tidak benar”, keputusan terpusat memang efektif dan berguna pada saat-saat krusial.
Solana sebagai blockchain publik, memiliki yayasan, pengembang inti, dan berbagai pihak di komunitas yang berperan dalam pengambilan keputusan. Proses pembaruan relatif lambat dan konservatif. Misalnya, Firedancer yang sangat dinantikan (klien Solana berkinerja tinggi yang dikembangkan oleh Jump) telah dimulai sejak 2022 hingga sekarang (pertengahan 2025) masih dalam tahap pengujian dan penyempurnaan, belum sepenuhnya diluncurkan; setiap perubahan yang melibatkan konsensus memerlukan waktu lama untuk audit dan pengoperasian testnet. Perubahan dalam perencanaan roadmap ICM bahkan lebih signifikan: harus mengganti algoritma konsensus inti, memperkenalkan eksekusi paralel yang sepenuhnya baru, dan mendistribusikan kekuasaan kunci, yang pasti memiliki kesulitan dan risiko yang lebih tinggi. Dapat diperkirakan, dalam dua atau tiga tahun ke depan, tim Solana perlu secara bertahap melaksanakan pembaruan ini, di mana setiap langkah mungkin menghadapi tantangan teknis yang tidak terduga atau resistensi dari komunitas.
Misalnya, BAM yang diluncurkan oleh Jito, agar benar-benar menguntungkan pengguna, sebagian besar validator harus beralih ke klien yang mendukung BAM. Jika tidak, transaksi pengguna kadang-kadang akan melalui BAM dan kadang-kadang tidak, yang akan menyebabkan pengalaman yang tidak konsisten bahkan celah arbitrase. Masalahnya adalah, Solana tidak dapat memaksa node validator untuk memperbarui klien. Oleh karena itu, meskipun BAM berhasil dikembangkan, kecepatan promosinya juga sulit diprediksi. Jadi, jadwal di ICM hanyalah perencanaan optimis, realisasinya kemungkinan akan ditunda berkali-kali, dan untuk mencapai semua tujuan, mungkin kita harus menunggu hingga tahun monyet dan tahun kuda.
Bahkan jika semuanya berjalan lancar, pada tahun 2027 Solana akan mencapai implementasi ACE dan lainnya, itu hanya “berhasil mengejar ketertinggalan” — mengejar fitur yang sudah disediakan oleh Hyperliquid pada tahun 2023-2024. Dan Hyperliquid sendiri tidak akan berhenti: misalnya, proposal HIP-3 akan diluncurkan pada paruh kedua tahun 2025, yang memungkinkan komunitas untuk secara mandiri meluncurkan pasar kontrak berkelanjutan. Berbagai inovasi akan semakin memperluas cakupan pasar Hyperliquid. Saat Solana akhirnya berhasil mengimplementasikan fitur-fitur yang ada di Hyperliquid sekarang, mungkin Hyperliquid sudah membuka keunggulan baru yang memimpin.
Melampaui persaingan teknologi
Meskipun artikel ini berfokus pada perbandingan antara Solana dan Hyperliquid dalam pertempuran jalur teknologi, kita juga harus melihat bahwa keberhasilan Hyperliquid tidak hanya bergantung pada faktor teknis. Hyperliquid memiliki banyak hal positif dalam operasi dan ekosistemnya:
Melihat jalur DEX Solana, DEX asli Solana seperti Drift saat ini tidak memiliki keunggulan yang jelas dalam desain produk dan mekanisme insentif. Hanya dengan meniru teknologi Hyperliquid dan menyamakan kinerja rantai, jika tidak ada fitur khas yang menyelesaikan masalah pengguna, tidak akan secara otomatis membawa pengguna kembali dalam skala besar, mengingat perpindahan pengguna juga memiliki biaya.
Oleh karena itu, jika hanya meniru langkah Hyperliquid, maka akan selamanya hanya bisa mengikuti dan tertinggal. Peluang nyata dari peta jalan Solana ICM tidak terletak di bidang kontrak berkelanjutan atau buku pesanan. Masih banyak bidang dalam ekosistem Solana yang belum dijelajahi oleh Hyperliquid, seperti peluncuran MEME, protokol pinjaman, dan lain-lain, yang juga dapat memanfaatkan perbaikan yang dibawa oleh ICM untuk menciptakan pengalaman pengguna yang lebih lancar. Jika Solana dapat menginovasi fitur di bidang-bidang ini dan menyelesaikan masalah pengguna, maka bahkan jika di pasar kontrak berkelanjutan tidak dapat segera membalikkan keadaan, tetap saja dapat memperkuat pencapaian visi “pasar modal internet”-nya. Bagaimanapun juga, sekuat apa pun Hyperliquid, itu hanyalah sebuah aplikasi rantai di bidang vertikal, sementara Solana memiliki peta aplikasi yang luas dan beragam, yang merupakan modal terbesarnya untuk jangka panjang.
🏁 Kesimpulan: Meniru itu mudah, melampaui itu sulit
Peta jalan ICM Solana menunjukkan tekad komunitas Solana untuk tidak kalah dan berjuang maju. Dari ACE ke Alpenglow hingga APE, masing-masing terkait dengan fitur khas Hyperliquid, memang ada makna “tiruan yang ditargetkan”.
Namun, meniru itu mudah, melampaui itu sulit. Solana perlu berusaha keras dalam penguasaan teknologi, kolaborasi ekosistem, dan strategi pasar untuk berhasil dalam pertunjukan peniruan ini. Dalam jangka pendek, Solana mungkin dapat meningkatkan pengalaman transaksi di blockchain melalui BAM dan sebagian memulihkan beberapa pengguna. Namun, untuk benar-benar mengguncang posisi terdepan Hyperliquid, mungkin dibutuhkan waktu yang lebih lama dan lebih banyak inovasi.
Setidaknya saat ini, Hyperliquid terus memperluas wilayahnya dengan keunggulan pangsa pasarnya, sementara Solana masih dalam proses mempercepat modifikasi mesinnya, dan mungkin proses modifikasi ini akan berlangsung cukup lama.
Peta jalan ICM menggambarkan masa depan yang menggairahkan, tetapi apakah bisa mencapai “menyalip di tikungan”, masih perlu diuji oleh waktu. Sebagai pengguna biasa, kita dapat berharap bahwa persaingan ini akan membawa pengalaman transaksi on-chain yang lebih baik—terlepas dari siapa yang akhirnya menang, pengguna adalah pihak yang diuntungkan.