Pengantar: Artikel ini disusun oleh peneliti Celestia NashQ yang tersebar tentang analisis model Rollup, termasuk 4 varian Rollup baru. Sebelumnya, dalam artikel Peneliti Celestia Menganalisis 6 Varian Rollup: Pemroses=Aggregator+Generator HeaderDia mencantumkan 6 model Rollup yang berbeda, dan artikel ini adalah abstraksi baru dari 4 jenis model Rollup berdasarkan artikel ini.

Sebelumnya, NashQ membagi sequencer Sequencer menjadi dua modul, Aggregator + Header Producer, dan memotong siklus instruksi transaksional untuk menjelaskan bagaimana Celestia Sovereign Rollup bekerja, mengeksplorasi resistensi sensor dan aktivitas dari varian Rollup yang berbeda, serta konfigurasi minimum agar pengguna menjadi minimal kepercayaan (yaitu, menjadi Tanpa Kepercayaan, jenis node minimum apa yang harus dijalankan pengguna Rollup).

Varian 7: Berbasis Rollup + Produsen Header Ganda + "MEV Protokol Tertinggi"

Dalam varian Rollup ini, pengguna jaringan Rollup mengirimkan data transaksi langsung ke blok lapisan DA, dan kemudian Header Producer bertanggung jawab atas pengurutan transaksi dan MEV diekstrak olehnya. Jelas, proses agregasi/inklusi transaksi varian Rollup 7 sama dengan yang diperkenalkan sebelumnya, yaitu Based Rollup, yang ditangani oleh lapisan DA (pengguna mengirimkan transaksi mereka langsung ke lapisan DA), tetapi pengurutan transaksi berbeda dari Based Rollup dalam hal node lapisan DA tidak bertanggung jawab atas pengurutan, yang ditangani oleh HP (Header Producer).

Mari kita asumsikan bahwa ada tiga HP yang bersaing satu sama lain dan mengikuti protokol alokasi MEV yang disebut “highest Protocol MEV”. Protokol ini diajukan oleh Skip Protocol dari ekosistem Cosmos, yang berbeda dari skema PBS Ether karena Block Builders membayar “tip” tambahan kepada Validators jaringan blockchain, dan blok yang dibangun oleh Builders yang paling banyak ditip akan diadopsi oleh Validators. Blok yang dibangun oleh Builders yang paling banyak ditip akan diadopsi oleh Validators. Pada saat yang sama, Skip Protocol mengajukan konsep “Sovereign MEV”, yang bermaksud memberikan otonomi alokasi MEV kepada semua Validators dan komunitas jaringan rantai publik, dan menyelesaikan masalah peningkatan sentralisasi builders karena efek flywheel dalam Ethernet PBS (tapi ini bukan inti dari artikel ini).

Dalam varian Rollup yang disajikan dalam makalah ini, Produsen Header yang berbeda perlu menyatakan jumlah tip di Header Batch yang mereka buat, dan Header Batch yang diposting oleh HP yang memberikan tip paling banyak secara otomatis diterima oleh node Rollup (secara otomatis melalui algoritma pemilihan fork ledger yang ditulis dalam kode node).

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

Jika ada kesalahan dalam Header yang diterbitkan oleh HP, seperti hasil eksekusi transaksi Stateroot yang tidak benar, atau tidak mengandung transaksi tertentu dalam Batch (transaksi yang hilang), node lengket Rollup jujur menyiarkan bukti kecurangan Bukti kecurangan ke node ringan. Namun, biasanya (secara optimis), node ringan dapat menerima Header yang diterbitkan oleh HP dan percaya bahwa tidak ada Masalah.

Analisis Resistensi Sensor: Ada 2 titik di Rollup ini di mana sensor transaksi mungkin terjadi. Titik pertama terdapat di lapisan DA, di mana dapat meninjau konten transaksi dan menolak inklusi transaksi pengguna tertentu. Tempat kedua masih berada di lapisan DA, di mana dapat meninjau Header yang dikirimkan oleh HP dan menolak untuk menyertakan Header tertentu, sehingga dapat bersekongkol dengan Header untuk memonopoli MEV melalui serangan sensor.

Pada saat yang sama, urutan transaksi ditangani oleh HP, dan karena adanya bukti penipuan (yang dapat digunakan melawan kasus HP menjatuhkan transaksi), HP sendiri cenderung tidak meluncurkan serangan sensorship, tetapi dapat menyogok node lapisan DA untuk melakukannya (atau menjalankan beberapa node lapisan DA sendiri). Solusi untuk hal ini adalah memperpanjang periode jendela di mana urutan transaksi Rollup difinalisasi, sehingga Header yang ditolak oleh node lapisan DA jahat dapat dimasukkan dalam rantai oleh node lapisan DA jujur tepat waktu sebelum akhir periode jendela, yang pada gilirannya meningkatkan kesulitan serangan sensorship node lapisan DA.

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

