Untuk mencapai ini, kita harus menawarkan harga yang lebih baik daripada Nasdaq, dan kita harus memberikan aplikasi kemampuan untuk membatalkan operasi sebelum transaksi dengan prioritas.
Diterjemahkan oleh: GaryMa Wu Mengatakan Blockchain
Ringkasan
Solana bertujuan untuk membangun jaringan perdagangan terdesentralisasi yang lebih efisien daripada NASDAQ, tetapi desain blockchain yang ada tidak sesuai dengan harapan, pembuat pasar Solana saat ini memiliki tingkat kemenangan yang rendah dalam perlombaan pembatalan pesanan (jauh lebih rendah dari 13% bursa terpusat), dan Jito Auctions memperburuk kontrol akses negara oleh satu pemimpin, yang mengakibatkan penyebaran yang melebar. Dalam hal ini, diusulkan untuk merekonstruksi mekanisme konsensus dan memperkenalkan beberapa pemimpin bersamaan untuk mengoptimalkan pemesanan pesanan, mengurangi biaya seleksi yang merugikan dari pembuat pasar, dan meningkatkan efisiensi harga.
Tujuan awal penciptaan Solana adalah untuk membangun blockchain yang cukup cepat dan cukup murah agar dapat menjalankan buku pesanan batas pusat yang dapat digunakan. Versi uji coba utama Solana diluncurkan pada Maret 2020 — — kini sudah lima tahun berlalu, meskipun kami telah mencapai banyak pencapaian, semakin jelas bahwa kami belum mencapai tujuan ini.
Infrastruktur blockchain yang ada saat ini tidak dirancang untuk transaksi. Jika kita ingin mewujudkan misi awal Solana, kita harus kembali ke titik awal, mulai dari prinsip yang paling dasar, dan meredesain mekanisme konsensus secara menyeluruh, akhirnya membangun jaringan terdesentralisasi yang mampu bersaing dengan New York Stock Exchange.
Apa yang kami maksud dengan bersaing dengan Bursa Saham New York adalah bahwa bursa di Solana perlu mampu menawarkan harga yang lebih baik daripada bursa terdesentralisasi. Dalam dunia pasar, harga didefinisikan oleh "spread": yaitu selisih antara harga tertinggi yang seseorang bersedia membayar untuk membeli aset dan harga terendah yang seseorang bersedia menerima untuk menjual aset.
Semakin kecil selisih harga, semakin baik harga yang didapat trader, dan efisiensi pasar juga semakin tinggi.
Rumus penyebarannya sederhana. Spread diatur sedemikian rupa sehingga keuntungan yang diharapkan yang akan diterima pembuat pasar dari perdagangan dengan pedagang non-informasi sama dengan kerugian yang diharapkan yang akan mereka alami dari perdagangan dengan pedagang informasi. Ketika pembuat pasar memiliki lebih banyak informasi daripada rekanan mereka, mereka menghasilkan uang; Ketika ada lebih sedikit informasi daripada rekanan, mereka kehilangan uang. Pembuat pasar biasanya menghasilkan sedikit uang pada setiap perdagangan dengan investor ritel, tetapi kehilangan banyak jika mereka dilindung nilai ke arah yang berlawanan ketika harga melonjak hebat (mudah-mudahan jarang). Ini adalah asal usul frasa "pembuat pasar mengambil gerbang dan kehilangan semangka".
Apa yang menentukan biaya pemilihan terbalik?
Untuk lebih memahami seleksi yang merugikan, kita perlu memahami apa yang dimainkan pembuat pasar game. Pembuat pasar membuat keputusan berdasarkan "harga wajar" yang berubah secara acak dari waktu ke waktu. Ketika harga wajar berada dalam spread bid-ask, kutipan pembuat pasar aman karena rekanan tidak dapat menghasilkan keuntungan dengan memakan kutipan. Tetapi segera setelah harga wajar melebihi spread bid-ask, perlombaan dimulai: pembuat pasar mencoba membatalkan pesanan secepat mungkin, dan pengambil mencoba mengambil pesanan yang sudah ketinggalan zaman sebelum pembuat pasar membatalkan. Ekspektasi pengambil yang sukses adalah perbedaan antara harga wajar dan penawaran yang sudah ketinggalan zaman. Kunci untuk mengurangi gesekan seleksi yang merugikan adalah memungkinkan pembuat pasar memenangkan perlombaan sebanyak mungkin.
Data dari bursa terpusat menunjukkan bahwa setelah fluktuasi harga, pembuat pasar hanya memiliki probabilitas 13% untuk dapat membatalkan pesanan lebih dulu.
Pembuat pasar di bursa terpusat cenderung tidak menang dalam perlombaan pembatalan, tetapi bahkan lebih rendah di Solana. Mekanisme lelang Jito – yang merupakan efek samping dari pengusul tunggal yang mengendalikan akses negara dalam jangka waktu yang lama – membuat hampir tidak mungkin bagi pembuat pasar untuk memenangkan perlombaan pembatalan. Bahkan jika pembuat pasar lebih cepat, keputusan sebenarnya adalah siapa yang menawar lebih tinggi dalam lelang Jito. Hal ini menempatkan pembuat pasar dalam dilema: mereka dapat membayar banyak uang untuk membatalkan pesanan mereka, atau membiarkan orang lain membayar harga tinggi untuk menembak mereka. Either way, mereka kehilangan uang dan harus memperlebar spread sebagai hasilnya.
Dalam praktiknya, struktur mikro pasar on-chain saat ini memberi pengambil keuntungan penggerak pertama dalam hal seleksi yang merugikan. Untuk mengatasi masalah ini, kita perlu memberikan aplikasi lebih banyak fleksibilitas dalam memesan transaksi. Jika kita ingin menurunkan spread, aplikasi harus dapat memberikan pembuat pasar awal yang lebih baik dalam perlombaan pembatalan pesanan. Salah satu cara untuk melakukannya adalah dengan memperkenalkan strategi penyortiran "batalkan dulu, isi nanti". Kami melihat blok dan memproses semua pembatalan sebelum memproses semua pengambilan.
Strategi ini dapat segera kita terapkan di Solana, hanya dengan mengubah urutan tayangan ulang saat ini dari model yang ditentukan pemimpin menjadi kebijakan yang memprioritaskan pembatalan. Tapi itu tidak menyelesaikan masalah sepenuhnya. Jika masih dikendalikan oleh satu pemimpin, yang masih dapat memilih untuk mengabaikan pembatalan perdagangan, maka kita kembali ke titik awal – pembuat pasar masih kurang menguntungkan untuk membatalkan perlombaan.
Satu-satunya cara untuk mengatasi masalah ini adalah dengan memperkenalkan beberapa pemimpin paralel (Concurrent Leaders). Dengan cara ini, jika salah satu pemimpin memblokir pembatalan transaksi, Anda dapat beralih untuk mengajukannya kepada pemimpin lain.
Implementasi — Urutan Transaksi
Pertanyaan terbesar tentang beberapa pemimpin paralel adalah: Bagaimana kita menggabungkan blok transaksi masing-masing ketika ada konflik? Jawabannya sederhana: kami membagi biaya menjadi dua kategori: biaya inklusi dan biaya pemesanan. Biaya penyertaan dibayarkan kepada validator yang berisi transaksi, dan biaya penyortiran dibayarkan ke protokol (burn). Ketika kita ingin menggabungkan blok masing-masing pemimpin, kita cukup mengambil penyatuan semua transaksi untuk semua blok dalam slot dan mengurutkannya sesuai dengan biaya penyortirannya.
Hanya langkah ini saja tidak cukup. Apa yang benar-benar ingin kami capai adalah memberi aplikasi kemampuan untuk mengontrol urutan transaksi dengan lebih fleksibel. Tambahkan satu elemen: sistem pemanggilan get\_transaction\_metadata, yang memungkinkan program membaca biaya urutan transaksi yang berinteraksi dengannya, sehingga memberikan alat kontrol urutan yang kuat untuk aplikasi.
Implementasi — Mekanisme Konsensus
Tujuan desain mekanisme konsensus kami meliputi:
Pengikatan dan Kebutaan (Binding & Blinding): Pemimpin paralel tidak dapat menyertakan informasi dari blok pemimpin lain dalam blok mereka sendiri (seperti menyerang transaksi pribadi), dan juga tidak dapat membatalkan blok mereka sendiri berdasarkan konten blok pemimpin lain (misalnya, membatalkan tawaran mereka sendiri setelah melihat tawaran lain).
Keadilan Jam (Wallclock Fairness): Pemimpin yang paralel harus mengajukan blok dalam waktu nyata yang kira-kira sama.
Berikut adalah ringkasan solusi paling efektif yang dikembangkan bersama Pranav Garimidi dan Joachim Neu dari a16z Research:
Setiap pemimpin akan mengubah blok mereka menjadi serpihan kode penghapusan (shreds). Setelah cukup banyak serpihan (lebih dari tingkat pengkodean) dipulihkan, blok tersebut dapat dipulihkan. Pemulihan sebagian tidak mungkin.
Pemimpin akan mengirimkan fragmen ke node relay di lapisan pertama pohon Turbine. Setiap pemimpin akan mengirimkan fragmen pertama mereka ke relay 1, fragmen kedua ke relay 2, dan seterusnya. Jika semuanya berjalan lancar, setiap relay akan menerima fragmen dari semua pemimpin.
Setelah waktu habis, relay mengirimkan pesan IHAVE yang sudah ditandatangani kepada pemimpin konsensus tunggal, memberi tahu tentang fragmen yang diterimanya.
Pemimpin konsensus kemudian membangun sebuah blok yang berisi pesan IHAVE ini; jika tidak mencakup proporsi IHAVE yang cukup, blok tersebut akan tidak valid.
Pemimpin konsensus akan menyiarkan blok ini kepada validator, dan validator mulai mencapai konsensus mengenai blok ini.
Rencana ini memenuhi atribut binding dan blind dengan probabilitas tinggi, dan memiliki kesetaraan jam yang baik, meskipun di masa depan mungkin akan ada rencana yang lebih baik.
Kesimpulan
Solana diciptakan dengan tujuan melampaui NASDAQ. Untuk melakukan ini, kami harus menawarkan harga yang lebih baik daripada NASDAQ. Untuk melakukan ini, kita harus memberi aplikasi kemampuan untuk memprioritaskan pembatalan sebelum ditutup. Untuk memberdayakan penerapan kemampuan ini, kita harus mencegah para pemimpin meninjau perintah secara sepihak. Dan untuk melakukan itu, kita harus membawa beberapa pemimpin secara paralel.
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Bagaimana Solana dapat ditingkatkan untuk mewujudkan visi Nasdaq on-chain?
**Penulis: **Max Resnick (Anza) & Anatoly Yakovenko (Solana Labs)
Diterjemahkan oleh: GaryMa Wu Mengatakan Blockchain
Ringkasan
Solana bertujuan untuk membangun jaringan perdagangan terdesentralisasi yang lebih efisien daripada NASDAQ, tetapi desain blockchain yang ada tidak sesuai dengan harapan, pembuat pasar Solana saat ini memiliki tingkat kemenangan yang rendah dalam perlombaan pembatalan pesanan (jauh lebih rendah dari 13% bursa terpusat), dan Jito Auctions memperburuk kontrol akses negara oleh satu pemimpin, yang mengakibatkan penyebaran yang melebar. Dalam hal ini, diusulkan untuk merekonstruksi mekanisme konsensus dan memperkenalkan beberapa pemimpin bersamaan untuk mengoptimalkan pemesanan pesanan, mengurangi biaya seleksi yang merugikan dari pembuat pasar, dan meningkatkan efisiensi harga.
Tujuan awal penciptaan Solana adalah untuk membangun blockchain yang cukup cepat dan cukup murah agar dapat menjalankan buku pesanan batas pusat yang dapat digunakan. Versi uji coba utama Solana diluncurkan pada Maret 2020 — — kini sudah lima tahun berlalu, meskipun kami telah mencapai banyak pencapaian, semakin jelas bahwa kami belum mencapai tujuan ini.
Infrastruktur blockchain yang ada saat ini tidak dirancang untuk transaksi. Jika kita ingin mewujudkan misi awal Solana, kita harus kembali ke titik awal, mulai dari prinsip yang paling dasar, dan meredesain mekanisme konsensus secara menyeluruh, akhirnya membangun jaringan terdesentralisasi yang mampu bersaing dengan New York Stock Exchange.
Apa yang kami maksud dengan bersaing dengan Bursa Saham New York adalah bahwa bursa di Solana perlu mampu menawarkan harga yang lebih baik daripada bursa terdesentralisasi. Dalam dunia pasar, harga didefinisikan oleh "spread": yaitu selisih antara harga tertinggi yang seseorang bersedia membayar untuk membeli aset dan harga terendah yang seseorang bersedia menerima untuk menjual aset.
Semakin kecil selisih harga, semakin baik harga yang didapat trader, dan efisiensi pasar juga semakin tinggi.
Rumus penyebarannya sederhana. Spread diatur sedemikian rupa sehingga keuntungan yang diharapkan yang akan diterima pembuat pasar dari perdagangan dengan pedagang non-informasi sama dengan kerugian yang diharapkan yang akan mereka alami dari perdagangan dengan pedagang informasi. Ketika pembuat pasar memiliki lebih banyak informasi daripada rekanan mereka, mereka menghasilkan uang; Ketika ada lebih sedikit informasi daripada rekanan, mereka kehilangan uang. Pembuat pasar biasanya menghasilkan sedikit uang pada setiap perdagangan dengan investor ritel, tetapi kehilangan banyak jika mereka dilindung nilai ke arah yang berlawanan ketika harga melonjak hebat (mudah-mudahan jarang). Ini adalah asal usul frasa "pembuat pasar mengambil gerbang dan kehilangan semangka".
Apa yang menentukan biaya pemilihan terbalik?
Untuk lebih memahami seleksi yang merugikan, kita perlu memahami apa yang dimainkan pembuat pasar game. Pembuat pasar membuat keputusan berdasarkan "harga wajar" yang berubah secara acak dari waktu ke waktu. Ketika harga wajar berada dalam spread bid-ask, kutipan pembuat pasar aman karena rekanan tidak dapat menghasilkan keuntungan dengan memakan kutipan. Tetapi segera setelah harga wajar melebihi spread bid-ask, perlombaan dimulai: pembuat pasar mencoba membatalkan pesanan secepat mungkin, dan pengambil mencoba mengambil pesanan yang sudah ketinggalan zaman sebelum pembuat pasar membatalkan. Ekspektasi pengambil yang sukses adalah perbedaan antara harga wajar dan penawaran yang sudah ketinggalan zaman. Kunci untuk mengurangi gesekan seleksi yang merugikan adalah memungkinkan pembuat pasar memenangkan perlombaan sebanyak mungkin.
Data dari bursa terpusat menunjukkan bahwa setelah fluktuasi harga, pembuat pasar hanya memiliki probabilitas 13% untuk dapat membatalkan pesanan lebih dulu.
Pembuat pasar di bursa terpusat cenderung tidak menang dalam perlombaan pembatalan, tetapi bahkan lebih rendah di Solana. Mekanisme lelang Jito – yang merupakan efek samping dari pengusul tunggal yang mengendalikan akses negara dalam jangka waktu yang lama – membuat hampir tidak mungkin bagi pembuat pasar untuk memenangkan perlombaan pembatalan. Bahkan jika pembuat pasar lebih cepat, keputusan sebenarnya adalah siapa yang menawar lebih tinggi dalam lelang Jito. Hal ini menempatkan pembuat pasar dalam dilema: mereka dapat membayar banyak uang untuk membatalkan pesanan mereka, atau membiarkan orang lain membayar harga tinggi untuk menembak mereka. Either way, mereka kehilangan uang dan harus memperlebar spread sebagai hasilnya.
Dalam praktiknya, struktur mikro pasar on-chain saat ini memberi pengambil keuntungan penggerak pertama dalam hal seleksi yang merugikan. Untuk mengatasi masalah ini, kita perlu memberikan aplikasi lebih banyak fleksibilitas dalam memesan transaksi. Jika kita ingin menurunkan spread, aplikasi harus dapat memberikan pembuat pasar awal yang lebih baik dalam perlombaan pembatalan pesanan. Salah satu cara untuk melakukannya adalah dengan memperkenalkan strategi penyortiran "batalkan dulu, isi nanti". Kami melihat blok dan memproses semua pembatalan sebelum memproses semua pengambilan.
Strategi ini dapat segera kita terapkan di Solana, hanya dengan mengubah urutan tayangan ulang saat ini dari model yang ditentukan pemimpin menjadi kebijakan yang memprioritaskan pembatalan. Tapi itu tidak menyelesaikan masalah sepenuhnya. Jika masih dikendalikan oleh satu pemimpin, yang masih dapat memilih untuk mengabaikan pembatalan perdagangan, maka kita kembali ke titik awal – pembuat pasar masih kurang menguntungkan untuk membatalkan perlombaan.
Satu-satunya cara untuk mengatasi masalah ini adalah dengan memperkenalkan beberapa pemimpin paralel (Concurrent Leaders). Dengan cara ini, jika salah satu pemimpin memblokir pembatalan transaksi, Anda dapat beralih untuk mengajukannya kepada pemimpin lain.
Implementasi — Urutan Transaksi
Pertanyaan terbesar tentang beberapa pemimpin paralel adalah: Bagaimana kita menggabungkan blok transaksi masing-masing ketika ada konflik? Jawabannya sederhana: kami membagi biaya menjadi dua kategori: biaya inklusi dan biaya pemesanan. Biaya penyertaan dibayarkan kepada validator yang berisi transaksi, dan biaya penyortiran dibayarkan ke protokol (burn). Ketika kita ingin menggabungkan blok masing-masing pemimpin, kita cukup mengambil penyatuan semua transaksi untuk semua blok dalam slot dan mengurutkannya sesuai dengan biaya penyortirannya.
Hanya langkah ini saja tidak cukup. Apa yang benar-benar ingin kami capai adalah memberi aplikasi kemampuan untuk mengontrol urutan transaksi dengan lebih fleksibel. Tambahkan satu elemen: sistem pemanggilan
get\_transaction\_metadata, yang memungkinkan program membaca biaya urutan transaksi yang berinteraksi dengannya, sehingga memberikan alat kontrol urutan yang kuat untuk aplikasi.Implementasi — Mekanisme Konsensus
Tujuan desain mekanisme konsensus kami meliputi:
Pengikatan dan Kebutaan (Binding & Blinding): Pemimpin paralel tidak dapat menyertakan informasi dari blok pemimpin lain dalam blok mereka sendiri (seperti menyerang transaksi pribadi), dan juga tidak dapat membatalkan blok mereka sendiri berdasarkan konten blok pemimpin lain (misalnya, membatalkan tawaran mereka sendiri setelah melihat tawaran lain).
Keadilan Jam (Wallclock Fairness): Pemimpin yang paralel harus mengajukan blok dalam waktu nyata yang kira-kira sama.
Berikut adalah ringkasan solusi paling efektif yang dikembangkan bersama Pranav Garimidi dan Joachim Neu dari a16z Research:
Setiap pemimpin akan mengubah blok mereka menjadi serpihan kode penghapusan (shreds). Setelah cukup banyak serpihan (lebih dari tingkat pengkodean) dipulihkan, blok tersebut dapat dipulihkan. Pemulihan sebagian tidak mungkin.
Pemimpin akan mengirimkan fragmen ke node relay di lapisan pertama pohon Turbine. Setiap pemimpin akan mengirimkan fragmen pertama mereka ke relay 1, fragmen kedua ke relay 2, dan seterusnya. Jika semuanya berjalan lancar, setiap relay akan menerima fragmen dari semua pemimpin.
Setelah waktu habis, relay mengirimkan pesan IHAVE yang sudah ditandatangani kepada pemimpin konsensus tunggal, memberi tahu tentang fragmen yang diterimanya.
Pemimpin konsensus kemudian membangun sebuah blok yang berisi pesan IHAVE ini; jika tidak mencakup proporsi IHAVE yang cukup, blok tersebut akan tidak valid.
Pemimpin konsensus akan menyiarkan blok ini kepada validator, dan validator mulai mencapai konsensus mengenai blok ini.
Rencana ini memenuhi atribut binding dan blind dengan probabilitas tinggi, dan memiliki kesetaraan jam yang baik, meskipun di masa depan mungkin akan ada rencana yang lebih baik.
Kesimpulan
Solana diciptakan dengan tujuan melampaui NASDAQ. Untuk melakukan ini, kami harus menawarkan harga yang lebih baik daripada NASDAQ. Untuk melakukan ini, kita harus memberi aplikasi kemampuan untuk memprioritaskan pembatalan sebelum ditutup. Untuk memberdayakan penerapan kemampuan ini, kita harus mencegah para pemimpin meninjau perintah secara sepihak. Dan untuk melakukan itu, kita harus membawa beberapa pemimpin secara paralel.