SNARK performansını ölçme: Ön uçlar, arka uçlar ve gelecek

Bir SNARK (Öz ve Etkileşimli Olmayan Bilgi Argümanları), blok zinciri ölçeklenebilirliği (örneğin, L2 toplamaları) ve mahremiyet için önemli bir kriptografik ilkel bulma uygulamalarıdır. SNARK'lar, birisinin güvenilmeyen bir doğrulayıcıya kanıtlamasına izin verir V (örneğin, Ethereum blok zinciri) bazı verileri bildiklerini (örneğin, bir grup geçerli işlem). Bunu kanıtlamanın naif bir yolu, verileri V, kim daha sonra geçerliliğini doğrudan kontrol edebilir. Bir SNARK aynı şeyi başarır, ancak daha iyi maliyetlerle V. Özellikle, bir SNARK kanıtı, verilerin kendisini içeren saf olandan daha kısa olmalıdır. (Daha fazla ayrıntı için, ders kitabımın taslağına bakın, Kanıtlar, Argümanlar ve Sıfır Bilgi. SNARK'lara giriş için bkz. Sarah Meicklejohn's sunum a16z kriptoda Yaz Araştırmaları Serisi.)

SNARK'lar için doğrulama maliyetleri değişebilir, ancak bunlar iyi anlaşılır ve genellikle oldukça iyidir. Örneğin, PlonK kanıtların maliyeti 290,000 gaz StarkWare'in kanıtları yaklaşık 5 milyon gaza mal olurken, Ethereum üzerinde doğrulamak için. SNARK'lar, blok zincirlerinin dışında bile çeşitli ortamlarda potansiyel olarak uygulanabilir - örneğin, hızlı ancak güvenilmeyen sunucular ve donanım. 

Ancak SNARK doğrulaması genellikle ucuz olduğundan, uygulanabilirliğin ana belirleyicileri SNARK kanıtlayıcının maliyetleridir. P. Bu yazıda, SNARK'ları kullanmanın ne zaman makul olduğunu ve SNARK'ların gelecekte nasıl gelişebileceğini belirlemek için bu maliyetlerin nasıl tahmin edileceğini açıklıyorum. Bunun hızlı hareket eden bir alan olduğunu ve bu yazıda tartışılan projelerin birçoğunun performanslarını aktif olarak iyileştirdiğini belirtmekte fayda var.

Ama önce: SNARK'lar nasıl dağıtılır?

SNARK dağıtımında bir geliştirici genellikle bir bilgisayar programı yazar ψ verileri girdi olarak alan w kanıtlayıcının bildiğini iddia ettiği (w için standlar Tanık) ve bunu kontrol eder w geçerlidir. Örneğin, toplamalarda, program içindeki tüm işlemlerin w dijital olarak imzalanır, hiçbir hesap bakiyesinin sıfırın altına düşmesine neden olmaz vb. program ψ daha sonra bir aracılığıyla beslenir SNARK ön ucu bu, onu SNARK teknolojisinin uygulanmasına daha uygun bir formatta derler. Bu SNARK dostu biçime bir ara temsil (IR). 

Tipik olarak, IR, eşdeğer olan bir tür devre tatmin edicilik örneğidir. ψ. Bunun anlamı devre C verileri girdi olarak alır w, ayrıca tipik olarak "belirleyici olmayan tavsiye" olarak adlandırılan bazı ekstra girdiler ve çalışır ψ on w. Tavsiye girdileri yardımcı olmak için kullanılır C koşmak ψ, Tutarken C küçük. Örneğin, her seferinde ψ iki sayıyı böler x ve y, bölüm q ve kalan r tavsiye olarak sunulabilir C, ve C basitçe kontrol edebilir x = qy + r. Bu çek yapmaktan daha ucuzdur C hesaplamak için bir bölme algoritması çalıştırın q ve r sıfırdan.

Son olarak, devre tatmini için bir SNARK uygulanır. C. Buna SNARK arka ucu. gibi yüksek düzeyde yapılandırılmış bir avuç problem için matris çarpımı, kıvrımlar, ve birkaç grafik problemi, bu ön uç/arka uç paradigmasından kaçınan ve böylece çok daha hızlı bir kanıt elde eden bilinen SNARK'lar mevcuttur. Ancak bu yazının odak noktası genel amaçlı SNARK'lar.

