Bu yazı, Vitalik abi tarafından yazılan şu makalenin çevirisidir. Mahir Uyan tarafından yazılmıştır.

Blockchain Ölçeklenebilirliğinin Sınırları

Geri bildirim ve inceleme için Felix Lange, Martin Swende, Marius van der Wijden ve Mark Tyneway'e özel teşekkürler.

Bir blok zincirinin ölçeklenebilirliğini ne kadar zorlayabilirsiniz? Gerçekten de Elon Musk'ın istediği gibi, aşırı merkezileşmeye yol açmadan ve bir blok zincirini var eden temel özelliklerden ödün vermeden "blok süresini 10 kat hızlandırabilir, blok boyutunu 10 kat artırabilir ve ücreti 100 kat düşürebilir misiniz?" Düşüremezseniz bile, ne kadar ileri gidebilirsiniz? Konsensus algoritmasını değiştirirseniz ne olur? Daha da önemlisi, teknolojiyi ZK-SNARK'lar veya sharding gibi özellikler getirecek şekilde değiştirirseniz ne olur? Shardlanmış bir blok zinciri teorik olarak daha fazla shard eklemeye devam edebilir; çok fazla shard eklemek diye bir şey var mı? Görünüşe göre, hem sharding ile hem de sharding olmadan blok zinciri ölçeklendirmesini sınırlayan önemli ve oldukça ince teknik faktörler var. Birçok durumda çözümler vardır, ancak çözümlerde bile sınırlar vardır. Bu yazı, bu sorunların çoğunun ne olduğunu ele alacaktır.

Merkeziyetsizlik İçin Kullanıcıların Node Çalıştırabilmesi Kritik:

Saat 02:35'te, dünyanın öbür ucunda mining havuzunuzun (ya da bir stake havuzunun) işletilmesine yardımcı olan ortağınızdan bir acil durum çağrısı alıyorsunuz. Ortağınız size yaklaşık 14 dakika önce havuzunuzun ve diğer birkaç havuzun hala ağın %79'unu taşıyan zincirden ayrıldığını söylüyor. Node’unuza göre, çoğunluk zincirin blokları geçersiz. Bir denge hatası var: anahtar blok hatalı bir şekilde bilinmeyen bir adrese 4,5 milyon ekstra coin atamış gibi görünüyor. Bir saat sonra, diğer iki küçük havuzun yanı sıra bazı blok explorerları ve borsalarldan oluşan bir telegram sohbetindesiniz. Sonunda birinin gruba bir tweet'in bağlantısını attığını görüyorsunuz.  "Yeni zincir içi sürdürülebilir protokol geliştirme fonunu duyuruyoruz" diye başlıyor tweet.

Sabah olduğunda, Twitter'da ve bu tartışmayı sansürlemeyen bir topluluk forumunda, her yerde tartışmalar var. Ancak o zamana kadar 4,5 milyon coinin önemli bir kısmı zincir üstünde diğer varlıklara dönüştürüldü ve milyarlarca dolarlık DeFi işlemi gerçekleştirildi. Konsensüs node'larının %79'u ve tüm büyük blok explorerları ile hafif cüzdan endpoint’leri bu yeni zinciri takip ediyor. Belki yeni geliştirme fonu bazı geliştirmeleri finanse eder, belki de sadece önde gelen havuzlar, borsalar ve yandaşları tarafından zimmete geçirilir. Ama her türlü, bu fon fiilen bir oldu bitti durumudur ve sıradan kullanıcıların karşı koyma şansı yoktur.

Bu Sizin Blokzincirinizde Olabilir mi?

Blokzincir topluluğunuzun elitleri, havuzlar, block explore araçları ve barındırılan node'lar muhtemelen oldukça iyi koordine olmuş durumdadır; büyük ihtimalle hepsi aynı Telegram ve WeChat gruplarında yer alıyordur. Kendi çıkarları doğrultusunda protokol kurallarında ani bir değişiklik yapmaya karar verirlerse, muhtemelen bunu başarabilirler. Ethereum blokzinciri, konsensüs hatalarını 10 saat içinde tamamen çözdü; eğer blokzincirinizin yalnızca bir istemci uygulaması varsa ve yalnızca birkaç düzine node'a kod değişikliği dağıtmanız gerekiyorsa, istemci kodunda bir değişikliği koordine etmek çok daha hızlı yapılabilir. Bu tür koordine edilmiş sosyal saldırıları etkisiz hale getirmenin tek güvenilir yolu, gerçekten merkezi olmayan bir grup olan kullanıcıların pasif savunmasından geçer.

