Blok Zinciri Ölçeklenebilirliğinin Dengesi: Polkadot ve Web3'ün Denge Yolu

Blok zinciri sürekli olarak daha yüksek verimlilik peşinde koşarken, bir anahtar sorun giderek belirginleşiyor: Genişletme performansı sağlanırken güvenlik ve sistem esnekliğinden fedakarlık etmek zorunda mıyız? Bu sadece teknik düzeyde bir meydan okuma değil, aynı zamanda mimari tasarımda derin bir tercih meselesidir. Web3 ekosistemi için, daha hızlı bir sistem eğer güven ve güvenlikten fedakarlık ederek inşa ediliyorsa, genellikle gerçekten sürdürülebilir yenilikleri desteklemekte zorlanır.

Polkadot, Web3 ölçeklenebilirliğinin önemli bir destekçisi olarak, rollup modelinin merkeziyetsizlik, güvenlik veya ağ birlikte çalışabilirliği konusunda herhangi bir taviz verip vermediğini sorgulamaktadır. Bu makalede, Polkadot'un ölçeklenebilirlik tasarımındaki tercihleri ve dengelemeleri derinlemesine incelenecek ve diğer önde gelen kamu blok zincirlerinin çözümleriyle karşılaştırılarak, performans, güvenlik ve merkeziyetsizlik arasında tercih edilen farklı yollar tartışılacaktı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ü, böylece merkeziyetsiz özelliklerini etkileyebilir mi?

Rollup'un çalışması, ( sıralayıcı ) ile bağlantılı olan ara zincirin sıralayıcısına bağlıdır ve iletişimi collator protokolü adı verilen bir mekanizma kullanır. Bu protokol tamamen izin gerektirmeyen ve 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'un durum geçiş taleplerini iletebilir. Bu talepler, ara zincirin bir core'u tarafından doğrulanacak, yalnızca bir ön koşulu yerine getirdiği takdirde: geçerli bir durum geçişi olmalıdır, aksi takdirde bu rollup'un durumu ilerletilmeyecektir.

Dikey genişleme dengelemeleri

Rollup, Polkadot'un çok çekirdekli mimarisinden faydalanarak dikey ölçeklenmeyi gerçekleştirebilir. Bu yeni yetenek, "Elastic Scaling" ( Elastic Scaling ) özelliği ile tanıtıldı. Tasarım sürecinde, rollup blok doğrulamanın belirli bir çekirdekte sabitlenmemesi nedeniyle esnekliğini etkileyebileceğini fark ettik.

Orta zincire blok gönderme protokolü izinsiz ve güvene dayalı olmadığından, herkes blokları rollup'a tahsis edilen 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'ın genel işleme kapasitesini ve verimliliğini düşürebilir.

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

Sequencer güvenilir mi?

Basit bir çözüm, protokolü "lisanslı" 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 varsayarak rollup'ın etkinliğini sağlamaktır.

Ancak, Polkadot'un tasarım felsefesinde, sequencer'a karşı herhangi bir güven varsayımı yapamayız, çünkü sistemin "güvensiz" 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'ın durum dönüşüm fonksiyonu (Runtime)'a devretmektir. 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ğılımının doğruluğunu garanti eder.

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

Doğrulama sonuçlarında, blokların hangi çekirdek üzerinde doğrulanacağını belirtmek için bir core selector bulunmaktadır. Doğrulayıcı, bu indeksin kendisinin sorumlu olduğu çekirdek ile tutarlı olup olmadığını kontrol eder; eğer tutarsızsa, bu blok atılacaktır.

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

Güvenlik

Ölçeklenebilirlik peşinde koşarken, Polkadot güvenlikten ödün vermemiştir. Rollup'ın güvenliği, ana zincir tarafından sağlanmaktadır; sadece bir dürüst sıralayıcı canlılığı sürdürebilir.

ELVES protokolü sayesinde, Polkadot güvenliğini tüm rolluplara tamamen genişletir, tüm çekirdek üzerindeki hesaplamaları doğrular, çekirdek sayısına herhangi bir sınırlama 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 ölçekleme, rollup'un programlanabilirliğini sınırlamaz. Polkadot'un rollup modeli, tek bir yürütmenin 2 saniye içinde tamamlanması koşuluyla, WebAssembly ortamında Turing tam hesaplamalarını destekler. Esnek ölçekleme 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 işlem hacmi ve daha düşük gecikme kaçınılmaz olarak karmaşıklığı beraberinde getirir, bu sistem tasarımındaki 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ı gerekliliklerini yerine getirmeleri gerekmektedir.

Belirli 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 bir core miktarı kullanın veya zincir dışı manuel ayarlamalar yapın;

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

• Otomatik strateji: Geçmiş 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.

Eşler arası uyumluluk

Polkadot, farklı rolluplar arasında 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 ( off-chain messaging ) için zincir dışı mesajlaşmayı destekleyecektir, burada kontrol katmanı olarak bir ara zincir, veri katmanı yerine geçecektir. Bu güncelleme, rollup'lar arası iletişim yeteneklerini esnek genişleme ile birlikte artıracak ve sistemin dikey genişleme yeteneklerini daha da güçlendirecektir.

Diğer protokoller hangi dengelemeleri yaptı?

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

Solana

Solana, Polkadot veya Ethereum'un parçalama mimarisini kullanmaz, bunun yerine tek katmanlı yüksek verimlilik mimarisi ile ölçeklenebilirlik sağlamakta, tarihsel kanıt (PoH), CPU paralel işleme ve lider tabanlı konsensüs mekanizmasına dayanmaktadır; teorik TPS 65.000'e kadar ulaşabilir.

Bir temel tasarım, önceden kamuya açık ve doğrulanabilir liderlik zamanlama 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ımı yapı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 kişi yaklaşık %1'lik blok oluşturma şansına sahip olacaktır;

• Tüm blok oluşturucular önceden ilan edildi, bu da ağın hedefli DDoS saldırılarına ve sık sık kesintilere maruz kalma riskini artırdı.

PoH ve paralel işleme, donanım gereksinimlerini son derece yüksek tutar ve bu da doğrulama düğümlerinin merkezileşmesine neden olur. Daha fazla stake edilen düğümlerin blok üretme olasılığı daha yüksektir, 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şı direnç yeteneğini feda etti, Nakamoto katsayısı yalnızca 20, Polkadot'un 172'sinin çok altında.

TON

TON, TPS'nin 104.715'e kadar ulaşabileceğini iddia ediyor, ancak bu rakam özel test ağında, 256 düğüm, 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çıkları bulunmaktadır: parça doğrulayıcılarının kimliği önceden ifşa edilebilir. TON beyaz kitabı da açıkça belirtmektedir ki, bu bant genişliğini optimize etse de, kötüye kullanılma riski taşımaktadır. "Kumarbaz iflası" mekanizmasının eksikliği nedeniyle, saldırganlar belirli bir parçayı tamamen kontrol altına almayı bekleyebilir veya dürüst doğrulayıcıları engellemek için DDoS saldırıları gerçekleştirebilir, bu da durumu değiştirmelerine olanak tanır.

Buna karşılık, Polkadot'un doğrulayıcıları rastgele atanmış ve gecikmeli olarak açıklanmaktadır; saldırganlar doğrulayıcıların kimliğini önceden bilemezler. Saldırı, tüm kontrolü başarıyla ele geçirmeye dayanmak zorundadır. Eğer bir dürüst doğrulayıcı itirazda bulunursa, saldırı başarısız olur ve saldırganın teminatı kaybetmesine yol açar.

Avalanche

Avalanche, ana ağ + yan 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 yan ağ) yönetimi ile oluşur.

Her bir alt ağın teorik TPS'si ~5,000'e ulaşabilir, Polkadot'un mantığı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 konusunda serbestçe seçim yapmasına izin verir ve alt ağlar coğrafi, KYC gibi ek gereksinimler belirleyebilir, bu da merkeziyetsizlik ve güvenlikten feragat eder.

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, bazıları tamamen merkezi hale gelebilir. Güvenliği artırmak istiyorsanız, yine de performansta bir ödün vermeniz gerekecek ve belirleyici bir güvenlik taahhüdü sağlamak zor olacaktır.

Ethereum

Ethereum'in ölçeklenebilirlik stratejisi, temel katmanda doğrudan sorunları çözmek yerine rollup katmanının ölçeklenebilirliğine bahse girmektir. Bu yaklaşım esasen sorunu çözmemekte, sadece sorunu yığının bir üst katmanına aktarmaktadır.

İyimser Rollup

Şu anda çoğu Optimistik rollup merkeziyettir. ( Bazıları sadece bir sıraya koyucuya sahiptir. ) Güvenlik eksikliği, birbirine izole olma, yüksek gecikme ( dolandırıcılık kanıtı süresinin beklenmesi gerekmektedir, genellikle birkaç gün ) gibi sorunlar bulunmaktadır.

ZK Rollup

ZK rollup'un uygulanması, tek bir işlem için işlenebilecek veri miktarıyla sınırlıdır. Sıfır bilgi kanıtı oluşturma hesaplama gereksinimleri çok yüksektir ve "kazanan her şeyi alır" mekanizması sistemin merkezileşmesine neden olabilir. TPS'yi garanti altına almak için, ZK rollup genellikle her işlem grubunun miktarını sınırlar; bu da yüksek talep durumunda ağ tıkanıklığına ve gaz fiyatlarının artmasına neden olabilir, bu da kullanıcı deneyimini etkiler.

Buna karşılık, Turing tamamlayıcı ZK rollup maliyeti, Polkadot'un temel kriptoekonomik güvenlik protokolünün yaklaşık 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, bu da maliyetleri ve kullanıcı ücretlerini daha da artırır.

Sonuç

Ölçeklenebilirliğin sonu, taviz olmamalıdır.

Diğer genel blok zincirlerine kıyasla, Polkadot merkeziyete geçerek performans, önceden belirlenmiş güven ile verimlilik sağlama yoluna girmemiş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 benimsediği "sıfır güven genişletilebilirliği" belki de Web3'ün uzun vadeli gelişimini destekleyebilecek gerçek çözüm olabilir.