Urutan = Agregator + Produser Header

• Judul asli yang diteruskan: Peneliti Celestia menganalisis 6 varian Rollup: Sequencer = agregator + Generator header

Catatan: Untuk tujuan membuat model Rollup lebih mudah dipahami dan dianalisis, peneliti Celestia, NashQ, membagi Rollup Sequencer menjadi dua entitas logis - Agregator dan Header Producer. Pada saat yang sama, ia membagi proses pemesanan transaksi menjadi tiga langkah logis: penyertaan, pemesanan, dan eksekusi.

Dipandu oleh pemikiran analitis ini, enam varian utama Sovereign Rollup menjadi lebih jelas dan lebih mudah dipahami. NashQ membahas secara rinci ketahanan sensor dan keaktifan varian Rollup yang berbeda, serta konfigurasi minimum setiap node varian Rollup dalam keadaan minimalisasi kepercayaan (yaitu, untuk mencapai keadaan tanpa kepercayaan, setidaknya jenis node apa yang harus dijalankan oleh pengguna Rollup).

Meskipun artikel ini menganalisis Rollup dari sudut pandang Celestia, yang berbeda dengan cara komunitas Ethereum menganalisis model Rollup, mengingat banyaknya interkoneksi antara Rollup Ethereum dan Celestia Sovereign Rollup, serta pengaruh yang semakin meningkat, artikel ini juga sangat layak untuk dibaca oleh para penggemar Ethereum.

Apa yang dimaksud dengan Rollup?

Rollups adalah blockchain yang memposting data transaksi mereka ke blockchain lain dan mewarisi konsensus dan ketersediaan datanya.

Mengapa saya mengubah "blokir" menjadi "data transaksi" di sini? Izinkan saya memberi tahu Anda perbedaan antara blok rollup dan data rollup dan menunjukkan kepada Anda bahwa rollup minimal hanya membutuhkan data rollup dengan varian pertama kami.

Blok rollup adalah sebuah struktur data yang mewakili blockchain pada ketinggian tertentu. Terdiri dari data rollup dan header rollup. Dan data Rollup adalah kumpulan transaksi atau perbedaan status antara kumpulan transaksi.

Varian 1: Rollup Pesimis Berbasis

Cara paling sederhana untuk membuat rollup dimulai dengan pengguna yang memposting transaksi ke blockchain lain. Kita akan menyebut blockchain ini sebagai lapisan konsensus dan ketersediaan data, tetapi saya akan menyingkatnya menjadi DA-Layer di semua diagram berikut. (Catatan: mirip dengan Layer1 yang sering disebut dalam komunitas Ethereum).

Pada varian pertama kami, setiap node rollup harus memutar ulang semua transaksi pada blockchain untuk memeriksa status terbaru. Kami baru saja membuat Rollup yang pesimis!

Rollup pesimis adalah rollup yang hanya mendukung node penuh yang memutar ulang semua transaksi dalam rollup untuk memeriksa validitasnya.

Tetapi dalam kasus ini, siapakah yang menjadi sequencer dalam kasus ini? Tidak ada entitas yang benar-benar mengeksekusi transaksi selain dari node penuh rollup itu sendiri. Biasanya, sequencer akan mengumpulkan transaksi dan menghasilkan header rollup, tetapi tidak ada header dalam kasus ini!

Untuk memfasilitasi diskusi, kami membagi sequencer menjadi dua entitas logis: agregator dan produser header membedakannya. Satu entitas harus sadar akan state (yaitu, harus mengeksekusi state untuk menghitung header), tetapi agregator tidak perlu memahami state untuk dapat mengagregasinya.

Pengurutan adalah proses agregasi dan produksi header.

Agregasi adalah proses pengelompokan transaksi ke dalam satu batch. Batch transaksi terdiri dari satu atau beberapa transaksi. (Catatan: Batch adalah bagian dari data di blok Rollup kecuali Header).

Produksi header adalah proses pembuatan header rollup.

