原标题: Bagaimana Saya Belajar Berhenti Khawatir & Menyukai Sharding
Tautan video:
Pembicara: Scott Sunarto (@smsunarto) pada Research Day
Pengeditan dan penyelesaian artikel: Justin Zhao (@hiCaptainZ)
Hai, saya Scott (@smsunarto), pendiri August Labs (@ArgusLabs_). Hari ini, saya akan berbicara tentang topik yang sudah lama tidak kita sentuh. Dengan roll-up menjadi arus utama saat ini, kami tidak membahas sharding eksekusi sebanyak yang kami lakukan tentang sharding data. Jadi, mari kita tinjau kembali topik yang agak terabaikan ini - sharding eksekusi.
Ini akan menjadi percakapan yang mudah. Saya tahu Anda telah mendengar konsep yang rumit sepanjang hari, jadi saya akan mencoba membuat diskusi ini sepraktis mungkin. Saya menyiapkan desain slide yang cocok untuk presentasi ini.
Bagi yang tidak mengenal saya, lucunya, saya dikenal di Twitter sebagai gadis anime. Saya juga merindukan kelulusan kuliah saya hanya untuk berada di sini, yang membuat orang tua saya kecewa. Saat ini, saya adalah pendiri Argus Labs. Kami melihat diri kami sebagai perusahaan game, bukan perusahaan infrastruktur atau cryptocurrency. Salah satu keluhan terbesar saya adalah semua orang di game crypto ingin membuat alat, tetapi tidak ada yang mau membuat konten atau aplikasi. Kami membutuhkan lebih banyak aplikasi yang benar-benar dapat digunakan pengguna.
Sebelumnya, saya membuat Dark Forest (@darkforest_eth) bersama teman pintar saya Brian Gu (@gubsheep) dan Alan Luo (@alanluo_0). Brian sekarang menjalankan 0xPARC (@0xPARC) dan dia jauh lebih pintar dari saya.
Pembahasan hari ini akan fokus pada melakukan sharding, tetapi dalam konteks kebanyakan orang tidak terbiasa membahas melakukan sharding. Kami biasanya membahas sharding eksekusi dalam konteks Lapisan 1, seperti sharding Ethereum atau sharding Dekat. Tapi hari ini, saya ingin sedikit mengubah konteksnya. Mari pikirkan seperti apa sharding di lingkungan roll-up.
Pertanyaan mendasar di sini adalah mengapa perusahaan game membuat roll-up sendiri, dan apa yang dapat kita pelajari dari World of Warcraft untuk merancang roll-up. Selain itu, kami akan menjelajahi bagaimana ruang desain untuk roll-up jauh melampaui realitas saat ini.
Untuk menjawab pertanyaan-pertanyaan ini, mari kita kembali ke tahun 2020, saat ide tentang Hutan Gelap pertama kali dikandung. Kami bertanya pada diri sendiri, bagaimana jika kami membuat game di mana setiap aksi game merupakan transaksi on-chain? Premisnya konyol saat itu, dan masih demikian bagi banyak orang saat ini. Tapi itu adalah hipotesis yang menarik, jadi kami membuatnya, dan Dark Forest lahir.
Dark Forest adalah game MMORTS eksplorasi ruang angkasa berantai penuh yang seluruhnya didasarkan pada Ethereum, ditenagai oleh ZK-Snarks. Dulu di tahun 2020, ZK belum sepopuler sekarang karena hampir tidak ada dokumentasi. Satu-satunya dokumentasi yang tersedia untuk Circom adalah Google Docs Jordi Baylina (@jbaylina). Terlepas dari tantangannya, kami belajar banyak selama ini, dan Dark Forest adalah perwujudan dari pembelajaran tersebut.
Dark Forest adalah eksperimen yang lebih besar dari yang kita duga. Kami memiliki lebih dari 10.000 pemain, triliunan gas dihabiskan, kekacauan dalam permainan, orang-orang menusuk rantai dari belakang. Hal yang paling menarik tentang Dark Forest dan game on-chain adalah sifat platformnya. Dengan memiliki game berantai penuh, Anda membuka pintu untuk merancang ruang bagi perilaku yang muncul, memungkinkan orang membuat kontrak pintar yang berinteraksi dengan game, serta klien alternatif dan mode game, seperti Dark Forest Arena dan penambang GPU.
Namun, dengan kekuatan besar datang tanggung jawab besar. Saat kami meluncurkan Dark Forest di xDai, sekarang dikenal sebagai Rantai Gnosis, kami akhirnya mengisi seluruh ruang blok rantai. Ini membuat rantai pada dasarnya tidak dapat digunakan untuk hal lain, termasuk DeFi, NFT, atau hal xDAI lainnya.
Jadi bagaimana sekarang? Sudahkah kita menemui jalan buntu? Akankah game rantai penuh tidak pernah menjadi kenyataan? Atau apakah kita akan kembali membuat game di mana hanya gambar JPEG kecil yang terhubung dan meyakinkan orang bahwa uang tumbuh di pohon? Jawabannya adalah, kami membiarkan perangkat lunak melakukan banyak hal. Banyak dari kita memiliki pandangan yang sangat kaku tentang blockchain dan roll-up, seolah-olah tidak ada banyak ruang untuk perbaikan. Tapi saya tidak setuju. Kita dapat bereksperimen dan menemukan kemungkinan baru.
Kami bertanya pada diri sendiri: jika kami merancang blockchain dari awal untuk game dan hanya game, akan seperti apa bentuknya? Kami membutuhkan throughput yang tinggi, jadi kami perlu menskalakan pembacaan dan penulisan. Sebagian besar blockchain dirancang untuk menulis-berat. Transaksi per detik (TPS) adalah metrik yang dibanggakan orang, tetapi kenyataannya, membaca sama pentingnya. Bagaimana Anda tahu di mana seorang pemain berada jika Anda tidak bisa membaca dari node blockchain? Ini sebenarnya hambatan pertama yang kami temukan dalam konstruksi blockchain.
Dark Forest memiliki masalah di mana node penuh banyak digunakan dan I/O meledak karena kita perlu membaca data dari status on-chain. Ini menghasilkan biaya server ribuan dolar, yang ditanggung dengan murah hati oleh tim xDAI. Namun, ini tidak ideal untuk jangka panjang. Kami membutuhkan throughput yang tinggi, tidak hanya untuk transaksi yang ditulis per detik, tetapi juga untuk membaca, seperti mengambil data dari blockchain itu sendiri.
Kami juga membutuhkan blockchain yang dapat diskalakan secara horizontal untuk menghindari masalah Tetangga Bising. Kami tidak ingin game populer tiba-tiba mogok di blockchain, menghentikan semua pekerjaan. Kami juga membutuhkan fleksibilitas dan kemampuan penyesuaian agar kami dapat memodifikasi state machine yang akan dirancang untuk game tersebut. Ini termasuk memiliki loop game, membuatnya dapat dieksekusi sendiri, dll.
Last but not least, bagi mereka yang tidak terbiasa dengan arsitektur game online, ini mungkin agak kabur, kita membutuhkan tick rate yang tinggi. Kutu adalah satuan atom waktu di dunia game. Dalam konteks blockchain, kami memiliki blok sebagai satuan waktu atom. Dalam permainan, kami memiliki kutu. Ini hampir serupa ketika Anda membuat game full-chain, di mana laju generasi tick atau blok dari blockchain Anda sama dengan tick dari game itu sendiri.
Oleh karena itu, yang kami butuhkan adalah blockchain dengan throughput tinggi, skalabilitas horizontal, fleksibilitas dan kustomisasi, serta tick rate yang tinggi. Desain seperti itu dapat memenuhi kebutuhan blockchain yang kami rancang dari awal untuk game tersebut.
Jika Anda memiliki tick rate yang lebih tinggi atau lebih banyak blok per detik, game akan terasa lebih responsif. Sebaliknya, jika tick rate Anda rendah, permainan akan terasa lamban. Satu hal penting yang perlu diingat adalah jika potongan ditunda, Anda akan mengalami kelambatan yang nyata dalam game. Ini adalah pengalaman yang buruk. Jika Anda pernah berurusan dengan pemain yang marah berteriak ke komputer karena kalah dalam permainan, itu adalah situasi yang sangat buruk.
Saat ini, rollup kami memiliki satu blok per detik, yang setara dengan satu centang. Jika kami ingin memiliki game yang lebih keren, kami membutuhkan tick rate yang lebih tinggi. Misalnya, Minecraft, game seni piksel sederhana, memiliki 26 tik per detik. Kami masih jauh dari membuat game yang responsif seperti Minecraft.
Solusi yang mungkin adalah menerapkan rollup kami sendiri. Meskipun tampaknya memperbaiki masalah, itu tidak benar-benar memperbaiki akar penyebab masalah. Misalnya, Anda akan memiliki throughput penulisan yang lebih tinggi, tetapi tidak cukup untuk level yang dibutuhkan game. Tentu saja, jika gim Anda memiliki seratus pemain, ini sudah cukup. Namun, jika Anda ingin membuat game yang membutuhkan throughput lebih tinggi, ada batasan yang sangat ketat karena cara I/O dilakukan pada build saat ini.
Di sisi baca, Anda tidak benar-benar mendapatkan peningkatan kinerja. Anda masih harus mengandalkan pengindeks. Anda tidak benar-benar memiliki skalabilitas horizontal. Jika Anda mencoba memulai rollup baru untuk menskalakan game secara horizontal, Anda akan menghancurkan ekosistem smart contract yang ada. Pasar yang diterapkan pemain tidak akan berfungsi dengan rantai lain yang Anda luncurkan untuk menskalakan game Anda secara horizontal. Ini menimbulkan banyak pertanyaan.
Akhirnya, tick rate yang tinggi dan blok per detik masih sedikit tantangan, meskipun kami dapat mendorongnya sekuat yang kami bisa, kami mungkin mendapatkan dua blok per detik, mungkin tiga, tetapi ini benar-benar cara kerja blockchain ini. paling jauh, karena ada banyak hal seperti menyusun ulang yang sangat bergantung pada siklus komputasi.
Untuk menjawab pertanyaan ini, kami melihat kembali ke awal tahun 2000-an dan akhir 1990-an, ketika game online seperti MMO baru saja muncul. Mereka memiliki konsep yang disebut sharding. Ini bukan konsep baru; itu sudah ada di masa lalu. Kata "sharding" yang kami gunakan dalam arsitektur database sebenarnya berasal dari referensi ke Ultima Online. Mereka adalah yang pertama menggunakan kata "pecahan" untuk menjelaskan server mereka yang berbeda.
Jadi, bagaimana cara kerja sharding dalam game? Ini bukan solusi satu ukuran untuk semua. Ini adalah alat di kotak alat, dan cara Anda menyesuaikannya dengan gim Anda akan berbeda dari satu kasus ke kasus lainnya. Misalnya, konstruksi sharding pertama adalah apa yang saya suka sebut sebagai sharding berbasis lokasi. Model mental yang baik adalah membayangkan sistem koordinat Cartesian yang dibagi menjadi empat kuadran, masing-masing dengan irisan permainannya sendiri. Setiap kali Anda ingin melintasi pecahan, Anda mengirim komunikasi ke pecahan lain yang mengatakan "hei, saya ingin pindah ke sana" dan Anda diteleportasi ke pecahan Anda, meninggalkan pemain sebelum Tubuh Anda. Dengan melakukan ini, Anda mendistribusikan beban kerja server ke beberapa contoh fisik, daripada memaksa satu server melakukan semua komputasi untuk seluruh dunia game. Konfigurasi kedua sekarang lebih populer. Ini disebut sharding multiverse, di mana Anda memiliki banyak instance game yang saling mencerminkan. Anda dapat memilih shard mana pun yang ingin Anda tuju, dan bebannya seimbang secara default sehingga setiap server tidak terlalu penuh.
Sekarang, pertanyaan kuncinya adalah, bagaimana Anda membawa konsep ini ke rollup? Itu sebabnya kami menciptakan World Engine. World Engine adalah infrastruktur andalan kami, pada dasarnya adalah penyortir pecahan yang dirancang untuk memulai. Desain kami berbeda dan lebih sesuai dengan kebutuhan kami daripada banyak desain penyortir pecahan yang telah kami lihat dalam beberapa diskusi sebelumnya. Arah optimalisasi kami adalah: A, throughput, B, kami ingin memastikan bahwa tidak ada kunci yang memblokir waktu berjalan untuk memastikan bahwa tingkat centang dan waktu blok seefisien mungkin, sehingga sinkron secara default, caranya kami merancang penyortir adalah penyortiran sebagian, daripada memaksa pemesanan total (setiap transaksi harus terjadi setelah yang lain).
Komponen utama di sini adalah kita memiliki dua hal utama. Kami memiliki sharding berbasis EVM, yang seperti rantai EVM murni, tempat pemain dapat menerapkan kontrak pintar, menggabungkan dengan game, membuat pasar dengan pajak, dan sebagainya. Ini seperti rantai biasa, bukan? Sesuatu seperti satu blok per detik atau sesuatu, cukup bagi Anda untuk melakukan semua perangkat dan pasar biasa.
Bahan rahasianya di sini adalah kami juga menggunakan shard game, yang pada dasarnya adalah mini-blockchain yang dirancang sebagai server game berperforma tinggi. Kami memiliki antarmuka implementasi bawa sendiri sehingga Anda dapat menyesuaikan shard ini sesuai keinginan Anda. Anda dapat membangun pecahan Anda sendiri dan menyuntikkannya ke pecahan dasar. Anda hanya perlu menerapkan satu set antarmuka standar, seperti Cosmos yang Anda kenal, Cosmos memiliki antarmuka ABC. Anda pada dasarnya dapat menyatukan ini menjadi spesifikasi yang serupa, membawa pecahan Anda sendiri ke dalam tumpukan Mesin Dunia.
Kuncinya di sini adalah kita memiliki tick rate yang tinggi yang saat ini tidak dapat kita capai dengan konstruksi sharding saat ini. Di sinilah saya ingin memperkenalkan Cardinal. Cardinal adalah implementasi sharding game pertama dari World Engine. Ini menggunakan Entity-Component-System (ECS) dengan arsitektur berorientasi data. Ini memungkinkan kami untuk memparalelkan game dan meningkatkan throughput perhitungan game. Ini memiliki tingkat centang yang dapat dikonfigurasi hingga 20 kutu per detik. Untuk orang-orang blockchain di sini, itu berarti 20 blok per detik.
Kami juga dapat melakukan geolokasi untuk mengurangi latensi. Misalnya, Anda mungkin memiliki penyortir di AS, lalu orang Asia harus menunggu 300 milidetik agar transaksi mencapai penyortir. Ini adalah masalah besar dalam game karena 300ms adalah waktu yang lama. Jika Anda mencoba memainkan game FPS dengan lag 200ms, pada dasarnya Anda sudah mati.
Poin kunci lain yang juga penting bagi kami adalah pengindeksan sendiri. Kami tidak lagi membutuhkan pengindeks eksternal. Kami tidak memerlukan kerangka kerja ini untuk meng-cache status game. Hal ini juga memungkinkan kami membuat lebih banyak game real-time tanpa masalah latensi karena pengindeks masih berusaha mengejar blok penyortir.
Kami juga memiliki sistem plugin yang memungkinkan orang memparalelkan validasi ZK, dll. Bagian terbaiknya, setidaknya bagi saya, adalah Anda dapat menulis kode Anda di Go. Tidak perlu lagi menggunakan Solidity untuk membuat game Anda berfungsi. Jika Anda pernah mencoba membuat game blockchain dengan Solidity, itu adalah mimpi buruk.
Namun, poin utama dari konstruksi pecahan kami adalah Anda dapat membangun apa saja sebagai pecahan. Mereka pada dasarnya seperti ruang desain tanpa batas, seperti pecahan.
Dengan asumsi Anda tidak suka menulis kode permainan Anda di Go, maka Anda dapat memilih cara lain. Namun, kami sedang mengerjakan shard game Solidity yang akan memungkinkan Anda mengimplementasikan game dalam Solidity dengan cara yang menawarkan kemungkinan pengkodean sambil tetap mempertahankan banyak manfaat Cardinal. Anda juga dapat membuat pecahan yang dicetak NFT dengan mempool unik dan konstruksi pemesanan, menyelesaikan masalah Tetangga Bising yang serupa dengan pencetakan dasar. Anda bahkan dapat membuat pecahan identitas game dan menggunakan NFT untuk merepresentasikan identitas game Anda, sehingga Anda dapat dengan mudah melakukan transaksi identitas game melalui NFT alih-alih berbagi kunci pribadi.
Ini adalah arsitektur tingkat tinggi, dan saya tidak akan membahas terlalu banyak detail mendalam hari ini karena keterbatasan waktu. Yang terpenting, kami mengizinkan kontrak pintar EVM untuk digabungkan dengan serpihan game menggunakan pick and pass khusus. Kami membuat pembungkus di sekitar Geth untuk memungkinkan komunikasi di antara keduanya, yang membuka banyak ruang desain di kedua arah. Kami sinkron secara default dan dapat beroperasi dengan lancar dan tersusun antara shard tanpa kunci.
Penyortir bersama kami berbeda karena tidak menggunakan konstruksi urutan bersama dari kumpulan atom yang memprioritaskan penyortiran global, yang memerlukan mekanisme penguncian dan menyebabkan masalah seperti pemblokiran utas utama, yang menyebabkan tingkat centang dan waktu pemblokiran yang tidak menentu, dan hasilnya adalah tertinggal dalam permainan. Itu juga memberlakukan batasan pada waktu blok per-pecahan dan membutuhkan berbagai kriptoekonomi dan konstruksi untuk mencegah penolakan layanan. Ada juga masalah besar yang belum saya lihat disebutkan di banyak konstruksi penyortir VCR: jika Anda memiliki pecahan berbeda yang bergantung satu sama lain dan menyebabkan kebuntuan, bagaimana Anda mengatasinya? Dengan desain asinkron, ini bukan masalah, karena semua orang melakukan apa yang ingin mereka lakukan, lalu melepaskannya.
Nyatanya, berkas atom dan roll-up melintasi pecahan biasanya tidak diperlukan. Untuk kasus penggunaan kami, kami tidak memerlukan apa pun yang memerlukan berkas atom, kami juga tidak berpikir itu adalah sesuatu yang harus kami rancang di sekitar kemurnian kasus penggunaan. Ini juga membawa banyak fitur menarik lainnya. Misalnya, setiap serpihan game dapat memiliki lapisan DA terpisah untuk rantai dasar. Misalnya, Anda dapat menggunakan shard dasar untuk mendorong data ke Ethereum, dan shard game dapat mendorong data ke Celestia (mirip dengan komite ketersediaan data). Anda juga dapat mengurangi persyaratan perangkat keras untuk menjalankan node penuh, karena Anda dapat menjalankan node penuh beling dasar Geth secara terpisah, tanpa menjalankan node beling game, yang memudahkan Anda untuk berintegrasi dengan hal-hal seperti Alkimia.
Singkatnya, saya ingin jujur di sini bahwa banyak orang mengharapkan konstruksi mereka untuk menyelesaikan semua masalah mereka, tetapi kami tidak melakukannya. Kami pikir konstruksi kami berfungsi untuk kami, tetapi mungkin tidak berfungsi untuk kasus penggunaan Anda. Tidak realistis untuk berasumsi bahwa konstruksi kami akan bekerja untuk semua orang. Bagi kami, ini sesuai dengan kebutuhan kami, menawarkan throughput yang tinggi, skalabilitas horizontal, fleksibilitas, dan tick rate yang tinggi, tetapi itu bukanlah obat untuk kanker. Jika Anda memerlukan protokol DeFi yang memerlukan kemampuan menyusun secara sinkron, konstruk ini mungkin bukan untuk Anda.
Secara umum, saya sangat percaya pada konsep arsitektur blockchain yang berpusat pada manusia. Dengan merancang seputar peran pengguna tertentu dan kasus penggunaan, Anda dapat melakukan pertukaran dengan lebih baik, daripada mencoba menyelesaikan masalah semua orang. Era renaisans telah tiba, dan setiap orang dapat merancang Roll-Up mereka sendiri untuk memenuhi kebutuhan khusus mereka sendiri, alih-alih mengandalkan solusi umum. Saya pikir kita harus menerima Ledakan Kambrium. Jangan membuat roll-up seperti layer satu dengan satu ukuran cocok untuk semua karena itu sama sekali tidak dirancang untuk menyelesaikan masalah yang sama. Saya pribadi menantikan untuk melihat lebih banyak orang menjelajahi lebih banyak ruang desain Roll-Up untuk kasus penggunaan. Misalnya, seperti apa Roll-Up yang dirancang khusus untuk pertukaran aset? Apakah itu akan didasarkan pada niat? Seperti apa Roll-Up yang dirancang khusus untuk CLOB on-chain (Central Limit Order Book)? Di sini, saya menyerahkan mic ke MJ. Terima kasih atas undangan Anda.
Versi bahasa Inggris:
Lihat Asli
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Mengapa Argus menggunakan sharding untuk membangun infrastruktur game full-chain?
原标题: Bagaimana Saya Belajar Berhenti Khawatir & Menyukai Sharding
Tautan video:
Pembicara: Scott Sunarto (@smsunarto) pada Research Day
Pengeditan dan penyelesaian artikel: Justin Zhao (@hiCaptainZ)
Hai, saya Scott (@smsunarto), pendiri August Labs (@ArgusLabs_). Hari ini, saya akan berbicara tentang topik yang sudah lama tidak kita sentuh. Dengan roll-up menjadi arus utama saat ini, kami tidak membahas sharding eksekusi sebanyak yang kami lakukan tentang sharding data. Jadi, mari kita tinjau kembali topik yang agak terabaikan ini - sharding eksekusi.
Ini akan menjadi percakapan yang mudah. Saya tahu Anda telah mendengar konsep yang rumit sepanjang hari, jadi saya akan mencoba membuat diskusi ini sepraktis mungkin. Saya menyiapkan desain slide yang cocok untuk presentasi ini.
Bagi yang tidak mengenal saya, lucunya, saya dikenal di Twitter sebagai gadis anime. Saya juga merindukan kelulusan kuliah saya hanya untuk berada di sini, yang membuat orang tua saya kecewa. Saat ini, saya adalah pendiri Argus Labs. Kami melihat diri kami sebagai perusahaan game, bukan perusahaan infrastruktur atau cryptocurrency. Salah satu keluhan terbesar saya adalah semua orang di game crypto ingin membuat alat, tetapi tidak ada yang mau membuat konten atau aplikasi. Kami membutuhkan lebih banyak aplikasi yang benar-benar dapat digunakan pengguna.
Sebelumnya, saya membuat Dark Forest (@darkforest_eth) bersama teman pintar saya Brian Gu (@gubsheep) dan Alan Luo (@alanluo_0). Brian sekarang menjalankan 0xPARC (@0xPARC) dan dia jauh lebih pintar dari saya.
Pembahasan hari ini akan fokus pada melakukan sharding, tetapi dalam konteks kebanyakan orang tidak terbiasa membahas melakukan sharding. Kami biasanya membahas sharding eksekusi dalam konteks Lapisan 1, seperti sharding Ethereum atau sharding Dekat. Tapi hari ini, saya ingin sedikit mengubah konteksnya. Mari pikirkan seperti apa sharding di lingkungan roll-up.
Pertanyaan mendasar di sini adalah mengapa perusahaan game membuat roll-up sendiri, dan apa yang dapat kita pelajari dari World of Warcraft untuk merancang roll-up. Selain itu, kami akan menjelajahi bagaimana ruang desain untuk roll-up jauh melampaui realitas saat ini.
Untuk menjawab pertanyaan-pertanyaan ini, mari kita kembali ke tahun 2020, saat ide tentang Hutan Gelap pertama kali dikandung. Kami bertanya pada diri sendiri, bagaimana jika kami membuat game di mana setiap aksi game merupakan transaksi on-chain? Premisnya konyol saat itu, dan masih demikian bagi banyak orang saat ini. Tapi itu adalah hipotesis yang menarik, jadi kami membuatnya, dan Dark Forest lahir.
Dark Forest adalah game MMORTS eksplorasi ruang angkasa berantai penuh yang seluruhnya didasarkan pada Ethereum, ditenagai oleh ZK-Snarks. Dulu di tahun 2020, ZK belum sepopuler sekarang karena hampir tidak ada dokumentasi. Satu-satunya dokumentasi yang tersedia untuk Circom adalah Google Docs Jordi Baylina (@jbaylina). Terlepas dari tantangannya, kami belajar banyak selama ini, dan Dark Forest adalah perwujudan dari pembelajaran tersebut.
Dark Forest adalah eksperimen yang lebih besar dari yang kita duga. Kami memiliki lebih dari 10.000 pemain, triliunan gas dihabiskan, kekacauan dalam permainan, orang-orang menusuk rantai dari belakang. Hal yang paling menarik tentang Dark Forest dan game on-chain adalah sifat platformnya. Dengan memiliki game berantai penuh, Anda membuka pintu untuk merancang ruang bagi perilaku yang muncul, memungkinkan orang membuat kontrak pintar yang berinteraksi dengan game, serta klien alternatif dan mode game, seperti Dark Forest Arena dan penambang GPU.
Namun, dengan kekuatan besar datang tanggung jawab besar. Saat kami meluncurkan Dark Forest di xDai, sekarang dikenal sebagai Rantai Gnosis, kami akhirnya mengisi seluruh ruang blok rantai. Ini membuat rantai pada dasarnya tidak dapat digunakan untuk hal lain, termasuk DeFi, NFT, atau hal xDAI lainnya.
Jadi bagaimana sekarang? Sudahkah kita menemui jalan buntu? Akankah game rantai penuh tidak pernah menjadi kenyataan? Atau apakah kita akan kembali membuat game di mana hanya gambar JPEG kecil yang terhubung dan meyakinkan orang bahwa uang tumbuh di pohon? Jawabannya adalah, kami membiarkan perangkat lunak melakukan banyak hal. Banyak dari kita memiliki pandangan yang sangat kaku tentang blockchain dan roll-up, seolah-olah tidak ada banyak ruang untuk perbaikan. Tapi saya tidak setuju. Kita dapat bereksperimen dan menemukan kemungkinan baru.
Kami bertanya pada diri sendiri: jika kami merancang blockchain dari awal untuk game dan hanya game, akan seperti apa bentuknya? Kami membutuhkan throughput yang tinggi, jadi kami perlu menskalakan pembacaan dan penulisan. Sebagian besar blockchain dirancang untuk menulis-berat. Transaksi per detik (TPS) adalah metrik yang dibanggakan orang, tetapi kenyataannya, membaca sama pentingnya. Bagaimana Anda tahu di mana seorang pemain berada jika Anda tidak bisa membaca dari node blockchain? Ini sebenarnya hambatan pertama yang kami temukan dalam konstruksi blockchain.
Dark Forest memiliki masalah di mana node penuh banyak digunakan dan I/O meledak karena kita perlu membaca data dari status on-chain. Ini menghasilkan biaya server ribuan dolar, yang ditanggung dengan murah hati oleh tim xDAI. Namun, ini tidak ideal untuk jangka panjang. Kami membutuhkan throughput yang tinggi, tidak hanya untuk transaksi yang ditulis per detik, tetapi juga untuk membaca, seperti mengambil data dari blockchain itu sendiri.
Kami juga membutuhkan blockchain yang dapat diskalakan secara horizontal untuk menghindari masalah Tetangga Bising. Kami tidak ingin game populer tiba-tiba mogok di blockchain, menghentikan semua pekerjaan. Kami juga membutuhkan fleksibilitas dan kemampuan penyesuaian agar kami dapat memodifikasi state machine yang akan dirancang untuk game tersebut. Ini termasuk memiliki loop game, membuatnya dapat dieksekusi sendiri, dll.
Last but not least, bagi mereka yang tidak terbiasa dengan arsitektur game online, ini mungkin agak kabur, kita membutuhkan tick rate yang tinggi. Kutu adalah satuan atom waktu di dunia game. Dalam konteks blockchain, kami memiliki blok sebagai satuan waktu atom. Dalam permainan, kami memiliki kutu. Ini hampir serupa ketika Anda membuat game full-chain, di mana laju generasi tick atau blok dari blockchain Anda sama dengan tick dari game itu sendiri.
Oleh karena itu, yang kami butuhkan adalah blockchain dengan throughput tinggi, skalabilitas horizontal, fleksibilitas dan kustomisasi, serta tick rate yang tinggi. Desain seperti itu dapat memenuhi kebutuhan blockchain yang kami rancang dari awal untuk game tersebut.
Jika Anda memiliki tick rate yang lebih tinggi atau lebih banyak blok per detik, game akan terasa lebih responsif. Sebaliknya, jika tick rate Anda rendah, permainan akan terasa lamban. Satu hal penting yang perlu diingat adalah jika potongan ditunda, Anda akan mengalami kelambatan yang nyata dalam game. Ini adalah pengalaman yang buruk. Jika Anda pernah berurusan dengan pemain yang marah berteriak ke komputer karena kalah dalam permainan, itu adalah situasi yang sangat buruk.
Saat ini, rollup kami memiliki satu blok per detik, yang setara dengan satu centang. Jika kami ingin memiliki game yang lebih keren, kami membutuhkan tick rate yang lebih tinggi. Misalnya, Minecraft, game seni piksel sederhana, memiliki 26 tik per detik. Kami masih jauh dari membuat game yang responsif seperti Minecraft.
Solusi yang mungkin adalah menerapkan rollup kami sendiri. Meskipun tampaknya memperbaiki masalah, itu tidak benar-benar memperbaiki akar penyebab masalah. Misalnya, Anda akan memiliki throughput penulisan yang lebih tinggi, tetapi tidak cukup untuk level yang dibutuhkan game. Tentu saja, jika gim Anda memiliki seratus pemain, ini sudah cukup. Namun, jika Anda ingin membuat game yang membutuhkan throughput lebih tinggi, ada batasan yang sangat ketat karena cara I/O dilakukan pada build saat ini.
Di sisi baca, Anda tidak benar-benar mendapatkan peningkatan kinerja. Anda masih harus mengandalkan pengindeks. Anda tidak benar-benar memiliki skalabilitas horizontal. Jika Anda mencoba memulai rollup baru untuk menskalakan game secara horizontal, Anda akan menghancurkan ekosistem smart contract yang ada. Pasar yang diterapkan pemain tidak akan berfungsi dengan rantai lain yang Anda luncurkan untuk menskalakan game Anda secara horizontal. Ini menimbulkan banyak pertanyaan.
Akhirnya, tick rate yang tinggi dan blok per detik masih sedikit tantangan, meskipun kami dapat mendorongnya sekuat yang kami bisa, kami mungkin mendapatkan dua blok per detik, mungkin tiga, tetapi ini benar-benar cara kerja blockchain ini. paling jauh, karena ada banyak hal seperti menyusun ulang yang sangat bergantung pada siklus komputasi.
Untuk menjawab pertanyaan ini, kami melihat kembali ke awal tahun 2000-an dan akhir 1990-an, ketika game online seperti MMO baru saja muncul. Mereka memiliki konsep yang disebut sharding. Ini bukan konsep baru; itu sudah ada di masa lalu. Kata "sharding" yang kami gunakan dalam arsitektur database sebenarnya berasal dari referensi ke Ultima Online. Mereka adalah yang pertama menggunakan kata "pecahan" untuk menjelaskan server mereka yang berbeda.
Jadi, bagaimana cara kerja sharding dalam game? Ini bukan solusi satu ukuran untuk semua. Ini adalah alat di kotak alat, dan cara Anda menyesuaikannya dengan gim Anda akan berbeda dari satu kasus ke kasus lainnya. Misalnya, konstruksi sharding pertama adalah apa yang saya suka sebut sebagai sharding berbasis lokasi. Model mental yang baik adalah membayangkan sistem koordinat Cartesian yang dibagi menjadi empat kuadran, masing-masing dengan irisan permainannya sendiri. Setiap kali Anda ingin melintasi pecahan, Anda mengirim komunikasi ke pecahan lain yang mengatakan "hei, saya ingin pindah ke sana" dan Anda diteleportasi ke pecahan Anda, meninggalkan pemain sebelum Tubuh Anda. Dengan melakukan ini, Anda mendistribusikan beban kerja server ke beberapa contoh fisik, daripada memaksa satu server melakukan semua komputasi untuk seluruh dunia game. Konfigurasi kedua sekarang lebih populer. Ini disebut sharding multiverse, di mana Anda memiliki banyak instance game yang saling mencerminkan. Anda dapat memilih shard mana pun yang ingin Anda tuju, dan bebannya seimbang secara default sehingga setiap server tidak terlalu penuh.
Sekarang, pertanyaan kuncinya adalah, bagaimana Anda membawa konsep ini ke rollup? Itu sebabnya kami menciptakan World Engine. World Engine adalah infrastruktur andalan kami, pada dasarnya adalah penyortir pecahan yang dirancang untuk memulai. Desain kami berbeda dan lebih sesuai dengan kebutuhan kami daripada banyak desain penyortir pecahan yang telah kami lihat dalam beberapa diskusi sebelumnya. Arah optimalisasi kami adalah: A, throughput, B, kami ingin memastikan bahwa tidak ada kunci yang memblokir waktu berjalan untuk memastikan bahwa tingkat centang dan waktu blok seefisien mungkin, sehingga sinkron secara default, caranya kami merancang penyortir adalah penyortiran sebagian, daripada memaksa pemesanan total (setiap transaksi harus terjadi setelah yang lain).
Komponen utama di sini adalah kita memiliki dua hal utama. Kami memiliki sharding berbasis EVM, yang seperti rantai EVM murni, tempat pemain dapat menerapkan kontrak pintar, menggabungkan dengan game, membuat pasar dengan pajak, dan sebagainya. Ini seperti rantai biasa, bukan? Sesuatu seperti satu blok per detik atau sesuatu, cukup bagi Anda untuk melakukan semua perangkat dan pasar biasa.
Bahan rahasianya di sini adalah kami juga menggunakan shard game, yang pada dasarnya adalah mini-blockchain yang dirancang sebagai server game berperforma tinggi. Kami memiliki antarmuka implementasi bawa sendiri sehingga Anda dapat menyesuaikan shard ini sesuai keinginan Anda. Anda dapat membangun pecahan Anda sendiri dan menyuntikkannya ke pecahan dasar. Anda hanya perlu menerapkan satu set antarmuka standar, seperti Cosmos yang Anda kenal, Cosmos memiliki antarmuka ABC. Anda pada dasarnya dapat menyatukan ini menjadi spesifikasi yang serupa, membawa pecahan Anda sendiri ke dalam tumpukan Mesin Dunia.
Kuncinya di sini adalah kita memiliki tick rate yang tinggi yang saat ini tidak dapat kita capai dengan konstruksi sharding saat ini. Di sinilah saya ingin memperkenalkan Cardinal. Cardinal adalah implementasi sharding game pertama dari World Engine. Ini menggunakan Entity-Component-System (ECS) dengan arsitektur berorientasi data. Ini memungkinkan kami untuk memparalelkan game dan meningkatkan throughput perhitungan game. Ini memiliki tingkat centang yang dapat dikonfigurasi hingga 20 kutu per detik. Untuk orang-orang blockchain di sini, itu berarti 20 blok per detik.
Kami juga dapat melakukan geolokasi untuk mengurangi latensi. Misalnya, Anda mungkin memiliki penyortir di AS, lalu orang Asia harus menunggu 300 milidetik agar transaksi mencapai penyortir. Ini adalah masalah besar dalam game karena 300ms adalah waktu yang lama. Jika Anda mencoba memainkan game FPS dengan lag 200ms, pada dasarnya Anda sudah mati.
Poin kunci lain yang juga penting bagi kami adalah pengindeksan sendiri. Kami tidak lagi membutuhkan pengindeks eksternal. Kami tidak memerlukan kerangka kerja ini untuk meng-cache status game. Hal ini juga memungkinkan kami membuat lebih banyak game real-time tanpa masalah latensi karena pengindeks masih berusaha mengejar blok penyortir.
Kami juga memiliki sistem plugin yang memungkinkan orang memparalelkan validasi ZK, dll. Bagian terbaiknya, setidaknya bagi saya, adalah Anda dapat menulis kode Anda di Go. Tidak perlu lagi menggunakan Solidity untuk membuat game Anda berfungsi. Jika Anda pernah mencoba membuat game blockchain dengan Solidity, itu adalah mimpi buruk.
Namun, poin utama dari konstruksi pecahan kami adalah Anda dapat membangun apa saja sebagai pecahan. Mereka pada dasarnya seperti ruang desain tanpa batas, seperti pecahan.
Dengan asumsi Anda tidak suka menulis kode permainan Anda di Go, maka Anda dapat memilih cara lain. Namun, kami sedang mengerjakan shard game Solidity yang akan memungkinkan Anda mengimplementasikan game dalam Solidity dengan cara yang menawarkan kemungkinan pengkodean sambil tetap mempertahankan banyak manfaat Cardinal. Anda juga dapat membuat pecahan yang dicetak NFT dengan mempool unik dan konstruksi pemesanan, menyelesaikan masalah Tetangga Bising yang serupa dengan pencetakan dasar. Anda bahkan dapat membuat pecahan identitas game dan menggunakan NFT untuk merepresentasikan identitas game Anda, sehingga Anda dapat dengan mudah melakukan transaksi identitas game melalui NFT alih-alih berbagi kunci pribadi.
Ini adalah arsitektur tingkat tinggi, dan saya tidak akan membahas terlalu banyak detail mendalam hari ini karena keterbatasan waktu. Yang terpenting, kami mengizinkan kontrak pintar EVM untuk digabungkan dengan serpihan game menggunakan pick and pass khusus. Kami membuat pembungkus di sekitar Geth untuk memungkinkan komunikasi di antara keduanya, yang membuka banyak ruang desain di kedua arah. Kami sinkron secara default dan dapat beroperasi dengan lancar dan tersusun antara shard tanpa kunci.
Penyortir bersama kami berbeda karena tidak menggunakan konstruksi urutan bersama dari kumpulan atom yang memprioritaskan penyortiran global, yang memerlukan mekanisme penguncian dan menyebabkan masalah seperti pemblokiran utas utama, yang menyebabkan tingkat centang dan waktu pemblokiran yang tidak menentu, dan hasilnya adalah tertinggal dalam permainan. Itu juga memberlakukan batasan pada waktu blok per-pecahan dan membutuhkan berbagai kriptoekonomi dan konstruksi untuk mencegah penolakan layanan. Ada juga masalah besar yang belum saya lihat disebutkan di banyak konstruksi penyortir VCR: jika Anda memiliki pecahan berbeda yang bergantung satu sama lain dan menyebabkan kebuntuan, bagaimana Anda mengatasinya? Dengan desain asinkron, ini bukan masalah, karena semua orang melakukan apa yang ingin mereka lakukan, lalu melepaskannya.
Nyatanya, berkas atom dan roll-up melintasi pecahan biasanya tidak diperlukan. Untuk kasus penggunaan kami, kami tidak memerlukan apa pun yang memerlukan berkas atom, kami juga tidak berpikir itu adalah sesuatu yang harus kami rancang di sekitar kemurnian kasus penggunaan. Ini juga membawa banyak fitur menarik lainnya. Misalnya, setiap serpihan game dapat memiliki lapisan DA terpisah untuk rantai dasar. Misalnya, Anda dapat menggunakan shard dasar untuk mendorong data ke Ethereum, dan shard game dapat mendorong data ke Celestia (mirip dengan komite ketersediaan data). Anda juga dapat mengurangi persyaratan perangkat keras untuk menjalankan node penuh, karena Anda dapat menjalankan node penuh beling dasar Geth secara terpisah, tanpa menjalankan node beling game, yang memudahkan Anda untuk berintegrasi dengan hal-hal seperti Alkimia.
Singkatnya, saya ingin jujur di sini bahwa banyak orang mengharapkan konstruksi mereka untuk menyelesaikan semua masalah mereka, tetapi kami tidak melakukannya. Kami pikir konstruksi kami berfungsi untuk kami, tetapi mungkin tidak berfungsi untuk kasus penggunaan Anda. Tidak realistis untuk berasumsi bahwa konstruksi kami akan bekerja untuk semua orang. Bagi kami, ini sesuai dengan kebutuhan kami, menawarkan throughput yang tinggi, skalabilitas horizontal, fleksibilitas, dan tick rate yang tinggi, tetapi itu bukanlah obat untuk kanker. Jika Anda memerlukan protokol DeFi yang memerlukan kemampuan menyusun secara sinkron, konstruk ini mungkin bukan untuk Anda.
Secara umum, saya sangat percaya pada konsep arsitektur blockchain yang berpusat pada manusia. Dengan merancang seputar peran pengguna tertentu dan kasus penggunaan, Anda dapat melakukan pertukaran dengan lebih baik, daripada mencoba menyelesaikan masalah semua orang. Era renaisans telah tiba, dan setiap orang dapat merancang Roll-Up mereka sendiri untuk memenuhi kebutuhan khusus mereka sendiri, alih-alih mengandalkan solusi umum. Saya pikir kita harus menerima Ledakan Kambrium. Jangan membuat roll-up seperti layer satu dengan satu ukuran cocok untuk semua karena itu sama sekali tidak dirancang untuk menyelesaikan masalah yang sama. Saya pribadi menantikan untuk melihat lebih banyak orang menjelajahi lebih banyak ruang desain Roll-Up untuk kasus penggunaan. Misalnya, seperti apa Roll-Up yang dirancang khusus untuk pertukaran aset? Apakah itu akan didasarkan pada niat? Seperti apa Roll-Up yang dirancang khusus untuk CLOB on-chain (Central Limit Order Book)? Di sini, saya menyerahkan mic ke MJ. Terima kasih atas undangan Anda.
Versi bahasa Inggris: