ZK-доказуемое соответствие — это способ работы быстрого, приватного ордербука, при этом предоставляя пользователям криптографическую гарантию того, что механизм соответствия следовал правилам. Проблема, которую он решает, проста: CLOB нуждается в операторе (или небольшой группе операторов), чтобы быстро сопоставлять заказы, но этот оператор также может обмануть (переставить, пропустить или выборочно заполнить). ZK меняет модель доверия: оператор может оставаться быстрым, но не может завершить обновление, если не докажет, что оно было вычислено правильно. 𝗛𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀 (𝗰𝗼𝗻𝗰𝗲𝗽𝘁𝘂𝗮𝗹𝗹𝘆) ➤ Заказы собираются и сопоставляются вне цепи (так что вы можете получить выполнение с низкой задержкой). ➤ Вместо публикации полного потока заказов система публикует: - 𝘢 𝘤𝘰𝘮𝘮𝘪𝘵𝘮𝘦𝘯𝘵 𝘵𝘰 𝘵𝘩𝘦 𝘣𝘢𝘵𝘤𝘩 / 𝘴𝘵𝘢𝘵𝘦 𝘵𝘳𝘢𝘯𝘴𝘪𝘵𝘪𝘰𝘯 (𝘰𝘧𝘵𝘦𝘯 𝘢 𝘴𝘵𝘢𝘵𝘦 𝘳𝘰𝘰𝘵) - 𝘢 𝘻𝘬-𝘱𝘳𝘰𝘰𝘧 𝘵𝘩𝘢𝘵 𝘵𝘩𝘦 𝘮𝘢𝘵𝘤𝘩𝘪𝘯𝘨 + 𝘳𝘪𝘴𝘬 𝘤𝘩𝘦𝘤𝘬𝘴 + 𝘣𝘢𝘭𝘢𝘯𝘤𝘦 𝘶𝘱𝘥𝘢𝘵𝘦𝘴 𝘸𝘦𝘳𝘦 𝘥𝘰𝘯𝘦 𝘢𝘤𝘤𝘰𝘳𝘥𝘪𝘯𝘨 𝘵𝘰 𝘵𝘩𝘦 𝘱𝘳𝘰𝘵𝘰𝘤𝘰𝘭 𝘳𝘶𝘭𝘦𝘴, - 𝘦𝘯𝘰𝘶𝘨𝘩 𝘥𝘢𝘵𝘢 𝘢𝘷𝘢𝘪𝘭𝘢𝘣𝘪𝘭𝘪𝘵𝘺 𝘴𝘰 𝘶𝘴𝘦𝘳𝘴 𝘤𝘢𝘯 𝘴𝘵𝘪𝘭𝘭 𝘦𝘹𝘪𝘵 𝘦𝘷𝘦𝘯 𝘪𝘧 𝘵𝘩𝘦 𝘰𝘱𝘦𝘳𝘢𝘵𝘰𝘳 𝘥𝘪𝘴𝘢𝘱𝘱𝘦𝘢𝘳𝘴. Это "достаточная доступность данных" — вот где выбор дизайна @hibachi_xyz интересен: Hibachi работает с высокопроизводительным CLOB и публикует зашифрованные данные о состоянии / сделках в @Celestia (так что стратегии и позиции не являются публичными), при этом публикуя доказательства, чтобы обновления оставались проверяемыми, используя SP1 (zkVM от Succinct), чтобы доказать CLOB. 𝗕𝘂𝘁 𝘄𝗵𝗮𝘁 “𝗺𝗮𝘁𝗰𝗵𝗶𝗻𝗴 𝘄𝗮𝘀 𝗰𝗼𝗿𝗿𝗲𝗰𝘁” 𝗺𝗲𝗮𝗻𝘀 𝗶𝗻 𝗽𝗿𝗼𝗼𝗳 𝘁𝗲𝗿𝗺𝘀? ZK-доказательство может обеспечить те же инварианты, на которые вы обычно полагаетесь, чтобы оператор биржи следовал, например: ➤ Заказы сопоставлялись только тогда, когда цены пересекаются (без невозможных заполнений). ➤ Последовательность заполнения соблюдала правило приоритета площадки (например, приоритет по цене и времени или любое другое, что указывает площадка). ➤ Балансы/маржи обновлялись правильно (без скрытых редактирований баланса). ➤ Результирующий корень состояния — это именно то, что вы получаете, применяя правила к предыдущему корню состояния + партии. Вы можете сохранить содержимое приватным (заказы, размеры, позиции), зашифровав то, что публикуется на уровне DA, в то время как доказательство убеждает всех в том, что зашифрованное обновление все еще является действительным переходом состояния.

