L2 Ağ Etkileri Nereden Geliyor? L2'yi yapışkan yapan nedir?

Yazar: Alana Levin; Derleyen: Huohuo, yöresel blockchain

İki yıl önce uygulama geliştiricileri, uygulamalarını nereye dağıtacaklarına karar verirken oldukça basit bir seçimle karşı karşıya kaldılar: Ethereum, Solana, Cosmos veya muhtemelen başka bir katman 1 zinciri. Toplama henüz kullanımda değil ve çok az kişi "modüler yığın" terimini duydu. L1'ler arasındaki farklar (verim, maliyet, vb.) açıktır ve anlaşılması nispeten kolaydır.

** Bugün işler çok farklı görünüyor. Uygulama geliştiricileri daha fazla seçenekle karşı karşıyadır: L1, genel toplamalar (Optimistic ve zk), gelişmiş IBC altyapısı, hizmet olarak Toplamalar sağlayıcıları, uygulama zincirleri ve daha fazlası. **

Daha fazla seçenek, daha fazla soruyu beraberinde getirir, örneğin: ekipler genel toplamalara mı dağıtım yapmalı yoksa uygulamaya özel toplamalar mı oluşturmalı? Genel toplamayı seçerseniz hangisini seçmelisiniz? Uygulama toplama rotasına giderlerse, hangi SDK/hizmet olarak toplama kullanılacak? Hangi veri kullanılabilirliği katmanı seçilmeli? EigenLayer yardımcı olabilir mi? Sıralayıcılar hakkında nasıl düşünülür? OP Stack rotasına gitmeyi seçerlerse, Optimism'in süper zincir ekosisteminde renkli bir küre emojisi kalacak mı? Bu sorular zor.

Sorunu daraltmak için bu makale, Ethereum ekosistemi içinde ölçeklendirmek isteyen ve Ethereum'da halihazırda konuşlandırılmış bir uygulamanın çerçevesini benimseyecektir. Bu nedenle, uygulama ekiplerinin kendi toplamalarını başlatıp başlatmamaya karar verirken karşılaştıkları karar ağacına, bu altyapı için hangi tür uygulamaların özellikle uygun olduğuna ilişkin varsayımlara ve benimseme için bir devrilme noktasına ne zaman ulaşabileceğimizi düşündüğümüze odaklanılacaktır.

1. Üst düzey çerçeve

Bir uygulama toplama kararının merkezinde aslında basit bir soru vardır: **uygulama kendi zincirinde olsaydı, kullanıcılar uygulamayı yine de kullanır mıydı? **Bu sorunun iki alt kümesi vardır:

1) Kullanıcıların, kendi zincirinde yer alan bir uygulamayı kullanma olasılıkları daha mı yüksek?

2) Uygulama kendi zincirinde ise, kullanıcının uygulamayı kullanması eşit derecede mümkün mü?

Uygulamaya özel toparlama avantajları, daha fazla kontrolden kaynaklanmaktadır: Gaz maliyetlerini çıkarma, diğer uygulama faaliyetlerinin neden olduğu zincir üzerindeki tıkanıklığı sınırlama, belirteçlerin nasıl kullanıldığını daha iyi deneme, farklı ekonomik yapıları keşfetme (entegre gaz iadeleri gibi) , özel yürütme ortamları oluşturun, erişim denetimlerini uygulayın (izin dağıtma gibi) ve daha fazlasını yapın.

** Ancak bu ekstra kontrol, daha büyük ekosisteme bağlanma pahasına gelir. **Paylaşılan/evrensel bir zincirdeki uygulamalar, halihazırda o zincirde bulunan likiditeye (ör. zincirler arasında ek köprüler olmadan), diğer uygulamalarla birleştirilebilirliğe ve halihazırda bu zincir dikkatine adanmış kullanıcılara erişebilir. Ortak bir zincir üzerinde inşa etmek, kendi zincirini çalıştıran bir uygulamaya göre daha az dahili mühendislik işi/ek yük gerektirir.

Daha iyi kontroller, ücretsiz olsaydı kullanıcı deneyimini geliştirebilirdi. Bu nedenle, temel sorunun cevabı - kullanıcıların bir uygulamayı kendi zincirinde olsaydı yine de kullanıp kullanmayacakları - gerçekten bu kontrolün bağlantı değiş tokuşuna karşı ne kadar şiddetli olduğuna bağlıdır. **

2. Uygulama kaç bağlantı kaybetmeyi göze alabilir?

Bağlantılar birçok biçimde gelir. En önemli ikisi: 1) Dikkat ve 2) Sermaye.

