SNARK Güvenlik ve Performans

SNARK (Özlü, Etkileşimli Olmayan Bilgi Argümanı), sistem tasarımında, özellikle merkezi olmayan ortamlarda heyecan verici yeni olasılıklar açan bir şifreleme aracıdır. SNARK'lar, verilerin geçerli olduğunu ve doğru şekilde işlendiğini kanıtlayabilen güvenilmeyen kuruluşlar tarafından verilerin işlenmesine izin verir. Bunu kanıtlamanın naif bir yolu, verileri yayınlamak, isteyen herkesin geçerliliğini kontrol etmesine ve doğrudan işlemesine izin vermek olacaktır. 

Bir SNARK aynı etkiyi sağlar, ancak daha iyi maliyetledoğrulayıcılara s. Örneğin, ikinci katman (L2) doğrulanabilir bir toplamada, bir toplama hizmeti blok zinciri işlemlerini işler. Hizmet, kullanıcılarının hesap bakiyelerini periyodik olarak birinci katman blok zincirine gönderir. Bakiyelere her güncelleme gönderdiğinde, eski hesap bakiyelerini güncellenmiş bakiyelerle değiştiren bir dizi geçerli işlemi bildiğine dair bir SNARK kanıtı ekler. Bu şekilde, blok zinciri doğrulayıcıları, işlem geçerliliğini kontrol etmek (örneğin, her işlem için bir dijital imzayı kontrol etmek) gibi zor işleri yapmak veya güncellenmiş bakiyeleri hesaplamak için işlemleri açıkça işlemek zorunda kalmazlar.  

My önceki yazı SNARK uygulanabilirliğinin birincil belirleyicisi olan SNARK kanıtlayıcılarının performansına odaklanmıştır. Bir SNARK kanıtlayıcıyı çalıştırmak, büyük ölçekli hesaplamalar için bir kanıt oluşturmanın mümkün olmadığı ölçüde, hesaplama açısından yoğun olabilirken, SNARK doğrulaması, verileri doğrudan kontrol etmekten ve işlemekten genellikle çok daha ucuzdur. Ancak, SNARK doğrulama maliyetleri önemli ölçüde farklılık gösterir. Bu gönderi, bu maliyetleri ortaya çıkarır ve farklı SNARK'ların güvenlik özelliklerini karşılaştırır. 

Özellikle, makul post-kuantum güvenliği (PQ-SNARK'lar) olan pratik SNARK'larda, güvenlik ve doğrulama maliyetleri arasında önemli bir gerilim olduğunu açıklıyorum. Ayrıca, bazı durumlarda, bu gerilim şu anda güvenlik yerine doğrulama maliyetleri lehine çözülmektedir.

SNARK'ların potansiyellerini gerçekleştirmeleri için konuşlandırılmış sistemlerin güvenli olması ve kullanıcıların güvenliklerinden emin olmaları gerekir. Bu özelliklerin uzun vadede korunmasına yardımcı olmak için web3 topluluğunun yapabileceği basit eylemler önererek yazıyı sonlandırıyorum. 

Nicel güvenlik önlemleri 

Bir SNARK, yanlış bir ifadenin inandırıcı bir kanıtını üretmek hesaplama açısından mümkün değilse güvenlidir. Örneğin, L2 özetleri bağlamında, fonlarımı çalmak isteyen bir saldırgan, "Justin'in tüm varlıklarını kendi hesabıma aktaran dijital olarak imzalanmış bir işlem biliyorum" şeklindeki yanlış bir beyanı kanıtlamak isteyecektir. 

Bir SNARK'ın güvenlik seviyesi, yanlış bir ifadenin ikna edici bir kanıtını bulmak için yapılması gereken iş miktarıyla ölçülür. Dijital imzalar gibi diğer kriptografik ilkellere benzer şekilde, bu miktardaki çalışmanın logaritmasına "güvenlik bitleri" denir. Örneğin, 30 bit güvenlik, 2³⁰ ≈ SNARK'a saldırmak için 1 milyar "iş adımı" gerekiyor. Bu, doğası gereği, gerçek dünya güvenliğinin yaklaşık bir ölçüsüdür, çünkü işin bir adımı kavramı değişebilir ve bellek gereksinimleri veya paralellik fırsatları gibi pratik hususlar dikkate alınmaz.

ve kaliteli olanlar

Güvenlik bitleri bir nicel bir SNARK'ın güvenlik ölçüsü. SNARK'lar ayrıca nitel güvenlik özellikleri. 

Örneğin, bazı SNARK'lar, yapılandırılmış bir kanıtlama anahtarı oluşturmak için güvenilir bir kurulum töreni gerektirir. Güvenilir bir kurulum gerektirmeyen SNARK'lar denir şeffaf. 

Saydam olmayan bir SNARK'ın güvenli olması için, tipik olarak törendeki en az bir katılımcının dürüst davranmış olması gerekir, yani diğer tüm katılımcıların kapaklarıyla birleştirilirse, bunu kolaylaştıracak bir "kapalı kapı" üretip daha sonra atmış olmalıdır. herhangi bir yanlış ifadenin ikna edici SNARK "kanıtlarını" bulmak için. Güvenilir kurulumlar olmak koşmak Bu varsayımı olabildiğince hafif kılmak için yüzlerce veya binlerce katılımcıyla. 

SNARK'lar ayrıca kuantum saldırılarına karşı duyarlılıklarında da farklılık gösterir. Spesifik olarak, birçok SNARK (örn. Groth16, PlonK, Atlantik kılıçbalığı, Bulletproofs, yeni) ayrık logaritmaların hesaplanmasının zor olduğu varsayımına dayanır (ve bazı durumlarda ek varsayımlar da). Ayrık logaritmaların hesaplanması, kuantum bilgisayarların verimli bir şekilde yapabileceği bir şeydir. Bu nedenle, bu SNARK'lar kuantum sonrası güvenli değildir (PQ dışı). 

Post-kuantuma geçmek için acil çabalar sürerken şifreleme şemaları, bu öncelikle şifreli mesajların uzun yıllar boyunca gizli tutulması ihtiyacından kaynaklanmaktadır. Bugün ele geçirilen bir mesajı depolayan ve diyelim ki elli yıl içinde bir kuantum bilgisayarın gelmesini bekleyen bir düşman, bilgisayarı elli yıllık mesajın şifresini çözmek için kullanabilir. SNARK'larda durum oldukça farklıdır. Bugün PQ olmayan SNARK'ların kullanımı, kuantum bilgisayarlar o zamana kadar gelse bile, elli yıl sonra blok zincirlerinin güvenliğini tehlikeye atmamalıdır. 

polinom taahhütleri

Tüm SNARK'lar, olarak bilinen bir şifreleme ilkelini kullanır. polinom taahhüt şeması, ve bu bileşen genellikle bir performans darboğazıdır. (Ayrıntılar için bkz. önceki yazı.) Ek olarak, bir SNARK'ın şeffaflığı ve makul kuantum sonrası güvenliği, yalnızca kullandığı polinom taahhüt şeması tarafından belirlenir. 

Öne çıkan bir örnek sözde KZG polinom taahhütleritarafından kullanılan PlonK, Atlantik kılıçbalığı, Ve bircok digerleri. KZG taahhütleri ne şeffaf ne de kuantum sonrası güvenlidir. Diğer taahhüt şemaları şeffaftır ancak kuantum sonrası değildir. Bulletproofs, Yaban faresi, ve dülgerbalığı. 

Yine de diğer şemalar hem şeffaf hem de makul bir şekilde kuantum sonrasıdır. Bunlar şunları içerir: ÜCRETSİZ, ışık, Ligero++, frenleme, ve Oryon. Bu şemaların tümü, hata düzeltme kodlarına dayanmaktadır. Hashing, kullandıkları tek kriptografik ilkeldir. Ayrıca şu özelliği paylaşırlar: doğrulama maliyetleri (karma değerlendirmelerin ve saha operasyonlarının sayısıyla ölçülür) güvenlik bitlerinin sayısıyla doğrusal olarak büyür.

Kabaca söylemek gerekirse, bu kuantum sonrası polinom taahhütlerinin tek bir "yinelemesi", yalnızca küçük bir sayıda (diyelim ki 2-4) bit güvenlik sağlar. Bu nedenle, güvenlik düzeyini "güçlendirmek" için protokolün birçok kez tekrarlanması gerekir ve doğrulama maliyetleri her tekrarda artar. Bu nedenle, PQ-SNARK'lardaki doğrulama maliyetlerini (ve dolayısıyla blok zinciri uygulamalarındaki gaz maliyetlerini) kontrol etmek için protokol tasarımcıları güvenlik seviyesini düşük tutmaya teşvik edilir. 

Nadir ile istisnalar, somut güvenlik ve doğrulama maliyetleri arasındaki bu gerilim, PQ olmayan SNARK'larda (hem şeffaf hem de şeffaf olmayan) ortaya çıkmaz. PQ-SNARK olmayanlar, ayrı logaritmaların hesaplanmasının zor olduğu ve güvenlik seviyelerinin kullanılan grup tarafından belirlendiği eliptik eğri grupları kullanır. Uygun eliptik eğri grubunun boyutu ve dolayısıyla her bir grup işleminin maliyeti, istenen güvenlik seviyesi ile birlikte büyür. Ancak numara Bir ispattaki grup elemanlarının sayısı grup seçiminden bağımsızdır. 

PQ-SNARK'larda, yalnızca istenen güvenlik düzeyiyle birlikte karma değerlendirmelerin boyutu doğrusal olarak büyümekle kalmaz, aynı zamanda kanıta dahil edilen ve doğrulayıcı tarafından gerçekleştirilen değerlendirmelerin sayısı da artar. 

Dağıtılan SNARK'larda somut doğrulayıcı maliyetleri ve güvenlik

Dağıtılan SNARK'ların somut doğrulayıcı maliyetleri ve güvenlik seviyeleri önemli ölçüde farklılık gösterir. İşte bazı açıklayıcı örnekler:

Doğrulayıcı maliyetleri 

My önceki yazı somut doğrulama maliyetlerine ilişkin iki örnekten bahsetti: PlonK kanıt maliyeti altında 300,000 gaz StarkWare'in kanıtları yaklaşık 5 milyon gaza mal olurken, Ethereum üzerinde doğrulamak için. StarkWare'in kanıtları şeffaftır ve PlonK'lar değilken makul bir şekilde kuantum sonrasıdır. Bununla birlikte, aşağıda ayrıntılı olarak açıklandığı gibi, StarkWare'in kanıtları, Ethereum'daki PlonK kanıtlarından çok daha düşük bir güvenlik seviyesinde çalıştırılıyor.

beton güvenlik

Ethereum ön derlemelerine sahip tek eliptik eğriye altbn128 adı verilir, bu nedenle Ethereum kullanımında dağıtılan tüm PQ olmayan SNARK'ların eğrisi budur. Aztek's ve zkSync's. Bu eğri - ve dolayısıyla onu kullanan konuşlandırılmış SNARK'ların - başlangıçta kabaca 128 bit güvenlik sunduğuna inanılıyordu. Ama nedeniyle geliştirilmiş saldırılar (kesin çalışma süresi belirlenmesi zor), eğrinin artık 100 ila 110 bit güvenlik sunduğu yaygın olarak kabul edilmektedir. 

EIP'ler var altında dikkate 128 bit'e yakın güvenlik sunduğuna inanılan farklı eğriler için ön derlemeler sunmak. Bu tür eğriler çoktan kullanıldı ZCash, Algorand, Dfinity, Filecoin ve Aleo dahil olmak üzere Ethereum dışı projelerin SNARK'larında. 

Buna karşılık, zincir üzerindeki verilere göre, StarkWare'in PQ-SNARK'ları (SHARP sisteminde, SHARed Prover'ın kısaltması) 80 bit güvenliği hedefleyecek şekilde yapılandırılmıştır. Bu güvenlik seviyesi, FRI'nin istatistiksel sağlamlığı hakkında (bu yazının ilerleyen bölümlerinde ele alacağım) belirli varsayımlar altında geçerlidir. 

"80 bit güvenlik" terimi bu bağlamda belirsiz, bu yüzden onu açmama izin verin. Kabaca söylemek gerekirse, bir saldırganın bir hash fonksiyonunu 2 değerlendirerek yanlış bir ifadenin ikna edici bir kanıtını üretebileceği anlamına gelir.⁸⁰ kez (yani KECCAK-256, Ethereum tarafından kullanılan karma işlevi). Daha kesin olmak gerekirse, 2 gerçekleştirmeye istekli bir saldırgan^k karma değerlendirmeler, kabaca 2 olasılıkla ikna edici bir kanıt üretebilir^k-80. Örneğin, 2 ile⁷⁰ karma değerlendirmeler, yaklaşık 2 olasılıkla yanlış bir ifadenin SNARK “kanıtı” bulunabilir.^-10 = 1 / 1024. 

Bu kavram, "80 bit güvenlik" teriminin diğer bağlamlarda ne anlama geldiğinden daha zayıftır. Örneğin, 80 bit güvenlik için yapılandırılmış bir çarpışmaya dayanıklı karma işlevi (CRHF'ler), 160 bit çıktılar üretecektir. Karma işlevi iyi tasarlanmışsa, en hızlı çarpışma bulma prosedürü, Doğum günü saldırısı, yaklaşık 2 ile bir çarpışma bulabilen bir kaba kuvvet prosedürü^160/2 = 2⁸⁰ hash değerlendirmeleri Ancak 2 ile^k hash değerlendirmeleri, Doğum günü saldırısı sadece 2 olasılığı olan bir çarpışma bulacak^2k-160. 

Örneğin, 2⁷⁰ hash değerlendirmeleri, 2 olasılığı olan bir çarpışmaya yol açacaktır.^-20  ≈ 1/1,000,000. Bu, bir saldırganın 1 bit güvenlikle yapılandırılmış bir PQ-SNARK kanıtı oluşturmasının 1,000/80 olasılığından çok daha küçüktür. 

Bu fark, bir saldırı gerçekleştirmenin çekiciliğini büyük ölçüde değiştirebilir. Örneklemek gerekirse, bir saldırganın 100$'lık bir bütçeye sahip olduğunu ve bunun 2 adet satın alabileceğini hayal edin.⁷⁰ hash değerlendirmeleri Saldırganın başarılı olması durumunda getirisinin 200 milyon dolar olduğunu varsayalım. 80 bit güvenlikle yapılandırılmış bir PQ-SNARK'a yönelik saldırının beklenen değeri (1/1,000) * 200 milyon ABD Doları veya 200 ABD Doları - maliyetin iki katıdır. Bir CRHF'de olduğu gibi başarı olasılığı yalnızca 1/1,000,000 olsaydı, saldırının beklenen değeri yalnızca 200 dolar olurdu. 

İki "80 bit güvenlik" kavramı, bağımsız saldırılara karşı sağlamlıkları açısından da önemli ölçüde farklılık gösterir. Örneğin, 1,000 bağımsız tarafın her birinin 2 eylem gerçekleştirerek PQ-SNARK'a saldırdığını varsayalım.⁷⁰ hash değerlendirmeleri Her biri yaklaşık 1/1,000 olasılıkla başarılı olduğundan, en az birinin başarılı olma olasılığı oldukça yüksektir. Her biri sadece 1/1,000,000 olasılıkla başarılı olsaydı durum böyle olmazdı.

İyi tasarlanmış eliptik eğri gruplarının, doğum günü benzeri saldırılarla CRHF'lere benzer şekilde davranması beklenir. Pollard'ın rho algoritması en iyi bilinen olmak. Bu, 128 bit güvenlik sunan bir grupta 2^k grup işlemleri, yalnızca 2 olasılıkla ayrık logaritma probleminin bir örneğine bir çözüm vermelidir.^2k-256. Örneğin, 2⁷⁰ grup işlemleri, yalnızca astronomik olarak küçük bir olasılıkla 2 olan ayrık bir logaritma bulur.^-116. Ayrıca, her grup işlemi bir CRHF değerlendirmesinden daha yavaştır. 

Bugün kaç tane hash değerlendirmesi yapılabilir?

Ocak 2020'de, hesaplama maliyeti 2'nin biraz altında⁶⁴ GPU'ları kullanan SHA-1 değerlendirmeleri $45,000. Bu maliyeti 2 koyar⁷⁰ GPU'lar üzerinde birkaç milyon dolarlık SHA-1 değerlendirmeleri (GPU'nun baskın olduğu iş kanıtı madenciliğinden geçiş muhtemelen GPU hesaplama talebini azaltacağından, maliyetini düşüreceğinden, Ethereum birleşmesinden sonra daha düşük olabilir). 

Kullanıcı fonlarında yüz milyonlarca dolar depolayan geçerlilik özetleri ile, yanlış bir ifadenin ikna edici bir kanıtını bulmak, milyonlarca dolar kâr sağlayabilir. Agresif varsayımlar altında 80 bit güvenlikte bir PQ-SNARK'ı yapılandırmak, kârlı saldırılar ile PQ-SNARK'ın varsayılan güvenliği arasında 10 bit'in altında bir boşluk bırakır.

Başka bir veri noktası olarak, Bitcoin'in ağ hash oranı şu anda yaklaşık 2'dir.⁶⁴  saniye başına hash değerlendirmeleri, yani bitcoin madencileri bir bütün olarak 2 gerçekleştirir⁸⁰ Her 256 saatte bir SHA-18 değerlendirmeleri. Tabii ki, bu göz kamaştırıcı sayı, bitcoin madenciliği için ASIC'lere yapılan büyük yatırımdan kaynaklanmaktadır. 

Varsayarsak altı bitcoin bloğu saatte oluşturulan ve blok başına 6.25 Bitcoin'lik mevcut blok ödülü verildiğinde, bu 2⁸⁰ SHA-256 değerlendirmelerinin maliyeti muhtemelen 22,000 * 18 * 6 * 6.25 ≈ 15 milyon dolardan daha azdır. Aksi takdirde, bitcoin madenciliği mevcut fiyatlarla karlı olmaz. 

Sağlıklı bir ekosistem için önerilen eylemler

SNARK'ları toplamalarda kullanmanın tüm amacı, kullanıcıların toplama hizmetine körü körüne güvenmelerine gerek kalmadan blok zinciri ölçeklenebilirliğini elde etmektir. Toplama hizmeti, SNARK doğrulayıcı olarak işlev gören akıllı sözleşmeyi yazdığından, halkın sözleşmeyi inceleyebilmesi ve gerçekten de uygun ifadelerin SNARK kanıtlarını doğruladığını onaylayabilmesi gerekir. Özetleme hizmetinin kendi kullanıcılarını sansürleyemediğinden emin olmak için akıllı sözleşmenin kamu tarafından incelenmesi de gerekli olabilir. Sansür direnci için önerilen yöntemler, toplama hizmetinin işlemlerini gerçekleştirememesi durumunda kullanıcıların fonlarını geri çekmeye zorlamalarına izin vermek için toplamanın akıllı sözleşmesini gerektirir. 

Bu protokollerin karmaşık doğası göz önüne alındığında, bu kamu denetimi paradigması, konuşlandırılan sözleşmelerin güvenliğini açık ve samimi bir şekilde tartışmak için uzmanlara bir miktar yük getirmektedir. 

Ancak PQ-SNARK'larda, bu SNARK'lar için güvenlik ve doğrulayıcı performansının gergin olmasıyla aynı nedenden dolayı uzmanların konuşlandırılan protokolün güvenlik seviyesini tespit etmesi bile zor olabilir: güvenlik seviyesi (ve doğrulayıcı maliyetleri), sistemin dahili parametrelerine bağlıdır. SNARK. Ve en azından StarkWare için akıllı sözleşmeler, bu parametreler, called logBlowupFactor, ​proofOfWorkBits ve n_Queries, akıllı sözleşmenin kodunda doğrudan belirtilmez, bunun yerine akıllı sözleşmeye genel veriler olarak iletilir. Bildiğim kadarıyla, zincir üzerindeki bilgilerden bu parametreleri tanımlamanın en kolay yolu dört aşamalı bir işlemdir: 

1. görüntüle uygun akıllı sözleşme Etherscan gibi bir blok gezgininde, 
2. bir tıklayın uygun “kanıt doğrulama” işlemi, 
3. işlemin giriş verilerinin kodunu çözmek ve
4. nasıl yapılacağını bul yorumlamak birlikte güvenlik seviyesini belirleyen anahtar SNARK parametrelerini öğrenmek için kodu çözülen giriş verileri. 

Bu son adım, işlemi uygulayan uygun Solidity kodunu bulmayı gerektirir, bu da başlı başına kafa karıştırıcı bir görev olabilir. (Hazırlanırken anket görüşmeler Bu yaz toplamalarda, Etherscan, yukarıdaki 2. Adıma göre SHARP doğrulayıcı işlemlerine ilişkin girdi verilerinin kodunu çözmeyi başardı. Ancak bu artık çalışmıyor gibi görünüyor.)

Öneri 1: İnceleme 

Bunu akılda tutarak, web3 topluluğuna ilk önerim, dağıtılan kuantum sonrası SNARK'ların güvenlik düzeyini incelemeyi çok daha kolay hale getirmektir. Bu muhtemelen, zincir üzerindeki verileri anlamak için daha iyi araçlar ve bu parametreleri bilinir hale getirirken projelerin kendileri tarafından artan şeffaflığı içerir. 

Öneri 2: Daha güçlü normlar

80 bit güvenlik çok düşük, özellikle 2'nin bulunduğu zayıf sürüm⁷⁰ hash değerlendirmeleri, yaklaşık 1/1000 olasılıkla başarılı bir şekilde saldırmak için yeterlidir - kriptografik ilkellere yönelik şaşırtıcı saldırıların uzun geçmişi göz önüne alındığında, daha da fazla. Yukarıda bahsedilenlerden biri, altbn128 gibi eşleştirme dostu eliptik eğrilere daha iyi saldırılardır. Daha ünlü bir örnek, 1 bit güvenlikte standartlaştırılmış ancak sonunda yalnızca yaklaşık 80 bit elde ettiği gösterilen SHA-60'dir. Bu geçmişi göz önünde bulundurarak, PQ-SNARK tasarımcıları, güvenlik seviyesini yapılandırırken, özellikle güvenlik analizi, FRI gibi nispeten yeni protokollerin istatistiksel güvenliği hakkında güçlü varsayımlar içeriyorsa, kendilerine 10 bitten fazla boşluk bırakmalıdır.

PQ-SNARK'lar için bile, yalnızca doğrulama maliyetlerini artırarak her zaman uygun güvenlik seviyelerine ulaşılabilir. Örneğin, SHARP'ın doğrulayıcısının güvenliğini 80 bitten 128 bite çıkarmak (FRI'nın istatistiksel sağlamlığı hakkındaki varsayımlar altında) gaz maliyetlerini kabaca iki kat artıracak, 5 milyondan biraz 10 milyonun biraz üzerine çıkaracaktır. FRI hakkında varsayımlar olmadan, gaz maliyetleri iki kat daha artarak 20 milyonun üzerine çıkacaktır. 

O halde bir sonraki önerim, web3 topluluğunun konuşlandırılmış SNARK'lar için uygun güvenlik seviyeleri etrafında daha güçlü normlar geliştirmesi gerektiğidir. Benim kişisel tavsiyem en az 100 bit ve SNARK'ın güvenliği standart olmayan varsayımlara dayanıyorsa en az 128 olacaktır. ilk ben değilim böyle bir teklifte bulunmak.

Burada, koşulsuz güvenliği “standart varsayım” olarak kategorize etmeye hazırım. rastgele kehanet modeli, dağıtılan SNARK'taki rastgele oracle, KECCAK-256 gibi standart bir karma işleviyle başlatılırsa. Rastgele kehanet modeli, iyi tasarlanmış kriptografik özet fonksiyonlarının davranışını yakalaması amaçlanan idealleştirilmiş bir ayardır. Genellikle PQ-SNARK'ların güvenliğini analiz etmek için kullanılır. 

Standart olmayan varsayımlara bir örnek, FRI gibi bir protokolün nicel sağlamlığına ilişkin varsayımlardır (aşağıda açıklanmıştır) ya etkileşimli bir ortamda ya da rastgele kehanet modelinde etkileşimli olmayan bir protokol olarak.

SNARK tasarımcıları, bazıları güvenlik açısından sınırları zorlayabilecek birçok heyecan verici yolla yenilik yapıyor - örneğin, daha standart karma işlevleri kadar kriptanalize tabi tutulmamış SNARK dostu karma işlevleri kullanarak. Bu tür çabalara bir son verilmesi çağrısı yapmıyorum - bundan çok uzak. Ancak bu ilkeller, bilinen, uygulanabilir saldırıları 10 bitin çok üzerinde aşan güvenlik seviyelerinde başlatılmalıdır. 

SNARK'ları kullanan toplamalar, genellikle L1'lerinin güvenliğini devralan olarak tanımlanır. Ancak, L1 tarafından kullanılan herhangi bir kriptografik ilkelden çok daha düşük güvenlik seviyelerinde yapılandırıldılarsa, bu zor bir durumdur. SNARK'lar artan benimsemeyi gördüklerinden, bunları konuşma şeklimizle tutarlı olacak şekilde dağıttığımızdan emin olmalıyız. SNARK'lar dikkatli bir şekilde analiz edildiği, uygun şekilde yapılandırıldığı ve doğru bir şekilde uygulandığı sürece, günümüzde kullanılan herhangi bir kriptografik ilkel kadar güvenlidir. 

Bir kenara: PQ-SNARK güvenliğine daha da derinlemesine dalın

StarkWare'in PQ-SNARK'larındaki 80 bit güvenlik aşağıdaki gibi hesaplanmıştır. Bu PQ-SNARK'lar, adı verilen bir polinom taahhüt şemasını kullanır. ÜCRETSİZve StarkWare'in SHARP doğrulayıcısı, bir varsayım altında 48 bit güvenlikte FRI çalıştırır. Kabaca konuşursak, varsayım, FRI'nin sağlamlığına basit bir saldırının optimal olduğudur. Bu saldırıda, bir hile ispatlayıcı az bir çabayla, doğrulayıcının rastgele seçilmiş kontrollerini 2 olasılıkla geçen bir “FRI ispatı” üretir.^-48. 

StarkWare, FRI'yi "öğütme" adı verilen bir teknikle birleştirir. Bu, dürüst kanıtlayıcının bir FRI kanıtı üretmeden önce 32 bitlik bir çalışma kanıtı üretmesini gerektirir. Öğütmenin faydası, bir hile ispatlayıcısının yukarıda bahsedilen FRI'ye basit saldırıyı gerçekleştirmesi için gereken işi büyük ölçüde arttırması, yaklaşık 2'ye çıkarmasıdır.³² hash değerlendirmeleri 

(beklenti olarak) 2'den beri⁴⁸ basit saldırı girişimleri, bunlardan biri başarılı olmadan önce gereklidir, hile kanıtlayıcısının bir FRI kanıtı oluşturmak için yapması gereken toplam iş miktarı kabaca 2'dir.⁴⁸ * 2³² = 2⁸⁰ hash değerlendirmeleri

Son olarak, FRI için 48 bitlik güvenliğin nasıl ortaya çıktığını açıklayalım. FRI doğrulayıcı, taahhüt edilen polinom için "sorgular" yapar. FRI doğrulama maliyetleri, sorgu sayısı ile doğrusal olarak büyür. Örneğin, 36 FRI doğrulayıcı sorgusu, 4 sorgudan yaklaşık 9 kat daha pahalıdır. Ancak daha fazla sorgu, daha fazla güvenlik anlamına gelir. "Sorgu başına güvenlik biti" sayısı, FRI'nin kod hızı adı verilen başka bir parametresine bağlıdır. 

Spesifik olarak, FRI, Reed-Solomon oran kodu adı verilen bir şey kullanır. r, Burada r her zaman kesinlikle 0 ile 1 arasında bir sayıdır. FRI kanıtlayıcısının maliyetleri ile ters orantılıdır. r, bu nedenle 1/16 oranı, ¼ oranından yaklaşık dört kat daha yavaş ve daha fazla alan gerektiren bir ispata yol açar. 

SHARP doğrulayıcı, 1/16 kod oranı ve 12 doğrulayıcı sorgusu ile FRI çalıştırıyor.

StarkWare, her bir FRI doğrulayıcı sorgusunun günlük eklediğini varsayıyor₂(1 /r) güvenlik parçaları. Bu varsayım altında, 12 doğrulayıcı sorgusu 12 * log verir₂(16) = 48 bit güvenlik.

Ancak, mevcut analizler yalnızca her doğrulayıcı sorgusunun günlükten biraz daha az eklediğini tespit eder.₂(1/r^1/2) güvenlik parçaları. Yani 12 FRI doğrulayıcı sorgusu yalnızca 12 * günlükten daha azını verir₂(4) = 24 bit "kanıtlanabilir" güvenlik. 

Güvenlik ve performans arasındaki gerilimi azaltmak için bir öneri

Pratik PQ-SNARK'lar, istenen güvenlik biti sayısıyla doğrusal olarak büyüyen doğrulama maliyetlerine sahiptir. Bu gerilimi azaltmak için umut verici bir teknik, önceki yazımda kanıtlayıcı ve doğrulayıcı maliyetleri arasındaki gerilimi çözmenin bir yolu olarak tanımladığım SNARK kompozisyonudur, ancak aynı zamanda güvenliği de ele alabilir. 

iki örnek 

Çokgen Hermez PlonK ile PQ-SNARK'lar oluşturma. Buradaki fikir, kanıtlayıcının önce bir PQ-SNARK kanıtı π üretmesidir. PQ-SNARK, hızlı bir doğrulayıcıya ve yeterli bir güvenlik düzeyine sahip olacak şekilde yapılandırılmışsa, π büyük olacaktır. Böylece ispatlayıcı doğrulayıcıya π göndermez. Bunun yerine, π'yi bildiğini kanıtlamak için PlonK'yı kullanır. 

Bu, π'yi girdi olarak alan ve PQ-SNARK doğrulayıcının π'yi kabul edip etmeyeceğini kontrol eden bir devreye PlonK uygulamak anlamına gelir. PQ-SNARK'ın polilogaritmik doğrulama maliyeti olduğundan, PlonK küçük bir devreye uygulanır ve bu nedenle PlonK kanıtlayıcısı hızlıdır. PlonK kanıtları küçük ve doğrulaması ucuz olduğundan, doğrulama maliyetleri düşüktür. 

Ne yazık ki, PlonK kullanımı şeffaflığı ve kuantum sonrası güvenliği yok eder. Bunun yerine, π bilgisini kanıtlamak için PlonK yerine PQ-SNARK'ın kendisini kullanmayı düşünebiliriz (aslında Poligon tarafından kullanılan PQ-SNARK bu şekilde kendi kendine oluşur). 

PQ-SNARK'ın bu ikinci uygulamasında, π bilgisini kanıtlamak için sistem, örneğin FRI'da kullanım için çok küçük bir kod oranı seçerek, makul boyuttaki kanıtlarla yeterli güvenliği sağlayacak şekilde yapılandırılabilir. Buradaki kilit nokta, bu küçük kod hızı, kanıtlama süresi için kötü olsa da, PQ-SNARK'ın ikinci uygulamasının yalnızca küçük bir devreye uygulanmasıdır, bu nedenle toplam kanıtlama süresi hala küçük olmalıdır.

Oluşturulan SNARK'ların güvenliğine ilişkin teorik anlayışımız arzulanan çok şey bırakıyor. Ancak, SNARK'ları oluşturan bileşenlerden birine tek tek saldırmaktan daha hızlı bilinen saldırılar yoktur. Örneğin, bir PQ-SNARK'ı PlonK ile oluşturuyorsak, PQ-SNARK'a saldırmaktan (yani, yanlış bir ifadenin PQ-SNARK kanıtı π'sini bulmak) veya PlonK'ya saldırmaktan (yani, "Doğrulayıcının kabul edeceği bir PQ-SNARK kanıtı π biliyorum." yanlış ifadesinin bir PlonK kanıtını bulun.)

SNARK'ları bu şekilde oluşturmak, performansı artırmanın giderek daha popüler hale gelen bir yoludur. Umarım protokol tasarımcıları da güvenliği artırmak için kullanır.

***

Justin Thaler Georgetown Üniversitesi'nde doçenttir. 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'deRkeley. 

Editör: Tim Sullivan @tim_org

***

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.