ZK Coprocessor Nedir ve DeFi İçin Neden Önemlidir?

ZK coprocessor nedir?

ZK coprocessor, hesaplamayı bir blockchain dışında gerçekleştiren ve ardından hesaplamanın doğru şekilde yapıldığına dair bir kanıt üreten bir sistemdir. ZK, zero-knowledge anlamına gelir. Bu, bir ifadeyi kanıtlamak için kullanılan her bilgi parçasını açıklamadan o ifadeyi kanıtlayabilen bir kriptografik teknikler ailesidir. Birçok coprocessor tasarımında faydalı özellik yalnızca gizlilik değildir. Doğrulanabilirliktir.

Bir smart contract'ın şunu sorduğunu hayal edin: Bu cüzdan N bloğunda bir protokolün en üst düzey kullanıcıları arasında mıydı? Bir hesap geçmiş bir dönemde en az belirli bir bakiyeye sahip miydi? Bir pool, binlerce blok boyunca bir risk eşiğinin altında kaldı mı? Geleneksel bir contract bu soruları ucuza yanıtlayamayabilir, çünkü blockchain'ler tüm geçmişlerini tekrar tekrar taramak için değil, mevcut durum geçişlerini yürütmek için tasarlanmıştır.

ZK coprocessor, geçmiş blockchain verilerini okur veya alır, istenen hesaplamayı off-chain gerçekleştirir ve bir kanıtla birlikte sonucu döndürür. Bir doğrulayıcı contract, kriptografik kuralları kullanarak bu kanıtı kontrol eder. Kanıt geçerliyse contract, bir sunucu operatöründen gelen basit bir beyanı kabul etmeden sonuca göre hareket edebilir.

Bunu blockchain verileri için doğrulanabilir dış kaynaklı bir bilgisayar olarak anlamak en doğrusudur. Bir contract'ı her şeyi bilir hale getirmez ve bir uygulamayı otomatik olarak özel, merkeziyetsiz veya ucuz yapmaz. Bu özellikler veri kaynağına, circuit veya sanal makineye, kanıtlama sistemine, doğrulayıcıya ve hizmetin etrafındaki ekonomik tasarıma bağlıdır.

Başlıca riskler ve hata biçimleri

Kanıt kelimesi olduğundan daha mutlak duyulabilir. Geçerli bir kanıt genellikle tanımlanmış bir hesaplamanın, tanımlanmış girdiler üzerinde, tanımlanmış bir kanıtlama sistemi altında doğru şekilde gerçekleştirildiğini ortaya koyar. Geliştiricinin doğru soruyu seçtiğini, doğru chain'i aldığını, bir contract'ı doğru yorumladığını veya yanıtın etrafında güvenli bir uygulama kurduğunu kanıtlamaz.

Merkezi teknik varsayım, kanıt sisteminin soundness özelliğidir. Soundness, yanlış bir ifade için geçerli görünen bir kanıt oluşturmayı pratikte imkânsız kılan özelliktir. Kriptografide, uygulamada, circuit'te, doğrulayıcı contract'ta veya trusted setup'ta ciddi bir kusur varsa, bir saldırgan contract'ın kabul edeceği hatalı bir sonucu gönderebilir. Zero-knowledge etiketi, bu bileşenlerin denetlenmesinin yerine geçmez.

Sıradan altyapı riskleri de vardır. Bir prover kullanılamaz hale gelebilir, bir veri sağlayıcı eksik geçmiş döndürebilir, bir hizmet yalnızca seçili chain'leri destekleyebilir veya bir contract kanıt göndermek için bir koordinatöre dayanabilir. Bazı sistemler multisig'e duyulan güveni azaltırken yine de çalışma süresi, veri erişilebilirliği, ücret ödemesi veya yazılım güncellemeleri için operatörlere bağlı kalır. Yönetişim anahtarları ve yükseltme izinleri, kanıt sistemiyle aynı titizlikle incelenmeyi hak eder.

Finansal hata biçimi DeFi içinde özellikle önemlidir. Kusurlu bir geçmiş hesaplama teminatı yanlış fiyatlandırabilir, ödülleri yanlış hesaplara dağıtabilir, likidasyonları tetikleyebilir veya kötü bir krediyi onaylayabilir. Bir kanıt, kodun yazıldığı gibi çalıştığını gösterebilir, ancak kodun kendisi ekonomik bir hata içerebilir. Bu nedenle kullanıcılar, coprocessor destekli bir uygulamayı geleneksel bir uygulamadan daha güvenli görmeden önce denetimleri, doğrulayıcı adreslerini, yükseltme kontrollerini, desteklenen veri kaynaklarını ve acil durum prosedürlerini incelemelidir.

