On-chain ve Web2 oyunları: varlıklar, ilerleme ve kurallar nerede saklanır

Ana fark, «gerçeğin kaynağı»nın nerede olduğudur: stüdyonun sunucularında mı, yoksa akıllı sözleşmelerde mi. Bu da projenin kapanması hâlinde oyuncuda neyin kalacağını belirler.

||
Güncellendi

Karşılaştırma ölçütü: state nerede saklanır, kurallar nerede yürütülür

«On-chain games vs Web2 games» — on-chain oyunlar ile Web2 oyunlarının mimari karşılaştırması: kuralların nerede yürütüldüğü ve oyun state’inin (ilerleme, envanter, karakter parametreleri) nerede saklandığı.

«NFT’li oyunlar» ile fully on-chain arasındaki temel fark, birinde token on-chain olabilirken ilerlemenin ve kuralların sunucuda kalabilmesidir.

  • Web2 → eşyalar ve ilerleme, geliştiricinin veritabanındaki kayıtlardır; erişim hesap ve servis kurallarıyla belirlenir.
  • On-chain → mantığın ve/veya state’in bir kısmı blokzincirde sabitlenir; varlıklar NFT olabilir, eylemler ise işlemlere (transactions) dönüşür.
  • Web3-hibrit → NFT cüzdanda saklanabilir, ancak oynanış ve ilerleme genellikle sunucuda güncellenir.
  • Fully on-chain → kurallar ve state akıllı sözleşmelerde bulunur; istemci uygulamalar değişebilir, ancak yürütme kuralları ve sözleşme state’i (olaylar ve sözleşme kayıtları) ağda kalır.

Temel sonuç: Web2’de sunucular kapatıldığında erişim ve ilerleme genellikle durur. Web3-hibritte NFT çoğu zaman cüzdanda kalır, ancak kullanım kuralları ve ilerleme sunucu taraflıysa oyun içi utiliti ortadan kaybolur.

«Gerçeğin kaynağı» — varlığa ilişkin hakları ve nihai state’i saklayan katman: stüdyonun sunucusu/veritabanı mı, yoksa akıllı sözleşme ve ağ verileri mi.

On-chain ve Web2 oyunları: görsel karşılaştırma — solda sunuculu Web2 ve «server off» durumunda duran ilerleme, sağda blokzincir, akıllı sözleşme, cüzdan ve adres sahibinde kalan NFT ile on-chain model.

Güncelleme: Web3-hibrit ve fully on-chain tanımları netleştirildi, «gerçeğin kaynağı» kontrol ölçütleri ve «server off» senaryosunun sonuçları eklendi.

4 maddede sonuç: Web2, hibrit ve fully on-chain

Karşılaştırma ölçütleri: ilerleme (state) nerede saklanır ve kuralları kim doğrular (sunucu mu akıllı sözleşme mi).

  • Önemli olan NFT’nin varlığı değil, ilerlemenin nerede saklandığı ve kuralların hangi katmanda yürütüldüğüdür.
  • Web2 → sunucu — tek gerçeğin kaynağı ve tek arıza noktasıdır.
  • Web3-hibrit → token cüzdanda kalabilir, ancak kullanım kurallarını çoğu zaman sunucu belirler.
  • Fully on-chain → kurallar ve state sözleşmelerde; istemci, ağ verilerine arayüzdür.

Modellerin karşılaştırması: varlıklar, ilerleme, sunucu bağımlılığı

Katmanlara göre karşılaştırma: gerçeğin kaynağı, varlıklar, ilerleme, sunuculara bağımlılık ve servisin kapanması durumunun sonuçları.

