VERI-ZEXE:
Universal Setup ile Merkeziyetsiz Gizli Hesaplama
ZEXE: arka planı ve sınırlamalar
Ethereum ve Solana gibi akıllı sözleşme sistemleri, web3 yenilikleri için mükemmel üretim alanlarıdır. Ancak, gizlilik veya ölçeklenebilirlik eksikliğinden ve bazen her ikisinden de muzdariptirler. Genel doğrulanabilirliği sağlamak için, tüm program durumları ve durum geçişleri herkese açık ve şeffaftır, gizlilikten ödün verilir ve tüm işlemler veya hesaplamalar, ölçeklenebilirliği etkileyen tüm düğümler (full node) tarafından yeniden yürütülür.
2019 yılında Bowe ve ark. kullanıcıların zincir dışı keyfi hesaplamaları yürütmelerine ve sıfır bilgi kanıtlarını kullanarak bu hesaplamanın doğruluğunu onaylayan bir işlem göndermelerine olanak tanıyan merkezi olmayan özel hesaplama (DPC) adlı bir plan önerdi [2]. Yukarıdaki her iki sorunla başa çıkmak için DPC şemasını başlatan ZEXE (zk-execution) adlı bir sistem uyguladılar. Kabaca, ZEXE, gizlilik garantilerini korurken tek uygulamalı bir sistemden akıllı sözleşme sistemine genelleşen bir “programlanabilir Zcash”tir.
ZEXE’nin bazı dikkate değer özellikleri şunlardır:
- Veri ve işlev gizliliği: ZEXE, tüm program durumlarının yanı sıra işlev çağrılarına (veri gizliliği) giriş/çıkışları ve daha da önemlisi, her işlemde hangi işlevlerin/programların çağrıldığını (işlev gizliliği) gizler. Özel akıllı sözleşmelere yönelik sayısız alternatif yaklaşımla bile ZEXE, işlev gizliliğini sağlayan tek somut yapı olmaya devam ediyor (makaledeki ilgili çalışma bölümüne bakın).
- Programlanabilirlik: ZEXE ile kullanıcılar, ilgili program durumları için geçiş kurallarını belirleyen bir kayda (Bitcoin Script fikrine benzer şekilde) keyfi ilkeler/tahminler ekleyebilirler. Bowe ve ark. ZEXE modeli altında kullanıcı tanımlı varlıkların, DEX’lerin ve düzenlemeye uyumlu sabit paraların nasıl programlanacağını gösterdiler.
- Kısa ve öz doğrulama: Zincir üzerinde doğrulayıcıların hesaplamayı yeniden yürütmesi gerekmez. Bunun yerine, zincir dışı hesaplamanın ne kadar pahalı olduğuna bakılmaksızın sabit zaman alan kısa işlem geçerlilik kanıtlarını doğrularlar.
Mevcut uygulamalar (SnarkVM testnet 1 ve SnarkVM testnet 2) yukarıda açıklanan özellikleri sunar, ancak pratikliklerini sınırlayan ve iyileştirme için çok yer bırakan dezavantajları vardır:[3]:
- Circuit-specific setup : ZEXE (SnarkVM testnet1), akıllı sözleşme yürütmelerinin doğruluğunu onaylamak için GM17 ve Groth16 gibi evrensel olmayan SNARK’ları kullanır ve her uygulama/program için son derece pratik olmayan güvenilir bir kurulum sağlar.
- Performans: Evrensel SNARK’lı ZEXE (SnarkVM testnet2), evrensel SNARK doğrulama mantığının daha yüksek karmaşıklığı ve ZEXE’nin SNARK doğrulama mantığını kodlayan bir ifade için bir SNARK kanıtı üretmesini gerektirmesi nedeniyle önemli bir performans düşüşü yaşar.
VERI-ZEXE: Performans kaybı olmadan Universal Setup
VERI-ZEXE, evrensel SNARK doğrulayıcı aygıtının devre karmaşıklığını azaltmak için birçok optimizasyon sunarak orijinal ZEXE’nin tüm özelliklerini ve özelliklerini korurken, yukarıda belirtilen iki zorluğu ele alır. Bu tekniklerin ayrıntılı açıklamaları için okuyucuları VERI-ZEXE belgesine yönlendiriyoruz; bu gönderide yalnızca kıyaslama sonuçlarımızı sergiliyor ve yorumluyoruz.
İlk olarak, kendimizi en önemli ölçütlerin arasında işlem oluşturma süresi (yani Yürütme algoritması), bellek kullanımı ve işlem geçerliliği kanıt boyutunu içeren son teknoloji ZEXE uygulamalarıyla karşılaştırıyoruz. Aşağıda gösterildiği gibi, performansımız orijinal evrensel olmayan ZEXE ile aynıdır. En iyi evrensel ZEXE uygulamasıyla karşılaştırıldığında, işlem oluşturmada ~9.0x ve bellek kullanımında ~2.6x iyileştirme elde ettik.
İkinci olarak, SnarkVM testnet2 ile daha ayrıntılı bir karşılaştırma sağlıyoruz. Aşağıda gösterildiği gibi, dış devremiz (derinlik-2 kanıt kompozisyonu sırasında kullanılır) boyutu çok daha küçüktür ve bu nedenle kanıtlama süresi bir büyüklük sırası daha hızlıdır, bu da tüm işlem boyutlarında çok daha hızlı kanıt üretimine yol açar:
Son olarak, TurboPlonk ve UltraPlonk kısıtlama sistemi tasarımındaki yeniliğimizi ve optimizasyon tekniklerimizi göstermek için VERI-ZEXE’de kullanılan kriptografik yapı taşları için kısıtlama maliyetinin bir dökümünü sunuyoruz. Bu yılın başlarında Jellyfish kitaplığımızı tanıttığımızda, gadget karmaşıklığına ilişkin bu önemli noktaları paylaştık.
Başlıca kriptografik yapı taşları ve cebirsel işlemler için PLONK kısıtlamalarının sayısı. Bu sayılar TurboPlonk tasarımına özeldir.
VERI-ZEXE + CAPE: özelleştirilebilir varlık politikası
ZEXE, özel bir akıllı sözleşme tasarımı olarak gümüş bir kurşun olmasa da ([3]’te bahsedilen daha fazla sorun nedeniyle), kullanıcılar arasında yüksek paralellik ve düşük işlem bağımlılığından yararlanacak minimum paylaşılan durumlara sahip uygulamalar için harika bir çözümdür. UTXO modeli. CAPE ürünü, bunun kullanıcılara nasıl görünebileceğinin harika bir örneğidir.
Şu anda CAPE protokolümüz yalnızca önceden tanımlanmış bir dizi varlık politikasını destekler (örneğin, para basma, anonim aktarımlar, anahtarları dondurma, belirlenmiş görüntüleme politikaları vb.), ancak dinamik, kullanıcı tanımlı varlık politikalarını desteklemez. Toplam arzı 1000 birim olan ve yalnızca belirli bir varlık belirlenmiş bir adrese ödendiğinde basılabilen yeni bir “konser jetonu” oluşturmak istediğinizi hayal edin. Yeni konser jetonumuzla ilişkili bu yeni para basma politikası, mevcut CAPE ürününün uygulayabileceğinin ötesine geçiyor. Varlık ihraççılarının gelecekteki varlıkları için özelleştirilmiş, daha karmaşık politikalar tasarlayabilmeleri yaygın bir gereklilik ve istenen bir özelliktir. VERI-ZEXE bu tür programlanabilirliği mümkün kılacaktır.
“VERI-ZEXE, özel akıllı sözleşmeler için bir alt tabaka görevi görebilir. Önceki çalışma ile karşılaştırıldığında, evrensel bir kurulumu ve işlem oluşturmada ~ 9 kat hızlanmanın yanı sıra bellek kullanımında ~ 2,6 kat tasarruf sağlayarak özel sabit paralar gibi uygulamaları zorluyor. pratiklik alanında keyfi, özelleştirilebilir varlık politikaları” diyor ilk yazar Alex Xiong.
Espresso Systems Baş Kriptografı Binyi Chen şunları ekledi: “VERI-ZEXE’nin altında yatan teknikler gizliliği sağlamakla sınırlı değil, aynı zamanda ölçeklenebilirliğe de yardımcı oluyor. Örneğin, aynı teknikler zk-zk olarak adlandırılanların performansını optimize etmek için kullanılabilir. -toplama, burada toplama, CAP veya Zcash gibi sıfır bilgili (özel) işlem biçimlerine uygulanır.”
Gelecekteki gönderilerde CAPE’yi ilerletmek için tasarımlarımız hakkında daha fazla bilgi vereceğiz ve bu çığır açan yeniliklerin Espresso’ya getireceği şeyler konusunda son derece heyecanlıyız. Bizi izlemeye devam edin!
Dipnotlar
[1]: Aleo’nun SnarkVM’si birçok yinelemeye sahiptir: testnet1 sürümleri, uygulamaya özel güvenilir kurulumlar gerektiren S&P19 belgesinde açıklanan ZEXE’nin makul ölçüde sadık bir gerçekleştirmesidir; testnet2'nin erken sürümü, doğum/ölüm tahminleri için kanıt üretmek için kullanılan kanıt sistemini GM17'den Marlin’e değiştirerek sistemi “evrensel” hale getirir; testnet2'nin sonraki sürümü ve gelecekteki testnet sürümleri, modeli basitleştirerek ancak programlanabilirliğini kısıtlayarak (örneğin, programlar arası çağrıya izin vermeyerek) orijinal DPC modelinden uzaklaşır. Testnet3, bu blogun kapsamı dışında olduğundan ve kodumuz testnet1 ve testnet2'nin önceki sürümlerine göre ölçüm yaptığından, yeni, basitleştirilmiş ancak kısıtlı DPC modeli. Karşılaştırma sırasında adil bir karşılaştırma yapmak için kodlarında ekstra değişiklikler yaptık, daha fazla ayrıntı için makalenin 4.2 Bölümüne bakın.
[2]: Zincir dışı hesaplamanın genel akışı ve zincir üzerinde hesaplama bütünlüğü kanıtının doğrulanması kulağa zk-rollup’a benzer gelebilir. ZEXE’deki kullanıcılar, işlem geçerlilik kanıtını oluşturur ve işlemleri doğrudan zincir üzerinde gönderirken, zk-Rollup’taki kullanıcılar, daha sonra zincir üzerinde gönderilecek zk kanıtını oluşturacak olan toplama doğrulayıcılarına işlem gönderir. Teknik olarak ZEXE, zincir dışı hesaplamanın tek bir kullanıcı veya çok kullanıcılı bir MPC protokolü veya bir toplama sunucusu tarzında nasıl yapıldığını umursamıyor, bu nedenle iki yaklaşımı tamamlayıcı buluyoruz.
[3]: ZEXE ile eşzamanlılık sorunu (birden çok kullanıcı aynı anda paylaşılan bir durumu yeni bir duruma geçirmeye çalıştığında), atomik birleştirilebilirlik yeteneği (ZEXE’de Flashloan benzeri bir uygulama elde etmek için “in” dediğimiz bir teknik gerektirir) dahil olmak üzere birçok başka zorluk vardır. — ZEXE kayıt nano çekirdeğini (RNK) biraz değiştiren paket birikimi”, UTXO modelinde yüklem programlamanın zorluğu (Chialisp gibi mevcut çözüm). Gelecekteki blog yazılarında bu sorunlardan bazılarına yaklaşımlarımızı tanıtmaya çalışacağız.