Geçmiş zincir verilerini nasıl kanıtlar?

Temel akış birkaç aşamadan oluşur. İlk olarak, bir uygulama bir sorgu ve ihtiyaç duyduğu verileri tanımlar. Sorgu bakiyeleri, takasları, likidite pozisyonlarını, borç verme faaliyetlerini veya daha önceki Ethereum bloklarında kaydedilmiş durum taahhütlerini içerebilir. Sistem daha sonra hesaplamanın gerektirdiğine bağlı olarak ilgili blok başlıklarını, işlem verilerini, makbuzları ve durum bilgilerini alır.

Ardından, zincir dışı bir işçi istenen programı çalıştırır. Bu program özel bir devre veya genellikle zkVM olarak adlandırılan genel amaçlı bir zero-knowledge sanal makinesi olabilir. Bir zkVM, geliştiricilerin mantığı daha tanıdık bir programlama ortamında ifade etmesini sağlar, sistem ise yürütmeyi kanıtlanabilir bir biçime dönüştürür. Sonuç, hem bir yanıtı hem de girdi verileri ve programla bağlantılı bir kanıtı içerir.

Zincir üstü doğrulayıcı normalde her geçmiş işlemi yeniden çalıştırmaz. Bir doğrulama anahtarı ve blok tanımlayıcısı, veri taahhüdü, sorgu parametreleri ve iddia edilen sonuç gibi herkese açık girdiler kullanarak kompakt bir kanıtı kontrol eder. Kanıt geçerse, bir sözleşme sonucu saklayabilir veya hemen kullanabilir. Sözleşme yine de blok ve durum taahhüdünün uygulamanın beklediği anlama geldiğini doğrulamalıdır.

Geçmiş verilere erişim, bir düğümden sadece bir sayı istemekten daha karmaşıktır. Bir bakiye, belirli bir bloktaki sözleşme depolamasına bağlı olabilir. Zaman ağırlıklı bir metrik çok sayıda durum anlık görüntüsü gerektirebilir. Günlüklere dayalı bir sonuç, event olarak yayımlanmamış bilgileri kaçırabilir. Sistem, archive-node verilerini mi, indekslenmiş bir temsili mi, bir blok taahhüdünü mü yoksa başka bir kaynağı mı kanıtladığını tanımlamalıdır. Bu seçimler hem doğruluğu hem de güveni etkiler.

Bir kanıt gerçekte ne söyler?

Bir sözleşmenin, bir adresin seçilen bir bloktan önce en az 100 gün boyunca likidite sağladığına dair bir iddia aldığını varsayalım. Kanıt, belirtilen bir programın belirtilen girdileri incelediğini ve bu sonuca ulaştığını ortaya koyabilir. Sorunun sadakati ölçmek için yararlı bir ölçüt olduğunu, adresin tek bir kişi tarafından kontrol edildiğini veya uygulamanın bir ödül ödemesi gerektiğini bağımsız olarak kanıtlamaz.

Yeniden üretilebilir sorguların ve şeffaf girdi taahhütlerinin önemli olmasının nedeni bu ayrımdır. Geliştiriciler, bir sonucun arkasındaki zinciri, blok aralığını, sözleşme adreslerini, program sürümünü ve varsayımları belirleyebilmelidir. Bu bağlam olmadan bir kanıt matematiksel olarak geçerli olabilir, ancak kullanıcıların yorumlaması zor olabilir.

Coprocessor ile rollup arasındaki fark

Bir rollup, ana zincirin dışında işlem grupları yürüten ve temel zincirin ortaya çıkan durumu doğrulaması veya yeniden oluşturması için yeterli veri ya da taahhüt yayımlayan bir ölçekleme sistemidir. Birincil rolü, rollup kendi hesap ve uygulama durumunu korurken kullanıcıların işlem yapabileceği bir yer sağlamaktır. Bir ZK rollup, durum geçişinin kendi kurallarına göre yürütüldüğünü göstermek için geçerlilik kanıtları kullanır.

