La corrispondenza verificabile ZK è un modo per gestire un libro ordini veloce e privato, garantendo comunque agli utenti una garanzia crittografica che il motore di corrispondenza ha seguito le regole. Il problema che risolve è semplice: un CLOB ha bisogno di un operatore (o di un piccolo gruppo di operatori) per abbinare rapidamente gli ordini, ma quell'operatore può anche imbrogliare (riordinare, saltare o riempire selettivamente). ZK cambia il modello di fiducia: l'operatore può rimanere veloce, ma non può finalizzare un aggiornamento a meno che non dimostri che è stato calcolato correttamente. 𝗛𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀 (𝗰𝗼𝗻𝗰𝗲𝗽𝘁𝘂𝗮𝗹𝗹𝘆) ➤ Gli ordini vengono raccolti e abbinati off-chain (quindi puoi ottenere un'esecuzione a bassa latenza). ➤ Invece di pubblicare il flusso completo degli ordini, il sistema pubblica: - 𝘢 𝘤𝘰𝘮𝘮𝘪𝘵𝘵𝘮𝘦𝘯𝘵 𝘵𝘰 𝘵𝘩𝘦 𝘣𝘢𝘵𝘤𝘩 / 𝘴𝘵𝘢𝘵𝘦 𝘵𝘳𝘢𝘯𝘴𝘪𝘵𝘪𝘰𝘯 (𝘰𝘧𝘵𝘦𝘯 𝘢 𝘴𝘵𝘢𝘵𝘦 𝘳𝘰𝘰𝘵) - 𝘢 𝘻𝘬-𝘱𝘳𝘰𝘰𝘧 𝘵𝘩𝘢𝘵 𝘵𝘩𝘦 𝘮𝘢𝘵𝘤𝘩𝘪𝘯𝘨 + 𝘳𝘪𝘴𝘬 𝘤𝘩𝘦𝘤𝘬𝘴 + 𝘣𝘢𝘭𝘢𝘯𝘤𝘦 𝘶𝘱𝘥𝘢𝘵𝘦𝘴 𝘸𝘦𝘳𝘦 𝘥𝘰𝘯𝘦 𝘢𝘤𝘤𝘰𝘳𝘥𝘪𝘯𝘨 𝘵𝘰 𝘵𝘩𝘦 𝘱𝘳𝘰𝘵𝘰𝘤𝘰𝘭 𝘳𝘶𝘭𝘦𝘴, - 𝘦𝘯𝘰𝘶𝘨𝘩 𝘥𝘢𝘵𝘢 𝘢𝘷𝘢𝘪𝘭𝘢𝘣𝘪𝘭𝘪𝘵𝘺 𝘴𝘰 𝘶𝘴𝘦𝘳𝘴 𝘤𝘢𝘯 𝘴𝘵𝘪𝘭𝘭 𝘦𝘹𝘪𝘵 𝘦𝘷𝘦𝘯 𝘪𝘧 𝘵𝘩𝘦 𝘰𝘱𝘦𝘳𝘢𝘵𝘰𝘳 𝘥𝘪𝘴𝘢𝘱𝘱𝘦𝘢𝘳𝘴. Quella "sufficiente disponibilità di dati" è dove la scelta di design di @hibachi_xyz è interessante: Hibachi sta gestendo un CLOB ad alte prestazioni e pubblicando dati di stato / commercio crittografati su @Celestia (quindi strategie e posizioni non sono pubbliche), mentre pubblica comunque prove affinché gli aggiornamenti rimangano verificabili, utilizzando SP1 (zkVM di Succinct) per dimostrare il CLOB. 𝗕𝘂𝘁 𝘄𝗵𝗮𝘁 “𝗺𝗮𝘁𝗰𝗵𝗶𝗻𝗴 𝘄𝗮𝘀 𝗰𝗼𝗿𝗿𝗲𝗰𝘁” 𝗺𝗲𝗮𝗻𝘀 𝗶𝗻 𝗽𝗿𝗼𝗼𝗳 𝘁𝗲𝗿𝗺𝘀? Una zk-proof può far rispettare le stesse invarianti su cui normalmente ci si aspetterebbe che un operatore di scambio segua, ad esempio: ➤ Gli ordini sono stati abbinati solo quando i prezzi si incrociano (nessun riempimento impossibile). ➤ La sequenza di riempimento ha rispettato la regola di priorità del luogo (ad es., priorità prezzo-tempo, o qualunque cosa specifichi il luogo). ➤ I saldi/margini sono stati aggiornati correttamente (nessuna modifica nascosta del saldo). ...