Bagaimana SUAVE Dapat Alamat Sentralisasi Builder

LanjutanJun 18, 2024
Ethereum selalu dianggap sebagai salah satu jaringan yang paling terdesentralisasi, tetapi masalah sentralisasi pembangun menjadi semakin serius. Kripto KOL 100y mengeksplorasi kemajuan yang telah dibuat Flashbots dalam mengatasi eksternalitas negatif MEV pada Ethereum dan memeriksa bagaimana SUAVE pada akhirnya bertujuan untuk memecahkan masalah yang berkaitan dengan MEV, termasuk sentralisasi pembangun.
Bagaimana SUAVE Dapat Alamat Sentralisasi Builder

1. Tantangan Berikutnya untuk Ethereum: Sentralisasi Pembangun

Ethereum sering dianggap sebagai salah satu jaringan yang paling terdesentralisasi bersama Bitcoin. Karena persyaratan perangkat keras yang relatif rendah untuk mengoperasikan node Ethereum, hampir semua orang dapat menjalankan node. Ada beberapa redundansi, jaringan menawarkan lebih dari 1 juta validator.

(Pangsa pasar pembangun | Sumber: Relayscan)

Namun, masalah kritis yang sering diabaikan adalah sentralisasi pembangun. Pembangun adalah entitas yang mengumpulkan transaksi dan bundel untuk membuat blok di jaringan Ethereum. Selama tujuh hari terakhir, 95% blok dihasilkan oleh hanya tiga pembangun.

Meskipun demikian, seperti yang telah Vitalik Buterin tunjukkan, sentralisasi pembangun tidak menimbulkan ancaman berat bagi keamanan keseluruhan jaringan Ethereum. Ini karena, bahkan jika bangunan blok agak terpusat, validator (pengusul) yang memverifikasi blok-blok ini tetap terdesentralisasi. Meskipun demikian, sentralisasi pembangun dapat menyebabkan berbagai masalah seperti sensor, pencarian sewa, dan masalah kehidupan.

Artikel ini akan mengeksplorasi perjalanan Flashbots dalam mengatasi eksternalitas negatif dari MEV Ethereum dan memeriksa bagaimana SUAVE pada akhirnya dapat menyelesaikan masalah yang berkaitan dengan MEV, termasuk sentralisasi pembangun.

2. Kemajuan Sejauh Ini

2.1 Proof of Work

Sebelum upgrade The Merge, jaringan Ethereum beroperasi pada konsensus PoW, mirip dengan jaringan Bitcoin, di mana penambang menggunakan perangkat keras untuk menambang blok. Selama periode ini, ketika pencari mengidentifikasi peluang MEV di mempool, satu-satunya cara untuk mendapatkan transaksi atau bundel mereka termasuk dalam blok adalah melalui lelang gas prioritas (PGA), di mana mereka menawar biaya gas lebih tinggi daripada pencari lainnya.

Ada masalah mendasar dengan pendekatan ini. Pertama, MEV mencuri adalah masalah. Penambang dapat melihat isi transaksi atau bundel yang dikirimkan oleh pencari dan, alih-alih memasukkannya ke dalam blok dengan biaya prioritas, mereka dapat menyalin transaksi ini dan mencuri MEV itu sendiri. Dengan demikian, pencari harus mempercayai penambang untuk mendapatkan keuntungan MEV.

Masalah kedua adalah kemacetan jaringan. Setiap kali peluang MEV muncul, pencari bersaing dengan menawar biaya prioritas yang lebih tinggi, yang menyebabkan peningkatan kemacetan di jaringan Ethereum. Ini membuat biaya transaksi rata-rata mahal dan tidak dapat diprediksi, berdampak negatif pada pengguna biasa.

(Lelang Flashbots | Sumber: Flashbots)

Untuk mengatasi eksternalitas negatif MEV di jaringan PoW Ethereum, Flashbots memperkenalkan Flashbots Auction, yang terdiri dari mev-geth dan mev-relay. Komponen utamanya adalah: 1) penambang daftar putih, 2) membangun mempool pribadi, dan 3) menerapkan sistem lelang penawaran tertutup.

Pengguna dan pencari dapat mengirimkan transaksi atau bundel ke mempool pribadi Lelang Flashbots, yang kemudian dikirim ke penambang yang masuk daftar putih menggunakan klien mev-geth melalui mev-relay terpusat. Pencari menyatakan tawaran untuk bundel mereka, dan penambang menggunakan mev-geth untuk memasukkan bundel penawaran tertinggi di blok.

Berbeda dengan sistem sebelumnya, pencari menggunakan mempool pribadi, sehingga tindakan mereka tidak berdampak pada pasar Ethereum gas, dan mereka tidak dapat melihat tawaran pencari lain, mengurangi persaingan. Akibatnya, Lelang Flashbots secara efektif mengurangi kemacetan di jaringan Ethereum. Namun, memasukkan penambang ke daftar putih masih diperlukan karena mereka masih bisa melihat konten bundel yang dikirimkan oleh pencari.

(Sumber: Flashbots)

Flashbots Auction diadopsi secara luas, dengan lebih dari 90% adopsi mev-geth. Ini secara signifikan mengurangi transaksi MEV yang gagal dan menurunkan biaya gas rata-rata di jaringan Ethereum, secara efektif mengurangi banyak eksternalitas negatif yang terkait dengan MEV.

2.2 Proof of Stake (PoS)

Pada September 2022, jaringan Ethereum beralih dari PoW ke PoS dengan aktivasi peningkatan The Merge. Proses termasuk transaksi yang dikirimkan pengguna dalam blok sebagian besar tetap tidak berubah dari PoW. Namun, ada masalah kritis dengan mengadopsi Lelang Flashbots secara langsung: daftar putih.

Secara PoW Ethereum, penambang secara fisik memiliki perangkat keras mereka, membuat proses daftar putih relatif mudah. Namun, dengan beralih ke PoS, berbagai entitas dapat berpartisipasi dalam memvalidasi secara anonim, membuat daftar putih menjadi sangat sulit.

