ZK-EVM TÜRLERİ

Ethereum kurucusu Vitalik, blockchain sektörünün önde gelen beyinlerinin başını çeken isimlerden bir tanesi. İçerik üretmek konusunda da yazılım üretmekte olduğu kadar çalışkan ve özverili olan Vitalik Buterin, paylaştıklarıyla blockchain developer’ları için yeryüzündeki en güncel, en besleyici kaynakları oluşturuyor. Bu yüzden Coinoxs Medium sayfamızda Vitalik’in içeriklerini çevirisini yapıp, hazine niteliğindeki bu içerikleri Türkçeye kazandırıyoruz. “Vitalikten Makaleler” adlı serimizin ilk yazısı “ZK-EVM Türleri” karşısınızda. İyi okumalar dileriz.

Görüş ve önerileri için PSE, Polygon Hermez, Zksync, Scroll, Matter Labs ve Starkware ekiplerine özel teşekkürler. Vitalik BUTERİN

Son zamanlarda gösterişli duyurular yapan birçok “ZK-EVM” (Zero-Knowledge Ethereum Virtual Machine) projesi var. Polygon, ZK-EVM projesini açık kaynaklı hale getirdi, ZKSync, ZKSync 2.0 için planlarını yayınladı ve görece yeni bir proje olan Scroll yakın zamanda ZK-EVM’lerini duyurdu. Ayrıca Privacy and Scaling Explorations ekibi, Nicolas Liochon ve diğerlerinin ekibi, EVM’den Starkware’in ZK uyumlu dili CAIRO bir Alfa Compiler ve bahsetmediğim diğerleri de çalışmalarını sürdürüyor.

Tüm bu projelerin temel amacı aynı: Ethereum’dakine benzer işlemlerin yürütülmesinin kriptografik ispatlarını gerçekleştirmek için ZK-SNARK teknolojisini kullanmak, böylelikle Ethereum zincirinin kendisini doğrulamayı çok daha kolay hale getirmek aynı zamanda ölçeklenebilir ZK-rollup’lar oluşturmak. Ancak, pratiklik ile hız arasında seçim yapmaları dolayısıyla bu projeler arasında ince farklar var. Bu içerik, EVM benzeri “türlerinin” bir sınıflandırmasını ve her bir türe ulaşmaya çalışmanın faydaları ve maliyetlerinin neler olduğunu açıklamaya çalışacaktır.

Type 1 (Ethereum’a denk)

Type-1 ZK-EVM’ler, tamamen ve tavizsiz bir şekilde Ethereum eşdeğeri olmaya çalışır. Kanıt oluşturmayı kolaylaştırmak için Ethereum sisteminin herhangi bir bölümünü değiştirmezler. Ne kadar çevresel olursa olsun, hash’lerin , state trie’lerin, precompile’ların yerini değiştirmez aynı zamanda konsensüs mekanizmasının yerini almazlar.

Avantajları: Mükemmel uyumluluk

Amaç, Ethereum bloklarını bugün olduğu gibi doğrulayabilmektir veya en azından execution-layer side (yürütme layer’ı (katman) tarafını) doğrulamaktır (yani, işaret zinciri konsensüs mantığı dahil değildir, ancak tüm işlem yürütme ve akıllı sözleşme ve hesap mantığı dahildir) .

Type 1 ZK-EVM’ler, nihayetinde Ethereum Layer-1'in kendisini daha ölçeklenebilir hale getirmek için ihtiyacımız olan şeydir. Uzun vadede, Type 2 veya Type 3 ZK-EVM’lerde test edilen Ethereum’daki geliştirmeler, Ethereum’a uygun şekilde dahil edilebilir, ancak böyle bir yeniden mimari, kendi karmaşıklıklarıyla birlikte gelir.

Type 1 ZK-EVM’ler ayrıca roll-up için idealdir, çünkü roll-up’ın birçok altyapıyı yeniden kullanmasına izin verir. Örneğin, Ethereum yürütme istemcileri, roll-up bloklarını oluşturmak ve işlemek için olduğu gibi kullanılabilir (veya en azından, para çekme işlemleri gerçekleştirildikten sonra olabilirler ve bu işlevsellik, ETH’nin toplamaya yatırılmasını desteklemek için yeniden kullanılabilir), bu nedenle araçlar blok kaşifleri, blok üretimi vb. gibi yeniden kullanımı çok kolaydır.

