2020'nin sonunda Fuel V1, Ethereum üzerinde bir ikinci katman (L2) ölçeklenebilirlik teknolojisi olarak devreye alındı. Fuel V1, Ethereum ana ağında dolandırıcılık kanıtlarına öncülük eden ilk optimistik rollup’tı. O zamandan bu yana Fuel, yeni nesil rollup mimarimiz Fuel V2'ye giden yolda önemli ölçüde büyüdü ve şu anda 40'tan fazla ekosistem projesine sahip ve hepsi de Ethereum üzerinde merkeziyetsiz uygulamaların bir sonraki çağını geliştirmeyi hedefliyor.

Bu blog yazısında, daha önce hiç değinilmemiş avantajlar sunduğuna inandığımız önemli bir teknik olan FuelProver ve hibrit doğrulamayı tanıtıyoruz.

Sorun

İkinci katman alanına iki ana yaklaşım hakim olmuştur: optimistik rollup'lar ve sıfır bilgi (ZK) rollup'ları. Her ikisi de umut vaat etse de, bazı ödünler vermeyi de gerektirir. Fuel V1, Arbitrum ve Optimism gibi optimistik rollup'lar, kanıtları zincir üzerinde doğrulamak için ekstra maliyet gerektirmeyen iyimser durumda önemli ölçüde daha basittirler, ancak güvenliği sağlamak için sahtekarlık kanıtlarına dayanan uzun para çekme süreleri ve karmaşık bir etkileşimli doğrulama süreci (IVG) ile sınırlıdırlar. Öte yandan, ZK kanıtları anında yürütme doğrulaması ve daha iyi veri sıkıştırma teknikleri sunar, ancak yavaş ve maliyetli kanıt üretimi ve zincir üzerinde doğrulama gerektirirler.

ZK nihayetinde blok zinciri doğrulamasının geleceği olacaktır, ancak kanıt oluşturma verimliliği bol sıfırlı TPS'lik rollup mimarileri için henüz mevcut değildir. Fuel binlerce TPS'ye ulaşmayı amaçladığı için Fuel'i tam bir ZK rollup'a dönüştürmek bugün için uygun değil.

Karşınızda FuelProver: Hibrit Bir Çözüm

Karşınızda optimistik / ZK karışımı FuelProver. Fuel V1 ile sunulan tek turlu sahtekarlık kanıtlama modelinin avantajlarını ve ZK kanıtlarının potansiyelini kabul ederek, her iki tarafın da en iyi yönlerini bir araya getiren bir ortak çözüm öngörüyoruz. FuelProver, ZK kanıtlama mimarisinden bağımsız olacak, yani en son geliştirilen genel amaçlı kanıtlayıcıları destekleyebilecek. Sonuçta, FuelProver, ZK teknolojisindeki en son gelişmelerle birlikte gelişebilen esnek ve uyarlanabilir bir sistem sağlamayı hedeflemektedir.

FuelProver'ın hibrit yaklaşımı aynı zamanda para çekme aralığının azaltılmasını sağlar ve kullanıcılara aktarılan her blok için pahalı kanıtlama maliyetinin dezavantajı olmadan yüksek verim elde eder.

Bunun nedeni, tek bir bloğun doğruluğunu kanıtlamak için daha öngörülebilir bir süreye sahip olmamızdır. İyimser bir hesapla, optimistik bir rollup'ta tipik 7 gün olan para çekme süresini ~8 saate düşürebiliriz (not, bu hala aktif araştırma aşamasındadır, bu değerler yaklaşık değerlerdir ve değişebilir).

FuelProver, her iki kanıtlama paradigmasının güçlü yönlerini harmanlayarak, kaçınılmaz olarak gördüğümüz ZK geleceğine doğru bir sıçrama tahtası görevi görürken, herhangi bir kısıtlamadan kaçınarak geliştiriciler için esnek ve optimum bir çözüm sağlar.

Hibrit Kanıtlama ve Finality

Hibrit kanıtlama kavramı, sahtekarlık kanıtları ile ZK kanıtlamasının birleşiminden ortaya çıkmaktadır. Dolayısıyla optimistik rollup'lar ile ZK rollup'lar arasındaki çizgide yer alan yeni bir ölçeklenebilirlik çözümleri kategorisini temsil eder. FuelProver bu yenilikçi fikrin bir uygulamasıdır.

Hibrit Kanıtlama, doğruluğu kanıtlamak için bir değil, potansiyel olarak birkaç ZK kanıtlayıcı kullanan, böylece doğruluğu kanıtlamak için tek bir ZK sistemine değil, birçok ZK sistemine güvenen bir teknik olarak tanımlanabilir. Bu, hata seviyesini azaltmak ve doğruluğu sağlamak için çeşitli türlerde sahtekarlık kanıtlama sistemlerini kullanmayı amaçlayan diğer optimistik rollup sahtekarlık kanıtlama modellerine benzer. FuelProver, gelişmiş doğruluk için çoklu kanıtlayıcı modeline doğru evrimleşmek amacıyla başlangıçta tek bir kanıtlayıcı kullanacaktır. Bu da, aynı fikrin diğer uygulamalarından (bkz. ZKFP'ler ve Hibrit rollup’lar) önemli bir farklılık ve gelişme olarak öne çıkmaktadır. Ethereum'un farklı dillerdeki çoklu istemci uygulamalarına benzer şekilde, bu çoklu-kanıtlayıcı model Fuel'in güvenlik modeline çeşitlilik ve sağlamlık katmaktadır. Bununla birlikte, hibrit kanıtlama tekniğinin Ethereum rollup ekosisteminin herhangi bir yerinde uygulanabileceğine inanıyoruz.

Optimistik rollup'larda, zincir üstü finality (kesinlik süresi) tipik olarak 7 gündür. Bu da, dijital varlıkların ana katmana geri dönmesi için güven minimize köprülemenin, dolandırıcılık ispatı sırasındaki olası gecikmelere bağlı olarak bir hafta veya daha uzun sürebileceği anlamına gelir. Hibrit kanıtlama, dolandırıcılık ispatındaki adım sayısının azaltılması sayesinde zincir üzerinde daha hızlı eyleme geçirilebilir bir sonuç elde edilmesini sağlar. Optimistik Rollup sistemleri, tarafların sansüre uğramamak için yeterli süreyle etkileşime girmeleri için bir bekleme süresi gerektirir. Hibrit kanıtlama modelinin çok sayıda etkileşim turu sırasında uzun süre beklemesi gerekmez. Teorik olarak, hibrit kanıtlama sistemi çok turlu sahtekarlık kanıtlama sistemine daha iyi bir alternatiftir çünkü her turda sansür direncini sağlamak için birkaç saat beklemek gerekmektedir.

Agnostik Bir Yaklaşım

Fuel, agnostik bir yaklaşım benimseyen bir blok zinciri işletim sistemidir, yani birçok popüler temel mimariyi desteklemeyi amaçlamaktadır. Bu, geliştiricilerin ve projelerin FuelVM’nin, araç ve paralel işlem yürütme avantajlarından yararlanırken kullanıma hazır genel amaçlı mimarilerden de daha iyi yararlanmalarını sağlar. Bu esneklik, mevcut ölçeklenebilirlik ihtiyaçlarından ödün vermeden gelecekte daha gelişmiş ZK tabanlı sistemlere daha yumuşak bir geçiş yapılmasına da olanak tanır. FuelProver; Risc Zero, zkSync, Powdr ve diğerleri dahil olmak üzere birden fazla kanıtlama mekanizmasını desteklemeyi amaçlamaktadır. Hibrit kanıtlamanın pek çok umut verici faydası olsa da FuelProver, tamamen sahtekarlık kanıtlanabilir sanal makinemiz ile oluşturulan optimistik bir seçeneği de destekleyecektir.

Geleceğe baktığımızda, bu durum Fuel'in tam bir ZK rollup'ı etkinleştirmesi ve dakikalar içinde neredeyse anlık finality’e ulaşması için umut verici bir yol sunuyor. Halihazırda birçok ZK ekibinden destek alan bu yeni hibrit yaklaşım, her iki tarafın da en iyi yönlerini sunan ve işler daha verimli hale geldikçe ve kullanıldıkça ZK ortamıyla birlikte gelişmek için ileriye dönük bir yol belirleyen güçlü bir kısa vadeli çözüm olarak duruyor.

Ethereum'da Yeni Bir Paradigmaya Adım Atın

FuelProver, Ethereum için Fuel ve ikinci katman ölçeklenebilirlik çözümlerinin gelişiminde dönüm noktası niteliğindedir. Hibrit kanıtlama modeliyle Fuel, agnostik ve modüler bir yaklaşım benimseyerek blok zincir alanındaki geliştiriciler ve kullanıcılar için yeni fırsatların önünü açıyor.

Fuel, birbirine bağlı blok zincirlerin bu yeni paradigmasına girerken, FuelProver da verimlilik, ölçeklenebilirlik ve güvenliğin kusursuz bir karışımını sağlayan güçlü bir araç olarak hizmet vermektedir. FuelV1'in temelleri üzerine inşa edilen ve optimistik rollup'ı tanıtan FuelProver, merkeziyetsiz uygulamalar için büyük bir potansiyelin kilidini açmaya yönelik bir sonraki adımı atıyor.

Modüler Yürütme Konusu

Modüler mimari, blok zincirlerin katlanarak büyümesini sağlayacaktır. Modüler yığının temel bir parçası olan yürütme katmanlarında yapılan inovasyonlar tüm hızıyla devam etmektedir.

Fuel, modüler blok zincir yığını için en hızlı yürütme katmanını inşa ediyor. Bölüm 1'de modüler yürütme katmanlarının hesaplamayı doğrulamadan ayırarak ölçeklenebilirliği nasıl sağladığını inceledik.

Ayrıca, modüler yürütme katmanlarının monolitik muadillerine kıyasla katlanarak ölçeklenmesini sağlayan ikinci bir temel faydaya daha değindik:

Monolitik zincirler, destekleyebilecekleri hesaplama hızı ve çeşitliliği konularında verimsiz teknolojilere bağlıdırlar. Öte yandan, modüler yürütme katmanları verimli hesaplama için optimize edilebilecek şekilde tasarlanabilir.

Bu yazı, ikinci temel faydaya odaklanarak Fuel'in blok zincirlerin hesaplama yönteminde nasıl devrim yarattığını incelemektedir.

Monolitik Zincirler: Birinci Katmanlarda Yinelemenin(Iterating) Zorluğu

Monolitik zincirler, hesaplama hızı ve çeşitliliği söz konusu olduğunda verimsiz teknolojilere bağlıdırlar.

Blok zincirler ilk tasarlandığında, akıllarda tek bir kullanım alanı vardı: dijital nakit. Bitcoin blok zinciri de bu dar kullanım alanı için optimize olacak şekilde tasarlandı.

Bitcoin'in ortaya çıkmasından kısa bir süre sonra, insanlar blok zincirlerin paranın çok ötesindeki kullanım potansiyelini fark etmeye başladı. Anlatı hızla "dağıtık defter"den "dağıtık bilgisayar"a kaydı. Bitcoin topluluğu bu kullanım alanını colored coin'ler aracılığıyla desteklemeye çalıştı, ancak güvenilir bir dağıtık hesaplamayı destekleyecek kadar çok yönlü olmadığı açıktı; orijinal kullanım alanına kilitli kalmıştı. Yeni bir mimari gerekliydi.

Bu sorunun farkına varan Ethereum yaratıcıları, dağıtık olan ve Turing testini geçen bir blok zincir oluşturmak için yola çıktılar, yani Ethereum Sanal Makinesi EVM’i. Ethereum'un 2015 yılında piyasaya sürülmesiyle birlikte blok zincirler, güvene dayalı olmayan bir ortamda rastlantısal hesaplamayı destekleyecek şekilde gelişmiştir. Artık herkes bir bilgisayar programı (akıllı sözleşme) oluşturup çalıştırabilir ve bunun dağıtık bir bilgisayarda çalışmasını sağlayabilir.

Ethereum, blok zincir kavramının ortaya çıkmasından 5 sene kadar bir süre sonra tasarlandı. Ethereum'un piyasaya sürülmesinden bu yana geçen 7 yıl içinde, Ethereum'un Bitcoin'e kıyasla kaydettiği ilerlemeden çok daha büyük bir ilerlemeyi temsil eden yeni kavramlar keşfedildi. Ancak Bitcoin gibi Ethereum da çoğunlukla ilk baştaki çekirdek mimarisine bağlı durumda.

Ethereum’da ve EVM'de yıllar içinde yapılan her iyileştirme için, geriye dönük uyumluluğu sürdürme ihtiyacı nedeniyle uygulanamayan birçok potansiyel yenilik vardır.

Sonuç olarak, blok zincir topluluğu her yeni inovasyon ortaya çıktığında yeni blok zincirleri finanse etmeye, inşa etmeye ve piyasaya sürmeye devam etti. Birçok yeni 1.katman blok zincir, güven gerektirmez ve dağıtık bilgi işlem kavramını yineleme vaadiyle piyasaya sürülmekte, ancak hepsi aynı zorlukla karşılaşmakta: yeni işlevleri ve iyileştirmeleri desteklemek için blok zincirleri upgrade etmek zor (ve çoğu zaman imkansız).

Ve böylece, öncekilere kıyasla parça parça iyileştirmelerle piyasaya sürülen yeni blok zincirler görmeye devam ettiğimiz döngü devam ediyor. Bu süreçte, likidite, fonlama, kullanıcı deneyimi ve geliştirici fikir paylaşımının giderek daha fazla bölündüğü, çoğunlukla uyumsuz blok zincirlerden oluşan bir ekosistemle baş başa kaldık. Bu arada, gerçek inovasyon için harcanabilecek enerji bunun yerine yatırımcıların, geliştiricilerin ve son kullanıcıların dikkatini çekmeye yönlendiriliyor.

Crypto has a serious problem.We're stuck in an endless cycle of new L1 smart contract platforms. Each purport to fix the problems of the L1s in the previous cycles.These L1s rinse and repeat the same bizdev strategy of prior L1s, building copy-cat DeFi & NFT ecosystems. pic.twitter.com/wsrva4f5RD

— Mustafa Al-Bassam 🧱 (@musalbas) October 18, 2022

Rekabet sağlıklıdır ve gelişen bir ekosistem için gereklidir. Ancak bu rekabet yanlış düzeyde gerçekleşiyor.

Modüler blok zinciri paradigması bu sorunu çözmeyi vaat ediyor. Modüler yığındaki her katman diğerlerinden bağımsız olduğu için, tüm yığının tamamen elden geçirilmesine gerek kalmadan bir katmanda yenilik yapılabilir. Yürütme katmanları yürütme konusunda rekabet edebilir. Veri kullanılabilirliği katmanları veri kullanılabilirliği konusunda rekabet edebilir. Her katman, geriye dönük uyumluluğu bozmadan kendi amacı için optimize edilebilir.

Paylaşılan uzlaşma katmanları likiditenin tek bir yerde toplanmasını sağlar, böylece likiditeyi parçalamadan veya son kullanıcı deneyiminde aksaklık yaratmadan yeni yürütme katmanları oluşturulabilir. Güven minimize edilmiş köprü kurmanın native olarak etkinleştirilmesi, topluluğun birlikte çalışabilirlik çabaları için harcanan kaynakları azaltabileceği ve bunun yerine anlamlı yenilikleri keşfetmeye odaklanabileceği anlamına gelir.

Modüler yığının ortaya çıkmasıyla, gösterişli ölçütlerle rekabet eden birinci katmanlardan oluşan farklı bir ekosistemden uzaklaşıp daha uyumlu, birlikte çalışabilir, upgrade edilebilir bir yığına doğru ilerleyebiliriz.

We believe innovation does not require launching a new L1, but can happen at the execution layer

— Fuel Labs (@fuellabs_) September 13, 2022

Modüler Yürütme: EVM'nin Ötesine Geçmek

EVM'nin orijinal tasarımı üzerinde iyileştirmeler vaat eden çok sayıda birinci katman blok zincire rağmen, ilk hamle avantajı EVM'nin blok zincir ekosisteminde "varsayılan" runtime ortamı olarak bir yer edinmesini sağladı. Akıllı sözleşme geliştirme, Solidity (EVM'nin programlama dili) ile eşanlamlı hale geldi ve bu da blok zincir geliştiricilerinin çoğunu ele geçirdi. Bu nedenle, şu anda geliştirilmekte olan yürütme katmanlarının çoğu EVM tabanlı roll-up'lardır.

Bunun iyi bir nedeni vardır: EVM'yi kullanmak, rollup'ların Solidity'de yazılmış mevcut uygulamalardan oluşan bir piyasaya ve bu uygulamalara zaten aşina olan geniş bir son kullanıcı grubuna ulaşmasını sağlar. EVM, geliştirici sektöründe zaten büyük bir paya sahip olduğu için yeni bir ekosistemin temelini atmak için harika bir araçtır.

Ancak, daha önce de incelediğimiz gibi, geriye dönük uyumluluğu sürdürme ihtiyacı, EVM'nin birçok yeniliğe adapte olamadığı anlamına gelmektedir. Buna ek olarak, EVM'nin çekirdek tasarımı modüler bir yığın için değil, monolitik bir zincir için optimize edilmiştir.

EVM'nin bazı sınırlamaları şunlardır:

• Sıralı Yürütme - EVM paralel işlem yürütmeyi desteklemez, bu da onu diğer VM tasarımlarına göre hesaplama açısından çok daha verimsiz hale getirir.

• Sahtekarlık Kanıtları - Ethereum'un hesap tabanlı(account-based) modeli, EVM zincirlerinde sahtekarlık kanıtları oluşturmanın ve yürütmenin son derece maliyetli ve verimsiz olduğu anlamına gelir, bu da modüler yürütme katmanları için ideal değildir.

• Solidity - EVM için en popüler programlama dili olan Solidity, kötü bir geliştirici deneyimi sunmasıyla ünlüdür ve güvenli akıllı sözleşmeler yazmayı zorlaştıracak şekilde tasarlanmıştır.

Fuel: Modüler Yürütme için Optimize Edildi

Modülerliğin ortaya çıkışı, yürütme katmanlarının EVM'nin sınırlamaları tarafından kısıtlanmadan Ethereum'un likiditesinden ve güvenliğinden yararlanabilmek anlamına gelir.

Yeni ve geliştirilmiş VM tasarım ilkelerini benimseyen modüler yürütme katmanları, verimli ve ölçeklenebilir hesaplama, üstün geliştirici deneyimi ve maksimum güvenlik için optimize edilebilir.

Fuel, en hızlı modüler yürütme katmanını oluşturmak için bu yeni tasarım alanından yararlanıyor.

FuelVM

Fuel'in temel yeniliklerinden biri tamamen yeni bir sanal makine olan FuelVM'dir. Ethereum üzerine inşa edilen yürütme katmanlarının ortaya çıkışı, geriye doğru uyumlu olma ihtiyacı ile kısıtlanmadan geçmiş VM tasarımlarını geliştirmek için yeni bir fırsat sunuyor.

EVM'nin yavaş işlem yürütmesi, bant genişliğinin temel darboğaz olduğu modüler öncesi bir dünyada yeterli olabilirken, yeni modüler yığın içinde (1.Katman Ethereum dahil) yapılan iyileştirmeler, ölçeklendirme söz konusu olduğunda hesaplama veriminin birincil kısıtlama haline geldiği anlamına geliyor.

Bu yeni paradigma göz önünde bulundurularak geliştirilen FuelVM, hızlı işlem yürütme için optimize edilecek şekilde tasarlanmıştır. EVM, Solana, WASM, Bitcoin ve Cosmos'tan dersler çıkaran FuelVM, geleneksel blok zincir sanal makine mimarilerinin savurgan işlemlerini azaltmak ve geliştiriciler için potansiyel tasarım alanını artırmak üzere tasarlanmıştır.

FuelVM, EVM topluluğu tarafından önerilen ve desteklenen, ancak geriye dönük uyumluluğu sürdürme ihtiyacı nedeniyle uygulanamayan birçok yeniliği bünyesinde barındırmaktadır. Bazı örnekler aşağıda vurgulanmıştır (tam liste için buraya bakın).

Sway ve Forc ile Üstün Geliştirici Deneyimi

Fuel protokol, geliştirici deneyimi ön planda tutularak tasarlanmıştır. FuelVM, kendisine eşlik eden Sway dili ile birlikte geliştirilmiştir. Sway, özellikle blok zincir sanal makinesinden yararlanmak için tasarlanmış, Rust tabanlı, domain'e özgü(domain specific) bir dildir. EVM'nin oluşturulmasından sonra geliştirilen Solidity'nin aksine, Sway, kullanışlı ve verimli çalışma özelliklerine sahip olacak şekilde sıfırdan oluşturulmuştur. Fuel, Sway’i Rust temelli yaratarak güçlü statik analiz ve derleyici geri bildirimi kullanmış ve akıllı sözleşme geliştirmeyi daha güvenli ve daha performanslı hale getirmiştir.

Tooling perspektifinden bakıldığında Fuel, Forc toolchain kullanarak EVM ekosistemini geliştirmektedir. Forc ile geliştiriciler, FuelVM için Sway uygulamaları oluşturmaya başlamak için ihtiyaç duydukları her şeyi tek bir toolchain ile elde edebilirler. Fuel, yalnızca yığının alt seviyelerini (protokol ve VM uygulamaları gibi) değil, aynı zamanda üst seviyelerini de (paket yönetimi, editör desteği, ortak kullanım eklentileri ve çok daha fazlası gibi) kapsayan kapsamlı, standartlaştırılmış, modüler bir yaklaşım benimser.

Writing dapps on Fuel is honestly so nice because you don't have to configure wagmi, hardhat/foundry, ethers.js. You don't have to copy/paste your ABI in your front-end project. All the tooling is integrated seamlessly and just works.Better developer experience 🤝 Ethereum

— cami ᵍᵐ (@camiinthisthang) October 5, 2022

Fuel'in geliştirici ortamı, Solidity gibi akıllı sözleşme dillerinin avantajlarını korurken, Rust tooling ekosisteminde sunulan paradigmaları benimseyerek Sway için öğrenme eğrisini tüm geliştirici deneyimi seviyeleri için kolayca yönetilebilir hale getirir.

Paralel İşlem Yürütme

Modern işlemciler giderek çok parçacıklı hale geldikçe işlemlerin paralel yürütülebilmesi, oldukça arzu edilen bir özelliktir. Dolayısıyla bu konu, Fuel protokol tasarlanırken temel husus olmuştur.

Paralel işlem yürütme, işlemler arasındaki ilişkileri belirleme ve ele alma becerisi gerektirir. İşlemleri ayrı çekirdekler üzerinde işlerken çakışmayı önlemek için, her bir işlem tarafından temas edilebilecek durum paylaşımlarının(shared state) önceden ("erişim listeleri" aracılığıyla) tanımlanması gerekir, böylece işlemler(transactions) birbirleriyle olası etkileşimleri olmayan kümelere ayrılabilir.

Hesap tabanlı tasarımının kısıtlamaları nedeniyle, Ethereum bu erişim listelerini destekleyememektedir, bu nedenle işlemleri sırayla (yani birbiri ardına) işlemek zorunda kalmaktadır. EIP-648, Ethereum'a erişim listelerinin eklenmesini önermiştir, ancak bu, getireceği diğer verimsizlikler nedeniyle hiçbir zaman uygulanmamıştır.

Bu sınırlamadan ders alan Fuel, UTXO modeli şeklinde katı durum erişim listeleri uygulayarak, tek iş parçacıklı blok zincirlerinde tipik olarak boşta olan birden fazla CPU iş parçacığı ve çekirdeği kullanma yeteneği kazandırmıştır. Sonuç olarak Fuel, işlemleri paralel olarak yürütebilir ve tek iş parçacıklı benzerlerine göre çok daha fazla işlem, durum erişimi(state access) ve işlemsel verim sağlar.

Fuel’s support for parallel transaction execution means validators can maximize efficiency by using all of their hardware (source: Fuel)

Verimlilik optimizasyonları sağlamanın yanı sıra, birden fazla işlemi paralel olarak işleme yeteneği, bu işlemleri doğrulamak için kaynak gereksinimlerinde karşılaştırılabilir bir artış olmadan işlem hacminin ölçeklenmesini sağladığından güvenlik iyileştirmelerine olanak tanır. Bu, node çalıştırmanın önündeki engeli azaltarak daha merkeziyetsiz bir doğrulayıcı ağına olanak tanır.

Sahtekarlık Kanıtları için Optimize Edildi

Sahtekarlık kanıtları, modüler blok zinciri yığınında temel bir teknolojidir. Bölüm 1'de, modüler yürütme katmanlarının, yalnızca tek bir dürüst node’un mevcut olduğu varsayımı altında güvenliğe olanak tanıyan, güven minimize edilmiş hafif istemcileri(light client) etkinleştirmek için dolandırıcılık kanıtlarından nasıl yararlanabileceğini inceledik.

Güven minimize edilmiş hafif istemciler ve paylaşılan uzlaştırma ve veri kullanılabilirliği katmanları ile modüler yürütme katmanları arasında güven minimize edilmiş köprüler kurmak mümkündür ki bu L1'ler arasında başarılması imkansız bir şeydir. Bu, güvenlik veya likiditeyi bölmeksizin yeni blok zinciri tasarımlarının denenmesine ve uygulanmasına olanak tanır.

Sahtekarlık kanıtlarının sağladığı faydalar nedeniyle Fuel, özellikle düşük maliyetli ve verimli bir şekilde sahtekarlık kanıtlanabilir olacak şekilde tasarlanmış ve geliştirilmiştir.

Ethereum'un hesaba dayalı modeli, sahtekarlık kanıtları oluşturmanın maliyetinin sınırsız olduğu anlamına gelirken, Fuel UTXO modelini kullanarak sahtekarlık kanıtları için optimize edilmiştir. UTXO sahtekarlık kanıtları, küresel bir durum ağacına(state tree) başvurmak zorunda kalmadan, bir UTXO'nun her harcamasının UTXO'nun oluşturulmasına "işaret etmesini" gerektirerek verimlilik sağlar. Ya a) işaretçinin geçersiz olduğunu ya da b) işaret edilen şeyin harcanan şeyle eşleşmediğini kanıtlamak, sahtekarlığı kapsamlı bir şekilde kanıtlamak için yeterlidir.

Ek bir avantaj olarak, FuelVM komut seti EVM içinde sahtekarlığa karşı kanıtlanabilir olacak şekilde tasarlanmıştır. Bu, Fuel'in Ethereum'u bir uzlaşma katmanı olarak kullanabileceği, derin likiditesinden ve geniş kullanıcı tabanından yararlanırken EVM'nin sınırlamaları ile kısıtlanmadan kalabileceği anlamına gelir.

Diğer Avantajlar

Yukarıdaki noktaların yanı sıra Fuel, aşağıdakiler de dahil olmak üzere bir dizi başka iyileştirmeyi de kullanmaktadır:

• Birden fazla yerel varlığı destekleme

• Yerel hesap soyutlama ve predicate’ler

• Çok boyutlu kaynak fiyatlandırması

• Sıralayıcı(sequencer) merkeziyetsizleştirme

Bu iyileştirmelerin bir açıklaması bu makalenin kapsamı dışındadır, ancak Blockchain Capital bu ek avantajlarla ilgili derinlemesine bir yazı yayınlamıştır.

Özet

• Monolitik paradigma, gösteriş ölçütleri üzerinde rekabet eden, likiditeyi, finansmanı ve geliştirici fikir paylaşımını parçalayan uyumsuz birinci katman blokzincirlerden oluşan bir ekosisteme neden olmaktadır. Fuel, inovasyonun yeni bir birinci katman başlatmayı gerektirmediği, ancak uygulama katmanında gerçekleşebileceği önermesini benimser.

• Modüler mimari, Fuel gibi MEL'lerin geriye dönük uyumluluk konusunda endişelenmeden verimli hesaplamaya odaklanmasını sağlar. Daha hızlı hesaplama yalnızca daha yüksek verim sağlamakla kalmaz, aynı zamanda doğrulayıcıların(validator) çalıştırılmasını daha verimli hale getirerek merkeziyetsizliği geliştirir. Bu da, Fuel'in EVM'nin verimsizlikleri tarafından engellenmeden Ethereum'un ölçeklenebilirliğine katkıda bulunmasını sağlar.

• EVM kullanan yürütme katmanları, Solidity uygulamaları ve geliştiricilerinin mevcut ekosisteminden faydalanabilir, ancak modüler yığının sunduğu tasarım alanından en iyi şekilde yararlanamaz. Fuel, bu yeni tasarım alanını, sahtekarlığa karşı kanıtlanabilir olmak ve en iyi geliştirici deneyimini sağlamak için sıfırdan tasarlanan FuelVM ile kullanmaktadır.

• Fuel, hızla yaklaşan modüler gelecek için optimize edilmiş yenilikler sunarak #MonolitikÖtesi ‘ne geçen yeni nesil blok zincirlere olanak sağlamaktadır.

Modüler yürütme katmanları, hesaplama ile doğrulamayı birbirinden ayırarak ölçeklenmeyi nasıl sağlayacaklar?

Modüler Yürütme Konusu

Blok zincirler, gerçek ölçeklenebilirliğe ulaşabilmek için giderek daha fazla modüler mimariye doğru ilerlemektedir. Daha önce tamamen monolitik olan Ethereum gibi zincirler bile monolitik blok zincir tasarımlarının getirdiği zorlukların üstesinden gelebilmek için modüler tasarıma geçmektedir.

Modüler blok zincirlerin temel bileşenlerinden biri yürütme katmanıdır. Fuel, modüler blok zincirleri için en hızlı yürütme katmanını inşa etmektedir.

Modüler yürütme katmanı ne demektir? Ve daha ölçeklenebilir blok zincir sistemlerini nasıl mümkün kılacaktır?

Modüler yürütme katmanları, monolitik rakiplerine göre iki temel avantaj sunar:

1. Monolitik zincirler hesaplama ve doğrulamayı aynı katmanda birleştirir, bu da düşük seviyede güvenlik ve sınırlı bir ölçeklenebilirliğe sebep olur. Modüler yürütme katmanları ise, hesaplama ve doğrulamayı birbirinden ayırarak bu sorunu önler ve çok daha yüksek seviye bir güvenlik sağlar.

2. Monolitik zincirler, destekleyebilecekleri hesaplama hızı ve çeşitliliği konularında verimsiz teknolojilere bağlıdırlar. Öte yandan, modüler yürütme katmanları verimli hesaplama için optimize edilebilecek şekilde tasarlanabilir.

Bu yazıda birinci temel fayda üzerinde durulacak, ikincisi ise daha sonra yayınlanacak olan ikinci bölümde ele alınacaktır.

Monolitik Blok Zincirlerin Temelleri: Hesaplama ve Doğrulama

Modüler yürütme katmanlarının (MYK’ler) getirdiği yenilikleri anlamak için öncelikle monolitik blok zincirlerin hesaplama ve doğrulamayı nasıl ele aldığını anlamamız gerekir.

Blok zincirler, işlemleri gerçekleştiren ve bunları bir blokta bir araya getiren(bunlara blok üreticileri denir) bir varlıklar ağına dayanır. Denetimler ve bakiyeler olmadan, kötü niyetli bir blok üreticisi bir bloğa geçersiz işlemler dahil edebilir (örneğin, kendi adresine token basmak). Bunu önlemek için blok zincirleri, zincirin kendi versiyonuna eklemeden önce bir bloğun geçerliliğini belirlemek için diğer node’lardan oluşan bir ağa güvenir.

Bu da bir blok zincirin çalışması için gereken iki temel işlevi ortaya çıkarır:

• Blok Üretimi (hesaplama) - Bir bloğu oluşturmak için işlemlerin yürütülmesi ve münferit durum geçişlerinin(individual state transitions) uygulanmasıdır.

• Blok Doğrulama (onaylama) - Durum geçişlerinin geçerli olduğunun teyit edilmesidir.

Monolitik Zincirlerde Hesaplama ve Doğrulama

NOT: Kolay anlaşılması için bu bölümde blok üretiminin ve doğrulamasının monolitik blok zincirlerde nasıl işlediğine dair basitleştirilmiş bir açıklama sunulmaktadır. Gerçekte bu süreç daha karmaşıktır ve zincirin tasarımına bağlı olarak farklılık gösterebilir. Ancak, temel ilkelerin çoğu geçerlidir.

Çoğu monolitik blok zincir tasarımında, hesaplama ve doğrulama validatörler (yani node’lar) tarafından gerçekleştirilir. Kullanıcı bir işlem gönderdiğinde, bir validatör işlemi gerçekleştirir ve ardından ilgili durum geçişini bir bloğa ekler. Bir blok oluşturulduktan ve paylaşıldıktan sonra, diğer node’lar bloğu indirir ve geçerli olduğunu teyit etmek için bloktaki işlemleri yeniden yürütür. Blok geçerliyse, dürüst olduklarını varsayarak, node’lar bu bloğu zincirin kendi versiyonlarına ekler ve böylece geçerliliğini onaylar.

Bazen uygulamalar veya kullanıcılar blok zincirin durumuna(state) erişmek isterler ancak tam bir node çalıştırmanın ve tüm işlemleri doğrulamanın gerektirdiği yüksek kaynak gereksinimlerine katlanmak istemezler. Bu amaçla, node’lar tarafından sağlanan blokların yalnızca geçerli işlemleri içerdiğini varsayan hafif istemciler çalıştırabilirler. Blok zincirin tamamını indirmezler ya da önceki tüm işlemlerin geçerli olduğunu doğrulamazlar. Bunun yerine, node’ların çoğunun dürüst olduğuna (yani zincirin kendi kopyalarına yalnızca geçerli blokları dahil ettiklerine) güvenmek zorundadırlar.

Buna dürüst çoğunluk varsayımı denir ve çoğu monolitik blok zincirin %51 saldırılarına karşı savunmasız olmasının nedenidir. Monolitik modelde, blok zincirin geçerli olduğunu(valid) doğrulamak için node’ların dürüst çoğunluğu olması gerektiğinden, hafif istemciler(light client) bu çoğunluğa güvenmek zorunda kalır. Node’ların yarısından fazlası dürüst değilse, hafif istemcilerin bunu bilmesinin bir yolu yoktur, bu nedenle de geçersiz bir zinciri takip edeceklerdir.

Dürüst Çoğunluk Varsayımı – Ölçeklenmenin Önündeki Engel

Monolitik zincirlerin ölçeklenebilirliği, bu dürüst çoğunluk varsayımına dayanmaları nedeniyle ciddi şekilde sınırlıdır. Bunun nedeni, işlem verimini artırmak için, aynı süre içinde daha fazla işlemin işlenmesini sağlamak üzere blok boyutunun ve/veya sıklığının artırılmasının gerekmesidir. Bu da node’lar için kaynak gereksinimlerini (ve ilgili maliyetleri) artırır; daha büyük/hızlı bloklar = daha fazla hesaplama = daha yüksek maliyet demektir.

Node çalıştırmanın maliyeti arttıkça, giderek daha fazla sayıda kullanıcı hafif bir istemci çalıştırmayı tercih edecek ve zincirin doğruluğunu onaylamak için giderek daha küçük bir node ağına güvenilecektir. Blok doğrulamasının giderek merkezileşmesi, monolitik zincirler için güvenlik açısından büyük bir tehdittir çünkü daha merkezi bir doğrulayıcı havuzu saldırılara karşı daha savunmasızdır ve bu doğrulayıcıların aralarında gizli anlaşma yapmaları daha kolaydır.

Modüler Yürütme: Hesaplama ve Doğrulamanın Ayrıştırılması

İyi haber şu ki, blok zincir sistemleri dürüst çoğunluk varsayımına dayanan tasarımlardan uzaklaşabilir. Monolitik tasarımın bu tuzağından kaçınmak için modüler blok zincir yığını(stack), hesaplamayı doğrulamadan ayırır. Yürütmeyi (yani hesaplamayı) temel zincirden (genellikle "ana zincir" olarak adlandırılır) uzaklaştırarak, merkeziyetsizlikten ödün vermeden daha fazla ölçeklenme elde edilebilir.

Modüler Yürütme Katmanı nedir?

Modüler blok zinciri yığını içinde yürütme katmanı, işlemlerin işlenmesi ve tekil durum geçişlerinin gerçekleştirilmesi gibi hesaplamalardan sorumludur.

Fuel, modüler yürütme katmanını: modüler blok zinciri yığını için tasarlanmış doğrulanabilir bir hesaplama sistemi olarak tanımlar. Daha somut bir ifadeyle, veri kullanılabilirliği için modüler bir blok zincirden yararlanan, dolandırıcılık veya geçerlilik kanıtlı bir blok zincir (veya başka bir hesaplama sistemi).

Biraz daha açmak gerekirse, hesaplama sistemleri aşağıdaki durumlarda modüler yürütme katmanları değildir: 1) sahtekarlık veya geçerlilik kanıtlı değillerse veya 2) veri kullanılabilirliğini başka bir katmana yüklemiyorlarsa.

