Opening remark

Pada tanggal 26 September 2023, Blocknative mengumumkan keputusannya untuk menghentikan operasi pembangunan blok dan relay-nya. Ketika saya mendengar berita tersebut sebelum pengumuman, saya terkejut. Meskipun saya sangat menyadari bahwa perusahaan yang mengoperasikan relay untuk PBS kehilangan uang, saya tidak mengharapkan siapapun benar-benar menutup operasinya. Ketika Matt bercanda, "Kita mungkin hanya memiliki beberapa relay tersisa setelah tahun depan tanpa skema insentif yang tepat" kembali di ETHCC di Paris, saya berasumsi para pengembang dan peneliti komunitas akhirnya akan mengidentifikasi solusi yang berkelanjutan untuk insentif relay sebelum kita mencapai kondisi tersebut.

"Aku peduli padamu"

Tapi sekarang saya menyadari bahwa mungkin pemikiran seperti itu agak naif. Saya selalu menganggap rem sebagai hal yang biasa dan telah membuang semua asumsi rasional dan ekonomi di balik rem atas nama kebaikan publik. Itu tidak cukup. Jadi di bawah ini adalah upaya saya untuk mengevaluasi insentif relay dari prinsip pertama dengan tujuan untuk menemukan jalur yang layak ke depan untuk relay tanpa mengorbankan desentralisasi.

Tugas relay

Mari kita lihat secara singkat grafik berikut yang menggambarkan peran relay dalam PBS.

Peran relay oleh Kydo

Singkatnya, pembangun mengirimkan penawaran ke relay, relay mengirimkan penawaran tersebut ke penawar, dan penawar berkomitmen pada blok paling berharga. Relay kemudian mengungkapkan isi blok, menegakkan pembayaran pembangun kepada penawar, dan menyebarkan blok ke seluruh jaringan. Untuk informasi lebih lanjut, silakan lihat posting inioleh Stephane. Jelas, relay memainkan peran kritis dalam jaringan pasokan transaksi kita saat ini. Jadi mengapa mereka tidak mendapatkan insentif dengan benar? Berikut adalah beberapa alasan yang saya lihat sejauh ini.

1. Relay adalah produk sampingan dari penyelesaian masalah monopoli proposer/dimensions via PBS

PBS awalnya diusulkan untuk mengatasi risiko-risiko berikut yang terkait dengan para pengusul:

1. Monopoli Pra-PBS Validator atas proposal blok dan penentuan urutan transaksi mengakibatkan risiko sensor protokol. Untuk mengilustrasikan, seorang validator yang canggih bisa mendapatkan lebih banyak biaya daripada penjudi tunggal dengan mengekstrak MEV. Hadiah lebih memungkinkan spin-up lebih banyak validator, menciptakan efek bola salju yang mengarah ke sentralisasi validator. Dengan PBS, validator (sekarang penawar) tidak akan lagi memiliki visibilitas dalam penentuan urutan blok pra-commitment dan bisa fokus pada peningkatan sifat resistensi sensor (CR) Ethereum melalui daftar inklusi (IL), yang merupakan penelitian yang sedang berlangsung. Kemungkinan besar sentralisasi validator terjadi dengan atau tanpa PBS, tetapi saya melihat PBS sebagai mitigasi terhadap tingkat sentralisasi yang ekstrim yang sudah kita amati dalam lanskap pembangun.
2. Sebuah peningkatan dalam persyaratan node untuk menjalankan algoritma penggabungan bundel dan infrastruktur rendah-latensi untuk agregasi bundel dan aliran pesanan. Pengejaran blok yang memaksimalkan pendapatan dapat mengakibatkan sentralisasi jaringan validator melalui peningkatan beban kerja proposer dan persyaratan latenensi yang terkait dengan menangkap MEV. Oleh karena itu, PBS memindahkan pekerjaan pengeplotan dan permainan latenensi ke pembangun untuk menjaga node validator tetap ringan.
3. Menambahkan overhead komputasi dari bukti KZG. Dalam kasus Darksharding, proposer akan perlu menghitung bukti KZG untuk hingga 64MB data rollup dalam waktu kurang dari 1 detik. PBS memungkinkan pembuktian khusus, mungkin pembangun, untuk efisien menyediakan bukti, dengan demikian memfasilitasi implementasi validator yang ringan.

