Geldim, Gördüm, EXECUTE Ettim!; ROLLUP

Hepinizin bildiği gibi Rollup kısaca, Ethereum ana ağının ölçeklenebilmesi için üretilen çözümlerdir ve bu çözümlere genel olarak “Layer 2" (ikinci katman) çözümleri diyoruz. Rollup konusuna daha önce yazdığım “The Blockchain” yazısında değinmiştim. Bu yazıda Rollupları iki bölüm halinde değerlendireceğiz. Birinci bölümde yapısı, işleyişi ve çeşitleri, ikinci bölümde ana ağ özelinde dizaynı ve problemleri olacak. İlk bölümü “The Blockchain” yazısından okuyanlar direkt ikinci bölüme geçebilir.

Birinci Bölüm; Rollup İşleyişi ve Çeşitleri

Rolluplar

Yapılacak işlemleri ana ağ dışında gerçekleştirerek sonuçları Layer 1(1. katman) blok zincire gönderip, ana ağda daha az işlem yapılmasını ve data alanı yaratılmasını hedefleyen çözümdür. Ana ağda daha az işlem gerçekleştirilmesi demek, dataları işlediğimiz blok boyutlarını büyütmeden, olabildiğince hızlı ve bu hıza paralel olarak daha fazla bloğu zincire ekleyebilmemiz demektir. Bunu anlamamız için Rollupların çalışma sistemine bakmamız gerekir. Ana zincirde, Rollup Layer’ın mevcut State’ini koruyan bir “Rollup Contract” vardır. Bu, üzerinde işlem yapan kullanıcıların hesap bakiyelerinin akıllı kontrat kodunu içerir. Özetle, Rollup Contract , Rollup Layer’daki işlemlerin “Stateroot”(durum kökü)’unu takip eder.

Rollup Layer’da işlemler gerçekleştiğinde, bir “State Transition”(durum geçişi)meydana gelir. Bu Stateroot’un da güncellenmesi gerektiği anlamına gelir. Ancak, her işlem için Stateroot güncellemek yerine, işlemler “Batch” dediğimiz toplu hale getirilmiş şekilde ana zincirdeki Rollup Contract’ına gönderilir. “Batch”, bu toplu işlemlerin sıkıştırılmış bir biçimini ve işlendikten sonraki verileri temsil eden güncellenmiş bir “Stateroot” içerecektir. Ana zincirdeki Rollup Contract, Batch’teki önceki Stateroot’un mevcut Stateroot ile eşleşip eşleşmediğini kontrol eder. Eğer eşleşiyorsa, “Stateroot” güncellenecektir.

İşlem verilerini ana zincire gönderdiğimiz ve zincirdeki işlemleri yürütmediğimiz için, ana zincirde yayınlanan işlem verilerinin ve Stateroot’un sahte olmadığını nasıl bilebiliriz? Bu soruya yanıt aramak için Rollupları işlem verilerinin ve Stateroot’un sahte olup olmamasını kanıtlama yöntemine göre ikiye ayırabiliriz.

• Optimistic Rollup

Optimistic Rolluplar adı üstünde “iyimser” yaklaşımlardır. Yapılan işlemlerin “transaction”ları (işlem verileri) ana ağa yayınlandığında doğru olduğu kabul edilir. Ana zincirdeki Rollup Contract’a yeni Stateroot’u ve işlem verilerini “Optimistic” olarak gönderiyoruz. Birisi tarafından ana zincire yeni bir Stateroot gönderildiğinde, Rollup Contract’ı bunu doğru kabul eder. Biri, Rollup Contract’ında geçersiz bir State Transition’ın yayınlandığını keşfederse, bir “Fraud Proof”(sahtekarlık kanıtı) oluşturabilir.

“Fraud Proof” şunları içerir:

• “Pre-state(ön durum) proof” veya bir işlem uygulanmadan önce işlerin nasıl göründüğü
• “Post-state(durum sonrası) proof” veya işlemin uygulanmasından sonra State’in nasıl görünmesi gerektiği
• Bir “State Transition” sırasında uygulanan Transaction’ların kanıtı

Bu Fraud Proof, ana zincirdeki Rollup Contract’a gönderilir. Rollup Contract daha sonra kanıtı doğrular ve işlem mantığını pre state’e uygular. Ardından, sonucu post-state ile karşılaştırır. Bir uyumsuzluk varsa, Batch’ı gönderen kişinin işlemleri doğru şekilde uygulamadığını kanıtlar. Rollup Contract daha sonra o Batch’i ve ondan sonraki tüm Batchleri geri alır.

