Yazar: Justin Thaler Kaynak: a16z Çeviri: Good Europe, Golden Finance
Sıfır Bilgi Sanal Makinesi (zkVMs), SNARK'ların halka açık hale gelmesini sağlamayı amaçlar, böylece SNARK uzmanlığı olmayan kişiler bile belirli bir girişte (veya tanıklıkta) belirli bir programın doğru bir şekilde çalıştığını kanıtlayabilir. Temel avantajı geliştirici deneyimindedir, ancak mevcut zkVMs hala güvenlik ve performans açısından büyük zorluklarla karşı karşıyadır. Eğer zkVMs vaatlerini gerçekleştirmek istiyorsa, tasarımcıların bu engelleri aşmaları gerekmektedir. Bu makale, zkVM gelişiminin muhtemel aşamalarını tartışacak ve bu sürecin tamamlanması birkaç yıl sürebilir - bu hızlı bir şekilde gerçekleştirilebileceğine inanmayın.
Karşılaşılan Zorluklar
Güvenlik açısından, zkVMs yüksek derecede karmaşık bir yazılım projesidir ve hala hatalarla doludur.
Performans açısından, bir programın doğru bir şekilde çalıştığını kanıtlamak, çoğu uygulamanın gerçek dünyada dağıtılmasını yüz binlerce kez yavaşlatarak geçici olarak mümkün olmayan hale getirebilir.
Bununla birlikte, blok zinciri endüstrisinde birçok ses hala zkVM'lerin hemen dağıtılabileceğini hatta bazı projelerin yüksek hesaplama maliyetleri ödediğini ve zincirdeki aktiviteler için sıfır bilgi kanıtları ürettiğini iddia ediyor. Ancak, zkVM'lerin hala birçok açığı olduğundan, bu uygulama aslında sadece pahalı bir kılıktan ibarettir, sistem SNARK tarafından korunuyormuş gibi görünmesini sağlar, ancak gerçekte ya izin kontrolüne bağımlıdır ya da daha da kötüsü - saldırı riskine karşı savunmasızdır.
Gerçek durum şudur ki, gerçekten güvenli ve verimli bir zkVM'nin inşasına hala yıllar var. Bu makale, zkVM'nin gerçek ilerlemesini takip etmemize, spekülasyonu zayıflatmamıza ve topluluğu gerçek teknolojik ilerlemelere odaklanmaya yönlendirmemize yardımcı olmak için bir dizi belirli ve aşamalı hedef önermektedir.
Güvenlik Gelişim Aşaması
Arka Plan
SNARK tabanlı zkVM'ler genellikle iki temel bileşeni içerir:
Polinomlu Etkileşimli Oracle Kanıtı (Polynomial Interactive Oracle Proof, PIOP): Polinom (veya polinom türetilmiş kısıtlamalar) için etkileşimli kanıt çerçevesi için kullanılır.
zkVM, sanal makinenin kayıtları ve belleğinın doğru kullanımını sağlayarak etkili yürütme izini kısıtlama sistemine kodlayarak ve ardından bu kısıtlamaların karşılanma durumunu SNARK ile kanıtlayarak gerçekleştirir.
Bu kadar karmaşık bir sistemde, zkVM'nin hiçbir hata içermediğinden emin olmanın tek yolu, formal doğrulamadır. **Aşağıda, zkVM'nin güvenliğiyle ilgili farklı aşamalar bulunmaktadır; ilk aşama protokol doğruluğuna odaklanmaktadır, ikinci ve üçüncü aşamalar ise uygulama doğruluğuna odaklanmaktadır.
Güvenlik Aşaması 1: Doğru Protokol
PIOP güvenilirlik için resmi doğrulama kanıtı;
PCS, bazı şifreleme varsayımları veya ideal modeller altında kısıtlayıcı şekilde doğrulama kanıtı sağlar;
Eğer Fiat-Shamir kullanılıyorsa, PIOP ve PCS'nin birleştirilmesiyle elde edilen kısa kanıt rastgele kahin modelinde güvenli resmi doğrulama ispatıdır (gerektiğinde diğer şifreleme varsayımlarını kullanarak güçlendirilebilir).
PIOP'un uyguladığı kısıtlama sistemi, VM'nin semantiğine eşit olan bir doğrulama kanıtıdır;
Yukarıdaki tüm bu parçaları tek bir, formal olarak doğrulanmış güvenli SNARK kanıtı haline getirin ve VM bytecode tarafından belirtilen herhangi bir programı çalıştırmak için kullanın. Protokolün zero-knowledge'i gerçekleştirmesi amaçlanıyorsa, bu özelliğin de formal olarak doğrulanması gerekmektedir, böylece tanıklarla ilgili hassas bilgilerin sızdırılmayacağından emin olun.
Eğer zkVM recursive kullanıyorsa, o zaman PIOP, taahhüt planları ve kısıtlama sistemleri ile ilgili olan rekürsif aşamada tümü doğrulanmalıdır, aksi takdirde bu alt aşama tamamlanmış sayılmaz.
Aşama 2 Güvenlik: Doğru Doğrulayıcı Uygulaması
Bu aşama, zkVM doğrulayıcı'nın gerçek uygulamasının (Rust, Solidity vb.) formal doğrulamasının yapılmasını gerektirir, böylece ilk aşamada doğrulanan protokole uygun olduğundan emin olunur. Bu aşamayı tamamlamak, zkVM uygulamasının ve teorik tasarımının uyumlu olduğu anlamına gelir ve sadece bir kağıt üzerindeki güvenlik protokolü veya Lean gibi dillerle yazılmış verimsiz bir spesifikasyon olmadığı anlamına gelir.
Doğrulayıcıları yalnızca odaklamak neden sadece ispatlayıcılara odaklanmamak için başlıca iki neden vardır: İlk olarak, doğrulayıcıların doğru olduğundan emin olmak zkVM ispat sisteminin bütünlüğünü sağlar (yani: doğrulayıcıların yanıltılmayacağından ve yanlış bir ispatı kabul etmeyeceğinden emin olun). İkincisi, zkVM doğrulayıcı uygulaması ispatlayıcı uygulamasından birkaç kat daha basittir, doğrulayıcının doğruluğu daha kısa sürede sağlanabilir.
Aşam 3: Doğru ispatlayıcı gerçekleştirme
Bu aşamada, zkVM kanıtlama'nın gerçek uygulamasının formal doğrulaması yapılmalıdır, böylece zaten doğrulanmış olan birinci ve ikinci aşamadaki kanıt sistemlerinin kanıtlarının doğru bir şekilde oluşturulduğundan emin olunur. Bu aşamanın amacı tamamlanma dır, yani: zkVM kullanan herhangi bir sistem, yasal bir ifadeyi kanıtlayamadığı için kilitlenmez. zkVM'nin sıfır bilgi özelliğine sahip olması gerekiyorsa, kanıtın tanıklar hakkında herhangi bir bilgi sızdırmayacağından emin olmak için formal doğrulama sağlanmalıdır.
Tahmini Zaman Çizelgesi
1. Aşama İlerlemesi: Gelecek yıl bazı ilerlemeler bekleyebiliriz (örneğin, ZKLib bu tür bir çabadır). Ancak en az iki yıl içinde hiçbir zkVM, 1. aşama gereksinimlerini tam olarak karşılayamayacak.
Aşama 2 ve Aşama 3: Bu aşamalar, Aşama 1'in bazı yönleriyle aynı anda ilerleyebilir. Örneğin, bazı ekipler, Plonk doğrulayıcısının uygulamasının makaledeki protokolle uyumlu olduğunu kanıtladı (makalenin protokolünün kendisi tam olarak doğrulanmamış olabilir). Bununla birlikte, herhangi bir zkVM'in 3. aşamaya dört yıldan az bir süre içinde ulaşacağını tahmin etmiyorum - hatta daha uzun sürebilir.
Anahtar Dikkat Noktaları: Fiat-Shamir güvenliği ve doğrulanmış bytecode
Birincil karmaşıklık sorunu, Fiat-Shamir dönüşümünün güvenliğinin hala çözülmemiş araştırma sorunları bulunduğudur. Tüm üç güvenlik aşaması, Fiat-Shamir'i ve rastgele kâhin'i mutlak güvenli olarak kabul eder, ancak aslında tüm paradigmada bir açık olabilir. Bu, rastgele kâhinin idealize modeli ile gerçek kullanılan karma fonksiyon arasındaki farktan kaynaklanmaktadır.
En kötü durumda, zaten Güvenlik Aşaması 2'ye ulaşmış bir sistem, Fiat-Shamir ile ilgili sorunlar nedeniyle tamamen güvensiz bulunabilir. Bu oldukça dikkatli incelenmesi gereken bir konudur ve araştırmalar devam etmelidir. Muhtemelen Fiat-Shamir dönüşümünü kendisi üzerinde değiştirmemiz gerekebilir, bu tür açıklıklara karşı daha iyi savunma sağlamak için.
Recursion kullanmayan sistemler teoride daha güvenlidir, çünkü bilinen bazı saldırılar, kullanılan devrelerin rekürsif kanıtlarda kullanılan devrelere benzer olmasıyla ilgilidir. Ancak bu risk hala çözülememiş temel bir sorundur.
Başka bir dikkat edilmesi gereken konu, zkVM'nin belirli bir hesaplama programının (bytecode tarafından belirlenir) doğru bir şekilde yürütüldüğünü kanıtlıyor olması durumunda bile, ancak eğer bytecode kendisi hatalıysa, o zaman bu kanıtın değeri son derece sınırlı olacaktır. Bu nedenle, zkVM'nin pratik kullanımı büyük ölçüde formal doğrulama sürecinden geçen bytecode'un nasıl oluşturulduğuna bağlıdır ve bu zorluk son derece büyüktür ve bu yazının tartışma kapsamının ötesine geçmektedir.
Kuantum Güvenliği Hakkında
Gelecekte en az 5 yıl boyunca (hatta daha uzun süre) kuantum bilgisayarlar ciddi bir tehdit oluşturmayacak, ancak yazılım açıkları hayati öneme sahip bir sorundur. Bu nedenle, mevcut öncelikli görev, bu makalede belirtilen güvenlik ve performans hedeflerini gerçekleştirmektir. Eğer kuantum karşıtı olmayan SNARK'lar bu hedeflere daha hızlı ulaşabilirse, onları öncelikli olarak kullanmalıyız. Kuantum karşıtı SNARK'lar gelişmeye yetişirse veya gerçek tehdit oluşturabilecek kuantum bilgisayarlarının ortaya çıkacağına dair işaretler belirirse, o zaman geçiş yapmayı düşünebiliriz.
Özel güvenlik seviyesi
100-bit Klasik Güvenlik herhangi bir SNARK'ın değerli varlıkları korumak için kullandığı en düşük standarttır (ancak bazı sistemler hala bu düşük standarta ulaşamamıştır). Bununla birlikte, bu kabul edilemez ve genellikle standart kriptografi uygulamaları 128-bit güvenlik veya daha yükseğini gerektirir. Eğer SNARK'ın performansı gerçekten standartları karşılıyorsa, güvenliği düşürmek için performansı artırmamalıyız.
Performans Aşaması
Mevcut Durum
Şu anda, zkVM doğrulayıcısının hesaplama maliyeti yaklaşık olarak yerel yürütmenin 1.000.000 katıdır. Başka bir deyişle, bir programın yerel yürütümü X CPU döngüsü gerektiriyorsa, doğru yürütümünün üretilmesi yaklaşık olarak X × 1.000.000 CPU döngüsü gerektirir. Bu durum bir yıl önce olduğu gibi bugün de geçerlidir (bazı yanlış anlamalar olmasına rağmen).
Bazı yaygın ifadeler endüstride yanıltıcı olabilir, örneğin:
"Ethereum ana ağı için bir belge oluşturma maliyeti yılda 100 milyon doların altında."
"Ethereum blok zincirinin neredeyse gerçek zamanlı olarak kanıt ürettiğimiz, sadece birkaç on GPU'ya ihtiyacımız var."
"Yeni zkVM'ımızın önceki nesilden 1000 kat daha hızlı olduğunu söylemek mümkün."
Ancak, bu ifadeler, bağlam olmadan yanıltıcı olabilir:
• Eski sürümden 1000 kat daha hızlı olan zkVM hala çok yavaş olabilir, bu daha çok geçmişin ne kadar kötü olduğunu gösterir, şu an ne kadar iyi olduğunu değil.
• Ethereum ana ağının hesaplama gücü gelecekte 10 kat artabilir bu, mevcut zkVM'nin talebi karşılamak için çok geride kalmasına neden olacaktır.
• Sözde "neredeyse anlık" kanıt oluşturma, birçok blockchain uygulamasında hala fazla yavaş (örneğin, Optimism'in blok süresi 2 saniye iken Ethereum'un 12 saniyeden çok daha hızlıdır).
• "Birkaç on GPU uzun süre 24/7 çalıştırıldığında", yeterli performans garantisi sağlayamaz.
• Bu genellikle 1MB'den büyük kanıt boyutları için oluşturulan zamanların çoğu uygulamalar için fazla büyük olabilir.
• "Yıllık maliyeti 100 milyon doların altında olan sadece **Ethereum tam düğüm yılda sadece yaklaşık 25 dolarlık hesaplama yapıyor".
Blockchain dışındaki uygulama senaryoları için bu tür hesaplama maliyeti açıkça çok yüksektir. Ne kadar paralel hesaplama veya mühendislik iyileştirme yapılırsa yapılsın, bu kadar büyük bir hesaplama maliyetini telafi etmek mümkün değildir.
Temel hedefimiz olarak belirlememiz gereken şey, performans maliyetinin yerel yürütmeden 100,000 kat fazla olmamasıdır. Ancak bu, sadece ilk adım olmaya devam ediyor. Gerçek büyük ölçekli ana akım uygulamaları gerçekleştirmek istiyorsak, maliyeti yerel yürütmeden 10,000 kat veya daha azına düşürmemiz gerekebilir.
Performans ölçümü
SNARK performansı üç ana bileşenden oluşur:
Alt katmanı ispat sisteminin sağlamlığı ve verimliliği.
Belirli uygulamalar için optimize edilmiş (örneğin önişlemeli).
Mühendislik ve donanım hızlandırma (örneğin GPU, FPGA veya çoklu çekirdekli CPU).
Although (2) and (3) are crucial for actual deployment, they are applicable to any proof system, so they may not necessarily reflect improvements in basic overhead. For example, adding GPU acceleration and precompilation to zkEVM can easily increase the speed by 50 times compared to relying solely on the CPU - this may make a system that is inherently less efficient appear superior to another system that has not undergone the same optimization.
Bu nedenle, bu makalede özel donanım ve önceden derlenmiş olmadan SNARK'ın temel performansı ölçülmektedir. Bu, mevcut referans test yönteminden farklıdır, çünkü genellikle üç faktörü tek bir 'genel bir değer' olarak birleştirir. Bu, bir elması parlatma süresine göre değerlendirmek gibi, doğal berraklığını değerlendirmek değildir.
Amacımız, genel kanıt sistemlerinin doğuştan gelen maliyetlerini izole etmek, henüz derinlemesine araştırılmamış teknolojilere giriş bariyerini azaltmak ve topluluğun gerçek ilerlemelere odaklanmasına yardımcı olmak için girişim faktörlerini ortadan kaldırmaktır.
Performans Aşaması
Aşağıda sunduğum beş performans aşamasının kilometre taşları. İlk olarak, CPU'daki doğrulayıcı maliyetini önemli ölçüde azaltmamız gerekiyor, ardından maliyeti daha da azaltmak için donanıma güvenmemiz gerekiyor. Aynı zamanda, bellek kullanımının da iyileştirilmesi gerekmektedir.
Tüm aşamalarda, geliştiricilerin kodu zkVM'nin performansı için ayarlamaması gerekir. Geliştirici deneyimi zkVM'nin temel avantajıdır. Performans standartlarını karşılamak için DevEx'i feda etmek, sadece standart testinin anlamını yitirmekle kalmaz, aynı zamanda zkVM'nin amacına aykırıdır.
Bu metriklerin odak noktası genellikle kanıtlayıcı maliyeti üzerinedir. Bununla birlikte, doğrulayıcıların **maliyetinin sınırsız bir şekilde artmasına izin verilirse (yani kanıt boyutu veya doğrulama süresinde sınır olmaksızın artış olursa), herhangi bir kanıtlayıcı metriği kolayca karşılanabilir. Bu nedenle, aşağıdaki aşamaların gereksinimlerini karşılamak için maksimum kanıt boyutunu ve maksimum doğrulama süresini aynı anda sınırlamak zorunludur.
Aşama 1 Gereksinimi: 'Makul Olmayan Doğrulama Maliyeti'
• Proof Size: Witness size must be less than proof size.
• Doğrulama Zamanı : Doğrulama işleminin hızı, programın doğal yürütme hızından daha yavaş olmamalıdır (yani, hesaplamanın doğrudan yürütülmesinden daha yavaş olmamalıdır).
Bu, kanıt boyutu ve doğrulama süresinin bir doğrulayıcıya doğrudan tanıklık göndermek ve doğrudan kontrol etmelerinden daha kötü olmayacağını sağlamak için en az gereksinimli basitlik gereksinimleridir.
Aşama 2 ve üzeri
• Maksimum Proof Boyutu：256 KB。
• Maksimum Doğrulama Zamanı: 16 milisaniye.
Bu sınırlar bilinçli olarak geniş bir şekilde ayarlanmıştır, böylece yeni ve hızlı kanıt teknolojisine uyum sağlarlar, hatta daha yüksek doğrulama maliyetleri getirebilirler. Aynı zamanda, bu sınırlar, blok zincirinde kullanmak isteyen neredeyse hiç proje olmayan yüksek maliyetli kanıtları dışlar.
Hız Aşaması 1
Tek iplikli ispat hızının yerel yürütmeden 100.000 kat daha yavaş olmaması gerekir (sadece Ethereum blok kanıtı değil, çeşitli uygulamalara uygundur) ve önceden derlemeye dayanmamalıdır.
Özellikle bir modern dizüstü bilgisayarda çalışan RISC-V işlemcinin hızı yaklaşık olarak 30 milyar döngü/saniye olduğunu varsayalım, bu durumda Aşama 1'e ulaşmak demek ki bu dizüstü bilgisayarın 30.000 RISC-V döngü/saniye hızında bir kanıt üretebilmesi (tek iş parçacığı).
Doğrulayıcı maliyeti, önceden tanımlanmış 'makul olmayan doğrulama maliyeti' standardını karşılamalıdır.
Hız Aşaması 2
Tek iş parçacığı kanıtı hızının yerel yürütmeden 10.000 kat daha yavaş olmaması gerekir。
Ya da, bazı umut verici SNARK yöntemlerinin (özellikle ikili alan SNARK) mevcut CPU ve GPU kısıtlamalarından etkilendiği düşünülürse, bu aşamayı FPGA (hatta ASIC) ile karşılamak mümkün olabilir:
FPGA tarafından simüle edilen RISC-V çekirdek sayısını orijinal hızda hesaplayın.
RISC-V yürütme (nearly real-time) için gereken FPGA sayısını hesaplayın, simüle edin ve kanıtlayın.
Eğer (2) miktarı (1) in 10,000 katından azsa, aşama 2 karşılanır.
• Belge Boyutu : Maksimum 256 KB.
• Doğrulama Süresi: Standart CPU'da en fazla 16 milisaniye.
Hız Aşaması 3
Hız aşaması 2'ye ulaşıldıktan sonra, 1000×'e kadar olan kanıt maliyetini (çeşitli uygulamalar için geçerli) gerçekleştirmek ve otomatik sentez ve formal doğrulama ile ön derlemeyi kullanmak gereklidir. Temel olarak, her program için komut kümesini dinamik olarak özelleştirerek kanıt oluşturmayı hızlandırın, ancak kullanım kolaylığı ve formal doğrulamayı garanti altına alın. (**Neden ön derlemenin çifte uçlu bir kılıç olduğu ve neden 'el yazması' ön derlemenin sürdürülebilir bir yöntem olmadığı hakkında daha fazla bilgi için bir sonraki bölüme bakınız.)
Bellek Aşaması 1
2 GB bellek altındaHız Aşaması 1'e ulaşmak ve aynı zamanda zero knowledge gereksinimlerini karşılamak. Bu aşama, mobil cihazlar veya tarayıcılar için hayati öneme sahiptir ve büyük miktarda istemci zkVM kullanımı için kapıları açar. Örneğin, akıllı telefonlar konum gizliliği, kimlik doğrulama vb. için kullanılabilir. Kanıt oluşturmanın 1-2 GB belleği aşması durumunda çoğu mobil cihaz çalışamaz.
İki önemli açıklama:
Büyük ölçekli hesaplama bile olsa (on binlerce CPU döngüsü gerektiren doğrudan yürütme), kanıt sisteminin 2 GB bellek sınırını koruması gerekir; aksi takdirde uygunluk sınırlı kalır.
Eğer kanıt hızı çok yavaşsa, 2 GB'lık bellek sınırını korumak çok kolaydır. Bu nedenle, bellek aşamasının 1 anlamlı hale gelmesi için hız aşamasının 1'e 2 GB bellek sınırı içinde ulaşılması gerekir.
Bellek Aşaması 2
200 MB bellekten az ile Hız Aşaması 1'e ulaşın (bellek aşaması 1'den 10 kat daha hızlı).
Neden 200 MB'a düşürmek istiyorsunuz? Bir blockchain olmayan senaryo düşünün: HTTPS web sitesine eriştiğinizde, kimlik doğrulama ve şifreleme sertifikalarını indirirsiniz. Web sitesi bu sertifikaları zk kanıtlarıyla göndermeye başlarsa, büyük web siteleri saniyede milyonlarca kanıt oluşturabilir. Her kanıt için 2 GB bellek gerekiyorsa, hesaplama kaynakları PB seviyesine ulaşacaktır, açıkça uygulanamaz. Bu nedenle, bellek kullanımını daha da azaltmak, blockchain olmayan uygulamalar için son derece önemlidir.
**Ön derleme: Son mil mi, koltuk değneği mi? **
Ön derleme, belirli fonksiyonlar için (hash, eliptik eğri imzası gibi) optimize edilmiş SNARK kısıtlama sistemi anlamına gelir. Ethereum'da, ön derleme Merkle hash ve imza doğrulamasının maliyetini azaltabilir, ancak ön derlemeye aşırı derecede bağımlı olmak SNARK'ın temel verimliliğini gerçekten artırmaz.
Ön derleme sorunu
1. Hala Yavaş：Hash ve imza ön derlemesi kullanılsa bile, zkVM hala blok zinciri içinde ve dışında temel kanıt sistemlerinin verimsizliği sorununu yaşamaktadır.
2. Güvenlik açığı：Eğer el ile ön derleme yapılmamışsa, hemen hemen her zaman güvenlik açıkları bulunur ve bu da felaketle sonuçlanabilir.
3. Geliştirici Deneyimi Zayıf: Şu anda, birçok zkVM geliştiricinin kısıtlama sistemi el ile yazması gerekiyor, 1960'ların programlama yöntemlerine benzer şekilde, geliştirme deneyimini ciddi şekilde etkiliyor.
4. Test Yanıltıcıdır: Eğer bir test, belirli bir ön derleme optimize etmeye bağlıysa, insanların dikkatini optimize edilmiş el yapımı kısıtlı sistemlere değil, SNARK tasarımının kendisini geliştirmeye odaklanmalarına neden olabilir.
5. I/O masrafı ve RAM'sız erişimÖn derleme yoğun şifreleme görevlerinin performansını artırabilir, ancak daha çeşitli iş yükleri için anlamlı bir hızlandırma sağlayamayabilirler çünkü giriş/çıkış iletimi sırasında büyük miktarda masraf oluştururlar ve RAM kullanamazlar.
Blockchain ortamında olsanız bile, Ethereum gibi tek bir L1'i aşarsanız (örneğin, bir dizi cross-chain köprü oluşturmak istiyorsanız), farklı hash fonksiyonları ve imza şemalarıyla karşılaşacaksınız. Bu sorunu çözmek için sürekli olarak ön derleme yapmak, hem ölçeklenebilir değil hem de büyük güvenlik riskleri taşır.
Gerçekten, önceden derlenmiş kodların uzun vadede hala çok önemli olduğuna inanıyorum, ancak sadece otomatik olarak sentezlendikten ve resmi olarak doğrulandıktan sonra bu kadar önemli hale gelirler. Bu şekilde, zkVM geliştiricilerinin deneyim avantajını koruyabiliriz ve aynı zamanda felaket risklerinden kaçınabiliriz. Bu görüş aşama 3'te yansımaktadır.
Beklenen Zaman Çizelgesi
Benim beklentim, zkVM'nin bu yılın ilerleyen dönemlerinde Hız Aşaması 1 ve Bellek Aşaması 1'e ulaşması. İlerleyen iki yıl içinde Hız Aşaması 2'yi de gerçekleştirebileceğimizi düşünüyorum, ancak henüz bu hedefe yeni bir araştırma yolu olmadan ulaşılıp ulaşılamayacağı belirsiz.
Kalan aşamaların (Hız Aşaması 3 ve Bellek Aşaması 2) gerçekleşmesinin birkaç yıl alması bekleniyor.
Bu metin, zkVM'nin güvenlik ve performans aşamalarını ayrı ayrı listelediği halde, bu ikisi tamamen bağımsız değildir. zkVM'deki açıkların sürekli olarak ortaya çıkmasıyla, bazı açıkların giderilmesinin kaçınılmaz olarak performansta önemli bir düşüşe neden olacağını öngörüyorum. Bu nedenle, zkVM'nin Güvenlik Aşaması 2'ye ulaşmadan önce, performans test sonuçları geçici veri olarak kabul edilmelidir.
zkVM, sıfır bilgi kanıtlarının gerçekten yaygınlaşmasında büyük potansiyele sahip, ancak şu anda hala erken aşamada - güvenlik zorluklarıyla dolu ve ciddi performans engelleri var. Piyasa spekülasyonu ve pazarlama faaliyetleri gerçek ilerlemeyi ölçmeyi zorlaştırıyor. Net güvenlik ve performans kilometre taşlarıyla, sisleri dağıtan bir yol haritası sunmayı umuyorum. Sonuçta hedefe ulaşacağız, ancak bu zaman ve araştırma ve mühendislikte sürekli çaba gerektiriyor.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
a16z: Yüksek Verimli ve Güvenli Yol Arayışında zkVM
Yazar: Justin Thaler Kaynak: a16z Çeviri: Good Europe, Golden Finance
Sıfır Bilgi Sanal Makinesi (zkVMs), SNARK'ların halka açık hale gelmesini sağlamayı amaçlar, böylece SNARK uzmanlığı olmayan kişiler bile belirli bir girişte (veya tanıklıkta) belirli bir programın doğru bir şekilde çalıştığını kanıtlayabilir. Temel avantajı geliştirici deneyimindedir, ancak mevcut zkVMs hala güvenlik ve performans açısından büyük zorluklarla karşı karşıyadır. Eğer zkVMs vaatlerini gerçekleştirmek istiyorsa, tasarımcıların bu engelleri aşmaları gerekmektedir. Bu makale, zkVM gelişiminin muhtemel aşamalarını tartışacak ve bu sürecin tamamlanması birkaç yıl sürebilir - bu hızlı bir şekilde gerçekleştirilebileceğine inanmayın.
Karşılaşılan Zorluklar
Güvenlik açısından, zkVMs yüksek derecede karmaşık bir yazılım projesidir ve hala hatalarla doludur.
Performans açısından, bir programın doğru bir şekilde çalıştığını kanıtlamak, çoğu uygulamanın gerçek dünyada dağıtılmasını yüz binlerce kez yavaşlatarak geçici olarak mümkün olmayan hale getirebilir.
Bununla birlikte, blok zinciri endüstrisinde birçok ses hala zkVM'lerin hemen dağıtılabileceğini hatta bazı projelerin yüksek hesaplama maliyetleri ödediğini ve zincirdeki aktiviteler için sıfır bilgi kanıtları ürettiğini iddia ediyor. Ancak, zkVM'lerin hala birçok açığı olduğundan, bu uygulama aslında sadece pahalı bir kılıktan ibarettir, sistem SNARK tarafından korunuyormuş gibi görünmesini sağlar, ancak gerçekte ya izin kontrolüne bağımlıdır ya da daha da kötüsü - saldırı riskine karşı savunmasızdır.
Gerçek durum şudur ki, gerçekten güvenli ve verimli bir zkVM'nin inşasına hala yıllar var. Bu makale, zkVM'nin gerçek ilerlemesini takip etmemize, spekülasyonu zayıflatmamıza ve topluluğu gerçek teknolojik ilerlemelere odaklanmaya yönlendirmemize yardımcı olmak için bir dizi belirli ve aşamalı hedef önermektedir.
Güvenlik Gelişim Aşaması
Arka Plan
SNARK tabanlı zkVM'ler genellikle iki temel bileşeni içerir:
Polinomlu Etkileşimli Oracle Kanıtı (Polynomial Interactive Oracle Proof, PIOP): Polinom (veya polinom türetilmiş kısıtlamalar) için etkileşimli kanıt çerçevesi için kullanılır.
Polinom Taahhüt Şeması (Polynomial Commitment Scheme, PCS): Kanıtlayıcının çoklu terimin değerlendirmesini sahtekarlık yapmadan tespit edemediğinden emin olun.
zkVM, sanal makinenin kayıtları ve belleğinın doğru kullanımını sağlayarak etkili yürütme izini kısıtlama sistemine kodlayarak ve ardından bu kısıtlamaların karşılanma durumunu SNARK ile kanıtlayarak gerçekleştirir.
Bu kadar karmaşık bir sistemde, zkVM'nin hiçbir hata içermediğinden emin olmanın tek yolu, formal doğrulamadır. **Aşağıda, zkVM'nin güvenliğiyle ilgili farklı aşamalar bulunmaktadır; ilk aşama protokol doğruluğuna odaklanmaktadır, ikinci ve üçüncü aşamalar ise uygulama doğruluğuna odaklanmaktadır.
Güvenlik Aşaması 1: Doğru Protokol
Eğer zkVM recursive kullanıyorsa, o zaman PIOP, taahhüt planları ve kısıtlama sistemleri ile ilgili olan rekürsif aşamada tümü doğrulanmalıdır, aksi takdirde bu alt aşama tamamlanmış sayılmaz.
Aşama 2 Güvenlik: Doğru Doğrulayıcı Uygulaması
Bu aşama, zkVM doğrulayıcı'nın gerçek uygulamasının (Rust, Solidity vb.) formal doğrulamasının yapılmasını gerektirir, böylece ilk aşamada doğrulanan protokole uygun olduğundan emin olunur. Bu aşamayı tamamlamak, zkVM uygulamasının ve teorik tasarımının uyumlu olduğu anlamına gelir ve sadece bir kağıt üzerindeki güvenlik protokolü veya Lean gibi dillerle yazılmış verimsiz bir spesifikasyon olmadığı anlamına gelir.
Doğrulayıcıları yalnızca odaklamak neden sadece ispatlayıcılara odaklanmamak için başlıca iki neden vardır: İlk olarak, doğrulayıcıların doğru olduğundan emin olmak zkVM ispat sisteminin bütünlüğünü sağlar (yani: doğrulayıcıların yanıltılmayacağından ve yanlış bir ispatı kabul etmeyeceğinden emin olun). İkincisi, zkVM doğrulayıcı uygulaması ispatlayıcı uygulamasından birkaç kat daha basittir, doğrulayıcının doğruluğu daha kısa sürede sağlanabilir.
Aşam 3: Doğru ispatlayıcı gerçekleştirme
Bu aşamada, zkVM kanıtlama'nın gerçek uygulamasının formal doğrulaması yapılmalıdır, böylece zaten doğrulanmış olan birinci ve ikinci aşamadaki kanıt sistemlerinin kanıtlarının doğru bir şekilde oluşturulduğundan emin olunur. Bu aşamanın amacı tamamlanma dır, yani: zkVM kullanan herhangi bir sistem, yasal bir ifadeyi kanıtlayamadığı için kilitlenmez. zkVM'nin sıfır bilgi özelliğine sahip olması gerekiyorsa, kanıtın tanıklar hakkında herhangi bir bilgi sızdırmayacağından emin olmak için formal doğrulama sağlanmalıdır.
Tahmini Zaman Çizelgesi
1. Aşama İlerlemesi: Gelecek yıl bazı ilerlemeler bekleyebiliriz (örneğin, ZKLib bu tür bir çabadır). Ancak en az iki yıl içinde hiçbir zkVM, 1. aşama gereksinimlerini tam olarak karşılayamayacak.
Aşama 2 ve Aşama 3: Bu aşamalar, Aşama 1'in bazı yönleriyle aynı anda ilerleyebilir. Örneğin, bazı ekipler, Plonk doğrulayıcısının uygulamasının makaledeki protokolle uyumlu olduğunu kanıtladı (makalenin protokolünün kendisi tam olarak doğrulanmamış olabilir). Bununla birlikte, herhangi bir zkVM'in 3. aşamaya dört yıldan az bir süre içinde ulaşacağını tahmin etmiyorum - hatta daha uzun sürebilir.
Anahtar Dikkat Noktaları: Fiat-Shamir güvenliği ve doğrulanmış bytecode
Birincil karmaşıklık sorunu, Fiat-Shamir dönüşümünün güvenliğinin hala çözülmemiş araştırma sorunları bulunduğudur. Tüm üç güvenlik aşaması, Fiat-Shamir'i ve rastgele kâhin'i mutlak güvenli olarak kabul eder, ancak aslında tüm paradigmada bir açık olabilir. Bu, rastgele kâhinin idealize modeli ile gerçek kullanılan karma fonksiyon arasındaki farktan kaynaklanmaktadır.
En kötü durumda, zaten Güvenlik Aşaması 2'ye ulaşmış bir sistem, Fiat-Shamir ile ilgili sorunlar nedeniyle tamamen güvensiz bulunabilir. Bu oldukça dikkatli incelenmesi gereken bir konudur ve araştırmalar devam etmelidir. Muhtemelen Fiat-Shamir dönüşümünü kendisi üzerinde değiştirmemiz gerekebilir, bu tür açıklıklara karşı daha iyi savunma sağlamak için.
Recursion kullanmayan sistemler teoride daha güvenlidir, çünkü bilinen bazı saldırılar, kullanılan devrelerin rekürsif kanıtlarda kullanılan devrelere benzer olmasıyla ilgilidir. Ancak bu risk hala çözülememiş temel bir sorundur.
Başka bir dikkat edilmesi gereken konu, zkVM'nin belirli bir hesaplama programının (bytecode tarafından belirlenir) doğru bir şekilde yürütüldüğünü kanıtlıyor olması durumunda bile, ancak eğer bytecode kendisi hatalıysa, o zaman bu kanıtın değeri son derece sınırlı olacaktır. Bu nedenle, zkVM'nin pratik kullanımı büyük ölçüde formal doğrulama sürecinden geçen bytecode'un nasıl oluşturulduğuna bağlıdır ve bu zorluk son derece büyüktür ve bu yazının tartışma kapsamının ötesine geçmektedir.
Kuantum Güvenliği Hakkında
Gelecekte en az 5 yıl boyunca (hatta daha uzun süre) kuantum bilgisayarlar ciddi bir tehdit oluşturmayacak, ancak yazılım açıkları hayati öneme sahip bir sorundur. Bu nedenle, mevcut öncelikli görev, bu makalede belirtilen güvenlik ve performans hedeflerini gerçekleştirmektir. Eğer kuantum karşıtı olmayan SNARK'lar bu hedeflere daha hızlı ulaşabilirse, onları öncelikli olarak kullanmalıyız. Kuantum karşıtı SNARK'lar gelişmeye yetişirse veya gerçek tehdit oluşturabilecek kuantum bilgisayarlarının ortaya çıkacağına dair işaretler belirirse, o zaman geçiş yapmayı düşünebiliriz.
Özel güvenlik seviyesi
100-bit Klasik Güvenlik herhangi bir SNARK'ın değerli varlıkları korumak için kullandığı en düşük standarttır (ancak bazı sistemler hala bu düşük standarta ulaşamamıştır). Bununla birlikte, bu kabul edilemez ve genellikle standart kriptografi uygulamaları 128-bit güvenlik veya daha yükseğini gerektirir. Eğer SNARK'ın performansı gerçekten standartları karşılıyorsa, güvenliği düşürmek için performansı artırmamalıyız.
Performans Aşaması
Mevcut Durum
Şu anda, zkVM doğrulayıcısının hesaplama maliyeti yaklaşık olarak yerel yürütmenin 1.000.000 katıdır. Başka bir deyişle, bir programın yerel yürütümü X CPU döngüsü gerektiriyorsa, doğru yürütümünün üretilmesi yaklaşık olarak X × 1.000.000 CPU döngüsü gerektirir. Bu durum bir yıl önce olduğu gibi bugün de geçerlidir (bazı yanlış anlamalar olmasına rağmen).
Bazı yaygın ifadeler endüstride yanıltıcı olabilir, örneğin:
"Ethereum ana ağı için bir belge oluşturma maliyeti yılda 100 milyon doların altında."
"Ethereum blok zincirinin neredeyse gerçek zamanlı olarak kanıt ürettiğimiz, sadece birkaç on GPU'ya ihtiyacımız var."
"Yeni zkVM'ımızın önceki nesilden 1000 kat daha hızlı olduğunu söylemek mümkün."
Ancak, bu ifadeler, bağlam olmadan yanıltıcı olabilir:
• Eski sürümden 1000 kat daha hızlı olan zkVM hala çok yavaş olabilir, bu daha çok geçmişin ne kadar kötü olduğunu gösterir, şu an ne kadar iyi olduğunu değil.
• Ethereum ana ağının hesaplama gücü gelecekte 10 kat artabilir bu, mevcut zkVM'nin talebi karşılamak için çok geride kalmasına neden olacaktır.
• Sözde "neredeyse anlık" kanıt oluşturma, birçok blockchain uygulamasında hala fazla yavaş (örneğin, Optimism'in blok süresi 2 saniye iken Ethereum'un 12 saniyeden çok daha hızlıdır).
• "Birkaç on GPU uzun süre 24/7 çalıştırıldığında", yeterli performans garantisi sağlayamaz.
• Bu genellikle 1MB'den büyük kanıt boyutları için oluşturulan zamanların çoğu uygulamalar için fazla büyük olabilir.
• "Yıllık maliyeti 100 milyon doların altında olan sadece **Ethereum tam düğüm yılda sadece yaklaşık 25 dolarlık hesaplama yapıyor".
Blockchain dışındaki uygulama senaryoları için bu tür hesaplama maliyeti açıkça çok yüksektir. Ne kadar paralel hesaplama veya mühendislik iyileştirme yapılırsa yapılsın, bu kadar büyük bir hesaplama maliyetini telafi etmek mümkün değildir.
Temel hedefimiz olarak belirlememiz gereken şey, performans maliyetinin yerel yürütmeden 100,000 kat fazla olmamasıdır. Ancak bu, sadece ilk adım olmaya devam ediyor. Gerçek büyük ölçekli ana akım uygulamaları gerçekleştirmek istiyorsak, maliyeti yerel yürütmeden 10,000 kat veya daha azına düşürmemiz gerekebilir.
Performans ölçümü
SNARK performansı üç ana bileşenden oluşur:
Alt katmanı ispat sisteminin sağlamlığı ve verimliliği.
Belirli uygulamalar için optimize edilmiş (örneğin önişlemeli).
Mühendislik ve donanım hızlandırma (örneğin GPU, FPGA veya çoklu çekirdekli CPU).
Although (2) and (3) are crucial for actual deployment, they are applicable to any proof system, so they may not necessarily reflect improvements in basic overhead. For example, adding GPU acceleration and precompilation to zkEVM can easily increase the speed by 50 times compared to relying solely on the CPU - this may make a system that is inherently less efficient appear superior to another system that has not undergone the same optimization.
Bu nedenle, bu makalede özel donanım ve önceden derlenmiş olmadan SNARK'ın temel performansı ölçülmektedir. Bu, mevcut referans test yönteminden farklıdır, çünkü genellikle üç faktörü tek bir 'genel bir değer' olarak birleştirir. Bu, bir elması parlatma süresine göre değerlendirmek gibi, doğal berraklığını değerlendirmek değildir.
Amacımız, genel kanıt sistemlerinin doğuştan gelen maliyetlerini izole etmek, henüz derinlemesine araştırılmamış teknolojilere giriş bariyerini azaltmak ve topluluğun gerçek ilerlemelere odaklanmasına yardımcı olmak için girişim faktörlerini ortadan kaldırmaktır.
Performans Aşaması
Aşağıda sunduğum beş performans aşamasının kilometre taşları. İlk olarak, CPU'daki doğrulayıcı maliyetini önemli ölçüde azaltmamız gerekiyor, ardından maliyeti daha da azaltmak için donanıma güvenmemiz gerekiyor. Aynı zamanda, bellek kullanımının da iyileştirilmesi gerekmektedir.
Tüm aşamalarda, geliştiricilerin kodu zkVM'nin performansı için ayarlamaması gerekir. Geliştirici deneyimi zkVM'nin temel avantajıdır. Performans standartlarını karşılamak için DevEx'i feda etmek, sadece standart testinin anlamını yitirmekle kalmaz, aynı zamanda zkVM'nin amacına aykırıdır.
Bu metriklerin odak noktası genellikle kanıtlayıcı maliyeti üzerinedir. Bununla birlikte, doğrulayıcıların **maliyetinin sınırsız bir şekilde artmasına izin verilirse (yani kanıt boyutu veya doğrulama süresinde sınır olmaksızın artış olursa), herhangi bir kanıtlayıcı metriği kolayca karşılanabilir. Bu nedenle, aşağıdaki aşamaların gereksinimlerini karşılamak için maksimum kanıt boyutunu ve maksimum doğrulama süresini aynı anda sınırlamak zorunludur.
Aşama 1 Gereksinimi: 'Makul Olmayan Doğrulama Maliyeti'
• Proof Size: Witness size must be less than proof size.
• Doğrulama Zamanı : Doğrulama işleminin hızı, programın doğal yürütme hızından daha yavaş olmamalıdır (yani, hesaplamanın doğrudan yürütülmesinden daha yavaş olmamalıdır).
Bu, kanıt boyutu ve doğrulama süresinin bir doğrulayıcıya doğrudan tanıklık göndermek ve doğrudan kontrol etmelerinden daha kötü olmayacağını sağlamak için en az gereksinimli basitlik gereksinimleridir.
Aşama 2 ve üzeri
• Maksimum Proof Boyutu：256 KB。
• Maksimum Doğrulama Zamanı: 16 milisaniye.
Bu sınırlar bilinçli olarak geniş bir şekilde ayarlanmıştır, böylece yeni ve hızlı kanıt teknolojisine uyum sağlarlar, hatta daha yüksek doğrulama maliyetleri getirebilirler. Aynı zamanda, bu sınırlar, blok zincirinde kullanmak isteyen neredeyse hiç proje olmayan yüksek maliyetli kanıtları dışlar.
Hız Aşaması 1
Tek iplikli ispat hızının yerel yürütmeden 100.000 kat daha yavaş olmaması gerekir (sadece Ethereum blok kanıtı değil, çeşitli uygulamalara uygundur) ve önceden derlemeye dayanmamalıdır.
Özellikle bir modern dizüstü bilgisayarda çalışan RISC-V işlemcinin hızı yaklaşık olarak 30 milyar döngü/saniye olduğunu varsayalım, bu durumda Aşama 1'e ulaşmak demek ki bu dizüstü bilgisayarın 30.000 RISC-V döngü/saniye hızında bir kanıt üretebilmesi (tek iş parçacığı).
Doğrulayıcı maliyeti, önceden tanımlanmış 'makul olmayan doğrulama maliyeti' standardını karşılamalıdır.
Hız Aşaması 2
Tek iş parçacığı kanıtı hızının yerel yürütmeden 10.000 kat daha yavaş olmaması gerekir。
Ya da, bazı umut verici SNARK yöntemlerinin (özellikle ikili alan SNARK) mevcut CPU ve GPU kısıtlamalarından etkilendiği düşünülürse, bu aşamayı FPGA (hatta ASIC) ile karşılamak mümkün olabilir:
FPGA tarafından simüle edilen RISC-V çekirdek sayısını orijinal hızda hesaplayın.
RISC-V yürütme (nearly real-time) için gereken FPGA sayısını hesaplayın, simüle edin ve kanıtlayın.
Eğer (2) miktarı (1) in 10,000 katından azsa, aşama 2 karşılanır.
• Belge Boyutu : Maksimum 256 KB.
• Doğrulama Süresi: Standart CPU'da en fazla 16 milisaniye.
Hız Aşaması 3
Hız aşaması 2'ye ulaşıldıktan sonra, 1000×'e kadar olan kanıt maliyetini (çeşitli uygulamalar için geçerli) gerçekleştirmek ve otomatik sentez ve formal doğrulama ile ön derlemeyi kullanmak gereklidir. Temel olarak, her program için komut kümesini dinamik olarak özelleştirerek kanıt oluşturmayı hızlandırın, ancak kullanım kolaylığı ve formal doğrulamayı garanti altına alın. (**Neden ön derlemenin çifte uçlu bir kılıç olduğu ve neden 'el yazması' ön derlemenin sürdürülebilir bir yöntem olmadığı hakkında daha fazla bilgi için bir sonraki bölüme bakınız.)
Bellek Aşaması 1
2 GB bellek altında Hız Aşaması 1'e ulaşmak ve aynı zamanda zero knowledge gereksinimlerini karşılamak. Bu aşama, mobil cihazlar veya tarayıcılar için hayati öneme sahiptir ve büyük miktarda istemci zkVM kullanımı için kapıları açar. Örneğin, akıllı telefonlar konum gizliliği, kimlik doğrulama vb. için kullanılabilir. Kanıt oluşturmanın 1-2 GB belleği aşması durumunda çoğu mobil cihaz çalışamaz.
İki önemli açıklama:
Büyük ölçekli hesaplama bile olsa (on binlerce CPU döngüsü gerektiren doğrudan yürütme), kanıt sisteminin 2 GB bellek sınırını koruması gerekir; aksi takdirde uygunluk sınırlı kalır.
Eğer kanıt hızı çok yavaşsa, 2 GB'lık bellek sınırını korumak çok kolaydır. Bu nedenle, bellek aşamasının 1 anlamlı hale gelmesi için hız aşamasının 1'e 2 GB bellek sınırı içinde ulaşılması gerekir.
Bellek Aşaması 2
200 MB bellekten az ile Hız Aşaması 1'e ulaşın (bellek aşaması 1'den 10 kat daha hızlı).
Neden 200 MB'a düşürmek istiyorsunuz? Bir blockchain olmayan senaryo düşünün: HTTPS web sitesine eriştiğinizde, kimlik doğrulama ve şifreleme sertifikalarını indirirsiniz. Web sitesi bu sertifikaları zk kanıtlarıyla göndermeye başlarsa, büyük web siteleri saniyede milyonlarca kanıt oluşturabilir. Her kanıt için 2 GB bellek gerekiyorsa, hesaplama kaynakları PB seviyesine ulaşacaktır, açıkça uygulanamaz. Bu nedenle, bellek kullanımını daha da azaltmak, blockchain olmayan uygulamalar için son derece önemlidir.
**Ön derleme: Son mil mi, koltuk değneği mi? **
Ön derleme, belirli fonksiyonlar için (hash, eliptik eğri imzası gibi) optimize edilmiş SNARK kısıtlama sistemi anlamına gelir. Ethereum'da, ön derleme Merkle hash ve imza doğrulamasının maliyetini azaltabilir, ancak ön derlemeye aşırı derecede bağımlı olmak SNARK'ın temel verimliliğini gerçekten artırmaz.
Ön derleme sorunu
1. Hala Yavaş：Hash ve imza ön derlemesi kullanılsa bile, zkVM hala blok zinciri içinde ve dışında temel kanıt sistemlerinin verimsizliği sorununu yaşamaktadır.
2. Güvenlik açığı：Eğer el ile ön derleme yapılmamışsa, hemen hemen her zaman güvenlik açıkları bulunur ve bu da felaketle sonuçlanabilir.
3. Geliştirici Deneyimi Zayıf: Şu anda, birçok zkVM geliştiricinin kısıtlama sistemi el ile yazması gerekiyor, 1960'ların programlama yöntemlerine benzer şekilde, geliştirme deneyimini ciddi şekilde etkiliyor.
4. Test Yanıltıcıdır: Eğer bir test, belirli bir ön derleme optimize etmeye bağlıysa, insanların dikkatini optimize edilmiş el yapımı kısıtlı sistemlere değil, SNARK tasarımının kendisini geliştirmeye odaklanmalarına neden olabilir.
5. I/O masrafı ve RAM'sız erişimÖn derleme yoğun şifreleme görevlerinin performansını artırabilir, ancak daha çeşitli iş yükleri için anlamlı bir hızlandırma sağlayamayabilirler çünkü giriş/çıkış iletimi sırasında büyük miktarda masraf oluştururlar ve RAM kullanamazlar.
Blockchain ortamında olsanız bile, Ethereum gibi tek bir L1'i aşarsanız (örneğin, bir dizi cross-chain köprü oluşturmak istiyorsanız), farklı hash fonksiyonları ve imza şemalarıyla karşılaşacaksınız. Bu sorunu çözmek için sürekli olarak ön derleme yapmak, hem ölçeklenebilir değil hem de büyük güvenlik riskleri taşır.
Gerçekten, önceden derlenmiş kodların uzun vadede hala çok önemli olduğuna inanıyorum, ancak sadece otomatik olarak sentezlendikten ve resmi olarak doğrulandıktan sonra bu kadar önemli hale gelirler. Bu şekilde, zkVM geliştiricilerinin deneyim avantajını koruyabiliriz ve aynı zamanda felaket risklerinden kaçınabiliriz. Bu görüş aşama 3'te yansımaktadır.
Beklenen Zaman Çizelgesi
Benim beklentim, zkVM'nin bu yılın ilerleyen dönemlerinde Hız Aşaması 1 ve Bellek Aşaması 1'e ulaşması. İlerleyen iki yıl içinde Hız Aşaması 2'yi de gerçekleştirebileceğimizi düşünüyorum, ancak henüz bu hedefe yeni bir araştırma yolu olmadan ulaşılıp ulaşılamayacağı belirsiz.
Kalan aşamaların (Hız Aşaması 3 ve Bellek Aşaması 2) gerçekleşmesinin birkaç yıl alması bekleniyor.
Bu metin, zkVM'nin güvenlik ve performans aşamalarını ayrı ayrı listelediği halde, bu ikisi tamamen bağımsız değildir. zkVM'deki açıkların sürekli olarak ortaya çıkmasıyla, bazı açıkların giderilmesinin kaçınılmaz olarak performansta önemli bir düşüşe neden olacağını öngörüyorum. Bu nedenle, zkVM'nin Güvenlik Aşaması 2'ye ulaşmadan önce, performans test sonuçları geçici veri olarak kabul edilmelidir.
zkVM, sıfır bilgi kanıtlarının gerçekten yaygınlaşmasında büyük potansiyele sahip, ancak şu anda hala erken aşamada - güvenlik zorluklarıyla dolu ve ciddi performans engelleri var. Piyasa spekülasyonu ve pazarlama faaliyetleri gerçek ilerlemeyi ölçmeyi zorlaştırıyor. Net güvenlik ve performans kilometre taşlarıyla, sisleri dağıtan bir yol haritası sunmayı umuyorum. Sonuçta hedefe ulaşacağız, ancak bu zaman ve araştırma ve mühendislikte sürekli çaba gerektiriyor.