Analisis mendalam tentang Based Booster Rollup: latar belakang, praktik, dan prospek

Penulis asli: jolestar (X: @jolestar )

Saya melihat beberapa teman berbicara tentang Based Rollup, kebanyakan dari mereka membicarakannya dari sudut pandang keamanan. Saya ingin berbicara tentang pandangan saya tentang Based Booster Rollup dari sudut pandang hubungan antara L1 dan L2, dan konstruksi aplikasi.

Ide Based Rollup sebenarnya sangat sederhana, yaitu, pengguna langsung mengirimkan transaksi L2 ke L1, yang diurutkan dan dikemas berdasarkan L1. Namun, L1 tidak memverifikasi keabsahan transaksi, tetapi hanya menjamin urutan dan ketersediaan transaksi. L2 adalah eksekutor murni yang mengeksekusi transaksi L2 yang dikemas pada L1. Apakah ini terlihat familier bagi Anda? Bukankah ini mode Inscription? Ya, Indexer dari inscription dapat dipahami sebagai L2 di sini. Saya telah mengatakan ini dalam artikel Apakah Inscription Bug atau Fitur?

Booster Rollup dimulai dari perspektif lain. Bagaimana cara membaca status L1 secara langsung melalui kontrak pada L2? Idenya tidak rumit. Karena Based Rollup sudah menjalankan transaksi L2 pada L1, mengapa tidak menjalankan transaksi L1 juga? Dengan cara ini, status L1 dan L2 berada dalam pohon status yang besar, dan kontrak L2 dapat langsung membaca status L1.

Jadi ada juga proyek yang menggabungkan Based Rollup dan Booster Rollup, yang disebut Based Booster Rollup (BBR), seperti taiko.

Latar Belakang BBR

Sejak BBR diusulkan hingga menarik perhatian pasar, latar belakang utamanya adalah masalah perpecahan yang disebabkan oleh solusi L2 arus utama Ethereum saat ini, perpecahan antara L1 dan L2, dan perpecahan antara L2. Fungsi yang disediakan oleh solusi L2 saat ini, baik dari perspektif pengembang atau perspektif pengguna, tidak jauh berbeda dari Alt-L1. Membaca data L1 masih bergantung pada Oracle, aset masih memerlukan jembatan, dan dompet harus berpindah jaringan. Perpecahan ini juga membawa masalah lain. Pengikatan antara L1 dan L2 tidak begitu ketat. L2 dapat menambahkan serangkaian mekanisme konsensus kapan saja untuk menjadi Alt-L1, berdiri sendiri, dan membuat pengembang dan pengguna pada dasarnya tidak menyadarinya. Hubungan pengikatan utama saat ini berasal dari batasan EF pada ortodoksi: L2 harus menggunakan L1 sebagai DA, tetapi jelas batasan ini tidak dapat diandalkan.

Jadi, jika kita mengganti semua solusi L2 saat ini dengan solusi Based Rollup, apakah masalahnya akan terpecahkan? Saya kira Optimism dan Arbitrum akan langsung berkata, bukankah mudah untuk beralih ke Based Rollup? Solusi L2 utama sekarang memiliki mekanisme Force Inclusion. L2 secara langsung menghapus Sequencer dan memungkinkan pengguna untuk mengirim transaksi ke L1 melalui Force Inclusion. Bukankah Based Rollup sudah diterapkan?

Namun, dapatkah ini menyelesaikan masalah fragmentasi? Tidak. Meskipun Arb dan Op sama-sama mengirimkan transaksi ke L1 secara real time, dan L1 mengemas serta mengurutkannya, keduanya masih terfragmentasi karena masing-masing hanya mengenali transaksinya sendiri. Pada titik ini, setiap orang harus memahami bahwa kunci untuk menyelesaikan masalah fragmentasi untuk Based Rollup adalah memiliki transaksi atau data yang dapat dibagikan antara L2, dan format data ini memerlukan:

• Itu harus berupa format defined pada L1 yang independen dari platform dan implementasi. Akun L2 dan mesin virtual yang berbeda berbeda, dan transaksinya tidak dapat dibagikan secara langsung.

• Hal ini memerlukan konsensus antar L2 dan dukungan dari berbagai L2.