Bir coprocessor farklı bir göreve sahiptir. Genellikle yeni bir işlem ortamı için kanonik hesap durumunu sürdürmez ve esas olarak kullanıcıların varlık yatırıp sıradan uygulama çağrıları yürüttüğü bir yer değildir. Bir blockchain üzerinde zaten var olan veriler üzerinde seçilmiş hesaplamalar yapar, ardından sonucu ve kanıtı o zincirdeki bir sözleşmeye geri gönderir.

Sınır bulanıklaşabilir. Bir rollup analiz için coprocessor benzeri bir hizmet kullanabilir ve bir coprocessor rollup tarzı kanıtlama altyapısı veya bir zkVM kullanabilir. Pratik soru, bir sunum dosyasında hangi etiketin göründüğü değildir. Sistemin kendi yürütme ortamında kullanıcı işlemlerini sıralamak ve sonuçlandırmaktan mı sorumlu olduğunu, yoksa başka bir zincirin geçmişi hakkında doğrulanabilir sorguları mı yanıtladığını sorun.

Kullanıcılar için bu fark risk yüzeyini değiştirir. Bir rollup, köprü saklama yapısı, veri kullanılabilirliği, sequencer davranışı, çekimler ve durum doğruluğu hakkında sorular doğurur. Bir coprocessor ise sorgu girdileri, kanıt sağlamlığı, geçmiş veri kapsamı, prover kullanılabilirliği ve hedef sözleşmenin sonucu güvenli şekilde işleyip işlemediği hakkında sorular doğurur. Hiçbir kategori tüm güven veya operasyonel riski ortadan kaldırmaz.

Oracle'dan nasıl ayrılır?

Bir oracle, bir akıllı sözleşmeye sözleşmenin doğrudan elde edemeyeceği bilgileri sağlar. Fiyat akışları tanıdık bir örnektir. Bir oracle ağı, borsalardan ETH fiyatlarını toplayabilir ve borç verme piyasaları için bir değer yayımlayabilir. Sözleşme, oracle'ın tasarımına, katılımcı raporlayıcılara, toplama yöntemine ve manipülasyona karşı korumalarına güvenir.

Bir ZK coprocessor genellikle belirtilen blockchain verilerinden bir hesaplamayı kanıtlar. Bir adresin bir protokolle etkileşime girdiğini, bir vault'un geçmiş risk maruziyetinin bir eşiği aştığını veya bir işlem kümesinin bir kuralı karşıladığını kanıtlayabilir. Kanıt, bir hesaplamanın girdilerini doğru şekilde izleyip izlemediğini yanıtlar. Harici bir piyasa fiyatının, gerçek dünya kimliğinin veya hukuki bir olgunun doğru olduğunu otomatik olarak kanıtlamaz.

İki sistem birlikte çalışabilir. Bir oracle imzalı veya başka şekilde kimliği doğrulanmış bir fiyat girdisi sağlayabilir ve bir coprocessor bu girdiyi geçmiş zincir üstü pozisyonlarla birlikte kullanan bir risk hesaplamasını kanıtlayabilir. Bu tasarımda kanıt hesaplamayı koruyabilir, oracle ise dış dünya verileri için bir güven noktası olarak kalır.

Trustless ifadesi hakkında da yararlı bir uyarı vardır. Bir kanıt, hesaplama için bir multisig'e veya tek bir sunucuya bağımlılığı azaltabilir, ancak girdilerinde hiç temsil edilmemiş olguları kanıtlayamaz. Bir uygulamanın gerçek dünya kimlik bilgisine, güncel bir borsa fiyatına veya hukuki bir iddiaya ihtiyacı varsa, yine de uygun bir tasdik veya oracle mekanizmasına ihtiyacı vardır.

Geliştiriciler bununla ne inşa edebilir?

En doğrudan fayda daha ucuz veya daha ifade gücü yüksek hesaplamadır. Ethereum sözleşmeleri yürütme için gas öder ve uzun geçmişleri taramak veya büyük veri kümelerini doğrudan zincir üzerinde işlemek pratik olmayabilir. Bir coprocessor ağır işi zincir dışına taşırken zincir üzerinde kompakt bir doğrulama adımı bırakır. Toplam maliyet yine de kanıtlama, veri alma, kanıt gönderimi ve bazen bir hizmet ücretini içerir, bu nedenle daha ucuz olması ücretsiz olduğu anlamına gelmez.

