Artikel ini akan memperkenalkan fitur “Privasi Terprogram” yang menyediakan transaksi yang lebih canggih dan desain pasar MEV yang lebih terbuka dan adil secara lintas-rantai -SUAVE. Sebelum masuk ke topik utama menjelaskan SUAVE, harap terlebih dahulu memahami konsep dari Intent.

Niat

Pengalaman saat ini menggunakan transaksi blockchain

Mengambil transaksi Ethereum sebagai contoh, diasumsikan seorang pengguna ingin menukar USDT-nya dengan ETH, dia mungkin pergi ke halaman web Uniswap untuk memeriksa harga, dan setelah mengatur selisih harga yang diizinkan, menandatangani dan mengirimkan transaksi, dan kemudian menunggu hasil transaksi.

Transaksi miliknya kemungkinan akan terlihat seperti ini: “Saya menandatangani dan mengirim transaksi ini, dengan nilai Nonce sebesar 23 dan biaya gas sebesar 30 Gwei. Ini akan mengeksekusi kontrak Uniswap untuk menukar 1000 USDT saya dengan 0.5 ETH, dengan slippage maksimum 1%.”

△ Nonce? Gwei? Sumber gambar:https://www.reddit.com/r/MemeRestoration/comments/ejcvd3/confused_math_lady_4080x2663px

Misalkan Alice adalah pengguna pemula, dan dia hanya ingin menukar USDT-nya dengan ETH, tetapi dia harus melewati banyak ambang batas untuk memenuhi keinginan kecil ini:

• Yang pertama adalah menemukan saluran pertukaran. Misalkan dia mencari di Google dan menemukan halaman Uniswap (setidaknya ada menu aset digital yang jelas dan tombol Swap), dan kemudian dia perlu memahami dan mengatur slippage (atau menggunakan default).
• Setelah mengeklik tombol Tukar, layar tanda tangan transaksi muncul, yang berisi Nonce dan Gwei dari biaya penanganan.
• Akhirnya dia mengirim transaksi, tetapi mungkin tidak ada yang terjadi dan Alice hanya bisa menunggu dalam kebingungan dan berdoa agar transaksi berhasil dieksekusi.

Setiap level adalah pertanyaan yang sebenarnya tidak perlu dipahami oleh pengguna pemula tetapi dipaksa untuk membuat pilihan: Di mana untuk menebus? Apakah Anda ingin mengatur slippage? Berapa persen yang harus diatur untuk slippage? Apakah Anda ingin menyesuaikan biaya gas (biaya penanganan)? Berapa banyak Gwei yang perlu disesuaikan? Mengapa transaksi gagal? Mengapa transaksi terjebak di sana begitu lama (mungkin ada masalah dengan Nonce atau biaya penanganan)? Apa yang harus saya lakukan?

Pengalaman penggunaan transaksi niat

Tidak seperti Transaksi, yang memerlukan untuk menentukan berbagai rincian transaksi, Niat hanya memerlukan pengguna untuk menentukan hasil yang ingin dicapai dan kondisi untuk pelaksanaan, dan sisanya diserahkan kepada orang yang lebih profesional.

Dalam Niat, Alice menentukan bahwa 1000 USDT harus ditukar dengan 0,5 ETH, tetapi mengingat biaya penanganan, harga disesuaikan menjadi 0,495 ETH, dan kemudian pesanan tersebut ditandatangani dan dikirim. Transaksi Alice akan terlihat seperti ini: “Saya menandatangani dan mengirim pesanan ini. Saya ingin menukar 1000 USDT dengan 0,495 ETH. Pesanan ini valid selama saya bisa mendapatkan 0,495 ETH.”

Ini sangat sederhana, bukan? Ini adalah pengalaman menggunakan limit order (Limit Order), dan juga pengalaman umum menggunakan DEX Aggregators (seperti 1inch dan Tokenlon).

△ Perbedaan antara Transaksi (atas) dan Intent (bawah). Dengan Intent, pengguna hanya perlu menentukan kondisi dan tidak perlu khawatir tentang cara mencapainya. Caption:https://www.paradigm.xyz/2023/06/intents

Melalui Intent, pengguna tidak perlu lagi berurusan dan khawatir tentang berbagai detail yang membosankan dan membingungkan antara pembuatan, penandatanganan, dan pelaksanaan transaksi. Mereka bahkan tidak perlu mencari tahu masalah dan terus mencoba ketika transaksi gagal. Selain itu, berbagai rantai akan memiliki proses transaksi dan kendala yang berbeda!

Melalui Intent, pengguna hanya perlu menentukan kondisi pelaksanaan dan hasil yang diharapkan dari Intent-nya. Selebihnya diserahkan kepada Solver profesional untuk mewujudkan Intent pengguna - bagaimana mengirim transaksi, memantau transaksi, mempercepat transaksi, dll. Menangani masalah-masalah merepotkan seperti kegagalan transaksi, dan Intent hanya dapat diimplementasikan ketika kondisi pelaksanaan dan hasil yang diharapkan terpenuhi, sehingga pengguna tidak perlu khawatir apakah kecelakaan akan menyebabkan aset menghilang.

Niat akan sangat meningkatkan pengalaman blockchain.

