Cara menskalakan rollup aplikasi

Rollup aplikasi muncul sebagai pemenang dalam menskalakan serangkaian aplikasi Ethereum tertentu. Aplikasi ini mendapatkan keuntungan dari jaminan kepemilikan yang kuat dan tanpa izin, namun tidak memerlukan interaksi simultan antara semua pengguna aplikasi. Game yang sepenuhnya on-chain (FOG) adalah contoh terbaik yang sesuai dengan deskripsi ini. FOG mendapat manfaat dari kepemilikan aset dalam game yang kuat, partisipasi game tanpa izin, dan modding game tanpa izin. Namun, sebagian besar permainan tidak mengharuskan semua pemain berinteraksi satu sama lain pada saat yang sama. Aplikasi lain yang dapat memperoleh manfaat dari strategi penskalaan rollup aplikasi mencakup pasar NFT, pertukaran Perpetual, dan inferensi AI on-chain.

Rollup aplikasi sudah menjadi implementasi utama untuk banyak kasus penggunaan ini. Namun, penerapan rollup standar, yaitu rollup EVM, masih memiliki batasan skalabilitas yang penting. Mereka mungkin dapat mencapai throughput sekitar 100 transaksi per detik. Throughput tersebut mungkin cukup untuk beberapa game on-chain, bergantung pada jenis gamenya. Namun, sebagian besar game memerlukan throughput yang jauh lebih tinggi untuk mendukung sejumlah besar (> 1000) pemain secara bersamaan. Artikel ini berfokus pada pendekatan penskalaan rollup aplikasi untuk menjangkau ratusan ribu peserta secara bersamaan. Untuk setiap pendekatan, saya membahas jenis aplikasi/permainan yang sesuai dan tantangan yang dihadapinya.

Pembangun yang menggunakan rollup aplikasi atau mereka yang membangun infrastruktur untuk menskalakan rollup aplikasi disarankan untuk menghubungi saya dan mengajukan permohonan ke Alliance. Saya berharap dapat bekerja sama dengan para pendiri untuk membangun area ini.

Penskalaan Horisontal

Skalabilitas horizontal adalah pendekatan paling sederhana untuk menskalakan rollup aplikasi. Namun, kesederhanaan ini mengakibatkan hilangnya komposisi yang membuatnya hanya cocok untuk sejumlah kecil aplikasi seperti game pemain tunggal.

Skalabilitas horizontal berarti menerapkan beberapa rollup aplikasi (OP atau ZK) dengan kontrak pintar yang sama yang diterapkan ke semua rollup. Bagian depan aplikasi dengan mulus mengarahkan pengguna ke salah satu rollup bergantung pada kapasitas, lokasi, atau opsi aplikasi tertentu. Alt Layer baru-baru ini mendemonstrasikan konsep ini dengan meluncurkan FOCG 2048 yang terukur. Di frontend game, pengguna memiliki opsi untuk memilih rollup mana yang akan digabungkan berdasarkan lokasi geografis mereka. Karena kesederhanaan dan ketersediaan penyedia Rollup-as-a-service seperti Caldera yang menangani semua pekerjaan infrastruktur terkait pemintalan dan pengelolaan rollup ini, pendekatan ini dapat dengan mudah diadopsi oleh pengembang game.

Meskipun sederhana, ada beberapa masalah dalam pendekatan penskalaan multi-rollup. Yang pertama adalah peralihan jaringan rollup. Dompet saat ini, misalnya Metamask, memerlukan persetujuan manual untuk terhubung ke jaringan baru, misalnya rollup instance. Hal ini menyebabkan pengalaman pengguna yang sulit dan membingungkan bagi pemain yang perlu terhubung secara manual ke beberapa “jaringan” untuk memainkan game yang sama. Untungnya, kompleksitas ini dapat dihilangkan dengan solusi AA. Yaitu, EIP 4337, dan dompet tertanam seperti Privy dan 0xPass.

