Ölçeklenebilirlik Dengelemesi: Polkadot ve Web3 Seçimi

Blockchain teknolojisinin sürekli olarak verimlilik artışını hedeflediği günümüzde, bir anahtar sorun yavaş yavaş gün yüzüne çıkıyor: Ölçeklenebilirliği artırırken güvenlik ve sistem esnekliğinden ödün vermemek nasıl mümkün olacak? Bu yalnızca teknik bir zorluk değil, aynı zamanda mimari tasarımın derin bir seçimi. Web3 ekosistemi açısından, güven ve güvenliğin feda edildiği bir temele dayanarak inşa edilen daha hızlı bir sistem, genellikle gerçek sürdürülebilir yenilikleri desteklemek için yetersiz kalır.

Web3 ölçeklenebilirliğinin önemli bir itici gücü olarak, Polkadot yüksek işlem hacmi ve düşük gecikme peşinde bazı tavizler vermiş olabilir mi? Rollup modeli merkeziyetsizlik, güvenlik veya ağ birlikte çalışabilirliği konusunda tavizler vermiş mi? Bu makale, Polkadot'un ölçeklenebilirlik tasarımındaki tercihlerini ve dengelemelerini derinlemesine inceleyecek ve diğer ana akım halka açık blok zincirlerinin çözümleriyle karşılaştırarak performans, güvenlik ve merkeziyetsizlik arasındaki farklı seçimleri tartışacaktır.

Polkadot genişletme tasarımının karşılaştığı zorluklar

Esneklik ve merkeziyetsizlik dengesi

Polkadot'un mimarisi doğrulayıcı ağı ve ara zincir üzerine dayanıyor, bu bazı açılardan merkeziyetçilik risklerini beraberinde getirebilir mi? Tek bir arıza noktası veya kontrol oluşma ihtimali var mı, bu da onun merkeziyetsiz özelliklerini etkileyebilir mi?

Rollup'ın çalışması, bağlantılı ara zincirin sıralayıcılarına bağımlıdır ve iletişim, collator protokolü olarak adlandırılan bir mekanizmayı kullanır. Bu protokol tamamen izinsiz ve güvensizdir, ağ bağlantısı olan herkes bunu kullanabilir, az sayıda ara zincir düğümüne bağlanabilir ve rollup'ın durum geçişi taleplerini sunabilir. Bu talepler, ara zincirin bir core'u tarafından doğrulanır ve sadece bir ön koşulu yerine getirmesi gerekir: Geçerli bir durum geçişi olmalıdır, aksi takdirde bu rollup'ın durumu ilerletilmeyecektir.

Dikey genişletme dengesi

Rollup, Polkadot'un çok çekirdekli mimarisinden yararlanarak dikey ölçeklenmeyi gerçekleştirebilir. Bu yeni yetenek, "esnek ölçeklenme" işlevi ile tanıtıldı. Tasarım sürecinde, rollup blok doğrulamanın belirli bir çekirdekte sabitlenmemesi nedeniyle esnekliğini etkileyebileceği keşfedildi.

Orta zincire blok göndermek için protokol izin gerektirmeyen ve güvene dayanmayan bir yapıya sahip olduğundan, herkes, rollup'a tahsis edilen herhangi bir core'a blok gönderebilir ve doğrulama yapabilir. Saldırganlar, daha önce doğrulanmış olan yasal blokları farklı core'lara tekrar tekrar göndererek kötü niyetli bir şekilde kaynak tüketebilir ve bu da rollup'ın genel verimliliğini ve verimliliğini azaltabilir.

Polkadot'un amacı, sistemin temel özelliklerini etkilemeden rollup esnekliğini ve ara zincir kaynaklarının etkin kullanımını sürdürmektir.

Sequencer güvenilir mi?

Basit bir çözüm, protokolü "izinli" olarak ayarlamaktır: örneğin beyaz liste mekanizması kullanmak veya varsayılan olarak güvenilir sıralayıcının kötü niyetli davranmayacağını varsaymak, böylece rollup'ın etkinliğini güvence altına almak.

Ancak, Polkadot'un tasarım felsefesinde, sequencer'a herhangi bir güven varsayımında bulunamayız, çünkü sistemin "güven gerektirmeyen" ve "izin gerektirmeyen" özelliklerini korumak zorundayız. Herkes, collator protokolünü kullanarak rollup durum dönüşüm talepleri gönderebilmelidir.

