Modular Yapılar Deep Dive 🤿: Execution Layer & Fuel
Roq4
Başlamadan,
Yazı, okurun Modular ve Monolitik yapılar hakkında belli bir miktar ön bilgiye sahip olduğu varsayılarak hazırlanmıştır ve bu nedenle, yazıya başlamadan önce aklınızda oluşabilecek soru işaretlerini gidermesi adına, Zero to Hero - Modular Yapılara Muhtaç Mıyız? başlıklı bu serinin ilk yazısını okumanızı öneririm. Yazı 3 ana bölümden oluşmaktadır. İlk bölüm monolitik ve modular execution karşılaştırmasından bahsediyoruz, ikinci bölümde rollup ve modular execution layer farkına göz atıyoruz, kapanışı ise Fuel ve kendi sanal makineleri olan FuelVM ile yapıyoruz. Ben araştırırken çok şey öğrendim, umarım size de bu bilgileri aktarabilirim! Geri dönüşlerinizi bekliyorum, keyifli okumalar! 🥳
Önce Monolitik Zincirler & Execution! 🧐
Serinin ilk yazısında olduğu gibi, bu yazıya da başlarken öncelikle monolitik zincirlerde gerçekleşen Execution’ı anlayıp sonrasında Modular Execution Layer (MEL) (yazının devamında MEL şeklinde kısaltılarak kullanılmıştır) ile olan ilişkisine bakmanın daha sağlıklı olacağını düşünüyorum. O zaman lafı çok uzatmadan başlayalım🥳
Geçtiğimiz yıllarda çıkan birçok blokzincir teknolojisine baktığımız zaman monolitik yapılardan kurtulamamışlardır. Kısa bir özet geçmek amacıyla bu yapılara bakacak olursak, ana katmak (base layer) olarak Consensus Layer’ın içerisinde Data Availability, Settlement ve Execution birlikte bulunmaktadır. Çoğunlukla ise Settlement ve Execution birbirlerine bağlı şekildedirler. Buradaki problem ise monolitik yapıların bütün işi ana katmanda gerçekleştirmesi ve dolaylı olarak üzerine düşen iş yükü nedeniyle, blokzincir yapısının sahip olduğu potansiyeli limitlemesidir.
Özel olarak Execution Layer’a bakacak olursak, MEL’leri monolitik muadillerinden ayıran 2 temel unsur olduğunu görmekteyiz.
MEL, hesaplama(computation, execution) ve doğrulama(verification) proseslerini birbirinden ayırırken, monolitik zincirlerde hesaplama ve doğrulama görevleri birlikte bulunmaktadır. Bu nedenle monolitik zincirler güvenlikten taviz vermemek için güvenirliği ikinci plana atarken, MEL ölçeklenebilirken güvenlikten taviz vermez.
MEL, hesaplama süreci için özel olarak optimize edilebilirken, monolitik zincirler hız ve çeşitlilik konusunda çok daha verimsiz kalmaktadırlar. [1]
Yukarıdaki bu iki temel unsuru anlamak için öncelikle computation ve verification nedir buna bakmamız gerekiyor. Gene kısa bir tanımlama yaparsak, computation ve verification monolitik zincirlerin güvenliğinden (security) ve dürüstlüğünden (integrity) emin oluyor diyebiliriz.
Computation süreci boyunca, ağda kullanıcılar işlem yaptıkça bu işlemler validatörler tarafından alınır ve blokzincirin kurallarına göre geçerliliği doğrulanır. Bu kontrolden geçen işlemler zincir üzerindeki yeni bir bloğa eklenir.
Verification, monolitik zincirlerde hem blokların hem de işlemlerin doğruluğunu kontrol etme sürecine verilen isimdir. Ağdaki her validatör bulunduğu blokzincirin bir kopyasına sahiptir. Yeni işlemlerin ve blokların geçerliliğini kendi blokzincir kopyalarına göre karşılaştırarak doğrularlar, geçerliliği kabul edilen blokları kendi kopyalarına eklerler, eğer bir işlem veya blok geçersiz olarak kabul edilirse ağ tarafından reddedilir.
Monolitik zincirlerde, tüm validatörler işlemlerin hem hesaplamasını hem de doğrulamasını yapar. Bazen kullanıcılar ya da uygulamalar bütün bir zincirdeki işlemleri doğrulamak istemezler ve sadece zincir üzerindeki doğrulanmış işlemlere ulaşmak isteyebilirler. Bunu yaparken full-node çalıştırmak yerine light-node çalıştırarak full node’ların doğruladığı dataya ulaşabilirler yani tamamen full-node’lara bağlıdırlar. Bu duruma bilinen adıyla Honest Majority Assumption (Çoğunluğun Dürüst Varsayımı) denir ve bu durum bütün monolitik zincirleri 51% atağı ile karşı karşıya bırakmaktadır.
Azınlığın Sesi Modular Execution Layer 🤯
Yukarıda bahsettiğimiz monolitik zincirlerin bu durumundan bizi kurtarmak adına yardım çığlığımıza modular yapılar yetişiyor! Bunu nasıl yaptığına aslında yukarıda ilk madde de bahsettik, computation ve verification proseslerini monolitik yapıların aksine birbirinden ayırarak. Execution (computation) prosesi ana katmandan ayrıldığından dolayı zincirin ölçeklenebilirliği artarken aynı zamanda merkeziyetsizlikten de ödün verilmiyor.
Başka bir deyişle, modular zincirlerde execution layer işlemin, işlenme sürecinden ve durum geçişlerinin (state transition) uygulanmasından sorumludur. Fuel’ın tanımlamasına göre MEL, modular zincir yapıları için özel olarak tasarlanmış onaylanabilir sistemlerdir. Yani fraud proof ya da validity proof ile anlaşma sağlanarak dataya ulaşabilmelidirler.
Ayrıca MEL’de hesaplamanın doğrulama prosesinden ayrılmasından dolayı, doğrulama işlemi merkeziyetsiz olduğu sürece hesaplamanın merkeziyetsizliğinin bir önemi kalmamaktadır. İki işlem birbirinden ayrı olduğundan dolayı blok boyutu ne kadar artarsa artsın (zincirin forklanması örnek olarak verilebilir) doğrulama ayrı bir işlem olduğu sürece geçersiz olan blokların zincire eklenmesi engellemiş olur. [1]
Giriş kısmında bahsettiğimiz iki maddeden ilkine birlikte bakabildik, çok uzamaması adına ikinci madde ile alakalı fuel-labs’ın kendi yazısının linkini bırakıyorum. Gayet açıklayıcı ve öğretici, ben okurken birçok şey öğrendim siz de devamına oradan bakabilirsiniz. Aynı zamanda ilk madde ile alakalı yazıya da kaynaklar kısmından ulaşabilirsiniz.
Rolluplara Bakmadan Geçmek Olmaz 🥐
Modular stack üzerinde execution layer’dan bahsederken rollup’lara bakmadan geçmek olmazdı. Serinin ilk yazısında bir ön bilgi olarak rollup’ların execution layer üzerinde özelleşmiş birer tür olduğunu söylemiştik. Bu söylemi biraz daha açalım istedim, hadi başlayalım.
Şu soruyla başlayalım o zaman, rollup’lar birer blokzincir midir? Evet birer blokzincirdir fakat kendi datasına sahip başka bir monolitik zincire (bkz. Ethereum) bağlıdırlar ve bağlı oldukları bu zincir üzerindeki işlemleri off-chain olarak execute’layıp bunları toplu bir şekilde tek bir işlem olarak geri monolitik zincire gönderirler. Peki bunun nasıl bir avantajı var diye sorarsanız, ana zincir üzerindeki işlemler off-chain olarak execute’landığı için zincirdeki rekabet azalır. Peki bunun nasıl bir dezavantajı var diye soracak olursanız, ana monolitik zincire olan bağımlılık. Tabi bir blokzincire rollup diyebilmek için bu yeterli değildir, aynı zamanda zincirin kendi proof (fraud proofs, validity proofs) ve permissionless mekanizmaları da olması gerekmektedir. Rollup’ların çıkış amaçları ise her zamanki gibi bağlı oldukları monolitik zincir üzerindeki ölçeklenebilirlik sorununu çözmektir. [3]
Modular Execution Layer = Rollup + ?? 🤔
Rollup’ları birazda olsa anladıktan sonra artık sıra MEL’in rollup’lardan farkları neler bunlara bakmanın zamanı geldi. Daha önce de söylediğimiz gibi rollup’lar aslında execution layer üzerine özelleşmiş yapılardır. Fuel ve Celestia Co-Founder’ı John Adler abimizin de dediği gibi Rollup’lar USB-3 ise MEL’ler Thunderbolt-3’ dir (Evet adam kaynaklardaki podcastte tam olarak bu benzetmeyi yaptı :D) USB-3 kablosuyla birçok işimizi yapabiliriz fakat Thunderbolt-3 ile hem USB-3’nin yaptığı bütün işlemleri yaparken hem de fazladan birçok özellikte kazanmış oluruz. Bu özelliklerden 2 tanesi,
MEL ile birlikte, kullanıcılar full-node çalıştırmak zorunda kalmadan light-node larını off-chain olarak çalıştırabilecek ve aynı zamanda full-node’a gerek kalmadan zinciri onaylayabilir. Bu sayede ise yapıya olan güven gereksinimi (trust minimization of the structure ) oldukça azalır, yani bir diğer deyişle yapı daha güvenilir hale gelir.
MEL herhangi bir monolitik L1 zincirine bağlı değillerdir, oldukça esnek şekilde kullanılabilirler. [2]
Modular Execution Layer’ların zengin kullanım şekillerine örnek, kaynak: fuel
Özetlersek, MEL rollup’ların bütün temel özelliklerini kendi üzerinde taşırken aynı zamanda trust minimizate sistemlerdir ve rollup’lar gibi iki yönlü bir köprü görevi görmektense, herhangi başka bir ana ağa ihtiyaçları yoktur.
Sahnede Fuel ⛽
Yukarıda bahsettiğim iki maddeyi Fuel üzerinden anlatmanın daha mantıklı olacağını düşünüyorum. Kısaca Fuel nedir diye özetlemek gerekirse birçok yerde de görebileceğiniz gibi kendi tanımlamalarıyla “Fuel is building the fastest execution layer for the modular blockchain stack.*“,* yani abiler diyor ki benden hızlısı mezarda ve sadece bunu demekle kalmıyorlar ve gerçekleştiriyorlar. Daha önemli olan kısmıysa dediklerini gerçekleştirirken herhangi bir güvenlik tavizi vermiyor olmaları. Peki bu nasıl mümkün olur?
Parallel Transaction Execution: Zincirdeki işlemlerin birden çok çekirdekte aynı anda doğrulandığı bir modeldir.
FuelVM (Daha detaylı olarak bir sonraki başlıkta bakacağız o yüzden şimdilik pas geçiyorum.)
Sway: Sway = Rust + Solidity şeklinde bir denklem kurulabilir. Sway, Rust’ın compile-time analizlerini ve güvenliğini alıp aynı zamanda syntax’ini kullanırken, Solidity’nin akıllı sözleşme yazma konusundaki ergonomosine ve güvenli yapısına sahiptir. [2]
FuelVM = EVM ++
Başlıktanda anlaşılacağı gibi Fuel Virtual Machine aka FuelVM kendine çıkış noktası olarak Ethereum Virtual Machine aka EVM’i örnek almıştır. Fuel üzerinde geliştirme yapmayı düşünen bir geliştiriciyseniz öncelikle EVM’i tam anlamıyla öğrenmiş olmak işinizi epey bir kolaylaştıracaktır çünkü FuelVM aslında EVM’in daha yenilikçi ve daha optimize olan bir hali gibi düşünülebilir. Dizayn olarak bakıldığında birkaç nüans farkı olsa da oldukça benzer durumdalardır. Peki bu FuelVM’in özel yanı ne diye soruyorsanız madde madde inceleyelim bakalım,
FuelVM, yerel bir hafıza yerine global olarak paylaşılan bir hafıza mimarisine sahiptir. Buradaki amaç her akıllı sözleşmenin kendi ayrı memory space, call data ve return datasına sahip olması yerine bunu global bir yapıdan sözleşmelere çağırtmaktır. Bu sayede ise datanın akıllı sözleşmeler arasında gezerken oluşturduğu maliyet azaltılmıştır.
FuelVM fraud-proof olarak inşa edilmiştir. Bu sayede Fuel light-client’larının bir trusted-party’e ihtiyacı kalmaz, full-node’a göre daha az kaynak kullanır ve günümüzdeki light-client’lara oranla çok daha güvenli bir yapıya sahip olur. EVM fraud proofs üzerine inşa edilmek için fazla karmaşık bir makinadır, bu nedenle genellikle ikinci bir katmana ihtiyaç duyar.
trust minimized light client’ların full node ve günümüzdeki light client’lar ile farkları, kaynak: fuel
FuelVM üzerinde birden fazla yerel varlık kullanılabilmektedir, öte yandan mainnette ise tek yerel varlık Ether’dir. FuelVM’in bu esnek yapısı sayesinde Fuel üzerindeki herhangi bir kontrat UTXO tabanlı herhangi bir yerli varlığı kullanabilir.
FuelVM 256-bit yerine 64-bit kelimeleri kullanır. Bu sayede geliştiricilerin akıllı sözleşme tarafında BigNumber hatalarından kurtulması sağlanmıştır. [2]
Son Sözler ⌛
Modular stack sayesinde blokzincir üzerindeki tek düzelikten kurtulmak ve çok daha esnek hareket etmek hedeflenmektedir. Özelikle MEL’lerin herhangi bir monolitik L1 zincire bağlı kalmak zorunda olmaması bunun en güzel örneği olarak verilebilir. Bu sayede ise modular stack, EVM’in yetersiz kaldığı durumlarda kendi çözümlerini üretebilir. Fuel ise bu düzenin MEL tarafındaki en büyük oyuncusu konumundadır. EVM’in ötesine giderek geliştirdikleri kendi sanal makineleri ve dilleri sayesinde Fuel, hem verimli hem de ölçeklenebilir execution’lar sağlarken aynı zamanda üstün geliştirici deneyimi ve maximum güvenlikten de vazgeçmemiştir. Tüm bu nedenlerden ötürü bitirişi şu cümle ile yapıyoruz,
Modularism, not Maximalism!
Kaynaklar ℹ️
Subscribe to my newsletter
Read articles from Roq4 directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by