Farklı ZK-EVM Türleri
2022 Aug 04
See all posts
Farklı ZK-EVM Türleri
PSE, Polygon Hermez, Zksync, Scroll, Matter Labs ve Starkware ekiplerine münazara ve inceleme, çeviri için eren'e özel teşekkürler.
Son zamanlarda birçok "ZK-EVM" projesinin çarpıcı duyurular yaptığı görüldü. Polygon ZK-EVM projesini açık kaynaklı hale getirdi, ZKSync, ZKSync 2.0 için planlarını yayınladı ve görece yeni bir oyuncu olan Scroll, ZK-EVM'lerini duyurdu. Ayrıca Privacy and Scaling Explorations ekibinin, Nicolas Liochon ve arkadaşlarının ekibinin, EVM'den Starkware'ın ZK-dostu dili Cairo'ya yönelik bir alfa derleyici ve kaçırdığım en az birkaç kişinin daha kesinlikle devam eden çabaları da var.
Tüm bu projelerin temel hedefi aynı: ZK-SNARK teknolojisini kullanarak Ethereum-benzeri işlemlerin kriptografik yürütülme kanıtlarını oluşturmak, bu kanıtları Ethereum zincirini doğrulamayı çok daha kolay hale getirmek veya Ethereum'un sunduğuna (neredeyse) eşdeğer ancak çok daha ölçeklenebilir olan ZK-rollup'lar inşa etmek için kullanmaktır. Ancak bu projeler arasında ince farklılıklar bulunmakta ve bunlar pratiklik ile hız arasındaki değiş tokuşları nasıl yaptıklarını belirlemektedir. Bu yazı, EVM denkliğinin farklı "tiplerinin" bir taksonomisini ve her bir tipe ulaşmaya çalışmanın fayda ve maliyetlerinin neler olduğunu açıklamaya çalışacaktır.
Genel Bakış (grafik biçiminde)
Tip 1 (tamamen Ethereum-dengi)
Tip 1 ZK-EVM'ler, tamamen ve ödün vermeden Ethereum-dengi olmaya çalışırlar. Kanıtları oluşturmayı kolaylaştırmak için Ethereum sisteminin herhangi bir parçasını değiştirmezler. Ne kadar çevresel olursa olsun hash'leri, state tree'leri, transaction tree'leri, ön-derlemeleri veya başka herhangi bir konsensüse dahil mantığı değiştirmezler.
Avantaj: mükemmel uyumluluk
Hedef, Ethereum bloklarını bugünkü haliyle doğrulayabilmektir - veya en azından yürütme-katmanı tarafını doğrulayabilmektir (bu nedenle, beacon zinciri konsensüs mantığı dahil değil, ancak tüm işlem yürütme ve akıllı kontrat ve hesap mantığı dahil).
Tip 1 ZK-EVM'ler, Ethereum katman 1'inin daha ölçeklenebilir hale gelmesini sağlamak için sonunda ihtiyacımız olan şeydir. Uzun vadede, Tip 2 veya Tip 3 ZK-EVM'lerde test edilmiş Ethereum'a yapılan modifikasyonlar, Ethereum'a uygun bir şekilde tanıtılabilir, ancak böyle bir yeniden tasarlama kendi komplekslikleri ile gelir.
Tip 1 ZK-EVM'ler aynı zamanda rollup'lar için idealdir, çünkü rollup'ların birçok altyapıyı tekrar kullanmalarına izin verirler. Örneğin, Ethereum execution istemcileri, rollup blokları oluşturmak ve işlemek için olduğu gibi kullanılabilir (veya en azından para çekme işlemleri implement edildiğinde ve bu işlevsellik, rollup'a ETH yatırılmasını desteklemek için tekrar kullanılabilir), bu nedenle blok gezginleri, blok üretimi vb. gibi araçlar çok kolay bir şekilde tekrar kullanılabilir.
Dezavantaj: kanıtlayıcı zamanı
Ethereum, başlangıçta ZK-dostu olacak şekilde tasarlanmamıştı, bu nedenle Ethereum protokolünün, ZK-kanıtlama için büyük miktarda hesaplama gerektiren birçok parçası var. Tip 1, Ethereum'u tam olarak kopyalamayı amaçlıyor, o yüzden bu verimsizlikleri hafifletebilecek bir yola sahip değil. Şu anda, Ethereum bloklarının kanıtlarının üretilmesi saatler sürüyor. Bu durum, kanıtlayıcıyı büyük ölçüde paralelleştirmeye yönelik zekice mühendislikle veya uzun vadede ZK-SNARK ASIC'ler ile hafifletilebilir.
Bunu kim inşa ediyor?
ZK-EVM Topluluk Sürümü (Privacy and Scaling Explorations, Scroll ekibi, Taiko ve diğerlerinin topluluk katkılarıyla başlatılan) Tier 1 bir ZK-EVM'dir.
Tip 2 (tamamen EVM-dengi)
Tip 2 ZK-EVM'ler tam anlamıyla EVM-dengi olmaya çalışır, ancak tam olarak Ethereum-dengi değildirler. Yani, "içeriden" bakıldığında tam olarak Ethereum gibi görünürler, ancak dışarıda bazı farklılıklar, özellikle blok yapısı ve state tree gibi veri yapılarında bulunur.
Hedef, mevcut uygulamalarla tamamen 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 seviyesinde mükemmel denklik
Tip 2 ZK-EVM'ler, Ethereum durumu gibi verileri tutan veri yapılarına değişiklikler yaparlar. Neyse ki, bunlar EVM'in doğrudan erişemeyeceği yapılar olduğundan, Ethereum üzerinde çalışan uygulamalar neredeyse her zaman Tip 2 ZK-EVM rollup'larında da çalışmaya devam eder. Ethereum execution istemcilerini olduğu gibi kullanamazsınız, ancak bazı değişikliklerle kullanabilirsiniz ve hala EVM hata ayıklama araçlarını ve çoğu diğer geliştirici altyapısını kullanabilirsiniz.
Az sayıda istisna vardır. Örneğin geçmiş işlemler, makbuzlar veya durum hakkındaki iddiaları doğrulamak için geçmiş Ethereum bloklarının Merkle kanıtlarını doğrulayan uygulamalarda bir uyumsuzluk ortaya çıkar (örn. köprüler bazen bunu yapar). Keccak'ı farklı bir hash fonksiyonuyla değiştiren bir ZK-EVM, bu kanıtları bozabilir. Bununla birlikte, zaten genellikle uygulamaların bu şekilde inşa edilmesini önermem, çünkü gelecek Ethereum değişiklikleri (örn. Verkle ağaçları) bu tür uygulamaları Ethereum'un kendisinin üzerinde bile bozacaktır. Daha iyi bir alternatif, Ethereum'un geleceğe-hazır geçmiş erişim ön-derlemelerini eklemesidir.
Dezavantaj: Gelişmiş ancak hala yavaş kanıtlayıcı süresi
Tip 2 ZK-EVM'ler, Ethereum yığınının gereksiz derecede karmaşık ve ZK dostu olmayan kriptografiye dayanan kısımlarını kaldırarak Tip 1'den daha hızlı kanıtlayıcı süreleri sağlar. Özellikle Ethereum'un Keccak'ını ve RLP tabanlı Merkle Patricia ağacını ve belki de blok ve makbuz yapılarını değiştirebilirler. Tip 2 ZK-EVM'ler, farklı bir hash fonksiyonu kullanabilirler, örneğin Poseidon. Başka bir doğal değişiklik, state tree'yi kod hash'ini ve keccak'ı depolayacak şekilde değiştirerek EXTCODEHASH ve EXTCODECOPY opcode'larını işlemek için hash doğrulama ihtiyacını ortadan kaldırmaktır.
Bu değişiklikler kanıtlayıcı sürelerini önemli ölçüde iyileştirir ancak her sorunu çözmez. EVM'i olduğu gibi kanıtlama zorunluluğundan kaynaklanan yavaşlık, EVM'in doğasında bulunan tüm verimsizlikler ve ZK dostu olmama durumuyla birlikte hala devam ediyor. Bunun basit bir örneği bellektir: Bir MLOAD, "hizalanmamış" parçalar (başlangıç ve bitişin 32'nin katı olmadığı) dahil olmak üzere herhangi bir 32 byte'ı okuyabildiğinden, bir MLOAD basitçe bir parçayı okuyormuş gibi yorumlanamaz; bunun yerine, sonucu birleştirmek için iki ardışık parçanın okunmasını ve bit işlemleri gerçekleştirilmesini gerektirebilir.
Bunu kim inşa ediyor?
Scroll'un ZK-EVM projesi, Polygon Hermez gibi Tip 2 ZK-EVM'e doğru ilerliyor. Bununla birlikte, her iki proje de henüz tam olarak oraya ulaşmadı; özellikle daha karmaşık ön-derlemelerin çoğu henüz implement edilmedi. Dolayısıyla şu anda her iki projenin de Tip 3. olarak değerlendirilmesi daha iyi.
Tip 2.5 (EVM-dengi, gaz ücretleri hariç)
En kötü durumda kanıt sürelerini önemli ölçüde iyileştirmenin bir yolu, EVM'deki ZK-kanıtlaması çok zor olan belirli işlemlerin gaz ücretlerini büyük ölçüde artırmaktır. Bu, ön-derlemeleri, KECCAK opcode'unu ve muhtemelen belirli kontrat çağırma kalıplarını veya belleğe/depolamaya erişmeyi veya geri döndürmeyi (revert) içerebilir.
Gaz ücretlerini değiştirmek, geliştirici araçlarının uyumluluğunu azaltabilir ve birkaç uygulamayı bozabilir, ancak genellikle "derin" EVM değişikliklerinden daha az riskli olarak kabul edilir. Geliştiriciler, bir işlemde bir bloğa sığmayacak kadar fazla gaz gerektirmemeye ve hard-coded gaz miktarlarıyla çağrılar yapmamaya dikkat etmelidir (bu zaten geliştiriciler için uzun süredir standart bir öneridir).
Kaynak sınırlamalarını yönetmenin alternatif bir yolu, her operasyonun kaç kez çağrılabileceği konusunda katı sınırlar belirlemektir. Bunun devrelerde uygulanması daha kolaydır, ancak EVM güvenlik varsayımlarıyla daha az uyumludur. Ben buna Tip 2.5 yerine Tip 3 yaklaşımı derim.
Tip 3 (neredeyse EVM-dengi)
Tip 3 ZK-EVM'ler neredeyse EVM-dengidir, ancak kanıt sürelerini daha da iyileştirmek ve EVM'i geliştirmeyi kolaylaştırmak için tam denklikten ödün verirler.
Avantaj: Daha kolay inşa edilir ve daha hızlı kanıtlayıcı süreleri sunar.
Tip 3 ZK-EVM'ler, ZK-EVM implementasyonunda uygulanması son derece zor olan birkaç özelliği kaldırabilir. Genellikle ön-derlemeler bu listede en üsttedir. Ek olarak, Tip 3 ZK-EVM'lerin bazen kontrat kodunu, belleği veya yığını nasıl ele aldıkları konusunda da küçük farklılıkları vardır.
Dezavantaj: Daha fazla uyumsuzluk.
Tip 3 ZK-EVM'in hedefi, çoğu uygulama ile uyumlu olup geri kalanları için sadece minimal yeniden yazım gerektirmektir. Bununla beraber, Tip 3 ZK-EVM'in kaldırdığı ön-derlemeleri kullanan veya VM'lerin farklı işlediği ince ayrıntılardaki bağımlılıklardan dolayı yeniden yazılması gereken bazı uygulamalar olacaktır.
Bunu kim inşa ediyor?
Scroll ve Polygon'un her ikisi de mevcut formlarıyla Tip 3'tür, ancak zamanla uyumluluğu artırmaları bekleniyor. Polygon, zkASM denen kendi dahili dilini ZK-doğruladıkları ve zkASM implementasyonunu kullanarak ZK-EVM kodunu yorumladıkları benzersiz bir tasarıma sahiptir. Bu implementasyon detayına rağmen yine de buna hakiki Tip 3 ZK-EVM diyeceğim; çünkü hala EVM kodunu doğrulayabiliyor, sadece bunu yapmak için yalnızca farklı bir dahili mantık kullanır.
Bugün, hiçbir ZK-EVM ekibi Tip 3 olmak istemez; Tip 3, ön-derlemelerin eklenmesi gibi karmaşık işler bitene ve proje Tip 2.5'a geçinceye kadar sadece bir geçiş aşamasıdır. Ancak gelecekte Tip 1 veya Tip 2 ZK-EVM'ler, düşük kanıtlayıcı süreleri ve gaz ücretleri ile geliştiriciler için işlevsellik sağlayan yeni ZK-SNARK dostu ön-derlemeler ekleyerek gönüllü olarak Tip 3 ZK-EVM'lere dönüşebilirler.
Tip 4 (yüksek-seviye-dil denkliği)
Bir Tip 4 sistemi, yüksek seviyeli bir dilde (örn. Solidity, Vyper veya her ikisinin de derlediği bir ara dilde) yazılmış akıllı kontrat kaynak kodunu alarak ve bunu açıkça ZK-SNARK dostu olacak şekilde tasarlanmış bir dilde derleyerek çalışır.
Avantaj: Çok hızlı kanıtlayıcı süreleri
Her EVM yürütülme işleminin tüm farklı bölümlerini ZK-kanıtlamayarak ve doğrudan yüksek seviye koddan başlayarak önlenebilecek çok sayıda ek yük vardır.
Bu avantajı bu yazımda sadece bir cümleyle açıklıyorum (aşağıdaki, uyumlulukla ilgili dezavantajlar için olan büyük listeyle karşılaştırıldığında), ancak bu bir değer yargısı olarak yorumlanmamalıdır! Yüksek seviyeli dillerden doğrudan derlemek gerçekten maliyetleri büyük ölçüde azaltabilir ve bir kanıtlayıcı olmayı daha kolay hale getirerek merkeziyetsizleşmeye yardımcı olabilir.
Dezavantaj: Daha fazla uyumsuzluk
Vyper veya Solidity ile yazılmış "normal" bir uygulama derlenebilir ve "sadece çalışır", ancak pek çok uygulamanın "normal" olmadığı bazı önemli yollar vardır:
- Kontratlar Tip 4 bir sistemde EVM'de olduğu gibi aynı adreslere sahip olmayabilir, çünkü CREATE2 kontrat adresleri tamı tamına bytecode'a bağlıdır. Bu, henüz deploy edilmemiş "Karşıolgusal kontratlara", ERC-4337 cüzdanlara, EIP-2470 tekillerine ve birçok diğer uygulamaya dayanan uygulamaları bozar.
- Elle yazılmış EVM bytecode kullanmak daha zordur. Birçok uygulama, verimlilik için bazı bölümlerinde elle yazılmış EVM bytecode kullanır. Tip 4 sistemleri bunu desteklemeyebilir, ancak bu kullanım durumlarını karşılamak için tam anlamıyla bir Tip 3 ZK-EVM olmanın çabasına girmeden sınırlı EVM bytecode desteği uygulamanın yolları vardır.
- Birçok hata ayıklama altyapısı taşınamaz, çünkü bu tür altyapılar EVM bytecode'u üzerinden çalışır. Bununla birlikte, bu dezavantaj "geleneksel" yüksek seviyeli veya ara diller (örn. LLVM) tarafından sunulan hata ayıklama altyapısına daha fazla erişim ile hafifletilir.
Geliştiriciler bu konuları akıllarında bulundurmalıdır.
Bunu kim inşa ediyor?
ZKSync bir Tip 4 sistemidir ancak zamanla EVM bytecode'u için uyumluluk ekleyebilir. Nethermind'ın Warp projesi, Solidity'den Starkware'in Cairo'suna derleyici inşa ediyor ve bu, StarkNet'i fiili bir Tip 4 sistemine dönüştürecektir.
The future of ZK-EVM types
Tipler diğer tiplerden açıkça "daha iyi" veya "daha kötü" değildir. Aksine, bunlar takas alanındaki farklı noktalardır: daha düşük-numaralı tipler mevcut altyapı ile daha uyumludur, ancak daha yavaştır ve daha yüksek-numaralı tipler mevcut altyapı ile daha az uyumludur, ancak daha hızlıdır. Genel olarak bu tiplerin tamamının keşfedilmesi alan açısından sağlıklıdır.
Ek olarak, ZK-EVM projeleri kolaylıkla yüksek-numaralı tiplerden başlayabilir ve zamanla daha düşük-numaralı tiplere atlayabilir (veya tam tersi). Örneğin:
- Bir ZK-EVM, özellikle ZK-kanıtlanması zor olan bazı özellikleri dahil etmemeye karar vererek Tip 3 olarak başlayabilir. Daha sonra zamanla bu özellikleri ekleyip Tip 2'ye geçebilirler.
- Bir ZK-EVM, Tip 2 olarak başlayabilir ve daha sonra, tamamen Ethereum'a uyumluluk modu ile veya daha hızlı kanıtlanabilen değiştirilmiş bir state tree ile çalışma olanağı sunarak hibrit bir Tip 2 / Tip 1 ZK-EVM haline gelebilir. Scroll bu yönde ilerlemeyi düşünüyor.
- Tip 4 olarak başlayan sistem, daha sonra EVM kodunu işleme yeteneğinin eklenmesiyle zamanla Tip 3 haline gelebilir (yine de geliştiriciler ücretleri ve kanıt sürelerini azaltmak için yüksek seviyeli dillerle doğrudan derlemeye yönelecektir).
- Tip 2 veya Tip 3 ZK-EVM, Ethereum'un daha ZK dostu olma çabasıyla modifikasyonlarını benimsemesi durumunda Tip 1 ZK-EVM haline gelebilir.
- Bir Tip 1 veya Tip 2 ZK-EVM, oldukça ZK-SNARK dostu bir dilde kodu doğrulamak için bir ön-derleme ekleyerek Tip 3 ZK-EVM haline gelebilir. Bu, geliştiricilere Ethereum uyumluluğu ve hız arasında bir seçenek sunar. Bu Tip 3 olacaktır çünkü mükemmel EVM-denkliğini bozar, ancak pratik amaçlar ve niyetler için Tip 1 ve 2'nin birçok avantajına sahip olur. Ana dezavantaj, bazı geliştirici araçlarının ZK-EVM'in özel ön-derlemelerini anlamayabileceğidir, ancak bu sorun düzeltilebilir: geliştirici araçları, ön-derlemenin EVM kodu dengi bir implementasyonunu içeren bir yapılandırma formatını destekleyerek evrensel ön-derleme desteği ekleyebilir.
Şahsen, benim umudum ZK-EVM'lerdeki iyileştirmeler ve Ethereum'un kendisini daha ZK-SNARK dostu hale getirecek iyileştirmelerin bir araya gelmesiyle her şeyin zamanla Tip 1 haline gelmesidir. Böyle bir gelecekte, hem ZK rollup'ları hem de Ethereum zincirinin kendisini doğrulamak için kullanılabilecek birden fazla ZK-EVM implementasyonuna sahip olurduk. Teorik olarak Ethereum'un L1 kullanımı için tek bir ZK-EVM implementasyonu üzerinde standartlaşmasına gerek yoktur; farklı istemciler farklı kanıtlar kullanabilir, bu nedenle kod fazlalığından yararlanmaya devam edelim.
Ancak böyle bir geleceğe ulaşmamız oldukça zaman alacak. Bu esnada, Ethereum ve Ethereum tabanlı ZK-rollup'larını ölçeklendirmenin farklı yollarında birçok inovasyon göreceğiz.
Farklı ZK-EVM Türleri
2022 Aug 04 See all postsPSE, Polygon Hermez, Zksync, Scroll, Matter Labs ve Starkware ekiplerine münazara ve inceleme, çeviri için eren'e özel teşekkürler.
Son zamanlarda birçok "ZK-EVM" projesinin çarpıcı duyurular yaptığı görüldü. Polygon ZK-EVM projesini açık kaynaklı hale getirdi, ZKSync, ZKSync 2.0 için planlarını yayınladı ve görece yeni bir oyuncu olan Scroll, ZK-EVM'lerini duyurdu. Ayrıca Privacy and Scaling Explorations ekibinin, Nicolas Liochon ve arkadaşlarının ekibinin, EVM'den Starkware'ın ZK-dostu dili Cairo'ya yönelik bir alfa derleyici ve kaçırdığım en az birkaç kişinin daha kesinlikle devam eden çabaları da var.
Tüm bu projelerin temel hedefi aynı: ZK-SNARK teknolojisini kullanarak Ethereum-benzeri işlemlerin kriptografik yürütülme kanıtlarını oluşturmak, bu kanıtları Ethereum zincirini doğrulamayı çok daha kolay hale getirmek veya Ethereum'un sunduğuna (neredeyse) eşdeğer ancak çok daha ölçeklenebilir olan ZK-rollup'lar inşa etmek için kullanmaktır. Ancak bu projeler arasında ince farklılıklar bulunmakta ve bunlar pratiklik ile hız arasındaki değiş tokuşları nasıl yaptıklarını belirlemektedir. Bu yazı, EVM denkliğinin farklı "tiplerinin" bir taksonomisini ve her bir tipe ulaşmaya çalışmanın fayda ve maliyetlerinin neler olduğunu açıklamaya çalışacaktır.
Genel Bakış (grafik biçiminde)
Tip 1 (tamamen Ethereum-dengi)
Tip 1 ZK-EVM'ler, tamamen ve ödün vermeden Ethereum-dengi olmaya çalışırlar. Kanıtları oluşturmayı kolaylaştırmak için Ethereum sisteminin herhangi bir parçasını değiştirmezler. Ne kadar çevresel olursa olsun hash'leri, state tree'leri, transaction tree'leri, ön-derlemeleri veya başka herhangi bir konsensüse dahil mantığı değiştirmezler.
Avantaj: mükemmel uyumluluk
Hedef, Ethereum bloklarını bugünkü haliyle doğrulayabilmektir - veya en azından yürütme-katmanı tarafını doğrulayabilmektir (bu nedenle, beacon zinciri konsensüs mantığı dahil değil, ancak tüm işlem yürütme ve akıllı kontrat ve hesap mantığı dahil).
Tip 1 ZK-EVM'ler, Ethereum katman 1'inin daha ölçeklenebilir hale gelmesini sağlamak için sonunda ihtiyacımız olan şeydir. Uzun vadede, Tip 2 veya Tip 3 ZK-EVM'lerde test edilmiş Ethereum'a yapılan modifikasyonlar, Ethereum'a uygun bir şekilde tanıtılabilir, ancak böyle bir yeniden tasarlama kendi komplekslikleri ile gelir.
Tip 1 ZK-EVM'ler aynı zamanda rollup'lar için idealdir, çünkü rollup'ların birçok altyapıyı tekrar kullanmalarına izin verirler. Örneğin, Ethereum execution istemcileri, rollup blokları oluşturmak ve işlemek için olduğu gibi kullanılabilir (veya en azından para çekme işlemleri implement edildiğinde ve bu işlevsellik, rollup'a ETH yatırılmasını desteklemek için tekrar kullanılabilir), bu nedenle blok gezginleri, blok üretimi vb. gibi araçlar çok kolay bir şekilde tekrar kullanılabilir.
Dezavantaj: kanıtlayıcı zamanı
Ethereum, başlangıçta ZK-dostu olacak şekilde tasarlanmamıştı, bu nedenle Ethereum protokolünün, ZK-kanıtlama için büyük miktarda hesaplama gerektiren birçok parçası var. Tip 1, Ethereum'u tam olarak kopyalamayı amaçlıyor, o yüzden bu verimsizlikleri hafifletebilecek bir yola sahip değil. Şu anda, Ethereum bloklarının kanıtlarının üretilmesi saatler sürüyor. Bu durum, kanıtlayıcıyı büyük ölçüde paralelleştirmeye yönelik zekice mühendislikle veya uzun vadede ZK-SNARK ASIC'ler ile hafifletilebilir.
Bunu kim inşa ediyor?
ZK-EVM Topluluk Sürümü (Privacy and Scaling Explorations, Scroll ekibi, Taiko ve diğerlerinin topluluk katkılarıyla başlatılan) Tier 1 bir ZK-EVM'dir.
Tip 2 (tamamen EVM-dengi)
Tip 2 ZK-EVM'ler tam anlamıyla EVM-dengi olmaya çalışır, ancak tam olarak Ethereum-dengi değildirler. Yani, "içeriden" bakıldığında tam olarak Ethereum gibi görünürler, ancak dışarıda bazı farklılıklar, özellikle blok yapısı ve state tree gibi veri yapılarında bulunur.
Hedef, mevcut uygulamalarla tamamen 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 seviyesinde mükemmel denklik
Tip 2 ZK-EVM'ler, Ethereum durumu gibi verileri tutan veri yapılarına değişiklikler yaparlar. Neyse ki, bunlar EVM'in doğrudan erişemeyeceği yapılar olduğundan, Ethereum üzerinde çalışan uygulamalar neredeyse her zaman Tip 2 ZK-EVM rollup'larında da çalışmaya devam eder. Ethereum execution istemcilerini olduğu gibi kullanamazsınız, ancak bazı değişikliklerle kullanabilirsiniz ve hala EVM hata ayıklama araçlarını ve çoğu diğer geliştirici altyapısını kullanabilirsiniz.
Az sayıda istisna vardır. Örneğin geçmiş işlemler, makbuzlar veya durum hakkındaki iddiaları doğrulamak için geçmiş Ethereum bloklarının Merkle kanıtlarını doğrulayan uygulamalarda bir uyumsuzluk ortaya çıkar (örn. köprüler bazen bunu yapar). Keccak'ı farklı bir hash fonksiyonuyla değiştiren bir ZK-EVM, bu kanıtları bozabilir. Bununla birlikte, zaten genellikle uygulamaların bu şekilde inşa edilmesini önermem, çünkü gelecek Ethereum değişiklikleri (örn. Verkle ağaçları) bu tür uygulamaları Ethereum'un kendisinin üzerinde bile bozacaktır. Daha iyi bir alternatif, Ethereum'un geleceğe-hazır geçmiş erişim ön-derlemelerini eklemesidir.
Dezavantaj: Gelişmiş ancak hala yavaş kanıtlayıcı süresi
Tip 2 ZK-EVM'ler, Ethereum yığınının gereksiz derecede karmaşık ve ZK dostu olmayan kriptografiye dayanan kısımlarını kaldırarak Tip 1'den daha hızlı kanıtlayıcı süreleri sağlar. Özellikle Ethereum'un Keccak'ını ve RLP tabanlı Merkle Patricia ağacını ve belki de blok ve makbuz yapılarını değiştirebilirler. Tip 2 ZK-EVM'ler, farklı bir hash fonksiyonu kullanabilirler, örneğin Poseidon. Başka bir doğal değişiklik, state tree'yi kod hash'ini ve keccak'ı depolayacak şekilde değiştirerek
EXTCODEHASHveEXTCODECOPYopcode'larını işlemek için hash doğrulama ihtiyacını ortadan kaldırmaktır.Bu değişiklikler kanıtlayıcı sürelerini önemli ölçüde iyileştirir ancak her sorunu çözmez. EVM'i olduğu gibi kanıtlama zorunluluğundan kaynaklanan yavaşlık, EVM'in doğasında bulunan tüm verimsizlikler ve ZK dostu olmama durumuyla birlikte hala devam ediyor. Bunun basit bir örneği bellektir: Bir
MLOAD, "hizalanmamış" parçalar (başlangıç ve bitişin 32'nin katı olmadığı) dahil olmak üzere herhangi bir 32 byte'ı okuyabildiğinden, bir MLOAD basitçe bir parçayı okuyormuş gibi yorumlanamaz; bunun yerine, sonucu birleştirmek için iki ardışık parçanın okunmasını ve bit işlemleri gerçekleştirilmesini gerektirebilir.Bunu kim inşa ediyor?
Scroll'un ZK-EVM projesi, Polygon Hermez gibi Tip 2 ZK-EVM'e doğru ilerliyor. Bununla birlikte, her iki proje de henüz tam olarak oraya ulaşmadı; özellikle daha karmaşık ön-derlemelerin çoğu henüz implement edilmedi. Dolayısıyla şu anda her iki projenin de Tip 3. olarak değerlendirilmesi daha iyi.
Tip 2.5 (EVM-dengi, gaz ücretleri hariç)
En kötü durumda kanıt sürelerini önemli ölçüde iyileştirmenin bir yolu, EVM'deki ZK-kanıtlaması çok zor olan belirli işlemlerin gaz ücretlerini büyük ölçüde artırmaktır. Bu, ön-derlemeleri, KECCAK opcode'unu ve muhtemelen belirli kontrat çağırma kalıplarını veya belleğe/depolamaya erişmeyi veya geri döndürmeyi (revert) içerebilir.
Gaz ücretlerini değiştirmek, geliştirici araçlarının uyumluluğunu azaltabilir ve birkaç uygulamayı bozabilir, ancak genellikle "derin" EVM değişikliklerinden daha az riskli olarak kabul edilir. Geliştiriciler, bir işlemde bir bloğa sığmayacak kadar fazla gaz gerektirmemeye ve hard-coded gaz miktarlarıyla çağrılar yapmamaya dikkat etmelidir (bu zaten geliştiriciler için uzun süredir standart bir öneridir).
Kaynak sınırlamalarını yönetmenin alternatif bir yolu, her operasyonun kaç kez çağrılabileceği konusunda katı sınırlar belirlemektir. Bunun devrelerde uygulanması daha kolaydır, ancak EVM güvenlik varsayımlarıyla daha az uyumludur. Ben buna Tip 2.5 yerine Tip 3 yaklaşımı derim.
Tip 3 (neredeyse EVM-dengi)
Tip 3 ZK-EVM'ler neredeyse EVM-dengidir, ancak kanıt sürelerini daha da iyileştirmek ve EVM'i geliştirmeyi kolaylaştırmak için tam denklikten ödün verirler.
Avantaj: Daha kolay inşa edilir ve daha hızlı kanıtlayıcı süreleri sunar.
Tip 3 ZK-EVM'ler, ZK-EVM implementasyonunda uygulanması son derece zor olan birkaç özelliği kaldırabilir. Genellikle ön-derlemeler bu listede en üsttedir. Ek olarak, Tip 3 ZK-EVM'lerin bazen kontrat kodunu, belleği veya yığını nasıl ele aldıkları konusunda da küçük farklılıkları vardır.
Dezavantaj: Daha fazla uyumsuzluk.
Tip 3 ZK-EVM'in hedefi, çoğu uygulama ile uyumlu olup geri kalanları için sadece minimal yeniden yazım gerektirmektir. Bununla beraber, Tip 3 ZK-EVM'in kaldırdığı ön-derlemeleri kullanan veya VM'lerin farklı işlediği ince ayrıntılardaki bağımlılıklardan dolayı yeniden yazılması gereken bazı uygulamalar olacaktır.
Bunu kim inşa ediyor?
Scroll ve Polygon'un her ikisi de mevcut formlarıyla Tip 3'tür, ancak zamanla uyumluluğu artırmaları bekleniyor. Polygon, zkASM denen kendi dahili dilini ZK-doğruladıkları ve zkASM implementasyonunu kullanarak ZK-EVM kodunu yorumladıkları benzersiz bir tasarıma sahiptir. Bu implementasyon detayına rağmen yine de buna hakiki Tip 3 ZK-EVM diyeceğim; çünkü hala EVM kodunu doğrulayabiliyor, sadece bunu yapmak için yalnızca farklı bir dahili mantık kullanır.
Bugün, hiçbir ZK-EVM ekibi Tip 3 olmak istemez; Tip 3, ön-derlemelerin eklenmesi gibi karmaşık işler bitene ve proje Tip 2.5'a geçinceye kadar sadece bir geçiş aşamasıdır. Ancak gelecekte Tip 1 veya Tip 2 ZK-EVM'ler, düşük kanıtlayıcı süreleri ve gaz ücretleri ile geliştiriciler için işlevsellik sağlayan yeni ZK-SNARK dostu ön-derlemeler ekleyerek gönüllü olarak Tip 3 ZK-EVM'lere dönüşebilirler.
Tip 4 (yüksek-seviye-dil denkliği)
Bir Tip 4 sistemi, yüksek seviyeli bir dilde (örn. Solidity, Vyper veya her ikisinin de derlediği bir ara dilde) yazılmış akıllı kontrat kaynak kodunu alarak ve bunu açıkça ZK-SNARK dostu olacak şekilde tasarlanmış bir dilde derleyerek çalışır.
Avantaj: Çok hızlı kanıtlayıcı süreleri
Her EVM yürütülme işleminin tüm farklı bölümlerini ZK-kanıtlamayarak ve doğrudan yüksek seviye koddan başlayarak önlenebilecek çok sayıda ek yük vardır.
Bu avantajı bu yazımda sadece bir cümleyle açıklıyorum (aşağıdaki, uyumlulukla ilgili dezavantajlar için olan büyük listeyle karşılaştırıldığında), ancak bu bir değer yargısı olarak yorumlanmamalıdır! Yüksek seviyeli dillerden doğrudan derlemek gerçekten maliyetleri büyük ölçüde azaltabilir ve bir kanıtlayıcı olmayı daha kolay hale getirerek merkeziyetsizleşmeye yardımcı olabilir.
Dezavantaj: Daha fazla uyumsuzluk
Vyper veya Solidity ile yazılmış "normal" bir uygulama derlenebilir ve "sadece çalışır", ancak pek çok uygulamanın "normal" olmadığı bazı önemli yollar vardır:
Geliştiriciler bu konuları akıllarında bulundurmalıdır.
Bunu kim inşa ediyor?
ZKSync bir Tip 4 sistemidir ancak zamanla EVM bytecode'u için uyumluluk ekleyebilir. Nethermind'ın Warp projesi, Solidity'den Starkware'in Cairo'suna derleyici inşa ediyor ve bu, StarkNet'i fiili bir Tip 4 sistemine dönüştürecektir.
The future of ZK-EVM types
Tipler diğer tiplerden açıkça "daha iyi" veya "daha kötü" değildir. Aksine, bunlar takas alanındaki farklı noktalardır: daha düşük-numaralı tipler mevcut altyapı ile daha uyumludur, ancak daha yavaştır ve daha yüksek-numaralı tipler mevcut altyapı ile daha az uyumludur, ancak daha hızlıdır. Genel olarak bu tiplerin tamamının keşfedilmesi alan açısından sağlıklıdır.
Ek olarak, ZK-EVM projeleri kolaylıkla yüksek-numaralı tiplerden başlayabilir ve zamanla daha düşük-numaralı tiplere atlayabilir (veya tam tersi). Örneğin:
Şahsen, benim umudum ZK-EVM'lerdeki iyileştirmeler ve Ethereum'un kendisini daha ZK-SNARK dostu hale getirecek iyileştirmelerin bir araya gelmesiyle her şeyin zamanla Tip 1 haline gelmesidir. Böyle bir gelecekte, hem ZK rollup'ları hem de Ethereum zincirinin kendisini doğrulamak için kullanılabilecek birden fazla ZK-EVM implementasyonuna sahip olurduk. Teorik olarak Ethereum'un L1 kullanımı için tek bir ZK-EVM implementasyonu üzerinde standartlaşmasına gerek yoktur; farklı istemciler farklı kanıtlar kullanabilir, bu nedenle kod fazlalığından yararlanmaya devam edelim.
Ancak böyle bir geleceğe ulaşmamız oldukça zaman alacak. Bu esnada, Ethereum ve Ethereum tabanlı ZK-rollup'larını ölçeklendirmenin farklı yollarında birçok inovasyon göreceğiz.