** Yerel dağıtıma dikkat edin. Kullanıcıların ekosisteme girdiklerinde ilgilendikleri ilk şey ekibin projesiyse, uygulamanın yerel bir dağıtıma sahip olması zorlayıcı bir durumdur. ** Dikkati kontrol eden uygulamalar, kendi zincirlerini başlatmak için daha uygundur; kullanıcılar, hangi zincirde bulunduğundan bağımsız olarak bu uygulamayı kullanacaklardır. Bana göre, yerel dağıtıma sahip mevcut uygulama örnekleri arasında Mirror, Zora, Manifold, Sound.xyz ve OnCyber sayılabilir. Güçlü bir dağıtıma sahip olmayan uygulamaların ilgi uyandırmak için kendi zincirlerini başlatmayı seçebileceğine dair bir argüman da var.

"Bağlanabilirliğin" ikinci bileşeni sermayedir. Çoğu zaman, kullanıcılar tarafından bir uygulama için dağıtılan fonlar, aynı ekosistemdeki başka bir uygulamadan geri alınır. Ben buna "paylaşılan likidite" diyorum ve sonuçları gerçek. Yeni uygulamaların, ekosisteme köprülenen daha büyük ETH miktarı nedeniyle bir genel amaçlı toplamayı diğerine tercih ettiğini gördük; ekosistemdeki mevcut sermaye, kullanıcı benimseme önündeki engelleri kaldırmaya yardımcı olabilir (kullanıcıları bir yeni ekosistem). Bu hususlar, ürününe bir tür finansallaştırma yerleştiren herhangi bir uygulama için geçerlidir. Saf DeFi dışındaki örnekler arasında Mirror aracılığıyla NFT makaleleri toplamak, bir Stealcam'deki görüntüleri "çalmak" için ödeme yapmak veya ürün içi bahşiş verme özelliği olan herhangi bir şey yer alabilir.

**Bu "fon bağlantısının" kaybı, uygulamaların kullanıcıları envanterlerini zincir üzerinde park etmeye zorlaması gerektiği anlamına gelir. ** Bunun bir nedeni tüketicilerin uygulamayı çok kullanıyor olması olabilir - köprü kurma deneyimi sancılıdır, bu nedenle zincir üzerinde sağlıklı bir fon arzını sürdürmek daha kolay olacaktır. Ancak boş envanterden daha ikna edici olan, kullanıcılara gelir sağlayan seçenekler sunmaktır. Bu, zincire özgü bir getiri biçimi, getiri sağlayan bitişik bir ürün oluşturan bir uygulama (Blur'un borç verme protokolü gibi) veya başka bir şey gibi görünebilir.

Yukarıdaki nedenler (dikkat ve sermaye), birçok kişinin zincir üstü oyunları uygulamaya özel toparlamalar için ideal adaylar olarak görmesinin nedenidir: oldukça bağımsız ekonomilerdir, tüketicilerin zihin payını kontrol ederler ve bir tür ve-kaçınma Sıkışıklığıdırlar. keyifli bir kullanıcı deneyimi için önemli olan bir kategoridir.

Başka bir deyişle, zincir üstü oyunlar yüksek derecede kontrolden yararlanır ve izole edilirlerse önemli ölçüde etkilenmezler. Uygulama toplama için çok uygun olan diğer uygulamalar, işlemleri sübvanse ederek (ör. ilk birkaç işlem ücretsizdir) veya ilk başta ödeme yapılmasını gerektirerek (ör. kullanıcı tarafından oluşturulan zincir üstü içerik, belirli sosyal uygulamalar, DePIN ağları, vb.) Ön kullanıcı sermayesi gereksinimlerini en aza indirin.

Elbette, projelerin altyapıları üzerinde daha fazla kontrol istemelerinin başka nedenleri de var. Toplamaya sahip olmak, dağıtma izni veya kullanıcı tarama gereksinimlerini (zincirin sahip olduğu/çalıştırdığı sıralayıcılarda KYC gibi) uygulama becerisi sunar. Ancak bu durumlarda, toparlama veritabanları ile merkezi veritabanları arasındaki çizgi giderek daha az belirgin hale gelir.

3. Bağlantı kaybını en aza indirin

Birlikte çalışabilirlik çözümleri geliştikçe, bağlantıya karşı kontrol değiş tokuşu daha az kritik hale gelir. **Köprüler ve sıralayıcılar genellikle bu soruda ele alınan kritik altyapılardır. Her ikisi de bir zincirdeki işlemlerin başka bir zincirdeki işlemleri etkilemesi için bir yol sağlaması açısından biraz benzerler. **Köprüler bunu mesajları ileterek veya varlık transferlerini etkinleştirerek yapar. Paylaşılan bir sıralayıcı bunu, birden çok zincirden işlemleri alıp sıralayarak ve bir zincirdeki eylemlerin diğerindeki eylemleri etkilemesini sağlayan bir koordinasyon mekanizması oluşturarak yapar. Atomik birleştirilebilirlik, paylaşılan sıralayıcılar ve köprüler gerektirir - sıralayıcının bir blokta birden çok (etki alanları arası) işlem içermesi garanti edilir ve bu işlemlerin fiili olarak yürütülmesi genellikle bir köprü gerektirir.

Toplamaların birim ekonomisi, "bağlanabilirliğin" etkili olduğu başka bir alandır. **L2 işlem ücretleri iki faktörden oluşur: 1) verileri L1'de yayınlama maliyeti ve 2) kullanıcıların dahil edilmesi için ödediği maliyet. **Toplama operatörü, işlemler için arama verilerini toplayarak yayınlama maliyetlerinin kullanıcılara yayılmasını sağlar - işlem sayısı ne kadar fazlaysa, kullanıcı başına ortalama maliyet o kadar düşük olur. Bu aynı zamanda, daha az etkin toparlamaların, yeterince büyük toplu iş boyutuna sahip olana kadar L1'e nakil işlemlerini geciktirebileceği anlamına gelir. Sonuç, daha yavaş bir tamamlama süresi ve daha kötü bir kullanıcı deneyimidir. Paylaşılan sipariş vericiler, giderek artan bir şekilde toplama katmanları olarak hizmet ediyor gibi görünmektedir; burada, birden çok küçük toparlamadan toplu işlemler, uzun kuyruğun varlığı için uygun birim ekonomisi oluşturmaya yardımcı olabilir.