Saya percaya bahwa PBS adalah langkah yang diperlukan untuk membuka jalan bagi jaringan konsensus yang lebih kuat, dapat diskalakan, dan CR, tetapi pada saat yang sama, ini telah berhasil 'mengalihkan' banyak masalah kepada para pembangun dan relay. Sebagai contoh, gambar berikut dari sensor.picmengusulkan bahwa sementara validator sebagian besar tidak menyensor, ada masalah sensor yang signifikan yang terkait dengan relay dan builders (kurang terdesentralisasi dan tanpa IL).

Pembatasan OFAC oleh Toni, lihathttps://censorship.pics

Selain itu, masalah relay dan builder bukanlah titik fokus utama dari PBS. Dan di antara keduanya, para builder memiliki insentif ekonomi eksplisit (MEV, CEX-DEX arbs) yang belum terjadi pada relay.

Relay Mempertanyakan Keberadaan Mereka oleh Matt Cutler

1. "Relay sementara, mengesahkan itu akan menyelesaikan masalah relay"

ePBS masih dalam penelitian dan memiliki banyak@mikeneuder/infinite-buffet":pertanyaan terbuka yang perlu dijawab. Pendekatan yang berbeda membawa kompromi yang berbeda dan perubahan protokol, beberapa lebih invasif daripada yang lain, seperti memerlukan waktu slot yang lebih lama. Masih banyak pekerjaan yang harus dilakukan untuk mencapai kesimpulan/konsensus apakah Ethereum seharusnya mengabadikan PBS sama sekali. Untuk masa mendatang, relay diperlukan untuk menjaga setup PBS saat ini, dan saya pikir sangat penting bahwa kita memprioritaskan menyelaraskan insentif para pemangku kepentingan yang ada dalam jaringan pasokan transaksi daripada menunggu solusi yang mungkin tidak pernah terwujud.

Menggambarkan kehidupan sebuah relay

1. 'Kebaikan publik' => Menghindari masalah keselarasan insentif di antara pembangun dan validator => Kompetisi harga beracun

Dengan ketidakpastian yang disebutkan di atas, menjalankan relay sebagai barang publik menjadi solusi sementara yang dapat dimengerti untuk menghindari masalah keselarasan insentif seputar biaya dalam jaringan pasokan txs. Namun, hal itu juga menyebabkan persaingan harga yang toksik di antara mereka yang mencoba memonetisasi relay.

bloXroute mencoba untuk memonetisasi di masa lalu dengan menawarkan layanan tambahan, seperti jaringan low-latency untuk penyebaran blok. Tujuan mereka adalah untuk menyediakan jaringan relay yang dioptimalkan untuk latensi, memungkinkan mereka untuk membebankan biaya berdasarkan keuntungan yang diperoleh oleh pembangun saat menggunakan relay bloXroute. Meskipun pendapatan tambahan hampir tidak mencukupi biaya pemeliharaan dan operasi relay (berkisar dari $100k-500k), itu merupakan keberhasilan yang sederhana dalam menunjukkan kemampuan sebuah relay untuk membebankan biaya. Namun, dengan adanya relay publik yang lebih baik (seperti Agnostic dan Ultrasound) yang mampu memberikan latensi yang relatif rendah,relay optimis) memasuki arena, persaingan untuk pengguna yang bersedia membayar untuk layanan-layanan ini semakin intens, membuat model biaya bloXroute kurang efektif dari waktu ke waktu. Tanpa solusi yang segera, pasar relay akan terus menjadi kontes untuk menentukan siapa yang bisa menopang kebaikan publik terlama dengan sumber daya terbesar.