Bu amaçla, ana zincire Batch gönderen herkesin bir depozito yatırması gerekir, böylece kötü niyetli davranırlarsa ve yakalanırlarsa “Slash”lenir, yani yatırdıkları depozitolar kesilir. Fraud Proof kanıtındaki doğrulama mekanizması, State üzerinden karşılaştırma şeklinde yapılan bir işlem olduğu için, Optimistic Rollup kullanan yapılardan varlıklarınızı çekmeniz uzun sürebilir. Fakat bu işlem girdilerini es geçmek için ekstra ücret ödeyerek bu işlem tamamlanabilir.

Zero Knowledge Rolluplar (Zk-Rollup)

İşlem verilerinin ve Stateroot’un sahte olup olmamasını kanıtlamasına göre Rollup’ları ikiye ayırabiliriz demiştik. Zk-Rollupların bu kanıtı neye göre yaptıklarını bilmemiz için kullandıkları teknolojiyi anlamız gerekir. Zk-Rolluplar her Batch’teki, Stateroot işlemi yürütmenin doğru sonuçta olduğunu kanıtlayan Zero Knowledge Proof (Sıfır Bilgi İspatı — Kısaca ZKP) adı verilen bir şifreleme kanıtı içerir. ZKP, Zk-Rollup katmanındaki işlemler yürütüldükten sonra blok zincirin durumunda oluşacak değişikliğin doğruluğunu temsil eden bir kanıttır. Validity Proof (geçerlilik kanıtı) dediğimiz bu kanıt, Zk-Rollup Kontratına nakledilir, böylece herkes bu kanıtı, Zk-Rollup katmanı üzerinde, belirli bir Batch’daki işlemleri doğrulamak için kullanabilir. ZKP’lar spesifik olarak ikiye ayrılır.

• Zk-Snark Kanıtları
• Zk-Stark Kanıtları

Şimdi ikisinin arasındaki temel farklara bakalım.

Zk-Snark ve Zk-Stark Kanıtları

Bu konuyu anlattığım başka bir yazıdan alıntı yapıyorum. ZKP, “Elimizdeki bir bilginin tamamını göstermeden, bilgiyi doğrulamak isteyenlere, bu bilginin yalnızca gereken kısmını göstererek bilgiye sahip olduğumuzu kanıtlamaya yarayan bir teknolojidir.” olarak tanımlayabiliriz. Bu cümleyi tekrar tekrar okuduğunuza yemin edebilirim ama kanıtlayamam, ama tırnak içindeki yazdığım cümlenin 2., 4., ve 8. kelimelerini al, bana bunları kelimelerde kullanılan harflere göre en uzun kelimeden en kısa kelimeye doğru sırala demiş olsaydım kanıt olur muydu? Eğer cümleyi okuduğunuzu, sizden istediğim şekilde kanıtlamak isteseydiniz şöyle bir sıralama sunacaktınız ; “isteyenlere” >”tamamını” >”bir” . Bunu yaparak, bana tırnak içindeki cümleyi okuduğunuzu kanıtlamış oldunuz hem de bütün cümleyi göstermeden. Burada anlattığım olayı blockchain ağlarına uygulayan teknolojiye ZKP (Zero Knowledge Proof) yani “Sıfır Bilgi Kanıtı” diyoruz. Zero Knowledge Proof teknolojileri kendi içerisinde kullandığı yöntemler itibariyle çeşitlilik gösterir. Yukarıda vermiş olduğum örnek cümledeki gibi, bize bu bilgilerden kısa ve öz bilgi kanıtları oluşturan (Prover) birileri var. Bu kanıtların doğruluğunu kontrol eden birileri de (Verifier) olmalı ki, bu bilgi kanıtları boşuna üretilmesin.Aynı zamanda bu kanıtlar öyle kanıtlar ki, doğruluğunu kontrol edenlerin sürekli soru sormasına gerek de yok, yani etkileşimsiz(non-interactive). ZK-SNARK kanıtı bunlardan biridir. ZkSNARK açılımı; Zero-Knowledge Succinct Non-interactive ARgument of Knowledge”’tir. Buradaki Zero-knowledge “Sıfır Bilgi” demek. SNARK’ı ise; “Kısa ve öz,(Succinct) etkileşimsiz(Non-interactive) bilgi kanıtları (Argument of knowledge)” olarak çevirebiliriz. Diğer bir kanıt türümüz olan Zk-STARK temelde yine bir SNARK. SNARK’tan farklı olmasının sebebi ise, kanıt üretirken kullandığı yöntemdir. Açılımı Zero-Knowledge Scalable Transparet ARgument of Knowledge (Ölçeklenebilir ve Şeffaf Bilgi Kanıtları)’dır.

Arasındaki farkları araştırmaya başlamanız, uçsuz bucaksız bir okyanusa açılmanıza sebep olacaktır.

ZKP kanıtları içerisine giren öğeler, soyut matematiğin(Polinomlar, vektörler, kısıtlama sistemi matrisleri vb.) alanına girdiği için, yaptığımız işlemler buradaki kontrol denklemleridir. Bu soyutlamaları kısa ve öz bir şekilde temsil etmemize izin veren üç büyük kriptografik teknoloji ailesi vardır:

