Genişletilebilirlik Seçimi: Polkadot ve Web3 Arasındaki Denge

Günümüzde blockchain'in daha yüksek verimlilik peşinde koştuğu bir ortamda, bir anahtar sorun giderek belirginleşiyor: Performansı artırırken güvenlik ve sistem esnekliğinden nasıl ödün vermeden? Bu sadece teknik bir meydan okuma değil, aynı zamanda mimari tasarımın derin bir seçimidir. Web3 ekosistemi için, daha hızlı bir sistemin güven ve güvenlikten ödün verilerek inşa edilmesi, genellikle sürdürülebilir yenilikleri desteklemek için yeterli olmamaktadır.

Web3 ölçeklenebilirliğinin önemli bir destekçisi olarak, Polkadot yüksek işlem hacmi ve düşük gecikme hedefleri doğrultusunda bazı fedakarlıklar mı yaptı? Rollup modeli merkeziyetsizlik, güvenlik veya ağlar arası etkileşim konularında tavizler mi verdi?

Bu makale, Polkadot'un ölçeklenebilirlik tasarımındaki tercihlerine ve dengelemelerine derinlemesine bir bakış sunarak bu konular etrafında şekillenecek ve diğer ana akım halka açık blok zincirlerin çözümleri ile karşılaştıracak; performans, güvenlik ve merkeziyetsizlik arasındaki farklı yol seçimlerini 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 merkezi bir ara zincir üzerine dayanıyor. Bu, bazı açılardan merkeziyet riski getirebilir mi? Tek bir arıza noktası veya kontrol oluşması mümkün mü, bu da merkeziyetsiz özelliklerini etkileyebilir mi?

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

Dikey genişletme denemeleri

Rollup, Polkadot'un çok çekirdekli mimarisinden yararlanarak dikey ölçeklenmeyi gerçekleştirebilir. Bu yeni yetenek, "esnek ölçeklenebilirlik" işlevi ile tanıtıldı. Tasarım sürecinde, rollup blok doğrulamasının belirli bir çekirdek üzerinde sabitlenmediği keşfedildi ve bu durum esnekliğini etkileyebilir.

Orta zincire blok göndermek için kullanılan protokolün izin gerektirmediği ve güvene dayalı olmadığı için, herkes rollup'a tahsis edilen herhangi bir core'a blok göndererek doğrulama yapabilir. Saldırganlar, daha önce doğrulanmış olan geçerli blokları farklı core'lara tekrar tekrar göndererek kötü niyetli bir şekilde kaynak tüketebilir ve böylece rollup'ın genel verimliliğini ve verimliliğini azaltabilir.

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

Sequencer'in güven sorunları

Basit bir çözüm, protokolü "izinli" olarak ayarlamaktır: örneğin, beyaz liste mekanizması kullanmak veya varsayılan olarak güvenilir sıralayıcıların kötü niyetli davranışta bulunmayacağı varsayımında bulunarak rollup'ın aktivitesini 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'ın durum dönüşüm taleplerini sunabilmelidir.

Polkadot: Taviz Vermeyen Çözüm

Polkadot'un sonunda seçtiği çözüm: Sorunu tamamen rollup'un durum dönüşüm fonksiyonu (Runtime)'a bırakmaktır. Runtime, tüm konsensüs bilgilerini tek bir güvenilir kaynak olarak sunduğundan, çıktıda hangi Polkadot çekirdeğinde doğrulama yapılacağı açıkça belirtilmelidir.

Bu tasarım, esneklik ve güvenliğin çift yönlü korunmasını sağlıyor. Polkadot, kullanılabilirlik sürecinde rollup'un durum dönüşümünü yeniden gerçekleştirir ve ELVES kripto ekonomik protokolü ile core dağılımının doğruluğunu sağlar.

Herhangi bir rollup bloğunun Polkadot veri kullanılabilirlik katmanına yazılmadan önce, yaklaşık 5 kişiden oluşan bir grup önce onun geçerliliğini doğrular. Bu grup, sıralayıcının sunduğu aday makbuzlar ve geçerlilik kanıtlarını alır; bunlar rollup bloğu ve ilgili depolama kanıtlarını içerir. Bu bilgiler, paralel zincir doğrulama işlevi tarafından işlenir ve ara zincirdeki doğrulayıcılar tarafından yeniden yürütülür.