4. Bir dönüm noktasında mıyız?

Uygulama zincirleri ve uygulama toplamaları fikri yeni değil. Bununla birlikte, uzun bir süre, gelişmekte olan bir yerleşim bölgesi gibi hissettirdi: çok sayıda altyapı inşa ediliyordu, ancak burada yaşayan kimse yoktu.

Ancak son aylarda, ilk sakin akınını görmeye başladık. Kafes, kendi toplamasıyla desteklenen zincir üzerinde otonom bir dünya olan OpCraft'ı inşa etti. Lit Protocol ve Synapse gibi projeler kendi toparlamalarını duyurdular (her ikisi de uygulama odaklı olmaktan çok altyapı odaklı olsa da). Zora, Zorachain'i başlattı. Daha olgun uygulama katmanı ekipleriyle (özellikle L2 stratejilerini düşünenler) yapılan son görüşmeler, uygulama toplamanın onlar için doğru olup olmadığını keşfetmeye başladı.

Benim varsayımım, gerçek dönüm noktasının (en az) 6-12 ay içinde geleceği yönünde. ** Oyun ve sosyal uygulamalar, uygulamaya özel toparlamalarla en bariz ürün pazarı uyumuna sahiptir: hem sosyal hem de oyun, büyük ölçüde dizine eklemeye dayanır (ve paylaşılan durumla rekabet etmek zorunda kalmayarak büyük fayda sağlar), sipariş sorunları (özellikle oyun oynarken) ve özel özellikler (gazsız işlemler gibi) özellikle eğlence odaklı tüketici ürünleri için kullanışlıdır**. Bu uygulama ekiplerinin çoğu hala yapım aşamasındadır. Özellikle oyunların geliştirilmesi ve piyasaya sürülmesi yıllar alabilir.

Diğer çıkarım, dikkat çekmenin daha az finansal uygulamalar için en kritik faktör olduğudur. Şimdiye kadar bu makale, uygulama toplamalarını "toplama başına bir uygulama" olarak tanımlamıştır. Ancak bu görüş çok dar olabilir. Belki birden fazla uygulama bir kolektif oluşturmaya, "dikkatlerini" toplamaya ve birlikte bir zincir başlatmaya karar verir. Aynı şekilde, büyük bir uygulamanın kendi zincirini oluşturmaya karar verdiğini ve diğer uygulamaları bu zincir üzerinde konuşlandırmaya teşvik ettiğini görebiliriz - aslında kontrol etmek istediği altyapının benimsenmesini test etmek için kendi uygulamasını kullanarak.

Son olarak, gelecekte daha fazla toplama göreceğimize inanıyorum. Uygulama toplamaları için altyapı hizmetleri inşa eden projelerde bir artış olmuştur. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer vb. ekiplerin kendi Toplamalarını başlatmaları için düşük kaldırma çözümleri sağlar.

Espresso, Astria ve Flashbots'un SUAVE'si sıralayıcı alanına erken girenlerden bazılarıdır. Kurulum maliyetleri düşüş eğilimi gösteriyor ve "bağlanabilirlik" değiş tokuşu daha az ciddi hale geliyor. Her ikisi de evlat edinme durumunu güçlendirir. **Ancak çok sayıda yeni altyapı sağlayıcısı, uygulama ekiplerinin çeşitli seçenekleri anlamak için zaman ayırabileceği ve bir kazanan seçmeden önce bu çeşitli oyuncuları savaş testine tabi tutabileceği anlamına da gelir. **Yine, evlat edinme belirtileri olsa da, sanırım dönüm noktasına hala birkaç ay var.