Ölçeklenebilirlik, Güvenlik ve Merkeziyetsizlik Dengesi: Polkadot'un Teknik Seçimleri

Blok zincirinin sürekli olarak daha yüksek verimlilik peşinde koştuğu bugün, bir anahtar sorun giderek belirginleşiyor: Ölçeklenebilirlik sağlanırken, güvenlik ve sistem esnekliğinden vazgeçmek zorunda mıyız?

Bu sadece teknik düzeyde bir zorluk değil, aynı zamanda mimari tasarımın derin bir seçimidir. Web3 ekosistemi için, daha hızlı bir sistem güven ve güvenliğin feda edilmesi üzerine inşa ediliyorsa, gerçek sürdürülebilir yenilikleri desteklemesi genellikle zordur.

Polkadot, Web3 ölçeklenebilirliğinin önemli bir itici gücü olarak, yüksek işlem hacmi ve düşük gecikme hedefleri doğrultusunda bazı fedakarlıklar mı yaptı? Rollup modeli, Merkeziyetsizlik, güvenlik veya ağ birlikte çalışabilirliği konusunda tavizler mi verdi?

Bu makale, Polkadot'un ölçeklenebilirlik tasarımındaki tercih ve dengelemeleri derinlemesine inceleyecek ve diğer ana akım kamu zincirleri ile çözümlerini karşılaştırarak, performans, güvenlik ve Merkeziyetsizlik arasında 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ğları ve merkezi bir ara zincir üzerine bağımlıdır. Bu, bazı açılardan merkeziyetçilik risklerini getirebilir mi? Tek bir arıza noktası veya kontrol oluşma olasılığı var mı, bu da merkeziyetsizlik özelliklerini etkileyebilir?

Rollup'ın çalışması, bağlantılı ara zincirin sıralayıcısına bağımlıdır ve iletişim, collator protokolü olarak adlandırılan bir mekanizma kullanır. Bu protokol tamamen izin gerektirmeyen, güvensizdir; ağ bağlantısı olan herkes bunu kullanabilir, birkaç ara zincir düğümüne bağlanabilir ve rollup'ın durum değiştirme taleplerini iletebilir. Bu talepler, ara zincirin bir core'u tarafından doğrulanır ve yalnızca bir ön koşulun karşılanması gerekir: geçerli bir durum değişikliği olmalıdır, aksi takdirde bu rollup'ın durumu ilerletilmeyecektir.

Dikey genişletme dengesi

Rollup, Polkadot'un çok çekirdekli mimarisini kullanarak dikey ölçeklenmeyi gerçekleştirebilir. Bu yeni yetenek, "esnek ölçeklenme" işlevi ile tanıtıldı. Tasarım sürecinde, rollup blok doğrulamasının belirli bir çekirdekte sabitlenmemiş olması nedeniyle esnekliğini etkileyebileceği tespit edildi.

Orta zincire blok göndermek için kullanılan protokol, izin gerektirmeyen ve güven gerektirmeyen bir yapıya sahip olduğundan, herkes rollup'a tahsis edilen herhangi bir core'a blok gönderebilir. Saldırganlar, daha önce doğrulanmış olan meşru 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 hedefi, sistemin temel özelliklerini etkilemeden, rollup'ların esnekliğini ve relay chain 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 güvenilir sıralayıcının kötü niyetli davranışta bulunmayacağını varsayarak rollup'ın etkinliğini garanti altına almak.

Ancak, Polkadot'un tasarım felsefesinde, sequencer'a herhangi bir güven varsayımı yapamayı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'ın 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ğinde doğrulamanın 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 dönüşümlerini yeniden yürütür ve ELVES kripto ekonomik protokolü aracılığıyla core dağıtımının doğruluğunu garanti eder.

Herhangi bir rollup bloğunun Polkadot veri kullanılabilirlik katmanına yazılmadan önce, yaklaşık 5 doğrulayıcıdan oluşan bir grup, önce onun yasallığını doğrulayacaktır. Bu grup, sıralayıcı tarafından sunulan aday makbuzları ve geçerlilik kanıtlarını alır; bu, rollup bloğunu ve ilgili depolama kanıtını içerir. Bu bilgiler, paralel zincir doğrulama işlevi tarafından işlenecek ve relay zincirindeki doğrulayıcılar tarafından yeniden gerçekleştirilecektir.

