L1'ler ve L2'ler, Toplamalar ve Entegre, Genel amaçlı ve Uygulamaya özel

Giriş

Bu kısa yazı aşağıdakilerin somut değiş tokuşlarını açıklayacaktır:

• L1'ler ve L2'ler
• Toplamalar ve entegre
• Uygulamaya özel ve genel amaçlı

Hangi mimarilerin ne zaman inşa edileceğini daha iyi anlamamız gerekiyor. Aksi takdirde, hiçbir kullanıcının anlayamayacağı veya etkileşimde bulunamayacağı, kafa karıştırıcı bir altyapı karmaşasıyla karşılaşmaya devam edeceğiz. Gördüğüm en yaygın hata bu:

Eclipse'in yaklaşan ana ağ lansmanı öncesindeki giriş yazısında belirtildiği gibi:

Modüler toplama vizyonu ile devasa ölçeğe, paralel yürütmeye ve paylaşılan duruma sahip tek bir zincire sahip olma yeteneği arasında sıklıkla yanlış bir ikilem ortaya çıkar. "Modüler" genellikle "uygulamaya özel" ile karıştırılır; bu da toplamaların birçok parçalı ve düşük verimli zincirden oluşan bir dünya anlamına geldiğine inanmanıza neden olur. Biz bu fikre meydan okuyoruz.

Toplamalar ve L2'ler kötü UX değildir. Parçalanmış toplamalar ve L2'ler kötü UX'tir. Düzgün tasarlanmış toplamalar ve L2'ler kullanıcı deneyimini geliştirmelidir.

Toplamalar ve Entegre

Eğer yararlı olduğu kanıtlanırsa, tüm zincirler sonunda en iyi teknolojiyi (örn. DAS + ZK) benimseyebilir. Son raporumda tartışıldığı gibi Toplamalar Güvenliği Devralır mı?, o zaman elimizde kalan ayrım kabaca şudur:

• “Toplamalar” diğer adıyla “Modüler” - Ana bilgisayar zincirlerine (DA katmanı) veri gönderen mantıksal olarak ayrı zincirler oluşturun. Ana bilgisayar zincirinin fikir birliğini yeniden kullanırlar.
• “Entegre” yani “Monolitik” - Her şeyi kendi fikir birliğine sahip tek bir protokole entegre edin. Verileri ayrı bir ana makine zincirine göndermeyin. (DA katmanı ve yürütme katmanı bir anlamda paylaşılan protokolün mantıksal olarak ayrı parçaları olsa bile).

Solana ve Eclipse, Syncracy'nin Solana Tezi'nde benzer şekilde gösterildiği gibi paralel yolları temsil eder:

Hasu ile son Sıradışı Çekirdek bölümümde tartıştığım gibi, her iki yaklaşımın da uzun vadeli değeri olacak.