Göreceğimiz gibi, SNARK arka ucunun kanıtlanmış maliyetleri, C'ler boyut. tutmak C küçük zor olabilir, çünkü devreler bir hesaplamayı ifade etmek için son derece sınırlı bir formattır. Onlar oluşur kapılar ile bağlanmıştır teller. Her kapı g bazı değerlerle beslenir ve bir çok bu değerlere basit fonksiyon. Sonuç daha sonra kaynaktan çıkan teller aracılığıyla "aşağı akış" kapılarına beslenir. g.

SNARK ölçeklenebilirliği: Gerçekten ne kadar zaman alıyor?

Anahtar soru şudur: SNARK kanıtlayıcısı, basitçe yeniden yürütmeye göre ne kadar daha fazla zaman alır? ψ veriler üzerinde? cevap genel gider SNARK'a göre, doğrudan tanık kontrolü. İkinci ifade, içinde bulunduğu naif ispatta şu gerçeği ifade eder: P gönderir w için V, V çekler wyürütülerek geçerliliği ψ geçiyoruz. 

Kanıtlanmış ek yükü “ön uç ek yükü” ve “arka uç ek yükü” olarak bölmek yararlıdır. Devreyi değerlendirirseniz C kapıdan kapıya F koşmaktan kat kat daha pahalı ψ, sonra ön uç ek yükünün F. Arka uç kanıtlayıcısını uygularsanız C is B değerlendirmekten kat daha pahalı C kapıdan kapıya, sonra arka uç ek yükünün B. Toplam ispat yükü, ürün, F·B. Bu çarpımsal ek yük önemli olabilir F ve B bireysel olarak mütevazıdır. 

