Orjinal Yazı: https://x.com/0xJaehaerys/status/1960051628129865918
Ethereum, lansmanından bu yana en büyük mimari dönüşümüne hazırlanıyor: EVM’nin (Ethereum Virtual Machine) yerine RISC-V getirilmesi.
Bunun sebebi basit: ZK (Zero-Knowledge) öncelikli bir gelecekte, EVM darboğaz haline geliyor.
Bugünkü zkEVM’ler bir yorumlayıcıya dayanıyor → 50–800 kat yavaşlatıyor,
“Precompile”lar (önceden derlenmiş sözleşmeler) protokolü karmaşıklık ve riskle şişirdi,
256-bit stack tasarımı, kanıt (proof) üretiminde son derece verimsiz.
RISC-V bu sorunları çözüyor:
Minimalist (~47 temel talimat) + olgun LLVM ekosistemi (Rust, C++, Go),
Şimdiden fiili zkVM standardı haline gelmiş durumda (10 projenin 9’u),
Resmî SAIL spesifikasyonu var (belirsiz Yellow Paper’a karşılık) → katı doğrulama sağlıyor,
Donanım tabanlı kanıt üretim yolları (ASIC’ler/FPGAlar) şimdiden test ediliyor (SP1, Nervos, Cartesi).
Geçiş 3 aşamada gerçekleşecek:
RISC-V’in precompile yerine geçmesi (düşük riskli testler),
Çift VM dönemi: EVM + RISC-V tam birlikte çalışabilirlikle.
EVM’nin RISC-V içinde yeniden uygulanması (Rosetta stratejisi).
Ekosisteme etkileri:
Optimistic rollup’lar bozuluyor (Arbitrum/Optimism sahtekârlık kanıtlarını yeniden inşa etmeli).
ZK rollup’lar büyük avantaj kazanıyor (Polygon, zkSync, Scroll → daha ucuz, daha hızlı, daha basit).
Geliştiriciler Rust/Go/Python kütüphanelerini doğrudan L1’de kullanabilecek.
Kullanıcılar ~100 kat daha ucuz kanıt alacak → “Gigagas L1” vizyonuna giden yol (~10k TPS).
Sonuçta Ethereum, bir “akıllı sözleşme VM”i olmaktan çıkıp, internet için minimal, doğrulanabilir bir güven katmanı haline evriliyor. Burada “bitiş çizgisi = her şeyi ZK-snark’lamak.”
TPS (Transactions Per Second): Saniyede işlem sayısı. Blockchain’in hız ölçütü.
EVM (Ethereum Virtual Machine): Ethereum’un akıllı sözleşmeleri çalıştıran sanal makinesi.
RISC-V: Açık kaynak bir işlemci talimat seti mimarisi. Basit, modüler, dünya çapında kullanılan bir standart.
ZK (Zero-Knowledge) / ZK-SNARK: Bir şeyin doğru olduğunu kanıtlamak için kullanılan kriptografik yöntem. Ayrıntıyı açıklamadan doğruluk kanıtı sağlar.
zkEVM: EVM’in Zero-Knowledge uyumlu versiyonu.
Precompile: Ethereum’da özel kriptografik fonksiyonların doğrudan zincire gömülü hali. Zamanla sisteme çok karmaşıklık ekledi.
Rosetta Strategy: EVM’nin RISC-V içinde çalıştırılması, böylece eski uygulamaların bozulmaması.
Rollup: Ethereum üzerinde ölçekleme teknolojisi.
Optimistic Rollup: İşlemleri geçerli varsayarak çalışır, gerekirse sahtekârlık kanıtıyla düzeltilir.
ZK Rollup: İşlemleri zincire koymadan önce ZK proof ile doğrular → daha güvenli ve hızlı.
LLVM: Modern derleyici altyapısı, Rust/C++ gibi dillerin farklı donanımlara çevrilmesini sağlar.
“Bitiş çizgisi… her şeyi ZK-snark’lamayı içeriyor.”
— Vitalik Buterin
ZK endgame (nihai hedef) kaçınılmazdır ve tez çok basittir: Ethereum, sıfır bilgi kanıtları (Zero-Knowledge proofs) üzerine tümüyle yeniden inşa ediliyor. Bu, şu an kullanılan protokolün teknik anlamdaki bitiş çizgisini temsil ediyor. Yani tüm sistemin mimarisini yeniden tasarlayıp inşa etmek.
Bu vizyonu bitiş çizgisi olarak kabul edersek, Ethereum şu anda lansmanından bu yana en önemli mimari evrimin eşiğinde duruyor. Tartışma artık küçük adımlarla yapılan yükseltmeler değil; hesaplama çekirdeğinin kökten yeniden inşası: Ethereum Sanal Makinesi’nin (EVM) değiştirilmesi.
Bu girişim, daha geniş kapsamlı “Lean Ethereum” vizyonunun bir köşe taşıdır. Bu vizyon, tüm protokolün sistematik olarak sadeleştirilmesini hedefler ve onu üç ana bileşene ayırır:
Lean Consensus (sade-hafif konsensüs),
Lean Data (sade-hafif veri),
Lean Execution (sade-hafif yürütme).
Lean Execution’ın kalbinde kritik bir soru vardır: Akıllı sözleşme devrimini mümkün kılan EVM, artık Ethereum’un geleceği için ana darboğaz mı haline geldi?
Ethereum Foundation’dan Justin Drake’in sözleriyle, uzun vadeli hedef her zaman “her şeyi Snark’lamak” olmuştur. Yani protokolün her katmanını geliştirmek için sıfır bilgi kanıtlarını (zk proofs) kullanmak. Uzun süre bu, biraz “uçuk bir hayal” olarak görülüyordu çünkü özellikle ihtiyaç duyulan şey gerçek zamanlı kanıtlama (real-time proving) fikriydi.
Artık gerçek zamanlı kanıtlamanın gerçeğe dönüşmesiyle birlikte, EVM’nin teorik verimsizlikleri pratik ve acil çözülmesi gereken bir sorun haline gelmiş durumda.
Bu analiz, Ethereum’un L1’ini RISC-V Talimat Seti Mimarisi’ne (ISA) taşımanın güçlü teknik ve stratejik gerekçelerini inceliyor. Bu hamle, görülmemiş bir ölçeklenebilirliği açmayı, protokolü basitleştirmeyi ve Ethereum’u doğrulanabilir hesaplama geleceği ile uyumlu hale getirmeyi vaat ediyor.
“Neden” sorusuna girmeden önce, “ne”nin değiştiğini anlamak önemli.
EVM, Ethereum üzerindeki akıllı sözleşmeler için çalışma ortamıdır. İşlemleri işler ve blockchain’in durumunu günceller. Yıllarca devrimci bir tasarıma sahip oldu; izinsiz (permissionless) bir platform yaratarak tüm DeFi (Decentralized Finance – Merkeziyetsiz Finans) ve NFT (Non-Fungible Token – Değiştirilemez Token) ekosistemlerinin doğmasına zemin hazırladı. Ancak, yaklaşık on yıllık bu özel (bespoke) mimari artık ciddi bir teknik borç (technical debt) taşıyor.
Öte yandan RISC-V bir şirket ürünü ya da özel bir yazılım değil; işlemci tasarımı için oluşturulmuş açık bir standarttır. Yani herkesin serbestçe erişebileceği, ücretsiz olarak kullanabileceği ve dünya çapında kabul gören evrensel bir “alfabe” gibidir. Nasıl ki alfabe, farklı dillerin üzerine inşa edilebileceği ortak bir temel sunuyorsa, RISC-V de farklı işlemci tasarımlarının üzerine inşa edilebileceği ortak bir temel sunar.
Jeremy Bruestle’nin Ethproofs oturumunda vurguladığı temel ilkeler (sadelik, modülerlik ve açık ekosistem) işte bu nedenle RISC-V’i Ethereum için benzersiz şekilde uygun hale getiriyor.
Minimalizm (Minimalism): Temel komut seti inanılmaz derecede basittir; yalnızca yaklaşık 40–47 komut içerir. Jeremy’nin sözleriyle: “neredeyse bizim süper minimalist genel amaçlı makine için ihtiyaç duyduğumuz kullanım senaryosuna kusursuz şekilde uygun.”
Modülarite (Modularity): Daha karmaşık işlevler, isteğe bağlı uzantılarla eklenir. Bu kritik bir özelliktir çünkü basit bir çekirdeğin, gerektiğinde genişletilebilmesine izin verir; temel protokole gereksiz karmaşıklık eklemeden.
Açık Ekosistem (Open Ecosystem): RISC-V, sadece kendi başına bir talimat seti (ISA) değil; aynı zamanda onu çevreleyen devasa ve olgun bir araç zinciri (toolchain) tarafından desteklenmektedir. Bunun en önemli örneği LLVM compiler toolchain (LLVM derleyici zinciri)’dir. LLVM, yüksek seviyeli programlama dillerini (Rust, C++, Go gibi yaygın kullanılan diller) alıp bunları farklı işlemci mimarilerine çevirebilen güçlü bir derleyici altyapısıdır. Yani bir geliştirici Rust veya Go dilinde yazdığı kodu, ekstra çaba harcamadan doğrudan RISC-V uyumlu hale getirebilir.
Ethereum bu ekosistemi benimseyerek, sıfırdan derleyici ve araç inşa etme zahmetinden kurtulmuş olur. Justin Drake’in sözleriyle: “Derleyiciler etrafında çok fazla araç var ve derleyici inşa etmek inanılmaz zor… Dolayısıyla bu derleyici ekosistemine sahip olmanın çok büyük bir değeri var.”
Başka bir deyişle, RISC-V sayesinde Ethereum, onlarca yıllık yazılım geliştirme birikimini ve milyonlarca geliştiricinin hâlihazırda kullandığı altyapıyı ücretsiz olarak miras alabiliyor.
Ethereum, RISC-V ile birlikte bu çalışmaların tümünden ücretsiz olarak yararlanabiliyor.
EVM’nin (Ethereum Virtual Machine – Ethereum Sanal Makinesi) değiştirilmesi zorunluluğu tek bir hatadan kaynaklanmıyor. Asıl sebep, ZK-native future (ZK-öncelikli gelecek) bağlamında görmezden gelinemez hale gelen temel sınırlamaların birleşimi. Bu sorunlar, sıfır bilgi kanıtı (Zero-Knowledge proofs) sistemlerinde ciddi performans darboğazlarından, protokolün içine işlemiş karmaşık ve riskli yapılara kadar uzanıyor.
Ethereum, L1 durumunu ZK-proof’larla (ZK kanıtlarıyla) doğrulayan bir modele geçtikçe, kanıtlayıcıların performansı (prover performance) en kritik darboğaz haline geliyor.
Vitalik Buterin’in sözleriyle:
“…Eğer zkVM’lerin (Zero-Knowledge Virtual Machines) uygulanma şekli, EVM yürütmesini (execution) alıp eninde sonunda RISC-V koduna dönüşen bir şeye derlemekse, neden akıllı sözleşme geliştiricilerine doğrudan alttaki RISC-V’i açmıyoruz ki? Böylece tüm o dış katmanı — yani fazladan bir sanal makine yorumlayıcısını — tamamen kaldırabiliriz.”
Bugünkü zkEVM’ler (Zero-Knowledge Ethereum Virtual Machines), EVM’nin çalışmasını doğrudan kanıtlamaz. Bunun yerine, EVM’yi taklit eden ayrı bir yorumlayıcı (interpreter) katman oluştururlar ve bu katman kanıtlanır. Ancak bu yorumlayıcı da zaten RISC-V koduna dönüştürülmüştür.
Yani aslında süreç şöyle işler:
EVM → Yorumlayıcı (Interpreter) → RISC-V
Bu da demek oluyor ki, akıllı sözleşmelerin doğrulanması için fazladan bir “ara halka” (yorumlayıcı katman) kullanılıyor. İşte bu gereksiz katman, sisteme ciddi bir aşırı yük (overhead) bindiriyor ve kanıt üretim sürecini büyük ölçüde yavaşlatıyor.
Bu fazladan yorumlama katmanı, muazzam bir performans kaybına yol açar. Tahminlere göre bu durum, doğrudan bir programı kanıtlamaya kıyasla 50–800 kat yavaşlamaya sebep oluyor. Hashing gibi diğer darboğazlar (ör. Keccak yerine Poseidon’a geçiş) optimize edildiğinde bile, blok yürütme (block execution) kısmı toplam kanıtlama süresinin %80–90’ını tüketmeye başlıyor.
Böylece EVM, L1 ölçeklenmesinin önündeki son ve en büyük engel haline geliyor. Vitalik’in hesaplamalarına göre bu katman kaldırıldığında, yürütme verimliliğinde potansiyel 100 kat artış sağlanabilir.
Burada kilit nokta şu: zkEVM’ler şu an EVM’yi doğrudan kanıtlamıyor; EVM’yi yorumlayan ayrı bir katmanı kanıtlıyorlar. Bu fazladan katman, Ethereum’un ZK tabanlı geleceğinde çok büyük bir yük haline geliyor.
EVM’nin belirli kriptografik işlemlerdeki zayıf performansını aşmak için, Ethereum protokolüne precompiled contracts (önceden derlenmiş sözleşmeler) eklendi. Bunlar, protokole doğrudan “gömülmüş” özel fonksiyonlardır. O dönem için pratik bir çözüm sağlasalar da bugün, Vitalik Buterin’in deyimiyle, oldukça “berbat” bir duruma yol açtılar:
“Precompile’lar bizim için berbat oldu… Ethereum’un güvenilir kod tabanını (trusted code base) aşırı şişirdiler… Konsensüs hataları açısından yaşadığımız en kötü ‘ucuz atlatma’ olaylarının bazılarına doğrudan sebep oldular.”
Buradaki temel sorun karmaşıklık (complexity). Vitalik, tek bir precompile örneği olan modexp’in (modüler üs alma işlemi) sarmalayıcı kodunu, tüm bir RISC-V yorumlayıcısıyla karşılaştırıyor. Ve ilginç biçimde, precompile’ın mantığının aslında çok daha karmaşık olduğunu gözlemliyor.
Yeni bir precompile eklemek için de oldukça yavaş ve politik açıdan sancılı bir süreç olan hard fork gerektiriyor. Bu da, özellikle yeni kriptografik yöntemlere ihtiyaç duyan uygulamaların inovasyon hızını kısıtlıyor.
Sonuçta Vitalik’in vardığı kesin hüküm şu:
“Bence bugünden itibaren yeni precompile eklenmesine dair bir moratoryum (tam durdurma) getirmeliyiz.”
EVM’nin (Ethereum Virtual Machine) çekirdek tasarımı, geçmişteki öncelikleri yansıtır; ancak günümüzün modern hesaplama ihtiyaçları için uygun değildir.
256-bit mimari (256-bit architecture): EVM, kriptografik değerleri işleyebilmek için 256-bit tabanlı olarak tasarlandı. Fakat akıllı sözleşme işlemlerinin büyük çoğunluğu aslında 32-bit veya 64-bit tam sayılar kullanır. Yani bu kadar geniş bir veri aralığı çoğu durumda gereksizdir. Bu verimsizlik özellikle ZK sistemlerinde (Zero-Knowledge systems) çok maliyetlidir. Vitalik’in açıklamasına göre:
“Küçük sayılar kullandığınızda, aslında tek tek sayı başına herhangi bir tasarruf elde etmiyorsunuz, ve karmaşıklık 2 ile 4 kat arasında şişiyor.”
Stack tabanlı mimari (Stack-based architecture): EVM, yığın tabanlı (stack-based) bir yapıya sahiptir. Buna karşılık modern CPU’lar ve RISC-V gibi ISA’lar register-based (kayıt tabanlı) bir modeli kullanır. Yığın tabanlı sistem, aynı işlemleri yapmak için daha fazla komut gerektirir ve derleyici optimizasyonlarını zorlaştırır. Bu da hem hız hem de verimlilik açısından ciddi bir dezavantaj yaratır.
Tüm bu faktörler — ZK kanıtlama darboğazı, precompile karmaşıklığı ve eski mimari tercihler — Ethereum’un EVM’nin ötesine evrilmesi gerektiğine dair güçlü ve acil bir gerekçe oluşturuyor.
Bu bölümde aslında EVM’nin neden “eskimiş” bir mimari olduğu çok net özetleniyor: yanlış yerde büyük sayı kullanımı, stack tabanlı tasarımın hantallığı ve ZK ortamında bu hataların çok daha maliyetli hale gelmesi.
RISC-V’in tercih edilmesinin sebebi yalnızca EVM’nin (Ethereum Virtual Machine) zayıflıkları değil; aynı zamanda RISC-V’in kendi tasarım felsefesinden kaynaklanan güçlü yanlarıdır. RISC-V, Ethereum gibi yüksek riskli bir ortam için mükemmel şekilde uygun, sağlam, basit ve doğrulanabilir bir temel sağlar.
Özel olarak tasarlanmış (bespoke), kapalı mimarilerin aksine RISC-V, köklü ve açık bir standarttır. Bu da Ethereum için üç kritik avantaj sağlar:
Yerleşik Ekosistem (Mature Ecosystem):
Ethereum, RISC-V’i benimseyerek bilgisayar bilimlerinde onlarca yıllık birikimi arkasına alır. Justin Drake’in açıkladığı gibi:
“LLVM (compiler toolchain), yüksek seviyeli dilleri farklı mimarilere derlemeyi sağlayan bir altyapıdır. Desteklenen mimarilerden biri RISC-V. Dolayısıyla RISC-V’i desteklediğinizde, LLVM’in desteklediği tüm üst seviye dilleri de otomatik olarak desteklemiş olursunuz.”
Bu, Rust, C++ ve Go gibi dillerde uzman milyonlarca geliştirici için Ethereum’a giriş bariyerini dramatik şekilde düşürür.
Tasarımda Sadelik (Simplicity by Design):
RISC-V’in minimalistliği bir eksiklik değil, bilinçli bir tercihtir. Yaklaşık 47 temel komut ile sanal makinenin çekirdeği inanılmaz derecede basit kalır. Bu sadelik, güvenlik açısından büyük bir avantajdır: daha küçük ve kompakt bir kod tabanı, denetlenmesi ve formel olarak doğrulanması (formal verification) çok daha kolay bir sistem anlamına gelir.
ZK Alanında Fiili Standardizasyon (De-Facto Standardization in the ZK Space):
zkVM (Zero-Knowledge Virtual Machine) ekosistemi aslında seçimini şimdiden yaptı. Justin Drake’in Ethproofs verilerinden aktardığına göre:
“RISC-V, zkVM backend’leri için önde gelen ISA’dır.”
Ethereum bloklarını kanıtlayabilen 10 farklı zkVM’den 9’u RISC-V’i hedef alıyor. Bu piyasa yakınsaması güçlü bir sinyaldir: Ethereum RISC-V’i benimseyerek spekülatif bir risk almıyor, zaten ZK geleceğini inşa eden projelerin tercih ettiği standarda uyum sağlıyor.
Bu bölümde önemli nokta şu: RISC-V yalnızca teknik olarak uygun değil, aynı zamanda ekosistemde şimdiden fiilen kabul edilmiş durumda. Ethereum’un bu standarda geçmesi “risk almak” değil, “uyum sağlamak” oluyor.
RISC-V’in gücü yalnızca ekosisteminde değil; iç mimarisi de güvenli ve doğrulanabilir sistemler inşa etmek için eşsiz biçimde uygundur.
Resmî, Makine-Tarafından Okunabilir Spesifikasyon (SAIL): RISC-V’in, SAIL adı verilen resmî bir tanımı vardır. Buradaki “makine tarafından okunabilir” ifadesi, bu tanımın yalnızca insanlar için yazılmış metin (prose) olmadığı; bilgisayarların ve matematiksel araçların doğrudan işleyebileceği kesin kurallı, formal bir dil kullanıldığı anlamına gelir.
Bu, EVM’nin spesifikasyonuna (Yellow Paper) kıyasla çok büyük bir gelişmedir. Çünkü Yellow Paper çoğunlukla doğal dilde yazılmıştır, yorumlamaya açıktır ve farklı geliştiriciler farklı şekilde anlayabilir. Buna karşılık SAIL spesifikasyonu, belirsizliğe yer bırakmaz; böylece matematiksel doğruluk kanıtlarını (formal proofs of correctness) mümkün kılar. Bu da milyarlarca dolarlık değeri güvence altına alan bir protokol için altın standarttır.
Ethereum Foundation’dan Alex Hicks’in Ethproofs çağrısında belirttiği gibi, bu sayede zkVM devreleri, doğrudan resmî RISC-V spesifikasyonu ile karşılaştırılarak doğrulanabilir.
Ayrıcalıklı Mimari (Privileged Architecture): RISC-V ayrıca genellikle göz ardı edilen ama güvenlik açısından kritik bir özellik içerir: farklı çalışma seviyeleri tanımlar. Bunların en önemlileri:
User Mode (Kullanıcı Modu): Güvenilmeyen uygulamalar (ör. akıllı sözleşmeler) için.
Supervisor Mode (Denetleyici Modu): Güvenilir “Yürütme Çekirdeği (Execution Kernel)” için.
Cartesi’den Diego’nun açıkladığı gibi:
“İşletim sisteminin kendisini diğer kodlardan koruması gerekir. Farklı programları birbirinden ayıran tüm bu mekanizmalar RISC-V standardının parçasıdır.”
Burada kilit nokta: EVM güvenliği büyük ölçüde yazılım bazlıdır, RISC-V ise donanım seviyesinde güvenlik ve doğrulama sunar.
Geçiş süreci, istikrarı ve geriye dönük uyumluluğu (backward compatibility) korumak için kademeli, çok aşamalı bir süreç olarak tasarlanıyor. Vitalik Buterin’in ortaya koyduğu bu yaklaşım devrimsel değil, evrimsel (evolutionary, not revolutionary) bir yol haritası.
İlk ve en temkinli adım, yeni sanal makineyi (VM) sınırlı kapasitede tanıtmaktır. Vitalik’in önerisiyle:
“Başlangıçta yeni VM’i sınırlı durumlarda kullanıyoruz. Mesela precompile’ların yerini almak için.”
Bu aşamada yeni EVM precompile’ları eklemek yerine, ihtiyaç duyulan fonksiyonlar beyaz listeye alınmış (whitelisted) RISC-V programları olarak uygulanır. Böylece yeni VM, mainnet üzerinde düşük riskli bir ortamda test edilmiş olur.
Sonraki aşamada yeni VM doğrudan kullanıcılara açılır. Geliştiriciler, sözleşmelerini (contracts) dağıtırken bytecode’un EVM mi yoksa RISC-V mi olduğunu belirten bir işaret (flag) ekleyebilir.
Buradaki en kritik özellik, sorunsuz etkileşim (seamless interoperability) sağlamaktır:
“İki tür sözleşme birbirini çağırabilir.”
Bu, ECALL (Environment Call) sistem çağrısı üzerinden, Ethereum istemcisinin (client) iki yürütme ortamı arasında aracı (mediator) olarak çalışmasıyla sağlanır.
Son aşamada hedef, en uç düzeyde protokol sadeleştirmesi (ultimate protocol simplification)’dir. Bu noktada:
“EVM’yi yeni VM’in içinde bir implementasyon haline getiriyoruz.”
Yani kanonik (resmî) EVM, RISC-V üzerinde çalışan, formel olarak doğrulanmış bir akıllı sözleşme haline gelir. Böylece:
Eski uygulamalar için kalıcı destek (perpetual support) sağlanır,
İstemci geliştiricileri artık yalnızca tek, minimal bir yürütme motorunu (execution engine) sürdürmek zorunda kalır.
Burada önemli nokta: Vitalik’in vizyonu EVM’yi bir anda ortadan kaldırmak yerine, adım adım RISC-V’nin içine gömmek. Sonunda EVM, RISC-V üzerinde çalışan bir sözleşmeye dönüşüyor ve sistem en sade haline ulaşıyor.
EVM’den (Ethereum Virtual Machine) RISC-V’e geçiş yalnızca çekirdek protokolü değil, tüm Ethereum ekosistemini derinden etkileyecek. Bu değişim, geliştirici deneyimini yeniden şekillendirecek, Layer-2 çözümleri arasındaki rekabet dengelerini kökten değiştirecek ve kanıt üretiminde (proof generation) yeni ekonomik modellerin önünü açacak.
Ethereum’un yürütme katmanının RISC-V’e geçmesi, rollup’ların iki ana türü için çok farklı sonuçlar doğuracak:
Optimistic Rollups (Arbitrum, Optimism):
Bu rollup’ların güvenlik modeli, fraud proofs (dolandırıcılık kanıtları) aracılığıyla çalışır. Yani şüpheli bir işlem olduğunda, anlaşmazlık L1 üzerinde yeniden yürütülerek çözülür. Ancak L1 EVM yerine RISC-V kullanmaya başladığında, bu model doğrudan bozulur.
Bu projeler önünde iki seçenek olacak:
Yepyeni bir fraud-proof sistemi tasarlamak (muazzam mühendislik çabası gerektirir),
Veya Ethereum’un güvenlik modelinden kısmen kopmak.
ZK Rollups (Polygon, zkSync, Scroll vb.):
Buna karşılık ZK rollup’lar için durum tam tersi: dev bir stratejik avantaj kazanıyorlar. Çünkü çoğu zaten dahili olarak RISC-V kullanıyor.
Ethereum L1 de aynı dili konuşmaya başladığında, entegrasyon çok daha sıkı ve verimli hale gelecek. Justin Drake’in ifadesiyle bu, “native rollups” çağını açabilir: Yani bir L2, aslında L1’in yürütme ortamının özelleştirilmiş bir versiyonu gibi çalışır, L1 VM ile kusursuz bir şekilde hesaplaşır.
Bu uyum şu sonuçları doğurur:
Teknoloji Yığını Basitleşir (Simplify the Tech Stack): L2 ekipleri artık içte kullandıkları RISC-V ile EVM arasında köprü kurmak zorunda kalmaz.
Araç ve Kod Yeniden Kullanımı (Tooling and Code Reuse): L1 RISC-V ortamı için geliştirilen derleyiciler, hata ayıklayıcılar ve formel doğrulama araçları L2’lerde de doğrudan kullanılabilir.
Ekonomik Teşviklerin Hizalanması (Align Economic Incentives): L1 gas ücretleri, RISC-V yürütmesini ZK ile kanıtlamanın gerçek maliyetini daha doğru yansıtır. Böylece daha rasyonel bir ekonomik model oluşur.
Özetle: Optimistic rollup’lar kırılma riskiyle karşı karşıya, ZK rollup’lar ise Ethereum’un yeni standardıyla tam uyum sağlayarak büyük kazanan olacak.
Ethereum üzerinde inşa edenler için bu geçiş, yıkıcı değil; daha çok evrimsel bir dönüşüm olacak.
En büyük fayda, çok daha geniş ve yerleşik yazılım geliştirme dünyasına erişimdir. Vitalik Buterin’in belirttiği gibi geliştiriciler artık akıllı sözleşmeleri Rust gibi ana akım dillerle yazabilecek ve bu diller Ethereum üzerinde Solidity/Vyper ile birlikte var olabilecek.
Vitalik aynı zamanda şunu da öngörüyor:
“Solidity ve Vyper akıllı sözleşme mantığı açısından zarif oldukları için uzun süre popüler kalmaya devam edecek.”
Ama Rust, Go veya Python gibi dillere ve onların devasa kütüphanelerine erişim, Ethereum üzerinde geliştirme deneyimini dönüştürecek. LLVM toolchain sayesinde, zincir üstü (on-chain) kod ile zincir dışı (off-chain) kodu aynı dilde yazmak mümkün hale gelecek. Vitalik’in benzetmesiyle bu, NodeJS deneyimine benzeyecek: yani hem sunucu tarafında hem de istemci tarafında aynı dili kullanmak gibi.
Kullanıcılar için en büyük kazanç, daha ucuz ve daha güçlü bir ağ olacak. ZK proving maliyetlerinde öngörülen yaklaşık 100 kat düşüş (işlem başına dolar seviyesinden, cent’in küçük bir kısmına kadar gerileme) doğrudan daha düşük ücretlere (fees) dönüşecek.
Hem L1 işlemlerinde hem de L2 hesaplaşmalarında bu ucuzluk, “Gigagas L1” vizyonunu (yaklaşık 10.000 TPS kapasite) mümkün hale getirecek. Bu da, zincir üzerinde çok daha karmaşık ve yüksek değerli uygulamaların doğmasını sağlayacak.
RISC-V’in teorik avantajları, halihazırda pratikte de kanıtlanmaya başlandı. Bunun en güçlü örneklerinden biri Succinct Labs ekibi. Onların çalışmaları, bu yeni mimari yaklaşımın tüm Ethereum için geçerliliğini gösteren güçlü bir vaka çalışması niteliğinde.
Succinct’in geliştirdiği SP1, RISC-V üzerine inşa edilmiş, yüksek performanslı ve açık kaynaklı bir zkVM’dir. SP1, yeni yaklaşımı doğrulayan şu felsefeyi benimsiyor:
EVM’nin kriptografik darboğazlarını aşmak için precompile merkezli bir yaklaşım yerine,
Yoğun hesaplama gerektiren işlemleri (ör. Keccak hashing) doğrudan optimize edilmiş ZK devrelerine (ZK circuits) aktarıyor.
Bu işlemler, RISC-V’in sağladığı ECALL talimatıyla çağrılıyor. Böylece donanım tabanlı hızın esnek yazılım modeliyle birleşmesi sağlanıyor.
Succinct’in etkisi yalnızca teknik değil, pratikte de gözle görülür durumda:
OP Succinct ürünü, SP1 kullanarak Optimistic Rollup’ları “ZK-ify” ediyor.
Bu sayede, normalde 7 gün süren kesinleşme ve para çekme (withdrawal) süreci, sadece 1 saate düşüyor.
Succinct’in kurucu ortağı Uma Roy’un ifadesiyle:
“OP Stack rollup’unuz artık finality için 7 gün beklemek zorunda değil… 1 saatlik finality elde ediliyor. Bu çok daha hızlı finality ve bu inanılmaz harika.”
Bu, tüm OP Stack ekosistemi için büyük bir sorun olan “uzun bekleme süreleri” problemini doğrudan çözüyor.
Ayrıca Succinct’in altyapısı, Succinct Prover Network adı verilen, kanıt üretimi için merkeziyetsiz bir pazar yeri olarak tasarlandı. Bu da, doğrulanabilir hesaplamanın geleceği için sürdürülebilir bir ekonomik model ortaya koyuyor.
Kısacası, Succinct’in çalışmaları sadece bir “teknik ispat” değil; bu makalede anlatılan geleceğin işleyen bir taslağı (working blueprint) durumunda.
RISC-V’in en büyük avantajlarından biri, yazılım ve donanım güvenliğinin “kutsal kasesi” sayılan formel doğrulama (formal verification) hedefini erişilebilir kılmasıdır.
Formel doğrulama, bir sistemin doğru çalıştığını matematiksel olarak kanıtlamak anlamına gelir.
EVM’nin zorluğu:
EVM, Yellow Paper adlı doğal dilde (prose) yazılmış belgelere dayanır.
Bu belgeler yorumlamaya açıktır, kesin değildir.
Bu yüzden EVM’yi matematiksel olarak tam doğrulamak son derece zordur.
RISC-V’in avantajı:
RISC-V’in resmî, bilgisayar tarafından işlenebilir (machine-readable) bir SAIL spesifikasyonu vardır.
Bu spesifikasyon, sistemin davranışını açık, tek anlamlı (unambiguous) bir şekilde tanımlar.
Böylece sistemin doğru çalıştığına dair matematiksel kanıt üretmek mümkün hale gelir.
Ethereum Foundation’dan Alex Hicks’in belirttiği gibi, şimdiden çalışmalar başladı:
zkVM RISC-V devreleri, resmî RISC-V spesifikasyonundan çıkarılan Lean biçimiyle karşılaştırılarak formel olarak doğrulanıyor.
Bu, Ethereum güvenliği açısından devasa bir adım:
Artık güven, hataya açık insan uygulamalarına değil, matematiksel olarak doğrulanmış kanıtlara kayıyor.
Tüm avantajlarına rağmen, RISC-V tabanlı bir L1 de beraberinde bazı zorlu ve ciddi riskler getiriyor.
Genel amaçlı bir ISA (Instruction Set Architecture – Talimat Seti Mimarisi) için deterministik ve adil bir gas modeli tasarlamak, en zor çözülmemiş problemlerden biridir.
Sadece “komut saymak” (instruction count) güvenli değildir. Çünkü saldırgan, önbelleği (cache) sürekli ıskalayan bir program yazarak düşük gas öderken çok yüksek kaynak kullanımına sebep olabilir.
Bu da potansiyel DoS (Denial-of-Service) saldırılarına yol açar.
Belki de en büyük ve en az fark edilen risk budur.
Güvenlik modeli, zincir üzerindeki VM’den (on-chain VM) zincir dışındaki derleyicilere (off-chain compilers) kayar.
Örneğin LLVM gibi derleyiciler her geliştirici tarafından kullanılır. Ancak bunlar son derece karmaşıktır ve bilinen hatalar (bugs) içerir.
Bir saldırgan, bu hatalardan faydalanarak zararsız görünen kaynak koddan aslında kötü niyetli bytecode üretebilir.
Ek bir sorun da tekrarlanabilir derlemeler (reproducible builds) meselesidir:
Zincirdeki derlenmiş binary’nin (çalıştırılabilir dosya) gerçekten herkese açık belirli bir kaynak koda ait olduğunu kanıtlamak çok zordur.
Çünkü derleme ortamındaki en küçük farklılık bile farklı binary çıktıları üretebilir.
Bu da şeffaflığı ve güvenilirliği tehdit eder.
Yani özetle:
Gas ölçüm modeli → bir bakıma saldırılara açık.
Derleyici güvenliği → Güven modeli, insan gözetimindeki zincir üstü VM’den, makineler tarafından üretilen zincir dışı derleyici çıktılarının doğruluğuna kayıyor. Yani yeni bir ‘makineler arası güven zinciri’ ortaya çıkıyor.
EVM döneminde güven zinciri: Güven, zincir üzerinde çalışan VM implementasyonuna dayanıyor. Yani insanlar tarafından yazılmış ve konsensüsle kabul edilmiş bir sanal makine koduna güveniyorsun.
RISC-V + LLVM gibi derleyiciler döneminde: Güven artık off-chain derleyicilere kayıyor. Yani zincir üstünde çalıştırılan şeyin güvenilirliğini, zincir dışındaki (off-chain) araç zincirine — derleyiciye, build ortamına — güvenmek zorunda kalıyorsun.
RISC-V’e geçişin beraberinde getirdiği riskleri azaltmak için çok katmanlı bir savunma yaklaşımı gerekiyor.
Geçişin kademeli, çok aşamalı planlanması aslında en temel risk azaltma stratejisidir.
İlk aşamada RISC-V yalnızca precompile replacement (precompile yerine geçiş) gibi düşük riskli alanlarda kullanılır.
Ardından dual-VM (çift VM) modeliyle hem EVM hem RISC-V birlikte çalışır.
Böylece topluluk, geri dönüşü olmayan büyük değişikliklerden önce, düşük riskli bir ortamda deneyim kazanır ve güven inşa eder.
Formel doğrulama nihai hedef olsa da, bunun sürekli ve saldırgan testlerle desteklenmesi gerekir.
Diligence Security’den Valentine’in Ethproofs çağrısında gösterdiği gibi, Argus fuzzer aracı şimdiden önde gelen zkVM’lerde 11 kritik hata (soundness & completeness bugs) tespit etti.
Bu durum şunu kanıtlıyor: en iyi tasarlanmış sistemlerde bile zayıflıklar olabilir; bunlar yalnızca yoğun testlerle ortaya çıkar.
Ekosistemin parçalanmasını (fragmentation) önlemek için topluluğun tek bir standart RISC-V profili üzerinde birleşmesi kritik önem taşıyor.
Muhtemel seçenek: RV64GC profili + Linux uyumlu ABI (Application Binary Interface)
Çünkü bu kombinasyon, Rust, C++, Go gibi yaygın diller ve araçlarla en geniş desteği sağlıyor.
Böylece yeni ekosistemden maksimum fayda elde ediliyor.
Ethereum Sanal Makinesi’ni (EVM) RISC-V ile değiştirme önerisi, ağın geleceği için kritik ve cesur bir vizyonu temsil ediyor. Bu yalnızca kademeli bir güncelleme değil; Ethereum’un yürütme katmanının kökten yeniden tasarımıdır.
Amaç:
Kökten gelen ölçeklenebilirlik darboğazlarını çözmek,
Protokolün karmaşıklığını basitleştirmek,
Platformu, genel amaçlı hesaplama dünyasıyla uyumlu hale getirmek.
Elbette yol, teknik ve sosyal açıdan dev zorluklarla dolu. Ancak uzun vadeli stratejik faydalar, bu iddialı girişimi haklı çıkaracak kadar güçlü.
Performans vs. Geriye Dönük Uyumluluk: ZK-native mimari büyük performans kazanımları getiriyor; ama eski uygulamaları koruma ihtiyacı süreci karmaşıklaştırıyor.
Basitlik vs. Ağ Etkisi: Daha sade bir protokol güvenlik açısından faydalı; ama EVM’nin getirdiği dev ağ etkisi (network effect) hâlâ çok güçlü.
Genel Amaçlı Ekosistem vs. Dış Araçlara Bağımlılık: RISC-V geniş bir ekosistem açıyor; ancak bu aynı zamanda karmaşık üçüncü taraf derleyicilere güveni de zorunlu kılıyor.
Bu mimari değişim, aslında daha geniş bir projenin ,“Lean Ethereum”, kalbinde yer alıyor.
Hedef: Ethereum L1’i (Layer-1), basit bir akıllı sözleşme platformundan çıkarmak,
Onu, yüksek verimli, güvenli bir settlement ve data availability layer (hesaplaşma ve veri erişim katmanı) haline getirmek.
Yani Ethereum, yalnızca kendi iç uygulamaları için değil, evrensel doğrulanabilir hesaplama (verifiable computation) için bir altyapı sunacak.
Vitalik Buterin’in ifadesiyle:
“Bitiş çizgisi… her şeyi ZK-snark’lamayı içeriyor.”
Bu vizyon, yalnızca Ethereum’u ölçeklemek değil; onu internetin temel güven katmanı (foundational trust layer) haline getirmektir.
Hashes (hash fonksiyonları) ve signatures (dijital imzalar)’dan sonra, üçüncü büyük kriptografik yapı taşı olarak SNARK’lar burada merkezi rol oynuyor.
Ethproofs: Geçiş yolunu tartışmak ve nesnel veriler toplamak için ortak bir forum.
Succinct Labs (SP1 zkVM): Anlatılan geleceğin yalnızca bir vizyon olmadığını, pratikte çalışan bir taslak (working blueprint) olduğunu kanıtlıyor.
Ethereum, RISC-V ile yalnızca kendi ölçeklenme sorunlarını çözmüyor. Aynı zamanda doğrulanabilir hesaplamanın geleceğini inşa ederek, internetin bir sonraki nesli için güvenin temel katmanı olmayı hedefliyor.
“Prove the world’s software.” (Dünyanın yazılımlarını kanıtla.)
Vitalik’in Açıklaması: https://www.youtube.com/watch?v=Iu7SJYMpOsE
ETHProofs Call #4: https://www.youtube.com/watch?v=rJiEV7jJFl4
Bu modelde bir akıllı sözleşme, User Mode içinde çalıştığı için blockchain’in durumuna doğrudan erişemez. Bunun yerine, ECALL (Environment Call) adlı özel bir talimat üzerinden Supervisor Mode’daki güvenilir çekirdeğe istekte bulunmak zorundadır. Bu da donanım tarafından zorlanan (hardware-enforced) bir güvenlik sınırı yaratır. Dolayısıyla yalnızca yazılım tabanlı sandboxing kullanan EVM’ye kıyasla çok daha sağlam ve doğrulanabilir bir güvenlik modelidir.
<100 subscribers
Share Dialog
theSahbaz.eth
Support dialog