Masa depan pasar relay

Sejauh ini, ada dua pendekatan untuk mencapai pasar relay yang lebih berkelanjutan di bawah asumsi yang berbeda.

1. Menguatkan kebaikan publik: Relays dapat mengumpulkan sumbangan dari DAO besar dan protokol untuk mendanai operasi. Ini mungkin lebih mudah dilaksanakan tetapi tidak pasti seberapa banyak yang dapat dikumpulkan dan untuk berapa lama pendanaan kebaikan publik akan bertahan. Sederhana tetapi tidak yakin seberapa berkelanjutannya, kecuali dana tersebut dalam jumlah besar (mungkin dana ETF?!?). Salah satu upaya hebat di depan adalah guild PBSdipimpin oleh Tina, meningkatkan kesadaran lebih banyak tentang isu insentif relay sambil mendanai penelitian relay dan operasi melalui hibahnya. Tentu saja mungkin untuk memiliki hibah kebaikan publik yang berkelanjutan melalui gilda PBS jika ada entitas, seperti dana ETF, yang bersedia mendonasikan sebagian dari keuntungannya ke gilda seperti apa yang VanEck melakukan untuk guild ProtokolNamun, mendapatkan sumbangan semacam itu sangat sulit dan mungkin bahkan tidak realistis pada tahap ini. Oleh karena itu, upaya kebaikan publik seperti guild PBS bisa dianggap sebagai insentif tambahan untuk melakukan lebih banyak penelitian dan pengembangan seputar mekanisme insentif relay.

2. Selesaikan masalah keselarasan insentif: Bentuk serikat relay & capai konsensus sosial untuk bersama-sama merancang model biaya yang berusaha memungkinkan monetisasi relay sambil menyelaraskan insentif pembangun dan validator. Ini memerlukan koordinasi dan kolaborasi di antara para pemangku kepentingan dalam jaringan pasokan txs kita, dan fokus artikel ini adalah untuk menjelajahi cara di mana hal ini dapat dicapai.

Relay Union: upaya untuk beralih dari kebaikan publik melalui konsensus sosial

Beberapa operator relay memiliki @KuDeTa/relay_guild_mvp":berusaha untuk menyelaraskan insentif semua pihak, termasuk validator dan pembangun, untuk menemukan jalan ke depan yang berkelanjutan. Untuk memulai diskusi, berikut pertanyaan penting yang perlu kita jawab:

1. Siapa yang harus membayar biaya relay?
2. Bagaimana seharusnya relay dibayar? (misalnya siapa yang menetapkan biaya dan bagaimana?)

Jadi mari kita jelajahi dua pertanyaan ini di sini.

Siapa yang harus membayar biaya relay?

Secara intuitif, tampaknya wajar bahwa para pembangun dan validator, yang sangat mengandalkan dan mendapatkan manfaat dari layanan yang diberikan oleh relay, seharusnya menanggung biaya yang terkait. Dalam hal praktis, kedua pihak dapat bekerja sama dengan memperbolehkan relay untuk mengurangi sebagian tawaran, tetapi ada kebutuhan bagi salah satu dari mereka untuk memfasilitasi pembayaran ini. Penting untuk diakui bahwa partisipasi masing-masing pihak juga memperkenalkan tingkat pengaruh dan daya ungkit yang berbeda bagi relay. Akibatnya, menjadi penting untuk menentukan pihak mana yang lebih cenderung, jika ada, untuk menampung dan mengganti relay. Pada dasarnya, kita harus menilai sejauh mana relay yang terhubung dengan baik dapat meyakinkan pembangun atau validator untuk memimpin dalam memfasilitasi pembayaran ini.

Catatan: Saya mengacu pada 'terhubung dengan baik' untuk berarti relay yang memiliki lebih dari sepertiga validator terdaftar di seluruh jaringan.

Leverage Relay terhadap para pembangun:

