blog 1HaberlerGeliştiricilerEnterpriseBlockchain AçıklamasıEtkinlikler ve KonferanslarBasınBültenler

Haber bültenimize abone ol.

E

Senin gizliliğine saygı duyuyoruz

AnasayfaBlogBlockchain Geliştirme

Zk-SNARK’lara giriş

Sıfır bilgi kanıtlarına ve zk-SNARK’ların Ethereum’a nasıl entegre edileceğine genel bir bakış. 27 Mart 2017

ev kahramanı


Bu yazıda, pratik bir bakış açısıyla zk-SNARK’lara genel bir bakış sunmayı hedefliyoruz. Gerçek matematiği bir kara kutu olarak ele alacağız ve onları nasıl kullanabileceğimiz konusunda bazı sezgiler geliştirmeye çalışacağız. Ayrıca, son çalışmaların basit bir uygulamasını da vereceğiz. zk-SNARK’ları Ethereum’a entegre etmek.

Sıfır Bilgi Kanıtı

Sıfır bilgi ispatlarının amacı, bir doğrulayıcının, tanığı doğrulayıcıya veya başka birine ifşa etmeden, bir kanıtlayıcının, tanık denilen gizli bir parametre bilgisine sahip olduğuna, bazı ilişkileri tatmin ettiğine ikna edebilmesidir..

Bunu daha somut olarak, C ile gösterilen ve iki girdi alan bir programa sahip olarak düşünebiliriz: C (x, w). X girdisi genel girdidir ve w gizli tanık girdisidir. Programın çıktısı boole’dir, yani doğru veya yanlış. Daha sonra hedefe belirli bir genel girdi verilir x, kanıtlayanın gizli bir girdi w bildiğini kanıtlayın, öyle ki C (x, w) == true.

Özellikle etkileşimli olmayan sıfır bilgi kanıtlarını tartışacağız. Bu, kanıtın kendisinin, kanıtlayıcıdan herhangi bir etkileşim olmaksızın doğrulanabilen bir veri bloğu olduğu anlamına gelir..

Örnek Program

Farz edelim ki Bob’a bir değerde bir H hash verildi ve Alice’in H’ye hash olan s değerini bildiğine dair bir kanıt elde etmek istiyor. Normalde Alice bunu Bob’a s vererek ispatlayacak, ardından Bob hash’i hesaplayacak ve H’ye eşittir.

Ancak, Alice’in s değerini Bob’a açıklamak istemediğini, bunun yerine sadece değeri bildiğini kanıtlamak istediğini varsayalım. Bunun için bir zk-SNARK kullanabilir.

Alice’in senaryosunu, burada bir Javascript işlevi olarak yazılan aşağıdaki programı kullanarak tanımlayabiliriz:

fonksiyon C (x, w) {return (sha256 (w) == x);} Kod dili: JavaScript (javascript)

Başka bir deyişle: program, bir genel karma x ve gizli bir w değeri alır ve eğer SHA – 256 karma w eşitse, true değerini döndürür..

Alice’in problemini C (x, w) fonksiyonunu kullanarak çevirirken, Alice’in s’yi açığa çıkarmak zorunda kalmadan C (H, s) == doğru olacak şekilde s’ye sahip olduğuna dair bir kanıt yaratması gerektiğini görürüz. Bu, zk-SNARK’ların çözdüğü genel problemdir.

Zk-SNARK’ın tanımı

Bir zk-SNARK, aşağıdaki şekilde tanımlanan üç G, P, V algoritmasından oluşur:

Anahtar üreteci G gizli bir parametre lambda’yı ve bir C programını alır ve iki kamuya açık anahtar, bir kanıtlayıcı anahtar pk ve bir doğrulama anahtarı vk üretir. Bu anahtarlar, belirli bir C programı için yalnızca bir kez oluşturulması gereken genel parametrelerdir..

Atasözü P girdi olarak ispatlama anahtarını pk, açık bir girdi x ve özel bir tanık w alır. Algoritma, kanıtlayanın bir tanığı w tanıdığına ve tanığın programı tatmin ettiğine dair bir kanıt prf = P (pk, x, w) üretir..

