Ölçeklenebilirlik Dengesi: Polkadot ve Web3 Arasındaki Seçim

Bugün blockchain sürekli daha yüksek verimlilik peşindeyken, bir anahtar soru giderek belirginleşiyor: Performansı artırırken güvenliği ve sistem esnekliğini nasıl sağlayabiliriz? Bu sadece teknik düzeyde bir meydan okuma değil, aynı zamanda mimari tasarımın derin bir seçimidir. Web3 ekosistemi için, güven ve güvenlikten ödün verilerek kurulan daha hızlı bir sistem, genellikle gerçekten sürdürülebilir yenilikleri desteklemede zorlanır.

Web3 ölçeklenebilirliğinin önemli bir itici gücü olarak Polkadot, yüksek throughput ve düşük gecikme hedeflerine ulaşırken bazı ödünler vermiş olabilir mi? Rollup modeli, merkeziyetsizlik, güvenlik veya ağ birlikte çalışabilirliği açısından herhangi bir taviz verdi mi? Bu makale, Polkadot'un ölçeklenebilirlik tasarımındaki tercihlerini ve dengelemelerini derinlemesine inceleyecek ve diğer ana akım kamu blok zincirlerinin çözümleri ile karşılaştırarak, bunların performans, güvenlik ve merkeziyetsizlik arasında farklı yol seçimlerini araştıracaktır.

Polkadot genişleme tasarımında karşılaşılan zorluklar

Esneklik ve merkeziyetsizlik dengesi

Polkadot'un mimarisi, doğrulayıcı ağı ve merkezi bir ara zincir üzerine dayanıyor, bu bazı açılardan merkeziyetçilik riski getirebilir mi? Tek bir arıza noktası veya kontrol oluşabilir mi ve bu, merkeziyetsizlik özelliklerini etkileyebilir mi?

Rollup'ın çalışması, ara zincir ile bağlantılı sıralayıcılara dayanır ve iletişim, collator protokolü adı verilen bir mekanizma 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 dönüşüm taleplerini gönderebilir. Bu talepler, ara zincirin bir core'u tarafından doğrulanır, tek bir ön koşul gerektirir: geçerli bir durum dönüşümü olmalıdır, aksi takdirde bu rollup'ın durumu ilerletilmeyecektir.

Dikey genişletme dengesi

Rollup, Polkadot'un çoklu çekirdek 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ğrulamasının belirli bir çekirdek üzerinde sabitlenmemesi nedeniyle esnekliğini etkileyebileceğini fark ettik.

Orta katman zincirine blok göndermenin protokolü, izin gerektirmeyen ve güvene dayanmayan bir yapıya sahip olduğundan, herkes, rollup'a tahsis edilen herhangi bir çekirdek üzerinde doğrulama yapmak üzere blok gönderebilir. Saldırganlar, daha önce doğrulanmış olan meşru blokları farklı çekirdeklerde tekrar tekrar göndermek için bunu kötüye kullanabilir, bu da kaynakları kötüye kullanarak rollup'ın genel verimliliğini ve verimliliğini azaltır.

Polkadot'un hedefi, sistemin temel özelliklerini etkilemeden rollup esnekliğini ve relay 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 sıralayıcının kötü niyetli davranmayacağına güvenmektir, böylece rollup'ın aktivitesini güvence altına alır.

Ancak, Polkadot'un tasarım felsefesinde, sequencer'a herhangi bir güven varsayımı yapamayı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: Sorunu tamamen rollup durum dönüşüm fonksiyonu (Runtime)'e bırakmaktır. 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 yönlü korunmasını sağlamaktadır. Polkadot, kullanılabilirlik sürecinde rollup'ın durum geçişlerini yeniden gerçekleştirir ve ELVES şifreleme ekonomik protokolü aracılığıyla core dağıtımının doğruluğunu garanti eder.

Herhangi bir rollup bloğuna Polkadot veri kullanılabilirlik katmanı (DA) yazılmadan önce, yaklaşık 5 doğrulayıcıdan oluşan bir grup önce onun geçerliliğini doğrular. 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 işlevine iletilecek ve ara zincirdeki doğrulayıcılar tarafından yeniden işlenecektir.