1. Relay yang terhubung dengan baik dapat mengirimkan tawaran ke lebih banyak validator, meningkatkan jangkauan tawaran para pembangun.
2. Pembangun besar, seperti Titan, Rsync, dan Beaver, dapat diberi insentif untuk membuat pembangun-relai yang terintegrasi secara vertikal untuk menghindari membayar biaya relai tambahan selama biaya pengoperasian & pengembangan relai - keuntungan tambahan dari keuntungan latensi dalam co-locating dengan relai << biaya membayar biaya relai eksternal. Pembangun besar yang memiliki sejumlah besar aktivitas CEX-DEX dan/atau mitra dagang terkait dapat memperoleh keuntungan dari peningkatan latensi dengan relai terintegrasi sehingga biaya operasi relai dapat diamortisasi. Namun, builder-relay secara umum dilengkapi dengan faktor-faktor risiko berikut, sehingga membatasi kandidat yang mungkin untuk meluncurkan builder-relay yang sukses hanya untuk pembangun yang memiliki reputasi baik dan dapat dipercaya.
   1. Validator konservatif besar mungkin tidak terhubung ke relay baru karena kekhawatiran keamanan/resiko (terutama yang besar seperti Coinbase dan Lido). Kemitraan BD dan nepotisme mungkin membantu, namun mendapatkan sejumlah besar validator untuk terhubung memerlukan reputasi yang baik untuk kinerja dan keandalan.
   2. Sebuah builder-relay memiliki potensi untuk memanipulasi penawarannya. Sebuah builder-relay mungkin mengklaim penawaran sebesar 100 ETH ketika pembayaran sebenarnya, setelah keterlibatan proposer, hanya 1 ETH. Jenis manipulasi ini menjadi lebih menantang ketika relay beroperasi sebagai entitas terpisah yang tepercaya, kecuali berkolusi dengan para builder. Perlu dicatat bahwa manipulasi seperti itu kemungkinan kecil terjadi dengan tiga builder teratas karena kekhawatiran tentang reputasi mereka. Oleh karena itu, terutama builder yang paling terkemuka yang dapat membentuk builder-relay yang validator lebih mungkin untuk dipercayai.
   3. Sebuah builder-relay bisa menghadapi risiko menjadi yatim piatu oleh validator jika builder yang sama juga mengirimkan penawaran melalui relay yang sudah ada. Bahkan ketika builder menjalankan builder-relay sendiri, mungkin masih perlu mengirimkan penawaran melalui relay incumbent untuk jangkauan yang lebih luas dan penyiaran yang efisien. Hal ini berpotensi membuat validator enggan terhubung ke builder-relay baru, mengingat mereka masih bisa menerima penawaran dari builder yang sama. Akibatnya, builder harus membedakan relay miliknya dari yang lain untuk meningkatkan peluang menarik lebih banyak validator. Strategi perbedaan ini bisa datang dengan biaya yang signifikan; builder mungkin perlu secara konsisten mengirimkan penawaran lebih tinggi melalui relay miliknya sendiri (yang mungkin kurang terhubung) dan penawaran lebih rendah melalui relay lain (yang lebih terhubung), jika mereka memilih untuk melakukannya. Selain itu, untuk memulai koneksi validator, builder harus terlibat dalam kemitraan pengembangan bisnis yang luas dan upaya pemasaran yang mengakibatkan biaya overhead yang lebih tinggi.

Leverage Relay atas validator:

