Solana Katman 2'lere ve Appchainlere İhtiyaç Duyuyor mu?

Bir ay önce, Solana’nın en popüler tüketici uygulaması olan ve ünlü sanatçıların ücretsiz NFT’lerini dağıtan DRiP’in kurucusu Vibhu, aşağıdaki açıklamasıyla çok ihtiyaç duyulan bir tartışma başlattı: “Solana, Katman 2’lere ve/veya rolluplara sahip olacak ve bunlara ihtiyaç duyacaktır.”

Vibhu’nun hayal kırıklığı, SOL fiyatlarının yükselmesi ve ağın tıkanması nedeniyle DRiP’in temel katmana önemli miktarda değer (haftada yaklaşık 20.000 dolar) sızdırmasından kaynaklandı. Solana’da aktivite artışı şunlara yol açar:
Artıları: Gelişmiş likidite, sermaye ve işlem hacimleri (birleştirilebilirlik sayesinde).
Eksileri: Yüksek altyapı maliyetleri, kötü kullanıcı deneyimi ve ağ tıkanıklığı.
Ancak, haftada milyonlarca NFT’yi sanatçılardan binlerce cüzdana dağıtmak için Solana’yı yalnızca altyapı olarak kullanan DRiP, yüksek birleştirilebilirlikten yararlanamıyor. Solana’nın TVL’sindeki büyüme ve sermaye girişi, yüksek altyapı maliyetleri gibi dezavantajlardan muzdarip olan DRiP üzerinde çok az etkiye sahiptir.

Vibhu, “Birleştirilebilirliğin getirisi azalıyor” diyor. Ayrıca, Solana uygulama geliştiricilerinin rolluplara olan ilgilerini şu nedenlerle özel olarak tartıştıklarını da belirtiyor:

Artan işlem hacmi, daha az blok alanı rekabeti ve daha düşük ücretler.

İşletmelerinin yarattığı ekonomik değer üzerinde daha fazla kontrol.

Son birkaç ayda Solana, JUP gibi airdrop’lardan ORE madenciliğine ve memecoin işlemelerinin zirve yaptığı dönemlere kadar birçok tıkanıklık sorunu yaşadı. Her ne kadar Firedancer’ın tüm bu sorunları çözebileceği öne sürülebilse de, gerçekçi olalım: zaman çizelgesi belirsizliğini koruyor ve şu an için 10 katın üzerine ölçeklenemiyor. Buna rağmen, benzer sorunlar ile olan savaşta kendini kanıtlamış tüm büyük zincirler arasında Solana’nın sona kalan bir dev olduğu gerçektir.

Solana dev olarak mı kalmalı yoksa modüler hale mi gelmeli? Solana da Ethereum gibi parçalı Katman 2 ve Katman 3 çözümleriyle gelişecek mi? Solana’da appchain’ler ve rollupların mevcut durumu nedir?

Bu soruları ele almak ve tüm tartışmayı özetlemek için, bu makale tüm olasılıkları inceleyecek, çeşitli projeleri tartışacak ve bunların artılarını ve eksilerini değerlendirecektir. Bu makale teknik ayrıntılara derinlemesine girmeyecek, bunun yerine çeşitli ölçeklendirme yaklaşımlarını tartışırken daha piyasa odaklı ve pratik bir bakış açısı benimseyerek genel bir bakış sunacaktır.

Özetle, şu konuları ele alacağız:

• Solana ve Ağ Tıkanıklığı
• Solana’yı Modüler Hale Getirmek
• Solana Appchain’leri, örneklerle
• Sollana Katman 2’ler ve Rolluplar (RollApps), örneklerle
• Altyapı Güçlendirme Rollupları ve Appchain’ler

  Solana ve Ağ Tıkanıklığı

  Öncelikle, herkesin bildiği bir sorunu ele alalım: Solana ağı, airdrop’lar, önemli miktarda memecoin işlemleri ve benzeri nedenlerle son zamanlarda oldukça yoğunlaştı (bu sorun şu anda çoğunlukla çözüldü). Bu durum, yüksek ping sürelerine, yüksek oranda başarısız işlem oranına ve daha yüksek öncelik ücretleri nedeniyle artan ağ ücretlerine yol açtı. Tüm bunlara rağmen, Solana sürekli olarak 1-2 bin TPS işleme kapasitesini korumuş ve tüm EVM zincirlerinin toplamından daha fazla işlem gerçekleştirmiştir. Bu, bir blokzinciri için iyi bir sorun olarak düşünülebilinir ve aslında Solana’nın bir dev olma tezini de sınamış oldu.