Solana her şeyi tek bir konsensusta birleştirme yaklaşımını benimsiyor. Geniş bir doğrulayıcı setini (~2.000 ) korurken minimum gecikmeyi (slot süreleri şu anda ortalama ~400-500 msolup, gelecekte 200 ms'ye ulaşması umulmaktadır ) takip eder. Bu inanılmaz başarı, birçok teknik atılım gerektirdi.

Ancak bu iki hedef (maksimum merkeziyetsizlik + minimum gecikme) doğası gereği gerilim içindedir. Maksimum hız ve verimde çalışırken bu fikir birliğini sabit tutmak inanılmaz derecede zordur. TowerBFT'nin resmi bir güvenlik veya canlılık analizi yoktur ve geçmişin kanıtlanmasının şu anda çekişmeli bir modelde yararlı ve dayanıklı olup olmadığı veya basitçe kaldırılıp kaldırılamayacağı açık değildir. Düşük gecikmeli bir sistemin ekonomisi elbette merkezileşme teşvikini de artırır.

Eclipse, fikir birliğinin ayrıştırılması yaklaşımını benimsiyor. Toplamalar, kontrollü bir ortamı çalıştırmak için elle seçilmiş daha küçük bir sıralayıcı setine (potansiyel olarak tek bir operatör tarafından bile çalıştırılabilir) sahip olabilir. Bu, kripto raylarının avantajlarına sahip bir Web2 ürünü sunarak güvenilirliği artırabilir ve gecikmeyi daha da azaltabilir. Solana'da dayanıklı nonce'ler kullanan bir L2 gibi konuşlandırılan bir ödeme uygulaması olan Code, anında ve güvenilir ödeme isteği açısından benzer. Neredeyse anlık gecikme süresine sahip harika UX'in ötesinde, alt sınırın daha da ileri itilmesi, yüksek değerli, düşük gecikmeli finansal uygulamalar için de gereklidir.

Toplamalar daha sonra, daha yavaş bir zaman ölçeğinde daha sağlam doğrulama için verilerini başka bir merkezi olmayan fikir birliği setine gönderebilir. Örneğin Celestia'nın tek slot finalinde 15 saniyelik blok süreleri var ki bu aslında Solana'dan çok da farklı değil! Solana'nın onayları ~400ms'dir, ardından 32 aralıktan (~12,8s) sonra kesinliğe ulaşılır .

Burada bedava öğle yemeği yok. Gerçek zamanlı doğrulayıcı kümesinin özellikleri (örneğin, Solana'nın toplama sıralayıcılardan çok daha fazla doğrulayıcısı vardır) ile sağlanan garantiler (örneğin, kontrollü esnek ortam, hatta daha düşük gecikme vb.) arasında potansiyel bir ödünleşim vardır. Verilen bağlılığın uygun düzeyi (ve hangi zaman ölçeğinde) bir spektrumdur. Açık mühendislik soruları halen devam etmektedir ve en iyi uyum muhtemelen kullanım senaryosuna göre değişecektir. Burada maliyetin de önemli olduğunu söylemeye gerek yok, dolayısıyla Celestia (Eclipse'in kullandığı) gibi ölçeklenebilir DA katmanlarına ihtiyaç duyulacak.

Eclipse'in Solana'nın yerini almayacağı kesin. Her biri farklı tavizler veriyor ve farklı bir pazarın peşinde koşuyor. Solana, SVM gelişiminin kalbi ve ruhu olmaya devam ediyor ve bunun sonucunda burada birçok yeni uygulamanın devreye alınması muhtemel. Ancak uzun vadede birden fazla SVM zincirinin olacağı açıktır (Pyth zaten öyledir). Gelecek tek zincirli değil ve SVM gerçekten muhteşem bir teknoloji. Eclipse, onu L2'ye ihraç etme eğilimini başlatıyor, ancak diğerlerinin buradaki değeri fark etmelerini ve onları takip etmelerini bekliyorum.

L1 ve L2

Burada L1 ve L2'yi daha popüler anlamda toplamaları, validyumları vb. içerecek şekilde kullanıyorum. Vitalik'in Farklı katman 2 türleri bölümünde anlatıldığı gibi:

İki yönlü doğrulama köprüleri, bir zincirin validium olması için neredeyse yeterlidir. Geriye kalan ana bileşen, Ethereum'da köprünün artık çalışmamasına neden olacak olağanüstü bir şey olursa, diğer zincirin buna karşılık olarak hard fork uygulayacağı yönündeki sosyal taahhüttür.

Bir L1'i L2'ye karşı kılan şey, çatallarla nasıl başa çıktığıdır. Bir validium, L1'i bir bloğu geri döndürürse geri döner ve taban katmanı sert çatallanırsa sert çatallanır. L2'yi yükseltmek için, L1 tarafından okunabilen bir köprü sözleşmesi olarak L1'de bir tür L2 yönetişiminin bulunması gerekir.

Peki neden böyle bir şeyi kullanalım ki? Bir zincirin çatal seçimini alttaki L1'e devretmesi ve oradaki köprünün etrafında kök salması mantıklı mı?

L1 savaşlarının bittiğine dair yaygın inanışlara rağmen Ethereum kazandı ve tüm Ethereum rakipleri artık L2 olmak istiyor - Ethereum L2'ler tüm zincirler için en iyi çözüm değil.

Ethereum L2'ler genellikle zincir oluşturmanın en güvenli ve ölçeklenebilir yolu olarak görülüyor. Ancak son raporumda da tartışıldığı gibi bu güvenlik özellikleri sıklıkla yanlış anlaşılıyor. Sadece Ethereum'a bir kanıt göndermek ve çatal seçim kuralınızı orada devretmek, zincirinizi sihirli bir şekilde süper güvenli hale getirmez.

Tüm zincirlerin kendi güvenlikleri için Ethereum L2'ler olarak konuşlandırılması gerektiği argümanı çoğunlukla yanlıştır. Aksine, L2'lerin birincil faydası, Ethereum'un ağ etkilerinden (kullanıcılar, likidite, geliştiriciler, araçlar vb.) yararlanma yeteneği olmuştur. Bu bir pazara açılma stratejisidir.

Dikkatin kriptoda kıt olan tek kaynak olduğu göz önüne alındığında, ilgi için mücadele etmek mantıklıdır. L2'ler doğal olarak geliştiriciler, kullanıcılar, medya vb. açısından en önemli kişiler arasında ön planda ve merkezde yer alır. Eskiden L2 olmak bu ilgiyi çekmek için yeterliydi.

Ancak L2 olmanın getirdiği ilgi azalıyor. Canlı ve gelecek Ethereum L2'lerin listesi artık herhangi bir kişinin takip edemeyeceği kadar uzun. L2'lere dönen zincirler, ilk hareket edenlerin (örneğin, İyimserlik ve Arbitrum) elde ettiği dikkat artışını alamıyor. Uzun zamandır beklenen zkEVM seli bile kullanıcıları, uygulamaları ve değeri çekmekte zorlanıyor.

Yani tek başına L2 olmak artık herkesin dikkatini garanti etmiyor. Ancak başka bir şekilde dikkat çekebilirseniz, bağımsız zincirlere göre yine de ürün avantajı sunabilir. Örneğin, bir piramit şemasını kareye dönüştürmek, L2'siz bir çoklu imzaya ~700 mm'lik bir çekim sağlayabilir. Alternatif olarak Ethereum'un ilk SVM L2'sini oluşturabilirsiniz.

Dikkat çeken bir ürününüz olduğunu varsayalım, şimdi L2 olmanın, bir zincirin Ethereum'un kullanıcı tabanına erişmesine ve daha iyi bir ürün deneyimi sunmasına nasıl yardımcı olabileceğini düşünelim. Bunu öncelikle Ethereum'un yerel varlıklarını (örneğin, ETH) uygun bir şekilde (örneğin, cazip güvenlik ve/veya UX'e sahip köprüler) kullanarak yapacaktır.

Bunun değeri genel olarak iki temel varsayıma bağlıdır:

1.Mevcut Ethereum varlıklarının belirli bir kullanım durumu için önemli olduğu (örneğin, ETH'ye bağlı DeFi)

Uygulamanız büyük ölçüde Ethereum ekosistemi varlıklarına bağımlıysa L2 mimarisi değerli olabilir. Ethereum varlıklarını hiç umursamıyorsanız, o zaman Ethereum L2 olmak pek değerli değildir. Ethereum tabanlı varlıklar, bugün kriptodaki en önemli varlıklardır, dolayısıyla bugün burada hizmet verilecek büyük bir pazar var.

Sektör düzeyinde ileriye baktığımızda buradaki temel soru, gelecekte kripto paranın yeni ve değerli yaratımının ne olacağıdır?

• Gelecekteki bu durumun mevcut Ethereum-yerel durumundan (örneğin, benzersiz yeni durum, RWA'lar vb.) giderek daha fazla bağlantısı kesilirse, o zaman L2'lerin çekiciliği azalabilir.
• Gelecekteki durum büyük ölçüde mevcut Ethereum yerel durumuna bağlıysa (örneğin, ETH ticareti), o zaman L2'ler önemli bir rol oynayabilir.

Önceki senaryo, kripto paranın ne olacağı konusunda yalnızca bir damla gördüğümüz ve bugün burada olanlara aşırı endekslememeniz gerektiği görüşünü benimsiyor. İkinci senaryo, kripto geliştirme ve uygulamalarının inanılmaz derecede yola bağlı olacağı, dolayısıyla mevcut durumun sonucu etkileyeceği görüşünü benimsiyor.

Her ikisi de bir dereceye kadar doğrudur, ancak endüstrinin uzun vadeli beklentilerine dair herhangi bir iyimser bakış açısının ilkine dayandığını düşünüyorum. Bugünün durumundan bağımsız olduğunu aklımıza bile getiremeyeceğimiz pek çok yeni ve benzersiz durum ortaya çıkacak. Kripto paranın mevcut durumu, gelecekteki beklenen duruma kıyasla kovada bir düşüş.

Örneğin, Ethereum'un yaygın olarak bahsedilen "uzlaşma güvenceleri", stabilcoinler (örneğin USDC) veya tokenize edilmiş hazine bonoları gibi gerçek dünya varlıkları (RWA'lar) için çok az şey ifade ediyor. İhraççının (örn. Circle) bunları kabul etmesi durumunda "yerleşmiştir".

Bu senaryoda, uygulamaların payı arttıkça Ethereum L2 olmanın çekiciliği azalabilir. Yeni bir USDC tabanlı ödeme uygulaması, doğası gereği Ethereum L2 olup olmadığını umursamaz. Kullanıcılara en iyi ürün deneyimini sunmalarına olanak tanıyan en ucuz, en hızlı, en güvenilir altyapıyı istiyorlar.

Burada rüzgarların değiştiğini açıkça görsek de, yeni bir devletin kurulması tarihsel olarak Solana için bir engel olmuştur. Solana'daki birçok tanınmış DeFi ve altyapı projesi artık tokenleri piyasaya sürüyor ve daha fazlası da gelecek. Bu Solana volanını harekete geçiriyor.

2.Ethereum ←→ L2 köprülerinin Ethereum ←→ L1 köprülerine tercih edilmesi (örn. güvenlik ve/veya UX nedenlerinden dolayı)

Belirli bir kullanım durumu için ilk varsayımın gerçekten karşılandığını varsayalım (örn. Ethereum-yerel, uygulamanız için oldukça değerlidir). Daha sonra, L2'nin bu varlıkları ayrı bir L1'e göre daha avantajlı bir şekilde ortaya çıkarıp çıkaramayacağını sormamız gerekiyor. Diyelim ki bir kullanıcının bir miktar ETH'si var ve bunu USDC ile takas etmek istiyor. Nereye gidiyorlar?

Köprü güvenliği burada sıklıkla bir motivasyon kaynağı olarak gösterilse de, mevcut bilgilere göre bu argüman zayıf görünüyor. En büyük döner köprülerin çoğunun kanıtları bile yok, beyaz listeye alınmış kanıtları var, çoklu imza kontrollü yükseltmeleri var veya tam anlamıyla bir L2'ye bile sahip değiller.

Bu, klasik fikir birliği doğrulayıcı köprülemeyle (örn. IBC) kıyaslanır. Uygulamada bu tür senaryolarda önemli bir doğrulayıcı yetersayı hatası yaşanmadı. Köprü arızaları genellikle hack'ler ve/veya güvenliği ihlal edilmiş köprü çoklu imzaları (L2'ler de aynı derecede hassastır) nedeniyle meydana gelmiştir.

Güvenlik iyileştirmeleri benim için bu noktada daha az ikna edici olsa da, Ethereum kullanıcılarına ve varlıklarına kolay erişim, benim görüşüme göre bugün L2 köprülemenin büyük bir faydasıdır. Base, Optimism ve Arbitrum gibi toplamalar daha çok Ethereum'un uzantılarına benziyor. Kullanıcılar aynı cüzdanları ve adresleri tutar, native gas token, ETH'nin tek kanonik bir versiyonudur, ETH, tüm işlem çiftleri gibi DeFi'ye hakimdir, sosyal uygulamalar, ETH'de NFT'leri fiyatlandırır ve yaratıcılara ETH'de ödeme yapar (örn., friend.tech), L2'ye yapılan para yatırma işlemleri anında gerçekleşir (çünkü birlikte yeniden düzenleneceklerdir) vb.

Kullanıcıların hangi köprüyü kullanacakları konusunda akıl yürütmeleri, değişen güvenlik varsayımlarını analiz etmeleri, mevcut birkaç sarılmış tokenden birini almaları, zincirin gas için yerel tokenini edinmeleri vb. beklenemez. Sadece ETH'lerini köprülemek, ETH'yi diğer tarafa almak ve L2'yi Ethereum veya başka herhangi bir L2'yi kullanacakları gibi kullanmaya devam etmek istiyorlar. Bu nedenle Eclipse, gaz için kullanılan yerel token olarak ETH'yi kullanacak. Yeni bir gas jetonunun zorla girilmesi UX'e zarar verir.

Peki Solana neden Ethereum L2 ile aynı avantajları sağlayamıyor? Bu aslında temel bir şeyden çok bir mühendislik sorusu haline geliyor ve zamanla daha da kolaylaşacak. Bu, gaz belirteçlerinin yanı sıra EVM'yi kullanmamakla ilgili diğer UX zorlukları için de geçerlidir (ki bu, L1 ve L2'ye özgü değildir):

• Gas token - Gas ödemeleri kullanıcılardan soyutlanarak kullanıcıların seçtikleri gas tokenı ile ödeme yapmalarına olanak sağlanır.
• Köprüleme - Köprülemenin zaman içinde daha fazla sertleşmesi ve standartlaşması muhtemeldir, bu da kullanıcılarda daha az kafa karışıklığına ve likidite parçalanmasına yol açacaktır.
• Cüzdanlar - MetaMask'ın yakın zamanda tanıtılan Snap'leri, Drift'in veya Solflare'nin MetaMask Snap'leri gibi, üzerine inşa edilen üçüncü taraf entegrasyonları aracılığıyla MetaMask desteğini EVM olmayan zincirlere kadar genişletiyor.
• Geliştirici Deneyimi - Dil engelleri ortadan kalkacak. Solang ve Neon gibi projeler Solidity geliştiricilerinin Solana üzerinde geliştirme yapmasına yardımcı olabilir ve Stylus gibi projeler Rust geliştiricilerinin Arbitrum üzerinde geliştirme yapmasına yardımcı olabilir.

Gelecekte, kullanıcılar Solana'nın hızı ve ölçeği ile ETH'ye yönelik güçlü tercihlerini ifade ederse, ETH'nin Solana DeFi'de rol oynaması bile mümkün olabilecektir. Uygulamada, Ethereum'a özgü varlıklara sahip bu kullanıcıların, karşılaştırılabilir şekilde ölçeklenebilir L2'lere erişimleri olduğu varsayılarak, tartıştığımız nedenlerden dolayı bunları Ethereum L2 ekosistemi içinde kullanmaya devam etmeleri çok daha muhtemeldir.

Uygulamaya özel ve Genel amaçlı

Bir zincirin L1 veya L2 olmasına bakılmaksızın, yürütmeyi ölçeklendirerek tek zincir verimini artırmaya açık bir ihtiyaç vardır. Toplamalar parçalanma anlamına gelmemelidir. Pek çok homojen zincirin durum bilgisi olan paylaşılan sıralayıcı altında birleştirilmesi, daha zorlu bir UX ile ölçeklendirme perspektifinden bakıldığında paralelleştirilmiş bir zincir gibi görünmesine neden olur.

Uygulamaya özel bir toplamayı dağıtmanın nedeni olarak sıklıkla "özel blok alanının" belirtildiğini görüyoruz. Ancak bu yanılgı, büyük ölçüde tek iş parçacıklı EVM'nin küresel ücret piyasalarıyla gereksiz sınırlamalarından kaynaklanmıştır. Yerel ücret pazarlarıyla paralelleştirilmiş bir SVM, uygulama zincirlerine olan ihtiyacı büyük ölçüde azaltır. Paylaşılan altyapıda daha fazla uygulamanın barındırılması, geliştirici ve kullanıcı karmaşıklığını anlamlı ölçüde azaltır. Çok zincirli bir dünyada zincirler arası kullanıcı deneyimi ve geliştirici karmaşıklığı, yeterince takdir edilmeyen bir varoluşsal risktir.

Bu, günün sonunda kelimenin tam anlamıyla tek bir zincir olacağı anlamına gelmiyor. Kendi zincirinizi dağıtmak için genel olarak dört argüman görüyorum:

1. Ölçeklenebilirlik ve Özel Blok Alanı - Yukarıda belirtildiği gibi, bu genellikle ikna edici değildir. Bir NFT nanesi zincirin geri kalanını etkili bir şekilde kapatmamalı, ancak cevap genellikle başka bir zincir yapmak değildir. Bu durum, yerel ücret piyasalarıyla paralelleştirilmiş bir VM ile hafifletilir. Ancak tüm ağın bant genişliği doyuma ulaştığı ölçüde, yerel ücret piyasaları işe yaramayacaktır (yani, paylaşılan zincirin ücretleri küresel olarak artacaktır). O zaman başka bir zincire ihtiyacın var.
2. Egemenlik - Kriptoda yönetişim hala oldukça zayıf ve kendi zincirden çatala sahip olmak yararlı bir koordinasyon mekanizması olabilir. Sezgilerim bunun çok nadir görülen bir durum olduğu yönünde, ancak kesin olarak söylemek zor. Bu , MakerDAO'nun uygulama zincirine olan ilgisiyle uyumludur.
3. Özelleştirilebilirlik - Konsensüs düzeyindeki özelleştirmeler belirli uygulamalar için değerli olabilir (örneğin, dYdX v4), ancak bu durumlar deneysel olarak az sayıdadır ve bugüne kadar çok uzaktır. Bir uygulama zincirinin parlak örneği olan dYdX bile, son Bell Curve bölümünde Antonio'ya göre "muhtemelen dYdX zincirinde genelleştirilmiş uygulamaya doğru daha fazla ilerleyecek". Paylaşılan bir zincirde çözülemeyen tam yığın özelleştirilebilirlik ihtiyacı genellikle kripto paraların çoğunda eksikti. Neredeyse tüm yeni toplamalar, yeni tokenlara sahip sıradan EVM çatallarından ibaret olmaya devam ediyor.
4. Değer Yakalama - Bu muhtemelen özelleştirilebilirliğin bir alt kümesidir, ancak oldukça önemlidir, bu yüzden onu böleceğiz. Yalnızca uygulamanız düşünülerek oluşturulmamış paylaşılan altyapının değerini içselleştirmek daha zor olabilir. Uygulama zincirleri, sorumlu uygulamalara değer tahsis edilmesini kolaylaştırabilir. Ancak bu, temel bir çabanın ötesinde bir mühendislik çabasıdır ve Solana'da bunun tam olarak nasıl yapılacağına ilişkin araştırmalar devam etmektedir. Ek olarak, kendi zincirinizi kurmanın, paylaşılan altyapı genelinde maliyetleri amorti etmenin ciddi bir genel gider maliyeti olduğunu unutmayın.

Bugün bir uygulama zinciri başlatmanın temel motivasyonu, genellikle zor durumdaki bir proje için algılanan anlatı desteği ve/veya belirteç faydasıdır. Ayı piyasasındaki gerileme ve buna bağlı olarak uygulama büyümesindeki eksiklik, aşırı karmaşık bir mimarinin geliştirilmesini ve finanse edilmesini teşvik etti ve bu da, kendi kendine oluşan karmaşıklıkları çözmek için yeni projelere ihtiyaç duyulmasıyla sonuçlandı.

Bugün kendi zincirinizi başlatmak, çoğu uygulamanın artan faydaları haklı çıkaramayacağı acı verici ve gereksiz ödünleşimleri (karmaşıklık, maliyet, daha kötü kullanıcı deneyimi, parçalanmış likidite vb.) beraberinde getirir. Bu kullanıcı deneyimini rekabetçi hale getirmek için gereken altyapı uzak görünüyor. Bu, uygulama zincirlerinin var olması için hiçbir neden olmadığı anlamına gelmez (kesinlikle vardır). Aksine, bir endüstri olarak anlatıyı bu yönde büyük ölçüde aşırı indeksledik ve bu nedenle, mevcut durum göz önüne alındığında yeniden paketlemeye yönelik mevcut eğilim açıkça faydalıdır.

Çözüm

Solana son aylarda haklı olarak büyük bir ivme kazandı. Bu keskin düzeltme, büyük ölçüde çok zincirli UX'in mevcut durumunun tanınmasından kaynaklanıyor; parçalanmış ve acı verici. Solana uygulamalarını kullanmanın kullanıcı deneyimi gerçekten inanılmaz. Pürüzsüz ve hızlı.

Toplamalar ve L2'ler UX açısından kötü bir şöhrete sahipler, ancak asıl sorun parçalanmadır. Toplamaları ve L2'leri parçalanmış yatay ölçeklendirmeyle ilişkilendiriyoruz çünkü pratikte çoğu EVM'yi olduğu gibi çatallamış ve kısıtlı DA bant genişliği kullanıyor. Sonunda pahalı ve kullanımı hantal hale gelirler.

Ancak bu temel değildir. Ölçeklenebilir bir DA katmanı üzerinde güçlü bir VM ile dikey olarak ölçeklendirme, bu kullanıcı deneyimi ve maliyet sorunlarını giderir. Hem L1'ler hem de L2'ler için yığının bir miktar yeniden paketlenmesi muhtemeldir. L2'ler ve toplamalar, doğru kullanıldığında kullanıcı deneyimini iyileştirecektir. Bu onların gerçek satış noktası olmalı.

Her iki yaklaşımın da yararları vardır. Öncelikle kendimize "Bu ürün hangi pazara hitap etmeye çalışıyor?" sorusunu sorarak daha iyi bir iş yapmamız gerekiyor. ve "bu mimari ihtiyacım olanı nasıl çözebilir?" bir sonraki L1, L2, L3'ü inşa etmeye başlamadan önce…

Yasal Uyarı:

1. Bu makale [dba]'dan yeniden basılmıştır. Tüm telif hakları orijinal yazara [Jon Charbonneau] 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.