Yazan: Alana Levin; Derleyen: Luffy, Foresight News
İki yıl önce uygulama geliştiricileri, uygulamalarını hangi zincire dağıtacaklarına karar verirken oldukça basit bir seçimle karşı karşıya kaldılar: Ethereum, Solana, Cosmos veya başka bir Katman 1 blok zinciri. O zamanlar Rollup henüz ana ağı başlatmamıştı ve çok az kişi "modüler yığın" terimini duymuştu. L1'ler arasındaki farklar (iş hacmi, ücretler 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 amaçlı Toplama (İyimser ve zk), IBC altyapısı, Hizmet sağlayıcı olarak Toplama, AppChain ve daha fazlası. Daha fazla seçenek, daha fazla soruyu beraberinde getirir: ekipler, uygulamaları genel toplamalara mı dağıtmalı yoksa uygulamaya özel toplamalar mı oluşturmalı? Genel Toplama'ya giderlerse, hangisini seçecekleri, uygulama Toplama rotasına giderlerse, hangi SDK'yı/Hizmet olarak Toplama'yı kullanacakları, hangi veri kullanılabilirlik katmanını seçecekleri, EigenLayer yardımcı olabilir, sıralayıcılar hakkında nasıl düşünülür; Optimism'in süper zincir ekosisteminde yer alıp alamayacağı OP Stack rotasını seçerlerse.
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. Dolayısıyla bu makale, uygulama ekiplerinin kendi toplamalarını başlatıp başlatmamaya karar verirken karşılaştıkları karar ağacına, hangi tür uygulamaların özellikle belirli altyapı türleri için uygun olduğuna ve benimseme devrilme noktasına ne zaman ulaşabileceğimize odaklanacak.
Üst Düzey Çerçeve
Uygulama toplama kararının merkezinde aslında basit bir soru var: Uygulama kendi zinciri üzerine kurulu olsaydı, kullanıcılar onu kullanmaya devam eder miydi? Daha fazla gelişme iki sorudur:
Kullanıcıların, kendi zincirinde olan bir uygulamayı kullanma olasılıkları daha mı yüksek?
Uygulama kendi zincirindeyse kullanıcılar da kullanır mı?
Uygulamaya özel toparlamaların faydaları daha iyi kontroldü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ığına dair daha iyi deney yapma, farklı ekonomik yapıları keşfetme (örn. yürütme ortamı, erişim kontrollerini uygulama (izin dağıtma gibi) ve daha fazlası.
Ancak bu ekstra kontrolün bedeli, daha geniş ekosisteme bağlantı kaybıdır. Evrensel bir zincirdeki uygulamalar, halihazırda o zincirde bulunan likiditeye erişebilir (örneğin, zincirler arasında ek köprülere gerek yoktur), diğer uygulamalarla birleştirilebilirlik ve zincir üzerinde kullanıcı dikkati. Kendi zincirlerini çalıştıran uygulamalarla karşılaştırıldığında, genel zincir üzerine inşa etmek aynı zamanda çok fazla mühendislik masrafından da tasarruf sağlar.
Daha iyi kontrol, ü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 ve bağlantı değiş tokuşuna bağlıdır.
**Bir uygulama ne kadar bağlantıdan ödün verebilir? **
Bağlantılar birçok biçimde gelir, en önemli ikisi: 1) dikkat ve 2) sermaye.
Dikkat yerli iletişim ile ilgilidir. Bir ekibin projesi, kullanıcıların ekosisteme girdiklerinde ilgilendikleri ilk projeyse, uygulama doğal olarak viraldir. Dikkat çekebilen uygulamalar, kendi zincirlerini başlatmak için daha uygundur; kullanıcılar, uygulama hangi zincirde olursa olsun uygulamayı kullanacaklardır. Kanımca, yerel yayılıma sahip mevcut uygulamalar arasında Mirror, Zora, Manifold, Sound.xyz ve OnCyber yer alıyor. Güçlü bir yayılımı olmayan uygulamaların, kullanıcıların ilgisini çekmek için kendi zincirlerini başlatmayı seçebileceğine dair bir argüman da var (ancak aynı anda birçok zincir bu rotayı takip ediyorsa bunu daha az ikna edici buluyorum).
Bağlanabilirliğin ikinci biçimi sermayedir. Çoğu zaman, kullanıcıların bir uygulamada dağıttığı fonlar, aynı ekosistemdeki başka bir uygulamadan aktarılır. Ben buna "paylaşılan likidite" diyorum ve sonuçları gerçek. Çok sayıda yeni uygulama, bu ekosisteme bağlanan büyük miktarda ETH nedeniyle Universal Rollup'ı seçiyor ve ekosistemdeki mevcut sermaye, (kullanıcıları yeni bir ekosisteme girmeye ikna etmeye çalışmak yerine) kullanıcı benimseme önündeki engellerin kaldırılmasına yardımcı olabilir. Bu faktörler, ürününe bir tür finansallaştırma ekleyen herhangi bir uygulama için dikkate alınması gereken hususlardır. DeFi dışındaki örnekler şunları içerebilir: Mirror yoluyla NFT kağıtları 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.
Bu "fon bağlantısının" kaybedilmesi, uygulamaların kullanıcıları zincirdeki fonları park etmeye zorlaması gerektiği anlamına gelir. Bunun bir nedeni, tüketicilerin uygulamayı çok kullanması olabilir, çapraz zincirler sonuçta acı vericidir, bu nedenle zincir üzerinde sağlıklı bir fon arzını sürdürmek daha kolay olacaktır. Ancak, atıl fonlardan daha da ilgi çekici olan, kullanıcılara getiri elde etme seçeneği sunmaktır. Bu, zincir yerliler, getiri sağlayan bitişik ürünler oluşturan uygulamalar (Blur'un borç verme protokolü gibi) ve daha fazlası biçimindeki getiriye benziyor.
Dikkat ve sermaye aynı zamanda birçok kişinin zincir üstü oyunları uygulamaya özel toplamalar için ideal adaylar olarak görmesinin nedenidir: oldukça bağımsız ekonomilerdir ve büyük ölçüde sorunsuz bir kullanıcı deneyimine güvenirler. Diğer bir deyişle, on-chain oyunlar yüksek derecede kontrolden yararlanır ve yetim kalmaları durumunda önemli kayıplara uğramazlar. Toplama için çok uygun olan diğer uygulamalar, işlemleri sübvanse ederek (ör. ilk birkaç işlem ücretsizdir) veya oturum açtıktan sonra ödeme yapılmasını gerektirerek (ör. kullanıcı tarafından oluşturulan zincir içi içerik, belirli sosyal uygulamalar, DePIN ağları vb.) bunu yapabilir. Ön kullanıcı sermayesi gereksinimlerini en aza indirir.
Elbette, projelerin altyapıları üzerinde daha fazla kontrol istemelerinin başka nedenleri de var. Tescilli Toplamalar, izinleri devreye alma ve kullanıcıları görüntüleme (ör. zincire ait/işletilen sıralayıcılar için KYC) olanağı sağlar. Ancak bu, Toplama veritabanları ile merkezi veritabanları arasındaki çizginin bulanıklaşmasına da yol açar.
Bağlantı Kaybını En Aza İndirin
Birlikte çalışabilirlik çözümleri geliştikçe, bağlantıya karşı kontrol ödünleşimi daha az önemli hale gelir. Köprüler ve sıralayıcılar genellikle tartışılan kritik altyapıdı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 sipariş verenler bunu birden çok zincirden işlemleri alıp sipariş ederek yapar. Atomik birleştirilebilirlik için hem paylaşılan düzenleyiciler hem de köprüler gereklidir - sipariş verenin bir blokta birden çok (çapraz zincir) 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 bölümden oluşur: 1) verileri L1'de yayınlama maliyeti ve 2) kullanıcıların işlem için ödediği maliyet. Yayınlama maliyetinin kullanıcılar arasında paylaşılabilmesi için işlem çağrısı verilerini toplayın: İşlem sayısı ne kadar fazlaysa, kullanıcı başına ortalama maliyet o kadar düşük olur. Bu aynı zamanda, daha az etkin Toplamaların yeterince büyük bir işlem paketine sahip olana kadar L1'e yayımlama işlemlerini geciktirebileceği anlamına gelir. Sonuç, daha yavaş tamamlama süreleri ve zayıf kullanıcı deneyimidir. Paylaşılan sipariş vericiler, giderek daha fazla sayıda küçük toparlamadan toplu işlemlerin uzun kuyruklu bireyler için uygun birim ekonomisi oluşturmaya yardımcı olabileceği toplama katmanları olarak hizmet ediyor gibi görünmektedir.
**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ştirilmekte olan bir yerleşim bölgesi gibi hissettirdi: pek çok altyapı inşa ediliyordu, ancak hiç sakin yoktu. Son aylarda, ilk sakinlerin akını görmeye başladık. Lattice, kendi toplaması tarafından desteklenen zincir üzerinde otonom bir dünya olan OpCraft'ı inşa etti; Lit Protocol ve Synapse kendi Toplamalarını duyurdular (gerçi her ikisi de uygulama odaklı projelerden daha altyapı odaklıdır); Zora, Zorachain'i başlattı. Olgun uygulama ekipleriyle (özellikle L2 stratejilerini düşünenlerle) yapılan son görüşmeler, uygulama özetlerinin kendileri 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 Toplamalar ile en bariz ürün pazarı uyumuna sahiptir: Hem sosyal hem de oyun, büyük ölçüde indeksleme, sıralama sorunları (özellikle oyunlarda) ve eğlence amaçlı tüketim için özel özelliklere (gazsız işlemler gibi) dayanır. önemli. Pek çok uygulama ekibi, özellikle geliştirilip piyasaya sürülmesi yıllar alabilen oyunlar olmak üzere yapım aşamasındadır.
Diğer çıkarım, daha az finansal uygulamalar için en kritik şeyin dikkat çekmek olduğu. Ş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 de birlikte bir zincir başlatmak için bir kolektif oluşturan birden fazla uygulama vardır. Aynı şekilde, bir uygulamanın kendi zincirini oluşturduğunu görebilir ve diğer uygulamaları bunun üzerine konuşlandırmaya teşvik edebiliriz.
Son olarak, gelecekte daha fazla Toplama göreceğimize kesinlikle inanıyorum. Uygulama toplamaları için altyapı hizmetleri oluşturan projeler çoğalacaktır. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, vb. uygulama ekiplerine kendi Toplamalarını başlatmaları için düşük eşikli çözümler sağlar. Espresso, Astria ve Flashbots'un SUAVE'si sıralayıcı alanındaki ilk kaşiflerden bazılarıydı. Başlangıç maliyetleri düşüş eğilimi gösteriyor ve "bağlanabilirlik" değiş tokuşu daha az önemli hale geliyor. Ancak bu kadar çok sayıda yeni altyapı sağlayıcısı, uygulama ekiplerinin çeşitli seçenekleri anlamalarının zaman alabileceği ve bu oyuncular arasında bir savaş çıkacağı anlamına da geliyor. Yine, benimseme belirtileri olsa da, sanırım dönüm noktasına hala birkaç ay var.
Geliştirici, Jill Gunter, Kyle Samani, Jason Maier, Cem Özer ve Viktor Bunin'e geri bildirimleri, yorumları ve bu fikirlerin çoğunun geliştirilmesine yardımcı olan sohbetleri için teşekkür ederiz.
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.
Modülerleştirme eğilimi altında, uygulama kendi zincirini oluşturmalı mı?
Yazan: Alana Levin; Derleyen: Luffy, Foresight News
İki yıl önce uygulama geliştiricileri, uygulamalarını hangi zincire dağıtacaklarına karar verirken oldukça basit bir seçimle karşı karşıya kaldılar: Ethereum, Solana, Cosmos veya başka bir Katman 1 blok zinciri. O zamanlar Rollup henüz ana ağı başlatmamıştı ve çok az kişi "modüler yığın" terimini duymuştu. L1'ler arasındaki farklar (iş hacmi, ücretler 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 amaçlı Toplama (İyimser ve zk), IBC altyapısı, Hizmet sağlayıcı olarak Toplama, AppChain ve daha fazlası. Daha fazla seçenek, daha fazla soruyu beraberinde getirir: ekipler, uygulamaları genel toplamalara mı dağıtmalı yoksa uygulamaya özel toplamalar mı oluşturmalı? Genel Toplama'ya giderlerse, hangisini seçecekleri, uygulama Toplama rotasına giderlerse, hangi SDK'yı/Hizmet olarak Toplama'yı kullanacakları, hangi veri kullanılabilirlik katmanını seçecekleri, EigenLayer yardımcı olabilir, sıralayıcılar hakkında nasıl düşünülür; Optimism'in süper zincir ekosisteminde yer alıp alamayacağı OP Stack rotasını seçerlerse.
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. Dolayısıyla bu makale, uygulama ekiplerinin kendi toplamalarını başlatıp başlatmamaya karar verirken karşılaştıkları karar ağacına, hangi tür uygulamaların özellikle belirli altyapı türleri için uygun olduğuna ve benimseme devrilme noktasına ne zaman ulaşabileceğimize odaklanacak.
Üst Düzey Çerçeve
Uygulama toplama kararının merkezinde aslında basit bir soru var: Uygulama kendi zinciri üzerine kurulu olsaydı, kullanıcılar onu kullanmaya devam eder miydi? Daha fazla gelişme iki sorudur:
Uygulamaya özel toparlamaların faydaları daha iyi kontroldü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ığına dair daha iyi deney yapma, farklı ekonomik yapıları keşfetme (örn. yürütme ortamı, erişim kontrollerini uygulama (izin dağıtma gibi) ve daha fazlası.
Ancak bu ekstra kontrolün bedeli, daha geniş ekosisteme bağlantı kaybıdır. Evrensel bir zincirdeki uygulamalar, halihazırda o zincirde bulunan likiditeye erişebilir (örneğin, zincirler arasında ek köprülere gerek yoktur), diğer uygulamalarla birleştirilebilirlik ve zincir üzerinde kullanıcı dikkati. Kendi zincirlerini çalıştıran uygulamalarla karşılaştırıldığında, genel zincir üzerine inşa etmek aynı zamanda çok fazla mühendislik masrafından da tasarruf sağlar.
Daha iyi kontrol, ü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 ve bağlantı değiş tokuşuna bağlıdır.
**Bir uygulama ne kadar bağlantıdan ödün verebilir? **
Bağlantılar birçok biçimde gelir, en önemli ikisi: 1) dikkat ve 2) sermaye.
Dikkat yerli iletişim ile ilgilidir. Bir ekibin projesi, kullanıcıların ekosisteme girdiklerinde ilgilendikleri ilk projeyse, uygulama doğal olarak viraldir. Dikkat çekebilen uygulamalar, kendi zincirlerini başlatmak için daha uygundur; kullanıcılar, uygulama hangi zincirde olursa olsun uygulamayı kullanacaklardır. Kanımca, yerel yayılıma sahip mevcut uygulamalar arasında Mirror, Zora, Manifold, Sound.xyz ve OnCyber yer alıyor. Güçlü bir yayılımı olmayan uygulamaların, kullanıcıların ilgisini çekmek için kendi zincirlerini başlatmayı seçebileceğine dair bir argüman da var (ancak aynı anda birçok zincir bu rotayı takip ediyorsa bunu daha az ikna edici buluyorum).
Bağlanabilirliğin ikinci biçimi sermayedir. Çoğu zaman, kullanıcıların bir uygulamada dağıttığı fonlar, aynı ekosistemdeki başka bir uygulamadan aktarılır. Ben buna "paylaşılan likidite" diyorum ve sonuçları gerçek. Çok sayıda yeni uygulama, bu ekosisteme bağlanan büyük miktarda ETH nedeniyle Universal Rollup'ı seçiyor ve ekosistemdeki mevcut sermaye, (kullanıcıları yeni bir ekosisteme girmeye ikna etmeye çalışmak yerine) kullanıcı benimseme önündeki engellerin kaldırılmasına yardımcı olabilir. Bu faktörler, ürününe bir tür finansallaştırma ekleyen herhangi bir uygulama için dikkate alınması gereken hususlardır. DeFi dışındaki örnekler şunları içerebilir: Mirror yoluyla NFT kağıtları 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.
Bu "fon bağlantısının" kaybedilmesi, uygulamaların kullanıcıları zincirdeki fonları park etmeye zorlaması gerektiği anlamına gelir. Bunun bir nedeni, tüketicilerin uygulamayı çok kullanması olabilir, çapraz zincirler sonuçta acı vericidir, bu nedenle zincir üzerinde sağlıklı bir fon arzını sürdürmek daha kolay olacaktır. Ancak, atıl fonlardan daha da ilgi çekici olan, kullanıcılara getiri elde etme seçeneği sunmaktır. Bu, zincir yerliler, getiri sağlayan bitişik ürünler oluşturan uygulamalar (Blur'un borç verme protokolü gibi) ve daha fazlası biçimindeki getiriye benziyor.
Dikkat ve sermaye aynı zamanda birçok kişinin zincir üstü oyunları uygulamaya özel toplamalar için ideal adaylar olarak görmesinin nedenidir: oldukça bağımsız ekonomilerdir ve büyük ölçüde sorunsuz bir kullanıcı deneyimine güvenirler. Diğer bir deyişle, on-chain oyunlar yüksek derecede kontrolden yararlanır ve yetim kalmaları durumunda önemli kayıplara uğramazlar. Toplama için çok uygun olan diğer uygulamalar, işlemleri sübvanse ederek (ör. ilk birkaç işlem ücretsizdir) veya oturum açtıktan sonra ödeme yapılmasını gerektirerek (ör. kullanıcı tarafından oluşturulan zincir içi içerik, belirli sosyal uygulamalar, DePIN ağları vb.) bunu yapabilir. Ön kullanıcı sermayesi gereksinimlerini en aza indirir.
Elbette, projelerin altyapıları üzerinde daha fazla kontrol istemelerinin başka nedenleri de var. Tescilli Toplamalar, izinleri devreye alma ve kullanıcıları görüntüleme (ör. zincire ait/işletilen sıralayıcılar için KYC) olanağı sağlar. Ancak bu, Toplama veritabanları ile merkezi veritabanları arasındaki çizginin bulanıklaşmasına da yol açar.
Bağlantı Kaybını En Aza İndirin
Birlikte çalışabilirlik çözümleri geliştikçe, bağlantıya karşı kontrol ödünleşimi daha az önemli hale gelir. Köprüler ve sıralayıcılar genellikle tartışılan kritik altyapıdı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 sipariş verenler bunu birden çok zincirden işlemleri alıp sipariş ederek yapar. Atomik birleştirilebilirlik için hem paylaşılan düzenleyiciler hem de köprüler gereklidir - sipariş verenin bir blokta birden çok (çapraz zincir) 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 bölümden oluşur: 1) verileri L1'de yayınlama maliyeti ve 2) kullanıcıların işlem için ödediği maliyet. Yayınlama maliyetinin kullanıcılar arasında paylaşılabilmesi için işlem çağrısı verilerini toplayın: İşlem sayısı ne kadar fazlaysa, kullanıcı başına ortalama maliyet o kadar düşük olur. Bu aynı zamanda, daha az etkin Toplamaların yeterince büyük bir işlem paketine sahip olana kadar L1'e yayımlama işlemlerini geciktirebileceği anlamına gelir. Sonuç, daha yavaş tamamlama süreleri ve zayıf kullanıcı deneyimidir. Paylaşılan sipariş vericiler, giderek daha fazla sayıda küçük toparlamadan toplu işlemlerin uzun kuyruklu bireyler için uygun birim ekonomisi oluşturmaya yardımcı olabileceği toplama katmanları olarak hizmet ediyor gibi görünmektedir.
**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ştirilmekte olan bir yerleşim bölgesi gibi hissettirdi: pek çok altyapı inşa ediliyordu, ancak hiç sakin yoktu. Son aylarda, ilk sakinlerin akını görmeye başladık. Lattice, kendi toplaması tarafından desteklenen zincir üzerinde otonom bir dünya olan OpCraft'ı inşa etti; Lit Protocol ve Synapse kendi Toplamalarını duyurdular (gerçi her ikisi de uygulama odaklı projelerden daha altyapı odaklıdır); Zora, Zorachain'i başlattı. Olgun uygulama ekipleriyle (özellikle L2 stratejilerini düşünenlerle) yapılan son görüşmeler, uygulama özetlerinin kendileri 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 Toplamalar ile en bariz ürün pazarı uyumuna sahiptir: Hem sosyal hem de oyun, büyük ölçüde indeksleme, sıralama sorunları (özellikle oyunlarda) ve eğlence amaçlı tüketim için özel özelliklere (gazsız işlemler gibi) dayanır. önemli. Pek çok uygulama ekibi, özellikle geliştirilip piyasaya sürülmesi yıllar alabilen oyunlar olmak üzere yapım aşamasındadır.
Diğer çıkarım, daha az finansal uygulamalar için en kritik şeyin dikkat çekmek olduğu. Ş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 de birlikte bir zincir başlatmak için bir kolektif oluşturan birden fazla uygulama vardır. Aynı şekilde, bir uygulamanın kendi zincirini oluşturduğunu görebilir ve diğer uygulamaları bunun üzerine konuşlandırmaya teşvik edebiliriz.
Son olarak, gelecekte daha fazla Toplama göreceğimize kesinlikle inanıyorum. Uygulama toplamaları için altyapı hizmetleri oluşturan projeler çoğalacaktır. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, vb. uygulama ekiplerine kendi Toplamalarını başlatmaları için düşük eşikli çözümler sağlar. Espresso, Astria ve Flashbots'un SUAVE'si sıralayıcı alanındaki ilk kaşiflerden bazılarıydı. Başlangıç maliyetleri düşüş eğilimi gösteriyor ve "bağlanabilirlik" değiş tokuşu daha az önemli hale geliyor. Ancak bu kadar çok sayıda yeni altyapı sağlayıcısı, uygulama ekiplerinin çeşitli seçenekleri anlamalarının zaman alabileceği ve bu oyuncular arasında bir savaş çıkacağı anlamına da geliyor. Yine, benimseme belirtileri olsa da, sanırım dönüm noktasına hala birkaç ay var.
Geliştirici, Jill Gunter, Kyle Samani, Jason Maier, Cem Özer ve Viktor Bunin'e geri bildirimleri, yorumları ve bu fikirlerin çoğunun geliştirilmesine yardımcı olan sohbetleri için teşekkür ederiz.