Haruskah Anda menggunakan Redstone untuk game onchain berikutnya?

Tim Lattice baru-baru ini mengumumkan Redstone - L2 baru mereka yang dibuat menggunakan kontribusi baru mereka pada OP Stack (tumpukan yang menggerakkan Optimism L2).

Oleh karena itu, pertanyaan yang ada di benak setiap orang adalah, “Haruskah game onchain dibangun di L2 ini, dan bagaimana perbandingannya dengan alternatif?”. Banyak yang telah menghubungi tim kami di Paima Studios untuk meminta pendapat kami mengingat kami adalah salah satu pembuat game onchain terbaik dengan permainan langsung di banyak rantai, jadi kami akan melakukan yang terbaik untuk menyelami nuansanya.

CATATAN

Pada saat penulisan, Redstone baru saja diumumkan. Web3 adalah ruang yang bergerak sangat cepat, jadi kami mendorong Anda untuk membaca postingan blog ini dengan pikiran terbuka terhadap Redstone karena mereka pasti akan mengumumkan lebih banyak tentang karya mereka.

Untuk memahami Redstone dan alasan keberadaannya, Anda harus terlebih dahulu memahami perbandingannya dengan alternatif lain yang secara aktif digunakan di pasar dan kelebihannya. Khususnya, dalam postingan blog ini, kami akan fokus untuk memberi Anda model mental yang benar sehingga Anda dapat memahami apa yang diusulkan Redstone, apa pun yang mereka umumkan selanjutnya.

Di mana semuanya​dimulai​

Jadi, Anda ingin membuat game onchain? Mengingat Redstone adalah Ethereum L2, kami berasumsi Anda sudah memutuskan untuk memanfaatkan Ethereum.

Jadi, mengapa Anda tidak bisa men-deploy game Anda ke Ethereum secara langsung? Anda mungkin mengetahuinya karena biayanya terlalu mahal (lebih dari >$1 per gerakan game pada saat penulisan), namun tahukah Anda mengapa biayanya terlalu mahal? Ternyata ada dua biaya utama: biaya eksekusi, dan biaya penyimpanan data - keduanya sangat mahal untuk sebuah game. Namun, sama seperti CPU yang lebih mahal dibandingkan harddisk, biaya eksekusi jauh lebih tinggi dibandingkan biaya penyimpanan. Lalu bagaimana jika kita dapat menemukan cara untuk mengubah biaya eksekusi menjadi biaya penyimpanan? Kabar baik: rollup melakukan hal ini.

Rollup sebagai​solusi​penskalaan

Rollup hadir dalam berbagai bentuk, masing-masing mengubah biaya eksekusi menjadi biaya penyimpanan dengan caranya sendiri:

1. Rollup optimis: jalankan perhitungan offchain, lalu simpan semua data yang diperlukan untuk menjalankan fungsi (hanya data, tanpa eksekusi) bersama dengan nilai hasil yang dihitung secara lokal. Hanya jalankan eksekusi jika seseorang yakin hasil yang Anda posting salah (“bukti penipuan”). \
   Contoh populer: Arbitrum, Optimisme
2. Rollup ZK: jalankan perhitungan offchain, lalu simpan semua data yang diperlukan untuk menjalankan fungsi (hanya data, tanpa eksekusi) bersama dengan bukti hasil ZK yang dihitung secara lokal. \
   Contoh populer: Sinkronisasi ZK, Starknet, Polygon zkEVM
3. Sovereign rollup: menjalankan penghitungan offchain, lalu menyimpan semua data yang diperlukan untuk menjalankan fungsi (hanya data, tanpa eksekusi). \
   Contoh populer: Rollkit, Mesin Paima

Memanfaatkan solusi ini akan menurunkan biaya transaksi game Anda menjadi sekitar $0,05 (lihat biaya l2 untuk nilai terkini), yang tentunya merupakan langkah besar ke arah yang benar.

Mengurangi biaya​L2​

Jelasnya, mengurangi biaya L2 ini adalah kunci kesuksesan game. Meskipun rollup pastinya semakin murah (komputer menjadi lebih baik, teknologi ZK menjadi lebih baik, dll.), biaya utamanya bukanlah menjalankan komputasi offchain, melainkan biaya posting data ke L1.

