Orijinal başlık: Güvenli ve verimli zkVM'lere giden yol: İlerlemeyi nasıl takip edebiliriz

Orijinal yazar: a16z crypto

Orijinal çeviri: Golem, Odaily Planet Daily

zkVM (sıfır bilgi sanal makinesi) "SNARK'ları demokratikleştirmeyi" vaat ediyor ve herkesin (profesyonel SNARK uzmanlığı olmayanlar bile) belirli bir girdide (veya tanıkta) herhangi bir programı doğru şekilde çalıştırdıklarını kanıtlamalarına olanak tanıyor. Temel güçleri geliştirici deneyiminde yatıyor, ancak şu anda hem güvenlik hem de performans açısından büyük zorluklarla karşı karşıyalar. ZkVM vizyonunun vaadini yerine getirebilmesi için tasarımcıların bu zorlukların üstesinden gelmeleri gerekiyor. Bu yazımda, tamamlanması birkaç yıl sürecek zkVM geliştirmenin olası aşamalarını özetledim.

Zorluklar

Güvenlik açısından zkVM oldukça karmaşık bir yazılım projesidir ve hala güvenlik açıklarıyla doludur. Performans açısından, bir programın doğru şekilde çalıştığını kanıtlamak, onu yerel olarak çalıştırmaktan yüz binlerce kat daha yavaş olabilir; bu da şu anda çoğu uygulamanın gerçek dünyada dağıtılmasını imkansız hale getirir.

Gerçek dünyadaki bu zorluklara rağmen, blockchain sektöründeki şirketlerin çoğu zkVM'yi hemen devreye alınmaya hazır olarak tasvir ediyor. Aslında bazı projeler, zincir üstü aktivitenin kanıtlarını üretmek için önemli miktarda hesaplama maliyeti ödedi. Ancak zkVM hala mükemmel olmadığından, bu aslında bir sistemin SNARK'lar tarafından korunduğu iddiasının pahalı bir yoludur; oysa gerçekte sistem ya izinle korunmaktadır ya da daha kötüsü, saldırılara karşı savunmasızdır.

Güvenli ve performanslı bir zkVM'ye ulaşmamıza hâlâ birkaç yıl var. Bu yazıda, zkVM'nin gelişimini takip etmek için bir dizi somut, aşamalı hedef öneriliyor. Bu hedefler, abartıları ortadan kaldıracak ve topluluğun gerçek ilerlemeye odaklanmasına yardımcı olacak.

Güvenlik Aşaması

SNARK tabanlı zkVM'ler genellikle iki ana bileşenden oluşur:

· Polinomlar Üzerindeki Etkileşimli Oracle Kanıtları (PIOP): Polinomlar (veya bunlardan türetilen kısıtlamalar) hakkındaki ifadeleri kanıtlamak için etkileşimli bir kanıt çerçevesi.

· Polinom Taahhüt Planı (PCS): Kanıtlayıcının, keşfedilmeden bir polinomun değerlendirmesi hakkında yalan söyleyememesini sağlar.

ZkVM, esasen geçerli bir yürütme izini bir kısıtlamalar sistemi olarak kodlar (genel olarak sanal makinenin kayıtları ve belleği doğru şekilde kullanmasını zorunlu kılar) ve ardından bu kısıtlamaların karşılandığını kanıtlamak için SNARK'ları uygular.

ZkVM gibi karmaşık bir sistemin hatasız olduğundan emin olmanın tek yolu resmi doğrulamadır. İşte güvenlik aşamalarının dökümü. 1. Aşama doğru protokole odaklanırken, 2. ve 3. Aşamalar doğru uygulamaya odaklanıyor.

Güvenlik Aşaması 1: Doğru Protokol

1. PIOP'un sağlamlığının resmi doğrulama kanıtı;

2. PCS'nin belirli kriptografik varsayımlar veya ideal modeller altında bağlayıcı olduğunun resmi doğrulama kanıtı;

3. PIOP ve PCS'yi birleştirerek elde edilen özlü argümanın, Fiat-Shamir kullanılırsa (gerektiğinde diğer kriptografik varsayımlarla zenginleştirilmiş) rastgele kehanet modelinde güvenli olduğunun resmi doğrulama kanıtı;

4. PIOP tarafından uygulanan kısıtlama sisteminin VM'nin semantiğine eşdeğer olduğunun resmi doğrulama kanıtı;

5. Yukarıdaki tüm parçaların, VM bayt koduyla belirtilen herhangi bir programı çalıştırmak için kullanılabilen tek, resmi olarak doğrulanmış güvenli bir SNARK kanıtına kapsamlı bir şekilde "yapıştırılması". Protokolün sıfır bilgiye ulaşmayı hedeflemesi durumunda, tanıklara ilişkin hassas bilgilerin sızdırılmamasını sağlamak için bu özelliğin de resmi olarak doğrulanması gerekir.

Özyineleme Uyarısı: Eğer zkVM yineleme kullanıyorsa, bu aşamanın tamamlanmış sayılması için o yinelemede yer alan her PIOP, taahhüt şeması ve kısıtlama sisteminin doğrulanması gerekir.

Güvenlik Aşaması 2: Doğrulayıcının Doğru Uygulanması