Solana Vakfı kısa süre önce yayınladıkları bir blog yazısında projelerin ağ performansını artırmak için acil önlemler almasını istedi. Bu önlemler arasında şunlar yer alıyor:
Öncelikli ücretlerin uygulanması: İşlemlerin gecikmesini veya iptal edilmesini önlemek için çok önemlidir.
Program Hesaplama Birimi (CU) kullanımını optimize etme: Yalnızca gerekli olanı kullanma.
Hisse ağırlıklı Hizmet Kalitesi (QoS) uygulamak: Uygulamaların kullanıcılarının işlemlerini önceliklendirmesine olanak tanımak.

Ancak, tüm bu önlemler işlemlerin tamamlanmasını yalnızca bir miktar iyileştirir ve sorunsuz bir işlem deneyimi garanti etmez. Bu soruna yönelik hızlı bir çözüm, Nisan ayı sonunda yayınlanması planlanan 1.18 sürümünde yer alacak olan ve merakla beklenen yeni İşlem Zamanlayıcıdır. Bu zamanlayıcı, mevcut zamanlayıcıyla birlikte sunulacak ancak varsayılan olarak etkinleştirilmeyecektir. Böylece, doğrulayıcılar yeni zamanlayıcının performansını izleyebilecek ve herhangi bir sorun ortaya çıkması durumunda eski zamanlayıcıya kolayca geri dönebileceklerdir. Bu yeni zamanlayıcı, eski zamanlayıcının verimsizliklerini gidererek blokları daha verimli ve ekonomik bir şekilde doldurmayı amaçlamaktadır.

Anza (Solana Labs’ın bir yan kuruluşu), QUIC uygulamasıyla ilgili sorunlar olarak tanımlanan ağ tıkanıklığını ve Agave (Solana Labs) doğrulayıcı istemcisinin çok sayıda isteği işleme koyması gerektiğinde sergilediği davranışı çözmek için sürekli çaba göstermektedir.

Modülerliğin savunucuları Solana için ‘modüler bir yol haritasını’ şiddetle savunurken, Solana Labs/Anza (Solana protokolünün ana bakımcısı) temel katmanın verimini ve gecikme süresini optimize etmeye odaklanmaya devam ediyor. Bazı olası iyileştirmeler şunlardır:

• Ücret piyasalarının yeniden düzenlenmesi ve temel ücretlerin artırılması (şu anda 5.000 Lamport veya 0,000005 SOL olarak belirlenmiştir).
• Hesaplar için üstel yazma kilidi ücreti uygulamak, yani spam’leri önlemek için ücretleri zaman içinde kademeli olarak artırmak.
• Ceza sistemi aracılığıyla CU bütçe taleplerinin optimize edilmesi.
• Genel ağ mimarisinin iyileştirilmesi.
  Dikey ölçeklendirmedeki (tek zincir) bu iyileştirmelere rağmen, Solana’nın yatay ölçeklendirmeyi (rollup’lar) benimseme olasılığını göz ardı edemeyiz. Aslında Solana, her ikisinin bir melezi haline gelebilir; rolluplar için mükemmel bir temel katman görevi görebilir ve ardışıklayıcılardan süper hızlı yumuşak onay alma gibi rolluplara önemli faydalar sağlayacak süper düşük gecikmeli blok süreleri (~400 ms) sunabilir. En iyi yanı, Solana’nın tarihsel olarak değişiklikleri hızlı bir şekilde uygulamasıdır, bu da Solana’yı Ethereum’dan daha verimli bir rollup katmanı haline getirebilir.

Güncelleme: Anza, devam eden ağ tıkanıklığını azaltmaya yardımcı olacak bazı yamalar yayınladı ve v1.18 sürümünde daha fazla iyileştirme yapılacak.

Solana’yı Modüler Hale Getirmek

Solana’yı modüler hale getirme çalışmaları çoktan başladı. Anza DevRel’in gönderisinde belirtildiği gibi, Solana doğrulayıcı ve SVM (işlemleri ve akıllı sözleşmeleri/programları işleyen yürütme ortamı) birbiriyle sıkı bir şekilde bağlantılıdır ve Anza (Solana Labs’tan ayrılan bir kuruluş) tarafından yönetilmektedir. Ancak, doğrulayıcı istemcisi ve SVM çalışma zamanı önümüzdeki birkaç ay içinde ayrılacaktır. Bu ayrılma, SVM’nin çatallanmasını ve “Solana appchain’lerinin“ kolayca oluşturulmasını sağlayacaktır. Rollup’lar için, bu avantaj Solana’nın Veri Kullanılabilirliği (DA)/blob katmanının optimize edilmesinden kaynaklanabilir, ancak bu daha sonraki bir aşamada gerçekleşebilir.