Uygulamada, F ve B her ikisi de kabaca 1000 veya daha büyük olabilir. Bu, doğrudan tanık kontrolüne ilişkin toplam kanıtlayıcı ek yükünün 1 milyon ila 10 milyon veya daha fazla olabileceği anlamına gelir. Bir dizüstü bilgisayarda yalnızca bir saniye çalışan bir program, onlarca veya yüzlerce günlük işlem süresi (tek iş parçacıklı) gerektiren bir SNARK kanıtlayıcısına kolayca yol açabilir. Neyse ki, bu çalışma tipik olarak (SNARK'a bağlı olarak) değişen kapsamlarda paralelleştirilebilir. 

Özetle, bugün bir uygulamada SNARK kullanmak istiyorsanız, üç şeyden birinin doğru olması gerekir:

1. Doğrudan tanık kontrolü, bir dizüstü bilgisayarda bir saniyeden çok daha kısa sürer.
2. Doğrudan tanık kontrolü, özellikle bir devrede temsil edilmeye uygundur, bu nedenle ön uç ek yükü küçüktür.
3. SNARK kanıtlayıcının bitmesi için günlerce beklemeye ve/veya çok büyük paralel hesaplama kaynakları için ödeme yapmaya hazırsınız.

Tbu yazının geri kalanı, ön uç ve arka uç genel giderlerinin nereden geldiğini ve bunları farklı SNARK'lar için nasıl tahmin ettiğimi açıklıyor. Daha sonra iyileştirme beklentilerine döneceğiz. 

Ön uçları ve arka uçları ayırma

Ön uçları arka uçlardan tamamen ayırmak zor olabilir çünkü farklı arka uçlar farklı devre türlerini destekler. Bu nedenle, ön uçlar, arabirim kurmayı bekledikleri arka uca bağlı olarak farklılık gösterebilir.

SNARK arka uçları genellikle aritmetik devreleri destekler, yani devrelere girişler bazı sonlu alanların elemanlarıdır ve devre kapılarının iki alan elemanının toplamasını ve çarpmasını gerçekleştirdiği anlamına gelir. Bu devreler kabaca doğası gereği cebirsel olan düz çizgi bilgisayar programlarına (dallar, koşullu ifadeler vb.) 

Çoğu arka uç, genellikle Sıra-1 Kısıtlama Memnuniyeti (R1CS) örnekleri olarak adlandırılan aritmetik devrelerin genelleştirilmesini destekler. dikkate değer istisna dışında Groth16 ve öncülleri olan bu SNARK'lar, diğer BT'leri de desteklemek için yapılabilir. Örneğin, StarkWare, Cebirsel Orta Düzey Temsil (AIR) adı verilen ve aynı zamanda PlonKish aritmetizasyonu PlonK ve diğer arka uçlar tarafından desteklenebilir. Bazı arka uçların daha genel IR'leri destekleme yeteneği, bu IR'leri üreten ön uçların ek yükünü azaltabilir. 

Arka uçlar, doğal olarak destekledikleri sonlu alanlar açısından da farklılık gösterir. Bunu bir sonraki bölümde daha ayrıntılı tartışacağım.

Ön uçlara çeşitli yaklaşımlar

Bazı (çok özel) bilgisayar programları doğal olarak aritmetik devrelere karşılık gelir. Bir örnek, bazı alanlar üzerinde matrislerin safça çarpımını gerçekleştiren bilgisayar programıdır. Ancak çoğu bilgisayar programı ne düz ne de cebirseldir. Genellikle koşullu ifadeler, doğal olarak sonlu alan aritmetiğine karşılık gelmeyen tamsayılı bölme veya kayan nokta aritmetiği gibi işlemler ve daha fazlasını içerirler. Bu durumlarda, ön uç ek yükü önemli olacaktır. 

Popüler bir ön uç yaklaşımı, sanal makine (VM) olarak da adlandırılan bazı basit CPU'ları temel olarak adım adım yürüten devreler üretmektir. Ön uç tasarımcıları, gerçek bilgisayar işlemcileri için montaj talimatlarına benzer bir dizi "ilkel işlem" belirtir. Ön ucu kullanmak isteyen geliştiriciler ya doğrudan montaj dilinde ya da Solidity gibi daha yüksek seviyeli bir dilde "tanık kontrol programları" yazacak ve programlarını otomatik olarak derleme koduna derleyecektir. 

Örneğin, StarkWare'in Kahire derleme talimatlarının kabaca sonlu bir alan üzerinde toplama ve çarpmaya, işlev çağrılarına ve değişmez (yani, bir kez yazılabilir) bir belleğe okuma ve yazma işlemlerine izin verdiği çok sınırlı bir derleme dilidir. Kahire VM bir von Neumann mimarisidir, yani ön uç tarafından üretilen devreler esasen bir Kahire programını kamu girdisi olarak alır ve programı tanık üzerinde "çalıştırır". Kahire dili Turing Complete'dir - sınırlı talimat setine rağmen, daha standart mimarileri simüle edebilir, ancak bunu yapmak pahalı olabilir. Kahire ön ucu, Kahire programlarının yürütülmesini sağlıyor T derece olarak adlandırılan şeye ilkel talimatlar2 HAVA ile T satırlar ve yaklaşık 50 sütunlar.” Ne tam olarak bu şu anlama geliyor bu gönderi için önemli değil, ancak SNARK kanıtlayıcıları söz konusu olduğunda, bu, her biri için 50 ila 100 kapılı devrelere karşılık gelir. T Kahire CPU'nun adımları. 

RISC Sıfır Kahire'ye benzer bir yaklaşım benimsiyor, ancak sanal makine sözde RISC-V mimarisi, popülaritesi artan zengin bir yazılım ekosistemine sahip açık kaynaklı bir mimari. Çok basit bir komut seti olarak, onu destekleyen verimli bir SNARK ön ucu tasarlamak nispeten izlenebilir olabilir (en azından x86 veya ARM gibi karmaşık mimarilere göre). Mayıs ayı itibariyle RISC Zero programları çeviriyor yürütme T ile derece-5 AIR'lere ilkel RISC-V komutları 3T satırlar ve 160 sütunlar. Bu, en azından devrelere karşılık gelir. 500 RISC-V CPU'nun adım başına kapı sayısı. Yakın gelecekte daha fazla iyileştirme bekleniyor.

Çeşitli zkEVM projeleri (örneğin, zkSync 2.0, Scroll, Polygon'un zkEVM'si) sanal makineyi Ethereum Sanal Makinesi (duh) olarak kabul eder. Her EVM talimatını eşdeğer bir “gadget”a (yani, talimatı uygulayan optimize edilmiş bir devre) dönüştürme süreci, daha basit Kahire ve RISC-V mimarilerinden önemli ölçüde daha fazladır. Bu ve diğer nedenlerle, zkEVM projelerinden bazıları EVM komut setini doğrudan uygulamıyorlar, daha ziyade üst düzey Solidity programlarını devrelere dönüştürmeden önce diğer montaj dillerinde derliyorlar. Bu projelerin performans sonuçları beklemededir.

RISC-V ve Kahire gibi "CPU öykünücüsü" projeleri, ilgili montaj dilindeki tüm programları işleyebilen tek bir devre üretir. Alternatif yaklaşımlar, farklı programlar için farklı devreler üreten “ASIC-benzeri”dir. Bu ASIC-benzeri yaklaşım, özellikle programın her zaman adımında yürüttüğü montaj talimatı programın girdisine bağlı olmadığında, bazı programlar için daha küçük devreler sağlayabilir. Örneğin, saf matris çarpımı gibi düz çizgi programları için potansiyel olarak ön uç ek yükünü tamamen önleyebilir. Ancak ASIC yaklaşımı da oldukça sınırlı görünüyor; bildiğim kadarıyla, önceden belirlenmiş yineleme sınırları olmadan döngüleri desteklemek için nasıl kullanılacağı bilinmiyor. 

Ön uç ek yükünün son bileşeni, tüm SNARK'ların sonlu alanlar üzerinde çalışan devreler kullanması gerçeğinden gelir. Dizüstü bilgisayarınızdaki CPU, tek bir makine talimatıyla iki tamsayıyı çarpabilir veya ekleyebilir. Bir ön uç, yeterince büyük bir karakteristiğe sahip bir alan üzerinden bir devre çıkışı verirse, esasen ilgili alan işlemi aracılığıyla bu çarpma veya toplamayı simüle edebilir. Ancak, gerçek bir CPU üzerinde saha operasyonunun uygulanması, tipik olarak birçok makine talimatı gerektirecektir (ancak bazı modern işlemcilerin belirli alanlar için yerel desteği olmasına rağmen). 

Bazı SNARK arka uçları, diğerlerinden daha esnek alan seçenekleri sağlar. Örneğin, arka uç bir şifreleme grubu kullanıyorsa G, devrenin alanı, içindeki eleman sayısıyla eşleşmelidir. G, sınırlayıcı olabilir. Ayrıca, tüm alanlar pratik FFT algoritmalarını desteklemez. 

Uygulanan tek bir SNARK var, frenleme, bu, rastgele (yeterince büyük) alanlar üzerindeki hesaplamaları doğal olarak destekler. onunla birlikte torunları, diğer SNARK'ların desteklediği alanlarda bile bilinen en hızlı somut kanıtlama performansına sahiptir, ancak kanıtları şu anda birçok blok zinciri uygulaması için çok büyüktür. Son iş ispat boyutunu iyileştirmeye çalışır, ancak ispat asimptotik olarak daha yavaştır ve orada gibi görünmektedir engelleri pratiklik için.

Bazı projeler, özellikle hızlı aritmetik olan alanlar üzerinde çalışmayı seçmiştir. Örneğin, plonky2 ve diğerleri karakteristik 2 alanını kullanır⁶⁴ - 2³² + 1 çünkü bu alandaki aritmetik, daha az yapılandırılmış alanlara göre birkaç kat daha hızlı uygulanabilir. Bununla birlikte, bu kadar küçük bir özelliğin kullanılması, saha işlemleri yoluyla tam sayı aritmetiğinin verimli bir şekilde temsil edilmesinde zorluklara yol açabilir (örneğin, iki adet 32 ​​bitlik işaretsiz tam sayının çarpılması, alan karakteristiğinden daha büyük bir sonuç verebilir). 

 Ancak ne olursa olsun, günümüzde tüm popüler SNARK'ların 128 bit güvenlik elde edebilmesi için (doğrulama maliyetlerinde önemli bir artış olmadan), 2'den daha büyük bir alan üzerinde çalışmaları gerekir.¹²⁸. Anlayabildiğim kadarıyla bu, her saha operasyonunun en az on adet 64-bit makine çarpması ve önemli ölçüde daha fazla ekleme ve bitsel işlem gerektireceği anlamına geliyor. Bu nedenle, sonlu alanlar üzerinde çalışan devrelere duyulan ihtiyaç nedeniyle, en azından bir büyüklük sırasına göre ön uç ek yükü hesaba katılmalıdır. 

Özetlemek gerekirse, bir sanal makine soyutlaması kullanan mevcut ön uçlar, sanal makinenin her adımında 100x ila 1000x geçitli devreler üretir ve muhtemelen daha karmaşık sanal makineler için daha fazla. Bunun da ötesinde, sonlu alan aritmetiği, modern işlemcilerdeki benzer komutlardan en az 10 kat daha yavaştır (işlemcinin belirli alanlar için yerleşik desteği varsa olası istisnalar dışında). Bir "ASIC ön uç yaklaşımı" bu genel giderlerin bir kısmını azaltabilir, ancak şu anda destekleyebileceği program türleriyle sınırlıdır.

Arka uç darboğazları nelerdir?

Devre tatmini için SNARK'lar tipik olarak "" olarak adlandırılan bilgi-teorik olarak güvenli bir protokolü birleştirerek tasarlanmıştır.polinom GİB” olarak adlandırılan bir şifreleme protokolü ilepolinom taahhüt şeması” Çoğu durumda, ispat için somut darboğaz, polinom taahhüt şemasıdır. Özellikle, bu SNARK'lar, derecesi (en azından) olan bir veya daha fazla polinomu kriptografik olarak taahhüt eder. |C|, devredeki kapı sayısı C. 

Buna karşılık, polinom taahhüt şemasındaki somut darboğaz, kullanılan şemaya ve devre boyutuna bağlı olacaktır. Ancak her zaman şu üç işlemden biri olacaktır: FFT'lerin hesaplanması, bir kriptografik gruptaki üsler veya Merkle-karma. Merkle hashing, yalnızca devre küçükse tipik olarak bir darboğazdır, bu yüzden daha fazla tartışmayacağız. 

Ayrık günlüğe dayalı polinom taahhütleri

Bir kriptografik grupta ayrık logaritma probleminin sertliğine dayalı polinom taahhütlerinde G (KZG, Bulletproofs, dülgerbalığı, ve Hyrax-taahhüt), kanıtlayıcı bir hesaplamak zorundadır Pedersen vektör taahhüdü polinomun katsayıları. Bu, polinomun derecesine eşit büyüklükte bir çoklu üstelleştirmeyi içerir. SNARK'larda bu derece tipik olarak boyuttur. |C| devrenin C.

Saf bir şekilde yapıldı, boyutun çok üslü |C| yaklaşık 1.5 gerektirir·|C|·log |G| ≈ 400·|C| grup operasyonları, nerede |G| gruptaki eleman sayısını belirtir G. Bununla birlikte, bunu kabaca log faktörü ile azaltabilen Pippenger algoritması adı verilen bir yaklaşım vardır. |C|. Büyük devreler için (örneğin, |C| ≥ 225), bu günlük |C| faktör somut olarak 25 veya daha fazla olabilir, yani büyük devreler için Pedersen vektör taahhüdünün 10'un biraz üzerinde hesaplanabilir olmasını bekliyoruz.·|C| grup işlemleri. Sırayla her grup operasyonu (çok kaba bir oyun sahası olarak) sonlu bir saha operasyonundan yaklaşık 10 kat daha yavaş olma eğilimindedir. Bu polinom taahhütlerini kullanan SNARK'lar, P yaklaşık 100·|C| saha operasyonları. 

Ne yazık ki, mevcut SNARK'ların yukarıdaki 100x faktörünün üzerine ek genel giderleri vardır. Örneğin:

• SpartalıHyrax polinom taahhüdünü kullanan ispatlayıcının yapması gerekenler |C|^½ her boyutta birçok çoklu üs |C|^½, Pippenger'ın algoritmasından gelen hızlanmayı kabaca iki kat zayıflatıyor. 
• In Groth16, P operasyonları genellikle eşleştirme dostu olmayan gruplardan en az 2 kat daha yavaş olan eşleştirme dostu bir grup üzerinde çalışmalıdır. P ayrıca 3 yerine 1 çoklu üs gerçekleştirmelidir. Kombine, bu 6'e göre en az ek faktör-100 yavaşlamasına neden olur.·|C| yukarıdaki tahmin. 
• Atlantik kılıçbalığı ve PlonK ayrıca eşleştirmeleri ve kanıtlayıcılarının 3'ten fazla polinomu önemli ölçüde taahhüt etmesini gerektirir. 
• kullanan herhangi bir SNARK için Bulletproofs (Örneğin, Halo2kabaca PlonK olan ancak KZG polinom taahhütleri yerine Bulletproofs ile), ispatlayıcı taahhüt şemasının “açılış” aşaması sırasında logaritmik olarak birçok çoklu üs hesaplaması yapmak zorundadır ve bu, herhangi bir Pippenger hızlandırmasını büyük ölçüde siler. 

Özetle, Pedersen vektör taahhütlerini kullanan bilinen SNARK'lar, en az 200x ve en fazla 1000x veya daha fazla arka uç ek yüküne sahip görünüyor. 

Diğer polinom taahhütleri

Diğer polinom taahhütlerini kullanan SNARK'lar için (örneğin ÜCRETSİZ ve Ligero-taahhüt), darboğaz, kanıtlayıcının büyük FFT'ler gerçekleştirmesi gerektiğidir. Örneğin, Kahire tarafından üretilen 2. derece AIR'lerde (51 sütun ve T satırlar, Kahire CPU'sunun her adımı için bir tane), StarkWare'in konuşlandırılmış kanıtlayıcısı, sütun başına en az 2 FFT yapar, aralarında uzunluk 16 ·T ve 32 ·T. sabitler 16 ve 32 StarkWare tarafından belirlenen FRI'nin dahili parametrelerine bağlıdır ve azaltılabilir - ancak artan doğrulama maliyetleri pahasına. 