Resmi doğrulama, zkVM doğrulayıcısının gerçek uygulamasının (Rust, Solidity, vb.'de) Aşama 1'de doğrulanan protokolle eşleştiğini kanıtlar. Bunu başarmak, uygulanan protokolün sağlam bir protokol olmasını (sadece kağıt üzerinde bir tasarım veya Lean'de yazılmış verimsiz bir şartname olmamasını) sağlar.

2. Aşamanın yalnızca doğrulayıcı uygulamasına (ve kanıtlayıcıya değil) odaklanmasının iki nedeni vardır. Birincisi, doğrulayıcının doğru kullanımı sağlamlığı (yani doğrulayıcının herhangi bir yanlış ifadenin gerçekten doğru olduğuna inanmasını engellemek) sağlamak için yeterlidir. İkinci olarak, zkVM doğrulayıcı uygulaması, kanıtlayıcı uygulamasından bir büyüklük sırasına göre daha basittir.

Güvenlik Aşaması 3: Doğru Kanıtlayıcı Uygulaması

ZkVM kanıtlayıcısının gerçek uygulaması, hem 1. hem de 2. aşamada doğrulanan kanıt sistemi için kanıtları doğru bir şekilde üretir, yani resmen doğrulanır. Bu, bütünlüğü garanti eder, yani zkVM kullanan herhangi bir sistem, kanıtlanamayan ifadelerle "sıkışıp kalmaz". Kanıtlayıcı sıfır bilgiye ulaşmayı amaçlıyorsa bu özelliğin resmen doğrulanması gerekir.

Beklenen Zaman Çizelgesi

· 1. Aşama İlerlemesi:Önümüzdeki yıl kademeli başarılar (örn. ZKLib) bekleyebiliriz. Ancak hiçbir zkVM en az iki yıl boyunca Aşama 1'in gereksinimlerini tam olarak karşılayamayacaktır;

· Aşama 2 ve 3: Bu aşamalar Aşama 1'in bazı yönleriyle paralel olarak ilerletilebilir. Örneğin, bazı ekipler Plonk doğrulayıcısının uygulanmasının makaledeki protokolle uyuştuğunu gösterdiler (makalenin protokolünün kendisi tam olarak doğrulanmamış olsa bile). Yine de herhangi bir zkVM'nin dört yıldan kısa bir sürede -ve muhtemelen daha uzun bir sürede- 3. aşamaya ulaşmasını beklemiyorum.

Önemli Notlar: Fiat-Shamir Güvenliği ve Doğrulanmış Bayt Kodu

Fiat-Shamir dönüşümünün güvenliğiyle ilgili çözülmemiş araştırma sorularının olması önemli bir komplikasyondur. Her üç aşamada da Fiat-Shamir ve rastgele kahinler aşılmaz güvenliklerinin bir parçası olarak değerlendiriliyor, ancak gerçekte paradigmanın tamamının güvenlik açıkları olabilir. Bu durum, idealize edilmiş rastgele kehanet ile gerçekte kullanılan karma fonksiyonları arasındaki tutarsızlıktan kaynaklanmaktadır. En kötü ihtimalle, 2. aşamaya ulaşan bir sistemin daha sonra Fiat-Shamir sorunu nedeniyle tamamen güvensiz olduğu ortaya çıkabilir. Bu durum ciddi endişelere ve devam eden araştırmalara yol açtı. Bu tür güvenlik açıklarına karşı daha iyi koruma sağlamak için dönüşümün kendisini değiştirmemiz gerekebilir.

Özyineleme içermeyen sistemler teorik olarak daha sağlamdır çünkü bilinen bazı saldırılar, yinelemeli kanıtlarda kullanılanlara benzer devreleri içerir.

Bir diğer not da, bir bilgisayar programının doğru bir şekilde çalıştırıldığını (bayt kodunda belirtildiği gibi) kanıtlamanın, bayt kodunun kendisi hatalıysa sınırlı bir değere sahip olduğudur. Bu nedenle, zkVM'nin kullanışlılığı büyük ölçüde resmi olarak doğrulanmış bayt kodu üretme yöntemlerine bağlıdır - bu, bu makalenin kapsamı dışında kalan büyük bir zorluktur.

Kuantum sonrası güvenlik hakkında

En azından önümüzdeki beş yıl boyunca (ve muhtemelen daha uzun süre boyunca), kuantum bilgisayarlar ciddi bir tehdit oluşturmayacak, ancak güvenlik açıkları varoluşsal bir risktir. Dolayısıyla artık asıl odaklanılması gereken nokta, bu makalede ele alınan güvenlik ve performans aşamalarının sağlanması olmalıdır. Eğer bu güvenlik gereksinimlerini kuantum güvenli olmayan SNARK'ları kullanarak daha erken karşılayabilirsek, o zaman kuantum sonrası SNARK'lar ortaya çıkana veya insanlar kriptografik olarak önemli kuantum bilgisayarları konusunda ciddi endişeler duyana kadar bunu yapmalıyız.

ZkVM Performans Durumu

Şu anda, zkVM kanıtlayıcısının katlandığı genel gider faktörü, yerel yürütmenin maliyetinin yaklaşık 1 milyon katıdır. Eğer bir programın çalışması X çevrim alıyorsa, doğru yürütülmesinin kanıtlanmasının maliyeti yaklaşık olarak X çarpı 1 milyon CPU çevrimidir. Bir yıl önce de durum böyleydi, bugün de durum aynı.

Popüler anlatılar genellikle bu harcamaları kabul edilebilir görünen şekillerde tasvir ediyor. Örneğin: · "Tüm Ethereum ana ağı için kanıt üretmenin maliyeti yılda bir milyon dolardan azdır." · "Ethereum blok kanıtlarını düzinelerce GPU kümesi kullanarak neredeyse gerçek zamanlı olarak üretebiliriz." · "En son zkVM'miz selefinden 1000 kat daha hızlı." · Teknik olarak doğru olsa da, bu iddialar uygun bağlam olmadan yanıltıcı olabilir. Örneğin:

· Eski zkVM'den 1000 kat daha hızlı, ancak mutlak değerler açısından hala çok yavaş. Bu, işlerin ne kadar iyi olduğundan çok, ne kadar kötü olduğu hakkında daha çok şey anlatıyor.

· Ethereum ana ağının işleyebileceği hesaplama miktarının 10 kat artırılmasına yönelik öneriler oldu. Bu, mevcut zkVM performansını daha da yavaşlatacaktır.

· İnsanların "Ethereum blokları için neredeyse gerçek zamanlı hisse kanıtı" olarak adlandırdığı şey, birçok blok zinciri uygulamasının gerektirdiğinden çok daha yavaştır (örneğin, Optimism'in 2 saniyelik blok süresi, Ethereum'un 12 saniyelik blok süresinden çok daha hızlıdır).

· “Her zaman, hatasız çalışan düzinelerce GPU” kabul edilebilir canlılık garantilerine ulaşamaz.

· Ethereum ana ağındaki tüm aktiviteleri kanıtlamanın yıllık maliyeti bir milyon dolardan azdır; bu da bir Ethereum tam düğümünün hesaplamaları gerçekleştirmek için yılda yalnızca yaklaşık 25 dolara mal olduğu gerçeğini yansıtır.

Blockchain dışındaki uygulamalar için bu tür bir ek yükün çok yüksek olduğu açıktır. Hiçbir paralellik veya mühendislik bu kadar büyük bir yükü telafi edemez. ZkVM'nin yerel yürütmeye kıyasla 100.000 kat daha yavaş olmaması için temel bir başlangıç noktası belirlemeliyiz; bu sadece ilk adım olsa bile. Gerçek ana akım benimseme muhtemelen 10.000x veya daha az bir ek yük gerektirecektir.

Performans nasıl ölçülür

SNARK performansının üç ana bileşeni vardır:

· Altta yatan kanıt sisteminin içsel verimliliği.

· Uygulamaya özgü iyileştirmeler (örneğin ön derleme).

· Mühendislik ve donanım hızlandırma (örn. GPU, FPGA veya çok çekirdekli CPU).

Son ikisi pratik dağıtımlar için kritik öneme sahip olsa da, genel olarak herhangi bir kanıt sistemine uygulanırlar, bu nedenle temeldeki genel giderleri yansıtmayabilirler. Örneğin, zkEVM'ye GPU hızlandırma ve ön derlemenin eklenmesi, ön derleme olmaksızın yalnızca CPU tabanlı bir yaklaşıma kıyasla kolayca 50 kat hız artışı sağlayabilir; bu da, özünde daha az verimli bir sistemin, benzer şekilde cilalanmamış bir sisteme göre daha üstün görünmesini sağlayabilir.

Bu nedenle, aşağıda özel donanım ve ön derleme olmaksızın SNARK'ın performansına odaklanılmaktadır. Bu, genellikle tüm üç faktörü tek bir "başlık numarasına" toplayan mevcut kıyaslama metodolojilerinden farklıdır. Bu, bir elmasın değerini, doğal berraklığına göre değil, cilalanmasının ne kadar sürdüğüne göre değerlendirmekle aynı şeydir. Amacımız, genel amaçlı kanıt sistemlerinin doğasında bulunan ek yükü ortadan kaldırmak, topluluğun karmaşayı ortadan kaldırmasına ve kanıt sistemi tasarımında gerçek ilerlemeye odaklanmasına yardımcı olmaktır.

Performans Aşamaları

Aşağıda 5 performans başarısı kilometre taşı bulunmaktadır. Öncelikle, kanıtlayıcının CPU üzerindeki yükünü büyüklük sırasına göre azaltmamız gerekiyor. Ancak o zaman donanım yoluyla daha fazla azaltıma odaklanılmalıdır. Bellek kullanımının da iyileştirilmesi gerekiyor.

Aşağıdaki aşamaların hiçbirinde, geliştiricilerin gerekli performansı elde etmek için zkVM tabanlı özel kod kurmasına gerek yoktur. Geliştirici deneyimi zkVM'nin en büyük avantajıdır. Performans ölçütlerini karşılamak uğruna DevEx'i feda etmek zkVM'nin amacına aykırı olacaktır.

Bu metrikler kanıtlama maliyetlerine odaklanır. Ancak, sınırsız doğrulayıcı maliyetlerine izin verilirse (yani, kanıt boyutu veya doğrulama süresi için üst sınır yoksa), herhangi bir kanıtlayıcı metriği kolayca karşılanabilir. Dolayısıyla bir sistemin anlatılan evrelere uyum sağlayabilmesi için kanıt boyutu ve doğrulama süresi için maksimum değerlerin belirlenmesi gerekmektedir.

Performans Gereksinimleri

1. Aşama Gereksinimleri: “Makul ve önemsiz olmayan doğrulama maliyeti”:

· Kanıt boyutu: Kanıt boyutu tanık boyutundan küçük olmalıdır.

· Doğrulama süresi: Kanıtın doğrulanması, programı yerel olarak çalıştırmaktan (yani, doğruluk kanıtı olmadan hesaplamayı gerçekleştirmekten) daha yavaş olmamalıdır.

Bunlar basitlik için gereken en düşük gerekliliklerdir. Kanıt boyutunun ve doğrulama süresinin, tanığı doğrulayıcıya gönderip doğrulayıcının doğruluğunu doğrudan kontrol etmesinden daha kötü olmadığından emin olurlar.

2. Aşama ve sonrası gereksinimler:

· Maksimum kanıt boyutu: 256 KB.

· Maksimum doğrulama süresi: 16 milisaniye.

Bu kesintiler, daha yüksek doğrulama maliyetleri doğurabilecek yeni hızlı kanıt tekniklerine yer açmak için kasıtlı olarak büyüktür. Aynı zamanda, çok az sayıda projenin blok zincirlerine dahil etmeye istekli olduğu kadar pahalı olan kanıtları da dışlıyorlar.

Hız Aşaması 1

Tek iş parçacıklı kanıtlar, ön derlemelere güvenmeden, çeşitli uygulamalarda (sadece Ethereum bloklarını kanıtlamak değil) ölçüldüğünde, yerel yürütmeden 100.000 kata kadar daha yavaş olmalıdır.

Bunu bağlamına oturtmak için, modern bir dizüstü bilgisayarda saniyede yaklaşık 3 milyar döngüde çalışan bir RISC-V işlemini hayal edin. 1. aşamaya ulaşmak, aynı dizüstü bilgisayarda saniyede yaklaşık 30.000 RISC-V çevrimini (tek iş parçacığı) gösterebileceğiniz anlamına gelir. Ancak doğrulama maliyetinin yukarıda belirtildiği gibi "makul ve önemsiz olmayan" olması gerekir.

Hız Aşaması 2

Tek iş parçacıklı kanıtlar, yerel yürütmeden on bin kata kadar daha yavaş olmalıdır.

Alternatif olarak, bazı ümit verici SNARK yaklaşımları (özellikle ikili alanlara dayalı olanlar) mevcut CPU'lar ve GPU'lar tarafından engellendiği için, FPGA'ları (veya hatta ASIC'leri) kullanarak şu aşamaya ulaşabilirsiniz:

Bir FPGA'nın yerel hızda öykünebileceği RISC-V çekirdek sayısı;

RISC-V'nin (neredeyse) gerçek zamanlı yürütülmesini simüle etmek ve kanıtlamak için gereken FPGA sayısı.

İkincisinin birincisinden en fazla 10.000 kat fazla olması durumunda 2. Aşamaya geçmeye hak kazanırsınız. Standart bir CPU'da kanıt boyutu en fazla 256 KB, doğrulayıcı süresi ise en fazla 16 milisaniye olmalıdır.

Hız Aşaması 3

Hız Aşaması 2'ye ulaşmanın yanı sıra, resmi doğrulamanın otomatik sentezi ve ön derlemesi kullanılarak 1000x'ten daha az kanıt yüküne (çok çeşitli uygulamalar için) ulaşmak mümkündür. Özünde, kanıtların hızlandırılması için talimat seti her program için dinamik olarak özelleştirilebilir, ancak bu, kullanımı ve biçimsel olarak doğrulanması kolay bir şekilde yapılabilir.

Bellek Aşaması 1

1. Aşamanın hızı, kanıtlayıcı için 2 GB'tan az bellek gerektirirken (ve sıfır bilgiye ulaşarak) elde edildi.

Bu, birçok mobil cihaz veya tarayıcı için kritik öneme sahiptir ve dolayısıyla sayısız istemci tarafı zkVM kullanım örneğinin önünü açar. Müşteri onayı önemlidir çünkü telefonlarımız gerçek dünyayla sürekli bağlantımızı sağlar: konumumuzu, kimlik bilgilerimizi ve daha fazlasını takip ederler. Eğer kanıtın üretilmesi 1-2 GB'tan fazla bellek gerektiriyorsa, bu günümüz mobil cihazlarının çoğu için çok fazla olacaktır. İki noktanın açıklığa kavuşturulması gerekiyor:

· 2 GB alan sınırı büyük ifadeler için geçerlidir (yerel olarak çalışması için trilyonlarca CPU döngüsü gerektiren ifadeler). Sadece küçük ifadeler için alan sınırları uygulayan ispat sistemlerinin geniş uygulanabilirliği yoktur.

· Eğer kanıtlayıcı çok yavaşsa, kanıtlayıcı boyutunu 2 GB belleğin altında tutmak kolaydır. Yani, bellek aşaması 1'i önemsiz kılmak için, hız aşaması 1'in 2 GB alan sınırı içinde karşılanmasını gerekli kıldım.

Bellek Aşaması 2

Aşama 1'in hızı, 200 MB'tan daha az bellek kullanımıyla elde edilir (Bellek Aşaması 1'den 10 kat daha iyi).

Neden 2 GB'ın altına itiyorsunuz? Blockchain dışındaki bir örneği ele alalım: HTTPS üzerinden bir web sitesini her ziyaret ettiğinizde, kimlik doğrulama ve şifreleme için bir sertifika indirirsiniz. Bunun yerine web siteleri bu sertifikalara sahip olunduğunu gösteren zk kanıtları gönderebilirler. Büyük web siteleri saniyede milyonlarca bu tür kanıt üretebilir. Her bir kanıtın üretilmesi için 2 GB bellek gerekiyorsa, toplamda PB RAM'e ihtiyaç vardır. Blok zinciri dışı dağıtımlar için bellek kullanımının daha da azaltılması kritik öneme sahiptir.

Ön derleme: Son mil mi yoksa bir koltuk değneği mi?

ZkVM tasarımında, ön derlemeler, Keccak/SHA karma işlemi veya dijital imzalar için eliptik eğri grup işlemleri gibi belirli işlevler için tasarlanmış özel SNARK'ları (veya kısıtlama sistemlerini) ifade eder. Ethereum'da (ağır işlerin çoğunun Merkle karma ve imza denetimini içerdiği yerde), birkaç elle hazırlanmış ön derleme kanıtlayıcı yükünü azaltabilir. Ancak bunlara koltuk değneği olarak güvenmek SNARK'ları olması gereken yere ulaştırmaz. Nedeni şu: · Çoğu uygulama için (hem blok zincirinin içinde hem de dışında) hâlâ çok yavaş: Karma ve imza ön derlemesine rağmen, mevcut zkVM, çekirdek kanıt sistemindeki verimsizlikler nedeniyle hâlâ çok yavaş (hem blok zincirinin içinde hem de dışında).

· Güvenlik Hataları:Resmi olarak doğrulanmamış el yazısıyla yazılmış ön derlemelerin, büyük ihtimalle felaket düzeyinde güvenlik hatalarına yol açabilecek hatalarla dolu olduğu söylenebilir.

· Zayıf geliştirici deneyimi: Günümüzde çoğu zkVM'de yeni bir ön derleme eklemek, her özellik için manuel olarak bir kısıtlama sistemi yazmak anlamına gelir; bu da esasen 1960'lar tarzı bir iş akışına dönüş anlamına gelir. Mevcut ön derlemeler olsa bile, geliştiricilerin her ön derlemeyi çağıracak şekilde kodlarını yeniden düzenlemeleri gerekir. Artımlı performans peşinde koşarken güvenlik ve geliştirici deneyimini de göz önünde bulundurarak optimizasyon yapmalıyız. Böyle yapmak, performansın olması gerektiği kadar iyi olmadığını kanıtlar.

· G/Ç Yükü ve RAM Yok: Ön derlemeler, kripto ağırlıklı görevler için performansı artırabilirken, giriş/çıkış geçerken önemli bir yük oluşturdukları ve RAM kullanamadıkları için daha çeşitli iş yükleri için anlamlı hızlanmalar sağlamayabilir. Blockchain bağlamında bile, Ethereum gibi monolitik bir L1'in ötesine geçtiğiniz anda (örneğin, bir dizi çapraz zincir köprüsü kurmak istediğinizde), farklı karma işlevleri ve imza şemalarıyla karşı karşıya kalırsınız. Sorun üstüne soruna tekrar tekrar ön derleme yapmak ölçeklenemez ve büyük bir güvenlik riski oluşturur.

Tüm bu nedenlerden dolayı, ilk önceliğimiz temeldeki zkVM'nin verimliliğini artırmak olmalıdır. En iyi zkVM'yi üreten teknikler aynı zamanda en iyi ön derleyicileri de üretir. Uzun vadede ön derlemelerin önemli olmaya devam edeceğine inanıyorum, ancak yalnızca otomatik olarak sentezlenmeleri ve resmi olarak doğrulanmaları durumunda. Bu şekilde, zkVM'nin geliştirici deneyimi avantajları korunurken aynı zamanda felaket düzeyindeki güvenlik risklerinden de kaçınılmış olur. Bu görüş 3. hız kademesinde de yansıtılmıştır.

Beklenen Zaman Çizelgesi

Bu yılın ilerleyen zamanlarında bir avuç zkVM'nin hız aşaması 1'e ve bellek aşaması 1'e ulaşmasını bekliyorum. Önümüzdeki iki yıl içinde Hız Fazı 2'ye de ulaşacağımızı düşünüyorum ama henüz ortaya çıkmamış bazı yeni fikirler olmadan oraya ulaşabileceğimiz belli değil. Geri kalan aşamaların (Hız Aşaması 3 ve Bellek Aşaması 2) tamamlanmasının birkaç yıl alacağını tahmin ediyorum.

Özet

Bu yazıda zkVM güvenliğinin ve performansının aşamalarını ayrı ayrı tanımlasam da, zkVM'nin bu yönleri tamamen bağımsız değildir. ZkVM'de daha fazla güvenlik açığı keşfedildikçe, bazılarının yalnızca önemli performans düşüşleriyle düzeltileceğini bekliyoruz. ZkVM güvenli aşama 2'ye ulaşana kadar performans askıya alınmalıdır.

zkVM'ler sıfır bilgi kanıtlarını gerçekten yaygınlaştırma potansiyeline sahipler, ancak bunlar hala emekleme aşamasındadır ve güvenlik zorlukları ve büyük performans yüküyle doludur. Abartılı reklam ve pazarlama propagandası gerçek ilerlemenin değerlendirilmesini zorlaştırıyor. Güvenlik ve performansa ilişkin net kilometre taşlarını belirleyerek dikkat dağıtıcı unsurları ortadan kaldıracak bir yol haritası sunmayı umuyoruz. Oraya varacağız ama bunun için zamana ve sürekli çabaya ihtiyacımız olacak.

Orijinal bağlantı