Joe C (Anza’da mühendis), işlem işleme iletişim hattının doğrulayıcıdan çıkarılıp SVM’ye yerleştirileceği SVM’yi modüler hale getirme planlarını da açıkladı. Bu sayede geliştiriciler, SVM’nin uygulamasını çalıştırabilecek ve herhangi bir doğrulayıcıdan bağımsız olarak çalışabilecek.

İzole edilmiş SVM, tamamen bağımsız modüllerden oluşan bir yapı olacak. Herhangi bir SVM uygulaması, bu modülleri iyi tanımlanmış arayüzler aracılığıyla çalıştırabilir ve özel çözümler tasarlamak için gereken ek yükü önemli ölçüde azaltarak SVM uyumlu projeler için engelleri daha da azaltabilir. Takımlar, ilgilendikleri modülleri uygularken, Agave veya Firedancer gibi diğer modüller için mevcut uygulamaları da kullanabilirler.

Kısaca, Solana daha fazla tak ve çalıştır özelliğine sahip olacak ve Solana appchain’lerini ve rollup’ları çok daha kolay hale getirecektir.

Genel olarak, bunun iki yönü vardır: Katman 2/Rollup’lar ve Appchain’ler. Her ikisine de tek tek bakacağız.

Solana Appchain’leri

SVM çatalları olarak da bilinen bu çatallar, esasen belirli uygulamalara adanmış Solana zincirinin çatallarıdır. Pyth, ilk Solana appchainiydi, ancak bu konsept, en büyük DeFi protokollerinden biri olan Maker’ın kurucusu Rune’un, Solana (SVM) kod tabanını temel alan bir Maker appchaini (yönetişim için) geliştirme önerisiyle büyük yankı uyandırmasıyla çok dikkat çekti. Rune, güçlü geliştirici topluluğu ve diğer VM’lere göre teknik üstünlüğü nedeniyle SVM’yi seçti ve tüketici ihtiyaçlarını daha iyi karşılamak için en performanslı zinciri çatallamayı hedefledi. Henüz hiçbir şey uygulanmamış olsa da, bu hamle Solana appchain’leri hakkında çok ihtiyaç duyulan bir tartışma başlattı.

Genel olarak iki türde olabilir:

İzinsiz: Mevcut Solana ana ağına benzer şekilde, herkes ağa katılabilir.
İzinli: Solana Vakfı tarafından kurumlar için “Solana İzinli Ortamlar (SPE)“ olarak paketlenmiş olan bu ürün, kuruluşların SVM tarafından desteklenen kendi zincir örneklerini oluşturmalarına ve sürdürmelerine olanak tanır.

Pyth: Orijinal Solana Appchain

Bir zamanlar, Pyth, Solana ana ağındaki tüm işlemlerin %10-20’sini oluşturuyordu. Ancak, herhangi bir birleştirilebilirlik gerektirmediğinden, Solana kod tabanını basitçe çatalladılar. Bu, yüksek frekanslı fiyat güncellemeleri için Solana’nın 400 ms’lik hızlı blok süresinden yararlanmalarını sağladı. Pythnet, appchain’i için SVM’yi benimseyen ilk ağdır.

Pythnet appchain’i Solana’nın ana ağının Proof-of-Authority (Yetki Kanıtı) çatalıdır ve Pyth’in veri yayıncıları ağı tarafından sağlanan verileri işlemek ve toplamak için bir hesaplama tabanı katmanı görevi görür.

Pyth neden taşındı?

Yüksek birleştirilebilirlik gerektirmiyordu (özellikle Solana dışı uygulamalar için) ve bu sayede ana ağın tıkanıklığından muaftı.

Verileri yayınlamak için izinli bir ortam gerekiyordu.

Altyapı maliyetlerini, daha önce temel katmana (Solana) sızan ücretleri içselleştirerek düşürmek.

Cube Exchange, tamamen zincir dışı bir emir defteri ve SVM appchaininde gerçekleştirilen uzlaşma işlemleriyle, egemen bir SVM appchaini olarak dağıtılan bir başka hibrit CEX örneğidir.