Oleh karena itu, harus ada protokol terlebih dahulu, merancang protokol publik dan format data terlebih dahulu, hanya menyimpan data yang diperlukan oleh protokol pada rantai, mengeksekusi dan memverifikasi di luar rantai, dan mengimplementasikan solusi dukungan untuk L2 yang berbeda. Namun sebenarnya cukup sulit untuk mencapai kedua poin ini. Pertama-tama, pengembang dalam ekosistem Ethereum umumnya merancang protokol melalui kontrak pintar, dan tidak memiliki kebiasaan merancang protokol secara langsung berdasarkan format data. Upaya utama dalam arah ini adalah Ethscriptions ketika prasasti populer terakhir kali. Poin kedua bahkan lebih sulit, dan memerlukan latihan dan waktu untuk memverifikasi.

Dari BBR ke BBSR, L2 yang Dapat Ditumpuk

Setelah membahas masalah berbagi data, mari kita bahas pengalaman pengguna. Jelas, jika semua transaksi dikirim langsung ke L1 oleh pengguna, pengalamannya hampir sama dengan menggunakan L1, baik itu Gas atau waktu konfirmasi. Jadi beberapa orang mulai merancang protokol prakonfirmasi untuk Based Rollup, tetapi jika protokol prakonfirmasi benar-benar dapat berfungsi, semua transaksi harus melewati protokol prakonfirmasi terlebih dahulu, lalu bukankah itu Sequencer? Apakah ini membuang-buang waktu untuk membicarakan hal ini?

Kontradiksi ini muncul karena orang-orang mencampuradukkan beberapa jenis transaksi:

1. Transaksi yang dikirimkan langsung oleh pengguna ke L1 dan dieksekusi serta diverifikasi oleh L1 adalah transaksi L1.

2. Pengguna mengirimkan langsung ke L1, tetapi L1 tidak secara langsung memverifikasi dan mengeksekusi. Transaksi data protokol bersama antara L2 dapat disebut transaksi L1.5.

3. Pengguna secara langsung mengirimkan transaksi ke L2 Sequencer, yang dikonfirmasi terlebih dahulu dan dieksekusi oleh Sequencer, transaksi khusus L2 tertentu.

Based Rollup hanya terkait dengan 1 dan 2. 3 adalah metode kerja Sequencer Rollup saat ini. Keduanya dapat digabungkan.

Misalkan ada solusi Rollup seperti ini:

1. Sequencer secara otomatis menyinkronkan semua transaksi L1 (termasuk L1.5) dan mengeksekusinya sesuai urutan yang diberikan oleh L1.

2. Sequencer menerima transaksi L2 pada saat yang sama, mengurutkannya bersama dengan transaksi L1, dan mengeksekusinya.

Melalui 1, ia mengimplementasikan Based dan Booster, dan melalui 2, ia mewujudkan konfirmasi cepat transaksi L2 tanpa mengorbankan pengalaman pengguna. Menurut skema penamaan sebelumnya, ini seharusnya disebut BBSR (Based Booster Sequencer Rollup), tetapi agak panjang dan tidak mudah dipahami, jadi saya menyebutnya Stackable L2. Seperti namanya, L2 ditumpuk pada L1, dan L2 berisi semua transaksi dan status L1. Ini adalah solusi dari @JaringanRooch .

Bagaimana cara memastikan DA transaksi L2? Rollup atau Rollout?

Jika solusi di atas diadopsi, akan agak aneh bagi L2 untuk mengemas transaksinya sendiri dan mengirimkannya ke L1 lagi, karena L2 akan membaca transaksi L1 yang mengemas transaksinya sendiri dan mengeksekusinya kembali, yang agak mirip dengan outputnya sendiri yang juga menjadi inputnya sendiri. Oleh karena itu, solusi Rooch adalah Rollout, bukan Rollup. Karena dalam jangka panjang, ruang blok L1 sangat berharga, dan beberapa transaksi L2 yang menempati ruang L1 adalah mode bergulir. Ruang L1 harus dibiarkan untuk transaksi L1 dan L1.5. Transaksi tingkat aplikasi L2 harus mencari ruang blok yang lebih murah dan memperluas ruang blok baru melalui peluncuran, yang juga kondusif bagi pengembangan seluruh ekosistem industri.

