Analisis Rollup dari perspektif Celestia: meninjau resistensi dan aktivitas 6 varian

Penulis: NashQ, peneliti di Celestia

原文标题：Mendefinisikan Ulang Sequencer: Memahami Aggregator dan Header Producer

Kompilasi: Faust, Geek Web3

Catatan Penerjemah: Untuk tujuan membuat model Rollup lebih mudah dipahami dan dianalisis, peneliti Celestia NashQ** membagi sequencer Rollup (Sequencer) menjadi dua entitas logis—aggregator dan generator Header. Pada saat yang sama, ia membagi proses pemesanan transaksi menjadi tiga langkah logis: inklusi, pemesanan, dan eksekusi. **

Di bawah panduan pemikiran analitis ini, enam varian penting Rollup berdaulat menjadi lebih jelas dan mudah dipahami. **NashQ membahas secara rinci resistensi sensor dan keaktifan varian Rollup yang berbeda, dan juga membahas konfigurasi minimum node dari setiap varian Rollup dalam status yang diminimalkan kepercayaan (yaitu, untuk mencapai status Tanpa Kepercayaan, apa yang harus dijalankan oleh pengguna Rollup setidaknya jenis simpul). **

Meskipun artikel ini menganalisis Rollup dari perspektif Celestia, yang berbeda dari cara komunitas Ethereum menganalisis model Rollup, mengingat banyak interkoneksi antara Rollup Ethereum dan Rollup berdaulat Celestia, serta pengaruh yang semakin berkembang, penting untuk Untuk Penggemar Ethereum, artikel ini juga sangat layak dibaca.

Apa itu Rollup?

Rollup adalah blockchain yang menerbitkan "data transaksi" ke blockchain lain dan mewarisi konsensus dan ketersediaan datanya.

Mengapa saya sengaja menggunakan kata "data transaksi" dan bukannya "memblokir"? Ini melibatkan perbedaan antara blok rollup dan data rollup, dengan rollup paling ringkas yang hanya membutuhkan data rollup seperti varian pertama di bawah.

Blok Rollup adalah struktur data yang mewakili buku besar blockchain pada ketinggian blok tertentu. Blok rollup terdiri dari data rollup dan header rollup. Diantaranya, data Rollup dapat berupa sekumpulan transaksi, atau menyatakan perubahan antara sekumpulan transaksi.

Varian 1: Rollup Pesimistis / Rollup Berbasis

Cara termudah untuk membuat Rollup adalah membiarkan pengguna menerbitkan transaksi ke blockchain lain, yang akan kita sebut sebagai lapisan konsensus dan ketersediaan data (Lapisan DA), dan saya hanya akan menyebutnya lapisan DA di bawah ini (Catatan Penerjemah: Mirip dengan Layer 1, yang sering dikatakan di komunitas Ethereum).

Dalam varian Rollup pertama yang akan saya perkenalkan, node jaringan Rollup harus mengeksekusi ulang transaksi Rollup yang terdapat di lapisan DA untuk memeriksa status akhir buku besar. Ini adalah Rollup pesimistis!

Pessimistic Rollup adalah Rollup yang hanya mendukung node penuh, dan node penuh ini perlu mengeksekusi ulang semua transaksi yang terdapat dalam buku besar Rollup untuk memeriksa validitasnya.

Namun dalam hal ini, siapa yang bertindak sebagai Sequencer of the Rollup? Faktanya, kecuali untuk node penuh Rollup, tidak ada entitas yang pernah mengeksekusi transaksi yang terdapat dalam buku besar Rollup. Secara umum, sequencer mengumpulkan data transaksi dan menghasilkan header Rollup. Tapi Rollup pesimis yang disebutkan di atas tidak memiliki header Rollup!

Untuk kenyamanan diskusi, kita dapat membagi sequencer menjadi dua entitas logis: Aggregator Aggregator dan Header Generator. Untuk menghasilkan Rollup Header, Anda harus terlebih dahulu menjalankan transaksi, menyelesaikan transisi status, lalu menghitung Header yang sesuai. Namun untuk agregator, tidak perlu menyelesaikan transisi status untuk melanjutkan langkah agregasi.

Sorting Sequencing adalah proses "agregasi + pembuatan Rollup Header".

Agregasi adalah langkah pengelompokan data transaksi menjadi satu batch. Sebuah batch umumnya berisi banyak transaksi (Catatan Penerjemah: Batch adalah bagian dari data di blok Rollup selain Header).