Untuk mengatasi eksternalitas negatif MEV pada PoS Ethereum, Flashbots memperkenalkan protokol baru yang disebut MEV-Boost. Roadmap jaringan Ethereum mencakup peningkatan PBS (Proposer-Builder Separation) untuk mendesentralisasikan MEV, dan MEV-Boost mengimplementasikan bagian dari PBS.

Dalam pengaturan baru ini, pembangun blok menerima transaksi dan bundel dari pengguna dan pencari untuk membuat blok penuh yang paling berharga, sementara pengusul memilih blok penuh tawaran tertinggi dari pembangun blok dan menyebarkannya ke jaringan. Tidak seperti mev-geth, MEV-Boost bertindak sebagai sespan ke klien konsensus, membuatnya kompatibel dengan jenis klien apa pun.

Berikut cara MEV-Boost beroperasi:

(MEV-Boost | Sumber: EigenLayer)

  1. Blok pembangun menerima transaksi dari pencari dan aliran pesanan pribadi, menggunakan algoritma ekstraksi MEV mereka untuk menyusun ulang transaksi untuk profitabilitas maksimum. Mereka kemudian membuat blok penuh dan mengajukan tawaran ke relai.
  2. Relai memverifikasi validitas blok yang diterima dari pembangun dan menyimpannya.
  3. Relai mengirimkan header blok, bersama dengan tawaran, ke pengusul.
  4. Pengusul memilih header blok dengan tawaran tertinggi dari yang dikirim oleh relai dan menandatanganinya.
  5. Relai mengungkapkan konten blok lengkap yang sesuai dengan header yang ditandatangani kepada pengusul.
  6. Pengusul mengirimkan blok lengkap ke jaringan dan mengumpulkan tawaran yang dilampirkan oleh pembuat blok.

(Sumber: mevboost.pics)

Dari perspektif Ethereum validator, MEV-Boost menawarkan keuntungan yang signifikan: tidak perlu proses daftar putih. Validator cukup menjalankan MEV-Boost Flashbots, dan pembuat blok hanya mengekstrak MEV nilai tertinggi dan mengirimkannya sebagai tawaran. Ini berarti validator dapat memperoleh pendapatan MEV tanpa memerlukan algoritma ekstraksi MEV mereka sendiri. Akibatnya, keuntungan MEV terdesentralisasi daripada terkonsentrasi di antara beberapa entitas.

(Sumber: mevboost.pics)

Meskipun merupakan middleware eksternal daripada protokol bawaan, MEV-Boost telah berhasil diadopsi oleh lebih dari 90% Ethereum validator untuk jangka waktu yang lama. Meskipun ada kelemahan bahwa pembangun dan pengusul harus mempercayai relai, jumlah relai telah meningkat menjadi delapan, mengurangi dominasi relai Flashbots dan mengurangi masalah terkait seperti sensor.

3. Sentralisasi Pembangun

3.1 Mengapa Pembangun Cenderung Menuju Sentralisasi

Sementara MEV-Boost telah mengurangi banyak eksternalitas negatif yang terkait dengan MEV, masalah sentralisasi pembangun, yang disebutkan sebelumnya, tetap belum terselesaikan. Saat ini, sekitar 90% dari blok jaringan Ethereum dibuat oleh hanya tiga hingga empat pembangun blok. Tetapi mengapa pembangun blok cenderung terpusat? Ada dua alasan utama:

Alur Pesanan Eksklusif (EOF)

Pertama, pasar pembuat blok pada dasarnya adalah pasar pemenang-mengambil-semua. Bayangkan Anda adalah seorang pencari yang telah mengidentifikasi peluang ekstraksi MEV dan menggabungkannya. Pembangun mana yang akan Anda kirimi bundel Anda? Meskipun Anda dapat mengirimkannya ke semua pembangun, semakin banyak pembangun yang Anda libatkan, semakin tinggi risiko pencurian MEV, karena pembangun dapat melihat konten bundel. Oleh karena itu, strategi optimal Anda adalah mengirim bundel hanya ke beberapa pembangun teratas dengan probabilitas inklusi blok tertinggi.

(Sumber: Frontier Research, Juni 2023)

Grafik di atas menunjukkan bahwa pembangun yang menerima lebih banyak bundel dari pencari memiliki probabilitas penyertaan blok yang lebih tinggi. Fenomena ini mempercepat roda gila sentralisasi: jika pembangun menerima lebih banyak bundel dari pencari, itu lebih mungkin untuk membangun blok yang lebih menguntungkan. Akibatnya, blok-blok ini lebih mungkin diadopsi oleh pengusul di jaringan Ethereum, memberi insentif kepada lebih banyak pencari untuk mengirim bundel mereka ke pembangun itu. Mengirim bundel ke pembangun yang kurang dominan dapat mengakibatkan keterlambatan dalam inklusi blok, membuat prediksi Gas Fee sulit dan berpotensi kehilangan peluang ekstraksi MEV.

Di luar kecenderungan alami menuju sentralisasi ini, pembangun dapat mencari transaksi atau bundel tambahan melalui EOF. Misalnya, pembuat tertentu mungkin menawarkan jaminan privasi atau bagian dari MEV yang diekstraksi kepada pengguna dan pencari yang mengirim transaksi atau bundel secara eksklusif kepada mereka. Aliran pesanan tambahan ini, yang tidak dapat diakses oleh pembangun lain, semakin mempercepat sentralisasi pembangun.

Memang, seperti yang ditunjukkan pada grafik, BloXroute memiliki tingkat inklusi blok yang jauh lebih tinggi dibandingkan dengan rekan-rekannya. Ini karena BloXroute beroperasi tidak hanya sebagai pembuat blok tetapi juga sebagai layanan relai, memberikan keuntungan latensi dalam memproses transaksi. Selain itu, BloXroute sumber EOF melalui layanan seperti BackRunMe.

(MEV distribusi | Sumber: BloXroute)