1. Relay terkemuka memperluas cakupan penawaran dari para pembangun.
2. Mendengarkan beberapa relay meningkatkan redundansi untuk pengiriman payload dan meningkatkan cakupan validator pada penawaran yang tidak tumpang tindih yang diajukan melalui relay. Tabel ini menunjukkan berbagai statistik seputar relay selama 7 hari terakhir (20/10/2023) untuk menggambarkan penawaran yang tidak tumpang tindih yang berasal dari pembangun berbeda melalui relay dengan jumlah pendaftaran validator. Berdasarkan Jumlah Pembangun (Total) dan Jumlah Pembangun (Top4), kita melihat bahwa relay yang secara teratur menerima penawaran dari pembangun teratas 3 & 4 memiliki persentase pengiriman payload yang berhasil yang tinggi. Perlu dicatat bahwa ini adalah korelasi dan tidak menunjukkan hubungan sebab-akibat antara persentase pengiriman payload yang tinggi dan menerima penawaran dari pembangun teratas. Namun, data ini menunjukkan bahwa sebuah relay yang memiliki reputasi dan kinerja yang baik cenderung menerima berbagai penawaran pembangun dan mencapai tingkat pengiriman payload yang lebih baik. Oleh karena itu, validator sebaiknya mendengarkan beberapa relay untuk memaksimalkan nilai penawaran.

Pada titik ini, saya harap sudah jelas bahwa baik validator maupun pembangun membutuhkan relay, dan sulit untuk mengatakan pihak mana yang lebih bergantung pada relay daripada yang lain. Pembangun dengan selektif mengirim penawaran mereka ke relay pilihan mereka dan tidak mengirim ke setiap relay secara membabi buta seperti yang telah diusulkan sebelumnya. Demikian pula, validator dengan selektif mendengarkan relay pilihan mereka dan tidak mendaftar secara membabi buta dengan setiap relay, juga karena kekhawatiran regulasi.

Seseorang bisa berpendapat bahwa relay mungkin memiliki lebih banyak pengaruh atas para pembangun karena dua alasan: pertama, lebih mudah meyakinkan para pembangun untuk mengajukan penawaran saat sudah cukup pendaftaran validator karena keuntungan kinerja; dan kedua, membangun relay pembangun adalah tugas yang tidak mudah. Namun, masih belum ada kesimpulan tentang siapa yang seharusnya menyesuaikan untuk memfasilitasi pembayaran dan menanggung biaya relay. Oleh karena itu, langkah selanjutnya adalah menjelajahi bagaimana biaya dapat didistribusikan.

Bagaimana seharusnya relay dibayar? (misalnya siapa yang menetapkan biaya dan bagaimana?)

Ada dua mode pembayaran yang mungkin: pembayaran real-time vs pembayaran tertunda, di mana yang pertama menyelesaikan pembayaran sementara pengiriman payload dilakukan dan yang terakhir menyelesaikan pembayaran setelahnya. Dengan itu diingat, mari kita bahas kelayakan teknis dari pendekatan pembayaran yang mungkin oleh pembangun dan validator, dari mana kita juga akan menjelajahi siapa dan bagaimana biaya diatur.

Jika pembangun membayar: Pembayaran real-time

1. Ultrasound baru-baru ini mengusulkan solusi yang memungkinkan pembayaran pembangun real-time yang juga mencoba untuk lebih menyesuaikan insentif pembangun. Berikut adalah gambaran tentang bagaimana cara kerjanya:

Diagram yang mengilustrasikan pembayaran real-time oleh para pembangun

1. Ketika seorang pembangun memenangkan penawaran, biasanya dia mengirimkan muatan yang transaksi terakhirnya membayar penawaran kepada para pengusul. Selama proses ini, relay melakukan peran memastikan bahwa transaksi terakhir benar-benar transfer penawaran dan bahwa jumlah tawaran yang disetujui oleh pengusul. Relay memiliki visibilitas penuh dan kontrol atas muatan selama proses ini dan harus dapat dipercaya. Ultrasound berupaya memanfaatkan kepercayaan itu dan memodifikasi transfer penawaran di mana relay, bukan pembangun, membayar pengusul hingga tawaran tertinggi kedua yang terlihat di relay lain sehingga selisih antara tawaran pertama dan kedua bisa didistribusikan di antara pembangun dan relay. Ini memungkinkan pengembalian tawaran kepada pembangun, namun untuk mengaktifkan ini, pembangun perlu menyetujuinya dengan cara memberikan hal berikut:
   1. Mengirim sejumlah agunan sehingga relay memiliki likuiditas untuk membayar jumlah penawaran tertinggi kedua kepada para proposer. Sebagai alternatif, relay juga bisa menyelesaikan langsung dengan para builder setelah pengiriman payload, yang mungkin memerlukan relay untuk memiliki modal yang cukup. Penyelesaian pasca-likuiditas pada dasarnya adalah kredit jangka pendek yang diberikan oleh relay kepada para builder. Oleh karena itu, relay bisa menjelajahi ide untuk membebankan bunga pada kredit jangka pendek sebagai cara monetisasi lainnya.
   2. Merkle path ke transaksi terakhir sehingga relay dapat memodifikasi transaksi terakhir dan oleh karena itu header.
