Web3 Ölçeklenebilirlik Dengelemesi: Polkadot'un Çözümü

Blok zincirinin daha yüksek verimlilik arayışında olduğu günümüzde, bir anahtar sorun giderek belirginleşiyor: Performansı artırırken güvenlik ve sistem esnekliğini nasıl dengede tutabiliriz?

Bu sadece teknik düzeyde bir zorluk değil, aynı zamanda mimari tasarımın derin bir seçimi. Web3 ekosistemi için, daha hızlı bir sistemin güven ve güvenlikten fedakarlık ederek inşa edilmesi, genellikle gerçek sürdürülebilir yeniliği desteklemede zorlanır.

Polkadot, Web3 ölçeklenebilirliğinin önemli bir destekçisi olarak, rollup modelinin merkeziyetsizlik, güvenlik veya ağler arası etkileşimde bir fedakarlık yapıp yapmadığını sorguluyor. Bu makale, Polkadot'un ölçeklenebilirlik tasarımındaki tercihlerini ve dengelemelerini derinlemesine inceleyecek ve diğer ana akım halka açık blok zincirlerinin çözümleri ile 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 zincirine dayanıyor, bu bazı açılardan merkeziyetçilik risklerini getirebilir mi? Tek bir arıza noktası veya kontrol oluşması mümkün mü, bu da onun merkeziyetsiz özelliklerini etkileyebilir mi?

Rollup'un çalışması, bir ara zincirin sıralayıcısına bağlıdır ve iletişim, collator protokolü adı verilen bir mekanizmayı kullanır. Bu protokol tamamen izinsiz ve güvensizdir, ağa bağlı olan herkes bunu kullanabilir, birkaç ara zincir düğümüne bağlanabilir ve rollup'un durum geçişi taleplerini gönderebilir. Bu talepler, ara zincirin bir çekirdek doğrulayıcısı tarafından doğrulanır; tek bir ön koşul gereklidir: geçerli bir durum geçişi olmalıdır, aksi takdirde bu rollup'un durumu ilerletilmeyecektir.

Dikey genişletme dengesi

Rollup, Polkadot'un çok çekirdekli mimarisinden yararlanarak dikey ölçeklenmeyi gerçekleştirebilir. Bu yeni yetenek "esnek ölçeklenme" işlevi ile tanıtılmıştır. Tasarım sürecinde, rollup blok doğrulamasının belirli bir çekirdek üzerinde sabitlenmemesi nedeniyle esnekliğini etkileyebileceğini fark ettik.

Orta zincire blok sunma protokolü izin gerektirmeyen ve güvene dayanmayan bir yapıya sahip olduğundan, herkes rollup'un atandığı herhangi bir core'a blok sunabilir. Saldırganlar, daha önce doğrulanmış olan meşru blokları farklı core'lara tekrar tekrar sunarak kötü niyetli bir şekilde kaynak tüketebilir ve böylece rollup'un genel verimliliğini ve verimliliğini 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 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ğini varsaymak, rollup'ın etkinliğini güvence altına alır.

Ancak, Polkadot'un tasarım felsefesinde, sequencer'a karşı herhangi bir güven varsayımında bulunamayız, çünkü sistemin "güvensiz" ve "izin gerektirmeyen" özelliklerini korumak gerekmektedir. Herkes, collator protokolünü kullanarak rollup'un durum geçiş taleplerini gönderebilmelidir.

Polkadot: Taviz Vermeyen Çözüm

Polkadot'un nihai seçtiği çözüm şudur: Sorunu tamamen rollup'un durum dönüştürme 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ğrulama yapılması 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 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.

Polkadot'un veri kullanılabilirlik katmanına (DA) herhangi bir rollup bloğunun yazılmasından önce, yaklaşık 5 doğrulayıcıdan oluşan bir grup, geçerliliğini doğrulamak için önce hareket eder. Bu grup, sıralayıcı tarafından sunulan aday makbuzları ve geçerlilik kanıtlarını alır; bunlar rollup bloğu ve ilgili depolama kanıtlarını içerir. Bu bilgiler, paralel zincir doğrulama işlevleri tarafından işlenecek ve aracı zincirdeki doğrulayıcılar tarafından yeniden yürütülecektir.