Doğrulama sonucunda bir core seçici bulunur, bu, blokların hangi core üzerinde doğrulanacağını belirtmek için kullanılır. Doğrulayıcı, bu indeksin kendisinin sorumlu olduğu core ile uyumlu olup olmadığını kontrol eder; uyumsuz ise, bu blok atılacaktır.

Bu mekanizma, sistemin her zaman güvene ihtiyaç duymadan ve izin gerektirmeden çalışması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ğini korumasını garanti eder.

güvenlik

Ölçeklenebilirlik peşinde koşarken, Polkadot güvenlikten ödün vermemiştir. Rollup'ın güvenliği, ana 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 tamamen genişletir, tüm çekirdek üzerindeki hesaplamaları doğrular, çekirdek sayısı üzerinde herhangi bir kısıtlama veya varsayımda bulunmadan.

Bu nedenle, Polkadot'un rollup'ları güvenlikten ödün vermeden gerçek ölçeklenebilirlik sağlayabilir.

Genel Kullanım

Esnek genişleme, rollup'un programlanabilirliğini kısıtlamaz. Polkadot'un rollup modeli, WebAssembly ortamında Turing eksiksiz hesaplamaların gerçekleştirilmesini destekler, tek bir yürütmenin 2 saniye içinde tamamlanması şartıyla. Esnek genişleme sayesinde, her 6 saniyelik döngü içinde gerçekleştirilebilecek toplam hesaplama miktarı artırılmakta, ancak hesaplama türleri etkilenmemektedir.

karmaşıklık

Daha yüksek bir throughput ve daha düşük gecikme, kaçınılmaz olarak karmaşıklığı beraberinde getirir; bu, sistem tasarımında tek kabul edilebilir uzlaşma yoludur.

Rollup, Agile Coretime arayüzü aracılığıyla kaynakları dinamik olarak ayarlayarak tutarlı bir güvenlik seviyesini sürdürebilir. Ayrıca, farklı kullanım senaryolarına uyum sağlamak için RFC103'ün bazı gereksinimlerini yerine getirmeleri gerekir.

Spesifik karmaşıklık, rollup'ın kaynak yönetim stratejilerine bağlıdır; bu stratejiler zincir üzerinde veya zincir dışında değişkenlere dayanabilir. Örneğin:

• Basit strateji: her zaman sabit bir core miktarı kullanın veya dışarıda manuel olarak ayarlayın;

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

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

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

birlikte çalışma

Polkadot, farklı rollup'lar arasında etkileşim desteği sağlarken, esnek ölçeklenme mesaj iletiminin verimliliğini etkilemez.

Rollup'lar arası mesaj iletişimi, alt katman taşıma katmanı tarafından gerçekleştirilir; her rollup'ın iletişim blok alanı sabittir ve tahsis edilen çekirdek sayısıyla ilgili değildir.

Gelecekte, Polkadot ayrıca, veri yüzeyi yerine kontrol yüzeyi olarak bir ara zincir kullanarak, zincir dışı mesaj iletimini destekleyecektir. Bu güncelleme, rollup'lar arası iletişim yeteneğini esnek ölçeklenme ile birlikte artıracak ve sistemin dikey ölçeklenme yeteneğini daha da güçlendirecektir.

Diğer protokoller hangi uzlaşmaları sağladı?

Herkesçe bilindiği gibi, performans artışı genellikle merkeziyetsizlik ve güvenlikten ödün vermekle sağlanır. Ancak Nakamoto katsayısına bakıldığında, bazı Polkadot rakiplerinin merkeziyetsizlik düzeyi düşük olsa bile, performansları pek tatmin edici değildir.

Solana

Solana, Polkadot veya Ethereum'un shard mimarisini kullanmamakta, bunun yerine tek katmanlı yüksek işlem hacmi mimarisi ile ölçeklenebilirliği sağlamaktadır. Tarihsel kanıt (PoH), CPU paralel işleme ve lider tabanlı konsensüs mekanizmasına dayanarak, teorik TPS 65.000'e kadar ulaşabilir.

Ana tasarımlardan biri, önceden halka açık ve doğrulanabilir bir lider atama mekanizmasıdır:

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