2. Pendekatan ini sepenuhnya memanfaatkan kompetisi laten yang sudah terjadi di antara para pembangun/relay dan berusaha untuk mendapatkan manfaat darinya. Namun, ada beberapa kekhawatiran:
   1. Karena pembangun pemenang menerima diskon pada selisih antara penawaran mereka dan penawaran tertinggi kedua yang diajukan melalui relay lain. Ini akan memberikan insentif kepada pembangun teratas untuk mengirimkan penawaran mereka HANYA ke relay yang paling baik kinerjanya (latensi terendah + cakupan validator yang luas) untuk memaksimalkan diskon mereka. Jika sebagian besar pembangun memilih pendekatan Ultrasound, akan sedikit atau bahkan tidak ada insentif bagi pembangun untuk mengirimkan penawaran mereka ke beberapa relay karena itu akan mengurangi diskon mereka menjadi nol, menyebabkan sentralisasi relay di mana satu entitas menangani lebih dari separuh pengiriman payload. Ini berpotensi membuat ruang relay bahkan lebih terpusat daripada ruang pembangun yang sudah terpusat. Bahkan jika semua relay teratas mencapai konsensus sosial tentang menerapkan model biaya ini, itu akan mengakibatkan sentralisasi penawaran dan relay.
   2. Kompetisi relay dapat menyebabkan inflasi % rebate, yang mengakibatkan perlombaan untuk memberikan rebate tertinggi (pendapatan relay terendah). Untuk mengatasi hal ini, mungkin diperlukan konsensus sosial di antara relay kompetitif teratas untuk setuju pada % rebate dan mekanisme penyesuaian.

Pendekatan yang diusulkan ini sangat menarik dan layak untuk menjelajahi lebih banyak ide di atasnya. Sebagai contoh, daripada menghitung delta antara penawaran tertinggi dari relay lain, kita bisa menjelajahi menggunakan delta dari penawaran tertinggi dan kedua tertinggi yang diterima dalam relay yang sama. Dengan demikian, pembangun bisa mengirimkan penawaran ke beberapa relay seperti biasa, dan relay tercepat yang mengirimkan penawaran teratas dan payload dapat menagih biaya dan memberikan diskon. Ini masih akan menuntut kompetisi latensi di antara relay namun dapat mencegah over-centralization relay dengan tidak mengurangi insentif pengajuan penawaran pembangun ke relay yang bersaing.

Jika pembangun membayar: Pembayaran ditangguhkan

Diagram yang mengilustrasikan pembayaran tertunda oleh para pembangun