Solana Appchain’lerinin bazı örnekleri şunlar olabilir:

• Sürekli Vadeli DEX’leri: Hyperliquid gibi, Sürekli Vadeli DEX’ler de ayrı Katman 1 ağları olarak çalışabilir. Ayrıca, alım satım kullanım örnekleri için blok başına işlem sayısı özelleştirilebilir veya koşullu mantık uygulanabilir. Örneğin, zararı durdur emrinin doğrudan Katman 1’e entegre edilmesi, durum geçişi olarak uygulanmasının sağlanması veya uygulamaya özgü atomik mantığın getirilmesi gibi.
• Yapay Zeka ve DePIN: Bunlar, Pyth gibi kontrollü bir hizmet sağlayıcı listesini içerebilir. Örneğin, Akash, Cosmos appchain’i aracılığıyla bir bilgi işlem piyasası olarak faaliyet göstermektedir.
• Yönetişim appchain’leri: MakerDAO’nun SVM appchain’ine olan ilgisiyle doğrulanmış, egemen bir yönetişim appchain’i ilgi çekici olabilir. Kripto para birimlerinde yönetişim hala gelişme aşamasındadır ve özel bir zincir-çatallama mekanizması, koordinasyon için yararlı bir araç olabilir.
• Geleceğin kurumsal appchain’leri: Potansiyel uygulamalar arasında fonlar (BlackRock gibi) veya ödeme sistemleri (Visa veya CBDC’ler gibi) yer almaktadır.
• Oyun Appchain’leri: Solana’da bir kumarhane oyun projesi, kendi appchain’ini oluşturmayı düşünüyor.
• Solana’nın değiştirilmiş çatalları: Monad veya Sei’nin optimize edilmiş EVM’ler (paralelleştirilmiş) sunmasına benzer şekilde, birisi Solana’nın daha optimize edilmiş bir sürümünü oluşturabilir. Bu eğilim, özellikle Solana ana ağı yeni tasarım mimarilerini keşfetmeye başladıkça, önümüzdeki yıllarda daha yaygın hale gelebilir.

  Solana Appchain Stack Öngörüsü

  Bir appchain oluşturmak nispeten basit olsa da, tüm appchain’ler arasında bağlantı sağlamak, birlikte çalışabilirlik için çok önemlidir. Avalanche Subnets (yerel Avalanche Warp Messaging ile bağlantılı) ve Cosmos appchain’lerinden (IBC ile bağlantılı) ilham alan Solana, appchain’lerini birbirine bağlamak için yerel bir mesajlaşma çerçevesi de oluşturabilir.

Ayrıca, Cosmos-SDK benzeri bir orta katman yazılımı oluşturarak, oracle’lar (Pyth veya Switchboard gibi), RPC’ler (Helius gibi) ve mesajlaşma bağlantısı (Wormhole gibi) için yerleşik destek ile appchain’ler oluşturmak için anahtar teslimi bir çözüm sunmak da mümkündür.

Polygon AggLayer’da ilginç bir yaklaşım olabilir. Bu yaklaşımda, geliştiriciler herhangi bir Katman 1 veya Katman 2 zincirini AggLayer’a bağlayabilir ve AggLayer, bağlı tüm zincirlerden ZK kanıtlarını toplar.

Bir Appchain Ağının Oluşturulması Solana Ekosistemi için Olumlu mu Olur?

Appchain’ler, SOL’a doğrudan değer katmasa da (yeniden stake edilen SOL ekonomik güvenlik için kullanılmadıkça SOL’da ücret ödemedikleri veya SOL’u gas token’ı olarak kullanmadıkları için), SVM ekosistemine büyük fayda sağlarlar. Tıpkı “EVM ağ etkileri” olduğu gibi, daha fazla SVM çatalı ve appchain SVM ağ etkilerini güçlendirecektir. Eclipse’i (Ethereum üzerindeki Katman 2 SVM) SVM için yükseliş eğilimli kılan mantık, Solana ana ağına doğrudan rakip olmasına rağmen burada da geçerlidir.

Solana Katman 2’leri

Solana Katman 2’leri veya rollup’lar, verileri ana zincirlerinin Veri Kullanılabilirliği (DA) katmanına gönderen ve ana zincirin konsensüs mekanizmasını yeniden kullanan mantıksal olarak ayrı zincirlerdir. Celestia gibi diğer DA Katmanlarını da kullanabilirler, ancak bu durumda gerçek bir rollup olmaktan çıkarlar. “RollApp”, genellikle Uygulamaya Özel Rollup’lar (çoğu Solana uygulaması tarafından araştırılmaktadır) için kullanılan bir terimdir.