Rollup Header adalah metadata tentang blok, yang minimal, termasuk komitmen untuk transaksi di blok tersebut. (Catatan: Komitmen di sini mengacu pada komitmen terhadap kebenaran hasil pemrosesan transaksi).

Melalui perspektif di atas, kita dapat melihat siapa yang memainkan peran masing-masing komponen Rollup. Pertama-tama, mari kita lihat bagian agregator. Rollup pesimis yang disebutkan sebelumnya tidak memiliki proses pembuatan header, dan pengguna mempublikasikan transaksi secara langsung ke DA-Layer, yang berarti jaringan DA-Layer pada dasarnya bertindak sebagai agregator.

Rollup Pesimis adalah varian Rollup yang mendelegasikan langkah agregasi ke DA-Layer. Kamera ini tidak memiliki sequencer. Kadang-kadang, jenis rollup ini disebut "rollup berdasarkan".

Rollup berbasis memiliki ketahanan sensor dan keaktifan yang sama dengan DA-Layer (aktivitas mengukur kecepatan respons sistem terhadap permintaan pengguna). Jika pengguna Rollup jenis ini ingin mencapai kondisi kepercayaan minimal (paling dekat dengan Trustless), mereka harus menjalankan setidaknya sebuah node ringan DA-Layer dan sebuah node penuh rollup.

Varian 2: Rollup Pesimis menggunakan Agregator Bersama

Mari kita bahas agregasi pesimistis menggunakan agregator bersama. Ide ini diusulkan oleh Evan Forbes dalam postingan 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 membuka UX yang setara dengan web2, sequencer bersama [...] dapat memberikan komitmen lunak yang cepat (catatan: bukan jaminan yang sangat andal). Komitmen lunak ini memberikan beberapa janji arbitrer mengenai urutan akhir transaksi (yaitu, mereka berjanji bahwa urutan transaksi tidak akan berubah), dan dapat digunakan untuk membuat versi negara yang diperbarui sebelum waktunya (tetapi finalisasi belum selesai saat ini).

Segera setelah data blok telah dikonfirmasi untuk diposting di baselayer (s/b mengacu pada DAlayer), status dapat dianggap final."

Karena kita masih menggunakan rollup pesimis, kita hanya memiliki node penuh rollup dan tidak ada node ringan. Setiap node harus mengeksekusi semua transaksi untuk menjamin validitas. Tidak ada light node dalam sistem ini, jadi tidak diperlukan rollup header, alias header producer. (Catatan: Secara umum, light node pada blockchain tidak perlu menyinkronkan blok yang lengkap, tetapi hanya menerima header blok)

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

Pada varian ini, pengguna Rollup perlu menjalankan setidaknya yang berikut ini dalam keadaan minim kepercayaan:

Node cahaya DA-Layer + node cahaya dari jaringan agregator bersama + Node penuh Rollup.

Pada saat ini, perlu untuk memverifikasi header agregator yang diterbitkan (tidak mengacu pada Rollup Header) melalui simpul cahaya jaringan agregator bersama. Seperti yang disebutkan di atas, agregator bersama melakukan tugas penyortiran transaksi. Dalam header agregator yang diterbitkan, berisi komitmen kriptografi, sesuai dengan Batch yang diterbitkannya pada DA-Layer.

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

(Karena konten yang terdapat di atas relatif tidak jelas, Anda dapat membaca diagramnya lagi)

Inklusi adalah proses di mana sebuah transaksi diterima ke dalam blockchain.

Pemesanan adalah proses mengatur transaksi dalam urutan tertentu dalam blockchain.

Eksekusi adalah proses di mana transaksi dalam blockchain diproses, dan efeknya diterapkan pada status blockchain.

Karena agregator bersama mengontrol penyertaan dan pemesanan, kami mewarisi resistensi sensornya.

Jika kita mengasumsikan L_ss adalah kelangsungan hidup agregator bersama, dan L_da adalah kelangsungan hidup DA-Layer, maka kelangsungan hidup skema ini adalah L = L_da && L_ss. Dengan kata lain, jika salah satu sistem mengalami kegagalan liveness, rollup juga mengalami kegagalan liveness.

