Peneliti Celestia: Interpretasi 4 Skema Rollup Baru

Penulis Asli: NashQ, Celestia

Kompilasi: Tautan, "Geek web3"

Pendahuluan: Artikel ini terdiri dari pidato peneliti Celestia NashQ yang tersebar tentang analisis model Rollup, termasuk 4 varian Rollup baru. Sebelumnya, dalam artikel "Analisis Rollup dari Perspektif Celestia: Ketahanan Sensor dan Aktivitas 6 Variasi", dia mencantumkan 6 model Rollup yang berbeda, dan artikel ini adalah 4 kategori barunya yang diabstraksikan berdasarkan model Rollup ini.

Sebelumnya, NashQ membagi Sequencer menjadi dua modul: agregator + Produser Header. Dimulai dari siklus hidup instruksi transaksi, menjelaskan prinsip operasi Rollup berdaulat Celestia, membahas anti-sensor dan aktivitas varian Rollup yang berbeda, dan pengalaman pengguna .Konfigurasi minimum di bawah premis meminimalkan kepercayaan (yaitu, untuk mencapai Trustless, jenis node mana yang harus dijalankan pengguna Rollup setidaknya).

Varian 7: Rollup Berbasis+Beberapa Produser Header+"Protokol MEV tertinggi"

Dalam varian Rollup ini, pengguna jaringan Rollup secara langsung menerbitkan data transaksi ke blok lapisan DA, dan kemudian Produser Header bertanggung jawab atas penyortiran transaksi, dan MEV diekstrak olehnya. Jelas, proses agregasi/penyertaan transaksi Rollup Variant 7 sama dengan Based Rollup yang diperkenalkan sebelumnya, yang merupakan tanggung jawab lapisan DA (pengguna langsung mengirim transaksi ke lapisan DA), tetapi pemesanan transaksi berbeda dari Berbasis Rollup, dan node lapisan DA tidak bertanggung jawab Penyortiran adalah tanggung jawab HP (Header Producer).

Berikut asumsi bahwa ada tiga HP yang bersaing satu sama lain dan mematuhi protokol alokasi MEV bernama "Protokol MEV tertinggi". Protokol ini diusulkan oleh Skip Protocol dari ekosistem Cosmos.Tidak seperti skema Ethereum PBS, Block Builder perlu membayar "tip" tambahan kepada Validator jaringan blockchain, dan blok yang dibangun oleh Builder dengan tip terbanyak akan diadopsi oleh Validator. Pada saat yang sama, Protokol SKIP mengusulkan konsep "Sovereign MEV", yang bermaksud untuk memungkinkan semua Validator dan komunitas di jaringan rantai publik memiliki otonomi untuk mengalokasikan MEV, dan untuk memecahkan masalah yang menjadi lebih banyak Builder di Ethereum PBS. lebih terpusat karena efek flywheel (tapi ini bukan inti dari artikel ini).

Dalam varian Rollup yang diperkenalkan di artikel ini, Produsen Header yang berbeda perlu menyatakan jumlah tip di Header Batch yang dibuat sendiri, dan Header Batch yang dikeluarkan oleh HP yang membayar tip terbanyak secara otomatis diterima oleh node Rollup (melalui ledger ditulis dalam kode simpul Algoritma pemilihan garpu dilakukan secara otomatis).

Selain itu, Batch Header yang dirilis oleh HP harus sesuai dengan Batch batch transaksi lengkap pada lapisan DA.

Jika ada kesalahan pada Header yang dikeluarkan oleh HP, misalnya hasil eksekusi transaksi Stateroot salah, atau transaksi dalam batch tidak disertakan (lost transaction), maka complete node HOLLY Rollup akan broadcast Fraud Proof ke light node . Namun biasanya (optimisnya), light node dapat menerima Header yang dikeluarkan oleh HP dan percaya bahwa tidak ada masalah dengannya.

Resistensi terhadap analisis sensor: Ada 2 poin dalam Rollup ini yang dapat melakukan peninjauan transaksi. Yang pertama ada di lapisan DA, yang dapat menyensor konten transaksi dan menolak transaksi yang melibatkan pengguna tertentu. Tempat kedua masih ada di lapisan DA, yang dapat meninjau header yang dikirimkan oleh HP dan menolak untuk menyertakan header tertentu, sehingga dapat berkonspirasi dengan header tersebut untuk memonopoli MEV melalui serangan review.

