Tantangan Baru Solana: Mencari Kualitas Transaksi yang Lebih Tinggi
Solana dikenal karena kecepatan tinggi dan volume transaksi yang besar, tetapi apakah itu berarti bahwa ia telah mencapai kesempurnaan? Ketika kita melihat transaksi-transaksi ini dengan cermat, kita tidak bisa tidak bertanya: Apakah semuanya menciptakan nilai yang nyata?
Faktanya, banyak transaksi di Solana tidak berasal dari permintaan yang nyata, melainkan dari arbitrase frekuensi tinggi yang memanfaatkan perbedaan informasi dalam milidetik untuk mendapatkan keuntungan. "Trader beracun" ini memanfaatkan keunggulan teknis dengan meningkatkan biaya Gas saat pembuat pasar akan membatalkan pesanan, memastikan bahwa transaksi mereka diprioritaskan untuk dipaketkan, sehingga menyelesaikan arbitrase dan menyebabkan kerugian bagi pembuat pasar. Untuk menutupi kerugian ini, pembuat pasar terpaksa memperlebar spread beli dan jual, akhirnya biaya tersebut ditanggung oleh pengguna biasa.
Solana selalu memiliki visi untuk mewujudkan buku pesanan di rantai untuk menggantikan bursa terpusat. Namun, keberadaan "trader beracun" menjadi penghalang untuk mencapai tujuan ini. Inilah tantangan baru yang dihadapi Solana: volume transaksi tidak sama dengan likuiditas. Pasar yang benar-benar sehat tidak membutuhkan lebih banyak transaksi, tetapi transaksi yang lebih berkualitas.
Bagaimana cara menghilangkan transaksi beracun dan melindungi likuiditas dengan lebih baik?
Dalam sistem saat ini, karena mekanisme lelang periodik konsensus Solana, pihak yang makan order sebenarnya memiliki hak prioritas, yang menyebabkan dampak MEV yang merugikan terhadap keadilan pasar.
Di bawah mekanisme konsensus yang ada di Solana, transaksi dalam setiap periode (Slot) diurutkan berdasarkan biaya Gas prioritas yang dibayarkan, dengan transaksi yang menawarkan harga tertinggi dieksekusi terlebih dahulu. Lelang ini dilakukan setiap 400 milidetik.
Dalam proses ini, pembuat pasar perlu sering menyesuaikan penawaran, membatalkan pesanan, dan mengajukan pesanan baru untuk menyesuaikan dengan perubahan harga pasar. Sementara itu, pemakan pesanan, terutama arbitrase frekuensi tinggi, terus memantau perbedaan harga, dan segera melakukan transaksi begitu menemukan peluang. Oleh karena itu, para arbitrase dapat mendapatkan keuntungan dengan membayar biaya yang lebih tinggi untuk menyelesaikan transaksi sebelum pesanan dibatalkan, yang menyebabkan pembuat pasar sering mengalami kerugian.
Untuk bursa perdagangan terdesentralisasi dengan buku pesanan, urutan yang ideal seharusnya: dengan fluktuasi harga, terlebih dahulu melaksanakan semua pembatalan, kemudian melaksanakan pesanan baru, dan terakhir melaksanakan transaksi. Namun, mekanisme konsensus Solana saat ini tidak dapat mencapai hal ini pada tingkat mikro.
Ada masalah serupa dalam penawaran oracle. Idealnya, harga oracle harus diperbarui terlebih dahulu sebelum mengeksekusi transaksi yang bergantung pada harga tersebut. Namun, dalam interval 400 milidetik saat ini, jika pasar bergejolak, transaksi mungkin tetap dieksekusi berdasarkan harga awal.
Untuk protokol pinjaman, praktik terbaik adalah menambah margin terlebih dahulu sebelum melakukan likuidasi.
Oleh karena itu, solusi yang paling ideal adalah yang memungkinkan berbagai protokol untuk mengurutkan transaksi sesuai kebutuhan, inilah yang selalu ditekankan oleh Solana tentang Eksekusi yang Dikendalikan Aplikasi (Application-Controlled Execution, ACE).
Marketplace Perakitan Blok (, BAM ) adalah solusi yang diajukan oleh Solana untuk masalah ini.
BAM membangun lapisan urut, atau yang dikenal sebagai lapisan pra-pemrosesan, antara aplikasi di rantai Solana dan jaringan utama. Ini memanfaatkan Trusted Execution Environments (TEEs ) untuk membangun kotak pasir privasi, di dalam kotak pasir melakukan urutan transaksi berdasarkan aturan urut yang telah ditentukan sebelumnya atau prinsip First In First Out (FIFO ).
Mekanisme ini dapat melayani buku pesanan, bursa kontrak berjangka, dan protokol kolam gelap dengan lebih baik.
Mode Urut Transaksi BAM
BAM mendukung tiga mode operasi:
Mode default Solana
Mode Block-Engine: saat ini inti dari beberapa solusi MEV, terutama berdasarkan mekanisme lelang
Mode BAM: Validator mengurutkan secara ketat sesuai prinsip FIFO.
Inti dari mode BAM mencakup hal-hal berikut:
Lingkungan Eksekusi Tepercaya ( TEEs ): Menggunakan TEEs untuk membangun lingkungan privasi untuk mengurutkan transaksi, memastikan keadilan.
Sistem Plugin: Melalui sistem plugin, BAM memungkinkan aplikasi untuk membangun logika pengurutan transaksi kustom, tetapi pengurutan ini berdasarkan aturan yang telah ditetapkan sebelumnya, bukan keputusan sembarangan dari node.
Sistem plugin direncanakan untuk mewujudkan pengurutan transaksi yang kompleks, sambil mempertahankan jaminan keamanan lingkungan TEE. Saat ini, sistem tersebut masih dalam tahap pengembangan awal.
Aplikasi Spesifik BAM
Perlindungan Penyelesaian Pinjaman: untuk perjanjian pinjaman, setelah risiko penyelesaian terdeteksi, lakukan tindakan tambahan jaminan terlebih dahulu, kemudian lakukan pemeriksaan penyelesaian.
Kombinasi perdagangan atomik: Untuk bursa terdesentralisasi, pertama perbarui harga oracle, lalu lakukan perdagangan yang bergantung pada harga tersebut. Untuk bursa kontrak, juga dapat menyelesaikan derivatif terkait dalam jendela waktu yang sama.
Perlindungan terhadap Fluktuasi Harga: untuk bursa terdesentralisasi, mendeteksi pesanan besar yang tidak normal, membaginya menjadi bagian-bagian kecil untuk dieksekusi secara bertahap, memberikan waktu reaksi yang cukup kepada pasar, menghindari likuidasi beruntun atau arbitrase yang dapat menyebabkan konsekuensi serius.
Perlindungan Pembuat Pasar: Saat terjadi peristiwa mendadak, dapat menyelesaikan pembatalan pesanan, pembaruan harga oracle, dan pemasangan kembali oleh pembuat pasar dalam milidetik, menghindari arbitrase jahat, dan mengurangi selisih harga.
Dengan penerapan BAM, pengalaman transaksi Solana akan meningkat secara signifikan, membuat pengalaman aplikasi mainnet-nya lebih dekat dengan bursa terpusat.
Secara keseluruhan, BAM membawa verifiabilitas, perlindungan privasi, dan pemrograman ke dalam proses pemrosesan transaksi Solana. Ini memungkinkan pengembang untuk membangun buku pesanan harga terbatas pusat, bursa kontrak berkelanjutan, kolam gelap, serta infrastruktur keuangan lainnya yang memerlukan kontrol urutan, pelaksanaan deterministik, dan perlindungan privasi, sehingga mendorong inovasi dan pengembangan ekosistem Solana.
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.
7 Suka
Hadiah
7
8
Posting ulang
Bagikan
Komentar
0/400
metaverse_hermit
· 3jam yang lalu
Parasit benar-benar banyak jebakan siapa yang tidak baik
Lihat AsliBalas0
DataChief
· 22jam yang lalu
suckers selalu rugi ya Siapa yang bisa menahan kerugian arbitrase
Lihat AsliBalas0
ChainComedian
· 22jam yang lalu
gas biaya naik, tidak bisa makan gratis lagi
Lihat AsliBalas0
RadioShackKnight
· 22jam yang lalu
Aduh, ini kan harga yang harus dibayar untuk perkembangan.
Lihat AsliBalas0
BlockchainGriller
· 22jam yang lalu
Siapa yang masih memperdagangkan sol?
Lihat AsliBalas0
SchroedingersFrontrun
· 22jam yang lalu
Siapa yang membeli, siapa yang rugi.
Lihat AsliBalas0
LayerHopper
· 22jam yang lalu
Operasi klasik Dianggap Bodoh
Lihat AsliBalas0
MoneyBurner
· 22jam yang lalu
Hehe, masih memimpin di copy trading Kupon Klip pro bull, siapa yang bukan mengandalkan kerja keras untuk menghasilkan uang.
Solana meluncurkan BAM: tantangan dan solusi baru untuk meningkatkan kualitas transaksi
Tantangan Baru Solana: Mencari Kualitas Transaksi yang Lebih Tinggi
Solana dikenal karena kecepatan tinggi dan volume transaksi yang besar, tetapi apakah itu berarti bahwa ia telah mencapai kesempurnaan? Ketika kita melihat transaksi-transaksi ini dengan cermat, kita tidak bisa tidak bertanya: Apakah semuanya menciptakan nilai yang nyata?
Faktanya, banyak transaksi di Solana tidak berasal dari permintaan yang nyata, melainkan dari arbitrase frekuensi tinggi yang memanfaatkan perbedaan informasi dalam milidetik untuk mendapatkan keuntungan. "Trader beracun" ini memanfaatkan keunggulan teknis dengan meningkatkan biaya Gas saat pembuat pasar akan membatalkan pesanan, memastikan bahwa transaksi mereka diprioritaskan untuk dipaketkan, sehingga menyelesaikan arbitrase dan menyebabkan kerugian bagi pembuat pasar. Untuk menutupi kerugian ini, pembuat pasar terpaksa memperlebar spread beli dan jual, akhirnya biaya tersebut ditanggung oleh pengguna biasa.
Solana selalu memiliki visi untuk mewujudkan buku pesanan di rantai untuk menggantikan bursa terpusat. Namun, keberadaan "trader beracun" menjadi penghalang untuk mencapai tujuan ini. Inilah tantangan baru yang dihadapi Solana: volume transaksi tidak sama dengan likuiditas. Pasar yang benar-benar sehat tidak membutuhkan lebih banyak transaksi, tetapi transaksi yang lebih berkualitas.
Bagaimana cara menghilangkan transaksi beracun dan melindungi likuiditas dengan lebih baik?
Dalam sistem saat ini, karena mekanisme lelang periodik konsensus Solana, pihak yang makan order sebenarnya memiliki hak prioritas, yang menyebabkan dampak MEV yang merugikan terhadap keadilan pasar.
Di bawah mekanisme konsensus yang ada di Solana, transaksi dalam setiap periode (Slot) diurutkan berdasarkan biaya Gas prioritas yang dibayarkan, dengan transaksi yang menawarkan harga tertinggi dieksekusi terlebih dahulu. Lelang ini dilakukan setiap 400 milidetik.
Dalam proses ini, pembuat pasar perlu sering menyesuaikan penawaran, membatalkan pesanan, dan mengajukan pesanan baru untuk menyesuaikan dengan perubahan harga pasar. Sementara itu, pemakan pesanan, terutama arbitrase frekuensi tinggi, terus memantau perbedaan harga, dan segera melakukan transaksi begitu menemukan peluang. Oleh karena itu, para arbitrase dapat mendapatkan keuntungan dengan membayar biaya yang lebih tinggi untuk menyelesaikan transaksi sebelum pesanan dibatalkan, yang menyebabkan pembuat pasar sering mengalami kerugian.
Untuk bursa perdagangan terdesentralisasi dengan buku pesanan, urutan yang ideal seharusnya: dengan fluktuasi harga, terlebih dahulu melaksanakan semua pembatalan, kemudian melaksanakan pesanan baru, dan terakhir melaksanakan transaksi. Namun, mekanisme konsensus Solana saat ini tidak dapat mencapai hal ini pada tingkat mikro.
Ada masalah serupa dalam penawaran oracle. Idealnya, harga oracle harus diperbarui terlebih dahulu sebelum mengeksekusi transaksi yang bergantung pada harga tersebut. Namun, dalam interval 400 milidetik saat ini, jika pasar bergejolak, transaksi mungkin tetap dieksekusi berdasarkan harga awal.
Untuk protokol pinjaman, praktik terbaik adalah menambah margin terlebih dahulu sebelum melakukan likuidasi.
Oleh karena itu, solusi yang paling ideal adalah yang memungkinkan berbagai protokol untuk mengurutkan transaksi sesuai kebutuhan, inilah yang selalu ditekankan oleh Solana tentang Eksekusi yang Dikendalikan Aplikasi (Application-Controlled Execution, ACE).
Marketplace Perakitan Blok (, BAM ) adalah solusi yang diajukan oleh Solana untuk masalah ini.
BAM membangun lapisan urut, atau yang dikenal sebagai lapisan pra-pemrosesan, antara aplikasi di rantai Solana dan jaringan utama. Ini memanfaatkan Trusted Execution Environments (TEEs ) untuk membangun kotak pasir privasi, di dalam kotak pasir melakukan urutan transaksi berdasarkan aturan urut yang telah ditentukan sebelumnya atau prinsip First In First Out (FIFO ).
Mekanisme ini dapat melayani buku pesanan, bursa kontrak berjangka, dan protokol kolam gelap dengan lebih baik.
Mode Urut Transaksi BAM
BAM mendukung tiga mode operasi:
Inti dari mode BAM mencakup hal-hal berikut:
Sistem plugin direncanakan untuk mewujudkan pengurutan transaksi yang kompleks, sambil mempertahankan jaminan keamanan lingkungan TEE. Saat ini, sistem tersebut masih dalam tahap pengembangan awal.
Aplikasi Spesifik BAM
Perlindungan Penyelesaian Pinjaman: untuk perjanjian pinjaman, setelah risiko penyelesaian terdeteksi, lakukan tindakan tambahan jaminan terlebih dahulu, kemudian lakukan pemeriksaan penyelesaian.
Kombinasi perdagangan atomik: Untuk bursa terdesentralisasi, pertama perbarui harga oracle, lalu lakukan perdagangan yang bergantung pada harga tersebut. Untuk bursa kontrak, juga dapat menyelesaikan derivatif terkait dalam jendela waktu yang sama.
Perlindungan terhadap Fluktuasi Harga: untuk bursa terdesentralisasi, mendeteksi pesanan besar yang tidak normal, membaginya menjadi bagian-bagian kecil untuk dieksekusi secara bertahap, memberikan waktu reaksi yang cukup kepada pasar, menghindari likuidasi beruntun atau arbitrase yang dapat menyebabkan konsekuensi serius.
Perlindungan Pembuat Pasar: Saat terjadi peristiwa mendadak, dapat menyelesaikan pembatalan pesanan, pembaruan harga oracle, dan pemasangan kembali oleh pembuat pasar dalam milidetik, menghindari arbitrase jahat, dan mengurangi selisih harga.
Dengan penerapan BAM, pengalaman transaksi Solana akan meningkat secara signifikan, membuat pengalaman aplikasi mainnet-nya lebih dekat dengan bursa terpusat.
Secara keseluruhan, BAM membawa verifiabilitas, perlindungan privasi, dan pemrograman ke dalam proses pemrosesan transaksi Solana. Ini memungkinkan pengembang untuk membangun buku pesanan harga terbatas pusat, bursa kontrak berkelanjutan, kolam gelap, serta infrastruktur keuangan lainnya yang memerlukan kontrol urutan, pelaksanaan deterministik, dan perlindungan privasi, sehingga mendorong inovasi dan pengembangan ekosistem Solana.