1. Relay akan menyiapkan kontrak pintar di mana pembangun dapat memposting beberapa ETH sebagai jaminan biaya sebagai bentuk pembayaran di muka untuk penggunaan relay. Setiap bulan (atau beberapa interval waktu tertentu), relay dapat memeriksa total jumlah penawaran dan penawaran pemenang yang diajukan oleh pembangun tertentu. Relay kemudian dapat memutuskan untuk membebankan pembangun sesuai dengan spesifikasi biaya mereka, seperti biaya % pada penawaran pemenang atau biaya tetap per penawaran pemenang, dll. Asumsi kepercayaan di sini adalah bahwa relay tidak menahan jaminan pembangun dan tidak membebankan biaya tambahan di luar spesifikasi biaya yang disepakati pada awalnya. Asumsi di sini adil bagi pembangun mengingat bahwa mereka sudah mempercayai relay untuk banyak tugas penting, seperti meneruskan penawaran/payload dan tidak membongkar dan mencuri MEV. Pendekatan ini memungkinkan ekspresi preferensi biaya relay yang fleksibel yang dapat lebih menyelaraskan insentif pembangun dan relay sambil mencegah over-centralization di antara relay. Namun, ada beberapa kekhawatiran:
   1. Pembayaran pembangun tertunda tidak memberikan rabat, oleh karena itu tidak kompetitif terhadap relay yang mengadopsi pendekatan pembayaran real-time Ultrasound (Yang terakhir memberikan rabat sementara yang pertama tidak)
   2. Pembangun mungkin mencoba untuk menghindari pembayaran tertunda ini dengan menjalankan relay mereka sendiri, tetapi karena faktor-faktor yang saya sebutkan sebelumnya, mungkin tidak sepadan bagi pembangun untuk mengeluarkan biaya dan usaha untuk menjalankan relay mereka sendiri jika biaya yang dibebankan wajar (berdasarkan penawaran menang dll.) dan cukup rendah (5% per penawaran menang).
2. Pembayaran tertunda sederhana dan fleksibel, hanya memerlukan jaminan pembangun yang relatif kecil sebagai pembayaran di muka yang dapat dipilih. Namun, menarik pembangun mungkin lebih menantang jika relay alternatif menawarkan diskon. Karena persyaratan jaminan yang lebih kecil, ini mungkin lebih cocok untuk pembangun dengan sumber daya yang lebih sedikit yang tidak bersedia menempatkan jaminan besar.

Jika validator membayar: Pembayaran real-time

MEV-Boost saat ini memetakan penawaran yang diterima dengan relay yang sesuai melalui \
relays[BlockHashHex(bidInfo.blockHash.String())] = append(relays[BlockHashHex(bidInfo.blockHash.String())], relay)

1. sehingga para pengusul dapat melacak semua pasangan tawaran-relay yang diterima. Ini memungkinkan para pengusul untuk melihat tawaran yang masuk dengan relay yang terkait dan jumlah tawaran yang tumpang tindih yang berasal dari relay yang berbeda. Namun, bidang penerima biaya dalam MEV-Boost digunakan untuk mendistribusikan imbalan validator ke alamat yang ditunjuk, biasanya validator sendiri. Oleh karena itu, konstruksi MEV-Boost saat ini melacak tawaran relay tetapi tidak memungkinkan pembayaran kepada entitas tambahan seperti relay. Untuk memungkinkan hal itu, ada dua solusi yang mungkin:
   1. Modifikasi MEV-Boost untuk memungkinkan penambahan penerima biaya tambahan untuk relay. Juga perlu menambahkan logika yang diperlukan untuk menentukan mekanisme distribusi biaya, seperti First-Come-First-Serve atau pembagian yang sama di antara relay yang menangani penawaran menang. Namun, melanjutkan rute ini akan memerlukan upaya Herculean dalam memperbarui MEV-Boost di seluruh validator yang ada di PBS dan tidak realistis dari sudut keselarasan insentif; tidak masuk akal bagi validator untuk memperbarui klien mereka sehingga mereka dapat dikenai biaya relay.
   2. Validasi memilih masuk ke PEPC/Eigenlayer di mana mereka berkomitmen untuk membayar biaya relay, misalnya % dari tawaran tertinggi. Pendekatan ini tidak memerlukan banyak koordinasi tetapi mungkin tidak efektif dalam menghasilkan pendapatan relay yang bermakna. Validator mungkin memilih masuk karena kebaikan publik tetapi harus menanggung risiko pemotongan, yang jelas tidak sejalan dengan insentif validator. Terlepas dari apakah memiliki modifikasi MEV-Boost atau tidak, pembayaran real-time oleh validator memerlukan pilihan masuk dari ribuan operator node, dan banyak mungkin tidak memilih untuk melakukannya karena biaya yang lebih rendah (tawaran) yang akan mereka terima dalam kedua skenario.