BackRunMe memungkinkan pengguna untuk mengirimkan transaksi pribadi, melindungi mereka dari serangan berbahaya seperti serangan front-running dan sandwich. Selain itu, jika keuntungan MEV dihasilkan dari backrunning transaksi pribadi yang dikirimkan ke BackRunMe, keuntungan didistribusikan sesuai dengan rasio yang ditunjukkan pada grafik. Pengguna dan pencari dapat menikmati berbagai manfaat dengan menggunakan UI swap BackRunMe atau hanya mengubah RPC mereka untuk mengirimkan transaksi.

Jadi, apa yang bisa dilakukan pembuat blok baru? Sayangnya, mereka memiliki pilihan terbatas selain meningkatkan pangsa pasar mereka dengan kerugian atau menawarkan layanan untuk menarik pengguna dan EOF pencari. Pendekatan sebelumnya, yang dikenal sebagai strategi subsidi blok, melibatkan penetapan tawaran yang lebih tinggi daripada keuntungan MEV yang dihasilkan dari blok bangunan untuk meningkatkan tingkat inklusi blok. Misalnya, pembuat f1b berhasil menggunakan strategi ini untuk meningkatkan jumlah pencari mereka dengan cepat.

MEV lintas domain

Semakin banyak aliran pesanan yang dapat diakses oleh pembuat blok, semakin tinggi kemungkinan menghasilkan blok yang lebih menguntungkan. Jika beberapa pembuat blok juga membuat blok untuk jaringan lain, mereka tidak hanya dapat mengakses aliran pesanan dari jaringan Ethereum tetapi juga aliran pesanan eksternal. Kemampuan ini kemungkinan akan mengarah pada sentralisasi lebih lanjut di sekitar pembangun ini.

3.2 Apa yang Harus Kita Lakukan?

Kami telah mengeksplorasi mengapa pasar pembangun cenderung terpusat. Meskipun sentralisasi pembangun tidak menimbulkan ancaman keamanan yang parah karena sifat desentralisasi pengusul (validator) yang memverifikasi dan menyebarkan blok, itu masih dapat menyebabkan masalah seperti 1) sensor, 2) pencarian sewa, dan 3) masalah kehidupan.

Sensor berpotensi dapat diatasi dengan fitur Ethereum protokol di masa mendatang seperti crList, yang secara asli akan memaksa pembangun untuk memasukkan semua transaksi seperti yang dipersyaratkan oleh pengusul. Namun, mengatasi perburuan rente di pasar monopolistik dan menyelesaikan masalah kehidupan karena downtime lebih menantang.

Oleh karena itu, solusi terbaik adalah mencegah sentralisasi pembangun sejak awal dengan mengurangi penyebab utamanya — EOF dan MEV lintas domain. Untuk mengatasi masalah ini, Flashbots memperkenalkan Single Unifying Auction for Value Expression (SUAVE) protokol. (Perlu dicatat bahwa SUAVE bukan satu-satunya solusi potensial untuk sentralisasi pembangun; untuk berbagai solusi potensial lainnya, lihat Jon Charbonneau 'Decentralizing the Builder Role').

4. Ini dia SUAVE

4.1 TL; DR

SUAVE berfokus pada penanganan dua faktor utama yang berkontribusi terhadap sentralisasi pembangun: EOF dan MEV lintas domain. Pertama, SUAVE dapat menerima transaksi dari semua jaringan, memungkinkan pembangun terdesentralisasi untuk secara inheren mengekstrak MEV lintas domain. Kedua, SUAVE mengoptimalkan kondisi bagi pengguna dengan menangani preferensi secara pribadi dan menawarkan bagian dari keuntungan MEV.

4.2 Ikhtisar

(Ikhtisar SUAVE | Sumber: Flashbots)

SUAVE adalah blockchain terpisah dari jaringan Ethereum, menawarkan mempool plug-and-play dan layanan pembangun terdesentralisasi yang dapat digunakan oleh banyak jaringan. Hal ini memungkinkan jaringan lain untuk melakukan outsourcing proses kompleks manajemen mempool dan pembangunan blok terdesentralisasi ke SUAVE. SUAVE terdiri dari tiga komponen utama:

Lingkungan Preferensi Universal

Pengguna dan pencari mengirimkan transaksi, bundel, maksud, dan ekspresi preferensi lainnya ke mempool SUAVE, bukan mempool jaringan asli, bersama dengan tawaran mereka. Di SUAVE, preferensi ini diperlakukan sebagai jenis transaksi asli. Dengan menggabungkan preferensi dari berbagai domain ke dalam satu mempool, kemungkinan eksekusi optimal meningkat. Pengaturan ini menguntungkan pembangun dengan menurunkan hambatan masuk dan meningkatkan potensi keuntungan.

Pasar Eksekusi Optimal

Pelaksana (Pencari, Pembangun, dll.) memantau mempool SUAVE dan bersaing untuk membuat bundel dengan kondisi eksekusi terbaik. Konsep utama yang diperkenalkan di sini adalah pesanan flow auction (OFA).

Dalam model MEV-Boost tradisional, keuntungan MEV mengalir dalam satu arah dari pengguna ke pencari ke pembangun ke pengusul. Namun, dengan OFA, pelaksana bersaing untuk preferensi pengguna, memungkinkan pengguna untuk juga menerima bagian dari keuntungan MEV. Strategi ini mirip dengan layanan seperti BackRunMe, yang bertujuan untuk menarik lebih banyak EOF dengan mendistribusikan kembali beberapa keuntungan MEV kepada pengguna dan pencari. Selain itu, SUAVE memastikan privasi preferensi dalam mempool, melindunginya dari serangan MEV berbahaya.

Perbedaannya adalah, sementara strategi semacam itu dapat mengarah pada sentralisasi pembangun tertentu di pasar pembangun saat ini, SUAVE menyematkan OFA ke dalam protokol itu sendiri, memberikan semua pembangun terdesentralisasi akses ke preferensi ini. Konsep OFA, seperti yang diusulkan oleh Flashbots, sudah diterapkan di jaringan Ethereum melalui MEV-Share dan nantinya akan dimasukkan ke dalam SUAVE.

