Blok Zinciri teknolojisinin sürekli daha yüksek verimlilik peşinde koştuğu bugün, bir anahtar sorun giderek belirginleşiyor: Performansı artırırken güvenlik ve sistem esnekliğinden nasıl ödün vermeden ilerleyebiliriz? Bu yalnızca teknik bir meydan okuma değil, aynı zamanda mimari tasarımın derin bir seçimidir. Web3 ekosistemi için, daha hızlı bir sistem eğer güven ve güvenlikten ödün verilerek inşa ediliyorsa, genellikle gerçekten sürdürülebilir yenilikleri desteklemek zor olur.
Bu makale, Polkadot'un ölçeklenebilirlik tasarımındaki trade-off'larını 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ındaki farklı yol seçimlerini analiz edecektir.
Polkadot'un mimarisi, doğrulayıcı ağlarına ve Relay Chain'e (Orta Zincir) dayanır. Rollup'ın çalışması, orta zincire bağlanan sıralayıcı (sequencer) üzerine kuruludur ve iletişimi collator protokol mekanizması kullanır. Bu protokol tamamen izin gerektirmeyen, güven gerektirmeyen bir sistemdir; ağ bağlantısı olan herkes bunu kullanabilir, az sayıda orta zincir düğümüne bağlanabilir ve rollup'ın durum değiştirme taleplerini iletebilir. Bu talepler, orta zincirin bir core'u tarafından doğrulanır; tek gereklilik şudur: geçerli bir durum değişikliği olmalıdır, aksi takdirde bu rollup'ın durumu ilerletilmeyecektir.
Dikey genişletme ile ilgili denge
Rollup, Polkadot'un çok çekirdekli mimarisinden yararlanarak dikey ölçeklenmeyi gerçekleştirebilir. Bu yeni yetenek, "esnek ölçekleme" (Elastic Scaling) işlevi ile tanıtıldı. Tasarım sürecinde, rollup blok doğrulamasının belirli bir çekirdekte sabitlenmediği tespit edildi, bu da esnekliğini etkileyebilir.
Orta zincire blok gönderme protokolü izinsiz ve güvensiz olduğundan, herkes rollup'a atanmış herhangi bir core'a blok göndererek doğrulama yapabilir. Saldırganlar bunu kullanarak daha önce doğrulanmış geçerli blokları farklı core'lara tekrar tekrar gönderebilir, kötü niyetli olarak kaynak tüketebilir ve böylece rollup'un genel verimliliğini ve verimliliğini azaltabilir.
Polkadot'un hedefi, sistemin temel özelliklerini etkilemeden, rollup'ların esnekliğini ve ara zincir kaynaklarının etkin kullanımını sürdürmektir.
Sequencer'ın güven sorunları
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ğını varsaymak, böylece rollup'ın etkinliğini sağlamak. Ancak, Polkadot'un tasarım felsefesinde, sıralayıcıya karşı herhangi bir güven varsayımında bulunamayız çünkü sistemin "güven gerektirmeyen" ve "izin gerektirmeyen" özelliklerini korumalıyız. Herkes, collator protokolünü kullanarak rollup'ın durum geçiş taleplerini gönderebilmelidir.
Polkadot: Uzlaşmaz Çözüm
Polkadot'un nihai seçimi şu şekildedir: 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ği üzerinde 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'un durum geçişlerini yeniden yürütür ve ELVES şifreleme ekonomik protokolü aracılığıyla core dağıtımının doğruluğunu garanti eder.
Herhangi bir rollup blokunun Polkadot veri kullanılabilirlik katmanına (DA) yazılmadan önce, yaklaşık 5 doğrulayıcıdan oluşan bir grup öncelikle geçerliliğini doğrular. Bu grup, sıralayıcıdan gelen aday makbuz (candidate receipt) ve geçerlilik kanıtı (PoV) alır; bu bilgiler rollup blokunu ve ilgili depolama kanıtını içerir. Bu bilgiler, paralel zincir doğrulama fonksiyonu tarafından işlenecek ve ara zincir üzerindeki doğrulayıcılar tarafından yeniden yürütülecektir.
Doğrulama sonucunda, hangi core'da blok doğrulanacağını belirlemek için bir core seçici bulunur. Doğrulayıcı, bu indeksin kendi sorumlu olduğu core ile tutarlı olup olmadığını kontrol eder; eğer tutarlı değilse, bu blok atılacaktır.
Bu mekanizma, sistemin her zaman güvene ihtiyaç duymayan ve izin gerektirmeyen özelliklerini korumasını sağlar, sıralayıcı gibi kötü niyetli aktörlerin doğrulama yerini manipüle etmesini engeller ve rollup birden fazla core kullansa bile esnekliği korur.
Güvenlik
Ölçeklenebilirlik arayışında, Polkadot güvenlikten ödün vermemiştir. Rollup'ın güvenliği, ana zincir tarafından sağlanır ve sadece 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ına herhangi bir kısıtlama veya varsayımda bulunmadan.
Bu nedenle, Polkadot'un rollup'ları güvenlikten ödün vermeden gerçek bir ölçeklenebilirlik sağlayabilir.
Genel Kullanım
Esnek genişleme, rollup'ın programlanabilirliğini sınırlamaz. Polkadot'un rollup modeli, WebAssembly ortamında Turing tam hesaplamaları gerçekleştirmeyi destekler, yeter ki tek bir yürütme 2 saniye içinde tamamlanmış olsun. 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ındaki 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 gerekliliklerini de yerine getirmelidir.
Rollup'un kaynak yönetim stratejileri bu karmaşıklığın belirleyici faktörüdür ve bu stratejiler zincir içi veya zincir dışı değişkenlere dayanabilir. Örneğin:
Basit strateji: Her zaman sabit bir core sayısı kullanın veya off-chain manuel olarak ayarlayın;
Hafif Strateji: Düğüm mempool'unda belirli işlem yüklerini izleme;
Otomatik strateji: Geçmiş veriler ve XCM arayüzü aracılığıyla coretime hizmetini önceden çağırarak kaynakları yapılandırmak.
Otomatik yöntemler daha verimli olsa da, gerçekleştirme ve test maliyetleri de önemli ölçüde artmaktadır.
İşlem Yapabilirlik
Polkadot, farklı rolluplar arasındaki etkileşimi desteklerken, esnek ölçeklenebilirlik mesaj iletiminin verimliliğini etkilemez.
Rollup'lar arası mesajlaşma, 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 off-chain messaging'i destekleyecek, bu da kontrol katmanı olarak bir relay chain'in kullanılacağı anlamına geliyor, veri katmanı yerine. Bu yükseltme, rolluplar arası iletişim yeteneklerini esnek bir şekilde artıracak ve sistemin dikey ölçeklenebilirliğini daha da güçlendirecek.
Diğer Protokollerin Tercihleri
Herkesin bildiği gibi, performans artışı genellikle merkeziyetsizlik ve güvenlikten taviz verme pahasına gelir. Ancak Nakamoto katsayısına göre, bazı Polkadot rakiplerinin merkeziyetsizlik düzeyi düşük olsa bile, performansları pek iç açıcı değildir.
Solana
Solana, Polkadot veya Ethereum'un parçalı mimarisini kullanmaz, bunun yerine tek katmanlı yüksek verimlilik mimarisi ile ölçeklenebilirlik sağlar, Tarihsel Kanıt (PoH), CPU paralel işlem ve lider tabanlı konsensüs mekanizmasına dayanır, teorik TPS 65.000'e kadar ulaşabilir.
Bir ana tasarım, önceden halka açık ve doğrulanabilir lider atama mekanizmasıdır:
Her epoch (yaklaşık iki gün veya 432.000 slot) başlangıcında, stake miktarına göre slot dağıtımı yapılır;
Daha fazla stake yapıldığında, daha fazla dağıtım olur. Örneğin, %1 stake yapan bir doğrulayıcı yaklaşık %1 blok oluşturma şansına sahip olacaktır;
Tüm blok üreticileri önceden açıklanır, bu durum ağın hedefli DDoS saldırılarına maruz kalma ve sık sık kesintiye uğrama riskini artırır.
PoH ve paralel işleme, donanım gereksinimlerini son derece yüksek hale getirerek doğrulama düğümlerinin merkezileşmesine yol açar. Daha fazla stake yapan 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ıya uğradığında sistemin çökme riskini artırır.
Solana, TPS peşinde merkeziyetsizliği ve saldırı direncini feda etti, Nakamoto katsayısı sadece 20, bu da Polkadot'un 172'sinin çok altında.
TON
TON, 104.715 TPS ulaşabileceğini iddia ediyor, ancak bu sayı özel test ağında, 256 düğümle, ideal ağ ve donanım koşullarında elde edilmiştir. Polkadot ise merkeziyetsiz genel ağda 128K TPS'ye ulaşmıştır.
TON'un konsensüs mekanizmasında güvenlik açıkları bulunmaktadır: parça doğrulayıcı düğümlerinin kimliği önceden ifşa edilebilir. TON beyaz kitabı da açıkça belirtmektedir ki bu, bant genişliğini optimize edebilir, ancak kötü niyetli kullanılabilir. "Kumarbaz iflası" mekanizmasının eksikliği nedeniyle, saldırganlar bir parçanın tamamen kontrolünü ele geçirmeyi bekleyebilir veya DDoS saldırılarıyla dürüst doğrulayıcıları engelleyerek durumu değiştirebilir.
Buna karşılık, Polkadot'un doğrulayıcıları rastgele atanır ve geç açıklanır, saldırganlar doğrulayıcı kimliğini önceden bilemezler, saldırı tüm kontrolü elde etme üzerine bahis oynamak zorundadır, bir tane bile dürüst doğrulayıcı itirazda bulunduğunda, 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çekleniyor. Ana ağ, X-Chain (para transferi, ~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şmaktadır.
Her bir alt ağın teorik TPS'si ~5,000'e kadar çıkabilir, Polkadot'un yaklaşımına benzer: Tek bir shard'ın yükünü azaltarak ölçeklenebilirliği sağlamak. Ancak Avalanche, doğrulayıcıların alt ağlara katılmayı serbestçe seçmelerine izin verir ve alt ağlar coğrafi, KYC gibi ek gereksinimleri ayarlayabilir, bu da merkezsizleşme ve güvenlikten ödün verir.
Polkadot'ta, tüm rollup'lar merkezi bir güvenlik korumasını paylaşırken; Avalanche'ın alt ağlarının varsayılan bir güvenlik garantisi yoktur, bazıları ise tamamen merkezi hale gelebilir. Güvenliği artırmak istendiğinde, yine de performansta bir uzlaşma sağlanması gerekecek ve belirleyici bir güvenlik taahhüdü sunmak zor olacaktır.
Ethereum
Ethereum'in ö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, sadece sorunu yığın katmanının bir üst katmanına aktarmaktadır.
İyimser Rollup
Şu anda çoğu Optimistic rollup merkeziyettir (bazıları sadece bir sıralayıcıya sahiptir), bu da güvenlik eksikliği, birbirlerinden izole olma ve yüksek gecikme (dolandırıcılık kanıtı süresinin beklenmesi gerekir, genellikle birkaç gün) gibi sorunlar ortaya çıkarmaktadır.
ZK Rollup
ZK rollup'un uygulanması, tek bir işlem başına işlenebilecek veri miktarıyla sınırlıdır. Sıfır bilgi kanıtı oluşturmanın hesaplama gereksinimleri çok 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 grubundaki işlem miktarını sınırlamakta, yüksek talep dönemlerinde ağ tıkanıklığına ve gaz fiyatlarının artmasına neden olarak kullanıcı deneyimini etkilemektedir.
Buna karşılık, Turing tam ZK rollup 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 dayanır, bu da maliyetleri ve kullanıcı ücretlerini daha da artırır.
Sonuç
Ölçeklenebilirliğin sonu, bir uzlaşma olmamalıdır.
Diğer kamu zincirleri ile karşılaştırıldığında, Polkadot merkeziyete geçerek performans, önceden belirlenmiş güven ile verimlilik sağlama yolunu izlememiş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.
Günümüzde daha büyük ölçekli uygulamaların hayata geçirilmesini hedeflerken, Polkadot'un benimsediği "sıfır güven genişletilebilirliği" belki de Web3'ün uzun vadeli gelişimini destekleyen gerçek çözüm olabilir.
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.
11 Likes
Reward
11
6
Share
Comment
0/400
GateUser-a5fa8bd0
· 17h ago
dot'u iyi öğren! Eski meslek güvenilir değil.
View OriginalReply0
AirdropworkerZhang
· 08-01 00:33
Bu verimlilik çok yüksek, maliyet çok düşük. Patron, madenciliğe gidiyorum.
View OriginalReply0
MEVHunter
· 07-31 10:51
meh... dot'un relaychain'i hala yoğun mempool baskısı altında darboğaz yaşıyor aslında. Geçen hafta toksik akış zirveleri gördüm.
View OriginalReply0
Lonely_Validator
· 07-31 10:51
Açık zincir eski oyuncusu, Dot her zaman rağbet görüyor.
View OriginalReply0
DeFiCaffeinator
· 07-31 10:51
DOT henüz Aya doğru uçmadı mı? Niye bu kadar telaşlısın?
Polkadot esnek ölçeklenebilirlik: ödün vermeyen Web3 performansı ve güvenlik dengesi
Blok Zinciri'nin Ölçeklenebilirlik Dengesi: Polkadot Örneğinde
Blok Zinciri teknolojisinin sürekli daha yüksek verimlilik peşinde koştuğu bugün, bir anahtar sorun giderek belirginleşiyor: Performansı artırırken güvenlik ve sistem esnekliğinden nasıl ödün vermeden ilerleyebiliriz? Bu yalnızca teknik bir meydan okuma değil, aynı zamanda mimari tasarımın derin bir seçimidir. Web3 ekosistemi için, daha hızlı bir sistem eğer güven ve güvenlikten ödün verilerek inşa ediliyorsa, genellikle gerçekten sürdürülebilir yenilikleri desteklemek zor olur.
Bu makale, Polkadot'un ölçeklenebilirlik tasarımındaki trade-off'larını 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ındaki farklı yol seçimlerini analiz edecektir.
Polkadot genişletme tasarımının karşılaştığı zorluklar
Esneklik ve merkeziyetsizlik dengesi
Polkadot'un mimarisi, doğrulayıcı ağlarına ve Relay Chain'e (Orta Zincir) dayanır. Rollup'ın çalışması, orta zincire bağlanan sıralayıcı (sequencer) üzerine kuruludur ve iletişimi collator protokol mekanizması kullanır. Bu protokol tamamen izin gerektirmeyen, güven gerektirmeyen bir sistemdir; ağ bağlantısı olan herkes bunu kullanabilir, az sayıda orta zincir düğümüne bağlanabilir ve rollup'ın durum değiştirme taleplerini iletebilir. Bu talepler, orta zincirin bir core'u tarafından doğrulanır; tek gereklilik şudur: geçerli bir durum değişikliği olmalıdır, aksi takdirde bu rollup'ın durumu ilerletilmeyecektir.
Dikey genişletme ile ilgili denge
Rollup, Polkadot'un çok çekirdekli mimarisinden yararlanarak dikey ölçeklenmeyi gerçekleştirebilir. Bu yeni yetenek, "esnek ölçekleme" (Elastic Scaling) işlevi ile tanıtıldı. Tasarım sürecinde, rollup blok doğrulamasının belirli bir çekirdekte sabitlenmediği tespit edildi, bu da esnekliğini etkileyebilir.
Orta zincire blok gönderme protokolü izinsiz ve güvensiz olduğundan, herkes rollup'a atanmış herhangi bir core'a blok göndererek doğrulama yapabilir. Saldırganlar bunu kullanarak daha önce doğrulanmış geçerli blokları farklı core'lara tekrar tekrar gönderebilir, kötü niyetli olarak kaynak tüketebilir ve böylece rollup'un genel verimliliğini ve verimliliğini azaltabilir.
Polkadot'un hedefi, sistemin temel özelliklerini etkilemeden, rollup'ların esnekliğini ve ara zincir kaynaklarının etkin kullanımını sürdürmektir.
Sequencer'ın güven sorunları
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ğını varsaymak, böylece rollup'ın etkinliğini sağlamak. Ancak, Polkadot'un tasarım felsefesinde, sıralayıcıya karşı herhangi bir güven varsayımında bulunamayız çünkü sistemin "güven gerektirmeyen" ve "izin gerektirmeyen" özelliklerini korumalıyız. Herkes, collator protokolünü kullanarak rollup'ın durum geçiş taleplerini gönderebilmelidir.
Polkadot: Uzlaşmaz Çözüm
Polkadot'un nihai seçimi şu şekildedir: 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ği üzerinde 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'un durum geçişlerini yeniden yürütür ve ELVES şifreleme ekonomik protokolü aracılığıyla core dağıtımının doğruluğunu garanti eder.
Herhangi bir rollup blokunun Polkadot veri kullanılabilirlik katmanına (DA) yazılmadan önce, yaklaşık 5 doğrulayıcıdan oluşan bir grup öncelikle geçerliliğini doğrular. Bu grup, sıralayıcıdan gelen aday makbuz (candidate receipt) ve geçerlilik kanıtı (PoV) alır; bu bilgiler rollup blokunu ve ilgili depolama kanıtını içerir. Bu bilgiler, paralel zincir doğrulama fonksiyonu tarafından işlenecek ve ara zincir üzerindeki doğrulayıcılar tarafından yeniden yürütülecektir.
Doğrulama sonucunda, hangi core'da blok doğrulanacağını belirlemek için bir core seçici bulunur. Doğrulayıcı, bu indeksin kendi sorumlu olduğu core ile tutarlı olup olmadığını kontrol eder; eğer tutarlı değilse, bu blok atılacaktır.
Bu mekanizma, sistemin her zaman güvene ihtiyaç duymayan ve izin gerektirmeyen özelliklerini korumasını sağlar, sıralayıcı gibi kötü niyetli aktörlerin doğrulama yerini manipüle etmesini engeller ve rollup birden fazla core kullansa bile esnekliği korur.
Güvenlik
Ölçeklenebilirlik arayışında, Polkadot güvenlikten ödün vermemiştir. Rollup'ın güvenliği, ana zincir tarafından sağlanır ve sadece 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ına herhangi bir kısıtlama veya varsayımda bulunmadan.
Bu nedenle, Polkadot'un rollup'ları güvenlikten ödün vermeden gerçek bir ölçeklenebilirlik sağlayabilir.
Genel Kullanım
Esnek genişleme, rollup'ın programlanabilirliğini sınırlamaz. Polkadot'un rollup modeli, WebAssembly ortamında Turing tam hesaplamaları gerçekleştirmeyi destekler, yeter ki tek bir yürütme 2 saniye içinde tamamlanmış olsun. 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ındaki 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 gerekliliklerini de yerine getirmelidir.
Rollup'un kaynak yönetim stratejileri bu karmaşıklığın belirleyici faktörüdür ve bu stratejiler zincir içi veya zincir dışı değişkenlere dayanabilir. Örneğin:
Otomatik yöntemler daha verimli olsa da, gerçekleştirme ve test maliyetleri de önemli ölçüde artmaktadır.
İşlem Yapabilirlik
Polkadot, farklı rolluplar arasındaki etkileşimi desteklerken, esnek ölçeklenebilirlik mesaj iletiminin verimliliğini etkilemez.
Rollup'lar arası mesajlaşma, 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 off-chain messaging'i destekleyecek, bu da kontrol katmanı olarak bir relay chain'in kullanılacağı anlamına geliyor, veri katmanı yerine. Bu yükseltme, rolluplar arası iletişim yeteneklerini esnek bir şekilde artıracak ve sistemin dikey ölçeklenebilirliğini daha da güçlendirecek.
Diğer Protokollerin Tercihleri
Herkesin bildiği gibi, performans artışı genellikle merkeziyetsizlik ve güvenlikten taviz verme pahasına gelir. Ancak Nakamoto katsayısına göre, bazı Polkadot rakiplerinin merkeziyetsizlik düzeyi düşük olsa bile, performansları pek iç açıcı değildir.
Solana
Solana, Polkadot veya Ethereum'un parçalı mimarisini kullanmaz, bunun yerine tek katmanlı yüksek verimlilik mimarisi ile ölçeklenebilirlik sağlar, Tarihsel Kanıt (PoH), CPU paralel işlem ve lider tabanlı konsensüs mekanizmasına dayanır, teorik TPS 65.000'e kadar ulaşabilir.
Bir ana tasarım, önceden halka açık ve doğrulanabilir lider atama mekanizmasıdır:
PoH ve paralel işleme, donanım gereksinimlerini son derece yüksek hale getirerek doğrulama düğümlerinin merkezileşmesine yol açar. Daha fazla stake yapan 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ıya uğradığında sistemin çökme riskini artırır.
Solana, TPS peşinde merkeziyetsizliği ve saldırı direncini feda etti, Nakamoto katsayısı sadece 20, bu da Polkadot'un 172'sinin çok altında.
TON
TON, 104.715 TPS ulaşabileceğini iddia ediyor, ancak bu sayı özel test ağında, 256 düğümle, ideal ağ ve donanım koşullarında elde edilmiştir. Polkadot ise merkeziyetsiz genel ağda 128K TPS'ye ulaşmıştır.
TON'un konsensüs mekanizmasında güvenlik açıkları bulunmaktadır: parça doğrulayıcı düğümlerinin kimliği önceden ifşa edilebilir. TON beyaz kitabı da açıkça belirtmektedir ki bu, bant genişliğini optimize edebilir, ancak kötü niyetli kullanılabilir. "Kumarbaz iflası" mekanizmasının eksikliği nedeniyle, saldırganlar bir parçanın tamamen kontrolünü ele geçirmeyi bekleyebilir veya DDoS saldırılarıyla dürüst doğrulayıcıları engelleyerek durumu değiştirebilir.
Buna karşılık, Polkadot'un doğrulayıcıları rastgele atanır ve geç açıklanır, saldırganlar doğrulayıcı kimliğini önceden bilemezler, saldırı tüm kontrolü elde etme üzerine bahis oynamak zorundadır, bir tane bile dürüst doğrulayıcı itirazda bulunduğunda, 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çekleniyor. Ana ağ, X-Chain (para transferi, ~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şmaktadır.
Her bir alt ağın teorik TPS'si ~5,000'e kadar çıkabilir, Polkadot'un yaklaşımına benzer: Tek bir shard'ın yükünü azaltarak ölçeklenebilirliği sağlamak. Ancak Avalanche, doğrulayıcıların alt ağlara katılmayı serbestçe seçmelerine izin verir ve alt ağlar coğrafi, KYC gibi ek gereksinimleri ayarlayabilir, bu da merkezsizleşme ve güvenlikten ödün verir.
Polkadot'ta, tüm rollup'lar merkezi bir güvenlik korumasını paylaşırken; Avalanche'ın alt ağlarının varsayılan bir güvenlik garantisi yoktur, bazıları ise tamamen merkezi hale gelebilir. Güvenliği artırmak istendiğinde, yine de performansta bir uzlaşma sağlanması gerekecek ve belirleyici bir güvenlik taahhüdü sunmak zor olacaktır.
Ethereum
Ethereum'in ö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, sadece sorunu yığın katmanının bir üst katmanına aktarmaktadır.
İyimser Rollup
Şu anda çoğu Optimistic rollup merkeziyettir (bazıları sadece bir sıralayıcıya sahiptir), bu da güvenlik eksikliği, birbirlerinden izole olma ve yüksek gecikme (dolandırıcılık kanıtı süresinin beklenmesi gerekir, genellikle birkaç gün) gibi sorunlar ortaya çıkarmaktadır.
ZK Rollup
ZK rollup'un uygulanması, tek bir işlem başına işlenebilecek veri miktarıyla sınırlıdır. Sıfır bilgi kanıtı oluşturmanın hesaplama gereksinimleri çok 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 grubundaki işlem miktarını sınırlamakta, yüksek talep dönemlerinde ağ tıkanıklığına ve gaz fiyatlarının artmasına neden olarak kullanıcı deneyimini etkilemektedir.
Buna karşılık, Turing tam ZK rollup 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 dayanır, bu da maliyetleri ve kullanıcı ücretlerini daha da artırır.
Sonuç
Ölçeklenebilirliğin sonu, bir uzlaşma olmamalıdır.
Diğer kamu zincirleri ile karşılaştırıldığında, Polkadot merkeziyete geçerek performans, önceden belirlenmiş güven ile verimlilik sağlama yolunu izlememiş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.
Günümüzde daha büyük ölçekli uygulamaların hayata geçirilmesini hedeflerken, Polkadot'un benimsediği "sıfır güven genişletilebilirliği" belki de Web3'ün uzun vadeli gelişimini destekleyen gerçek çözüm olabilir.