Doğrulama sonuçlarında hangi core üzerinde blokların doğrulanacağını belirlemek için bir core seçici içerir. Doğrulayıcı, bu indeksin kendi sorumlu olduğu core ile tutarlı olup olmadığını karşılaştıracaktır; eğer tutarsızsa, bu blok atılacaktır.

Bu mekanizma, sistemin her zaman güvene ihtiyaç duymayan ve izin gerektirmeyen özelliklerini korumasını sağlar, sıralayıcılar gibi kötü niyetli aktörlerin doğrulama konumunu manipüle etmesini önler ve rollup birden fazla çekirdek kullansa bile esnekliğini korur.

Güvenlik

Ölçeklenebilirlik peşinde koşarken, Polkadot güvenlikten ödün vermedi. Rollup'ın güvenliği, ara zincir tarafından sağlanır ve sadece bir dürüst sıralayıcı yeterlidir.

ELVES protokolü sayesinde, Polkadot güvenliğini tüm rollup'lara tamamen genişletir, çekirdek üzerindeki tüm hesaplamaları doğrular, çekirdek sayısına ilişkin herhangi bir kısıtlama veya varsayıma ihtiyaç duymaz.

Bu nedenle, Polkadot'un rollup'ları güvenlikten ödün vermeden gerçek ölçeklenebilirlik sağlayabilir.

Genel Kullanım

Esnek genişleme, rollup'ın programlanabilirliğini sınırlamayacaktır. Polkadot'un rollup modeli, WebAssembly ortamında Turing tam hesaplamaların yürütülmesini destekler, tek bir yürütme 2 saniye içinde tamamlandığı sürece. Esnek genişleme sayesinde, her 6 saniyelik döngü içinde gerçekleştirilebilecek toplam hesaplama miktarı artırılabilir, ancak hesaplama türü 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 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ısmen RFC103 gereksinimlerini 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 sayıda core kullanın veya zincir dışı olarak manuel ayarlamalar yapın;

• Hafif strateji: Belirli işlem yüklerini düğüm mempool'unda izlemek;

• Otomatik strateji: Tarihsel veriler ve XCM arayüzü aracılığıyla coretime hizmetini önceden arayarak kaynakları yapılandırma.

Otomatik yöntemler daha verimli olsa da, uygulama ve test maliyetleri de önemli ölçüde artmaktadır.

Müdahale

Polkadot, farklı rollup'lar arasındaki etkileşimi desteklerken, 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 zincir dışı mesajlaşmayı destekleyecek ve bunu kontrol yüzeyi olarak bir ara zincir kullanarak, veri yüzeyi yerine. Bu yükseltme, rollup'lar arası iletişim yeteneklerini esnek bir şekilde genişletmeyi artıracak ve sistemin dikey genişleme yeteneğini daha da güçlendirecektir.

Diğer protokoller hangi dengeleri sağladı?

Herkesçe bilindiği gibi, performans artışı genellikle merkeziyetsizlik ve güvenlikten fedakarlık yapılarak sağlanır. Ancak Nakamoto katsayısına göre, bazı Polkadot rakiplerinin merkeziyetsizlik derecesi düşük olsa bile, performansları pek tatmin edici değildir.

Solana

Solana, Polkadot veya Ethereum'un parçalama mimarisini kullanmıyor, bunun yerine tek katmanlı yüksek işlem hacmi mimarisi ile ölçeklenebilirlik sağlıyor ve Tarihsel Kanıt (PoH), CPU paralel işleme ve lider bazlı konsensüs mekanizmasına dayanıyor. Teorik TPS 65.000'e kadar çıkabiliyor.

Bir ana tasarım, önceden halka açık ve doğrulanabilir lider planlama mekanizmasıdır:

• Her epoch'un (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ıkça, dağıtım da 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 üreticileri önceden duyurulmuş olup, bu durum ağın hedefli DDoS saldırılarına ve sık sık kesintilere maruz kalma riskini artırmıştır.

PoH ve paralel işleme, donanım gereksinimlerini son derece yüksek tutarak doğrulayıcı düğümlerin merkeziyetsizliğini artırır. Daha fazla hissesine sahip düğümlerin blok oluşturma şansı daha yüksektir, küçük düğümlerin neredeyse hiç slotu yoktur, bu da merkeziyetsizliği daha da artırır ve saldırıya uğradığında sistemin çökme riskini artırır.