İyimser olarak, 32 uzunluğunda bir FFT·T yaklaşık 64 sürer·T·günlük(32T) alan çarpımları. Bu, nispeten küçük değerler için bile T (Örneğin, T ≥ 2²⁰), sütun başına saha operasyonlarının sayısı en az 64·25·T= 1600·T. Yani arka uç ek yükü en azından binlerde görünüyor. Ayrıca, büyük FFT'lerin, alan operasyonlarından ziyade bellek bant genişliği nedeniyle daha fazla darboğaz yaşaması mümkündür. 

Bazı bağlamlarda, büyük FFT'ler gerçekleştiren SNARK'ların arka uç yükü, kanıt toplama adı verilen bir teknikle hafifletilebilir. Toplamalar için bu şu anlama gelir: P (toplama hizmeti) büyük bir toplu işlemi, örneğin 10 küçük toplu işlere böler. Her küçük parti için i, P bir SNARK kanıtı üretir πi partinin geçerliliği. Fakat P Bu kanıtları Ethereum'a göndermez, çünkü bu, gaz maliyetlerinde yaklaşık 10 kat artışa yol açacaktır. Bunun yerine, bu sefer bir kanıt üretmek için SNARK tekrar uygulanır. π bunu kurmak P bilir π₁ , ...,π₁₀. Yani tanık olan P bildiğini iddia etmek on kanıttır π₁,…,π₁₀ve doğrudan tanık kontrolü, kanıtların her birine SNARK doğrulama prosedürünü uygular. Bu tek kanıt π Ethereum'a gönderildi. 

FRI ve Ligero-commit gibi polinom taahhütlerinde, aralarında güçlü bir gerilim vardır. P Zaman ve V Birini diğeriyle takas edebilen bir topuz görevi gören dahili parametrelerle birlikte maliyetler. Dan beri π₁ ,…,π₁₀ Ethereum'a gönderilmez, düğme ayarlanabilir, böylece bu kanıtlar büyüktür ve onları üretmek daha hızlıdır. Yalnızca SNARK'ın son uygulamasında, bir araya getirmek için π₁ ,…,π₁₀ tek bir kanıta π, taahhüt şemasının küçük bir kanıt sağlamak için yapılandırılması gerekiyor mu? 

StarkWare kanıt toplamayı dağıtmayı planlıyor yakında. Bu aynı zamanda gibi projelerin odak noktasıdır. plonky2.

SNARK ölçeklenebilirliğinin diğer darboğazları nelerdir?

Bu gönderi kanıtlamaya odaklandı zaman, ancak diğer kanıtlama maliyetleri de ölçeklenebilirlik darboğazları olabilir. Örneğin, birçok SNARK arka ucu için, kanıtlayıcının her bir kapı için birkaç alan öğesini depolaması gerekir. Cve bu alan maliyeti çok büyük olabilir. Örneğin, bir program ψ bir dizüstü bilgisayarda bir saniyede çalışmak, modern bir işlemcide belki bir milyar ilkel işlemi gerçekleştirebilir. Gördüğümüz gibi, genel olarak beklenmelidir C böyle bir işlem başına 100'den fazla kapı gerektirmek. Bu, SNARK'a bağlı olarak, SNARK'a bağlı olarak onlarca veya yüzlerce terabaytlık alan anlamına gelebilecek 100 milyar kapı anlamına gelir. P. 

Başka bir örnek: birçok popüler SNARK (örn. PlonK, Atlantik kılıçbalığı, Groth16) yapılandırılmış bir "kanıtlama anahtarı" oluşturmak için karmaşık bir "güvenilir kurulum töreni" gerektirir. hangi kanıtlayıcı tarafından saklanmalıdır. Bildiğim kadarıyla, bu tür en büyük tören yaklaşık 2 ile devreleri destekleyebilen bir kanıtlama anahtarı üretti²⁸≈250 milyon kapı. Kanıtlama anahtarı, birkaç düzine gigabayt boyutundadır. 

Kanıt toplamanın mümkün olduğu bağlamlarda, bu darboğazlar büyük ölçüde azaltılabilir. 

İleriye bakmak: daha ölçeklenebilir SNARK'lar için beklentiler

Hem ön uç hem de arka uç genel giderleri, üç veya daha fazla büyüklük sırası olabilir. Bunların yakın gelecekte önemli ölçüde düşmesini bekleyebilir miyiz? 

Sanırım yapacağız - bir noktaya kadar. Birincisi, günümüzdeki en hızlı arka uçlar (ör. Spartalı ve frenlemeve diğer SNARK'ları birleştiren toplam kontrol protokolü polinom taahhütleri ile) büyük kanıtlara sahiptir - tipik olarak devrenin boyutunda karekök - bu nedenle insanlar onları gerçekten kullanmıyor. Küçük geçirmez SNARK'lara sahip bir derinlik kompozisyonu yoluyla kanıt boyutunun ve doğrulayıcı süresinin yakın gelecekte anlamlı bir şekilde azalmasını bekliyorum. Kanıt toplamaya benzer şekilde, bu, bir kanıtlayıcının önce bir SNARK kanıtı üreteceği anlamına gelir. π "hızlı kanıtlayıcı, geniş kapsamlı" SNARK ile, ancak gönderilmez π için V. Daha doğrusu, P bir kanıt üretmek için küçük bir SNARK kullanırdı π' bildiği π, ve gönder π' için V. Bu, bugün popüler olan SNARK'ların arka uç genel giderlerini büyük ölçüde azaltabilir. 

İkincisi, donanım hızlandırma yardımcı olabilir. Çok kaba bir genel kural, GPU'ların CPU'lara göre 10 kat hızlanma ve ASIC'lerin GPU'lara göre 10 kat hızlanma satın alabilmesidir. Ancak, bu cephede üç endişem var. İlk olarak, büyük FFT'ler saha operasyonları yerine bellek bant genişliği tarafından darboğaz yapabilir, bu nedenle bu tür FFT'leri gerçekleştiren SNARK'lar özel donanımdan sınırlı hızlanmalar görebilir. İkincisi, bu gönderi polinom bağlılığı darboğazına odaklanırken, birçok SNARK, kanıtlayıcının yalnızca biraz daha ucuz olan diğer işlemleri yapmasını gerektirir. Böylece polinom taahhüt darboğazını kırmak (örn. çoklu üsleri hızlandırmak ayrık günlük tabanlı SNARK'larda), eskisinden çok daha iyi olmayan yeni bir darboğaz işlemi bırakabilir. (Örneğin, Groth16, Marlin ve PlonK dahil SNARK'lar ayrıca çoklu üslere ek olarak kanıtlanmış FFT'lere sahiptir.) Son olarak, en verimli SNARK'lara yol açan alanlar ve eliptik eğriler bir süre daha gelişmeye devam edebilir ve bu, ASIC tabanlı kanıtlayıcı hızlandırma için zorluklar yaratabilir.

