Blok Zinciri Genişletilebilirliğinin Dengesi: Polkadot ve Web3 Seçimi
Günümüzde Blok Zinciri'nin sürekli olarak verimlilik artışı peşinde koştuğu bir dönemde, bir anahtar sorun giderek gün yüzüne çıkıyor: Performansı artırırken güvenlik ve sistem esnekliğinden ödün vermeden nasıl genişletme yapabiliriz?
Bu sadece teknik düzeyde bir meydan okuma değil, aynı zamanda mimari tasarımın derin bir seçimidir. Web3 ekosistemi için, sadece daha hızlı sistemler peşinde koşmak ve güven ile güvenliği göz ardı etmek, gerçekten sürdürülebilir yenilikleri desteklemek zordur.
Web3 ölçeklenebilirliğinin önemli bir itici gücü olarak Polkadot, yüksek throughput ve düşük gecikme peşinde koşarken, bazı fedakarlıklar yapmış olabilir mi? Rollup modeli, merkeziyetsizlik, güvenlik veya ağlar arası etkileşim konusunda bir taviz mi vermiştir?
Bu makale, bu konular etrafında bir tartışma yürütecek, Polkadot'un ölçeklenebilirlik tasarımındaki dengeyi derinlemesine analiz edecek ve diğer ana akım kamu blok zincirlerinin çözümleri ile karşılaştırarak performans, güvenlik ve merkeziyetsizlik arasında yaptıkları farklı seçimleri inceleyecektir.
Polkadot'un mimarisi doğrulayıcı ağı ve relay chain'e dayanıyor, bu bazı açılardan merkezileşme riski getirebilir mi? Tek bir hata noktası veya kontrol oluşması mümkün mü, bu da merkeziyetsiz özelliklerini etkileyebilir mi?
Rollup'ın çalışması, bağlantılı ara zincirin sıralayıcısına bağlıdır ve iletişim, collator protokol mekanizmasını kullanır. Bu protokol tamamen izinsiz ve güvensizdir, ağ bağlantısına sahip olan herkes bunu kullanabilir, birkaç ara zincir düğümüne bağlanabilir ve rollup durum dönüşüm taleplerini gönderebilir. Bu talepler, ara zincirin bir core'u tarafından doğrulanır, yalnızca bir ön koşulu yerine getirmesi gerekir: geçerli bir durum dönüşümü olmalıdır, aksi takdirde bu rollup'ın durumu ilerlemeyecektir.
Dikey genişleme dengesi
Rollup, Polkadot'un çok çekirdekli mimarisinden yararlanarak dikey ölçeklenmeyi gerçekleştirebilir. Bu yeni yetenek, "esnek ölçeklenebilirlik" işlevi ile tanıtılmıştır. Tasarım sürecinde, rollup blok doğrulamasının belirli bir çekirdek üzerinde sabitlenmemesi nedeniyle, bu durumun esnekliğini etkileyebileceği keşfedilmiştir.
Orta zincire blok gönderme protokolü izin gerektirmeyen ve güvene dayanmayan bir yapı olduğundan, herkes, rollup'a tahsis edilen herhangi bir core'a blok göndererek doğrulama yapabilir. Saldırganlar, daha önce doğrulanmış yasal blokları farklı core'lara tekrar tekrar göndererek bu durumu kötüye kullanabilir, kaynakları kötü niyetli bir şekilde tüketebilir ve böylece rollup'ın genel verimliliğini ve verimini azaltabilir.
Polkadot'un hedefi, sistemin temel özelliklerini etkilemeden, rollup'ın 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 sıralayıcıyı kötü niyetli davranış göstermeyecek şekilde güvenmektir, böylece rollup'ın etkinliğini sağlamak.
Ancak, Polkadot'un tasarım felsefesinde, sequencer için herhangi bir güven varsayımında bulunamayız, çünkü sistemin "güven gerektirmeyen" ve "izin gerektirmeyen" özelliklerini korumamız gerekiyor. Herkes, collator protokolünü kullanarak rollup durum dönüşüm talepleri gönderebilmelidir.
Polkadot: Uzlaşmaz Çözüm
Polkadot'un nihai seçtiği çözüm, sorunu tamamen rollup'ın durum dönüşüm fonksiyonuna (Runtime) devretmektir. Runtime, tüm konsensüs bilgilerini sağlayan tek güvenilir kaynaktır, bu nedenle çıktıda hangi Polkadot core üzerinde doğrulamanın yapılacağını açıkça belirtmek zorundadır.
Bu tasarım, esneklik ve güvenliğin çift korumasını sağlamaktadır. Polkadot, kullanılabilirlik süreçlerinde 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 Blok'un Polkadot veri kullanılabilirlik katmanına yazılmadan önce, yaklaşık 5 doğrulayıcıdan oluşan bir grup önce yasalitesini doğrulayacaktır. Onlar sıralayıcı tarafından sunulan aday makbuzları ve geçerlilik kanıtlarını alır, bunlar rollup Blok'unu ve ilgili depolama kanıtını içerir. Bu bilgiler, paralel zincir doğrulama fonksiyonu tarafından işlenecek ve ara zincirdeki doğrulayıcılar tarafından yeniden yürütülecektir.
Doğrulama sonuçlarında, blokun hangi core üzerinde doğrulanacağını belirlemek için bir core seçici vardır. Doğrulayıcı, bu indeksin kendi 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üvene ve izne ihtiyaç duymayan özelliklerini korumasını sağlar, sıralayıcı gibi kötü niyetli aktörlerin doğrulama konumunu manipüle etmesini engeller ve rollup çoklu çekirdek kullansa bile esnekliğin korunmasını garanti eder.
Güvenlik
Ölçeklenebilirlik arayışında, Polkadot güvenlikten ödün vermemiştir. Rollup'ın güvenliği, ana zincir tarafından sağlanmakta olup, sadece bir dürüst sıralayıcı hayatta kalmayı sürdürmek için yeterlidir.
ELVES protokolü sayesinde, Polkadot güvenliğini tüm rollup'lara tam olarak genişletir, tüm çekirdek üzerindeki hesaplamaları doğrular ve çekirdek sayısına ilişkin herhangi bir sınırlama veya varsayımda bulunmaz.
Bu nedenle, Polkadot'un rollup'ları gerçek bir ölçeklenebilirlik sağlayabilirken güvenlikten ödün vermemektedir.
Genel Kullanım
Esnek genişleme, rollup'un programlanabilirliğini sınırlamaz. Polkadot'un rollup modeli, tek bir yürütmenin 2 saniye içinde tamamlanması koşuluyla, WebAssembly ortamında Turing tam hesaplamaların gerçekleştirilmesini destekler. Esnek genişleme sayesinde, her 6 saniye döngüsünde gerçekleştirilebilecek toplam hesaplama miktarı artırılır, ancak hesaplama türleri etkilenmez.
Karmaşıklık
Daha yüksek bir işlem hacmi ve daha düşük 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 getirmelidir.
Belirli bir karmaşıklık, rollup'ın kaynak yönetim stratejilerine bağlıdır ve bu stratejiler zincir üstü veya zincir dışı 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 birlikte çalışabilirliği desteklerken, esnek ölçeklenebilirlik mesaj iletiminin verimliliğini etkilemez.
Rollup'lar arası mesaj iletimi, alt katman taşıma katmanı tarafından gerçekleştirilir. Her rollup'ın iletişim blok alanı sabittir ve atanan ç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ışı mesajlaşmayı destekleyecektir. Bu yükseltme, rollup'lar arası iletişim yeteneklerini esnek bir şekilde artıracak ve sistemin dikey ölçeklenebilirliğini daha da güçlendirecektir.
Diğer Protokollerin Değerlendirilmesi
Herkesin bildiği gibi, performans artışı genellikle merkeziyetsizlik ve güvenlikten fedakarlık yapılarak elde edilir. Ancak Nakamoto katsayısına göre, bazı Polkadot rakiplerinin merkeziyetsizlik dereceleri düşük olsa bile, performansları tatmin edici değildir.
Solana
Solana, Polkadot veya Ethereum'un parçalama mimarisini kullanmaz, bunun yerine tek katmanlı yüksek işlem hacmi mimarisi ile ölçeklenebilirlik sağlar, geçmiş kanıtı (PoH), CPU paralel işleme ve lider tabanlı konsensüs mekanizmasına dayanır, teorik TPS 65.000'e kadar ulaşabilir.
Ana bir tasarım, önceden kamuya açık ve doğrulanabilir lider programlama 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ımı yapılır;
Daha fazla stake yapıldıkça, dağıtım o kadar artar. Örneğin, %1'lik bir doğrulayıcı stake edenler yaklaşık %1'lik blok fırsatı elde eder;
Tüm blok üreticileri önceden ilan edildi, bu da ağın yönlendirilmiş DDoS saldırılarına ve sık kesintilere maruz kalma riskini artırdı.
PoH ve paralel işlemcilerin donanım gereksinimleri oldukça yüksektir, bu da doğrulayıcı düğümlerin merkezileşmesine yol açar. Daha fazla stake edilen düğümlerin blok oluşturma şansı daha yüksektir, 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ı dayanıklılığından ödün vermiştir, Nakamoto katsayısı yalnızca 20'dir ve bu da Polkadot'un 172'sinin oldukça altındadır.
TON
TON, TPS'nin 104.715'e kadar ulaşabileceğini iddia ediyor, ancak bu rakam özel test ağı, 256 düğüm, ideal ağ ve donanım koşulları altında gerçekleştirilmiştir. Oysa Polkadot, merkeziyetsiz kamusal ağda 128K TPS'ye ulaşmıştır.
TON'un konsensüs mekanizmasında güvenlik açığı bulunmaktadır: parçalı doğrulayıcı düğümlerin kimlikleri önceden açığa çıkacaktır. TON beyaz kitabı da açıkça belirtiyor ki, bu bant genişliğini optimize edebilse de kötü niyetli olarak kullanılabilir. "Kumarbaz iflası" mekanizmasının eksikliği nedeniyle, saldırganlar bir parçayı tamamen kontrol altına almak için bekleyebilir veya DDoS saldırıları ile 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 gecikmeli olarak açıklanır; saldırganlar doğrulayıcı kimliğini önceden bilemezler. Saldırı, tüm kontrolü baştan sona bahis yapmayı gerektirir. Eğer bir dürüst doğrulayıcı itirazda bulunursa, saldırı başarısız olur ve saldırganın stake kaybıyla sonuçlanır.
Avalanche
Avalanche, ana ağ + alt ağ mimarisi ile genişleme sağlamaktadı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şmaktadır.
Her bir alt ağın teorik TPS'si ~5,000'e ulaşabilir, Polkadot'un yaklaşımına benzer: Bireysel shard'ın yükünü azaltarak ölçeklenebilirlik sağlamak. Ancak Avalanche, doğrulayıcıların alt ağa katılma konusunda özgürce seçim yapmasına izin verir ve alt ağlar coğrafi, KYC gibi ek gereksinimler belirleyebilir, bu da merkeziyetsizlik ve güvenlikten ödün verir.
Polkadot'ta, tüm rollup'lar ortak bir güvenlik garantisine sahiptir; oysa Avalanche'ın alt ağlarının varsayılan bir güvenlik garantisi yoktur, bazıları tamamen merkezi olabilir. Güvenliği artırmak isterseniz, performansta bir uzlaşma yapmanız gerekecek ve belirli bir güvenlik taahhüdü sağlamak zor olacaktır.
Ethereum
Ethereum'in ölçeklenme stratejisi, temel katmanda doğrudan sorunları çözmek yerine rollup katmanının ölçeklenebilirliğine bahis yapmaktır. Bu yaklaşım esasen sorunu çözmemekte, sorunu yığın üzerindeki bir üst katmana aktarmaktadır.
İyimser Rollup
Günümüzde çoğu Optimistik rollup merkeziyettir (bazıları yalnızca bir sıralayıcıya sahiptir) ve güvenlik yetersizliği, birbirinden izole olma, yüksek gecikme (genellikle birkaç gün süren dolandırıcılık kanıtı süresini bekleme) gibi sorunlar bulunmaktadır.
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ı üretme hesaplama gereksinimleri son derece yüksektir ve "kazanan her şeyi alır" mekanizması sistemin merkezileşmesine neden olabilir. TPS'yi garanti etmek için, ZK rollup genellikle her seferdeki işlem miktarını sınırlar, bu da yüksek talep anlarında 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'un maliyeti yaklaşık olarak Polkadot'un temel kripto ekonomik 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ğlı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 kamu blok zincirlerine kıyasla, Polkadot merkeziyeti performansla, önceden belirlenmiş güveni verimlilikle değiştirme yoluna girmemiş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 savunduğu "sıfır güven genişletilebilirliği" belki de Web3'ün uzun vadeli gelişimini destekleyebilecek gerçek çözüm.
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.
16 Likes
Reward
16
6
Repost
Share
Comment
0/400
Fren_Not_Food
· 07-23 13:22
Proje iyi görünüyor, ancak gerçek performansa bakalım.
View OriginalReply0
BlockchainDecoder
· 07-23 11:10
Son zamanlarda Cho araştırma grubunun verilerine atıfta bulunarak, tek zincir tps genellikle 3k'nın altında kalmaktadır, denge sorunlarının aşılması acil bir ihtiyaçtır.
Polkadot sıfır ödün genişletilebilirlik: Web3 ekosisteminin yeni seçeneği
Blok Zinciri Genişletilebilirliğinin Dengesi: Polkadot ve Web3 Seçimi
Günümüzde Blok Zinciri'nin sürekli olarak verimlilik artışı peşinde koştuğu bir dönemde, bir anahtar sorun giderek gün yüzüne çıkıyor: Performansı artırırken güvenlik ve sistem esnekliğinden ödün vermeden nasıl genişletme yapabiliriz?
Bu sadece teknik düzeyde bir meydan okuma değil, aynı zamanda mimari tasarımın derin bir seçimidir. Web3 ekosistemi için, sadece daha hızlı sistemler peşinde koşmak ve güven ile güvenliği göz ardı etmek, gerçekten sürdürülebilir yenilikleri desteklemek zordur.
Web3 ölçeklenebilirliğinin önemli bir itici gücü olarak Polkadot, yüksek throughput ve düşük gecikme peşinde koşarken, bazı fedakarlıklar yapmış olabilir mi? Rollup modeli, merkeziyetsizlik, güvenlik veya ağlar arası etkileşim konusunda bir taviz mi vermiştir?
Bu makale, bu konular etrafında bir tartışma yürütecek, Polkadot'un ölçeklenebilirlik tasarımındaki dengeyi derinlemesine analiz edecek ve diğer ana akım kamu blok zincirlerinin çözümleri ile karşılaştırarak performans, güvenlik ve merkeziyetsizlik arasında yaptıkları farklı seçimleri inceleyecektir.
Polkadot Genişletme Tasarımının Karşılaştığı Zorluklar
Esneklik ve merkeziyetsizlik dengesi
Polkadot'un mimarisi doğrulayıcı ağı ve relay chain'e dayanıyor, bu bazı açılardan merkezileşme riski getirebilir mi? Tek bir hata noktası veya kontrol oluşması mümkün mü, bu da merkeziyetsiz özelliklerini etkileyebilir mi?
Rollup'ın çalışması, bağlantılı ara zincirin sıralayıcısına bağlıdır ve iletişim, collator protokol mekanizmasını kullanır. Bu protokol tamamen izinsiz ve güvensizdir, ağ bağlantısına sahip olan herkes bunu kullanabilir, birkaç ara zincir düğümüne bağlanabilir ve rollup durum dönüşüm taleplerini gönderebilir. Bu talepler, ara zincirin bir core'u tarafından doğrulanır, yalnızca bir ön koşulu yerine getirmesi gerekir: geçerli bir durum dönüşümü olmalıdır, aksi takdirde bu rollup'ın durumu ilerlemeyecektir.
Dikey genişleme dengesi
Rollup, Polkadot'un çok çekirdekli mimarisinden yararlanarak dikey ölçeklenmeyi gerçekleştirebilir. Bu yeni yetenek, "esnek ölçeklenebilirlik" işlevi ile tanıtılmıştır. Tasarım sürecinde, rollup blok doğrulamasının belirli bir çekirdek üzerinde sabitlenmemesi nedeniyle, bu durumun esnekliğini etkileyebileceği keşfedilmiştir.
Orta zincire blok gönderme protokolü izin gerektirmeyen ve güvene dayanmayan bir yapı olduğundan, herkes, rollup'a tahsis edilen herhangi bir core'a blok göndererek doğrulama yapabilir. Saldırganlar, daha önce doğrulanmış yasal blokları farklı core'lara tekrar tekrar göndererek bu durumu kötüye kullanabilir, kaynakları kötü niyetli bir şekilde tüketebilir ve böylece rollup'ın genel verimliliğini ve verimini azaltabilir.
Polkadot'un hedefi, sistemin temel özelliklerini etkilemeden, rollup'ın 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 sıralayıcıyı kötü niyetli davranış göstermeyecek şekilde güvenmektir, böylece rollup'ın etkinliğini sağlamak.
Ancak, Polkadot'un tasarım felsefesinde, sequencer için herhangi bir güven varsayımında bulunamayız, çünkü sistemin "güven gerektirmeyen" ve "izin gerektirmeyen" özelliklerini korumamız gerekiyor. Herkes, collator protokolünü kullanarak rollup durum dönüşüm talepleri gönderebilmelidir.
Polkadot: Uzlaşmaz Çözüm
Polkadot'un nihai seçtiği çözüm, sorunu tamamen rollup'ın durum dönüşüm fonksiyonuna (Runtime) devretmektir. Runtime, tüm konsensüs bilgilerini sağlayan tek güvenilir kaynaktır, bu nedenle çıktıda hangi Polkadot core üzerinde doğrulamanın yapılacağını açıkça belirtmek zorundadır.
Bu tasarım, esneklik ve güvenliğin çift korumasını sağlamaktadır. Polkadot, kullanılabilirlik süreçlerinde 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 Blok'un Polkadot veri kullanılabilirlik katmanına yazılmadan önce, yaklaşık 5 doğrulayıcıdan oluşan bir grup önce yasalitesini doğrulayacaktır. Onlar sıralayıcı tarafından sunulan aday makbuzları ve geçerlilik kanıtlarını alır, bunlar rollup Blok'unu ve ilgili depolama kanıtını içerir. Bu bilgiler, paralel zincir doğrulama fonksiyonu tarafından işlenecek ve ara zincirdeki doğrulayıcılar tarafından yeniden yürütülecektir.
Doğrulama sonuçlarında, blokun hangi core üzerinde doğrulanacağını belirlemek için bir core seçici vardır. Doğrulayıcı, bu indeksin kendi 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üvene ve izne ihtiyaç duymayan özelliklerini korumasını sağlar, sıralayıcı gibi kötü niyetli aktörlerin doğrulama konumunu manipüle etmesini engeller ve rollup çoklu çekirdek kullansa bile esnekliğin korunmasını garanti eder.
Güvenlik
Ölçeklenebilirlik arayışında, Polkadot güvenlikten ödün vermemiştir. Rollup'ın güvenliği, ana zincir tarafından sağlanmakta olup, sadece bir dürüst sıralayıcı hayatta kalmayı sürdürmek için yeterlidir.
ELVES protokolü sayesinde, Polkadot güvenliğini tüm rollup'lara tam olarak genişletir, tüm çekirdek üzerindeki hesaplamaları doğrular ve çekirdek sayısına ilişkin herhangi bir sınırlama veya varsayımda bulunmaz.
Bu nedenle, Polkadot'un rollup'ları gerçek bir ölçeklenebilirlik sağlayabilirken güvenlikten ödün vermemektedir.
Genel Kullanım
Esnek genişleme, rollup'un programlanabilirliğini sınırlamaz. Polkadot'un rollup modeli, tek bir yürütmenin 2 saniye içinde tamamlanması koşuluyla, WebAssembly ortamında Turing tam hesaplamaların gerçekleştirilmesini destekler. Esnek genişleme sayesinde, her 6 saniye döngüsünde gerçekleştirilebilecek toplam hesaplama miktarı artırılır, ancak hesaplama türleri etkilenmez.
Karmaşıklık
Daha yüksek bir işlem hacmi ve daha düşük 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 getirmelidir.
Belirli bir karmaşıklık, rollup'ın kaynak yönetim stratejilerine bağlıdır ve bu stratejiler zincir üstü veya zincir dışı değişkenlere dayanabilir. Örneğin:
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 birlikte çalışabilirliği desteklerken, esnek ölçeklenebilirlik mesaj iletiminin verimliliğini etkilemez.
Rollup'lar arası mesaj iletimi, alt katman taşıma katmanı tarafından gerçekleştirilir. Her rollup'ın iletişim blok alanı sabittir ve atanan ç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ışı mesajlaşmayı destekleyecektir. Bu yükseltme, rollup'lar arası iletişim yeteneklerini esnek bir şekilde artıracak ve sistemin dikey ölçeklenebilirliğini daha da güçlendirecektir.
Diğer Protokollerin Değerlendirilmesi
Herkesin bildiği gibi, performans artışı genellikle merkeziyetsizlik ve güvenlikten fedakarlık yapılarak elde edilir. Ancak Nakamoto katsayısına göre, bazı Polkadot rakiplerinin merkeziyetsizlik dereceleri düşük olsa bile, performansları tatmin edici değildir.
Solana
Solana, Polkadot veya Ethereum'un parçalama mimarisini kullanmaz, bunun yerine tek katmanlı yüksek işlem hacmi mimarisi ile ölçeklenebilirlik sağlar, geçmiş kanıtı (PoH), CPU paralel işleme ve lider tabanlı konsensüs mekanizmasına dayanır, teorik TPS 65.000'e kadar ulaşabilir.
Ana bir tasarım, önceden kamuya açık ve doğrulanabilir lider programlama mekanizmasıdır:
PoH ve paralel işlemcilerin donanım gereksinimleri oldukça yüksektir, bu da doğrulayıcı düğümlerin merkezileşmesine yol açar. Daha fazla stake edilen düğümlerin blok oluşturma şansı daha yüksektir, 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ı dayanıklılığından ödün vermiştir, Nakamoto katsayısı yalnızca 20'dir ve bu da Polkadot'un 172'sinin oldukça altındadır.
TON
TON, TPS'nin 104.715'e kadar ulaşabileceğini iddia ediyor, ancak bu rakam özel test ağı, 256 düğüm, ideal ağ ve donanım koşulları altında gerçekleştirilmiştir. Oysa Polkadot, merkeziyetsiz kamusal ağda 128K TPS'ye ulaşmıştır.
TON'un konsensüs mekanizmasında güvenlik açığı bulunmaktadır: parçalı doğrulayıcı düğümlerin kimlikleri önceden açığa çıkacaktır. TON beyaz kitabı da açıkça belirtiyor ki, bu bant genişliğini optimize edebilse de kötü niyetli olarak kullanılabilir. "Kumarbaz iflası" mekanizmasının eksikliği nedeniyle, saldırganlar bir parçayı tamamen kontrol altına almak için bekleyebilir veya DDoS saldırıları ile 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 gecikmeli olarak açıklanır; saldırganlar doğrulayıcı kimliğini önceden bilemezler. Saldırı, tüm kontrolü baştan sona bahis yapmayı gerektirir. Eğer bir dürüst doğrulayıcı itirazda bulunursa, saldırı başarısız olur ve saldırganın stake kaybıyla sonuçlanır.
Avalanche
Avalanche, ana ağ + alt ağ mimarisi ile genişleme sağlamaktadı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şmaktadır.
Her bir alt ağın teorik TPS'si ~5,000'e ulaşabilir, Polkadot'un yaklaşımına benzer: Bireysel shard'ın yükünü azaltarak ölçeklenebilirlik sağlamak. Ancak Avalanche, doğrulayıcıların alt ağa katılma konusunda özgürce seçim yapmasına izin verir ve alt ağlar coğrafi, KYC gibi ek gereksinimler belirleyebilir, bu da merkeziyetsizlik ve güvenlikten ödün verir.
Polkadot'ta, tüm rollup'lar ortak bir güvenlik garantisine sahiptir; oysa Avalanche'ın alt ağlarının varsayılan bir güvenlik garantisi yoktur, bazıları tamamen merkezi olabilir. Güvenliği artırmak isterseniz, performansta bir uzlaşma yapmanız gerekecek ve belirli bir güvenlik taahhüdü sağlamak zor olacaktır.
Ethereum
Ethereum'in ölçeklenme stratejisi, temel katmanda doğrudan sorunları çözmek yerine rollup katmanının ölçeklenebilirliğine bahis yapmaktır. Bu yaklaşım esasen sorunu çözmemekte, sorunu yığın üzerindeki bir üst katmana aktarmaktadır.
İyimser Rollup
Günümüzde çoğu Optimistik rollup merkeziyettir (bazıları yalnızca bir sıralayıcıya sahiptir) ve güvenlik yetersizliği, birbirinden izole olma, yüksek gecikme (genellikle birkaç gün süren dolandırıcılık kanıtı süresini bekleme) gibi sorunlar bulunmaktadır.
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ı üretme hesaplama gereksinimleri son derece yüksektir ve "kazanan her şeyi alır" mekanizması sistemin merkezileşmesine neden olabilir. TPS'yi garanti etmek için, ZK rollup genellikle her seferdeki işlem miktarını sınırlar, bu da yüksek talep anlarında 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'un maliyeti yaklaşık olarak Polkadot'un temel kripto ekonomik 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ğlı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 kamu blok zincirlerine kıyasla, Polkadot merkeziyeti performansla, önceden belirlenmiş güveni verimlilikle değiştirme yoluna girmemiş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 savunduğu "sıfır güven genişletilebilirliği" belki de Web3'ün uzun vadeli gelişimini destekleyebilecek gerçek çözüm.