Bangunan Blok Terdesentralisasi

Pada komponen sebelumnya, sebagian besar preferensi menemukan rute eksekusi optimalnya. Pembangun blok terdesentralisasi kemudian menggunakan informasi ini untuk membangun blok parsial atau penuh yang memaksimalkan keuntungan MEV, yang kemudian mereka sampaikan ke validator berbagai jaringan.

Tidak semua validator jaringan lain dapat menggunakan SUAVE, mirip dengan bagaimana tidak semua Ethereum validator menggunakan MEV-Boost. Validator yang mendengarkan SUAVE dapat menerima blok SUAVE dan menambahkan blok yang menguntungkan ke jaringan mereka. Jika mereka SUAVE-tidak sadar, pembangun blok SUAVE harus berpartisipasi dalam lelang gas prioritas (PGA) untuk memasukkan blok mereka. Setelah preferensi terpenuhi dalam rantai tujuan, oracle memberi tahu jaringan SUAVE, dan tawaran dikirim ke pelaksana untuk penyelesaian.

4.3 MEVM

SUAVE adalah blockchain yang menggunakan MEVM sebagai lingkungan eksekusinya. MEVM dibangun di atas kerangka kerja EVM, dengan prakompilasi tambahan untuk kasus penggunaan MEV. Pengembang dapat menggunakan Solidity untuk membuat aplikasi MEV sebagai smart contract, memungkinkan pembangunan terdesentralisasi dari infrastruktur terkait MEV yang sebelumnya terpusat. Misalnya, berbagai metode pembuatan blok atau lelang aliran pesanan dapat diimplementasikan sebagai smart contract.

Mengingat kebutuhan akan data dan komputasi sensitif, MEVM juga menawarkan fitur privasi. Perhitungan sensitif dijalankan off-chain oleh node eksekusi. Awalnya, Flashbots atau pihak ketiga akan menyediakan ini secara terpusat tetapi pada akhirnya, itu akan dijalankan di lingkungan eksekusi tepercaya (TEE) seperti Intel SGX.

5. Ringkasan &; Tantangan ke Depan

Singkatnya, SUAVE bertujuan untuk mengumpulkan transaksi dari semua jaringan blockchain dan menyediakan blok dengan eksekusi paling efisien ke jaringan tersebut. Jika visi SUAVE sepenuhnya terwujud, itu akan memungkinkan desentralisasi MEV sejati, menawarkan manfaat berikut kepada berbagai peserta dalam ekosistem blockchain:

  1. Pengguna: Dilindungi dari serangan MEV berbahaya melalui privasi dan menawarkan eksekusi terbaik.
  2. Pembangun: Dapat bersaing secara adil dengan pembangun lain karena transaksi privasi yang melekat pada SUAVE dan lelang aliran pesanan (OFA), dan memiliki akses ke preferensi lintas domain, memungkinkan mereka untuk membangun blok yang lebih menguntungkan daripada saat beroperasi dalam satu domain.
  3. Jaringan: Dapat dengan mudah mengalihdayakan proses pembuatan blok ke SUAVE.

Terlepas dari visinya yang ambisius, SUAVE masih dalam tahap awal dan menghadapi beberapa tantangan sebelum dapat sepenuhnya direalisasikan.

  1. Model Keamanan: Model keamanan SUAVE masih belum terdefinisi. Mengingat bahwa blok SUAVE kemungkinan akan digunakan dalam jaringan L2 berbasis Ethereum dan Ethereum, tingkat keamanannya idealnya harus sesuai dengan Ethereum, tetapi mencapai ini rumit. Ada diskusi tentang apakah SUAVE harus dibangun sebagai Ethereum L2 atau menggunakan keamanan kripto-ekonomi EigenLayer.
  2. Transaksi Lintas Domain Atom: Ini adalah tidak dijamin. Sangat menantang untuk memproses transaksi secara atomik di seluruh jaringan dengan waktu blok yang berbeda. Transaksi mungkin berhasil pada jaringan blok-waktu cepat tetapi gagal pada yang lebih lambat. Selain itu, karena tidak semua validator di semua jaringan sadar SUAVE, termasuk blok melalui lelang gas prioritas (PGA) mungkin gagal.
  3. Desain Oracle: Desain oracle yang canggih diperlukan untuk secara akurat dan cepat membawa hasil dari domain eksternal ke SUAVE untuk penyelesaian. Oracle setidaknya harus seaman SUAVE, karena mereka dapat menjadi vektor serangan.
  4. Pengalaman Pengguna: UX yang mudah digunakan harus dirancang untuk SUAVE. Pengguna perlu menetapkan tawaran untuk preferensi mereka dan menahan ETH di jaringan SUAVE. Antarmuka yang memungkinkan pengguna untuk dengan mudah mengekspresikan berbagai jenis preferensi juga diperlukan.

Kekhawatiran terbesar adalah apakah SUAVE dapat mencapai tingkat adopsi yang signifikan mirip dengan mev-geth atau MEV-Boost. Agar SUAVE dapat mewujudkan visinya, ia harus mencapai skala ekonomi. Banyak pengguna dari berbagai jaringan perlu mengirim preferensi mereka ke SUAVE, dan banyak pembangun harus berpartisipasi untuk menciptakan sistem yang efisien. Sementara mev-geth adalah klien dan MEV-Boost adalah sespan middleware yang dapat dengan mudah diadopsi oleh validator yang ada, SUAVE adalah jaringan blockchain berdasarkan MEVM. Oleh karena itu, masih harus dilihat apakah sistem besar ini dapat mencapai adopsi yang berarti di banyak jaringan.

Penafian:

  1. Artikel ini dicetak ulang dari [mirror]. Semua hak cipta milik penulis asli [00y]. Jika ada keberatan dengan cetak ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.
  2. Penafian Kewajiban: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata milik penulis dan bukan merupakan saran investasi.
  3. Penerjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.