𝗥𝗼𝗯𝗼𝘁𝗶𝗰𝘀 𝘀𝗮𝗳𝗲𝘁𝘆 𝗿𝗲𝗴𝘂𝗹𝗮𝘁𝗶𝗼𝗻 𝘂𝗽𝗱𝗮𝘁𝗲𝘀 (𝗨𝗦/𝗘𝗨) К концу 2025 года регуляторная ситуация для «роботов в общественных местах» выглядит по-разному в ЕС и США. В ЕС направление идет к единой, многоуровневой системе соблюдения норм: ➤ безопасность продукта (для физической машины) ➤ кибербезопасность (поскольку роботы подключены) ➤ и управление ИИ (поскольку автономия и восприятие управляются ИИ) Командам необходима документация, контроль жизненного цикла и (в некоторых случаях) рабочие потоки классификации рисков ИИ, работающие параллельно (классическое регулирование для ЕС, много ограничений и бумажной работы). В США ситуация более секторальная: самые четкие федеральные «обновления» касаются автономии на дорогах (отчеты о ДТП NHTSA и пути развертывания/освобождения) и дронов (принудительное соблюдение FAA Remote ID). Для наземных роботов на тротуарах и в общественных помещениях правила остаются более фрагментированными и часто местными.

𝗧𝗿𝗮𝗰𝗸𝗶𝗻𝗴 𝗮𝗻𝗱 𝗼𝗯𝗷𝗲𝗰𝘁 𝗱𝗲𝘁𝗲𝗰𝘁𝗶𝗼𝗻 𝗳𝗼𝗿 𝗿𝗼𝗯𝗼𝘁𝗶𝗰𝘀 В робототехнике обнаружение объектов — это моментальный снимок: "на этом кадре есть бутылка на (x, y)." Отслеживание объектов — это более сложная, операционная задача: "это та же бутылка, что и раньше, она двигалась так, и она все еще там, даже если я не вижу ее в течение 200 мс." Представьте себе мобильного манипулятора на кухонном столе. Задача проста на бумаге: взять синюю бутылку с загроможденного стола, пока рядом движется человек. У робота есть камера (возможно, также и глубинная). Он запускает детектор объектов и получает ограничивающий прямоугольник с меткой "бутылка" и коэффициентом уверенности. Это звучит как восприятие. Но это еще не так. На кадре 1 детектор видит бутылку. На кадре 2 рука человека частично закрывает ее, уверенность падает, и прямоугольник исчезает. На кадре 3 бутылка снова появляется, но детектор немного смещает прямоугольник. С точки зрения планировщика бутылка исчезла и телепортировалась. В загроможденной обстановке вы также получаете дубликаты: детектор может создать два правдоподобных "бутылочных" прямоугольника для одного и того же объекта. Если робот реагирует непосредственно на обнаружения в каждом кадре, вы видите классические ошибки: ➤ он колеблется, потому что цель "пропала" каждые несколько кадров, ➤ он постоянно пересчитывает, потому что позиция цели дрожит, ➤ он тянется к неправильному объекту, когда появляются два похожих предмета, ➤ он не может надежно соблюдать правило "не сталкиваться с человеком", потому что прямоугольник человека тоже мерцает. Вот почему восприятие в робототехнике редко останавливается на обнаружении. Ему нужна постоянство объектов: способность сказать "это все еще та же бутылка, даже если я на мгновение потерял ее из виду." Отслеживание — это то, что превращает предположения из кадра в кадр в стабильную модель мира. Типичный подход — это "отслеживание по обнаружению": вы все еще запускаете детектор каждый кадр, но прикрепляете обнаружения к постоянным трекам (ИД) с течением времени, используя предсказание + ассоциацию. Конкретно, трекер делает три вещи: ➤ Предсказывает "где должна быть бутылка сейчас?" ➤ Ассоциирует "какое обнаружение принадлежит какому треку?" ➤ Поддерживает идентичность при изменениях Вернемся к нашей сцене со столом: как только вы начинаете отслеживание, бутылка перестает мерцать. У нее есть стабильный ИД, сглаженная оценка позиции и часто оценка скорости. Теперь планировщик может вести себя как взрослый: он может подождать короткое изменение в окружении, сосредоточиться на одной цели и спланировать безопасную траекторию вокруг движущегося человека. Даже с отслеживанием робот все еще не знает, что он делает с точки зрения человека. У него есть "Трек #7" с ограничивающим прямоугольником и, возможно, классом "бутылка." Этого недостаточно для реальных задач, потому что реальные задачи связаны с отношениями и намерениями: ➤ "Возьмите синюю бутылку (не прозрачную)." ➤ "Не тянитесь через человека." ➤ "Бутылка за кружкой." ➤ "Если человек тянется к ней, остановитесь." Вот где LLM (часто в паре с VLM) могут помочь, рассуждая над структурированным представлением сцены, построенным из треков. Ключевое здесь то, что LLM должен работать в стабильном состоянии. Если вы подаете ему сырые обнаружения по кадрам, вы получите низкое рассуждение, потому что его входные данные мерцают. Отслеживание делает семантический слой согласованным.