Solana, TPS peşinde merkeziyetsizlik ve saldırıya dayanıklılık yeteneğinden feragat etti, Nakamoto katsayısı yalnızca 20 olup Polkadot'un 172'sinin çok altındadır.

TON

TON, TPS'nin 104.715'e kadar çıkabileceğini iddia ediyor, ancak bu rakam özel bir test ağında, 256 düğümle, ideal ağ ve donanım koşullarında elde edilmiştir. Polkadot ise Merkeziyetsizlik kamu ağında 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 edilecektir. TON beyaz kitabı da buna açıkça işaret eder; bu, bant genişliğini optimize etse de, kötü niyetli kişiler tarafından kullanılabilir. "Kumarbaz iflası" mekanizmasının eksikliği nedeniyle, saldırganlar bir parçayı tamamen kontrol altına almayı bekleyebilir veya DDoS saldırılarıyla dürüst doğrulayıcıları engelleyerek durumu değiştirebilir.

Buna karşın, 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 bilemez, saldırı tüm kontrolü kazanmak 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 kaybeder.

Avalanche

Avalanche, ana ağ + alt ağ mimarisi kullanarak ölçeklenir; ana ağ, X-Chain (transferler, ~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önetir) bileşenlerinden oluşur.

Her bir 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çeklenmeyi sağlamak. Ancak Avalanche, doğrulayıcıların alt ağlara katılımını serbestçe seçmelerine izin verir ve alt ağlar coğrafi, KYC gibi ek gereksinimler belirleyebilir, bu da Merkeziyetsizlik ve güvenlikten ödün vermek anlamına gelir.

Polkadot'ta, tüm rolluplar ortak bir güvenlik garantisi paylaşır; oysa Avalanche'ın alt ağları varsayılan bir güvenlik garantisine sahip değildir ve bazıları tamamen merkeziyetsiz olabilir. Güvenliği artırmak istiyorsanız, yine de performansta bir taviz vermeniz gerekecek ve kesin bir güvenlik taahhüdü sağlamak zor olacaktır.

Ethereum

Ethereum'in ölçeklendirme stratejisi, temel katmanda doğrudan sorunları çözmek yerine rollup katmanının ölçeklenebilirliğine bahis yapmaktır. Bu yöntem esasen sorunu çözmemekte, sadece sorunu yığın katmanının bir üstüne aktarmaktadır.

İyimser Rollup

Şu anda çoğu Optimistic rollup merkeziyetsizdir (bazıları sadece bir sequencer'a sahiptir), güvenlik yetersizliği, birbirinden izolasyon, yüksek gecikme (dolandırıcılık kanıtı süresinin beklenmesi gerekir, genellikle birkaç gün) gibi sorunlar vardır.

ZK Rollup

ZK rollup'un uygulanması, tek bir işlemde işlenebilecek veri miktarının sınırlamalarıyla karşı karşıyadır. Sıfır bilgi kanıtı üretme hesaplama gereksinimleri oldukça yüksektir ve "kazanan hepsini alır" mekanizması sistemin merkeziyetsizleşmesini kolaylaştırabilir. TPS'yi garanti altına almak için, ZK rollup genellikle her işlem grubundaki işlem sayısını sınırlar; yüksek talep dönemlerinde ağ tıkanıklığı, gaz fiyatlarının artması gibi sorunlar yaşanabilir ve bu da kullanıcı deneyimini olumsuz etkiler.

Buna karşılık, Turing tam ZK rollup'ın maliyeti Polkadot'un çekirdek 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 ve kullanıcı ücretlerini daha da artırır.

Sonuç

Ölçeklenebilirliğin sonu, uzlaşma olmamalıdır.

Diğer halka açık blok zincirlerine kıyasla, Polkadot merkeziyetsizlikten ödün vermeden performansı, önceden belirlenmiş güvenle verimliliği değişen bir yol izlememiştir. Bunun yerine, esnek ölçeklenebilirlik, izinsiz 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 gerçekleştirilmesi peşinde, Polkadot'un savunduğu "sıfır güven ölçeklenebilirliği" belki de Web3'ün uzun vadeli gelişimini destekleyebilecek gerçek çözüm.