Bagaimana SUAVE Dapat Alamat Sentralisasi Builder

LanjutanJun 18, 2024
Ethereum selalu dianggap sebagai salah satu jaringan yang paling terdesentralisasi, tetapi masalah sentralisasi pembangun menjadi semakin serius. Kripto KOL 100y mengeksplorasi kemajuan yang telah dibuat Flashbots dalam mengatasi eksternalitas negatif MEV pada Ethereum dan memeriksa bagaimana SUAVE pada akhirnya bertujuan untuk memecahkan masalah yang berkaitan dengan MEV, termasuk sentralisasi pembangun.
Bagaimana SUAVE Dapat Alamat Sentralisasi Builder

1. Tantangan Berikutnya untuk Ethereum: Sentralisasi Pembangun

Ethereum sering dianggap sebagai salah satu jaringan yang paling terdesentralisasi bersama Bitcoin. Karena persyaratan perangkat keras yang relatif rendah untuk mengoperasikan node Ethereum, hampir semua orang dapat menjalankan node. Ada beberapa redundansi, jaringan menawarkan lebih dari 1 juta validator.

(Pangsa pasar pembangun | Sumber: Relayscan)

Namun, masalah kritis yang sering diabaikan adalah sentralisasi pembangun. Pembangun adalah entitas yang mengumpulkan transaksi dan bundel untuk membuat blok di jaringan Ethereum. Selama tujuh hari terakhir, 95% blok dihasilkan oleh hanya tiga pembangun.

Meskipun demikian, seperti yang telah Vitalik Buterin tunjukkan, sentralisasi pembangun tidak menimbulkan ancaman berat bagi keamanan keseluruhan jaringan Ethereum. Ini karena, bahkan jika bangunan blok agak terpusat, validator (pengusul) yang memverifikasi blok-blok ini tetap terdesentralisasi. Meskipun demikian, sentralisasi pembangun dapat menyebabkan berbagai masalah seperti sensor, pencarian sewa, dan masalah kehidupan.

Artikel ini akan mengeksplorasi perjalanan Flashbots dalam mengatasi eksternalitas negatif dari MEV Ethereum dan memeriksa bagaimana SUAVE pada akhirnya dapat menyelesaikan masalah yang berkaitan dengan MEV, termasuk sentralisasi pembangun.

2. Kemajuan Sejauh Ini

2.1 Proof of Work

Sebelum upgrade The Merge, jaringan Ethereum beroperasi pada konsensus PoW, mirip dengan jaringan Bitcoin, di mana penambang menggunakan perangkat keras untuk menambang blok. Selama periode ini, ketika pencari mengidentifikasi peluang MEV di mempool, satu-satunya cara untuk mendapatkan transaksi atau bundel mereka termasuk dalam blok adalah melalui lelang gas prioritas (PGA), di mana mereka menawar biaya gas lebih tinggi daripada pencari lainnya.

Ada masalah mendasar dengan pendekatan ini. Pertama, MEV mencuri adalah masalah. Penambang dapat melihat isi transaksi atau bundel yang dikirimkan oleh pencari dan, alih-alih memasukkannya ke dalam blok dengan biaya prioritas, mereka dapat menyalin transaksi ini dan mencuri MEV itu sendiri. Dengan demikian, pencari harus mempercayai penambang untuk mendapatkan keuntungan MEV.

Masalah kedua adalah kemacetan jaringan. Setiap kali peluang MEV muncul, pencari bersaing dengan menawar biaya prioritas yang lebih tinggi, yang menyebabkan peningkatan kemacetan di jaringan Ethereum. Ini membuat biaya transaksi rata-rata mahal dan tidak dapat diprediksi, berdampak negatif pada pengguna biasa.

(Lelang Flashbots | Sumber: Flashbots)

Untuk mengatasi eksternalitas negatif MEV di jaringan PoW Ethereum, Flashbots memperkenalkan Flashbots Auction, yang terdiri dari mev-geth dan mev-relay. Komponen utamanya adalah: 1) penambang daftar putih, 2) membangun mempool pribadi, dan 3) menerapkan sistem lelang penawaran tertutup.

Pengguna dan pencari dapat mengirimkan transaksi atau bundel ke mempool pribadi Lelang Flashbots, yang kemudian dikirim ke penambang yang masuk daftar putih menggunakan klien mev-geth melalui mev-relay terpusat. Pencari menyatakan tawaran untuk bundel mereka, dan penambang menggunakan mev-geth untuk memasukkan bundel penawaran tertinggi di blok.

Berbeda dengan sistem sebelumnya, pencari menggunakan mempool pribadi, sehingga tindakan mereka tidak berdampak pada pasar Ethereum gas, dan mereka tidak dapat melihat tawaran pencari lain, mengurangi persaingan. Akibatnya, Lelang Flashbots secara efektif mengurangi kemacetan di jaringan Ethereum. Namun, memasukkan penambang ke daftar putih masih diperlukan karena mereka masih bisa melihat konten bundel yang dikirimkan oleh pencari.

(Sumber: Flashbots)

Flashbots Auction diadopsi secara luas, dengan lebih dari 90% adopsi mev-geth. Ini secara signifikan mengurangi transaksi MEV yang gagal dan menurunkan biaya gas rata-rata di jaringan Ethereum, secara efektif mengurangi banyak eksternalitas negatif yang terkait dengan MEV.

2.2 Proof of Stake (PoS)

Pada September 2022, jaringan Ethereum beralih dari PoW ke PoS dengan aktivasi peningkatan The Merge. Proses termasuk transaksi yang dikirimkan pengguna dalam blok sebagian besar tetap tidak berubah dari PoW. Namun, ada masalah kritis dengan mengadopsi Lelang Flashbots secara langsung: daftar putih.

Secara PoW Ethereum, penambang secara fisik memiliki perangkat keras mereka, membuat proses daftar putih relatif mudah. Namun, dengan beralih ke PoS, berbagai entitas dapat berpartisipasi dalam memvalidasi secara anonim, membuat daftar putih menjadi sangat sulit.