Tantangan lainnya adalah pengelolaan status pemain selama transisi antar rollup. Dalam beberapa kasus, misalnya penurunan kapasitas, aplikasi mungkin perlu menggabungkan beberapa instans rollup ke dalam satu instans untuk menghemat sumber daya. Dalam kasus seperti ini, semua status pemain aktif perlu dimigrasikan ke instance baru. Solusi penghubung yang ada saat ini, khususnya jembatan zk, dapat menjadi sangat penting dalam memecahkan masalah ini. Dengan menggunakan solusi ini, dimungkinkan untuk menjembatani status permainan pemain ke instance rollup baru sambil mempertahankan bukti validitas status ini. Namun, latensi solusi penghubung yang ada mungkin kurang optimal untuk kasus penggunaan game.

Saluran Negara Bagian ZK

Pendekatan penskalaan rollup aplikasi lain yang lebih cocok untuk game multipemain, misalnya Poker, adalah saluran zk state. Dalam permainan ini, interaksi pemain terjadi di antara sejumlah kecil pemain, misalnya 2–10. Permainan di antara para pemain ini hanya penting selama permainan sedang berlangsung. Namun hasil akhir permainan lebih penting karena mempengaruhi keseimbangan aset masing-masing pemain. Oleh karena itu, penting untuk menyimpan hasilnya dalam lapisan persisten bersama.

Dalam hal ini, rollup aplikasi mewakili lapisan informasi bersama tempat hasil game disimpan dan tempat aset game berada. Untuk setiap game dalam rollup, ZK State Channel dapat dimulai untuk menayangkan game ini. Selama bermain game, setiap pemain menghasilkan transaksi dan membuat ZKP yang membuktikan bahwa mereka telah mengikuti aturan permainan. Bukti dari interaksi pemain lain mengumpulkan bukti sebelumnya menggunakan pemeriksaan rekursif. Saat permainan berakhir, ZKP akhir diserahkan ke rollup aplikasi untuk membuktikan validitas permainan dan validitas hasil akhir. Perubahan status yang dihasilkan dari game mengubah status pemain pada rollup aplikasi.

Saluran negara bagian ZK memindahkan interaksi game ke luar rantai. Oleh karena itu, aktivitas dan transaksi dalam game tidak diperhitungkan dalam throughput rollup aplikasi. Dengan menggunakan pendekatan ini, rollup aplikasi dapat diperluas secara besar-besaran untuk mendukung puluhan atau ratusan ribu pemain secara bersamaan. Transaksi rollup aplikasi hanya berupa verifikasi ZKP yang dihasilkan dan transaksi pembaruan status yang menghasilkan faktor penskalaan 100–1000x. Beberapa tim termasuk Ontropy telah fokus pada pengembangan teknologi ini.

Kelemahan dari pendekatan ini adalah mengharuskan pemain menjalankan logika game dan menghasilkan ZKP di perangkat mereka. Seringkali pembuktian ini ringan dan dengan memanfaatkan sistem pembuktian canggih seperti Halo2, pembuktian dapat memakan waktu kurang dari beberapa detik. Namun, hal ini mungkin masih menyebabkan penurunan UX bagi pemain dengan perangkat dengan sumber daya terbatas.

Modifikasi pada pendekatan ini yang dapat mengatasi masalah ini adalah dengan menugaskan salah satu peserta saluran status zk sebagai sequencer sementara. Sequencer ini akan menerima transaksi setiap pemain dan menghasilkan ZKP yang sesuai serta membagikan ZKP tersebut kepada semua peserta saluran. Modifikasi ini dapat dianggap sebagai ZK L3 sementara yang menerima rollup aplikasi. Tim Cartridge telah menerapkan arsitektur ini dengan merancang sequencer khusus yang disebut Katana.

Pendekatan saluran zk state memiliki banyak potensi. Namun, ada beberapa pertanyaan terbuka terkait dengan lingkungan eksekusi di dalam saluran status zk dan cara mengoptimalkannya untuk rekursi bukti. Lingkungan zkEVM saat ini tidak terlalu efisien dan sebagian besar saat ini tidak mendukung rekursi bukti. Alternatifnya termasuk zkVM ringan atau bahkan menggunakan sirkuit zk khusus untuk interaksi pemain jika jumlah tindakan yang mungkin dilakukan pemain terbatas.

Mengubah Lingkungan Eksekusi

Pendekatan ketiga untuk skalabilitas rollup aplikasi adalah dengan mengubah lingkungan eksekusi rollup. Meskipun alat pengembang EVM sudah matang dan berlimpah, alat tersebut tidak cocok untuk aplikasi berperforma tinggi seperti game. Lebih lanjut, model eksekusi dan penyimpanan single-thread EVM menyebabkan berkurangnya throughput yang dapat ditingkatkan.