Polkadot: Taviz Vermeyen Çözüm

Polkadot'un nihai seçtiği çözüm şudur: Sorunu tamamen rollup'un durum dönüşüm fonksiyonuna (Runtime) bırakmak. Runtime, tüm konsensüs bilgilerinin tek güvenilir kaynağıdır, bu nedenle çıktıda hangi Polkadot çekirdeğinde doğrulamanın yapılması gerektiği açıkça belirtilmelidir.

Bu tasarım, esneklik ve güvenliğin çift korumasını sağlar. Polkadot, kullanılabilirlik sürecinde rollup durum geçişlerini yeniden gerçekleştirir ve ELVES kripto ekonomik protokolü aracılığıyla core dağıtımının doğruluğunu garanti eder.

Herhangi bir rollup bloğunun Polkadot veri kullanılabilirlik katmanına yazılmadan önce, yaklaşık 5 doğrulayıcıdan oluşan bir grup, geçerliliğini öncelikle doğrulayacaktır. Onlar, sıralayıcı tarafından sunulan aday makbuzları ve geçerlilik kanıtlarını alırlar, bunlar rollup bloğunu ve ilgili depolama kanıtını içerir. Bu bilgiler, paralel zincir doğrulama fonksiyonu tarafından işlenecek ve tekrar eden doğrulayıcılar tarafından yeniden yürütülecektir.

Doğrulama sonucunda, blokların hangi core üzerinde doğrulanacağını belirlemek için bir core seçici içerir. Doğrulayıcı, bu indeksin kendisinin sorumlu olduğu core ile uyumlu olup olmadığını kontrol eder; eğer uyumsuzsa, bu blok atılacaktır.

Bu mekanizma, sistemin her zaman güven gerektirmeyen ve izin gerektirmeyen özelliklerini korumasını sağlar, sıralayıcı gibi kötü niyetli aktörlerin doğrulama konumunu manipüle etmesini önler ve rollup birden fazla çekirdek kullansa bile esnekliği korur.

güvenlik

Ölçeklenebilirlik peşinde koşarken, Polkadot güvenlikten ödün vermemiştir. Rollup'ın güvenliği, bir ara zincir tarafından sağlanır ve yalnızca bir dürüst sıralayıcı hayatta kalmayı sürdürebilir.

ELVES protokolü sayesinde, Polkadot güvenliğini tüm rollup'lara tam olarak genişletir, tüm çekirdek üzerindeki hesaplamaları doğrular, çekirdek sayısı üzerinde herhangi bir kısıtlama veya varsayımda bulunmaya gerek kalmaz.

Bu nedenle, Polkadot'un rollup'ları gerçek ölçeklenebilirliği güvenlikten ödün vermeden gerçekleştirebilir.

Genel Kullanım

Esnek genişleme, rollup'ın programlanabilirliğini kısıtlamaz. Polkadot'un rollup modeli, her bir yürütmenin 2 saniye içinde tamamlanması koşuluyla, WebAssembly ortamında Turing tam hesaplamaların gerçekleştirilmesine olanak tanır. Esnek genişleme sayesinde, her 6 saniyelik döngüde gerçekleştirilebilecek toplam hesaplama miktarı artırılır, ancak hesaplama türleri etkilenmez.

karmaşıklık

Daha yüksek bir geçiş hacmi ve daha düşük bir gecikme kaçınılmaz olarak karmaşıklığı beraberinde getirir; bu, sistem tasarımında tek kabul edilebilir trade-off yöntemidir.

Rollup, Agile Coretime arayüzü aracılığıyla kaynakları dinamik olarak ayarlayarak tutarlı bir güvenlik seviyesi sağlamaktadır. Ayrıca, farklı kullanım senaryolarına uyum sağlamak için kısmi RFC103 gereksinimlerini de yerine getirmeleri gerekmektedir.

Belirli karmaşıklık, rollup'ın kaynak yönetim stratejilerine bağlıdır ve bu stratejiler zincir üzerindeki veya zincir altındaki değişkenlere dayanabilir. Örneğin:

• Basit strateji: Her zaman sabit bir core miktarı kullanın veya zincir dışı manuel ayarlamalar yapın;