Doğrulama sonucunda, blokların hangi core üzerinde doğrulanacağını belirlemek için bir core selector bulunur. Doğrulayıcı, bu indeksin kendisine ait olan core ile tutarlı olup olmadığını karşılaştırır; eğer tutarsızsa, bu blok atılacaktır.

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

güvenlik

Genişleme amacı güderken, Polkadot güvenlikten ödün vermemiştir. Rollup'ın güvenliği, yalnızca bir dürüst sıralayıcı ile sürdürülebilirlik sağlaması için relay chain tarafından güvence altına alınmıştır.

ELVES protokolü sayesinde, Polkadot güvenliğini tüm rollup'lara tam olarak genişletiyor, tüm çekirdek üzerindeki hesaplamaları doğruluyor ve çekirdek sayısı konusunda herhangi bir kısıtlama veya varsayımda bulunmaya gerek kalmıyor.

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

Genel Kullanım

Esnek genişleme, rollup'ın programlanabilirliğini kısıtlamaz. Polkadot'un rollup modeli, tek bir işlemin 2 saniye içinde tamamlanması şartıyla, WebAssembly ortamında Turing tam hesaplamaları yürütmeyi destekler. 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 throughput ve daha düşük bir gecikme kaçınılmaz olarak karmaşıklığı beraberinde getirir; bu, sistem tasarımında tek kabul edilebilir denge 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 kısmi RFC103 gereksinimlerini yerine getirmeleri gerekmektedir.

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

• Basit strateji: her zaman sabit bir core miktarı kullanın veya zincir dışı manuel olarak ayarlayın;
• Hafif strateji: Belirli işlem yüklerini düğüm mempool'unda izlemek;
• Otomatik strateji: Tarihsel veriler ve XCM arayüzü aracılığıyla coretime hizmetini önceden çağırarak kaynakları yapılandırmak.

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

birlikte çalışabilirlik

Polkadot, farklı rolluplar arasında birlikte çalışabilirliği destekler ve esnek ölçeklenme, mesaj iletimi verimliliğini etkilemez.

Rollup'lar arası mesaj iletişimi, temel iletim katmanı tarafından gerçekleştirilir; her rollup'ın iletişim blok alanı sabittir ve atanan çekirdek sayısıyla ilgisi yoktur.

Gelecekte, Polkadot dışa mesaj iletimini destekleyecek, burada ara zincir kontrol düzlemi olarak işlev görecek, veri düzlemi olarak değil. Bu yükseltme, rollup'lar arası iletişim yeteneklerini esnek bir şekilde artırarak sistemin dikey genişleme yeteneklerini daha da güçlendirecek.

Diğer Protokollerin Değerlendirilmesi

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

Solana

Solana, Polkadot veya Ethereum'un parçalı mimarisini kullanmak yerine, tek katmanlı yüksek verim mimarisi ile ölçeklenebilirlik sağlamakta, tarihsel kanıtlama (PoH), CPU paralel işleme ve lider tabanlı konsensüs mekanizmasına dayanmaktadır. Teorik TPS 65,000'e ulaşabilir.

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

• Her epoch ( yaklaşık iki gün veya 432.000 slot) başladığında, stake miktarına göre slot dağıtılır;
• Daha fazla stake yapıldıkça, dağıtım o kadar fazla olur. Örneğin, %1'lik bir doğrulayıcı stake eden, yaklaşık %1'lik bir blok oluşturma şansına sahip olacaktır;
• Tüm blok oluşturanlar ö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 getiriyor ve bu da doğrulama düğümlerinin merkezileşmesine neden oluyor. Daha fazla stake eden düğümlerin blok oluşturma fırsatları daha büyük, küçük düğümlerin neredeyse hiç slotu yok, bu da merkezileşmeyi daha da artırıyor ve saldırıya uğradıklarında sistemin çökme riskini artırıyor.