Tips Membaca 1: Sebenarnya, sudah banyak contoh penggunaan Intent, seperti tanda tangan dompet multi-tanda tangan, konsep Kunci Sesi yang memberikan izin eksekusi spesifik dan batas waktu kepada pihak ketiga, atau mekanisme transaksi pencocokan batch seperti CowSwap. Bahkan di dunia Web2, ada jejak Intent, seperti mesin pencari (Saya memasukkan apa yang ingin saya kueri, dan mesin pencari menemukan informasi relevan untuk saya melalui berbagai saluran) atau pemotretan online e-commerce (Saya memasukkan apa yang ingin saya beli) Sesuatu, perusahaan e-commerce menemukannya melalui berbagai saluran dan mengirimkannya kepada saya). Hanya saja kata Intent baru-baru ini menjadi populer di dunia Web3.

Pertimbangan membaca 2: Dalam bahasa Inggris, kata Imperatif (“imperatif”) digunakan untuk menggambarkan pengalaman menggunakan Transaksi, yang bertujuan mengeluarkan perintah lengkap untuk menyelesaikan tujuan; sedangkan kata “Deklaratif” (“Pernyataan”) digunakan untuk menggambarkan pengalaman menggunakan Niat. Deskriptif, menunjukkan bahwa hal ini digunakan dengan menyatakan kondisi eksekusi dan hasil eksekusi.

Niat dalam dunia lintas-rantai

Dalam aplikasi lintas-rantai seperti jembatan lintas-rantai dan DEX lintas-rantai, karena melibatkan dua atau lebih rantai, pengguna harus berurusan dengan lebih banyak transaksi di rantai yang berbeda.

Mengecualikan aplikasi lintas-rantai melalui multi-tanda tangan pihak proyek, dapat memberikan pengalaman pengguna yang lebih baik (misalnya, setelah pengguna mengirim transaksi di rantai sumber, multi-tanda tangan pihak proyek akan secara otomatis mengirim aset ke pengguna di rantai target) Alamat yang ditentukan tidak memerlukan pengguna melakukan operasi apa pun di rantai target). Aplikasi lintas-rantai lain yang lebih terdesentralisasi seperti Nomad dan Succinct tidak memiliki pengalaman yang baik seperti itu. Pengguna mungkin perlu mengirim transaksi ke rantai target untuk menyelesaikan operasi.

Oleh karena itu, peningkatan pengalaman pengguna yang dapat dibawa oleh Intent menjadi lebih penting dan mendesak di dunia lintas-rantai.

Melalui Intent, operasi lintas rantai hanya akan mengharuskan pengguna untuk menandatangani, dan mereka tidak perlu lagi khawatir tentang aturan transaksi dan detail setiap rantai. Pengguna akan dapat mengoperasikan rantai yang berbeda dengan pengalaman pengguna yang sama, dan bahkan tidak akan merasakan fakta bahwa ada rantai yang berbeda.

ELEGAN

Nama lengkap SUAVE adalah Single Unifying Auction for Value Expression, tujuannya adalah menjadi pasar MEV yang terpadu di berbagai rantai. Di pasar ini, pengguna dapat mengekspresikan kondisi penutupan dan imbalan transaksi secara efisien. Pada saat yang sama, pelaksana (Executors) akan bersaing satu sama lain, dan akan bekerja sama secara efisien untuk menyelesaikan permintaan pengguna.

SUAVE dapat berfungsi sebagai kolam transaksi untuk blockchain dan juga berperan sebagai peran Builder yang bertanggung jawab untuk menghasilkan konten blok dari blockchain tersebut. Namun, SUAVE tidak dimaksudkan untuk menggantikan kolam transaksi dan fungsionalitas Builder yang ada dari blockchain, tetapi lebih untuk terhubung secara mulus ke blockchain yang ada dengan cara plug and play.

Setelah SUAVE terhubung ke blockchain, blockchain tersebut setara dengan memiliki Pembangun terdesentralisasi, sangat profesional, dan powerful yang merambah sumber transaksi blockchain yang beragam. Memiliki sumber transaksi blockchain yang beragam pada saat yang sama akan memberikan keuntungan besar di pasar MEV lintas domain yang akan tumbuh secara bertahap di masa depan. Pemangun dengan keunggulan ini akan lebih kompetitif daripada pemangun yang beroperasi pada satu rantai saja.

Dari Flashbot ke MEV-Boost ke SUAVE

Dari Flashbot hingga MEV-Boost, semangat yang mereka pegang adalah mengakui keberadaan MEV dan berusaha untuk membawa kegiatan ekonomi tersembunyi ke permukaan. Mereka bertujuan untuk membentuk pasar publik di mana siapa pun dapat berpartisipasi, untuk menghindari skenario di mana beberapa individu secara diam-diam mengendalikan dan mendominasi minat ekonomi yang besar ini, secara bertahap mengarah pada konsentrasi sumber daya di tangan mereka dan pada akhirnya memengaruhi desentralisasi dan keamanan seluruh jaringan blockchain.

