Desain inti ePBS dibangun dengan fokus pada keamanan Builder, memberikan kendali penuh kepada Builder atas transaksi Blok.
ePBS adalah proposal untuk mengintegrasikan PBS langsung ke lapisan konsensus Ethereum, yang dikenal sebagai In-Protocol PBS, untuk mengatasi potensi kegagalan Relay dan menghilangkan titik kegagalan tunggal dalam sistem.
ePBS masih mengikuti dasar dari PBS asli, meningkatkan resistensi pensensoran dan desentralisasi jaringan melalui kemampuan Drop entitas tunggal untuk mengontrol konten Blok.
Komite Keberlanjutan Payload (PTC) bertindak sebagai pengawas untuk memastikan ketepatan waktu dan efektivitas konten transaksi di dalam blok baru.
Pendahuluan
Pada bulan Februari, pengembang Prysm Potuz menganggap ada masalah kepercayaan dalam jaringan utama ETH dan mendorong penundaan fork Electra hingga tahun 2025 untuk menyempurnakan desain ePBS melalui acara Interop. Namun, komunitas ETH memiliki pendapat yang berbeda tentang ePBS, beberapa pengembang dan peneliti khawatir tentang risiko yang mungkin ditimbulkannya. Pendapat tentang ePBS beragam, hari ini kita akan memahami apa itu ePBS? Dan apa perbedaannya dengan PBS.
Sebelumnya kami menyebutkan bahwa mekanisme PBS dirancang untuk memastikan keamanan dari Proposer dan memastikan keamanan dari Builder, oleh karena itu hak ini diberikan kepada Relay yang dipercayai. Relay bertanggung jawab untuk menyimpan konten Blok, memastikan bahwa Proposer akan menerima konten Blok tetapi tidak dapat dengan mudah mencuri konten Blok dari Builder. Tetapi jika Relay bersifat jahat, baik Proposer maupun Builder akan menjadi korban, dan mereka hanya dapat beralih dan bekerja sama dengan Relay lainnya serta berharap bahwa Relay lainnya tidak bersifat jahat. Di sini terdapat masalah, kami harus menemukan pihak ketiga yang dapat dipercayai untuk melakukan penugasan kepercayaan. Karena PBS adalah solusi di luar protokol. PBS bergantung pada Konsensus masyarakat dan kepatuhan sukarela, membutuhkan koordinasi dan kepercayaan tambahan.
Di PBS, harus ada peran middleman sebagai pihak kreditur pihak ketiga untuk menangani masalah:
Jika Proposer ingin menjual hak konten Blok, harus mempercayai middleman.
Builder yang ingin membeli hak untuk membangun Blok harus mempercayai middleman.
Desain revolusioner ePBS
Pemisahan Pembangun dan Penyumbang Bawaan
Enshrined Proposer-Builder Separation (ePBS) adalah variasi lain yang berasal dari PBS. ePBS adalah proposal untuk menyertakan PBS langsung ke lapisan Konsensus ETH, sehingga juga dikenal sebagai In-Protocol PBS. Kelahirannya bertujuan untuk mengatasi potensi kegagalan Relay dan menghilangkan kegagalan titik tunggal dalam sistem. Sebagai Mekanisme Konsensus yang baru berkembang, selanjutnya kami akan mendalaminya untuk menjelaskan prinsip intinya, keunggulan, dan perbedaannya dengan Proposer-Builder Separation (PBS) tradisional.
ePBS, yaitu pemisahan proposer-builder yang tertanam, mekanisme yang tertanam dalam protokol blockchain. Menggantikan peran Relay yang harus dipercayai dengan protokol Ethereum, sehingga jika salah satu pihak proposer atau builder berbuat jahat, hukuman (slashing) dapat diberlakukan oleh protokol Ethereum itu sendiri, bukan bergantung pada kepercayaan terhadap suatu peran. Ini juga merupakan perbedaan dan perbedaan terbesar antara seluruh protokol dan protokol PBS yang pernah kita sebutkan sebelumnya.
Tentu saja, pemisahan peran dalam penerapan ePBS masih mengikuti dasar PBS asli, dengan meningkatkan tingkat resistensi pensensoran dan desentralisasi jaringan Blockchain melalui kemampuan Drop entitas tunggal untuk mengendalikan konten Blok.
Proposer：Bertanggung jawab atas proposisi Blok, termasuk informasi Header Blok
Builder: Konten spesifik Blok yang dibangun
Dua Keuntungan Besar
Menghukum tindakan jahat secara langsung tanpa perlu pihak ketiga yang dipercaya
Dari namanya saja, Anda dapat mengetahui bahwa Enshrined di ePBS dapat diketahui karena melakukan pekerjaan internalisasi protokol, juga akan langsung menghukum tindakan jahat, dan pusat kepercayaan juga mengalami perubahan diam-diam di bawah pengaturan ini.
protokol memiliki kemampuan untuk mengenali dan menangani, serta memberikan hukuman langsung
Di PBS, identifikasi dan hukuman tindakan jahat memerlukan intervensi pihak ketiga (validator, relay, dll). Namun dalam ePBS, karena desainnya di dalam protokol, tindakan jahat dapat langsung diidentifikasi dan ditangani oleh protokol itu sendiri.
Tidak perlu memberikan kredit kepada pihak ketiga, meningkatkan tingkat Desentralisasi
PBS sampai batas tertentu bergantung pada tata kelola eksternal atau pihak ketiga, yang menghadapi masalah sentralisasi kepercayaan. Sebaliknya, ePBS dengan menuliskan aturan ke dalam protokol, mengurangi kebutuhan kepercayaan pada pihak ketiga eksternal, meningkatkan tingkat desentralisasi sistem.
*Perbandingan PBS tradisional dan ePBS
Desain ePBS
Tarian Eksekusi dan Verifikasi
Di POS Ethereum, waktu slot dibagi menjadi interval 12 detik. Di setiap slot, validator dipilih secara acak untuk mengusulkan sebuah Blok. Sementara itu, sebuah komite ditentukan untuk memverifikasi kevalidan Blok. Jika sebuah Blok tidak diajukan dalam slot yang diberikan, 4 detik kemudian, validator yang bertanggung jawab akan memverifikasi Blok sebelumnya.
sumber: ethresearch, satu slot ePBS akan ditangani oleh CL (layer konsensus) dan EL (layer eksekusi). Informasi Blok disiarkan di layer konsensus, kemudian Blok akan diserahkan ke layer eksekusi untuk diverifikasi.
Tahap BlokMenawar: Builder akan memulai Menawar dan mengirimkannya kepada Proposer.
pengusul Siaran: Pengusul memilih Menawar dan memilih apakah akan menggunakan Daftar Inklusi untuk membangun konten Blok mereka sendiri. Kemudian siarakan Blok.
Voting validator: Setelah melihat Blok, akan melakukan pemungutan suara berdasarkan hasil validasinya.
Bukti Gabungan (Aggregate attestation): Bukti gabungan dibuat oleh aggregator, yang menggabungkan bukti dari beberapa validator terhadap Blok yang sama. Validator memverifikasi melalui bukti gabungan.
Siaran Payload: Builder harus mempublikasikan Payload Eksekusi lengkap dalam waktu yang ditentukan.
PTC Voting: Komite Khusus, Pengawasan dan Verifikasi Payload Builder apakah tepat waktu dan efektif.
Proposer slot berikutnya merilis Blok mereka, dibangun di atas hasil pemungutan suara PTC dan bukti agregasi pada Blok lengkap atau Blok Kosong. Ketika persentase yang lebih tinggi dari suara PT dalam sebuah Blok dirilis tepat waktu, maka Blok tersebut akan dianggap sebagai Blok Penuh.
PTC, mengawasi konten transaksi dalam blok baru secara tepat waktu dan efektif
Komite Ketepatan Waktu Muatan (PTC), "Komite Ketepatan Waktu Muatan". Tugas utama adalah memastikan bahwa konten transaksi di blok baru ditambahkan secara tepat waktu dan akurat. Komite ini terdiri dari validator (521 orang yang dipinjam dari Dewan Rantai Suar sebagai bagian dari komite) yang tugasnya adalah memeriksa bahwa Pembangun telah selesai mengisi transaksi blok dan bahwa mereka dijalankan dengan benar sesuai dengan aturan sebelum akhir setiap siklus pembuatan blok.
Secara sederhana, PTC seperti tim pengawas yang memantau apakah Builder telah mengirimkan pekerjaan mereka tepat waktu dan apakah mengandung Blok transaksi yang benar. Jika Builder melakukan pekerjaan dengan baik, mengirimkan Blok yang memenuhi syarat tepat waktu, PTC akan mengkonfirmasi hal ini melalui pemungutan suara. Dengan demikian, jaringan dapat mengetahui Blok mana yang lengkap dan valid, serta mana yang mungkin bermasalah atau tidak lengkap.
Melalui mekanisme voting, PTC memengaruhi status Blok sebagai "Blok penuh" atau "Blok Kosong". Jika PTC memverifikasi keakuratan dan ketepatan waktu beban, Blok tersebut dapat dianggap sebagai "Blok penuh"; jika tidak ada beban atau beban disampaikan dengan latensi, Blok dapat ditandai sebagai "Blok Kosong". Selanjutnya, berdasarkan hasil voting PTC, jaringan secara langsung memberikan insentif atau hukuman kepada Proposer dan Builder untuk mendorong pembangunan Blok yang tepat waktu dan akurat.
Blok lengkap (full block): Blok mengandung serangkaian payload yang valid, dan juga dapat mengandung beberapa transaksi, dan status eksekusi transaksi akan diperbarui secara tepat waktu.
Blok Kosong（empty block）：Blok hampir tidak mengandung transaksi apa pun, atau hanya mengandung sangat sedikit transaksi. Itu bisa menjadi blok CL, tetapi tidak akan memperbarui status EL.
Implementasi resistensi pensensoran ePBS, dikombinasikan dengan desain Inclusion List
Meskipun desain inti ePBS dibangun dengan fokus pada keamanan Builder, itu memberikan kontrol penuh kepada Builder atas transaksi Blok. Oleh karena itu, menggabungkan Daftar Inklusi akan menjadi bentuk kombinasi yang sangat sempurna untuk mencapai ketahanan terhadap penyensoran dan desentralisasi.
Sebelumnya kami telah menyebutkan CL dalam artikel kami, secara umum menjelaskan prosesnya (untuk detail, klik tautan: undefined). ** Berikan daftar ini kepada Builder, prioritaskan transaksi-transaksi ini. Daftar ini harus mencakup semua transaksi yang sedang aktif, baik transaksi tersebut berada di dalam kolam transaksi atau tidak. Selama Blok masih memiliki ruang kosong, transaksi dalam daftar harus dimasukkan ke dalam Blok Builder. Jika Blok penuh, Builder harus dengan jelas menandai dan mengonfirmasi bahwa mereka telah memperhatikan daftar ini.
Ketika Builder mencoba untuk memeriksa beberapa transaksi, karena pelaksanaan EIP-1559, Blok yang terus diisi dengan transaksi akan menyebabkan biaya dasarNaik dengan cepat. Jika saat ini Builder tetap mempertahankan pemeriksaan dengan menambahkan transaksi palsu ke Blok, biaya yang terus meningkat akan membuat tindakan ini menjadi terlalu mahal dan tidak lagi praktis.
Ringkasan
ePBS melalui protokol internal, memisahkan peran proposer dan builder. Melalui PTC sebagai subset dari komite bukti, bertanggung jawab untuk memberikan suara mengenai validitas dan ketepatan waktu ution Payload yang diterbitkan oleh Builder. Keunggulan intinya adalah mengubah peran pihak ketiga yang dipercayai secara tradisional menjadi protokol Ethereum itu sendiri untuk melaksanakan pengawasan dan hukuman, sehingga mengurangi kebutuhan kepercayaan pada entitas tunggal. Ini tidak hanya meningkatkan resistensi pensensoran sistem, tetapi juga melalui mekanisme seperti Daftar Inklusi, memperkuat perlindungan transaksi, membuat biaya pemeriksaan transaksi menjadi mahal dan tidak praktis.
Selain itu, ePBS hanya menyediakan pilihan pemisahan Blok Proposer dan Builder pada tingkat protokol, bukan keharusan. Perbedaan terbesar mereka adalah mekanisme pembayaran dan model kepercayaan. Ketika mempertimbangkan masalah kepercayaan dalam seluruh protokol, biaya yang harus dibayar adalah komitmen pembayaran di muka. Dibandingkan dengan ePBS, MEV-Boost dapat memutuskan jumlah pembayaran kepada Beacon Proposer berdasarkan keuntungan yang dihasilkan dari Payload ution yang diurutkan sendiri, dengan lebih banyak keuntungan dan ruang. Mungkin suatu hari mekanisme ePBS bisa diimplementasikan tanpa perlu mempertimbangkan biaya komitmen di muka, dengan harapan dan impian kecil!
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Krisis Kepercayaaan Diri实验 ePBS的protokol内置
TL;DR
Pendahuluan
Pada bulan Februari, pengembang Prysm Potuz menganggap ada masalah kepercayaan dalam jaringan utama ETH dan mendorong penundaan fork Electra hingga tahun 2025 untuk menyempurnakan desain ePBS melalui acara Interop. Namun, komunitas ETH memiliki pendapat yang berbeda tentang ePBS, beberapa pengembang dan peneliti khawatir tentang risiko yang mungkin ditimbulkannya. Pendapat tentang ePBS beragam, hari ini kita akan memahami apa itu ePBS? Dan apa perbedaannya dengan PBS.
Sebelumnya kami menyebutkan bahwa mekanisme PBS dirancang untuk memastikan keamanan dari Proposer dan memastikan keamanan dari Builder, oleh karena itu hak ini diberikan kepada Relay yang dipercayai. Relay bertanggung jawab untuk menyimpan konten Blok, memastikan bahwa Proposer akan menerima konten Blok tetapi tidak dapat dengan mudah mencuri konten Blok dari Builder. Tetapi jika Relay bersifat jahat, baik Proposer maupun Builder akan menjadi korban, dan mereka hanya dapat beralih dan bekerja sama dengan Relay lainnya serta berharap bahwa Relay lainnya tidak bersifat jahat. Di sini terdapat masalah, kami harus menemukan pihak ketiga yang dapat dipercayai untuk melakukan penugasan kepercayaan. Karena PBS adalah solusi di luar protokol. PBS bergantung pada Konsensus masyarakat dan kepatuhan sukarela, membutuhkan koordinasi dan kepercayaan tambahan.
Di PBS, harus ada peran middleman sebagai pihak kreditur pihak ketiga untuk menangani masalah:
Desain revolusioner ePBS
Pemisahan Pembangun dan Penyumbang Bawaan
Enshrined Proposer-Builder Separation (ePBS) adalah variasi lain yang berasal dari PBS. ePBS adalah proposal untuk menyertakan PBS langsung ke lapisan Konsensus ETH, sehingga juga dikenal sebagai In-Protocol PBS. Kelahirannya bertujuan untuk mengatasi potensi kegagalan Relay dan menghilangkan kegagalan titik tunggal dalam sistem. Sebagai Mekanisme Konsensus yang baru berkembang, selanjutnya kami akan mendalaminya untuk menjelaskan prinsip intinya, keunggulan, dan perbedaannya dengan Proposer-Builder Separation (PBS) tradisional.
ePBS, yaitu pemisahan proposer-builder yang tertanam, mekanisme yang tertanam dalam protokol blockchain. Menggantikan peran Relay yang harus dipercayai dengan protokol Ethereum, sehingga jika salah satu pihak proposer atau builder berbuat jahat, hukuman (slashing) dapat diberlakukan oleh protokol Ethereum itu sendiri, bukan bergantung pada kepercayaan terhadap suatu peran. Ini juga merupakan perbedaan dan perbedaan terbesar antara seluruh protokol dan protokol PBS yang pernah kita sebutkan sebelumnya.
Tentu saja, pemisahan peran dalam penerapan ePBS masih mengikuti dasar PBS asli, dengan meningkatkan tingkat resistensi pensensoran dan desentralisasi jaringan Blockchain melalui kemampuan Drop entitas tunggal untuk mengendalikan konten Blok.
Dua Keuntungan Besar
Menghukum tindakan jahat secara langsung tanpa perlu pihak ketiga yang dipercaya
Dari namanya saja, Anda dapat mengetahui bahwa Enshrined di ePBS dapat diketahui karena melakukan pekerjaan internalisasi protokol, juga akan langsung menghukum tindakan jahat, dan pusat kepercayaan juga mengalami perubahan diam-diam di bawah pengaturan ini.
Di PBS, identifikasi dan hukuman tindakan jahat memerlukan intervensi pihak ketiga (validator, relay, dll). Namun dalam ePBS, karena desainnya di dalam protokol, tindakan jahat dapat langsung diidentifikasi dan ditangani oleh protokol itu sendiri.
PBS sampai batas tertentu bergantung pada tata kelola eksternal atau pihak ketiga, yang menghadapi masalah sentralisasi kepercayaan. Sebaliknya, ePBS dengan menuliskan aturan ke dalam protokol, mengurangi kebutuhan kepercayaan pada pihak ketiga eksternal, meningkatkan tingkat desentralisasi sistem.
*Perbandingan PBS tradisional dan ePBS
Desain ePBS
Tarian Eksekusi dan Verifikasi
Di POS Ethereum, waktu slot dibagi menjadi interval 12 detik. Di setiap slot, validator dipilih secara acak untuk mengusulkan sebuah Blok. Sementara itu, sebuah komite ditentukan untuk memverifikasi kevalidan Blok. Jika sebuah Blok tidak diajukan dalam slot yang diberikan, 4 detik kemudian, validator yang bertanggung jawab akan memverifikasi Blok sebelumnya.
sumber: ethresearch, satu slot ePBS akan ditangani oleh CL (layer konsensus) dan EL (layer eksekusi). Informasi Blok disiarkan di layer konsensus, kemudian Blok akan diserahkan ke layer eksekusi untuk diverifikasi.
PTC, mengawasi konten transaksi dalam blok baru secara tepat waktu dan efektif
Komite Ketepatan Waktu Muatan (PTC), "Komite Ketepatan Waktu Muatan". Tugas utama adalah memastikan bahwa konten transaksi di blok baru ditambahkan secara tepat waktu dan akurat. Komite ini terdiri dari validator (521 orang yang dipinjam dari Dewan Rantai Suar sebagai bagian dari komite) yang tugasnya adalah memeriksa bahwa Pembangun telah selesai mengisi transaksi blok dan bahwa mereka dijalankan dengan benar sesuai dengan aturan sebelum akhir setiap siklus pembuatan blok.
Secara sederhana, PTC seperti tim pengawas yang memantau apakah Builder telah mengirimkan pekerjaan mereka tepat waktu dan apakah mengandung Blok transaksi yang benar. Jika Builder melakukan pekerjaan dengan baik, mengirimkan Blok yang memenuhi syarat tepat waktu, PTC akan mengkonfirmasi hal ini melalui pemungutan suara. Dengan demikian, jaringan dapat mengetahui Blok mana yang lengkap dan valid, serta mana yang mungkin bermasalah atau tidak lengkap.
Melalui mekanisme voting, PTC memengaruhi status Blok sebagai "Blok penuh" atau "Blok Kosong". Jika PTC memverifikasi keakuratan dan ketepatan waktu beban, Blok tersebut dapat dianggap sebagai "Blok penuh"; jika tidak ada beban atau beban disampaikan dengan latensi, Blok dapat ditandai sebagai "Blok Kosong". Selanjutnya, berdasarkan hasil voting PTC, jaringan secara langsung memberikan insentif atau hukuman kepada Proposer dan Builder untuk mendorong pembangunan Blok yang tepat waktu dan akurat.
Implementasi resistensi pensensoran ePBS, dikombinasikan dengan desain Inclusion List
Meskipun desain inti ePBS dibangun dengan fokus pada keamanan Builder, itu memberikan kontrol penuh kepada Builder atas transaksi Blok. Oleh karena itu, menggabungkan Daftar Inklusi akan menjadi bentuk kombinasi yang sangat sempurna untuk mencapai ketahanan terhadap penyensoran dan desentralisasi.
Sebelumnya kami telah menyebutkan CL dalam artikel kami, secara umum menjelaskan prosesnya (untuk detail, klik tautan: undefined). ** Berikan daftar ini kepada Builder, prioritaskan transaksi-transaksi ini. Daftar ini harus mencakup semua transaksi yang sedang aktif, baik transaksi tersebut berada di dalam kolam transaksi atau tidak. Selama Blok masih memiliki ruang kosong, transaksi dalam daftar harus dimasukkan ke dalam Blok Builder. Jika Blok penuh, Builder harus dengan jelas menandai dan mengonfirmasi bahwa mereka telah memperhatikan daftar ini.
Ketika Builder mencoba untuk memeriksa beberapa transaksi, karena pelaksanaan EIP-1559, Blok yang terus diisi dengan transaksi akan menyebabkan biaya dasarNaik dengan cepat. Jika saat ini Builder tetap mempertahankan pemeriksaan dengan menambahkan transaksi palsu ke Blok, biaya yang terus meningkat akan membuat tindakan ini menjadi terlalu mahal dan tidak lagi praktis.
Ringkasan
ePBS melalui protokol internal, memisahkan peran proposer dan builder. Melalui PTC sebagai subset dari komite bukti, bertanggung jawab untuk memberikan suara mengenai validitas dan ketepatan waktu ution Payload yang diterbitkan oleh Builder. Keunggulan intinya adalah mengubah peran pihak ketiga yang dipercayai secara tradisional menjadi protokol Ethereum itu sendiri untuk melaksanakan pengawasan dan hukuman, sehingga mengurangi kebutuhan kepercayaan pada entitas tunggal. Ini tidak hanya meningkatkan resistensi pensensoran sistem, tetapi juga melalui mekanisme seperti Daftar Inklusi, memperkuat perlindungan transaksi, membuat biaya pemeriksaan transaksi menjadi mahal dan tidak praktis.
Selain itu, ePBS hanya menyediakan pilihan pemisahan Blok Proposer dan Builder pada tingkat protokol, bukan keharusan. Perbedaan terbesar mereka adalah mekanisme pembayaran dan model kepercayaan. Ketika mempertimbangkan masalah kepercayaan dalam seluruh protokol, biaya yang harus dibayar adalah komitmen pembayaran di muka. Dibandingkan dengan ePBS, MEV-Boost dapat memutuskan jumlah pembayaran kepada Beacon Proposer berdasarkan keuntungan yang dihasilkan dari Payload ution yang diurutkan sendiri, dengan lebih banyak keuntungan dan ruang. Mungkin suatu hari mekanisme ePBS bisa diimplementasikan tanpa perlu mempertimbangkan biaya komitmen di muka, dengan harapan dan impian kecil!