Pertunjukan Tiruan Solana: Bisakah Mengejar Hyperliquid?

Baru-baru ini, anggota penting ekosistem Solana, termasuk Yayasan Solana, Anza, Jito Labs, dan lainnya, telah bersama-sama merilis peta jalan teknologi yang berjudul "(Internet Capital Markets, ICM)". Ide dasar dari peta jalan ini adalah "(Application Controlled Execution, ACE)", yang bertujuan untuk memberikan aplikasi di blockchain hak urut perdagangan mandiri dalam milidetik, menciptakan "Wall Street di Blockchain" yang terdesentralisasi.

Menariknya, setelah membaca seluruh peta jalan, meskipun tidak secara langsung menyebutkan Hyperliquid, desain di dalamnya hampir di setiap tempat ditujukan untuk kekuatan Hyperliquid. Ini seperti Solana yang berkata: "Apa yang kamu punya di Hyperliquid, kami juga ingin memilikinya, dan kami akan melakukannya dengan lebih baik!"

Hyperliquid menguasai pasar kontrak perpetual di blockchain, dengan volume perdagangan mencapai sekitar 65% dari keseluruhan pasar perpetual terdesentralisasi. Menghadapi pesaing seperti itu, Solana jelas tidak ingin tertinggal oleh pendatang baru, oleh karena itu meluncurkan peta jalan ICM ini.

Jadi, apa sebenarnya yang terjadi dengan "pertunjukan tiruan" ini? Apakah Solana benar-benar dapat mengejar atau bahkan melampaui Hyperliquid? Mari kita dalami topik ini.

Latar Belakang dan Isi ICM

Siapa yang memimpin perubahan ini?

Para pemain utama ekosistem Solana yang terlibat dalam penyusunan peta jalan adalah:

• Solana Foundation/Labs: "Ayah kandung" Solana, bertanggung jawab untuk koordinasi keseluruhan dan pengembangan protokol inti.

• Anza: Perusahaan pengembang yang didirikan oleh mantan anggota Solana Labs, mirip dengan ConsenSys di Ethereum. Mereka mengambil banyak pekerjaan inti dalam peta jalan kali ini, seperti protokol konsensus baru Alpenglow.

• Jito Labs: Penyedia infrastruktur MEV di Solana, memiliki pengaruh besar, hampir mengendalikan "kekuasaan hidup dan mati" dari semua aliran MEV di Solana. Kali ini mereka memimpin penyediaan Block Assembly Marketplace (BAM) dan solusi pengurutan transaksi lainnya.

• Multicoin Capital: lembaga investasi kripto yang terkenal, juga merupakan pendukung awal Solana. Karena memegang sejumlah besar SOL dan hak atas proyek ekosistem, mereka juga 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 antar node validasi Solana.

• Drift: Proyek DEX kontrak berkelanjutan terkemuka di Solana. Sebelumnya, Drift menggunakan model pencocokan off-chain, dan saat menghadapi Hyperliquid yang sepenuhnya on-chain, tampaknya agak kesulitan. Kali ini, terlibat dalam penyusunan peta jalan, jelas berharap dapat memanfaatkan peningkatan dasar untuk bangkit kembali.

masalah inti yang harus diselesaikan