Jika layer DA memiliki active fault, maka Rollup juga akan memiliki active fault. Atas dasar ini, Rollup akan memiliki kesalahan aktif hanya jika semua HP memiliki kesalahan aktif.

Varian 8: ZK Rollup dengan Aggregator Bersama + Pembuktian Terdesentralisasi

Varian 8 menggunakan Shared Aggregator (SA) untuk inklusi + pengurutan transaksi, di mana SA menerbitkan urutan transaksi Batch ke lapisan DA, dan urutan transaksi secara teoritis tidak berubah setelah urutan transaksi dikirim ke lapisan DA.

Dan sebelum Batch dikirim ke layer DA, Shared Aggregator SA pertama-tama dapat menyiarkan Batch + SA Header ke full node dan Prover, dan SA Header ke light node, kecuali bahwa pada saat ini, Batch yang tidak ada pada layer DA masih tidak stabil, dan dapat diganti kapan saja.

Penting untuk dicatat bahwa Header yang diterbitkan oleh Aggregator Bersama SA bukanlah hal yang sama dengan Header Batch yang diterbitkan oleh HP. Header SA berisi bukti kriptografis untuk memastikan bahwa Batch yang dibaca oleh node Rollup dari lapisan DA memang dihasilkan oleh SA, dan bukan dipalsukan olehnya.

Prover membaca Batch transaksi dari lapisan DA (dan juga disinkronkan langsung ke agregator bersama), menghasilkan Bukti ZK+Header Batch, dan mempublikasikannya ke lapisan DA. Jelas Prover bertindak sebagai HP.

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

Ketahanan sensorship: pada varian 8, lapisan DA tidak dapat melakukan serangan penyensoran terhadap beberapa transaksi tertentu, tetapi hanya dapat melakukan serangan penyensoran Batch terhadap seluruh batch transaksi yang diajukan oleh aggregator bersama. Pada saat yang sama, aggregator bersama dapat menolak untuk mengemas transaksi pengguna tertentu.

Aktif: L = L_da && L_sa && L_pm. Bagian apa pun dari varian ini gagal aktif maka Rollup akan gagal aktif. Jika Prover gagal, maka node ringan tidak akan dapat menyinkronkan kemajuan ledger Rollup dengan efisien. Tetapi karena node lengkap menyinkronkan semua urutan transaksi Batch, itu dapat mengikuti kemajuan buku. Pada saat ini, node lengkap tidak terpengaruh dan semua node ringan gagal, yang setara dengan kasus yang sebelumnya dijelaskan dari Based Rollup dengan aggregator bersama.

Konfigurasi minimum untuk minimisasi kepercayaan: node ringan tingkat DA + node ringan Jaringan Aggregator Bersama + node ringan Rollup

Varian 9: Aggregator Bersama + Prover Terdesentralisasi + ZK-Rollup dengan beberapa DA

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

Berdasarkan kebutuhan proyektor Rollup, Rollup yang paling murah, aman, aktif, dan cepat dapat disesuaikan, dan lapisan DA dengan throughput tertinggi dapat dipilih. Secara umum, Batch dari tinggi blok Rollup tertentu (misalnya, yang ke-10.000) tidak harus ada pada lapisan DA yang berbeda secara bersamaan, tetapi jika ada, konten mereka harus sama. Jika dua Batch dengan tinggi yang sama dan konten yang berbeda hadir pada lapisan DA yang berbeda, itu berarti bahwa aggregator bersama dengan sengaja terlibat dalam fork ledger.

Di sini, kami memilih Pasar Prover terdesentralisasi yang sama seperti pada varian 8, di mana Prover bertindak sebagai Produsen Header dan menerbitkan Batch Header dan ZKProof. pada titik ini, Prover perlu bersaing melalui mekanisme lelang tip yang disebutkan dalam varian 7 (diproposkan oleh Protokol SKIP).

Kecepatan penyelesaian transaksi (kecepatan konfirmasi final) dari varian 9 dipengaruhi oleh lapisan DA tercepat yang digunakan di antara blok-blok.

Ketahanan sensorship: pengumpul bersama dapat terlibat dalam serangan penyensoran, tetapi jumlah lapisan DA opsional menjadi lebih besar, dan kemungkinan serangan penyensoran yang terkait dengan lapisan DA menurun.