• Hafif strateji: Düğüm mempool'unda belirli işlem yüklerini izlemek;

• Otomatik strateji: Geçmiş veriler ve XCM arayüzü aracılığıyla coretime hizmetini önceden çağırarak kaynakları yapılandırma.

Otomatik yöntemler daha verimli olsa da, uygulama ve test maliyetleri de önemli ölçüde artmaktadır.

birlikte çalışabilirlik

Polkadot, farklı rolluplar arasındaki etkileşimi desteklerken, esnek ölçeklenebilirlik mesaj iletiminin verimliliğini etkilemez.

Rollup'lar arası mesaj iletimi, alt düzey taşıma katmanı tarafından gerçekleştirilir. Her bir rollup'ın iletişim blok alanı sabittir ve bunun dağıtılan çekirdek sayısıyla bir ilgisi yoktur.

Gelecekte, Polkadot ayrıca verilerin aktarımı için bir kontrol yüzeyi olarak, veri yüzeyi yerine bir ara zincir ile dışa mesaj iletimini destekleyecektir. Bu güncelleme, rolluplar arasındaki iletişim yeteneklerini esnek bir şekilde genişleterek sistemin dikey genişleme yeteneklerini daha da artıracaktır.

Diğer protokoller hangi dengelemeleri yaptı?

Herkesin bildiği gibi, performans artışı genellikle merkeziyetsizlik ve güvenlikten ödün verme pahasına gelir. Ancak Nakamoto katsayısına göre, bazı Polkadot rakiplerinin merkeziyetsizlik derecesi düşük olsa da, performansları da pek iç açıcı değildir.

Solana

Solana, Polkadot veya Ethereum'un parçalama mimarisini kullanmaz; bunun yerine, tarihsel kanıt (PoH), CPU paralel işleme ve lider bazlı konsensüs mekanizmasına dayanarak ölçeklenebilirliği tek katmanlı yüksek verim mimarisi ile gerçekleştirir. Teorik TPS 65.000'e kadar ulaşabilir.

Bir ana tasarım, önceden açıklanmış ve doğrulanabilir liderlik zamanlama mekanizmasıdır:

• Her epoch (yaklaşık iki gün veya 432.000 slot) başlangıcında, staking miktarına göre slot dağıtılır;

• Ne kadar fazla stake ederseniz, o kadar fazla dağıtım alırsınız. Örneğin, %1'lik bir doğrulayıcı stake edenler yaklaşık %1'lik blok oluşturma şansına sahip olacaktır;

• Tüm blok üreticileri önceden duyuruldu, bu da ağın hedefli DDoS saldırılarına ve sık sık kesintilere maruz kalma riskini artırdı.

PoH ve paralel işleme, donanım gereksinimlerini son derece yüksek hale getirerek doğrulayıcı düğümlerin merkezileşmesine neden olur. Daha fazla staking yapan düğümlerin blok oluşturma olasılığı daha yüksektir, küçük düğümlerin neredeyse hiç slotu yoktur, bu durum merkezileşmeyi daha da artırır ve sistemin saldırıya uğraması durumunda çökme riskini artırır.

Solana, TPS peşinde merkeziyetsizlik ve saldırı direncinden feragat etmiştir; Nakamoto katsayısı yalnızca 20'dir ve bu Polkadot'un 172'sinin oldukça altındadır.

TON

TON, TPS'nin 104.715'e ulaşabileceğini iddia ediyor, ancak bu rakam özel test ağında, 256 düğüm ile, ideal ağ ve donanım koşulları altında gerçekleştirilmiştir. Polkadot ise merkeziyetsiz genel ağda 128K TPS'ye ulaşmıştır.

TON'un konsensüs mekanizmasında güvenlik açığı var: parça doğrulayıcı düğümlerinin kimliği önceden ifşa edilebilir. TON beyaz kitabında da belirtildiği gibi, bu bant genişliğini optimize etse de, kötü niyetli bir şekilde kullanılabilir. "Kumarbaz iflası" mekanizmasının eksikliği nedeniyle, saldırganlar bir parçayı tamamen kontrol altına almak için bekleyebilir veya dürüst doğrulayıcıları engellemek için DDoS saldırıları gerçekleştirebilir, böylece durumu değiştirebilir.