Doğrulayıcı V, ispat doğruysa doğru, aksi halde yanlış döndüren V’yi (vk, x, prf) hesaplar. Dolayısıyla, kanıtlayıcı C (x, w) == true ‘yu tatmin eden bir tanığı biliyorsa, bu işlev true.

Burada, jeneratörde kullanılan gizli parametre lambda’ya dikkat edin. Bu parametre bazen zk-SNARK’ların gerçek dünya uygulamalarında kullanılmasını zorlaştırır. Bunun nedeni, bu parametreyi bilen herkesin sahte kanıtlar üretebilmesidir. Spesifik olarak, herhangi bir C programı ve x kamu girdisi verildiğinde, lambda’yı bilen bir kişi, V (vk, x, fake_prf) ‘nin gizli w bilgisi olmadan doğru olarak değerlendireceği şekilde bir sahte_prf kanıtı oluşturabilir..

Bu nedenle, jeneratörün gerçekten çalıştırılması, hiç kimsenin parametreyi öğrenmediğinden ve herhangi bir yerde kaydetmediğinden emin olmak için çok güvenli bir işlem gerektirir. Nedeni buydu son derece ayrıntılı tören Zcash ekibi, “toksik atık” parametresi lambda’nın süreçte yok edildiğinden emin olurken, kanıtlama anahtarı ve doğrulama anahtarını oluşturmak için yürüttü.

Örnek Programımız İçin Bir zk-SNARK

Alice ve Bob, Alice’in yukarıdaki örnekteki gizli değeri bildiğini kanıtlaması için pratikte bir zk-SNARK’ı nasıl kullanırdı??

Her şeyden önce, yukarıda tartışıldığı gibi aşağıdaki işlevle tanımlanan bir programı kullanacağız:

fonksiyon C (x, w) {return (sha256 (w) == x); } Kod dili: JavaScript (javascript)

İlk adım Bob’un kanıtlama anahtarı pk ve doğrulama anahtarı vk’yi oluşturmak için jeneratör G’yi çalıştırmasıdır. İlk olarak, rastgele lambda üretin ve bunu girdi olarak kullanın:

(pk, vk) = G (C, lambda)

Lambda parametresini dikkatli kullanın, çünkü Alice lambda’nın değerini öğrenirse sahte kanıtlar yaratabilecektir. Bob, pk ve vk’yi Alice ile paylaşacak.

Alice şimdi atasözü rolünü oynayacak. Bilinen karma H’ye hash olan s değerini bildiğini kanıtlaması gerekir. Prf ispatını oluşturmak için pk, H ve s girişlerini kullanarak kanıtlama algoritması P’yi çalıştırır:

prf = P (pk, H, s)

Daha sonra Alice, V (vk, H, prf) doğrulama fonksiyonunu çalıştıran Bob’a prf ispatını sunar; bu durumda, Alice gizli s’yi doğru bir şekilde bildiği için bu durumda true döner. Bob, Alice’in sırrı bildiğinden emin olabilir, ancak Alice’in Bob’a sırrı açıklamasına gerek yoktu..

Yeniden Kullanılabilir Kanıtlama ve Doğrulama Anahtarları

Yukarıdaki örneğimizde, Bob Alice’e bir sır bildiğini kanıtlamak istiyorsa zk-SNARK kullanılamaz, çünkü Alice Bob’un lambda parametresini kaydetmediğini bilemez. Bob makul bir şekilde sahte kanıtlar yapabilirdi.

Bir program birçok kişi için yararlıysa (Zcash örneğinde olduğu gibi), Alice ve Bob’dan ayrı, güvenilir bağımsız bir grup jeneratörü çalıştırabilir ve lambda hakkında kimsenin öğrenemeyeceği bir şekilde kanıtlama anahtarı pk ve doğrulama anahtarı vk oluşturabilir..

Grubun hile yapmadığına güvenen herkes bu anahtarları gelecekteki etkileşimler için kullanabilir..