• FRI tabanlı kriptografi Merkle Tree’lerden,
• Inner Product Argument(IPA):(İç Çarpım Kanıtları) Regular Elliptic Curves(Düzenli Eliptik Eğriler)’den,
• KZG Commitments tabanlı kriptografi ise Trusted Setup ile hesaplanan eşleştirmeli eliptik eğrilerden yararlanır.

Bu teknolojiler, üç tür kanıta yol açar: FRI, STARK’lara, KZG Commitments “Regular” SNARK’lara ve IPA tabanlı şemalar ise Bulletproof dediğimiz kanıtlara yol açar. Bulletproof kanıtları HALO projesinde kullanılan kanıt çeşitidir. Fakat burada konumuz Rolluplar özelinde olduğu için konu dışıdır. KZG Commitments tabanlı kriptografi kullanan SNARKların, Fast Reed-Solomon Interactive Proof of Proximity tabanlı kriptografi kullanan STARKlara karşı avantajları ve dezavantajları vardır. Bu avantajlara ve dezavantajlara hem kanıt üretici (prover) hem de doğrulayıcı (verifier) tarafından bakmak gerekir. Arasındaki farkları üç başlık altında inceleyebiliriz.

1. Ceremony gerektirme durumu
2. Computational Complexity (Hesapsal Karmaşıklık)
3. Programlanabilirlik

Ceremony gerektirme; Kanıtlayıcılar (Provers) ve Doğrulayıcılar (Verifiers) için Common Reference String(CRS)(Ortak Referans Dizisi) olarak adlandırdığımız, “güvenilir” bir tarafça önceden oluşturulan parametreler dizisi ile gerçekleşen durumdur. Çünkü CRS oluşturulurken girilen bilgilerin hemen yok edilmesi gerekir. Bu bilgilere “Toxic Waste” deriz. Aksi takdirde bu bilgiler kötü niyetli kişiler tarafından sahte kanıtlar oluşturulmak için kullanılabilir. Bir sistemin güvenliği büyük ölçüde CRS’in nasıl oluşturulduğuna bağlıdır. Bunu, gizliliği koruyan blok zinciri tabanlı sistemlerin ideallerinden ödün vermeden yapmak (güvenlik ve merkeziyetsizlik) çok önemlidir. CRS’in önemi ve birden fazla bağımsız tarafın sürece katkıda bulunma gereksinimi nedeniyle, katılım sürecine “Setup Ceremony”denir. “Trusted Setup” dediğimiz güvenli kurulum kavramı buradan gelmektedir. Şimdiye kadar, “Setup Ceremony” için tercih edilen teknik, Multi-Party Computation (MPC) olmuştur. “Setup Ceremony MPC Şemaları”, CRS’i yinelemeli olarak oluşturmak için rastgeleliğe katkıda bulunan, birden çok tarafı içeren, etkileşimli protokollerdir. Burada dikkatinizi çekmesi gereken nokta, katılımcıların güvenilir olması gerekliliğidir.SNARKlar bu yönüyle “Ceremony” gerektirdiği için “Trusted Setup” ihtiyacı doğar. STARKlar ise buna ihtiyaç duymazlar.

2. Computational Complexity; ürettiğimiz kanıtların, oluşturulma (prover) ve doğrulama (verifier) tarafındaki işlem sürelerinin, girdi boyutu fonksiyonu cinsinden ifade edilmesidir (NE!!??). Kanıt oluşturulurken emin olunması gereken iki konu vardır. Doğruluk ve Computational Complexity(Hesapsal Karmaşıklık). Doğruluk kısmını yukarıda anlatılan denklemler yardımı ile yapıyoruz. Computational Complexity’nin önemli olmasının sebebi ise: Girdi boyutu arttıkça, hesaplama süresindeki artışın, Verifier ve Prover açısından çıkaracağı zorluktur.