Kullanıcılar zinciri doğrulayan (doğrudan ya da daha gelişmiş dolaylı tekniklerle) ve madencilerin ya da stakerların %90'ından fazlası bu blokları desteklese bile protokol kurallarını ihlal eden blokları otomatik olarak reddeden node’lar çalıştırsaydı hikayenin nasıl sonuçlanacağını bir düşünün. Eğer her kullanıcı bir doğrulama node’u çalıştırsaydı, saldırı hızla başarısız olurdu: birkaç madencilik havuzu ve borsa forklanır ve bu süreçte oldukça aptal görünürdü. Ancak bazı kullanıcılar doğrulama node’ları çalıştırsa bile, saldırı saldırgan için temiz bir zafere yol açmazdı; bunun yerine, farklı kullanıcıların zincirin farklı görünümlerini görmesiyle kaosa yol açardı. En azından, ardından gelen piyasa paniği ve muhtemelen kalıcı zincir bölünmesi saldırganların kârını büyük ölçüde azaltacaktır. Böylesine uzun süreli bir çatışmanın üstesinden gelme düşüncesi bile çoğu saldırıyı caydıracaktır.

Eğer 37 node çalıştıran ve 80000 pasif dinleyiciden oluşan, imzaları kontrol eden ve başlıkları engelleyen bir topluluğunuz varsa, saldırgan kazanır. Eğer herkesin bir node çalıştırdığı bir topluluğunuz varsa, saldırgan kaybeder. Koordineli saldırılara karşı sürü bağışıklığının devreye girdiği eşiğin tam olarak ne olduğunu bilmiyoruz, ancak kesinlikle açık olan bir şey var: daha fazla node iyi, daha az node kötü ve kesinlikle birkaç düzine veya birkaç yüzden fazlasına ihtiyacımız var.

Peki, tam node’ların yapmasını isteyebileceğimiz iş miktarının sınırları nelerdir?

Bir node’u çalıştırabilecek kullanıcı sayısını en üst düzeye çıkarmak için normal tüketici donanımına odaklanacağız. Elde edilmesi kolay (örneğin Amazon'dan) bazı özel donanım satın alımları talep ederek elde edilebilecek bazı kapasite artışları vardır, ancak bunlar aslında ölçeklenebilirliği o kadar da artırmaz.

Bir node'un büyük miktarda işlemi işlemesini sınırlayan üç temel faktör vardır:

Hesaplama gücü: Bir node çalıştırmak için bir CPU’nun % kaçını güvenle talep edebiliriz?

Bant genişliği: Mevcut internet bağlantılarının gerçekleri göz önüne alındığında, bir blok kaç bayt içerebilir?

Depolama: Kullanıcılardan disk üzerinde kaç gigabayt depolamalarını isteyebiliriz? Ayrıca, ne kadar hızlı okunabilir olmalı? (örnğin HDD mi yoksa SSD'ye mi ihtiyacımız var?)

Bir blok zincirinin "basit" teknikler kullanılarak ne kadar ölçeklendirilebileceğine dair birçok hatalı yaklaşım, bu sayıların her biri için aşırı iyimser tahminlerden kaynaklanmaktadır. Bu üç faktörü teker teker ele alabiliriz:

Hesaplama Gücü:

Kötü cevap: CPU gücünün %100'ü blok doğrulama için harcanabilir.

Doğru cevap: CPU gücünün ~%5-10'u blok doğrulama için harcanabilir.

Sınırın bu kadar düşük olmasının dört temel nedeni vardır:

•DoS saldırıları (koddaki zayıflıklardan yararlanmak için bir saldırgan tarafından hazırlanan ve normal işlemlerden daha uzun süren işlemler) olasılığını karşılamak için bir güvenlik marjına ihtiyacımız var.

•Nodeların çevrimdışı olduktan sonra zinciri senkronize edebilmesi gerekir. Ağdan bir dakikalığına ayrılırsam, birkaç saniye içinde yetişebilmeliyim.

•Bir node’u çalıştırmak pilinizi çok hızlı tüketmemeli ve diğer tüm uygulamalarınızı çok yavaşlatmamalıdır.

•Nodeların yapması gereken başka blok üretimi dışı görevler de vardır, çoğunlukla p2p ağında gelen işlemleri ve istekleri doğrulamak ve yanıtlamakla ilgilidir.

Yakın zamana kadar, "neden yalnızca %5-10?" sorusuna getirilen açıklamaların çoğunun farklı bir soruna odaklandığını unutmayın: PoW blokları rastgele zamanlarda geldiği için, blokları doğrulamanın uzun sürmesi aynı anda birden fazla blok oluşturulması riskini artırır. Bu soruna yönelik birçok çözüm bulunmaktadır (örneğin Bitcoin NG ya da sadece proof of stake kullanımı). Ancak bu düzeltmeler diğer dört sorunu çözmez ve bu nedenle ölçeklenebilirlikte başlangıçta düşünüldüğü gibi büyük kazançlar sağlamaz. Paralellik de sihirli bir kurşun değildir. Genellikle, görünüşte tek iş parçacıklı blok zincirlerinin istemcileri bile zaten paralelleştirilmiştir: imzalar bir iş parçacığı tarafından doğrulanabilirken, yürütme diğer iş parçacıkları tarafından yapılır ve arka planda işlem havuzu mantığını işleyen ayrı bir iş parçacığı vardır. Ve tüm iş parçacıklarında %100 kullanıma yaklaştıkça, bir node’u çalıştırmak daha fazla enerji tüketir ve DoS'a karşı güvenlik marjınız azalır.

Bant Genişliği:

Kötü cevap: Her 2-3 saniyede bir 10 MB'lık bloklarımız varsa, çoğu kullanıcı >10 MB/sn ağa sahiptir, bu nedenle elbette bunu kaldırabilirler.

Doğru cevap: belki her 12 saniyede 1-5 MB'lık bloklarla başa çıkabiliriz. Yine de zor.

Günümüzde internet bağlantılarının ne kadar bant genişliği sunabileceğine dair çok yüksek reklam istatistiklerini sık sık duyuyoruz: 100 Mbps ve hatta 1 Gbps gibi rakamları duymak yaygındır. Ancak, reklamı yapılan bant genişliği ile bir bağlantının beklenen gerçek bant genişliği arasında çeşitli nedenlerden dolayı büyük bir fark vardır:

"Mbps" "saniyede milyonlarca bit" anlamına gelir; bir bit bir baytın 1/8'idir, bu nedenle reklamı yapılan bayt sayılarını elde etmek için reklamı yapılan bit sayılarını 8'e bölmelisiniz.

İnternet sağlayıcıları, tıpkı tüm şirketler gibi, genellikle yalan söyler.

Her zaman aynı internet bağlantısını kullanan birden fazla uygulama vardır, bu nedenle bir node tüm bant genişliğini kullanamaz.

p2p ağları kaçınılmaz olarak kendi ek yüklerini getirir: node’lar genellikle aynı bloğu birden çok kez indirir ve yeniden yükler (işlemlerin bir bloğa dahil edilmeden önce mempool üzerinden yayınlanmasından bahsetmeye gerek yok).

2019'da Starkware, işlem veri gazı maliyetinin düşürülmesinin ardından 500 kB'lık blokları ilk kez yayınladığı bir deney yaptığında, birkaç node bu boyuttaki blokları işleyemedi. Büyük blokları işleme yeteneği o zamandan beri geliştirildi ve geliştirilmeye devam edecek. Ancak ne yaparsak yapalım, MB/sn cinsinden ortalama bant genişliğini safça alıp, kendimizi 1sn gecikmeyle sorunumuz olmadığına ikna etmekten ve bu boyutta bloklara sahip olmaktan hala çok uzak olacağız.

Depolama :

Kötü cevap: 10 terabayt.

Doğru cevap: 512 gigabayt.

Buradaki ana argüman, tahmin edebileceğiniz gibi, başka yerlerdekiyle aynı: teori ve pratik arasındaki fark. Teoride, Amazon'dan satın alabileceğiniz 8 TB katı hal sürücüleri var (SSD'lere veya NVME'ye ihtiyacınız var; HDD'ler blok zinciri durumunu depolamak için çok yavaş). Pratikte, bu blog yazısını yazmak için kullanılan dizüstü bilgisayarda 512 GB var ve insanların kendi donanımlarını satın almalarını sağlarsanız, birçoğu tembelleşecek (ya da 8 TB SSD için 800 doları karşılayamayacaklar) ve merkezi bir sağlayıcı kullanacaklardır. Ve bir blok zincirini bir miktar depolama alanına sığdırabilseniz bile, yüksek düzeyde bir etkinlik diski kolayca yakabilir ve sizi sürekli yeni bir tane almaya zorlayabilir.

Ayrıca, depolama boyutu yeni bir node’un çevrimiçi olabilmesi ve ağa katılmaya başlayabilmesi için gereken süreyi belirler. Mevcut node’ların depolamak zorunda olduğu veriler, yeni bir node’un indirmek zorunda olduğu verilerdir. Bu ilk senkronizasyon süresi (ve bant genişliği) aynı zamanda kullanıcıların node’ları çalıştırabilmesinin önündeki en büyük engeldir. Bu blog yazısını yazarken, yeni bir geth node’unu senkronize etmek yaklaşık15 saatimi aldı. Ethereum 10 kat daha fazla kullanılıyor olsaydı, yeni bir geth node’unu senkronize etmek en az bir hafta sürerdi ve internet bağlantınızın yavaşlamasına neden olma olasılığı çok daha yüksek olurdu. Tüm bunlar, bir saldırı sırasında daha da önemlidir; çünkü saldırıya başarılı bir yanıt vermek, muhtemelen daha önce node çalıştırmayan birçok kullanıcının yeni node’lar oluşturmasını gerektirecektir.

Etkileşim etkileri:

Ayrıca, bu üç maliyet türü arasında etkileşim etkileri de vardır. Veritabanları verileri depolamak ve almak için dahili olarak ağaç yapıları kullandığından, bir veritabanından veri getirmenin maliyeti veritabanının boyutunun logaritması ile artar. Aslında, en üst düzey (veya en üst birkaç düzey) RAM'de önbelleğe alınabildiğinden, disk erişim maliyeti RAM'de önbelleğe alınan verilerin boyutunun bir katı olarak veritabanının boyutuyla orantılıdır.

Örneğin, önbellek 4 GB ise ve veritabanının her katmanının bir öncekinden 4 kat daha büyük olduğunu varsayarsak, Ethereum'un mevcut 64 GB durumu 2 erişim gerektirecektir. Ancak durum boyutu 4 kat artarak 256 GB'a çıkarsa, bu 3 erişime çıkacaktır (yani okuma başına 1,5 kat daha fazla erişim). Dolayısıyla, hem durum boyutunu hem de okuma sayısını artıracak olan gaz limitindeki 4 kat artış, aslında blok doğrulama süresinde 6 kat artışa dönüşebilir. Bu etki daha da güçlü olabilir: sabit disklerin doluyken okunması ve yazılması, neredeyse boşken olduğundan daha uzun sürer.

Peki, Ethereum için Ne Anlama Geliyor?

Bugün Ethereum blok zincirinde, bir node çalıştırmak birçok kullanıcı için zaten zor olsa da, en azından normal donanımlarda hala mümkün (bu yazıyı yazarken dizüstü bilgisayarımda bir node’u senkronize ettim!). Dolayısıyla, darboğazlara girmeye çok yakınız. Core Developerların en çok endişe duyduğu konu depolama boyutudur. Bu nedenle, şu anda, hesaplama ve verideki darboğazları çözmeye yönelik cesur çabaların ve hatta konsensüs algoritmasındaki değişikliklerin, büyük gaz limiti artışlarının kabul edilmesine yol açması pek olası değildir. Ethereum'un göze çarpan en büyük DoS güvenlik açığının çözülmesi bile yalnızca %20'lik bir gaz limiti artışına yol açmıştır.

Depolama boyutu sorunlarının tek çözümü durumsuzluk ve durum süresinin dolmasıdır. Durumsuzluk, kalıcı depolama sağlamadan zinciri doğrulayan bir node sınıfına izin verir. Durum sona ermesi, yakın zamanda erişilmemiş olan durumu dışarı iter ve kullanıcıları yenilemek için manuel olarak kanıt sağlamaya zorlar. Bu yolların her ikisi üzerinde de uzun süredir çalışılıyor ve durumsuzluk konusunda kavram kanıtı uygulaması çoktan başladı. Bu iki iyileştirme bir araya geldiğinde bu endişeleri büyük ölçüde hafifletebilir ve önemli bir gaz limiti artışı için alan açabilir. Ancak durumsuzluk ve durum sona ermesi uygulandıktan sonra bile, diğer sınırlamalar baskın olmaya başlayana kadar gaz limitleri güvenli bir şekilde yalnızca belki yaklaşık 3 kat artabilir.

Bir diğer olası orta vadeli çözüm ise işlemleri doğrulamak için ZK-SNARK'ların kullanılmasıdır. ZK-SNARK'lar, normal kullanıcıların durumu kişisel olarak depolamak veya blokları doğrulamak zorunda kalmamalarını sağlayacaktır, ancak veri kullanılamazlığı saldırılarına karşı koruma sağlamak için bloklardaki tüm verileri indirmeleri gerekecektir. Ayrıca, saldırganlar geçersiz blokları zorla geçiremese bile, kapasite bir konsensüs node’unu çalıştırmanın çok zor olduğu noktaya kadar artırılırsa, koordineli sansür saldırıları riski hala vardır. Dolayısıyla, ZK-SNARK'lar kapasiteyi sonsuza kadar artıramazlar, ancak yine de kapasiteyi önemli bir marjla (belki 1-2 büyüklük mertebesi) artırabilirler. Bazı zincirler bu yaklaşımı 1. katmanda araştırmaktadır; Ethereum bu yaklaşımın faydalarını zksync, Loopring ve Starknet gibi layer-2 protokolleri (ZK rollup'ları olarak adlandırılır) aracılığıyla elde etmektedir.

Sharding’den sonra ne olur?

Sharding temel olarak yukarıdaki sınırlamaları aşar, çünkü bir blok zincirinde bulunan verileri tek bir node’un işlemesi ve depolaması gereken verilerden ayırır. Node’lar blokları kişisel olarak indirip çalıştırarak doğrulamak yerine, blokları dolaylı olarak doğrulamak için gelişmiş matematiksel ve kriptografik teknikler kullanırlar. Sonuç olarak, shardlanmış blok zincirleri, shardlanmamış blok zincirlerinin yapamayacağı çok yüksek işlem hacmine güvenli bir şekilde sahip olabilir. Bu, geçersiz blokları başarılı bir şekilde reddeden naif tam doğrulama için verimli aalternatifler yaratmada çok fazla kriptografik zeka gerektirir, ancak yapılabilir: teori iyi bir şekilde oluşturulmuştur ve taslak şartnamelere dayalı kavramların kanıtı üzerinde zaten çalışılmaktadır.

Ethereum, toplam ölçeklenebilirliğin bir node’un hem tek bir shardı hem de her shard için sabit miktarda yönetim işi gerçekleştirmesi gereken işaret zincirini işleyebilmesi gerektiği gerçeğiyle sınırlı olduğu kuadratik sharding kullanmayı planlamaktadır. Shard’lar çok büyükse, node’lar artık tek tek shard’ları işleyemez ve çok fazla shard varsa, node’lar artık işaret zincirini işleyemez. Bu iki kısıtlamanın çarpımı üst sınırı oluşturur. Muhtemelen, kübik sharding veya hatta üstel sharding yaparak daha da ileri gidilebilir. Veri kullanılabilirliği örneklemesi böyle bir tasarımda kesinlikle çok daha karmaşık hale gelecektir, ancak yapılabilir. Ancak Ethereum kuadratik sharding’den ileri gitmiyor. Bunun nedeni, işlem shard’larından işlem shard’larına geçerek elde ettiğiniz ekstra ölçeklenebilirlik kazanımlarının, diğer riskler kabul edilemeyecek kadar yüksek hale gelmeden gerçekleştirilememesidir. Peki bu riskler nelerdir?

Minimum kullanıcı sayısı:

Shardlanmamış bir blok zinciri, ona katılmak isteyen tek bir kullanıcı bile olduğu sürece çalışabilir. Shardlanmış blok zincirleri böyle değildir: hiçbir node tüm zinciri işleyemez ve bu nedenle en azından zinciri birlikte işleyebilmeleri için yeterli sayıda node’a ihtiyacınız vardır. Her bir node 50 TPS işleyebiliyorsa ve zincir 10000 TPS işleyebiliyorsa, zincirin hayatta kalabilmesi için en az 200 node’a ihtiyacı vardır. Zincir herhangi bir noktada 200 node’un altına düşerse, node’lar zincire ayak uydurmayı bırakır ya da node’lar  geçersiz blokları tespit etmeyi bırakır ya da node  yazılımının nasıl kurulduğuna bağlı olarak bir dizi başka kötü şey olabilir.

Pratikte, güvenli minimum sayı, fazlalık ihtiyacı nedeniyle (veri kullanılabilirliği örneklemesi dahil) saf "zincir TPS/ node TPS" sezgiselinden birkaç kat daha yüksektir; yukarıdaki örneğimiz için buna 1000 node diyelim. Shardlanmış bir blok zincirinin kapasitesi 10 kat artarsa, minimum kullanıcı sayısı da 10 kat artar. Şimdi şu soruyu sorabilirsiniz: Neden az bir kapasiteyle başlamıyoruz ve bunu yalnızca çok sayıda kullanıcı gördüğümüzde artırmıyoruz, böylece gerçekten ihtiyacımız oluyor ve kullanıcı sayısı azalırsa azaltmıyoruz?

Bununla ilgili birkaç sorun vardır:

Bir blok zincirinin kendisi, üzerinde kaç benzersiz kullanıcı olduğunu güvenilir bir şekilde tespit edemez ve bu nedenle bu, shard sayısını tespit etmek ve ayarlamak için bir tür yönetişim gerektirir. Kapasite sınırları üzerindeki yönetim kolayca bir bölünme ve çatışma odağı haline gelebilir. Ya birçok kullanıcı aniden ve beklenmedik bir şekilde aynı anda ayrılırsa? Bir çatallanmanın başlaması için gereken minimum kullanıcı sayısını artırmak, düşmanca ele geçirmelere karşı savunmayı zorlaştırır.

Minimum kullanıcı sayısının 1.000'in altında olması neredeyse kesinlikle iyidir. Öte yandan, minimum kullanıcı sayısının 1 milyon olması kesinlikle uygun değildir. Minimum 10.000 kullanıcı sayısı bile tartışmalı bir şekilde riskli olmaya başlıyor. Bu nedenle, birkaç yüzden fazla shard’a sahip shard’lı bir blok zincirini haklı çıkarmak zor görünmektedir.

Geçmişin Geri Alınabilirliği:

Kullanıcıların gerçekten değer verdiği bir blok zincirinin önemli bir özelliği kalıcılıktır. Bir sunucuda saklanan dijital bir varlık, şirket iflas ettiğinde veya bu ekosistemi sürdürmeye olan ilgisini kaybettiğinde 10 yıl içinde var olmayı bırakacaktır. Öte yandan Ethereum üzerindeki bir NFT sonsuza dek kalıcıdır.

Ancak bir blok zincirinin kapasitesi çok yükseldiğinde, tüm bu verileri saklamak zorlaşır, ta ki bir noktada tarihin bir kısmının hiç kimse tarafından saklanmaması gibi büyük bir risk ortaya çıkana kadar. Bu riski ölçmek kolaydır. Blok zincirinin veri kapasitesini MB/sn cinsinden alın ve yıllık terabayt cinsinden depolanan veri miktarını elde etmek için 30 ile çarpın. Mevcut sharding planının veri kapasitesi 1,3 MB/sn, yani yaklaşık 40 TB/yıl'dır. Bu 10 kat artırılırsa 400 TB/yıl olur. Verilerin sadece erişilebilir değil, aynı zamanda kolay erişilebilir olmasını istiyorsak, meta verilere de ihtiyacımız olacaktır (örneğin, rollup işlemlerinin sıkıştırmasını açma), bu nedenle bunu yılda 4 petabayt veya on yıl sonra 40 petabayt yaparız. İnternet Arşivi 50 petabayt kullanıyor. Yani bu, shardlanmış bir blok zincirinin güvenli bir şekilde ne kadar büyük olabileceğine dair makul bir üst sınırdır. Dolayısıyla, bu boyutların her ikisinde de Ethereum sharding tasarımı aslında kabaca makul maksimum güvenli değerlere oldukça yakın bir şekilde hedeflenmiş gibi görünüyor. Sabit değerler biraz artırılabilir, ancak çok fazla değil.

Özet:

Bir blok zincirini ölçeklendirmeye çalışmanın iki yolu vardır: temel teknik iyileştirmeler ve sadece parametreleri artırmak. Parametreleri artırmak ilk başta kulağa çok cazip geliyor: bir peçete üzerinde hesap yaparsanız, kendinizi bir tüketici dizüstü bilgisayarının saniyede binlerce işlemi işleyebileceğine ikna etmek kolaydır, ZK-SNARK'lar veya rollup'lar veya sharding gerekmez. Ne yazık ki, bu yaklaşımın temelde kusurlu olmasının birçok ince nedeni vardır.

Blok zinciri node’larını çalıştıran bilgisayarlar CPU gücünün %100'ünü zinciri doğrulamak için harcayamaz; beklenmedik DoS saldırılarına karşı koymak için büyük bir güvenlik marjına ihtiyaç duyarlar, mempool'daki işlemleri işlemek gibi görevler için yedek kapasiteye ihtiyaç duyarlar ve bir bilgisayarda bir node çalıştırmanın o bilgisayarı aynı anda başka herhangi bir uygulama için kullanılamaz hale getirmesini istemezsiniz. Bant genişliğinin de benzer şekilde ek yükü vardır: 10 MB/sn'lik bir bağlantı, her saniye 10 megabaytlık bir blok alabileceğiniz anlamına gelmez! Belki her 12 saniyede bir 1-5 megabaytlık bir blok. Depolama için de durum aynıdır. Bir node çalıştırmak için donanım gereksinimlerini artırmak ve node çalıştırmayı uzman aktörlerle sınırlamak bir çözüm değildir. Bir blok zincirinin merkezi olmaması için, sıradan kullanıcıların bir node çalıştırabilmesi ve node çalıştırmanın ortak bir faaliyet olduğu bir kültüre sahip olması çok önemlidir.

Öte yandan temel teknik iyileştirmeler işe yarayabilir. Şu anda Ethereum'daki ana darboğaz depolama boyutudur. Durumsuzluk ve durum sona ermesi bunu düzeltebilir ve belki 3 kata kadar bir artışa izin verebilir - ancak daha fazla değil, çünkü bir node’u çalıştırmanın bugün olduğundan daha kolay olmasını istiyoruz. Shardlanmış blok zincirleri çok daha fazla ölçeklenebilir, çünkü shardlanmış bir blok zincirindeki tek bir node’un her işlemi işlemesi gerekmez. Ancak orada bile kapasitenin sınırları vardır: kapasite arttıkça minimum güvenli kullanıcı sayısı artar ve zinciri arşivlemenin maliyeti (ve kimse zinciri arşivlemeye zahmet etmezse verilerin kaybolma riski) artar. Ancak çok fazla endişelenmemize gerek yok: bu sınırlar, muhtemelen bir blok zincirinin tam güvenliğiyle saniyede bir milyondan fazla işlemi işleyebileceğimiz kadar yüksektir. Ancak bunu, blok zincirlerini bu kadar değerli kılan ademi merkeziyetçilikten ödün vermeden yapmak için çalışmak gerekecek.