La coincidencia verificable por ZK es una forma de ejecutar un libro de órdenes rápido y privado, mientras se brinda a los usuarios una garantía criptográfica de que el motor de coincidencia siguió las reglas. El problema que resuelve es simple: un CLOB necesita un operador (o un pequeño conjunto de operadores) para emparejar órdenes rápidamente, pero ese operador también puede hacer trampa (reordenar, omitir o llenar selectivamente). ZK cambia el modelo de confianza: el operador puede seguir siendo rápido, pero no puede finalizar una actualización a menos que demuestre que se calculó correctamente. 𝗖𝗼́𝗺𝗼 𝗮𝗯𝗮𝗷𝗮 𝗲𝘀𝘁𝗼 (𝗰𝗼𝗻𝗰𝗲𝗽𝘁𝘂𝗮𝗹𝗹𝘆) ➤ Las órdenes se recopilan y se emparejan fuera de la cadena (así puedes obtener una ejecución de baja latencia). ➤ En lugar de publicar el flujo completo de órdenes, el sistema publica: - 𝘂𝘁𝘁𝘦𝘳𝘦𝘴 𝘵𝘰 𝘵𝘩𝘦 𝘣𝘢𝘵𝘤𝘩 / 𝘴𝘵𝘢𝘵𝘦 𝘵𝘳𝘢𝘯𝘴𝘪𝘵𝘪𝘰𝘯 (𝘰𝘧𝘵𝘦𝘯 𝘢 𝘴𝘵𝘢𝘵𝘦 𝘳𝘰𝘰𝘵) - 𝘢 𝘻𝘬-𝘱𝘳𝘰𝘰𝘧 𝘵𝘩𝘢𝘵 𝘵𝘩𝘦 𝘮𝘢𝘵𝘤𝘩𝘪𝘯𝘨 + 𝘳𝘪𝘴𝘬 𝘤𝘩𝘦𝘤𝘬𝘴 + 𝘣𝘢𝘭𝘢𝘯𝘤𝘦 𝘶𝘱𝘥𝘢𝘵𝘦𝘴 𝘸𝘦𝘳𝘦 𝘥𝘰𝘯𝘦 𝘢𝘤𝘤𝘰𝘳𝘥𝘪𝘯𝘨 𝘵𝘰 𝘵𝘩𝘦 𝘱𝘳𝘰𝘵𝘰𝘤𝘰𝘭 𝘳𝘶𝘭𝘦𝘴, - 𝘦𝘯𝘰𝘶𝘨𝘩 𝘥𝘢𝘵𝘢 𝘢𝘷𝘢𝘪𝘭𝘢𝘣𝘪𝘭𝘪𝘵𝘺 𝘴𝘰 𝘶𝘴𝘦𝘳𝘴 𝘤𝘢𝘯 𝘴𝘵𝘪𝘭𝘭 𝘦𝘹𝘪𝘵 𝘦𝘷𝘦𝘯 𝘪𝘧 𝘵𝘩𝘦 𝘰𝘱𝘦𝘳𝘢𝘵𝘰𝘳 𝘥𝘪𝘴𝘢𝘱𝘱𝘦𝘢𝘳𝘴. Esa “suficiente disponibilidad de datos” es donde la elección de diseño de @hibachi_xyz es interesante: Hibachi está ejecutando un CLOB de alto rendimiento y publicando datos de estado / comercio cifrados en @Celestia (para que las estrategias y posiciones no sean públicas), mientras sigue publicando pruebas para que las actualizaciones sigan siendo verificables, utilizando SP1 (zkVM de Succinct) para probar el CLOB. 𝗠𝗮𝘀 𝗾𝘂𝗲 𝗲𝗹 𝗺𝗲𝗮𝗻𝗶𝗻𝗴 𝗼𝗳 “𝗺𝗮𝘁𝗰𝗵𝗶𝗻𝗴 𝘄𝗮𝘀 𝗰𝗼𝗿𝗿𝗲𝗰𝘁” 𝗶𝗻 𝗽𝗿𝗼𝗼𝗳 𝘁𝗲𝗿𝗺𝘀? Una prueba zk puede hacer cumplir las mismas invariantes en las que normalmente confiarías en un operador de intercambio, por ejemplo: ➤ Las órdenes se emparejaron solo cuando los precios se cruzaron (sin llenados imposibles). ➤ La secuencia de llenado respetó la regla de prioridad del lugar (por ejemplo, prioridad de precio-tiempo, o lo que el lugar especifique). ➤ Los saldos/márgenes se actualizaron correctamente (sin ediciones ocultas de saldo). ➤ La raíz de estado resultante es exactamente lo que obtienes al aplicar las reglas a la raíz de estado anterior + el lote. Puedes mantener los contenidos privados (órdenes, tamaños, posiciones) cifrando lo que se publica en la capa de DA, mientras que la prueba convence a todos de que la actualización cifrada sigue siendo una transición de estado válida.