Praktik BBSR/L2 yang Dapat Ditumpuk dalam Ekosistem Bitcoin

Uraian sebelumnya semuanya dari sudut pandang Ethereum. Karena Rooch adalah praktik BBSR atau Stackable L2 pertama Bitcoin, mari kita bahas perbedaan dalam ekosistem Bitcoin.

Tidak ada kontrak pintar Turing-lengkap pada Bitcoin L2, yang menjadi keuntungan dalam mode Based Rollup. Karena Based Rollup tidak memerlukan L1 untuk mengeksekusi dan memverifikasi transaksi, ia hanya perlu memastikan Permission Less dan DA. Hal ini juga memaksa proyek-proyek dalam ekosistem Bitcoin untuk merancang protokol berdasarkan struktur data dari waktu yang lama. Baik itu koin berwarna, atau RGB, Taproot Assets, Ordinals Inscription, Atomicals, Runs, dll., semuanya merupakan upaya dalam kategori ini dan dapat dimasukkan dalam konsep luas protokol CSV (Client-side Validation). Transaksi mereka adalah transaksi L1.5 yang umum. Jika proyek-proyek dalam ekosistem Ethereum ingin mempraktikkan Based L2 dan merancang protokol yang dibagikan antara beberapa L2, itu akan kurang lebih sama dengan protokol di atas.

Mari kita ambil Rooch sebagai contoh untuk menjelaskan mode kerja BBSR pada Bitcoin:

1. Pengguna akan langsung mengirimkan transaksi L1 dan L1.5 ke Bitcoin. Karena protokolnya bersifat publik, titik masuknya bisa berupa aplikasi apa pun.

2. Rooch akan menyinkronkan semua transaksi L1, memproses UTXO di dalamnya, dan mencari tahu apakah ada informasi protokol tambahan, lalu menggunakan modul Move yang sesuai untuk memprosesnya. Misalnya, transaksi yang diidentifikasi sebagai Inscription akan diproses oleh modul ord, sementara transaksi Babylon Staking akan diproses oleh modul bbn.

3. Pengguna langsung mengirimkan transaksi L2 ke node Roochs Sequencer untuk diproses. Hasil eksekusi dari tiga transaksi di atas akan menghasilkan pohon status yang lengkap, dan kontrak aplikasi dapat memanfaatkan status yang dihasilkan oleh transaksi L1 dan L1.5 secara penuh.

Aplikasi dalam mode ini dapat merancang dua jenis transaksi, satu adalah transaksi protokol publik (Bagian Berbasis, pada L1), dan yang lainnya adalah transaksi aplikasi (diurutkan oleh Sequencer). Keduanya dapat bekerja sama satu sama lain melalui mode Booster untuk memastikan Permission Less sekaligus memastikan pengalaman pengguna.

Seperti disebutkan sebelumnya, desain protokol publik memerlukan waktu dan latihan untuk memverifikasi dan mencapai konsensus, dan Rooch dapat menyediakan lingkungan eksperimen yang nyaman: jika Anda ingin merancang aplikasi atau protokol aset baru pada Bitcoin, Anda hanya perlu menentukan format protokol, lalu menerapkan modul kontrak Move yang sesuai untuk memprosesnya, lalu Anda dapat bereksperimen dengan membangun skenario aplikasi.

Tentu saja, ekosistem Bitcoin juga menghadapi beberapa tantangan di sepanjang rute ini:

1. Ketika Bitcoin pertama kali dirancang, tidak ada cukup ruang untuk pengembangan untuk skenario DA ini. Oleh karena itu, cara menulis data ke Bitcoin adalah salah satu arah yang telah dicoba dieksplorasi oleh berbagai protokol, seperti menyematkan data dalam OP_RETURN, melalui Witness, dan bahkan melalui tanda tangan. Saat ini, masih terdapat kekurangan solusi yang terstandarisasi.

2. Ekosistem Bitcoin belum mencapai konsensus luas tentang nilai data tertanam pada rantai tersebut. Inilah yang saya serukan sejak kegilaan penulisan terakhir. Ekosistem Bitcoin harus mementingkan nilai Bitcoin sebagai bus data publik global.