Parametre Web2 Web3-hibrit
(kısmen on-chain)
Fully on-chain
Gerçeğin kaynağı Stüdyonun sunucusu/veritabanı Sunucu + bazı haklar/varlıklar için blokzincir Akıllı sözleşmeler ve ağ verileri
Varlıklar Oyun içi kayıt Cüzdandaki NFT/tokenlar; utiliti çoğu zaman sunucu tarafından belirlenir NFT/tokenlar + kullanım kuralları sözleşmede
İlerleme (state) Sunucu taraflı Genellikle sunucu taraflı On-chain (sözleşme state’i)
«Sunucu kapatıldı» Erişim ve ilerleme genellikle sona erer NFT kalabilir, ancak modlar/kurallar/ilerleme kaybolabilir Kurallar ve state ağda kalır, arayüz değişebilir
UX/hız En yüksek Orta (cüzdan, imzalar) Ödünleşim (ücretler, gecikme, erişim altyapısı)
Ana riskler Merkezileşme: stüdyo kuralları ve erişimi değiştirebilir Token vardır, ancak utiliti sunuculara bağlıdır Sözleşme güvenliği + ölçeklenebilirlik ve UX
GameFi pratikte: «token sahipliği» nerede, «servis kurallarına göre erişim» nerede
Bu analiz, mimariyi (sunucu/sözleşme) tipik GameFi modelleri (P2E/P&E) ve token ile NFT utilitisi için risklerle eşleştirmeye yardımcı olur.

Okuma için terimler: NFT, on-chain/off-chain, akıllı sözleşme, state

Karşılaştırma için minimum kavram seti: neyin varlık olduğu, state’in nerede saklandığı ve kuralların nerede yürütüldüğü.

  • NFT — blokzincirde benzersiz bir token; dijital bir nesnenin (örneğin bir eşyanın) sahipliğini doğrular.
  • Akıllı sözleşme — blokzincirde kuralları yürüten ve verileri saklayan/güncelleyen kod.
  • On-chain — eylem veya veri blokzincir ağında kaydedilir.
  • Off-chain — eylem veya veri blokzincir dışında saklanır (sunucu, istemci, kapalı veritabanı).
  • Fully on-chain — oyunun mantığı ve durumu blokzincirdedir; istemci, sözleşme verileri ve kurallarına arayüzdür.
  • Gerçeğin kaynağı — nihai durumu belirleyen katman: varlığın sahibi kim, seviye kaç, envanter ne.

Model sınırları: Web2 oyunu, Web3-hibrit, fully on-chain

Yürütme ölçütüne göre ayrım: «tokenleştirilmiş varlıklar» ile «kurallar ve state sözleşmelerde» farklı modellerdir.

Web2 oyunları: state (ilerleme, envanter, karakter parametreleri) merkezî sunucularda saklanır ve güncellenir.

On-chain oyunlar: eylemler ve/veya state blokzincirde kaydedilir ve akıllı sözleşme kurallarıyla yürütülür.

Web3-hibrit: varlıklar tokenleştirilir (NFT/tokenlar), ancak mantığın ve ilerlemenin önemli kısmı off-chain kalır.

Fully on-chain: blokzincir yürütme katmanı olarak kullanılır: mantık ve state sözleşmelerdedir, arayüzler farklı olabilir.

Temel tez: NFT’nin varlığı utiliti’nin korunacağını garanti etmez. Utiliti ancak kullanım kuralları ve/veya kritik state sözleşmelerde sabitlenmişse ya da sözleşme state’ini okuyan ve aynı kuralları yürüten uyumlu bir istemci varsa korunur.

Varlık hakları: «veritabanında» vs «cüzdanda»

Token sahipliği ile oyun içi utiliti’nin varlığı farklı durumlardır; çünkü farklı katmanlar tarafından belirlenir.

Web2: varlık geliştiricinin sisteminde bir kayıt

Eşya veritabanında bir satırdır; erişim ise hesabın servis işlevlerini kullanma hakkıdır.

  • Hesap ve platform kuralları, hangi eşyaların ve modların erişilebilir olduğunu belirler.
  • Hesap engeli veya servisin kapanması genellikle eşyalara ve ilerlemeye erişimi sona erdirir.
  • Transfer ve ticaret çoğunlukla ürün kuralları ve stüdyo altyapısıyla sınırlandırılır.

Sonuç: varlık servis dışında bağımsız bir nesne değil, veritabanındaki bir kayıt olarak kalır.

Web3: varlık cüzdan adresinde bir token (NFT/token)

Sahip, token’ı anahtarlarla kontrol eder; ancak utiliti, token kullanım kurallarının nerede yürütüldüğüne bağlıdır.

  • Token, oyun hesabından bağımsız olarak kalabilir; çünkü kayıt ağdadır.
  • Token kullanım kurallarını sunucu belirliyorsa, stüdyo token’a dokunmadan utiliti’yi kapatabilir.
  • Servis kapandıktan sonra, uyumlu istemciler veya on-chain kullanım kuralları yoksa token’ın fiyatı düşebilir.

