Güvenli ve verimli zkVM'ler için yol: İlerlemenin takip edilmesi
Orijinal yazar: a16z kripto
Orijinal metin çevirisi: Golem, Odaily Daily Planet
zkVM (Zero Knowledge Virtual Machine) SNARK'ı genelleştirmeyi taahhüt eder, bu da herkesin (özellikle SNARK uzmanlığı olmayanlar dahil) belirli bir giriş (veya şahitlik) üzerinde doğru bir şekilde çalıştıklarını kanıtlayabileceği anlamına gelir. Temel avantajları geliştirici deneyimindedir, ancak şu anda hem güvenlik hem de performans açısından büyük zorluklarla karşı karşıyadırlar. zkVM'nin taahhütlerini yerine getirmek için tasarımcıların bu zorlukları aşmaları gerekmektedir. Bu makalede, zkVM geliştirme olası aşamalarını listeledim ve bu aşamaların tamamlanması birkaç yıl sürebilir.
Challenge
Güvenlik açısından, zkVM yüksek derecede karmaşık bir yazılım projesidir ve hala hatalarla doludur. Performans açısından, doğrulama programının doğru şekilde çalıştığını kanıtlama hızı yerel çalışmaya göre onbinlerce kat daha yavaş olabilir, bu da çoğu uygulamanın şu anda gerçek dünyada dağıtılamamasına neden olmaktadır.
Bu gerçek zorluklar varken, blok zinciri endüstrisindeki çoğu şirket, zkVM'yi hemen dağıtılabilecek bir şey olarak tasvir ediyor. Aslında, bazı projeler, zincirdeki etkinliği kanıtlamak için büyük miktarda hesaplama maliyeti ödedi. Ancak zkVM hala eksik olduğundan, bu sadece SNARK koruması altında olduğunu taklit etmek için pahalı bir yol, aslında ya izinle korunur ya da daha kötüsü, kolayca saldırıya uğrar.
Güvenli ve yüksek performanslı zkVM'nin gerçekleşmesine birkaç yıl var. Bu makale, zkVM'nin ilerlemesini izlemek için aşamalı hedefler serisi öneriyor - bu hedefler spekülasyonu ortadan kaldırabilir ve topluluğun gerçek ilerlemeye odaklanmasına yardımcı olabilir.
Güvenlik Aşaması
SNARK tabanlı zkVM genellikle iki ana bileşeni içerir:
· Polinom İnteraktif Oracle Kanıtı (PIOP)( : Polinom hakkındaki ifadeleri (veya onlardan sonuç çıkarılan kısıtlamaları) kanıtlamak için etkileşimli bir kanıt çerçevesi.
· Polinom taahhüt şeması )PCS(: Kanıtlayıcıların polinom değerlendirmesinde yalan söyleyememesini gizli tutar.
zkVM, etkin yürütmenin özünü izleme kodunu kısıtlama sistemine kodlamak olarak ele alır - genel olarak, bunlar virtual makinenin kayıtlarını ve belleği doğru şekilde kullanmasını zorlar - ardından bu kısıtlamaların yerine getirildiğini kanıtlamak için SNARK uygular.
ZkVM gibi karmaşık bir sistemde hata olmamasının tek yolu, formal doğrulamadır. Güvenlik aşamaları aşağıda belirtilmiştir. Aşama 1, doğru protokole odaklanırken, Aşama 2 ve Aşama 3, doğru uygulamaya odaklanmaktadır.
Güvenlik Aşaması 1: Doğru Protokol
1、PIOP güvenilirlik için resmi doğrulama kanıtı;
2、PCS bazı şifreleme varsayımları veya ideal modeller altında zorlayıcı bir şekilde doğrulanmış kanıtı sahiptir；
3、Eğer Fiat-Shamir kullanılıyorsa, PIOP ve PCS tarafından elde edilen kısa kanıt, rastgele kehanet modelinde güvenli resmi doğrulama kanıtıdır (gerekirse diğer şifreleme varsayımlarını güçlendirmek için).
4、PIOP uygulanan kısıtlama sistemi, VM'nin semantiğine eşit olan bir doğrulama kanıtıdır;
5、Tüm bu bölümleri tek bir, formal doğrulanmış güvenli SNARK kanıtı olarak 'yapıştırmak' için, VM bytecode tarafından belirtilen herhangi bir programa çalıştırılması için. Protokol zero-knowledge'ı gerçekleştirmeyi amaçlıyorsa, bu özelliği de formal doğrulamak için, şahitlerle ilgili hassas bilgilerin sızdırılmayacağından emin olmak gereklidir.
Rekürsif Uyarı: zkVM'nin rekürsif olarak kullanılması durumunda, bu aşamayı tamamlanmış kabul etmek için her PIOP, taahhüt planı ve taahhüt sistemi ile ilişkili herhangi bir yerin doğrulanması gerekir.
Güvenlik Aşaması 2: Doğru Doğrulayıcı Uygulaması
Formal doğrulama, zkVM doğrulayıcısının gerçek uygulamasının (Rust, Solidity vb. kullanılarak) 1. aşama doğrulaması protokolüyle eşleştiğini kanıtlar. Bu, uygulamanın protokolünün yalnızca mantıklı değil, aynı zamanda düşük verimli spesifikasyonlarla Lean gibi yazılmış olabileceğinden emin olur.
aşama, doğrulayıcı uygulamasına (kanıtlayıcı değil) odaklanmanın nedeni iki yönlüdür. İlk olarak, doğrulayıcıyı doğru bir şekilde kullanmak, güvenilirliği sağlamak için yeterlidir (yani doğrulayıcının herhangi bir yanlış beyana gerçekte gerçek olduğuna inanamamasını sağlamak). İkincisi, zkVM doğrulayıcı uygulaması, prover uygulamasından birkaç kez daha basittir.
Güvenlik Aşaması 3: Doğru Zamanlayıcı Uygulaması
zkVM onaylayıcısının gerçek uygulaması, Aşama 1 ve Aşama 2'de doğrulanan kanıtlama sisteminin kanıtlama sistemini doğru bir şekilde oluşturduğunda resmi olarak doğrulanır. Bu, bütünlüğü sağlar, yani zkVM kullanan herhangi bir sistem, kanıtlanamayan ifadeler tarafından "takılıp kalmaz". Kanıtlayıcı sıfır bilgiyi uygulamak niyetindeyse, bu özelliğin resmi olarak doğrulanması gerekir.
Tahmini Zaman Çizelgesi
· Aşama 1 İlerleme: Gelecek yıl aşamalı başarılar elde etmeyi bekleyebiliriz (örneğin ZKLib). Ancak en az iki yıl içinde hiçbir zkVM Aşama 1 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ı takımlar, Plonk doğrulayıcısının uygulamasının makaledeki protokolle uyumlu olduğunu kanıtlamıştır (makalenin protokolünün kendisi tamamen doğrulanmamış olabilir). Yine de, herhangi bir zkVM'in üçüncü aşamaya dört yıldan az bir sürede ulaşmayı beklemiyorum - ve belki daha uzun bir süre.
Önemli Notlar: Fiat-Shamir güvenliği ve doğrulanmış bayt kodu
Birincil karmaşık faktör, Fiat-Shamir dönüşümü etrafında çözülememiş araştırma sorunlarının varlığıdır. Tüm üç aşama, Fiat-Shamir'i ve rasgele kehanetçileri kusursuz güvenliklerinin bir parçası olarak görür, ancak aslında tüm paradigmada zayıflıklar olabilir. Bu, rasgele kehanetçi ile idealize edilmiş ve gerçek kullanılan karma işlevi arasındaki farklılıklardan kaynaklanmaktadır. En kötü durumda, Fiat-Shamir sorunundan dolayı, 2. aşamaya ulaşıldığında sistem tamamen güvensiz bulunabilir. Bu ciddi endişelere ve sürekli araştırmalara neden olmuştur. Bu tür zayıflıklara karşı daha iyi korunmak için dönüşümü kendisini değiştirmemiz gerekebilir.
Teoride, geriye dönük olmayan sistemler, bazı bilinen saldırılarla ilgili devrelerin, kullanılan devrelerle benzer olması nedeniyle daha sağlamdır.
Başka bir dikkat çekici husus, eğer bayt kodunda kusurlar varsa, bu durumda bilgisayar programının doğru şekilde çalıştığı (bayt kodu aracılığıyla belirtildiği şekilde) kanıtlanmış olsa bile, değeri sınırlı olacaktır. Bu nedenle, zkVM'nin kullanılabilirliği büyük ölçüde formal doğrulama için bayt kodu üretme yöntemine bağlıdır - bu, bu yazının kapsamının ötesinde büyük bir zorluk oluşturur.
Gelecek Kuantum Sonrası Dönem Güvenliği
En az beş yıl boyunca (muhtemelen daha uzun bir süre), kuantum bilgisayarlar ciddi bir tehdit oluşturmayacak, ancak zayıflıklar bir hayatta kalma riskidir. Bu nedenle, şu anki ana odak noktası, bu makalede tartışılan güvenlik ve performans gereksinimlerini karşılamaktır. Eğer kuantum güvenli olmayan SNARK'ı bu güvenlik gereksinimlerini daha hızlı karşılayabilirsek, o zaman bunu yapmalıyız, sonrasında kuantum SNARK yetişene veya insanlar şifreleme ile ilgili kuantum bilgisayarların ortaya çıkmasından ciddi endişe duyana kadar.
zkVM 的性能现状
Şu anda, zkVM belgelendirici tarafından üretilen harcama katsayısı, yerel yürütme maliyetinin 1000000 katına yaklaşıyor. Eğer bir programın çalışması için X döngüye ihtiyacı varsa, doğru bir şekilde yürütmenin maliyeti yaklaşık olarak X kez 1000000 CPU döngüsüdür. Bir yıl önce durum buydu ve bugün hala öyle.
Popüler anlatılar genellikle bu tür harcamaları kabul edilebilir bir şekilde tanımlamak için duyulabilir.
·「Ethereum ana ağı için yıllık üretim maliyeti milyon doların altında.」
·「Biz neredeyse onlarca GPU'dan oluşan bir küme kullanarak Ethereum blok kanıtını gerçek zamanlı olarak üretebiliriz.」
·「Bizim en yeni zkVM, öncüsüne göre 1000 kat daha hızlı.」
Teknik olarak bu ifadeler doğru olsa da, uygun bir bağlam olmadan yanıltıcı olabilir. Örneğin:
Eski sürümden zkVM 1000 kat daha hızlı, ancak mutlak hız hala çok yavaş. Bu daha çok şeyin ne kadar kötü olduğunu gösteriyor, ne kadar iyi olduğunu değil.
· Birisi Ethereum ana ağının işlem hacmini 10 kat artırmayı önerdi. Bu, mevcut zkVM performansını daha yavaş hale getirecektir.
· İnsanların söylediği 'Ethereum bloğun neredeyse gerçek zamanlı kanıtı', birçok blok zinciri uygulamasının gerektirdiğinden çok daha yavaş (örneğin, Optimism'in blok süresi 2 saniyedir, Ethereum'un 12 saniyelik blok süresinden çok daha hızlı).
· 'Onlarca GPU sürekli çalışırken, hiçbir hata olmaksızın' kabul edilebilir bir canlılık garantisi sağlayamaz.
· Ethereum ana ağındaki tüm faaliyetlerin yansıtılması için yılda milyon dolar harcamak, Ethereum tam düğümünün yılda sadece yaklaşık 25 dolar harcaması gerektiğini kanıtlamak için yeterli değildir.
Blockchain dışındaki uygulamalar için, bu açıkça çok yüksek maliyetli. Herhangi bir paralelleştirme veya mühendislik, bu kadar büyük maliyeti telafi edemez. Yerel yürütme ile karşılaştırıldığında, zkVM hızının en fazla 100.000 kat yavaşladığı temel bir referans olmalıdır - bu sadece ilk adım olsa bile. Gerçek ana akım benimseme, yaklaşık 10.000 kat veya daha düşük maliyet gerektirebilir.
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ü optimizasyon (örneğin derleme öncesi).
· Mühendislik ve donanım hızlandırma (örneğin GPU, FPGA veya çoklu çekirdekli CPU).
Her ne kadar son iki unsur gerçek uygulama için hayati öneme sahip olsa da, genellikle herhangi bir ispat sistemi için geçerli oldukları için temel maliyetleri yansıtmak zorunda olmadıklarını belirtmek önemlidir. Örneğin, GPU hızlandırma ve ön derleme eklemek zkEVM içinde 50 kat hızlanmaya kolayca yol açabilir, bu da saf CPU tabanlı derleme olmayan yöntemden çok daha hızlıdır - bu, temelde daha az verimli olan bir sistemi aynı şekilde cilalanmamış bir sistemden daha iyi göstermeye yeterli olabilir.
Bu nedenle, SNARK'ın performansı özel donanım ve derleme olmadan aşağıda vurgulanmaktadır. Bu, mevcut referans test yönteminden farklıdır, çünkü genellikle bu üç faktörü tek bir 'başlık numarası' olarak özetler. Bu, bir elmasın saflığı yerine cilalama süresine göre elmasın değerlendirilmesine benzer. Amacımız genel kanıt sistemlerinin içsel maliyetini ortadan kaldırmaktır - topluluğun karışıklık faktörlerini ortadan kaldırmasına yardımcı olmak ve kanıt sistem tasarımının gerçek ilerlemesine odaklanmaktır.
Performans Aşaması
Aşağıda 5 performans kilometretaşı var. İlk olarak, CPU üzerindeki doğrulayıcı maliyetini birkaç kat azaltmamız gerekiyor. Ancak böylece odak donanım yoluyla daha fazla azaltmaya çevrilmelidir. Ayrıca bellek kullanım oranını artırmak zorundayız.
Tüm aşamalarda, geliştiricilerin gerekli performansı elde etmek için zkVM yapılandırmasına özel kod yazmaları gerekmez. Geliştirici deneyimi, zkVM'nin temel avantajıdır. Performans kriterlerini karşılamak için DevEx'i feda etmek, zkVM'nin kendi anlamına aykırı olacaktır.
Bu göstergeler, doğrulayıcı maliyetini vurgular. Ancak, sınırsız doğrulayıcı maliyetine izin verilirse (yani, kanıt boyutu veya doğrulama süresi için bir üst sınır yoksa), herhangi bir doğrulayıcı göstergesini kolayca karşılayabilirsiniz. Bu nedenle, belirtilen aşamaya uygun bir sistem olması için kanıt boyutu ve doğrulama süresi için maksimum değerler belirtilmelidir.
) Performans gereksinimi
Aşama 1 gereksinimi: 'Makul ve olağanüstü doğrulama maliyeti' :
· Boyut kanıtı: Boyut kanıtı, tanık boyutundan küçük olmalıdır.
· Doğrulama süresi: Doğrulama işleminin hızı, yerel programın çalışma hızından daha yavaş olmamalıdır (yani, hesaplamanın doğruluğu kanıtlanmadan gerçekleştirilmez).
Bunlar, kanıt boyutunun ve doğrulama süresinin tanıkların doğruluğunu doğrudan kontrol etmelerinden daha kötü olmayacağını sağlar, bu da en az gereksinimleri temsil eder.
Aşama 2 ve sonrası gereksinimleri:
· Maksimum ispat boyutu: 256 KB。
· En büyük doğrulama süresi: 16 milisaniye.
Bu kesme değerleri, yeni ve daha yüksek doğrulama maliyeti getirebilecek hızlı kanıt teknolojilerine uyum sağlamak amacıyla kasıtlı olarak artırılmıştır. Aynı zamanda, çok pahalı kanıtları dışlar, bu da neredeyse hiçbir proje bunları blok zincirine dahil etmeye istekli değildir.
Hız Aşaması 1
Tek iş parçacığı kanıtının, yerel yürütmeden en fazla yüz bin kat daha yavaş olması gerekiyor, Ethereum bloklarını sadece kanıtlamakla kalmayıp bir dizi uygulamada ölçülmesi gerekir ve önceden derlenmişlere bağlı olmamalıdır.
Daha spesifik olarak, modern bir dizüstü bilgisayarda saniyede yaklaşık 30 milyar döngü çalışan RISC-V işlemini hayal edin. 1. aşamayı başarmak, aynı dizüstü bilgisayarda saniyede yaklaşık 30.000 RISC-V döngüsünü (tek iş parçacığı) kanıtlamanızı sağlar. Ancak doğrulama maliyeti, önce belirtildiği gibi "makul ve sıradışı" olmalıdır.
Hız Aşaması 2
Tek iş parçacığı kanıtının yerel yürütmeden en fazla on kat daha yavaş olması gerekir.
Ya da, bazı umut vadeden SNARK yöntemleri (özellikle ikili alan üzerindeki yöntemler) mevcut CPU ve GPU'ları engellediği için bu aşamaya ulaşmak için FPGA (hatta ASIC) ile karşılaştırabilirsiniz:
FPGA, yerel hızda simüle edilebilen RISC-V çekirdek sayısını destekler;
RISC-V'nin neredeyse gerçek zamanlı yürütmesi için gereken FPGA miktarını simüle etmek ve kanıtlamak.
Eğer ikincisi birincisinden en fazla 10,000 kat büyükse, ikinci aşamaya girmeye hak kazanırsınız. Standart bir CPU'da, ispat büyüklüğü en fazla 256 KB olmalı ve doğrulayıcı süresi en fazla 16 milisaniye olmalıdır.
Hız Aşaması 3
Aşama 2 hızına ulaşmanın ötesinde, otomatik sentez ve biçim doğrulaması kullanılarak 1000 katın altında ispat maliyetiyle (geniş uygulamalar için geçerli) ön derleme ile gerçekleştirilebilir. Temelde, her program için kanıtı hızlandırmak için özelleştirilmiş bir komut kümesi oluşturabilirsiniz, ancak bunu kullanımı kolay ve biçim doğrulaması yapılabilir bir şekilde yapmalısınız.
Bellek Aşaması 1
Aşama 1'de, 2 GB'den az bellek gerektiren bir ispatçıda hız, sıfır bilgi ile birlikte başarıyla gerçekleştirildi.
Bu, birçok mobil cihaz veya tarayıcı için son derece önemlidir, bu nedenle sayısız istemci zkVM kullanım durumunu başlatır. İstemci kanıtı önemlidir çünkü telefonlarımız gerçek dünya ile sürekli iletişim halinde olduğumuz araçlardır: konumumuzu, kimlik bilgilerimizi vb. takip ederler. Kanıt üretmek için 1-2 GB'dan fazla belleğe ihtiyaç duyulursa, günümüz mobil cihazları için gerçekten çok fazla olacaktır. Netleştirilmesi gereken iki nokta vardır:
· 2 GB alan sınırı, büyük cümleler için geçerlidir (yerel olarak çalıştırmak için on milyarlarca CPU döngüsü gerektiren cümleler). Yalnızca küçük cümleler için alan sınırını kanıtlayan sistem, geniş bir uygulanabilirlik eksikliğine sahiptir.
· Eğer ispatlayıcı çok yavaşsa, ispatlayıcının hafızasını 2 GB'ın altında tutmak çok kolaydır. Bu nedenle, bellek aşamasını basitleştirmemek için 2 GB hafıza sınırında hız aşamasını 1'de karşılamayı talep ediyorum.
Bellek Aşaması 2
Aşama 1'in hızı, bellek kullanımının 200 MB'den az olduğu durumda gerçekleşir (bellek Aşama 1'in 10 katı daha iyidir).
Neden 2 GB'nın altına düşmek istiyoruz? Bir merkezi olmayan bir örnek düşünün: Her web sitesine HTTPS ile erişildiğinde kimlik doğrulama ve şifreleme için bir sertifika indirirsiniz. Bunun yerine, site bu sertifikalara sahip zk kanıtlarını gönderebilir. Büyük web siteleri saniyede milyonlarca bu tür kanıt gönderebilir. Her kanıtın 2 GB RAM gerektirmesi durumunda, toplamda PB seviyesinde RAM'a ihtiyaç duyulur. Bellek kullanımını daha da düşürmek, merkezi olmayan uygulamalar için son derece önemlidir.
Precompile: Son Mil mi Koltuk Değneği mi?
zkVM tasarımında, ön derleme belirli bir işlev için özel olarak özelleştirilmiş SNARK'ları (veya kısıtlama sistemlerini) ifade eder, örneğin dijital imza için Keccak/SHA karma işlevi veya eliptik eğri grup işlemleri. Ethereum'da (çoğu yoğun işlemin Merkle karma ve imza doğrulamasını içerdiği) bazı el yapımı ön derlemeler, ispatçı maliyetini azaltabilir. Ancak onlara dayanmak, SNARK'ın ihtiyaç duyduğu hedefe ulaşmasını sağlamaz. Bunun nedenleri aşağıda belirtilmiştir:
· Çoğu uygulama (hem içeride hem dışarıda blockchain) için hâlâ çok yavaş: Mevcut zkVM, hatta önceden derlenmiş hash ve imzaları kullanarak, çünkü çekirdek ispat sistemi verimsiz olduğu için hâlâ çok yavaş (hem blockchain ortamında hem de blockchain dışında).
· Güvenlik hatası: Resmi olarak doğrulanmamış elle yazılmış ön derleme neredeyse kesinlikle hatalarla doludur ve felaketle sonuçlanabilecek güvenlik hatalarına neden olabilir.
**· Geliştirici Deneyimi Zayıf: **Çoğu zkVM'nin bugününde, yeni bir ön derleme eklemek her işlev için kısıtlama sistemini manuel olarak yazmayı gerektirir - bu temelde 1960'ların tarzı bir iş akışına geri dönüş anlamına gelir. Mevcut ön derlemeleri kullanmak bile, geliştiricilerin her bir ön derlemeyi çağırmak için kodlarını yeniden yapılandırmaları gerekir. Güvenliği ve geliştirici deneyimini optimize etmeliyiz, artı performans için bu ikisini feda etmek yerine. Bu, sadece performansın beklenen seviyeye ulaşmadığını kanıtlayabilir.
· I/O giderleri ve RAM olmadan: Ö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ğlayamayabilir çünkü giriş/çıkış iletişiminde büyük miktarda gider oluşturur ve RAM kullanamazlar. Blok zincir ortamında olsanız da, Ethereum gibi tek katmanlı L1'den daha fazlasını aşmak istediğiniz sürece (örneğin, çapraz zincir köprüleri oluşturmak istiyorsanız), farklı hash fonksiyonları ve imza şemalarıyla karşılaşacaksınız. Aynı sorunu tekrar tekrar ön derleme yaparak çözmek genişlemeyi sağlamaz ve büyük güvenlik riskleri getirir.
Tüm bu nedenlerden dolayı, ana hedefimizin altta yatan zkVM'in verimliliğini artırmak olduğuna inanıyorum. En iyi zkVM teknolojisi en iyi önceden derlenmişleri de üretecektir. Uzun vadede önceden derlenmişlerin hala kritik öneme sahip olacağına gerçekten inanıyorum, ancak bunların otomatik olarak sentezlenip resmi olarak doğrulanması şartıyla. Böylece zkVM geliştiricilerinin deneyim avantajını koruyabilir ve aynı zamanda felaket getiren güvenlik risklerinden kaçınabiliriz. Bu görüş, Hız Aşaması 3'te yansıtılmaktadır.
Tahmini Zaman Çizelgesi
Benim beklentim, az sayıda zkVM'nin bu yılın ilerleyen dönemlerinde hız aşaması 1 ve bellek aşaması 1'i gerçekleştirecek olmasıdır. Gelecek iki yıl içinde hız aşaması 2'nin de gerçekleşeceğini düşünüyorum, ancak henüz net değil, bazı henüz ortaya çıkmamış yeni fikirler olmadan bu hedefi gerçekleştirebilir miyiz. Kalan aşamaların (hız aşaması 3 ve bellek aşaması 2) gerçekleştirilmesi için birkaç yıl gerekeceğini tahmin ediyorum.
Toplama
Bu makalede zkVM'nin güvenliği ve performansı ayrı ayrı belirlense de, zkVM'nin bu yönleri tamamen bağımsız değildir. Daha fazla açık bulundukça, bazı açıkların yalnızca performansın önemli ölçüde düşmesi durumunda giderilebileceği öngörülmektedir. Güvenlik aşaması 2'ye ulaşana kadar, performans ertelenmelidir.
zkVM, sıfır bilgi kanıtlarını gerçekten yaygınlaştırabilir, ancak hala başlangıç aşamasındalar - güvenlik zorlukları ve büyük performans maliyetleriyle dolu. Hype ve pazarlama çabaları gerçek ilerlemeyi değerlendirmeyi zorlaştırıyor. Net güvenlik ve performans kilometre taşlarını açıklayarak, engelsiz bir yol haritası sağlamayı umut ediyoruz. Hedeflere ulaşacağız, ancak bunun zaman ve sürekli çaba gerektireceğini unutmamak önemlidir.
Orijinal metin bağlantısı
：
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: Güvenli ve Verimli zkVM'in Aşamalı Olarak Nasıl Gerçekleştirileceği (Geliştiriciler İçin Gerekli)
zkVM (Zero Knowledge Virtual Machine) SNARK'ı genelleştirmeyi taahhüt eder, bu da herkesin (özellikle SNARK uzmanlığı olmayanlar dahil) belirli bir giriş (veya şahitlik) üzerinde doğru bir şekilde çalıştıklarını kanıtlayabileceği anlamına gelir. Temel avantajları geliştirici deneyimindedir, ancak şu anda hem güvenlik hem de performans açısından büyük zorluklarla karşı karşıyadırlar. zkVM'nin taahhütlerini yerine getirmek için tasarımcıların bu zorlukları aşmaları gerekmektedir. Bu makalede, zkVM geliştirme olası aşamalarını listeledim ve bu aşamaların tamamlanması birkaç yıl sürebilir.
Challenge
Güvenlik açısından, zkVM yüksek derecede karmaşık bir yazılım projesidir ve hala hatalarla doludur. Performans açısından, doğrulama programının doğru şekilde çalıştığını kanıtlama hızı yerel çalışmaya göre onbinlerce kat daha yavaş olabilir, bu da çoğu uygulamanın şu anda gerçek dünyada dağıtılamamasına neden olmaktadır.
Bu gerçek zorluklar varken, blok zinciri endüstrisindeki çoğu şirket, zkVM'yi hemen dağıtılabilecek bir şey olarak tasvir ediyor. Aslında, bazı projeler, zincirdeki etkinliği kanıtlamak için büyük miktarda hesaplama maliyeti ödedi. Ancak zkVM hala eksik olduğundan, bu sadece SNARK koruması altında olduğunu taklit etmek için pahalı bir yol, aslında ya izinle korunur ya da daha kötüsü, kolayca saldırıya uğrar.
Güvenli ve yüksek performanslı zkVM'nin gerçekleşmesine birkaç yıl var. Bu makale, zkVM'nin ilerlemesini izlemek için aşamalı hedefler serisi öneriyor - bu hedefler spekülasyonu ortadan kaldırabilir ve topluluğun gerçek ilerlemeye odaklanmasına yardımcı olabilir.
Güvenlik Aşaması
SNARK tabanlı zkVM genellikle iki ana bileşeni içerir:
· Polinom İnteraktif Oracle Kanıtı (PIOP)( : Polinom hakkındaki ifadeleri (veya onlardan sonuç çıkarılan kısıtlamaları) kanıtlamak için etkileşimli bir kanıt çerçevesi.
· Polinom taahhüt şeması )PCS(: Kanıtlayıcıların polinom değerlendirmesinde yalan söyleyememesini gizli tutar.
zkVM, etkin yürütmenin özünü izleme kodunu kısıtlama sistemine kodlamak olarak ele alır - genel olarak, bunlar virtual makinenin kayıtlarını ve belleği doğru şekilde kullanmasını zorlar - ardından bu kısıtlamaların yerine getirildiğini kanıtlamak için SNARK uygular.
ZkVM gibi karmaşık bir sistemde hata olmamasının tek yolu, formal doğrulamadır. Güvenlik aşamaları aşağıda belirtilmiştir. Aşama 1, doğru protokole odaklanırken, Aşama 2 ve Aşama 3, doğru uygulamaya odaklanmaktadır.
Güvenlik Aşaması 1: Doğru Protokol
1、PIOP güvenilirlik için resmi doğrulama kanıtı;
2、PCS bazı şifreleme varsayımları veya ideal modeller altında zorlayıcı bir şekilde doğrulanmış kanıtı sahiptir；
3、Eğer Fiat-Shamir kullanılıyorsa, PIOP ve PCS tarafından elde edilen kısa kanıt, rastgele kehanet modelinde güvenli resmi doğrulama kanıtıdır (gerekirse diğer şifreleme varsayımlarını güçlendirmek için).
4、PIOP uygulanan kısıtlama sistemi, VM'nin semantiğine eşit olan bir doğrulama kanıtıdır;
5、Tüm bu bölümleri tek bir, formal doğrulanmış güvenli SNARK kanıtı olarak 'yapıştırmak' için, VM bytecode tarafından belirtilen herhangi bir programa çalıştırılması için. Protokol zero-knowledge'ı gerçekleştirmeyi amaçlıyorsa, bu özelliği de formal doğrulamak için, şahitlerle ilgili hassas bilgilerin sızdırılmayacağından emin olmak gereklidir.
Rekürsif Uyarı: zkVM'nin rekürsif olarak kullanılması durumunda, bu aşamayı tamamlanmış kabul etmek için her PIOP, taahhüt planı ve taahhüt sistemi ile ilişkili herhangi bir yerin doğrulanması gerekir.
Güvenlik Aşaması 2: Doğru Doğrulayıcı Uygulaması
Formal doğrulama, zkVM doğrulayıcısının gerçek uygulamasının (Rust, Solidity vb. kullanılarak) 1. aşama doğrulaması protokolüyle eşleştiğini kanıtlar. Bu, uygulamanın protokolünün yalnızca mantıklı değil, aynı zamanda düşük verimli spesifikasyonlarla Lean gibi yazılmış olabileceğinden emin olur.
Güvenlik Aşaması 3: Doğru Zamanlayıcı Uygulaması
zkVM onaylayıcısının gerçek uygulaması, Aşama 1 ve Aşama 2'de doğrulanan kanıtlama sisteminin kanıtlama sistemini doğru bir şekilde oluşturduğunda resmi olarak doğrulanır. Bu, bütünlüğü sağlar, yani zkVM kullanan herhangi bir sistem, kanıtlanamayan ifadeler tarafından "takılıp kalmaz". Kanıtlayıcı sıfır bilgiyi uygulamak niyetindeyse, bu özelliğin resmi olarak doğrulanması gerekir.
Tahmini Zaman Çizelgesi
· Aşama 1 İlerleme: Gelecek yıl aşamalı başarılar elde etmeyi bekleyebiliriz (örneğin ZKLib). Ancak en az iki yıl içinde hiçbir zkVM Aşama 1 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ı takımlar, Plonk doğrulayıcısının uygulamasının makaledeki protokolle uyumlu olduğunu kanıtlamıştır (makalenin protokolünün kendisi tamamen doğrulanmamış olabilir). Yine de, herhangi bir zkVM'in üçüncü aşamaya dört yıldan az bir sürede ulaşmayı beklemiyorum - ve belki daha uzun bir süre.
Önemli Notlar: Fiat-Shamir güvenliği ve doğrulanmış bayt kodu
Birincil karmaşık faktör, Fiat-Shamir dönüşümü etrafında çözülememiş araştırma sorunlarının varlığıdır. Tüm üç aşama, Fiat-Shamir'i ve rasgele kehanetçileri kusursuz güvenliklerinin bir parçası olarak görür, ancak aslında tüm paradigmada zayıflıklar olabilir. Bu, rasgele kehanetçi ile idealize edilmiş ve gerçek kullanılan karma işlevi arasındaki farklılıklardan kaynaklanmaktadır. En kötü durumda, Fiat-Shamir sorunundan dolayı, 2. aşamaya ulaşıldığında sistem tamamen güvensiz bulunabilir. Bu ciddi endişelere ve sürekli araştırmalara neden olmuştur. Bu tür zayıflıklara karşı daha iyi korunmak için dönüşümü kendisini değiştirmemiz gerekebilir.
Teoride, geriye dönük olmayan sistemler, bazı bilinen saldırılarla ilgili devrelerin, kullanılan devrelerle benzer olması nedeniyle daha sağlamdır.
Başka bir dikkat çekici husus, eğer bayt kodunda kusurlar varsa, bu durumda bilgisayar programının doğru şekilde çalıştığı (bayt kodu aracılığıyla belirtildiği şekilde) kanıtlanmış olsa bile, değeri sınırlı olacaktır. Bu nedenle, zkVM'nin kullanılabilirliği büyük ölçüde formal doğrulama için bayt kodu üretme yöntemine bağlıdır - bu, bu yazının kapsamının ötesinde büyük bir zorluk oluşturur.
Gelecek Kuantum Sonrası Dönem Güvenliği
En az beş yıl boyunca (muhtemelen daha uzun bir süre), kuantum bilgisayarlar ciddi bir tehdit oluşturmayacak, ancak zayıflıklar bir hayatta kalma riskidir. Bu nedenle, şu anki ana odak noktası, bu makalede tartışılan güvenlik ve performans gereksinimlerini karşılamaktır. Eğer kuantum güvenli olmayan SNARK'ı bu güvenlik gereksinimlerini daha hızlı karşılayabilirsek, o zaman bunu yapmalıyız, sonrasında kuantum SNARK yetişene veya insanlar şifreleme ile ilgili kuantum bilgisayarların ortaya çıkmasından ciddi endişe duyana kadar.
zkVM 的性能现状
Şu anda, zkVM belgelendirici tarafından üretilen harcama katsayısı, yerel yürütme maliyetinin 1000000 katına yaklaşıyor. Eğer bir programın çalışması için X döngüye ihtiyacı varsa, doğru bir şekilde yürütmenin maliyeti yaklaşık olarak X kez 1000000 CPU döngüsüdür. Bir yıl önce durum buydu ve bugün hala öyle.
Popüler anlatılar genellikle bu tür harcamaları kabul edilebilir bir şekilde tanımlamak için duyulabilir.
·「Ethereum ana ağı için yıllık üretim maliyeti milyon doların altında.」
·「Biz neredeyse onlarca GPU'dan oluşan bir küme kullanarak Ethereum blok kanıtını gerçek zamanlı olarak üretebiliriz.」
·「Bizim en yeni zkVM, öncüsüne göre 1000 kat daha hızlı.」
Teknik olarak bu ifadeler doğru olsa da, uygun bir bağlam olmadan yanıltıcı olabilir. Örneğin:
Eski sürümden zkVM 1000 kat daha hızlı, ancak mutlak hız hala çok yavaş. Bu daha çok şeyin ne kadar kötü olduğunu gösteriyor, ne kadar iyi olduğunu değil.
· Birisi Ethereum ana ağının işlem hacmini 10 kat artırmayı önerdi. Bu, mevcut zkVM performansını daha yavaş hale getirecektir.
· İnsanların söylediği 'Ethereum bloğun neredeyse gerçek zamanlı kanıtı', birçok blok zinciri uygulamasının gerektirdiğinden çok daha yavaş (örneğin, Optimism'in blok süresi 2 saniyedir, Ethereum'un 12 saniyelik blok süresinden çok daha hızlı).
· 'Onlarca GPU sürekli çalışırken, hiçbir hata olmaksızın' kabul edilebilir bir canlılık garantisi sağlayamaz.
· Ethereum ana ağındaki tüm faaliyetlerin yansıtılması için yılda milyon dolar harcamak, Ethereum tam düğümünün yılda sadece yaklaşık 25 dolar harcaması gerektiğini kanıtlamak için yeterli değildir.
Blockchain dışındaki uygulamalar için, bu açıkça çok yüksek maliyetli. Herhangi bir paralelleştirme veya mühendislik, bu kadar büyük maliyeti telafi edemez. Yerel yürütme ile karşılaştırıldığında, zkVM hızının en fazla 100.000 kat yavaşladığı temel bir referans olmalıdır - bu sadece ilk adım olsa bile. Gerçek ana akım benimseme, yaklaşık 10.000 kat veya daha düşük maliyet gerektirebilir.
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ü optimizasyon (örneğin derleme öncesi).
· Mühendislik ve donanım hızlandırma (örneğin GPU, FPGA veya çoklu çekirdekli CPU).
Her ne kadar son iki unsur gerçek uygulama için hayati öneme sahip olsa da, genellikle herhangi bir ispat sistemi için geçerli oldukları için temel maliyetleri yansıtmak zorunda olmadıklarını belirtmek önemlidir. Örneğin, GPU hızlandırma ve ön derleme eklemek zkEVM içinde 50 kat hızlanmaya kolayca yol açabilir, bu da saf CPU tabanlı derleme olmayan yöntemden çok daha hızlıdır - bu, temelde daha az verimli olan bir sistemi aynı şekilde cilalanmamış bir sistemden daha iyi göstermeye yeterli olabilir.
Bu nedenle, SNARK'ın performansı özel donanım ve derleme olmadan aşağıda vurgulanmaktadır. Bu, mevcut referans test yönteminden farklıdır, çünkü genellikle bu üç faktörü tek bir 'başlık numarası' olarak özetler. Bu, bir elmasın saflığı yerine cilalama süresine göre elmasın değerlendirilmesine benzer. Amacımız genel kanıt sistemlerinin içsel maliyetini ortadan kaldırmaktır - topluluğun karışıklık faktörlerini ortadan kaldırmasına yardımcı olmak ve kanıt sistem tasarımının gerçek ilerlemesine odaklanmaktır.
Performans Aşaması
Aşağıda 5 performans kilometretaşı var. İlk olarak, CPU üzerindeki doğrulayıcı maliyetini birkaç kat azaltmamız gerekiyor. Ancak böylece odak donanım yoluyla daha fazla azaltmaya çevrilmelidir. Ayrıca bellek kullanım oranını artırmak zorundayız.
Tüm aşamalarda, geliştiricilerin gerekli performansı elde etmek için zkVM yapılandırmasına özel kod yazmaları gerekmez. Geliştirici deneyimi, zkVM'nin temel avantajıdır. Performans kriterlerini karşılamak için DevEx'i feda etmek, zkVM'nin kendi anlamına aykırı olacaktır.
Bu göstergeler, doğrulayıcı maliyetini vurgular. Ancak, sınırsız doğrulayıcı maliyetine izin verilirse (yani, kanıt boyutu veya doğrulama süresi için bir üst sınır yoksa), herhangi bir doğrulayıcı göstergesini kolayca karşılayabilirsiniz. Bu nedenle, belirtilen aşamaya uygun bir sistem olması için kanıt boyutu ve doğrulama süresi için maksimum değerler belirtilmelidir.
) Performans gereksinimi
Aşama 1 gereksinimi: 'Makul ve olağanüstü doğrulama maliyeti' :
· Boyut kanıtı: Boyut kanıtı, tanık boyutundan küçük olmalıdır.
· Doğrulama süresi: Doğrulama işleminin hızı, yerel programın çalışma hızından daha yavaş olmamalıdır (yani, hesaplamanın doğruluğu kanıtlanmadan gerçekleştirilmez).
Bunlar, kanıt boyutunun ve doğrulama süresinin tanıkların doğruluğunu doğrudan kontrol etmelerinden daha kötü olmayacağını sağlar, bu da en az gereksinimleri temsil eder.
Aşama 2 ve sonrası gereksinimleri:
· Maksimum ispat boyutu: 256 KB。
· En büyük doğrulama süresi: 16 milisaniye.
Bu kesme değerleri, yeni ve daha yüksek doğrulama maliyeti getirebilecek hızlı kanıt teknolojilerine uyum sağlamak amacıyla kasıtlı olarak artırılmıştır. Aynı zamanda, çok pahalı kanıtları dışlar, bu da neredeyse hiçbir proje bunları blok zincirine dahil etmeye istekli değildir.
Hız Aşaması 1
Tek iş parçacığı kanıtının, yerel yürütmeden en fazla yüz bin kat daha yavaş olması gerekiyor, Ethereum bloklarını sadece kanıtlamakla kalmayıp bir dizi uygulamada ölçülmesi gerekir ve önceden derlenmişlere bağlı olmamalıdır.
Daha spesifik olarak, modern bir dizüstü bilgisayarda saniyede yaklaşık 30 milyar döngü çalışan RISC-V işlemini hayal edin. 1. aşamayı başarmak, aynı dizüstü bilgisayarda saniyede yaklaşık 30.000 RISC-V döngüsünü (tek iş parçacığı) kanıtlamanızı sağlar. Ancak doğrulama maliyeti, önce belirtildiği gibi "makul ve sıradışı" olmalıdır.
Hız Aşaması 2
Tek iş parçacığı kanıtının yerel yürütmeden en fazla on kat daha yavaş olması gerekir.
Ya da, bazı umut vadeden SNARK yöntemleri (özellikle ikili alan üzerindeki yöntemler) mevcut CPU ve GPU'ları engellediği için bu aşamaya ulaşmak için FPGA (hatta ASIC) ile karşılaştırabilirsiniz:
FPGA, yerel hızda simüle edilebilen RISC-V çekirdek sayısını destekler;
RISC-V'nin neredeyse gerçek zamanlı yürütmesi için gereken FPGA miktarını simüle etmek ve kanıtlamak.
Eğer ikincisi birincisinden en fazla 10,000 kat büyükse, ikinci aşamaya girmeye hak kazanırsınız. Standart bir CPU'da, ispat büyüklüğü en fazla 256 KB olmalı ve doğrulayıcı süresi en fazla 16 milisaniye olmalıdır.
Hız Aşaması 3
Aşama 2 hızına ulaşmanın ötesinde, otomatik sentez ve biçim doğrulaması kullanılarak 1000 katın altında ispat maliyetiyle (geniş uygulamalar için geçerli) ön derleme ile gerçekleştirilebilir. Temelde, her program için kanıtı hızlandırmak için özelleştirilmiş bir komut kümesi oluşturabilirsiniz, ancak bunu kullanımı kolay ve biçim doğrulaması yapılabilir bir şekilde yapmalısınız.
Bellek Aşaması 1
Aşama 1'de, 2 GB'den az bellek gerektiren bir ispatçıda hız, sıfır bilgi ile birlikte başarıyla gerçekleştirildi.
Bu, birçok mobil cihaz veya tarayıcı için son derece önemlidir, bu nedenle sayısız istemci zkVM kullanım durumunu başlatır. İstemci kanıtı önemlidir çünkü telefonlarımız gerçek dünya ile sürekli iletişim halinde olduğumuz araçlardır: konumumuzu, kimlik bilgilerimizi vb. takip ederler. Kanıt üretmek için 1-2 GB'dan fazla belleğe ihtiyaç duyulursa, günümüz mobil cihazları için gerçekten çok fazla olacaktır. Netleştirilmesi gereken iki nokta vardır:
· 2 GB alan sınırı, büyük cümleler için geçerlidir (yerel olarak çalıştırmak için on milyarlarca CPU döngüsü gerektiren cümleler). Yalnızca küçük cümleler için alan sınırını kanıtlayan sistem, geniş bir uygulanabilirlik eksikliğine sahiptir.
· Eğer ispatlayıcı çok yavaşsa, ispatlayıcının hafızasını 2 GB'ın altında tutmak çok kolaydır. Bu nedenle, bellek aşamasını basitleştirmemek için 2 GB hafıza sınırında hız aşamasını 1'de karşılamayı talep ediyorum.
Bellek Aşaması 2
Aşama 1'in hızı, bellek kullanımının 200 MB'den az olduğu durumda gerçekleşir (bellek Aşama 1'in 10 katı daha iyidir).
Neden 2 GB'nın altına düşmek istiyoruz? Bir merkezi olmayan bir örnek düşünün: Her web sitesine HTTPS ile erişildiğinde kimlik doğrulama ve şifreleme için bir sertifika indirirsiniz. Bunun yerine, site bu sertifikalara sahip zk kanıtlarını gönderebilir. Büyük web siteleri saniyede milyonlarca bu tür kanıt gönderebilir. Her kanıtın 2 GB RAM gerektirmesi durumunda, toplamda PB seviyesinde RAM'a ihtiyaç duyulur. Bellek kullanımını daha da düşürmek, merkezi olmayan uygulamalar için son derece önemlidir.
Precompile: Son Mil mi Koltuk Değneği mi?
zkVM tasarımında, ön derleme belirli bir işlev için özel olarak özelleştirilmiş SNARK'ları (veya kısıtlama sistemlerini) ifade eder, örneğin dijital imza için Keccak/SHA karma işlevi veya eliptik eğri grup işlemleri. Ethereum'da (çoğu yoğun işlemin Merkle karma ve imza doğrulamasını içerdiği) bazı el yapımı ön derlemeler, ispatçı maliyetini azaltabilir. Ancak onlara dayanmak, SNARK'ın ihtiyaç duyduğu hedefe ulaşmasını sağlamaz. Bunun nedenleri aşağıda belirtilmiştir:
· Çoğu uygulama (hem içeride hem dışarıda blockchain) için hâlâ çok yavaş: Mevcut zkVM, hatta önceden derlenmiş hash ve imzaları kullanarak, çünkü çekirdek ispat sistemi verimsiz olduğu için hâlâ çok yavaş (hem blockchain ortamında hem de blockchain dışında).
· Güvenlik hatası: Resmi olarak doğrulanmamış elle yazılmış ön derleme neredeyse kesinlikle hatalarla doludur ve felaketle sonuçlanabilecek güvenlik hatalarına neden olabilir.
**· Geliştirici Deneyimi Zayıf: **Çoğu zkVM'nin bugününde, yeni bir ön derleme eklemek her işlev için kısıtlama sistemini manuel olarak yazmayı gerektirir - bu temelde 1960'ların tarzı bir iş akışına geri dönüş anlamına gelir. Mevcut ön derlemeleri kullanmak bile, geliştiricilerin her bir ön derlemeyi çağırmak için kodlarını yeniden yapılandırmaları gerekir. Güvenliği ve geliştirici deneyimini optimize etmeliyiz, artı performans için bu ikisini feda etmek yerine. Bu, sadece performansın beklenen seviyeye ulaşmadığını kanıtlayabilir.
· I/O giderleri ve RAM olmadan: Ö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ğlayamayabilir çünkü giriş/çıkış iletişiminde büyük miktarda gider oluşturur ve RAM kullanamazlar. Blok zincir ortamında olsanız da, Ethereum gibi tek katmanlı L1'den daha fazlasını aşmak istediğiniz sürece (örneğin, çapraz zincir köprüleri oluşturmak istiyorsanız), farklı hash fonksiyonları ve imza şemalarıyla karşılaşacaksınız. Aynı sorunu tekrar tekrar ön derleme yaparak çözmek genişlemeyi sağlamaz ve büyük güvenlik riskleri getirir.
Tüm bu nedenlerden dolayı, ana hedefimizin altta yatan zkVM'in verimliliğini artırmak olduğuna inanıyorum. En iyi zkVM teknolojisi en iyi önceden derlenmişleri de üretecektir. Uzun vadede önceden derlenmişlerin hala kritik öneme sahip olacağına gerçekten inanıyorum, ancak bunların otomatik olarak sentezlenip resmi olarak doğrulanması şartıyla. Böylece zkVM geliştiricilerinin deneyim avantajını koruyabilir ve aynı zamanda felaket getiren güvenlik risklerinden kaçınabiliriz. Bu görüş, Hız Aşaması 3'te yansıtılmaktadır.
Tahmini Zaman Çizelgesi
Benim beklentim, az sayıda zkVM'nin bu yılın ilerleyen dönemlerinde hız aşaması 1 ve bellek aşaması 1'i gerçekleştirecek olmasıdır. Gelecek iki yıl içinde hız aşaması 2'nin de gerçekleşeceğini düşünüyorum, ancak henüz net değil, bazı henüz ortaya çıkmamış yeni fikirler olmadan bu hedefi gerçekleştirebilir miyiz. Kalan aşamaların (hız aşaması 3 ve bellek aşaması 2) gerçekleştirilmesi için birkaç yıl gerekeceğini tahmin ediyorum.
Toplama
Bu makalede zkVM'nin güvenliği ve performansı ayrı ayrı belirlense de, zkVM'nin bu yönleri tamamen bağımsız değildir. Daha fazla açık bulundukça, bazı açıkların yalnızca performansın önemli ölçüde düşmesi durumunda giderilebileceği öngörülmektedir. Güvenlik aşaması 2'ye ulaşana kadar, performans ertelenmelidir.
zkVM, sıfır bilgi kanıtlarını gerçekten yaygınlaştırabilir, ancak hala başlangıç aşamasındalar - güvenlik zorlukları ve büyük performans maliyetleriyle dolu. Hype ve pazarlama çabaları gerçek ilerlemeyi değerlendirmeyi zorlaştırıyor. Net güvenlik ve performans kilometre taşlarını açıklayarak, engelsiz bir yol haritası sağlamayı umut ediyoruz. Hedeflere ulaşacağız, ancak bunun zaman ve sürekli çaba gerektireceğini unutmamak önemlidir.
Orijinal metin bağlantısı
：