Ölçeklenebilirlik Dengesi: Polkadot ve Web3'ün Zorlukları
Günümüzde blok zincirinin daha yüksek verimlilik peşinde koştuğu bir dönemde, bir anahtar sorun giderek belirginleşiyor: Performansı artırırken güvenlik ve sistem esnekliğinden nasıl ödün vermemek gerekiyor? Bu sadece teknik bir meydan okuma değil, aynı zamanda mimari tasarımda derin bir seçimdir. Web3 ekosistemi için, daha hızlı bir sistem eğer güven ve güvenlikten ödün verme temelinde inşa edilmişse, genellikle gerçekten sürdürülebilir yenilikleri desteklemek için yetersiz kalır.
Web3 ölçeklenebilirliğinin önemli bir destekçisi olarak, Polkadot yüksek işlem hacmi ve düşük gecikme hedefinde bazı fedakarlıklar yapmış mı? Rollup modeli, merkeziyetsizlik, güvenlik veya ağlar arası etkileşim konusunda bazı tavizler vermiş mi?
Bu makale, bu sorunlar etrafında dönecek, Polkadot'un ölçeklenebilirlik tasarımındaki tercihleri ve dengeleri derinlemesine analiz edecek ve diğer ana akım kamu blok zincirlerinin çözümleriyle karşılaştırarak performans, güvenlik ve merkeziyetsizlik arasındaki farklı yol seçimlerini tartışacaktır.
Polkadot'un mimarisi, doğrulayıcı ağı ve ara zincire bağımlıdır; bu, bazı açılardan merkezileşme riski getirebilir mi? Tek bir nokta arızası veya kontrolü oluşabilir mi, bu da merkeziyetsiz özelliklerini etkileyebilir mi?
Rollup'ın çalışması, bağlantılı bir 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 iletebilir. Bu talepler, ara zincirin bir çekirdeği tarafından doğrulanır ve yalnızca bir ön koşulun karşılanması gerekir: geçerli bir durum geçişi olmalıdır, aksi takdirde o rollup'ın durumu ileriye taşınmayacaktır.
Dikey genişleme dengelemeleri
Rollup, Polkadot'un çok çekirdekli mimarisinden yararlanarak dikey ölçeklenmeyi gerçekleştirebilir. Bu yeni yetenek, "esnek ölçeklenebilirlik" özelliği ile tanıtılmıştır. Tasarım sürecinde, rollup bloklarının doğrulamasının belirli bir çekirdek üzerinde sabitlenmemesi nedeniyle esnekliğini etkileyebileceği keşfedilmiştir.
Orta zincire blok gönderme protokolü izin gerektirmediği ve güvene dayanmadığı için, herkes rollup'a tahsis edilen herhangi bir çekirdeğe blok gönderebilir ve doğrulama yapabilir. Saldırganlar bunu kötüye kullanarak, daha önce doğrulanmış geçerli blokları farklı çekirdeklere tekrar tekrar gönderebilir ve kaynakları kötü niyetli bir şekilde tüketerek rollup'ın genel verimliliğini ve verimliliğini azaltabilir.
Polkadot'un amacı, sistemin ana özelliklerini etkilemeden, rollup'un 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ıların kötü niyetli davranmayacağını varsaymak, böylece rollup'ın etkinliğini sağlamak.
Ancak, Polkadot'un tasarım felsefesinde, sequencer'a karşı 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 durum dönüşüm talepleri gönderebilmelidir.
Polkadot: Taviz Vermeyen Çö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ğrulama yapılması gerektiği açıkça belirtilmelidir.
Bu tasarım, esneklik ve güvenliğin çift koruması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ğunun Polkadot'un veri erişim katmanına yazılmadan önce, yaklaşık 5 doğrulayıcıdan oluşan bir grup öncelikle geçerliliğini doğrulayacaktır. Bu grup, sıralayıcı tarafından gönderilen aday makbuzları ve geçerlilik kanıtlarını alır ve bunlar rollup bloğ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 sonucunda, blokların hangi çekirdek üzerinde doğrulanacağını belirtmek için bir çekirdek seçici içerir. Doğrulayıcı, bu indeksin kendisinin sorumlu olduğu çekirdek ile uyumlu olup olmadığını karşılaştırır; eğer uyumlu değilse, bu blok atılacaktır.
Bu mekanizma, sistemin her zaman güven gerektirmeyen ve izin gerektirmeyen özelliklerini korumasını sağlar, sıralayıcılar gibi kötü niyetli aktörlerin doğrulama konumunu manipüle etmesini engeller ve rollup birden fazla çekirdek kullansa bile esnekliği korur.
güvenlik
Ölçeklenebilirlik peşinde koşarken, Polkadot güvenlikten ödün vermemiştir. Rollup'ın güvenliği, bir ana zincir tarafından sağlanmaktadır ve sadece bir dürüst sıralayıcı yeterlidir.
ELVES protokolü sayesinde, Polkadot güvenliğini tüm rollup'lara eksiksiz bir şekilde genişletir, tüm çekirdeklerdeki hesaplamaları doğrular ve çekirdek sayısına herhangi bir sınırlama veya varsayımda bulunmaya gerek kalmaz.
Bu nedenle, Polkadot'un rollup'ları gerçek ölçeklenebilirliği güvenlikten ödün vermeden gerçekleştirebilir.
Genel Kullanım
Esnek genişleme, rollup'ın programlanabilirliğini kısıtlamaz. Polkadot'un rollup modeli, tek bir yürütmenin 2 saniye içinde tamamlanması koşuluyla, WebAssembly ortamında Turing tam hesaplamayı destekler. Esnek genişleme sayesinde, her 6 saniyelik döngü içinde 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 uzlaşma yoludur.
Rollup, Agile Coretime arayüzü aracılığıyla kaynakları dinamik olarak ayarlayarak tutarlı bir güvenlik seviyesi sağlamak için kullanılabilir. Ayrıca, farklı kullanım senaryolarına uyum sağlamak için kısmi RFC103 gerekliliklerini yerine getirmeleri gerekir.
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. Örneğin:
Basit strateji: Her zaman sabit bir core sayısı kullanın veya zincir dışı manuel olarak ayarlayın;
Hafif strateji: Düğüm mempool'unda belirli işlem yüklerini izlemek;
Otomatik stratejiler: Tarihsel 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 etkileşimi desteklerken, esnek ölçeklenebilirlik mesaj iletiminin verimliliğini etkilemez.
Kapsayıcı rollup'ların mesaj iletimi, alt düzey 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 alanı yerine kontrol alanı olarak bir ara zincir kullanarak, zincir dışı mesajlaşmayı destekleyecektir. Bu güncelleme, rollup'lar arasındaki iletişim yeteneklerinin esnek bir şekilde genişlemesini sağlayarak sistemin dikey genişleme yeteneklerini daha da artıracaktır.
Diğer protokoller hangi ödünleri verdi?
Herkesin bildiği gibi, performans artışı genellikle merkezsizlik ve güvenlikten ödün verilmesiyle elde edilir. Ancak Nakamoto katsayısına bakıldığında, bazı Polkadot rakiplerinin merkezsizlik derecesi daha düşük olsa da, performansları da pek tatmin edici değildir.
Solana
Solana, Polkadot veya Ethereum'un parçalı mimarisini kullanmak yerine, çok katmanlı yüksek verimlilik mimarisi ile ölçeklenebilirlik sağlamakta, tarihsel kanıt (PoH), CPU paralel işleme ve liderlik temelli konsensüs mekanizmasına dayanmaktadır. Teorik TPS 65,000'e kadar çıkabilmektedir.
Bir ana 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şlangıcında, stake miktarına göre slot dağıtılır;
Daha fazla staking, daha fazla dağıtım anlamına gelir. Örneğin, %1'lik bir doğrulayıcı stake edenler, yaklaşık %1'lik blok oluşturma şansına sahip olacaktır;
Tüm blok üreticileri önceden açıklandığı için, ağın hedefli DDoS saldırılarına maruz kalma ve sık sık çökme riski artmıştır.
PoH ve paralel işleme, donanım gereksinimlerini son derece yüksek hale getirir ve bu da doğrulama düğümlerinin merkezileşmesine yol açar. Daha fazla stake eden 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ılara karşı dayanıklılığı feda etti; Nakamoto katsayısı yalnızca 20'dir, bu da 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ında gerçekleştirilmiştir. Polkadot ise merkeziyetsiz halka açık bir ağda 128K TPS'ye ulaşmıştır.
TON'un konsensüs mekanizmasında güvenlik açıkları bulunmaktadır: parça doğrulama 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ım için fırsat yaratabilir. "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ı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 gecikmeli olarak açıklanır; saldırganlar, doğrulayıcıların kimliğini önceden bilemezler. Saldırı, tüm kontrolü başarıyla sağlamak için bahis yapmayı gerektirir; eğer bir dürüst doğrulayıcı itirazda bulunursa, saldırı başarısız olur ve saldırgan stake kaybına uğrar.
Avalanche
Avalanche, ana ağ + alt ağ mimarisi kullanarak ölçeklenir. 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şur.
Her bir alt ağın teorik TPS değeri ~5,000'e 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 seçiminde özgür olmasına izin verir ve alt ağlar coğrafi, KYC gibi ek gereksinimler belirleyebilir, bu da merkeziyetsizlik ve güvenlikten feragat anlamına gelir.
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 ve bazıları tamamen merkezi hale gelebilir. Güvenliği artırmak istendiğinde, performansta bir uzlaşma sağlamak gerekir ve belirleyici bir güvenlik taahhüdü sunmak zordur.
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, temelde sorunu çözmemektedir; aksine, sorunu yığının bir üst katmanına iletmektedir.
İyimser Rollup
Şu anda çoğu Optimistic rollup merkeziyettir (bazıları sadece bir sıralayıcıya sahiptir), güvenlik yetersizliği, birbirinden izole olma ve yüksek gecikme (genellikle birkaç gün süren dolandırıcılık kanıtı süresi beklemesi gerekir) 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ı oluşturma hesaplama gereksinimleri son derece yüksektir ve "kazanan her şeyi alır" mekanizması, sistemin merkezileşmesine yol açabilir. TPS'yi garantilemek için, ZK rollup genellikle her bir işlem grubunun miktarını sınırlar; bu da yüksek talep sırasında ağ tıkanıklığına ve gas fiyatlarının artmasına neden olabilir, bu da kullanıcı deneyimini olumsuz etkiler.
Buna kıyasla, Turing tam ZK rollup'un maliyeti yaklaşık olarak Polkadot'un çekirdek kripto ekonomi güvenlik protokolünün 2x10^6 katıdır.
Ayrıca, ZK rollup'ın veri kullanılabilirliği sorunları 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 zincirlerle karşılaştırıldığında, Polkadot merkeziyete geçiş yaparak performans elde etme veya önceden belirlenmiş güven ile verimlilik sağlamaya çalışmamaktadır. Bunun yerine, esnek genişleme, izin gerektirmeyen protokol tasarımı, birleşik güvenlik katmanı ve esnek kaynak yönetim mekanizması sayesinde 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 ölçeklenebilirliğ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.
13 Likes
Reward
13
10
Repost
Share
Comment
0/400
DuskSurfer
· 07-24 17:29
Altyapı öncelikli olmalıdır ki hızla ilerleyebilelim.
View OriginalReply0
TokenRationEater
· 07-24 00:36
Yeterince hızlı değil, zaten 22 yıl oldu.
View OriginalReply0
LiquidityWhisperer
· 07-22 15:35
Hız ve güvenlik bir arada olamaz mı?
View OriginalReply0
DiamondHands
· 07-22 13:17
Hız ve güvenlik aslında birbirini dışlar.
View OriginalReply0
GasGuru
· 07-21 22:12
Yine bir chain denge sağlama işlemi yapıyor.
View OriginalReply0
TokenVelocity
· 07-21 22:10
Polkadot gerçekten güvenli mi? Yoksa Emiciler Tarafından Oyuna Getirilmek mi?
View OriginalReply0
BearMarketSage
· 07-21 21:53
Ne yazık ki balık ve ayı pençesi bir arada olamaz.
View OriginalReply0
MidnightSeller
· 07-21 21:52
Hız için güvenliği feda etmek, neredeyse çatıda beklemek gibidir.
View OriginalReply0
PermabullPete
· 07-21 21:48
Anladım ama noktalar ne?
View OriginalReply0
MEVSandwichMaker
· 07-21 21:48
Kurbanın bedeli her zaman ödenmelidir, sadece kimin önce patlayacağına bağlı.
Polkadot, sıfır güvenli genişlemeyi nasıl gerçekleştiriyor? Web3'ün geleceğini şekillendiriyor.
Ölçeklenebilirlik Dengesi: Polkadot ve Web3'ün Zorlukları
Günümüzde blok zincirinin daha yüksek verimlilik peşinde koştuğu bir dönemde, bir anahtar sorun giderek belirginleşiyor: Performansı artırırken güvenlik ve sistem esnekliğinden nasıl ödün vermemek gerekiyor? Bu sadece teknik bir meydan okuma değil, aynı zamanda mimari tasarımda derin bir seçimdir. Web3 ekosistemi için, daha hızlı bir sistem eğer güven ve güvenlikten ödün verme temelinde inşa edilmişse, genellikle gerçekten sürdürülebilir yenilikleri desteklemek için yetersiz kalır.
Web3 ölçeklenebilirliğinin önemli bir destekçisi olarak, Polkadot yüksek işlem hacmi ve düşük gecikme hedefinde bazı fedakarlıklar yapmış mı? Rollup modeli, merkeziyetsizlik, güvenlik veya ağlar arası etkileşim konusunda bazı tavizler vermiş mi?
Bu makale, bu sorunlar etrafında dönecek, Polkadot'un ölçeklenebilirlik tasarımındaki tercihleri ve dengeleri derinlemesine analiz edecek ve diğer ana akım kamu blok zincirlerinin çözümleriyle karşılaştırarak 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 ara zincire bağımlıdır; bu, bazı açılardan merkezileşme riski getirebilir mi? Tek bir nokta arızası veya kontrolü oluşabilir mi, bu da merkeziyetsiz özelliklerini etkileyebilir mi?
Rollup'ın çalışması, bağlantılı bir 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 iletebilir. Bu talepler, ara zincirin bir çekirdeği tarafından doğrulanır ve yalnızca bir ön koşulun karşılanması gerekir: geçerli bir durum geçişi olmalıdır, aksi takdirde o rollup'ın durumu ileriye taşınmayacaktır.
Dikey genişleme dengelemeleri
Rollup, Polkadot'un çok çekirdekli mimarisinden yararlanarak dikey ölçeklenmeyi gerçekleştirebilir. Bu yeni yetenek, "esnek ölçeklenebilirlik" özelliği ile tanıtılmıştır. Tasarım sürecinde, rollup bloklarının doğrulamasının belirli bir çekirdek üzerinde sabitlenmemesi nedeniyle esnekliğini etkileyebileceği keşfedilmiştir.
Orta zincire blok gönderme protokolü izin gerektirmediği ve güvene dayanmadığı için, herkes rollup'a tahsis edilen herhangi bir çekirdeğe blok gönderebilir ve doğrulama yapabilir. Saldırganlar bunu kötüye kullanarak, daha önce doğrulanmış geçerli blokları farklı çekirdeklere tekrar tekrar gönderebilir ve kaynakları kötü niyetli bir şekilde tüketerek rollup'ın genel verimliliğini ve verimliliğini azaltabilir.
Polkadot'un amacı, sistemin ana özelliklerini etkilemeden, rollup'un 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ıların kötü niyetli davranmayacağını varsaymak, böylece rollup'ın etkinliğini sağlamak.
Ancak, Polkadot'un tasarım felsefesinde, sequencer'a karşı 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 durum dönüşüm talepleri gönderebilmelidir.
Polkadot: Taviz Vermeyen Çö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ğrulama yapılması gerektiği açıkça belirtilmelidir.
Bu tasarım, esneklik ve güvenliğin çift koruması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ğunun Polkadot'un veri erişim katmanına yazılmadan önce, yaklaşık 5 doğrulayıcıdan oluşan bir grup öncelikle geçerliliğini doğrulayacaktır. Bu grup, sıralayıcı tarafından gönderilen aday makbuzları ve geçerlilik kanıtlarını alır ve bunlar rollup bloğ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 sonucunda, blokların hangi çekirdek üzerinde doğrulanacağını belirtmek için bir çekirdek seçici içerir. Doğrulayıcı, bu indeksin kendisinin sorumlu olduğu çekirdek ile uyumlu olup olmadığını karşılaştırır; eğer uyumlu değilse, bu blok atılacaktır.
Bu mekanizma, sistemin her zaman güven gerektirmeyen ve izin gerektirmeyen özelliklerini korumasını sağlar, sıralayıcılar gibi kötü niyetli aktörlerin doğrulama konumunu manipüle etmesini engeller ve rollup birden fazla çekirdek kullansa bile esnekliği korur.
güvenlik
Ölçeklenebilirlik peşinde koşarken, Polkadot güvenlikten ödün vermemiştir. Rollup'ın güvenliği, bir ana zincir tarafından sağlanmaktadır ve sadece bir dürüst sıralayıcı yeterlidir.
ELVES protokolü sayesinde, Polkadot güvenliğini tüm rollup'lara eksiksiz bir şekilde genişletir, tüm çekirdeklerdeki hesaplamaları doğrular ve çekirdek sayısına herhangi bir sınırlama veya varsayımda bulunmaya gerek kalmaz.
Bu nedenle, Polkadot'un rollup'ları gerçek ölçeklenebilirliği güvenlikten ödün vermeden gerçekleştirebilir.
Genel Kullanım
Esnek genişleme, rollup'ın programlanabilirliğini kısıtlamaz. Polkadot'un rollup modeli, tek bir yürütmenin 2 saniye içinde tamamlanması koşuluyla, WebAssembly ortamında Turing tam hesaplamayı destekler. Esnek genişleme sayesinde, her 6 saniyelik döngü içinde 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 uzlaşma yoludur.
Rollup, Agile Coretime arayüzü aracılığıyla kaynakları dinamik olarak ayarlayarak tutarlı bir güvenlik seviyesi sağlamak için kullanılabilir. Ayrıca, farklı kullanım senaryolarına uyum sağlamak için kısmi RFC103 gerekliliklerini yerine getirmeleri gerekir.
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. Örneğin:
Basit strateji: Her zaman sabit bir core sayısı kullanın veya zincir dışı manuel olarak ayarlayın;
Hafif strateji: Düğüm mempool'unda belirli işlem yüklerini izlemek;
Otomatik stratejiler: Tarihsel 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 etkileşimi desteklerken, esnek ölçeklenebilirlik mesaj iletiminin verimliliğini etkilemez.
Kapsayıcı rollup'ların mesaj iletimi, alt düzey 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 alanı yerine kontrol alanı olarak bir ara zincir kullanarak, zincir dışı mesajlaşmayı destekleyecektir. Bu güncelleme, rollup'lar arasındaki iletişim yeteneklerinin esnek bir şekilde genişlemesini sağlayarak sistemin dikey genişleme yeteneklerini daha da artıracaktır.
Diğer protokoller hangi ödünleri verdi?
Herkesin bildiği gibi, performans artışı genellikle merkezsizlik ve güvenlikten ödün verilmesiyle elde edilir. Ancak Nakamoto katsayısına bakıldığında, bazı Polkadot rakiplerinin merkezsizlik derecesi daha düşük olsa da, performansları da pek tatmin edici değildir.
Solana
Solana, Polkadot veya Ethereum'un parçalı mimarisini kullanmak yerine, çok katmanlı yüksek verimlilik mimarisi ile ölçeklenebilirlik sağlamakta, tarihsel kanıt (PoH), CPU paralel işleme ve liderlik temelli konsensüs mekanizmasına dayanmaktadır. Teorik TPS 65,000'e kadar çıkabilmektedir.
Bir ana 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şlangıcında, stake miktarına göre slot dağıtılır;
Daha fazla staking, daha fazla dağıtım anlamına gelir. Örneğin, %1'lik bir doğrulayıcı stake edenler, yaklaşık %1'lik blok oluşturma şansına sahip olacaktır;
Tüm blok üreticileri önceden açıklandığı için, ağın hedefli DDoS saldırılarına maruz kalma ve sık sık çökme riski artmıştır.
PoH ve paralel işleme, donanım gereksinimlerini son derece yüksek hale getirir ve bu da doğrulama düğümlerinin merkezileşmesine yol açar. Daha fazla stake eden 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ılara karşı dayanıklılığı feda etti; Nakamoto katsayısı yalnızca 20'dir, bu da 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ında gerçekleştirilmiştir. Polkadot ise merkeziyetsiz halka açık bir ağda 128K TPS'ye ulaşmıştır.
TON'un konsensüs mekanizmasında güvenlik açıkları bulunmaktadır: parça doğrulama 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ım için fırsat yaratabilir. "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ı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 gecikmeli olarak açıklanır; saldırganlar, doğrulayıcıların kimliğini önceden bilemezler. Saldırı, tüm kontrolü başarıyla sağlamak için bahis yapmayı gerektirir; eğer bir dürüst doğrulayıcı itirazda bulunursa, saldırı başarısız olur ve saldırgan stake kaybına uğrar.
Avalanche
Avalanche, ana ağ + alt ağ mimarisi kullanarak ölçeklenir. 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şur.
Her bir alt ağın teorik TPS değeri ~5,000'e 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 seçiminde özgür olmasına izin verir ve alt ağlar coğrafi, KYC gibi ek gereksinimler belirleyebilir, bu da merkeziyetsizlik ve güvenlikten feragat anlamına gelir.
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 ve bazıları tamamen merkezi hale gelebilir. Güvenliği artırmak istendiğinde, performansta bir uzlaşma sağlamak gerekir ve belirleyici bir güvenlik taahhüdü sunmak zordur.
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, temelde sorunu çözmemektedir; aksine, sorunu yığının bir üst katmanına iletmektedir.
İyimser Rollup
Şu anda çoğu Optimistic rollup merkeziyettir (bazıları sadece bir sıralayıcıya sahiptir), güvenlik yetersizliği, birbirinden izole olma ve yüksek gecikme (genellikle birkaç gün süren dolandırıcılık kanıtı süresi beklemesi gerekir) 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ı oluşturma hesaplama gereksinimleri son derece yüksektir ve "kazanan her şeyi alır" mekanizması, sistemin merkezileşmesine yol açabilir. TPS'yi garantilemek için, ZK rollup genellikle her bir işlem grubunun miktarını sınırlar; bu da yüksek talep sırasında ağ tıkanıklığına ve gas fiyatlarının artmasına neden olabilir, bu da kullanıcı deneyimini olumsuz etkiler.
Buna kıyasla, Turing tam ZK rollup'un maliyeti yaklaşık olarak Polkadot'un çekirdek kripto ekonomi güvenlik protokolünün 2x10^6 katıdır.
Ayrıca, ZK rollup'ın veri kullanılabilirliği sorunları 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 zincirlerle karşılaştırıldığında, Polkadot merkeziyete geçiş yaparak performans elde etme veya önceden belirlenmiş güven ile verimlilik sağlamaya çalışmamaktadır. Bunun yerine, esnek genişleme, izin gerektirmeyen protokol tasarımı, birleşik güvenlik katmanı ve esnek kaynak yönetim mekanizması sayesinde 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 ölçeklenebilirliği", belki de Web3'ün uzun vadeli gelişimini destekleyebilecek gerçek çözüm.