Jika validator membayar: Pembayaran Ditangguhkan

1. Mirip dengan pembayaran tertunda builder, relay dapat membuat kontrak untuk validator untuk memposting jaminan ETH dan mengenakan biaya sesuai dengan preferensi biaya. Ini kemungkinan akan menjadi model opt-in karena sulit untuk meyakinkan dan menyelaraskan ribuan operator node (jauh lebih mudah dilakukan dengan builder dengan upaya kolektif). Namun, ini bisa menjadi perpanjangan dari mekanisme biaya tertunda builder di mana validator yang baik hati dapat berkontribusi pada kolam jaminan selain dari builder.

Pemikiran Penutup

Setelah menjelajahi dinamika insentif seputar pembangun/validator dan pendekatan untuk insentif relay yang berkelanjutan, beberapa hal menjadi jelas:

1. Kebaikan publik (tanpa memungut biaya) akan selalu mengarah pada perlombaan ke dasar: Bahkan jika Ultrasound dan bloXroute mencoba untuk menangkap nilai pada keunggulan latensi, penangkapan nilai akan terpaksa nol jika ada relay kebaikan publik yang sama kompetitif dan netral yang menyediakan optimasi latensi yang serupa.

2. Konsensus sosial di antara relay netral utama untuk menarik diri dari kebaikan publik diperlukan: Setidaknya semua relay utama saat ini (sebagian besar di antaranya netral) seharusnya secara kolektif mengakhiri relay gratis dan mulai bereksperimen dengan opsi masuk dalam skema insentif yang diusulkan.

3. Lebih mudah untuk mengenakan biaya kepada para pembangun: Menerapkan pembayaran validator membutuhkan koordinasi yang besar dan penyelarasan insentif di antara ribuan operator node. Hal ini menjadi lebih sulit mengingat pendapatan relay selalu berasal dari pendapatan tawaran proposer. Selain itu, validator memiliki pengaruh atas relay karena registrasi validator yang lebih banyak memungkinkan relay yang lebih kompetitif, sehingga menarik lebih banyak tawaran dari para pembangun. Oleh karena itu, saya percaya lebih praktis untuk meyakinkan 20-30 pembangun dan mencoba menyelaraskan insentif mereka.

4. Pertarungan antara insentif relay dan sentralisasi: Dalam merancang skema insentif relay kami, kami harus mempertimbangkan risiko sentralisasi dari relay yang muncul dari persaingan laten. Idealnya, kami ingin pasar relay kerjasama yang memastikan pengiriman payload kolaboratif untuk liveness maksimum sambil masih memungkinkan monetisasi, yang dapat berasal dari keuntungan laten. Penting juga untuk dicatat bahwa munculnya pembangun blok terdistribusi seperti SUAVE membantu mengurangi kebutuhan akan relay karena memindahkan beban kepercayaan pada validasi txs ke TEE yang diperkuat.

Sementara masih banyak pekerjaan yang harus dilakukan dalam mencari pendekatan yang tepat untuk mendorong relai secara berkelanjutan, saya harap tulisan ini dapat membantu memperjelas beberapa dinamika insentif yang belum terjamah dan tantangan teknis yang terkait dengan berbagai pendekatan untuk mengatasi masalah insentif relai ini. Saya juga berharap untuk melihat lebih banyak diskusi di masa depan seputar insentif relai untuk mendorong inisiatif ini ke depan.

Disclaimer：

1. Artikel ini diambil dari [Relaycermin]. Semua hak cipta milik penulis asli [Ballsyalchemist]. Jika ada keberatan terhadap cetakan ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.
2. Penyangkalan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini sepenuhnya merupakan milik penulis dan tidak merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau melakukan plagiarisme terhadap artikel yang diterjemahkan dilarang.