Langkah pembuatan header adalah proses pembuatan Rollup Header. Rollup Header adalah metadata tentang blok Rollup, setidaknya termasuk komitmen data transaksi di blok tersebut (Catatan Penerjemah: Komitmen yang disebutkan di sini mengacu pada komitmen terhadap kebenaran hasil pemrosesan transaksi).

Melalui perspektif di atas, terlihat siapa yang bertanggung jawab atas setiap bagian dari Rollup. Pertama lihat bagian agregator Aggregator. Rollup pesimis yang disebutkan di atas tidak memiliki proses pembuatan Header, dan pengguna menerbitkan transaksi langsung ke lapisan DA, yang berarti bahwa jaringan lapisan DA pada dasarnya bertindak sebagai agregator.

Oleh karena itu, rollup pesimis adalah varian Rollup yang mendelegasikan langkah agregasi ke lapisan DA, yang tidak memiliki sequencer Sequencer. Terkadang rollup jenis ini disebut "rollup berbasis".

Based Rollup memiliki ketahanan sensor dan aktivitas yang sama dengan lapisan DA (aktivitas mengukur kecepatan umpan balik sistem terhadap permintaan pengguna). Jika pengguna tipe Rollup ini ingin mencapai status kepercayaan minimal (paling dekat dengan Trustless), mereka harus menjalankan setidaknya satu light node dari jaringan lapisan DA dan node penuh dari jaringan Rollup.

Varian 2: Agregasi pesimis menggunakan agregator bersama

Mari kita bahas agregasi pesimis menggunakan agregator bersama. Ide ini disarankan oleh Evan Forbes dalam posting forumnya tentang desain sequencer bersama. Asumsi utamanya adalah bahwa sequencer bersama adalah satu-satunya cara formal untuk mengurutkan transaksi. Evan menjelaskan manfaat sequencer bersama seperti ini:**

"Untuk mencapai pengalaman pengguna yang setara dengan Web2, ** sequencer bersama dapat memberikan Soft Commitment generasi cepat (bukan jaminan yang sangat andal). Soft Commitment ini memberikan beberapa jaminan tentang pesanan transaksi akhir (yaitu, pesanan transaksi komitmen tidak akan ubah), dan langkah memperbarui status buku besar Rollup dapat dilakukan terlebih dahulu (namun Finalisasi belum selesai).**

Setelah data blok Rollup dikonfirmasi dan dirilis ke lapisan dasar Lapisan Dasar (di sini harus merujuk ke lapisan DA), pembaruan status buku besar Rollup diselesaikan dan diselesaikan. "

Varian Rollup yang disebutkan di atas masih termasuk dalam kategori Rollup pesimis, karena hanya terdapat node penuh pada sistem Rollup jenis ini dan tidak ada node ringan. Setiap node Rollup harus menjalankan semua transaksi untuk memastikan validitas pembaruan status buku besar. Karena jenis Rollup ini tidak memiliki light node, maka tidak memerlukan Rollup Header, juga tidak memerlukan Header generator. (Catatan Penerjemah: Secara umum, light node dari blockchain tidak perlu menyinkronkan blok lengkap, hanya menerima header blok)

Karena tidak ada langkah pembuatan Header Rollup, sequencer bersama Rollup yang disebutkan di atas tidak perlu menjalankan transaksi untuk pembaruan status (prasyarat untuk membuat Header), tetapi hanya menyertakan proses agregasi data transaksi. Jadi saya lebih suka menyebutnya agregator bersama agregator bersama.

Dalam varian ini, pengguna Rollup setidaknya harus menjalankan light node lapisan DA + light node dari jaringan agregator bersama + Rollup full node dalam status yang diminimalkan kepercayaan.

Pada titik ini, Anda perlu memverifikasi header agregator yang dipublikasikan (bukan Rollup Header) melalui node ringan dari jaringan agregator bersama. Seperti disebutkan di atas, agregator bersama melakukan pekerjaan menyortir transaksi. Ini berisi komitmen kriptografis di header agregator yang diterbitkan, sesuai dengan Batch yang dirilis pada lapisan DA.

Dengan cara ini, operator node Rollup dapat mengonfirmasi bahwa batch Batch yang diterima dari lapisan DA dibuat oleh agregator bersama dan bukan oleh orang lain.