Namun ketika orang-orang belajar lebih banyak tentang MEV, mereka secara bertahap menyadari bahwa selain pasar MEV yang matang di Ethereum, juga ada pasar MEV lintas-rantai dan lintas-batas. Pasar MEV lintas-batas ini akan jauh lebih besar dari Ethereum, dan transaksi lintas-rantai akan memiliki lebih banyak kesempatan untuk mengekstrak MEV daripada transaksi pada rantai yang sama.

Jika tidak ada seseorang seperti Flashbot untuk mengekspos pasar MEV lintas-rantai, membawanya ke permukaan, dan memungkinkan partisipasi yang adil bagi semua orang, sedikit individu yang mengeksploitasi MEV lintas-rantai akan memiliki keuntungan yang lebih besar, akhirnya memengaruhi keamanan seluruh jaringan blockchain.

Fenomena lain yang akan memengaruhi sentralisasi dan keamanan adalah Aliran Pesanan Pribadi: transaksi pengguna tidak lagi mengalir ke kolam transaksi publik, tetapi langsung ke Pencari atau Pembangun. Aliran Pesanan Pribadi dapat berasal dari Pencari atau Pembangun yang membeli hak untuk menghasilkan pendapatan dari transaksi pengguna, atau Pembangun menyediakan layanan menarik, seperti (1) pembatalan gratis transaksi atau pesanan DEX yang dikirim oleh pengguna, atau (2) menyediakan Pra-Konfirmasi, sebelum transaksi diterima, pengguna dipastikan seberapa cepat transaksi akan diterima, sehingga pengguna tidak perlu khawatir apakah transaksi tersebut akan diterima dan berapa lama waktu yang dibutuhkan untuk diterima.

Meskipun Aliran Pesanan Pribadi pada awalnya dapat menguntungkan pengguna, dalam jangka panjang, hal itu akan mengakibatkan sentralisasi. Pencari/Pembangun dengan Aliran Pesanan Pribadi akan memiliki keunggulan kompetitif dan mendapatkan lebih banyak manfaat dibandingkan dengan mereka yang tidak memiliki, menyebabkan dampak yang merugikan pada persaingan. Selain itu, karena tidak ada insentif untuk berbagi Aliran Pesanan Pribadi dengan Pencari/Pembangun baru, para pendatang baru ini akan berada dalam posisi yang merugikan saat memulai permainan.

Mengapa blok dari transaksi pengguna ke Bundle yang dibuat oleh Pencari harus dikumpulkan melalui Aliran Pesanan Pribadi? Hal ini karena konten transaksi dan Bundle bersifat publik dan tidak terenkripsi. Jika dilihat dan diperoleh oleh orang lain, hal ini dapat membahayakan pengguna atau Pencari. Misalnya, orang lain dapat mengekstrak MEV dari transaksi pengguna melalui serangan pincers atau membongkar Bundle, merebut MEV tersebut. Oleh karena itu, baik pengguna maupun Pencari saat ini harus mempercayai Builder, karena mereka perlu menyerahkan konten asli transaksi dan Bundle kepada Builder dan percaya bahwa Builder tidak akan menyebabkan kerusakan apa pun.

Kemunculan SUAVE adalah untuk menyelesaikan risiko sentralisasi yang disebabkan oleh MEV lintas batas dan Aliran Pesanan Pribadi.

Pertama, dengan mendirikan pasar publik yang melayani MEV lintas-rantai, pengguna atau Pencari dapat menyatakan kondisi pendapatan mereka untuk transaksi atau bundel di pasar ini. Misalnya, jika seorang pengguna memiliki dua transaksi yang perlu diproses ke Ethereum dan Arbitrum masing-masing, dan kedua transaksi harus disertakan dan dieksekusi sebelum waktu tertentu, mereka dapat menentukan kondisi-kondisi ini di pasar. Para Eksekutor di pasar (yang bisa menjadi Pencari atau Pembangun) akan bersaing untuk memenuhi permintaan ini untuk mendapatkan imbalan. Tetapi bagaimana pengguna atau Pencari bisa percaya untuk melemparkan transaksi atau bundel mereka ke pasar publik ini? Inilah tempat teknologi privasi masuk. Dengan mengenkripsi transaksi, pengguna atau Pencari tidak perlu lagi khawatir tentang potensi kerugian yang disebabkan oleh orang lain melihat transaksi mereka. Hanya dengan privasi transaksi, Aliran Pesanan Terbuka bisa terwujud.

SUAVE lebih lanjut mengusulkan konsep Privasi Terprogram, di mana pengguna atau pencari dapat memilih apakah akan mengungkapkan bagian-bagian tertentu dari transaksi atau konten bundel (seperti alamat kontrak pelaksanaan transaksi) daripada terbatas pada memilih antara enkripsi lengkap atau tanpa enkripsi.

Dibandingkan dengan transaksi yang sepenuhnya terenkripsi, transaksi yang mengungkapkan informasi spesifik dapat dimasukkan ke dalam bundel atau blok dengan lebih efektif dan cepat, dan bahkan menerima kickback, seperti yang dijelaskan dalam bagian MEV-Share artikel keempat. Dengan mengungkapkan informasi spesifik, Searcher bahkan dapat berkolaborasi satu sama lain. Searcher B dapat membangun di atas bundel Searcher A: bundel Searcher A mengikuti transaksi pengguna untuk arbitrase, dan bundel Searcher B mengikuti bundel Searcher A untuk arbitrase. Privasi sangat penting untuk aliran pesanan terbuka. Privasi memungkinkan Searcher untuk memiliki kesempatan untuk bekerja sama satu sama lain, saling menguntungkan daripada bersaing untuk peluang MEV.