Untuk mengatasi eksternalitas negatif MEV pada PoS Ethereum, Flashbots memperkenalkan protokol baru yang disebut MEV-Boost. Roadmap jaringan Ethereum mencakup peningkatan PBS (Proposer-Builder Separation) untuk mendesentralisasikan MEV, dan MEV-Boost mengimplementasikan bagian dari PBS.

Dalam pengaturan baru ini, pembangun blok menerima transaksi dan bundel dari pengguna dan pencari untuk membuat blok penuh yang paling berharga, sementara pengusul memilih blok penuh tawaran tertinggi dari pembangun blok dan menyebarkannya ke jaringan. Tidak seperti mev-geth, MEV-Boost bertindak sebagai sespan ke klien konsensus, membuatnya kompatibel dengan jenis klien apa pun.

Berikut cara MEV-Boost beroperasi:

(MEV-Boost | Sumber: EigenLayer)

  1. Blok pembangun menerima transaksi dari pencari dan aliran pesanan pribadi, menggunakan algoritma ekstraksi MEV mereka untuk menyusun ulang transaksi untuk profitabilitas maksimum. Mereka kemudian membuat blok penuh dan mengajukan tawaran ke relai.
  2. Relai memverifikasi validitas blok yang diterima dari pembangun dan menyimpannya.
  3. Relai mengirimkan header blok, bersama dengan tawaran, ke pengusul.
  4. Pengusul memilih header blok dengan tawaran tertinggi dari yang dikirim oleh relai dan menandatanganinya.
  5. Relai mengungkapkan konten blok lengkap yang sesuai dengan header yang ditandatangani kepada pengusul.
  6. Pengusul mengirimkan blok lengkap ke jaringan dan mengumpulkan tawaran yang dilampirkan oleh pembuat blok.

(Sumber: mevboost.pics)

Dari perspektif Ethereum validator, MEV-Boost menawarkan keuntungan yang signifikan: tidak perlu proses daftar putih. Validator cukup menjalankan MEV-Boost Flashbots, dan pembuat blok hanya mengekstrak MEV nilai tertinggi dan mengirimkannya sebagai tawaran. Ini berarti validator dapat memperoleh pendapatan MEV tanpa memerlukan algoritma ekstraksi MEV mereka sendiri. Akibatnya, keuntungan MEV terdesentralisasi daripada terkonsentrasi di antara beberapa entitas.

(Sumber: mevboost.pics)

Meskipun merupakan middleware eksternal daripada protokol bawaan, MEV-Boost telah berhasil diadopsi oleh lebih dari 90% Ethereum validator untuk jangka waktu yang lama. Meskipun ada kelemahan bahwa pembangun dan pengusul harus mempercayai relai, jumlah relai telah meningkat menjadi delapan, mengurangi dominasi relai Flashbots dan mengurangi masalah terkait seperti sensor.

3. Sentralisasi Pembangun

3.1 Mengapa Pembangun Cenderung Menuju Sentralisasi

Sementara MEV-Boost telah mengurangi banyak eksternalitas negatif yang terkait dengan MEV, masalah sentralisasi pembangun, yang disebutkan sebelumnya, tetap belum terselesaikan. Saat ini, sekitar 90% dari blok jaringan Ethereum dibuat oleh hanya tiga hingga empat pembangun blok. Tetapi mengapa pembangun blok cenderung terpusat? Ada dua alasan utama:

Alur Pesanan Eksklusif (EOF)

Pertama, pasar pembuat blok pada dasarnya adalah pasar pemenang-mengambil-semua. Bayangkan Anda adalah seorang pencari yang telah mengidentifikasi peluang ekstraksi MEV dan menggabungkannya. Pembangun mana yang akan Anda kirimi bundel Anda? Meskipun Anda dapat mengirimkannya ke semua pembangun, semakin banyak pembangun yang Anda libatkan, semakin tinggi risiko pencurian MEV, karena pembangun dapat melihat konten bundel. Oleh karena itu, strategi optimal Anda adalah mengirim bundel hanya ke beberapa pembangun teratas dengan probabilitas inklusi blok tertinggi.

(Sumber: Frontier Research, Juni 2023)

Grafik di atas menunjukkan bahwa pembangun yang menerima lebih banyak bundel dari pencari memiliki probabilitas penyertaan blok yang lebih tinggi. Fenomena ini mempercepat roda gila sentralisasi: jika pembangun menerima lebih banyak bundel dari pencari, itu lebih mungkin untuk membangun blok yang lebih menguntungkan. Akibatnya, blok-blok ini lebih mungkin diadopsi oleh pengusul di jaringan Ethereum, memberi insentif kepada lebih banyak pencari untuk mengirim bundel mereka ke pembangun itu. Mengirim bundel ke pembangun yang kurang dominan dapat mengakibatkan keterlambatan dalam inklusi blok, membuat prediksi Gas Fee sulit dan berpotensi kehilangan peluang ekstraksi MEV.

Di luar kecenderungan alami menuju sentralisasi ini, pembangun dapat mencari transaksi atau bundel tambahan melalui EOF. Misalnya, pembuat tertentu mungkin menawarkan jaminan privasi atau bagian dari MEV yang diekstraksi kepada pengguna dan pencari yang mengirim transaksi atau bundel secara eksklusif kepada mereka. Aliran pesanan tambahan ini, yang tidak dapat diakses oleh pembangun lain, semakin mempercepat sentralisasi pembangun.

Memang, seperti yang ditunjukkan pada grafik, BloXroute memiliki tingkat inklusi blok yang jauh lebih tinggi dibandingkan dengan rekan-rekannya. Ini karena BloXroute beroperasi tidak hanya sebagai pembuat blok tetapi juga sebagai layanan relai, memberikan keuntungan latensi dalam memproses transaksi. Selain itu, BloXroute sumber EOF melalui layanan seperti BackRunMe.

(MEV distribusi | Sumber: BloXroute)