Dezavantaj: Kanıtlama zamanı

Ethereum orijinal olarak ZK dostu olarak tasarlanmamıştır, bu nedenle Ethereum protokolünün ZK-kanıtı için büyük miktarda hesaplama gerektiren birçok kısmı vardır. Type 1, Ethereum’u tam olarak kopyalamayı amaçlar ve bu nedenle bu verimsizlikleri azaltmanın bir yolu yoktur. Şu anda, Ethereum bloklarının kanıtlarının üretilmesi saatler sürmektedir. Bu, kanıtlayıcıyı büyük ölçüde paralel hale getirmek için akıllı mühendislikle veya daha uzun vadede ZK-SNARK ASIC’lerle hafifletilebilir.

Kim inşa ediyor?

Gizlilik ve Ölçekleme Keşifleri ekibi ZK-EVM çalışması, Type 1 ZK-EVM inşa ediyor.

Type 2 (EVM’e denk)

Type 2 ZK-EVM’ler, tam olarak EVM eşdeğeri olmaya çalışır, ancak tam olarak Ethereum eşdeğeri değildir. Yani, “içeriden” tam olarak Ethereum’a benziyorlar, ancak dışarıda, özellikle blok yapısı ve state trie (durum ağacı) gibi veri yapılarında bazı farklılıkları var.

Amaç, mevcut uygulamalarla tam uyumlu olmak, ancak geliştirmeyi kolaylaştırmak ve kanıt oluşturmayı daha hızlı hale getirmek için Ethereum’da bazı küçük değişiklikler yapmaktır.

Avantaj: VM (Virtual Machine) düzeyinde mükemmel denklik

Type 2 ZK-EVM’ler, Ethereum durumu gibi şeyleri tutan veri yapılarında değişiklikler yapar. Neyse ki, bunlar EVM’nin doğrudan erişemediği yapılardır ve bu nedenle Ethereum üzerinde çalışan uygulamalar neredeyse her zaman bir Type 2 ZK-EVM roll-up’ta (akıllı sözleşmedeki işlemlerin toplamı) çalışır. Ethereum yürütme istemcilerini olduğu gibi kullanamazsınız, ancak bunları bazı değişikliklerle kullanabilirsiniz ve yine de EVM hata ayıklama araçlarını ve diğer birçok geliştirici altyapısını kullanabilirsiniz.

Az sayıda istisnası vardır. Geçmiş işlemler, makbuzlar veya durum hakkındaki iddiaları doğrulamak için Ethereum blokları kayıtları Merkle kanıtlarını doğrulayan uygulamalar için bir uyumsuzluk ortaya çıkar (örneğin, köprüler bazen bunu yapar). Keccak’ı farklı bir hash fonksiyonu ile değiştiren bir ZK-EVM bu ispatları bozar. Bununla birlikte, genellikle bu şekilde uygulama oluşturmamanızı tavsiye ederim, çünkü gelecekteki Ethereum değişiklikleri (örn. Verkle ağaçları) bu tür uygulamaları Ethereum’un kendisinde bile bozacaktır. Ethereum’un kendisinin geleceğe dönük geçmiş erişim ön derlemeleri eklemesi daha iyi bir alternatif olacaktır.

Dezavantaj: Geliştirilmiş ancak yine de yavaş kanıtlama süresi

Type 2 ZK-EVM’ler, esas olarak Ethereum yığınının gereksiz yere karmaşık ve ZK dostu olmayan şifrelemeye dayanan kısımlarını kaldırarak Type 1'den daha hızlı kanıtlama süreleri sağlar. Özellikle Ethereum’un Keccak ve RLP tabanlı Merkle Patricia ağacını ve belki de blok ve makbuz yapılarını değiştirebilirler. Type 2 ZK-EVM’ler bunun yerine farklı bir karma işlevi kullanabilir, örn. Poseidon. Diğer bir doğal değişiklik, durum ağacını kod hash ve keccak’ı depolamak için değiştirerek, EXTCODEHASH ve EXTCODECOPY işlem kodlarını işlemek için karmaları doğrulama ihtiyacını ortadan kaldırmaktır.