Manfaat lain dari SUAVE

• Melalui SUAVE, transaksi DEX lintas rantai dapat memperoleh harga yang lebih baik, dan Intents lintas rantai dapat dieksekusi dengan lebih efisien.
• Jika SUAVE dianggap sebagai Builder yang besar namun terdesentralisasi, maka akan memiliki lebih banyak keuntungan daripada Builder yang terpusat karena mengumpulkan lebih banyak Aliran Pesanan, yang juga dapat menarik lebih banyak Builder untuk bergabung dengan SUAVE, dan dapat lebih lanjut Mengurangi risiko yang disebabkan oleh sentralisasi Builder.
• Melalui SUAVE, setiap rantai tidak perlu membangun kolam transaksi pribadinya sendiri dan pasar MEV rantai sendiri, dan dapat fokus sumber daya dan energinya pada menyelesaikan masalah lain atau menyediakan layanan yang lebih baik.

arsitektur SUAVE

Papan Buletin untuk Preferensi Pengguna

SUAVE dapat dijelaskan sebagai papan buletin 'Preferensi Pengguna'. Istilah 'Pengguna' di sini tidak selalu merujuk pada pengguna blockchain umum, tetapi Pencari juga bisa menjadi Pengguna SUAVE. Selanjutnya, 'Pengguna' akan merujuk kepada pengguna blockchain umum, dan 'Pengguna SUAVE' akan merujuk kepada pengguna SUAVE.

Preferensi Pengguna SUAVE mirip dengan Intent khusus yang berfokus pada pengurutan transaksi. Tidak seperti Intent umum yang mungkin ditemui pembaca di tempat lain, yang dapat menentukan berbagai kondisi. Mirip dengan cara pengguna menentukan preferensi dan kondisi dalam Intent, dalam Preferensi, Pengguna SUAVE menentukan preferensi atau kondisi untuk "transaksi atau pendapatan bundel masuk ke blok," seperti:

• “Saya ingin transaksi saya diurutkan sebelum transaksi 0xabcd dan disertakan sebelum blok 110050.” Sebenarnya, ini mirip dengan kondisi yang ditentukan oleh Bundle of Searcher saat menggunakan Flashbot.
• “Saya ingin Bundle saya dimasukkan dan mendatangkan 0.05 ETH sebagai pendapatan bagi saya.”
• “Saya ingin Niat A dan Niat B disertakan dalam blok 1001 dari rantai X dan blok 50900 dari rantai Y masing-masing.” \

Tips membaca: Pengguna juga dapat mengirimkan transaksi blockchain umum (tanpa menentukan Preferensi apa pun) ke SUAVE, yaitu, cukup menggunakan SUAVE sebagai kolam perdagangan umum atau Flashbot, seperti langsung mengirimkan transaksi transfer ETH atau transaksi Uniswap nya ke SUAVE itu.

Tentu saja, jika Anda hanya menetapkan kondisi, tidak perlu merancang arsitektur baru untuk melakukan ini, cukup gunakan Flashbot asli. Jadi sebenarnya, Preferensi yang ditentukan dalam SUAVE harus sesuai dengan imbalan, jika tidak, tidak ada yang akan bersedia untuk menyelesaikan Preferensi Anda secara bersyarat. Tentu saja, prasyarat pembayaran haruslah Preferensi telah tercapai.

Dengan membuat penunjukan Preferensi dan imbalan ke dalam kontrak pintar untuk dipenuhi, pihak-pihak permintaan (seperti pengguna atau Pencari) akan dapat mengajukan persyaratan Preferensi yang lebih rinci dan beragam, dan persyaratan ini dipenuhi melalui insentif ekonomi daripada Mengandalkan kebaikan Sang Pembangun.

• “Saya ingin transaksi saya diurutkan sebelum transaksi 0xabcd dan dimasukkan sebelum blok 110050. Jika tercapai, saya akan memberi Anda 3 ETH.”
• “Saya ingin Bundle saya dimasukkan dan membawa saya 0.05 ETH pendapatan. Jika tercapai, saya akan memberi Anda 0.02 ETH.”
• "Saya ingin Intent A dan Intent B masing-masing dimasukkan dalam blok ke-1001 dari rantai X dan blok ke-50900 dari rantai Y. Jika ini tercapai, saya akan memberi Anda 1,8 ETH "。

Arsitektur

SUAVE dapat dilihat terdiri dari tiga komponen: Lingkungan Preferensi, Pasar Eksekusi dan Bangunan Blok Terdesentralisasi.

• Lingkungan Preferensi adalah tempat yang menampung Preferensi Pengguna dan hadiah dari berbagai rantai, termasuk rantai SUAVE dan kolam transaksinya. Pengguna SUAVE mungkin menjadi pengguna umum atau Pencari.
• Pasar Eksekusi adalah kelompok Eksekutor profesional yang menemukan dan mengeksekusi Preferensi Pengguna (mengeksekusi Preferensi Pengguna dengan mengemasnya ke dalam Bundel) untuk mendapatkan imbalan. Eksekutor dapat menjadi Pencari atau Pembangun
• Pembangunan Blok Terdesentralisasi adalah proses menyusun beberapa Bundel menjadi blok untuk satu atau lebih rantai.