Solana Rollupları, Ethereum ile Aynı mı Olacak?

Görünüşe göre hayır. Solana için Rolluplar, son kullanıcılar için büyük ölçüde soyutlaştırılacaktır. İdeolojik açıdan, Ethereum rollupları genelde özeleydi. Ethereum Vakfı ve liderleri, ölçeklendirmenin en iyi yolunun rolluplar olduğunu kararlaştırdı ve CryptoKitties fiyaskosunun ardından çeşitli Katman 2’leri desteklemeye başladı. Solana’da ise talep, aşağıdan yukarıya doğru, yani tüketiciler tarafından büyük ölçüde benimsenen uygulama geliştiricilerinden geliyor. Sonuç olarak, mevcut roll-up stratejilerinin çoğu pazarlama stratejileridir ve tüketici talebinden çok anlatıma dayalıdır. Bu önemli bir farktır ve Ethereum’da gördüğümüzden farklı bir rollup geleceğine yol açabilir.

Sıkıştırma = Rolluplar mıdır?

Katman 2’ler, Katman 2 üzerinde işlemleri gerçekleştirerek, işlem verilerini toplu hale getirerek ve sıkıştırarak temel katman blokzincirlerini (Katman 1’ler) ölçeklendirir. Sıkıştırılmış veriler daha sonra Katman 1’e gönderilir ve sahtekarlık kanıtı (iyimser rollup) veya geçerlilik kanıtı (zk rollup) olarak kullanılır. Bu kanıtlama süreci “uzlaşma” olarak adlandırılır. Benzer şekilde, sıkıştırma işlemlerini ana ağdan yükleyerek temel katmanda durum için çekişmeyi azaltır. Özellikle, Grass Katman 2, rollup için Durum Sıkıştırmasını kullanacak.

Solana’da Rollupların Durumu

Şu anda “biraz rollapps” olarak görülen iki tanesi kullanılıyor:

• GetCode: Mikro ödeme SDK’sı içeren bir ödeme uygulaması, herkesin anında ödeme yapmasını ve ödeme almasını sağlar ve ayrıca uygulaması için sözde rollup yöntemi kullanır. Tüm işlemler için niyetler oluşturur ve N aralıklarla Solana’da yerleşen rollup benzeri bir sıralayıcı kullanır.
  Rollup benzeri bir yapı kullanmak şunları sağlar:
• Esneklik: Niyetler, sadece ödeme işlemleri değil, çeşitli gelecekteki faaliyetleri de temsil edebilir. Ayrıca, Solana bir zincir olarak da gerektiğinde değiştirilebilir.
• Anında ve Özel: Sıralayıcıların yumuşak kesinliği sayesinde, Solana’da tıkanıklık olsa bile ödemeler anında gerçekleşir. İşlemler zincir üzerinde görünür olsa da, kesin değer ve amaç gizli kalır, böylece kullanıcı gizliliği sağlanır.
• MagicBlocks tarafından sunulan Ephermal Rolluplar: MagicBlocks, bir web3 oyun altyapısı, özellikle oyunlar için Ephermal (veya geçici) rolluplar geliştirmiştir. SVM’nin hesap yapısını kullanır ve oyun durumu kümelere ayrılır. Durumu geçici olarak bir yardımcı katmana veya yapılandırılabilir özel bir katman olan “geçici yığına” aktarır. Geçici rollup, yüksek verimde işlem işlemeyi kolaylaştırmak için özel bir SVM çalışma zamanı veya rollup olarak çalışır.

Rollup benzeri bir yapı kullanmak şunları sağlar:

• Özel çalışma zamanının, gassız işlemler, daha hızlı blok zamanları ve bir zamanlama mekanizmasının (örneğin, saat gibi ve ücret almadan çalışan entegre bir işlem planlama sistemi) dahil edilmesi gibi özellikleri içerecek şekilde özelleştirilmesi.
• Geliştiriciler, programları ayrı bir zincir veya rollup yerine temel katmana (ör. Solana) dağıtacak. ER’ler mevcut ekosistemi parçalamaz ve izole bir ortam yaratmadan hedefli işlemlerin hızlanmasına olanak tanır. Bu, mevcut tüm Solana altyapısının kullanılabileceği anlamına gelir.
  Bu yaklaşım, talep üzerine rollup başlatabilen ve milyonlarca işlem gerçekleştiren kullanıcıları karşılamak için yatayda otomatik ölçeklenebilen, son derece ölçeklenebilir bir sistem sağlar; üstelik geleneksel L2’lerde tipik olarak görülen ödünler olmadan. MagicBlock özellikle oyunlara odaklanmış olsa da, bu yaklaşım ödemeler gibi diğer uygulamalara da uygulanabilir.

  Yaklaşan Solana Rollupları:

• Grass: Doğrulanmış veri toplama yoluyla yapay zeka veri sorunlarını çözmeyi amaçlayan bir DePIN projesi. Grass düğümleri yapay zeka eğitim verileri için web’i taradığında, doğrulayıcılar verileri zincir üzerinde depolar, verilerin nereden geldiğini ve hangi düğümün toplamadan sorumlu olduğunu hassas bir şekilde takip eder ve bu düğümlere orantılı olarak ödül verir.
• Zeta: Solana’daki en eski Sürekli Vadeli DEX’lerden biri olan ve tamamen zincir üzerinde sürekli vadeli emir defterine sahip olan Zeta, eşleştirme işlemlerini Solana rollup’u aracılığıyla zincir dışına taşımayı planlıyor.
  İlginç bir şekilde, Armani (Backpack’in kurucu ortağı) da artık Katman 2’ye yöneldiklerini tweetledi.

Ayrıca Sonic, oyunların Solana üzerinde kendi zincirlerini dağıtabilmelerini sağlayacak modüler bir SVM zinciri (Hypergrid) inşa ediyor. Eclipse ve NitroVM gibi SVM tabanlı Ethereum rollupları da SVM’yi yürütme motoru olarak kullanıyor. Neon, Solana üzerinde EVM uyumlu bir Katman 2 olarak işlev görüyor. Ayrıca, Molecule (bir SVM Bitcoin Katman 2) gibi fikir aşamasında olan projeler de var.

Sovereign SDK, node.js’ye benzer başka bir çerçevedir, ancak rolluplar oluşturmak için kullanılır. Kullanıcılar Rust kodlarını getirir, Sovereign SDK da bunları herhangi bir blokzincirinde dağıtılabilen Optimistic veya ZK rollup’lara dönüştürür. Rust kodu, özel bir uygulama mantığı veya herhangi bir VM olabilir.

Rolluplar Hakkında Birkaç Tez

Rolluplar SOL ile uyumlu olmalı: “ETH uyumlu” kavramı popüler bir meme haline geldi. Katman 2’ler ve Restaking/EigenLayer’ın neden en popüler konu haline geldiğini düşünüyorsunuz? Çünkü, ETH her yerde temel varlık olarak kullanıldığından, “ETH’nin parasal değerini” artırırlar. Aynı ilke Solana için de geçerlidir. Solana topluluğu, SOL varlıklarını artıracak her türlü çözümü destekleyecektir, bu kadar basit. Solana ekosistemi genişledikçe, bir zamanlar göz ardı edilen “SOL’un parasal değeri” önem kazanacaktır. Unutmayın, çoğu Rollup zaten bir “Pazarlama Stratejisi”dir ve piyasalar hala Uygulamalardan daha çok Altyapıya değer verdiği için daha iyi token değeri artışı sağlarlar.

Rolluplar, Solana’nın bir uzantısı gibi hissedilecek: Güvenlik avantajlarının ötesinde (yani, temel katmandan güvenlik özelliklerinin benimsenmesi), Solana kullanıcılarına ve varlıklara kolay erişim sunmak açısından önemli bir avantaj olacaktır. Jon Charbonneau’nun da belirttiği gibi, Base, Optimism ve Arbitrum gibi Ethereum Rollup’ları daha çok Ethereum’un uzantıları gibi hissediliyor. Kullanıcılar aynı cüzdanları ve adresleri kullanmaya devam ediyor, yerel gas token’ı ETH’nin tek doğal versiyonu, ETH tüm işlem çiftleriyle DeFi’yi domine ediyor, sosyal uygulamalar NFT’leri ETH ile fiyatlandırıyor ve yaratıcılara ETH ile ödeme yapıyor (ör. friend.tech) ve Katman 2’ye para yatırma işlemleri anında gerçekleşiyor vb. Benzer şekilde, aynı şey Solana’da da olacak. Ethereum’dan öğrenilenlerle, çoğu Solana Rollapp, kullanıcılara ayrı bir zincir kullanıyormuş gibi hissettirmeyecektir (örneğin, Getcode).