Untuk memudahkan, saya akan menggunakan liveness sebagai boolean. Jika agregator bersama gagal, kita tidak dapat melanjutkan rollup. Jika DA-Layer gagal, kita dapat melanjutkan dengan komitmen lunak agregator bersama. Namun, kami akan mengandalkan konsensus agregator bersama dan ketersediaan data, yang akan lebih buruk daripada DA-Layer asli.

Mari kita lanjutkan menjelajahi ketahanan sensor dari solusi Rollup di atas:

Dalam skema ini, DA-Layer tidak dapat menyensor transaksi tertentu. (Catatan: Peninjauan transaksi sering kali menolak untuk mengizinkan transaksi tertentu untuk diunggah ke chain). Ini hanya dapat menyensor seluruh kumpulan rollup yang sudah dikumpulkan oleh agregator bersama. (menolak batch untuk dimasukkan ke dalam DA-Layer).

Namun, menurut alur kerja Rollup, ketika agregator berbagi mengirimkan batch transaksi ke DA-Layer, ia telah menyelesaikan pengurutan transaksi, dan urutan di antara batch yang berbeda juga telah ditentukan. Oleh karena itu, tinjauan transaksi oleh DA-Layer seperti ini tidak memiliki efek lain kecuali menunda finalitas buku besar Rollup.

Singkatnya, saya percaya bahwa fokus ketahanan sensor adalah untuk memastikan bahwa tidak ada satu entitas pun yang dapat mengendalikan atau memanipulasi aliran informasi dalam sistem, sementara kelangsungan hidup melibatkan pemeliharaan fungsionalitas dan ketersediaan sistem, bahkan dengan adanya pemadaman jaringan dan tindakan permusuhan. Meskipun hal ini bertentangan dengan definisi akademis arus utama saat ini, saya akan tetap menggunakan definisi konsep yang telah saya nyatakan.

Varian 3: Rollup Pesimis dengan Agregasi Berbasis dan Berbagi

Meskipun komunitas menikmati manfaat dari agregator bersama, kami ingin menghindari ketergantungan pada agregator tersebut dan ingin memiliki fallback ke DA-Layer. Kami akan menggabungkan pemesanan dan memungkinkan pengguna untuk mengirimkan transaksi langsung ke DA-Layer. Ini menggabungkan agregasi berbasis dan bersama.

Kami mengasumsikan pemesanan akhir akan ditafsirkan sebagai semua transaksi yang dipesan oleh agregator bersama dan kemudian semua transaksi berbasis setelah itu per blok DA-Layer. Kami menyebutnya sebagai aturan pilihan garpu rollups.

Agregasi adalah proses dua langkah di sini. Pertama, agregator bersama memimpin, mengumpulkan beberapa transaksi. Kemudian, DA-Layer menggabungkan dengan batch yang sudah dipesan dan transaksi yang dikirimkan pengguna secara langsung.

Analisis resistensi sensor sekarang lebih kompleks. Node jaringan DA-Layer dapat meninjau Batch yang dikirimkan oleh agregator bersama sebelum blok DA-Layer berikutnya diproduksi. Setelah mengetahui data transaksi dalam Batch, node DA-Layer dapat mengekstrak nilai MEV, memulai transaksi yang berjalan di depan dengan akunnya di jaringan Rollup, dan memasukkannya ke dalam blok DA-Layer sebelum menyertakan Batch yang dikirimkan oleh agregator bersama Rollup.

Tampaknya, finalitas pesanan transaksi yang dijamin oleh komitmen lunak dari varian Rollup jenis ketiga lebih rapuh daripada varian Rollup jenis kedua yang disebutkan di atas. Dalam hal ini, agregator bersama menyerahkan nilai MEV ke node DA-Layer. Mengenai hal ini, saya sarankan para pembaca untuk menonton ceramah tentang sensor MEV yang menguntungkan.

