ZK-weryfikowalne dopasowanie to sposób na prowadzenie szybkiej, prywatnej książki zleceń, jednocześnie dając użytkownikom kryptograficzną gwarancję, że silnik dopasowujący przestrzegał zasad. Problem, który rozwiązuje, jest prosty: CLOB potrzebuje operatora (lub małego zestawu operatorów), aby szybko dopasować zlecenia, ale ten operator może również oszukiwać (przestawiać, pomijać lub selektywnie wypełniać). ZK zmienia model zaufania: operator może pozostać szybki, ale nie może sfinalizować aktualizacji, chyba że udowodni, że została obliczona poprawnie. 𝗛𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀 (𝗰𝗼𝗻𝗰𝗲𝗽𝘁𝘂𝗮𝗹𝗹𝘆) ➤ Zlecenia są zbierane i dopasowywane poza łańcuchem (więc możesz uzyskać niską latencję wykonania). ➤ Zamiast publikować pełny przepływ zleceń, system publikuje: - 𝘢 𝘤𝘰𝘮𝘮𝘪𝘵𝘮𝘦𝘯𝘵 𝘵𝘰 𝘵𝘩𝘦 𝘣𝘢𝘵𝘤𝘩 / 𝘴𝘵𝘢𝘵𝘦 𝘵𝘳𝘢𝘯𝘴𝘪𝘵𝘪𝘰𝘯 (𝘰𝘧𝘵𝘦𝘯 𝘢 𝘴𝘵𝘢𝘵𝘦 𝘳𝘰𝘰𝘵) - 𝘢 𝘻𝘬-𝘱𝘳𝘰𝘰𝘧 𝘵𝘩𝘢𝘵 𝘵𝘩𝘦 𝘮𝘢𝘵𝘤𝘩𝘪𝘯𝘨 + 𝘳𝘪𝘴𝘬 𝘤𝘩𝘦𝘤𝘬𝘴 + 𝘣𝘢𝘭𝘢𝘯𝘤𝘦 𝘶𝘱𝘥𝘢𝘵𝘦𝘴 𝘸𝘦𝘳𝘦 𝘥𝘰𝘯𝘦 𝘢𝘤𝘤𝘰𝘳𝘥𝘪𝘯𝘨 𝘵𝘰 𝘵𝘩𝘦 𝘱𝘳𝘰𝘵𝘰𝘤𝘰𝘭 𝘳𝘶𝘭𝘦𝘴, - 𝘦𝘯𝘰𝘶𝘨𝘩 𝘥𝘢𝘵𝘢 𝘢𝘷𝘢𝘪𝘭𝘢𝘣𝘪𝘭𝘪𝘵𝘺 𝘴𝘰 𝘶𝘴𝘦𝘳𝘴 𝘤𝘢𝘯 𝘴𝘵𝘪𝘭𝘭 𝘦𝘹𝘪𝘵 𝘦𝘷𝘦𝘯 𝘪𝘧 𝘵𝘩𝘦 𝘰𝘱𝘦𝘳𝘢𝘵𝘰𝘳 𝘥𝘪𝘴𝘢𝘱𝘱𝘦𝘢𝘳𝘴. To „wystarczająca dostępność danych” jest tym, co czyni wybór projektowy @hibachi_xyz interesującym: Hibachi prowadzi wysokowydajny CLOB i publikuje zaszyfrowane dane stanu / transakcji do @Celestia (więc strategie i pozycje nie są publiczne), jednocześnie publikując dowody, aby aktualizacje pozostały weryfikowalne, używając SP1 (zkVM Succinct) do udowodnienia CLOB. 𝗕𝘂𝘁 𝘄𝗵𝗮𝘁 “𝗺𝗮𝘁𝗰𝗵𝗶𝗻𝗴 𝘄𝗮𝘀 𝗰𝗼𝗿𝗿𝗲𝗰𝘁” 𝗺𝗲𝗮𝗻𝘀 𝗶𝗻 𝗽𝗿𝗼𝗼𝗳 𝘁𝗲𝗿𝗺𝘀? Dowód zk może egzekwować te same inwarianty, na których normalnie polegałbyś, aby operator giełdy je przestrzegał, na przykład: ➤ Zlecenia były dopasowywane tylko wtedy, gdy ceny się krzyżowały (brak niemożliwych wypełnień). ➤ Sekwencja wypełnień respektowała zasady priorytetu miejsca (np. priorytet ceny-czasu lub cokolwiek, co określa miejsce). ➤ Salda/marginesy były aktualizowane poprawnie (brak ukrytych edycji salda). ...