Tip1'den Tip4'e kadar çeşitli ZK-EVM türleri arasındaki farklar nelerdir?

Orijinal yazar| Lisa Akselrod

Derlenmiş | Odaily Planet Daily 0xAyA

*Editörün notu: Yazar, daha önce Vitalik'in yazdığı ZK-EVM tanıtım makalesinden yola çıkarak derlemiş ve ZK-EVM'nin çeşitli türlerini ve aralarındaki farkları ayrıntılı olarak tanıtmıştır. *

Yaklaşık bir yıl önce bir grup ZK-EVM, bir test ağı başlatmak üzere olduklarını duyurdu. Bu hamleler Ethereum topluluğunun merakını uyandırdı ve Ethereum denkliği ve EVM denkliği gibi terimlerin ardındaki nüanslar hakkında tartışmayı ateşledi.

Konuya açıklık getirmek adına Vitalik, çeşitli ZK-EVM'leri dört tipte sınıflandıran ve aralarındaki farkları açıklayan "Farklı ZK-EVM Türleri" başlıklı önemli bir makale yazdı.

Temel fikir şudur: Tip 1 (örneğin Taiko) Ethereum'a tamamen eşdeğerdir, Tip 4 (örneğin zkSync) ise etkili kanıt oluşturma konusunda üstündür. Diğer tüm türler (Tip 2, Tip 2.5 ve Tip 3) bu ikisinin arasındadır (örn. Polygon zkEVM, Scroll, Linea).

ZK-EVM'lerin çoğu başlangıçta Tip 2.5 ve Tip 3'tür ve bazılarının Tip 1 veya Tip 2'ye doğru gelişme niyeti ortaya çıkmıştır, ancak bu projeler bunun için belirli bir zaman çizelgesi veya taahhüt sunmamıştır.

**Bu makale Tip 1 ile Tip 2/Tip 2.5 arasındaki farklara odaklanmakta ve Ethereum eşdeğerliğinin kırılmasının olası sonuçlarını açıklamaktadır. Diğer türlere de kısaca değineceğiz. **

ZK-EVM'nin ana hedefi Ethereum'u ölçeklendirmek, yani diğer özelliklerini (güvenlik, geliştirici deneyimi vb.) korurken Ethereum'un verimini arttırmaktır. İdeal olarak ZK-EVM şunları yapabilmelidir:

• Sarı Kitaptaki Ethereum Sanal Makine spesifikasyonuna göre değiştirilmemiş yerel bayt kodunun (Ethereum işlem kodlarının %100'ünü kapsayan) yürütülmesini gösterir.
• Düşük maliyetle hızlı bir şekilde provalar oluşturun.
• Ethereum için geliştirilen araçların ve altyapının %100 yeniden kullanılmasına olanak sağlar.
• Herhangi bir Ethereum dApp'in ZK-EVM'de "olduğu gibi" yeniden konuşlandırılmasına izin verin ("olduğu gibi", hiçbir değişiklik gerekmediği, ödün verilmediği anlamına gelir).

ZK-EVM tipleri arasındaki farklar

ZK-EVM dünyasında, farklılıklar temel olarak Ethereum/EVM eşdeğerliği düzeyinden, ZK dostu olmayan unsurların kanıt oluşturma maliyeti ve hızı üzerindeki etkisinden ve devre uygulamasının karmaşıklığından (VM yapısı veya durumu gibi) kaynaklanmaktadır. ağaçlar).

Bu farklılıkları, özellikle Tip 1'i Tip 2/Tip 2.5'ten ayırt ederek inceleyelim. Ayrıca her türle en alakalı kullanım senaryolarına da değineceğiz.

Çeşitli türleri karşılaştırırken genellikle aşağıdaki tablo kullanılır:

ZK-EVM alanında tam zamanlı çalışmayanlar için bu tablo kafa karıştırıcı görünebilir, bu nedenle bu terimleri sıradan terimlere çevirelim ve bir göz atalım:

Bu şema, her türün gerçekte neye benzediğine dair daha net bir resim verir, ancak yine de biraz belirsiz olabilir.Her türü ayrı ayrı açıklayarak ZK-EVM dünyasını tam olarak keşfedelim.

Tip 1: Ethereum'a eşdeğer

Vitalik Buterin:

"Tip 1 ZK-EVM, Ethereum katman 1'in kendisini daha ölçeklenebilir hale getirmek için nihai olarak ihtiyacımız olan şeydir."

Tip 1, kanıt oluşturmayı kolaylaştırmak için Ethereum sisteminin herhangi bir bölümünü değiştirmemek anlamına gelir. Ethereum'da herhangi bir değişiklik yapılmaması, güvenlikten taviz verilmemesi anlamına gelir; zira çoğu kriptografik temel (örn. hash işlevleri), geliştirici altyapısı (örn. hata ayıklayıcılar) veya zincir altyapısı (örn. yürütme istemcileri) zaten 9 yıllık saha testinden geçmiştir.

Tip 1 ZK-EVM hiçbir şeyin yerini almaz: karmalar, durum ağaçları, işlem ağaçları, ön derleme veya başka herhangi bir konsensüs mantığı; her şey ana ağın EVM'si ile tamamen aynıdır.

• Tip 1, tüm bloklardan işlem yürütmeye, akıllı sözleşmelere ve hesap mantığına kadar Ethereum zincirinin kendisini doğrulayabilen tek türdür.

Tip 2: EVM'ye eşdeğer

Tip 2, ZK'ye elverişli olmayan bazı parçaları kaldırarak kanıt oluşturmayı daha hızlı hale getirir ve devre geliştirmeyi kolaylaştırır. Ancak bunun sonuçları nedeniyle ZK-rollup'ın diğer bölümlerinin (düğüm yazılımı gibi) geliştirilmesini daha karmaşık hale getirebilir. Bu karmaşıklıklara, yerleşik en iyi uygulamalar ve test araçları ile uygulanan değişiklikler (değiştirilmiş durum ağacı gibi) arasındaki uyumsuzluklar neden olabilir.

*Not: Ethereum'a eşdeğer ve EVM'ye eşdeğer aynı değildir. Ethereum'a eşdeğerlik, Ethereum'un hiçbir kısmının değiştirilmediği anlamına gelir; bu, tüm Ethereum dApp'leriyle tamamen uyumlu olduğu anlamına gelirken, EVM'ye eşdeğerlik, veri yapılarında (blok yapıları veya durum ağaçları gibi) değişikliklere izin verir. *

Bu ayarlamalar küçük gibi görünse de Ethereum'un uyumluluğunu etkiler. Veri yapılarının değiştirilmesi, özellikle geçmiş işlemlere, makbuzlara veya durumlara (zincir köprüler gibi) ilişkin Merkle kanıtlarını doğrularken, Ethereum dApp'lerinin Tip 2 ZK-EVM ile uyumsuz olmasına neden olabilir.

ZK'nin düşmanca unsurlarını silin

Ethereum'da yapılan değişikliklerin amacı geliştirmeyi basitleştirmek ve kanıt oluşturma hızını artırmaktır. Amaç, Ethereum'un düşmanca sıfır bilgi şifrelemesine dayanan kısımlarını budamaktır. Daha teknik bir ifadeyle, yerel olmayan alanlar (hash fonksiyonları gibi) nedeniyle çok sayıda kapı (toplama ve çarpma işlemleri) gerektiren parçalar, çok sayıda çok skaler çarpma ve/veya hızlı Fourier dönüşümü (FFT); veya Sadece çok fazla manipülasyon gerektiren kısım.

Tip 2 ZK-EVM'nin değiştirebileceği dost canlısı olmayan sıfır bilgi unsurlarının spesifik örnekleri:

• Hash fonksiyonu: Ethereum, Keccak hash fonksiyonunu kullanırken, birçok ZK-EVM, çok daha az sayıda kapı gerektiren Poseidon hash fonksiyonunu kullanır. Örneğin, her türden kaç karma fonksiyonunun saniyede hesaplanabileceğini tahmin edelim (yani üretim hızını gösteren bir karşılaştırma).

Poseidon karma fonksiyonlarının kanıt oluşturmada önemli hız avantajları vardır.

Bununla birlikte, daha yeni kriptografik temellerin, topluluk tarafından yaygın olarak tanınan yerleşik kriptografik temellere göre daha popüler olmadığını belirtmek önemlidir. Poseidon hız sunsa da Keccak'ın savaşta test edilmiş özellikleri, yaygın olarak benimsendiği için onu daha sağlam ve güvenli hale getiriyor.

Bu nedenle Keccak, daha eski olmasına ve daha geniş bir topluluk tarafından benimsenmesine rağmen (akıllı cihazlardaki güvenlik sistemleri veya sensörler gibi diğer sektörlerde), sonuçta ZK topluluğu içinde yer alan Poseidon'dan daha denenmiş ve test edilmiş olarak değerlendirilebilir. oluşturmak ve kullanmak için işlevler.

• Veri depolama için durum ağaçları: Örneğin, Ethereum Merkle Patricia ağaçlarını kullanırken (Keccak hashingini kullanarak), bazı Tip 2 ZK-EVM'ler seyrek Merkle ağaçlarını (Poseidon hashingini kullanarak) seçer. Durum ağacının değiştirilmesi bazı uyumsuzluklara neden olabilir. Örneğin, Ethereum'un Merkle ağacı farklı düğüm türlerine sahiptir ve verileri kodlamak için RLP'yi kullanır ki bu ZK'da yapılması zor bir şeydir.
• Blok yapısı: Bloklar büyük miktarda bilgi içerir. Ancak, L2'yi keşfederken yalnızca ution_payload_header (yani blok karması) ile ilgileniyoruz. Aşağıdaki görselde ution_payload_header içerisinde yer alan tüm verilerin yapısı (blok hash) bulunmaktadır.

**Lütfen unutmayın: Bu bileşenlerden herhangi birinin değiştirilmesi Ethereum eşdeğerliğini bozacaktır. **

Tip 2.5: Gaz maliyeti dikkate alındığında EVM'ye eşdeğerdir

Tip 2.5 ZK-EVM, EVM'de ZK teknolojisi kullanılarak kanıtlanması zor olan belirli operasyonların gaz maliyetini artırır.

Ethereum'un blok başına gaz limiti (30 M gaz) göz önüne alındığında, işlem kodu başına gaz maliyetinin arttırılması, blok başına daha az işlem koduyla sonuçlanır. Bu nedenle bir bloğa daha az karmaşık işlem kodları dahil edilebilir. Daha basit işlem kodları, devrelerin daha küçük olmasına ve kanıtların daha hızlı oluşturulmasına olanak tanır.

• Gaz iş için bir ölçü birimidir.
• Opcode fiyatları gaz bazında hesaplanmıştır.
• Opcode'lar makine dili talimatlarındaki işlemleri belirtir.
• Bir program, işlem kodlarının statik bir listesidir. Program yürütme bir yürütme izlemesidir.
• Yürütme izlemesi, bir program tarafından yürütülen işlem kodlarının belirli bir sıralı listesidir.

ZK'yi kanıtlaması zor olan kısımlar şunları içerir:

• Keccak işlem kodları ve Keccak'a bağlı diğer bazı işlem kodları.
• Önceden derlenmiş: EVM tarafından erişilebilen işlevler. Bazıları, kriptografik işlevler (blake 2 f veya sha 256 gibi) gibi karmaşık veya matematiksel açıdan karmaşık görevler sağlar. EVM içinde yürütülmezler, bunun yerine yürütme istemcisinde sabit kodlanmış ve özel adreslere yapılan CALL'ları kullanarak EVM'ye sunulan işlevler olarak yürütülürler.
• Bellek erişimi: örneğin bellek yuvası boyutunun arttırılması (örneğin, Ethereum bayt hizalı bellek kullanırken Polygon zkEVM 32 baytlık bellek yuvaları kullanır). Bu değişikliği mümkün kılmak için belirli işlem kodlarının (MLOAD gibi) iç mantığının değiştirilmesi gerekiyordu.
• Depolama (yani karma işlevinin veya durum ağacının yukarıda açıklandığı gibi değiştirilmesi).