Untuk mengatasi hal ini, Ethereum akan memperkenalkan cara baru untuk menyimpan data yang jauh lebih murah (disebut EIP4844) di mana data hanya disimpan sementara (dalam praktiknya, ~2 minggu sehingga cukup lama untuk memposting bukti penipuan dan agar data dapat direplikasi oleh node di seluruh dunia).

EIP4844 hadir dengan beberapa kelemahan:

• Data hanya bersifat sementara (Anda perlu mencari solusi penyimpanan lain agar data tetap dihosting setelahnya)
• Data terbatas, dibatasi sekitar 2 MiB per blok (dibagikan di antara semua rollup di Ethereum)

Jadi seperti yang Anda lihat, meskipun upaya sedang dilakukan untuk menurunkan biaya, upaya tersebut tidak akan cukup untuk membuat game onchain layak dilakukan di L2 mengingat terus meningkatnya minat terhadap ruang blockchain (kecepatan adopsi lebih cepat daripada kecepatan inovasi teknis )

Alternatif #1: Simpan data di server terpusat (atau kumpulan server )

Salah satu alternatif untuk menjaga biaya tetap rendah adalah dengan menyimpan data di server terpusat yang dipercaya orang untuk Anda operasikan, dan hanya memposting hash data secara onchain. Varian dari ide ini adalah dengan menggunakan sekelompok mesin yang dioperasikan secara independen yang digabungkan sebagai multisig. Skema seperti ini disebut “Komite Ketersediaan Data” (DAC) dan inilah yang digunakan oleh Arbitrum Nova, Arbitrum Orbit, dan Polygon CDK.

Skema ini jauh lebih murah ($0,001/tx untuk Arbitrum Nova jika Anda mengabaikan pasar biaya) sebagai imbalan atas jaringan yang lebih terpusat. Risiko utamanya adalah jika DAC berhenti menghosting data (misal: mereka memposting hash dan tidak pernah membagikan data untuk hash tersebut), jaringan akan terhenti.

Catatan khusus tentang​Arbitrum​

Anda mungkin penasaran mengapa Arbitrum muncul dua kali dalam daftar. Arbitrum menyediakan 3 penawaran utama saat ini:

• Arbitrum One (jaringan Arbitrum utama yang merupakan rollup penuh dengan data di Ethereum)
• Arbitrum Nova (L2 yang menggunakan DAC)
• Arbitrum Orbit (tumpukan untuk membuat L3 untuk Arbitrum One)

Seperti yang Anda lihat, masalah dengan Nova adalah tidak ada cara yang baik untuk memanfaatkan DeFi untuk game Anda (pengguna harus membuka (Nova -> ETH L1 -> One) dan menghabiskan banyak bahan bakar hanya untuk menjembatani), sedangkan tumpukan Orbit baru memungkinkan Anda pergi dengan mudah (Orbit -> One). Selain itu, karena Orbit adalah tumpukan untuk membuat L3, Anda dapat menggunakan L3 yang sudah ada seperti Xai Games yang mendukung DAC-nya sendiri, atau memutar L3 Anda sendiri (walaupun jika Anda memiliki L3 khusus game yang satu-satunya koneksi ke Ethereum kadang-kadang diposkan hash, Anda mungkin lebih baik menggunakan web2.5)

Alternatif #2: Simpan data di​jaringan​terdesentralisasi lainnya

Daripada menunggu EIP4844 diimplementasikan dengan bandwidth terbatas di mainnet, proyek lain seperti Celestia, Avail, dan EigenDA telah memutuskan untuk menerapkan konsep serupa sebagai rantai terpisah (disebut lapisan Ketersediaan Data (“DA”)), dan dengan fokus murni pada dalam kasus penggunaan ini, mereka juga menawarkan batas data yang lebih tinggi daripada yang didukung oleh paket mainnet Ethereum. Platform ini tidak mendukung kontrak pintar, dan dimaksudkan untuk digunakan semata-mata sebagai lapisan data untuk L2.

Khususnya, dimungkinkan untuk membuat OP Stack dengan data tentang Celestia serta Arbitrum Orbit dengan data tentang Celestia juga. Hal ini disertai dengan beberapa trade-off:

1. Memercayai. Rollup Anda sekarang bergantung pada lapisan DA untuk keamanan di atas Ethereum (tetapi bisa dibilang lebih baik daripada DAC)
2. Biaya. Rollup Anda sekarang harus membayar jaringan DA untuk keamanannya (yang harus Anda bayar dalam token asli lapisan DA)
3. Kecepatan. Waktu blok Celestia adalah 15 detik, dan waktu blok Avail adalah 20 detik. Misalnya, data harus diselesaikan ke Celestia sebelum dapat dijembatani ke EVM dengan kontrak blobstream Celestia. Ambillah poin ini dengan hati-hati, karena semua L2 secara umum meniru waktu blok yang lebih cepat daripada yang dapat diberikan oleh Ethereum (mengingat waktu blok Ethereum hanya 15 detik meskipun Arbitrum menggunakan waktu blok lebih cepat dari ini).

Pengaturan seperti ini terutama digunakan oleh Mantle (OP Stack + EigenLayer DA) dan Manta Pacific (OP Stack + Celestia). Biaya untuk hal ini masih harus dilihat, namun tim Celestia mengklaim sekitar $0,001, yang berarti biaya penyimpanan pada lapisan DA (relatif terhadap biaya eksekusi dari pasar biaya di sisi EVM) adalah minimal.

Alternatif #3: Simpan data dalam DAC yang dapat​ditantang​

Terakhir, kita bisa membicarakan tentang apa yang ditawarkan Redstone. Jika Anda tidak menyukai pengorbanan dalam menyimpan data pada lapisan DA, namun tidak menyukai sentralisasi DAC, Anda dapat membangun DAC di mana Anda dapat menghukum komite secara finansial jika mereka tidak menyediakan datanya. .

Untuk membantu memahami maksudnya, mari kita lihat alur cara kerja protokol DAC:

Cara menulis​data​

1. Sequencer untuk Redstone menerima transaksi Anda
2. Sequencer mengirimkan data ke DAC untuk disimpan
3. DAC mengembalikan pengakuan bahwa data disimpan
4. Sequencer memposting hash data ke L1

Cara membaca​data​

1. Sinkronkan rantai Ethereum untuk mencari hash yang dikirimkan ke kontrak rollup
2. Kueri data untuk hash dari DAC
3. Hitung keadaan L2 berdasarkan data ini

Jadi apa yang​diubah​Redstone?

Saat membaca data, jika data tidak tersedia, Anda dapat menantang DAC dengan mengklaim DAC tidak menyediakan data (alias data tidak dapat diunduh dari server mereka).

Untuk memberikan insentif yang tepat kepada semua orang agar jujur, kami menyiapkan aturan pemotongan berikut:

1. Jika penantang tidak jujur (data benar-benar tersedia), mereka akan dipotong (jika tidak, Anda dapat menyerang jaringan secara finansial dengan menantang setiap blok)
2. Jika DCA tidak jujur (data tidak tersedia), DCA akan dipotong.

Tampaknya ini merupakan solusi sederhana, namun kesulitannya adalah mencari tahu siapa yang salah jika terjadi masalah. Pikirkan skenario berikut:

1. Sequencer memposting hash tanpa membagikan data sebenarnya
2. Seseorang menantang sequencer
3. Sequencer, melihat tantangan, dan membuat data tersedia

Jika Anda adalah pengamat luar yang tidak memantau rantai secara realtime, datanya terlihat tersedia (jika Anda menanyakan DAC setelah kejadian, Anda mendapatkan data seperti yang diharapkan), jadi sepertinya penantangnya berbohong meskipun mereka tidak.

Jika solusi Anda untuk masalah ini adalah dengan berasumsi bahwa sequencer tidak akan pernah berbohong hanya untuk sebuah game, mengapa tidak menggunakan DAC standar saja. Selain itu, dengan asumsi sequencer tersebut jujur tidak cocok dengan konsep “superchain” sequencer bersama, yang berarti aset tidak dapat menggunakan sequencer bersama untuk ditransfer antar rantai OP Stack (sehingga Anda mengalami masalah yang sama seperti Arbitrum Nova kecuali Redstone dikerahkan sebagai L3)

Bagaimana tim Lattice berencana menangani hal ini akan menjadi poin penting yang harus diwaspadai seiring dengan tersedianya lebih banyak dokumentasi dan informasi peta jalan.

Alternatif #4: Gunakan​ZK​