• Daha fazla stake yapıldıkça, daha fazla dağıtım yapılır. Örneğin, %1'lik bir doğrulayıcı stake eden yaklaşık %1 blok oluşturma şansına sahip olacaktır;

• Tüm blok oluşturucular ö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 tutar, bu da doğrulama düğümlerinin merkezileşmesine yol açar. Daha fazla stake edilen düğümlerin blok oluşturma şansı daha büyükken, küçük düğümlerin neredeyse hiç slotu yoktur, bu da merkezileşmeyi daha da artırır ve saldırı sonrası sistemin çökme riskini artırır.

Solana, TPS peşinde merkeziyetsizlik ve saldırı direncinden ödün vermiştir; Nakamoto katsayısı yalnızca 20'dir ve bu, Polkadot'un 172'sinin çok altındadır.

TON

TON, 104.715 TPS'ye ulaşabileceğini iddia ediyor, ancak bu sayı özel bir test ağında, 256 düğümle, 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: shard doğrulayıcılarının kimliği önceden ifşa edilebilir. TON beyaz kitabı da açıkça belirtmektedir ki, 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 shardı tamamen kontrol altına almak için bekleyebilir ya da dürüst doğrulayıcıları engellemek için DDoS saldırıları gerçekleştirebilir, böylece durumu değiştirebilir.

Buna karşılık, Polkadot'un doğrulayıcıları rastgele dağıtılır ve gecikmeli olarak açıklanır; saldırganlar, doğrulayıcıların kimliğini önceden bilemezler. Saldırı, tüm kontrolü başarıyla kazanmayı gerektirir; eğer bir dürüst doğrulayıcı itirazda bulunursa, saldırı başarısız olur ve saldırganın teminatı kaybetmesine yol açar.

Avalanche

Avalanche, ana ağ + alt ağ mimarisi kullanarak ölçeklenir; ana ağ, X-Chain( transferleri, ~4.500 TPS), C-Chain( akıllı sözleşmeleri, ~100-200 TPS) ve P-Chain( doğrulayıcıları ve alt ağları yönetimi ile 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ılma özgürlüğüne izin verir ve alt ağlar coğrafi, KYC gibi ek gereklilikler belirleyebilir, bu da merkeziyetsizlik ve güvenlikten fedakarlık yapılması 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 uzlaşma sağlanması gerekir ve belirleyici bir güvenlik taahhüdü sunmak zordur.

) Ethereum

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

İyimser Rollup

Şu anda çoğu Optimistic rollup merkeziyettir, bu da güvenlik yetersizliği, birbirinden izole olma, yüksek gecikme gibi sorunlar barındırmaktadır. Dolandırıcılık kanıtı sürecinin beklenmesi gerekiyor, genellikle birkaç gün sürmektedir.

ZK Rollup

ZK rollup'un uygulanması, tek bir işlemde işlenebilecek veri miktarıyla sınırlıdır. Sıfır bilgi kanıtı oluşturmanın hesaplama gereksinimleri son derece yüksektir ve "kazanan her şeyi alır" mekanizması sistemin merkezileşmesine yol açabilir. TPS'yi sağlamak için, ZK rollup genellikle her bir işlem grubunun boyutunu sınırlar; yüksek talep olduğunda ağ tıkanıklığı ve gaz fiyatlarının artması gibi sorunlara yol açarak kullanıcı deneyimini etkileyebilir.

Karşılaştırıldığında, Turing tam ZK rollup'ın maliyeti yaklaşık olarak Polkadot'un temel kriptoekonomi güvenlik protokolünün 2x10^6 katıdır.

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

Sonuç

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

Diğer halka açık blok zincirler ile karşılaştırıldığında, Polkadot merkezileşmeyi performans ile değiştirme veya önceden belirlenmiş güveni verimlilik ile değiştirme yoluna girmemiştir, bunun yerine esnek ölçeklenebilirlik, izin gerektirmeyen protokol tasarımı, birleştirilmiş 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 daha büyük ölçekli uygulamaların hayata geçirilmesini hedeflerken, Polkadot'un benimsediği "sıfır güven genişletilebilirlik" belki de Web3'ün uzun vadeli gelişimini destekleyebilecek gerçek çözüm.