Ön uç tarafında, Kahire, RISC Zero, zkEVM'ler ve diğerleri gibi projelerin “CPU öykünücüsü” yaklaşımının, CPU komut setlerinin karmaşıklığı ile gerçekten (performans açısından) oldukça iyi ölçeklendiğini giderek daha fazla görebiliriz. Aslında, bu tam olarak çeşitli zkEVM projelerinin umududur. Bu, ön uç ek yükü üç veya daha fazla büyüklük sırası kalırken, ön uçların gerçek CPU mimarileriyle giderek daha fazla eşleşen VM'leri desteklemeyi başardığı anlamına gelebilir. Telafi edici bir endişe, giderek daha karmaşık talimatları uygulayan elle kodlanmış gadget'lar çoğaldıkça, ön uçların karmaşık hale gelmesi ve denetlenmesinin zorlaşmasıdır. Resmi doğrulama yöntemleri, bu endişenin ele alınmasında büyük olasılıkla önemli bir rol oynayacaktır. 

Son olarak, en azından blok zinciri uygulamalarında, doğada ortaya çıkan akıllı sözleşmelerin çoğunun temel olarak basit, SNARK dostu talimatlar kullandığını görebiliriz. Bu, Solidity gibi yüksek seviyeli programlama dillerini ve EVM'ninkiler de dahil olmak üzere zengin talimat setlerini desteklemekle birlikte gelen genelliği ve gelişmiş geliştirici deneyimini korurken pratikte düşük ön uç genel giderlerini sağlayabilir. 

