La correspondencia verificable por ZK es una forma de gestionar un libro de pedidos rápido y privado mientras se ofrece a los usuarios una garantía criptográfica de que el motor de emparejamiento sigue las reglas. El problema que resuelve es sencillo: 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, saltarse o llenar selectivamente). ZK cambia el modelo de confianza: el operador puede mantenerse rápido, pero no puede finalizar una actualización a menos que demuestre que se calculó correctamente. Cómo funciona (conceptualmente) ➤ Las órdenes se recogen y emparejan fuera de la cadena (para que puedas obtener una ejecución de baja latencia). ➤ En lugar de publicar el flujo completo de órdenes, el sistema publica: - un compromiso con la transición por lotes / estado (a menudo una raíz de estado) - una prueba zk de que las actualizaciones de coincidencia + control de riesgo + balance se realizaron según las reglas del protocolo, - suficiente disponibilidad de datos para que los usuarios puedan salir incluso si el operador desaparece. Esa "suficiente disponibilidad de datos" es donde la elección de diseño de @hibachi_xyz resulta interesante: Hibachi está ejecutando un CLOB de alto rendimiento y publicando datos cifrados de estado/comercio a @Celestia (para que las estrategias y posiciones no sean públicas), mientras sigue publicando pruebas para que las actualizaciones sean verificables, usando SP1 (zkVM de Succinct) para demostrar el CLOB. Pero, ¿qué significa "coincidencia correcta" en términos de demostración? Una prueba zk puede imponer los mismos invariantes que normalmente dependerías de un operador de intercambio para seguir, por ejemplo: ➤ Los pedidos se emparejaban solo cuando los precios se cruzaban (sin rellenos imposibles). ➤ La secuencia de llenado respetaba la regla de prioridad del lugar (por ejemplo, prioridad precio-tiempo, o lo que especifique el local). ➤ Los saldos/márgenes se actualizaron correctamente (sin ediciones ocultas de saldo). ➤ La raíz de estado resultante es exactamente lo que obtienes aplicando las reglas a la raíz de estado anterior + el lote. Puedes mantener el contenido privado (órdenes, tamaños, posiciones) cifrando lo que se publica en la capa DA, mientras la prueba convence a todos de que la actualización cifrada sigue siendo una transición de estado válida.

Actualizaciones de la regulación de seguridad robótica (EE. UU./UE) A finales de 2025, la situación regulatoria para los "robots en espacios públicos" es diferente en la UE frente a Estados Unidos. En la UE, la dirección es hacia una única pila de cumplimiento en capas: ➤ Seguridad del producto (para la máquina física) ➤ Ciberseguridad (porque los robots están conectados) ➤ y la gobernanza de la IA (porque la autonomía y la percepción están impulsadas por la IA) Los equipos necesitan documentación, controles del ciclo de vida y (en algunos casos) flujos de trabajo de clasificación de riesgos por IA que funcionen en paralelo (regulación clásica para la UE, muchas limitaciones y papeleo). En Estados Unidos, la situación es más sectorial: las "actualizaciones" federales más claras se sitúan en la autonomía en carretera (informes de accidentes de la NHTSA y vías de despliegue/exención) y drones (aplicación de la FAA Remote ID). Para los robots terrestres en aceras y espacios públicos cubiertos, las normas siguen siendo más fragmentadas y a menudo locales.

Seguimiento y detección de objetos para robótica En robótica, la detección de objetos es una instantánea: "hay una botella en (x, y) en este marco." El seguimiento de objetos es lo más difícil y operativo: "esta es la misma botella que antes, se movía así, y sigue ahí aunque no la vea en 200 ms." Imagina un manipulador móvil en la encimera de la cocina. La tarea es sencilla en el papel: coger la botella azul de una mesa desordenada mientras una persona se mueve cerca. El robot tiene cámara (quizá también profundidad). Ejecuta un detector de objetos y recibe una caja delimitadora etiquetada como "botella" con una puntuación de confianza. Eso suena a percepción. Todavía no lo es. En el fotograma 1, el detector ve la botella. En el frame 2, el brazo de la persona lo oculta parcialmente, la confianza baja y la caja desaparece. En el fotograma 3 la botella reaparece pero el detector mueve ligeramente la caja. Desde la perspectiva del planificador, la botella ha desaparecido y se ha teletransportado. En el desorden, también aparecen duplicados: el detector puede producir dos cajas "botella" plausibles para el mismo objeto. Si el robot reacciona directamente a las detecciones por fotograma, se observan comportamientos clásicos de fallo: ➤ duda porque el objetivo "falta" cada pocos fotogramas, ➤ se replanifica constantemente porque la posición objetivo titubea, ➤ se acerca al objeto equivocado cuando aparecen dos objetos similares, ➤ No puede hacer cumplir de forma fiable "no choques con la persona" porque la caja de la persona también parpadea. Por eso la percepción en robótica rara vez se detiene en la detección. Necesita permanencia objetiva: la capacidad de decir "esta sigue siendo la misma botella, aunque la pierda de vista brevemente." El seguimiento es lo que convierte las conjeturas fotograma a cuadro en un modelo de mundo estable. Un enfoque típico es el "seguimiento por detección": sigues ejecutando un detector en cada fotograma, pero asocias detecciones a pistas persistentes (IDs) a lo largo del tiempo usando predicción + asociación. Concretamente, el rastreador hace tres cosas: ➤ Predecir "¿dónde debería estar la botella ahora?" ➤ Asociar "¿a qué pista pertenece la detección de qué pista?" ➤ Mantener la identidad bajo cambios Volviendo a nuestra escena de mesa: una vez que lo sigues, 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 a que pase un breve cambio de entorno, comprometerse con un objetivo y planificar una trayectoria segura alrededor de una persona en movimiento. Incluso con rastreo, el robot sigue sin saber lo que hace en términos humanos. Tiene "Pista #7" con un recuadro delimitador y quizá una etiqueta de clase "botella". Eso no es suficiente para tareas reales porque las tareas reales tienen que ver con las relaciones y la intención: ➤ "Elige la botella azul (no la transparente)." ➤ "No estires la mano a través de la persona." ➤ "La botella está detrás de la taza." ➤ "Si la persona está intentando alcanzarlo, pausa." Aquí es donde los LLMs (a menudo emparejados con VLMs) 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 das detecciones por cuadro en bruto, obtendrás poca razón porque sus entradas parpadean. El seguimiento hace que la capa semántica sea coherente.