△ PE di sebelah kiri mengumpulkan Niat dan transaksi arbitrase di berbagai rantai, lalu Para Pelaksana di tengah mencoba memenuhi Preferensi ini dan mengemasnya ke dalam Bundel, dan memberikan Bundel ini kepada peran di sebelah kanan yang memiliki hak untuk memproduksi blok untuk merakit blok. Sumber gambar:https://writings.flashbots.net/the-future-of-mev-is-suave

SUAVE akan memiliki rantai dan kolam transaksi sendiri. SUAVE menyebut rantai tersebut sebagai Lapisan Penyelesaian dan kolam transaksi sebagai Lapisan Pesan.

Kontrak pintar dapat diterapkan di rantai untuk membuat kontrak antara Preferensi dan imbalan. Kolam transaksi akan diisi dengan transaksi di mana Pengguna SUAVE mendeklarasikan Preferensi dan Eksekutor menerima imbalan.

Siklus hidup transaksi SUAVE

1. Ekspresi Preferensi: Pengguna SUAVE menentukan Preferensi dan menawar salah satu atau lebih dari Niat/Transaksinya.
2. Optimisasi Eksekusi: Executor menemukan jalur eksekusi yang memenuhi Preferensi Pengguna, dan bahkan dapat menemukan jalur optimal untuknya.
3. Penyelesaian Preferensi: Bundle(s) Eksekutor berhasil disertakan dalam blok rantai target dan memenuhi Preferensi yang ditentukan oleh Pengguna SUAVE.
4. Penyelesaian Pembayaran: Oracle mengembalikan status rantai target ke Rantai SUAVE, dan Eksekutor menjalankan kontrak cerdas. Setelah kontrak mengonfirmasi bahwa Preferensi telah dipenuhi, imbalan Pengguna SUAVE diberikan kepada Eksekutor.

△ Preferensi empat langkah dari pembentukan hingga eksekusi hingga penyelesaian. Sumber gambar:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

MEVM

SUAVE perlu bisa menulis Preferensi dalam bahasa pemrograman dan mengonversinya menjadi kontrak pintar untuk memenuhi kontrak antara Pengguna SUAVE dan Eksekutor. SUAVE diharapkan merancang MEV spesifik EVM berdasarkan EVM - MEVM.

MEVM akan menambahkan kontrak Precompile baru dan tipe transaksi khusus untuk MEV. Preferensi Pengguna, Bundel Pengemasan, dan fungsi Pembangunan Blok semua dapat dengan mudah diselesaikan di MEVM.

Kode program contoh pada gambar di bawah menulis algoritma Pembangunan Blok Harga Gas Efektif (EGP) menggunakan kontrak Solidity dan pra-kompilasi MEVM.

EGP Block Building mengurutkan Bundles sesuai dengan Harga Gas yang diberikan oleh masing-masing Bundle. Bundles dengan Gas Price yang lebih tinggi akan diurutkan di bagian depan blok:

△ Fungsi merah muda dalam gambar adalah fungsi Precompile dari MEVM, yang dirancang khusus untuk digunakan MEV. Sumber gambar:https://writings.flashbots.net/mevm-suave-centauri-and-beyond

Tips membaca: Pelaksanaan algoritma Pembangunan Blok sebenarnya tidak terjadi pada rantai SUAVE Chain, tetapi Pembangun Blok mensimulasikan pelaksanaannya di luar rantai (seperti node akan mensimulasikan pelaksanaan transaksi secara lokal), sehingga proses pelaksanaan ini sebenarnya tidak akan menjadi transaksi yang memakan ruang blok dan sumber daya komputasi SUAVE Chain, dan juga tidak akan terbatas oleh kinerja output SUAVE Chain.

Melalui komposabilitas kontrak EVM, Pencari dan Pencari atau Pencari dan Builder akan dapat bekerja sama melalui kontrak, menggantikan hubungan kepercayaan sepihak yang asli. Kerja sama juga akan meningkatkan efisiensi Bundel dan mengekstrak lebih banyak MEV, yang dapat menguntungkan setiap peserta dalam rantai pasokan MEV. Selain itu, peserta dapat langsung menggunakan alat pengembangan berbasis EVM dan infrastruktur, seperti Penyedia RPC, alat uji coba seperti Foundry, dll., dan pengalaman pengembangan akan sangat baik.

Selain itu, MEVM akan menyediakan fungsi privasi transaksi, karena tanpa privasi, tidak ada kemungkinan kerjasama. Tanpa privasi, Pencari harus khawatir MEV mereka akan dicuri. Pada tahap awal, privasi ini akan dicapai melalui hardware terpercaya SGX. Transaksi akan dienkripsi dan kemudian dikirim ke SGX untuk dieksekusi. Dipercayai bahwa SGX akan menjalankan kode program yang ditunjuknya tanpa mencuri MEV sesuka hati. Di masa depan, ketika teknologi kriptografi canggih lainnya secara bertahap matang, kriptografi dapat digunakan untuk menggantikan hardware terpercaya. Untuk lebih detailnya, silakan merujuk ke artikel sebelumnya pada Mempools Terenkripsi.

