Le matching vérifiable par ZK est un moyen d'exécuter un carnet de commandes rapide et privé tout en offrant aux utilisateurs une garantie cryptographique que le moteur de correspondance a respecté les règles. Le problème qu'il résout est simple : un CLOB a besoin d'un opérateur (ou d'un petit groupe d'opérateurs) pour faire correspondre les ordres rapidement, mais cet opérateur peut aussi tricher (réorganiser, sauter ou remplir sélectivement). ZK change le modèle de confiance : l'opérateur peut rester rapide, mais ne peut pas finaliser une mise à jour à moins de prouver qu'elle a été calculée correctement. 𝗖𝗼𝗺𝗺𝗲𝗻𝘁 𝗰𝗲𝗹𝗮 𝗳𝗼𝗻𝗰𝘁𝗶𝗼𝗻𝗻𝗲 (𝗰𝗼𝗻𝗰𝗲𝗽𝘁𝘂𝗲𝗹𝗹𝗲𝗺𝗲𝗻𝘁) ➤ Les ordres sont collectés et appariés hors chaîne (vous pouvez donc obtenir une exécution à faible latence). ➤ Au lieu de publier l'intégralité du flux d'ordres, le système publie : - 𝘂𝘀𝘁𝘦 𝘤𝘰𝘮𝘮𝘪𝘵𝘵𝘦𝘯𝘵 𝘢 𝘭'𝘦𝘵𝘵𝘦𝘳𝘦 / 𝘴𝘵𝘢𝘵𝘦 𝘵𝘳𝘢𝘯𝘴𝘪𝘵𝘪𝘰𝘯 (𝘦𝘳𝘦𝘳𝘦𝘳𝘦 𝘢 𝘶𝘯 𝘴𝘵𝘢𝘵𝘦 𝘳𝘰𝘰𝘵) - 𝘶𝘯 𝘻𝘬-𝘱𝘳𝘰𝘰𝘧 𝘲𝘶𝘦 𝘭𝘦 𝘮𝘢𝘵𝘤𝘩𝘪𝘯𝘨 + 𝘤𝘩𝘦𝘤𝘬𝘴 𝘥𝘦 𝘳𝘪𝘴𝘲𝘶𝘦 + 𝘭𝘦𝘴 𝘶𝘱𝘥𝘢𝘵𝘦𝘴 𝘥𝘦 𝘣𝘢𝘭𝘢𝘯𝘤𝘦 𝘴𝘦𝘳𝘦𝘯𝘵 𝘦𝘧𝘧𝘦𝘤𝘵𝘶𝘦𝘴 𝘢𝘤𝘤𝘰𝘳𝘥𝘪𝘯𝘨 𝘢𝘶𝘹 𝘳𝘦𝘶𝘭𝘦𝘴 𝘥𝘦 𝘭𝘦 𝘱𝘳𝘰𝘵𝘰𝘤𝘰𝘭, - 𝘦𝘯𝘰𝘶𝘨𝘩 𝘥𝘢𝘵𝘢 𝘢𝘷𝘢𝘪𝘭𝘢𝘣𝘪𝘭𝘪𝘵𝘺 𝘴𝘰 𝘲𝘶𝘦 𝘭𝘦𝘴 𝘶𝘴𝘦𝘳𝘴 𝘱𝘦𝘶𝘵 𝘴𝘵𝘪𝘭𝘭 𝘦𝘹𝘪𝘵 𝘦𝘷𝘦𝘯 𝘴𝘪 𝘭'𝘰𝘱𝘦𝘳𝘢𝘵𝘦𝘶𝘳 𝘥𝘪𝘴𝘢𝘱𝘱𝘦𝘢𝘪𝘳. Cette "disponibilité de données suffisante" est là où le choix de conception de @hibachi_xyz est intéressant : Hibachi exécute un CLOB haute performance et publie des données d'état / de transaction cryptées sur @Celestia (de sorte que les stratégies et les positions ne soient pas publiques), tout en publiant des preuves afin que les mises à jour restent vérifiables, en utilisant SP1 (le zkVM de Succinct) pour prouver le CLOB. 𝗠𝗮𝗶𝘀 𝗾𝘂𝗲𝘀𝗾𝘂𝗲 𝗹𝗮 𝗳𝗼𝗻𝗰𝘁𝗶𝗼𝗻 𝗱𝗲 𝗺𝗮𝘁𝗰𝗵𝗶𝗻𝗴 𝗲𝘀𝘁 𝗰𝗼𝗿𝗿𝗲𝗰𝘁 𝗲𝗻 𝘁𝗲𝗿𝗺𝗲𝘀 𝗱𝗲 𝗽𝗿𝗼𝗼𝗳 ? Un zk-proof peut faire respecter les mêmes invariants que vous vous fieriez normalement à un opérateur d'échange pour suivre, par exemple : ➤ Les ordres n'étaient appariés que lorsque les prix se croisent (pas de remplissages impossibles). ➤ La séquence de remplissage respectait la règle de priorité du lieu (par exemple, priorité prix-temps, ou ce que le lieu spécifie). ➤ Les soldes/marges étaient mis à jour correctement (pas de modifications de solde cachées). ➤ La racine d'état résultante est exactement ce que vous obtenez en appliquant les règles à la racine d'état précédente + le lot. Vous pouvez garder le contenu privé (ordres, tailles, positions) en cryptant ce qui est publié sur la couche DA, tandis que la preuve convainc tout le monde que la mise à jour cryptée est toujours une transition d'état valide.

𝗥𝗼𝗯𝗼𝘁𝗶𝗰𝘀 𝘀𝗮𝗳𝗲𝘁𝘆 𝗿𝗲𝗴𝘂𝗹𝗮𝘁𝗶𝗼𝗻 𝘂𝗽𝗱𝗮𝘁𝗲𝘀 (𝗨𝗦/𝗘𝗨) D'ici la fin de 2025, l'histoire réglementaire concernant les "robots dans les espaces publics" est différente dans l'UE par rapport aux États-Unis. Dans l'UE, la direction est vers une pile de conformité unique et stratifiée : ➤ sécurité des produits (pour la machine physique) ➤ cybersécurité (car les robots sont connectés) ➤ et gouvernance de l'IA (car l'autonomie et la perception sont pilotées par l'IA) Les équipes ont besoin de documentation, de contrôles de cycle de vie, et (dans certains cas) de flux de travail de classification des risques liés à l'IA fonctionnant en parallèle (réglementation classique pour l'UE, beaucoup de limitations et de paperasse). Aux États-Unis, le tableau est plus sectoriel : les "mises à jour" fédérales les plus claires se trouvent dans l'autonomie sur route (rapports d'accidents NHTSA et voies de déploiement/exemption) et les drones (application de l'ID à distance FAA). Pour les robots terrestres sur les trottoirs et dans les lieux publics intérieurs, les règles restent plus fragmentées et souvent locales.