Bu değişiklikler prova sürelerini önemli ölçüde iyileştirir, ancak her sorunu çözmez. EVM’nin doğasında var olan tüm verimsizlikler ve ZK düşmanlığı ile EVM’yi olduğu gibi kanıtlama zorunluluğunun getirdiği yavaşlık hala devam etmektedir. Bunun basit bir örneği bellektir: Bir MLOAD, “hizalanmamış” parçalar (başlangıç ​​ve bitişin 32'nin katı olmadığı yerlerde) dahil olmak üzere herhangi bir 32 baytı okuyabildiğinden, bir MLOAD yalnızca bir parçayı okumak olarak yorumlanamaz; bunun yerine, sonucu birleştirmek için iki ardışık parçanın okunmasını ve bit işlemleri gerçekleştirmesini gerektirebilir.

Kim inşa ediyor?

Scroll’un ZK-EVM projesi, Polygon Hermez gibi Type 2 ZK-EVM’ye doğru ilerliyor. Bununla birlikte, hiçbir proje henüz tam olarak orada değil; özellikle, daha karmaşık ön derlemelerin çoğu henüz uygulanmadı. Bu nedenle, şu anda her iki proje de Type 3 olarak kabul edilir.

Type 2.5 (Gas maliyetleri hariç EVM’ye denk)

En kötü durum kanıtlama sürelerini önemli ölçüde iyileştirmenin bir yolu, EVM’deki ZK tarafından kanıtlanması çok zor olan belirli işlemlerin gas maliyetlerini büyük ölçüde artırmaktır. Bu, ön derlemeleri, KECCAK işlem kodunu ve muhtemelen belirli çağrı sözleşmeleri veya belleğe veya depolamaya erişim veya geri alma modellerini içerebilir.

Değişen gas maliyetleri, geliştirici araç uyumluluğunu azaltabilir ve birkaç uygulamayı bozabilir, ancak genellikle “daha derin” EVM değişikliklerinden daha az riskli olarak kabul edilir. Geliştiriciler, bir işlemde bir bloğa sığacak olandan daha fazla gas gerektirmemeye, asla sabit kodlanmış gas miktarlarıyla arama yapmamaya özen göstermelidir (bu, geliştiriciler için uzun süredir standart bir tavsiye olmuştur).

Kaynak kısıtlamalarını yönetmenin alternatif bir yolu, her bir işlemin çağrılabileceği sayıda katı sınırlar koymaktır. Bu, devrelerde uygulanması daha kolaydır, ancak EVM güvenlik varsayımlarıyla çok daha az iyi çalışır. Bu yaklaşımı Type 2.5 yerine Type 3 olarak adlandırırdım.

Type 3 (Neredeyse EVM eşdeğeri)

Type 3 ZK-EVM’ler neredeyse EVM eşdeğeridir, ancak test sürelerini daha da iyileştirmek ve EVM’yi geliştirmeyi kolaylaştırmak için tam eşdeğerlikten ödünler verir.

Avantaj: İnşası daha kolay ve daha hızlı test süreleri

Type 3 ZK-EVM’ler, bir ZK-EVM uygulamasında uygulanması son derece zor olan birkaç özelliği kaldırabilir. Ön derlemeler genellikle burada listenin en üstünde yer alır; Ek olarak, Type 3 ZK-EVM’ler bazen sözleşme kodunu, belleği veya yığını nasıl ele aldıkları konusunda da küçük farklılıklara sahiptir.

Dezavantaj: daha fazla uyumsuzluk

Type 3 ZK-EVM’nin amacı, çoğu uygulamayla uyumlu olmak ve geri kalanı için yalnızca minimum yeniden yazma gereksinimi sağlamaktır. Bununla birlikte, Type 3 ZK-EVM’nin kaldırdığı ön derlemeleri kullandıkları için veya VM’lerin farklı şekilde ele aldığı uç durumlardaki ince bağımlılıklar nedeniyle yeniden yazılması gereken bazı uygulamalar olacaktır.

Kim inşa ediyor?

Kaydırma ve Çokgen, mevcut formlarında Type 3'tür, ancak zamanla uyumluluğu geliştirmeleri beklenir. Polygon, zkASM adı verilen kendi dahili dillerini ZK-doğruladıkları ve zkASM uygulamasını kullanarak ZK-EVM kodunu yorumladıkları benzersiz bir tasarıma sahiptir. Bu uygulama detayına rağmen, buna yine de gerçek bir Type 3 ZK-EVM diyeceğim; yine de EVM kodunu doğrulayabilir, bunu yapmak için sadece bazı farklı dahili mantık kullanır.

Bugün hiçbir ZK-EVM takımı Type 3 olmak istemiyor; Type 3, karmaşık ön derleme ekleme işi bitene ve proje Type 2.5'e geçinceye kadar basit bir geçiş aşamasıdır. Ancak gelecekte Type 1 veya Type 2 ZK-EVM’ler, geliştiriciler için düşük kanıtlama süreleri ve gas maliyetleri ile işlevsellik sağlayan yeni ZK-SNARK dostu ön derlemeler ekleyerek gönüllü olarak Type 3 ZK-EVM’ler haline gelebilir.

Type 4 (High level programlama dilleriyle eşdeğer)

Type 4 sistemi, high level programlama dilleri ile yazılmış akıllı sözleşme kaynak kodunu (örn. Solidity, Vyper veya her ikisi de derlenen bazı ara ürünler) alarak ve bunu açıkça ZK-SNARK dostu olacak şekilde tasarlanmış bir dilde derleyerek çalışır.

Avantaj: Çok hızlı test süreleri

Her EVM yürütme adımının tüm farklı bölümlerini ZK ile kanıtlamayarak ve doğrudan high level programlama dilleriyle oluşturulmuş koddan başlayarak önleyebileceğiniz çok fazla ek yük vardır.

Bu yazıda bu avantajı sadece bir cümle ile açıklıyorum (uyumlulukla ilgili dezavantajlar için aşağıdaki büyük madde işareti listesine kıyasla), ancak bu bir değer yargısı olarak yorumlanmamalıdır! Yüksek seviyeli dillerden doğrudan derleme yapmak, maliyetleri büyük ölçüde azaltabilir ve profesyonel olmayı kolaylaştırarak ademi merkeziyetçiliğe yardımcı olabilir.

Dezavantaj: Daha fazla uyumsuzluk

Vyper veya Solidity ile yazılmış “normal” bir uygulama derlenebilir ve “sadece çalışır”, ancak birçok uygulamanın “normal” olmadığı bazı önemli yollar vardır:

CREATE2 sözleşme adresleri tam bayt koduna bağlı olduğundan, sözleşmeler Type 4 sisteminde EVM’de olduğu gibi aynı adreslere sahip olmayabilir. Bu, henüz dağıtılmamış “karşı-olgusal sözleşmelere”, ERC-4337 cüzdanlarına, EIP-2470 tektonlarına ve diğer birçok uygulamaya dayanan uygulamaları kırar.

El yazısı EVM bayt kodunun kullanımı daha zordur. Birçok uygulama, verimlilik için bazı kısımlarda el yazısı EVM bayt kodunu kullanır. Type 4 sistemler bunu desteklemeyebilir, ancak bu kullanım durumlarını karşılamak için tam bir Type 3 ZK-EVM olma çabasına girmeden sınırlı EVM bayt kodu desteğini uygulamanın yolları vardır.

Birçok hata ayıklama altyapısı taşınamaz, çünkü bu tür bir altyapı, EVM bayt kodu üzerinden çalışır. Bununla birlikte, bu dezavantaj, “geleneksel” üst düzey veya ara dillerden (örn. LLVM) hata ayıklama altyapısına daha fazla erişim ile hafifletilir.

Geliştiriciler bu konulara dikkat etmelidir.

Kim inşa ediyor?

ZKSync, bir Type 4 sistemidir, ancak zamanla EVM bayt kodu için uyumluluk sağlayabilir. Nethermind’in Warp projesi, Solidity’den Starkware’s Cairo’ya, StarkNet’i fiili bir Type 4 sistemine dönüştürecek bir derleyici inşa ediyor.

ZK-EVM türlerinin geleceği

Türler, diğer türlerden açıkça “daha iyi” veya “daha kötü” değildir. Daha ziyade farklı olarak ele alınması gereken özelliklere sahiplerdir: düşük numaralı türler mevcut altyapıyla daha uyumludur. Ancak daha yavaştır ve daha yüksek numaralı türler mevcut altyapıyla daha az uyumlu ancak daha hızlıdır. Genel olarak, tüm bu türlerin keşfedilmesi ekosistem için gereklidir.

Ek olarak, ZK-EVM projeleri kolaylıkla daha yüksek numaralı türlerden başlayabilir ve zaman içinde daha düşük numaralı türlere (veya tam tersi) atlayabilir. Örneğin:

Bir ZK-EVM, özellikle ZK tarafından kanıtlanması zor olan bazı özellikleri dahil etmemeye karar vererek Type 3 olarak başlayabilir. Daha sonra zamanla bu özellikleri ekleyip Type 2'ye geçebilirler.

Bir ZK-EVM, Type 2 olarak başlayabilir ve daha sonra tam Ethereum uyumluluk modunda veya daha hızlı kanıtlanabilen değiştirilmiş bir state trie ile çalışma imkanı sağlayarak hibrit bir Type 2 / Type 1 ZK-EVM haline gelebilir. Örneğin Scroll bu yöntemi kullanmayı planlıyor.

Type 4 sistem olarak başlayan sistem, daha sonra EVM kodunu işleme yeteneği ekleyerek zamanla Type 3 haline gelebilir (ancak geliştiricilerin ücretleri ve test sürelerini azaltmak için doğrudan yüksek seviyeli dillerden derleme yapmaları teşvik edilecektir)

Type 2 veya Type 3 ZK-EVM, Ethereum’un daha ZK dostu olma çabasıyla değişikliklerini benimsemesi durumunda Type 1 ZK-EVM olabilir.

Type 1 veya Type 2 ZK-EVM, kodu doğrulamak için çok ZK-SNARK dostu bir dilde bir ön derleme ekleyerek Type 3 ZK-EVM olabilir. Bu, geliştiricilere Ethereum uyumluluğu ve hız arasında seçim yapma imkânı sunar. Bu, Type 3 olacaktır, çünkü mükemmel EVM eşdeğerliği bozulacaktır. Ancak pratik açıdan, Type 1 ve 2'nin birçok avantajına sahip olacaktır. Ana dezavantajı, bazı geliştirici araçlarının ZK-EVM’nin geleneklerini anlamaması olabilir. Ön derlemeler, ancak bu düzeltilebilir: geliştirici araçları, ön derlemenin EVM koduna eşdeğer bir uygulamasını içeren bir yapılandırma biçimini destekleyerek evrensel ön derleme desteği ekleyebilir.

Şahsen umudum, ZK-EVM’lerdeki iyileştirmelerin ve Ethereum’un kendisinde daha ZK-SNARK dostu hale getirmek için yapılan iyileştirmelerin bir kombinasyonu yoluyla her şeyin zamanla Type 1 haline gelmesidir. Böyle bir gelecekte, hem ZK roll-up’ı için hem de Ethereum zincirinin kendisini doğrulamak için kullanılabileceği birden fazla ZK-EVM uygulamasına sahip olacağız. Teorik olarak, Ethereum’un Layer-1 kullanımı için tek bir ZK-EVM uygulamasında standardize etmesine gerek yoktur; farklı müşteriler farklı kanıtlar kullanabilir, bu nedenle kod fazlalığından yararlanmaya devam ediyoruz.

Ancak, böyle bir geleceğe ulaşmak oldukça fazla zaman alacaktır. Bu arada, Ethereum ve Ethereum tabanlı ZK roll-up’ını ölçeklendirmenin bir çok yeni yollarının bulunduğunu göreceğiz.

Makalenin orjinal: https://vitalik.eth.limo/general/2022/08/04/zkevm.html

TEŞEKKÜRLER VİTALİK …

Çevirmen: Mehmet Şakar

Editör: Serhan İnan Arabacıgil

Coinoxs Medium sayfasında yazar/çevirmen olmaya ne dersiniz? Blockchain literatürüne hakimseniz, teknik çeviri yapmak için yeterli bir İngilizce seviyesine sahipseniz bizimle iletişime geçin. Geleceğin teknolojilerine dair, nitelikli Türkçe kaynakları hep birlikte oluşturalım.