Ethereum’da zk-SNARK’lar

Geliştiriciler, zk-SNARK’ları Ethereum’a entegre etmeye çoktan başladı. Bu neye benziyor? Somut olarak, doğrulama algoritmasının yapı taşlarını önceden derlenmiş sözleşmeler şeklinde Ethereum’a ekleyebilirsiniz. Bunu nasıl yapacağınız aşağıda açıklanmıştır: kanıtlama anahtarını ve doğrulama anahtarını üretmek için jeneratörü zincir dışı çalıştırın. Daha sonra herhangi bir kanıtlayıcı, zincir dışı da bir kanıt oluşturmak için kanıtlama anahtarını kullanabilir. Daha sonra, genel doğrulama algoritmasını giriş parametreleri olarak ispat, doğrulama anahtarı ve genel girişi kullanarak akıllı bir sözleşme içinde çalıştırabilirsiniz. Daha sonra, diğer zincir içi etkinlikleri tetiklemek için doğrulama algoritmasının sonucunu kullanabilirsiniz..

Örnek: Gizli İşlemler

İşte zk-SNARK’ların Ethereum’da gizliliğe nasıl yardımcı olabileceğine dair basit bir örnek. Basit bir jeton sözleşmemiz olduğunu varsayalım. Normalde bir belirteç sözleşmesinin özünde adreslerden dengelere bir eşleme bulunur:

eşleme (adres => uint256) bakiyeler; Kod dili: JavaScript (javascript)

Bir dengeyi bir bakiyenin karmasıyla değiştirmek dışında aynı temel çekirdeği koruyacağız:

eşleme (adres => bytes32) balanceHashes; Kod dili: JavaScript (javascript)

İşlemlerin gönderenini veya alıcısını gizlemeyeceğiz. Ancak bakiyeleri gizleyeceğiz ve tutarları göndereceğiz. Bu özellik bazen şu şekilde anılır: gizli işlemler.

Jetonları bir hesaptan diğerine göndermek için iki zk-SNARK kullanacağız. Bir kanıt gönderen tarafından ve diğeri alıcı tarafından oluşturulur.

Normalde, boyut değeri olan bir işlemin geçerli olması için bir jeton sözleşmesinde aşağıdakileri doğrulamamız gerekir:

bakiyeler [fromAddress] >= değer

Zk-SNARK’larımızın bunun geçerli olduğunu ve güncellenmiş karmaların güncellenmiş bakiyelerle eşleştiğini kanıtlaması gerekir.

Ana fikir, gönderenin başlangıç ​​bakiyesini ve işlem değerini özel girdi olarak kullanmasıdır. Kamu girdileri olarak, başlangıç ​​dengesi, bitiş dengesi ve değer karmalarını kullanırlar. Benzer şekilde, alıcı başlangıç ​​bakiyesini ve değerini gizli girişler olarak kullanacaktır. Genel girdiler olarak, başlangıç ​​dengesi, bitiş bakiyesi ve değer karmalarını kullanırlar.

Aşağıda, zk-SNARK göndericisi için kullanacağımız program var, burada daha önce olduğu gibi x genel girişi ve w özel girişi temsil ediyor.

function senderFunction (x, w) {return (w.senderBalanceBefore > w.value && sha256 (w.value) == x.hashValue && sha256 (w.senderBalanceBefore) == x.hashSenderBalanceBefore && sha256 (w.senderBalanceBefore – w.value) == x.hashSenderBalanceAfter)} Kod dili: JavaScript (javascript)

Alıcının kullandığı program aşağıdadır:

function alıcıFunction (x, w) {return (sha256 (w.value) == x.hashValue && sha256 (w.receiverBalanceBefore) == x.hashReceiverBalanceBalanceBefore && sha256 (w.receiverBalanceBefore + w.value) == x.hashReceiverBalanceAfter)} Kod dili: JavaScript (javascript)

