ZK ve Optimistic Rolluplar Nedir?
Önceki yazımda ZKP ve SNARK’tan bahsetmiştim. Özellikle mahremiyet vurgusu yaptım ama ZK-Snark’lar veya Optimistic Rollup’lar sadece mahremiyeti değil ölçeklenebilirliği de sağlıyor.( Aslında çok daha fazlasını…)
Bildiğiniz gibi Bitcoin ve Ethereum ölçeklenemiyor, yani hem güvenlik hem merkeziyetsizlik hem de ölçeklenebilirlik aynı anda sağlanamıyor. Mesela Ethereum’da 32 ETH’ye sahip herkes node kurabiliyor, kurduğunda ise, merkeziyetsizlik sağlanıyor fakat bu sefer de “State bloat” sorunu ortaya çıkıyor, yani ağın boyutu yükseliyor. Bu sefer de işlemler çok pahalı oluyor.
Şu soru sorulabilir: Blokları büyütüp, işlemlerin hızlanmasını ve ucuzlanmasını sağlayamaz mıyız?
Hayır. Çünkü blokları büyütürsek bu sefer ağın boyutu inanılmaz derecelere yükselir, bir node kurmak için TB’larca veri indirmemiz ve node kuracağımız donanımın çok daha yüksek gereksinimlere sahip olması gerektiği anlamına gelir.
Örneğin, BSC’de sadece 21 tane validatör vardır ve donanım gereksinimler çok fazladır. İşlemler çok ucuz ve hızlı olur fakat bu sefer de merkeziyetsizlikten ödün vermiş oluyorlar.
Bu duruma “ The Scalability Trilemma” deniyor.
Rolluplar ise bu sorunu çözmek için tasarlanan teknolojilerdir. Şimdilik 2'ye ayrılıyorlar.
- Optimistic Rolluplar(ORU)
- ZK-Rolluplar(ZKR)
Her iki çözüm de işlemleri Ethereum dışında execute eder ve bu işlemlerin prooflarını Ethereum’a gönderir. Bu 2 Rollup türünün farkı burada başlar, farkı Ethereum’a nasıl proof gönderdiği ile alakalıdır. Bu proof tiplerine ise “Fraud Proof” ve “Validity proof” diyoruz.
Fraud Proof Nedir?
Optimistic Rolluplar’da sequencer denilen operator bulunur, Rollup üzerindeki işlemleri sıkıştırıp, sıralayıp batch haline getiriyor ve Ethereum’a yolluyor. Bunu yapmalarının sebebi ise ana chaine göre 10 - 100 kat daha verimli olması.
Peki Ethereum’a gönderilen bir verinin doğru olup olmadığını nasıl anlıyoruz?
İşte burada Fraud Prooflar devreye giriyor. yalnızca L1'e yollanılan işlemlere itiraz edilirken ihtiyaç duyuluyor. Yani ORU’lar L1'e her işlem doğruymuş gibi proof yollar, adı üstünde “Optimistic”dir. Validity Prooflarda böyle bir durum olmaz ona sonra geleceğim.
Batch yollandıktan sonra eğer yollanılan işlemlerde kötü niyetli merkle root ya da herhangi bir veri bulunursa Fraud Proof oluşturulur.
Peki bu Fraud Proofu kim oluşturuyor?
Burada nodelere az da olsa girmek durumundayım.
Nerdeyse çoğu blockchainlerde Full node ve Light nodeler bulunur.
Full node:
- Blockchaindeki gerekli olan tüm stateyi indirir.
- Bloktaki her şeyi indirir ve doğrular.
Light node:
- Blockchaindeki gerekli olan küçük bir stateyi indirir
- Sadece bloğun header kısmını indirir ve anormal bir durum olursa, full nodeler tarafından light nodelere, blok verilerinin geçerli olup olmadığını anlamak için gerekli veri sağlanır ve kontrol ederler.
Aslında bu yazıda DAS gibi konulara girmek istiyordum fakat pek uygun olmadığını anladım. Celestia veya benzeri projeleri yazdığımda detaylı olarak anlatacağım.
Dediğim gibi full nodeler chaindeki gerekli olan tüm stateyi indirir ve böylece blokları doğrulayabilirler. Örneğin Sequencer devre dışı kalırsa ne olur?
Öğrendiğiniz gibi zaten verilerimiz Ethereum’a gidiyordu, bu yüzden fonlarımız güvende olur çünkü DA chain Ethereum oluyor, Ethereum’a güveniyoruz. Hemen yeni bir sequencer yerleştirilip, tekrar chain devam edebilir.
Ayrıca unutmayın, Optimistic Rolluplar, ZK-Rolluplara göre bu konuda az da olsa daha avantajlıdır. Çünkü, kendiniz de rahatça node kurabilirsiniz. Bu nodeleri ZK-Rolluplar’da kurmanız için büyük çaplı donanımlar gerekir fakat yine de fazla dert olmadığını söylemek isterim.
Peki ya Sequencer kötü niyetliyse ne olur?
Bu durumda Rolluptaki bir node Fraud Proof oluşturur ve bu oluşturma aşamasında “tartışma dönemi” dediğimiz 14 günlük bir süreç başlar. Rollup bridgelerinde bu durumu görüyoruz. Sequencer’in işlemi geçersiz sayılır ve projeye göre gerekli slash uygulanır.
Optimistic Rolluplar, chainde sadece1 tane dürüst full node olmasıyla güvenli olurlar(1/N)
Peki chainde 1 tane bile full node olduğunu nasıl varsayabiliriz. Bildiğiniz gibi Optimistic Rolluplar milyonlarca usd yatırım almış projeler. VC’ler veya CEX’ler kesinlikle full node kuracaktır. Normal kullanıcılardan bahsetmiyorum bile.
Şunu unutmayın; Rolluplarda ne kadar da Fraud veya Validity Proof olursa olsun, 3'ncu parti bridgeleri(Hop, Orbiter vs.) kötü niyetli kişiler boşaltabilir. Bunun sebebi ise, Rollupların pre-confirmation olması, 3'ncu parti köprülerde herhangi bir Fraud veya Validity Proof mekanizması olmamasıdır. Güvenliğiniz bridge kadardır, o yüzden işlemleriniz anında gerçekleşir.
Yukarıdaki projelerden Arbitrum’un Fraud Proof mekanizmasını inceleyelim:
Interactive Proving
Önceki yazımda ZKP’den bahsetmiştim, o yazımda Interactive proofları anlatmıştım, yine de kısa bir kesimini burada paylaşıp. linkini bırakıyorum.
İki kişi hayal edelim, Alice’nin renk körü olduğunu, Bob’un ise olmadığını.
Bob, Alice’nin elinde özdeş ve renkleri farklı olan(Kırmızı ve yeşil) 2 adet topunun olduğunu kanıtlamaya çalışıyor.
Fakat Alice renk körü olduğu için topları aynı renkte görüyor ve bunların farklı renkte olduğuna inanmıyor.
- Alice(Verifier), her elinde birer tane olmak üzere iki topu alır ve arkasına koyar.
- Ardından toplardan birini Bob’a( Prover) gösterir. Tekrar arkasına koyar topu.
- Ardından, Bob’a rastgele başka bir top gösterir.
- Sonra Bob’a “topları değiştirdim mi?” diye sorar.
- İşlem gerektiği kadar tekrarlanabilir.
Bob renk körü olmadığı için topların değişip değişmediğini kesin olarak görür ve bunu renkleri söylemeden kanıtlar.
Alice’nin sakla+karıştır ve Bob’un tepkisinden oluşan bu döngüyü birkaç kez tekrarlayan Alice, sonunda Bob’un sırrını (topların rengini) bildiğine ikna olacaktır. Bunu ne kadar fazla tekrarlarsak, o kadar yüksek ihtimalle emin oluyoruz.
Bu örnek “sıfır bilgi”dir çünkü Alice hangi topun kırmızı hangisinin yeşil olduğunu asla öğrenemez.
Peki toplar aynı renkte olsaydı?
Eğer toplar aynı renkte olsaydı, Bob(prover) %50'den yüksek bir olasılıkla asla tahmin edemezdi. Ve bu işlemi defalarca tekrarlarsanız, başarılı olma olasılığınız sıfıra yaklaşırdı.
İşte Arbitrum’un kullandığı Fraud Proof mekanizması böyle çalışır, yanlış olan bir işlem ne kadar çok tekrarlanırsa, zaten her bir ihtimal %50'den daha fazla olamayacağı için.(N/2) yanlış olan işlemin doğrulanması o kadar kesinleşir.
Re-executing transactions
Diğer bir Fraud Proof mekanizması olan Re-executing, Arbitrum’un Interactive proving’e karşı karşılatırdığı bir çeşitidir.
Bu çeşitte L1 referans oluyor. Bir uyuşmazlığın doğru olup olmadığını anlamak için, Ethereum’da işlem Re-execute ediliyor ve kanıtlanmış oluyor.
Fakat bu işlem L1'de gerçekleştiği için Interactive Proving’e göre çok fazla maliyetlidir. Her batcha state durumu göndermeli ve gerçekten bir hata olduğunda Ethereum’da olan normal bir execute’ye göre daha pahalı bir Re-executing yapılır.
Peki Fraud Proof’un dezavantajları nelerdir?
- Validity Proof’a göre işlemlerin tam olarak doğrulanması için uzun süreler beklenmesi gerekir.
- L1 sansürü, yani ana ağın bir kısmının ele geçirilip, Rollup batchlerinin görmezden gelinmesi. Zaten ana ağın güvenliğini aldığımız için, böyle bir durumun olması felakete yol açardı. O yüzden tam olarak dezavantajı diyemeyiz.
- Verifier’s Dilemma
Nedir bu Verifier’s Dilemma?
Tekrardan başa dönelim. Verifier’den bahsetmiştik, o L2 nodeleri oluyordu(Farklı bir yazılım da olabilir, projeden projeye değişebilir). Bu sorun ise o nodelerin probleminden oluşuyor.
1. Nodelerin teşvikleri istendiği gibi çalışırsa, kimse ağa atak yapmaz.
2. Kimse atak yapmaya çalışmıyorsa, o zaman node kurmanın bir anlamı olmaz çünkü kimse atak yapmıyorsa ödül kazanamazsınız.
3. Hiç kimse node çalıştırmazsa, sequencerin fonları çalması için bir fırsat oluşur.
4. Sequencer fonları çalar ve Rollup artık istendiği gibi çalışmaz.
Bu sorun önemli gibi gözükse de, yazının bir kısmında VC’lerin ve CEX’lerin node kurduğundan bahsetmiştim. Örneğin; Binance ve Bybit node kurdu. Neden? Çünkü binlerce ETH’lerini Arbitrum’a neden emanet etsinler? Arbitrum’da her çeşit nodenin Fraud Proof atabildiğini unutmayalım.
Dediğim gibi topluluktan bahsetmiyorum bile, o yüzden bu durumun olması imkansıza yakın. Ayrıca bu durum sadece L2'ler için. Birçok proje Fraud Proof teknolojisi kullanıyor, her projenin farklı çözümleri olabilir.
Validity Proof Nedir?
ZK- Rollup’lar, Ethereum’a state durum değişikliğini matematiksel ve kriptografi kullanılarak, hesaplanmış şekilde L1'e Validity Proof yollar. Buradaki büyük olay, Ethereum’a gönderilen her işlem kesinlikle doğru olarak kabul edilir. E Fraud Proof da kabul ediyordu diye diyebilirsiniz. Buradaki farklılık, Fraud Prooflardaki gibi “tartışma dönemi” olmamasıdır. Yani Fraud Prooflar sadece yanlış işlem varsa oluşturuluyordu ama Validity Prooflar her batch için oluşturuluyor.
Yukarıda Optimistic Rollup’larda node kurmanın basitliğinden, ZK-Rollup’larda ise zorluğundan bahsetmiştim. Bunun sebebi işte budur. Her batch için Validity Proof atmak zorunda olduğunuz için, büyük makineler gerekir ve pahalıdır. Bu da Scalability’i etkiler.
Rollup’ların bir sıkıntısı ise “data availability problem” Ethereum’a batch yolladığımızda, her daha fazla batchde daha fazla veri ve pahalılık oluşur.
ZK-Rollup’larda proof ve veri yollanılır Etherem’a ve data Ethereum’da available olmuş olur. Ayrıca proofu Ethereum’a atmak şartıyla, veri off-chain veya başka bir on-chainde available olabilir.(Validium vb.)
Optimistic Rollup’larda on-chain olarak datanın available olması gerekir çünkü stateyi doğrulamak ve gerekirse bir Fraud Proof oluşturabilmemiz için Data’nın available olması gerekiyor.
Peki ZK-Rollup’larda Sequencer durursa & kötü niyetli olursa ne olur?
Burada 2 yöntem bulunuyor.
1.Sequencerin çevrimdışı olması halinde “Escape Hatch” denilen yöntem uygulanıyor. L2 Node kurup, L1'e Merkle Proofu’muzu gösterip, yaklaşık 1M Gas ödeyerek varlıklarımızı L1'e çekebiliyoruz.
2. Diğer bir yöntem ise Rollupta blok basmak. Buna “Proposing Block Exit” diyoruz. Zk-Rollup’larda proof üretmek zor ve pahalı olduğundan, ORU’larda bu işlemi yapmak daha kolay ama Escape Hatch ile de çıkabilidiğimiz için bu karşılaştırmanın pek de anlamı olmuyor.
Prover durusa ne olur?
Sequencer durduğunda aslında sistem yine devam ediyor, sadece çok yavaşlıyor.(Ethereum kadar, yaklaşık 15 TPS)
Prover durduğunda ise artık L1 ile bağlantı kesilmiş oluyor, ZK Proof yollanmıyor ama sistem yine de devam ediyor.
Örneğin; dYdX’de bir işlem açtınız ve liq olmaya yakın bir pozisyonunuz var ve işlemi takip etmektesiniz.
Sequencer durursa, liveness’iniz Ethereum kadar olur. İsterseniz exit yapabilirsiniz, isterseniz işlemlerinize devam edebilirsiniz.
Prover durursa artık Ethereum güvenliğinden bahsedemeyiz, artık exit yapmanın vakti gelmiştir demektir.
Bu durumda işlemimiz yine devam edecektir fakat en kısa zamanda çıkmanız gerekebilir çünkü varlıklarınız güvende değildir. Bu durumda Liveness’imiz zarar görüyor, çünkü belki işlemimiz Kâra geçecekti ve zorla exit yaptırılmış olduk.
Peki Prover kötü niyetliyse ne olur?
Bu durumda Rollup’ı forklamak gerekebiliyor. Buna “Mass Exit” diyoruz. Rollup forklandığında herkesin L1'e varlıklarını geçirebilmesi sağlanır. Bunun gerçekleştirilmesi için rollup proverinin kaynak kodları open-source olmalı yoksa sadece ekibe bağlı kalırız.
Liveness Nedir?
Bir blockchainin blok üretimine devam edebilme yeteneğidir. Yani zırt pırt blockchain durursa liveness düşük demektir, eğer sorunsuz bir şekilde durmadan devam ediyorsa chain, liveness yüksektir.
Buradan anladık ki, hem ORU’ların hem de ZKR’ların dataları her zaman available olmalıdır.
Önemli olan bir konu ise, ZKR’ların içerisindeki datalar gasdan tasarruf etmek için ORU’lardan farklı olarak tüm işlem ayrıntılarını yayınlamıyor sadece state farklarını(yani bir bloğun bir önceki bloğa göre farklarını) içeriyor olması.
ZKR’ların bu özelliği şimdilik ORU’lardan daha ucuz işlem yapmamızı sağlıyor. Güzel bir özellik gibi görünse de ufak dezavantajları var denilebilir.
ZK-Rollup’larda proofları oluşturan donanıma Prover denilir. Bu işlemin tamamını Prover görür ve gerekli proofu oluşturup, L1'e yollar.
Burada ORU savunucuları bu özelliğin, bazı önemli verileri gizlediğini iddia ediyor, ZKR’u savunanlar ise ucuz işlemler için ufak bir bedel olduğunu söylüyor.
EVM, zkVM ve zkEVM Nedir?
ZK tarafında bir süredir VM geliştirilmiyordu, L2'ler ASIC(Application-specific integrated circuit) olarak çalışıyor ve sadece Coin göndermeye veya swap yapmaya olanak sağlıyordu.(ZkSync 1.0, dYdX vs.)
Bu App’ler VM’siz çalışabiliyordu fakat L2'lerin aynı normal bir blockchain gibi olması gerekiyordu, çünkü Ethereum’un yükünü almak için, zaten L1'in sunduğu neredeyse her özelliği sunmanız gerekir.
Bu yüzden L2'lerde zkVM dönemi başladı. Bu VM çeşidi, EVM değildir ama EVM’yi anlayabiliyor.
Avantajları nelerdir?
- Basittirler, zkEVM gibi tüm EVM circuitlerini yazmaya gerek yoktur.
- Recursive VM’ler yapılabilir, StarkWare’nin L3 üzerine çalışması örnek gösterilebilir. Mesela L2'de bir işlem yaptığınızda nasıl L1'e o işlemin proofu gidiyorsa, L3'de de aynı işlem L2 için geçerli olur. Yani L2 Verifier görevi görür. Eth’ye proof gitmediği için işlemler çok çok ucuz olur.
EVM: Ethereum Virtual Machine. Execution katmanında bulunup, smart contractları yürütür.
- EVM-compatibility: Solidity/Vyper düzeyinde uyumluluk
- EVM-equivalence: EVM bytecode düzeyinde uyumluluk
- EVM specification-level compatibility: zkEVM olarak adlandırılan düzeydir.
Bildiğiniz gibi Ethereum’da Solidity bulunuyor, bu kodları EVM alıp, Opcode’ye dönüştürüp, sonrasında Bytecode haline getiriyor.
Bir EVM’ye zkEVM dememiz için Bytecode’yi tam olarak circuit yapması gerekli. Üstteki tabloda Starknet ve zksync sadece dil bazında uyumlu olurken Polygon Hermez ve Scroll bytecode seviyesinde uyumlu oluyor. Fakat zkEVM’ye en çok yaklaşan Scroll oluyor.
Neden?
Çünkü Scroll bytecodeleri circuit yaparken, Hermez Opcode’yi circuit yaptıktan sonra farklı bir bytecode algoritmasına compile ediyor.
Dediğim gibi bir VM’ye, zkEVM dememiz için bytecode’lerin hepsini circuit yapması gerekiyor.
Peki neden diğerleri de scroll gibi tam olarak eşdeğer olarak EVM’lerini tasarlamıyor?
EVM tasarlanırken, ileride zkEVM yapılması planlanmıyordu, bu yüzden ZK yapılarına çok uyumsuz.
- Normal bir VM’den farklı olarak EVM bazı özel opcodeler kullanır.
- EVM keccak256 şifrelemesi kullanır, zk yapılarıyla uyumsuzdur. ZkSync gibi bazı VM’ler keccak256'yı kaldırmaya çalışır. Ama bu da EVM eşdeğeri olmaz, yeni denetimler gerektirir.
Bunun gibi çok fazla sebep vardır, o yüzden zkEVM’ler tasarlamak zordur.
Developerler için zkEVM biçilmiş kaftandır, çünkü yeni bir dil öğrenmeye gerek yoktur. zkVM’lerde yeni dil gerekir fakat tüm kodları baştan yazmanız yine de gerekmez çünkü WARP gibi Solidity’den Cairo’ya çeviren dönüştürücüler bulunur fakat 100% bir çeviri olmayacaktır, eksik kısımlarının developer tarafından yazılması gerekiyor.
İşin sonunda zkEVM’nin ne kadar önemli olduğunu anladık, çoğu kişi bunun çok fazla önemli olmadığını, kullanıcı için bir şey değiştirmeyeceğini söylüyor. Buna katılmıyorum, daha iyisini yapmak varken neden yapmayalım? Kullanıcı en güvenli olduğunu bildiği yerde işlem yapmak isteyecektir. Ayrıca Scroll’un zkEVM’i ileride L1'lerde de kullanılabilir, çok büyük bir potansiyel. Bu yüzden Scroll gibi projeleri takip etmenizi öneririm.
Multi-Sig problemi
Rolluplar şu anda ne kadar da L1 güvenliğinde işlem yapma reklamı yapsa da bu beyaz bir yalandır. Bir Rollup, Fraud veya Validity Proof attığında onun güvenli olduğunu varsayamayız. Rollupların bir kısmı upgradabledir, yani istenildiği zaman forklanabilir.
Bunu engellemek için Rollup immutable(forklanamaz) olabilir, token ile de forklanabilir ya da forklanma talebi sonrası belirli bir delay koyulur fonların güvenle taşınabilmesi için, eğer delay yoksa fonlarınız artık Rollup ekibinin elinde demektir, isterlerse ağı forklayıp çalabilirler.
Mesela Aztec’de 1/2 multi-sig vardır. 2 walletten biri forklayabilir istediği zaman ve delay yoktur.
ZkSync ise 21 günlük delay koymuş fakat eğer 15 multi-sig sahibinden 9'u onay verirse anında fork gerçekleşir.
Güzel bir çözüm fakat mükemmel olduğunu söyleyemeyiz, ZkSync ekibi ve bu multi-sig sahipleri kötü niyetli bir anlaşma bile yapabilir, bunun olma olasılığı çok düşük olsa da mümkündür. Bu yüzden ZkSync, upgradable olmak yerine Immutable versiyona geçiş yapacaklarını söylüyorlar, yani forklanamaz versiyonuna. Bunun olabilmesi için her şeyin yerli yerine oturması gerekiyor, bu aylar veya yıllar sürebilecek bir şey.
https://twitter.com/VitalikButerin/status/1553342590786813952
Bu yazıyı hazırlarken bile ortaya yeni bir fikir çıkıyor, Vitalik Hybrid şekilde çalışan Rollup fikrini ortaya attı.
Kısaca sürekli Validity Proof atmak yerine, 24 saattlik süreçte bir “tartışma dönemi” olmazsa 24 saatte bir Validity Proof atmaya yarıyor.
Bir de Rolluplarda tek contract yoktur birden fazla contract vardır, mesela bir hacker 1 tane contractı patlattıysa, bu tüm Rollup’ı boşaltabileceği anlamına gelmeyebilir. Yine de bu savunulacak bir şey değildir.
Smart contract bile olmayan, sadece EIP güncellemesi ile forklanabilen Rolluplar da vardır bunlara “Enshrined Rollup” diyoruz. Şimdilik proje olarak görmedik ama ileride göreceğimizden eminim.
Artık genel olarak Rollupları biliyoruz sayılır, diğer yazılarımda da Rollup ekosisteminin ne kadar büyük ve etkileyici olduğunu daha fazla anlayacaksınız. Şimdilik benden bu kadar, okuyan herkese teşekkür ederim.