Yukarıdaki tabloda, girdi boyutu arttıkça, hesaplamanın zorluğunun constant(sabit) seviyesinden başlayıp, logaritmik olarak arttığı, girdinin boyutunun daha da yükselmesi halinde lineer olarak ilerlediği, oradan polinomyal düzeye eriştiği ve en sonunda exponential seviyeye ulaştığı belirtilmektedir. Bu ne demek? Örneğin hesaplayacağımız işlem datası “n” olsun, “k” ise verilerden kanıt oluşturmak için, verinin bir parçasını aldığımız sample(örnek) olsun. eğer k>1 kabul edersek, n^k polinomyal bir complexity(karmaşılık) iken, k^n ise exponential complexity seviyesindedir. Çünkü “n” dediğimiz girdi büyüdükçe lineer olarak hesaplama karmaşıklığı artar. Tabloda gösterilen büyük “O”, küçük “o” ve “Omega” ise Complexity büyüklüğüdür. SNARKların Verifier tarafından doğrulanma zamanı constant’tır. Toplam Data(n) arttığında sample yaptığımız miktarı arttırmamız gerekirse log(n) olarak artacaktır. Bu bize SNARKların işledikleri total veriyi belirli bir miktar üzerine çıkaramayacaklarını gösterir. Bunun sebebi ise kullandıkları kriptografik yöntemdir. STARKlar ise FRI tabanlı kriptografik hesaplama yaptığı için, işledikleri veriyi “n” doğrultusunda arttırabilir. STARKların “Verifier” tarafında doğrulama zamanları ise poly-logaritmik olarak artar. “Verifier Time” O(nlog(n)) değerinde olduğu için, Time Complexity oranı “Quasilinear” (Yarı lineer) boyutundadır. Hesaplama zamanını gösteren tablo aşağıdaki gibidir.

Bu durum, SNARK ve STARK arasında bir farka yol açar. KZG Commitments tabanlı kriptografi kullanan SNARKların doğrulama zamanı “Low Constant” iken, STARKların doğrulama zamanı Poly-logaritmiktir. Bu bilgiler ışığında aşağıdaki karşılaştırmalı tablodan ikisini karşılaştırabilirsiniz.

3. Programlanabilirlik durumu ise; Computational Complexity ve Ceremony durumuna bağlı olarak, ispatların oluşturulması belirli bir programa özgü olduğu için programı değiştirmek; baştan başlamak, eski parametreleri atmak ve yenilerini oluşturmak zorunda kalmamız demektir. Bu nedenle, SNARKların programlanabilirlik esnekliği STARKlara göre sınırlıdır.

Genel olarak Optimistic (Suç ispat edilene kadar herkes masumdur) ve Zk-Rollup (Kimseye güvenmek zorunda değilsin, sadece doğrula) yaklaşımı, ölçeklenme açısından hangisinin daha iyi olup olmadığı ile ilgili değildir. Kullanılışlılığı daha ön plandadır. Ethereum tarafı Optimistic Rollup yaklaşımını daha çok benimsemiştir. Çünkü uygulaması basittir. Fakat ZKP sisteminin de geleceğin teknolojisinin alt yapısı olduğu unutulmamalıdır. Ayrıca bir Zk-Rollup, “Validity Proof”(Geçerlilik Kanıtları) ürettiği için, StarkWare bunlara “Validity Rollup” da der.

Bir Zk-Rollup işlem kanıtını ana ağa gönderip, Batch içerisinde datayı göndermiyorsa buna Validium deriz. Validium yapısındaki Zk-Rolluplarda data dışarıda tutulur. Bu datanın güvenliği ise Zk-Rollup’ın komitesine kalmıştır. Batch’de sadece işlem kanıtları olup, data olmayacağı için daha ucuz olacaktır. Ancak “Data” ağ dışında olduğu için, ana ağ ile aynı güvenlik düzeyinde olmayacaktır. Bunun bir tercih meselesi haline gelmesi için Volition dediğimiz yapılar oluşturulmaktadır. Bu yapılarda kullanıcılar sadece kanıtı veya kanıt + datayı ağa göndermek arasında tercih yaparak, dilerlerse güvenli işlemler yapabilecektir. Yani Volition yapılarında data ağ dışındadır fakat istenildiğinde ana ağa gönderilebilir.

Rollup uygulamalarının temeldeki çalışma mantığını anlamazsanız, Rollup mükemmeldir diyen herkese inanmak zorunda kalırsınız. Çünkü anlatılırken terimler çok kullanılıyor. Rollup, temelde execution’un (işlemi yürütme) data ve consensustan ayrılarak bunun zincir üstü (on-chain) veya zincir dışı (off-chain) yürütülmesidir. Yukarıda da bahsettiğimiz gibi execution’un ana ağ dışında gerçekleşmesi, ana ağda daha az işlem gerçekleşeceği için, data kapasitemizin artması demektir. Çünkü işlemleri ağ dışında gerçekleştirip sonuçlarını ana ağa gönderiyoruz. Peki her şey teorideki gibi düzgün bir şekilde mi yürüyor?

İkinci Bölüm; Rollup Yapılarının Ana Ağdaki Dizaynı ve Problemleri