Sonuç: token adreste kalabilir, ancak sunucu taraflı kurallar ve ilerleme kapanınca «oyun içi fayda» ortadan kaybolur.

Ayrım: «cüzdanda NFT» token sahipliğini ifade eder. «Token oyun hakları verir» ifadesi, kullanım kurallarının hangi katmanda tanımlandığı ve yürütüldüğüne bağlıdır.

Temel fikir: sunucu utiliti’yi servis etmeyi bıraktığında NFT kalabilir.

İlerleme ve doğrulamalar: sunucu state’i vs sözleşme state’i

Temel soru: state nerede güncellenir ve durum geçişlerini hangi katman doğrular — sunucu mu akıllı sözleşme mi.

Sunucu state’i: ilerleme servis veritabanında saklanır; «resmî sürüm» sunucu tarafından belirlenir.

Sözleşme state’i: ilerleme akıllı sözleşme verilerinde ve ağ olaylarında (events) kaydedilir; geçişler sözleşme mantığıyla doğrulanır.

Karşılaştırılan Sunucu state’i Sözleşme state’i
İlerleme nerede saklanır Servisin veritabanı Sözleşme verileri + ağ olayları
Geçişleri kim doğrular Sunucu mantığı ve servis kuralları Akıllı sözleşme mantığı (neyin izinli, neyin yasak olduğu)
Nihai sürümü kim belirler Tek hakem olarak sunucu Gerçeğin kaynağı olarak ağ ve sözleşme
Admin değişiklikleri Mümkün (ör. ödül dağıtımını geri alma) Sözleşme kuralları ve işlemlerle sınırlı
Sonuç nasıl doğrulanır Servis ve hesap verilerine göre Ağ verilerine göre (sözleşme state’i ve olaylar)
Servis kapalıysa İlerleme ve «resmî sürüm» veritabanıyla birlikte kaybolabilir State ve olaylar ağda kalır, arayüz değişebilir

Örnek: sezon sonucu (sıralama ve ödül) on-chain kaydedildiyse, istemci değişse bile ağ verileriyle doğrulanabilir; sezon sonucu sunucuda saklanıyorsa, «resmî sürüm» servis kapatıldığında kaybolur.

Ödünleşim: on-chain haklar ve on-chain sonuçlar, off-chain oynanış

  • On-chain: sahiplik, nadir ödüller ve sezon sonuçları (sunucudan bağımsız doğrulanması gerekenler).
  • Off-chain: hız ve UX için yüksek frekanslı eylemler (savaş, hareket, matchmaking).
  • Sonuç: on-chain, her eylemi değil nadir ama anlamlı olayları sabitler.

Haklar ve nihai sonuçlar sözleşmelere ne kadar çok yazılırsa, sahiplik ve sezon sonuçlarını doğrulamak için sunucu bağımlılığı o kadar azalır.

Servisin kapanması senaryosu: her modelde ne kaybolur

Sunucuların kapanması, varlıkları ve ilerlemeyi farklı etkiler; çünkü modellerde gerçeğin kaynağı farklıdır.

Web2: altyapının kapanması, sunucu state’inin güncellenmesini ve hesaba veri sunulmasını durdurur.

Sonuç: ilerlemeye ve eşyalara erişim genellikle servisle birlikte sona erer.

Web3-hibrit: NFT ağda bir kayıt olarak adreste kalır, ancak sunucu taraflı unsurlar (ilerleme, modlar, kullanım kuralları) kaybolabilir.

Sonuç: token vardır, ancak sunucular kapanınca utiliti durur.

Fully on-chain: mantık ve state sözleşmelerde olduğu için veriler tek bir şirkete bağlı olmadan ağda kalır.

Sınırlama: rahat erişim, istemci uygulamalarına ve veri okuma altyapısına (RPC ve indexer’lar) bağlıdır.

On-chain sınırlamaları: ücretler, gecikmeler, UX ve sözleşme riski