Saat ini, beberapa solusi desain telah muncul untuk mengurangi kemampuan node jaringan DA-Layer untuk mengeksekusi transaksi MEV tersebut, seperti fungsi "periode jendela reorganisasi", yang akan menunda transaksi yang dikirimkan langsung oleh pengguna jaringan Rollup ke DA-Layer. Sovereign Labs telah merinci hal ini dalam proposal desainnya yang dinamakan Based Sequencing with Soft Confirmations, di mana konsep "preferred sequencer" diusulkan.

Karena MEV bergantung pada skema agregator yang Anda pilih dan aturan pilihan fork pada rollup, beberapa tidak akan membocorkan apa pun, dan beberapa akan membocorkan sebagian atau seluruh MEV ke DA-Layer, tetapi itu adalah topik untuk hari lain.

Mengenai kelincahan, desain rollup ini lebih unggul daripada sekadar memiliki agregator bersama. Jika agregator bersama mengalami kegagalan liveness, pengguna masih dapat mengirimkan transaksi ke DA-Layer.

Terakhir, mari kita bahas tentang pengaturan yang meminimalkan kepercayaan terkecil: simpul cahaya DA-Layer + simpul cahaya agregator bersama + simpul penuh rollup.

Pada saat ini, kita masih perlu memvalidasi header agregator bersama untuk node penuh rollup kita untuk dapat membedakan batch transaksi untuk aturan pilihan fork-nya.

Varian 4: Rollup Optimis Berbasis dengan Produser Header Terpusat

Mari kita mulai memasak beberapa node ringan menggunakan varian yang disebut rollup optimis berbasis dengan produser header terpusat. Desain ini menggunakan DA-Layer untuk mengumpulkan transaksi, tetapi kami memperkenalkan produsen header terpusat untuk mengaktifkan node cahaya rollup.

Node lampu Rollup secara tidak langsung dapat memverifikasi validitas transaksi Rollup melalui satu putaran pembuktian penipuan. Simpul cahaya akan mengambil sikap optimis terhadap generator Rollup Header, dan membuat konfirmasi akhir setelah periode jendela bukti penipuan berakhir. Kemungkinan lain adalah bahwa ia menerima bukti penipuan dari full node yang jujur, mengetahui bahwa generator Header telah mengirimkan data yang salah.

Saya tidak akan menjelaskan secara detail tentang cara kerja pembuktian kecurangan satu putaran, karena ini akan melanggar cakupan artikel ini. Manfaatnya adalah Anda dapat mengurangi waktu jendela bukti penipuan dari 7 hari menjadi beberapa hari, yang belum ditentukan namun nilainya lebih kecil. Light node dapat menerima bukti-bukti kecurangan melalui lapisan p2p tanpa perlu menunggu adanya perselisihan, karena semuanya ditangkap dalam satu bukti.

Kami menggunakan DA-Layer sebagai agregator yang mewarisi ketahanan terhadap sensor. Ia melakukan penyertaan dan pemesanan. Produser header terpusat akan membaca urutan kanonik dari DA-Layer dan dapat membuat header yang valid dari situ. Produser header terpusat akan memposting header dan state root ke DA-Layer. Akar negara ini sangat penting untuk menciptakan bukti kecurangan terhadap komitmen ini. Agregator melakukan penyertaan dan pemesanan, sementara produsen header melakukan eksekusi.

Diasumsikan bahwa DA-Layer (yang juga bertindak sebagai agregator Rollup saat ini) cukup terdesentralisasi dan memiliki ketahanan sensor yang baik. Selain itu, produser Header tidak dapat mengubah urutan transaksi Rollup yang diterbitkan oleh agregator. Sekarang, jika produser Header terdesentralisasi, satu-satunya keuntungan adalah keaktifan yang lebih baik, tetapi sifat-sifat lain dari Rollup sama dengan varian pertama, Rollup Berbasis.