𝗥𝗼𝗯𝗼𝘁𝗶𝗰𝘀 𝘀𝗮𝗳𝗲𝘁𝘆 𝗿𝗲𝗴𝘂𝗹𝗮𝘁𝗶𝗼𝗻 𝘂𝗽𝗱𝗮𝘁𝗲𝘀 (𝗨𝗦/𝗘𝗨) Para finales de 2025, la historia regulatoria sobre "robots en espacios públicos" se ve diferente en la UE en comparación con EE. UU. En la UE, la dirección es hacia un único conjunto de cumplimiento por capas: ➤ seguridad del producto (para la máquina física) ➤ ciberseguridad (porque los robots están conectados) ➤ y gobernanza de la IA (porque la autonomía y la percepción son impulsadas por IA) Los equipos necesitan documentación, controles del ciclo de vida y (en algunos casos) flujos de trabajo de clasificación de riesgos de IA funcionando en paralelo (regulación clásica para la UE, muchas limitaciones y papeleo). En EE. UU., la imagen es más sectorial: las "actualizaciones" federales más claras se encuentran en la autonomía en carretera (informes de accidentes de NHTSA y vías de despliegue/exención) y drones (aplicación de ID remota de la FAA). Para robots terrestres en aceras y lugares públicos interiores, las reglas siguen siendo más fragmentadas y a menudo locales.

𝗧𝗿𝗮𝗰𝗸𝗶𝗻𝗴 𝗮𝗻𝗱 𝗼𝗯𝗷𝗲𝗰𝘁 𝗱𝗲𝘁𝗲𝗰𝘁𝗶𝗼𝗻 𝗳𝗼𝗿 𝗿𝗼𝗯𝗼𝘁𝗶𝗰𝘀 En robótica, la detección de objetos es una instantánea: “hay una botella en (x, y) en este fotograma.” El seguimiento de objetos es la tarea más difícil y operativa: “esta es la misma botella que antes, se movió así, y sigue ahí incluso si no la veo durante 200 ms.” Imagina un manipulador móvil en una encimera de cocina. La tarea es simple sobre el papel: recoger la botella azul de una mesa desordenada mientras una persona se mueve cerca. El robot tiene una cámara (quizás también de profundidad). Ejecuta un detector de objetos y obtiene un cuadro delimitador etiquetado como “botella” con un puntaje de confianza. Eso suena como percepción. Aún no lo es. En el fotograma 1, el detector ve la botella. En el fotograma 2, el brazo de la persona la oculta parcialmente, la confianza disminuye y el cuadro desaparece. En el fotograma 3, la botella reaparece, pero el detector desplaza ligeramente el cuadro. Desde la perspectiva del planificador, la botella ha parpadeado fuera de existencia y se ha teletransportado. En el desorden, también obtienes duplicados: el detector podría producir dos cuadros plausibles de “botella” para el mismo objeto. Si el robot reacciona directamente a las detecciones por fotograma, verás comportamientos de fallo clásicos: ➤ duda porque el objetivo está “faltando” cada pocos fotogramas, ➤ replantea constantemente porque la posición del objetivo tiembla, ➤ se dirige hacia el objeto equivocado cuando aparecen dos artículos similares, ➤ no puede hacer cumplir de manera confiable “no chocar con la persona” porque el cuadro de la persona también parpadea. Por eso la percepción en robótica rara vez se detiene en la detección. Necesita permanencia del objeto: la capacidad de decir “esta sigue siendo la misma botella, incluso si pierdo la vista de ella brevemente.” El seguimiento es lo que convierte las conjeturas fotograma a fotograma en un modelo de mundo estable. Un enfoque típico es “seguimiento por detección”: aún ejecutas un detector en cada fotograma, pero asocias las detecciones a pistas persistentes (IDs) a lo largo del tiempo utilizando predicción + asociación. Concretamente, el rastreador hace tres cosas: ➤ Predecir “¿dónde debería estar la botella ahora?” ➤ Asociar “¿qué detección pertenece a qué pista?” ➤ Mantener la identidad bajo cambios Volviendo a nuestra escena de la mesa: una vez que haces seguimiento, la botella deja de parpadear. Tiene un ID estable, una estimación de posición suavizada y a menudo una estimación de velocidad. Ahora el planificador puede comportarse como un adulto: puede esperar un breve cambio en el entorno, comprometerse con un objetivo y planificar una trayectoria segura alrededor de una persona en movimiento. Incluso con el seguimiento, el robot aún no sabe lo que está haciendo en términos humanos. Tiene “Seguimiento #7” con un cuadro delimitador y tal vez una etiqueta de clase “botella.” Eso no es suficiente para tareas reales porque las tareas reales se tratan de relaciones e intenciones: ➤ “Recoge la botella azul (no la clara).” ➤ “No te acerques a la persona.” ➤ “La botella está detrás de la taza.” ➤ “Si la persona está alcanzándola, pausa.” Aquí es donde los LLM (a menudo emparejados con VLM) pueden ayudar razonando sobre una representación estructurada de la escena construida a partir de pistas. La clave es que el LLM debe operar en un estado estable. Si le alimentas detecciones crudas por fotograma, obtendrás un razonamiento bajo porque sus entradas parpadean. El seguimiento hace que la capa semántica sea coherente.