Bütün Layer 1 ağların, ölçeklenmesini ve güvenlik varsayımlarını etkileyen en önemli konu, Data ve Data’nın mevcudiyeti konusudur. Buna Data Available konusu denir. Datanın Layer 1 dediğimiz ana ağlarda veya ana ağ dışında tutulmasına göre güvenlik varsayımlarınız değişecektir. Örneğin, yukarıda bahsettiğimiz Validium yapılarında data off-chain tutulduğu için, ana ağ ile aynı güvenlik varsayımını paylaşmaz. Volition dediğimiz yapılar bu yüzden uygulanmaya çalışılmakta. Ama Volition yapılarında konu biraz tercih meselesi olduğu için, yine uygulamanın bütün datası ana ağ üzerinde olmayacak. Rolluplar, Ethereum ölçeklenme problemlerini çözmek için üretilen uygulamalar olsa bile, aslında Ethereum’dan bağımsız ağlardır. Ethereum’daki işlemleri on-chain veya off-chain kendileri Execute eden (işlemleri yürüten)uygulamalara Rollup denir. İşlem verilerinin(Transaction) ve Stateroot’un sahte olup olmadığının kanıtlama yöntemine göre, Rollupların ikiye ayırıldığını (Optimistic ve Zk Rollup) anladınız. Ethereum üzerindeki Rolluplar, standart halde olmadıkları için, bir takım problemlerle karşılaşılmakta. Ethereum programlanabilirlik üzerine kurulmuş bir akıllı kontrat platformudur. Eğer temelde olması gereken önemli kuralları “Kervan yolda düzülür” mantığı ile, her şeyi “yolda” yapmaya çalışırsanız, sonuç olarak hala işin başında kalırsınız. Ethereum, daha fazla TPS artışı sağlayacak bir “gas limit” artışından ziyade Rollup odaklı bir ölçeklenme yolu çizdi. Data büyümemesi için gas limit arttırmıyoruz deyip, Computation (hesaplama) yapan Rollup odaklı bir yaklaşımı benimsedikten sonra, Rolluplar ucuzlasın diye datayı ucuzlatmaya çalışmak da ayrı bir ironi olsa gerek. Ethereum’un şu anki durumuna baktığımızda, ölçeklenmenin yanında çözmesi gereken bir sorun da Data konusu. Zaten bunun çözülmesi gereken bir problem olduklarını gördükleri içindir ki, klasik shard planlarından vazgeçip Danksharding dizaynına yöneldiler. Rolluplardan gelen data ulaşılabilir olmalıdır. Yani bir Rollup’ın Full Node’undan gelen verinin tam,doğru ve eksiksiz bir şekilde Ethereum Nodelarında tutulduğuna emin olunması gerek. Erasure Code dediğimiz sistem, verilerin tamamını indirmemize gerek kalmadan, belirli parçalarını indirerek, bütün veriye ulaşmamazı sağlayan bir sistemdir. Bu sistem şu an Ethereum’da var mı? Cevap: Hayır. Yani Ethereum Nodeları Rolluplardan gelen verinin tamamını indiriyor. Peki bütün Rolluplarda bu durum aynı mı? Cevap: Hayır. Bu durum sadece Optimistic ve Zk-Rolluplar için geçerli. Zaten Rolluplar da bu ikisi değil miydi dediğinizi duyar gibiyim. “Data Rollup üzerinde kalsın, bize göndermesin, yeterince data yüküm var” denildiğinde bu yapılara Validium denilmiş. Data Availability konusu gündeme gelince “İsteyenlerin datası Ethereum’a alınır, problemi büyütmeye gerek yok.” dediklerinde de Validiumlar, Volition’a dönüşmüş oldu. Neticede olan ise şu; “Data ve Consensus bize ait, Execution’u Ethereum’dan bağımsız yapın” denildiğinde bu yapılar Rollup oldu. “Zk-Rolluplar, eskiden Plasma yapılarında olduğu gibi datayı off-chain tutsun, nasıl olsa Validity Proof ile datanın doğruluğunu ispatlamış oluyoruz, data yükünden kurtulalım” denildiğinde de Validium oldu. Genel çerçeveye baktığımızda “Bunların standart hale getirilmesi gerekir, bu durumda her biri için farklı güvenlik paradigması oluşmuş oldu ve Ethereum ağı ile aynı güvenlik düzeyinde değiller.” diye eleştiri geldiğinde cevap; “Bir şey deniyoruz, deneyerek öğreniyoruz, ölçekleneceğiz.” oluyor. Yani Rollup odaklı ölçeklenmenin yol haritasında kervan yolda düzülüyor. Fakat ölçeklenme konusu Ethereum’da sadece Rollup odaklı değil. Bunu aynı zamanda ana ağ üzerinde de yapmaya çalışıyorlar(Danksharding)