Doğrulama sonucunda, blokların hangi çekirdek üzerinde doğrulanacağını belirten bir çekirdek seçici (core selector) bulunur. Doğrulayıcı, bu indeksin kendisine ait olan çekirdek ile uyumlu olup olmadığını kontrol eder; eğer uyumlu değilse, bu blok reddedilecektir.

Bu mekanizma, sistemin her zaman güvene ihtiyaç duymadan ve izin almadan çalışmasını sağlamakta, sıralayıcı gibi kötü niyetli aktörlerin doğrulama konumunu manipüle etmesini önlemekte, böylece rollup birden fazla çekirdek kullansa bile esnekliğini korumaktadır.

güvenlik

Ölçeklenebilirlik arayışında 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 rolluplara tamamen genişletir, tüm çekirdek üzerindeki hesaplamaları doğrular ve çekirdek sayısına herhangi bir kısıtlama 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'un programlanabilirliğini sınırlamayacaktır. Polkadot'un rollup modeli, WebAssembly ortamında Turing tamamlayıcı hesaplamaların gerçekleştirilmesini destekler, yeter ki tek bir yürütme 2 saniye içinde tamamlansın. 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 throughput 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 seviyesini koruyabilir. Ayrıca, farklı kullanım senaryolarına uyum sağlamak için RFC103'ün bazı gereksinimlerini yerine getirmelidir.

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

• Basit strateji: Her zaman sabit bir core miktarı kullanın veya zincir dışı manuel ayarlamalar yapın;

• Hafif strateji: Düğüm mempool'unda belirli işlem yüklerini izleme;

• Otomatik strateji: Geçmiş veriler ve XCM arayüzü aracılığıyla coretime hizmeti için kaynakları önceden yapılandırma.

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

birlikte çalışabilirlik

Polkadot, farklı rollup'lar arasında etkileşimi desteklerken, esnek ölçeklenebilirlik mesaj iletiminin verimliliğini etkilemez.

Rollup'lar arası mesajlaşma iletişimi, alt katman taşıma katmanı tarafından gerçekleştirilir; her rollup'un iletişim blok alanı sabittir ve tahsis edilen çekirdek sayısıyla ilgisi yoktur.

Gelecekte, Polkadot ayrıca dışa mesaj iletimini destekleyecek, burada kontrol düzeyi olarak ara zincir kullanılacak, veri düzeyi yerine. Bu güncelleme, rollup'lar arası iletişim yeteneğini esnek genişleme ile birlikte artıracak ve sistemin dikey genişleme yeteneğini daha da güçlendirecek.

Diğer protokoller hangi uzlaşmaları yaptı?

Herkesin bildiği gibi, performans artışı genellikle merkeziyetsizlik ve güvenlikten feragat edilmesiyle gerçekleşir. Ancak Nakamoto katsayısına göre, bazı Polkadot rakiplerinin merkeziyetsizlik düzeyi düşük olsa da, performansları pek de tatmin edici değildir.

Belirli bir blok zinciri A

Bir kamu blok zinciri A, Polkadot veya Ethereum'un parçalı mimarisini kullanmamakta, bunun yerine tek katmanlı yüksek verim mimarisi ile ölçeklenebilirliği sağlamaktadır. Tarihsel kanıt, CPU paralel işleme ve lider tabanlı konsensüs mekanizmasına dayanarak, teorik TPS 65,000'e ulaşabilir.

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;

• Ne kadar çok stake yaparsanız, o kadar fazla dağıtım alırsınız. Örneğin, %1 stake yapan bir doğrulayıcı yaklaşık %1 blok oluşturma şansı elde edecektir;

• Tüm blok üreticileri önceden duyuruldu, bu da ağın hedefli DDoS saldırılarına ve sık kesintilere maruz kalma riskini artırmaktadır.

Tarih, paralel işlemenin donanım gereksinimlerinin son derece yüksek olduğunu ve bunun da doğrulama düğümlerinin merkezileşmesine yol açtığını kanıtlamıştır. Daha fazla stake eden düğümlerin blok oluşturma fırsatları daha büyük olurken, 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.

Bir kamu blok zinciri A, TPS'yi artırmak için merkeziyetsizliği ve saldırıya dayanıklılığı feda etmiştir, Nakamoto katsayısı yalnızca 20'dir, bu da Polkadot'un 172'sinin oldukça altındadır.

Belirli bir kamu blok zinciri B

Bir kamu blockchain'i B, 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 elde edilmiştir. Oysa Polkadot, merkeziyetsiz kamu ağında 128K TPS'ye ulaşmıştır.