Peta jalan ini berfokus pada perbaikan struktur mikro pasar, secara sederhana, mekanisme perdagangan on-chain saat ini tidak cukup ramah bagi pembuat pasar, yaitu Taker yang secara aktif memulai perdagangan mendapat keuntungan, sementara Market Maker yang menunggu order untuk dieksekusi( justru menderita kerugian. Ini karena Taker sering kali menguasai informasi terbaru, dan secara aktif meningkatkan biaya transaksi untuk memastikan perdagangan mereka dieksekusi lebih dahulu, sementara Maker sering kali tidak sempat membatalkan order, terpaksa mengeksekusi pada harga yang merugikan.

Beberapa arbiter frekuensi tinggi akan memanfaatkan ketidaksamaan ini untuk melancarkan serangan "lalu lintas beracun". Misalnya, jika harga di rantai belum diperbarui, tetapi harga di luar rantai sudah berubah, arbiter dapat mengambil pesanan pembuat pasar dengan harga lama, membuat pembuat pasar menanggung kerugian. Hasilnya adalah Maker, untuk melindungi dirinya sendiri, harus memperlebar selisih harga beli dan jual, atau mengurangi jumlah pesanan, yang mengakibatkan penurunan likuiditas pasar secara keseluruhan.

Peta jalan ICM bertujuan untuk menyeimbangkan pola ini, menarik likuiditas berkualitas tinggi kembali ke dalam 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 buku pesanan lebih mudah digunakan, dan mengurangi gangguan MEV yang merugikan. Secara spesifik mencakup:

• Marketplace Block Assembly Jito Labs)BAM( modul diluncurkan di mainnet. Makna modul ini adalah untuk menyediakan sistem eksternal sementara sebelum peluncuran Ultimate ACE)Application Controlled Execution(, memungkinkan kontrak pintar di Solana memiliki hak urut transaksi secara mandiri.

• Tim Anza mengoptimalkan "masuk ke Slot yang sama" untuk meningkatkan tingkat keberhasilan, sehingga mengurangi slippage dan kerugian MEV.

Perbaikan ini diperkirakan akan dilaksanakan secara bertahap antara Juli hingga September 2025.

Tengah )3-9 bulan (: Memperkenalkan jaringan cepat khusus dan konsensus baru, secara signifikan mengurangi latensi, meningkatkan throughput:

• Menerapkan jaringan serat optik khusus DoubleZero, menyediakan komunikasi berkecepatan tinggi dengan hampir tidak ada jitter dan pengurangan latensi hingga 100ms untuk validator.

• Meluncurkan protokol konsensus Alpenglow, mengurangi waktu konfirmasi akhir dari sekitar 12,8 detik menjadi sekitar 0,15 detik.

• Mengembangkan Eksekusi Program Asinkron ) Asynchronous Program Execution, APE (, mengurangi blokir konsensus pada eksekusi transaksi.

Jangka Panjang )9-30 Bulan (: Melakukan upgrade revolusioner pada arsitektur inti Solana, dengan target untuk mencapainya sekitar tahun 2027:

• Banyak Pemimpin Paralel )Multiple Concurrent Leaders, MCL(: Memungkinkan beberapa validator untuk mengusulkan transaksi secara bersamaan dalam pipeline masing-masing, kemudian mengurutkan dan menggabungkan blok paralel ini berdasarkan biaya prioritas. Ini dapat memperlemah monopoli satu pengemas, meningkatkan ketahanan terhadap sensor.

• Aplikasi asli dengan kontrol eksekusi )Application Controlled Execution, ACE( fitur: Secara nyata memberikan kekuasaan kepada kontrak pintar di atas rantai untuk mengontrol urutan eksekusi transaksi.

Analisis sampai di sini, pengajuan peta jalan ICM kali ini, cerita di baliknya seharusnya seperti ini: DEX lama Drift di Solana telah dikalahkan oleh pendatang baru Hyperliquid dengan pengalaman "Binance di atas rantai" yang sangat baik. Drift sendiri tidak mampu bersaing, terpaksa meminta bantuan dari "raksasa" seperti Solana Labs, Anza, Jito, dan lainnya. "Raksasa" tersebut mengusulkan rencana perombakan teknis ICM, mengklaim akan mereplikasi dan melengkapi keahlian utama Hyperliquid untuk Drift, membantu mereka kembali bersaing di pasar DEX. Namun, "raksasa" juga mengatakan bahwa perombakan teknis kali ini sangat sulit, sehingga mereka membagi rencana teknis menjadi strategi tiga langkah, dan perlengkapan yang bisa diberikan kepada Drift dalam waktu dekat hanya adalah BAM dari Jito, agar Drift bisa bertahan dan dibandingkan dengan Hyperliquid.

Setelah menetapkan latar cerita, di bab-bab selanjutnya, kita akan menganalisis secara rinci keterampilan apa saja yang ditiru dan direplikasi oleh ICM dari Hyperliquid.

Meniru Satu: Mekanisme Urutan Transaksi

Masalahnya: Seperti yang disebutkan sebelumnya, rantai saat ini condong ke pihak pengambil, sementara pembuat harus menanggung "aliran beracun". Pengguna yang secara aktif mengambil pesanan dapat, berdasarkan harga terbaru di luar rantai, segera memulai transaksi terhadap pesanan yang terdaftar di rantai, dan dengan meningkatkan biaya transaksi, mereka dapat mendapatkan eksekusi prioritas, sementara pembuat pasar sering kali tidak dapat memperbarui atau membatalkan pesanan dengan cepat. Hasilnya, pembuat pasar harus memperlebar selisih harga, atau bahkan mencabut likuiditas, yang membuat kedalaman pasar menjadi lebih buruk.

) Solusi Ultimatum ICM: Aplikasi Eksekusi Terkontrol ###ACE(

