TL;DR

• ePBS dirancang dengan fokus pada keamanan Builder, memberikan kontrol penuh kepada Builder atas transaksi blok.
• Ini mengintegrasikan Proposer-Builder Separation (PBS) langsung ke lapisan konsensus Ethereum, yang disebut In-Protocol PBS, untuk mengatasi kegagalan relay potensial dan menghilangkan titik-titik kegagalan sistem tunggal.
• ePBS melanjutkan dasar PBS dengan mengurangi kontrol entitas tunggal atas konten blok, meningkatkan ketahanan sensor jaringan dan desentralisasi.
• Komite Keberadaan Payload (PTC) memastikan keberadaan dan validitas transaksi dalam blok baru.

Pengenalan

Pada bulan Februari, pengembang Prysm Potuz mengutarakan kekhawatiran tentang masalah kepercayaan di mainnet Ethereum, menyarankan penundaan fork Electra hingga 2025, menggunakan Acara Interoperabilitas untuk menyempurnakan desain ePBS. Namun, ada pendapat yang bervariasi dalam komunitas Ethereum, dengan beberapa pengembang dan peneliti khawatir tentang risiko potensial. Pendapat tentang ePBS terbagi, jadi hari ini kita akan menjelajahi apa itu ePBS dan bagaimana perbedaannya dengan PBS.

Sebelumnya, kami menyebutkan bahwa mekanisme PBS memastikan keamanan komitmen Proposer dan penjelasan Builder dengan menugaskan tanggung jawab ini kepada relay terpercaya. Relay menyimpan konten blok dan memastikan bahwa Proposer menerima konten blok tetapi tidak dapat dengan mudah mencuri konten Builder. Namun, jika relay bersifat jahat, baik Proposer maupun Builder dapat dirugikan, dan mereka hanya dapat beralih ke relay lain dan berharap relay tersebut tidak bersifat jahat. Hal ini menimbulkan masalah: kita harus menemukan pihak ketiga terpercaya untuk delegasi. PBS adalah solusi off-chain yang bergantung pada konsensus komunitas dan kepatuhan sukarela, memerlukan koordinasi tambahan dan kepercayaan.

Dalam PBS, harus ada peran perantara untuk bertindak sebagai penangan kepercayaan pihak ketiga:

• Penyangga harus mempercayai perantara jika mereka ingin menjual hak konten blok.
• Pembangun harus mempercayai perantara jika mereka ingin membeli hak membangun blok.

Desain Revolusioner ePBS

Pemisahan Pembangun Penawar Bawaan

Pemisahan Enshrined Proposer-Builder (ePBS) adalah varian dari PBS yang terintegrasi langsung ke lapisan konsensus Ethereum, juga dikenal sebagai In-Protocol PBS. Ini dirancang untuk mengatasi kegagalan relay potensial dan menghilangkan titik-titik kegagalan tunggal sistem. Sebagai mekanisme konsensus yang sedang berkembang, sekarang kita akan mendalami ePBS, menjelaskan prinsip intinya, keunggulan, dan bagaimana perbedaannya dari Proposer-Builder Separation (PBS) tradisional.

PBS menggantikan kebutuhan akan peran relay yang dipercayai dengan menggunakan protokol Ethereum itu sendiri. Jika Proposer atau Builder bertindak dengan jahat, protokol Ethereum dapat memberlakukan sanksi (seperti penyitaan), menghilangkan ketergantungan pada kepercayaan terhadap peran pihak ketiga. Ini adalah perbedaan utama dari PBS, di mana kepercayaan bersifat eksternal.

Namun demikian, pemisahan peran dalam ePBS masih mengikuti struktur PBS asli, mengurangi kendali entitas tunggal terhadap konten blok, sehingga meningkatkan ketahanan sensor dan desentralisasi jaringan blockchain.

• Proposer: Bertanggung jawab untuk mengusulkan blok, termasuk informasi header blok.
• Builder: Bertanggung jawab untuk membangun konten blok.

Dua Manfaat Utama

Hukuman Langsung untuk Tindakan Jahat & Tidak Perlu Kepercayaan Pihak Ketiga

Dari namanya, jelas bahwa istilah "Dihormati" dalam ePBS mencerminkan desain terintegrasi protokolnya, memungkinkan hukuman langsung untuk perilaku jahat. Integrasi ini secara halus mengubah model kepercayaan dalam sistem.

1. Kemampuan Terintegrasi untuk Deteksi dan Penegakan

   Di PBS, mengidentifikasi dan memberi hukuman pada tindakan jahat bergantung pada intervensi pihak ketiga, seperti validator atau relay. Sebaliknya, ePBS, yang bersifat asli protokol, memungkinkan protokol itu sendiri untuk secara langsung mendeteksi dan menangani pelanggaran tanpa memerlukan keterlibatan eksternal.

