Ölçeklenebilirlik ve Güvenlik Dengesi: Polkadot'un Web3 Mimari Tasarımı
Günümüzde blockchain teknolojisinin daha yüksek verimlilik peşinde koştuğu bir ortamda, bir anahtar sorun giderek daha belirgin hale geliyor: Performansı artırırken sistemin güvenliğinden ve esnekliğinden ödün vermeden nasıl yapılabilir? Bu yalnızca teknik bir zorluk değil, aynı zamanda mimari tasarımın derinlemesine değerlendirilmesini de içeriyor. Web3 ekosistemi için, eğer yüksek hızlı bir sistem güven ve güvenlikten ödün vererek inşa edilirse, genellikle gerçekten sürdürülebilir yenilikleri desteklemekte zorluk çeker.
Web3 ölçeklenebilirliğinin önemli bir destekleyicisi olarak Polkadot, yüksek throughput ve düşük gecikme hedeflerine ulaşırken bazı tavizler veriyor mu? Rollup modeli, merkeziyetsizlik, güvenlik veya ağlar arası birlikte çalışabilirlik açısından bir şeylerden feragat ediyor mu? Bu makale, bu sorular etrafında tartışmalar yürütecek, Polkadot'un ölçeklenebilirlik tasarımındaki seçimlerini ve dengelemelerini derinlemesine analiz edecek ve diğer ana akım kamu blok zincirlerinin çözümleri ile karşılaştırarak performans, güvenlik ve merkeziyetsizlik üçlüsü arasındaki farklı seçimleri inceleyecek.
Polkadot'un mimarisi, doğrulayıcı ağı ve ara zincire bağlıdır, bu bazı açılardan merkezileşme riski getirebilir mi? Tek bir arıza noktası veya kontrol oluşması, merkeziyetsiz özelliklerini etkileyebilir mi?
Rollup'ın çalışması, bağlantılı ara zincirin sıralayıcısına bağımlıdır ve iletişim collator protokol mekanizmasını kullanır. Bu protokol tamamen izin gerektirmeyen, güvene dayanmayan bir yapıya sahiptir; ağ bağlantısı olan herkes bunu kullanabilir, az sayıda ara zincir düğümüne bağlanabilir ve rollup'ın durum geçiş taleplerini gönderebilir. Bu talepler, ara zincirin belirli bir çekirdek doğrulayıcısı tarafından doğrulanır; tek 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şlemenin dengesi
Rollup, Polkadot'un çok çekirdekli mimarisini kullanarak dikey ölçeklenmeyi gerçekleştirebilir. Bu yeni yetenek, "esnek ölçeklenme" özelliği ile tanıtılmıştır. Tasarım sürecinde, rollup blok doğrulamasının belirli bir çekirdekte sabitlenmemesi nedeniyle, bu durumun esnekliği etkileyebileceği bulunmuştur.
Orta zincire blok göndermek için kullanılan protokol izin gerektirmeyen ve güvene dayanmayan bir yapıya sahip olduğundan, herkes rollup'a tahsis edilen herhangi bir çekirdeğe blok gönderip doğrulama yapabilir. Saldırganlar, daha önce doğrulanmış olan meşru blokları farklı çekirdeklerde tekrar tekrar göndermeyi kullanarak, kötü niyetle kaynak tüketebilir ve böylece rollup'ın genel verimliliğini ve throughput'unu azaltabilir.
Polkadot'un hedefi, sistemin temel ö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 güvenilir sıralayıcıların kötü niyetli davranışta bulunmadığını varsaymak, böylece rollup'ın aktivitesini güvence altına almak.
Ancak, Polkadot'un tasarım felsefesinde, sıralayıcıya 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'un durum dönüşüm taleplerini gönderebilmelidir.
Polkadot: Taviz Vermeyen Çözüm
Polkadot'un nihai seçtiği çözüm: Sorunu tamamen rollup'un durum dönüşüm fonksiyonuna (Runtime) bırakmaktır. Runtime, tüm konsensüs bilgilerinin tek güvenilir kaynağıdır, bu nedenle hangi Polkadot çekirdeğinde doğrulamanın gerçekleştirilmesi gerektiğini çıktı içinde açıkça belirtmek zorundadır.
Bu tasarım, esneklik ve güvenliğin çift korumasını sağlar. Polkadot, kullanılabilirlik sürecinde rollup'ın 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.
Polkadot'un veri kullanılabilirliği katmanına herhangi bir rollup bloğu yazılmadan önce, yaklaşık 5 doğrulayıcıdan oluşan bir grup önce bunun geçerliliğini doğrular. Bu grup, sıralayıcı tarafından sunulan aday makbuzları ve geçerlilik kanıtlarını alır, bunlar arasında rollup bloğu ve ilgili depolama kanıtı bulunmaktadır. Bu bilgiler, paralel zincir doğrulama fonksiyonuna iletilecek ve ara zincir üzerindeki doğrulayıcılar tarafından yeniden yürütülecektir.
Doğrulama sonucunda, blokların hangi çekirdek üzerinde doğrulanacağını belirtmek için bir core seçici içerir. Doğrulayıcı, bu indeksin kendi sorumlu olduğu çekirdek 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üven gerektirmeyen ve izin gerektirmeyen özelliklerini korumasını sağlar, sıralayıcı gibi kötü niyetli aktörlerin doğrulama pozisyonlarını manipüle etmesini engeller ve rollup birden fazla core kullansa bile esnekliğin korunması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 sadece bir dürüst sıralayıcı hayatta kalmayı sürdürebilir.
ELVES protokolü sayesinde, Polkadot güvenliğini tüm rollup'lara kapsamlı bir şekilde genişletir, tüm çekirdek üzerindeki hesaplamaları doğrular ve çekirdek sayısına dair 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ırlamayacaktır. Polkadot'un rollup modeli, tek bir yürütmenin 2 saniye içinde tamamlanması şartıyla, WebAssembly ortamında Turing tamamlayıcı hesaplamaları destekler. Esnek genişleme sayesinde, her 6 saniyelik döngüde gerçekleştirilebilecek toplam hesaplama miktarı artırılmakta, ancak hesaplama türü etkilenmemektedir.
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ındaki tek kabul edilebilir denge şeklidir.
Rollup, Agile Coretime arayüzü aracılığıyla kaynakları dinamik olarak ayarlayarak tutarlı bir güvenlik seviyesini koruyabilir. Ayrıca, farklı kullanım senaryolarına uyum sağlamak için kısmi RFC103 gereksinimlerini de yerine getirmelidir.
Belirli karmaşıklık, rollup'ın kaynak yönetim stratejilerine bağlıdır ve bu stratejiler zincir üzerindeki veya zincir dışındaki değişkenlere dayanabilir. Örnek olarak:
Basit strateji: her zaman sabit bir core miktarı kullanın veya zincir dışı manuel olarak ayarlayı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ında birlikte çalışabilirliği desteklerken, esnek ölçeklenebilirlik mesaj iletiminin verimliliğini etkilemez.
Karmaşık rollup'ların mesaj iletişimi, alt katman iletim 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üzeyinden ziyade kontrol yüzeyi olarak bir ara zincir tarafından dış mesajlaşmayı destekleyecektir. Bu güncelleme, rollup'lar arası iletişim yeteneklerini esnek genişleme ile birlikte artırarak sistemin dikey genişleme yeteneğini daha da güçlendirecektir.
Diğer Protokollerin Dengeleri
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 seviyeleri düşük olsa bile, performansları pek tatmin edici değildir.
Solana
Solana, Polkadot veya Ethereum'un parçalı mimarisini benimsememekte, bunun yerine tek katmanlı yüksek verimlilik mimarisi ile ölçeklenebilirlik sağlamaktadır. Tarihsel kanıt, CPU paralel işleme ve lider temelli konsensüs mekanizmasına dayanmaktadır; teorik TPS 65,000'e kadar ulaşabilmektedir.
Ana tasarım, önceden kamuya açık ve doğrulanabilir bir lider atama mekanizmasıdır:
Her epoch'ta (yaklaşık iki gün veya 432.000 slot) başlangıcında, stake miktarına göre slot dağıtılır;
Daha fazla stake yapıldığında, dağıtım da 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 üreticilerinin önceden açıklanması, ağın hedefli DDoS saldırılarına ve sık sık kesintilere maruz kalma riskini artırmıştır.
Tarih, paralel işlemenin donanım gereksinimlerinin çok yüksek olduğunu ve bu durumun doğrulama düğümlerinin merkezileşmesine yol açtığını kanıtlamıştır. Daha fazla stake eden düğümlerin blok oluşturma fırsatı artarken, küçük düğümlerin neredeyse hiç slotu olmamakta ve bu durum merkezileşmeyi daha da artırmakta, ayrıca saldırıya uğradığında sistemin çökme riskini de artırmaktadır.
Solana, TPS peşinde merkeziyetsizliği ve saldırı dayanıklılığını feda etti, Nakamoto katsayısı yalnızca 20'dir ve bu, Polkadot'un 172'sinin çok altındadır.
TON
TON, 104.715 TPS ulaşabileceğini iddia ediyor, ancak bu sayı özel bir test ağında, 256 düğümle, ideal ağ ve donanım koşullarında gerçekleştirilmiştir. Polkadot ise merkeziyetsiz ana ağda 128K TPS'ye ulaşmıştır.
TON'un konsensüs mekanizmasında güvenlik açığı bulunmaktadır: parçalanmış doğrulayıcı düğümlerin 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 olarak kullanılabilir. "Kumarbaz iflası" mekanizmasının eksikliği nedeniyle, saldırganlar belirli bir parçayı tamamen kontrol edene kadar 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 atanır ve gecikmeli olarak ifşa edilir, bu nedenle saldırganlar doğrulayıcıların kimliğini önceden bilemez. Saldırı, tüm kontrolü başarıyla elde etmeyi gerektirir; eğer bir dürüst doğrulayıcı itirazda bulunursa, saldırı başarısız olur ve saldırganın teminat kaybına neden olur.
Avalanche
Avalanche, ana ağ + alt ağ mimarisi kullanarak genişlemektedir. 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önetmek) bileşenlerinden oluşmaktadır.
Her bir alt ağın teorik TPS'si ~5,000'e ulaşabilir, bu da 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ğlara katılımı serbestçe seçmelerine izin verir ve alt ağlar coğrafi, KYC gibi ek gereksinimler belirleyebilir, bu da merkeziyetsizlik ve güvenlikten fedakarlık yapar.
Polkadot'ta, tüm rollup'lar ortak bir güvenlik garantisi paylaşırken; Avalanche'ın alt ağlarının varsayılan bir güvenlik garantisi yoktur, bazıları tamamen merkeziyeteşebilir. Güvenliği artırmak istendiğinde, yine de performansta bir ödün vermek gerekecek ve kesin bir güvenlik taahhüdü sağlamak zor olacaktır.
Ethereum
Ethereum'un ölçeklenebilirlik stratejisi, temel katmanda doğrudan sorunları çözmek yerine, rollup katmanının ölçeklenebilirliğine bahis yapmaktır. Bu yaklaşım temelde sorunu çözmemekte, sadece sorunu yığın üzerindeki bir üst katmana aktarmaktadır.
İyimser Rollup
Şu anda çoğu Optimistic rollup merkeziyettir ve güvenlik eksikliği, birbirlerinden izole olmaları, yüksek gecikme (genellikle birkaç gün süren dolandırıcılık kanıtı süresini beklemek zorunda kalmaları) gibi sorunlar vardır.
ZK Rollup
ZK rollup'un uygulanması, tek bir işlem için işlenebilecek veri miktarı ile 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 yol açabilir. TPS'yi garanti altına almak için, ZK rollup genellikle her bir işlem grubunu sınırlamakta, yüksek talep sırasında ağ tıkanıklığı ve gaz fiyatlarının artmasına neden olarak kullanıcı deneyimini etkilemektedir.
Buna kıyasla, 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 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 ve maliyetleri ile kullanıcı ücretlerini daha da artırır.
Sonuç
Ölçeklenebilirliğin sonu, bir uzlaşma olmamalıdır.
Diğer genel blok zincirlerine kıyasla, Polkadot merkeziyete dayalı performans ve önceden belirlenmiş güven ile verimlilik değişimi yoluna girmemiştir. Bunun yerine, esnek ölçeklenebilirlik, izin gerektirmeyen protokol tasarımı, birleşik güvenlik katmanı ve esnek kaynak yönetimi 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çirilmesini hedeflerken, Polkadot'un savunduğu "sıfır güvenli ölçeklenebilirlik" 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.
19 Likes
Reward
19
5
Repost
Share
Comment
0/400
NFT_Therapy
· 07-16 00:58
Yine eski frenim dot ile karşılaştım!
View OriginalReply0
LayerZeroHero
· 07-14 19:38
Gerçek şu ki, kesinlikle bir trade-off var, bunu benchmark ile doğrulamak gerekiyor...
Polkadot'un Web3 mimarisi: Ölçeklenebilirlik ve güvenliğin mükemmel dengesi
Ölçeklenebilirlik ve Güvenlik Dengesi: Polkadot'un Web3 Mimari Tasarımı
Günümüzde blockchain teknolojisinin daha yüksek verimlilik peşinde koştuğu bir ortamda, bir anahtar sorun giderek daha belirgin hale geliyor: Performansı artırırken sistemin güvenliğinden ve esnekliğinden ödün vermeden nasıl yapılabilir? Bu yalnızca teknik bir zorluk değil, aynı zamanda mimari tasarımın derinlemesine değerlendirilmesini de içeriyor. Web3 ekosistemi için, eğer yüksek hızlı bir sistem güven ve güvenlikten ödün vererek inşa edilirse, genellikle gerçekten sürdürülebilir yenilikleri desteklemekte zorluk çeker.
Web3 ölçeklenebilirliğinin önemli bir destekleyicisi olarak Polkadot, yüksek throughput ve düşük gecikme hedeflerine ulaşırken bazı tavizler veriyor mu? Rollup modeli, merkeziyetsizlik, güvenlik veya ağlar arası birlikte çalışabilirlik açısından bir şeylerden feragat ediyor mu? Bu makale, bu sorular etrafında tartışmalar yürütecek, Polkadot'un ölçeklenebilirlik tasarımındaki seçimlerini ve dengelemelerini derinlemesine analiz edecek ve diğer ana akım kamu blok zincirlerinin çözümleri ile karşılaştırarak performans, güvenlik ve merkeziyetsizlik üçlüsü arasındaki farklı seçimleri inceleyecek.
Polkadot genişletme tasarımının karşılaştığı zorluklar
Esneklik ve merkeziyetsizlik dengesi
Polkadot'un mimarisi, doğrulayıcı ağı ve ara zincire bağlıdır, bu bazı açılardan merkezileşme riski getirebilir mi? Tek bir arıza noktası veya kontrol oluşması, merkeziyetsiz özelliklerini etkileyebilir mi?
Rollup'ın çalışması, bağlantılı ara zincirin sıralayıcısına bağımlıdır ve iletişim collator protokol mekanizmasını kullanır. Bu protokol tamamen izin gerektirmeyen, güvene dayanmayan bir yapıya sahiptir; ağ bağlantısı olan herkes bunu kullanabilir, az sayıda ara zincir düğümüne bağlanabilir ve rollup'ın durum geçiş taleplerini gönderebilir. Bu talepler, ara zincirin belirli bir çekirdek doğrulayıcısı tarafından doğrulanır; tek 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şlemenin dengesi
Rollup, Polkadot'un çok çekirdekli mimarisini kullanarak dikey ölçeklenmeyi gerçekleştirebilir. Bu yeni yetenek, "esnek ölçeklenme" özelliği ile tanıtılmıştır. Tasarım sürecinde, rollup blok doğrulamasının belirli bir çekirdekte sabitlenmemesi nedeniyle, bu durumun esnekliği etkileyebileceği bulunmuştur.
Orta zincire blok göndermek için kullanılan protokol izin gerektirmeyen ve güvene dayanmayan bir yapıya sahip olduğundan, herkes rollup'a tahsis edilen herhangi bir çekirdeğe blok gönderip doğrulama yapabilir. Saldırganlar, daha önce doğrulanmış olan meşru blokları farklı çekirdeklerde tekrar tekrar göndermeyi kullanarak, kötü niyetle kaynak tüketebilir ve böylece rollup'ın genel verimliliğini ve throughput'unu azaltabilir.
Polkadot'un hedefi, sistemin temel ö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 güvenilir sıralayıcıların kötü niyetli davranışta bulunmadığını varsaymak, böylece rollup'ın aktivitesini güvence altına almak.
Ancak, Polkadot'un tasarım felsefesinde, sıralayıcıya 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'un durum dönüşüm taleplerini gönderebilmelidir.
Polkadot: Taviz Vermeyen Çözüm
Polkadot'un nihai seçtiği çözüm: Sorunu tamamen rollup'un durum dönüşüm fonksiyonuna (Runtime) bırakmaktır. Runtime, tüm konsensüs bilgilerinin tek güvenilir kaynağıdır, bu nedenle hangi Polkadot çekirdeğinde doğrulamanın gerçekleştirilmesi gerektiğini çıktı içinde açıkça belirtmek zorundadır.
Bu tasarım, esneklik ve güvenliğin çift korumasını sağlar. Polkadot, kullanılabilirlik sürecinde rollup'ın 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.
Polkadot'un veri kullanılabilirliği katmanına herhangi bir rollup bloğu yazılmadan önce, yaklaşık 5 doğrulayıcıdan oluşan bir grup önce bunun geçerliliğini doğrular. Bu grup, sıralayıcı tarafından sunulan aday makbuzları ve geçerlilik kanıtlarını alır, bunlar arasında rollup bloğu ve ilgili depolama kanıtı bulunmaktadır. Bu bilgiler, paralel zincir doğrulama fonksiyonuna iletilecek ve ara zincir üzerindeki doğrulayıcılar tarafından yeniden yürütülecektir.
Doğrulama sonucunda, blokların hangi çekirdek üzerinde doğrulanacağını belirtmek için bir core seçici içerir. Doğrulayıcı, bu indeksin kendi sorumlu olduğu çekirdek 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üven gerektirmeyen ve izin gerektirmeyen özelliklerini korumasını sağlar, sıralayıcı gibi kötü niyetli aktörlerin doğrulama pozisyonlarını manipüle etmesini engeller ve rollup birden fazla core kullansa bile esnekliğin korunması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 sadece bir dürüst sıralayıcı hayatta kalmayı sürdürebilir.
ELVES protokolü sayesinde, Polkadot güvenliğini tüm rollup'lara kapsamlı bir şekilde genişletir, tüm çekirdek üzerindeki hesaplamaları doğrular ve çekirdek sayısına dair 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ırlamayacaktır. Polkadot'un rollup modeli, tek bir yürütmenin 2 saniye içinde tamamlanması şartıyla, WebAssembly ortamında Turing tamamlayıcı hesaplamaları destekler. Esnek genişleme sayesinde, her 6 saniyelik döngüde gerçekleştirilebilecek toplam hesaplama miktarı artırılmakta, ancak hesaplama türü etkilenmemektedir.
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ındaki tek kabul edilebilir denge şeklidir.
Rollup, Agile Coretime arayüzü aracılığıyla kaynakları dinamik olarak ayarlayarak tutarlı bir güvenlik seviyesini koruyabilir. Ayrıca, farklı kullanım senaryolarına uyum sağlamak için kısmi RFC103 gereksinimlerini de yerine getirmelidir.
Belirli karmaşıklık, rollup'ın kaynak yönetim stratejilerine bağlıdır ve bu stratejiler zincir üzerindeki veya zincir dışındaki değişkenlere dayanabilir. Örnek olarak:
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 desteklerken, esnek ölçeklenebilirlik mesaj iletiminin verimliliğini etkilemez.
Karmaşık rollup'ların mesaj iletişimi, alt katman iletim 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üzeyinden ziyade kontrol yüzeyi olarak bir ara zincir tarafından dış mesajlaşmayı destekleyecektir. Bu güncelleme, rollup'lar arası iletişim yeteneklerini esnek genişleme ile birlikte artırarak sistemin dikey genişleme yeteneğini daha da güçlendirecektir.
Diğer Protokollerin Dengeleri
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 seviyeleri düşük olsa bile, performansları pek tatmin edici değildir.
Solana
Solana, Polkadot veya Ethereum'un parçalı mimarisini benimsememekte, bunun yerine tek katmanlı yüksek verimlilik mimarisi ile ölçeklenebilirlik sağlamaktadır. Tarihsel kanıt, CPU paralel işleme ve lider temelli konsensüs mekanizmasına dayanmaktadır; teorik TPS 65,000'e kadar ulaşabilmektedir.
Ana tasarım, önceden kamuya açık ve doğrulanabilir bir lider atama mekanizmasıdır:
Tarih, paralel işlemenin donanım gereksinimlerinin çok yüksek olduğunu ve bu durumun doğrulama düğümlerinin merkezileşmesine yol açtığını kanıtlamıştır. Daha fazla stake eden düğümlerin blok oluşturma fırsatı artarken, küçük düğümlerin neredeyse hiç slotu olmamakta ve bu durum merkezileşmeyi daha da artırmakta, ayrıca saldırıya uğradığında sistemin çökme riskini de artırmaktadır.
Solana, TPS peşinde merkeziyetsizliği ve saldırı dayanıklılığını feda etti, Nakamoto katsayısı yalnızca 20'dir ve bu, Polkadot'un 172'sinin çok altındadır.
TON
TON, 104.715 TPS ulaşabileceğini iddia ediyor, ancak bu sayı özel bir test ağında, 256 düğümle, ideal ağ ve donanım koşullarında gerçekleştirilmiştir. Polkadot ise merkeziyetsiz ana ağda 128K TPS'ye ulaşmıştır.
TON'un konsensüs mekanizmasında güvenlik açığı bulunmaktadır: parçalanmış doğrulayıcı düğümlerin 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 olarak kullanılabilir. "Kumarbaz iflası" mekanizmasının eksikliği nedeniyle, saldırganlar belirli bir parçayı tamamen kontrol edene kadar 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 atanır ve gecikmeli olarak ifşa edilir, bu nedenle saldırganlar doğrulayıcıların kimliğini önceden bilemez. Saldırı, tüm kontrolü başarıyla elde etmeyi gerektirir; eğer bir dürüst doğrulayıcı itirazda bulunursa, saldırı başarısız olur ve saldırganın teminat kaybına neden olur.
Avalanche
Avalanche, ana ağ + alt ağ mimarisi kullanarak genişlemektedir. 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önetmek) bileşenlerinden oluşmaktadır.
Her bir alt ağın teorik TPS'si ~5,000'e ulaşabilir, bu da 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ğlara katılımı serbestçe seçmelerine izin verir ve alt ağlar coğrafi, KYC gibi ek gereksinimler belirleyebilir, bu da merkeziyetsizlik ve güvenlikten fedakarlık yapar.
Polkadot'ta, tüm rollup'lar ortak bir güvenlik garantisi paylaşırken; Avalanche'ın alt ağlarının varsayılan bir güvenlik garantisi yoktur, bazıları tamamen merkeziyeteşebilir. Güvenliği artırmak istendiğinde, yine de performansta bir ödün vermek gerekecek ve kesin bir güvenlik taahhüdü sağlamak zor olacaktır.
Ethereum
Ethereum'un ölçeklenebilirlik stratejisi, temel katmanda doğrudan sorunları çözmek yerine, rollup katmanının ölçeklenebilirliğine bahis yapmaktır. Bu yaklaşım temelde sorunu çözmemekte, sadece sorunu yığın üzerindeki bir üst katmana aktarmaktadır.
İyimser Rollup
Şu anda çoğu Optimistic rollup merkeziyettir ve güvenlik eksikliği, birbirlerinden izole olmaları, yüksek gecikme (genellikle birkaç gün süren dolandırıcılık kanıtı süresini beklemek zorunda kalmaları) gibi sorunlar vardır.
ZK Rollup
ZK rollup'un uygulanması, tek bir işlem için işlenebilecek veri miktarı ile 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 yol açabilir. TPS'yi garanti altına almak için, ZK rollup genellikle her bir işlem grubunu sınırlamakta, yüksek talep sırasında ağ tıkanıklığı ve gaz fiyatlarının artmasına neden olarak kullanıcı deneyimini etkilemektedir.
Buna kıyasla, 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 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 ve maliyetleri ile kullanıcı ücretlerini daha da artırır.
Sonuç
Ölçeklenebilirliğin sonu, bir uzlaşma olmamalıdır.
Diğer genel blok zincirlerine kıyasla, Polkadot merkeziyete dayalı performans ve önceden belirlenmiş güven ile verimlilik değişimi yoluna girmemiştir. Bunun yerine, esnek ölçeklenebilirlik, izin gerektirmeyen protokol tasarımı, birleşik güvenlik katmanı ve esnek kaynak yönetimi 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çirilmesini hedeflerken, Polkadot'un savunduğu "sıfır güvenli ölçeklenebilirlik" belki de Web3'ün uzun vadeli gelişimini destekleyebilecek gerçek çözüm.