BackRunMe memungkinkan pengguna untuk mengirimkan transaksi pribadi, melindungi mereka dari serangan berbahaya seperti serangan front-running dan sandwich. Selain itu, jika keuntungan MEV dihasilkan dari backrunning transaksi pribadi yang dikirimkan ke BackRunMe, keuntungan didistribusikan sesuai dengan rasio yang ditunjukkan pada grafik. Pengguna dan pencari dapat menikmati berbagai manfaat dengan menggunakan UI swap BackRunMe atau hanya mengubah RPC mereka untuk mengirimkan transaksi.

Jadi, apa yang bisa dilakukan pembuat blok baru? Sayangnya, mereka memiliki pilihan terbatas selain meningkatkan pangsa pasar mereka dengan kerugian atau menawarkan layanan untuk menarik pengguna dan EOF pencari. Pendekatan sebelumnya, yang dikenal sebagai strategi subsidi blok, melibatkan penetapan tawaran yang lebih tinggi daripada keuntungan MEV yang dihasilkan dari blok bangunan untuk meningkatkan tingkat inklusi blok. Misalnya, pembuat f1b berhasil menggunakan strategi ini untuk meningkatkan jumlah pencari mereka dengan cepat.

MEV lintas domain

Semakin banyak aliran pesanan yang dapat diakses oleh pembuat blok, semakin tinggi kemungkinan menghasilkan blok yang lebih menguntungkan. Jika beberapa pembuat blok juga membuat blok untuk jaringan lain, mereka tidak hanya dapat mengakses aliran pesanan dari jaringan Ethereum tetapi juga aliran pesanan eksternal. Kemampuan ini kemungkinan akan mengarah pada sentralisasi lebih lanjut di sekitar pembangun ini.

3.2 Apa yang Harus Kita Lakukan?

Kami telah mengeksplorasi mengapa pasar pembangun cenderung terpusat. Meskipun sentralisasi pembangun tidak menimbulkan ancaman keamanan yang parah karena sifat desentralisasi pengusul (validator) yang memverifikasi dan menyebarkan blok, itu masih dapat menyebabkan masalah seperti 1) sensor, 2) pencarian sewa, dan 3) masalah kehidupan.

Sensor berpotensi dapat diatasi dengan fitur Ethereum protokol di masa mendatang seperti crList, yang secara asli akan memaksa pembangun untuk memasukkan semua transaksi seperti yang dipersyaratkan oleh pengusul. Namun, mengatasi perburuan rente di pasar monopolistik dan menyelesaikan masalah kehidupan karena downtime lebih menantang.

Oleh karena itu, solusi terbaik adalah mencegah sentralisasi pembangun sejak awal dengan mengurangi penyebab utamanya — EOF dan MEV lintas domain. Untuk mengatasi masalah ini, Flashbots memperkenalkan Single Unifying Auction for Value Expression (SUAVE) protokol. (Perlu dicatat bahwa SUAVE bukan satu-satunya solusi potensial untuk sentralisasi pembangun; untuk berbagai solusi potensial lainnya, lihat Jon Charbonneau 'Decentralizing the Builder Role').

4. Ini dia SUAVE

4.1 TL; DR

SUAVE berfokus pada penanganan dua faktor utama yang berkontribusi terhadap sentralisasi pembangun: EOF dan MEV lintas domain. Pertama, SUAVE dapat menerima transaksi dari semua jaringan, memungkinkan pembangun terdesentralisasi untuk secara inheren mengekstrak MEV lintas domain. Kedua, SUAVE mengoptimalkan kondisi bagi pengguna dengan menangani preferensi secara pribadi dan menawarkan bagian dari keuntungan MEV.

4.2 Ikhtisar

(Ikhtisar SUAVE | Sumber: Flashbots)

SUAVE adalah blockchain terpisah dari jaringan Ethereum, menawarkan mempool plug-and-play dan layanan pembangun terdesentralisasi yang dapat digunakan oleh banyak jaringan. Hal ini memungkinkan jaringan lain untuk melakukan outsourcing proses kompleks manajemen mempool dan pembangunan blok terdesentralisasi ke SUAVE. SUAVE terdiri dari tiga komponen utama:

Lingkungan Preferensi Universal

Pengguna dan pencari mengirimkan transaksi, bundel, maksud, dan ekspresi preferensi lainnya ke mempool SUAVE, bukan mempool jaringan asli, bersama dengan tawaran mereka. Di SUAVE, preferensi ini diperlakukan sebagai jenis transaksi asli. Dengan menggabungkan preferensi dari berbagai domain ke dalam satu mempool, kemungkinan eksekusi optimal meningkat. Pengaturan ini menguntungkan pembangun dengan menurunkan hambatan masuk dan meningkatkan potensi keuntungan.

Pasar Eksekusi Optimal

Pelaksana (Pencari, Pembangun, dll.) memantau mempool SUAVE dan bersaing untuk membuat bundel dengan kondisi eksekusi terbaik. Konsep utama yang diperkenalkan di sini adalah pesanan flow auction (OFA).

Dalam model MEV-Boost tradisional, keuntungan MEV mengalir dalam satu arah dari pengguna ke pencari ke pembangun ke pengusul. Namun, dengan OFA, pelaksana bersaing untuk preferensi pengguna, memungkinkan pengguna untuk juga menerima bagian dari keuntungan MEV. Strategi ini mirip dengan layanan seperti BackRunMe, yang bertujuan untuk menarik lebih banyak EOF dengan mendistribusikan kembali beberapa keuntungan MEV kepada pengguna dan pencari. Selain itu, SUAVE memastikan privasi preferensi dalam mempool, melindunginya dari serangan MEV berbahaya.

Perbedaannya adalah, sementara strategi semacam itu dapat mengarah pada sentralisasi pembangun tertentu di pasar pembangun saat ini, SUAVE menyematkan OFA ke dalam protokol itu sendiri, memberikan semua pembangun terdesentralisasi akses ke preferensi ini. Konsep OFA, seperti yang diusulkan oleh Flashbots, sudah diterapkan di jaringan Ethereum melalui MEV-Share dan nantinya akan dimasukkan ke dalam SUAVE.