• Inklusi adalah proses memasukkan transaksi ke dalam blockchain.
• Sorting Ordering mengacu pada proses mengatur transaksi di blockchain dalam urutan tertentu.
• Eksekusi mengacu pada proses pemrosesan transaksi di blockchain dan menyelesaikan pembaruan status.

Karena agregator bersama menangani penyertaan dan penyortiran, penolakan sensor Rollup bergantung padanya.

Jika diasumsikan bahwa L_ss adalah aktivitas agregator bersama dan L_da adalah aktivitas DA-Layer, maka aktivitas model Rollup adalah L = L_da && L_ss. Dengan kata lain, jika salah satu dari dua bagian mengalami kegagalan liveness, Rollup juga mengalami kegagalan liveness.

Untuk kesederhanaan, saya akan melihat keaktifan sebagai nilai bool. Jika agregator bersama gagal, Rollup tidak dapat terus beroperasi. Jika jaringan lapisan DA gagal, agregator bersama dapat terus menyediakan Soft Commitment untuk blok Rollup. Namun saat ini, atribut Rollup akan bergantung sepenuhnya pada jaringan agregator bersama, dan atribut yang terakhir seringkali jauh lebih rendah daripada lapisan DA asli.

Mari kita lanjutkan menjelajahi resistensi sensor dari skema Rollup di atas:

Dalam skema ini, lapisan DA tidak dapat meninjau beberapa transaksi tertentu (Catatan Penerjemah: Tinjauan transaksi seringkali dapat menolak untuk mengizinkan transaksi tertentu diunggah ke rantai), itu hanya dapat dimulai untuk seluruh kumpulan transaksi yang dikirimkan oleh agregator bersama Tinjauan transaksi (menolak untuk mengizinkan Batch disertakan dalam lapisan DA).

Namun, menurut alur kerja Rollup, ketika agregator bersama mengirimkan batch transaksi ke lapisan DA, itu telah menyelesaikan penyortiran transaksi, dan urutan antara batch yang berbeda juga telah ditentukan. Oleh karena itu, tinjauan transaksi semacam ini pada lapisan DA tidak memiliki efek lain kecuali menunda konfirmasi akhir buku besar Rollup.

Singkatnya, saya percaya bahwa titik resistensi sensor adalah untuk memastikan bahwa tidak ada satu entitas pun yang dapat mengontrol atau memanipulasi aliran informasi di dalam sistem, sementara liveness melibatkan pemeliharaan fungsionalitas dan ketersediaan sistem, bahkan dengan adanya pemadaman jaringan dan perilaku konfrontatif. Meskipun ini bertentangan dengan definisi akademik arus utama saat ini, saya akan tetap menggunakan definisi konsep yang telah saya artikulasikan.

Varian 3: Rollup Pesimis berdasarkan Rollup Berbasis dan Agregator Bersama

Meskipun agregator bersama membawa manfaat bagi pengguna dan komunitas, kita harus menghindari ketergantungan yang berlebihan padanya dan mengizinkan pengguna untuk menarik diri dari agregator bersama ke lapisan DA. Kami dapat menggabungkan dua varian Rollup yang diperkenalkan sebelumnya, memungkinkan pengguna mengirimkan transaksi langsung ke lapisan DA saat menggunakan agregator bersama. **

Kami berasumsi bahwa urutan transaksi Rollup akhir bergantung pada urutan transaksi yang dikirimkan oleh agregator bersama, dan transaksi Rollup yang dikirimkan langsung oleh pengguna di blok lapisan DA. Kami menyebutnya aturan pemilihan garpu Rollup ini.

Agregasi dibagi menjadi dua langkah di sini. Pertama, agregator bersama berperan, menggabungkan beberapa transaksi. Kemudian, lapisan DA dapat menggabungkan Batch yang dikirimkan oleh agregator bersama dan transaksi yang dikirimkan langsung oleh pengguna.

** Analisis resistensi sensor sedikit lebih rumit pada saat ini. **Node jaringan lapisan DA dapat meninjau Batch yang dikirimkan oleh agregator bersama sebelum blok lapisan DA berikutnya diproduksi. Setelah mengetahui data transaksi dalam batch, node lapisan DA dapat mengekstraksi nilai MEV. Akun di jaringan memulai a transaksi yang berjalan di depan dan memasukkannya ke dalam blok lapisan DA terlebih dahulu, lalu menyertakan kumpulan yang dikirimkan oleh agregator bersama Rollup.