Saran membaca: Namun demikian, ada juga kerugian berdasarkan EVM, misalnya, EVM terlalu ekspresif: Malahan, untuk menulis fungsi yang diperlukan oleh MEV, Anda tidak memerlukan banyak Opcode dalam EVM. Mengizinkan penggunaan Opcode ini memungkinkan orang yang bersedia menulis eksekusi yang sangat kompleks. , dan kemudian biarkan transaksi gagal di akhir eksekusi, menyebabkan node membuang banyak sumber daya komputasi, yang merupakan serangan DoS. Proyek Anoma mendesain ulang bahasa pemrograman dan lingkungan eksekusi khusus untuk mengekspresikan dan mengeksekusi Intents. Di masa depan, SUAVE juga dapat menggunakan arsitektur Anoma untuk menggantikan MEVM.

Plug-N-Play SUAVE

Jika pengembang blok atau Validator dari suatu rantai mengetahui adanya SUAVE dan bermaksud untuk menggunakan SUAVE, maka SUAVE akan dianggap sebagai Pembangun Blok. Jika SUAVE memberikan harga penawaran yang lebih tinggi untuk blok yang dibangunnya, maka Penambang atau Validator akan menggunakan blok SUAVE. Mengambil MEV-Boost saat ini di Ethereum sebagai contoh, blok yang disusun oleh SUAVE akan dikonversi menjadi format yang sesuai dengan mekanisme penawaran MEV-Boost melalui plug-in yang disediakan oleh SUAVE. Proposer tidak perlu melakukan perubahan apa pun untuk mengadopsi blok SUAVE.

Jika pengembang blok atau Validator dari suatu rantai tidak mengetahui keberadaan SUAVE, maka Pengeksekusi SUAVE akan menawar untuk menerima Bundelnya melalui aturan biaya rantai tersebut.

Tantangan MEV lintas-rantai

Setiap rantai memiliki pengembang blok dan validatornya sendiri. Blok B1 dari SUAVE yang diterima oleh rantai X tidak berarti bahwa blok B2 juga akan diterima dengan sukses oleh Validator dari rantai Y. Mekanisme produksi blok dan pasar dari rantai X dan rantai Y adalah independen. Kecuali kedua rantai X dan Y menggunakan Shared Sequencer, dan Sequencer yang sama menghasilkan blok untuk kedua rantai secara bersamaan, maka hanya dengan menggabungkan SUAVE kita dapat memastikan Inklusi Atomik: kedua rantai tidak boleh “mengumpulkan transaksi (atau blok) tertentu bersama”. Yuan)”, atau “tidak ada pendapatan sama sekali”.

Dan bahkan jika Sequencer Bersama dapat menjamin Atomic Inclusion, itu tidak berarti bahwa transaksi akan dieksekusi “berhasil” setelah dimasukkan. Jika kedua transaksi tidak dieksekusi “berhasil”, itu berarti bahwa MEV lintas-rantai telah gagal. Dengan asumsi bahwa Pengguna SUAVE ingin menyelesaikan arbitrase lintas-rantai, transaksi pada kedua rantai harus dihasilkan secara real-time dan dieksekusi dengan sukses sebelum dia bisa mendapatkan manfaat:

• Jika Pengguna SUAVE tidak bersedia menanggung risiko kegagalan eksekusi transaksi, maka Preferensinya akan meminta agar kedua transaksi harus berhasil dieksekusi sebelum mereka diselesaikan, dan kemudian Pengeksekusi akan dibayar dan Pengeksekusi akan menanggung risiko. Dia dapat membatasi “hasil eksekusi yang berhasil” dengan menentukan status di rantai, misalnya, menentukan bahwa sebuah kontrak harus mengeluarkan Event tertentu, atau menentukan seberapa besar saldo token dari alamat tertentu harus lebih besar dari. Selanjutnya, Pengeksekusi yang bersedia mengambil risiko akan mencoba membuat kedua transaksi menjadi real-time dan berhasil dieksekusi. Jika hanya salah satunya yang diterima atau eksekusi salah satu transaksi “gagal”, Pengeksekusi tidak akan mendapatkan hadiah.
• Jika Pengguna SUAVE bersedia mengambil risiko, maka Preferensinya mungkin hanya memerlukan kedua transaksi diterima, dan juga tidak masalah jika eksekusi transaksi gagal (yaitu, transaksi Revert). Pengeksekusi masih akan mencoba yang terbaik untuk mengeksekusi kedua transaksi dengan sukses (eksekusi sukses dapat menghasilkan imbalan yang lebih tinggi), tetapi selama ada pendapatan, Anda dapat mendapatkan imbalan.

Mengambil gambar di bawah ini sebagai contoh, Pengguna SUAVE ingin melakukan arbitrase transaksi lintas rantai antara Rollup 1 dan Rollup 2: membeli satu ETH dengan harga lebih rendah di Rollup 1, dan menjual satu ETH dengan harga lebih tinggi di Rollup 2.