Peta jalan ICM mengusulkan konsep ACE)Application Controlled Execution(, yaitu mendelegasikan hak urutan transaksi kepada aplikasi di setiap rantai, di mana aplikasi sendiri menentukan bagaimana transaksi yang terkait dengan aplikasi tersebut diurutkan dan dieksekusi. Sebagai contoh, di masa depan saat ACE diimplementasikan di Solana, kontrak DeFi dapat menerapkan aturan urutan transaksi kustom berikut:

• Pembaruan harga Oracle disisipkan: Aplikasi DeFi dapat menyisipkan transaksi untuk mendapatkan harga terbaru dari oracle sebelum mencocokkan transaksi besar, memastikan order dicocokkan berdasarkan harga yang wajar dan terbaru, serta mencegah penawaran pembuat pasar berdasarkan harga yang ketinggalan zaman agar tidak dieksploitasi.

• Eksekusi pembatalan pesanan yang diprioritaskan: Aplikasi dapat mengatur "permintaan pembatalan pesanan" untuk diprioritaskan sebelum eksekusi "transaksi baru", memberikan kesempatan kepada maker untuk menarik kembali pesanan yang tertunda saat kondisi pasar tidak menguntungkan.

• Lelang di bagian belakang tim: Misalnya, setelah munculnya pesanan beli besar yang mendorong harga naik, aplikasi DeFi akan "segera" mengeluarkan kesempatan untuk dilelang, siapa yang bersedia mengembalikan keuntungan terbesar kepada protokol ) atau pengguna (, protokol DeFi akan membiarkan transaksi mereka dieksekusi setelah pesanan besar. Aplikasi DeFi dapat mengembalikan pendapatan lelang kepada pengguna, sehingga mengubah aliran MEV beracun menjadi pendapatan yang baik.

) BAM JITO: skema transisi

Sebelum ACE resmi diluncurkan, Jito Labs meluncurkan solusi transisi yang disebut Block Assembly Marketplace ###BAM(. Alur kerja BAM adalah:

1. Pengguna mengirim transaksi ke node yang menjalankan perangkat lunak BAM ) daripada langsung ke Leader saat ini (.

2. Node BAM mengumpulkan transaksi lokal dan menjalankan berbagai plugin ) plugin ( untuk melakukan pengurutan ulang paket transaksi ) Bundle ( di bawah perlindungan privasi ). Plugin dijalankan dalam lingkungan TEE yang aman, menyembunyikan konten transaksi dari pihak luar 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.

3. Bundle transaksi yang telah diurutkan kemudian dikirim ke Pemimpin Solana untuk dikemas ke dalam blockchain.

BAM dapat dianggap sebagai ladang percobaan sebelum ACE di blockchain, secara fungsi sangat mendekati ACE yang sempurna, hanya saja ia berjalan di jaringan independen di luar, bukan di dalam protokol rantai utama Solana.