On-chain doğrulanabilirliği artırır, ancak ücretler, gecikmeler ve anahtar yönetimi gereksinimleri ekler.

  • Throughput ve gecikmeler: eylemlerin kaydı işlemler ve onaylar gerektirir.
  • İşlem maliyeti: state’i on-chain saklamak ve güncellemek pahalı olabilir.
  • UX engelleri: cüzdan, anahtarlar, imzalar ve erişim kurtarma ayrı bir risk katmanıdır.
  • Erişim altyapısı: RPC, indexer’lar ve arayüzler state okumayı kolaylaştırma ve erişilebilirliği etkiler.
  • Sözleşme güvenliği: kod hataları ve yanlış izinler, state ve varlıklar için geri döndürülemez sonuçlara yol açar.

Oyun tasarımı sonucu: sık mikro eylemler nadiren on-chain taşınır; daha çok nadir ama anlamlı olaylar (haklar, ödüller, sezon sonuçları) on-chain sabitlenir.

Hibritin popüler olma nedeni: blokzincir haklar ve ekonomik olaylar için kullanılır; yüksek frekanslı oynanış, her eylemde ücret ve gecikmeden kaçınmak için off-chain bırakılır.

Temel ödünleşim: on-chain doğrulanabilirlik, ücret ve UX sürtünmesiyle ödenir.

Cüzdan = anahtar kontrolü: varlıklara erişimi kaybetmemek
On-chain sahiplik yalnızca seed phrase ve yedeklerin kontrolüyle korunur. Rehber, tek arıza noktası olmadan saklama ve kurtarmayı açıklar.

Seçim ölçütleri: on-chain ne zaman değer katar, ne zaman katmaz

Mimariye göre filtre: varlık hakları ve doğrulanabilir sonuçların önemli olduğu yerler ile hız ve kesintisiz UX’in daha önemli olduğu yerler.

On-chain daha sık anlamlıdır

Değerin sahipliğe, kökene ve ikincil piyasaya bağlı olduğu durumlarda.

  • İkincil piyasanın önemli olduğu koleksiyon eşyaları ve kartlar.
  • Ağ olaylarıyla doğrulanabilen kurallara sahip kaynak ekonomileri ve crafting.
  • Varlık haklarını ve sezon sonuçlarını korumanın kritik olduğu uzun ömürlü dünyalar.

Web2 çoğu zaman daha rasyoneldir

Hızın, düşük sürtünmenin ve her eylemde ücret olmamasının daha önemli olduğu durumlarda.

  • Gecikmenin kritik olduğu real-time türler (FPS, aksiyon).
  • Cüzdan ve imza olmadan kitlesel onboarding’e sahip casual oyunlar.
  • Eşyaların servis dışında bir değerinin olmadığı projeler.
GameFi ekonomisi kontrolü: ödüller, sinks, talep ve «emisyon talebin üzerinde» riski
Ekonomi token ve piyasaya bağlıysa, sürdürülebilirlik emisyon, sinks (token’ı dolaşımdan çıkaran mekanizmalar) ve talep dengesine bağlıdır. Analiz, girişten önce dengesizlikleri tespit etmeyi gösterir.

Örnekler (yaklaşımlar için referanslar)

Bu bir öneri ve kalite değerlendirmesi değildir. Bölümün amacı, piyasanın farklı mimarileri genellikle nasıl adlandırdığını göstermektir.

Ölçütlerle kontrol: (1) ilerleme hesapta mı sözleşmede mi saklanır? (2) resmî site olmadan state’i görüntüleyen alternatif bir istemci/izleyici var mı? (3) NFT utiliti’si sözleşme tarafından mı yoksa sunucu kurallarıyla mı belirlenir?

  • Tokenleştirilmiş varlıklar (çoğu zaman hibrit) → eşyalar ve karakterler NFT, ancak oynanış ve ilerleme off-chain.
  • Ekonomik ve koleksiyon formatları → daha sık on-chain varlık haklarını ve varlıklar etrafındaki piyasa kurallarını sabitler.
  • Fully on-chain yönelimler → kuralları ve state’i sözleşmelerde tutmaya çalışır; istemci, ağ verilerine arayüzdür.

Kontrol ölçütü: NFT’nin varlığından ziyade, ilerlemenin nerede saklandığı ve kuralların hangi katmanda yürütüldüğü daha önemlidir.

