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). ➤ Der resultierende Status-Root ist genau das, was Sie erhalten, indem Sie die Regeln auf den vorherigen Status-Root + die Batch anwenden. Sie können die Inhalte privat halten (Aufträge, Größen, Positionen), indem Sie das, was an die DA-Schicht veröffentlicht wird, verschlüsseln, während der Beweis alle überzeugt, dass das verschlüsselte Update immer noch eine gültige Statusübergang ist.

𝗥𝗼𝗯𝗼𝘁𝗶𝗰𝘀 𝘀𝗮𝗳𝗲𝘁𝘆 𝗿𝗲𝗴𝘂𝗹𝗮𝘁𝗶𝗼𝗻 𝘂𝗽𝗱𝗮𝘁𝗲𝘀 (𝗨𝗦/𝗘𝗨) Bis Ende 2025 sieht die regulatorische Situation für „Roboter in öffentlichen Räumen“ in der EU anders aus als in den USA. In der EU geht die Richtung hin zu einem einheitlichen, gestuften Compliance-Stack: ➤ Produktsicherheit (für die physische Maschine) ➤ Cybersicherheit (weil Roboter vernetzt sind) ➤ und KI-Governance (weil Autonomie und Wahrnehmung KI-gesteuert sind) Teams benötigen Dokumentation, Lebenszykluskontrollen und (in einigen Fällen) KI-Risikoklassifizierungs-Workstreams, die parallel laufen (klassische Regulierung für die EU, viele Einschränkungen und Papierkram). In den USA ist das Bild stärker sektorenbasiert: die klarsten bundesstaatlichen „Updates“ befinden sich im Bereich der On-Road-Autonomie (NHTSA-Unfallberichterstattung und Bereitstellungs-/Ausnahmewege) und Drohnen (FAA Remote ID-Durchsetzung). Für Bodenroboter auf Gehwegen und in öffentlichen Innenräumen bleiben die Regeln fragmentierter und oft lokal.

𝗧𝗿𝗮𝗰𝗸𝗶𝗻𝗴 𝗮𝗻𝗱 𝗼𝗯𝗷𝗲𝗰𝘁 𝗱𝗲𝘁𝗲𝗰𝘁𝗶𝗼𝗻 𝗳𝗼𝗿 𝗿𝗼𝗯𝗼𝘁𝗶𝗰𝘀 In der Robotik ist die Objekterkennung ein Schnappschuss: „Es gibt eine Flasche bei (x, y) in diesem Bild.“ Objektverfolgung ist die schwierigere, operationale Sache: „Das ist die gleiche Flasche wie zuvor, sie hat sich so bewegt, und sie ist immer noch da, auch wenn ich sie für 200 ms nicht sehe.“ Stellen Sie sich einen mobilen Manipulator an einer Küchenzeile vor. Die Aufgabe ist auf dem Papier einfach: Nehmen Sie die blaue Flasche von einem überladenen Tisch, während sich eine Person in der Nähe bewegt. Der Roboter hat eine Kamera (vielleicht auch eine Tiefenkamera). Er führt einen Objekterkenner aus und erhält eine Begrenzungsbox, die mit „Flasche“ beschriftet ist, mit einem Vertrauensscore. Das klingt nach Wahrnehmung. Ist es aber noch nicht. Im Bild 1 sieht der Detektor die Flasche. Im Bild 2 verdeckt der Arm der Person teilweise die Flasche, das Vertrauen sinkt, und die Box verschwindet. Im Bild 3 taucht die Flasche wieder auf, aber der Detektor verschiebt die Box leicht. Aus der Perspektive des Planers ist die Flasche aus dem Dasein verschwunden und teleportiert. In einem Durcheinander gibt es auch Duplikate: Der Detektor könnte zwei plausible „Flasche“-Boxen für dasselbe Objekt erzeugen. Wenn der Roboter direkt auf die Erkennungen pro Bild reagiert, sieht man klassische Fehlverhalten: ➤ Er zögert, weil das Ziel in jedem zweiten Bild „fehlt“, ➤ Er plant ständig neu, weil die Zielposition schwankt, ➤ Er greift nach dem falschen Objekt, wenn zwei ähnliche Gegenstände erscheinen, ➤ Er kann nicht zuverlässig durchsetzen, „nicht mit der Person zu kollidieren“, weil die Box der Person ebenfalls flackert. Deshalb hört die Wahrnehmung in der Robotik selten bei der Erkennung auf. Sie benötigt Objektpermanenz: die Fähigkeit zu sagen „das ist immer noch die gleiche Flasche, auch wenn ich sie kurz aus den Augen verliere.“ Tracking verwandelt die Schätzungen von Bild zu Bild in ein stabiles Weltmodell. Ein typischer Ansatz ist „Tracking durch Erkennung“: Sie führen weiterhin einen Detektor in jedem Bild aus, aber Sie verknüpfen die Erkennungen über die Zeit mit beständigen Verfolgungen (IDs) unter Verwendung von Vorhersage + Assoziation. Konkret macht der Tracker drei Dinge: ➤ Vorhersagen „Wo sollte die Flasche jetzt sein?“ ➤ Assoziieren „Welche Erkennung gehört zu welcher Verfolgung?“ ➤ Identität unter Veränderungen aufrechterhalten Zurück zu unserer Tischszene: Sobald Sie verfolgen, hört die Flasche auf zu blinken. Sie hat eine stabile ID, eine geglättete Positionsschätzung und oft eine Geschwindigkeitsabschätzung. Jetzt kann der Planer sich wie ein Erwachsener verhalten: Er kann eine kurze Umweltveränderung abwarten, sich auf ein Ziel festlegen und eine sichere Trajektorie um eine sich bewegende Person planen. Selbst mit Tracking weiß der Roboter immer noch nicht, was er in menschlichen Begriffen tut. Er hat „Track #7“ mit einer Begrenzungsbox und vielleicht einem Klassenlabel „Flasche“. Das reicht nicht für echte Aufgaben, denn echte Aufgaben betreffen Beziehungen und Absichten: ➤ „Nehmen Sie die blaue Flasche (nicht die klare).“ ➤ „Reichen Sie nicht über die Person hinweg.“ ➤ „Die Flasche ist hinter der Tasse.“ ➤ „Wenn die Person danach greift, pausieren.“ Hier können LLMs (oft in Kombination mit VLMs) helfen, indem sie über eine strukturierte Darstellung der Szene nachdenken, die aus Verfolgungen aufgebaut ist. Der Schlüssel ist, dass das LLM in einem stabilen Zustand arbeiten muss. Wenn Sie ihm rohe Erkennungen pro Bild füttern, erhalten Sie ein niedriges Denkvermögen, weil seine Eingaben flackern. Tracking macht die semantische Ebene kohärent.