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.

𝗧𝗿𝗮𝗰𝗸𝗶𝗻𝗴 𝗲𝘁 𝗱𝗲𝘁𝗲𝗰𝘁𝗶𝗼𝗻 𝗱'𝗼𝗯𝗷𝗲𝘁 𝗽𝗼𝘂𝗿 𝗹𝗲𝘀 𝗿𝗼𝗯𝗼𝘁𝘀 Dans la robotique, la détection d'objets est un instantané : « il y a une bouteille à (x, y) dans ce cadre. » Le suivi d'objets est la chose plus difficile et plus opérationnelle : « c'est la même bouteille que précédemment, elle a bougé comme ça, et elle est toujours là même si je ne la vois pas pendant 200 ms. » Imaginez un manipulateur mobile sur un plan de travail de cuisine. La tâche est simple sur le papier : prendre la bouteille bleue d'une table encombrée pendant qu'une personne se déplace à proximité. Le robot a une caméra (peut-être aussi une caméra de profondeur). Il exécute un détecteur d'objets et obtient une boîte englobante étiquetée « bouteille » avec un score de confiance. Cela ressemble à de la perception. Ce n'est pas encore le cas. Dans le cadre 1, le détecteur voit la bouteille. Dans le cadre 2, le bras de la personne l'occlut partiellement, la confiance diminue et la boîte disparaît. Dans le cadre 3, la bouteille réapparaît mais le détecteur déplace légèrement la boîte. Du point de vue du planificateur, la bouteille a clignoté hors de l'existence et s'est téléportée. Dans le désordre, vous obtenez également des doublons : le détecteur peut produire deux boîtes « bouteille » plausibles pour le même objet. Si le robot réagit directement aux détections par cadre, vous voyez des comportements d'échec classiques : ➤ il hésite parce que la cible est « manquante » tous les quelques cadres, ➤ il replanifie constamment parce que la position de la cible tremble, ➤ il atteint l'objet incorrect lorsque deux articles similaires apparaissent, ➤ il ne peut pas appliquer de manière fiable « ne pas entrer en collision avec la personne » parce que la boîte de la personne clignote aussi. C'est pourquoi la perception robotique ne s'arrête que rarement à la détection. Elle a besoin de permanence des objets : la capacité de dire « c'est toujours la même bouteille, même si je la perds de vue brièvement. » Le suivi est ce qui transforme les suppositions cadre par cadre en un modèle du monde stable. Une approche typique est le « suivi par détection » : vous exécutez toujours un détecteur à chaque cadre, mais vous attachez les détections à des pistes persistantes (IDs) au fil du temps en utilisant la prédiction + l'association. Concrètement, le suiveur fait trois choses : ➤ Prédire « où devrait être la bouteille maintenant ? » ➤ Associer « quelle détection appartient à quelle piste ? » ➤ Maintenir l'identité sous les changements Revenons à notre scène de table : une fois que vous suivez, la bouteille cesse de clignoter. Elle a un ID stable, une estimation de position lissée, et souvent une estimation de vitesse. Maintenant, le planificateur peut se comporter comme un adulte : il peut attendre un court changement d'environnement, s'engager sur une cible, et planifier une trajectoire sûre autour d'une personne en mouvement. Même avec le suivi, le robot ne sait toujours pas ce qu'il fait en termes humains. Il a « Suivi #7 » avec une boîte englobante et peut-être une étiquette de classe « bouteille. » Ce n'est pas suffisant pour des tâches réelles car les tâches réelles concernent les relations et l'intention : ➤ « Prenez la bouteille bleue (pas la transparente). » ➤ « Ne pas atteindre à travers la personne. » ➤ « La bouteille est derrière la tasse. » ➤ « Si la personne tend la main pour l'attraper, faites une pause. » C'est là que les LLM (souvent associés aux VLM) peuvent aider en raisonnant sur une représentation structurée de la scène construite à partir des pistes. La clé est que le LLM doit fonctionner dans un état stable. Si vous lui fournissez des détections brutes par cadre, vous obtiendrez un raisonnement faible car ses entrées clignotent. Le suivi rend la couche sémantique cohérente.