Blok Zinciri Genişletilebilirliğinin Tercihi: Polkadot'un Yenilikçi Yolu

Blok Zinciri teknolojisinin daha yüksek verimlilik peşinde koştuğu bugünlerde, bir anahtar sorun giderek belirginleşiyor: Performansı artırırken, 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 seçimidir. Web3 ekosistemi için, daha hızlı bir sistem eğer güven ve güvenliğin feda edilmesi üzerine inşa ediliyorsa, genellikle gerçekten sürdürülebilir yenilikleri desteklemekte zorlanır.

Web3 ölçeklenebilirliğinin önemli bir destekleyicisi olarak, Polkadot yüksek işlem hacmi ve düşük gecikme hedeflerine ulaşırken bazı tavizler verdi mi? Rollup modeli merkeziyetsizlik, güvenlik veya ağ etkileşimi konusunda bir ödün mü verdi? Bu makale, Polkadot'un ölçeklenebilirlik tasarımındaki seçimlerini ve dengelemelerini derinlemesine inceleyecek ve diğer ana akım halka açık blok zincirlerin çözümleriyle 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ğı ve (Relay Chain)'a bağlıdır. Bu, bazı yönlerden merkeziyetçilik riski getirebilir mi? Tek bir arıza noktası veya kontrol oluşması mümkün mü, bu da merkeziyetsiz özelliklerini etkileyebilir mi?

Rollup'ın çalışması, ( sıralayıcısına bağlı olarak, ara zinciri bağlayan bir iletişim mekanizması olan collator protokolüne dayanır. Bu protokol tamamen izinsiz ve güvensizdir, ağa bağlı olan herkes bunu kullanabilir, birkaç ara zincir düğümü ile bağlantı kurabilir ve rollup'ın durum dönüşüm taleplerini gönderebilir. Bu talepler, ara zincirin bir core'u tarafından doğrulanır, sadece bir ön koşul yerine getirilmelidir: Geçerli bir durum dönüşümü olmalıdır, aksi takdirde rollup'ın durumu ilerletilmeyecektir.

) Dikey genişleme ikilemi

Rollup, Polkadot'un çok çekirdekli mimarisini kullanarak dikey ölçeklendirme gerçekleştirebilir. Bu yeni yetenek, "esnek ölçeklendirme" ### Elastic Scaling ( işlevi ile tanıtıldı. Tasarım sürecinde, rollup blok doğrulamasının belirli bir çekirdek üzerinde sabitlenmemesi nedeniyle bu durumun esnekliği etkileyebileceği keşfedilmiştir.

Orta zincire blok göndermek için protokolün izin gerektirmeyen, güvene dayanmayan olması nedeniyle, herkes blokları rollup'un tahsis edildiği herhangi bir core'a doğrulama için gönderebilir. Saldırganlar bunu kullanarak, daha önce doğrulanmış geçerli blokları farklı core'lara tekrar tekrar gönderebilir, kötü niyetle kaynak tüketebilir ve böylece rollup'un genel işleme kapasitesini ve verimliliğini azaltabilir.

Polkadot'un hedefi, sistemin kritik özelliklerini etkilemeden, rollup'un esnekliğini ve ara zincir kaynaklarının etkin kullanımını sürdürmektir.

) Sequencer'ın güven problemi

Basit bir çözüm, protokolü "izinli" olarak ayarlamaktır: örneğin, beyaz liste mekanizması benimsemek veya varsayılan olarak sıralayıcıların kötü niyetli davranışta bulunmayacağına güvenmek, böylece rollup'ın aktivitesini güvence altına almak.

Ancak, Polkadot'un tasarım felsefesinde, sequencer ile ilgili 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 durum dönüşüm talepleri gönderebilmelidir.

Polkadot: Uzlaşmaz Çözüm

Polkadot'un nihai seçtiği çözüm: Sorunu tamamen rollup'un durum dönüşüm fonksiyonu ###Runtime('a 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 yapılması gerektiği açıkça belirtilmelidir.