Monolitik blok zincirler gibi, modüler yürütme katmanları da kendilerine özel blok üreticilerinden oluşan bir ağ kullanır. Bu birimler, işlemlerin yürütülmesi ve blokların üretilmesi gibi yoğun kaynak gerektiren süreçlerle ilgilenir. Ancak, monolitik sistemlerden farklı olarak, doğrulama işlemi yürütme katmanında değil, modüler blok zincir yığınının daha alt seviyelerinde gerçekleştirilir.

Doğrulama - Blok Üreticilerini Dürüst Kılmak

Modüler yürütmenin dehası, doğrulamanın (yani blok doğrulama) merkeziyetsiz olduğu sürece, hesaplamanın (yani blok üretiminin) merkeziyetsiz olmasına gerek olmamasıdır. Blok boyutlarının artırılması blok üreten node’ların merkezileşmesine yol açar ancak doğrulama ayrıldığı sürece, geçersiz bloklar zincire eklenmeyecektir.

Fakat bu nasıl mümkün olabilir? Blok üretiminin merkezi olarak kalmasına izin verirsek güvenliğin korunmasını nasıl sağlayabiliriz? İşte bu noktada modülerlik devreye giriyor.

Modüler yürütme katmanları, yoğun kaynak gerektiren yürütme işlevini, işlem gruplarını bir araya getirip yürüten ve bunları bloklar halinde periyodik olarak ana zincire (uzlaşma/ konsensüs/ veri erişilebilirliği katmanları) gönderen güçlü blok üreticilerine devreder. Bu blok üreticilerini dürüst kılmak ve blokların yalnızca geçerli işlemleri içerdiklerinden emin olmak için ana zincire gönderilen blokları indiren ve yeniden yürüten, blok üretmeyen ek node’lar (bunlar genellikle "doğrulayıcılar" veya "kanıtlayıcılar" olarak adlandırılırlar) vardır.

Bu node’ların işlemlerin geçerliliğini veya geçersizliğini nasıl ilettiğinin özellikleri, modüler yürütme katmanının optimistik model ya da sıfır bilgi(zk) modeli kullanmasına bağlı olarak farklılık gösterir. Optimistik modüler yürütme katmanları söz konusu olduğunda, node’lar yalnızca geçersiz bir işlem tespit ettiklerinde harekete geçerler (sahtekarlık kanıtları aracılığıyla). Tersine, sıfır bilgi(zk) modüler yürütme katmanlarında, node’lar işlemlerin geçerliliğini aktif olarak onaylar (geçerlilik kanıtları aracılığıyla). Her iki durumda da, blok üreticisi tarafından sağlanan tüm işlemlerin geçerliliği veya geçersizliği modüler yürütme katmanında değil, ana zincirde onaylanır.

Bir Örnek: Optimistik Modüler Yürütme Katmanlarında Dolandırıcılık Kanıtları

Daha detaylı bir örnek sunmak için optimistik modüler yürütme katmanlarının (aksi kanıtlanmadıkça tüm işlemlerin geçerli olduğunun varsayıldığı) durumunu inceleyelim. Modüler yürütme katmanındaki tek bir node bile ana zincirde yayınlanan bir blok içinde geçersiz bir işlem tespit ederse, işlemin geçersiz olduğunu kriptografik olarak kanıtlayan bir sahtekarlık kanıtı (önceden tanımlanmış bir "uyuşmazlık çözüm süreci" içinde) oluşturabilir.

Bu durum, belirli bir modüler yığının yapısına bağlı olarak çeşitli şekillerde ele alınabilir. Örneğin:

Uzlaşma katmanına sahip modüler zincirlerde:

• Node’lar, sahtekarlık kanıtını, işlemi doğrudan yeniden yürüten uzlaşma katmanındaki özel bir anlaşmazlık çözüm sözleşmesine sunar (bunun, modüler yürütme katmanı işlemlerinin, uzlaşma katmanının sanal makinesinde deterministik bir şekilde sahtekarlık kanıtlanabilir hale getirecek şekilde yapılandırılmasını gerektirdiğini unutmayın - örneğin, FuelVM, Ethereum'da uzlaşmayı sağlayabilmek için EVM içinde sahtekarlık kanıtlanabilir olacak şekilde tasarlanmıştır).

• Eğer işlem geçersizse, suç işleyen blok üreticisi slashing yoluyla cezalandırılır (yani fon kaybeder), "ihbarcı" bu fonların bir kısmı ile ödüllendirilir ve zincirin durumu geçersiz işlem öncesine döndürülür. Geçersiz işlemi takip eden herhangi bir işlemin geçerli bir duruma karşılık geldiğine dair bir garanti olmadığından, sonra gelen bu işlemler yeniden gerçekleştirilir.

Uzlaşma katmanına sahip olmayan modüler zincirlerde:

• Node, hafif istemcileri bloğun geçersiz bir işlem içerdiği konusunda uyarmak için eşten eşe sistemle (p2p) sahtekarlık kanıtını iletir. Sahtekarlık kanıtını blok üreticisinin dürüst olmayan davranışının kanıtı olarak kullanan node’lar, ana zincirde blok üreticisinin fonlarını kesen bir ceza işlemi önerebilir.

• Zincirin "meşru" versiyonunu saptayacak bir uzlaşma katmanı olmadığından, kötü niyetli node’lar teorik olarak bloğu reddetmemeyi seçebilir; ancak, sahtekarlık kanıtı zaten hafif istemcilere iletildiğinden hafif istemciler, kötü niyetli bir node’un zincir versiyonunu takip etmemeleri gerektiğini bilirler. Sonuç olarak, sosyal konsensüs geçersiz bloğun reddedileceğini taahhüt eder.

Her iki durumda da, doğrulama süreci yürütme katmanı yerine ana zincirde yer aldığından, güvenlik ana zincire devredilir. Yani yürütme katmanı kendi başına daha düşük güvenlik garantisiyle çalışabilir. Yürütme katmanındaki node’ların %99'u dürüst olmasa bile, yürütme katmanında yalnızca geçerli işlemlerin olmasını sağlamak için sadece bir dürüst node yeterlidir.

Bu, node’ların dürüst çoğunluğuna güvenmek yerine, modüler yürütme katmanlarının (ve modüler yürütme katmanı hafif istemcilerinin) tek bir dürüst çoğunluk varsayımıyla çalışabileceği anlamına gelir.

Monolitik sistemdeki geçersiz bir blok sadece node’ların çoğunluğu tarafından geri döndürülebilirken, modüler bir sistemdeki tek bir node, sahtekarlık/geçerlilik kanıtlarını kullanarak geçersiz bir işlemi geri döndürmeye zorlayabilir.

Bu Durum Ölçeklenebilirliği Nasıl Sağlar?

Hesaplamanın ana zincir dışında yapılması, işlem hacminde büyük artışlara sebep olur. Ayrı gerçekleşen blok doğrulama süreci blok üreticilerini dürüst hale getirdiğinden, blok üretiminin merkezileştirilmesi endişesi olmadan blok boyutu önemli ölçüde artırılabilir.

Daha büyük bloklar, doğrulama yapan tüm node’lara daha fazla yük bindirse de, dürüst olmayan bir çoğunluğa dayanan merkezileştirme tabanlı güvenlik açıkları imkansız hale geldiğinden, dürüst olmayan çoğunluk varsayımı, bu alandaki merkezileşmenin daha az tehdit olduğu anlamına gelir.

Hafif istemcilerin node’ların en az yarısının dürüst olduğuna güvenmesini gerektiren monolitik sistemlerin tersine, hafif istemciler modüler bir mimari altında çok daha yüksek güvenlikle çalışabilir, çünkü sahtekarlık kanıtları, tek bir dürüst node’dan gelen bir kanıta dayalı olarak geçersiz işlemleri tanımlamalarını sağlar.

Buna ek olarak, blok üreticileri herhangi bir kötü niyetli faaliyetin tespit edileceğinin ve ‘slashing’ ile sonuçlanacağının farkındadır, bu nedenle dürüst olmayan bir davranışa teşebbüs etme olasılıkları daha düşüktür. Bu nedenle, yürütme katmanı, modüler yığının güvenlik açısından optimize edilmiş alt seviyelerine dayanırken, hesaplama açısından optimize edilebilir (yani çok sayıda işlem gerçekleştirebilir).

Modüler Yürütme: Potansiyel Zorluklar

Modüler mimari, bazı teknik ve oyun teorisi zorluklarını da beraberinde getirmektedir.

Veri Erişilebilirliği

Sahtekarlık/geçerlilik kanıtları dürüst node’ların sahtekarlığı kanıtlamasını sağlarken, ek bir sorun daha vardır: veri erişilebilirliği. Kanıt oluşturmak ve geçerliliğini belirlemek için bir bloktaki tüm işlemleri indirmeleri ve yeniden yürütmeleri gerektiğinden, node’lar blok erişilebilirliğine güvenirler.

Kötü niyetli bir blok üreticisi, teorik olarak ana zincire yalnızca blok başlıklarını yollayabilir ve potansiyel olarak ilgili verilerin bir kısmını veya tamamını saklayabilir. Bu durum, node’ların hafif istemcileri konu hakkında uyarmak için sahtekarlık/geçerlilik kanıtları oluşturabilmesini engeller.

Bir bloğu doğrulamaya çalışırken, verilerin kötü niyetli bir blok üreticisi tarafından saklandığını tespit etmek node’lar için önemsizdir. Bu durumda, kolaylıkla zincirin geçersiz olduğunu varsayabilir ve ondan uzaklaşabilirler. Ancak hafif istemciler, tüm bloğu indirmeden verilerin bir blok üreticisi tarafından saklanıp saklanmadığını nasıl belirleyebilir?

Veri erişilebilirliği örneklemesi (Data Availability Sampling-DAS) adı verilen yeni bir teknoloji, hafif istemcilerin bir bloğun tamamının yayınlanıp yayınlanmadığını olasılıksal olarak belirlemesini sağlar. Kısacası, hafif istemciler node’lardan bloğun rastgele küçük bölümlerini (veya "örneklerini") talep eder.

İstenen tüm örnekler mevcutsa, veri erişilebilirliği örneklemesi yapan yeterli sayıda hafif istemci olduğu varsayılırsa, bu olasılıksal olarak tüm bloğun mevcut olduğunu kanıtlar. Bloğun herhangi bir kısmı mevcut değilse, hafif istemciler verilerin saklandığını bilir ve zincirin o versiyonundan uzaklaşabilir.

Bu teknolojinin daha detaylı açıklaması bu yazının kapsamı dışındadır, ancak daha fazlasını buradan okuyabilirsiniz. Sonuç olarak Veri Erişilebilirliği Örneklemesi, kötü niyetli bir blok üreticisi verileri saklasa bile hafif istemcilerin geçersiz blokları tespit etmesini sağlar.

Doğrulayıcı İkilemi(Verifiers Dilemma)

** **Bir diğer potansiyel sorun ise " doğrulayıcı ikilemi" olarak adlandırılan olgudur. Basitleştirilmiş haliyle aşağıdaki gibidir:

• Eğer blok üreticileri, node’ların dürüst olmayan faaliyetleri tespit edeceğini bilirlerse, slash’ten kaçınmak için dürüst davranacaklardır.

• Zaman içinde, node’lar blok üreticilerinin dürüst davranmaya devam edeceğini varsayarsa, geçersiz bir işlemi tanımladıkları için asla ödül almayacaklarından blokları doğrulamaya devam etmek için hiçbir teşvikleri kalmaz.

• Node’lar blokları doğrulamaya devam etmek için finansal olarak teşvik edilmezlerse, bunu yapmayı bırakabilirler. Bu noktada, blok üreticilerinin usulsüz şekilde davranması mümkün hale gelir. Hala sıfır olmayan miktarda node olsa bile, blok üreticisinin kalan node’lara geçersiz işlemleri görmezden gelmeleri için rüşvet vermesi finansal olarak mantıklı hale gelebilir.

Bu durum, modüler bir yürütme katmanının ne kadar güvenli hale gelirse (yani bir blok üreticisinin dürüst davranmaması için daha az teşvik varsa), daha düşük güvenliğe doğru o kadar fazla eğilim gösterdiği (yani node’ların artık blokları doğrulamaya teşvik edilmediği) döngüsel bir muamma ile sonuçlanır. Öte yandan, ne kadar az güvenli olursa, o kadar yüksek güvenlik eğilimi gösterir.

Bu ikilem bir takım yollarla hafifletilebilir (bu faktörlerin oyun teorisini baz alan analizi için bu yazıya bakınız):

• Fedakarlık - Modüler Yürütme Katmanları yalnızca tek bir dürüst doğrulayıcı gerektirdiğinden, en az bir fedakar node çalıştığı sürece sistem güvenli kalırlar. Ancak bu, pratikte yeterince güvenli olsa da, büyük miktarda varlığı kontrol eden bir sistem için yeterli bir garanti değildir.

• Ekonomik çıkar - Potansiyel ihbarcı ödülünün ötesine geçen node’ları çalıştırmak için finansal teşvikleri olan birçok kuruluş vardır. Örneğin, blok kaşifleri, likidite sağlayıcıları ya da dapp'ler gibi ürün ve hizmetlerin işlerini etkin bir şekilde yürütebilmeleri için Modüler Yürütme Katmanları'nın bütün durumuna(full state) erişmeleri gerekir. Ancak bu kuruluşlar (teoride) kötü niyetli bir blok üreticisi tarafından rüşvet almaya açıktır.

• Balinalar - Bir Modüler Yürütme Katmanı üzerinde büyük miktarda varlığı olan kuruluşlar, çıkarlarının korunduğundan ve zincirin güvenli olduğundan emin olmak için node çalıştırmayı seçebilir.

• Hızlı para çekme - Optimistik Modüler Yürütme Katmanları, modüler yığının alt katmanlarında sona ermeyi(finalise) gerçekleştirmeden önce bir anlaşmazlık çözüm süresine dayandığından, Modüler Yürütme Katmanı’ndan uzlaşma katmanına para çekme işlemleri bu süre dolana kadar sonuçlandırılmaz. Bu nedenle, hızlı para çekme işlemleri sunan, Modüler Yürütme Katmanı’nda tokenleri kabul eden ve aynı tokenleri anında (bir ücret karşılığında) uzlaştırma katmanındaki kullanıcıya gönderen üçüncü taraf hizmetleri için bir pazar bulunmaktadır. Modüler Yürütme Katmanı durumunun(state) uzlaşma katmanına fon gönderdikten sonra geri döndürülmemesini sağlamak için, hizmet sağlayıcı böyle bir işleme girmeden önce zincirin geçerliliğini doğrulamaya teşvik edilir.

• Blok üreticileri - Önceki geçersiz blokların üzerine blok gönderen blok üreticileri için bir ceza getirilmesi mümkündür. Böyle bir uygulama yapıldığında, blok üreticileri bir blok göndermeden önce zincirin geçerliliğini doğrulamaya teşvik edilecektir.

Yukarıdaki risk azaltma stratejileri tek başlarına tamamen etkili olmayabilir, ancak bir araya geldiklerinde bir takım farklı grupların Modüler Yürütme Katmanları üzerinde node çalıştırmaya ve zincirin durumunu doğrulamaya devam etmeleri için açık bir teşvik söz konusudur.

Yeni Bir Proje Alanı: EVM'nin Ötesine Geçmek

Modüler blok zinciri yığını, tek bir dürüst azınlık varsayımı altında yüksek güvenlik sağlayan bir tasarım benimseyerek, daha önce monolitik tasarımlar için mümkün olandan çok daha yüksek verimli blok zincirlerin geliştirilmesine olanak tanır.

Bununla birlikte, hesaplamayı doğrulamadan ayırmanın getirdiği ölçeklenebilirlik avantajlarının yanı sıra, özellikle yığının en üst kısmına yani modüler yürütme katmanına odaklanarak ölçeklenebilirlik konusunda daha fazla ilerlenebilir. Bu katmanda hesaplamayı daha ölçeklenebilir ve verimli hale getirmek, daha iyi blok zincirleri oluşturmanın bir sonraki adımıdır.

Şu anda geliştirilmekte olan çoğu modüler yürütme katmanı, ana zincir olarak Ethereum'u kullandığı için EVM'yi de yürütme ortamı olarak kullanmaktadır. Bu, içten yanmalı bir motorun enerji verimliliğini artırmaya benzer bir tasarımdır yani, modası geçmiş bir teknolojide yapılan aşamalı bir iyileştirmedir.

Gerçekte, modüler yığın çok daha geniş bir tasarım alanı açarak modüler yürütme katmanlarının verimsiz EVM'ye dayanma ihtiyacını ortadan kaldırır. Fuel, EVM'nin ötesine geçen, verimli ve ölçeklenebilir hesaplama, üstün geliştirici deneyimi ve maksimum güvenlik için optimizasyon yapan modüler bir yürütme katmanı oluşturmak için bu yeni tasarım alanından yararlanıyor.

Bölüm 2'de, modüler yürütme katmanlarının gerçek ölçeklenebilirliğe ulaşmak için önceki nesil blok zincir tasarımının teknolojik sınırlamalarını nasıl aşabileceğini inceleyeceğiz.

** **

Ethereum ölçeklenmesinde alternatif sanal makinelerin önemi.

Yeni birinci katman projelerin giderek daha popüler hale geldiği bugünlerde Ethereum, hala web3 alanına birçok yönden liderlik etmektedir. Ethereum; büyük bir geliştirici ve kullanıcı kitlesine, konsensüs ve veri erişilebilirliği katmanında ölçeklenmeye yönelik güçlü bir yol haritasına ve çok büyük likiditeye sahiptir.

Ethereum üzerinde geliştirilmiş çok sayıda rollup ve ikinci katman ölçeklendirme çözümünün de gösterdiği gibi, mevcut Ethereum ekosistemi üstünde inşa edilerek elde edilebilecek pek çok değer vardır.

Öte yandan, EVM ve Solidity'nin öneminin azaldığı yönünde giderek artan bir söylem de bulunmaktadır.

https://twitter.com/DennisonBertram/status/1586114575107244032?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1586114575107244032%7Ctwgr%5Efb7b96f8446c3fe5f122fcf3bb49690390a2a9f0%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Ffuel-labs.ghost.io%2Fscaling-ethereum-with-fuel%2F

Ethereum üzerinde geliştirilenler de dahil olmak üzere yeni blok zincirlerde EVM uyumluluğu, artık olmazsa olmaz bir özellik değildir. EVM uyumlu olmayan zincirlerin de geniş kitlelerce benimsendiğini görebiliyoruz.

Fırsat

Şu anda, ölçeklenebilirliğin önündeki ana darboğaz işlemleri yürütme hızı değildir; daha ziyade, konsensüs ve veri erişilebilirliği katmanının destekleyebileceği sınırlı bant genişliğidir. Bu ortamda, EVM'nin yavaş işlem yürütme yetenekleri "yeterince iyi" olmaktadır, çünkü hala Ethereum'un sağlayabileceği bant genişliğini geride bırakabiliyor.

Bununla birlikte, Ethereum, konsensüs ve veri erişilebilirliği katmanında gerçekleşecek ölçeklenme yolunda -proto-danksharding'in yakında ve sharding'in 2023 içinde gerçekleşmesi planlanıyor- ilerliyor. Ufukta görünen ana katman ölçeklenebilirliği sayesinde blok alanı artık temel kısıt olmayacaktır. Bir sonraki darboğaz; yürütme katmanlarının işlemleri ne kadar hızlı işleyebildiği, yani hesaplama alanında olacaktır.

Bu gelecekte, nispeten yavaş ve hesaplama açısından maliyetli olan EVM, konsensüs ve veri erişilebilirliği katmanında, artan bant genişliği arzına ayak uydurma konusunda yeterli olamayacaktır.

EVM, Ethereum blok zincirinin orijinal versiyonu kapsamında yeterince performanslı olacak şekilde tasarlanmıştı. Hem Ethereum hem de EVM ilk sürümlerinden bu yana iyileştirmeler görmüş olsalar da, EVM tarafındaki anlamlı ilerleme, geriye dönük uyumluluğu sürdürme ihtiyacı nedeniyle sürekli olarak kısıtlanmıştır.

Ethereum ana katmanında bant genişliğini artırarak sağlanan faydayı en üst düzeye çıkarmak için, L2'lerin yürütme katmanında daha performanslı sanal makineler oluşturup dağıtarak bu ölçeklenebilirlik iyileştirmeleri ile eşleşmeleri gerekecektir.

Bu yeni paradigma, yürütme katmanlarının EVM'nin ötesine geçerek Ethereum için gerçek ölçeklenebilirliği aramaları için bir fırsat (ve zorluk) sunmaktadır.

Çözüm

Fuel tam da bu amaç için tasarlanmıştır: EVM'yi dönüştürerek Ethereum'u ölçeklendirmek ve EVM’yi bir sonraki aşamaya taşımak için.

Mevcut ikinci katmanlar ve rollup'lar esas olarak monolitik blok zincir yığınları için tasarlanmıştır, yani genellikle büyük miktarlarda birinci katman bant genişliği potansiyeli için optimize edilmemişlerdir. Fuel ise bu potansiyelin kullanılmasına yönelik olarak özgün bir biçimde tasarlanmıştır.

Fuel gibi modüler yürütme katmanları; yeni ve geliştirilmiş VM tasarım ilkelerini benimseyerek verimli ve ölçeklenebilir hesaplama, üstün geliştirici deneyimi ve maksimum güvenlik için özel olarak optimize edebilir ve tüm bunları yaparken de Ethereum'un ölçeklendirilmesine doğrudan katkıda bulunabilir.

Fuel Ethereum'un Ölçeklenmesine Nasıl Yardımcı Olacak?

Tüm bunlar gerçekleştikten sonra Fuel Ethereum'un ölçeklenmesine nasıl yardımcı olacak? Bunun için bir dizi faktör var:

Ethereum Üzerinde İnşa Edilmek

Fuel'in mevcut yol haritası Ethereum ana ağına dağıtımı içermektedir. Beta-2 test ağı, Ethereum'un Goerli test ağına bir köprü ile bağlanarak zaten kullanılmaya başlandı ve 2023 yılında da mainnet’e geçilmesi planlanıyor.

Ethereum Yol Haritası ile Uyumluluk

Ethereum ana geliştirici topluluğu, rollup merkezli bir Ethereum'a doğru ilerlendiğini açıkça belirtmiştir. Bu yol haritasının bir parçası olarak Vitalik, "Ethereum ana katman ölçeklendirmesinin [öncelikle] zincir üzerindeki hesaplamanın verimliliğine değil, veri bloklarının ne kadar veri tutabileceğini ölçeklendirmeye odaklanacağını" belirtmiştir.

Başka bir deyişle, Ethereum'un ölçeklenme çabaları; modüler yürütme katmanları için bant genişliği sağlamaya odaklanırken, işlem yürütme hızında iyileştirmeler yapmak için bu katmanlara güvenmektedir. Bu nedenle Fuel, Ethereum'un ölçeklendirme yol haritasını desteklemek için yürütme katmanında hızlı ve verimli hesaplama sağlamaya odaklanmıştır.

FuelVM: EVM'nin içindeki Dolandırıcılık Kanıtı

FuelVM komut seti, EVM içinde hem hızlı hem de dolandırıcılığa karşı kanıtlanabilir olacak şekilde özel olarak tasarlanmıştır. Başka bir deyişle Fuel, Ethereum'un bir uzlaşma katmanı olarak kullanılmasını desteklemek amacıyla tasarlanmıştır.

Geliştiricileri Ethereum Ekosistemine Kazandırma

Fuel, geliştirici deneyimi ön planda tutularak tasarlanmıştır ve Sway dili de şimdiden büyük ilgi görmeye başlamıştır. Fuel, geliştiricilerin sevdiği Rust tabanlı bir DSL ve kapsamlı araçlar oluşturarak çok sayıda yeni geliştiriciyi ekosisteme çekecek şekilde konumlanmıştır.

https://twitter.com/reimao42/status/1589240548170563584?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1589240548170563584%7Ctwgr%5Efb7b96f8446c3fe5f122fcf3bb49690390a2a9f0%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Ffuel-labs.ghost.io%2Fscaling-ethereum-with-fuel%2F

Buna ek olarak FuelVM'nin tasarımı, EVM'de (orderbook DEX'leri gibi) mümkün olmayan yeni kullanım alanlarını mümkün kılmaktadır. Daha fazla özellik ve daha iyi bir geliştirici deneyimi ile daha fazla projeye, çok daha fazla kullanım alanına ve daha fazla son kullanıcıya yol açacaktır.

Fuel, iki ağ arasında güven minimize edilmiş bir köprü ile Ethereum üzerinde konuşlandırılacağından, bu geliştiriciler ve kullanıcılar alternatif birinci katmanlara yönelmek yerine Ethereum ekosisteminin büyümesine doğrudan katkıda bulunacaklardır.

Fuel: Tüm Gücüyle Ethereum'u Ölçeklendirmek

Ethereum'un modüler bir yol haritasına olan kararlılığı, yürütme katmanında hesaplamayı daha ölçeklenebilir ve verimli hale getirmenin, daha ölçeklenebilir bir Ethereum ekosistemi oluşturmanın bir sonraki adımı olduğu anlamına gelmektedir. Alternatif sanal makineler bu denklemin çok önemli bir parçasıdır ve Fuel de işte bu alanda öncülük etmektedir.

Fuel, en hızlı modüler yürütme katmanını inşa ederek Ethereum'a maksimum güvenlik ve yüksek esneklikte işlem kapasitesi getiriyor.

Windows kullanıcıları için, projenin resmi dokümanına göre anlattım.

Önce

http://www.docker.com/products/docker-desktop/

sitesinden 'Docker Desktop'ı indirip, kurup, -free plan'ı seçerek- hesap oluşturuyorum. İşlemler 'Docker Desktop' açıkken yapılacağı için açık bırakıyorum.

Daha sonra

Microsoft Store'dan 'WSL'yi indirip kuruyorum.

Açtıktan sonra sırasıyla aşağıdaki komutları giriyorum.

sudo apt update

ile güncelliyorum.

curl https://www.espressosys.com/cape/docker-compose.yaml --output docker-compose.yaml

komutunu çalıştırıyorum. Sonrasında

sudo su

komutu ile 'root'a gidiyorum. Burada

ls

deyip 'docker-compose.yaml' dosyasının burada olduğundan emin oluyorum. Sonrasında sırasıyla

docker-compose down -v

docker-compose pull

docker-compose up

komutlarını çalıştırıyorum. Aldığım çıktı böyle görünüyor:

Sonrasında Chrome Browser'da adres çubuğuna

localhost

yazıyorum. Açılan sayfa:

'Set up new CAPE Wallet' diyorum.

Sonrasında 'Reveal Keys'

Kelimelerimi not edip, cüzdanıma isim ve şifre belirledikten sonra açılan sayfadan 'Request some CAPE' ile Test Token istiyorum.

Daha sonra MM'yi Arbitrum Goerli Test ağına bağlıyorum.

İsterseniz elle bilgileri elle girin,

isterseniz chainlist.org 'dan kaydedin.

Goerli Test Ether istiyorum. Adresler:

http://goerli-faucet.pk910.de/

https://faucet.paradigm.xyz/

http://goerlifaucet.com/

Goerli'deki test etheri

http://bridge.arbitrum.io

adresinden Arbitrum Goerli'ye köprülüyorum. Gelmesi 15 dakika civarı sürüyor.

Daha sonra bu test etherleri aşağıdaki kontrat adreslerini kullanarak ilgili tokenlere swaplıyorum.

WETH: 0x4F1D9E040cf28A522ec79951cDb7B55c8aE4744E

DAI: 0xBeec50ed16E3559afCD582cC98ed2b5F5DcA189E

USDC: 0x9A4f4Ee35a8FfEE459B3187A372d422790fc8aAB

Önce bu tokenleri MM'ye ekliyorum. Daha sonra bu kontrat adreslerine MM içinden Test Ether göndererek swap yapıyorum.

Alıcı adres kısmına yukarıdaki adresleri sırayla yazıyorum. MM zaten uyarı veriyor 'Anladım'a tıklıyorum sonra gönder diyorum. Swap gerçekleşiyor.

Cüzdanımın son hali:

Tekrar CAPE cüzdanıma dönüyorum. Soldaki 'Account' sekmesinden yeni bir adres, 'Viewing Key' ve 'Freezing Key' oluşturuyorum. Yeni adresi kendime token yollamak için kullanacağım.

'Viewing ve Freezing Key'ler ise şu an bu UI üstünde kullanılamıyor. Ama oluşturuyorum yine de.

Artık CAPE'i kullanmaya hazırım. Hemen bir varlık oluşturuyorum.

Sol taraftaki menüden 'New CAPE Asset'e giriyorum.

ERC kontrat adrese yukarıdaki adreslerden birini yazıyorum. USDC yazdım ben. Token Symbol'e istediğinizi yazabilirsiniz. ABC yazdım.

Daha önce oluşturduğum 'Asset Viewing Key' ve 'Asset Freezing Key'lerimi de aşağıdaki ilgili yerlere yapıştırıp tüm kutucukları tickliyorum.

Generate New Cape Asset'i tıklayınca MM'den onay veriyorum ve varlığı oluşturmuş oluyorum.

Yeni ürettiğim varlığı Wrap ediyorum. Bunun için 'Wrap' menüsünden varlığı seçip miktar giriyorum. Hangi kontrat adresini kullandıysanız o miktardan az girmeniz gerekiyor.

Elimde olan diğer tokenlerden de küçük miktarlar wrap yapıyorum.

Aynı menüden bir de 'Domestic CAPE Asset' üretiyorum.

Bu sefer 'Token Symbol'ü ABCD, 'Amount'u da 200 yapıyorum. Siz tabi istediğiniz gibi yapabilirsiniz.

Tekrardan eğer isterseniz aşağıdaki kutucukları da bir önceki gibi doldurabilirsiniz. Ben doldurmadım. Direkt 'Create New CAPE Asset' dedim.

Cüzdanımın son hali. ABCD ve ABC tokenleri benim ürettiğim tokenler.

Bundan sonra dileyenler 'Send' ve 'Receive' sekmelerinden token gönderip alabilirler. İsteyenler adreslerini yazarlarsa yollayabilirim. Uzun bir testnet ama denemekte fayda görüyorum.

Here are some of the ones I've been following:

01. FUEL NOMEN

Fuel Nomen is a next generation blockchain name system on Fuel. It is currently in development, but we will talk about it a lot when it goes live.

Follow on twitter: @fuelnomen

02. THUNDER

The first NFT marketplace developed on Fuel. Their Discord server went live a couple of days ago and they hinted at an 'early role'. I say hop on in.

Follow on twitter: @thunderbyfuel

Join Discord: Thunder

03. POOLSHARK PROTOCOL

Poolshark Protocol is an orderbook SDK with Directional Liquidity building on Fuel. Their public testnet is planning to go live on Q1 2023.

Web site: poolshark.fi

Follow on Twitter: @poolshark_labs

Join Discord: Poolshark

04. FUELET WALLET

Fuelet wallet is a self-custodial crypto wallet for the web3 users. It will be available on iOS, Android and Chrome soon.

Web Site: fuelet.app

Follow on Twitter: FueletWallet

05. UNIC

Unic is an NFT project that users can turn any NFT or photo into a verifiable asset. 'Early role' is given on their Discord server. You can also test their ‘Demo App’ if you like.

Web Site: unic.io

Follow on Twitter: @0xUnic

Join Discord: Unic

As FuellabsTurkiye, we published this installation in Turkish. This is the instruction I prepared for global users.

Since Fuel is currently in alpha, it is not possible to download the wallet from the Chrome store. Therefore, you need to download the Fuel Wallet zip file for installation.

Download the zip file from the link:

https://fuels-wallet.vercel.app/app/fuel-wallet.zip

Then in the Chrome or Brave browser; open the 'Extensions' page from the 'Settings' tab.

Turn on 'Developer Mode' in the upper right corner.

Drag the zip file we just downloaded into this page and go to the installation page.

Click on 'Create a Wallet'. Save the recovery words, check the box on the left and click 'Next'.

Paste the copied words and click 'Next' again. On the opening page, create a password and complete the installation.

This is what our wallet looks like when it is just created.

Click on the 'Faucet' link below and get Test Ethers from the page that opens.

Then receive 0.5 test ether.

Since Fuel is under active development, this is all we can do with the wallet for now. I will continue to inform you as it develops.

https://docs.fuel.sh/v1.1.0/Introduction/Welcome.html

Giriş

Fuel, Ethereum için düşük maliyetli, yüksek verimli değer aktarım işlemleri hedefleyen izin ve güven gerektirmez (permissionless and trustless) bir L2 protokolüdür. Fuel, yüksek düzeyde optimize edilmiş optimistik bir rollup tasarımıyla desteklenmektedir.

Fuel'ın Özellikleri:

• Tamamen merkeziyetsiz: gözetimsiz(non-custodial), sansüre dayanıklı ve izin gerektirmez(permissionless)

• Benzersiz UTXO tabanlı tasarımıyla dünyanın en ölçeklenebilir optimistik roll-up'ıdır

• 500 TPS maksimum zincir üstü kapasite (throughput) (BLS toplu imzaları(aggregate signatures) ile 4300)

• 10.000 TPS'ye kadar dalgalanma alım(surge intake) kapasitesi

• Herhangi bir Ethereum adresini kullanarak gönderme ve alma, kayıt gerektirmez

• ETH ve tüm ERC-20 tokenleri desteklenmektedir

• Herhangi iki token arasında gözetimsiz(Non-custodial) token takasları

• Ücretler sadece ETH ile değil, herhangi bir token ile ödenebilir

• Zincirler arası atomik(atomic) takaslar ve ek kullanım durumları için HTLC'ler

• Atomik takaslar kullanılarak 10 dakikadan kısa sürede para çekme

Fuel'ı Farklı Kılan Nedir?

• Maksimum ölçeklenebilirlik için optimize edilmiş UTXO tabanlı tasarım

  -Paralellik: işlemler, yaygın olarak kullanılan donanımlar ile paralel olarak doğrulanabilir

  -Durum darboğazı yok: benzersiz dolandırıcılık kanıtı şeması ile durum sıralamasına(state serialization) gerek kalmaz

• Özel anahtar formatları veya zincir üstü hesap kaydı gerekmez

• Ön teminat gerekliliği yoktur (kanalların aksine)(unlike channels)

• İzin gerektirmez ve sansüre dayanıklı (Plasma/Validium'un aksine)

• Yüksek gecikme süresi ile külfetli kanıt üretimi yok (ZK rollup'ları ve Validium'un aksine)

• Egzotik kriptografi yok (ZK rollup'ları ve Validium'un aksine)

• Trusted setup yok(No trusted setup) (SNARK tabanlı ZK rollup'ları ve Validium'un aksine)

• Kullanıcı düzeyindeki sorunlara karşı özenli ve dikkatlidir

  -Funnel sözleşmelerini kullanarak herhangi bir hesaptan (döviz hesapları dahil) basit transferler kullanarak para yatırabilir

  -Fuel üzerindeki işlemleri yetkilendirmek için akıllı sözleşme cüzdanı kullanabilir

Mini Sözlük:

UTXO: UTXO modeli, protokolün coinlerin herhangi bir zamanda nerede olduğunu takip etme mekanizması olarak hizmet eder.

Censorship resistant: Herhangi bir tarafın ağ üzerindeki işlemleri değiştirmesini engelleyen bir ağ özelliğidir.

Permissionless: Ağa katılmak için kimseden izin almaya gerek olmamasıdır.

Non-custodial: Non-Custodial bir cüzdanda, özel anahtarlarınızın tek kontrolü sizdedir ve bu anahtarlar da kripto paranızı kontrol eder ve fonların size ait olduğunu kanıtlar. Custodial bir cüzdanda ise özel anahtarlarınız başka bir tarafın kontrolündedir. Bugünlerde çoğu custodial cüzdan, web tabanlı borsa cüzdanlarıdır.

Trusted setup: Güvenilir kurulum, bir kriptografik protokol her çalıştırıldığında kullanılması gereken bir veri parçası oluşturmak için bir kez yapılan bir prosedürdür.

Bu yazıda, Scroll'un genel mimarisine genel bir bakış sunuyoruz. Daha spesifik olarak, Scroll'un merkezi bir sıralama node'u(sequencing node) ve merkeziyetsiz kanıtlama ağından(proving network) oluşan ilk versiyonunu ele alacağız. Gelecekte sıralama node'ları kümesini merkezsizleştirmeye kararlıyız ve buna yönelik tasarımımızı gelecek makalelerde paylaşacağız.

Scroll'un mimarisi

Mevcut mimari üç altyapı bileşeninden oluşmaktadır (bkz. Şekil 1):

• Scroll Node'u: Kullanıcı işlemlerinden L2 blokları oluşturur, bunları Ethereum temel katmanına iletir ayrıca mesajları L1 ve L2 arasında iletir.

• Roller Network: İşlemlerin doğru şekilde yürütüldüğünü kanıtlamak için zkEVM geçerlilik kanıtlarını(validity proofs) oluşturur.

• Rollup ve Köprü Sözleşmeleri: Scroll işlemleri için veri kullanılabilirliği(data availability) sağlar, zkEVM geçerlilik kanıtlarını(validity proofs) doğrular ve kullanıcıların Ethereum ve Scroll arasında varlıkların taşınmasına olanak tanır.

Aşağıda, bu bileşenlerin her birinin rollerini detaylandırıyoruz.

Scroll Node'u

Scroll node'u, uygulamaların ve kullanıcıların Scroll ile etkileşime girmesinin ana yoludur. Sequencer, Coordinator ve Relayer olmak üzere üç modülden oluşur.

Sequencer bir JSON-RPC arayüzü sağlayarak L2 işlemlerini kabul eder. Birkaç saniyede bir, L2 mempool'dan bir grup işlem alır ve yeni bir L2 bloğu ve yeni bir state root(durum kökü) oluşturmak için bunları yürütür(execute). Sequencer uygulamamız, en popüler Ethereum node uygulamalarından biri olan Go-Ethereum'a (Geth) dayanmaktadır. Geth'i forklayarak en iyi uyumluluğu elde edebilir ve kendini kanıtlamış güvenliği devralabiliriz.

Yeni bir blok oluşturulduğunda, Coordinator bilgilendirilir ve Sequencerdan bu bloğun yürütme izini alır. Daha sonra yürütme izini kanıt üretimi için roller havuzundan rastgele seçilen bir Roller'a gönderir.

Relayer, hem Ethereum hem de Scroll üzerinde konuşlandırılan köprü ve rollup sözleşmelerini izler. İki ana sorumluluğu vardır. İlk olarak, veri kullanılabilirliği(data availability) ve geçerlilik kanıtı(validity proof) dahil olmak üzere L2 bloklarının durumunu takip etmek için rollup sözleşmesini izler. İkinci olarak, hem Ethereum hem de Scroll üzerinde konuşlandırılan köprü sözleşmelerinden para yatırma ve çekme olaylarını izler ve mesajları bir taraftan diğerine aktarır.

Roller Ağı

Roller'lar, zkRollup için geçerlilik kanıtları üretmekten sorumlu, ağdaki kanıtlayıcılar olarak hizmet vermektedir. Roller'ların kanıtlama süresini ve kanıtlama maliyetini azaltmak için GPU'lar, FPGA'lar ve ASIC'ler gibi hızlandırıcıları kullanması beklenmektedir. Şekil 2, bir Roller'ın her blok için geçerlilik kanıtını nasıl oluşturduğunu göstermektedir. Süreç aşağıdaki adımlardan oluşur:

• Bir Roller ilk olarak Coordinatordan alınan yürütme izini devre tanıklarına(circuit witnesses) dönüştürür.

• Her bir zkEVM circuit'ı için kanıtlar üretir.

• Son olarak, birden fazla zkEVM circuit'ından gelen kanıtları tek bir blok kanıtta birleştirmek için kanıt toplamayı(proof aggregation) kullanır.

Rollup ve Köprü Kontratları

Scroll, Rollup ve Köprü akıllı kontratları aracılığıyla Ethereum'un temel katmanına bağlanır. Bunlar birlikte, L2 işlemleri için veri kullanılabilirliğini sağlar ve kullanıcıların L1 ve L2 arasında varlık ve mesaj aktarmasına olanak tanırlar.

Rollup kontratı, Sequencer'dan L2 durum köklerini(state roots) ve bloklarını alır. Durum köklerini(state roots) Ethereum state'i, L2 blok verilerini de Ethereum calldata olarak saklar. Bu, Scroll blokları için veri kullanılabilirliği(data availability) sağlar ve Scroll Relayer dahil dizinleyicilerin(indexers) L2 bloklarını yeniden oluşturabilmesini sağlamak için Ethereum'un güvenliğinden yararlanır. Bir L2 bloğunun geçerliliğini ortaya koyan bir blok kanıtı Rollup kontratı tarafından doğrulandıktan sonra, ilgili blok Scroll üzerinde kesinleşmiş kabul edilir.

Ethereum ve Scroll üzerinde konuşlandırılan Köprü kontratları, kullanıcıların L1 ve L2 arasında rastgele mesajlar iletmesine olanak tanır. Bu mesaj geçirme protokolünün yanı sıra, kullanıcıların ERC-20 varlıklarını her iki yönde de köprülemesine olanak tanıyan trustless bir köprüleme protokolü de oluşturduk. Ethereum'dan Scroll'a bir mesaj veya fon göndermek için kullanıcılar Köprü kontratında bir sendMessage işlemi çağırır. Relayer bu işlemi L1 üzerinde indeksleyecek ve bir L2 bloğuna dahil edilmesi için Sequencer'a gönderecektir. Scroll'dan Ethereum'a geri mesaj göndermek için L2 Köprü kontratında benzer bir işlem kullanılır.

Scroll'un zkRollup'ı nasıl çalışır?

Bu üç mimari parçayı bir araya getirdiğimizde, Scroll'un zkRollup'ının, aşağıdaki Şekil 3'te özetlenen iş akışını açıklayabiliriz.

Scroll'daki L2 blokları oluşturulur, temel katman Ethereum'a işlenir ve aşağıdaki adımlar şeklinde sonuçlandırılır:

1. Sequencer bir dizi blok oluşturur. Sequencer, i'nci blok için bir yürütme izi T oluşturur ve bunu Coordinator gönderir. Bu sırada, işlem datası D'yi veri kullanılabilirliği(data availability) için Ethereum'daki Rollup kontratına calldata olarak ve ortaya çıkan durum köklerini(state roots) ve işlem datasına yönelik taahhütleri de durum(state) olarak Rollup kontratına gönderir.

2. Coordinator, her blok izi için bir geçerlilik kanıtı oluşturmak üzere rastgele bir Roller seçer. Kanıt oluşturma sürecini hızlandırmak için, kanıtlar, farklı bloklar için farklı Rollerlar üzerinde paralel olarak oluşturulabilir.

3. Roller, i'nci blok için P blok kanıtını oluşturduktan sonra bunu Coordinatore geri gönderir. Her k blokta bir, Coordinator k blok kanıtını tek bir A toplam kanıtında(aggregate proof) toplamak için başka bir Roller'a bir toplama görevi gönderir.

4. Son olarak, Coordinator i+1'den i+k'ya kadar olan L2 bloklarını sonuçlandırmak için toplam kanıtı(aggregate proof) daha önce Rollup kontratına sunulan durum kökleri(state roots) ve işlem datası taahhütlerine karşı doğrulayarak toplam kanıt A'yı Rollup kontratına sunar.

Şekil 3, Scroll bloklarının L1'de çok aşamalı bir süreç ile sonlandırılacağını göstermektedir. Her bir L2 bloğu sonlandırılana kadar aşağıdaki üç aşamadan geçecektir.

• Precommitted, bir bloğun bir Sequencer tarafından önerildiğini ve Roller'lara gönderildiğini gösterir. Precommitted bloklar Ethereum temel katmanında yayınlanmadıkları için henüz Scroll L2 zincirinin meşru bir parçası olmasalar da, Sequencer'a güvenen kullanıcılar beklenti içinde bu bloklar üzerinde işlem yapmayı seçebilirler.

• Committed, bu bloğun işlem datalarının Ethereum'daki rollup kontratına gönderildiğini gösterir. Bu, blok datalarının mevcut olmasını sağlar, ancak geçerli bir şekilde yürütüldüğünü kanıtlamaz.

• Finalized, bu bloktaki işlemlerin doğru şekilde yürütüldüğünün Ethereum'da zincir üzerinde bir geçerlilik kanıtı doğrulanarak kanıtlandığını gösterir. Sonuçlandırılmış bloklar, Scroll L2 zincirinin meşru parçaları olarak kabul edilir.

Toparlamak gerekirse Scroll, temel katman Ethereum'dan güçlü güvenlik garantileri devralırken L2 üzerinde yerel EVM bytecode'unu çalıştırabilir. Bu serideki bir sonraki yazıda, geliştiricilerin Scroll'da dapp'leri dağıtmaları(deploy) için iş akışını ve kullanıcıların bunlarla nasıl etkileşime girebileceğini açıklayacağız.

Hakkımızda daha fazlası

Scroll'un mimarisini vizyonumuz, değerlerimiz ve teknik ilkelerimizle uyumlu olacak şekilde tasarladık. Gelecek makalelerde, Scroll'un Ethereum üzerinde daha ölçeklenebilir bir kullanıcı ve geliştirici deneyimi sağlamak için bu mimariyi nasıl kullanacağını açıklayacağız. Daha fazlasını öğrenmek için bizi takip etmeye devam edin ve signup.scroll.io adresinden pre-alpha test ağımızı denemek için kaydolun!

Ethereum'u açık ve topluluk odaklı bir şekilde ölçeklendirme vizyonumuz ilginizi çekiyorsa, Scroll'un Ethereum için en geliştirici ve kullanıcı dostu ölçeklendirme çözümü haline gelmesine yardımcı olacak değerlerle uyumlu bireyler arıyoruz.

• Eğer bir ZK araştırmacısı, ZKP, Go veya Solidity geliştiricisi veya GPU mühendisiyseniz, mümkün olanın sınırında birçok ilginç teknik zorluk üzerinde çalışıyoruz. Gelin, bizimle bu çözülmemiş problemler için son teknoloji çözümler üretin!

• Ekosistemleri veya toplulukları geliştirip büyütmeyi seviyorsanız, toplulukla uyumlu ve kullanıcı dostu bir şekilde inşa ettiğimizden emin olmak için geliştirici elçileri ve topluluk organizatörleri arıyoruz.

Bu görevler ve Scroll hakkında daha fazla bilgi edinmek için web sitemize, Twitter'a, Discord'a veya iş ilanları sayfamıza göz atın. Doğrudan koda ulaşmak ve bizimle birlikte geliştirme yapmak istiyorsanız, repolarımızı github.com/scroll-tech ve github.com/privacy-scaling-explorations/zkevm-circuits adreslerinde bulabilirsiniz.

NOT: Anlatırken daha iyi öğreniyoruz. Ben de önce kendim sonra da ilgilenenler için çevirdim. Bu yazı resmi bir çeviri olmamakla beraber aslıyla birebir aynıdır.

Orjinal yazının linki:

https://scroll.mirror.xyz/nDAbJbSIJdQIWqp9kn8J0MVS4s6pYBwHmK7keidQs-k

Teknik İlkelerimiz

1. Kullanıcı güvenliğinin sağlanması

Blok zinciri ölçekleme çözümleri bağlamında, en önemli güvenlik biçimi, kullanıcı fonlarının ve verilerinin doğruluğu(integrity) ile ilgilidir. Bir ölçeklendirme çözümü kullanıcılara ek yetenekler sunabilse de, kullanıcıların fonlarına erişimlerini sürdürebilmelerinin her şeyden önce geldiğine inanıyoruz. Scroll için bu, kullanıcıların güvenlik için Layer2 node'larının dürüstlüğüne güvenmeleri gerekmediği ve bunun yerine Layer2'de işlem yaparken bile Layer1 güvenliğinden tam olarak yararlanabileceği anlamına gelir. Bu prensibe göre Ethereum üzerine inşa ederek, Ethereum temel katmanının(Layer1) en güvenli ve merkezi olmayan konsensüsünde Scroll güvenliğini temellendiriyoruz.

2. EVM-denkliğini korumak

Etkili bir Ethereum ölçeklendirme çözümü, kullanıcılara ek yetenekler sağlamanın yanı sıra, kullanıcılara ve geliştiricilere mevcut dapp'lerden ve geliştirici araçlarından sorunsuz bir geçiş yolu sağlamalıdır. Bunu başarmanın en iyi yolunun EVM-denkliğini korumak olduğuna inanıyoruz. EVM dengi bir ortam, Ethereum sarı kağıdındaki Ethereum Sanal Makinesi(EVM) özellikleri ile tamamen aynı şekilde davranır. Bu, kullanıcıların ve geliştiricilerin pahalı denetimler yaptırmadan, ek kod değişiklikleri veya geliştirme iş akışlarında rahatsız edici değişiklikler yapmadan geçiş yapabilecekleri anlamına gelir.

EVM-denkliği, esasen, aktarım(transpilation) gibi çözümler yoluyla EVM ile basit uyumluluktan çok daha güçlü garantiler sağlar. Yalnızca uyumluluğa karar vermek, kullanıcıları ve geliştiricileri, Ethereum'un destekleyici altyapısının büyük bölümünü değiştirmeye ve hatta tamamen yeniden uygulamaya(reimplement) zorlayabilir. Ayrıca, EVM denkliği olmadan güvenliği sağlamak çok daha zor hale gelir. Sonuç olarak, maksimum seviyede geliştirici ve kullanıcı dostu olmak için Scroll, yalnızca EVM uyumlu değil, EVM dengidir.

3. Verimlilik

Kullanıcıların Layer 2'de harika bir deneyim yaşaması için aşağıdakilere inanıyoruz:

• İşlem ücretleri düşük olmalı, emirler temel katmandakinden(base layer) daha ucuz olmalıdır.

• Kullanıcılar, Layer 2'de anında ön onay ve temel katmanda -bizim durumumuzda Ethereum- makul derecede hızlı kesinlik(finality) deneyimlemelidir.

Bu koşulların merkezi bir operatörle karşılanması kolay olsa da, güvenliği korumak için merkezi olmayan bir ortamda tutulmaya devam etmeleri gerekir. Layer 2 bağlamında, hem Layer 2'de hem de temel katmanda(L1) kullanıcı güvenliğini ve merkeziyetsizliği korurken Scroll'un mümkün olduğunca verimli olması gerektiğine inanıyoruz.

4. Topluluğun tüm katmanlarında merkeziyetsizlik

Merkeziyetsizlik, blokzincirlerin, genellikle görmezden gelinen veya verimlilik için harcanan temel bir özelliğidir. Bunun, blokzincirlerin en değerli yönlerinden biri olduğuna ve protokollerin ve toplulukların sansüre veya koordineli saldırılara karşı dayanıklı olmasını sağladığına inanıyoruz. Node operatörleri, kanıtlayıcılar(provers), geliştiriciler ve kullanıcılar topluluğu da dahil olmak üzere Scroll'un birçok yönü genelinde merkeziyetsizliği göz önünde bulunduruyoruz. Toplulukla birlikte açık bir şekilde inşa ederek ve hem kanıtlamayı(prove) hem de sıralamayı(sequence) merkezden dağıtmak için güvenilir bir yol çizerek, Scroll tüm boyutlarda merkeziyetsizleşme sağlamaya kararlıdır.

İlkelerimiz Scroll'un tasarımına nasıl yön verir

Scroll için ana tasarım seçenekleri, doğal olarak bu teknik ilkeler tarafından yönlendirilmiştir.

1. Güvenlik ve EVM-denkliği bizi zkEVM-tabanlı bir zkRollup çözümüne ulaştırdı

Scroll'u geliştirirken güvenlik birinci önceliğimizdi. zkRollup tabanlı tasarımımızda, Scroll üzerinde yürütülen Layer 2 işlemlerinin bütünlüğü, Ethereum ana katmanındaki akıllı bir sözleşmede doğrulanan kısa ve öz sıfır bilgi kanıtlarıyla(succinct zero-knowledge proofs) sağlanır. Bu, Scroll işlemlerinin Ethereum temel katmanındaki işlemler kadar güvenli olmasını sağlar. Sonuç olarak, kullanıcıların fonlarını güvende tutmak için herhangi bir üçüncü tarafa güvenmeleri gerekmez - güvenlik, Ethereum temel katmanının güvenliğinden ve sıfır bilgili(Zk) kriptografinin matematiksel garantilerinden gelir. Bunun, kullanıcılarımız için en iyi güvenliği sağlayan ve mümkün olan minimum güven varsayımları kümesi olduğuna inanıyoruz.

Bir zkRollup yaklaşımına karar verdikten sonra, bunu kullanıcılar ve geliştiriciler için erişilebilir kılmayı sağlamak zorunda kaldık. Bir zkEVM aracılığıyla EVM-denkliğine ulaşmanın en önemli amaç(holy-grail) olduğunu hemen anladık. Denkliği bozmak bu işi büyük ölçüde basitleştirecek olsa da, sıfır bilgi kriptografisindeki son gelişmeleri kullanarak bir zkEVM oluşturmanın mümkün olduğunu fark ettiğimizde, bunun en iyi seçim olacağına karar verdik. Scroll, teknik olarak zor olan bu görevi üstlenerek en iyi kullanıcı ve geliştirici deneyimini sunmayı amaçlamaktadır. zkEVM'imiz, kısa ve öz ZK kanıtlarını(succinct ZK proofs) kullanarak yerel EVM bayt kodunun doğru şekilde yürütüldüğünü kanıtlar, EVM'nin kendisinin durum geçiş işlevi(state transition function) üzerinde güvence sağlar ve Scroll'un JSON-RPC arayüzü ve işlem formatı gibi Ethereum yerel geliştirici araçlarını desteklemesine izin verir.

2. Merkeziyetsizlik, bizi merkeziyetsiz bir kanıtlanmış ağa(prover network) götürür

zkEVM'mizi tasarlarken, EVM'yi bir ZK kanıtı haline getirmenin, yerel alanlar arasındaki uyumsuzluk nedeniyle büyük bir kanıtlama yüküyle sonuçlanacağını hemen fark ettik. Bu kanıtlama süresinden kaynaklanan Layer 1'deki kesinlik(finality) süresini azaltmak için, Scroll Layer 2 blokları için kanıt oluşturan izin gerektirmez(permissionless) ve merkeziyetsiz bir kanıtlayıcı ağı olan Roller ağımızı oluşturmaya karar verdik.

Merkeziyetsiz kanıtlayıcı ağımızın iki önemli teknik avantajı vardır:

• Kanıtlama altyapımızı fazlasıyla paralel hale gelebilecek şekilde tasarladık. Bu, Scroll'un yalnızca daha fazla kanıtlama node'u ekleyerek kanıtlama işlemini büyük ölçüde ölçekleyebileceği anlamına gelir.

• Topluluk, merkezi bir şekilde yalnızca Scroll ekibine güvenmek yerine, daha iyi donanım çözümleri oluşturmaları ve kanıtlayıcılarını kendileri çalıştırmaları için teşvik edilecektir. Ağın ilk aşamasında önyükleme yapmak için, ileride halka açık kullanım için açık kaynak yapacağımız, dahili olarak GPU onaylı çözümler oluşturuyoruz. Bu fikir olgunlaşırken, bir yandan da çeşitli donanım şirketleri ile ASIC ve FPGA çözümlerini araştırıyoruz. Uzun vadede, bu alandaki rekabeti dört gözle bekliyoruz ve kanıt oluşturma süresinin gecikmesinin(latency) ve maliyetinin katlanarak azalacağına inanıyoruz.

Son olarak ve en önemlisi, ilk adımımızın kanıtlayıcıyı merkeziyetsizleştirmek olması, topluluk katılımı ve merkeziyetsizlik ilkelerimize gösterdiğimiz bağlılıktır. Scroll ana ağa(mainnet) yaklaştıkça, kanıtlama ağımızın(prover network) yanı sıra sıralayıcıyı(sequencer) merkeziyetsizleştirmeyi ve protokol için daha fazla sansür direnci ve sağlamlık sağlamayı planlıyoruz.

3. Verimlilik, açık araştırma odaklı inovasyona odaklanmamızı sağlıyor

Güvenlik ve merkeziyetsizliğin getirdiği güçlü kısıtlamalar altında Scroll'un zkEVM'sini pratik hale getirmek için, tüm topluluğun yenilikçi ve araştırma odaklı çözümlerinden yararlandık. zkEVM tasarımımız, birkaç tanesini saymak gerekirse, kanıtlama sistemleri, kanıt toplama ve ZK donanım hızlandırma alanlarındaki son atılımlara entegredir. Açık geliştirme yaklaşımımız, Ethereum Vakfı'ndaki PSE (Gizlilik ve Ölçeklendirme Araştırmaları) grubuyla ve diğer ortak çalışanlarla en iyi fikirleri bulmak için çalışmamıza izin verdi ve bu açık kaynaklı araştırma yaklaşımının, en iyi ve en verimli çözümü üreteceğine inanıyoruz.

zkEVM'imizin ilk versiyonuna yaklaşırken, optimizasyona ve sistemimize en yeni ve en iyi teknikleri entegre etmeye odaklanıyoruz. Bu bağlamda, şunları araştırıyoruz:

• Danksharding sonrası veri bloblarının(data blobs) Scroll'un verimliliğini nasıl iyileştirebileceği

• Yeni donanım dostu ZK algoritmaları ile Scroll'un zkEVM'sini nasıl birlikte optimize edebileceğimiz

• Layer 2 uygulama geliştiricilerine yeni ZK temel öğelerini nasıl sunarız

📜Toparlamak gerekirse

Bu makalede özetlenen teknik ilkeler, Scroll'u, mevcut Ethereum topluluğuyla uyumlu ve henüz blokzincir kullanmayan milyarlarca kişi için bir ölçeklendirme yolu sağlayan bir protokol tasarımına yönlendirdi. Önümüzdeki birkaç hafta içinde, Scroll'un mimarisi ile kullanıcı ve geliştirici deneyimi hakkında somut ayrıntılar içeren daha fazla yazı yayınlayacağız. Bunlar hakkında daha fazla bilgi edinmek için bizi takibe devam edin ve signup.scroll.io adresinde alfa öncesi test ağımızı denemek için kaydolun!

Ethereum'u açık ve topluluk odaklı ölçeklendirme vizyonumuz ilginizi çekiyorsa, Scroll'un Ethereum için en geliştirici ve kullanıcı dostu ölçeklendirme çözümü olmasına yardımcı olacak değerlere uygun bireyler arıyoruz.

• Bir ZK araştırmacısı, ZKP, Go veya Solidity geliştiricisi veya bir GPU mühendisiyseniz, mümkün olanın sınırlarında, birçok ilginç teknik zorluk üzerinde çalışıyoruz. Gelin, bu sorunlara bizimle birlikte en yeni çözümleri üretin!

• Ekosistemleri veya toplulukları geliştirip büyütmeyi seviyorsanız, toplulukla uyumlu ve kullanıcı dostu olarak inşa ettiğimizden emin olmak için geliştirici destekçileri ve topluluk yöneticileri arıyoruz.

Bu görevler ve Scroll hakkında daha fazla bilgi edinmek için web sitemize, Twitter’a Discord'a veya kariyer sayfamıza göz atın. Doğrudan kod yazmaya geçmek ve bizimle birlikte geliştirmek istiyorsanız, repolarımızı github.com/scroll-tech ve github.com/privacy-scaling-explorations/zkevm-circuits adresinde bulabilirsiniz.

NOT: Anlatırken daha iyi öğreniyoruz. Ben de önce kendime sonra da ilgilenenlere anlattım. Bu yazı resmi bir çeviri olmamakla beraber aslıyla birebir aynıdır.

Orjinal yazının linki:

https://mirror.xyz/scroll.eth/N7cAie4ul0PdSxNdv2FTqgMV2JEkhOJocsxfeqe4SFE

‍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.

Blockzincir nedir?

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.

Hata Kanıtları(Fault Proofs) ve Optimistik Rolluplar

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.

Veri Kullanılabilirliği Sorunu(The Data Availability Problem)

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.)

Çözümler

İ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.

Geçerlilik Kanıtları ve Sıfır Bilgi Rollupları(Validity Proofs and Zero Knowledge Rollups)

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.

Peki Şimdi Neredeyiz

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.

toplam maliyet(gaz olarak) = sabit maliyetlerin toplamı + (batch boyutu * çağrı verileri için gerekli gaz)

"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.

Çalışma Devam Ediyor

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.

Kendim öğrenmeye çalıştığım konular hakkında merak edenlere de faydalı olmaya çalışıyorum. Faydalandıysanız ne mutlu bana.

1. Bugün FuelVM'nin neden EVM olduğunu, ve fakat büyük ölçüde geliştirilmiş olduğunu ve bunun blokzincirin geleceği için ne anlama geldiğini tartışacağım.

2. EVM performansını iyileştirmek için uygulamaya hazır sayısız yaklaşım var. Fakat, bunların birçoğu Ethereum protokolünün geriye dönük uyumluluğunu ve süreçteki birçok dapp'i bozacaktır.

   Taze bir başlangıca ihtiyaç var.

3. Ethereum üzerine inşa edilmiş yürütme katmanları (Execution Layers) bize daha iyi bir şeyler inşa etmek için yeni bir fırsat veriyor. Tasarımların geriye dönük uyumlu olması gerekmez ve aslında Ethereum için küresel verim ve benimseme sağlamak için ne gerekiyorsa yapabilir.

   Yürütme katmanları ileriye doğru bir yol sağlar.

4. Bir zamanlar, herhangi bir CPU mimarisinin x86 dışında bir şey olabileceği düşünülemezdi, ancak zaman geçtikçe ve alternatiflerin faydaları ortaya çıktıkça, ARM şimdi birçok mobil üründe ve Apple ürününde çok fazla kullanılıyor.

   FuelVM'de de benzer bir ışık görüyoruz.

5. EVM'nin L1 veya L2 olarak kullanılmaya devam etmesi; blok zinciri uygulamaları için pahalı ve son derece kısıtlı bir tasarım alanı yaratacak, küresel erişilebilirliği sadece bunu karşılayabilecek birkaç kişiyle sınırlayacak, DeFi projelerini kısıtlayacak ve büyümeyi azaltacaktır.

6. Küresel talep arttıkça ve hesaplama alanı (compute space) daha kıt hale geldikçe, uygulamalar, Ethereum'a ve EVM'ye daha iyi alternatifler aramaya başlayacak ve bunlardan taşınmaya zorlanacak.

   https://twitter.com/musalbas/status/1539736794215976960

7. Birçok yönden FuelVM'yi, WASM, Bitcoin ve diğer popüler blokzincirlerinden (çalışma zamanlarından - runtime) öğrenilenlere ek olarak, yıllar boyunca uygulanan en güçlü fikirlerin bulunduğu bir EVM olarak düşünebilirsiniz.

   Bir anlamda: FuelVM, 'büyük ölçüde geliştirilmiş' bir EVM'dir.

   Fakat nasıl farklı?

8. Yeni başlayanlar için FuelVM, 256 değil 64-bit kelimeler kullanır. 256-bit EVM'de bize iyi hizmet etmiş olsa da, FuelVM'deki kütüphaneler, büyük sayılar gibi şeyleri işlemek için uygulama düzeyinde verimli bir şekilde oluşturulabildiğinden, bu kelime boyutunu korumaya pek gerek yoktur.

   https://medium.com/coinmonks/10-evm-design-mistakes-7c9a75a77ee9

9. FuelVM, yığın tabanlı (stack-based) yerine kayıt tabanlıdır (register-based).

   Blok zincirlerde her işlem ücretlendirilir. Görüldüğü gibi, bu ek yük çok pahalıdır. Aynı miktarda işi yapmak için gereken işlem sayısını azaltmak için optimizasyon, çok büyük avantajlara sahiptir.

10. Kayıt tabanlı VM'ler, yığın tabanlı VM'lere kıyasla genellikle aynı işi yapmak için daha az talimat gerektirir.

    Bu sebeple FuelVM'ye güzel bir uyum gösterirler.

    https://arxiv.org/abs/1611.00467

11. FuelVM, yeni bir bellek mimarisine sahiptir.

    EVM'de her kontrat çağrısı, iletilen veya döndürülen verileri seri hale getirmelidir. Bu, kontratlar arası iletişimi ciddi şekilde sınırlayan israf edilmiş bir işlemdir.

12. Fuel ile, kontratlar arasında arama yapmak, yalnızca işaretçileri verilere aktarmak kadar kolaydır, çünkü tüm çağrı yapıları (call frames), paylaşılan bir bellek bloğundan herhangi bir yerde okuyabilir.

    https://github.com/FuelLabs/fuel-specs/blob/master/specs/vm/instruction_set.md

13. FuelVM, sahtekarlık kanıtlanabilirliği (fraud-provability) için tasarlanmıştır.

    EVM, sahtekarlık kanıtları oluşturmak için zor bir yapıdır. Genellikle WASM veya MIPS gibi ikincil bir katmanın, sahtekarlıkla kanıtlanabilir bir sisteme yorumlanmasını bile gerektirir.

14. FuelVM, en başından beri sahtekarlığı kanıtlayacak şekilde tasarlanmıştır, tüm operasyonlar bu özellik göz önünde bulundurularak seçilmiştir.

    https://github.com/FuelLabs/fuel-specs

15. FuelVM'nin birden çok yerel varlığı vardır.

    Ethereum'da tek yerel varlık Ether'dir. Maliyet anlamında birinci sınıf muamele gören ve bir çağrı yoluyla itilip çekilen bir tek O'dur.

16. Fuel'de herhangi bir kontrat, bir dizi kolay varlık işlem kodu kullanarak kendi UTXO tabanlı yerel varlığını basabilir. Bunların tümü, yerel düzeyde arama ve optimizasyonun avantajlarını elde edebilir.

    https://fuellabs.github.io/sway/v0.16.2/blockchain-development/native_assets.html

17. FuelVM, dinamik uzunluk memcopy, memequal ve memclear gibi kaynak kısıtlı sistemlere yardımcı olan birçok operasyona sahiptir.

    Bu işlemleri EVM'de yapmak, yineleme ve döngüler kullanmayı gerektirir, bu da bellek alanları üzerinde çalışmayı olması gerekenden daha pahalı hale getirir.

18. FuelVM, yüklemler adı verilen bir tür hesap soyutlamasını zaten içeriyor.

    Bitcoin'den devralınan ödeme komut dosyası hash'inin (pay to script hash) bir türü, bir harcama koşulu komut dosyasına (spending condition script hash) coin gönderebilir. Bu, çoklu imzalar gibi şeylerin herhangi bir sözleşme olmaksızın kullanılmasına ve oluşturulmasına izin verir.

19. FuelVM, komut dosyalarıyla UX'den onay/aktarma ihtiyacını ortadan kaldırır.

    EVM'den farklı olarak FuelVM, bir kontrat dağıtılmadan (deploy) bir kaynak göndericiden birçok eylemin gerçekleşmesine izin veren komut dosyalarına sahiptir.

20. FuelVM, başlangıçtan itibaren atomik bir UTXO paradigması ile inşa edilmiştir.

    Hesap modelinden farklı olarak Fuel, daha verimli bir varlık transferi ve mülkiyeti sağlayan bir UTXO sistemi kullanır; burada fonlar her aktarıldığında hesap ağacının yeniden oluşturulması gerekmez.

21. FuelVM, denetlenebilirlik için tasarlanmıştır.

    EVM'den farklı olarak, FuelVM'nin operasyonlarını uç durumları denetlemeyi göz önünde bulundurarak tasarladık ve kendi kendini yok etme durumları gibi tuhaf durumlarla karşılaşmamamızı sağlamak için her bir işlem kodunun olası yan etki sonuçlarını basitleştirdik.

22. FuelVM, çok tanıklı, çok girişli, çok çıkışlı işlemler için tasarlanmıştır.

    Bir işlem, geliştiriciye işlem (transaction) düzeyinde çok daha fazla seçenek sunan birçok farklı tanık ve yerel varlık içerebilir.

    https://twitter.com/fuellabs_/status/1500942977371357184

23. FuelVM, farklı sig-hash durumları sağlar.

    Bu, birden fazla taraf tarafından kısmen imzalanmış işlemlere izin verebileceğinden, meta işlemler gibi şeylerin işlem düzeyinde yapılabileceği anlamına gelir.

    https://eips.ethereum.org/EIPS/eip-2771

24. FuelVM, tüm işlemi bellekte sağlar.

    Bu, kısıtlayıcı mantığın tipik olarak kullanılacağı koşullu harcama koşulları için özellikle önemli olan yürütme sırasında tüm işlem ayrıntılarının iç gözleminin daha iyi yapılmasını sağlar.

25. FuelVM, güvenli matematik ile kuşanmış olarak gelir.

    Ethereum'da tek bir kütüphanenin sayısız dağıtımı vardır: güvenli matematik. FuelVM bunu VM düzeyinde sağlar ve istendiğinde etkinleştirilebilir veya devre dışı bırakılabilir.

    https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/math/SafeMath.sol

26. FuelVM talimatları 32-bit kelime uyumludur (aligned).

    EVM bayt kodu, sözcük uyumlu değildir, bu da ayrıştırmayı olması gerekenden daha karmaşık hale getirir.

    Tüm FuelVM işlemleri, verimli ayrıştırma, sahtekarlık kanıtlanabilirliği ve denetlenebilirlik için tasarlanan 32 bit sözcük uyumludur.

27. FuelVM, yığın yönetimi (heap management) için tasarlanmıştır.

    EVM'den farklı olarak FuelVM, yığınları yönetmek için hoş operasyonlarla yüklü olarak gelir. Ortak dinamik bellek içi veri yapılarını kullanmak için toplam maliyeti azaltır.

    https://github.com/FuelLabs/fuel-specs/blob/master/specs/vm/instruction_set.md#aloc-allocate-memory

28. FuelVM, takımlarla (tooling) dikey olarak entegre olacak şekilde tasarlanmıştır.

    Başlangıçta bir dil olmadan tasarlanan EVM'den farklı olarak FuelVM, kendine eşlik eden dili @swaylang ile birlikte oluşturulmuştur ve (swaylang)'in, bir işlemin (transaction) belirli kısımlarını almak gibi kullanışlı ve verimli özelliklere sahip olduğundan emin olunmuştur.

29. Düz-ingilizce özelliği.

    Ethereum yellow paper'ı, EVM'yi detaylandırma hedeflerini gerçekleştirirken Okuması ve yorumlaması kolay bir belge değildi.

    FuelVM, geliştiriciler ve denetçiler için kolay anlaşılması için işaretlemede düz İngilizce olarak belgelenmiştir.

30. Ethereum ile hashing ve imzalama için geriye dönük uyumluluk.

    FuelVM, MetaMask veya Ethereum Ledger uygulaması gibi standartlaştırılmış Ethereum cüzdanlarından hesap yönetimi, imza oluşturma ve hash oluşturmayı sağlayan Ethereum'un keccak256 operasyonuna sahiptir.

31. Şube (Branch) optimizasyonu.

    Tüm FuelVM operasyonları, operasyon başına meydana gelen dahili şubelerin(branch) azaltılması için maksimum optimizasyon fırsatı sağlamak üzere tasarlanmıştır.

    Şube sayısını azaltmak, aynı davranışları gerçekleştirirken operasyonların daha ucuza fiyatlanabilmesi anlamına gelir.

32. Standartlaştırılmış hash için tercih: sha256.

    FuelVM, keccak256 Ethereum'dan hem çok güvenli, hem daha verimli hem de resmi olarak standartlaştırılmış olduğu anlaşıldığından, tüm büyük karma işlemleri için sha256 kullanır.

    https://twitter.com/drakefjustin/status/1110648087352090625

33. Kurucunun(constructor) kaldırılması.

    EVM, sözleşmeli kuruculara izin verirken, potansiyel yan etkiler nedeniyle bir güvenlik riski de ekler.

    FuelVM, uç durumları ortadan kaldıran ancak yine de bir geliştiricinin bir sözleşmenin ilk durumunu ayarlamasına izin veren daha basit bir depolama başlangıcına(inin) izin verir.

34. Tüm kontrat kimlikleri deterministiktir.

    EVM için, deterministik sözleşme kimlikleri yalnızca create2 ile bir gerçekten sonra eklendi.

    FuelVM, varsayılan olarak deterministik sözleşme adreslerini etkinleştirir. Tüm kontrat kimlikleri, bir parçanın(salt), kontrat kodunun ve başlangıç ​​durumunun özetidir.

35. FuelVM, benzer kontrat ve çağrı paradigmalarını sürdürür.

    Diğer EVM olmayan tasarımların aksine Fuel, Ethereum ile alıştığımız tanıdık kontrat ve çağrı paradigmalarını geride bırakmaz, ancak scriptlerle deneyimi geliştirir.

    https://fuellabs.github.io/sway/v0.16.2/blockchain-development/calling_contracts.html

36. FuelVM benzer depolama işlemlerine sahiptir.

    WASM çalışma zamanlarından (runtime) farklı olarak Fuel, Ethereum'un kullanışlı depolama API'sini tutar ve bireysel hesapların geliştirici tarafından yönetilmesi gerekmeyen tanıdık bir anahtar/değer deposu modeline izin verir.

    https://github.com/FuelLabs/fuel-specs/blob/master/specs/vm/instruction_set.md#swwq-state-write-32-bytes

37. FuelVM'nin nasıl çalıştığını görmek istiyorsanız, lütfen aşağıdaki linkten -@SwayLang ve Fuel devnet'teki FuelVM kullanılarak oluşturulmuş- Uniswap tarzı bir DEX olan SwaySwap'a bakın.

    https://twitter.com/fuellabs_/status/1539987539985055744

38. FuelVM kullanarak geliştirme yapmak istiyorsanız, Sway Book'u okuyarak ve ilk Fuel uygulamanızı geliştirerek başlayın.

    https://fuellabs.github.io/sway/v0.16.2/

39. FuelVM'yi incelemek istiyorsanız, bootcamp'ine göz atın.

    

40. FuelVM'nin hedeflenen amacı, dünyaya verimli, taşınabilir, sahtekarlık kanıtlanabilir ve erişilebilir bir blok zinciri sanal makinesi sağlamaktır.

    FuelVM'nin otonom geleceği sağlamak için kritik olduğuna inanıyoruz.

    https://twitter.com/fuellabs_/status/1516054414330458117

41. Daha fazlasını discordda konuşalım!

    https://discord.com/invite/xfpK4Pe

Espresso Systems, Espresso'yu geliştiriyor: yüksek verim ve düşük ücretler elde etmek için PoS konsensüsü ile ZK-Rollup mekanizmasını birleştiren bir L1 blok zinciri sistemi. Espresso ayrıca, herhangi bir EVM blok zincirinde çalışabilen (ve sonunda Espresso'da yerel olarak çalışacak) bir uygulama olan Ethereum için Yapılandırılabilir Varlık Gizliliği'ni(Configurable Asset Privacy - CAPE) geliştirmiştir. CAPE, varlık üreticilerinin kullanıcılara özelleştirilmiş gizlilik garantileri (customized privacy guarantees) sunmasına olanak tanır.

Hem ölçeklendirme hem de gizlilik hakkında ne düşündüğümüz ve Web3'ün olanaklarını dönüştürecek sistemleri nasıl oluşturduğumuz konusunda aşağıda daha fazlasını okuyabilirsiniz. Yakında Ethereum'un Rinkeby test ağında bir demo olarak yayınlanacak olan CAPE'in ilk sürümümüzü inceleyebilirsiniz. Ayrıca sıfır bilgi kanıtları için kitaplığımız olan ve diğer kriptografi araçları olan açık kaynaklı yazılım Jellyfish'i de sunarız. Bizi Twitter ve Discord'dan da takip edebilirsiniz.

MERKEZİYETSİZ ZK-ROLLUPLAR

Espresso'nun iş hacmini ölçeklendirme yaklaşımı, merkeziyetsiz bir PoS konsensüs protokolü ile EVM için ZK-Rollup'un dikkatli bir şekilde entegrasyonunu içerir. ZK-Rollup, tipik olarak mevcut bir konsensüs protokolünün üzerinde bir L2 olarak uygulanan, gelişmekte olan bir ölçeklendirme tekniğidir. Bir sunucu, çok sayıda işlemi tek bir özet işlemde toplar ve geçerliliklerinin kısa ve öz bir sıfır bilgi kanıtı (zk-SNARK) üretir ve daha sonra konsensüs sistemine gönderilir. Bu rollup kanıtı, konsensüs protokolünün işlemleri doğrulamak için ihtiyaç duyduğu hem bilgi miktarını hem de hesaplamayı sıkıştırarak verimi artırır. Ethereum için çeşitli rollup çözümleri geliştirilmektedir, ancak mevcut tasarım alanıyla ilgili bir sorun var: veri kullanılabilirliği sorunu (data availability problem). Kullanıcıların yeni işlemler oluşturmak için verilere ihtiyaç duyarlar. Sıfır bilgi kanıtı, ham veri içeriğini ifşa etmeden bir işlem bloğunun geçerliliğini iletebilirken, gelecekteki işlemleri oluşturmak için gerekli olan verilerin kullanılabilirliğini garanti etmez. Sorunu çözmek için, mevcut rolluplar ya konsensüse gönderilen özet işlem içindeki ham işlem verilerini içerir ya da verileri gördüğünü onaylamak için merkezi bir veri kullanılabilirlik komitesi (data availability committee) kullanır. İkisi de tatmin edici değildir; birincisi sınırlı sıkıştırmaya ve dolayısıyla sınırlı ölçeklendirmeye sahipken, diğeri merkeziyetsizliği baltalar.

Gerekli olan, merkeziyetsiz veri kullanılabilirliğini (decentralized data availability) korurken verimi en üst düzeye çıkarabilecek bir yaklaşımdır. Espresso Systems olarak biz, ZK-Rollup ölçeklendirme mekanizmasını en başından beri PoS konsensüs protokolümüzle sıkı bir şekilde entegre ederek buna bir çözüm geliştiriyoruz. Espresso ZK-Rollup'un doğal olarak konsensüs ile entegre olması;-ona bir kara kutuymuş gibi davranmasına gerek yok- Espresso'nun, rollup temelli konsensüs protokolüne agnostik ayrı bir modüler bileşen olarak yaklaşan diğer tasarımlar gibi ödün vermekten kaçınmasını sağlayacak şeydir.

Önümüzdeki haftalarda ölçeklendirme yaklaşımımız hakkında çok daha fazlasını paylaşacağız. Güncellemeler için lütfen Twitter ve Discord kanalımız üzerinden bizi takip etmeye devam edin.

ETHEREUM ÜZERİNDE YAPILANDIRILABİLİR VARLIK GİZLİLİĞİ

CAPE (Configurable Asset Privacy for Ethereum), Espresso Systems tarafından geliştirilen ve dijital varlık oluşturucuların bastıkları tokenlerdeki (mint) etkinlik hakkında kimin hangi bilgileri görebileceğini belirlemelerini sağlayan bir akıllı sözleşme uygulamasıdır.

Stabilcoinlerden NFT'lere kadar CAPE'deki dijital varlıklar, Web3 ürünlerinin belirgin bir avantajı olan şeffaflığı, kullanıcılar tarafından ihtiyaç duyulan her yerde gizlilikle dengeleyecek şekilde özelleştirilebilir. CAPE işlemleri anonim ve normal izleyiciler için ayırt edilemez görünürken, işlem yapılan varlığın türünü bile gizlerken, bir varlığın yaratıcısı bir görüntüleme politikası yapılandırabilir, bu da belirli tarafların o varlık için işlemlerle ilgili seçilmiş bilgilerin şifresini çözebilmesini sağlar.

CAPE, yeni varlıklar oluşturmak veya Ethereum'da zaten var olan varlıkları sarmak (wrap) için kullanılabilir ve onlara gizlilik özellikleri kazandırır. Bir ERC-20'yi CAPE ile sarmak, kimin neyi görebileceğini ve kimin söz konusu varlıklarla ilgili belirli kontrolleri sürdürebileceğini yapılandıran bir sarmalayıcı tipinin belirtilmesini gerektirir. Sarma, varlığı ERC-20 sözleşmesinde kilitleyip belirtilen türde karşılık gelen bir CAPE varlığı oluştururken, sargıyı çözme (unwrap) ise CAPE varlığını yakar ve kilidi serbest bırakır.

CAPE, varlık oluşturmak veya sarmak isteyen herkes tarafından kullanılabilirken, protokol, özellikle stabilcoin sağlayıcıları düşünülerek tasarlandı. Stablecoin sağlayıcıları günümüzde genellikle dolandırıcılık, hırsızlık ve anlaşmazlık çözümleri ile baş etmeye çalışmakta ve varlıkları için faaliyet defterine (ledger) ve varlık dondurma yetenekleri gibi kontrollere ilişkin bilgileri muhafaza edebilmeyi talep etmektedirler. CAPE'den önce, bu tür varlık oluşturucuların, görünürlük ve anlaşmazlık çözümüyle ilgili ihtiyaçları karşılarken tokenlarının gizlilik etkin sürümlerini kullanıcılara sunmaları için hiçbir çözüm yoktu. CAPE'nin görüntüleme ve dondurma politikalarıyla bu artık mümkün. Varlık oluşturuculara bu yetenekleri vermenin yanı sıra, CAPE, kullanıcıların hangi verileri paylaştıklarından haberdar olmalarına ve bunları aktif olarak seçmelerine ve kimlerin işlemlerine ilişkin iç görülere sahip olduklarına ve işlemleri üzerinde kontrole sahip olabileceklerine olanak tanır.

CAPE'in kaynak kodlarına buradan ulaşabilirsiniz. CAPE herhangi bir EVM blok zincirinde çalıştırılabilse de, uygulamayı Espresso'ya geçirmek ve bir köprü aracılığıyla Ethereum varlıklarıyla etkileşimi sağlamak için nihai planlarla Ethereum Rinkeby test ağında bir demo olarak yakında yayınlayacağız.

CAPE'in açık kaynak kontratlarına buradan ve dokümanlarına da buradan göz atabilirsiniz.

SIRADA NE VAR?

Tüm bunları gerçeğe dönüştürmek için, Espresso Systems'ın Greylock Partners ve Electric Capital liderliğinde Sequoia Capital, Blockchain Capital ve Slow Ventures'ın katılımıyla 32mm $ fon sağladığını paylaşmaktan heyecan duyuyoruz. Polychain Capital, Alameda Research, Coinbase Ventures, Gemini Frontier Fund, Paxos ve Terraform Labs gibi büyük endüstri oyuncuları da Espresso Systems'ı desteklemektedir.

Bu fon, Web3'ü geniş çapta benimsenmeye hazır hale getirecek altyapı ve ürünleri araştıran, inşa eden ve uygulayan ekibi büyütmek için gerekli kaynakları sağlayacaktır. Fonlar aynı zamanda bu ürünleri bir dizi kanal aracılığıyla pazara sunmaya da gidecektir. Örneğin; yerel son kullanıcı ürünlerinin dağıtımı, geliştiricilerin benimsenmesi ve girişimciler, yeni kurulan şirketler ve işletmelerle ortaklıklar.

Önümüzdeki birkaç hafta içinde, Ethereum Rinkeby test ağında CAPE'i sunacağız ve uygulama için bir grafik kullanıcı ara yüzü yayınlayacağız. Ayrıca ölçeklendirme çözümümüz hakkında daha fazla bilgi paylaşacağız.

Daha fazlası için web sitemize buradan ulaşabilir, Discord ve Twitter topluluğumuza katılabilirsiniz.

NOT: Anlatırken daha iyi öğreniyoruz. Ben de önce kendime sonra da ilgilenenlere anlattım. Bu yazı resmi bir çeviri olmamakla beraber aslıyla birebir aynıdır.

Orjinal yazının linki:

https://www.espressosys.com/blog/introducing-espresso-systems