2. Mengurangi Ketergantungan pada Pihak Ketiga, Meningkatkan Desentralisasi

   PBS secara inheren bergantung pada tata kelola eksternal atau pihak ketiga, yang memperkenalkan unsur sentralisasi kepercayaan. Namun, ePBS memasukkan aturan-aturan dalam protokol, secara mendasar mengurangi ketergantungan pada kepercayaan eksternal. Perubahan ini meningkatkan desentralisasi sistem, menjadikannya lebih kuat dan tahan terhadap manipulasi.

*Perbandingan antara PBS Tradisional dan ePBS👇

Desain ePBS

Tarian Eksekusi dan Verifikasi

Dalam sistem Proof of Stake (PoS) Ethereum, waktu untuk setiap slot dibagi menjadi interval 12 detik. Dalam setiap slot, validator dipilih secara acak untuk mengusulkan blok, dan komite ditugaskan untuk memverifikasi validitas blok. Jika blok tidak diusulkan selama slot yang diberikan, validator yang bertanggung jawab akan memverifikasi blok sebelumnya setelah 4 detik.

Sumber: ethresearch, satu slot ePBS akan diproses oleh Lapisan Konsensus (CL) dan Lapisan Eksekusi (EL). Informasi blok disiarkan di lapisan konsensus, dan kemudian blok dikirimkan ke lapisan eksekusi untuk verifikasi.

1. Fase Penawaran Blok: Builder mulai menawar dan mengirimkan penawaran ke Proposer.
2. Penyiar Proposal: Proposer memilih penawaran pemenang dan memutuskan apakah akan menggunakan Daftar Inklusi untuk membangun konten blok, kemudian menyiarakan blok tersebut.
3. Voting Validator: Setelah melihat blok, validator memberikan suara berdasarkan hasil verifikasi mereka.
4. Attestasi Agregat: Attestasi agregat dibuat oleh Aggregator, yang menggabungkan bukti validator yang berbeda untuk blok yang sama. Validator kemudian menggunakan attestasi agregat untuk memverifikasi blok.
5. Payload Broadcasting: Builder harus mempublikasikan payload eksekusi lengkap dalam waktu yang ditentukan.
6. Voting PTC: Komite Keteraturan Payload (PTC) mengawasi dan memverifikasi apakah payload Builder timely dan valid.
7. Proposer slot berikutnya menerbitkan blok mereka, membangunnya pada blok penuh atau kosong berdasarkan hasil voting PTC dan kesaksian yang diagregasi. Blok dengan persentase suara PT tepat waktu yang lebih tinggi dianggap sebagai blok penuh.

PTC - Memastikan Kepatutan Waktu dan Validitas Transaksi di Blok-blok Baru \Payload Timeliness Committee (PTC) memastikan bahwa transaksi di blok baru ditambahkan secara tepat waktu dan akurat. Komite ini terdiri dari validator (521 anggota yang dipinjam dari komite rantai suar), yang memeriksa apakah Builder telah menyelesaikan pengisian transaksi blok dan apakah transaksi ini dijalankan dengan benar sesuai dengan aturan sebelum akhir setiap siklus pembuatan blok.

Secara sederhana, PTC bertindak seperti tim pengawas, memastikan bahwa Pembangun menyerahkan pekerjaan mereka tepat waktu dan memasukkan transaksi yang benar di blok. Jika Builder melakukannya dengan baik dan menyerahkan blok yang diperlukan tepat waktu, PTC mengonfirmasinya melalui pemungutan suara. Dengan cara ini, jaringan dapat mengidentifikasi blok mana yang lengkap dan valid, dan mana yang mungkin memiliki masalah atau tidak lengkap.

Melalui mekanisme pemungutan suara, PTC memengaruhi apakah suatu blok dianggap sebagai blok penuh atau blok kosong. Jika PTC memverifikasi ketepatan waktu dan kebenaran payload, blok diakui sebagai blok penuh. Jika tidak ada payload atau payload mengalami keterlambatan, blok tersebut dapat ditandai sebagai blok kosong. Berdasarkan suara PTC, jaringan secara langsung memberikan imbalan atau hukuman kepada Proposer dan Builder untuk mendorong konstruksi blok yang tepat waktu dan akurat.

• Blok Penuh: Blok berisi satu set lengkap muatan yang valid, berpotensi termasuk beberapa transaksi, dan status eksekusi transaksi diperbarui tepat waktu.
• Blok Kosong: Blok ini berisi sangat sedikit atau tidak ada transaksi sama sekali. Ini mungkin merupakan blok CL, tetapi tidak memperbarui status EL.
• Blok Hilang: Slot kosong. Ini mengacu pada blok yang diharapkan tetapi tidak dibuat atau berhasil ditambahkan ke rantai. Blok yang hilang dapat diklasifikasikan sebagai penuh atau kosong berdasarkan suara pilihan garpu (blok, slot).