Programlar, gönderme bakiyesinin gönderilen değerden daha büyük olup olmadığını ve tüm karmaların eşleşip eşleşmediğini kontrol eder. Güvenilir bir grup insan, zk-SNARK’larımız için kanıtlama ve doğrulama anahtarlarını oluşturacaktır. Onlara confTxSenderPk, confTxSenderVk, confTxReceiverPk ve confTxReceiverVk diyelim.

Bir token sözleşmesinde zk-SNARK’ları kullanmak şuna benzer:

işlev aktarımı (adres _to, bytes32 hashValue, bytes32 hashSenderBalanceAfter, bytes32 hashReceiverBalanceAfter, bayt zkProofSender, bayt zkProofReceiver) {bytes32 hashSenderBalanceBefore = balanceHashes [msg.sender]; bytes32 hashReceiverBalanceBefore = balanceHashes [_to]; bool senderProofIsCorrect = zksnarkverify (confTxSenderVk, [hashSenderBalanceBefore, hashSenderBalanceAfter, hashValue], zkProofSender); bool alıcıProofIsCorrect = zksnarkverify (confTxReceiverVk, [hashReceiverBalanceBefore, hashReceiverBalanceAfter, hashValue], zkProofReceiver); if (senderProofIsCorrect && ReceiverProofIsCorrect) {balanceHashes [msg.sender] = hashSenderBalanceAfter; balanceHashes [_to] = hashReceiverBalanceAfter; }} Kod dili: JavaScript (javascript)

Bu nedenle, blok zincirindeki tek güncelleme, bakiyelerin kendileri değil, bakiyelerin hash’larıdır. Bununla birlikte, tüm bakiyelerin doğru bir şekilde güncellendiğini bilebiliriz çünkü kanıtın doğrulandığını kendimiz kontrol edebiliriz..

Detaylar

Yukarıdaki gizli işlem şeması, esasen zk-SNARK’ların Ethereum’da nasıl kullanılabileceğine dair pratik bir örnek vermektir. Sağlam bir gizli işlem planı oluşturmak için bir dizi sorunu ele almamız gerekir:

  • Kullanıcıların bakiyelerini istemci tarafında takip etmeleri gerekir ve bakiyeyi kaybederseniz bu belirteçler geri alınamaz. Bakiyeler, imzalama anahtarından türetilen bir anahtarla şifrelenmiş olarak zincir üzerinde saklanabilir..
  • Dengeleri anlamak için karmaları tersine çevirme yeteneğini önlemek için terazilerin 32 baytlık veri kullanması ve entropiyi kodlaması gerekir.
  • Kullanılmayan bir adrese göndermenin uç durumuyla uğraşmanız gerekiyor.
  • Gönderenin, göndermek için alıcıyla etkileşime girmesi gerekir. Potansiyel olarak, gönderenin işlemi başlatmak için kanıtlarını kullandığı bir sistem olabilir. Alıcı daha sonra blok zincirinde “bekleyen bir işlemin” olduğunu görebilir ve bunu tamamlayabilir..

En son Ethereum haberleri, kurumsal çözümler, geliştirici kaynakları ve daha fazlası için haber bültenimize abone olun.Başarılı Bir Blockchain Ürünü Nasıl OluşturulurWeb semineri

Başarılı Bir Blockchain Ürünü Nasıl Oluşturulur

Ethereum Düğümü Nasıl Kurulur ve ÇalıştırılırWeb semineri

Ethereum Düğümü Nasıl Kurulur ve Çalıştırılır

Kendi Ethereum API'nizi Nasıl Oluşturabilirsiniz?Web semineri

Kendi Ethereum API’nizi Nasıl Oluşturabilirsiniz?

Sosyal Simge Nasıl OluşturulurWeb semineri

Sosyal Simge Nasıl Oluşturulur

Akıllı Sözleşme Geliştirmede Güvenlik Araçlarını KullanmaWeb semineri

Akıllı Sözleşme Geliştirmede Güvenlik Araçlarını Kullanma

Finansın Geleceği Dijital Varlıklar ve DeFiWeb semineri

Finansın Geleceği: Dijital Varlıklar ve DeFi

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me