Aktivitas: L = (L_da1 || L_da2) && L_sa && L_pm.

Variant 9 lebih aktif dibandingkan dengan varian sebelumnya. Selama tidak ada kegagalan aktivitas di semua jaringan lapisan DA, segalanya dapat berjalan dengan normal.

Konfigurasi minimum untuk minimalisasi kepercayaan: node cahaya di lapisan DA yang berbeda + node cahaya jaringan agregator bersama + node cahaya rollup.

Jelas, semakin banyak lapisan DA yang kita gunakan, semakin banyak node cahaya yang harus kita jalankan. Tetapi manfaat dari ini dapat mengesampingkan biayanya.

Varian 10: Dua ZK-Rollups + Prover Terdesentralisasi dengan simpul cahaya on-chain satu sama lain (dapat dijembatani)

Varian 10 adalah perpanjangan dari Varian 5 dengan tujuan menciptakan 2 ZK-Rollups yang dapat terhubung satu sama lain. Dibandingkan dengan Varian 5 (Berbasis Rollup+ZKP+Prover Terdesentralisasi), Varian 10 memiliki peran tambahan dari Relayer pengulang, yang membungkus Batch Header+ZK-Proof ke dalam satu transaksi tunggal. Cukup kirim transaksi ini ke node ringan Rollup1 di mana Rollup2 berjalan membuktikan bahwa Batch dari ketinggian tertentu valid. Tentu saja, Rollup2 juga perlu menjalankan node ringan dari lapisan DA.

Ini adalah prasyarat untuk menjaga kepercayaan jembatan lintas rantai minimal. Namun, jika seseorang sedang menyeberang dari Ether Rollup (Rollup SC berbasis kontrak pintar) ke Ether, tidak perlu lagi menjalankan node ringan lapisan DA Rollup, karena lapisan DA adalah Ether itu sendiri. Ini sangat berbeda dari Celestia’s Sovereign Rollup, di mana Rollups harus menjalankan node ringan lapisan DA masing-masing untuk saling menyeberang.

Ketika Relayer mengirim transaksi lintas-rantai, transaksi diproses oleh pengumpul 2 Rollup2 dan HP2. Kami menambahkan keduanya ke dalam grafik untuk memahami bagaimana node-node di Rollup2 menangani transaksi lintas-Rollup.

Pengulangan Relayer dari Rollup 2 akan mendapatkan Batch Header dan ZKP dari Rollup 2 dan mengirimkannya kembali ke Rollup 1. Rollup 1 juga memiliki node ringan untuk Rollup 2 dan node ringan untuk lapisan DA.

Kita dapat membuat model lebih disederhanakan. Misalkan dua Rollups menggunakan Aggregator Bersama dan Produser Header yang sama, dengan kata lain, mereka menggunakan lapisan DA yang tumpang tindih.

Dalam kasus ini, Pemberi Relayer dapat dilarang secara langsung. Karena Batch Header dan ZK Proof telah dipublikasikan oleh HP ke lapisan DA yang sama, data seperti Header dan ZKP dari Rollup lain dapat dibaca secara langsung pada lapisan DA, dan tidak lagi perlu dilewatkan ke Aggregator Bersama melalui Relayer.

Jelas, Rollup yang menggunakan lapisan DA yang sama tidak perlu bergantung pada Relayers (banyak jembatan lintas rantai bergantung pada node relai). Ini dapat memecahkan masalah keamanan jembatan lintas rantai (dari sudut pandang ini, inter-spanning antara SC Rollups di Ethernet lebih aman daripada inter-spanning antara chain publik yang berbeda).

Pada titik ini, konfigurasi minimum untuk minimisasi kepercayaan: sebuah node ringan tier DA + sebuah node ringan Rollup.

Pernyataan:

1. Artikel ini diambil dari [[Geek Web3](https://mp.weixin.qq.com/s/Wi4FPTCZli5g8UGVkYFnlw) ], hak cipta milik penulis asli [NashQ, Celestia], jika Anda memiliki keberatan terhadap pembaruan, silakan hubungi tim Pembelajaran Gate, tim akan ditangani sesuai dengan proses yang relevan secepat mungkin.
2. Penafian: Pandangan dan opini yang terdapat dalam artikel ini mewakili pandangan pribadi penulis dan bukan merupakan saran investasi apa pun.
3. Artikel dalam bahasa lain diterjemahkan oleh tim Gate Learn dan mungkin tidak boleh direproduksi, didistribusikan, atau disalin tanpa referensi ke Gate.io.