Nilai L1 sebagai bus data umum global

Sejak musim panas DeFi, seluruh bidang Kripto telah mengeksplorasi aplikasi baru di luar DeFi. Baik itu kegilaan prasasti Bitcoin atau diskusi hangat Based Rollup baru-baru ini, hal itu dapat dipahami sebagai penemuan kembali nilai L1 sebagai bus data. Dari perspektif sistem terdistribusi, pemisahan antar sistem dapat dicapai melalui bus data, dan pemisahan antar sistem merupakan salah satu prasyarat utama untuk mencapai izin yang lebih sedikit. Misalnya, bursa terdesentralisasi dalam ekosistem Kripto telah memanfaatkan sepenuhnya blockchain sebagai Bus Data untuk mencapai docking terdesentralisasi, yang sulit dicapai secara langsung dalam sistem keuangan tradisional. Jika Anda ingin mendukung aplikasi yang lebih kompleks, Anda hanya perlu meningkatkan transaksi transfer sederhana ke transaksi protokol aplikasi untuk mencapai izin tingkat aplikasi yang lebih sedikit, dan metode ini merupakan yang paling tidak invasif untuk aplikasi yang ada.

Artikel ini terutama membahas BBR dari sudut pandang ekologi dan aplikasi. Keamanan mode BBR dan interoperabilitas status L1, L1.5, dan L2 dalam mode BBR akan dibahas secara rinci dalam artikel selanjutnya. Beberapa tautan terkait dilampirkan di bagian akhir, termasuk artikel historis saya dan penjelasan Based Rollup dari berbagai sudut pandang oleh teman-teman Twitter.

Tautan Terkait:
1. Stackable L2 — Solusi ekspansi blockchain baru https://rooch.network/zh-CN/blog/stackable-l2

2. Bagaimana seharusnya Bitcoin Layer 2 dilakukan? https://x.com/jolestar/status/1717358817992995120 Saya merancang rencana awal berdasarkan bagaimana L2 menggunakan status dan data pada Bitcoin L1. Seorang teman menyebutkan solusi Booster di komentar, dan akhirnya menerapkan solusi Booster dalam praktiknya.

3. Apakah tulisan itu merupakan bug atau fitur? https://x.com/jolestar/status/1732711942563959185 Artikel ini menjelaskan nilai prasasti dari sudut pandang bagaimana L2 dibangun, termasuk masalah kesesuaian insentif antara L1 dan L2.

4. Pembahasan mengenai Based Rollup dari sudut pandang teori pengurangan @kerne l1 983 https://web3 caff.com/zh/arsip/108241

5. Artikel @jason_chen 998 tentang Based Rollup https://x.com/jason_chen998/status/1799692331635048697

6. Berdasarkan Laporan Riset Rollup Track https://research.web3 caff.com/zh/arsip/22719

Tautan asli

Artikel ini bersumber dari internet: Analisis mendalam tentang Based Booster Rollup: latar belakang, praktik, dan prospek

Terkait: Kata sandi aman PayFi dalam revolusi pembayaran menjaga inti keuangan Web3

Artikel ini Hash (SHA 1): 8656ff83d95af1de9dab2b925597cf72c6f63c66 No.: Lianyuan Security Knowledge No.032 Dengan terus berkembangnya teknologi blockchain, industri keuangan mengalami transformasi yang belum pernah terjadi sebelumnya. Dalam konteks ini, sebuah konsep baru muncul secara bertahap: PayFi (Payment Finance). Istilah ini pertama kali diusulkan oleh Lily Liu, Ketua Solana Foundation, pada konferensi EthCC 2024 untuk mengeksplorasi model pembayaran dan keuangan yang inovatif. Visi PayFi bukan hanya sistem pembayaran yang berbasis pada kriptomata uang, tetapi juga berharap untuk menyediakan layanan keuangan yang lebih aman, lebih cepat, dan lebih murah kepada pengguna melalui teknologi terdesentralisasi yang dikombinasikan dengan nilai waktu mata uang. 1. Konsep inti PayFi: nilai waktu uang dan keuangan terdesentralisasi Apa itu PayFi Lily Liu menyebutkan bahwa motivasi inti PayFi adalah untuk mewujudkan visi asli Bitcoin…