Bangunan Blok Terdesentralisasi

Pada komponen sebelumnya, sebagian besar preferensi menemukan rute eksekusi optimalnya. Pembangun blok terdesentralisasi kemudian menggunakan informasi ini untuk membangun blok parsial atau penuh yang memaksimalkan keuntungan MEV, yang kemudian mereka sampaikan ke validator berbagai jaringan.

Tidak semua validator jaringan lain dapat menggunakan SUAVE, mirip dengan bagaimana tidak semua Ethereum validator menggunakan MEV-Boost. Validator yang mendengarkan SUAVE dapat menerima blok SUAVE dan menambahkan blok yang menguntungkan ke jaringan mereka. Jika mereka SUAVE-tidak sadar, pembangun blok SUAVE harus berpartisipasi dalam lelang gas prioritas (PGA) untuk memasukkan blok mereka. Setelah preferensi terpenuhi dalam rantai tujuan, oracle memberi tahu jaringan SUAVE, dan tawaran dikirim ke pelaksana untuk penyelesaian.

4.3 MEVM

SUAVE adalah blockchain yang menggunakan MEVM sebagai lingkungan eksekusinya. MEVM dibangun di atas kerangka kerja EVM, dengan prakompilasi tambahan untuk kasus penggunaan MEV. Pengembang dapat menggunakan Solidity untuk membuat aplikasi MEV sebagai smart contract, memungkinkan pembangunan terdesentralisasi dari infrastruktur terkait MEV yang sebelumnya terpusat. Misalnya, berbagai metode pembuatan blok atau lelang aliran pesanan dapat diimplementasikan sebagai smart contract.

Mengingat kebutuhan akan data dan komputasi sensitif, MEVM juga menawarkan fitur privasi. Perhitungan sensitif dijalankan off-chain oleh node eksekusi. Awalnya, Flashbots atau pihak ketiga akan menyediakan ini secara terpusat tetapi pada akhirnya, itu akan dijalankan di lingkungan eksekusi tepercaya (TEE) seperti Intel SGX.

5. Ringkasan &; Tantangan ke Depan

Singkatnya, SUAVE bertujuan untuk mengumpulkan transaksi dari semua jaringan blockchain dan menyediakan blok dengan eksekusi paling efisien ke jaringan tersebut. Jika visi SUAVE sepenuhnya terwujud, itu akan memungkinkan desentralisasi MEV sejati, menawarkan manfaat berikut kepada berbagai peserta dalam ekosistem blockchain:

  1. Pengguna: Dilindungi dari serangan MEV berbahaya melalui privasi dan menawarkan eksekusi terbaik.
  2. Pembangun: Dapat bersaing secara adil dengan pembangun lain karena transaksi privasi yang melekat pada SUAVE dan lelang aliran pesanan (OFA), dan memiliki akses ke preferensi lintas domain, memungkinkan mereka untuk membangun blok yang lebih menguntungkan daripada saat beroperasi dalam satu domain.
  3. Jaringan: Dapat dengan mudah mengalihdayakan proses pembuatan blok ke SUAVE.

Terlepas dari visinya yang ambisius, SUAVE masih dalam tahap awal dan menghadapi beberapa tantangan sebelum dapat sepenuhnya direalisasikan.

  1. Model Keamanan: Model keamanan SUAVE masih belum terdefinisi. Mengingat bahwa blok SUAVE kemungkinan akan digunakan dalam jaringan L2 berbasis Ethereum dan Ethereum, tingkat keamanannya idealnya harus sesuai dengan Ethereum, tetapi mencapai ini rumit. Ada diskusi tentang apakah SUAVE harus dibangun sebagai Ethereum L2 atau menggunakan keamanan kripto-ekonomi EigenLayer.
  2. Transaksi Lintas Domain Atom: Ini adalah tidak dijamin. Sangat menantang untuk memproses transaksi secara atomik di seluruh jaringan dengan waktu blok yang berbeda. Transaksi mungkin berhasil pada jaringan blok-waktu cepat tetapi gagal pada yang lebih lambat. Selain itu, karena tidak semua validator di semua jaringan sadar SUAVE, termasuk blok melalui lelang gas prioritas (PGA) mungkin gagal.
  3. Desain Oracle: Desain oracle yang canggih diperlukan untuk secara akurat dan cepat membawa hasil dari domain eksternal ke SUAVE untuk penyelesaian. Oracle setidaknya harus seaman SUAVE, karena mereka dapat menjadi vektor serangan.
  4. Pengalaman Pengguna: UX yang mudah digunakan harus dirancang untuk SUAVE. Pengguna perlu menetapkan tawaran untuk preferensi mereka dan menahan ETH di jaringan SUAVE. Antarmuka yang memungkinkan pengguna untuk dengan mudah mengekspresikan berbagai jenis preferensi juga diperlukan.

Kekhawatiran terbesar adalah apakah SUAVE dapat mencapai tingkat adopsi yang signifikan mirip dengan mev-geth atau MEV-Boost. Agar SUAVE dapat mewujudkan visinya, ia harus mencapai skala ekonomi. Banyak pengguna dari berbagai jaringan perlu mengirim preferensi mereka ke SUAVE, dan banyak pembangun harus berpartisipasi untuk menciptakan sistem yang efisien. Sementara mev-geth adalah klien dan MEV-Boost adalah sespan middleware yang dapat dengan mudah diadopsi oleh validator yang ada, SUAVE adalah jaringan blockchain berdasarkan MEVM. Oleh karena itu, masih harus dilihat apakah sistem besar ini dapat mencapai adopsi yang berarti di banyak jaringan.

Penafian:

  1. Artikel ini dicetak ulang dari [mirror]. Semua hak cipta milik penulis asli [00y]. Jika ada keberatan dengan cetak ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.
  2. Penafian Kewajiban: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata milik penulis dan bukan merupakan saran investasi.
  3. Penerjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.
Comece agora
Inscreva-se e ganhe um cupom de
$100
!