Gas maliyetlerinin değiştirilmesi, geliştirici araçlarının uyumluluğunu azaltabilir ve bazı dApp'leri bozabilir. Örneğin, artan gas maliyetleriyle birlikte işlem kodlarını sıklıkla çalıştıran bir akıllı sözleşme, blok gaz sınırını aşabilir ve yürütülemeyebilir.

Tip 3: EVM'ye neredeyse eşdeğer

Tip 3 ZK-EVM, ZK için geçerli olmayan ön derlemeyi atlar ve bellek ve depolama erişimini ayarlayabilir.

Kaldırılan önceden derlenmiş uygulamalara dayanan dApp'lerin yeniden yazılması gerekecektir. Olağandışı durumlarda, Type 3 ZK-EVM ve orijinal EVM tarafından uç durumların nasıl ele alındığına ilişkin farklılıklar dApp'te ayarlamalar gerektirebilir.

Tip 4 (yüksek seviye dile eşdeğer)

Tip 4 zaten EVM'den çok uzakta.

Üst düzey bir dilde (örneğin, Solidity, Çinko) yazılan akıllı sözleşme kaynak kodu, ZK dostu sanal makinelere uygun işlem kodları üreten bir ara temsil halinde derlenir.

• Bu yöntem, her EVM yürütme adımı için ZK provalarının oluşturulmasını önler, böylece prova çalışmasını büyük ölçüde azaltır.
• Sözleşme derlenebilse bile dApp'in EVM elle yazılan bayt kodunu kullanması durumunda daha fazla çalışma yapılması gerekir. *Tip 4 ZK-EVM ayrıca hata ayıklayıcılar ve izleyiciler gibi kendi geliştirici araçlarını (yalnızca işlem kodu düzeyinde) gerektirir.

Yürütme yörüngesini kanıtlayan ZK devresinde, her adım kısıtlamayı uygular ve her adımın maliyeti tüm işlem kodlarının toplamıdır. Bu nedenle Tip 4 ZK-EVM, verimliliği optimize etmek için mümkün olduğunca az sayıda karmaşık işlem kodu kullanacak şekilde tasarlanmıştır.

Özel işlem kodlarının (Ethereum kapsamında olmayan işlem kodları), varsayılan olarak Ethereum'da mümkün olmayan yeni özelliklerin aktarılmasını mümkün kıldığını belirtmekte fayda var. Örneğin, hesap soyutlama özelliği aracılığıyla yürütme için birden fazla çağrı yapın veya Argent gibi kullanıma hazır bir çözüm kullanarak akıllı sözleşme cüzdanı başlatın.

Özetle

Farklı ZK-EVM türleri, farklı hedeflere ve özelliklere öncelik verir. Tip 1, Ethereum eşdeğerliğine odaklanırken Tip 4, verimli kanıt oluşturmaya öncelik verir. Diğer türler bu uç noktalar arasında yer alıyor ve birçok Tip 2 ve 3 ZK-EVM protokolü, Ethereum eşdeğerlerine geçme niyetlerini açıkladı.

Bu dört sınıflandırma türü, ZK toplamasının son durumu olmayabilir ve gelecekte başka değişikliklere tabi olabilir. Örneğin, bazı ZK-EVM'ler hibrit hale gelebilir, Tip 1/2, Tip 4 çözümler geliştirebilir (mümkün olan en yüksek verimlilikle) ve dApp'lere her iki seçeneği de sunabilir, Tip 3 ve 4 ZK-EVM'ler ise Ethereum eşdeğeri seçeneği ekleyebilir.