Penulis: Pavel Paramonov Sumber: X, @paramonoww Terjemahan: Good Oppa, Golden Finance
Banyak orang menganggap bahwa "ASS adalah segalanya yang Anda butuhkan," menganggapnya sebagai solusi lengkap yang hampir tidak memerlukan perbaikan. Namun, ASS tidak dapat menyelesaikan semua masalah, dan juga memiliki beberapa asumsi kepercayaan.
1. dApp yang dapat melakukan deserialisasi sendiri adalah sebagian dari pembangun Blok
Ketika sebuah bundel transaksi masuk ke dalam Blok, dApp memiliki hak untuk mengekstrak MEV (maximal extractable value) mereka sendiri dari anggota MEV Rantai Pasokan lainnya seperti proposer, pencari, dan pembangun. Namun, konsep ini tidak sempurna (tidak ada yang sempurna di dunia enkripsi), dan mungkin memiliki beberapa asumsi kepercayaan.
2. Permainan yang inklusif
Tantangan yang dihadapi oleh dApp yang dapat melakukan self-serialization adalah semakin tinggi nilai yang diikat, semakin besar kebutuhan untuk memastikan bahwa transaksi MEV yang ditangkap dimasukkan ke dalam Blok. Jika transaksi yang berhasil menangkap MEV tidak dimasukkan ke dalam Blok, maka transaksi tersebut mungkin menjadi tidak menguntungkan sama sekali, yang tidak hanya merugikan transaksi lain yang tidak dapat menghasilkan MEV, tetapi juga merugikan pengguna.
Ini adalah skenario pemikiran yang menarik:
dApp memiliki kemampuan untuk menangkap semua MEV yang dihasilkannya
Namun jika tidak hanya kehilangan kesempatan MEV, tetapi juga mungkin kehilangan pengguna yang memberikan nilai bagi platform (misalnya jika AMM terus gagal, siapa lagi yang akan menggunakannya), maka itu tidak masuk akal.
Yang paling menarik adalah bahwa penawar juga perlu mendapatkan keuntungan, ini menciptakan situasi saling merugikan:
Aplikasi terdesentralisasi yang mengalami autoserialisasi kehilangan MEV karena pengikatannya tidak termasuk dalam Blok
Penyaji kehilangan MEV karena tidak dapat membongkar dan menyusun ulang ikatan atom asli (meskipun mereka dapat memilih transaksi lain)
3. dApp ASS tidak boleh merugikan pengguna biasa dan Penyedia Likuiditas (LP) dengan mengekstraksi MEV
Seperti yang kita ketahui, sebagian besar MEV dihasilkan dan diekstraksi melalui lalu lintas beracun. LP kehilangan sebagian besar pendapatan dari lalu lintas tidak sadar karena MEV. Menarik Likuiditas ke platform merupakan salah satu hal terberat dalam dunia enkripsi, sementara AMM seharusnya ikuti pembagian MEV secara adil kepada LP, yang mungkin membantu mengurangi Impermanent Loss.
Dalam realitas saat ini, mengelola posisi LP secara aktif (bahkan beberapa posisi LP) dapat dianggap sebagai pekerjaan penuh waktu. Jika terjadi serangan sandwich, nilai akan dikembalikan kepada para trader; jika terjadi Arbitrase antara pertukaran sentralisasi dan pertukaran desentralisasi, nilai akan dikembalikan kepada LP. Jadi, pertanyaannya adalah berapa pengembalian yang seharusnya mereka dapatkan, dan berapa nilai yang harus tetap di dApp?
**4. Jika ukuran bundel bertentangan dengan ukuran Blok dari rantai dasar, apa yang harus dilakukan?
Jelas, tidak semua dApp akan mengurutkan secara otomatis (setidaknya dalam waktu dekat). Ukuran Blok (atau batch transaksi) terbatas; tanpa batasan, tidak akan ada Blokchain atau "Blokchain". Misalnya, jika satu Blok dapat menampung maksimal 100 transaksi, beberapa skenario berikut mungkin terjadi:
dApp mengirimkan bundel dengan 100 transaksi yang mengisi seluruh Blok. Seberapa besar peluang keuntungan bagi 'anggota' lain dalam Rantai Pasokan MEV untuk memasukkannya, mengusulkannya, dan melaksanakannya?
dApp telah mengirimkan ikatan dengan 99 transaksi, dan masih ada 1 posisi yang tersisa. Apakah pengusul memiliki insentif yang cukup untuk menyertakan ikatan ini? (Kecuali jika mereka melakukan kerja sama tertentu, seperti pra-konfirmasi)
Dua dApp telah mengirimkan bundel. Bundel pertama berisi 60 transaksi, yang kedua berisi 50 transaksi. Jelasnya, hanya bisa ada satu bundel.
Intinya, MEV yang dihasilkan oleh ikatan pertama lebih banyak daripada yang kedua, tetapi dari sudut pandang lain, menyertakan ikatan kedua lebih menguntungkan karena 50 transaksi non-dApp yang tidak berurutan lainnya dapat menciptakan lebih banyak nilai untuk Blok setelah dikombinasikan dengan ikatan.
Jadi siapa yang harus disertakan? Siapa yang paling menguntungkan di Blok, bukan hanya mengikat internal?
Solusi yang dapat diimplementasikan adalah FCFS (First Come First Serve), tetapi itu tidak dapat menjamin akurasi karena latensi masih ada.
Bagaimana memastikan serialisasi menguntungkan semua orang, bukan hanya satu peserta, dan menghilangkan nilai bagi peserta lain (LP, pengguna)?
Solusi yang potensial adalah menetapkan aturan serialisasi khusus, hanya mereka yang mengikuti aturan ini yang berhak untuk mengurutkan bundel. Ini sangat penting karena serialisasi yang tidak tepat dapat menyebabkan kerentanan keamanan.
Untuk pasangan perdagangan AMM, aturan verifikasi yang rakus dapat mencegah perdagangan tertekan di kolam AMM tertentu. Namun, sebagian besar perdagangan DEX adalah perdagangan pertukaran multipel, sehingga diperlukan cara lain untuk memberikan jaminan tahan terhadap MEV.
Masih dalam tahap awal!
Saat ini ada beberapa cara untuk melakukan deserialisasi diri, saya terinspirasi oleh metode @SorellaLabs dalam topik ini. Kami masih berada pada tahap awal dalam mengimplementasikan deserialisasi diri (atau ASS, seperti yang disebutkan oleh @ballsyalchemist), ada pertimbangan yang berbeda dalam infrastruktur yang berbeda.
Tujuan ASS adalah membuat dApp bertanggung jawab atas serialisasi-nya, tanpa perlu khawatir tentang eksekusi (yang ditangani oleh rantai). Meskipun di L1, ASS relatif jelas, namun di L2 lebih menarik karena hanya perlu menangani satu serialisasi, dan L2 dapat membawa lebih banyak konten melalui penerapan aturan serialisasi lokal.
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.
Apakah menerapkan skema pengurutan khusus benar-benar dapat menyelesaikan semua masalah?
Penulis: Pavel Paramonov Sumber: X, @paramonoww Terjemahan: Good Oppa, Golden Finance
Banyak orang menganggap bahwa "ASS adalah segalanya yang Anda butuhkan," menganggapnya sebagai solusi lengkap yang hampir tidak memerlukan perbaikan. Namun, ASS tidak dapat menyelesaikan semua masalah, dan juga memiliki beberapa asumsi kepercayaan.
1. dApp yang dapat melakukan deserialisasi sendiri adalah sebagian dari pembangun Blok
Ketika sebuah bundel transaksi masuk ke dalam Blok, dApp memiliki hak untuk mengekstrak MEV (maximal extractable value) mereka sendiri dari anggota MEV Rantai Pasokan lainnya seperti proposer, pencari, dan pembangun. Namun, konsep ini tidak sempurna (tidak ada yang sempurna di dunia enkripsi), dan mungkin memiliki beberapa asumsi kepercayaan.
2. Permainan yang inklusif
Tantangan yang dihadapi oleh dApp yang dapat melakukan self-serialization adalah semakin tinggi nilai yang diikat, semakin besar kebutuhan untuk memastikan bahwa transaksi MEV yang ditangkap dimasukkan ke dalam Blok. Jika transaksi yang berhasil menangkap MEV tidak dimasukkan ke dalam Blok, maka transaksi tersebut mungkin menjadi tidak menguntungkan sama sekali, yang tidak hanya merugikan transaksi lain yang tidak dapat menghasilkan MEV, tetapi juga merugikan pengguna.
Ini adalah skenario pemikiran yang menarik:
Yang paling menarik adalah bahwa penawar juga perlu mendapatkan keuntungan, ini menciptakan situasi saling merugikan:
3. dApp ASS tidak boleh merugikan pengguna biasa dan Penyedia Likuiditas (LP) dengan mengekstraksi MEV
Seperti yang kita ketahui, sebagian besar MEV dihasilkan dan diekstraksi melalui lalu lintas beracun. LP kehilangan sebagian besar pendapatan dari lalu lintas tidak sadar karena MEV. Menarik Likuiditas ke platform merupakan salah satu hal terberat dalam dunia enkripsi, sementara AMM seharusnya ikuti pembagian MEV secara adil kepada LP, yang mungkin membantu mengurangi Impermanent Loss.
Dalam realitas saat ini, mengelola posisi LP secara aktif (bahkan beberapa posisi LP) dapat dianggap sebagai pekerjaan penuh waktu. Jika terjadi serangan sandwich, nilai akan dikembalikan kepada para trader; jika terjadi Arbitrase antara pertukaran sentralisasi dan pertukaran desentralisasi, nilai akan dikembalikan kepada LP. Jadi, pertanyaannya adalah berapa pengembalian yang seharusnya mereka dapatkan, dan berapa nilai yang harus tetap di dApp?
**4. Jika ukuran bundel bertentangan dengan ukuran Blok dari rantai dasar, apa yang harus dilakukan?
Jelas, tidak semua dApp akan mengurutkan secara otomatis (setidaknya dalam waktu dekat). Ukuran Blok (atau batch transaksi) terbatas; tanpa batasan, tidak akan ada Blokchain atau "Blokchain". Misalnya, jika satu Blok dapat menampung maksimal 100 transaksi, beberapa skenario berikut mungkin terjadi:
Intinya, MEV yang dihasilkan oleh ikatan pertama lebih banyak daripada yang kedua, tetapi dari sudut pandang lain, menyertakan ikatan kedua lebih menguntungkan karena 50 transaksi non-dApp yang tidak berurutan lainnya dapat menciptakan lebih banyak nilai untuk Blok setelah dikombinasikan dengan ikatan.
Jadi siapa yang harus disertakan? Siapa yang paling menguntungkan di Blok, bukan hanya mengikat internal?
Solusi yang dapat diimplementasikan adalah FCFS (First Come First Serve), tetapi itu tidak dapat menjamin akurasi karena latensi masih ada.
Bagaimana memastikan serialisasi menguntungkan semua orang, bukan hanya satu peserta, dan menghilangkan nilai bagi peserta lain (LP, pengguna)?
Solusi yang potensial adalah menetapkan aturan serialisasi khusus, hanya mereka yang mengikuti aturan ini yang berhak untuk mengurutkan bundel. Ini sangat penting karena serialisasi yang tidak tepat dapat menyebabkan kerentanan keamanan.
Untuk pasangan perdagangan AMM, aturan verifikasi yang rakus dapat mencegah perdagangan tertekan di kolam AMM tertentu. Namun, sebagian besar perdagangan DEX adalah perdagangan pertukaran multipel, sehingga diperlukan cara lain untuk memberikan jaminan tahan terhadap MEV.
Masih dalam tahap awal!
Saat ini ada beberapa cara untuk melakukan deserialisasi diri, saya terinspirasi oleh metode @SorellaLabs dalam topik ini. Kami masih berada pada tahap awal dalam mengimplementasikan deserialisasi diri (atau ASS, seperti yang disebutkan oleh @ballsyalchemist), ada pertimbangan yang berbeda dalam infrastruktur yang berbeda.
Tujuan ASS adalah membuat dApp bertanggung jawab atas serialisasi-nya, tanpa perlu khawatir tentang eksekusi (yang ditangani oleh rantai). Meskipun di L1, ASS relatif jelas, namun di L2 lebih menarik karena hanya perlu menangani satu serialisasi, dan L2 dapat membawa lebih banyak konten melalui penerapan aturan serialisasi lokal.
naik ruang besar z!（Blok ruang terkecuali）