Keuntungan utama dari pendekatan ini adalah Meningkatkan throughput rollup tidak memerlukan pengorbanan komposisi atau membatasi jumlah kasus penggunaan. Pendekatan ini dapat bekerja untuk aplikasi Web 3 apa pun selama lingkungan eksekusi dapat mencapai throughput yang dibutuhkan oleh aplikasi tersebut. Hal ini menjadikannya satu-satunya solusi yang layak untuk aplikasi yang memerlukan akses ke status bersama seperti AMM, protokol peminjaman, dan aplikasi DeFi lainnya.

Memperluas fungsionalitas EVM melalui prakompilasi

Pendekatan pertama adalah agar rollup tetap kompatibel dengan EVM dan mengatasi beberapa keterbatasan throughput melalui prakompilasi. Idenya di sini sederhana. Prakompilasi hanyalah memindahkan operasi EVM yang mahal secara komputasi ke tingkat node. Operasi yang memerlukan ratusan atau ribuan OP EVM dan mengonsumsi 100 ribu+ gas dapat disederhanakan menjadi satu operasi dengan biaya bahan bakar 100x lebih rendah. Memperluas lingkungan rollup dengan prakompilasi sering disebut EVM+. Contoh pendekatan ini termasuk mendukung privasi on-chain dan mendukung skema tanda tangan yang lebih efisien, misalnya tanda tangan BLS. Misalnya, permainan poker zkHoldem menggunakan operasi FHE dan zk khusus untuk mencapai pembagian dan pengungkapan kartu poker pribadi. Pengembangan prakompilasi khusus ini sering kali merupakan upaya bersama antara pengembang rollup aplikasi dan penyedia Raas yang mengelola penerapan dan pemeliharaan infra rollup aplikasi.

Menggunakan lingkungan eksekusi non-EVM

Pendekatan lain untuk meningkatkan lingkungan eksekusi rollup adalah dengan melepaskan diri dari EVM. Pendekatan ini semakin populer di kalangan pengembang yang baru mengenal ekosistem Ethereum dan pengembang yang percaya bahwa Soliditas bukanlah bahasa terbaik untuk mengembangkan aplikasi yang kompleks.

Saat ini kami memiliki aplikasi rollup yang berjalan pada runtime WASM, SVM, Kairo, dan bahkan Linux. Sebagian besar pendekatan ini memungkinkan pengembang untuk menulis kontrak pintar mereka dalam bahasa tingkat tinggi seperti Rust atau C. Kelemahannya adalah interoperabilitas dengan kontrak Solidity yang ada sering kali hilang. Namun, kompatibilitas dengan EVM masih dapat dibuat. Misalnya, stylus Aributrum menggunakan co-prosesor untuk membuat kontrak Stylus kompatibel dengan EVM. Desain ini membawa Stylus lebih dekat ke arsitektur EVM+ dibandingkan non-EVM.

Lingkungan eksekusi hibrid

Pendekatan ketiga yang sangat populer dalam FOG adalah menggabungkan fitur terbaik dari dua pendekatan sebelumnya. Pendekatan ini menggabungkan kompatibilitas EVM dengan lingkungan eksekusi non-EVM khusus. Lingkungan non-EVM fokus pada eksekusi kinerja tinggi dari permainan inti primitif. Manajemen aset dalam game, misalnya, perdagangan NFT dalam game dapat ditangani dengan kontrak Soliditas standar.

Keuntungan dari pendekatan ini adalah kompatibilitas EVM memastikan keselarasan dengan ekosistem pengembang dan produk yang lebih besar. Hal ini juga memungkinkan komposisi tanpa izin. Pengembang dapat memodifikasi dan memperluas logika permainan dengan menambahkan kontrak pintar EVM/soliditas. Sementara itu, mesin permainan non-EVM khusus mencapai throughput tinggi yang tidak dapat dipenuhi oleh EVM.