Ketahanan Sensor ePBS, Gabungan dengan Desain Daftar Inklusi

Sementara desain inti ePBS berkisar pada keamanan Builder dan memberikan kontrol penuh kepada Builder atas transaksi blok, implementasi Daftar Inklusi menjadikannya kombinasi yang sempurna untuk mencapai ketahanan sensor dan desentralisasi.

Dalam artikel-artikel sebelumnya, kami membahas tentang CLproses (untuk detail lebih lanjut, silakan kunjungi: https://mp.weixin.qq.com/s/EBzr0ttBLosYnRBNVKF6rg). Secara singkat, Penawar memberikan Daftar Transaksi yang harus diprioritaskan kepada Builder. Daftar ini harus mencakup semua transaksi yang sedang aktif, terlepas dari apakah mereka berada di dalam kolam transaksi. Selama masih ada ruang tersisa di blok, transaksi dari daftar harus dimasukkan ke dalam blok Builder. Jika blok sudah penuh, Builder harus dengan jelas menunjukkan dan mengkonfirmasi bahwa mereka telah menerima daftar tersebut.

Ketika seorang Builder mencoba menyensor transaksi tertentu, biaya dasar akan naik dengan cepat karena penerapan EIP-1559, karena blok terus-menerus diisi dengan transaksi. Jika Builder bersikeras menambahkan transaksi palsu ke blok untuk melakukan penyensoran, biaya yang meningkat akan membuat tindakan tersebut tidak terjangkau dan tidak praktis.

Ringkasan

ePBS memisahkan peran Proposer dan Builder melalui integrasi protokolnya. Dengan PTC bertindak sebagai subset dari komite verifikasi, ia bertanggung jawab untuk memilih validitas dan ketepatan waktu dari Execution Payload yang dirilis oleh Builder. Keuntungan inti dari ePBS terletak pada pergeserannya dari mengandalkan pihak ketiga yang dipercayai menjadi diawasi dan dikenai hukuman langsung oleh protokol Ethereum itu sendiri, mengurangi kebutuhan untuk mempercayai satu entitas. Ini tidak hanya meningkatkan ketahanan sensor sistem tetapi juga memperkuat perlindungan transaksi melalui mekanisme seperti Inclusion List, membuat biaya penyensoran transaksi terlalu tinggi dan tidak praktis.

Penting untuk dicatat bahwa ePBS menyediakan opsi pemisahan Proposer-Builder blok pada tingkat protokol, bukan menjadi wajib. Perbedaan utama antara ePBS dan model lainnya terletak pada mekanisme pembayaran dan model kepercayaan mereka. Ketika mempertimbangkan masalah kepercayaan dalam protokol secara keseluruhan, biaya yang harus dibayar adalah kebutuhan untuk berkomitmen membayar biaya di muka. Sebaliknya, MEV-Boost memungkinkan pembayaran kepada Beacon Proposer berdasarkan keuntungan yang diperoleh dari Execution Payload yang disusun, menawarkan lebih banyak ruang untuk profitabilitas. Mungkin suatu hari nanti, ePBS dapat berkembang menjadi titik di mana komitmen biaya di muka tidak lagi diperlukan - ini adalah harapan kecil untuk masa depan!

Referensi

@ttsao/epbs-faq0"">https://hackmd.io/@ttsao/epbs-faq0

@potuz/rJ9GCnT1C"">https://hackmd.io/@potuz/rJ9GCnT1C

https://mirror.xyz/ohotties.eth/kw_7qbkOl4NV1pmpRgVwtsS-7TZff_zTmmNEOm2BbmU

https://mirror.xyz/barnabe.eth/LJUb_TpANS0VWi3TOwGx_fgomBvqPaQ39anVj3mnCOg

https://ethresear.ch/t/epbs-design-constraints/18728?u=barnabe

@potuz/ry9NirU2p"">https://hackmd.io/@potuz/ry9NirU2p

https://vitalik.eth.limo/general/2023/09/30/enshrinement.html

https://ethresear.ch/t/three-dichotomies-in-epbs/16267

https://ethresear.ch/t/the-contention-between-preconfs-and-epbs/19770?utm_source=substack&utm_medium=email

Disclaimer：

1. Artikel ini dicetak ulang dari [Uncommons], Semua hak cipta adalah milik penulis asli [Jocelyn]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Gerbang Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penolakan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata merupakan milik penulis dan tidak merupakan saran investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Belajar gate. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.