***

Justin Thaler is Georgetown Üniversitesi'nde Doçent. Georgetown'a katılmadan önce, New York'taki Yahoo Labs'da Araştırma Bilimcisi olarak iki yıl geçirdi ve öncesinde Simons Bilgisayar Teorisi Enstitüsü UC Berkeley'de. 

***

Teşekkür: minnettarım Elena Burger bu yazının konusunu önerdiğiniz için ve Arasu Arun, Joseph Bonneau, ve Sam Ragsdale anlayışlı yorumlar için Editörüme ayrıca teşekkürler, Tim Sullivan.

***

Burada ifade edilen görüşler, alıntı yapılan bireysel AH Capital Management, LLC (“a16z”) personelinin görüşleridir ve a16z veya iştiraklerinin görüşleri değildir. Burada yer alan belirli bilgiler, a16z tarafından yönetilen fonların portföy şirketleri de dahil olmak üzere üçüncü taraf kaynaklardan elde edilmiştir. a16z, güvenilir olduğuna inanılan kaynaklardan alınmış olsa da, bu tür bilgileri bağımsız olarak doğrulamamıştır ve bilgilerin kalıcı doğruluğu veya belirli bir duruma uygunluğu hakkında hiçbir beyanda bulunmaz. Ayrıca, bu içerik üçüncü taraf reklamlarını içerebilir; a16z, bu tür reklamları incelememiştir ve burada yer alan herhangi bir reklam içeriğini onaylamaz.

Bu içerik yalnızca bilgilendirme amaçlıdır ve yasal, ticari, yatırım veya vergi tavsiyesi olarak kullanılmamalıdır. Bu konularda kendi danışmanlarınıza danışmalısınız. Herhangi bir menkul kıymete veya dijital varlığa yapılan atıflar yalnızca açıklama amaçlıdır ve yatırım tavsiyesi veya yatırım danışmanlığı hizmetleri sağlama teklifi teşkil etmez. Ayrıca, bu içerik herhangi bir yatırımcıya veya muhtemel yatırımcılara yönelik değildir veya bu içerik tarafından kullanılması amaçlanmamıştır ve a16z tarafından yönetilen herhangi bir fona yatırım yapma kararı verilirken hiçbir koşulda bu içeriğe güvenilemez. (Bir a16z fonuna yatırım yapma teklifi, yalnızca tahsisli satış mutabakatı, abonelik sözleşmesi ve bu tür bir fonun diğer ilgili belgeleri ile yapılacaktır ve bunların tamamı okunmalıdır.) Bahsedilen, atıfta bulunulan veya atıfta bulunulan herhangi bir yatırım veya portföy şirketi veya a16z tarafından yönetilen araçlara yapılan tüm yatırımları temsil etmemektedir ve yatırımların karlı olacağına veya gelecekte yapılacak diğer yatırımların benzer özelliklere veya sonuçlara sahip olacağına dair hiçbir garanti verilemez. Andreessen Horowitz tarafından yönetilen fonlar tarafından yapılan yatırımların bir listesi (ihraççının a16z'nin kamuya açıklanmasına izin vermediği yatırımlar ve halka açık dijital varlıklara yapılan habersiz yatırımlar hariç) https://a16z.com/investments adresinde bulunabilir. /.

İçerisinde yer alan çizelgeler ve grafikler yalnızca bilgilendirme amaçlıdır ve herhangi bir yatırım kararı verirken bunlara güvenilmemelidir. Geçmiş performans gelecekteki sonuçların göstergesi değildir. İçerik yalnızca belirtilen tarih itibariyle konuşur. Bu materyallerde ifade edilen tüm tahminler, tahminler, tahminler, hedefler, beklentiler ve/veya görüşler önceden bildirilmeksizin değiştirilebilir ve farklı olabilir veya başkaları tarafından ifade edilen görüşlere aykırı olabilir. Ek önemli bilgiler için lütfen https://a16z.com/disclosures adresine bakın.