ÇEKİM KANITLARI, İTİRAZLAR VE ROOT CHALLENGE'LARI
Her USDC ödemesi — challenge kâr paylaşımı, lider tablosu ödülü, referans komisyonu — vault'tan kullanıcının cüzdanını, borçlu olunan bakiyeyi, nonce'u ve Base'e commit edilmiş yayınlanmış bir settlement root'unu bağlayan bir kriptografik kanıta karşı ayrılır. Merkle kanıtı saklanan root'a karşı yeniden yapılandırılamazsa finalizeWithdraw revert olur. Bu sayfa dört adımlı talep yaşam döngüsünü, herhangi bir topluluk üyesinin USDC hareket etmeden önce kötü bir root'a itiraz etmesine izin veren üç challenge yöntemini ve bir çekim 24 saatlik hedeften daha uzun süre kanıt penceresinde kalırsa tam toparlanma yolunu adım adım anlatır.
Yedi kontrat primitifi kanıt-bazlı çıkışı oluşturur. İlk dördü her çekim için gereklidir; son üçü yayınlanmış bir root'a challenge etmek için ayağa kalkma hakkı olan herhangi bir adres için kullanılabilir.
| Mekanizma | Ne yapar |
|---|---|
| requestWithdraw(amount) | Kullanıcının cüzdanını, miktarı ve timestamp'i belirli bir çekim niyetine bağlayan on-chain bir nonce yayar — nonce yok, çıkış yolu yok |
| Durum root'u geçmişi | Son settlement root'larının append-only halkası; finalizeWithdraw hâlâ bu geçmişte olan bir root'a referans vermelidir; bu, sessiz değiştirmeyi tespit edilebilir kılar |
| Merkle kanıtı + leaf | Kullanıcı tarafı leaf verisi (cüzdan, bakiye, nonce listesi) artı referans verilen root'u yeniden yapılandıran kardeş yolu — yeniden yapılandırma başarısızlığı çağrıyı revert eder |
| disputeWindowSec | Root commit ile en erken finalizeWithdraw arasındaki yapılandırılabilir challenge penceresi; hızlı ödemeleri itiraz süresine karşı dengelemek için ayarlanmıştır |
| challengeRootFraudProof | Runtime'ın geçerli durum geçişleriyle tutarsız bir root commit ettiğini kanıtlayan bir fraud-verifier çıktısını gönderir |
| challengeRootInvalidLeaf | Yayınlanan ağaçtaki belirli bir hesap bakiyesinin runtime'ın borçlu olduğuyla çeliştiğini gösteren bir karşı-leaf gönderir |
| challengeRootConflict | Bildirilen parent veya sequence numaraları birbiriyle çelişen iki root'u gönderir, bir geçmiş çatallanmasını ortaya çıkarır |
#Çekim yolu kanıt-kapılıdır
Kullanıcı, çıkmak istediği USDC miktarıyla requestWithdraw'u çağırarak başlar. Kontrat, talebi kullanıcının cüzdanına, miktara ve blok timestamp'ine bağlayan bir nonce yayar. Bu nonce runtime'ın üzerinde hareket etmesine izin verilen tek şeydir — requestWithdraw çağrısı hiç yapmamış bir cüzdana runtime-başlatılan bir ödeme, Merkle leaf'inde eşleşen bir nonce mevcut olmadığı için finalizeWithdraw'dan geçemez.
Runtime ardından talebi bir sonraki settlement durumuna dahil eder. O durum Base'e commit edildiğinde, yeni root append-only geçmiş halkasına girer ve disputeWindowSec başlar. Gateway, kullanıcının leaf verisini ve root'u yeniden yapılandırmak için gereken kardeş yolu açığa çıkarır; böylece kullanıcı (veya güvendiği herhangi bir istemci) göndermeden önce kanıtı off-chain doğrulayabilir. disputeWindowSec başarılı bir challenge olmadan geçtikten sonra, finalizeWithdraw çağrılabilir: kontrat Merkle yeniden yapılandırmasını referans verilen root'a karşı on-chain yeniden çalıştırır, nonce'un eşleştiğini ve tüketilmediğini kontrol eder, root'un hâlâ geçmişte olduğunu doğrular ve ancak o zaman USDC'yi kullanıcının cüzdanına transfer eder.
Bir çekim 24 saatlik hedefin ötesinde kalırsa, başarısızlık gözlemlenebilirdir. Ya disputeWindowSec hâlâ açıktır (kontratta görünür), root henüz commit edilmemiştir (Basescan'de requestWithdraw'dan beri bir commitSettlement transaction'ının yokluğu olarak görünür) veya manuel inceleme kuyruğu ödemeyi podyum top-üç veya $5K üzeri doğrulama için flag'lemiştir. Her durumda talep kuyrukta kalır ve kapı koşulu temizlendiği anda finalize edilebilir — onunla ilgili hiçbir şey sona ermez.
requestWithdraw(amount)
-> on-chain nonce cüzdan + tutar + zaman damgasini baglar
-> runtime talebi sonraki settlement root'a dahil eder
-> commitSettlement(root) Base'e yazilir, history ring'e girer
-> disputeWindowSec baslar
-> gateway off-chain dogrulama icin leaf + sibling path sunar
-> disputeWindowSec basarili challenge olmadan dolar
-> finalizeWithdraw(nonce, leaf, proof, rootRef) USDC'yi serbest birakir#Challenge'lar ve fraud kanıtları neden vardır
Yayın doğrulukla aynı şey değildir. İtiraz penceresi, bir karşı-örnek inşa edebilen herkesin USDC karşı hareket etmeden önce kötü bir root'u durdurma hakkına sahip olması için vardır. Üç challenge yolu, kötü niyetli veya hatalı bir runtime'ın tanıtabileceği üç başarısızlık modunu kapsar. challengeRootFraudProof, yayınlanan root'un geçerli durum geçişleri tarafından üretilmiş olamayacağı durumu hedefler — fraud-verifier hook'u itiraz edilen adımı on-chain çalıştırır ve çıktısı uyuşmazsa root'u reddeder. challengeRootInvalidLeaf, belirli bir hesap leaf'inin runtime'ın borçlu olması gereken bir bakiyeyi yanlış belirttiği durumu hedefler; challenger karşı-leaf'i gönderir ve kontrat imzaları ve birikmiş bakiyeleri karşılaştırır. challengeRootConflict, geçmiş çatallanmalarını hedefler: parent referansları veya sequence numaraları birbirleriyle çelişen iki commit edilmiş root karşılıklı olarak hariçtir ve kontrat sonraki commit'i geçersiz kılar.
Başarılı bir challenge, itiraz edilen root'u geçersiz kılar, ona referans veren herhangi bir çekimi dondurur ve runtime'ı son bilinen-iyi durumdan yeniden hesaplayıp yeniden commit etmeye zorlar. Başarısız bir challenge, challenger'ın gönderdiği bond'u tüketir ve root'u yerinde bırakır. Ekonomik asimetri — yanlış alarmlar için bond kaybı, doğru alarmlar için vault-ölçekli etki önleme — kasıtlıdır. Spekülatif şikayetler yerine yeniden üretilebilir karşı-örnekler gönderme disiplinini ödüllendirir, aynı zamanda itiraz yolunu bir tane üretebilen herhangi bir adres için açık tutar.
Bu yüzden bir Dexter çekimi runtime'a izole olarak güvenmeye dayanmaz. Commit edilmiş bir root'a, doğrulanabilir bir kanıta, sessizce yeniden yazılamayan bir geçmişe, herhangi bir üçüncü tarafın challenge edebileceği bir pencereye ve her finalizasyonu Base'e yayınlayan bir multi-sig vault'a dayanır.