Solana, TPS peşinde merkeziyetsizlik ve saldırılara karşı direncini feda etti, Nakamoto katsayısı yalnızca 20'dir, bu da Polkadot'un 172'sinin oldukça altındadır.

TON

TON, 104.715 TPS'ye ulaşabileceğini iddia ediyor, ancak bu rakam özel bir test ağında, 256 düğümle, ideal ağ ve donanım koşulları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çalı doğrulama düğümlerinin kimliği önceden ifşa edilebilir. TON beyaz kitabında da belirtildiği gibi, bu bant genişliğini optimize edebilse de kötü niyetli bir şekilde kullanılabilir. "Kumarbaz iflası" mekanizmasının eksikliği nedeniyle, saldırganlar bir parçanın tamamen kontrolünü ele geçirmek için bekleyebilir veya dürüst doğrulayıcıları DDoS saldırılarıyla engelleyerek durumu değiştirebilir.

Buna karşılık, Polkadot'un doğrulayıcıları rastgele dağıtılır ve gecikmeli olarak ifşa edilir, bu nedenle saldırganlar doğrulayıcıların kimliğini önceden bilemezler. Saldırı, tüm kontrollerin başarılı olmasına bahis oynamak zorundadır; eğer bir dürüst doğrulayıcı itirazda bulunursa, saldırı başarısız olur ve saldırganın stake kaybına yol açar.

Avalanche

Avalanche, ana ağ + alt ağ mimarisi kullanarak ölçekleniyor; ana ağ, X-Chain( transferleri, ~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önetmekten oluşuyor.

Her bir alt ağın teorik TPS’si ~5.000’e kadar ulaşabilir, bu 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 gereksinimler belirleyebilir, bu da merkeziyetsizlik ve güvenlikten feragat etmektir.

Polkadot'ta, tüm rollup'lar birleşik bir güvenlik sağlarken; Avalanche'ın alt ağları varsayılan bir güvenlik garantisine sahip değildir, bazıları tamamen merkeziyete bile dönüşebilir. Güvenliği artırmak istiyorsanız, yine de performansta bir taviz vermeniz gerekecek ve belirleyici bir güvenlik taahhüdü sağlamak zor olacaktır.

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 çözmemekte, sorunu yığın üzerindeki bir üst katmana aktarmaktadır.

İyimser Rollup

Şu anda çoğu Optimistic rollup merkeziyettir ( bazıları hatta sadece bir sequencer'a sahiptir ), bu da güvenlik eksikliği, birbirinden izole olma, yüksek gecikme ( dolandırıcılık kanıtı süresinin beklenmesi gerektiği, genellikle birkaç gün ) gibi sorunlara yol açmaktadır.

ZK Rollup

ZK rollup'un uygulanması, tek bir işlemin işleyebileceği 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ı, sistemi merkezileştirme eğilimindedir. TPS'yi garanti etmek için, ZK rollup genellikle her bir işlem grubunu sınırlamakta, yüksek talep olduğunda ağ tıkanıklığına, gaz fiyatlarının artmasına ve kullanıcı deneyiminin etkilenmesine neden olmaktadır.

Buna karşılık, Turing tam ZK rollup'ın maliyeti Polkadot'un temel kripto ekonomi 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 dayanı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 kamu blok zincirlerinin aksine, Polkadot merkeziyeti performans için feda etme, önceden belirlenmiş güven ile verimlilik sağlama yolunu seçmemiştir. Bunun yerine, esnek genişleme, izin gerektirmeyen protokol tasarımı, birleşik güvenlik katmanı ve esnek kaynak yönetim mekanizması aracılığıyla güvenlik, merkeziyetsizlik ve yüksek performans arasında çok boyutlu bir denge sağlamıştır.

Günümüzde daha büyük ölçekli uygulamaların hayata geçirilmesi adına Polkadot'un savunduğu "sıfır güven genişletilebilirlik" belki de Web3'ün uzun vadeli gelişimini destekleyebilecek gerçek çözüm.