原标题: Endişelenmeyi ve Sevgiyi Paylaşmayı Durdurmayı Nasıl Öğrendim?
Video bağlantısı:
Konuşmacı: Araştırma Günü'nde Scott Sunarto (@smsunarto)
Makale düzenleme ve bitirme: Justin Zhao (@hiCaptainZ)
Merhaba, ben Scott (@smsunarto), August Labs'ın (@ArgusLabs_) kurucusu. Bugün uzun zamandır değinmediğimiz bir konudan bahsedeceğim. Özetlemelerin zamanın ana akımı haline gelmesiyle, yürütme parçalamayı veri parçalama kadar tartışmıyoruz. Öyleyse, biraz ihmal edilmiş olan bu konuyu yeniden ele alalım - yürütme parçalama.
Bu kolay bir konuşma olacak. Bütün gün karmaşık kavramlar duyduğunu biliyorum, bu yüzden bu tartışmayı mümkün olduğunca pratik hale getirmeye çalışacağım. Bu sunuma uygun bir slayt tasarımı hazırladım.
Beni tanımayanlar için komik olan şu ki Twitter'da bir anime kızı olarak tanınıyorum. Sırf burada olmak için üniversite mezuniyetimi de kaçırdım, ailemi dehşete düşürerek. Şu anda Argus Labs'ın kurucusuyum. Kendimizi bir altyapı veya kripto para şirketi olarak değil, bir oyun şirketi olarak görüyoruz. En büyük sinirlerimden biri, kripto oyunlarındaki herkesin araçlar oluşturmak istemesi, ancak kimsenin içerik veya uygulama oluşturmak istememesi. Kullanıcıların gerçekten kullanabileceği daha fazla uygulamaya ihtiyacımız var.
Daha önce, akıllı arkadaşlarım Brian Gu (@gubsheep) ve Alan Luo (@alanluo_0) ile Dark Forest'ı (@darkforest_eth) birlikte yarattım. Brian şu anda 0xPARC (@0xPARC) kullanıyor ve benden çok daha akıllı.
Bugünün tartışması parçalama gerçekleştirmeye odaklanacak, ancak bir bağlamda çoğu insan parçalama gerçekleştirme tartışmasına aşina değil. Yürütme parçalamayı genellikle Katman 1 bağlamında, örneğin Ethereum parçalama veya Near parçalama gibi tartışırız. Ama bugün, içeriği biraz değiştirmek istiyorum. Toplama ortamında parçalamanın nasıl görüneceğini düşünelim.
Buradaki temel soru, bir oyun şirketinin neden kendi roll-up'ını oluşturması gerektiği ve World of Warcraft'tan roll-up'ları tasarlamak için ne öğrenebileceğimizdir. Ek olarak, roll-up'lar için tasarım alanının mevcut gerçeklerin çok ötesine nasıl geçtiğini keşfedeceğiz.
Bu soruları cevaplamak için Karanlık Orman fikrinin ilk ortaya çıktığı 2020 yılına geri dönelim. Kendimize, her oyun eyleminin zincirleme bir işlem olduğu bir oyun yaratırsak ne olur diye sorduk. Önerme o zamanlar saçmaydı ve bugün hala birçok insan için öyle. Ama ilginç bir hipotezdi, biz de onu kurduk ve Karanlık Orman doğdu.
Dark Forest, tamamen Ethereum tabanlı, ZK-Snarks tarafından desteklenen, tam zincirli bir uzay keşfi MMORTS oyunudur. 2020'de ZK bugünkü kadar popüler değildi çünkü neredeyse hiç belge yoktu. Circom için mevcut tek belge Jordi Baylina'nın (@jbaylina) Google Dokümanlarıdır. Zorluklara rağmen yol boyunca çok şey öğrendik ve Dark Forest bu öğrendiklerimizin vücut bulmuş hali.
Dark Forest düşündüğümüzden daha büyük bir deney. 10.000'den fazla oyuncumuz, harcanan trilyonlarca benzinimiz, oyunda kaosumuz, zincirin sırtından bıçaklayan insanlar var. Dark Forest ve on-chain oyunlarıyla ilgili en büyüleyici şey, platform oluşturma doğasıdır. Tam zincirli bir oyuna sahip olarak, ortaya çıkan davranışlar için bir tasarım alanının kapısını açarsınız ve insanların oyunla etkileşime giren akıllı sözleşmelerin yanı sıra alternatif istemciler ve Dark Forest Arena ve GPU madencileri gibi oyun modları oluşturmasına olanak tanırsınız.
Ancak, büyük güç büyük sorumluluk getirir. Artık Gnosis Zinciri olarak bilinen xDai'de Dark Forest'ı başlattığımızda, zincirin tüm blok alanını doldurduk. Bu, zinciri temelde DeFi, NFT'ler veya başka herhangi bir xDAI şeyi dahil olmak üzere başka herhangi bir şey için kullanılamaz hale getirir.
Peki şimdi ne olacak? Bir çıkmaza mı girdik? Tam zincirli oyunlar asla gerçek olmayacak mı? Yoksa sadece küçük JPEG resimlerin zincirde olduğu oyunlar yapmaya geri dönüp insanları paranın ağaçta yetiştiğine ikna mı edeceğiz? Cevap şu ki, yazılımın bir şeyler yapmasına izin veriyoruz. Birçoğumuz, sanki iyileştirme için fazla yer yokmuş gibi, blockchain ve roll-up'lar hakkında çok katı bir görüşe sahibiz. Ama katılmıyorum. Yeni olasılıklar deneyebilir ve bulabiliriz.
Kendimize bir soru sorduk: sıfırdan oyunlar ve sadece oyunlar için bir blockchain tasarlayacak olsaydık, nasıl görünürdü? Yüksek verime ihtiyacımız var, bu nedenle okuma ve yazma işlemlerini ölçeklendirmemiz gerekiyor. Blok zincirlerinin çoğu yazma ağırlıklı olacak şekilde tasarlanmıştır. Saniye başına işlem sayısı (TPS), insanların övündüğü bir ölçümdür, ancak gerçekte okumalar da aynı derecede önemlidir. Bir blockchain düğümünden okuyamıyorsanız, bir oyuncunun nerede olduğunu nasıl bilebilirsiniz? Bu aslında blockchain yapımında bulduğumuz ilk darboğaz.
Dark Forest, tam düğümlerin yoğun bir şekilde kullanıldığı ve I/O'nun patladığı bir soruna sahip çünkü zincir üstü durumdan veri okumamız gerekiyor. Bu, xDAI ekibi tarafından bizim için cömertçe karşılanan binlerce dolarlık sunucu maliyetiyle sonuçlandı. Ancak, bu uzun vadede ideal değildir. Yalnızca saniyede yazılan işlemler için değil, blok zincirinin kendisinden veri almak gibi okumalar için de yüksek verime ihtiyacımız var.
Gürültülü Komşu sorununu önlemek için yatay olarak ölçeklenebilir bir blok zincirine de ihtiyacımız var. Popüler bir oyunun aniden blok zincirinde çökmeye başlamasını ve tüm işi durdurmasını istemiyoruz. Oyun için tasarlanacak durum makinesini değiştirebilmemiz için esnekliğe ve özelleştirilebilirliğe de ihtiyacımız var. Bu, bir oyun döngüsüne sahip olmayı, onu kendi kendine yürütmeyi vb. içerir.
Son olarak, çevrimiçi oyunların mimarisine aşina olmayanlar için bu biraz belirsiz olabilir, yüksek tıklama oranına ihtiyacımız var. Tikler, oyun dünyasında atomik zaman birimidir. Blok zincirleri bağlamında, atomik zaman birimleri olarak bloklarımız var. Oyunlarda tiklerimiz var. Blok zincirinizin tik veya blok oluşturma oranının oyunun kendisinin tik'ine eşit olduğu tam zincirli bir oyun oluşturduğunuzda bu neredeyse benzerdir.
Bu nedenle ihtiyacımız olan şey, yüksek iş hacmine, yatay ölçeklenebilirliğe, esnekliğe ve özelleştirmeye ve yüksek tıklama oranına sahip bir blok zinciridir. Böyle bir tasarım, oyun için sıfırdan tasarladığımız blok zincirinin ihtiyaçlarını karşılayabilir.
Saniyede daha yüksek tıklama oranınız veya daha fazla bloğunuz varsa, oyun daha duyarlı olacaktır. Tersine, tıklama oranınız düşükse, oyun yavaşlayacaktır. Unutulmaması gereken önemli bir şey, parçalar gecikirse oyunda fark edilir bir gecikme yaşayacağınızdır. Bu kötü bir deneyim. Bir oyunu kaybettiği için bilgisayara bağıran kızgın oyuncularla uğraştıysanız, bu kesinlikle korkunç bir durum.
Şu anda toplamalarımız saniyede bir bloğa sahiptir ve bu da bir onay işaretine eşittir. Daha havalı oyunlar istiyorsak, daha yüksek tıklama oranlarına ihtiyacımız var. Örneğin, basit bir piksel sanat oyunu olan Minecraft'ta saniyede 26 tik vardır. Minecraft kadar duyarlı bir oyun geliştirmekten hâlâ çok uzağız.
Muhtemel bir çözüm, kendi toplamamızı dağıtmaktır. Sorunu çözüyor gibi görünse de, aslında sorunun temel nedenini çözmez. Örneğin, daha yüksek yazma hızına sahip olacaksınız, ancak oyunların ihtiyaç duyduğu düzeyde olmayacaksınız. Elbette oyununuzda yüz oyuncu varsa bu yeterli olacaktır. Bununla birlikte, daha yüksek verim gerektiren bir oyun oluşturmak istiyorsanız, mevcut derlemede G/Ç'nin yapılma şeklinden dolayı çok katı kısıtlamalar vardır.
Okuma tarafında, gerçekten bir performans kazancı elde edemezsiniz. Hala indeksleyicilere güvenmeniz gerekiyor. Gerçekten yatay ölçeklenebilirliğe sahip değilsiniz. Oyununuzu yatay olarak ölçeklendirmek için yeni bir toplama başlatmaya çalışırsanız, mevcut akıllı sözleşme ekosisteminizi yok edersiniz. Oyuncu tarafından dağıtılan pazar yerleri, oyununuzu yatay olarak ölçeklendirmek için başlattığınız diğer zincirlerle çalışmaz. Bu birçok soruyu gündeme getiriyor.
Son olarak, yüksek tıklama hızı ve saniye başına blok sayısı hala biraz zorlayıcıdır, elimizden geldiğince zorlasak da, saniyede iki, belki üç blok elde edebiliriz, ancak bu gerçekten bu blokaj zincirlerinin işleyiş şeklidir. en uzakta, çünkü yeniden sıralama gibi büyük ölçüde bilgi işlem döngülerine dayanan bir dizi şey var.
Bu soruyu ele almak için, MMO'lar gibi çevrimiçi oyunların yeni ortaya çıktığı 2000'lerin başına ve 1990'ların sonlarına dönüyoruz. Parçalama diye bir konseptleri var. Bu yeni bir kavram değil, geçmişte de vardı. Veritabanı mimarisinde kullandığımız "sharding" kelimesi aslında Ultima Online'a yapılan bir göndermeden gelmektedir. Farklı sunucularını açıklamak için "shard" kelimesini ilk kullanan onlardı.
Peki, oyunlarda parçalama nasıl çalışır? Herkese uyan tek bir çözüm değil. Araç kutusunda bulunan bir araçtır ve onu oyununuza nasıl uyarlayacağınız duruma göre değişir. Örneğin, ilk parçalama yapısı, konuma dayalı parçalama olarak adlandırmayı sevdiğim şeydir. İyi bir zihinsel model, her biri kendi oyun dilimine sahip dört çeyreğe bölünmüş bir Kartezyen koordinat sistemi hayal etmektir. Bir shard'ı her geçmek istediğinizde, başka bir shard'a "hey, oraya taşınmak istiyorum" diyen bir iletişim gönderirsiniz ve shard'ınıza ışınlanarak oyuncuları Body'den önce bırakırsınız. Bunu yaparak, bir sunucuyu tüm oyun dünyası için tüm hesaplamaları yapmaya zorlamak yerine, sunucunun iş yükünü birden çok fiziksel örneğe dağıtırsınız. İkinci yapılandırma artık daha popüler. Birbirini yansıtan birden çok oyun örneğine sahip olduğunuz buna çoklu evren parçalama denir. Hangi shard'a gitmek istediğinizi seçebilirsiniz ve her sunucunun aşırı kalabalık olmaması için yük dengesi varsayılan olarak sağlanır.
Şimdi, anahtar soru şu: Bu konsepti toparlamaya nasıl getirirsiniz? Bu yüzden World Engine'i yarattık. World Engine, temel olarak başlangıç için tasarlanmış, üzerinde düşünülmüş bir parça ayırıcı olan amiral gemisi altyapımızdır. Bizimki, son birkaç tartışmada gördüğümüz parça ayırıcı tasarımlarının çoğundan farklı ve ihtiyaçlarımıza daha uygun. Optimizasyonumuzun yönü şudur: A, verim, B, tıklama oranı ve blok süresinin mümkün olduğunca verimli olmasını sağlamak için çalışma süresini engelleyen hiçbir kilit olmadığından emin olmak istiyoruz, bu nedenle varsayılan olarak senkronize, yol sıralayıcıyı toplam sıralamayı zorlamak yerine kısmi sıralama olarak tasarlıyoruz (her işlemin birbiri ardına gerçekleşmesi gerekir).
Buradaki temel bileşenler, iki ana şeye sahip olmamızdır. Oyuncuların akıllı sözleşmeler uygulayabilecekleri, oyunlarla birleştirebilecekleri, vergilerle pazarlar oluşturabilecekleri, vb. gibi saf bir EVM zincirine benzeyen EVM tabanlı parçalamaya sahibiz. Normal bir zincir gibi, değil mi? Saniyede bir blok gibi bir şey, tüm tipik cihazlarınızı ve pazarlarınızı yapmanız için yeterli.
Buradaki gizli bileşen, aynı zamanda, esasen yüksek performanslı bir oyun sunucusu olarak tasarlanmış bir mini blok zinciri olan bir oyun parçası kullanmamızdır. Bu parçayı beğeninize göre özelleştirebilmeniz için kendi uygulamanızı getir arayüzümüz var. Kendi parçalarınızı oluşturabilir ve bunları temel parçaya enjekte edebilirsiniz. Yalnızca bir dizi standart arabirim uygulamanız gerekir, tıpkı aşina olduğunuz Cosmos gibi, Cosmos'un bir ABC arabirimi vardır. Temel olarak bunu benzer bir spesifikasyonda bir araya getirerek kendi parçalarınızı World Engine yığınına getirebilirsiniz.
Buradaki anahtar, şu anda mevcut parçalama yapısıyla elde edemediğimiz yüksek bir tıklama oranına sahip olmamızdır. Kardinal'i burada tanıtmak istiyorum. Cardinal, World Engine'in ilk oyun parçalama uygulamasıdır. Veri odaklı bir mimariye sahip Entity-Component-System (ECS) kullanır. Bu, oyunu paralelleştirmemize ve oyun hesaplamalarının verimini artırmamıza olanak tanır. Saniyede 20 tıklamaya kadar yapılandırılabilir bir tıklama hızına sahiptir. Buradaki blok zincir halkı için bu, saniyede 20 blok demektir.
Gecikmeyi azaltmak için coğrafi konumunu da belirleyebiliriz. Örneğin, ABD'de bir sıralayıcınız olabilir ve ardından Asyalılar, işlemin sıralayıcıya ulaşması için 300 milisaniye beklemek zorunda kalabilir. Bu oyunlarda çok büyük bir sorun çünkü 300ms uzun bir süre. 200 ms gecikmeli bir FPS oyunu oynamaya çalışırsanız, temelde ölüsünüz demektir.
Bizim için önemli olan bir diğer kilit nokta da self indexli olmasıdır. Artık harici indeksleyicilere ihtiyacımız yok. Oyun durumunu önbelleğe almak için bu çerçevelere ihtiyacımız yok. Bu aynı zamanda, dizin oluşturucu hala sıralayıcı bloklarını yakalamaya çalışırken, gecikme sorunları olmadan daha fazla gerçek zamanlı oyun oluşturmamızı sağlar.
Ayrıca insanların ZK doğrulamasını vb. paralelleştirmesine izin veren bir eklenti sistemimiz var. En azından benim için en iyi yanı, kodunuzu Go'da yazabilmenizdir. Artık oyununuzu çalıştırmak için Solidity kullanmanıza gerek yok. Şimdiye kadar Solidity ile bir blockchain oyunu oluşturmaya çalıştıysanız, bu tam bir kabustu.
Ancak, shard oluşturmamızın kilit noktası, shard olarak her şeyi inşa edebilmenizdir. Temelde sonsuz bir tasarım alanı gibidirler, tıpkı bir parçanın olabileceği gibi.
Oyun kodunuzu Go'da yazmaktan hoşlanmadığınızı varsayarsak, o zaman başka yollar seçebilirsiniz. Ancak, Cardinal'in pek çok avantajını korurken kodlama olanakları sunan bir şekilde Solidity'de oyunlar uygulamanıza izin verecek bir Solidity oyun parçası üzerinde çalışıyoruz. Ayrıca, benzersiz bir mempool ve sipariş yapısına sahip bir NFT basılmış parça oluşturabilir, Noisy Neighbor problemini temel basmaya benzer şekilde çözebilirsiniz. Hatta bir oyun kimlik parçası oluşturup oyun kimliğinizi temsil etmek için NFT'yi kullanabilirsiniz, böylece özel anahtarları paylaşmak yerine NFT üzerinden oyun kimliği işlemlerini kolayca gerçekleştirebilirsiniz.
Bu üst düzey bir mimari ve zaman kısıtlamaları nedeniyle bugün çok fazla derinlemesine ayrıntıya girmeyeceğim. En önemlisi, EVM akıllı sözleşmelerinin özel seç ve pas kullanarak oyun parçalarıyla birleştirilmesine izin veriyoruz. Aralarında iletişime izin vermek için Geth'in etrafında bir sarmalayıcı oluşturduk, bu da her iki yönde de çok fazla tasarım alanı açıyor. Varsayılan olarak senkronizeyiz ve kilitsiz parçalar arasında sorunsuz ve uyumlu bir şekilde birlikte çalışabiliriz.
Paylaşılan sıralayıcımız, bir kilitleme mekanizması gerektiren ve ana iş parçacığının bloke edilmesi, istikrarsız tıklama hızlarına ve blok sürelerine yol açması gibi sorunlara neden olan ve sonuç olarak gecikmeye neden olan küresel sıralanmış atomik demetlere öncelik veren paylaşılan dizi yapısını kullanmaması bakımından farklıdır. oyun. Ayrıca parça başına blok sürelerine sınırlamalar getirir ve hizmet reddini önlemek için çeşitli kriptoekonomi ve yapılar gerektirir. Birçok VCR sıralayıcı yapısında bahsetmediğim başka bir büyük sorun daha var: Birbirine bağlı farklı parçalarınız ve kilitlenmeleriniz varsa, bunu nasıl çözersiniz? Eşzamansız tasarımda bu bir sorun değil çünkü herkes yapmak istediğini yapıyor ve sonra bırakıyor.
Aslında, atomik kirişler ve kırıklar boyunca toplamalar genellikle gerekli değildir. Kullanım durumumuz için, atomik ışınlar gerektiren hiçbir şeye ihtiyacımız yok ve bunun, Toplamalarımızı kullanım durumu saflığı etrafında tasarlamamız gerektiğini düşünmüyoruz. Bu aynı zamanda başka birçok ilginç özelliği de beraberinde getiriyor. Örneğin, her oyun parçacığı, temel zincir için ayrı bir DA katmanına sahip olabilir. Örneğin, verileri Ethereum'a göndermek için temel parçayı kullanabilirsiniz ve oyun parçası verileri Celestia'ya aktarabilir (veri kullanılabilirliği komitesine benzer). Ayrıca tam bir düğüm çalıştırmak için donanım gereksinimlerini azaltabilirsiniz, çünkü temel parça Geth tam düğümü oyun parça düğümünü çalıştırmadan ayrı olarak çalıştırabilirsiniz, bu da Alchemy gibi şeylerle entegre olmanızı kolaylaştırır.
Özetlemek gerekirse, burada dürüst olmak istiyorum, birçok insan yapılarının tüm sorunlarını çözmesini bekliyor ama biz yapmıyoruz. Yapımızın bizim için çalıştığını düşünüyoruz, ancak sizin kullanım durumunuz için çalışmayabilir. Yapılarımızın herkes için işe yarayacağını varsaymak gerçekçi değildir. Bizim için ihtiyaçlarımıza uyuyor, yüksek verim, yatay ölçeklenebilirlik, esneklik ve yüksek tıklama oranları sağlıyor, ancak kanser tedavisi değil. Eşzamanlı şekillendirilebilirlik gerektiren bir DeFi protokolüne ihtiyacınız varsa bu yapı size göre olmayabilir.
Genel olarak, insan merkezli bir blockchain mimarisi kavramına gerçekten inanıyorum. Belirli kullanıcı rolleri ve kullanım durumları etrafında tasarlayarak, herkesin sorunlarını çözmeye çalışmak yerine daha iyi ödünler verebilirsiniz. Rönesans dönemi geldi ve herkes genel bir çözüme güvenmek yerine kendi özel ihtiyaçlarını karşılamak için kendi Roll-Up'larını tasarlayabilir. Bence Kambriyen Patlamasını kucaklamalıyız. Aynı sorunu çözmek için tasarlanmadığından, herkese uyan tek bedenli birinci katman gibi toplamalar oluşturmayın. Kişisel olarak, daha fazla insanın kullanım durumları için Roll-Up tasarım alanını daha fazla keşfetmesini dört gözle bekliyorum. Örneğin, varlık takası için özel olarak tasarlanmış bir Toplama nasıl görünür? Niyete dayalı mı olacak? Zincir üstü CLOB'lar (Merkezi Limitli Emir Defteri) için özel olarak tasarlanmış bir Toplama nasıl görünür? Burada mikrofonu MJ'e veriyorum. Davetiniz için teşekkür ederim.
İngilizce versiyon:
View Original
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.
Argus, tam zincirli bir oyun altyapısı oluşturmak için parçalamayı neden kullanıyor?
原标题: Endişelenmeyi ve Sevgiyi Paylaşmayı Durdurmayı Nasıl Öğrendim?
Video bağlantısı:
Konuşmacı: Araştırma Günü'nde Scott Sunarto (@smsunarto)
Makale düzenleme ve bitirme: Justin Zhao (@hiCaptainZ)
Merhaba, ben Scott (@smsunarto), August Labs'ın (@ArgusLabs_) kurucusu. Bugün uzun zamandır değinmediğimiz bir konudan bahsedeceğim. Özetlemelerin zamanın ana akımı haline gelmesiyle, yürütme parçalamayı veri parçalama kadar tartışmıyoruz. Öyleyse, biraz ihmal edilmiş olan bu konuyu yeniden ele alalım - yürütme parçalama.
Bu kolay bir konuşma olacak. Bütün gün karmaşık kavramlar duyduğunu biliyorum, bu yüzden bu tartışmayı mümkün olduğunca pratik hale getirmeye çalışacağım. Bu sunuma uygun bir slayt tasarımı hazırladım.
Beni tanımayanlar için komik olan şu ki Twitter'da bir anime kızı olarak tanınıyorum. Sırf burada olmak için üniversite mezuniyetimi de kaçırdım, ailemi dehşete düşürerek. Şu anda Argus Labs'ın kurucusuyum. Kendimizi bir altyapı veya kripto para şirketi olarak değil, bir oyun şirketi olarak görüyoruz. En büyük sinirlerimden biri, kripto oyunlarındaki herkesin araçlar oluşturmak istemesi, ancak kimsenin içerik veya uygulama oluşturmak istememesi. Kullanıcıların gerçekten kullanabileceği daha fazla uygulamaya ihtiyacımız var.
Daha önce, akıllı arkadaşlarım Brian Gu (@gubsheep) ve Alan Luo (@alanluo_0) ile Dark Forest'ı (@darkforest_eth) birlikte yarattım. Brian şu anda 0xPARC (@0xPARC) kullanıyor ve benden çok daha akıllı.
Bugünün tartışması parçalama gerçekleştirmeye odaklanacak, ancak bir bağlamda çoğu insan parçalama gerçekleştirme tartışmasına aşina değil. Yürütme parçalamayı genellikle Katman 1 bağlamında, örneğin Ethereum parçalama veya Near parçalama gibi tartışırız. Ama bugün, içeriği biraz değiştirmek istiyorum. Toplama ortamında parçalamanın nasıl görüneceğini düşünelim.
Buradaki temel soru, bir oyun şirketinin neden kendi roll-up'ını oluşturması gerektiği ve World of Warcraft'tan roll-up'ları tasarlamak için ne öğrenebileceğimizdir. Ek olarak, roll-up'lar için tasarım alanının mevcut gerçeklerin çok ötesine nasıl geçtiğini keşfedeceğiz.
Bu soruları cevaplamak için Karanlık Orman fikrinin ilk ortaya çıktığı 2020 yılına geri dönelim. Kendimize, her oyun eyleminin zincirleme bir işlem olduğu bir oyun yaratırsak ne olur diye sorduk. Önerme o zamanlar saçmaydı ve bugün hala birçok insan için öyle. Ama ilginç bir hipotezdi, biz de onu kurduk ve Karanlık Orman doğdu.
Dark Forest, tamamen Ethereum tabanlı, ZK-Snarks tarafından desteklenen, tam zincirli bir uzay keşfi MMORTS oyunudur. 2020'de ZK bugünkü kadar popüler değildi çünkü neredeyse hiç belge yoktu. Circom için mevcut tek belge Jordi Baylina'nın (@jbaylina) Google Dokümanlarıdır. Zorluklara rağmen yol boyunca çok şey öğrendik ve Dark Forest bu öğrendiklerimizin vücut bulmuş hali.
Dark Forest düşündüğümüzden daha büyük bir deney. 10.000'den fazla oyuncumuz, harcanan trilyonlarca benzinimiz, oyunda kaosumuz, zincirin sırtından bıçaklayan insanlar var. Dark Forest ve on-chain oyunlarıyla ilgili en büyüleyici şey, platform oluşturma doğasıdır. Tam zincirli bir oyuna sahip olarak, ortaya çıkan davranışlar için bir tasarım alanının kapısını açarsınız ve insanların oyunla etkileşime giren akıllı sözleşmelerin yanı sıra alternatif istemciler ve Dark Forest Arena ve GPU madencileri gibi oyun modları oluşturmasına olanak tanırsınız.
Ancak, büyük güç büyük sorumluluk getirir. Artık Gnosis Zinciri olarak bilinen xDai'de Dark Forest'ı başlattığımızda, zincirin tüm blok alanını doldurduk. Bu, zinciri temelde DeFi, NFT'ler veya başka herhangi bir xDAI şeyi dahil olmak üzere başka herhangi bir şey için kullanılamaz hale getirir.
Peki şimdi ne olacak? Bir çıkmaza mı girdik? Tam zincirli oyunlar asla gerçek olmayacak mı? Yoksa sadece küçük JPEG resimlerin zincirde olduğu oyunlar yapmaya geri dönüp insanları paranın ağaçta yetiştiğine ikna mı edeceğiz? Cevap şu ki, yazılımın bir şeyler yapmasına izin veriyoruz. Birçoğumuz, sanki iyileştirme için fazla yer yokmuş gibi, blockchain ve roll-up'lar hakkında çok katı bir görüşe sahibiz. Ama katılmıyorum. Yeni olasılıklar deneyebilir ve bulabiliriz.
Kendimize bir soru sorduk: sıfırdan oyunlar ve sadece oyunlar için bir blockchain tasarlayacak olsaydık, nasıl görünürdü? Yüksek verime ihtiyacımız var, bu nedenle okuma ve yazma işlemlerini ölçeklendirmemiz gerekiyor. Blok zincirlerinin çoğu yazma ağırlıklı olacak şekilde tasarlanmıştır. Saniye başına işlem sayısı (TPS), insanların övündüğü bir ölçümdür, ancak gerçekte okumalar da aynı derecede önemlidir. Bir blockchain düğümünden okuyamıyorsanız, bir oyuncunun nerede olduğunu nasıl bilebilirsiniz? Bu aslında blockchain yapımında bulduğumuz ilk darboğaz.
Dark Forest, tam düğümlerin yoğun bir şekilde kullanıldığı ve I/O'nun patladığı bir soruna sahip çünkü zincir üstü durumdan veri okumamız gerekiyor. Bu, xDAI ekibi tarafından bizim için cömertçe karşılanan binlerce dolarlık sunucu maliyetiyle sonuçlandı. Ancak, bu uzun vadede ideal değildir. Yalnızca saniyede yazılan işlemler için değil, blok zincirinin kendisinden veri almak gibi okumalar için de yüksek verime ihtiyacımız var.
Gürültülü Komşu sorununu önlemek için yatay olarak ölçeklenebilir bir blok zincirine de ihtiyacımız var. Popüler bir oyunun aniden blok zincirinde çökmeye başlamasını ve tüm işi durdurmasını istemiyoruz. Oyun için tasarlanacak durum makinesini değiştirebilmemiz için esnekliğe ve özelleştirilebilirliğe de ihtiyacımız var. Bu, bir oyun döngüsüne sahip olmayı, onu kendi kendine yürütmeyi vb. içerir.
Son olarak, çevrimiçi oyunların mimarisine aşina olmayanlar için bu biraz belirsiz olabilir, yüksek tıklama oranına ihtiyacımız var. Tikler, oyun dünyasında atomik zaman birimidir. Blok zincirleri bağlamında, atomik zaman birimleri olarak bloklarımız var. Oyunlarda tiklerimiz var. Blok zincirinizin tik veya blok oluşturma oranının oyunun kendisinin tik'ine eşit olduğu tam zincirli bir oyun oluşturduğunuzda bu neredeyse benzerdir.
Bu nedenle ihtiyacımız olan şey, yüksek iş hacmine, yatay ölçeklenebilirliğe, esnekliğe ve özelleştirmeye ve yüksek tıklama oranına sahip bir blok zinciridir. Böyle bir tasarım, oyun için sıfırdan tasarladığımız blok zincirinin ihtiyaçlarını karşılayabilir.
Saniyede daha yüksek tıklama oranınız veya daha fazla bloğunuz varsa, oyun daha duyarlı olacaktır. Tersine, tıklama oranınız düşükse, oyun yavaşlayacaktır. Unutulmaması gereken önemli bir şey, parçalar gecikirse oyunda fark edilir bir gecikme yaşayacağınızdır. Bu kötü bir deneyim. Bir oyunu kaybettiği için bilgisayara bağıran kızgın oyuncularla uğraştıysanız, bu kesinlikle korkunç bir durum.
Şu anda toplamalarımız saniyede bir bloğa sahiptir ve bu da bir onay işaretine eşittir. Daha havalı oyunlar istiyorsak, daha yüksek tıklama oranlarına ihtiyacımız var. Örneğin, basit bir piksel sanat oyunu olan Minecraft'ta saniyede 26 tik vardır. Minecraft kadar duyarlı bir oyun geliştirmekten hâlâ çok uzağız.
Muhtemel bir çözüm, kendi toplamamızı dağıtmaktır. Sorunu çözüyor gibi görünse de, aslında sorunun temel nedenini çözmez. Örneğin, daha yüksek yazma hızına sahip olacaksınız, ancak oyunların ihtiyaç duyduğu düzeyde olmayacaksınız. Elbette oyununuzda yüz oyuncu varsa bu yeterli olacaktır. Bununla birlikte, daha yüksek verim gerektiren bir oyun oluşturmak istiyorsanız, mevcut derlemede G/Ç'nin yapılma şeklinden dolayı çok katı kısıtlamalar vardır.
Okuma tarafında, gerçekten bir performans kazancı elde edemezsiniz. Hala indeksleyicilere güvenmeniz gerekiyor. Gerçekten yatay ölçeklenebilirliğe sahip değilsiniz. Oyununuzu yatay olarak ölçeklendirmek için yeni bir toplama başlatmaya çalışırsanız, mevcut akıllı sözleşme ekosisteminizi yok edersiniz. Oyuncu tarafından dağıtılan pazar yerleri, oyununuzu yatay olarak ölçeklendirmek için başlattığınız diğer zincirlerle çalışmaz. Bu birçok soruyu gündeme getiriyor.
Son olarak, yüksek tıklama hızı ve saniye başına blok sayısı hala biraz zorlayıcıdır, elimizden geldiğince zorlasak da, saniyede iki, belki üç blok elde edebiliriz, ancak bu gerçekten bu blokaj zincirlerinin işleyiş şeklidir. en uzakta, çünkü yeniden sıralama gibi büyük ölçüde bilgi işlem döngülerine dayanan bir dizi şey var.
Bu soruyu ele almak için, MMO'lar gibi çevrimiçi oyunların yeni ortaya çıktığı 2000'lerin başına ve 1990'ların sonlarına dönüyoruz. Parçalama diye bir konseptleri var. Bu yeni bir kavram değil, geçmişte de vardı. Veritabanı mimarisinde kullandığımız "sharding" kelimesi aslında Ultima Online'a yapılan bir göndermeden gelmektedir. Farklı sunucularını açıklamak için "shard" kelimesini ilk kullanan onlardı.
Peki, oyunlarda parçalama nasıl çalışır? Herkese uyan tek bir çözüm değil. Araç kutusunda bulunan bir araçtır ve onu oyununuza nasıl uyarlayacağınız duruma göre değişir. Örneğin, ilk parçalama yapısı, konuma dayalı parçalama olarak adlandırmayı sevdiğim şeydir. İyi bir zihinsel model, her biri kendi oyun dilimine sahip dört çeyreğe bölünmüş bir Kartezyen koordinat sistemi hayal etmektir. Bir shard'ı her geçmek istediğinizde, başka bir shard'a "hey, oraya taşınmak istiyorum" diyen bir iletişim gönderirsiniz ve shard'ınıza ışınlanarak oyuncuları Body'den önce bırakırsınız. Bunu yaparak, bir sunucuyu tüm oyun dünyası için tüm hesaplamaları yapmaya zorlamak yerine, sunucunun iş yükünü birden çok fiziksel örneğe dağıtırsınız. İkinci yapılandırma artık daha popüler. Birbirini yansıtan birden çok oyun örneğine sahip olduğunuz buna çoklu evren parçalama denir. Hangi shard'a gitmek istediğinizi seçebilirsiniz ve her sunucunun aşırı kalabalık olmaması için yük dengesi varsayılan olarak sağlanır.
Şimdi, anahtar soru şu: Bu konsepti toparlamaya nasıl getirirsiniz? Bu yüzden World Engine'i yarattık. World Engine, temel olarak başlangıç için tasarlanmış, üzerinde düşünülmüş bir parça ayırıcı olan amiral gemisi altyapımızdır. Bizimki, son birkaç tartışmada gördüğümüz parça ayırıcı tasarımlarının çoğundan farklı ve ihtiyaçlarımıza daha uygun. Optimizasyonumuzun yönü şudur: A, verim, B, tıklama oranı ve blok süresinin mümkün olduğunca verimli olmasını sağlamak için çalışma süresini engelleyen hiçbir kilit olmadığından emin olmak istiyoruz, bu nedenle varsayılan olarak senkronize, yol sıralayıcıyı toplam sıralamayı zorlamak yerine kısmi sıralama olarak tasarlıyoruz (her işlemin birbiri ardına gerçekleşmesi gerekir).
Buradaki temel bileşenler, iki ana şeye sahip olmamızdır. Oyuncuların akıllı sözleşmeler uygulayabilecekleri, oyunlarla birleştirebilecekleri, vergilerle pazarlar oluşturabilecekleri, vb. gibi saf bir EVM zincirine benzeyen EVM tabanlı parçalamaya sahibiz. Normal bir zincir gibi, değil mi? Saniyede bir blok gibi bir şey, tüm tipik cihazlarınızı ve pazarlarınızı yapmanız için yeterli.
Buradaki gizli bileşen, aynı zamanda, esasen yüksek performanslı bir oyun sunucusu olarak tasarlanmış bir mini blok zinciri olan bir oyun parçası kullanmamızdır. Bu parçayı beğeninize göre özelleştirebilmeniz için kendi uygulamanızı getir arayüzümüz var. Kendi parçalarınızı oluşturabilir ve bunları temel parçaya enjekte edebilirsiniz. Yalnızca bir dizi standart arabirim uygulamanız gerekir, tıpkı aşina olduğunuz Cosmos gibi, Cosmos'un bir ABC arabirimi vardır. Temel olarak bunu benzer bir spesifikasyonda bir araya getirerek kendi parçalarınızı World Engine yığınına getirebilirsiniz.
Buradaki anahtar, şu anda mevcut parçalama yapısıyla elde edemediğimiz yüksek bir tıklama oranına sahip olmamızdır. Kardinal'i burada tanıtmak istiyorum. Cardinal, World Engine'in ilk oyun parçalama uygulamasıdır. Veri odaklı bir mimariye sahip Entity-Component-System (ECS) kullanır. Bu, oyunu paralelleştirmemize ve oyun hesaplamalarının verimini artırmamıza olanak tanır. Saniyede 20 tıklamaya kadar yapılandırılabilir bir tıklama hızına sahiptir. Buradaki blok zincir halkı için bu, saniyede 20 blok demektir.
Gecikmeyi azaltmak için coğrafi konumunu da belirleyebiliriz. Örneğin, ABD'de bir sıralayıcınız olabilir ve ardından Asyalılar, işlemin sıralayıcıya ulaşması için 300 milisaniye beklemek zorunda kalabilir. Bu oyunlarda çok büyük bir sorun çünkü 300ms uzun bir süre. 200 ms gecikmeli bir FPS oyunu oynamaya çalışırsanız, temelde ölüsünüz demektir.
Bizim için önemli olan bir diğer kilit nokta da self indexli olmasıdır. Artık harici indeksleyicilere ihtiyacımız yok. Oyun durumunu önbelleğe almak için bu çerçevelere ihtiyacımız yok. Bu aynı zamanda, dizin oluşturucu hala sıralayıcı bloklarını yakalamaya çalışırken, gecikme sorunları olmadan daha fazla gerçek zamanlı oyun oluşturmamızı sağlar.
Ayrıca insanların ZK doğrulamasını vb. paralelleştirmesine izin veren bir eklenti sistemimiz var. En azından benim için en iyi yanı, kodunuzu Go'da yazabilmenizdir. Artık oyununuzu çalıştırmak için Solidity kullanmanıza gerek yok. Şimdiye kadar Solidity ile bir blockchain oyunu oluşturmaya çalıştıysanız, bu tam bir kabustu.
Ancak, shard oluşturmamızın kilit noktası, shard olarak her şeyi inşa edebilmenizdir. Temelde sonsuz bir tasarım alanı gibidirler, tıpkı bir parçanın olabileceği gibi.
Oyun kodunuzu Go'da yazmaktan hoşlanmadığınızı varsayarsak, o zaman başka yollar seçebilirsiniz. Ancak, Cardinal'in pek çok avantajını korurken kodlama olanakları sunan bir şekilde Solidity'de oyunlar uygulamanıza izin verecek bir Solidity oyun parçası üzerinde çalışıyoruz. Ayrıca, benzersiz bir mempool ve sipariş yapısına sahip bir NFT basılmış parça oluşturabilir, Noisy Neighbor problemini temel basmaya benzer şekilde çözebilirsiniz. Hatta bir oyun kimlik parçası oluşturup oyun kimliğinizi temsil etmek için NFT'yi kullanabilirsiniz, böylece özel anahtarları paylaşmak yerine NFT üzerinden oyun kimliği işlemlerini kolayca gerçekleştirebilirsiniz.
Bu üst düzey bir mimari ve zaman kısıtlamaları nedeniyle bugün çok fazla derinlemesine ayrıntıya girmeyeceğim. En önemlisi, EVM akıllı sözleşmelerinin özel seç ve pas kullanarak oyun parçalarıyla birleştirilmesine izin veriyoruz. Aralarında iletişime izin vermek için Geth'in etrafında bir sarmalayıcı oluşturduk, bu da her iki yönde de çok fazla tasarım alanı açıyor. Varsayılan olarak senkronizeyiz ve kilitsiz parçalar arasında sorunsuz ve uyumlu bir şekilde birlikte çalışabiliriz.
Paylaşılan sıralayıcımız, bir kilitleme mekanizması gerektiren ve ana iş parçacığının bloke edilmesi, istikrarsız tıklama hızlarına ve blok sürelerine yol açması gibi sorunlara neden olan ve sonuç olarak gecikmeye neden olan küresel sıralanmış atomik demetlere öncelik veren paylaşılan dizi yapısını kullanmaması bakımından farklıdır. oyun. Ayrıca parça başına blok sürelerine sınırlamalar getirir ve hizmet reddini önlemek için çeşitli kriptoekonomi ve yapılar gerektirir. Birçok VCR sıralayıcı yapısında bahsetmediğim başka bir büyük sorun daha var: Birbirine bağlı farklı parçalarınız ve kilitlenmeleriniz varsa, bunu nasıl çözersiniz? Eşzamansız tasarımda bu bir sorun değil çünkü herkes yapmak istediğini yapıyor ve sonra bırakıyor.
Aslında, atomik kirişler ve kırıklar boyunca toplamalar genellikle gerekli değildir. Kullanım durumumuz için, atomik ışınlar gerektiren hiçbir şeye ihtiyacımız yok ve bunun, Toplamalarımızı kullanım durumu saflığı etrafında tasarlamamız gerektiğini düşünmüyoruz. Bu aynı zamanda başka birçok ilginç özelliği de beraberinde getiriyor. Örneğin, her oyun parçacığı, temel zincir için ayrı bir DA katmanına sahip olabilir. Örneğin, verileri Ethereum'a göndermek için temel parçayı kullanabilirsiniz ve oyun parçası verileri Celestia'ya aktarabilir (veri kullanılabilirliği komitesine benzer). Ayrıca tam bir düğüm çalıştırmak için donanım gereksinimlerini azaltabilirsiniz, çünkü temel parça Geth tam düğümü oyun parça düğümünü çalıştırmadan ayrı olarak çalıştırabilirsiniz, bu da Alchemy gibi şeylerle entegre olmanızı kolaylaştırır.
Özetlemek gerekirse, burada dürüst olmak istiyorum, birçok insan yapılarının tüm sorunlarını çözmesini bekliyor ama biz yapmıyoruz. Yapımızın bizim için çalıştığını düşünüyoruz, ancak sizin kullanım durumunuz için çalışmayabilir. Yapılarımızın herkes için işe yarayacağını varsaymak gerçekçi değildir. Bizim için ihtiyaçlarımıza uyuyor, yüksek verim, yatay ölçeklenebilirlik, esneklik ve yüksek tıklama oranları sağlıyor, ancak kanser tedavisi değil. Eşzamanlı şekillendirilebilirlik gerektiren bir DeFi protokolüne ihtiyacınız varsa bu yapı size göre olmayabilir.
Genel olarak, insan merkezli bir blockchain mimarisi kavramına gerçekten inanıyorum. Belirli kullanıcı rolleri ve kullanım durumları etrafında tasarlayarak, herkesin sorunlarını çözmeye çalışmak yerine daha iyi ödünler verebilirsiniz. Rönesans dönemi geldi ve herkes genel bir çözüme güvenmek yerine kendi özel ihtiyaçlarını karşılamak için kendi Roll-Up'larını tasarlayabilir. Bence Kambriyen Patlamasını kucaklamalıyız. Aynı sorunu çözmek için tasarlanmadığından, herkese uyan tek bedenli birinci katman gibi toplamalar oluşturmayın. Kişisel olarak, daha fazla insanın kullanım durumları için Roll-Up tasarım alanını daha fazla keşfetmesini dört gözle bekliyorum. Örneğin, varlık takası için özel olarak tasarlanmış bir Toplama nasıl görünür? Niyete dayalı mı olacak? Zincir üstü CLOB'lar (Merkezi Limitli Emir Defteri) için özel olarak tasarlanmış bir Toplama nasıl görünür? Burada mikrofonu MJ'e veriyorum. Davetiniz için teşekkür ederim.
İngilizce versiyon: