“Modüler blok zinciri” fikri, ölçeklenebilirlik ve blok zinciri altyapısı etrafında kategori tanımlayan bir anlatı haline geliyor.

‍Varsayım oldukça basit: Katman 1 blok zincirinin temel bileşenlerini ayrıştırarak, bireysel katmanlarda 100 kat iyileştirme yapabiliriz, bu da daha ölçeklenebilir, birleştirilebilir ve merkezi olmayan bir sistemle sonuçlanır. Modüler blok zincirlerini uzun uzadıya tartışmadan önce, mevcut blok zinciri mimarisini ve blok zincirlerinin mevcut uygulamalarıyla karşılaştığı sınırlamaları anlamalıyız.

Kısaca blokzincir temellerini özetleyelim. Blok zincirindeki bloklar iki bileşenden oluşur: blok başlığı ve bu başlıkla ilişkili işlem verileri. Bloklar, işlemlerin geçerli olması için örneğin kullanıcıların hesap bakiyelerinden daha fazla ether göndermediğinden emin olmak için tüm blok verilerini ayrıştıran ve hesaplayan "tam düğümler"(full nodes) aracılığıyla doğrulanır.

Ayrıca bir blok zinciri oluşturan fonksyonellik “katmanlarını” da kısaca özetleyelim.

Uygulama (Execution) İşlemler ve durum değişiklikleri(state changes) başlangıçta burada işlenir. Kullanıcılar ayrıca işlemleri imzalayarak, akıllı sözleşmeleri dağıtarak(deploy) ve varlıkları aktararak blok zinciri ile tipik olarak bu katman aracılığıyla etkileşime girer. ‍

Anlaşma(Settlement) Uzlaşma katmanı, rollupların yürütülmesinin doğrulandığı ve anlaşmazlıkların çözüldüğü yerdir. Bu katman monolitik zincirlerde mevcut değildir ve modüler yığının isteğe bağlı bir parçasıdır. ABD mahkeme sistemine benzer bir şekilde, Anlaşma katmanını, anlaşmazlıklar üzerinde nihai tahkim sağlayan ABD Yüksek Mahkemesi olarak düşünün.

Uzlaşma(Consensus) Blok zincirlerinin konsensüs katmanı, blokların içeriğini indiren ve yürüten ve durum geçişlerinin geçerliliği konusunda fikir birliğine varan tam düğümler ağı aracılığıyla sıralama ve kesinlik sağlar. ‍

Veri kullanılabilirliği(Data Availability) Bir durum geçişinin(state transition) geçerli olduğunu doğrulamak için gereken veriler bu katmanda yayınlanmalı ve saklanmalıdır. Bu, kötü niyetli blok üreticilerinin işlem verilerini sakladığı saldırılar durumunda kolayca doğrulanabilir olmalıdır. Veri kullanılabilirliği katmanı, blok zinciri ölçeklenebilirlik üçlemi için ana darboğazdır, nedenini daha sonra keşfedeceğiz.

Örneğin Ethereum monolitiktir, yani temel katman yukarıda bahsedilen tüm bileşenleri yönetir.

Blokzincirler şu anda “Blokzincir Ölçeklenebilirlik Üçlemesi” adı verilen bir sorunla karşı karşıya. Brewer'ın dağıtık sistemler teoremine benzer şekilde, blok zinciri mimarisi tipik olarak diğer ikisi için güçlü garantiler sağlamak için merkeziyetsizlik, güvenlik veya ölçeklenebilirlikten ödün verir.

‍

Güvenlik, ağın saldırı altında çalışabilme yeteneğini ifade eder. Bu ilke, blok zincirlerinin temel bir ilkesidir ve asla taviz verilmemelidir, bu nedenle gerçek hesaplaşma genellikle ölçeklenebilirlik ve merkeziyetsizlik arasındadır.

Merkeziyetsizliği blok zinciri sistemleri bağlamında tanımlayalım: Bir blok zincirinin merkeziyetsiz olması için, donanım gereksinimleri katılım için bir sınırlama olmamalı ve ağın doğrulanması için kaynak gereksinimleri düşük olmalıdır.

Ölçeklenebilirlik, bir blok zincirinin veriminin, doğrulama maliyetine bölünmesi anlamına gelir: yani bir blok zincirinin, doğrulama için kaynak gereksinimlerini düşük tutarken artan miktarda işlemi işleme yeteneğidir. Verimi artırmanın iki ana yolu vardır. İlk olarak, blok boyutunu ve dolayısıyla bir bloğa dahil edilebilecek işlemlerin kapasitesini artırabilirsiniz. Ne yazık ki, daha büyük blok boyutları, daha yüksek hesaplama çıktısı ihtiyacına yanıt olarak tam düğümleri çalıştırmanın donanım gereksinimleri arttıkça ağın merkezileşmesiyle sonuçlanır. Özellikle monolitik blok zincirleri, verimdeki bir artış, zinciri doğrulama maliyetindeki bir artışla ilişkili olduğundan ve daha az merkeziyetsizlikle sonuçlandığından bu sorunla karşılaşır. İkinci olarak, zincir üzerinde hesaplamanın doğrulanmasına izin veren kanıtları kullanırken hesaplama yükünü ana ağdaki düğümlerden uzaklaştırarak yürütmeyi(execution) zincir dışına taşıyabilirsiniz.

‍Modüler bir mimari ile blok zincirlerinin, meselelerin ayrılması ilkesi ile blok zinciri ölçeklenebilirlik üçlemesini çözmeye başlaması mümkündür. Modüler bir yürütme(execution) ve veri kullanılabilirlik(data availability) katmanı aracılığıyla, blok zincirler, hesaplama ve doğrulama maliyeti arasındaki korelasyonu kırarak ağı güven gerektirmez(trustless) ve merkeziyetsiz hale getiren özellikleri korurken aynı zamanda verimi ölçekleyebilir. Hata kanıtlarını(fault proofs), rollupları ve bunların Veri Kullanılabilirliği sorunuyla nasıl ilişkili olduğunu tanıtarak bunun nasıl mümkün olduğunu keşfedelim.

Vitalik, Endgame'de, merkezilik ve merkeziyetsizlik arasında olası bir uzlaşmanın, blok üretiminin geleceğinin ölçeklenebilirlik amacıyla havuzlara ve uzman üreticilere merkezileşmesi ve blok doğrulamanın (üreticileri dürüst tutarak) önemli ölçüde merkeziyetsiz kalması gerektiğini belirtiyor. Bu, blok zinciri düğümlerini tam düğümlere(full nodes) ve hafif istemcilere(light clients) bölerek elde edilebilir. Bu modelin ilgili olduğu iki sorun vardır: blok doğrulama (hesaplamanın doğruluğunu doğrulama) ve blok kullanılabilirliği (tüm verilerin yayınlandığını doğrulama). Önce blok doğrulamadaki uygulamasını inceleyelim.

Tam düğümler bloktaki her işlemi indirir, hesaplar ve doğrularken, hafif istemciler yalnızca blok başlıklarını indirir ve işlemlerin geçerli olduğunu varsayar. Hafif istemciler daha sonra işlem doğrulaması için tam düğümler tarafından oluşturulan hata kanıtlarına güvenir. Bu da, hafif istemcilerin geçersiz işlemleri özerk bir şekilde tanımlamasına ve tam bir düğümle neredeyse aynı güvenlik garantileri altında çalışmasına olanak tanır. Varsayılan olarak, hafif istemciler durum geçişlerinin geçerli olduğunu varsayar ve hata kanıtları alarak durumların geçerliliğine itiraz edebilir.

Bir düğümün durumu bir hata kanıtıyla sorgulandığında, ilgili işlemleri yeniden yürüten tam bir düğüm aracılığıyla fikir birliği sağlanır ve bu da dürüst olmayan düğümün hissesinin kesilmesiyle(slash) sonuçlanır.

Hafif istemciler ve hataya dayanıklı(fault proof) model, zincirin tam durumu(full state) ile hata kanıtı sunan en az bir dürüst tam düğümün bulunduğu dürüst azınlık varsayımı altında güvenlidir. Doğrulayıcılar, tüm parçalarda(shardlarda) 1/N güvenlik garantisini korurken, bir parçada tam bir düğüm çalıştırmayı ve geri kalanında hafif istemcileri çalıştırmayı seçebildiğinden, bu model özellikle parçalanmış blok zincirleri(sharded blockchains) (Ethereum'un birleştirme sonrası mimarisi gibi) için geçerlidir.

Optimistik Rolluplar, blok zinciri yürütme katmanını sıralayıcılara(sequencers), birden fazla işlemi bir araya getiren ve yürüten ve sıkıştırılmış verileri periyodik olarak ana zincire geri gönderen güçlü bilgisayarlara güvenli bir şekilde soyutlamak için bu modeli kullanır. Bu hesaplamayı zincir dışına kaydırmak (ana zincire göre), işlem veriminde 10-100 kat artışa izin verir. Bu zincir dışı sıralayıcıların(sequencer) iyi huylu kalacağına nasıl güvenebiliriz? Operatörlerin bir sıralayıcıyı çalıştırmak için kilitlemesi(stake) gereken tokenleri, sunarız. Sıralayıcılar, işlem verilerini ana zincire geri gönderdiğinden, daha sonra, hata kanıtları yayınlamak ve ardından kötü niyetli sıralayıcıların payını kesmek için bir üst zincir ile rollupı arasındaki durum uyumsuzluklarını izleyen düğümler olan doğrulayıcıları(verifier) kullanabiliriz. Optimistik rolluplar hata kanıtlarını kullandığından, ağda tek bir dürüst doğrulayıcının var olduğu varsayımı altında güvenlidirler. Hata kanıtlarının bu kullanımı, optimistik rollupların adlarını türettikleri yerdir - durum geçişlerinin, uzlaşma katmanında ele alınan bir anlaşmazlık döneminde (dispute period) aksi kanıtlanana kadar geçerli olduğu varsayılır.

Güveni en aza indirirken verimi bu şekilde ölçekleyebiliriz: Hesaplamanın doğrulamasını merkeziyetsiz tutarken hesaplamanın merkezileşmesine göz yumun.

Hata kanıtı, merkeziyetsiz blok doğrulamasını çözmek için kullanışlı bir araç olsa da, tam düğümler, hata kanıtı oluşturmak için blok kullanılabilirliğine(block availability) bağlıdır. Kötü niyetli bir blok üreticisi, yalnızca blok başlıklarını yayınlamayı ve karşılık gelen verilerin bir kısmını veya tamamını saklamayı seçebilir, bu da tam düğümlerin geçersiz işlemleri doğrulamasını ve tanımlamasını ve böylece hata kanıtı oluşturmasını engeller. Bu tür bir saldırı, tüm bloğu basitçe indirebildikleri ve tutarsızlıkları veya saklanan verileri fark ettiklerinde geçersiz zincirden uzaklaşabildikleri(fork) için tam düğümlerin fark etmesi için önemsizdir. Bununla birlikte, hafif istemciler, tam düğümlerden uzaklaşarak, potansiyel olarak geçersiz bir zincirin başlıklarını izlemeye devam edecektir. (Hafif istemcilerin tüm bloğu indirmediğini ve durum geçişlerinin(state transitions) varsayılan olarak geçerli olduğunu varsaydığını unutmayın.)

Bu, hata kanıtlarıyla ilgili olduğu için veri kullanılabilirliği sorununun özüdür: hafif istemciler, doğrulamadan önce tüm işlem verilerinin bir blokta serbest bırakıldığından emin olmalıdır, öyle ki, tam düğümler ve hafif istemciler, kurallı zincir için aynı başlık üzerinde otomatik olarak anlaşmalıdır. (Veri mevcudiyeti için hata kanıtlama için neden benzer bir sistem kullanamadığımızı merak ediyorsanız, veri stopajı ikilemini burada derinlemesine okuyabilirsiniz. Esasen oyun teorisi, burada kullanılan hataya dayalı bir sistemin istismar edileceğini ve dürüst oyuncular için kaybet-kaybet durumuyla sonuçlanacağını belirtir.)

İlk kareye döndük gibi görünebilir. Hafif istemciler, donanım gereksinimlerini merkezileştirerek ve böylece hafif istemcilerin amacını ortadan kaldırarak tüm bloğu indirmek zorunda kalmadan bir bloktaki tüm işlem verilerinin serbest bırakılmasını nasıl sağlayabilir?

Bunu başarmanın bir yolu, silme kodlaması(erasure coding) adı verilen matematiksel bir ilkeldir. Bir bloktaki baytları çoğaltarak, silme kodlaması, verilerin belli bir yüzdesi kaybolsa bile tüm bloğun yeniden oluşturulmasını sağlar. Bu teknoloji, veri kullanılabilirliği örneklemesi gerçekleştirmek için kullanılır ve hafif istemcilerin, bloğun küçük kısımlarını rastgele örnekleyerek yayınlanan bir bloğun tamamını olasılıksal olarak belirlemesine olanak tanır. Bu, hafif istemcilerin, geçerli olarak kabul etmeden ve ilgili blok başlığını takip etmeden önce tüm işlem verilerinin belirli bir bloğa dahil edilmesini sağlar. Bununla birlikte, bu teknik için birkaç uyarı vardır: veri kullanılabilirliği örneklemesi yüksek gecikme süresine sahiptir ve dürüst azınlık varsayımına benzer şekilde, güvenlik garantisi, bir bloğun kullanılabilirliğini olasılıksal olarak belirleyebilmek için örnekleme gerçekleştiren yeterli hafif istemcilerin olduğu varsayımına dayanır.

Merkeziyetsiz blok doğrulama için başka bir çözüm, durum geçişleri için işlem verilerine ihtiyaç duymayı ortadan kaldırmaktır. Geçerlilik kanıtları, aksine, hata kanıtlarına kıyasla daha pesimistik bir bakış açısına sahiptir. Uyuşmazlık sürecini ortadan kaldırarak, geçerlilik kanıtları, her bir durum geçişi için bir kanıt gerektirme dengesiyle tüm durum geçişlerinin atomikliğini(atomicity) garanti edebilir. Bu, yeni sıfır bilgi teknolojileri SNARK'lar ve STARK'lar kullanılarak gerçekleştirilir. Hata kanıtlarıyla karşılaştırıldığında, geçerlilik kanıtları, daha güçlü durum garantileri karşılığında daha fazla hesaplama yoğunluğu gerektirir ve ölçeklenebilirliği etkiler.

Sıfır Bilgi Rollupları, durum doğrulaması için hata kanıtları yerine geçerlilik kanıtlarını kullanan rolluplardır. Sıralayıcıların hesaplamayı ele aldığı ve doğrulayıcıların karşılık gelen kanıtları oluşturduğu bir sıralayıcı/doğrulayıcı modeli aracılığıyla optimistik rolluplar olarak (hata kanıtları yerine şema olarak geçerlilik kanıtlarıyla da olsa) benzer bir hesaplama ve doğrulama modelini takip ederler.Örneğin Starknet, önyükleme amacıyla merkezi sıralayıcılarla başlatıldı ve yol haritasında açık sıralayıcıların ve kanıtlayıcıların aşamalı olarak merkeziyetsizleştirilmesine sahiptir. Sıralayıcılarda zincir dışı yürütme nedeniyle hesaplamaların kendileri ZK rolluplarında sınırsızdır. Bununla birlikte, bu hesaplamalar için kanıtların zincir üzerinde doğrulanması gerektiğinden, kesinlik(finality) hala kanıt oluşturma tarafından darboğazdadır.

Durum doğrulaması için hafif istemcileri kullanma tekniğinin yalnızca hataya dayanıklı mimariyle ilgili olduğunu belirtmek önemlidir. Durum geçişlerinin geçerlilik kanıtlarıyla geçerli olması garanti edildiğinden, düğümlerin blokları doğrulaması için artık işlem verilerine gerek yoktur. Bununla birlikte, geçerlilik kanıtları için veri kullanılabilirliği sorunu hala mevcuttur ve biraz daha belirsizdir: garantili duruma rağmen, geçerlilik kanıtları için işlem verileri hala gereklidir, öyle ki düğümler son kullanıcılara durum geçişlerini güncelleyebilir ve sunabilir. Bu nedenle, geçerlilik kanıtlarını kullanan rolluplarda hala veri kullanılabilirliği sorunu vardır.

Vitalik'in tezini hatırlayın: tüm yollar merkezi blok üretimine ve merkeziyetsiz blok doğrulamaya çıkar. Blok üretici donanımındaki ilerlemeler yoluyla rollup verimini katlanarak artırabilsek de, gerçek ölçeklenebilirlik darboğazı, blok doğrulamasından ziyade blok kullanılabilirliğidir. Bu, önemli bir içgörüye yol açar: Yürütme katmanını ne kadar güçlü yaparsak yapalım veya hangi kanıt uygulamasını kullanırsak kullanalım, verimimiz nihai olarak veri kullanılabilirliği ile sınırlıdır.

Şu anda veri kullanılabilirliğini sağlamamızın bir yolu, blok zinciri verilerini zincir üzerinde yayınlamaktır. Rollup uygulamaları, Ethereum ana ağını bir veri kullanılabilirlik katmanı olarak kullanır ve tüm rollup bloklarını Ethereum'da periyodik olarak yayınlar. Bu boşluk çözümünün(stop-gap solution) karşılaştığı birincil sorun, Ethereum'un mevcut mimarisinin, veri kullanılabilirliği örneklemesi gerçekleştiren hafif istemciler yerine bloğun tamamını indirerek veri kullanılabilirliğini garanti eden tam düğümlere dayanmasıdır. Ek verim için blok boyutlarını artırdıkça, bu kaçınılmaz olarak, veri kullanılabilirliğini doğrulayan ve ağı merkezileştiren tam düğümler için artan donanım gereksinimleriyle sonuçlanır.

Gelecekte, Ethereum, ağı koruyan hem tam düğümlerden hem de hafif istemcilerden oluşan veri kullanılabilirliği örneklemesini kullanan parçalı bir mimariye geçmeyi planlıyor. (Not - Ethereum parçalaması(sharding) teknik olarak hata kanıtı yerine KZG taahhütlerini kullanır, ancak veri kullanılabilirliği sorunu ne olursa olsun önemlidir.) Ancak bu, sorunun yalnızca bir kısmını çözer: rollup mimarisinin karşılaştığı bir diğer temel sorun, rollup bloklarının çağrı verileri(calldata) olarak Ethereum ana ağına atılmasıdır. Bu, çağrı verilerinin ölçek açısından pahalı olması ve rollup işlemi toplu boyutundan bağımsız olarak bayt başına 16 gaz maliyetiyle L2 kullanıcılarında darboğaz oluşturması nedeniyle sorunları ortaya çıkarır.

"Bu, son kullanıcıların rolluplardan yararlanması durumunda bile, çağrı verilerini(call data) Ethereum'a göndermenin, bu sabit oranın bir sonucu olarak bugün karşılaştıkları korkunç gaz maliyetlerine (aşağıdaki grafiğe bakın) borçlu olacağı anlamına geliyor."

Validyumlar, ölçeklenebilirliği ve verimi artırmanın ve veri kullanılabilirliği garantilerini korumanın başka bir yoludur: granüler işlem verileri, zincir dışı (kaynağa göre) bir veri kullanılabilirlik komitesine(DA committee), PoS gardiyanlara veya veri kullanılabilirlik katmanına gönderilebilir. Veri kullanılabilirliğini Ethereum çağrı verilerinden zincir dışı çözümlere kaydırarak, validiumlar artan rollup kullanımıyla ilişkili sabit byte gaz maliyetlerini bypas eder.

Rollup mimarisi ayrıca, blok zincirlerinin yürütmeyi veya hesaplamayı kendisini sağlamak yerine sadece blokları sıralama ve bu blokların veri kullanılabilirliğini garanti etme işlevini yerine getirmek konusunda benzersiz bir anlayışa yol açmıştır. İlk modüler blok zinciri ağı olan Celestia'nın arkasındaki temel tasarım felsefesi budur. Eskiden LazyLedger olarak bilinen Celestia, yürütme ve doğrulamayı diğer modüler katmanlara bırakarak “tembel blok zinciri”(lazy blockchain) olarak başladı ve yalnızca veri kullanılabilirliği örneklemesi yoluyla işlem sıralaması ve veri kullanılabilirliği garantileri için bir veri kullanılabilirlik katmanı sağlamaya odaklandı. Merkezi blok üretimi ve merkeziyetsiz blok doğrulayıcılar, Celestia'nın tasarımının arkasındaki temel dayanaktır: cep telefonları bile hafif bir istemci olarak katılabilir ve ağı koruyabilir. Veri kullanılabilirliği örneklemesinin özellikleri nedeniyle, bir veri kullanılabilirlik katmanı olarak Celestia'ya bağlanan rolluplar, aynı olasılık garantilerini korurken Celestia hafif düğümlerinin(Light nodes) sayısı arttıkça daha yüksek blok boyutlarını (ve dolayısıyla verimi) destekleyebilir.

Günümüzde diğer çözümler arasında StarkEx, zkPorter ve Polygon Avail yer alıyor ve StarkEx şu anda üretimde kullanılan tek validium. Ne olursa olsun, çoğu validium, güvenilir bir komite, gardiyanlar veya genelleştirilmiş veri kullanılabilirlik katmanı aracılığıyla yönetilip yönetilmediğine bakılmaksızın, veri kullanılabilirliği kaynağında örtük bir güven varsayımı içerir. Bu güven aynı zamanda kötü niyetli operatörlerin kullanıcı fonlarının çekilmesini(withdraw) önleyebileceğini gösteriyor.

Modüler blok zinciri mimarisi, mevcut kripto ortamında çok tartışılan bir konudur. Modüler bir blok zinciri mimarisi için Celestium vizyonunda, güvenlik endişeleri ve parçalanmış bir yerleşim ve veri kullanılabilirlik katmanıyla ilişkili ek güven varsayımları nedeniyle önemli bir geri dönüş oldu.

Bu arada, blok zinciri yığınının tüm cephelerinde önemli ilerlemeler kaydedildi: Fuel Labs, yürütme katmanında paralelleştirilmiş bir VM üzerinde çalışıyor ve Optimism ekibi, parçalama(sharding), teşvikli doğrulama ve merkeziyetsiz bir sıralayıcı(sequencer) üzerinde çalışıyor. Hibrit optimistik ve sıfır bilgi çözümleri de geliştirme aşamasındadır.

Ethereum'un merge sonrası geliştirme yol haritası, birleşik bir yerleşim ve veri kullanılabilirlik katmanı için planlar içerir. Danksharding, özellikle, Ethereum L1 veri parçalarını ve blok alanını bir “veri kullanılabilirlik motoruna” dönüştürmek ve optimize etmek için tasarlanmış Ethereum yol haritasında umut verici bir gelişmedir ve böylece L2 rolluplarının düşük maliyetli, yüksek verimli işlemler gerçekleştirmesine izin verir.

‍Celestia'nın sade mimarisi ayrıca, WASM, Starknet ve FuelVM gibi alternatif, EVM olmayan sanal makineler için temel altyapıyı hazırlayarak, onu bir veri kullanılabilirlik katmanı olarak kullanmak için çok çeşitli yürütme katmanı uygulamalarına izin verir. Çeşitli yürütme çözümleri için bu paylaşılan veri kullanılabilirliği, geliştiricilerin Celestia kümeleri(clusters) arasında güveni en aza indirilmiş köprüler oluşturmasına, zincirler arası ve ekosistemler arası birleştirilebilirliğin ve Ethereum ve rollupları arasında mümkün olana benzer şekilde birlikte çalışabilirliğin kilidini açmasına olanak tanır.

Starkware'in öncülük ettiği Volitions, zincir içi ve zincir dışı veri kullanılabilirliği ikilemine yenilikçi bir çözüm sunar: kullanıcılar ve geliştiriciler, işlem verilerini zincir dışı göndermek için validium kullanma veya işlem verilerini zincirde tutma arasında seçim yapabilir. Bunların her ikisinin de benzersiz avantajları ve dezavantajları vardır.

Ek olarak, katman 2 çözümlerinin artan kullanımı ve yaygınlığı, katman 3: fraktal ölçeklemenin kilidini açar. Fraktal ölçekleme, uygulamaya özel rollupların katman 2'lerde dağıtılmasına(deploy) olanak tanır - geliştiriciler artık uygulamalarını veri kullanılabilirliğinden gizliliğe kadar altyapılarının tam denetimiyle dağıtabilir. Uygulamaya özel bağımsız zincirlerde (ör.Cosmos) olduğu gibi pahalı temel zincir yerine Katman 3'te dağıtım(deploy) yapmak, katman 2'deki tüm katman 3 uygulamaları arasında birlikte çalışabilirliği de sağlar. Yani rollup üstünde rollup yapılır.

Web altyapısının şirket içi sunuculardan bulut sunucularına nasıl geliştiğine benzer şekilde, merkeziyetsiz web, monolitik blok zincirlerinden ve silolu konsensüs katmanlarından, paylaşılan konsensüs katmanlarına sahip modüler, uygulamaya özel zincirlere dönüşüyor. Hangi çözüm ve uygulamanın başarılı olacağına bakılmaksızın, bir şey açıktır: Modüler bir gelecekte kullanıcılar nihai kazananlardır.

Blockchain mimarisi hakkında düşünceleriniz nelerdir? Yanlış bir şey mi anladım? Geri bildirim veya sorularınız için Twitter @0xAlec üzerinden veya alec@volt.capital e-posta adresi aracılığıyla bize ulaşmaktan çekinmeyin. ‍

İnceleme ve geri bildirim sağlama için Nick White, John Adler, Alex Beckett, John Wang ve Osprey'e çok teşekkürler.

Paradigm Research, Delphi Research, Polynya ve Celestia'daki ekibe modüler blok zincirler üzerinde derinlemesine kaynaklar yayınladıkları için ayrıca teşekkürler. Devamını aşağıdaki linklerden okuyabilirsiniz.

https://www.paradigm.xyz/2021/01/almost-everything-you-need-to-know-about-optimistic-rollup

https://blog.celestia.org/ethereum-off-chain-data-availability-landscape/

https://members.delphidigital.io/reports/pay-attention-to-celestia

https://polynya.medium.com/updated-thoughts-on-modular-blockchains-ce1b159fa1b3

https://vitalik.ca/general/2020/08/20/trust.html

https://vitalik.ca/general/2021/12/06/endgame.html

‍

NOT: Bu yazı, Alec Chen’in 7 Temmuz 2022 tarihinde yayınladığı blog yazısının -resmi olmayan- çevirisidir. Tüm resimler ve bağlantılar blog yazısından alınmıştır. Yazının orjinal haline buradan ulaşabilirsiniz.

“Modüler blok zinciri” fikri, ölçeklenebilirlik ve blok zinciri altyapısı etrafında kategori tanımlayan bir anlatı haline geliyor.

‍Varsayım oldukça basit: Katman 1 blok zincirinin temel bileşenlerini ayrıştırarak, bireysel katmanlarda 100 kat iyileştirme yapabiliriz, bu da daha ölçeklenebilir, birleştirilebilir ve merkezi olmayan bir sistemle sonuçlanır. Modüler blok zincirlerini uzun uzadıya tartışmadan önce, mevcut blok zinciri mimarisini ve blok zincirlerinin mevcut uygulamalarıyla karşılaştığı sınırlamaları anlamalıyız.

Kısaca blokzincir temellerini özetleyelim. Blok zincirindeki bloklar iki bileşenden oluşur: blok başlığı ve bu başlıkla ilişkili işlem verileri. Bloklar, işlemlerin geçerli olması için örneğin kullanıcıların hesap bakiyelerinden daha fazla ether göndermediğinden emin olmak için tüm blok verilerini ayrıştıran ve hesaplayan "tam düğümler"(full nodes) aracılığıyla doğrulanır.

Ayrıca bir blok zinciri oluşturan fonksyonellik “katmanlarını” da kısaca özetleyelim.

Uygulama (Execution) İşlemler ve durum değişiklikleri(state changes) başlangıçta burada işlenir. Kullanıcılar ayrıca işlemleri imzalayarak, akıllı sözleşmeleri dağıtarak(deploy) ve varlıkları aktararak blok zinciri ile tipik olarak bu katman aracılığıyla etkileşime girer. ‍

Anlaşma(Settlement) Uzlaşma katmanı, rollupların yürütülmesinin doğrulandığı ve anlaşmazlıkların çözüldüğü yerdir. Bu katman monolitik zincirlerde mevcut değildir ve modüler yığının isteğe bağlı bir parçasıdır. ABD mahkeme sistemine benzer bir şekilde, Anlaşma katmanını, anlaşmazlıklar üzerinde nihai tahkim sağlayan ABD Yüksek Mahkemesi olarak düşünün.

Uzlaşma(Consensus) Blok zincirlerinin konsensüs katmanı, blokların içeriğini indiren ve yürüten ve durum geçişlerinin geçerliliği konusunda fikir birliğine varan tam düğümler ağı aracılığıyla sıralama ve kesinlik sağlar. ‍

Veri kullanılabilirliği(Data Availability) Bir durum geçişinin(state transition) geçerli olduğunu doğrulamak için gereken veriler bu katmanda yayınlanmalı ve saklanmalıdır. Bu, kötü niyetli blok üreticilerinin işlem verilerini sakladığı saldırılar durumunda kolayca doğrulanabilir olmalıdır. Veri kullanılabilirliği katmanı, blok zinciri ölçeklenebilirlik üçlemi için ana darboğazdır, nedenini daha sonra keşfedeceğiz.

Örneğin Ethereum monolitiktir, yani temel katman yukarıda bahsedilen tüm bileşenleri yönetir.

Blokzincirler şu anda “Blokzincir Ölçeklenebilirlik Üçlemesi” adı verilen bir sorunla karşı karşıya. Brewer'ın dağıtık sistemler teoremine benzer şekilde, blok zinciri mimarisi tipik olarak diğer ikisi için güçlü garantiler sağlamak için merkeziyetsizlik, güvenlik veya ölçeklenebilirlikten ödün verir.

‍

Güvenlik, ağın saldırı altında çalışabilme yeteneğini ifade eder. Bu ilke, blok zincirlerinin temel bir ilkesidir ve asla taviz verilmemelidir, bu nedenle gerçek hesaplaşma genellikle ölçeklenebilirlik ve merkeziyetsizlik arasındadır.

Merkeziyetsizliği blok zinciri sistemleri bağlamında tanımlayalım: Bir blok zincirinin merkeziyetsiz olması için, donanım gereksinimleri katılım için bir sınırlama olmamalı ve ağın doğrulanması için kaynak gereksinimleri düşük olmalıdır.

Ölçeklenebilirlik, bir blok zincirinin veriminin, doğrulama maliyetine bölünmesi anlamına gelir: yani bir blok zincirinin, doğrulama için kaynak gereksinimlerini düşük tutarken artan miktarda işlemi işleme yeteneğidir. Verimi artırmanın iki ana yolu vardır. İlk olarak, blok boyutunu ve dolayısıyla bir bloğa dahil edilebilecek işlemlerin kapasitesini artırabilirsiniz. Ne yazık ki, daha büyük blok boyutları, daha yüksek hesaplama çıktısı ihtiyacına yanıt olarak tam düğümleri çalıştırmanın donanım gereksinimleri arttıkça ağın merkezileşmesiyle sonuçlanır. Özellikle monolitik blok zincirleri, verimdeki bir artış, zinciri doğrulama maliyetindeki bir artışla ilişkili olduğundan ve daha az merkeziyetsizlikle sonuçlandığından bu sorunla karşılaşır. İkinci olarak, zincir üzerinde hesaplamanın doğrulanmasına izin veren kanıtları kullanırken hesaplama yükünü ana ağdaki düğümlerden uzaklaştırarak yürütmeyi(execution) zincir dışına taşıyabilirsiniz.

‍Modüler bir mimari ile blok zincirlerinin, meselelerin ayrılması ilkesi ile blok zinciri ölçeklenebilirlik üçlemesini çözmeye başlaması mümkündür. Modüler bir yürütme(execution) ve veri kullanılabilirlik(data availability) katmanı aracılığıyla, blok zincirler, hesaplama ve doğrulama maliyeti arasındaki korelasyonu kırarak ağı güven gerektirmez(trustless) ve merkeziyetsiz hale getiren özellikleri korurken aynı zamanda verimi ölçekleyebilir. Hata kanıtlarını(fault proofs), rollupları ve bunların Veri Kullanılabilirliği sorunuyla nasıl ilişkili olduğunu tanıtarak bunun nasıl mümkün olduğunu keşfedelim.

Vitalik, Endgame'de, merkezilik ve merkeziyetsizlik arasında olası bir uzlaşmanın, blok üretiminin geleceğinin ölçeklenebilirlik amacıyla havuzlara ve uzman üreticilere merkezileşmesi ve blok doğrulamanın (üreticileri dürüst tutarak) önemli ölçüde merkeziyetsiz kalması gerektiğini belirtiyor. Bu, blok zinciri düğümlerini tam düğümlere(full nodes) ve hafif istemcilere(light clients) bölerek elde edilebilir. Bu modelin ilgili olduğu iki sorun vardır: blok doğrulama (hesaplamanın doğruluğunu doğrulama) ve blok kullanılabilirliği (tüm verilerin yayınlandığını doğrulama). Önce blok doğrulamadaki uygulamasını inceleyelim.

Tam düğümler bloktaki her işlemi indirir, hesaplar ve doğrularken, hafif istemciler yalnızca blok başlıklarını indirir ve işlemlerin geçerli olduğunu varsayar. Hafif istemciler daha sonra işlem doğrulaması için tam düğümler tarafından oluşturulan hata kanıtlarına güvenir. Bu da, hafif istemcilerin geçersiz işlemleri özerk bir şekilde tanımlamasına ve tam bir düğümle neredeyse aynı güvenlik garantileri altında çalışmasına olanak tanır. Varsayılan olarak, hafif istemciler durum geçişlerinin geçerli olduğunu varsayar ve hata kanıtları alarak durumların geçerliliğine itiraz edebilir.

Bir düğümün durumu bir hata kanıtıyla sorgulandığında, ilgili işlemleri yeniden yürüten tam bir düğüm aracılığıyla fikir birliği sağlanır ve bu da dürüst olmayan düğümün hissesinin kesilmesiyle(slash) sonuçlanır.

Hafif istemciler ve hataya dayanıklı(fault proof) model, zincirin tam durumu(full state) ile hata kanıtı sunan en az bir dürüst tam düğümün bulunduğu dürüst azınlık varsayımı altında güvenlidir. Doğrulayıcılar, tüm parçalarda(shardlarda) 1/N güvenlik garantisini korurken, bir parçada tam bir düğüm çalıştırmayı ve geri kalanında hafif istemcileri çalıştırmayı seçebildiğinden, bu model özellikle parçalanmış blok zincirleri(sharded blockchains) (Ethereum'un birleştirme sonrası mimarisi gibi) için geçerlidir.

Optimistik Rolluplar, blok zinciri yürütme katmanını sıralayıcılara(sequencers), birden fazla işlemi bir araya getiren ve yürüten ve sıkıştırılmış verileri periyodik olarak ana zincire geri gönderen güçlü bilgisayarlara güvenli bir şekilde soyutlamak için bu modeli kullanır. Bu hesaplamayı zincir dışına kaydırmak (ana zincire göre), işlem veriminde 10-100 kat artışa izin verir. Bu zincir dışı sıralayıcıların(sequencer) iyi huylu kalacağına nasıl güvenebiliriz? Operatörlerin bir sıralayıcıyı çalıştırmak için kilitlemesi(stake) gereken tokenleri, sunarız. Sıralayıcılar, işlem verilerini ana zincire geri gönderdiğinden, daha sonra, hata kanıtları yayınlamak ve ardından kötü niyetli sıralayıcıların payını kesmek için bir üst zincir ile rollupı arasındaki durum uyumsuzluklarını izleyen düğümler olan doğrulayıcıları(verifier) kullanabiliriz. Optimistik rolluplar hata kanıtlarını kullandığından, ağda tek bir dürüst doğrulayıcının var olduğu varsayımı altında güvenlidirler. Hata kanıtlarının bu kullanımı, optimistik rollupların adlarını türettikleri yerdir - durum geçişlerinin, uzlaşma katmanında ele alınan bir anlaşmazlık döneminde (dispute period) aksi kanıtlanana kadar geçerli olduğu varsayılır.

Güveni en aza indirirken verimi bu şekilde ölçekleyebiliriz: Hesaplamanın doğrulamasını merkeziyetsiz tutarken hesaplamanın merkezileşmesine göz yumun.

Hata kanıtı, merkeziyetsiz blok doğrulamasını çözmek için kullanışlı bir araç olsa da, tam düğümler, hata kanıtı oluşturmak için blok kullanılabilirliğine(block availability) bağlıdır. Kötü niyetli bir blok üreticisi, yalnızca blok başlıklarını yayınlamayı ve karşılık gelen verilerin bir kısmını veya tamamını saklamayı seçebilir, bu da tam düğümlerin geçersiz işlemleri doğrulamasını ve tanımlamasını ve böylece hata kanıtı oluşturmasını engeller. Bu tür bir saldırı, tüm bloğu basitçe indirebildikleri ve tutarsızlıkları veya saklanan verileri fark ettiklerinde geçersiz zincirden uzaklaşabildikleri(fork) için tam düğümlerin fark etmesi için önemsizdir. Bununla birlikte, hafif istemciler, tam düğümlerden uzaklaşarak, potansiyel olarak geçersiz bir zincirin başlıklarını izlemeye devam edecektir. (Hafif istemcilerin tüm bloğu indirmediğini ve durum geçişlerinin(state transitions) varsayılan olarak geçerli olduğunu varsaydığını unutmayın.)

Bu, hata kanıtlarıyla ilgili olduğu için veri kullanılabilirliği sorununun özüdür: hafif istemciler, doğrulamadan önce tüm işlem verilerinin bir blokta serbest bırakıldığından emin olmalıdır, öyle ki, tam düğümler ve hafif istemciler, kurallı zincir için aynı başlık üzerinde otomatik olarak anlaşmalıdır. (Veri mevcudiyeti için hata kanıtlama için neden benzer bir sistem kullanamadığımızı merak ediyorsanız, veri stopajı ikilemini burada derinlemesine okuyabilirsiniz. Esasen oyun teorisi, burada kullanılan hataya dayalı bir sistemin istismar edileceğini ve dürüst oyuncular için kaybet-kaybet durumuyla sonuçlanacağını belirtir.)

İlk kareye döndük gibi görünebilir. Hafif istemciler, donanım gereksinimlerini merkezileştirerek ve böylece hafif istemcilerin amacını ortadan kaldırarak tüm bloğu indirmek zorunda kalmadan bir bloktaki tüm işlem verilerinin serbest bırakılmasını nasıl sağlayabilir?

Bunu başarmanın bir yolu, silme kodlaması(erasure coding) adı verilen matematiksel bir ilkeldir. Bir bloktaki baytları çoğaltarak, silme kodlaması, verilerin belli bir yüzdesi kaybolsa bile tüm bloğun yeniden oluşturulmasını sağlar. Bu teknoloji, veri kullanılabilirliği örneklemesi gerçekleştirmek için kullanılır ve hafif istemcilerin, bloğun küçük kısımlarını rastgele örnekleyerek yayınlanan bir bloğun tamamını olasılıksal olarak belirlemesine olanak tanır. Bu, hafif istemcilerin, geçerli olarak kabul etmeden ve ilgili blok başlığını takip etmeden önce tüm işlem verilerinin belirli bir bloğa dahil edilmesini sağlar. Bununla birlikte, bu teknik için birkaç uyarı vardır: veri kullanılabilirliği örneklemesi yüksek gecikme süresine sahiptir ve dürüst azınlık varsayımına benzer şekilde, güvenlik garantisi, bir bloğun kullanılabilirliğini olasılıksal olarak belirleyebilmek için örnekleme gerçekleştiren yeterli hafif istemcilerin olduğu varsayımına dayanır.

Merkeziyetsiz blok doğrulama için başka bir çözüm, durum geçişleri için işlem verilerine ihtiyaç duymayı ortadan kaldırmaktır. Geçerlilik kanıtları, aksine, hata kanıtlarına kıyasla daha pesimistik bir bakış açısına sahiptir. Uyuşmazlık sürecini ortadan kaldırarak, geçerlilik kanıtları, her bir durum geçişi için bir kanıt gerektirme dengesiyle tüm durum geçişlerinin atomikliğini(atomicity) garanti edebilir. Bu, yeni sıfır bilgi teknolojileri SNARK'lar ve STARK'lar kullanılarak gerçekleştirilir. Hata kanıtlarıyla karşılaştırıldığında, geçerlilik kanıtları, daha güçlü durum garantileri karşılığında daha fazla hesaplama yoğunluğu gerektirir ve ölçeklenebilirliği etkiler.

Sıfır Bilgi Rollupları, durum doğrulaması için hata kanıtları yerine geçerlilik kanıtlarını kullanan rolluplardır. Sıralayıcıların hesaplamayı ele aldığı ve doğrulayıcıların karşılık gelen kanıtları oluşturduğu bir sıralayıcı/doğrulayıcı modeli aracılığıyla optimistik rolluplar olarak (hata kanıtları yerine şema olarak geçerlilik kanıtlarıyla da olsa) benzer bir hesaplama ve doğrulama modelini takip ederler.Örneğin Starknet, önyükleme amacıyla merkezi sıralayıcılarla başlatıldı ve yol haritasında açık sıralayıcıların ve kanıtlayıcıların aşamalı olarak merkeziyetsizleştirilmesine sahiptir. Sıralayıcılarda zincir dışı yürütme nedeniyle hesaplamaların kendileri ZK rolluplarında sınırsızdır. Bununla birlikte, bu hesaplamalar için kanıtların zincir üzerinde doğrulanması gerektiğinden, kesinlik(finality) hala kanıt oluşturma tarafından darboğazdadır.

Durum doğrulaması için hafif istemcileri kullanma tekniğinin yalnızca hataya dayanıklı mimariyle ilgili olduğunu belirtmek önemlidir. Durum geçişlerinin geçerlilik kanıtlarıyla geçerli olması garanti edildiğinden, düğümlerin blokları doğrulaması için artık işlem verilerine gerek yoktur. Bununla birlikte, geçerlilik kanıtları için veri kullanılabilirliği sorunu hala mevcuttur ve biraz daha belirsizdir: garantili duruma rağmen, geçerlilik kanıtları için işlem verileri hala gereklidir, öyle ki düğümler son kullanıcılara durum geçişlerini güncelleyebilir ve sunabilir. Bu nedenle, geçerlilik kanıtlarını kullanan rolluplarda hala veri kullanılabilirliği sorunu vardır.

Vitalik'in tezini hatırlayın: tüm yollar merkezi blok üretimine ve merkeziyetsiz blok doğrulamaya çıkar. Blok üretici donanımındaki ilerlemeler yoluyla rollup verimini katlanarak artırabilsek de, gerçek ölçeklenebilirlik darboğazı, blok doğrulamasından ziyade blok kullanılabilirliğidir. Bu, önemli bir içgörüye yol açar: Yürütme katmanını ne kadar güçlü yaparsak yapalım veya hangi kanıt uygulamasını kullanırsak kullanalım, verimimiz nihai olarak veri kullanılabilirliği ile sınırlıdır.

Şu anda veri kullanılabilirliğini sağlamamızın bir yolu, blok zinciri verilerini zincir üzerinde yayınlamaktır. Rollup uygulamaları, Ethereum ana ağını bir veri kullanılabilirlik katmanı olarak kullanır ve tüm rollup bloklarını Ethereum'da periyodik olarak yayınlar. Bu boşluk çözümünün(stop-gap solution) karşılaştığı birincil sorun, Ethereum'un mevcut mimarisinin, veri kullanılabilirliği örneklemesi gerçekleştiren hafif istemciler yerine bloğun tamamını indirerek veri kullanılabilirliğini garanti eden tam düğümlere dayanmasıdır. Ek verim için blok boyutlarını artırdıkça, bu kaçınılmaz olarak, veri kullanılabilirliğini doğrulayan ve ağı merkezileştiren tam düğümler için artan donanım gereksinimleriyle sonuçlanır.

Gelecekte, Ethereum, ağı koruyan hem tam düğümlerden hem de hafif istemcilerden oluşan veri kullanılabilirliği örneklemesini kullanan parçalı bir mimariye geçmeyi planlıyor. (Not - Ethereum parçalaması(sharding) teknik olarak hata kanıtı yerine KZG taahhütlerini kullanır, ancak veri kullanılabilirliği sorunu ne olursa olsun önemlidir.) Ancak bu, sorunun yalnızca bir kısmını çözer: rollup mimarisinin karşılaştığı bir diğer temel sorun, rollup bloklarının çağrı verileri(calldata) olarak Ethereum ana ağına atılmasıdır. Bu, çağrı verilerinin ölçek açısından pahalı olması ve rollup işlemi toplu boyutundan bağımsız olarak bayt başına 16 gaz maliyetiyle L2 kullanıcılarında darboğaz oluşturması nedeniyle sorunları ortaya çıkarır.

"Bu, son kullanıcıların rolluplardan yararlanması durumunda bile, çağrı verilerini(call data) Ethereum'a göndermenin, bu sabit oranın bir sonucu olarak bugün karşılaştıkları korkunç gaz maliyetlerine (aşağıdaki grafiğe bakın) borçlu olacağı anlamına geliyor."

Validyumlar, ölçeklenebilirliği ve verimi artırmanın ve veri kullanılabilirliği garantilerini korumanın başka bir yoludur: granüler işlem verileri, zincir dışı (kaynağa göre) bir veri kullanılabilirlik komitesine(DA committee), PoS gardiyanlara veya veri kullanılabilirlik katmanına gönderilebilir. Veri kullanılabilirliğini Ethereum çağrı verilerinden zincir dışı çözümlere kaydırarak, validiumlar artan rollup kullanımıyla ilişkili sabit byte gaz maliyetlerini bypas eder.

Rollup mimarisi ayrıca, blok zincirlerinin yürütmeyi veya hesaplamayı kendisini sağlamak yerine sadece blokları sıralama ve bu blokların veri kullanılabilirliğini garanti etme işlevini yerine getirmek konusunda benzersiz bir anlayışa yol açmıştır. İlk modüler blok zinciri ağı olan Celestia'nın arkasındaki temel tasarım felsefesi budur. Eskiden LazyLedger olarak bilinen Celestia, yürütme ve doğrulamayı diğer modüler katmanlara bırakarak “tembel blok zinciri”(lazy blockchain) olarak başladı ve yalnızca veri kullanılabilirliği örneklemesi yoluyla işlem sıralaması ve veri kullanılabilirliği garantileri için bir veri kullanılabilirlik katmanı sağlamaya odaklandı. Merkezi blok üretimi ve merkeziyetsiz blok doğrulayıcılar, Celestia'nın tasarımının arkasındaki temel dayanaktır: cep telefonları bile hafif bir istemci olarak katılabilir ve ağı koruyabilir. Veri kullanılabilirliği örneklemesinin özellikleri nedeniyle, bir veri kullanılabilirlik katmanı olarak Celestia'ya bağlanan rolluplar, aynı olasılık garantilerini korurken Celestia hafif düğümlerinin(Light nodes) sayısı arttıkça daha yüksek blok boyutlarını (ve dolayısıyla verimi) destekleyebilir.

Günümüzde diğer çözümler arasında StarkEx, zkPorter ve Polygon Avail yer alıyor ve StarkEx şu anda üretimde kullanılan tek validium. Ne olursa olsun, çoğu validium, güvenilir bir komite, gardiyanlar veya genelleştirilmiş veri kullanılabilirlik katmanı aracılığıyla yönetilip yönetilmediğine bakılmaksızın, veri kullanılabilirliği kaynağında örtük bir güven varsayımı içerir. Bu güven aynı zamanda kötü niyetli operatörlerin kullanıcı fonlarının çekilmesini(withdraw) önleyebileceğini gösteriyor.

Modüler blok zinciri mimarisi, mevcut kripto ortamında çok tartışılan bir konudur. Modüler bir blok zinciri mimarisi için Celestium vizyonunda, güvenlik endişeleri ve parçalanmış bir yerleşim ve veri kullanılabilirlik katmanıyla ilişkili ek güven varsayımları nedeniyle önemli bir geri dönüş oldu.

Bu arada, blok zinciri yığınının tüm cephelerinde önemli ilerlemeler kaydedildi: Fuel Labs, yürütme katmanında paralelleştirilmiş bir VM üzerinde çalışıyor ve Optimism ekibi, parçalama(sharding), teşvikli doğrulama ve merkeziyetsiz bir sıralayıcı(sequencer) üzerinde çalışıyor. Hibrit optimistik ve sıfır bilgi çözümleri de geliştirme aşamasındadır.

Ethereum'un merge sonrası geliştirme yol haritası, birleşik bir yerleşim ve veri kullanılabilirlik katmanı için planlar içerir. Danksharding, özellikle, Ethereum L1 veri parçalarını ve blok alanını bir “veri kullanılabilirlik motoruna” dönüştürmek ve optimize etmek için tasarlanmış Ethereum yol haritasında umut verici bir gelişmedir ve böylece L2 rolluplarının düşük maliyetli, yüksek verimli işlemler gerçekleştirmesine izin verir.

‍Celestia'nın sade mimarisi ayrıca, WASM, Starknet ve FuelVM gibi alternatif, EVM olmayan sanal makineler için temel altyapıyı hazırlayarak, onu bir veri kullanılabilirlik katmanı olarak kullanmak için çok çeşitli yürütme katmanı uygulamalarına izin verir. Çeşitli yürütme çözümleri için bu paylaşılan veri kullanılabilirliği, geliştiricilerin Celestia kümeleri(clusters) arasında güveni en aza indirilmiş köprüler oluşturmasına, zincirler arası ve ekosistemler arası birleştirilebilirliğin ve Ethereum ve rollupları arasında mümkün olana benzer şekilde birlikte çalışabilirliğin kilidini açmasına olanak tanır.

Starkware'in öncülük ettiği Volitions, zincir içi ve zincir dışı veri kullanılabilirliği ikilemine yenilikçi bir çözüm sunar: kullanıcılar ve geliştiriciler, işlem verilerini zincir dışı göndermek için validium kullanma veya işlem verilerini zincirde tutma arasında seçim yapabilir. Bunların her ikisinin de benzersiz avantajları ve dezavantajları vardır.

Ek olarak, katman 2 çözümlerinin artan kullanımı ve yaygınlığı, katman 3: fraktal ölçeklemenin kilidini açar. Fraktal ölçekleme, uygulamaya özel rollupların katman 2'lerde dağıtılmasına(deploy) olanak tanır - geliştiriciler artık uygulamalarını veri kullanılabilirliğinden gizliliğe kadar altyapılarının tam denetimiyle dağıtabilir. Uygulamaya özel bağımsız zincirlerde (ör.Cosmos) olduğu gibi pahalı temel zincir yerine Katman 3'te dağıtım(deploy) yapmak, katman 2'deki tüm katman 3 uygulamaları arasında birlikte çalışabilirliği de sağlar. Yani rollup üstünde rollup yapılır.

Web altyapısının şirket içi sunuculardan bulut sunucularına nasıl geliştiğine benzer şekilde, merkeziyetsiz web, monolitik blok zincirlerinden ve silolu konsensüs katmanlarından, paylaşılan konsensüs katmanlarına sahip modüler, uygulamaya özel zincirlere dönüşüyor. Hangi çözüm ve uygulamanın başarılı olacağına bakılmaksızın, bir şey açıktır: Modüler bir gelecekte kullanıcılar nihai kazananlardır.

Blockchain mimarisi hakkında düşünceleriniz nelerdir? Yanlış bir şey mi anladım? Geri bildirim veya sorularınız için Twitter @0xAlec üzerinden veya alec@volt.capital e-posta adresi aracılığıyla bize ulaşmaktan çekinmeyin. ‍

İnceleme ve geri bildirim sağlama için Nick White, John Adler, Alex Beckett, John Wang ve Osprey'e çok teşekkürler.

Paradigm Research, Delphi Research, Polynya ve Celestia'daki ekibe modüler blok zincirler üzerinde derinlemesine kaynaklar yayınladıkları için ayrıca teşekkürler. Devamını aşağıdaki linklerden okuyabilirsiniz.

https://www.paradigm.xyz/2021/01/almost-everything-you-need-to-know-about-optimistic-rollup

https://blog.celestia.org/ethereum-off-chain-data-availability-landscape/

https://members.delphidigital.io/reports/pay-attention-to-celestia

https://polynya.medium.com/updated-thoughts-on-modular-blockchains-ce1b159fa1b3

https://vitalik.ca/general/2020/08/20/trust.html

https://vitalik.ca/general/2021/12/06/endgame.html

‍

NOT: Bu yazı, Alec Chen’in 7 Temmuz 2022 tarihinde yayınladığı blog yazısının -resmi olmayan- çevirisidir. Tüm resimler ve bağlantılar blog yazısından alınmıştır. Yazının orjinal haline buradan ulaşabilirsiniz.