ZK-verifierbar matchning är ett sätt att köra en snabb, privat orderbok samtidigt som användarna får en kryptografisk garanti för att matchningsmotorn följde reglerna. Problemet den löser är enkelt: en CLOB behöver en operatör (eller en liten uppsättning operatörer) för att snabbt matcha order, men den operatören kan också fuska (omordna, hoppa över eller selektivt fylla). ZK ändrar förtroendemodellen: operatören kan vara snabb, men kan inte slutföra en uppdatering om de inte bevisar att den beräknats korrekt. Hur det fungerar (konceptuellt) ➤ Order samlas in och matchas off-chain (så du kan få låg latens-exekvering). ➤ Istället för att publicera hela order-flödet publicerar systemet: - ett åtagande för batch-/tillståndsövergången (ofta en tillståndsrot) - ett zk-bevis på att matchningen + riskkontroller + balansuppdateringar gjordes enligt protokollreglerna, - tillräcklig datatillgänglighet så att användare fortfarande kan lämna även om operatören försvinner. Den "tillräckliga datatillgängligheten" är där @hibachi_xyz designval är intressant: Hibachi kör en högpresterande CLOB och postar krypterad status-/handelsdata till @Celestia (så strategier och positioner är inte offentliga), samtidigt som han publicerar bevis så att uppdateringar förblir verifierbara, med hjälp av SP1 (Succincts zkVM) för att bevisa CLOB:n. Men vad betyder "matchning var korrekt" i bevistermer? Ett zk-proof kan upprätthålla samma invarianter som du normalt skulle förlita dig på att en utbytesoperator följer, till exempel: ➤ Beställningar matchades endast när priserna korsades (inga omöjliga fyllningar). ➤ Fyllningssekvensen respekterade lokalens prioriteringsregel (t.ex. pris-tidsprioritet eller vad platsen nu angier). ➤ Saldon/marginaler uppdaterades korrekt (inga dolda saldo-redigeringar). ...