Ethereum’daki Optimistic ve Zk-Rolluplar datalarını, kendilerinin Full Nodeları (Sequencer) aracılığı ile Ethereum Nodelarına gönderir. Ethereum’da Erasure Code sistemi olmadığı için (şimdilik) bu dataların tamamı, bütün halinde Ethereum Nodelarında tutulur. Yani Ethereum, Rolluplar özelinde, Execute ederek TPS artışı sağlamış oldu. Data ölçeklenmesi ise hala problem. Bu ölçeklenememe, Rollupların kapasitesi önünde ise bir dar boğazdır. Fazla işlem verisi göndermek Ethereum’a TPS artışı getirmiş olacak, fakat Rollupların data kapasitesi, Ethereum’un data kapasitesi ile paralel ilerlediği için, vaadettikleri verimin önünde engel teşkil etmekte. Optimistic Rollup yapılarına baktığımızda, verilerin ve Stateroot ’un sahte olup olmadığını anlamamız için kullandığımız Fraud Proof sistemi önümüze “Verifier Dilemma” problemini getirir. Verifier Dilemma problemi, Optimistic Rollup verilerinin ve Stateroot’unun doğruluğuna bakacak Ethereum validatörlerinin(doğrulayıcı) teşviki ile ilgili bir problemdir. Bu problemi maddelersek;

1. Ethereum validatörlerinin Fraud Proof teşvikleri istendiği gibi çalışırsa, Optimistic Rollup Nodeları (Sequencer) hile yapmaz.
2. Eğer kimse hile yapmıyorsa, o zaman bir Ethereum Validatörünün (doğrulayıcı) Fraud Proof yapmasının bir anlamı yoktur çünkü Fraud Proof oluşturmaktan hiç para kazanmıyorsunuz.
3. Hiç kimse bir Fraud Proof oluşturmazsa, sonunda bir Optimistic Rollup sequencer’ının hile yapması için bir fırsat olur
4. Sequencer hile yapıyorsa, sistem artık istendiği gibi çalışmıyordur.

Bu paradoksu aşmanın çözümleri var. Mesela ikincil doğrulama gibi. Fakat Ethereum ana ağında böyle çözümler şimdilik yok. Bunu da yine Danksharding ile çözmeye çalışacaklar. Ayrıca Optimistic Rollup olarak transactionları ve staterootu Ethereumdaki sözleşmemize attıktan sonra Fraud Proof yayınlanırsa, State’i değişeceği için Optimistic Rollup Reorg yapmak zorunda kalır. Zk-Rollup tarafında ise Ethereum’a giden verilerin doğruluğu konusunda şüphe etmiyoruz, çünkü Zero Knowledge Proof teknolojisi sayesinde verilerin Validity Proofları oluşturuluyor. Zero Knowledge Prooflar aynı zamanda data taşımaz, datalar ile birlikte gelir. Verilerin doğru olduğunun kanıtlanması yeterli midir? Hayır değildir. Verilerin doğru olduğunu Validity Prooflar ile kanıtlamış olsak bile Ethereum ile aynı güvenlik düzeyinde değiliz henüz. Çünkü Execution hala Ethereum dışında. Ethereum ile aynı güvenlik düzeyinde olmak istiyorsanız, Governence kurmanız gerekir. Multisig’e sahip bir azınlık, Ethereum’un güvenlik varsayımlarının hiç olmasına neden olur. Rollupların token çıkartıp, token sahibi topluluk üzerinden bir Governence getirmesi, yine Ethereum’dan daha az güvenli bir yapı elde etmemize sebep olacaktır. PoS mekanizması ile çalışan bir Rollup Node’u veya Node grubu, stake edilmiş Rollup tokenlarının çoğunluğuna sahip ise, boş blok basarak sisteme DOS saldırısı yapabilir. Saldırı yapanların kendilerine maliyeti stake ettiği jetonlarının değerinin düşmesi olur. Ama İşlemleri gerçekleştirmek için yüksek ücret alırlar. “Token Withdraw” yapmak isteyen kullanıcıların para çekmesine izin vermek için yüksek bir “fee” keserler. Rollupta bulunan belirli tokenlerın arzını kilitleyerek, fiyatlarda dalgalanma yaratırlar ve bu dalgalanan fiyatlardan yararlanabilirler. Stake için kullanılan token üzerinde short açarlar ve kâr edebilirler. Bu durum Ethereum ana ağında olsaydı, bu tarz saldırılara karşı “Hardfork” yapabilecekken, Rolluplarda yapamıyoruz. Bir nevi RUGPULL dediğimiz olay gerçekleşmiş oluyor. Bunu dile getiren ben değilim, Zk-Rollupların mucidi “Barrywhitehat”. Ayrıntılı okuma için TIKLA.