Bir kamu blok zinciri B'nin konsensüs mekanizmasında güvenlik açığı bulunmaktadır: parçalama doğrulama düğümlerinin kimlikleri önceden ifşa edilebilir. Kamu blok zinciri B'nin beyaz kitabı da açıkça belirtmektedir ki, bu bant genişliğini optimize etse de kötü niyetli kullanımlara yol açabilir. "Kumarbaz iflası" mekanizmasının eksikliği nedeniyle, saldırganlar bir parçayı tamamen kontrol altına almak için bekleyebilir veya dürüst doğrulayıcıların bağlantısını kesmek için DDoS saldırıları gerçekleştirebilir, bu da durumu değiştirmelerine olanak tanır.

Buna karşın, Polkadot'un doğrulayıcıları rastgele atanmakta ve gecikmeli olarak ortaya çıkmaktadır; saldırganlar doğrulayıcı kimliğini önceden bilemezler. Saldırının başarılı olması için tüm kontrolü riske atmak gerekmekte, eğer bir dürüst doğrulayıcı itirazda bulunursa saldırı başarısız olur ve saldırganın stake kaybına yol açar.

Belirli Bir Kamu Zinciri C

Bazı bir kamu blok zinciri C, ana ağ + alt ağ mimarisi kullanarak genişler; ana ağ, X-Chain (transfer, ~4,500 TPS), C-Chain (akıllı sözleşme, ~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'si ~5,000'e kadar ulaşabilir, Polkadot'un yaklaşımına benzer: tekil shard'ın yükünü azaltarak ölçeklenebilirliği sağlamak. Ancak, belirli bir halka açık blok zinciri C, doğrulayıcılara alt ağlara katılmayı serbestçe seçme imkanı tanırken, alt ağlar coğrafi, KYC gibi ek gereksinimler belirleyebilir ve bu da merkeziyetsizlik ve güvenlikten fedakarlık yapılmasına yol açar.

Polkadot'ta, tüm rollup'lar birleşik bir güvenlik garantisi paylaşır; ancak belirli bir kamu zinciri C'nin alt ağı, varsayılan bir güvenlik garantisine sahip değildir ve bazıları tamamen merkezi hale gelebilir. Güvenliği artırmak istiyorsanız, yine de performansta bir ödün vermeniz gerekecek ve kesin bir güvenlik taahhüdü sağlamak zor olacaktır.

Ethereum

Ethereum'un ölçeklenebilirlik stratejisi, temel katmanda sorunları doğrudan çözmek yerine rollup katmanının ölçeklenebilirliğine bahis oynamaktır. Bu yaklaşım esasen sorunları çözmemekte, yalnızca sorunları yığın üzerindeki bir üst katmana aktarmaktadır.

İyimser Rollup

Şu anda çoğu Optimistik rollup merkeziyettir (bazıları yalnızca bir sequencer'a sahiptir) ve güvenlik eksikliği, birbirinden izole olma, yüksek gecikme (dolandırıcılık kanıtı süresini beklemek gerektiğinden, genellikle birkaç gün) gibi sorunlar vardır.

ZK Rollup

ZK rollup'un uygulanması, tek bir işlem başına işlenebilecek veri miktarıyla sınırlıdır. Sıfır bilgi kanıtı oluşturmanın hesaplama gereksinimleri çok 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 miktarını sınırlar, yüksek talep durumlarında ağ tıkanıklığı ve gaz fiyatlarının artmasına neden olarak kullanıcı deneyimini etkiler.

Buna göre, Turing tam ZK rollup'un maliyeti yaklaşık olarak Polkadot'un temel kripto ekonomik güvenlik protokolünün 2x10^6 katıdır.

Ayrıca, ZK rollup'ın veri kullanılabilirliği sorunları 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, bir uzlaşma olmamalıdır.

Diğer kamu blok zincirleriyle kıyaslandığında, Polkadot merkeziyete geçerek performans elde etme veya önceden belirlenmiş güven ile verimlilik sağlama yolunu izlememiştir. Bunun yerine, esnek ölçeklenebilirlik, 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.

Günümüzde daha büyük ölçekli uygulamaların hayata geçirilmesini hedeflerken, Polkadot'un benimsediği "sıfır güven genişlemesi", belki de Web3'ün uzun vadeli gelişimini destekleyebilecek gerçek çözüm olabilir.