Buna kıyasla, Polkadot'un doğrulayıcıları rastgele dağıtılır ve geç açıklanır, bu nedenle saldırganlar doğrulayıcıların kimliğini önceden bilemezler, saldırı tüm kontrolü başarıyla elde etmeyi gerektirir, bir dürüst doğrulayıcı itirazda bulunduğu sürece saldırı başarısız olur ve saldırganın stake ettiği miktar kaybolur.

Avalanche

Avalanche, ana ağ + alt ağ mimarisini genişletmek için kullanır; ana ağ, X-Chain (transfer, ~4,500 TPS), C-Chain (akıllı sözleşmeler, ~100-200 TPS) ve P-Chain (doğrulayıcıları ve alt ağları yönetme) bileşenlerinden oluşur.

Her bir alt ağın teorik TPS'si ~5,000'e ulaşabilir, Polkadot'un yaklaşımına benzer: Tek bir shard'ın yükünü azaltarak ölçeklenebilirlik sağlamak. Ancak Avalanche, doğrulayıcıların alt ağlara katılmayı özgürce seçmelerine izin verir ve alt ağlar coğrafi, KYC gibi ek gereksinimler belirleyebilir, bu da merkezsizlik ve güvenlikten feragat anlamına gelir.

Polkadot'ta, tüm rolluplar ortak bir güvenlik garantisi paylaşır; oysa Avalanche'ın alt ağlarının varsayılan bir güvenlik garantisi yoktur, bazıları tamamen merkezi hale gelebilir. Güvenliği artırmak istendiğinde, yine de performansta bir fedakarlık yapmak gerekir ve kesin bir güvenlik taahhüdü sağlamak zordur.

Ethereum

Ethereum'un ölçeklenme stratejisi, temel katmanda doğrudan sorunları çözmek yerine, rollup katmanının ölçeklenebilirliğine bahis oynamaktır. Bu yaklaşım aslında sorunu çözmemektedir, aksine sorunu yığının bir üst katmanına aktarmaktadır.

İyimser Rollup

Şu anda çoğu Optimistic rollup merkeziyettir ve güvenlik eksikliği, birbirine izole olma, yüksek gecikme (genellikle birkaç gün süren dolandırıcılık kanıtı süresini beklemek gerekir) gibi sorunlar vardır.

ZK Rollup

ZK rollup'un uygulanması, tek bir işlemde işlenebilecek veri miktarı ile sınırlıdır. Sıfır bilgi kanıtı üretiminin hesaplama gereksinimleri oldukça yüksektir ve "kazanan her şeyi alır" mekanizması, sistemi merkezileştirme eğilimindedir. TPS'nin garanti altına alınması için, ZK rollup genellikle her seferdeki işlem miktarını kısıtlar, bu da yüksek talep durumunda ağ tıkanıklığı ve gaz fiyatlarının artmasına neden olarak kullanıcı deneyimini olumsuz etkileyebilir.

Buna karşılık, Turing tam ZK rollup maliyeti, Polkadot'un temel kripto ekonomik güvenlik protokolünün yaklaşık 2x10^6 katıdır.

Ayrıca, ZK rollup'ın veri kullanılabilirliği sorunları, dezavantajlarını daha da artıracaktır. Herkesin işlemleri doğrulamasını sağlamak için, tam işlem verilerinin sağlanması gerekmektedir. Bu genellikle ek veri kullanılabilirliği çözümlerine bağımlılık gerektirir ve maliyetleri ile kullanıcı ücretlerini daha da artırır.

Sonuç

Ölçeklenebilirliğin sonu, bir uzlaşma olmamalıdır.

Diğer halka açık zincirlerle karşılaştırıldığında, Polkadot merkeziyeti performans için değiştirip, önceden belirlenmiş bir güveni verimlilik için değiştirme yoluna gitmemiştir; bunun yerine, esnek ölçeklenebilirlik, izin gerektirmeyen protokol tasarımı, birleşik güvenlik katmanı ve esnek kaynak yönetim mekanizması ile güvenlik, merkeziyetsizlik ve yüksek performans arasında çok boyutlu bir denge sağlamıştır.

Bugünün daha büyük ölçekli uygulamaların hayata geçirilmesine yönelik çabalarında, Polkadot'un benimsediği "sıfır güven ölçeklenebilirliği", belki de Web3'ün uzun vadeli gelişimini destekleyebilecek gerçek çözüm.