Solana, “Rolluplardan” daha fazla “RollApp’e” sahip olacak: Solana, yüksek gas ücretleri nedeniyle ana ağın kullanılamaz hale geldiği Ethereum gibi bir ölçeklendirme sorununa sahip değildir, çünkü son derece optimize edilmiştir. Ancak, özel blok alanı gerektiren bazı uygulamalar kendi rolluplarını oluşturacaktır. Solana’daki genel amaçlı Rolluplar mantıklı gelmese de, ekonomik açıdan projeler için mantıklıdır. Örneğin, Base kullanıcıları Coinbase için sadece bir günde 2 milyon dolar gelir elde etti! Geliştiriciler için teşvikler büyük ölçüde Katman 2’ye yöneliktir. Ancak, gözlem edildiği gibi, her EVM rollup’ı sıradan bir rollup gibi görünmektedir ve Linea, Scroll veya zkSync gibi çoğu, sadece token airdrop’ları için birkaç işlem gerçekleştiren kişiler tarafından kullanılan hayalet zincirler haline gelmiştir. Ayrıca, Solana’daki genel amaçlı Katman 2’lerin Ethereum’da görülen eski sorunlara, yani merkezi rolluplara, tıkanıklığa ve likidite parçalanmasına yol açabilir.

Neden bazı uygulamalar Rollapps/appchain’e geçmek ister?

Her uygulama başlangıçta Solana Ana Ağında çalışmaya başlar, çünkü paylaşılan altyapıda daha fazla uygulama barındırmak geliştiriciler ve kullanıcılar için karmaşıklığı önemli ölçüde azaltır. Ancak, bu uygulamalar büyüdükçe aşağıdakileri yapmak isteyebilirler:

Değer Yakalama: Tek bir uygulama için tasarlanmamış paylaşımlı bir Solana katmanında değeri içselleştirmek daha zordur. MEV yakalama, DEX’ler için bir başka kazançlı seçenek olabilir.

Özel Blok Alanı.

Özelleştirilebilirlik: Örneğin, Getcode, kullanıcılarının özel ödemelerini kolaylaştırmak için bir sıralayıcı kullanır. Ücret Piyasası Deneyimleri, MEV’i en aza indirmek için şifrelenmiş mempool’lar, Özel emir defterleri.

Ancak, tüm uygulamalar kendi Rolluplarını başlatmak istemeyecektir, özellikle belirli bir kullanım oranına ulaşmamış olanlar (örneğin, yeterli TVL, kullanıcı ve hacim). Bugün kendi zincirinizi başlatmak, çoğu uygulama, özellikle de erken aşamadaki uygulamalar için, artan faydalar için haklı gösterilemeyecek acı verici ve gereksiz ödünler (karmaşıklık, maliyet, daha kötü kullanıcı deneyimi, parçalanmış likidite vb.) gerektirir. Solana, SVM geliştirmenin kalbi ve ruhu olmaya devam ediyor ve bunun sonucunda birçok yeni uygulama devreye alınacaktır.

Uygulama Geliştiricileri için: Solana Ana Ağı veya Appchain veya Rollup tercihi tamamen duruma bağlıdır. Diğer tüm uygulamalarla birleştirilebilirliğe güçlü bir ihtiyaç yoksa, birkaç farklı bileşeni zincir dışına çıkarmak (appchain veya rollup) tamamen mantıklıdır. Bir kullanıcının, rollup veya appchain kullanıp kullanmadığını bilmesine gerek olmamalıdır. Grass, Zeta ve Getcode, kullanıcıları için kullandıkları tüm rollup tipi altyapıları soyutlaştırır. İzinli ve özelleştirme kullanım durumları için Token Extension, bileşim özelliğini korurken KYC/transfer mantığı gibi çoğu ihtiyacı da karşılar.

Peki, DRiP bir Katman2/Appchain olacak mı?

Şu anda DRiP, Solana’yı şu amaçlarla kullanmaktadır:

