ZK-verifiserbar matching er en måte å kjøre en rask, privat ordrebok på, samtidig som brukerne får en kryptografisk garanti for at matchingsmotoren fulgte reglene. Problemet den løser er enkelt: en CLOB trenger en operatør (eller et lite sett operatører) for å matche ordre raskt, men den operatøren kan også jukse (omorganisere, hoppe over eller fylle selektivt). ZK endrer tillitsmodellen: operatøren kan være rask, men kan ikke fullføre en oppdatering med mindre de kan bevise at den ble riktig beregnet. Hvordan det fungerer (konseptuelt) ➤ Ordre samles inn og matches utenfor kjeden (slik at du kan få lav-latens utførelse). ➤ I stedet for å publisere hele ordreflyten, publiserer systemet: - en forpliktelse til batch-/tilstandsovergangen (ofte en tilstandsrot) - et ZK-bevis på at matching + risikokontroller + balanseoppdateringer ble gjort i henhold til protokollreglene, - tilstrekkelig datatilgjengelighet slik at brukerne fortsatt kan avslutte selv om operatøren forsvinner. Den «tilstrekkelige datatilgjengeligheten» er der @hibachi_xyz sitt designvalg er interessant: Hibachi kjører en høyytelses CLOB og legger ut krypterte tilstands-/handelsdata til @Celestia (slik at strategier og posisjoner ikke er offentlige), samtidig som han publiserer bevis slik at oppdateringer forblir verifiserbare, ved å bruke SP1 (Succincts zkVM) for å bevise CLOB. Men hva betyr «matching var riktig» i bevistermer? Et zk-bevis kan håndheve de samme invariantene du normalt ville stole på at en utvekslingsoperatør følger, for eksempel: ➤ Bestillinger ble kun matchet når prisene krysset (ingen umulige fyllinger). ➤ Fyllingssekvensen respekterte stedets prioriteringsregel (f.eks. pris-tidsprioritet, eller hva stedet enn spesifiserer). ➤ Saldoer/marginer ble oppdatert korrekt (ingen skjulte saldo-redigeringer). ...