Jika produser header mengalami kegagalan liveness, rollup juga mengalami kegagalan liveness. Simpul cahaya tidak akan dapat mengikuti rantai, sementara simpul penuh masih dapat mengikuti rantai jika diinginkan, kembali ke rollup pesimis berbasis seperti yang dijelaskan dalam varian 1. Jelas, Konfigurasi minimum untuk minimalisasi kepercayaan yang dijelaskan dalam varian 4 adalah:

Node lampu DA-Layer + Node lampu Rollup.

Varian 5: Berbasis ZK-Rollup dengan Pasar Prover yang Terdesentralisasi

Kita telah membahas Pessimistic Rollup (Rollup Berbasis) dan Optimistic Rollup, sekarang saatnya untuk mempertimbangkan ZK-Rollup. Baru-baru ini Toghrul membuat presentasi tentang pemisahan agregator (Sequencer) dan produser Header (Prover) (Pemisahan Sequencer-Prover dalam Zero-Knowledge Rollups). Dalam model ini, menerbitkan transaksi sebagai data Rollup dan bukan sebagai State Diff lebih mudah ditangani, jadi saya akan fokus pada yang pertama. Varian 5 adalah zk-rollup berbasis dengan pasar prover yang terdesentralisasi.

Sekarang, Anda seharusnya sudah memahami apa yang dilakukan oleh rollup berbasis. Varian 5 mendelegasikan peran agregator ke node DA-Layer, yang melakukan pekerjaan penyertaan dan pemesanan, saya akan mengutip dari dokumen Sovereign-Labs yang melakukan pekerjaan luar biasa dalam menjelaskan siklus hidup desain mereka. Saya akan menyesuaikannya sedikit agar sesuai dengan varian 5.

Pengguna mengirim gumpalan data baru ke rantai L1. Segera setelah gumpalan diselesaikan pada L1, maka secara logika, gumpalan tersebut sudah final. Segera setelah blok L1 diselesaikan, node penuh dari rollup memindai dan memproses semua gumpalan data yang relevan sesuai urutan kemunculannya, menghasilkan root state rollup yang baru. Pada titik ini, blok diselesaikan secara subjektif dari sudut pandang semua node penuh.

Produsen header kami dalam desain ini adalah pasar pepatah yang terdesentralisasi.

Node Prover (node penuh yang berjalan di dalam ZKVM) melakukan proses yang kurang lebih sama dengan node penuh - memindai blok DA dan memproses semua batch secara berurutan - menghasilkan bukti dan mengirimkannya ke rantai. (Proofs perlu diposting di rantai jika rollup ingin memberi insentif kepada para pembukti - jika tidak, tidak mungkin untuk mengetahui pembukti mana yang pertama kali memproses batch tertentu). Setelah sebuah bukti untuk batch tertentu telah diposting di chain, batch tersebut secara subyektif bersifat final untuk semua node, termasuk light node.

(Karena ada banyak konsep yang terlibat, Anda bisa melihat diagram skematiknya lagi)

Varian 5 memiliki ketahanan sensor yang sama dengan DA-Layer. Pasar prover yang terdesentralisasi tidak dapat menyensor transaksi karena DA-Layer menentukan urutan kanonik. Kami mendesentralisasi produsen header hanya untuk meningkatkan daya hidup dan menciptakan pasar insentif. Liveness di sini adalah L = L_da && L_pm (pepatah pasar). Jika insentif pasar prover tidak selaras, atau mengalami kegagalan liveness, light node tidak akan dapat mengikuti rantai, tetapi rollup node penuh masih dapat mengikuti rantai jika diinginkan, kembali ke rollup pesimis berbasis. Pengaturan terkecil yang meminimalkan kepercayaan ada di sini, seperti halnya dalam kasus optimis yang memiliki simpul cahaya DA-Layer + simpul cahaya rollup.

Varian 6: Rollup Hibrida Berbasis dengan Produser Header Optimis Terpusat dan Prover Terdesentralisasi

Kami masih membiarkan node DA-Layer bertindak sebagai agregator untuk Rollup, dan mendelegasikannya untuk menangani penyertaan dan penyortiran transaksi.