Jelas, finalitas pesanan transaksi yang dijamin oleh komitmen lunak varian Rollup tipe ketiga lebih rapuh daripada varian Rollup tipe kedua yang disebutkan di atas. Dalam hal ini, agregator bersama menyerahkan nilai MEV ke simpul lapisan DA. Dalam hal ini, saya merekomendasikan pembaca untuk menonton kuliah penelitian tentang mengeksploitasi MEV tersensor yang menguntungkan.

Saat ini, beberapa skema desain telah muncul untuk mengurangi kemampuan node jaringan lapisan DA untuk mengeksekusi transaksi MEV tersebut, seperti fungsi "periode jendela reorganisasi", yang akan menunda eksekusi transaksi yang diserahkan langsung ke lapisan DA oleh pengguna jaringan Rollup . Sovereign Labs menjelaskan hal ini secara rinci dalam proposal desain mereka yang disebut Pengurutan Berbasis dengan Konfirmasi Lembut, yang memperkenalkan konsep "pengurutan pilihan".

Karena masalah MEV bergantung pada skema agregator yang dipilih oleh Rollup, dan aturan pemilihan fork rollup, beberapa skema tidak akan membocorkan MEV ke lapisan DA, dan beberapa skema akan membocorkan sebagian atau semua MEV ke lapisan DA, tetapi ini adalah topik lain.

Untuk liveness, skema rollup ini memiliki keunggulan dibandingkan skema yang hanya mengizinkan agregator bersama untuk mengirimkan transaksi ke lapisan DA. Jika terjadi kegagalan liveness pada agregator bersama, pengguna masih dapat mengirimkan transaksi ke lapisan DA.

Terakhir, mari kita bicara tentang konfigurasi minimum pengguna Rollup di bawah minimalisasi kepercayaan:

Setidaknya jalankan DA layer light node + shared aggregator light node + Rollup full node.

Pada titik ini, masih diperlukan untuk memverifikasi header agregator yang dikeluarkan oleh agregator bersama, sehingga simpul penuh rollup dapat membedakan kumpulan transaksi sesuai dengan aturan pemilihan fork.

Varian 4: Rollup Berbasis Optimis dan Generator Header Terpusat

Mari kita bahas varian yang disebut Based Optimistic Rollup dan generator header terpusat. **Solusi ini menggunakan lapisan DA untuk mengagregasi transaksi Rollup, tetapi memperkenalkan generator Header terpusat untuk menghasilkan Rollup Header guna mengaktifkan node ringan Rollup. **

Node ringan Rollup dapat secara tidak langsung memeriksa validitas transaksi Rollup melalui satu putaran bukti penipuan. Light node akan optimis tentang generator Rollup Header, dan akan membuat konfirmasi akhir setelah periode jendela bukti penipuan berakhir. Kemungkinan lain adalah menerima bukti penipuan dari node penuh yang jujur bahwa generator header mengirimkan data yang salah.

Saya tidak akan membahas detail tentang cara kerja bukti penipuan satu putaran di sini, karena hal itu berada di luar cakupan artikel ini. Keuntungan dari satu putaran bukti penipuan adalah dapat mempersingkat periode jendela bukti penipuan dari 7 hari sampai batas tertentu Nilai spesifiknya belum ditentukan, tetapi urutan besarnya lebih kecil daripada rollup optimis tradisional. Light node dapat memperoleh bukti penipuan melalui jaringan P2P yang terdiri dari node penuh Rollup tanpa menunggu proses sengketa selanjutnya, karena semua kriteria sudah lengkap tersedia dalam satu bukti penipuan.

Model Rollup di atas menggunakan lapisan DA sebagai agregator dan mewarisi ketahanan sensornya. Lapisan DA pada titik ini bertanggung jawab untuk menampung dan memesan transaksi. Generator Header terpusat akan membaca urutan transaksi Rollup dari lapisan DA dan membuat Rollup Header yang sesuai. Generator Header akan menerbitkan Header dan Stateroot ke lapisan DA. Stateroots ini diperlukan saat membuat bukti penipuan. **Singkatnya, agregator bertanggung jawab untuk memasukkan dan menyortir transaksi, dan generator Header akan mengeksekusi transaksi untuk memperbarui status untuk mendapatkan Stateroot. **