Contoh pendekatan ini adalah World Engine dari Argus dan Keystone dari Curio. World Engine memisahkan eksekusi logika game ke dalam lapisan terpisah yang disebut Game Shard yang berjalan di atas lapisan yang kompatibel dengan EVM. Game Shard juga dirancang untuk memungkinkan penskalaan horizontal untuk menyesuaikan total throughput rollup berdasarkan permintaan. Demikian pula, arsitektur Keystone Curio menggabungkan mesin permainan throughput tinggi dengan EVM sebagai lingkungan eksekusi rollup. Tantangannya di sini adalah mencapai interoperabilitas yang lancar antara mesin EVM dan mesin game.

Pertimbangan Ketersediaan Data

Pada pembahasan sebelumnya, fokusnya adalah pada aspek utama penskalaan rollup aplikasi yaitu meningkatkan throughput transaksi rollup. Ada topik lain yang terkait dengan peningkatan throughput ini seperti Ketersediaan Data (DA), desentralisasi sequencer, dan kecepatan penyelesaian. Ketersediaan data adalah masalah yang paling mendesak untuk rollup aplikasi dengan throughput tinggi.

Rollup aplikasi tunggal berpotensi mencapai throughput melebihi 10 ribu tps. Menggunakan Ethereum sebagai lapisan DA untuk transaksi ini tidak dimungkinkan. Pertama, biaya rata-rata penerbitan data transfer L2 ETH sederhana di L1 dapat melebihi $0,10. Biaya ini terlalu tinggi untuk sebagian besar pembatalan aplikasi. Lebih penting lagi, L1 Ethereum saat ini tidak dapat mendukung lebih dari sekitar 8k TPS [1] untuk rollup yang menggunakan L1 untuk DA.

Batal aplikasi terutama akan bergantung pada solusi DA eksternal. Celestia dan EigenDA saat ini diposisikan sebagai opsi yang paling memungkinkan untuk rollup aplikasi. Misalnya, Eclipse berencana menggunakan Celestia untuk rollup berbasis SVM dengan throughput tinggi. Argus dan mesin game throughput tinggi juga berencana menggunakan Celestia pada awalnya. Demikian pula, EigenDA yang menjanjikan throughput data hingga 10 MB/detik dapat menjadi solusi yang layak untuk beberapa rollup aplikasi.

Namun mengintegrasikan Celestia atau EigneDA memiliki kelemahan utama yaitu kebocoran nilai ekonomi. Rollup aplikasi harus membayar biaya untuk lapisan DA selain biaya penyelesaian pada Ethereum L1. Biaya penyelesaian sangat penting untuk rollup aplikasi karena ini menyelaraskan keamanan rollup dengan keamanan Ethereum. Jaminan DA kurang penting terutama dalam konteks FOG dimana nilai transaksinya jauh lebih kecil. Selain itu, Celestia dan EigenDA menjanjikan biaya yang rendah karena jaringan ini masih baru dan pada awalnya memiliki pemanfaatan yang rendah. Ketika jaringan DA ini mencapai pemanfaatan yang tinggi, biaya DA juga bisa menjadi berlebihan. Menurut pendapat saya, rollup aplikasi sebaiknya menggunakan Komite Ketersediaan Data (DAC) sederhana untuk membuktikan ketersediaan data rollup[3] .

Sebagai kesimpulan, saya percaya bahwa rollup aplikasi adalah solusi terbaik yang ada untuk menskalakan aplikasi dengan throughput tinggi secara umum dan game on-chain secara spesifik. Menskalakan pembatalan aplikasi ini adalah kunci untuk mencapai adopsi arus utama yang melampaui pengguna kripto asli. Di Alliance, kami ingin mewujudkan visi ini dengan mendukung para pendiri yang membangun visi ini

Saya ingin mengucapkan terima kasih kepada Matt Katz, Kevin Zhang, Tarrence van As, dan Larry Liu atas masukan berharga mereka pada artikel ini.

[1] Mengasumsikan 50% dari batas gas blok Ethereum hanya untuk menyimpan data menggunakan data panggilan, ukuran tx rata-rata 10 byte. Waktu blok 12 detik

Penafian:

1. Artikel ini dicetak ulang dari [Aliansi]. Semua hak cipta milik penulis asli [Mohamed Fouda]. Jika ada keberatan terhadap cetak ulang ini, silakan menghubungi tim Gate Learn , dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini adalah sepenuhnya milik penulis dan bukan merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.