Standartlaşma konusu Rollupların, Ethereum ana ağı ile aynı güvenlik düzeyinde olması için önemlidir. Standart ortaya konulmadan yapılan geliştirmelerden dolayı, Rollupların birbirleri ile uyumsuz yapıları, Execute Shard gibi Core yazılımlar ile dizayn edilmedikleri için güvenlik sorunu oluşturuyor ve bu konu şu an beta sürümlerinde oldukları için geçiştiriliyor. Rolluplar çok kompleks yapıda akıllı kontratlardır. Ethereum’daki akıllı kontratlar için Upgrade mekanizması yoktur. Ethereum’daki ikinci katman likiditesinin yüzde 90'ını oluşturan en büyük 4 proje anında Upgrade(yükseltilebilir) edilen kontratlar kullanıyor. Rolluplarda çıkan bir hatayı local veya remote exploit edenler olursa, fonları örneğin Bitcoine gönderip orada swap yaparlarsa bir daha bunu geri döndüremezsiniz. Bu sefer kodlara müdahale mekanizması konulduğunda, müdahele mekanizması Ethereum güvenliğinden düşük olacağı için Ethereumda olmak mantıksız olur. Belirli bir kompleksliğin üzerine çıkan ve büyüyen Rolluplar boş yere ölçeklenme tavizi verdikleri ve EVM limitlerine takıldıkları için kendi ağlarına geçmelidirler. Bu durumda ortaya çıkan sonuç şu oluyor; kodların belirli bir standartta olması gerekir. Bu standartları da ağın kendisinin koruması gerekir. Eğer hata varsa Ethereum bunu izlememeli. Rolluplar bu mantığı bozan en büyük örneklerdir.

Ethereum, yukarıda bahsetmiş olduğumuz konulara çözüm aramakta ve geliştirmekte. Danksharding ile önce data katmanı oluşturacaklar, daha sonra da bu katmanı shardlara bölecekler. Shardlardaki datanın tamamını tutacak validatörlere Builder diyorlar. Shard’ın datasını alıp Erasure Code sistemi ile oluşturacakları her ufak data parçası da “Chunk” olacak. Böylece Data Availability Sampling (verilerin mevcudiyetinin örneklenmesi) yapmak istediğimizde rastgele “Chunk” verisi isteyeceğiz. Bu Chunkların gerçekten o bloğun datalarından mı oluşuyor diye doğruluğunu kontrol etmek için, Chunk’ın Zk-Snark kanıtına bakacağız. Ya da birilerinin Chunkları toplayıp birleştirerek Zk-Snark kanıtı oluşturması gerekecek. Zk-Snark kanıtı oluşturacak proverlara da KZG committee diyorlar. Çünkü hatırlarsanız Zk-Snarklar KZG tabanlı kriptografi kullanan teknolojilerdi. İleride bu komitenin ismi FRI committee olursa şaşırmayın. Chunkların doğruluk kanıtlarını FRI tabanlı kriptografi kullanan Zk-Stark ile yapmak istediklerini düşündüklerine eminim ama kanıtlayamam. Ethereum her şeyi düşünüyor. Ama düşündükleri fikirlerden de çabuk vazgeçiyorlar. Mesela önceden “BIG BLOCK olmaz” derlerken, Danksharding ile blokları bayağı büyütmüş olacaklar. Builder denilen yapılar Shard datalarının tamamını tutacakları için, donanım seviyeleri normal nodelara göre çok yüksek olacaklardır. Bu yüksek donanımlı süper validatörlerin Zk-Snark kanıtlarını da yapacaklarını düşünüyorum. Çünkü Zk-Snark kanıtı yapmak belirli seviyede yüksek donanım gücü gerektiriyor. Hazır ellerinin altında varken, Builderları bu iş için kullanacaklardır. Zero Knowledge Proof teknolojisinde kanıtları kimin oluşturduğunun pek bir önemi yoktur. Bir kişinin oluşturması bile yeterlidir. Bu sayede Builderlar verileri sansürleyemezler. Ethereum ise Builder sayısı kadar merkeziyetsiz olacaktır. Çünkü herkes bu kadar yüksek donanımda validatör kuramaz. Aşırı sayıda Full Node kurarak, “Biz merkeziyetsizlikten taviz vermiyoruz.” söylemlerinin, Builder özelinde yıkılacak olması pek sorun değil. En azından BIG BLOCK+DAS yapabilecekler. Zero Knowledge Proof gibi hayatımızda bundan sonra her zaman olacak bir teknolojiyi, Ethereum ana ağında kullanmaları da güzel.

Zero Knowledge Proof teknolojisini kullanan Rollupların, Optimistic Rolluplar ile kıyaslanarak, “Ama Optimistic Rolluplar da harika” temalı sayfalarca yazı yazılması ayrı bir konu. Zero Knowledge Proofların muazzam teknolojiler olması, Optimistic Rollupları kötü yapmaz, fakat ikisi karşılaştırılamayacak derecede kavramlardır. Rolluplar işlemleri Batchlere sıkıştırıyor demiştik. Optimistic Rollupları; Finality, TPS, Liveness konusu üzerinden kıyaslayanlar, Zero Knowledge Proofların şu iki özelliğini görmezden geliyor demektir;