Asumsikan bahwa lapisan DA (yang juga bertindak sebagai agregator untuk Rollup pada saat ini) cukup terdesentralisasi dan tahan sensor. Selain itu, generator header tidak dapat mengubah urutan transaksi Rollup yang diterbitkan oleh agregator. Sekarang, jika generator header terdesentralisasi, satu-satunya keuntungan adalah liveness yang lebih baik, tetapi properti Rollup lainnya sama dengan varian pertama Based Rollup.

Jika header generator gagal liveness, rollup juga akan gagal liveness. Node ringan tidak akan bisa mengikuti progres buku besar Rollup, tetapi node penuh bisa. Pada titik ini, Rollup yang dijelaskan dalam Varian 4 berubah menjadi Rollup Berdasarkan yang dijelaskan dalam Varian 1. Rupanya, konfigurasi minimum yang diminimalkan kepercayaan yang dijelaskan oleh Varian 4 adalah:

** Node cahaya lapisan DA + Node cahaya Rollup. **

Varian 5: Berbasis ZK-Rollup dan Decentralized Prover Market

Kita telah membahas Pessimistic Rollup (Based Rollup) dan Optimistic Rollup, sekarang saatnya untuk mempertimbangkan ZK-Rollup. Baru-baru ini Toghrul berpidato tentang pemisahan agregator (Sequencer) dan generator Header (Prover) (Sequencer-Prover Separation in Zero-Knowledge Rollups). Dalam model ini, lebih mudah menangani transaksi penerbitan sebagai data Rollup daripada State Diff, jadi saya akan fokus pada yang pertama. **Varian 5 adalah Prover Market terdesentralisasi berdasarkan zk-rollup. **

Sekarang, Anda seharusnya sudah terbiasa dengan cara kerja Rollup. Varian 5 mendelegasikan peran agregator ke simpul lapisan DA, yang melakukan pekerjaan termasuk dan menyortir transaksi. Saya akan mengutip dokumentasi Sovereign-Labs, yang memiliki penjelasan bagus tentang siklus transaksi dalam varian 5:

Pengguna menerbitkan blok data baru ke rantai L1 (lapisan DA). Setelah blok data ini diselesaikan pada rantai L1, itu secara logis final (tidak dapat diubah). Setelah blok rantai L1 memasuki tahap finalisasi (yaitu, mereka tidak dapat dibatalkan), node penuh Rollup akan memindai blok ini, memproses semua blok data yang terkait dengan Rollup secara berurutan, dan menghasilkan Stateroot negara root Rollup terbaru . Pada titik ini, dari perspektif simpul penuh Rollup, blok data ini telah diselesaikan.

Dalam model ini, generator Header dijalankan oleh Prover Market yang terdesentralisasi.

Proses kerja node Prover Prover (node penuh yang berjalan di ZKVM) serupa dengan node penuh Rollup normal—memindai blockchain lapisan DA dan memproses semua kumpulan transaksi Rollup secara berurutan—untuk menghasilkan Bukti tanpa pengetahuan yang sesuai dan menerbitkan pada rantai lapisan DA. (Jika sistem Rollup ingin memotivasi pembukti, yang terakhir harus mengirim bukti ZK yang dihasilkan ke rantai lapisan DA, jika tidak maka tidak mungkin untuk menentukan Prover mana yang mengirimkan bukti ZK terlebih dahulu). Setelah bukti ZK yang terkait dengan kumpulan transaksi tertentu dirilis ke rantai, kumpulan transaksi diselesaikan di mata semua node Rolup (termasuk node ringan).

Varian 5 memiliki ketahanan sensor yang sama dengan lapisan DA. Pasar Prover yang terdesentralisasi tidak dapat meninjau transaksi Rollup, karena lapisan DA telah menentukan urutan transaksi standar, hanya untuk mendapatkan aktivitas yang lebih baik dan menciptakan pasar insentif, maka generator Header (di sini mengacu pada Prover) adalah perubahan yang terdesentralisasi.

Aktivitas di sini adalah L = L_da && L_pm (Aktivitas Prover). Jika insentif Prover Market tidak konsisten, atau ada kegagalan aktif, rollup light node tidak akan dapat menyinkronkan progres blockchain, tetapi rollup full node bisa. Untuk full node, ini hanyalah fallback ke Batal Berbasis/Batal Pesimis. Konfigurasi minimum untuk minimalisasi kepercayaan di sini sama dengan kasus Rollup optimis, yaitu