Perhatikan bahwa masalah data tidak dibagikan (serangan pemotongan data) yang memengaruhi Redstone tidak hanya terjadi pada rollup Optimis. ZK Rollup yang datanya disimpan di luar rantai (disebut “Validium”) mengalami masalah yang sama, itulah sebabnya orang umumnya lebih tertarik pada rollup (yang memposting semua data ke dalam rantai).

Oleh karena itu, rollup ZK, secara umum, tidak akan membantu Anda mengurangi biaya data game Anda dengan aman. Mereka pasti dapat membantu menskalakan game Anda dengan banyak cara lain (memindahkan lebih banyak komputasi ke mesin lokal pengguna, menggunakan bukti rekursif untuk mengumpulkan banyak interaksi bersama-sama baik gaya rollup atau gaya saluran negara, dll.), tapi itu adalah topik untuk a posting masa depan.

Bagaimana saya bisa membuat biaya game saya lebih rendah lagi jika Soliditas sendirilah masalahnya ?

Seluruh postingan blog ini telah kita bahas tentang cara menangani biaya penyimpanan. Namun, beberapa game mungkin memiliki CPU terbatas (meskipun dijalankan dalam rantai EVM terpusat, game tersebut beroperasi). Jika ini adalah Anda, Anda mungkin tertarik menggunakan Sovereign Rollup untuk memungkinkan Anda menskalakan game melampaui batas EVM menggunakan Paima Engine.

Paima Engine memungkinkan pembuatan mesin status khusus aplikasi dalam Javascript yang dapat Anda terapkan ke rantai EVM pilihan Anda (termasuk Redstone!). Rollup kedaulatan ini dapat mengakses informasi EVM (termasuk data mesin MUD), sehingga dapat berfungsi sebagai cara terbaik untuk membuat bagian mana pun dari game Anda berjalan lebih cepat dan lebih murah.

​Kesimpulan​

Kesimpulannya, mengurangi biaya data adalah langkah paling penting untuk menurunkan biaya game onchain. Ada banyak solusi berbeda dengan trade-off berbeda yang ada saat ini, dan Redstone menyatakan dirinya lebih aman daripada DAC standar, namun masih harus dilihat apakah ini lebih aman, dan apakah perbedaannya cukup berarti untuk menjadi alternatif yang layak. ke solusi yang didukung lapisan DA. Untuk proyek yang perlu menskalakan komputasi selain data, solusi seperti Paima Engine hadir untuk mengatasi masalah tersebut.

Sebagai penafian terakhir, ingatlah bahwa detail Redstone belum diumumkan sepenuhnya. Postingan blog ini akan memberi Anda model mental yang tepat untuk memahami pengumuman mereka di masa depan, jadi mari kita berpikiran terbuka dan melihat apa yang mereka usulkan ke depan.

​Studio​Paima

Paima Studios, didirikan pada April 2022, adalah pengembang inti Paima Engine: mesin Web3 yang dibuat menggunakan teknologi lapisan 2 baru yang memungkinkan pembuatan game onchain, gamifikasi, dan dunia otonom. Paima Engine adalah cara yang aman dan mudah untuk memasuki Web3 karena dapat digunakan dengan keterampilan Web2 dan tidak memaparkan pengguna atau pengembang terhadap risiko dan peretasan Web3 yang umum.

• Basis kode Mesin Paima: https://github.com/PaimaStudios/paima-engine
• Dokumentasi Paima: https://docs.paimastudios.com/
• Templat Paima: https://github.com/PaimaStudios/paima-game-templates
• Paket NPM Paima: <a href="https://www.npmjs.com/package/@paima/sdk""> https://www.npmjs.com/package/@paima/sdk

Anda juga dapat mempelajari lebih lanjut dari media sosial kami:

• Youtube: <a href="https://www.youtube.com/@paimastudios""> https://www.youtube.com/@paimastudios
• Perselisihan: http://discord.gg/jZ59ArVaxv
• Reddit: https://reddit.com/r/paima
• Twitter: https://twitter.com/PaimaStudios

Ingin bekerja sama? Jangan ragu untuk menghubungi kami melalui halaman kontak kami: https://paimastudios.com/contact/

Penafian:

1. Artikel ini dicetak ulang dari [blog.paimastudios]. Semua hak cipta milik penulis asli [paimastudios]. 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.