ZK-verifiable Matching ist eine Möglichkeit, ein schnelles, privates Orderbuch zu betreiben und den Nutzern gleichzeitig eine kryptografische Garantie zu geben, dass die Matching-Engine die Regeln befolgt. Das Problem, das es löst, ist einfach: Ein CLOB benötigt einen Betreiber (oder eine kleine Gruppe von Betreibern), um Aufträge schnell abzugleichen, aber dieser Betreiber kann auch betrügen (neu anordnen, überspringen oder selektiv ausfüllen). ZK ändert das Vertrauensmodell: Der Betreiber kann schnell bleiben, darf jedoch ein Update nicht abschließen, es sei denn, er beweist, dass es korrekt berechnet wurde. 𝗛𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀 (𝗰𝗼𝗻𝗰𝗲𝗽𝘁𝘂𝗮𝗹𝗹𝘆) ➤ Aufträge werden off-chain gesammelt und abgeglichen (so dass Sie eine latenzarme Ausführung erhalten). ➤ Anstatt den gesamten Auftragsfluss zu veröffentlichen, veröffentlicht das System: - 𝘢 𝘤𝘰𝘮𝘮𝘪𝘵𝘮𝘦𝘯𝘵 𝘵𝘰 𝘵𝘩𝘦 𝘣𝘢𝘵𝘤𝘩 / 𝘴𝘵𝘢𝘵𝘦 𝘵𝘳𝘢𝘯𝘴𝘪𝘵𝘪𝘰𝘯 (𝘰𝘧𝘵𝘦𝘯 𝘢 𝘴𝘵𝘢𝘵𝘦 𝘳𝘰𝘰𝘵) - 𝘢 𝘻𝘬-𝘱𝘳𝘰𝘰𝘧 𝘵𝘩𝘢𝘵 𝘵𝘩𝘦 𝘮𝘢𝘵𝘤𝘩𝘪𝘯𝘨 + 𝘳𝘪𝘴𝘬 𝘤𝘩𝘦𝘤𝘬𝘴 + 𝘣𝘢𝘭𝘢𝘯𝘤𝘦 𝘶𝘱𝘥𝘢𝘵𝘦𝘴 𝘸𝘦𝘳𝘦 𝘥𝘰𝘯𝘦 𝘢𝘤𝘤𝘰𝘳𝘥𝘪𝘯𝘨 𝘵𝘰 𝘵𝘩𝘦 𝘱𝘳𝘰𝘵𝘰𝘤𝘰𝘭 𝘳𝘶𝘭𝘦𝘴, - 𝘦𝘯𝘰𝘶𝘨𝘩 𝘥𝘢𝘵𝘢 𝘢𝘷𝘢𝘪𝘭𝘢𝘣𝘪𝘭𝘪𝘵𝘺 𝘴𝘰 𝘶𝘴𝘦𝘳𝘴 𝘤𝘢𝘯 𝘴𝘵𝘪𝘭𝘭 𝘦𝘹𝘪𝘵 𝘦𝘷𝘦𝘯 𝘪𝘧 𝘵𝘩𝘦 𝘰𝘱𝘦𝘳𝘢𝘵𝘰𝘳 𝘥𝘪𝘴𝘢𝘱𝘱𝘦𝘢𝘳𝘴. Dieses „ausreichende Datenverfügbarkeit“ ist, wo die Designentscheidung von @hibachi_xyz interessant ist: Hibachi betreibt einen Hochleistungs-CLOB und veröffentlicht verschlüsselte Status- / Handelsdaten an @Celestia (so dass Strategien und Positionen nicht öffentlich sind), während es gleichzeitig Beweise veröffentlicht, damit Updates überprüfbar bleiben, indem SP1 (Succincts zkVM) verwendet wird, um den CLOB zu beweisen. 𝗕𝘂𝘁 𝘄𝗵𝗮𝘁 “𝗺𝗮𝘁𝗰𝗵𝗶𝗻𝗴 𝘄𝗮𝘀 𝗰𝗼𝗿𝗿𝗲𝗰𝘁” 𝗺𝗲𝗮𝗻𝘀 𝗶𝗻 𝗽𝗿𝗼𝗼𝗳 𝘁𝗲𝗿𝗺𝘀? Ein zk-Beweis kann die gleichen Invarianten durchsetzen, auf die Sie normalerweise von einem Börsenbetreiber angewiesen wären, zum Beispiel: ➤ Aufträge wurden nur abgeglichen, wenn die Preise sich kreuzen (keine unmöglichen Füllungen). ➤ Die Füllsequenz respektierte die Prioritätsregel des Marktes (z. B. Preis-Zeit-Priorität oder was auch immer der Markt angibt). ➤ Salden/Margen wurden korrekt aktualisiert (keine versteckten Saldenänderungen). ...