@boundless_xyz eco'yu keşfederken, @RiscZero R0VM'nin uygulamalarında ilginç bir kullanım durumu keşfettim: ZK Proof of Exploit - zkPoEx. Tüm hatalar arasında en kritik olanları canlı ürünlerde bulunanlardır. Kriptoda, kritik güvenlik açıkları hemen fon istismarına yol açtığından, canlı hataların parasal değeri çok yüksektir. Tipik olarak, bu tür hatalar bulunduğunda, @immunefi veya @HackenProof gibi hata ödül platformları, hatanın gerçekliğini ve ciddiyetini doğrulamak ve ödül pazarlığını düzeltmek için aracı görevi görür. Bu yapının bir sorunu var: Beyaz şapkalı ödül almadan önce hata detaylarının açıklanması gerekiyor. Projenin bakış açısına göre, hata raporunu aldıktan ve inceledikten sonra, yama yapabilir ve ardından "kapsam dışı" olduğunu iddia edebilir veya önem derecesini düşürebilirler. Çok aşırı durumlarda, aracılar güvenlik açığını görebilir ve önce bundan yararlanabilir. zkPoEx, RiscZero'nun R0VM'si aracılığıyla, hata detaylarını açığa çıkarmadan ZK kanıtı ile bir güvenlik açığının varlığının kanıtlanmasına olanak tanır. Belirli koşulları karşılayan bir hatanın var olduğunu kanıtlayabileceğinden, hata bulucular projelerden önceden kısmi ödeme istemek gibi daha işbirlikçi yanıtlar bekleyebilirler. Daha ayrıntılı olarak açıklamak gerekirse, raporlayıcı, R0VM içindeki hedef sözleşmenin durum değerlerini değiştirmek için calldata/exploit sözleşmesini özel girdi olarak ve saldırı zamanı durumunu genel girdi olarak kullanır. Yürütmeden sonra, R0VM Prover tarafından oluşturulan tx makbuzu ve kanıtı, saldırının denge değişiklikleri gibi belirli koşulları karşılayıp karşılamadığını doğrulayabilir. Şahsen bu yöntemin canlı güvenlik açıklarını bildirmek için oldukça yararlı olduğunu düşünüyorum, ancak henüz bu yaklaşım kullanılarak hataların bildirildiği herhangi bir durum görmedim. Görünüşe göre projelerin koşulları önceden sağlaması gerekiyor... Böyle bir sistemin pratikte uygulanması gerçekten zorsa, zorlukların neler olacağını bilmek isterim.