Solana sudah cukup cepat, volume cukup besar. Lalu apakah itu benar-benar "cukup"?
Ketika kita melihat transaksi-transaksi tersebut, ada satu pertanyaan yang selalu ada: Apakah transaksi-transaksi ini benar-benar menciptakan nilai?
Transaksi besar pada Solana tidak berasal dari permintaan transaksi yang nyata, melainkan dari para arbitrase frekuensi tinggi yang memanfaatkan perbedaan informasi dalam millisecond untuk mendapatkan keuntungan. Para "trader beracun" (Toxic-takers) ini memanfaatkan keunggulan teknologi, dengan meningkatkan Gas saat pembuat pasar (Maker) akan membatalkan order, sehingga transaksi mereka dapat diprioritaskan untuk dibundel, menyelesaikan arbitrase dan membuat pembuat pasar menanggung kerugian. Untuk menutupi kerugian, pembuat pasar hanya dapat memperlebar selisih harga beli dan jual.
Akhirnya, pengguna biasa yang membayar untuk ini. Solana selalu memiliki impian untuk mewujudkan buku pesanan di blockchain, menggantikan CEX. Namun, dengan cara ini, "trader beracun" menjadi hambatan untuk mewujudkan impian tersebut. Inilah tantangan baru yang dihadapi Solana: volume ≠ likuiditas. Pasar yang benar-benar sehat bukanlah tentang lebih banyak perdagangan, tetapi perdagangan yang lebih baik.
Bagaimana cara menghapus transaksi beracun untuk melindungi likuiditas dengan lebih baik?
Dalam sistem saat ini, pemakan (Takers) memiliki hak prioritas sebenarnya karena mekanisme lelang periodik konsensus Solana, yang membuat pengaruh MEV yang merugikan memengaruhi keadilan pasar.
Bagaimana cara memahaminya?
Dalam konsensus Solana saat ini, setiap periode Slot, transaksi diurutkan berdasarkan biaya Gas yang dibayar. Siapa yang menawar lebih tinggi, transaksi mereka akan dieksekusi terlebih dahulu. Lelang ini bersifat periodik, setiap 400 milidetik satu Slot.
Dalam proses ini, pembuat pasar perlu sering menyesuaikan tawaran, membatalkan pesanan, dan mengajukan ulang pesanan. Saat harga pasar berubah, perlu segera diperbarui.
Dan para pemakan pesanan (Taker), terutama para arbitrase frekuensi tinggi, memantau perbedaan harga dan segera melakukan transaksi begitu mereka menemukan kesempatan. Oleh karena itu, para arbitrase dapat menyelesaikan transaksi dengan membayar biaya yang lebih tinggi untuk mengalahkan pembatalan pesanan. Hal ini menyebabkan pembuat pasar sering "diserang" dan menanggung kerugian.
Untuk buku pesanan DEX, urutan ideal seharusnya adalah, seiring dengan fluktuasi harga, pertama-tama mengeksekusi semua pembatalan, kemudian mengeksekusi pesanan baru, dan terakhir mengeksekusi transaksi. Ini adalah sesuatu yang saat ini tidak dapat dicapai oleh konsensus Solana di tingkat mikro.
Dan di sisi penawaran oracle juga sama, situasi ideal adalah memperbarui harga oracle terlebih dahulu, sebelum mengeksekusi transaksi yang bergantung pada harga tersebut. Namun, dalam interval 400 milidetik saat ini, pasar mungkin mengalami fluktuasi yang tajam, yang menyebabkan transaksi tetap dilakukan berdasarkan harga awal.
Untuk protokol pinjaman, sebaiknya terlebih dahulu menambah margin, kemudian melakukan likuidasi.
Jadi, sebaiknya ada cara yang memungkinkan berbagai protokol untuk mengurutkan transaksi sesuai kebutuhan, yaitu ACE (Application-Controlled Execution) yang selalu ditekankan oleh Solana.
BAM (Block Assembly Marketplace, pasar perakitan blok) adalah jawaban Solana.
BAM di jaringan Solana membangun lapisan pengurutan, atau yang disebut lapisan pra-pemrosesan, antara aplikasi dan mainnet.
Memanfaatkan Lingkungan Eksekusi Tepercaya (Trusted Execution Environments, TEEs) untuk membangun kotak pasir privasi, di dalam kotak pasir melakukan pengurutan transaksi berdasarkan aturan pengurutan yang telah ditentukan sebelumnya, atau FIFO (First In First Out).
Melayani buku pesanan (CLOBs), bursa kontrak berjangka (Perpetual Exchanges), dan protokol kolam gelap (Dark Pools) dengan lebih baik.
Solana biasanya membandingkan pengemasan transaksi dengan mode BAM
Bagaimana memahami BAM yang membangun lapisan pengurutan antara aplikasi Solana dan mainnet? Mari kita mulai dengan perbandingan yang intuitif.
Proses perdagangan Solana yang normal,
1）Pengguna mengonfirmasi transaksi di dompet.
2）Mengirim transaksi ke node RPC,
3）RPC mengirimkan ke node Leader Solana mainnet dalam periode Slot saat ini,
4）Leader mengumpulkan transaksi dari pool transaksi, mengurutkan, mengemas menjadi blok untuk disiarkan,
5）Pemungutan suara node lainnya.
Jika suatu aplikasi menghubungkan BAM, alur transaksi adalah sebagai berikut,
1）Pengguna mengonfirmasi transaksi di dompet,
2）Transaksi dikirim ke node RPC,
3）Transaksi dipindahkan ke jaringan BAM, diurutkan dalam privasi TEE. Selama proses tersebut, node dapat menambahkan transaksi tambahan melalui plugin, seperti memperbarui harga oracle, kemudian menghasilkan bukti,
4）Data transaksi dikirim ke node Leader di jaringan utama Solana,
5）Leader mengumpulkan transaksi, mengumpulkan paket data BAM, kemudian mengemasnya menjadi blok untuk disiarkan,
Suara node lainnya.
Jadi, sebenarnya BAM tidak bertentangan dengan proses konsensus jaringan utama Solana saat ini, melainkan sebagai "opsi". BAM tidak berjalan langsung di jaringan utama Solana, tetapi dengan cara yang disebut "off-chain", menyelesaikan pengurutan transaksi sebelumnya, mengemas transaksi, dan kemudian mengirimkannya ke jaringan utama Solana.
BAM mode pengurutan volume
BAM mendukung tiga mode operasi,
1）Solana mode default;
2）Mode Block-Engine; solusi MEV Jito saat ini, inti dari mekanisme lelang.
3）Mode BAM, validator mengikuti urutan FIFO (pertama masuk, pertama keluar) secara ketat.
Inti dari mode BAM, ada beberapa poin berikut:
1）Lingkungan Eksekusi Terpercaya TEEs: Privasi dan Keadilan Menggunakan Lingkungan Eksekusi Terpercaya TEEs, membangun lingkungan privasi, dan mengurutkan transaksi. Sisi lain dari privasi disebut keadilan.
2）Sistem Plugin: Pengurutan Kompleks Melalui sistem plugin, BAM memungkinkan aplikasi membangun logika pengurutan transaksi kustom. Dan pengurutan kustom ini, bukan berarti node dapat mengurutkan sesuka hati, tetapi berdasarkan aturan yang telah ditetapkan sebelumnya.
Rencana plugin untuk mewujudkan pengurutan transaksi yang kompleks, sambil menjaga jaminan keamanan lingkungan TEE. Saat ini masih dalam tahap pengembangan awal.
Seperti yang disebutkan sebelumnya,
Untuk order book DEX, urutan yang ideal seharusnya adalah, seiring dengan fluktuasi harga, pertama-tama mengeksekusi semua pembatalan, kemudian mengeksekusi order baru, dan terakhir mengeksekusi transaksi. Ini adalah sesuatu yang saat ini tidak dapat dilakukan oleh konsensus Solana di tingkat mikro.
Dan di sisi harga oracle juga sama, dalam kondisi ideal, harga oracle diperbarui terlebih dahulu, kemudian melakukan transaksi yang bergantung pada harga tersebut. Namun dalam interval 400 milidetik saat ini, pasar dapat berfluktuasi dengan tajam, yang menyebabkan transaksi tetap dilakukan berdasarkan harga sebelumnya.
Untuk perjanjian pinjaman, sebaiknya diisi jaminan terlebih dahulu, kemudian dilakukan likuidasi. Ini secara nyata mewujudkan fungsi kontrol eksekusi aplikasi ACE.
Jadi, apa yang sebenarnya dicapai oleh BAM?
Sebagai contoh,
1）Perlindungan Likuidasi Pinjaman
Untuk perjanjian pinjaman, setelah mendeteksi risiko likuidasi, lakukan operasi tambahan jaminan terlebih dahulu, kemudian lakukan pemeriksaan likuidasi.
Kombinasi transaksi tingkat atom
Untuk DEX, perbarui harga oracle terlebih dahulu, kemudian lakukan transaksi yang bergantung pada harga tersebut. Jika DEX adalah kontrak, maka juga dapat menyelesaikan derivatif yang relevan. Semua operasi di atas selesai dalam jendela waktu yang sama.
3）perlindungan terhadap fluktuasi harga
Untuk DEX, deteksi pesanan besar yang abnormal, pecah pesanan besar menjadi bagian kecil, eksekusi secara bertahap, berikan waktu reaksi pasar, hindari likuidasi berantai atau arbitrase yang menyebabkan spiral kematian.
4）Perlindungan Pembuat Pasar
Kejadian mendadak terjadi, pembatalan pesanan dalam milidetik, oracle memperbarui harga, pembuat pasar memasang kembali pesanan. Hindari arbitrase jahat, kurangi selisih harga.
BAM awalnya akan diluncurkan pada akhir Juli.
Dan, dengan penerapan BAM, pengalaman transaksi Solana akan mengalami perbaikan yang signifikan. BAM akan membuat pengalaman aplikasi di mainnet Solana lebih mendekati CEX.
Dengan demikian,
BAM membawa verifiabilitas, perlindungan privasi, dan pemrograman ke dalam proses pemrosesan transaksi Solana, memungkinkan pengembang untuk membangun buku pesanan batas pusat (CLOBs), bursa kontrak berjangka (Perpetual Exchanges), kolam gelap (Dark Pools), dan infrastruktur keuangan lainnya yang memerlukan kontrol pemesanan, eksekusi yang pasti, 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.
Menginterpretasikan pasar perakitan blok Solana BAM: ketika kecepatan bukan lagi satu-satunya tujuan.
Solana sudah cukup cepat, volume cukup besar. Lalu apakah itu benar-benar "cukup"?
Ketika kita melihat transaksi-transaksi tersebut, ada satu pertanyaan yang selalu ada: Apakah transaksi-transaksi ini benar-benar menciptakan nilai?
Transaksi besar pada Solana tidak berasal dari permintaan transaksi yang nyata, melainkan dari para arbitrase frekuensi tinggi yang memanfaatkan perbedaan informasi dalam millisecond untuk mendapatkan keuntungan. Para "trader beracun" (Toxic-takers) ini memanfaatkan keunggulan teknologi, dengan meningkatkan Gas saat pembuat pasar (Maker) akan membatalkan order, sehingga transaksi mereka dapat diprioritaskan untuk dibundel, menyelesaikan arbitrase dan membuat pembuat pasar menanggung kerugian. Untuk menutupi kerugian, pembuat pasar hanya dapat memperlebar selisih harga beli dan jual.
Akhirnya, pengguna biasa yang membayar untuk ini. Solana selalu memiliki impian untuk mewujudkan buku pesanan di blockchain, menggantikan CEX. Namun, dengan cara ini, "trader beracun" menjadi hambatan untuk mewujudkan impian tersebut. Inilah tantangan baru yang dihadapi Solana: volume ≠ likuiditas. Pasar yang benar-benar sehat bukanlah tentang lebih banyak perdagangan, tetapi perdagangan yang lebih baik.
Bagaimana cara menghapus transaksi beracun untuk melindungi likuiditas dengan lebih baik?
Dalam sistem saat ini, pemakan (Takers) memiliki hak prioritas sebenarnya karena mekanisme lelang periodik konsensus Solana, yang membuat pengaruh MEV yang merugikan memengaruhi keadilan pasar.
Bagaimana cara memahaminya?
Dalam konsensus Solana saat ini, setiap periode Slot, transaksi diurutkan berdasarkan biaya Gas yang dibayar. Siapa yang menawar lebih tinggi, transaksi mereka akan dieksekusi terlebih dahulu. Lelang ini bersifat periodik, setiap 400 milidetik satu Slot.
Dalam proses ini, pembuat pasar perlu sering menyesuaikan tawaran, membatalkan pesanan, dan mengajukan ulang pesanan. Saat harga pasar berubah, perlu segera diperbarui.
Dan para pemakan pesanan (Taker), terutama para arbitrase frekuensi tinggi, memantau perbedaan harga dan segera melakukan transaksi begitu mereka menemukan kesempatan. Oleh karena itu, para arbitrase dapat menyelesaikan transaksi dengan membayar biaya yang lebih tinggi untuk mengalahkan pembatalan pesanan. Hal ini menyebabkan pembuat pasar sering "diserang" dan menanggung kerugian.
Untuk buku pesanan DEX, urutan ideal seharusnya adalah, seiring dengan fluktuasi harga, pertama-tama mengeksekusi semua pembatalan, kemudian mengeksekusi pesanan baru, dan terakhir mengeksekusi transaksi. Ini adalah sesuatu yang saat ini tidak dapat dicapai oleh konsensus Solana di tingkat mikro.
Dan di sisi penawaran oracle juga sama, situasi ideal adalah memperbarui harga oracle terlebih dahulu, sebelum mengeksekusi transaksi yang bergantung pada harga tersebut. Namun, dalam interval 400 milidetik saat ini, pasar mungkin mengalami fluktuasi yang tajam, yang menyebabkan transaksi tetap dilakukan berdasarkan harga awal.
Untuk protokol pinjaman, sebaiknya terlebih dahulu menambah margin, kemudian melakukan likuidasi.
Jadi, sebaiknya ada cara yang memungkinkan berbagai protokol untuk mengurutkan transaksi sesuai kebutuhan, yaitu ACE (Application-Controlled Execution) yang selalu ditekankan oleh Solana.
BAM (Block Assembly Marketplace, pasar perakitan blok) adalah jawaban Solana.
BAM di jaringan Solana membangun lapisan pengurutan, atau yang disebut lapisan pra-pemrosesan, antara aplikasi dan mainnet.
Memanfaatkan Lingkungan Eksekusi Tepercaya (Trusted Execution Environments, TEEs) untuk membangun kotak pasir privasi, di dalam kotak pasir melakukan pengurutan transaksi berdasarkan aturan pengurutan yang telah ditentukan sebelumnya, atau FIFO (First In First Out).
Melayani buku pesanan (CLOBs), bursa kontrak berjangka (Perpetual Exchanges), dan protokol kolam gelap (Dark Pools) dengan lebih baik.
Solana biasanya membandingkan pengemasan transaksi dengan mode BAM
Bagaimana memahami BAM yang membangun lapisan pengurutan antara aplikasi Solana dan mainnet? Mari kita mulai dengan perbandingan yang intuitif.
Proses perdagangan Solana yang normal,
1）Pengguna mengonfirmasi transaksi di dompet.
2）Mengirim transaksi ke node RPC,
3）RPC mengirimkan ke node Leader Solana mainnet dalam periode Slot saat ini,
4）Leader mengumpulkan transaksi dari pool transaksi, mengurutkan, mengemas menjadi blok untuk disiarkan,
5）Pemungutan suara node lainnya.
Jika suatu aplikasi menghubungkan BAM, alur transaksi adalah sebagai berikut,
1）Pengguna mengonfirmasi transaksi di dompet,
2）Transaksi dikirim ke node RPC,
3）Transaksi dipindahkan ke jaringan BAM, diurutkan dalam privasi TEE. Selama proses tersebut, node dapat menambahkan transaksi tambahan melalui plugin, seperti memperbarui harga oracle, kemudian menghasilkan bukti,
4）Data transaksi dikirim ke node Leader di jaringan utama Solana,
5）Leader mengumpulkan transaksi, mengumpulkan paket data BAM, kemudian mengemasnya menjadi blok untuk disiarkan,
Jadi, sebenarnya BAM tidak bertentangan dengan proses konsensus jaringan utama Solana saat ini, melainkan sebagai "opsi". BAM tidak berjalan langsung di jaringan utama Solana, tetapi dengan cara yang disebut "off-chain", menyelesaikan pengurutan transaksi sebelumnya, mengemas transaksi, dan kemudian mengirimkannya ke jaringan utama Solana.
BAM mode pengurutan volume
BAM mendukung tiga mode operasi,
1）Solana mode default;
2）Mode Block-Engine; solusi MEV Jito saat ini, inti dari mekanisme lelang.
3）Mode BAM, validator mengikuti urutan FIFO (pertama masuk, pertama keluar) secara ketat.
Inti dari mode BAM, ada beberapa poin berikut:
1）Lingkungan Eksekusi Terpercaya TEEs: Privasi dan Keadilan Menggunakan Lingkungan Eksekusi Terpercaya TEEs, membangun lingkungan privasi, dan mengurutkan transaksi. Sisi lain dari privasi disebut keadilan.
2）Sistem Plugin: Pengurutan Kompleks Melalui sistem plugin, BAM memungkinkan aplikasi membangun logika pengurutan transaksi kustom. Dan pengurutan kustom ini, bukan berarti node dapat mengurutkan sesuka hati, tetapi berdasarkan aturan yang telah ditetapkan sebelumnya.
Rencana plugin untuk mewujudkan pengurutan transaksi yang kompleks, sambil menjaga jaminan keamanan lingkungan TEE. Saat ini masih dalam tahap pengembangan awal.
Seperti yang disebutkan sebelumnya,
Untuk order book DEX, urutan yang ideal seharusnya adalah, seiring dengan fluktuasi harga, pertama-tama mengeksekusi semua pembatalan, kemudian mengeksekusi order baru, dan terakhir mengeksekusi transaksi. Ini adalah sesuatu yang saat ini tidak dapat dilakukan oleh konsensus Solana di tingkat mikro.
Dan di sisi harga oracle juga sama, dalam kondisi ideal, harga oracle diperbarui terlebih dahulu, kemudian melakukan transaksi yang bergantung pada harga tersebut. Namun dalam interval 400 milidetik saat ini, pasar dapat berfluktuasi dengan tajam, yang menyebabkan transaksi tetap dilakukan berdasarkan harga sebelumnya.
Untuk perjanjian pinjaman, sebaiknya diisi jaminan terlebih dahulu, kemudian dilakukan likuidasi. Ini secara nyata mewujudkan fungsi kontrol eksekusi aplikasi ACE.
Jadi, apa yang sebenarnya dicapai oleh BAM?
Sebagai contoh,
1）Perlindungan Likuidasi Pinjaman
Untuk perjanjian pinjaman, setelah mendeteksi risiko likuidasi, lakukan operasi tambahan jaminan terlebih dahulu, kemudian lakukan pemeriksaan likuidasi.
Untuk DEX, perbarui harga oracle terlebih dahulu, kemudian lakukan transaksi yang bergantung pada harga tersebut. Jika DEX adalah kontrak, maka juga dapat menyelesaikan derivatif yang relevan. Semua operasi di atas selesai dalam jendela waktu yang sama.
3）perlindungan terhadap fluktuasi harga
Untuk DEX, deteksi pesanan besar yang abnormal, pecah pesanan besar menjadi bagian kecil, eksekusi secara bertahap, berikan waktu reaksi pasar, hindari likuidasi berantai atau arbitrase yang menyebabkan spiral kematian.
4）Perlindungan Pembuat Pasar
Kejadian mendadak terjadi, pembatalan pesanan dalam milidetik, oracle memperbarui harga, pembuat pasar memasang kembali pesanan. Hindari arbitrase jahat, kurangi selisih harga.
BAM awalnya akan diluncurkan pada akhir Juli.
Dan, dengan penerapan BAM, pengalaman transaksi Solana akan mengalami perbaikan yang signifikan. BAM akan membuat pengalaman aplikasi di mainnet Solana lebih mendekati CEX.
Dengan demikian,
BAM membawa verifiabilitas, perlindungan privasi, dan pemrograman ke dalam proses pemrosesan transaksi Solana, memungkinkan pengembang untuk membangun buku pesanan batas pusat (CLOBs), bursa kontrak berjangka (Perpetual Exchanges), kolam gelap (Dark Pools), dan infrastruktur keuangan lainnya yang memerlukan kontrol pemesanan, eksekusi yang pasti, dan perlindungan privasi, sehingga mendorong inovasi dan pengembangan ekosistem Solana.
Di atas.