Lattice ekibi kısa bir süre önce OP Stack'e (Optimism L2'ye güç veren yığın) yeni katkılarını kullanarak inşa ettikleri yeni L2'leri Redstone'u duyurdu.

Bu nedenle herkesin aklındaki soru şu: "Zincir üstü oyunlar bu L2 üzerine kurulmalı mı ve alternatifleriyle karşılaştırıldığında nasıldır?". Çoklu zincirlerde canlı oyunlar içeren zincir üstü oyunların en iyi geliştiricilerinden biri olduğumuz ve bu nedenle nüanslara dalmak için elimizden gelenin en iyisini yapacağımız göz önüne alındığında, pek çok kişi Paima Studios'taki ekibimize görüşümüzü almak için ulaşıyor.

NOT

Bu yazının yazıldığı sırada Redstone daha yeni duyurulmuştu. Web3 çok hızlı hareket eden bir alandır ve bu nedenle, çalışmaları hakkında kaçınılmaz olarak daha fazla bilgi veren Redstone'a karşı bu blog yazısını açık fikirlilikle okumanızı öneririz.

Redstone'u ve neden var olduğunu anlamak için öncelikle piyasada aktif olarak kullanılan diğer alternatiflerle ve bunların takaslarıyla nasıl karşılaştırıldığını anlamalısınız. Özellikle, bu blog yazısında, daha sonra ne duyurulursa duyurulsun Redstone'un ne önerdiğini anlayabilmeniz için size doğru zihinsel modeli vermeye odaklanacağız.

Her şeyin​başladığı​yer

Yani bir zincir üstü oyun mu geliştirmek istiyorsunuz? Redstone'un bir Ethereum L2 olduğu göz önüne alındığında, Ethereum'dan yararlanmaya zaten karar verdiğinizi varsayacağız.

Peki neden oyununuzu doğrudan Ethereum'a dağıtmıyorsunuz? Bunun maliyetinin çok yüksek olmasından kaynaklandığını biliyor olabilirsiniz (bu yazının yazıldığı sırada oyun hamlesi başına >1$'dan fazla), ama neden bu kadar pahalı olduğunu biliyor musunuz? İki ana maliyetin olduğu ortaya çıktı: yürütme maliyeti ve veri depolama maliyeti; bunların her ikisi de bir oyun için aşırı derecede pahalı. Ancak CPU'ların sabit disklerden daha pahalı olması gibi, yürütme maliyeti de depolama maliyetlerinden önemli ölçüde daha yüksektir. Peki yürütme maliyetini depolama maliyetine dönüştürmenin bir yolunu bulabilirsek ne olur? İyi haber: Toplamalar tam olarak bunu yapar.

Ölçeklendirme​çözümü​olarak toplamalar

Toplamalar, her biri yürütme maliyetlerini depolama maliyetlerine kendi yöntemleriyle dönüştüren birçok biçimde gelir:

1. İyimser toplamalar: hesaplamayı zincir dışında çalıştırın, ardından işlevi yürütmek için gereken tüm verileri (yalnızca veriler, yürütme yok) sonuç için yerel olarak hesaplanan değerinizle birlikte saklayın. Yürütmeyi yalnızca birisi gönderdiğiniz sonucun yanlış olduğuna ("sahtekarlığa karşı kanıt") inanırsa çalıştırın. \
   Popüler örnekler: Arbitrum, İyimserlik
2. ZK toplamaları: hesaplamayı zincir dışında çalıştırın, ardından işlevi yürütmek için gereken tüm verileri (yalnızca veriler, yürütme yok) yerel olarak hesaplanan sonucun ZK kanıtıyla birlikte saklayın. \
   Popüler örnekler: ZK Sync, Starknet, Polygon zkEVM
3. Egemen toplama: hesaplamayı zincir dışında çalıştırın, ardından işlevi yürütmek için gereken tüm verileri saklayın (yalnızca veriler, yürütme yok). \
   Popüler örnekler: Rollkit, Paima Engine

Bu çözümlerden yararlanmak, oyununuz için bir işlem maliyetini yaklaşık 0,05$'a düşürür (güncel değerler için l2fees'e bakın), bu kesinlikle doğru yönde atılmış büyük bir adımdır.

​L2'lerin​maliyetinin azaltılması

Açıkçası, bu L2'lerin maliyetlerini azaltmak oyunların başarılı olmasının anahtarıdır. Toplamalar kesinlikle ucuzlasa da (bilgisayarlar daha iyi hale geliyor, ZK teknolojisi daha iyi hale geliyor vb.), birincil maliyetler zincir dışı hesaplamayı çalıştırmak değil, daha ziyade verileri L1'e göndermenin maliyetidir.

