ROLLUP ÇALIŞMA MEKANİZMASI VE ÇEŞİTLERİ
Blockchain ağları özünde, hepsi aynı programı çalıştıran bir grup bilgisayardır. bu nedenle işleyebilecekleri işlem (transaction) sayısı, bilgisayarın programı çalıştıran gücüyle sınırlıdır. İnsanlar daha güçlü donanımlara sahip bilgisayarları çalıştırabilseler de bunun bir sınırı vardır ve yüksek donanımlı bilgisayarların çalıştırılması daha pahalı hale geldikçe, bunu yapmaya gücü yeten insan sayısını sınırlayarak merkezileşmeye yol açar. Ethereum, kendisinin işlemek durumunda olacağı Transaction’ları (işlem verileri) üzerinde çalışacak Layer 2 (ikinci katman) adı verilen uygulamalara işlem yaptırma ile bir çözüm yöntemi geliştirip, Transaction’ları işleyebilme kapasitesini (Execution) devrederek bu sorunu hafifletmeye yönelik bir yol haritasını benimsemiştir. Böylece Layer 1 (birinci katman) denilen Ethereum ağı üzerindeki “Node”’ların (blockchain programını yürüten ve transaction’ları işleyen bilgisayarlar) yapacak daha az işi olur ve “Execution ölçeklemesi” yaratır.
Rollup’lar, Layer 2 çözümlerinden biridir ve hepsinin kendi özellikleri olan birçok Rollup türü vardır;
- Smart Contract Rollup
- Validium
- Volitions
- Sovereign Rollup
Merkle Tree
Rollup’ların nasıl çalıştığına girmeden önce, çalışma mantığını anlamanın önemli bir ön koşulu “Merkle Tree” denilen veri yapısını anlamaktır. Merkle Tree, herkesin fonlarının ve işlemlerinin durumunun depolandığı veri yapısıdır. Bu anlık durumlara da “State” denir.
Diyelim ki Abdurrahman Amca’nın 3 Ether sahipliği ve Melahat Teyze’nin 5 Ether’e sahipliği gibi State’e dahil etmek istenilen parçalar olsun. Bu state parçaları daha sonra Leaf Node olarak adlandırılan şeyi oluşturmak için hash yapılır. Hash, bir veri grubunun kriptografik özeti demektir. Leaf Node denilen Merkle Tree’nin hash edilmiş yaprağı, daha sonra “Branch Node” oluşturmak için yine başka bir Leaf Node ile hash edilir.
Daha sonra iki Branch Node, başka bir Branch Node oluşturmak için birlikte hash edilir (özetlenir) ve “State Root” (Durum Kökü) veya “Merkle Root” (Merkle Kökü) olarak adlandırılan tepeye ulaşana kadar devam eder. “Root” (Kök) denilen şey, tüm State’i temsil eden bir hash özetidir.
Bunun gibi tek bir hash ile bir şeyin tüm durumunu temsil edebilmek, Rollup’ların kullandığı Merkle Tree veri yapısının temel özelliklerinden biridir. Veriler, tıpkı bir ağacın yaprakları ve dalları gibi bağlantılıdır. İstenilen durumda tek bir hash özeti ile bütün bir ağacı temsil edilebilir kılınır.
Bu yöntemi kullanmanın diğer büyük avantajı, tüm State’i indirmek zorunda kalmadan; state parçası, birkaç Branch Node ve Merkle Root’a sahip olunduğu sürece Merkle Tree’de (Merkle Ağacı) bir state parçasının var olduğunun doğrulanabilmesidir.
Örneğin, Merkle Root’a sahip olunursa ve birisi Abdurrahman Amca’nın 3 Ether’e sahip olduğunu kanıtlamak isterse, kanıtlamaya çalışılan state parçasının yanı sıra aşağıdaki örnekteki gibi Branch Node’lar ile ispat etmesi gerekir. Leaf Node E’yi elde etmek için state parçasının hash’ini bulup, bunu F node’u ile birlikte tekrar hash özetini çıkardıktan sonra EF node’u elde edilebilir. Daha sonra EFGH’yi elde etmek için GH ile hash özeti çıkarılır ve Root’a ulaşana kadar böyle devam eder.
Eğer bulunan bu Root, sahip olunan Merkle Root ile eşleşirse Abdurrahman Amca’nın gerçektende 3 Ether’e sahip olduğu onaylanabilir. Abdurrahman Amca’nın 5 Ether’e sahip olduğuna dair yalan söylenmeye çalışırlarsa, hash’ler tamamen farklı olur ve farklı bir son hash elde edilir. Bunun gibi bir Merkle Tree veri yapısında bir state parçasının var olduğunu kanıtlayabilmeye Merkle Proof (Merkle Kanıtı) denir ve Rollup’ların kullandığı diğer önemli özelliktir.
Rollupların Çalışma Mekanizması
Rollup’ların çalışma mekanizmasına Layer 1 (Ethereum) açısından bakıldığında, Rollup’lar insanların fonlarını gönderebilecekleri akıllı bir sözleşmeden (Smart Contract) ibarettir. Smart Contract’taki fonların durumu Layer 1 'nın işleme sorumluluğunda değildir ve Layer 2 tarafından yönetilecektir. Layer 1'nın fonların durumunun ne olduğunu bilme şekli, Layer 2'dan ara sıra bir Merkle Root gönderilmesi durumuna bağlıdır.
Layer 2, tüm Merkle Tree’yi yöneten katmandır. Böylece kullanıcılar, State içerisinde herhangi bir değişiklik yapmak için doğrudan Layer 2 ile etkileşime girer. Peki Layer 2 çevrimiçi olmadığı durumlarda ne olur?
Layer 1'in yalnızca Merkle Root’u alması gerektiğinden, kullanıcılar bir Merkle Proof oluşturmak için Branch Node’lara ihtiyaç duyacaklarından, fonlarını kanıtlamalarına yetecek veri olmayacaktır. Sahip olduğu fonlarını kanıtlayamadıkları için fonlarının takılıp kalacağı ve Layer 2'nun tekrar çevrimiçi olmasını ummaları gerektiği anlamına gelir. Bu sorunu önlemek için, Layer 2 yeni bir Merkle Root gönderdiğinde, Merkle Tree’deki değişikliği yeniden oluşturmaya yeterli veriyi de göndermesi gerekir. Böylece kullanıcılar bu verilere bakarak tüm Merkle Tree’yi kendileri yeniden oluşturabilirler.
Layer 1 Node’larının bu verileri işlemesi veya Merkle Tree’yi kendilerinin yeniden oluşturması gerekmez. Ancak verileri indirmek isteyen kullanıcılar için verilerin mevcudiyetini sağlamak zorundadır (Data Availability).
Layer 1 Smart Contract’ı, örneğin iki gün gibi bir süre içinde yeni bir Merkle Root almamışsa, kullanıcıların doğrudan Layer 1 Smart Contract’ından para çekmek için Merkle Proof kullanabilecekleri bir tür acil durum işlevine sahiptir.
Olabilecek başka bir sorun da, Layer 2'nun kullanıcı Transaction’larını sansürlerken, acil para çekme işlevini kullanamamaları için zamanında Merkle Root göndermeye devam etmesidir.
Bu durumu önlemek için Layer 1 Smart Contract’ında, kullanıcının Layer 2'yu Transaction’ları bir sonraki State güncellemesine dahil etmeye zorlamasına izin veren başka bir acil durum işlevi vardır. Aksi takdirde State güncellemesi olmayacaktır.
Layer 2 yanlış davranırsa bu acil durum işlevleri, Rollup’tan Rollup’a değişebilir. Bu nedenle burada anlatılandan farklı olabilir. Bununla birlikte bütün güvenlik önlemleri kullanılıyor olsa bile, Layer 2 sahte bir State Root göndermeye çalışırsa ne olur?
Böyle bir durumu engellemek adına Layer 1'da kullanılmak için bir çeşit kanıt (Proof) gereklidir. Kanıtlar, Rollup’ları güvenilir kılan kilit kısımdır. Mevcut Rollup dizaynlarında kullanılan iki ana kanıt türü vardır. Fraud Proof (Dolandırıcılık kanıtları) ve Zero Knowledge Proof (Sıfır bilgi kanıtları).
Optimistic Rolluplar
İlk olarak ele alınacak Optimistic Rollup’larda, Rollup Node’ları Layer 1 Smart Contract’ına bir State Root gönderdiğinde, Fraud Proof’ları kullanan Optimistic Rollup Node’ları, Root ile birlikte küçük bir bond göndermeleri gerekir. Layer 1 Smart Contract’ı optimistik (iyimser) bir şekilde Optimistic Rollup’a güvenir ve yeni State Root’u günceller. Ancak bu güncelleme yedi gün boyunca kesin hale gelmez. Bu süre zarfında, bir başkası State Root’un hileli olduğunu kanıtladığı bir Fraud Proof oluşturabiliyorsa State geri alınır ve bunu bildiren kişi ödül olarak bond elde eder. Fraud Proof oluşturmaya çalışan dürüst bir kişi olduğu sürece herkesin parası güvende olur.
Verifier Dilemma Problemi
Fraud Proof yaratırken karşılaşılan bir problem ise Verifier Dilemma Problemi’dir. Bu problemi özetlemek gerekire;
- Ethereum Fraud Proof teşvikleri istendiği gibi çalışırsa, Optimistic Rollup Node’ları (Sequencer) hile yapmaz.
- Eğer kimse hile yapmıyorsa, o zaman birisinin Fraud Proof yapmasının bir anlamı yoktur çünkü Fraud Proof oluşturmaktan hiç para kazanmıyorsunuz.
- Hiç kimse bir Fraud Proof oluşturmazsa, sonunda Optimistic Rollup Sequencer’ının hile yapması için bir fırsat olur.
- Sequencer hile yapıyorsa, sistem artık istendiği gibi çalışmıyordur.
Verifier Dilemma problemi, Optimistic Rollup verilerinin ve State Root’unun doğruluğuna bakacak kişilerin teşviki ile ilgili bir problemdir.
Bununla birlikte, bir Fraud Proof oluşturmak için, imzaların geçerli olduğu da dahil olmak üzere State Root değişikliğinde gerçekleşen tüm Transaction’ların doğrulanması gerekir. Bu, Optimistic Rollup’ların State değişikliğine neden olan tüm Transaction’ları Layer 1'a da göndermesi gerektiği anlamına gelir.
Sıkıştırma tekniklerini kullanarak, işlemleri büyük ölçüde doğrulamak (Verify) için gereken veri miktarı azaltılabilinir. Ancak yine de State değişikliğine yol açan Transaction’ların gönderilme gereksinimleri her zaman fazla olacaktır.
Zero Knowledge Rolluplar
Diğer Rollup türü, Zero Knowledge Rollup’lardır. Zero Knowledge Proofları, bir kullanıcının görev hakkında herhangi bir bilgi vermek zorunda kalmadan bir görevi doğru bir şekilde tamamladığına dair bir Proof (Kanıt) oluşturabildiği nispeten yeni bir kriptografi biçimidir.
Bir Zk-Proof’un en iyi bilinen örneklerinden biri “Mağara Kapısı Analojisi”’dir. Tek girişi olan dairesel bir mağara ve mağaranın arkasında şifreyle açılması gereken bir kapının olduğu bir senaryoda; mağaranın bir ucundan girip diğer ucundan çıkan birisi kapının şifresini bildiğini herhangi bir bilgi vermeden kanıtlamış olur.
Her Zk-Proofu, bu analoji gibi bir etkileşimin olduğu bir tür senaryo oluşturmayı gerektiren, oldukça fazla işlem gücüne sahip bilgisayarlar aracılığı ile yaratılır. Dolayısıyla Zk Rollup’lar, Layer 2 Previous State’i (önceki durumu) doğru bir şekilde aldığına, bazı geçerli Transaction’ları işlediğine ve State değişikliklerinden sonra yeni bir State Root ürettiğine dair Zero Knowledge Proof üretecektir.
Zk-Rollup’lar, hileli herhangi bir şey yapmaya çalışıldığında, geçerli bir Zk Proof’u üretemezler. Bu nedenle Layer 1'daki Smart Contract, gönderilen yeni State Root’u kabul etmez.
Zk Rollup’lar, hiçbir Transaction’un sahtesini yapamayacakları için, Optimistic Rollup’lar gibi tüm Transaction ve Signature (imza) verilerini Layer 1'a göndermeleri gerekmediği anlamına gelir. Bu durum Zk-Rollup’ların, Proof oluşturdukları ispat şemasının özelliklerinden kaynaklıdır.
Kullanıcıların daha önce bahsedilen acil durum işlevleri (Emergency Function) için Merkle Proof oluşturmasına yetecek kadar veri gönderilse de, tüm Transaction ve Signature verilerinden daha az veri gönderilir. Zk-Rollup’ların en büyük avantajı, Proof doğrulandıktan sonra State güncellemelerini anında halletmesidir (Settlement). Bu nedenle Optimistic Rollup’lar gibi kesinlik/finality için yedi gün beklemeye gerek yoktur.
Bu nedenle birçok kişi, Zero Knowledge Proof üretmek için daha verimli yöntemler bulunduğunda Zk-Rollup’ların Ethereum ölçeklemesi adına gelecek olacağını düşünüyor. Şu anda verimli bir Zk-Proof ispat şeması oluşturmak hala zor olduğundan, daha genel ve verimli bir hesaplama için proof üretimi uzun zaman alabilir. Zk-Proof üretiminin zorluğundan dolayı Optimistic Rollup’lar bugün daha esnek ve kullanışlıdır. Önemli olan şey, kullanıcıların Merkle Proof’ları oluşturması için bir Proof ve Rollup’ların yeterli veri içeren bir State Root’u göndermeleridir.
Rollupların Dezavantajları
Rollup’ların avantajları olduğu kadar, dezavantajları da vardır. Rollup’lar teorik olarak Layer 1 kullanmak kadar güvenli gibi lanse edilse de, güvenlikleri büyük ölçüde nasıl tasarlandıklarına bağlıdır. Ethereum üzerinde çalışan farklı Rollup’ların risklerini değerlendiren L2beat adlı bir web sitesi vardır. TIKLA
Görüldüğü gibi, şu anda neredeyse tüm Rollup’ların en az bir potansiyel riski var. Bu nedenle günümüz Rollup’larında, Layer 1'a kıyasla yalnızca Rollup kullanmanın daha yüksek bir risk içerdiği gerçeği unutulmamalıdır.
İkinci olarak bir Rollup kullanıldığında, Transaction’ları sıralamak Rollup işlemini yapan Node’ların elindedir. Örneğin, bir DEX üzerinden bir şeyler satın alındığında Rollup Node’larını çalıştıran kişiler, işlemleri önden yürütme yeteneğine sahiptir. Farklı Rollup’ların farklı Sequancer (İşlemleri sıralayan Node’lar) mekanizmaları ile Ordering Transactions (işlemleri sıralama) yöntemleri olacaktır. İleride merkeziyetsiz Sequencer yapılarına geçileceği dile getirilse de günümüzde hemen hemen bütün Rollup’lar merkezi Sequencer mekanizmasına sahiptir.
Üçüncüsü, bir Rollup üzerindeki fonlar yalnızca kendi içindeki diğer fonlarla etkileşim kurabilir. Bu, ekosistemin bölüneceği anlamına gelir. Her Rollup temelde kendi ekosistemi gibi davranır.
Bazı insanlar bu problemi aşmak için zincirler arasında paylaşılan likidite ve köprü mekanizmaları üzerinde çalıştığından, gelecekte bu problem daha az sorun olacak gibi görünse de, her zaman yazılım hatası olasılığı vardır. Özellikle kod hataları bu tarz inşa edilen yapılarda daha sık gözlenmektedir.
Özetlemek gerekirse Rolluplar, insanların paralarını gönderdikleri bir Smart Contract’tır ve Smart Contract’taki tüm fonların durumu Merkle Root ile temsil edilir. Layer 1'ın fonları yönetmek için yapması gereken işlem, Proof’un geçerli olup olmadığını kontrol etmenin yanı sıra, Layer 2'den yeni bir Merkle Root aldığında State’i güncellemektir. Layer 2 ayrıca Layer 1'a Merkle Root ile birlikte State’i değiştiren Transaction’ları da gönderir. Ancak Layer 1'ın bu verileri işlemesine gerek yoktur. Nitekim bu veriler Layer 2 çevrimdışı ve acil durumlarda, kullanıcıların fonlarını kanıtlayabilmeleri için önemli veriler olduğundan, kullanıcılara verilerin mevcut olduğu ve gerektiğinde kullanabilecekleri bir ortam sunması gerekir (Data Availability). Rollup’ları güvenli hale getirebilecek teori bu olsa bile, şu anda bunları kullanırken oluşan riskler de vardır. Ancak doğru şekilde inşa edilirlerse, son derece kullanışlı bir araç olacakları ve herkes için daha ucuz işlemler sağlamak adına gelecekte kripto ekosisteminin büyük bir parçası olacakları açıktır.
Sovereign Rolluplar
‘Sovereign Rollup’lar, Layer 2 olmadıkları için benzersiz bir Rollup türüdür. Consensus ve Transaction işlemlerini diğer zincirlere yaptıran Layer 1 yapısına benzer. Kendi ekosistemleri ve kuralları vardır. Güvenliği başka bir zincirle paylaşsalar bile bağımsız ağ yapılarını/sovereignty korurlar. Diğer zincirlere dış kaynak sağlayarak, High Throughput (yüksek aktarım hızı/verim) elde etmelerini sağlar.
Normal Layer 1 zincirlerindeki en büyük sorun, ağın doğrulanması için bir Full Node çalıştırılması gerekmesidir. Smart Contract ağları gibi pek çok işlemi gerçekleştirmeyen Bitcoin benzeri zincirler için bu sorun olmaz ve birçok kişi kendi Node’larını çalıştırmayı karşılayabilir. Bununla birlikte, Solana gibi bir zinciri doğrulamak/validate istenirse, yalnızca birkaç kişinin karşılayabileceği mükemmel bir internet bağlantısıyla çalışan güçlü bilgisayarlara ihtiyacı gerekir. Böylece doğrulayıcıların/validatörlerin hatalı davranmayacağına güvenmek zorunda kalınır. Sovereign Rolluplar, Bitcoin’den bile daha hafif düğümler/Light Clients kullanarak Solana gibi bir zinciri doğrulayabilmeyi hedefliyor.
Bir blok zincirindeki tipik bir bloğa bakılırsa, Block Header(blok başlığı) ve Block Body(blok gövdesi) olarak bölündüğü görülür. Block Header, bir önceki bloğa referans, bloktaki işlemlerin Merkle Root’u ve genel olarak Consensus için kullanılan diğer validatörlerin yanı sıra State Root gibi birkaç önemli veri parçasını içerir. Block Body ise, bloktaki tüm Transaction’ların listendiği alandır.
Sovereign Rollup’ların amacı, Block Header’ı indiren Light Client’ların, tüm bloğu indiren (Block Header+Block Body) Full Node’lar kadar güvenli olabildiği bir zincir oluşturmaktır. Bu, insanların daha güçlü nodelar kullanmasını gerektirmeden bloktaki Transaction sayısını büyük ölçüde artırılabileceği anlamına gelir.
Öncelikle, yalnızca Light Client’ları olan normal bir blok zincirindeki sorunların ne olduğuna bakılırsa, ilk büyük sorun Light Client’ların aslında bloktaki tüm işlemlerin geçerli olup olmadığını bilmemeleridir. Normalde Full Node’lar her işlemi doğrular, işler ve Blok Header ile aynı Merkle Root’u alıp almadıklarını görmek için bunları bir araya getirir.
Bir blok üreticisi veya validatör grubu (Block Producer), yalnızca Light Client’ların çalıştığı bir zincirde kendilerine 100 Ether veren sahte/fake Transaction’lar oluşturabilir ve bu durumu Light Client’lar fark etmez.
Bu sorunu çözmek için Sovereign Rollup’lar, Optimistic ve Zero Knowledge Rollup’ların kullandığı aynı tür Fraud veya Validity Proof mekanizmasını kullanır. Bir blok üretildiğinde Block Producer ayrıca bloğun ve bloktaki tüm Transaction’ların geçerli olduğuna dair bir kanıt (Proof) sunmak zorundadır. Bu Proof, Block Header’ın bir parçası olabilir. Artık Light Client, Block Header’daki Merkle Root’un yalnızca geçerli/valid Transaction ’lardan yapıldığına ve Block Producer’ın bloğa sahte/fake Transaction’lar eklemediğine güvenebilir. Block Producer sahte Transaction’lar eklemeye çalışırsa, Block Header’daki Proof geçerli olmaz ve böylece Light Client bloğu reddedebilir.
Ancak bir sonraki sorun, Light Client’ların bloktaki işlemlerin Merkle Root’una sahip olmalarına rağmen, aslında işlemlerin ne olduğunu bilmemeleridir. Herkes Light Client çalıştırıyorsa, bloklardaki Transaction’ları bilenler yalnızca Block Producer’lardır. Block Producer’lar bu verileri paylaşmazsa, sahip olduğunuz tek şey kimsenin neye sahip olduğunu bilmediği ve dolayısıyla kimsenin bir şey yapamadığı geçerli/valid bir zincirdir.
Sovereign Rollup’ların sorunu çözmek için diğer zincirlere dış kaynak sağlamaya başladığı yer burasıdır. Celestia gibi zincirler tamamen Data Availability/veri mevcudiyeti konusuna yoğunlaşmışlardır. Bu zincirler, verilerin birçok Node arasında bölündüğü yöntemlere sahip olacağından Celestia gibi zincirlere veri göndermek çok ucuz işlemlerle gerçekleşecektir.
Ayrıca Celestia gibi zincirler, hiçbir verinin eksik olmadığını ve gerekirse yeniden oluşturulabileceğini doğrulamak için, verilerin küçük parçalarını örnekleyebileceğiniz (Sampling) yöntemlere de sahip olduklarından, Sovereign Rollup’lar bu zincirleri kendi avantajlarına kullanabilir ve Block Producer’larının tüm bloğu Celestia’ya göndermesini sağlayabilir.
Böylece Sovereign Rollup’ta herhangi bir veriye ihtiyaç duyan biri Celestia zincirini kontrol edebilir. Light Client’lar, Block Producer’ın verileri yayınladığını ve ihtiyacı olan herkes için mevcut olduğunu doğrulamak adına Celestia’dan birkaç parça veriyi örnekleyebilir (Data Availability Sampling). Veri mevcut değilse, bloğu geçersiz sayabilirler.
Blokları başka bir zincire göndermek aslında blok sıralama/sequencer problemini çözer. İyi bir güvenlik düzeyi isteniliyorsa, stake yapanların ödüllendirilmesi gereken yerlerde Consensus yöntemlerine sahip olmak pahalı olabilir. Zayıf bir Consensusa sahip olunursa, bir Blok Producer’ın Consensus ağırlığının %51'inden fazlasına sahip olduğu, zinciri yeniden düzenleyen ve potansiyel olarak Double Spend (Çifte Harcama) yapmak için geçerli Proof’lar ürettiği, hatta Data Availability’i kullanarak karşıt bir blok çatalı (Fork Chain) oluşturabildiği gibi durumlarla karşılaşılır. (Konu ile ilgili olarak daha detaylı okuma yapmak isteyenler şu yazıma TIKLA)
Sovereign Rollup’lar bloklarını başka bir zincire gönderdikleri için, blokların diğer zincirlerin Consensus yöntemiyle sıralanmış olacağı gerçeğinden yararlanırlar ve bu sıraya göre kendi çatal kurallarını (Fork Choise) oluşturabilirler. Bu durum Fork’un galibi olarak görünmek için, diğer zincirde sadece ilk bloğu dikkate almak kadar basittir. Sovereign Rollup’ların, kendi kurallarına karar verebilecek kendi Node’ları vardır. Bu nedenle zincirin saldırıya uğraması veya yanlış davranışlar olması durumunda güvenliği başka bir zincirle paylaşabilseler bile, Rollup Node’ları gerekirse farklı bir zincirin Consensus mekanizmasını kullanmak için çatallanabilir/Forklanabilir. Böyle bir esnekliğe sahip olduklarından güvenlik paylaşımı yaptıkları diğer zincire tamamen bağlı değillerdir. Hatta kendi Consensus yöntemlerini bile kurabilirler, ancak o zaman artık Rollup olmazlar. Başka bir zincirden Consensus ödünç alan Sovereign Rolluplar, Block Producer’larını tamamen lidersiz hale getirebilir ve herkesin blok göndermesine izin verebilirler. İnsanların bloklara spam göndermesini önlemek için bir tür Sybil koruma yöntemine ihtiyaç duyarlarsa, PoW veya PoS mekanizması kullanılabilir, ancak bu güvenlik açısından önemli olmaz.
Özet olarak, Sovereign Rollup ile herkes Blok Producer olabilir. Blok Producer’lar, gönderilen tüm Transaction’lara ayak uydurabilmek ve çok sayıda işlemle büyük bloklar oluşturabilmek için, muhtemelen güçlü makineler olacaktır. Bir Block Producer, blok oluşturduğunda, Block Header’ı tüm Light Client’lara gönderir. Ancak aynı zamanda, Light Client’ların kontrol edebilmesi ve Block Producer’ların sahte/Fake Transaction yapmadıklarını Light Client’ların da onaylayabilmeleri için Block Header’a bir Fraud veya Validity Proof eklemesi gerekir. Ayrıca, tüm bloğun Celestia gibi başka bir zincire gönderilmesi, Light Client’ların gerektiğinde verilerin küçük bir bölümünü örneklemesi için (Data Availability Sampling), verilerin mevcut olmasına (Data Availability) izin verir. Blokların gönderildiği zincir, blokları kendi Consensus mekanizmasını kullanarak sıralayacağı için, Sovereign Rollup herhangi bir anlaşmazlık olması durumunda bu sırayı kendi çatal/Fork kurallarında kullanabilir. Yazıda bunun mümkün olduğunu göstermek için Sovereign Rollupların yalnızca Light Client’lara sahip olarak tanımlansa da, aynı zamanda Block Producer gibi Full Node çalıştıran insanlar da olacaktır. Full Node’lar insanların her zaman Celestia’ya gitmek yerine, verilere erişmesini kolaylaştırır. Bu dizayn, ortalama bir kullanıcının düşük donanımlı Light Client’lar ile zincirin State’inin geçerli olduğunu doğrulamasına izin verirken, çok sayıda Transaction’u işleyebilen güçlü bir zincir yapısına kavuşturur. Yani yüksek düzeyde merkeziyetsizlik korunurken, yüksek Throughput (aktarım hızı) verimine sahip olmanın özellikleri, birçok projenin gelecekte Sovereign Rollup’ları kullanma olasılığının fazla olmasının nedenidir.
Validium/Volition
Normal Smart Contract Rollup’larında , Rollup’ların Layer 1'da meydana gelen tüm işlemlerle ilgili veri göndermesi gerekir. Kullanıcıların acil durumlarda paralarını çekmek ve Proof oluşturabilmeleri için, Transaction’ları Layer 1'a göndermek en güvenli seçenek iken, bu yol bazen çok pahalı olabilir. Bu sebeple Throughput (aktarım hızı) darboğaz/bottleneck haline gelir.
Verileri Layer 1'a göndermek yerine Validium’un seçenek olarak kullanılmasının gerektiği yer bu darboğazdır. Veriler off-chain bir veri komitesine yayınlanır /postalanır. Bu veri komiteleri (Data Availability Committee/DAC), verileri çok daha ucuz bir fiyata depolayacak ve kullanıma sunacağından, artık yalnızca Merkle Root’un Layer 1'a gönderilmesi yeterli olur.
Sadece Merkle Root’un Layer 1'a gönderilmesi, işlem maliyetini azalttığından, Validium potansiyel olarak düşük maliyetle daha fazla Throughput sağlayabilir. Ama bu durumda zincir dışı veri komitesi (Data Availability Committee) darboğaz/bottleneck olur. Komite, bu iş hacmine kavuşmak için, güvenliğin feda edildiği bir darboğaz/bottleneck’tir.
Volition ise, kullanıcıların Güvenlik/Throuhput tercih etmelerine veya o anki parasal durumlarına göre verilerin nereye gönderileceğini bir seçenek olarak sunan, Validium yapısının daha esnetilmiş halidir.
Buraya kadar okuyan herkese, Rollup’ların çalışma mekanizmasını, avantajlarını, dezavantajlarını ve çeşitlerini olabildiğince kısa tutarak ve bol görsel ile anlatmaya çalıştım. Bir dahaki yazıda görüşmek üzere.
Hoşça kalın…
