Blok Zinciri Ölçeklenebilirliğinin Tercihleri ve Dengesi: Polkadot Örneği
Blok Zinciri teknolojisinin daha yüksek verimlilik peşinde koştuğu günümüzde, bir anahtar sorun giderek gün yüzüne çıkıyor: Performansı genişletirken, güvenlik ve sistem esnekliğinden ödün vermeden nasıl yapılabilir? Bu sadece teknik bir zorluk değil, aynı zamanda mimari tasarımın derin bir tercihidir. Web3 ekosistemi için, daha hızlı bir sistem güven ve güvenlikten ödün vererek inşa ediliyorsa, genellikle gerçekten sürdürülebilir yenilikleri desteklemesi zordur.
Web3 ölçeklenebilirliğinin önemli bir itici gücü olarak, Polkadot yüksek throughput ve düşük gecikme hedefleri doğrultusunda bazı fedakarlıklar yaptı mı? Rollup modeli, merkeziyetsizlik, güvenlik veya ağ birlikte çalışabilirliği konusunda tavizler verdi mi? Bu makale bu sorular etrafında şekillenecek, Polkadot'un ölçeklenebilirlik tasarımındaki tercihlerini ve dengelemelerini derinlemesine analiz edecek ve diğer ana akım kamu 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 dayanıyor, bu bazı açılardan merkeziyetçilik riskleri getirebilir mi? Tek bir arıza noktası veya kontrol oluşma ihtimali var mı, bu da merkeziyetsizlik özelliklerini etkileyebilir mi?
Rollup'ın çalışması, bir ara zincirin sıralayıcısına bağlıdır ve iletişimi collator protokolü adı verilen bir mekanizmayı kullanır. Bu protokol tamamen izin gerektirmeyen, güvene dayanmayan bir yapıya sahiptir; ağ bağlantısı olan herkes bunu kullanabilir, birkaç ara zincir düğümüne bağlanabilir ve rollup'ın durum dönüşüm taleplerini iletebilir. Bu talepler, ara zincirin bir çekirdek doğrulayıcısı tarafından doğrulanır ve yalnızca bir ön koşulun karşılanması gerekir: geçerli bir durum dönüşümü olmalıdır, aksi takdirde o rollup'ın durumu ilerletilmeyecektir.
Dikey genişleme dengesi
Rollup, Polkadot'un çoklu çekirdek mimarisinden yararlanarak dikey ölçeklendirme gerçekleştirebilir. Bu yeni yetenek "esnek ölçeklendirme" işlevi ile tanıtıldı. Tasarım sürecinde, rollup blok doğrulamasının belirli bir çekirdek üzerinde sabitlenmemesi nedeniyle esnekliği etkileyebileceği keşfedildi.
Orta zincire blok göndermek için protokol izinsiz ve güvene dayalı olmadığından, herkes, rollup'a tahsis edilen herhangi bir core'a blok gönderebilir ve bu blokların doğrulanmasını sağlayabilir. Saldırganlar, daha önce doğrulanan geçerli blokları farklı core'lara tekrar tekrar göndererek kaynakları kötüye kullanabilir ve böylece rollup'ın genel verimliliğini ve verimliliğini azaltabilir.
Polkadot'un amacı, sistemin temel özelliklerini etkilemeden rollup 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 davranış göstermeyeceğine güvenmektir, böylece rollup'ın aktivitesi güvence altına alınır.
Ancak, Polkadot'un tasarım felsefesinde, sequencer'a herhangi bir güven varsayımında bulunamayız çünkü sistemin "güven gerektirmeyen" ve "izin gerektirmeyen" özelliklerini korumamız gerekiyor. Herkes, collator protokolünü kullanarak rollup durum dönüşüm taleplerini gönderebilmelidir.
Polkadot: Uzlaşmaz Çözüm
Polkadot'un nihai seçtiği çözüm: Sorunu tamamen rollup'un durum değişim fonksiyonuna (Runtime) bırakmaktır. Runtime, tüm konsensüs bilgilerinin tek güvenilir kaynağıdır, bu nedenle çıktıda hangi Polkadot çekirdeğinde doğrulamanın gerçekleştirilmesi 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'ın durum dönüşümlerini yeniden gerçekleştirir ve core dağıtımının doğruluğunu ELVES şifreleme ekonomik protokolü ile güvence altına alır.
Herhangi bir rollup Blok'un Polkadot'un veri kullanılabilirlik katmanına yazılmadan önce, yaklaşık 5 doğrulayıcıdan oluşan bir grup önce onun geçerliliğini doğrular. Onlar sıralayıcı tarafından sunulan aday makbuzlar ve geçerlilik kanıtlarını alırlar; bu, rollup Blok'u 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, blokun hangi çekirdekte doğrulanacağını belirtmek için bir çekirdek seçici içerir. Doğrulayıcı, bu indeksin kendisine ait olan çekirdek ile uyumlu olup olmadığını karşılaştıracaktır; eğer uyumlu değilse, bu blok atılacaktır.
Bu mekanizma, sistemin her zaman güvene gerek duymayan ve izin gerektirmeyen özelliklerini korumasını sağlar, sıralayıcı gibi kötü niyetli aktörlerin doğrulama yerini manipüle etmesini önler ve rollup'ların birden fazla çekirdek kullanması durumunda bile esnekliğini korumasını garanti eder.
Güvenlik
Ölçeklenebilirlik arayışında, Polkadot güvenlikten ödün vermedi. Rollup'ın güvenliği, ana zincir tarafından sağlanır ve yalnızca bir dürüst sıralayıcı hayatta kalmayı sürdürebilir.
ELVES protokolü sayesinde, Polkadot güvenliğini tüm rolluplara tam olarak genişletir, tüm çekirdek üzerindeki hesaplamaları doğrular, çekirdek sayısı üzerinde herhangi bir kısıtlama veya varsayımda bulunmadan.
Bu nedenle, Polkadot'un rollup'ları güvenlikten ödün vermeden gerçek ölçeklenebilirlik sağlayabilir.
Genel Kullanım
Esnek genişleme, rollup'un programlanabilirliğini sınırlamayacaktır. 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 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 bir gecikme kaçınılmaz olarak karmaşıklığı beraberinde getirir; bu, sistem tasarımında 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 RFC103'ün bazı gereksinimlerini yerine getirmeleri gerekmektedir.
Belirli bir karmaşıklık, rollup'ın kaynak yönetim stratejilerine bağlıdır ve bu stratejiler, zincir içi veya zincir dışı değişkenlere dayanabilir. Örneğin:
Basit strateji: Her zaman sabit sayıda core kullanın veya zincir dışı manuel olarak ayarlayın;
Hafif strateji: Düğüm mempool'unda belirli işlem yüklerini izlemek;
Otomatik strateji: 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.
İşletilebilirlik
Polkadot, farklı rollup'lar arasında etkileşimi destekler ve esnek ölçeklenebilirlik mesaj iletiminin verimliliğini etkilemez.
Rollup'lar arası mesaj iletişimi, 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 verilerden ziyade kontrol düzlemi olarak bir ara zincir kullanarak zincir dışı mesajlaşmayı destekleyecektir. Bu yükseltme, rollup'lar arasındaki iletişim yeteneklerinin esnek genişlemeyle birlikte artırılmasını sağlayacak ve sistemin dikey genişleme yeteneğini daha da güçlendirecektir.
Diğer protokoller hangi ödünleri verdi?
Herkesçe bilindiği gibi, performans artışı genellikle merkeziyetsizlik ve güvenlikten ödün verme pahasına gerçekleşir. Ancak Nakamoto katsayısına göre, bazı Polkadot rakiplerinin merkeziyetsizlik dereceleri düşük olsa bile, performansları pek de iç açıcı değildir.
Solana
Solana, Polkadot veya Ethereum'un parçalama mimarisini kullanmamakta, bunun yerine tek katmanlı yüksek işlem hacmi mimarisi ile ölçeklenebilirlik sağlamaktadır. Tarihsel kanıt, CPU paralel işleme ve lider tabanlı konsensüs mekanizmasına dayanmaktadır; teorik TPS 65.000'e kadar ulaşabilir.
Ana bir tasarım, önceden kamuya açık ve doğrulanabilir lider atama mekanizmasıdır:
Her epoch (yaklaşık iki gün veya 432.000 slot) başlangıcında, staking miktarına göre slot dağıtılır;
Daha fazla stake yapıldıkça, dağıtım o kadar fazla olur. Örneğin, %1'lik bir doğrulayıcı stake eden biri yaklaşık %1 blok oluşturma şansına sahip olacaktır;
Tüm blok oluşturanlar önceden açıklanmış olup, ağın hedefli DDoS saldırılarına maruz kalma ve sık sık çökme riski artırılmış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ı göstermektedir. Daha fazla stake edilen düğümlerin blok üretme şansı daha büyükken, küçük düğümlerin neredeyse hiç slotu yoktur, bu da merkezileşmeyi daha da artırmakta ve saldırıya uğradığında sistemin çökme riskini artırmaktadır.
Solana, TPS peşinde merkeziyetsizliği ve saldırıya dayanıklılığı feda etti, Nakamoto katsayısı yalnızca 20'dir, bu da Polkadot'un 172'sinin oldukça altındadır.
TON
TON, TPS'nin 104,715'e ulaşabileceğini iddia ediyor, ancak bu rakam özel bir test ağında, 256 düğümle, ideal ağ ve donanım koşullarında gerçekleştirilmiştir. Polkadot ise merkeziyetsiz halka açık ağında 128K TPS'ye ulaşmıştır.
TON'un konsensüs mekanizmasında güvenlik açıkları bulunmaktadır: parçalama doğrulayıcılarının kimliği önceden ifşa edilebilir. TON beyaz kitabı da açıkça belirttiği gibi, bu bant genişliğini optimize etse de kötü niyetli kullanım için bir fırsat yaratabilir. "Kumarbaz iflası" mekanizmasının eksikliği nedeniyle, saldırganlar bir parçayı tamamen kontrol etmek için bekleyebilir veya DDoS saldırılarıyla dürüst doğrulayıcıların bağlantısını keserek durumu değiştirebilir.
Buna kıyasla, Polkadot'un doğrulayıcıları rastgele atanır ve gecikmeli olarak açıklanır, bu nedenle saldırganlar doğrulayıcıların kimliğini önceden bilemezler, saldırı tüm kontrolü kazanma üzerine bahis oynamalıdır; eğer bir dürüst doğrulayıcı itiraz başlatırsa, saldırı başarısız olur ve saldırgan stake'ini kaybeder.
Avalanche
Avalanche, ana ağ + alt ağ mimarisini genişletme için kullanı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 alt ağın teorik TPS'si ~5,000'e ulaşabilir, Polkadot'un yaklaşımına benzer: Tek bir shard'ın yükünü azaltarak ölçeklenme sağlamak. Ancak Avalanche, doğrulayıcıların alt ağlara katılma özgürlüğüne sahip olmasına izin verir ve alt ağlar coğrafi, KYC gibi ek gereksinimler ayarlayabilir; bu da merkeziyetsizlik ve güvenlikten ödün verir.
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 taviz vermek gerekmekte ve kesin güvenlik taahhütleri sağlamak zorlaşmaktadır.
Ethereum
Ethereum'un genişletme stratejisi, temel katmanda doğrudan sorunları çözmek yerine rollup katmanının ölçeklenebilirliğine bahis oynamaktır. Bu yaklaşım esasen problemi çözmemekte, sorunu yığın üst katmana aktarmaktadır.
İyimser Rollup
Şu anda çoğu Optimistic rollup merkeziyettir (bazıları hatta sadece bir sequencer'a sahiptir) ve güvenlik yetersizliği, birbirlerinden izole olma, yüksek gecikme (dolandırıcılık kanıtı süresinin beklenmesi gerekir, genellikle birkaç gün) gibi sorunlar bulunmaktadır.
ZK Rollup
ZK rollup'un uygulanması, tek bir işlem için işlenebilir veri miktarı ile 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 sağlamak için, ZK rollup genellikle her parti işlem miktarını sınırlamakta, yüksek talep anlarında ağ tıkanıklığına, gaz fiyatlarının artmasına ve kullanıcı deneyimini olumsuz etkilemektedir.
Buna karşılık, Turing tamamlayıcı ZK rollup'un maliyeti, Polkadot'un temel kriptoekonomi 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 bağlıdır ve maliyetleri ve kullanıcı ücretlerini daha da artırmaktadır.
Sonuç
Ölçeklenebilirliğin sonu, bir uzlaşma olmamalıdır.
Diğer halka açık blok zincirlerine kıyasla, Polkadot merkeziyete dayanarak performans, önceden belirlenmiş güven ile verimlilik kazanma yoluna gitmemiştir; bunun yerine esnek ölçeklenebilirlik, izin gerektirmeyen protokol tasarımı, birleşik güvenlik katmanı ve esnek kaynak yönetim mekanizması aracılığıyla güvenlik, merkeziyetsizlik ve yüksek performans arasında çok boyutlu bir denge sağlamıştır.
Günümüzde daha büyük ölçekli uygulamaların hayata geç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.
Polkadot esnek ölçeklenebilirlik: Performans ile Merkeziyetsizlik arasında denge arayışı
Blok Zinciri Ölçeklenebilirliğinin Tercihleri ve Dengesi: Polkadot Örneği
Blok Zinciri teknolojisinin daha yüksek verimlilik peşinde koştuğu günümüzde, bir anahtar sorun giderek gün yüzüne çıkıyor: Performansı genişletirken, güvenlik ve sistem esnekliğinden ödün vermeden nasıl yapılabilir? Bu sadece teknik bir zorluk değil, aynı zamanda mimari tasarımın derin bir tercihidir. Web3 ekosistemi için, daha hızlı bir sistem güven ve güvenlikten ödün vererek inşa ediliyorsa, genellikle gerçekten sürdürülebilir yenilikleri desteklemesi zordur.
Web3 ölçeklenebilirliğinin önemli bir itici gücü olarak, Polkadot yüksek throughput ve düşük gecikme hedefleri doğrultusunda bazı fedakarlıklar yaptı mı? Rollup modeli, merkeziyetsizlik, güvenlik veya ağ birlikte çalışabilirliği konusunda tavizler verdi mi? Bu makale bu sorular etrafında şekillenecek, Polkadot'un ölçeklenebilirlik tasarımındaki tercihlerini ve dengelemelerini derinlemesine analiz edecek ve diğer ana akım kamu 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 dayanıyor, bu bazı açılardan merkeziyetçilik riskleri getirebilir mi? Tek bir arıza noktası veya kontrol oluşma ihtimali var mı, bu da merkeziyetsizlik özelliklerini etkileyebilir mi?
Rollup'ın çalışması, bir ara zincirin sıralayıcısına bağlıdır ve iletişimi collator protokolü adı verilen bir mekanizmayı kullanır. Bu protokol tamamen izin gerektirmeyen, güvene dayanmayan bir yapıya sahiptir; ağ bağlantısı olan herkes bunu kullanabilir, birkaç ara zincir düğümüne bağlanabilir ve rollup'ın durum dönüşüm taleplerini iletebilir. Bu talepler, ara zincirin bir çekirdek doğrulayıcısı tarafından doğrulanır ve yalnızca bir ön koşulun karşılanması gerekir: geçerli bir durum dönüşümü olmalıdır, aksi takdirde o rollup'ın durumu ilerletilmeyecektir.
Dikey genişleme dengesi
Rollup, Polkadot'un çoklu çekirdek mimarisinden yararlanarak dikey ölçeklendirme gerçekleştirebilir. Bu yeni yetenek "esnek ölçeklendirme" işlevi ile tanıtıldı. Tasarım sürecinde, rollup blok doğrulamasının belirli bir çekirdek üzerinde sabitlenmemesi nedeniyle esnekliği etkileyebileceği keşfedildi.
Orta zincire blok göndermek için protokol izinsiz ve güvene dayalı olmadığından, herkes, rollup'a tahsis edilen herhangi bir core'a blok gönderebilir ve bu blokların doğrulanmasını sağlayabilir. Saldırganlar, daha önce doğrulanan geçerli blokları farklı core'lara tekrar tekrar göndererek kaynakları kötüye kullanabilir ve böylece rollup'ın genel verimliliğini ve verimliliğini azaltabilir.
Polkadot'un amacı, sistemin temel özelliklerini etkilemeden rollup 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 davranış göstermeyeceğine güvenmektir, böylece rollup'ın aktivitesi güvence altına alınır.
Ancak, Polkadot'un tasarım felsefesinde, sequencer'a herhangi bir güven varsayımında bulunamayız çünkü sistemin "güven gerektirmeyen" ve "izin gerektirmeyen" özelliklerini korumamız gerekiyor. Herkes, collator protokolünü kullanarak rollup durum dönüşüm taleplerini gönderebilmelidir.
Polkadot: Uzlaşmaz Çözüm
Polkadot'un nihai seçtiği çözüm: Sorunu tamamen rollup'un durum değişim fonksiyonuna (Runtime) bırakmaktır. Runtime, tüm konsensüs bilgilerinin tek güvenilir kaynağıdır, bu nedenle çıktıda hangi Polkadot çekirdeğinde doğrulamanın gerçekleştirilmesi 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'ın durum dönüşümlerini yeniden gerçekleştirir ve core dağıtımının doğruluğunu ELVES şifreleme ekonomik protokolü ile güvence altına alır.
Herhangi bir rollup Blok'un Polkadot'un veri kullanılabilirlik katmanına yazılmadan önce, yaklaşık 5 doğrulayıcıdan oluşan bir grup önce onun geçerliliğini doğrular. Onlar sıralayıcı tarafından sunulan aday makbuzlar ve geçerlilik kanıtlarını alırlar; bu, rollup Blok'u 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, blokun hangi çekirdekte doğrulanacağını belirtmek için bir çekirdek seçici içerir. Doğrulayıcı, bu indeksin kendisine ait olan çekirdek ile uyumlu olup olmadığını karşılaştıracaktır; eğer uyumlu değilse, bu blok atılacaktır.
Bu mekanizma, sistemin her zaman güvene gerek duymayan ve izin gerektirmeyen özelliklerini korumasını sağlar, sıralayıcı gibi kötü niyetli aktörlerin doğrulama yerini manipüle etmesini önler ve rollup'ların birden fazla çekirdek kullanması durumunda bile esnekliğini korumasını garanti eder.
Güvenlik
Ölçeklenebilirlik arayışında, Polkadot güvenlikten ödün vermedi. Rollup'ın güvenliği, ana zincir tarafından sağlanır ve yalnızca bir dürüst sıralayıcı hayatta kalmayı sürdürebilir.
ELVES protokolü sayesinde, Polkadot güvenliğini tüm rolluplara tam olarak genişletir, tüm çekirdek üzerindeki hesaplamaları doğrular, çekirdek sayısı üzerinde herhangi bir kısıtlama veya varsayımda bulunmadan.
Bu nedenle, Polkadot'un rollup'ları güvenlikten ödün vermeden gerçek ölçeklenebilirlik sağlayabilir.
Genel Kullanım
Esnek genişleme, rollup'un programlanabilirliğini sınırlamayacaktır. 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 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 bir gecikme kaçınılmaz olarak karmaşıklığı beraberinde getirir; bu, sistem tasarımında 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 RFC103'ün bazı gereksinimlerini yerine getirmeleri gerekmektedir.
Belirli bir karmaşıklık, rollup'ın kaynak yönetim stratejilerine bağlıdır ve bu stratejiler, zincir içi veya zincir dışı değişkenlere dayanabilir. Örneğin:
Basit strateji: Her zaman sabit sayıda core kullanın veya zincir dışı manuel olarak ayarlayın;
Hafif strateji: Düğüm mempool'unda belirli işlem yüklerini izlemek;
Otomatik strateji: 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.
İşletilebilirlik
Polkadot, farklı rollup'lar arasında etkileşimi destekler ve esnek ölçeklenebilirlik mesaj iletiminin verimliliğini etkilemez.
Rollup'lar arası mesaj iletişimi, 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 verilerden ziyade kontrol düzlemi olarak bir ara zincir kullanarak zincir dışı mesajlaşmayı destekleyecektir. Bu yükseltme, rollup'lar arasındaki iletişim yeteneklerinin esnek genişlemeyle birlikte artırılmasını sağlayacak ve sistemin dikey genişleme yeteneğini daha da güçlendirecektir.
Diğer protokoller hangi ödünleri verdi?
Herkesçe bilindiği gibi, performans artışı genellikle merkeziyetsizlik ve güvenlikten ödün verme pahasına gerçekleşir. Ancak Nakamoto katsayısına göre, bazı Polkadot rakiplerinin merkeziyetsizlik dereceleri düşük olsa bile, performansları pek de iç açıcı değildir.
Solana
Solana, Polkadot veya Ethereum'un parçalama mimarisini kullanmamakta, bunun yerine tek katmanlı yüksek işlem hacmi mimarisi ile ölçeklenebilirlik sağlamaktadır. Tarihsel kanıt, CPU paralel işleme ve lider tabanlı konsensüs mekanizmasına dayanmaktadır; teorik TPS 65.000'e kadar ulaşabilir.
Ana bir tasarım, önceden kamuya açık ve doğrulanabilir lider atama mekanizmasıdır:
Her epoch (yaklaşık iki gün veya 432.000 slot) başlangıcında, staking miktarına göre slot dağıtılır;
Daha fazla stake yapıldıkça, dağıtım o kadar fazla olur. Örneğin, %1'lik bir doğrulayıcı stake eden biri yaklaşık %1 blok oluşturma şansına sahip olacaktır;
Tüm blok oluşturanlar önceden açıklanmış olup, ağın hedefli DDoS saldırılarına maruz kalma ve sık sık çökme riski artırılmış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ı göstermektedir. Daha fazla stake edilen düğümlerin blok üretme şansı daha büyükken, küçük düğümlerin neredeyse hiç slotu yoktur, bu da merkezileşmeyi daha da artırmakta ve saldırıya uğradığında sistemin çökme riskini artırmaktadır.
Solana, TPS peşinde merkeziyetsizliği ve saldırıya dayanıklılığı feda etti, Nakamoto katsayısı yalnızca 20'dir, bu da Polkadot'un 172'sinin oldukça altındadır.
TON
TON, TPS'nin 104,715'e ulaşabileceğini iddia ediyor, ancak bu rakam özel bir test ağında, 256 düğümle, ideal ağ ve donanım koşullarında gerçekleştirilmiştir. Polkadot ise merkeziyetsiz halka açık ağında 128K TPS'ye ulaşmıştır.
TON'un konsensüs mekanizmasında güvenlik açıkları bulunmaktadır: parçalama doğrulayıcılarının kimliği önceden ifşa edilebilir. TON beyaz kitabı da açıkça belirttiği gibi, bu bant genişliğini optimize etse de kötü niyetli kullanım için bir fırsat yaratabilir. "Kumarbaz iflası" mekanizmasının eksikliği nedeniyle, saldırganlar bir parçayı tamamen kontrol etmek için bekleyebilir veya DDoS saldırılarıyla dürüst doğrulayıcıların bağlantısını keserek durumu değiştirebilir.
Buna kıyasla, Polkadot'un doğrulayıcıları rastgele atanır ve gecikmeli olarak açıklanır, bu nedenle saldırganlar doğrulayıcıların kimliğini önceden bilemezler, saldırı tüm kontrolü kazanma üzerine bahis oynamalıdır; eğer bir dürüst doğrulayıcı itiraz başlatırsa, saldırı başarısız olur ve saldırgan stake'ini kaybeder.
Avalanche
Avalanche, ana ağ + alt ağ mimarisini genişletme için kullanı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 alt ağın teorik TPS'si ~5,000'e ulaşabilir, Polkadot'un yaklaşımına benzer: Tek bir shard'ın yükünü azaltarak ölçeklenme sağlamak. Ancak Avalanche, doğrulayıcıların alt ağlara katılma özgürlüğüne sahip olmasına izin verir ve alt ağlar coğrafi, KYC gibi ek gereksinimler ayarlayabilir; bu da merkeziyetsizlik ve güvenlikten ödün verir.
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 taviz vermek gerekmekte ve kesin güvenlik taahhütleri sağlamak zorlaşmaktadır.
Ethereum
Ethereum'un genişletme stratejisi, temel katmanda doğrudan sorunları çözmek yerine rollup katmanının ölçeklenebilirliğine bahis oynamaktır. Bu yaklaşım esasen problemi çözmemekte, sorunu yığın üst katmana aktarmaktadır.
İyimser Rollup
Şu anda çoğu Optimistic rollup merkeziyettir (bazıları hatta sadece bir sequencer'a sahiptir) ve güvenlik yetersizliği, birbirlerinden izole olma, yüksek gecikme (dolandırıcılık kanıtı süresinin beklenmesi gerekir, genellikle birkaç gün) gibi sorunlar bulunmaktadır.
ZK Rollup
ZK rollup'un uygulanması, tek bir işlem için işlenebilir veri miktarı ile 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 sağlamak için, ZK rollup genellikle her parti işlem miktarını sınırlamakta, yüksek talep anlarında ağ tıkanıklığına, gaz fiyatlarının artmasına ve kullanıcı deneyimini olumsuz etkilemektedir.
Buna karşılık, Turing tamamlayıcı ZK rollup'un maliyeti, Polkadot'un temel kriptoekonomi 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 bağlıdır ve maliyetleri ve kullanıcı ücretlerini daha da artırmaktadır.
Sonuç
Ölçeklenebilirliğin sonu, bir uzlaşma olmamalıdır.
Diğer halka açık blok zincirlerine kıyasla, Polkadot merkeziyete dayanarak performans, önceden belirlenmiş güven ile verimlilik kazanma yoluna gitmemiştir; bunun yerine esnek ölçeklenebilirlik, izin gerektirmeyen protokol tasarımı, birleşik güvenlik katmanı ve esnek kaynak yönetim mekanizması aracılığıyla güvenlik, merkeziyetsizlik ve yüksek performans arasında çok boyutlu bir denge sağlamıştır.
Günümüzde daha büyük ölçekli uygulamaların hayata geç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.