1.Kanıtlar birleştirilebilir; yani bir birleştirme kanıtı oluşturmak için iki kanıt birleştirilebilir.
2.Birleştirmeler ilişkiseldir; yani birleştirme kanıtları, birleştirme sırasından bağımsız olarak aynıdır.

Bu özelliklerinden dolayı bir Stark kanıtının içine bir milyon transfer sığdırılabilir olduklarını gördüğünüzde şaşırmayın. Bu özellikler, Zk-Rollupları Finality, TPS ve Liveness konusunda Optimistic Rolluplara karşı çok avantajlı hale getirebilir. Bu yine de Optimistic Rollupları kötü yapmaz, çünkü Optimistic Rolluplar, Ethereum’un ve Layer 2 uygulamalarının ideal yapıya geçmeden önce kullanılacak en optimal uygulamalardır, kurulumları da oldukça basittir. İkisini kıyaslamak yerine, bu şekilde işlevselleği anlattıldığında ikisinin farkının, daha anlaşılır olması sağlanır.

Peki Rolluplar için ideal yapı ne olacaktır? Yukarıda açıkça anlatılan nedenlerden ötürü Rolluplar ideal yapılar değildir. Ethereum’un yapacağı işlerin, Rolluplar tarafından yapılmaya çalışılması saçmalıktır. Ethereum Vakfı’nın öncülerinden olan Justin Drake’in dediği ve bizzat Vitalik Buterin tarafından da kabul edilen, “Ethereum’u yeniden dizayn etseydik SNARK dostu bir Virtual Machine geliştirip, Ethereum ana ağında bulunan bu Virtual Machine üzerine bir çok Enshrined Zk-Rollup uygulaması yapardım” söylemi bunu gösterir. (İnanmıyorsan TIKLA) Çünkü Rollup denilen uygulamalar, ana ağın üzerinde geliştirilmeli ve ana ağ ile birlikte değişebilmelidir. Baştan bir SNARK dostu Virtual Machine geliştirmek yerine, Enshrined Zk-Rollup dediğimiz Layer 1 üzerine gömülen yapıları, Ethereum Nodeları ile Sharddaki uygulamanın Zero Knowledge Prooflarını Execute ederek (doğrulayarak) yapabilirsiniz. Optimistic Rolluplar ile de yapılabilir. Sequencer işlemini Ethereum Validatörleri yapar. İşin sonunda Fraud Proof yapacağına ve Datalara Erasure Code uygulayacağına DAS yapmak için Execute etmek daha mantıklı. Zaten Enshrined Rollup meselesi teorik ve Ethereum’a gelip gelmeyeceği konusu bilinemez olduğundan, bahsi bile yersiz. Ethereum’un önünde, Enshrined Rollup yapılarından önce yapacağı yığınla işi var . En hızlı halletmeleri gereken konu başta The Merge ile PoW’den PoS’e geçiş meselesi. Daha sonra da Danksharding konusu geliyor. Ethereum’da Dankrad Feist gibi zeki bir adam olduğu için, işler bir tık daha hızlı halledilecek gibi duruyor. Her şeyi yapmaya çalışan Ethereum cephesinde işleri iyi toparladı. (Yine de çok ümitli değilim) Fakat Ethereum şu anki haliyle, uygulamalara yönelik yükseltilebilir mekanizmaları olan çoklu blockchain yapısında değil, Execution Rolluplarda, Data Shardı sorununu halletmiş değil, Rolluplar geldi oyun bitti (The Endgame) demek biraz abes oluyor.

Sonuç olarak, DAS yapılmaya çalışılacak, PoS yapılmaya çalışılıyor, Data Sharding yapmaya çalışılacak, Erasure Code sistemi getirilmeye çalışılacak, Batchlere BLS koymaya çalışılıyor, ana ağında DAS için Zk-Snark kullanmaya çalışılacak, Random Sampling için VRF sistemi koymaya çalışılacak vs vs vs. Yıllardır en idealini düşünüyorlar, sonuç; hala PoW’da. Ethereum’un bu yavaş ilerlemesinden, güvenlik varsayımı ile Rollupların uyuşmazlığından ve akıllı kontrat özelinde Rollupların yapılarından dolayı, Rolluplar bu ortama uygun değiller. Rolluplar için ideal olan Parachain olmaktır ya da Cevmos üzerine yerleşmektir. Evmos+Celestia, yeni olmasına rağmen Ethereum’dan hızlı gelişecek bana göre. Ethereum en iyi ihtimalle 2022 yazında PoS mekanizmasına geçecek gibi. Danksharding ve onunla birlikte gelecek özelliklere ne zaman geçeceklerini bilmiyorum. Ethereum bu hızda ilerleme kaydetmeye devam ederse belki de bu durumlar gerçekleşir. Buraya kadar okuduğunuz için teşekkür ederim. Bir dahaki yazımızda görüşmek üzere, şimdilik hoşça kalın…