Node cahaya lapisan DA + Node cahaya Rollup.

Varian 6: Rollup Berbasis Hybrid + Generator Header Optimis Terpusat + Pembukti Terdesentralisasi

Kami masih membiarkan simpul lapisan DA bertindak sebagai agregator Rollup dan mendelegasikan pekerjaan menyertakan dan memesan transaksi kepada mereka.

Seperti yang dapat Anda lihat dari gambar di bawah ini, baik ZK Rollup dan Optimistic Rollup menggunakan kumpulan transaksi terurut yang sama pada lapisan DA sebagai sumber buku besar Rollup. Inilah alasan mengapa kita dapat menggunakan kedua sistem bukti pada saat yang sama: kumpulan transaksi yang dipesan pada lapisan DA tidak terpengaruh oleh sistem bukti.

Mari kita bicara tentang finalitas terlebih dahulu. Dari perspektif simpul penuh Rollup, saat blok lapisan DA diselesaikan, kumpulan transaksi Rollup yang terkandung di dalamnya diselesaikan dan tidak dapat diubah. Tapi kami lebih peduli tentang finalitas dari perspektif node cahaya. Asumsikan bahwa generator Header terpusat menggadaikan beberapa aset, menandatangani Rollup Header yang dihasilkan, dan mengirimkan Stateroot yang dihitung ke lapisan DA.

Seperti varian 4 sebelumnya, light node akan secara optimis mempercayai generator header, percaya bahwa header yang dikeluarkannya benar, dan menunggu bukti penipuan dari jaringan full node. Jika periode jendela bukti penipuan telah berakhir dan jaringan simpul penuh belum mengeluarkan bukti penipuan, dari perspektif simpul ringan Rollup, blok Rollup diselesaikan.

Poin utamanya adalah jika kita bisa mendapatkan bukti ZK, kita tidak perlu menunggu jendela bukti penipuan berakhir. Selain satu putaran bukti penipuan, kami dapat mengganti bukti penipuan dengan bukti ZK dan membuang header palsu yang dihasilkan oleh generator header berbahaya!

Saat light node menerima bukti ZK untuk sekumpulan transaksi Rollup, kumpulan tersebut diselesaikan.

Sekarang kami memiliki Komitmen Lunak yang cepat dan penyelesaian yang cepat.

Varian 6 masih memiliki ketahanan sensor yang sama dengan lapisan DA karena didasarkan pada lapisan DA. Untuk keaktifan, kami akan memiliki L = L_da && (L_op || L_pm), yang berarti kami menambahkan jaminan keaktifan. Jika generator Header terpusat atau Pasar Prover terdesentralisasi mengalami kegagalan liveness, kita dapat beralih ke yang lain dari keduanya.

Dalam varian ini, konfigurasi minimum untuk minimalisasi kepercayaan pengguna adalah:

**Satu light node lapisan DA + satu light node Rollup. **

Ringkasan:

1. Kami membagi peran kunci Rollup - Sequencer menjadi dua komponen logis:

Agregator dan generator Header.

2. Kami membagi pekerjaan Sequencer menjadi tiga proses logis: penahanan, penyortiran, dan eksekusi.

3. Rollup pesimistis dan rollup berbasis adalah satu hal.

4. Sesuai dengan kebutuhan Anda, Anda dapat memilih solusi agregator dan generator header yang berbeda.

5. Setiap varian Rollup yang diperkenalkan di postingan ini mengikuti pola desain yang sama:

Akhirnya, saya punya beberapa pemikiran. Silakan berpikir tentang:

• Bagaimana Rollup klasik (mengacu pada Ethereum Rollup) diklasifikasikan ke dalam varian di atas?
• Di semua varian, kami hanya membiarkan agregator bertanggung jawab atas penyertaan + penyortiran, dan generator Header untuk menjalankan transaksi. Bagaimana jika agregator hanya bertanggung jawab untuk menyertakan transaksi, dan generator header bertanggung jawab untuk memesan dan menjalankan transaksi? Mempertimbangkan pengenalan langkah lelang on-chain, bisakah kita benar-benar memisahkan ketiga langkah ini?
• Apa itu Shared Header Producer/Header Producer Market?
• Siapa yang menangkap nilai MEV? Bisakah pengguna mendapatkannya kembali?