Jika kedua perdagangan dibayar secara real time dan dieksekusi dengan sukses, Pengguna SUAVE dapat menghasilkan selisih harga. Skenario 1 dan 2 dalam tabel di gambar adalah "Pengguna SUAVE bersedia menanggung risiko sendiri" dan "Eksekutor bersedia menanggung risiko" masing-masing.

Tiga kolom paling bawah dari tabel adalah “imbalan untuk kedua keberhasilan”, “imbalan untuk hanya satu keberhasilan” dan “hasil akhir untuk hanya satu keberhasilan”:

• Hadiah untuk kedua transaksi sukses (Pengguna SUAVE mendapatkan selisih harga):
  • Skenario 1: Pengguna SUAVE membayar biaya penanganan $50 kepada Executor.
  • Skenario 2: Pengguna SUAVE membayar biaya penanganan $70 kepada Executor (lebih mahal karena Executor menanggung risiko).
• Hanya ada satu imbalan atas kesuksesan (Pengguna SUAVE tidak menghasilkan spread):
  • Skenario 1: Pengguna SUAVE membayar biaya penanganan $25 kepada Executor. Pengguna SUAVE menyerap risiko sendiri.
  • Skenario 2: Pengguna SUAVE tidak perlu membayar biaya atau mengambil risiko.
• Hanya ada satu hasil sukses (Pengguna SUAVE tidak mendapatkan spread):
  • Skenario 1: Pengguna SUAVE membayar biaya penanganan $25 kepada Executor dan memiliki ETH ekstra di tangan.
  • Skenario 2: Pengguna SUAVE tidak perlu membayar biaya penanganan kepada Eksekutor dan tidak akan memiliki tambahan ETH di tangan. Dan Eksekutor memiliki satu ETH lagi di tangannya.

△ Hasil eksekusi yang berbeda di bawah situasi yang berbeda. Sumber gambar:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

MEV lintas-rantai memerlukan Eksekutor untuk memiliki modal, bersedia mengambil risiko, dan memiliki teknologi yang cukup untuk memastikan pendapatan dan eksekusi yang sukses secara real-time, Atomic. Ini bisa menjadi pekerjaan yang menguntungkan namun memiliki batasan yang relatif tinggi.

Mengapa SUAVE membutuhkan rantainya sendiri?

Mengapa kita tidak bisa hanya mentransfer dan berbagi Preferensi melalui jaringan P2P? Karena jaringan P2P murni tidak dapat mencegah jaringan penuh dengan Preferensi tanpa henti (yaitu serangan DoS). Jika itu adalah rantai, serangan DoS dapat dicegah melalui biaya penanganan.

Mengapa SUAVE tidak menggunakan rantai yang sudah ada? Karena SUAVE memerlukan fungsinya sendiri (MEV) dan pengaturan rantai sendiri seperti waktu blok dan ukuran blok. Jika Anda membangunnya langsung di Ethereum, Anda akan menghadapi masalah seperti biaya yang terlalu tinggi, waktu blok yang terlalu lama, dan fungsi terbatas.

Selain itu, karena SUAVE perlu memperoleh informasi dari rantai lain untuk memverifikasi apakah Preferensi terpenuhi, Rantai SUAVE independen dapat menjaga netralitas dengan mengumpulkan informasi dari semua rantai lain.

Namun, SUAVE memiliki rantai sendiri, yang juga berarti bahwa (1) Pengguna SUAVE mungkin perlu mentransfer aset dari rantai lain ke Rantai SUAVE untuk menggunakan SUAVE, dan (2) SUAVE perlu mengandalkan Oracle untuk melaporkan informasi dari rantai lain. Ini berarti bahwa SUAVE sendiri memiliki kebutuhan kepercayaan tambahan untuk Oracle. Jika Oracle tidak aman, itu akan memengaruhi keamanan kontrak di SUAVE.

Tip membaca: Belum banyak detail tentang apakah SUAVE akan memiliki token sendiri, apakah aset perlu ditransfer ke Rantai SUAVE untuk digunakan, atau bagaimana mentransfer ke Rantai SUAVE. Hanya disebutkan dalam video dan artikel 'Pengguna SUAVE harus pertama-tama mentransfer aset dari rantai lain ke Rantai SUAVE sebelum mereka dapat menggunakannya.'

Model desain dan keamanan SUAVE Chain itu sendiri masih dalam pembahasan. Jika SUAVE Chain adalah Rollup di Ethereum, maka Anda dapat langsung menggunakan mekanisme Rollup sendiri untuk transfer aset dan membaca informasi Rollup lain. Ini akan lebih baik daripada bergantung pada rollup lainnya. Teknologi lintas-rantai dan layanan Oracle membawa banyak keamanan.

Jika Validator Rantai SUAVE dapat digabungkan dengan Eigenlayer, akan lebih aman dan dapat diandalkan untuk langsung menggunakan Validator Ethereum sebagai Validator Rantai SUAVE daripada menghasilkan seperangkat Validator oleh SUAVE sendiri. Namun tentu saja, desain-desain ini juga memiliki kekurangan yang sesuai. Untuk diskusi lebih lanjut tentang desain Rantai SUAVE, silakan merujuk ke artikel ini.

