Beş ZK-EVM tipini ayrıntılı olarak açıklayın: mimari, avantajlar ve dezavantajlar ve çözümler

Orijinal metnin yazarı: s Orijinal metnin derlemesi: Deep Tide TechFlow

Bu makale, her biri benzersiz mimariye, avantaj ve dezavantajlara ve olası çözümlere sahip beş ZK-EVM tipini ayrıntılı olarak incelemektedir.

Ayrıca makale, okuyucuların bu türlerin pratik uygulamalardaki performansını daha iyi anlayabilmeleri için bazı pratik proje örneklerini de listeler. İster bir blockchain geliştiricisi olun, ister blockchain teknolojisiyle ilgilenen bir okuyucu olun, bu makale size derinlemesine ve özlü bilgiler sağlayacaktır.

ZK-EVM tiplerini, artılarını ve eksilerini keşfedelim.

1. Tip 1: tamamen Ethereum'a eşdeğer;

2. Tip 2: EVM'ye tamamen eşdeğerdir;

3. Tip 2.5: Kısmen EVM'ye eşdeğer;

4. Tip 3: EVM'ye neredeyse eşdeğerdir;

5. Tip 4: üst düzey dilin eşdeğer olduğu yer.

Tip 1: Ethereum'a tamamen eşdeğer

Mimari: Ethereum ile tamamen aynıdır ve Ethereum sisteminin herhangi bir parçasını değiştirmez.

avantaj

Mükemmel Uyumluluk:

• Ethereum bloklarını doğrulama yeteneği;
• Ethereum L1'i daha ölçeklenebilir hale getirmeye yardımcı olun;
• Çok sayıda altyapıyı yeniden kullanabildikleri için Toplamalar için uygundur.

eksiklik

Mükemmel Uyumluluk:

• Ethereum orijinal olarak ZK işlevselliği için tasarlanmamıştır;
• Ethereum'un birçok bileşeni, ZK kanıtları (ZKP) oluşturmak için çok fazla hesaplama gerektirir;
• Ethereum blokları için kanıtların oluşturulması saatler alır.

Sorunun çözümü:

• Büyük ölçekli paralelleştirme kanıtı;
• ZK-SNARK ASIC.

Tip 2: EVM'ye tamamen eşdeğer

Mimari:

• Veri yapısı (blok yapısı ve durum ağacı) Ethereum'dan önemli ölçüde farklıdır;
• Mevcut uygulamalarla tam uyumlu;
• Daha kolay geliştirme ve daha hızlı kanıt üretimi için Ethereum'da küçük değişiklikler.

avantaj

• Tip 1'den daha hızlı prova süreleri sağlar;
• Veri yapısına EVM tarafından doğrudan erişilmez;
• Ethereum üzerinde çalışan uygulamalar: Tip 2 üzerinde çalışması muhtemeldir;
• Mevcut EVM hata ayıklama araçları ve diğer geliştirme altyapısı için destek.

eksiklik

Dezavantajlarını anlamadan önce "Keccak" nedir onu anlayın:

• Ethereum blok zincirinin karma algoritması;
• Ethereum üzerindeki verileri korumak için kullanılır;
• Mesajın bir hash'e dönüştürüldüğünden emin olun.

Tip 2, geçmiş işlemler, makbuzlar/durumlar hakkındaki bilgileri doğrulamak için geçmiş blokların Merkle kanıtlarını doğrulayan uygulamalarla uyumlu değildir. Bunun nedeni, karma algoritma değişirse (artık Keccak değil), ispatın geçersiz hale gelmesidir.

Keccak'ı Merkle ispatlarını (alfabeleri) kullanan bir dil olarak düşünebiliriz. Eğer ZK-EVM, Keccak'ı başka bir hashing algoritması (Poseidon gibi) ile değiştirirse, Merkle ispatları yabancılaşacak ve uygulamalar bunları okuyamayacak ve iddialarını doğrulayamayacaktır.

Eksiklikler için potansiyel çözüm: Ethereum, gelecekteki ölçeklenebilir geçmiş erişim ön derlemesini ekleyebilir.

proje

• Taslak;
• Çokgen Hermez.

Ancak, bu projeler henüz daha karmaşık bir ön derleme uygulamamıştır, bu nedenle tamamlanmamış Tip 2 olarak kabul edilebilirler.

Tip 2.5: Kısmen EVM'ye eşdeğer

Mimari:

ZK'nın kanıtlanması zor olan belirli EVM operasyonlarının gaz maliyetini artırın;

• Önceden derlenmiş;
• Keccak işlem kodu;
• Sözleşmeyi arama modu;
• Erişim belleği;
• depolamak.

avantaj

• Önemli ölçüde iyileştirilmiş en kötü durum kanıtlama süresi;
• EVM yığınında daha derin değişiklikler yapmaktan daha güvenli.

eksiklik

• Geliştirme araçlarının uyumluluğu azalır;
• Bazı uygulamalar çalışmaz.

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

Mimari:

• ZK-EVM uygulamasında, uygulanması son derece zor olan bazı işlevler silinir, genellikle önceden derlenir;
• ZK-EVM'nin sözleşme kodunu, belleği veya yığını işleme biçiminde küçük farklılıkları vardır.

avantaj

• doğrulama süresini kısaltın;
• EVM'nin geliştirilmesini kolaylaştırın;
• Amaç, daha az uyumlu uygulamalar için en az yeniden yazma gerektirmektir.

eksiklik

• Daha fazla uyumsuzluk;
• Type 3'te kaldırılan ön derleme kullanan uygulamaların yeniden yazılması gerekir.

proje

Şu anda Scroll ve Polygon, Type 3 olarak kabul ediliyor, ancak ZK-EVM ekibi Type 3 olmakla yetinmemeli, Type 3, ZK-EVM'nin uyumluluğu artırmak için ön derleme eklediği ve Type 2.5'e geçtiği bir geçiş aşamasıdır.

Tip 4: üst düzey dil eşdeğeri

Mimari:

• Üst düzey dillerde (Solidity, Vyper gibi) yazılmış akıllı sözleşme kodunu kabul edin;
• ZK-SNARK dostu olacak şekilde tasarlanmış bir dilde derlenmiştir.

avantaj

• Çok hızlı prova süresi;
• Azaltılmış ek yük (maliyet, zaman ve hesaplama çabası);
• Kanıtlayıcı olma engelini azaltın: yerelleşme derecesini artırın.

eksiklik

• Tip 4 sistemde, adres tam bayt koduna bağlı olduğundan, sözleşmenin adresi EVM'deki adresten farklı olabilir;
• Bu, tip 4 ZK-EVM'lerin bayt kodları yoksa, adres oluşturamayacakları anlamına gelir;
• Tip 4, yukarıdaki durumlarda karşı olgusal sözleşmelere dayanan uygulamalarla uyumsuz olacaktır;
• Pek çok hata ayıklama altyapısı, EVM bayt kodunda çalıştıkları için taşınabilir değildir.

proje

• zkSync

Son olarak, herkesin farklı zkEVM'leri bir bakışta anlamasına yardımcı olmak için yukarıdaki türleri birlikte karşılaştırabiliriz.