Pada saat yang sama, HP bertanggung jawab atas pemesanan transaksi, karena adanya bukti penipuan (dapat ditargetkan pada situasi di mana HP kehilangan transaksi), HP sendiri seringkali tidak meluncurkan serangan sensor, tetapi dapat menyuap node. dari lapisan DA untuk melakukannya (atau menjalankan beberapa lapisan DA dengan sendirinya) node). Solusi untuk ini adalah memperpanjang periode jendela untuk penyelesaian urutan transaksi Rollup, sehingga Header yang ditolak oleh node lapisan DA berbahaya dapat dimasukkan ke dalam rantai oleh node lapisan DA yang jujur sebelum akhir periode jendela, sehingga meningkatkan ulasan simpul lapisan DA Kesulitan serangan.

**Aktivitas:**L = L_da && ( L_hp1 || L_hp2 || L_hp3 )

Jika lapisan DA mengalami kegagalan liveness, Rollup juga akan mengalami kegagalan liveness. Berdasarkan hal ini, Rollup akan gagal hidup hanya jika semua HP gagal hidup.

Varian 8: ZK Rollup dari Shared Aggregator + Decentralized Prover

Varian 8 menggunakan agregator bersama Shared Aggregator (SA) untuk penyertaan + penyortiran transaksi. SA menerbitkan Batch urutan transaksi ke lapisan DA. Setelah urutan transaksi dikirim ke lapisan DA, urutan transaksi tidak akan berubah secara teoritis.

Sebelum Batch dikirim ke lapisan DA, SA agregator bersama dapat terlebih dahulu menyiarkan Batch+ SA Header ke node penuh dan Prover, dan menyiarkan Header SA ke light node, tetapi Batch yang tidak ada di lapisan DA adalah masih tidak stabil saat ini dan dapat diblokir kapan saja.ganti.

Perlu diperhatikan bahwa header yang dikeluarkan oleh SA agregator bersama tidak sama dengan header batch yang dikeluarkan oleh HP. Header SA berisi bukti kriptografik untuk memastikan bahwa Batch yang dibaca oleh node Rollup dari lapisan DA memang dihasilkan oleh SA, bukan dipalsukan oleh orang lain.

Prover membaca Batch batch transaksi dari lapisan DA (juga dapat langsung disinkronkan ke agregator bersama), menghasilkan ZK Proof+Batch Header, dan menerbitkannya ke lapisan DA. Jelas Prover memainkan peran HP.

Untuk light node Rollup, setelah menerima ZKProof, urutan transaksi yang terdapat dalam Batch ini akhirnya dikonfirmasi. Tentu saja Prover juga dapat menyiarkan ZKP melalui jaringan Rollup p2p di bawah rantai lapisan DA, sehingga dapat diterima oleh light node lebih cepat, tetapi saat ini ZKP belum dikirim ke lapisan DA, dan tidak memiliki " finalitas".

• **Resistensi terhadap penyensoran: **Dalam varian 8, lapisan DA tidak dapat melakukan serangan penyensoran pada transaksi spesifik tertentu, tetapi hanya dapat melakukan serangan peninjauan pada seluruh kumpulan transaksi yang dikirimkan oleh agregator bersama. Pada saat yang sama, agregator bersama dapat menolak mengemas transaksi pengguna tertentu.
• **Aktivitas: **L = L_da && L_sa && L_pm. Dalam varian ini, jika ada bagian yang mengalami kegagalan liveness, Rollup akan mengalami kegagalan liveness. Jika Prover gagal, node cahaya tidak akan dapat secara efektif menyinkronkan kemajuan buku besar Rollup. Namun, karena node penuh menyinkronkan semua kumpulan urutan transaksi, itu dapat mengikuti kemajuan buku besar. Saat ini, semua node tidak akan terpengaruh, dan semua node ringan akan gagal, yang setara dengan situasi Batal Berbasis menggunakan agregator bersama yang diperkenalkan sebelumnya.
• **Konfigurasi minimum untuk minimalisasi kepercayaan: **Node lampu lapisan DA + node lampu jaringan agregator bersama + Node lampu Rollup

Varian 9: Agregator bersama + Prover terdesentralisasi + ZK-Rollup dengan beberapa DA

Varian 9 sebenarnya didasarkan pada varian 8 di atas, tetapi memiliki lebih dari satu lapisan DA, yang secara efektif dapat meningkatkan aktivitas Rollup. Di Varian 9, agregator bersama SA dapat menerbitkan Batch urutan transaksi ke lapisan DA apa pun, dan dapat memilih lapisan DA yang berbeda untuk menerbitkan data sesuai dengan kebutuhannya sendiri, sehingga dapat mengoptimalkan parameter Rollup yang relevan secara dinamis, seperti: biaya data, keamanan, keaktifan, latensi transaksi, dan finalitas.