Seperti yang dapat Anda lihat dari gambar di bawah ini, baik ZK Rollup dan Optimistic Rollup menggunakan batch transaksi yang sama yang dipesan di DA-Layer sebagai sumber buku besar Rollup. Inilah mengapa kita dapat menggunakan dua sistem bukti pada saat yang sama: batch transaksi yang dipesan pada DA-Layer tidak terpengaruh oleh sistem bukti itu sendiri.

Mari kita bicara tentang finalitas. Dari perspektif node penuh rollup, rollup sudah final ketika DA-Layer sudah final, karena hanya perlu mengeksekusi transaksi untuk varian ini. Tetapi kami lebih peduli tentang hasil akhir dari simpul cahaya. Mari kita asumsikan produsen header terpusat memasang beberapa saham, menandatangani header, dan memposting akar state yang dihitung ke DA-Layer.

Seperti varian 4 sebelumnya, light node akan secara optimis mempercayai eksekusi dan menunggu bukti kecurangan dari full node yang jujur yang menunjukkan bahwa produsen header melakukan kecurangan. Setelah jendela bukti penipuan selesai, blok rollup menjadi final dari sudut pandang simpul lampu rollup.

Poin kuncinya adalah jika kita bisa mendapatkan bukti ZK, kita tidak perlu lagi menunggu jendela bukti penipuan berakhir. Selain bukti penipuan satu putaran, kami dapat mengganti bukti penipuan dengan bukti ZK dan mengabaikan header berbahaya apa pun yang dihasilkan dari produsen header yang optimis!

Ketika light node menerima sertifikat ZK yang sesuai dengan batch transaksi Rollup tertentu, batch tersebut akan diselesaikan.

Sekarang kami memiliki komitmen lunak yang cepat dan penyelesaian yang cepat.

Varian 6 masih menikmati ketahanan sensor yang sama dengan DA-Layer yang menjadi basisnya. Untuk liveness, kita akan memiliki L = L_da && (L_op || L_pm ), yang berarti kita meningkatkan jaminan liveness. Jika salah satu dari produsen header terpusat atau pasar prover mengalami kegagalan, kita dapat kembali ke skema lainnya.

Pengaturan terkecil yang meminimalkan kepercayaan adalah simpul lampu DA-Layer + simpul lampu rollup.

Ringkasan:

1. Kami membagi sequencer menjadi dua entitas logis: agregator dan produser header

2. Kami membagi sequencer ke dalam tiga proses logis: penyertaan, pemesanan, dan eksekusi.

3. Rollup pesimis dan rollup berbasis adalah sesuatu

4. Tergantung pada kebutuhan Anda, Anda bisa menggunakan agregator plug-and-play dan produsen header.

5. Setiap varian Rollup dalam artikel ini mengikuti pola desain ini:
   

Akhirnya, saya memiliki beberapa pemikiran. Tolong pikirkan:

• Bagaimana rollup klasik cocok dengan ini? (mengacu pada Ethereum Rollup)
• Di semua varian, kami hanya membuat agregator melakukan inklusi + pemesanan dan eksekusi produser header. Bagaimana jika agregator hanya melakukan penyertaan dan produser header melakukan pemesanan dan eksekusi? Pikirkan lelang on-chain. Bisakah kita memisahkan ketiganya?
• Apa yang dimaksud dengan produsen header bersama / pasar produsen header?
• Siapa yang mendapatkan MEV? Dan bisakah kita mendapatkannya kembali?

Penafian: Penafian

1. Artikel ini dicetak ulang dari[Geek Web3], Teruskan Judul Asli'Peneliti Celestia menganalisis 6 varian Rollup: Sequencer = agregator + Header generator', Semua hak cipta adalah milik penulis asli[NashQ, Peneliti Celestia]. Jika ada keberatan dengan pencetakan ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata merupakan pandangan dan pendapat penulis dan bukan merupakan saran investasi.
3. Penerjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel terjemahan dilarang.