Beberapa teman sedang mendiskusikan Based Rollup, terutama dari perspektif keamanan. Di sini, saya akan berbagi pandangan saya tentang Based Booster Rollup dari perspektif hubungan L1 dan L2 serta pembangunan aplikasi.
Ide di balik Based Rollup adalah sederhana: pengguna mengirimkan transaksi L2 langsung ke L1, di mana L1 menangani pengurutan dan pengemasan. Namun, L1 tidak memverifikasi keabsahan transaksi, hanya memastikan urutan dan ketersediaan transaksi. L2 adalah lapisan eksekusi murni, memproses transaksi L2 yang dikemas di L1. Jika pengaturan ini terasa akrab, itu karena mirip dengan model Inscription. Sebenarnya, Anda dapat menganggap Indexer Inscription sebagai L2 dalam konteks ini—sebuah poin yang saya bahas dalam artikel saya “Apakah Inscription adalah Bug atau Fitur?”
Booster Rollup mengambil pendekatan yang berbeda: bagaimana L2 dapat langsung membaca status L1 melalui kontrak? Karena Based Rollup sudah mengeksekusi transaksi L2 di L1, mengapa tidak memproses transaksi L1 juga? Dengan cara ini, status L1 dan L2 dapat ada dalam pohon status yang bersatu, memungkinkan kontrak L2 untuk mengakses status L1 secara langsung.
Ini telah menyebabkan proyek menggabungkan Based Rollup dan Booster Rollup, yang secara kolektif disebut sebagai Based Booster Rollup (BBR), seperti yang terlihat dengan proyek seperti #Taiko .
Latar Belakang BBR
Ketertarikan yang growing pada BBR sebagian besar berasal dari fragmentasi saat ini dalam solusi L2 mainstream Ethereum. Fragmentasi ini terjadi antara L1 dan L2, dan di antara L2 itu sendiri. Solusi L2 saat ini beroperasi mirip dengan Alt-L1, bergantung pada oracle untuk mengakses data L1, menjembatani aset, dan membutuhkan pengalihan jaringan di dompet. Selain itu, ikatan antara L1 dan L2 tidak selalu kuat, dan L2 dapat dengan mudah menerapkan mekanisme konsensus mereka sendiri untuk menjadi Alt-L1, secara efektif beroperasi secara independen.
Apakah mengganti semua solusi L2 saat ini dengan Based Rollup akan memperbaiki fragmentasi ini? #Optimism dan #Arbitrum mungkin berargumen bahwa itu memungkinkan karena solusi L2 utama memiliki mekanisme Force Inclusion yang menghapus Sequencer, memungkinkan pengguna untuk mengirim transaksi langsung ke L1 dan mencapai Based Rollup.
Namun, sementara Arb dan Op memang mengirimkan transaksi ke L1 secara real-time untuk pengurutan, mereka tetap terfragmentasi, karena mereka hanya mengenali transaksi mereka. Kunci untuk menyelesaikan fragmentasi ini dengan Based Rollup terletak pada memiliki protokol yang memungkinkan transaksi atau data yang dibagikan di seluruh L2, dengan data yang:
1. Memiliki format yang independen dari platform atau implementasi, didefinisikan di tingkat L1, karena L2 yang berbeda bervariasi dalam akun dan mesin virtual.
2. Diterima oleh beberapa L2.
Oleh karena itu, desain protokol harus datang pertama, menciptakan format data yang dibagikan yang dapat disepakati oleh L2, dan hanya meninggalkan data protokol yang esensial di on-chain, dengan eksekusi dan verifikasi yang terjadi di luar rantai. Arah ini terbukti menantang karena pengembang Ethereum biasanya merancang protokol menggunakan kontrak pintar daripada format data. Upaya utama di sini adalah Ethscriptions selama kegilaan Inscription sebelumnya.
Dari BBR ke BBSR: L2 yang Dapat Ditumpuk
Setelah masalah berbagi data ditangani, pengalaman pengguna menjadi perhatian. Mengirimkan semua transaksi langsung ke L1 akan menyerupai menggunakan L1 dalam hal biaya gas dan waktu konfirmasi. Untuk meningkatkan ini, beberapa telah merancang protokol pra-konfirmasi untuk Based Rollup, meskipun penerapan protokol semacam itu secara efektif memperkenalkan kembali Sequencers, membatalkan beberapa penyederhanaan.
Kontradiksi ini muncul dari mencampurkan tiga jenis transaksi:
1. Transaksi L1 yang langsung diajukan dan dieksekusi oleh L1.
2. Transaksi L1.5 yang diajukan ke L1 tetapi tidak segera dieksekusi oleh L1, memfasilitasi protokol berbagi data L2.
3. Transaksi spesifik L2 yang diajukan ke Sequencer L2 untuk pra-konfirmasi dan eksekusi.
Based Rollup hanya relevan untuk dua jenis pertama, sedangkan yang ketiga termasuk dalam model Sequencer Rollup saat ini. Ini dapat berdampingan. Bayangkan model Rollup di mana:
1. Sequencer secara otomatis menyinkronkan dan mengeksekusi semua transaksi L1 (termasuk L1.5) dalam urutan yang ditentukan oleh L1.
2. Sequencer menerima dan mencampur transaksi L2 dengan transaksi L1 untuk pengurutan dan eksekusi.
Dalam pengaturan ini, 1 memungkinkan fungsi Based dan Booster, sementara 2 mencapai konfirmasi transaksi L2 yang cepat tanpa mengorbankan pengalaman pengguna. Saya akan menyebut ini model L2 yang Dapat Ditumpuk, di mana L2 menumpuk di atas L1 dan menggabungkan semua transaksi dan status L1. Pendekatan ini sedang diterapkan oleh Rooch Network.
Memastikan Ketersediaan Data (DA) untuk Transaksi L2: Rollup atau Rollout?
Dengan model ini, menjadi berlebihan bagi L2 untuk mengemas transaksi mereka untuk dikirimkan ke L1, karena mereka akan terus mengeksekusi data yang sama. Dengan demikian, solusi Rooch menggunakan Rollout sebagai pengganti Rollup, menghemat ruang blok L1 yang berharga dengan meninggalkannya untuk transaksi L1 dan L1.5, sementara transaksi L2 berkembang ke ruang blok alternatif, menguntungkan seluruh ekosistem.
Praktik BBSR/L2 yang Dapat Ditumpuk Ekosistem Bitcoin
Deskripsi ini sejauh ini berasal dari sudut pandang Ethereum. Namun, sebagai praktik BBSR atau L2 yang dapat ditumpuk pertama di Bitcoin, Rooch memanfaatkan beberapa keuntungan unik.
L2 Bitcoin tidak memiliki kontrak pintar yang lengkap Turing, menjadikan model Based Rollup ideal, karena hanya membutuhkan DA yang tanpa izin. Proyek-proyek Bitcoin, seperti Colored Coins, RGB, Aset Taproot, dan Inscription Ordinals, telah lama mengadopsi protokol berbasis struktur data, cocok dengan kerangka kerja CSV (Client-Side Validation) yang luas dan mencontohkan transaksi L1.5 yang khas. Jika proyek Ethereum mengadopsi L2 Berdasarkan, protokol mereka mungkin terlihat mirip.
Dalam model BBSR berbasis Bitcoin dari Rooch:
1. Pengguna mengirimkan baik transaksi L1 maupun L1.5 ke Bitcoin.
2. Rooch menyinkronkan semua transaksi L1, memproses UTXO, mengidentifikasi transaksi dengan data protokol, dan mengeksekusinya dengan modul spesifik (misalnya, modul ord untuk transaksi Inscription).
3. Pengguna mengirimkan transaksi L2 langsung ke Sequencer Rooch, dengan hasil yang digabungkan menjadi pohon status lengkap yang dapat sepenuhnya dimanfaatkan oleh kontrak aplikasi.
Model ini mendukung dua jenis transaksi: transaksi protokol publik (Based, di L1) dan transaksi spesifik aplikasi (diurutkan oleh Sequencer), menggabungkan manfaat Booster dengan protokol tanpa izin dan peningkatan pengalaman pengguna.
Desain protokol publik, yang membutuhkan waktu dan praktik untuk memvalidasi dan mencapai konsensus, memiliki lingkungan pengujian yang nyaman dengan Rooch, di mana merancang protokol aplikasi Bitcoin semudah mendefinisikan format dan menerapkan kontrak Move yang sesuai.
Nilai L1 sebagai Bus Data Global
Sejak DeFi Summer, industri kripto telah mencari aplikasi non-DeFi. Kegilaan Inscription baru-baru ini dan diskusi tentang Based Rollup mengungkapkan penemuan kembali nilai L1 sebagai bus data. Dalam sistem terdesentralisasi, bus data memungkinkan pemisahan sistem—sebuah kondisi kunci untuk operasi tanpa izin. Aplikasi hanya perlu meningkatkan protokol transaksi menjadi transaksi spesifik aplikasi untuk dampak minimal pada sistem yang ada.
Artikel ini telah berfokus pada BBR dari perspektif ekosistem dan aplikasi. Nanti, kita akan menjelajahi keamanan BBR, interoperabilitas L1-L1.5-L2, dan topik terkait secara lebih mendetail.