DeFi risk motorları

Bir borç verme protokolü, yoğunlaşmayı, likidasyon davranışını veya bir borçlunun diğer piyasalarla ilişkisini tahmin etmek için geçmiş pozisyonları kullanabilir. Bir vault, zincir üstü kodunun verimli şekilde işleyebileceğinden daha uzun bir risk penceresini kontrol edebilir. Bir ödül sistemi, her ara değeri zincir üzerinde saklamadan birçok blok boyunca katılımı hesaplayabilir.

Bu kullanımlar değerlidir çünkü DeFi uygulamaları genellikle tek bir güncel sayıdan ziyade bağlama ihtiyaç duyar. Ancak risk modelleri kanıtlandıkları için doğru hale gelmez. Geliştiricilerin yine de sağlam varsayımlar seçmesi, eksik verileri ve flash-loan davranışını hesaba katması ve bir kanıt geciktiğinde veya kullanılamadığında protokolün nasıl tepki vereceğini tanımlaması gerekir.

Özel kimlik ve uygunluk

Bir kullanıcı, kimlik bilgisinin kendisini açıklamadan daha büyük bir kimlik bilgisi hakkında dar kapsamlı bir iddiayı kanıtlayabilir. Örneğin, bir uygulama bir kişinin yaş veya yargı alanı şartını karşıladığını ya da bir cüzdanın bir katılım kuralını sağladığını doğrulayabilir, aynı zamanda sözleşmeye açığa çıkan bilgiyi sınırlayabilir. Bunun gerçekten özel olup olmadığı kimlik bilgisini veren tarafa, cüzdana, metadata'ya, iptal sürecine ve uygulamanın herkese açık olarak ne kaydettiğine bağlıdır.

Zincir üstü faaliyet, bir kanıt bazı girdileri gizlediğinde bile çoğu zaman ilişkilendirilebilir. Özel bir kanıt, özel işlemleri, anonim ağ kullanımını veya her türlü analize karşı korumayı garanti etmez. Kimlik sistemleri ayrıca bir kişinin yalnızca tek bir uygun kimliği kontrol ettiğini kanıtlama sorunuyla karşı karşıyadır ve kriptografi tek başına bunu çözmez.

Ucuz hesaplama ve karmaşık sorgular

Genel hesaplama başka bir hedeftir. Bir geliştirici, blockchain geçmişi üzerinde itibar mantığı, portföy analizi, yönetişim hesaplamaları veya oyun kuralları çalıştırmak isteyebilir. Genel amaçlı bir sistem, her işlemi zincir üstü sözleşme olarak yazmaya kıyasla bu görevleri ifade etmenin önündeki engeli azaltabilir.

Axiom, blockchain verileri üzerinde doğrulanabilir sorgulara odaklanır. RISC Zero, RISC-V ortamında çalışan programları kanıtlayabilen genel amaçlı bir zkVM yaklaşımı sunar. Succinct, SP1 zkVM dahil olmak üzere kanıtlama altyapısı ve araçları geliştirir. Bu projeler, tek bir standartlaştırılmış üründen ziyade geniş bir tasarım alanını gösterir. Performansları, desteklenen girdileri, dağıtım modelleri ve üretim garantileri önemli ölçüde farklılık gösterebilir, bu nedenle tek başına bir proje adı belirli bir entegrasyonun güvenli veya olgun olduğunun kanıtı değildir.

Mevcut sınırlar: kanıtlama maliyeti, gecikme ve benimsenme

Kanıtlama hesaplaması yoğun kaynak gerektirir. Normal bir sunucu için ucuz olan bir sorgu, ilgili her adımın bir kanıtta temsil edilmesi gerektiğinde önemli donanım, bellek ve mühendislik çalışması gerektirebilir. Daha geniş tarihsel aralıklar, karmaşık programlar, kriptografik işlemler ve aynı anda çok sayıda kullanıcı, kanıtlama süresini ve işletme maliyetini artırabilir.

Gecikme de önemlidir. Anında yanıt gerektiren bir kontrat çağrısı, üretilmesi dakikalar veya daha uzun süren bir kanıtla uyumlu olmayabilir. Bazı uygulamalar asenkron güncellemeleri tolere edebilir. Diğerleri, bir kanıt beklemedeyken yedek bir çözüme, önbelleğe alınmış bir sonuca, iyimser bir süreye veya muhafazakar bir eyleme ihtiyaç duyar. Bu geçici çözümler yeni tasarım tercihleri ve bazen yeni güven varsayımları ortaya çıkarır.

