Potrivirea verificabilă prin ZK este o modalitate de a rula un carnet de ordine rapid și privat, oferind totodată utilizatorilor o garanție criptografică că motorul de potrivire respectă regulile. Problema pe care o rezolvă este simplă: un CLOB are nevoie de un operator (sau de un set mic de operatori) pentru a potrivi rapid ordinele, dar acel operator poate trișa (reordonare, sărit sau completat selectiv). ZK schimbă modelul de încredere: operatorul poate rămâne rapid, dar nu poate finaliza o actualizare decât dacă dovedește că a fost calculată corect. Cum funcționează (conceptual) ➤ Ordinele sunt colectate și potrivite off-chain (astfel încât să poți obține execuție cu latență scăzută). ➤ În loc să publice fluxul complet de ordine, sistemul publică: - un angajament față de tranziția batch / stare (adesea o rădăcină de stare) - o dovadă zk că potrivirea + verificările riscului + actualizările de echilibru au fost realizate conform regulilor protocolului, - disponibilitate suficientă de date astfel încât utilizatorii să poată ieși chiar dacă operatorul dispare. Acea "disponibilitate suficientă de date" este ceea ce face ca alegerea de design a lui @hibachi_xyz să fie interesantă: Hibachi rulează un CLOB de înaltă performanță și postează date criptate de stat/tranzacționare către @Celestia (deci strategiile și pozițiile nu sunt publice), publicând în același timp dovezi pentru ca actualizările să rămână verificabile, folosind SP1 (zkVM de la Succinct) pentru a demonstra CLOB-ul. Dar ce înseamnă "potrivirea a fost corectă" în termeni de dovadă? O probă zk poate impune aceiași invarianți pe care în mod normal te-ai baza pe un operator de schimb să îi urmeze, de exemplu: ➤ Comenzile erau egalate doar când prețurile se încruzeau (fără umpleri imposibile). ➤ Secvența de umplere respecta regula priorității locației (de exemplu, prioritate preț-timp sau orice specifică locația). ➤ Soldurile/marjele au fost actualizate corect (fără modificări ascunse ale soldului). ...