Perlu dicatat bahwa Jito sebelumnya hanya menyediakan infrastruktur untuk ekstraksi MEV ) seperti Jito Block Engine (, yang model bisnisnya adalah menciptakan peluang bagi arbitrase dan membagikan keuntungan dengan mengoptimalkan urutan transaksi. Ini dalam beberapa hal adalah "mata panah" yang berdiri di sisi berlawanan dari pengguna biasa dan yang dieksploitasi. Namun, Jito pada awal 2024 menutup fungsi mempool publik ) untuk robot arbitrase ( guna mengurangi eksternalitas negatif seperti serangan sandwich. Tindakan ini menunjukkan bahwa komunitas Solana cenderung untuk menekan MEV yang merugikan dan menjaga keadilan pengguna.

Peluncuran BAM semakin sejalan dengan pemikiran ini: pada dasarnya, ia mengubah mekanisme pemesanan yang sebelumnya 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, dan 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 menghasilkan keuntungan dari biaya plugin.

) belajar dari HYPERLIQUID

Pendekatan ACE/BAM di atas sebenarnya dapat dianggap sebagai upaya untuk mengejar mekanisme pencocokan di Hyperliquid. Hyperliquid adalah sebuah rantai khusus ###Appchain(, yang secara alami ditujukan untuk layanan DEX. Selain itu, HLP Vault yang dikelola oleh Hyperliquid secara resmi sebenarnya adalah salah satu pembuat pasar terbesar di platform tersebut, sehingga tidak sulit untuk memahami bahwa aturan rantai Hyperliquid lebih condong kepada penyedia likuiditas, yang telah menerapkan banyak desain perlindungan bagi pembuat pasar di tingkat rantai, seperti:

• Prioritas perlindungan bagi pihak yang memasang order: pembatalan order dan hanya melakukan order maker diproses lebih dulu, untuk menghindari dealer yang tidak tahu berisiko terkena transaksi yang merugikan. "Eksekusi pembatalan prioritas" yang disebutkan oleh Solana ACE telah 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 pemesanan yang dicocokkan, sistem akan menarik harga oracle terbaru untuk mengevaluasi margin kedua belah pihak, memastikan tidak ada risiko yang disebabkan oleh keterlambatan harga. Ini mirip dengan ACE yang menyisipkan pembaruan oracle sebelum pelaksanaan transaksi.

• Perlindungan transaksi sendiri: Jika alamat yang sama membeli dan menjual secara bersamaan, Hyperliquid secara otomatis membatalkan daripada mencocokkan, untuk mencegah manipulasi 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 satu rantai khusus. Solana sekarang berharap untuk menyalin efek tersebut dengan menggunakan rantai umum dan plugin modular------yaitu agar setiap aplikasi memiliki kontrol yang serupa dengan Hyperliquid dalam pengurutan transaksi.

Meniru Dua: Finalitas Instan

) Perbandingan konsensus yang ada

Solana saat ini menggunakan Tower BFT, konfirmasi dan finalitas bersifat probabilistik dan progresif: satu blok yang mendapatkan 2/3 suara dianggap sebagai "konfirmasi ### Confirmed (", tetapi perlu akumulasi sekitar 32 blok berikutnya ) yang biasanya memakan waktu sekitar 13 detik ( untuk diikat sebagai "finalisasi ) Finalized (". Untuk beberapa aplikasi ) seperti perdagangan frekuensi tinggi (, waktu konfirmasi final sekitar sepuluh detik masih terlalu lama.

HyperBFT adalah algoritma konsensus yang dikembangkan sendiri oleh Hyperliquid, terinspirasi oleh konsensus HotStuff, menggunakan dua putaran pemungutan suara untuk mengkonfirmasi blok, mencapai "finalitas instan".

• Putaran pertama: Prabola ) Prevote (: Validator akan melakukan verifikasi cepat setelah menerima blok kandidat yang disiarkan oleh Proposer. Jika verifikasi berhasil, setiap validator akan memberikan satu suara "prabola" ) Prevote (, dan menyebarkannya ke seluruh jaringan. Suara ini mewakili: "Saya sudah melihatnya secara awal, blok ini tidak ada masalah."

• Putaran kedua: Pre-commit ) Precommit (: Setelah seorang validator mengumpulkan Prevote dari lebih dari dua pertiga validator untuk blok kandidat yang sama, ia memperoleh kepercayaan yang cukup bahwa sebagian besar anggota jaringan menyetujui blok ini. Oleh karena itu, validator tersebut akan memberikan suara "pre-commit" yang lebih berpengaruh ) Precommit (, dan