Pada tanggal 2 April, pelaku jaringan Ethereum jahat mengeksploitasi kerentanan dalam relai MEV-Boost untuk mencuri $20 juta dari pencari MEV (lihat laporan Flashbots). Selama beberapa hari berikutnya, pengembang mengatasi kerentanan tersebut dengan merilis lima tambalan. Tambalan ini, dikombinasikan dengan penundaan jaringan dan kebijakan validator, menyebabkan fluktuasi singkat di jaringan Ethereum pada 6 April. Penataan ulang blok dapat merusak kesehatan jaringan karena memperlambat laju produksi blok dan mengurangi jaminan penyelesaian.
Dalam posting ini, dengan Seeker diserang dan jaringan sementara tidak stabil, kami menjelajahi interaksi antara MEV-Boost dan konsensus, menganalisis seluk-beluk mekanisme bukti saham Ethereum, dan membuat daftar beberapa kemungkinan langkah maju.
MEV-Boost dan mengapa itu penting
MEV-Boost adalah protokol yang dirancang oleh Flashbots dan komunitas untuk mengurangi dampak negatif dari Nilai Maksimum yang Dapat Diekstrak (MEV) pada jaringan Ethereum.
Ada 3 aktor di MEV-Boost:
Relay - Auctioneers yang saling percaya, menghubungkan produsen blok dan pembuat blok
Konstruktor - entitas kompleks yang membangun blok untuk memaksimalkan MEV untuk diri mereka sendiri dan pembuat blok
Urutan perkiraan peristiwa untuk setiap blok adalah:
Builder membuat blok dengan menerima transaksi dari pengguna, pencari, atau aliran pesanan (pribadi atau publik) lainnya
Pembangun mengirimkan blok ke relai
Relai memverifikasi validitas blok dan menghitung jumlah yang dibayarkan ke produsen blok
Relayer mengirimkan judul kosong dan nilai pembayaran ke produsen blok dari slot saat ini
Produsen Blok mengevaluasi semua tawaran yang telah mereka terima dan menandatangani tajuk kosong terkait dengan pembayaran tertinggi
Produser blok mengirimkan tajuk yang ditandatangani ini kembali ke relai
Relai menerbitkan blok menggunakan node beacon asli mereka dan mengembalikannya ke pemberi blok. Hadiah didistribusikan ke pembangun dan pengusul melalui transaksi dalam blok dan hadiah blok.
Relai adalah pihak ketiga tepercaya yang memfasilitasi pertukaran ruang blok yang adil oleh produsen blok dan pemesanan transaksi oleh pembangun untuk ekstraksi MEV. Relay melindungi pembangun dengan melindungi pembangun dari pencurian MEV, mencegah produsen blok menyalin transaksi pembangun untuk mengambil MEV tanpa mendistribusikannya ke pencari/pemborong yang menemukannya. Relai melindungi produsen blok dengan mengonfirmasi validitas blok mereka, memproses ratusan blok per slot atas nama mereka, dan memastikan keakuratan pembayaran produsen blok.
MEV-Boost adalah infrastruktur protokol utama karena memungkinkan semua produsen blok mengakses MEV secara demokratis tanpa memerlukan hubungan kepercayaan dengan pembangun atau pencari, yang berkontribusi pada desentralisasi Ethereum jangka panjang.
Aturan pemilihan fork Ethereum dan MEV-Boost
Sebelum membahas serangan dan respons, mari kita lihat mekanisme proof-of-stake Ethereum dan aturan pemilihan fork terkait. Aturan pilihan garpu memungkinkan jaringan untuk mencapai konsensus pada kepala rantai, seperti yang didefinisikan dalam artikel "reorganisasi pasca-merger Ethereum":
"Aturan pilihan garpu adalah fungsi yang dievaluasi oleh klien, yang mengambil sebagai input blok yang terlihat dan informasi lainnya, dan mengeluarkan "rantai kanonik" ke klien. Aturan pilihan garpu penting karena mungkin ada beberapa rantai yang valid untuk dipilih (misalnya, jika dua blok yang bersaing dengan blok induk yang sama diterbitkan pada waktu yang sama). "
Aturan pemilihan garpu juga bergantung pada waktu, yang berdampak signifikan pada pembuatan blok.
siklus slot dan sub-slot
Dalam mekanisme proof-of-stake Ethereum, waktu dibagi menjadi beberapa slot setiap 12 detik. Algoritme proof-of-stake secara acak memberikan lisensi kepada validator untuk mengusulkan blok di dalam slot itu; validator ini disebut produsen blok. Dalam slot yang sama, validator lain diberi tugas memvalidasi (voting) untuk kepala rantai yang menerapkan aturan fork-choice sesuai dengan pandangan lokal mereka. Slot 12 detik ini dibagi menjadi tiga fase, masing-masing berbiaya 4 detik.
Peristiwa yang terjadi pada slot adalah sebagai berikut, dimana t=0 menunjukkan awal dari slot.
Selama slot, momen paling kritis adalah batas waktu otentikasi pada t=4. Jika validator pengesahan tidak melihat blok pada batas waktu pengesahan, mereka akan memilih kepala rantai yang diterima sebelumnya (menurut aturan pilihan garpu). Semakin awal sebuah blok diusulkan, semakin banyak waktu yang dimilikinya untuk menyebar dan dengan demikian mengumpulkan lebih banyak persetujuan (karena lebih banyak validator yang melihatnya sebelum batas waktu persetujuan).
Dari perspektif kesehatan jaringan, waktu optimal untuk pelepasan blok adalah t=0 (menurut spesifikasi). Namun, karena nilai blok meningkat secara monoton dari waktu ke waktu, produsen blok memiliki insentif untuk menunda pelepasan blok mereka sehingga lebih banyak MEV dapat terakumulasi. Lihat Permainan pengaturan waktu di Proof-of-Stake dan diskusi ini untuk detailnya.
Sebelumnya, produsen blok dapat menerbitkan blok setelah batas waktu sertifikasi (bahkan mendekati akhir slot), selama validator berikutnya mengamati blok tersebut sebelum membuat blok untuk slot berikutnya. Ini karena blok anak mewarisi bobot blok induk, dan aturan pemilihan garpu berakhir di simpul daun. Oleh karena itu, menunda rilis blok tidak memiliki efek samping. Untuk membantu mengubah perilaku rasional (menunda rilis blok) menjadi perilaku jujur (menerbitkan tepat waktu), sebuah "reorg jujur" diterapkan.
Mekanisme Hadiah Blok Produser dan Reorganisasi Jujur
Dua konsep baru diperkenalkan ke klien konsensus yang berdampak penting pada tenggat waktu otentikasi.
Mekanisme Hadiah Produsen Blok - Bertujuan untuk meminimalkan serangan penyeimbangan ulang dengan memberikan "hadiah" pilihan garpu kepada produsen blok yang setara dengan 40% dari bobot autentikasi penuh. Yang penting, hadiah ini hanya berlaku untuk seluruh slot.
Reorganisasi yang jujur - manfaatkan akselerasi produsen blok, memungkinkan produsen blok yang jujur untuk memaksa reorganisasi blok dengan bobot autentikasi di bawah 20%. Ini sudah diterapkan di Lighthouse dan Prysm (dimulai dengan v4.0 - rilis Capella). Perubahan ini bersifat opsional karena merupakan keputusan yang dibuat oleh produsen blok dan tidak memengaruhi perilaku validator yang mengautentikasi. Jadi kami tidak menerapkannya ke semua klien pada saat yang sama, juga tidak terikat pada hard fork tertentu.
Perlu dicatat bahwa reorganisasi yang jujur dihindari dalam beberapa kasus khusus:
Selama blok batas zaman
Jika rantai belum selesai
Jika kepala rantai bukan kepala slot sebelum reorganisasi
Kasus 3 memastikan bahwa reorg yang jujur hanya menghapus satu blok dari rantai, yang bertindak sebagai pemutus arus, memungkinkan rantai untuk terus memproduksi blok selama periode latensi jaringan yang ekstrim. Hal ini juga mencerminkan bahwa pengusul kurang percaya pada persepsi jaringan, karena mereka tidak dapat memastikan apakah blok yang ditingkatkan yang diusulkan akan dianggap sebagai norma.
Gambar di bawah ini menunjukkan bagaimana perilaku jujur dapat diubah untuk menerapkan strategi restrukturisasi.
Dalam hal ini, misalkan b1 mewakili blok yang terlambat. Karena penundaan, b1 hanya memiliki 19% dari bobot pembuktian slot ke-n. Sisa 81% dari bobot bukti ditugaskan ke induk blok HEAD karena banyak pembuktian tidak melihat b1 sebelum batas waktu pembuktian.
Jika tidak ada reorganisasi yang jujur, pengusul slot n+1 akan menganggap b1 sebagai kepala rantai dan membangun sub-blok b2. Pengusul tidak melakukan upaya untuk menata ulang b1, padahal bobot pembuktiannya hanya 19%. Pada slot n+1, b2 memiliki peningkatan pengusul, dengan asumsi disampaikan tepat waktu, b2 akan menjadi norma dengan mengumpulkan mayoritas bukti untuk slot tersebut.
Dengan Reorganisasi Jujur, segalanya menjadi sangat berbeda. Sekarang, pengusul slot n+1 melihat bahwa 19% bobot bukti b1 berada di bawah ambang batas reorganisasi, jadi mereka membuat blok dengan HEAD sebagai induk dan memaksa b1 untuk mengatur ulang. Saat kita mencapai batas waktu pembuktian untuk slot n+1, pembukti yang jujur akan membandingkan bobot relatif b1 (19%) dengan b2 (40% dari dorongan pengusul). Semua klien mengimplementasikan peningkatan pengusul, jadi b2 akan dianggap sebagai kepala rantai dan akan mengumpulkan bukti untuk slot n+1.
Relay dan perbaikan node Beacon untuk serangan unbundling
Dalam serangan unbundling pada 2 April, pengusul mengeksploitasi kerentanan relai untuk mengirimkan tajuk tanda tangan yang tidak valid ke relai. Selama beberapa hari berikutnya, tim relai dan pengembangan inti merilis banyak tambalan perangkat lunak untuk mengurangi risiko serangan berulang. Lima perubahan utama adalah sebagai berikut:
Perubahan Relai: Periksa basis data untuk pengusul berbahaya yang diketahui (digunakan dalam produksi hanya dengan Relai Ultrasonik dan telah dihapus). Memeriksa apakah relai telah mengirimkan blok penuh ke slot di jaringan P2P. Memperkenalkan penundaan acak yang seragam dalam rentang 0-500ms sebelum blok diterbitkan (dihapus dari semua relai).
Perubahan simpul suar (relai simpul suar saja): Validasi blok suar sebelum disiarkan. Periksa jaringan untuk konfirmasi palsu sebelum memublikasikan blokir. Kombinasi dari perubahan ini menyebabkan ketidakstabilan konsensus, sebuah masalah yang diperparah oleh fakta bahwa mayoritas validator sekarang menggunakan strategi reorganisasi jujur yang dijelaskan di atas.
KONSEKUENSI YANG TIDAK DIINGINKAN
Kelima perubahan di atas semuanya memperkenalkan penundaan di jalur panas penerbitan blok relai, yang meningkatkan kemungkinan bahwa blok relai akan disiarkan setelah batas waktu konfirmasi. Diagram di bawah ini menunjukkan urutan kelima pemeriksaan ini dan bagaimana penundaan yang terjadi menyebabkan publikasi blok melampaui batas waktu konfirmasi.
Header yang ditandatangani dalam jumlah besar dengan jeda t = 0 (mis. t = 3) biasanya tidak menimbulkan masalah hingga pemeriksaan ini diterapkan. Karena relai memiliki overhead yang sangat rendah, relai akan menerbitkan blok sebelum t = 4 tanpa menunggu batas waktu konfirmasi.
Namun, karena keterlambatan pengenalan kelima tambalan ini, relai sekarang mungkin ikut bertanggung jawab atas keterlambatan siaran. Mari kita lihat proses penerbitan blok hipotetis di bawah ini.
Relai menerima header yang ditandatangani dari produser blok pada t = 3. Pada t = 4, relai masih melakukan pengecekan, sehingga siaran akan terjadi setelah batas waktu konfirmasi. Dalam hal ini, kombinasi dari header bertanda tertunda yang dikirim oleh produser blok dan beberapa penundaan tambahan yang diperkenalkan oleh relai menyebabkan kegagalan siaran sebelum batas waktu konfirmasi. Jika tidak ada reorganisasi yang jujur, blok-blok ini kemungkinan besar akan berhasil masuk ke dalam rantai. Seperti yang ditunjukkan pada Gambar 2, pembuat blok yang jujur dari slot berikutnya tidak akan dengan sengaja mengatur ulang karena blok ini terlambat. Namun, jika tenggat waktu konfirmasi terlewati, blok tersebut akan diatur ulang oleh produsen blok berikutnya.
Akibatnya, jumlah blok bercabang meningkat secara dramatis pada hari-hari setelah serangan itu.
Data selama dua minggu dari Metrika menunjukkan bahwa dalam skenario terburuk, 13 blok (4,3%) dapat diatur ulang dalam satu jam, yaitu sekitar 5 kali lipat dari kecepatan normal. Peningkatan dramatis dalam jumlah blok bercabang menjadi jelas saat para relai meluncurkan berbagai perubahan. Berkat upaya komunitas yang hebat dari operator relai dan pengembang inti, begitu dampaknya diketahui, banyak perubahan dibatalkan dan jaringan dipulihkan ke keadaan sehat.
Sampai hari ini, perubahan yang paling berguna adalah pemeriksaan validasi dan penolakan blok simpul suar sebelum diterbitkan. Pembuat blok berbahaya tidak dapat lagi melakukan serangan dengan mengirimkan header yang tidak valid ke relai dan memastikan node suar relai tidak melihat blok yang ditolak sebelum menerbitkannya. Meskipun demikian, relai masih menghadapi denial-of-attack yang lebih umum yang diajukan di MEV-Boost dan ePBS.
Tindakan Selanjutnya
Dalam posting ini, kami menyoroti cara kerja MEV-Boost dan betapa pentingnya konsensus Ethereum. Kami juga memberikan analisis terperinci dari beberapa aspek yang kurang dikenal dari aturan pilihan garpu Ethereum terkait waktu. Dengan menggunakan serangan "unbundling" dan respons pengembang sebagai studi kasus, kami menyoroti potensi kerentanan aspek-aspek yang bergantung pada waktu dari aturan pilihan fork dan dampaknya terhadap stabilitas jaringan.
Dengan mengingat hal ini, komunitas riset harus menilai berapa jumlah reorganisasi yang "dapat diterima", dengan mempertimbangkan paparan serangan penolakan yang lebih umum, untuk menentukan apakah mitigasi harus diterapkan.
Selain itu, beberapa arah masa depan saat ini sedang dieksplorasi secara aktif:
Terapkan mekanisme headlock untuk melindungi MEV-boost dari serangan kesalahan kesetaraan. Ini juga akan memerlukan perubahan pada perangkat lunak klien konsensus dan kemungkinan perubahan spesifikasi untuk memperpanjang batas waktu pengiriman bukti.
Meningkatkan jumlah dan distribusi program bug bounty untuk software MEV-Boost.
Perluas perangkat lunak simulasi untuk mengeksplorasi bagaimana pengaturan waktu sub-slot memengaruhi stabilitas jaringan, yang dapat digunakan untuk mengevaluasi cara menyesuaikan tenggat waktu pengiriman bukti untuk mengurangi reorganisasi.
Optimalkan jalur pelepasan blok pada relai untuk mengurangi penundaan yang tidak perlu - ini sudah dieksplorasi.
Mengakui MEV-boost sebagai fitur protokol inti dan memasukkannya ke dalam klien konsensus, yaitu "diabadikan-PBS (ePBS)". ePBS dua slot rentan terhadap serangan yang nyata, jadi menerapkan "mekanisme headlock" masih menjadi pilihan.
Dengan menambahkan lebih banyak pengujian sarang dan/atau spesifikasi seputar masalah seputar latensi dan tenggat waktu sertifikasi.
Dorong keragaman klien relai dengan membangun implementasi tambahan dari spesifikasi relai.
Pertimbangkan untuk menyesuaikan penalti untuk serangan yang jelas, tetapi perlu diingat bahwa bahkan penalti 32 ETH penuh pun tidak dapat mencegah perilaku jahat saat peluang MEV ekstrem ada.
Tinjau kembali waktu sub-slot dan pertimbangkan untuk menyesuaikan fase propagasi blok (misalnya, menyesuaikan tenggat waktu sertifikasi dari t=4 menjadi t=6).
Secara keseluruhan, kami sangat senang dengan kebangkitan MEV dan ekosistem mev-boost. Melalui pemisahan serangan dan mitigasi, kami telah belajar tentang hubungan kritis antara latensi, peningkatan MEV, dan mekanisme konsensus; kami berharap protokol akan terus diperkuat untuk menangani hal ini.
Lihat Asli
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.
Penjelasan terperinci tentang prinsip kerja MEV-Boost dan aturan pemilihan garpu Ethereum
Penulis: Georgios Konstantopoulos, Mike Neuder
Kompilasi: Kxp, BlockBeats
Perkenalan
Pada tanggal 2 April, pelaku jaringan Ethereum jahat mengeksploitasi kerentanan dalam relai MEV-Boost untuk mencuri $20 juta dari pencari MEV (lihat laporan Flashbots). Selama beberapa hari berikutnya, pengembang mengatasi kerentanan tersebut dengan merilis lima tambalan. Tambalan ini, dikombinasikan dengan penundaan jaringan dan kebijakan validator, menyebabkan fluktuasi singkat di jaringan Ethereum pada 6 April. Penataan ulang blok dapat merusak kesehatan jaringan karena memperlambat laju produksi blok dan mengurangi jaminan penyelesaian.
Dalam posting ini, dengan Seeker diserang dan jaringan sementara tidak stabil, kami menjelajahi interaksi antara MEV-Boost dan konsensus, menganalisis seluk-beluk mekanisme bukti saham Ethereum, dan membuat daftar beberapa kemungkinan langkah maju.
MEV-Boost dan mengapa itu penting
MEV-Boost adalah protokol yang dirancang oleh Flashbots dan komunitas untuk mengurangi dampak negatif dari Nilai Maksimum yang Dapat Diekstrak (MEV) pada jaringan Ethereum.
Ada 3 aktor di MEV-Boost:
Relay - Auctioneers yang saling percaya, menghubungkan produsen blok dan pembuat blok
Konstruktor - entitas kompleks yang membangun blok untuk memaksimalkan MEV untuk diri mereka sendiri dan pembuat blok
Blokir produsen - verifikator bukti saham Ethereum
Urutan perkiraan peristiwa untuk setiap blok adalah:
Builder membuat blok dengan menerima transaksi dari pengguna, pencari, atau aliran pesanan (pribadi atau publik) lainnya
Pembangun mengirimkan blok ke relai
Relai memverifikasi validitas blok dan menghitung jumlah yang dibayarkan ke produsen blok
Relayer mengirimkan judul kosong dan nilai pembayaran ke produsen blok dari slot saat ini
Produsen Blok mengevaluasi semua tawaran yang telah mereka terima dan menandatangani tajuk kosong terkait dengan pembayaran tertinggi
Produser blok mengirimkan tajuk yang ditandatangani ini kembali ke relai
Relai menerbitkan blok menggunakan node beacon asli mereka dan mengembalikannya ke pemberi blok. Hadiah didistribusikan ke pembangun dan pengusul melalui transaksi dalam blok dan hadiah blok.
Relai adalah pihak ketiga tepercaya yang memfasilitasi pertukaran ruang blok yang adil oleh produsen blok dan pemesanan transaksi oleh pembangun untuk ekstraksi MEV. Relay melindungi pembangun dengan melindungi pembangun dari pencurian MEV, mencegah produsen blok menyalin transaksi pembangun untuk mengambil MEV tanpa mendistribusikannya ke pencari/pemborong yang menemukannya. Relai melindungi produsen blok dengan mengonfirmasi validitas blok mereka, memproses ratusan blok per slot atas nama mereka, dan memastikan keakuratan pembayaran produsen blok.
MEV-Boost adalah infrastruktur protokol utama karena memungkinkan semua produsen blok mengakses MEV secara demokratis tanpa memerlukan hubungan kepercayaan dengan pembangun atau pencari, yang berkontribusi pada desentralisasi Ethereum jangka panjang.
Aturan pemilihan fork Ethereum dan MEV-Boost
Sebelum membahas serangan dan respons, mari kita lihat mekanisme proof-of-stake Ethereum dan aturan pemilihan fork terkait. Aturan pilihan garpu memungkinkan jaringan untuk mencapai konsensus pada kepala rantai, seperti yang didefinisikan dalam artikel "reorganisasi pasca-merger Ethereum":
"Aturan pilihan garpu adalah fungsi yang dievaluasi oleh klien, yang mengambil sebagai input blok yang terlihat dan informasi lainnya, dan mengeluarkan "rantai kanonik" ke klien. Aturan pilihan garpu penting karena mungkin ada beberapa rantai yang valid untuk dipilih (misalnya, jika dua blok yang bersaing dengan blok induk yang sama diterbitkan pada waktu yang sama). "
Aturan pemilihan garpu juga bergantung pada waktu, yang berdampak signifikan pada pembuatan blok.
siklus slot dan sub-slot
Dalam mekanisme proof-of-stake Ethereum, waktu dibagi menjadi beberapa slot setiap 12 detik. Algoritme proof-of-stake secara acak memberikan lisensi kepada validator untuk mengusulkan blok di dalam slot itu; validator ini disebut produsen blok. Dalam slot yang sama, validator lain diberi tugas memvalidasi (voting) untuk kepala rantai yang menerapkan aturan fork-choice sesuai dengan pandangan lokal mereka. Slot 12 detik ini dibagi menjadi tiga fase, masing-masing berbiaya 4 detik.
Peristiwa yang terjadi pada slot adalah sebagai berikut, dimana t=0 menunjukkan awal dari slot.
Selama slot, momen paling kritis adalah batas waktu otentikasi pada t=4. Jika validator pengesahan tidak melihat blok pada batas waktu pengesahan, mereka akan memilih kepala rantai yang diterima sebelumnya (menurut aturan pilihan garpu). Semakin awal sebuah blok diusulkan, semakin banyak waktu yang dimilikinya untuk menyebar dan dengan demikian mengumpulkan lebih banyak persetujuan (karena lebih banyak validator yang melihatnya sebelum batas waktu persetujuan).
Dari perspektif kesehatan jaringan, waktu optimal untuk pelepasan blok adalah t=0 (menurut spesifikasi). Namun, karena nilai blok meningkat secara monoton dari waktu ke waktu, produsen blok memiliki insentif untuk menunda pelepasan blok mereka sehingga lebih banyak MEV dapat terakumulasi. Lihat Permainan pengaturan waktu di Proof-of-Stake dan diskusi ini untuk detailnya.
Sebelumnya, produsen blok dapat menerbitkan blok setelah batas waktu sertifikasi (bahkan mendekati akhir slot), selama validator berikutnya mengamati blok tersebut sebelum membuat blok untuk slot berikutnya. Ini karena blok anak mewarisi bobot blok induk, dan aturan pemilihan garpu berakhir di simpul daun. Oleh karena itu, menunda rilis blok tidak memiliki efek samping. Untuk membantu mengubah perilaku rasional (menunda rilis blok) menjadi perilaku jujur (menerbitkan tepat waktu), sebuah "reorg jujur" diterapkan.
Mekanisme Hadiah Blok Produser dan Reorganisasi Jujur
Dua konsep baru diperkenalkan ke klien konsensus yang berdampak penting pada tenggat waktu otentikasi.
Mekanisme Hadiah Produsen Blok - Bertujuan untuk meminimalkan serangan penyeimbangan ulang dengan memberikan "hadiah" pilihan garpu kepada produsen blok yang setara dengan 40% dari bobot autentikasi penuh. Yang penting, hadiah ini hanya berlaku untuk seluruh slot.
Reorganisasi yang jujur - manfaatkan akselerasi produsen blok, memungkinkan produsen blok yang jujur untuk memaksa reorganisasi blok dengan bobot autentikasi di bawah 20%. Ini sudah diterapkan di Lighthouse dan Prysm (dimulai dengan v4.0 - rilis Capella). Perubahan ini bersifat opsional karena merupakan keputusan yang dibuat oleh produsen blok dan tidak memengaruhi perilaku validator yang mengautentikasi. Jadi kami tidak menerapkannya ke semua klien pada saat yang sama, juga tidak terikat pada hard fork tertentu.
Perlu dicatat bahwa reorganisasi yang jujur dihindari dalam beberapa kasus khusus:
Selama blok batas zaman
Jika rantai belum selesai
Jika kepala rantai bukan kepala slot sebelum reorganisasi
Kasus 3 memastikan bahwa reorg yang jujur hanya menghapus satu blok dari rantai, yang bertindak sebagai pemutus arus, memungkinkan rantai untuk terus memproduksi blok selama periode latensi jaringan yang ekstrim. Hal ini juga mencerminkan bahwa pengusul kurang percaya pada persepsi jaringan, karena mereka tidak dapat memastikan apakah blok yang ditingkatkan yang diusulkan akan dianggap sebagai norma.
Gambar di bawah ini menunjukkan bagaimana perilaku jujur dapat diubah untuk menerapkan strategi restrukturisasi.
Dalam hal ini, misalkan b1 mewakili blok yang terlambat. Karena penundaan, b1 hanya memiliki 19% dari bobot pembuktian slot ke-n. Sisa 81% dari bobot bukti ditugaskan ke induk blok HEAD karena banyak pembuktian tidak melihat b1 sebelum batas waktu pembuktian.
Jika tidak ada reorganisasi yang jujur, pengusul slot n+1 akan menganggap b1 sebagai kepala rantai dan membangun sub-blok b2. Pengusul tidak melakukan upaya untuk menata ulang b1, padahal bobot pembuktiannya hanya 19%. Pada slot n+1, b2 memiliki peningkatan pengusul, dengan asumsi disampaikan tepat waktu, b2 akan menjadi norma dengan mengumpulkan mayoritas bukti untuk slot tersebut.
Dengan Reorganisasi Jujur, segalanya menjadi sangat berbeda. Sekarang, pengusul slot n+1 melihat bahwa 19% bobot bukti b1 berada di bawah ambang batas reorganisasi, jadi mereka membuat blok dengan HEAD sebagai induk dan memaksa b1 untuk mengatur ulang. Saat kita mencapai batas waktu pembuktian untuk slot n+1, pembukti yang jujur akan membandingkan bobot relatif b1 (19%) dengan b2 (40% dari dorongan pengusul). Semua klien mengimplementasikan peningkatan pengusul, jadi b2 akan dianggap sebagai kepala rantai dan akan mengumpulkan bukti untuk slot n+1.
Relay dan perbaikan node Beacon untuk serangan unbundling
Dalam serangan unbundling pada 2 April, pengusul mengeksploitasi kerentanan relai untuk mengirimkan tajuk tanda tangan yang tidak valid ke relai. Selama beberapa hari berikutnya, tim relai dan pengembangan inti merilis banyak tambalan perangkat lunak untuk mengurangi risiko serangan berulang. Lima perubahan utama adalah sebagai berikut:
Perubahan Relai: Periksa basis data untuk pengusul berbahaya yang diketahui (digunakan dalam produksi hanya dengan Relai Ultrasonik dan telah dihapus). Memeriksa apakah relai telah mengirimkan blok penuh ke slot di jaringan P2P. Memperkenalkan penundaan acak yang seragam dalam rentang 0-500ms sebelum blok diterbitkan (dihapus dari semua relai).
Perubahan simpul suar (relai simpul suar saja): Validasi blok suar sebelum disiarkan. Periksa jaringan untuk konfirmasi palsu sebelum memublikasikan blokir. Kombinasi dari perubahan ini menyebabkan ketidakstabilan konsensus, sebuah masalah yang diperparah oleh fakta bahwa mayoritas validator sekarang menggunakan strategi reorganisasi jujur yang dijelaskan di atas.
KONSEKUENSI YANG TIDAK DIINGINKAN
Kelima perubahan di atas semuanya memperkenalkan penundaan di jalur panas penerbitan blok relai, yang meningkatkan kemungkinan bahwa blok relai akan disiarkan setelah batas waktu konfirmasi. Diagram di bawah ini menunjukkan urutan kelima pemeriksaan ini dan bagaimana penundaan yang terjadi menyebabkan publikasi blok melampaui batas waktu konfirmasi.
Header yang ditandatangani dalam jumlah besar dengan jeda t = 0 (mis. t = 3) biasanya tidak menimbulkan masalah hingga pemeriksaan ini diterapkan. Karena relai memiliki overhead yang sangat rendah, relai akan menerbitkan blok sebelum t = 4 tanpa menunggu batas waktu konfirmasi.
Namun, karena keterlambatan pengenalan kelima tambalan ini, relai sekarang mungkin ikut bertanggung jawab atas keterlambatan siaran. Mari kita lihat proses penerbitan blok hipotetis di bawah ini.
Relai menerima header yang ditandatangani dari produser blok pada t = 3. Pada t = 4, relai masih melakukan pengecekan, sehingga siaran akan terjadi setelah batas waktu konfirmasi. Dalam hal ini, kombinasi dari header bertanda tertunda yang dikirim oleh produser blok dan beberapa penundaan tambahan yang diperkenalkan oleh relai menyebabkan kegagalan siaran sebelum batas waktu konfirmasi. Jika tidak ada reorganisasi yang jujur, blok-blok ini kemungkinan besar akan berhasil masuk ke dalam rantai. Seperti yang ditunjukkan pada Gambar 2, pembuat blok yang jujur dari slot berikutnya tidak akan dengan sengaja mengatur ulang karena blok ini terlambat. Namun, jika tenggat waktu konfirmasi terlewati, blok tersebut akan diatur ulang oleh produsen blok berikutnya.
Akibatnya, jumlah blok bercabang meningkat secara dramatis pada hari-hari setelah serangan itu.
Data selama dua minggu dari Metrika menunjukkan bahwa dalam skenario terburuk, 13 blok (4,3%) dapat diatur ulang dalam satu jam, yaitu sekitar 5 kali lipat dari kecepatan normal. Peningkatan dramatis dalam jumlah blok bercabang menjadi jelas saat para relai meluncurkan berbagai perubahan. Berkat upaya komunitas yang hebat dari operator relai dan pengembang inti, begitu dampaknya diketahui, banyak perubahan dibatalkan dan jaringan dipulihkan ke keadaan sehat.
Sampai hari ini, perubahan yang paling berguna adalah pemeriksaan validasi dan penolakan blok simpul suar sebelum diterbitkan. Pembuat blok berbahaya tidak dapat lagi melakukan serangan dengan mengirimkan header yang tidak valid ke relai dan memastikan node suar relai tidak melihat blok yang ditolak sebelum menerbitkannya. Meskipun demikian, relai masih menghadapi denial-of-attack yang lebih umum yang diajukan di MEV-Boost dan ePBS.
Tindakan Selanjutnya
Dalam posting ini, kami menyoroti cara kerja MEV-Boost dan betapa pentingnya konsensus Ethereum. Kami juga memberikan analisis terperinci dari beberapa aspek yang kurang dikenal dari aturan pilihan garpu Ethereum terkait waktu. Dengan menggunakan serangan "unbundling" dan respons pengembang sebagai studi kasus, kami menyoroti potensi kerentanan aspek-aspek yang bergantung pada waktu dari aturan pilihan fork dan dampaknya terhadap stabilitas jaringan.
Dengan mengingat hal ini, komunitas riset harus menilai berapa jumlah reorganisasi yang "dapat diterima", dengan mempertimbangkan paparan serangan penolakan yang lebih umum, untuk menentukan apakah mitigasi harus diterapkan.
Selain itu, beberapa arah masa depan saat ini sedang dieksplorasi secara aktif:
Terapkan mekanisme headlock untuk melindungi MEV-boost dari serangan kesalahan kesetaraan. Ini juga akan memerlukan perubahan pada perangkat lunak klien konsensus dan kemungkinan perubahan spesifikasi untuk memperpanjang batas waktu pengiriman bukti.
Meningkatkan jumlah dan distribusi program bug bounty untuk software MEV-Boost.
Perluas perangkat lunak simulasi untuk mengeksplorasi bagaimana pengaturan waktu sub-slot memengaruhi stabilitas jaringan, yang dapat digunakan untuk mengevaluasi cara menyesuaikan tenggat waktu pengiriman bukti untuk mengurangi reorganisasi.
Optimalkan jalur pelepasan blok pada relai untuk mengurangi penundaan yang tidak perlu - ini sudah dieksplorasi.
Mengakui MEV-boost sebagai fitur protokol inti dan memasukkannya ke dalam klien konsensus, yaitu "diabadikan-PBS (ePBS)". ePBS dua slot rentan terhadap serangan yang nyata, jadi menerapkan "mekanisme headlock" masih menjadi pilihan.
Dengan menambahkan lebih banyak pengujian sarang dan/atau spesifikasi seputar masalah seputar latensi dan tenggat waktu sertifikasi.
Dorong keragaman klien relai dengan membangun implementasi tambahan dari spesifikasi relai.
Pertimbangkan untuk menyesuaikan penalti untuk serangan yang jelas, tetapi perlu diingat bahwa bahkan penalti 32 ETH penuh pun tidak dapat mencegah perilaku jahat saat peluang MEV ekstrem ada.
Tinjau kembali waktu sub-slot dan pertimbangkan untuk menyesuaikan fase propagasi blok (misalnya, menyesuaikan tenggat waktu sertifikasi dari t=4 menjadi t=6).
Secara keseluruhan, kami sangat senang dengan kebangkitan MEV dan ekosistem mev-boost. Melalui pemisahan serangan dan mitigasi, kami telah belajar tentang hubungan kritis antara latensi, peningkatan MEV, dan mekanisme konsensus; kami berharap protokol akan terus diperkuat untuk menangani hal ini.