Üç yaygın algı hatası

Beklenti hataları genellikle «token sahipliği»nin «çalışan utiliti» ve «gerçeğin kaynağı» ile karıştırılmasından kaynaklanır.

«NFT var — demek ki oyunu kapatamazlar»

Token ağda var olabilir, ancak sunucu oynanışı ve sunucu ilerlemesi kaybolabilir.

  • Token sahipliği, servisin oyun kurallarını sürdürmesi için bir yükümlülük oluşturmaz.
  • Risk, ilerlemenin nerede saklandığına ve token kullanım kurallarının nerede yürütüldüğüne göre belirlenir.

Sonuç: kontrol, NFT’nin varlığıyla değil ilerleme ve kurallarla başlamalıdır.

«On-chain = tamamen merkeziyetsiz»

On-chain noktasal kullanılabilir: varlıklar için, ancak ilerleme ve maç kuralları için değil.

  • On-chain varlıklar, on-chain ilerleme anlamına gelmez.
  • Hibrit model, sunuculara kritik bağımlılıkları koruyabilir.

Sonuç: ilerleme ve kurallar için «gerçeğin kaynağı» sunucuda mı sözleşmede mi aranmalıdır.

«Fully on-chain’in sınırı yok»

Sözleşme state’i ağda kalır, ancak ücretler, gecikmeler ve okuma altyapısı üzerinden erişim UX’i etkiler.

  • Ücretler ve onaylar, on-chain eylem sıklığını sınırlar.
  • İstemcilerin, RPC’nin ve indexer’ların erişilebilirliği, state okumayı etkiler.

Sonuç: on-chain eylem sayısı ve tek bir frontend olmadan state görüntüleme imkânı değerlendirilmelidir.

SSS

On-chain gaming nedir?
Blokzincirin yürütme ve/veya depolama katmanı olarak kullanıldığı modeldir: mantık ve veriler akıllı sözleşmelerde yer alır, eylemler ve state on-chain kaydedilir.
Web2 ve Web3 oyunları arasındaki fark basitçe nedir?
Web2’de ilerleme ve kurallar şirketin sunucularındadır. Web3’te hakların ve varlıkların bir kısmı blokzincire taşınır (ör. cüzdanda NFT), ancak birçok projede ilerleme ve kurallar sunucu taraflı kalır.
Oyun kapanırsa NFT’ye ne olur?
Token genellikle ağda adreste kalır. Kullanım kuralları ve ilerleme sunucu taraflıydıysa ve artık servis edilmezse oyun içi utiliti kaybolur.
Cüzdan olmadan Web3 oyunları oynanabilir mi?
Bazı projeler Web2’ye benzer bir onboarding kullanır ve blokzincir öğelerini daha sonra devreye alır. Token’lara doğrudan sahiplik, cüzdan ve anahtar kontrolü gerektirir.
Sunucular olmadan ilerleme korunabilir mi?
Fully on-chain modelde — evet, state sözleşmeler tarafından saklanıp güncelleniyorsa. Birçok projede hız için ilerleme off-chain kalır.
Neden henüz az sayıda fully on-chain oyun var?
Çünkü eylemleri on-chain kaydetmek işlem ve onay gerektirir; bu da ücret ve gecikme yaratır. Bu nedenle on-chain, çoğu zaman her oynanış eylemini değil hakları ve ekonomik olayları sabitler.

Son kontrol: üç işaretle on-chain vs Web2

Model değerlendirmesi tek soruya iner: ilerleme ve kurallar için «gerçeğin kaynağı» nerede?

  • İlerleme: sezon sonucu ve kilit ödüller sözleşmeye yazılır ya da servis veritabanında kalır.
  • Kurallar: state geçişleri akıllı sözleşme tarafından ya da sunucu mantığıyla doğrulanır.
  • Kapanma riski: servis ortadan kalktığında yalnızca ağ verileri ve bunlara uyumlu erişim kalır.

İlerleme ve kurallar sunucuda yaşıyorsa, on-chain öğeler varlık olarak kalır; ancak oyunun «resmî sürümünü» korumaz.

Makale faydali miydi?

Yeni incelemeleri ve siralamalar kacirmamak icin guncellemelerimize abone olun

Tum Borsalari Gor →