Ringkasan tantangan SUAVE

• Waktu blok Rantai SUAVE: Waktu blok Rantai SUAVE harus cukup pendek agar Pengguna SUAVE dapat menyatakan Preferensinya untuk dieksekusi oleh Pemegang Kendali SUAVE. Jika waktu Rantai SUAVE lebih lama dari rantai yang terhubung (seperti Solana atau Rollup lainnya), mudah bagi Pengguna SUAVE untuk tidak memiliki waktu untuk memberi tahu Pemegang Kendali SUAVE bahwa ia ingin transaksi disertakan dalam blok berikutnya dari suatu rantai tertentu. Sebuah blok telah diproduksi.
• Risiko Oracle: Oracle bertanggung jawab untuk memberikan informasi tentang rantai lain, dan mungkin juga bertanggung jawab untuk mentransfer aset Pengguna SUAVE ke Rantai SUAVE, sehingga pentingnya Oracle bukanlah hal yang remeh.
• Pengalaman penggunaan lintas-rantai: Pengguna SUAVE perlu mentransfer aset ke Rantai SUAVE yang juga merupakan kekurangan dalam pengalaman penggunaan.
• Model ekonomi: Apakah SUAVE perlu mengeluarkan asetnya sendiri, bagaimana mendorong Validator SUAVE, bagaimana mencegah mekanisme insentif ekonomi SUAVE memengaruhi keamanan ekonomi rantai lain, dll.
• Teknologi privasi: Dalam jangka pendek, SUAVE akan harus mengandalkan perangkat keras terpercaya seperti SGX untuk menyediakan fungsi privasi transaksi, tetapi dalam jangka panjang akan harus beralih ke pendekatan yang lebih terdesentralisasi dan aman untuk mengurangi risiko.
• Bahasa Preferensi yang Sesuai: Apakah EVM cocok sebagai sarana untuk menyatakan dan menjalankan Preferensi?

Ringkasan dan sorotan

• Munculnya SUAVE adalah untuk (1) mengatasi risiko sentralisasi yang disebabkan oleh perbedaan keuntungan dari Builders yang dapat dihasilkan dari Cross Domain MEV, dan (2) membuka pintu bagi kolaborasi antara Searchers / Builders melalui pengenalan privasi yang dapat diprogram, mengurangi risiko sentralisasi yang mungkin timbul dari Aliran Pesanan Pribadi.
• Transaksi yang sepenuhnya pribadi membuat pekerjaan Pencari sulit, karena mereka tidak dapat secara efektif Back-Run transaksi pengguna, yang mengakibatkan penurunan efisiensi on-chain. Namun, pengguna tidak perlu memilih antara 'privasi' dan 'efisiensi.' Sebaliknya, mereka dapat menggunakan privasi yang dapat diprogram untuk memilih untuk mengungkapkan informasi parsial, membuat pekerjaan Pencari lebih mudah dan meningkatkan efisiensi on-chain serta imbalan Back-run.
• Dengan SUAVE, Pengguna SUAVE dapat menentukan preferensi dan berbagai kondisi Intent/transaksi mereka, sementara sisanya ditangani oleh Eksekutor profesional untuk mencapai kondisi tersebut dan mengklaim hadiah yang dijanjikan oleh Pengguna SUAVE setelah terpenuhi.
• SUAVE akan memiliki rantai sendiri karena P2P murni tidak dapat mencegah serangan DoS, dan SUAVE akan memiliki fitur dan pengaturan unik sendiri untuk rantai (MEV), sehingga rantai yang ada tidak dapat langsung digunakan. Rantai ini akan didasarkan pada modifikasi EVM, menambahkan fungsionalitas yang diperlukan untuk MEV, yang disebut MEVM.
• MEV lintas-rantai adalah operasi yang sangat menantang, karena membutuhkan penjaminan Inklusi Atomik dan menjamin “eksekusi sukses” dari transaksi. Pengguna SUAVE dapat menentukan status untuk mensyaratkan bahwa transaksi harus dieksekusi dengan sukses sebelum memberikan imbalan kepada Eksekutor, dengan demikian mentransfer risiko kepada Eksekutor. Sequencer Bersama dapat menjamin Inklusi Atomik tetapi tidak menjamin bahwa transaksi akan dieksekusi “dengan sukses.”
• SUAVE sebagai rantainya sendiri juga berarti bahwa Pengguna SUAVE perlu mentransfer aset ke Rantai SUAVE sebelum mereka dapat menggunakan SUAVE. Selain itu, Oracle yang aman diperlukan untuk melaporkan informasi dari rantai lain ke Rantai SUAVE untuk memverifikasi apakah Preferensi telah terpenuhi.
• SUAVE masih menghadapi banyak tantangan teknis dan desain, seperti Oracle yang aman, teknik privasi yang aman, bahasa preferensi, dan model ekonomi, antara lain.

Disclaimer：

1. Artikel ini diambil dari [ imToken Labs]. Semua hak cipta adalah milik penulis asli [Nic]. Jika ada keberatan terhadap pencetakan ulang ini, silakan hubungi Belajar Gatetim, dan mereka akan menanganinya dengan segera.
2. Penafian Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.