Sesuai dengan kebutuhan pihak proyek Rollup, Rollup kecepatan termurah, teraman, paling aktif, dan penyelesaian dapat disesuaikan, dan lapisan DA dengan throughput tertinggi dapat dipilih. Secara umum, Batch dengan ketinggian blok Rollup tertentu (seperti yang ke-10.000) tidak perlu ada di lapisan DA yang berbeda pada saat yang sama, tetapi jika ada, isinya harus konsisten. Jika dua kumpulan dengan tinggi yang sama dan konten yang berbeda muncul di lapisan DA yang berbeda, itu berarti agregator bersama dengan sengaja membagi buku besar.

Di sini, kami memilih Pasar Prover terdesentralisasi yang sama dengan Varian 8, di mana Prover bertindak sebagai Prover Header dan merilis Batch Header dan ZKProof. Pada titik ini, Prover perlu bersaing melalui mekanisme pelelangan tip yang disebutkan dalam Varian 7 (diusulkan oleh Protokol SKIP).

Kecepatan penyelesaian transaksi (kecepatan konfirmasi akhir) Varian 9 dipengaruhi oleh lapisan DA dengan pembuatan blok tercepat.

Resistensi terhadap penyensoran: Agregator bersama dapat terlibat dalam serangan penyensoran, tetapi dengan lebih banyak lapisan DA opsional, kemungkinan serangan penyensoran terkait lapisan DA berkurang.

**活性：**L = ( L_da1 || L_da2) && L_sa && L_pm。

Varian 9 lebih aktif dari varian sebelumnya. Selama tidak semua jaringan lapisan DA mengalami kegagalan langsung, semuanya akan berfungsi dengan baik.

Konfigurasi minimum untuk minimalisasi kepercayaan: light node dari berbagai lapisan DA + node light jaringan agregator bersama + Rollup light node.

Jelas, semakin banyak lapisan DA yang kita adopsi, semakin banyak node ringan yang harus kita jalankan. Tetapi manfaat dari melakukannya mungkin lebih besar daripada biayanya.

Varian 10: Dua ZK-Rollup+Prover terdesentralisasi, masing-masing dengan simpul ringan pada rantai (dapat dijembatani)

Varian 10 merupakan perpanjangan dari Varian 5 untuk membuat 2 ZK-Rollup yang dapat saling menjembatani. Dibandingkan dengan Varian 5 (Based Rollup+ZKP+Decentralized Prover), Varian 10 memiliki peran relayer tambahan, yang membungkus Batch Header+ZK-Proof ke dalam sebuah transaksi. Selama transaksi ini dikirim ke light node Rollup1 yang berjalan di Rollup2, ini dapat membuktikan bahwa ketinggian Batch tertentu valid. Tentu saja, Rollup2 juga membutuhkan node ringan yang menjalankan lapisan DA.

Ini adalah prasyarat untuk menjaga kepercayaan lintas jembatan seminimal mungkin. Tetapi jika cross-chain dari Ethereum Rollup (smart contract-based SC Rollup) ke Ethereum, tidak perlu menjalankan light node lapisan DA Rollup, karena lapisan DA adalah Ethereum itu sendiri. Ini sangat berbeda dari Rollup berdaulat Celestia, yang Rollupnya saling merentang dan harus menjalankan light node dari lapisan DA pihak lain.

Ketika Relayer mengirim transaksi lintas rantai, itu akan diproses oleh Aggregator 2 dan HP2 Rollup2. Kami menambahkan keduanya ke grafik untuk memahami bagaimana node Rollup2 memproses transaksi di seluruh Rollups.

Relayer dari Rollup2 akan mendapatkan Batch Header dan ZKP dari Rollup 2 dan mengirimkannya kembali ke Rollup1. Rollup 1 juga memiliki simpul cahaya Rollup 2 dan simpul cahaya lapisan DA.

Kita bisa membuat modelnya lebih disederhanakan. Asumsikan bahwa dua Pembatalan menggunakan agregator bersama dan Produser Header yang sama, dengan kata lain, lapisan DA yang mereka gunakan tumpang tindih.

Dalam hal ini, Relayer dapat di-ban secara langsung. Karena Batch Header dan ZK Proof sudah dipublish oleh HP ke layer DA yang sama, data seperti Header dan ZKP Rollup lain bisa langsung dibaca di layer DA, dan tidak perlu lagi diteruskan ke shared aggregator melalui Penyalur.

Jelas, Rollup menggunakan lapisan DA yang sama tidak perlu bergantung pada Relayer (banyak jembatan lintas rantai bergantung pada node relai). Ini dapat memecahkan masalah keamanan jembatan rantai silang (dari sudut pandang ini, rentang silang antara SC Rollups of Ethereum lebih aman daripada rantai silang antara rantai publik yang berbeda).

Saat ini, **konfigurasi minimum untuk minimalisasi kepercayaan: **simpul cahaya lapisan DA + simpul cahaya Rollup.