• Kullanıcı tarafından oluşturulan cüzdanlar (Katman 2/Appchain üzerinde olabilir)
• Sıkıştırılmış NFT’lerin dağıtımı (Katman 2/Appchain üzerinde olabilir)
• Sıkıştırılmış NFT alım satımı (Katman 2/Appchain üzerinde olabilir, ancak fonların köprülenmesi gerekir)
  Katman 2’ler/Appchain’lerin de sağlayabileceği teknolojinin yanı sıra, Solana Katman 1’de bulunmanın güçlü bir gerekliliği olmadığını açıkça görebiliriz. DRiP’in birincil hedefi her zaman web2 kullanıcıları olduğu için, bu kullanıcıları doğrudan kendi zincirine dahil edebilir, bu da uzun vadede çok daha yüksek kontrol sağlar, çünkü tüm değeri temel zincire (Solana) sızdırmaz. Ayrıca, DRiP belirli bir kullanım oranına ulaştı (Solana’daki en büyük tüketici uygulaması) ve artık kendi zincirine geçecek. Getcode gibi sözde bir rollup yapısı, DRiP için tamamen mantıklıdır.

  Rollup’ları ve Appchain’leri Güçlendiren Altyapı

  Rollapp/appchain tezi genişlerse, mevcut altyapı sağlayıcıları yeni piyasalara girerek büyük fayda sağlayacaktır:

Caldera gibi mevcut Rollup as a Service (RaaS) sağlayıcıları, talep ortaya çıktıkça SVM piyasasına kolayca girebilir. Eclipse ve NitroVM gibi SVM Ethereum rollupları da bu fırsatı yakından takip ediyor. Ayrıca, Sovereign Labs, Solana’da rollup’ları mümkün kılan bir Sovereign SDK Solana adaptörü sunmaktadır (henüz üretim aşamasına gelmemiştir).

Mert’in defalarca ima ettiği gibi, Helius da Solana Katman 2’leri için altyapı kurmaya uygun bir başka şirkettir.

Rome Protocol gibi Paylaşımlı Sıralayıcılar ve Tinydancer gibi hafif istemcilere duyulan ihtiyaç. Paylaşımlı sıralayıcılar, atomik arbitraj, MEV ve kesintisiz köprüleme gibi faaliyetleri mümkün kılarak likidite parçalanmasını azaltmaları nedeniyle rolluplar için ilgi çekici olabilir.

Phantom, Backpack ve Solflare gibi cüzdanlar.

Squads gibi çoklu imza ve akıllı sözleşme cüzdan altyapısı. Squads her zaman “Solana ve SVM için nihai akıllı sözleşme cüzdan altyapısı katmanı” olarak konumlandırılmıştır.

SOL Restaking: Modüler tez, bu rolluplar/appchain’ler SOL paylaşımlı güvenlik gerektirebileceği ve Solana ile daha uyumlu hale gelebileceği için restaking’i de teşvik etmektedir. Bu da şuna yol açar:

Cambrian, Picaso ve Solayer gibi erken aşamasındaki oyuncular
Stakenet ve Sanctum gibi LST’ler aracılığıyla Jito
Doğrulayıcılar, gelir artışı

Son Düşünceler: Solana Tüm Dünyanın Talebini Karşılayabilir mi?

Kesinlikle hayır. Gerçekçi olalım: Moore Yasası’nı (donanım performansının sürekli gelişeceği ve Solana’nın bu tür donanım gelişmeleri için optimize edildiği) hesaba katsak bile, bu pratik değildir. DRiP’in NFT’leri göndermesi gibi daha az kritik işlemlerin sonunda kendi zincirlerine taşınacağına, en değerli işlemlerin ise gerçek birleştirilebilirliğin gerekli olduğu ana zincirde kalacağına inanıyorum (örneğin Spot DEX’ler).
Ve hayır, bu Solana’nın bir dev olma ve birleştirilebilirlik savaşında kaybettiği anlamına gelmez; birleştirilebilirlik ve düşük gecikmeye bağlı durumları diğer zincirlerden daha iyi yönetecektir. Ve hayır, Sui, Aptos, Sei, Monad vb. henüz daha iyi değil, çünkü bunları bilmiyoruz ve yüksek gerçek kullanıcı aktivitesi için henüz kullanım testinden geçmediler.

Ethereum’dan farklı olarak, Solana Ana Ağı “B2B zinciri” olmayı hedeflemiyor; her zaman tüketici zinciri olmuştur ve olmaya devam edecektir. Büyük ölçekli dağıtık sistemler oluşturmak son derece zordur ve Solana, en değerli işlemler için küresel paylaşımlı defter haline gelme potansiyelinde en önde gelen zincirdir.

Bu makale, The Superteam Blog kaynağından alıntılanmıştır. İçeriğin tüm telif hakları yazara aittir. Telif haklarına ilişkin sorularınız için bizimle iletişime geçebilirsiniz.