Bu tasarım, esneklik ve güvenliğin çift güvence altına alındığı bir yapıdır. 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 sağlar.

Herhangi bir rollup Blok'un Polkadot veri kullanılabilirlik katmanına yazılmadan önce )DA(, yaklaşık 5 kişiden oluşan bir grup öncelikle geçerliliğini doğruladı. Onlar, sıralayıcı tarafından sunulan aday makbuzu )candidate receipt( ve geçerlilik kanıtı )PoV( alır; bu, rollup Blok'u ve ilgili depolama kanıtını içerir. Bu bilgiler, paralel zincir doğrulama fonksiyonu tarafından işlenecek ve aracı zincir üzerindeki doğrulayıcılar tarafından yeniden yürütülecektir.

Doğrulama sonucunda, hangi çekirdekte blokların doğrulanacağını belirtmek için bir çekirdek seçici içerir. Doğrulayıcı, bu indeksin sorumlu olduğu çekirdek ile uyumlu olup olmadığını karşılaştırır; eğer uyumsuzsa, bu blok atılacaktır.

Bu mekanizma, sistemin her zaman güvene dayalı ve izin gerektirmeyen özellikleri 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ği sağlar.

) Güvenlik

Ölçeklenebilirlik arayışında Polkadot, güvenlikten ödün vermemiştir. Rollup'ın güvenliği, relay chain tarafından sağlanmaktadır, sadece bir dürüst sıralayıcı hayatta kalmayı sürdürebilir.

ELVES protokolü sayesinde, Polkadot güvenliğini tüm rollup'lara tam olarak genişletir, çekirdek üzerindeki tüm hesaplamaları doğrular, çekirdek sayısına ilişkin 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 tam hesaplamalarını destekler. Esnek genişleme sayesinde, her 6 saniyelik döngüde gerçekleştirilebilecek toplam hesaplama miktarı artırılabilir, ancak hesaplama türü 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ındaki tek kabul edilebilir denge yoludur.

Rollup, Agile Coretime arayüzü üzerinden 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 de yerine getirmelidir.

Belirli karmaşıklık, rollup'ın kaynak yönetim stratejilerine bağlıdır; bu stratejiler zincir üzerindeki veya zincir dışındaki değişkenlere dayanabilir. Örneğin:

• 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: Tarih verileri 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.

Birlikte Çalışabilirlik

Polkadot, farklı rolluplar arasında etkileşimi desteklerken, esnek ölçeklenmenin mesaj iletiminin verimliliğini etkilemeyecektir.

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 ### off-chain messaging ( için zincir dışı mesajlaşmayı destekleyecek, burada kontrol katmanı olarak bir ara zincir kullanılacak, veri katmanı yerine. Bu güncelleme, rollup'lar arası iletişim yeteneklerini esneklikle artıracak ve sistemin dikey ölçeklenebilirliğini daha da güçlendirecektir.

Diğer Protokollerin Dengeleri

Herkes tarafından bilindiği gibi, performans artışı genellikle merkeziyetsizlik ve güvenlikten feragat edilerek elde edilir. Ancak Nakamoto katsayısına göre, bazı Polkadot rakiplerinin merkeziyetsizlik dereceleri düşük olsa da, performansları da pek iç açıcı değildir.

) Solana

Solana, Polkadot veya Ethereum'un parçalı mimarisini kullanmamakta, bunun yerine tek katmanlı yüksek verim mimarisi ile ölçeklenebilirlik sağlamaktadır. Tarihsel kanıtlara ###PoH(, CPU paralel işleme ve lider tabanlı konsensüs mekanizmasına dayanarak, teorik TPS 65,000'e kadar ulaşabilmektedir.

Ana tasarım unsurlarından biri, önceden halka açık ve doğrulanabilir lider atama mekanizmasıdır:

• Her epoch ) yaklaşık iki gün veya 432.000 slot ( başladığında, stake miktarına göre slot dağıtılır;
• Daha fazla staking, daha fazla dağıtım demektir. Örneğin, %1 staking yapan bir doğrulayıcı yaklaşık %1 blok oluşturma şansı elde edecektir;
• Tüm blok üretenler önceden ilan edildi, bu durum ağın hedefli DDoS saldırılarına ve sık sık kesintilere maruz kalma riskini artırdı.

PoH ve paralel işlem, donanım gereksinimlerini son derece yüksek hale getirerek doğrulayıcı düğümlerin merkezileşmesine neden olur. Daha fazla stake edilen düğümlerin blok oluşturma şansı daha büyük, küçük düğümlerin neredeyse hiç slotu yok, bu da merkezileşmeyi daha da artırır ve sistemin saldırıya uğraması durumunda çökme riskini artırır.

Solana, TPS peşinde merkeziyetsizlik ve saldırı dayanıklılığından ödün vermiştir, Nakamoto katsayısı sadece 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 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çığı var: parça doğrulayıcı düğümlerin kimlikleri önceden açığa çıkabilir. TON beyaz kitabı da açıkça belirtmektedir ki, bu bant genişliğini optimize etse de kötü niyetli bir şekilde kullanılabilir. "Kumarbaz iflası" mekanizmasının eksikliği nedeniyle, saldırganlar belirli 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şılık, Polkadot'ta 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ü kazanmayı gerektirir, eğer bir dürüst doğrulayıcı itiraz başlatırsa, saldırı başarısız olur ve saldırganın teminat kaybına yol açar.

Avalanche

Avalanche, ana ağ + alt ağ mimarisi kullanarak ölçeklenir. Ana ağ, X-Chain### transferleri, ~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 için oluşur.

Her bir alt ağın teorik TPS'i ~5,000'e ulaşabilir, 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ılmada serbestçe seçim yapmalarına izin verir ve alt ağlar coğrafi, KYC gibi ek gereksinimler belirleyebilir, bu da merkeziyetsizlik ve güvenlikten feragat edilmesine yol açar.

Polkadot'ta, tüm rolluplar ortak bir güvenlik garantisi paylaşırken; Avalanche'ın alt ağlarının varsayılan bir güvenlik garantisi yoktur, bazıları ise tamamen merkezi hale gelebilir. Güvenliği artırmak isterseniz, yine performansta bir taviz vermeniz gerekir ve belirli 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çeklenmesine bahis oynamaktır. Bu yaklaşım esasen sorunu çözmemekte, yalnızca sorunu yığının bir üst katmanına aktarmaktadır.

)# İyimser Rollup

Şu anda çoğu Optimistic rollup merkeziyettir. ### Bazıları sadece bir sıralayıcıya sahiptir ###, bu da güvenlik eksikliği, birbirinden izole olma, yüksek gecikme ( dolandırıcılık kanıtı süresinin beklenmesi gerektiği, genellikle birkaç gün ) gibi sorunlara yol açmaktadır.

(# ZK Rollup

ZK rollup'ın uygulanması, tek bir işlem için işlenebilecek veri miktarının kısıtlamalarından etkilenir. Sıfır bilgi kanıtı oluşturma hesaplama gereksinimleri son derece yüksektir ve "kazanan her şeyi alır" mekanizması sistemin merkezileşmesine neden olabilir. TPS'yi sağlamak için, ZK rollup genellikle her bir işlem grubundaki işlem sayısını sınırlar; yüksek talep olduğunda ağ tıkanıklığı, gaz fiyatlarının artışı gibi sorunlara yol açarak kullanıcı deneyimini olumsuz etkiler.

Buna karşılık, 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 bağlıdır ve maliyetleri ve kullanıcı ücretlerini daha da artırır.

Sonuç

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

Diğer kamu blok zincirleri ile karşılaştırıldığında, Polkadot merkeziyeti performans için feda etme veya önceden belirlenmiş güven ile verimlilik sağlama yolunu seçmemiştir. Bunun yerine, esnek ölçeklenebilirlik, izinsiz 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.

Bugün 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.