Veri erişilebilirliği ve indeksleme pratik darboğazlar olmaya devam ediyor. Bir kanıtlayıcının arşiv erişimine, özel indekslere veya önceden işlenmiş taahhütlere ihtiyacı olabilir. Bir zincir yeniden düzenlenirse, veri formatını değiştirirse veya eksik tarihsel kapsama sahipse, uygulamanın net bir politikaya ihtiyacı vardır. Kanıt, yalnızca programın gerçekten tüketebildiği veri kadar faydalıdır.

Geliştirici deneyimi gelişiyor, ancak devreler veya zkVM programları yazmak hâlâ uzmanlık gerektirir. Hatalar uygulama kodundan, kanıtlanabilir bir forma çeviriden, herkese açık ve özel girdilerin işlenmesinden veya doğrulayıcı entegrasyonundan kaynaklanabilir. Denetimler yardımcı olur, ancak garanti değildir. Açık kaynak kod, yeniden üretilebilir derlemeler, bağımsız doğrulama, hata ödül programları ve muhafazakar sınırlar incelenmesi gereken anlamlı sinyallerdir.

Bu, kullanıcılar ve geliştiriciler için ne anlama gelir?

Geliştiriciler için, kontratın doğrulaması gereken tam iddia ile başlayın. Bloğu, zinciri, veri taahhütlerini, program sürümünü, kabul edilebilir bayatlığı ve kanıt üretilemezse davranışı tanımlayın. Ardından bir coprocessor seçeneğini, kayan bir toplamı saklamak, yerleşik bir oracle kullanmak veya hesaplamayı doğrudan on-chain yapmak gibi daha basit seçeneklerle karşılaştırın. En gelişmiş mimari otomatik olarak en iyi mimari değildir.

Kullanıcılar için, ZK-powered ifadesinin ötesine bakın. Ürünün gerçek mainnet kullanımı olup olmadığını veya ağırlıklı olarak bir gösterimden ibaret olup olmadığını öğrenin. Hangi kısımların açık kaynak olduğunu, doğrulayıcıyı kimin yükseltebildiğini, bir koordinatörün kanıtları sansürleyip sansürleyemeyeceğini veya geciktirip geciktiremeyeceğini, tarihsel verinin nasıl sağlandığını ve hatalı bir sonuçtan sonra ne olduğunu kontrol edin. Bir protokol büyük mevduatları kabul ediyorsa, kriptografik markalamaya güvenmek yerine denetimleri ve olay geçmişini inceleyin.

Üç soruyu birbirinden ayırmak da faydalıdır. Sistem istenen sonucu hesaplayabiliyor mu? Sonucu sağlam biçimde kanıtlayabiliyor mu? Uygulama bu sonucu hasmane koşullar altında güvenli şekilde kullanacak mı? İlk soruya ikna edici bir yanıt, diğer ikisini çözmüş olmaz.

İleri düzey bir okur olarak, bu konuyu Ethereum ölçeklemesinin nasıl çalıştığı ve zero-knowledge proofs nedir ile de karşılaştırmak isteyebilirsiniz. Bu kavramlar, kanıt üretiminin on-chain doğrulama işini neden azaltabildiğini, ancak veri, hesaplama ve güven konusunda hâlâ dikkatli tercihler gerektirdiğini açıklar.

ZK coprocessor iddialarını eleştirel okuyun

ZK coprocessor alanı hızlı ilerliyor ve etrafındaki iddialar çoğu zaman daha da hızlı ilerliyor. Teknik sürümleri, entegrasyonları ve güvenlik haberlerini manuel olarak takip etmek zordur. Zippfeed, ilgili başlıkları bullish, neutral veya bearish duyarlılık puanlaması ve önem derecesiyle öne çıkararak anlamlı bir üretim dağıtımını bir prototipten, ortaklık duyurusundan veya çözülmemiş riskten ayırt etmenize yardımcı olur. Bu bağlamı, haberleri herhangi bir projeyi satın alma veya kullanma tavsiyesi olarak görmeden teknolojiyi takip etmek için kullanın.