Bununla başa çıkmak için Ethereum, verilerin yalnızca geçici olarak (pratikte yaklaşık 2 hafta) saklandığı, çok daha ucuz olan ( EIP4844 adı verilen) verileri depolamanın yeni bir yolunu sunacak, böylece herhangi bir sahtekarlığa karşı korumanın yayınlanması için yeterince uzun olacak ve Verilerin dünya genelindeki düğümler tarafından kopyalanması için).

EIP4844'ün bazı dezavantajları da vardır:

• Veriler yalnızca geçicidir (daha sonra bunları barındırılmaya devam etmek için başka bir depolama çözümü bulmanız gerekecektir)
• Veriler sınırlıdır ve blok başına yaklaşık 2 MiB ile sınırlıdır (Ethereum'daki tüm toplamalar arasında paylaşılır)

Gördüğünüz gibi, maliyetleri düşürmek için çaba gösterilse de, blockchain alanına olan ilginin devam eden büyümesi göz önüne alındığında, bunlar L2'de zincir içi oyunları uygulanabilir hale getirmek için yeterli olmayacak (benimseme hızı, teknik yenilik hızından daha hızlıdır) )

Alternatif #1: Verileri merkezi bir sunucuda (veya sunucu grubunda )saklayın

Maliyeti düşük tutmanın bir alternatifi, verileri insanların sizin çalıştırmanız konusunda size güvendiği merkezi bir sunucuda depolamak ve verilerin yalnızca karma değerini zincirde yayınlamaktır. Bu fikrin bir çeşidi, çoklu imza olarak bir araya getirilmiş, bağımsız olarak çalıştırılan bir grup makineyi kullanmaktır. Böyle bir şemaya "Veri Kullanılabilirliği Komitesi" (DAC) denir ve Arbitrum Nova, Arbitrum Orbit ve Polygon CDK tarafından kullanılan da budur.

Ağın daha merkezi olması karşılığında bu planlar çok daha ucuzdur (ücret piyasasını göz ardı ederseniz Arbitrum Nova için 0,001 $ / tx). Ana risk, DAC'nin verileri barındırmayı durdurması durumunda (örneğin: bir karma gönderirler ve bu karma için verileri hiçbir zaman paylaşmazlar) ağın durmasıdır.

​Arbitrum​hakkında özel bir not

Arbitrum'un neden listede iki kez göründüğünü merak ediyor olabilirsiniz. Arbitrum şu anda 3 ana teklif sunmaktadır:

• Arbitrum One (Ethereum'daki verileri içeren tam kapsamlı ana Arbitrum ağı)
• Arbitrum Nova (DAC kullanan bir L2)
• Arbitrum Orbit (Arbitrum One için L3'ler oluşturmaya yönelik bir yığın)

Gördüğünüz gibi Nova'nın sorunu, oyununuz için DeFi'den yararlanmanın iyi bir yolunun olmaması (kullanıcıların (Nova -> ETH L1 -> One) seçeneğine gitmesi ve sırf köprü kurmak için benzine çok para harcaması gerekirdi), oysa yeni Orbit yığını kolayca gitmenizi sağlar (Orbit -> Bir). Ek olarak, Orbit, L3'ler oluşturmaya yönelik bir yığın olduğundan, kendi DAC'sine güç sağlayan Xai Games gibi mevcut bir L3'ü kullanabilir veya kendi L3'ünüzü çalıştırabilirsiniz (her ne kadar Ethereum ile tek bağlantısı ara sıra paylaşım yapmak olan oyuna özel bir L3'ünüz varsa da) karmalar, muhtemelen web2.5 ile daha iyi durumda olabilirsiniz)

Alternatif #2: Verileri başka bir merkezi olmayan​ağda​saklayın

Celestia, Avail ve EigenDA gibi diğer projeler, EIP4844'ün ana ağda sınırlı bant genişliği ile uygulanmasını beklemek yerine, benzer bir konsepti ayrı bir zincir (Veri Kullanılabilirliği ("DA") katmanı olarak adlandırılır) olarak ve tamamen odaklanarak uygulamaya karar verdi. Bu kullanım durumunda, Ethereum ana ağının desteklemeyi planladığından daha yüksek veri limitleri sunuyorlar. Bu platformlar akıllı sözleşmeleri desteklememektedir ve bunun yerine yalnızca L2'ler için veri katmanı olarak kullanılmak üzere tasarlanmıştır.

Özellikle Celestia'ya ilişkin verileri içeren bir OP Yığını ve ayrıca Celestia'ya ilişkin verileri içeren bir Arbitrum Orbit oluşturmak mümkündür. Bu bazı ödünleşimleri de beraberinde getiriyor:

1. Güven. Toplamanız artık Ethereum'un üzerindeki güvenlik için DA katmanına bağlı (ancak muhtemelen bir DAC'den daha iyi)
2. Maliyet. Toplamanızın artık güvenliği için DA ağına ödeme yapması gerekiyor (bunu da DA katmanının yerel belirteciyle ödemeniz gerekiyor)
3. Hız. Celestia blok süreleri 15 saniyedir ve Avail blok süreleri 20 saniyedir. Örneğin, verilerin Celestia'nın blob akışı sözleşmesiyle EVM'ye köprülenebilmesi için önce Celestia'ya yerleşmesi gerekiyor. Ancak bu noktaya biraz şüpheyle yaklaşın, çünkü tüm L2'ler genel olarak Ethereum'un sağlayabileceğinden daha hızlı blok sürelerini taklit eder (Ethereum'un blok süreleri Arbitrum'un bundan daha hızlı bir blok süresi kullanmasına rağmen yalnızca 15 saniyedir).

Bu tür bir kurulum özellikle Mantle (OP Stack + EigenLayer DA) ve Manta Pacific (OP Stack + Celestia) tarafından kullanılıyor. Bunların maliyeti hala görülecek, ancak Celestia ekibi yaklaşık 0,001 $ talep ediyor , bu da bir DA katmanındaki depolama maliyetinin (EVM tarafındaki bir ücret piyasasındaki yürütme maliyetine göre) minimum düzeyde olduğu anlamına geliyor.

Alternatif #3: Verileri​sorgulanabilecek​bir DAC'de saklayın

Son olarak Redstone'un neler sunduğundan bahsedebiliriz. Verileri bir DA katmanında depolamanın getirdiği tavizlerden ve DAC'nin merkezileştirilmesinden hoşlanmıyorsanız, bunun yerine, verileri kullanılabilir hale getirmemeleri durumunda komiteyi mali olarak cezalandırabileceğiniz bir DAC oluşturabilirsiniz. .

Bunun ne anlama geldiğini anlamanıza yardımcı olmak için DAC protokolünün nasıl çalıştığına ilişkin bir akışın üzerinden geçelim:

​Veri​nasıl yazılır?

1. Redstone Sıralayıcısı işleminizi alır
2. Sıralayıcı, verileri depolanacak DAC'ye gönderir
3. DAC, verilerin saklandığına dair bir onay döndürür
4. Sıralayıcı, verinin karma değerini L1'e gönderir

​Veriler​nasıl okunur?

1. Toplama sözleşmesine gönderilen karmaları arayan bir Ethereum zincirini senkronize edin
2. DAC'den karma verilerini sorgulama
3. Bu verilere dayanarak L2'nin durumunu hesaplayın

Peki Redstone neyi​değiştiriyor?

Verileri okurken, veriler mevcut değilse, verileri kullanılabilir hale getirmediğini (diğer bir deyişle veriler sunucularından indirilemez) iddia ederek DAC'ye itiraz edebilirsiniz.

Herkesi dürüst olmaya teşvik etmek için aşağıdaki kesme kurallarını belirledik:

1. Eğer rakip sahtekârsa (veriler gerçekten mevcuttu), kesintiye uğrarlar (aksi takdirde, her bloğa meydan okuyarak ağa finansal olarak saldırabilirsiniz)
2. DCA sahtekârsa (veriler mevcut değilse), kesintiye uğrarlar.

Bu basit bir çözüm gibi görünse de zorluk, bir sorun ortaya çıktığında kimin hatalı olduğunu bulmaktır. Aşağıdaki senaryoyu düşünün:

1. Sequencer, gerçek verileri paylaşmadan bir karma yayınlıyor
2. Birisi sıralayıcıya meydan okuyor
3. Sıralayıcı, zorluğu görüyor ve verileri kullanılabilir hale getiriyor

Zinciri gerçek zamanlı olarak izlemeyen bir dış gözlemciyseniz, veriler mevcut görünür (eğer olaydan sonra DAC'yi sorgularsanız verileri beklendiği gibi alırsınız), yani meydan okuyan kişi yalan söylemesine rağmen yalan söylüyormuş gibi görünür. değildi.

Bu soruna çözümünüz, sıralayıcının yalnızca bir oyun için asla yalan söylemeyeceğini varsaymaksa, neden bunun yerine standart bir DAC kullanmayasınız? Ek olarak, sıralayıcının dürüst olduğunu varsaymak, paylaşılan sıralayıcı "süper zincir" kavramıyla pek uyumlu değildir; bu, varlıkların OP Yığın zincirleri arasında aktarılmak üzere paylaşılan sıralayıcıyı kullanamayacağı anlamına gelir (bu nedenle Redstone olmadığı sürece Arbitrum Nova ile aynı sorunla karşılaşırsınız) L3 olarak konuşlandırılır)

Lattice ekibinin bunu nasıl ele almayı planladığı, daha fazla belge ve yol haritası bilgisi sunuldukça dikkat edilmesi gereken önemli nokta olacak.

Alternatif #4: ​ZK​Kullanın

Redstone'u etkileyen verilerin paylaşılmaması sorununun (veri saklama saldırıları) Optimistic toplamalara özel olmadığını unutmayın. Verileri zincir dışında depolanan ("Validium'lar" olarak adlandırılır) ZK Toplamaları da aynı sorundan muzdariptir; bu nedenle insanlar genellikle toplamalarla (tüm verileri bir zincire gönderen) daha fazla ilgilenir.

Bu nedenle ZK toplamaları genel olarak oyununuzun veri maliyetini güvenli bir şekilde azaltmanıza yardımcı olmayacaktır. Kesinlikle oyununuzu başka birçok yolla ölçeklendirmenize yardımcı olabilirler (kullanıcının yerel makinesine daha fazla hesaplama taşımak, birçok etkileşimi toplama tarzında veya durum kanalı tarzında bir araya getirmek için özyinelemeli kanıtları kullanmak, vb.), ancak bu, üzerinde çalışılması gereken bir konudur. gelecekteki gönderi.

Sorun Solidity'deyse oyunumun maliyetlerini nasıl daha da düşürebilirim ?

Bu blog yazımızın tamamında depolama maliyetlerinin nasıl ele alınacağından bahsettik. Ancak bazı oyunlar CPU sınırlı olabilir (işlettikleri merkezi bir EVM zincirinde çalışsalar bile). Eğer bu sizseniz, Paima Engine'i kullanarak oyununuzu EVM sınırlarının ötesine ölçeklendirmenize olanak tanıyan bir Sovereign toplaması kullanmak ilginizi çekebilir.

Paima Engine, Javascript'te seçtiğiniz herhangi bir EVM zincirine (Redstone dahil!) dağıtabileceğiniz uygulamaya özel durum makineleri oluşturmanıza olanak tanır. Bu egemen toplamalar EVM bilgilerine (MUD motoru verileri dahil) erişebilir ve böylece oyununuzun herhangi bir bölümünün çok daha hızlı ve daha ucuz çalışmasını sağlamanın harika bir yolu olarak hareket edebilir.

​Sonuç​

Sonuç olarak, veri maliyetini azaltmak, zincir içi oyun maliyetlerini düşürmenin en önemli adımıdır. Günümüzde farklı ödünleşimlere sahip birçok farklı mevcut çözüm var ve Redstone kendisini standart DAC'den daha güvenli olarak tanıtıyor, ancak anlamlı bir şekilde daha güvenli olup olmadığı ve farkın geçerli bir alternatif olacak kadar anlamlı olup olmadığı henüz bilinmiyor. DA katmanı destekli çözümlere. Hesaplamayı veri üzerine ölçeklendirmesi gereken projeler için, sorunun üstesinden gelmek üzere Paima Engine gibi çözümler mevcuttur.

Son bir sorumluluk reddi beyanı olarak, Redstone ayrıntılarının henüz tam olarak açıklanmadığını unutmayın. Bu blog yazısı size gelecekteki duyurularını anlamanız için doğru zihinsel modeli sunacaktır; bu yüzden açık fikirli olalım ve ileriye yönelik neler önerdiklerini görelim.

Paima​Stüdyoları​

Nisan 2022'de kurulan Paima Studios, zincir üstü oyunlar, oyunlaştırma ve otonom dünyalar oluşturmaya olanak tanıyan yeni katman 2 teknolojisi kullanılarak oluşturulmuş bir Web3 motoru olan Paima Engine'in temel geliştiricileridir. Paima Engine, Web2 becerileriyle kullanılabildiğinden ve kullanıcıları veya geliştiricileri yaygın Web3 risklerine ve saldırılarına maruz bırakmadığından Web3'e girmenin güvenli ve kolay bir yoludur.

• Paima Engine kod tabanı: https://github.com/PaimaStudios/paima-engine
• Paima belgeleri: https://docs.paimastudios.com/
• Paima şablonu: https://github.com/PaimaStudios/paima-game-templates
• Paima NPM paketi: <a href="https://www.npmjs.com/package/@paima/sdk""> https://www.npmjs.com/package/@paima/sdk

Ayrıca sosyal medyamızdan daha fazla bilgi edinebilirsiniz:

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

Birlikte çalışmak ister misiniz? İletişim sayfamız aracılığıyla bize ulaşmaktan çekinmeyin: https://paimastudios.com/contact/

Yasal Uyarı:

1. Bu makale [blog.paimastudios] adresinden yeniden basılmıştır. Tüm telif hakları orijinal yazara [paimastudios] aittir. Bu yeniden basıma itirazlarınız varsa lütfen Gate Learn ekibiyle iletişime geçin; onlar konuyu hemen halledeceklerdir.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve görüşler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri Gate Learn ekibi tarafından yapılır. Aksi belirtilmedikçe tercüme edilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.