La corrispondenza verificabile ZK è un modo per gestire un libro ordini veloce e privato, garantendo comunque agli utenti una garanzia crittografica che il motore di corrispondenza ha seguito le regole. Il problema che risolve è semplice: un CLOB ha bisogno di un operatore (o di un piccolo gruppo di operatori) per abbinare rapidamente gli ordini, ma quell'operatore può anche imbrogliare (riordinare, saltare o riempire selettivamente). ZK cambia il modello di fiducia: l'operatore può rimanere veloce, ma non può finalizzare un aggiornamento a meno che non dimostri che è stato calcolato correttamente. 𝗛𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀 (𝗰𝗼𝗻𝗰𝗲𝗽𝘁𝘂𝗮𝗹𝗹𝘆) ➤ Gli ordini vengono raccolti e abbinati off-chain (quindi puoi ottenere un'esecuzione a bassa latenza). ➤ Invece di pubblicare il flusso completo degli ordini, il sistema pubblica: - 𝘢 𝘤𝘰𝘮𝘮𝘪𝘵𝘵𝘮𝘦𝘯𝘵 𝘵𝘰 𝘵𝘩𝘦 𝘣𝘢𝘵𝘤𝘩 / 𝘴𝘵𝘢𝘵𝘦 𝘵𝘳𝘢𝘯𝘴𝘪𝘵𝘪𝘰𝘯 (𝘰𝘧𝘵𝘦𝘯 𝘢 𝘴𝘵𝘢𝘵𝘦 𝘳𝘰𝘰𝘵) - 𝘢 𝘻𝘬-𝘱𝘳𝘰𝘰𝘧 𝘵𝘩𝘢𝘵 𝘵𝘩𝘦 𝘮𝘢𝘵𝘤𝘩𝘪𝘯𝘨 + 𝘳𝘪𝘴𝘬 𝘤𝘩𝘦𝘤𝘬𝘴 + 𝘣𝘢𝘭𝘢𝘯𝘤𝘦 𝘶𝘱𝘥𝘢𝘵𝘦𝘴 𝘸𝘦𝘳𝘦 𝘥𝘰𝘯𝘦 𝘢𝘤𝘤𝘰𝘳𝘥𝘪𝘯𝘨 𝘵𝘰 𝘵𝘩𝘦 𝘱𝘳𝘰𝘵𝘰𝘤𝘰𝘭 𝘳𝘶𝘭𝘦𝘴, - 𝘦𝘯𝘰𝘶𝘨𝘩 𝘥𝘢𝘵𝘢 𝘢𝘷𝘢𝘪𝘭𝘢𝘣𝘪𝘭𝘪𝘵𝘺 𝘴𝘰 𝘶𝘴𝘦𝘳𝘴 𝘤𝘢𝘯 𝘴𝘵𝘪𝘭𝘭 𝘦𝘹𝘪𝘵 𝘦𝘷𝘦𝘯 𝘪𝘧 𝘵𝘩𝘦 𝘰𝘱𝘦𝘳𝘢𝘵𝘰𝘳 𝘥𝘪𝘴𝘢𝘱𝘱𝘦𝘢𝘳𝘴. Quella "sufficiente disponibilità di dati" è dove la scelta di design di @hibachi_xyz è interessante: Hibachi sta gestendo un CLOB ad alte prestazioni e pubblicando dati di stato / commercio crittografati su @Celestia (quindi strategie e posizioni non sono pubbliche), mentre pubblica comunque prove affinché gli aggiornamenti rimangano verificabili, utilizzando SP1 (zkVM di Succinct) per dimostrare il CLOB. 𝗕𝘂𝘁 𝘄𝗵𝗮𝘁 “𝗺𝗮𝘁𝗰𝗵𝗶𝗻𝗴 𝘄𝗮𝘀 𝗰𝗼𝗿𝗿𝗲𝗰𝘁” 𝗺𝗲𝗮𝗻𝘀 𝗶𝗻 𝗽𝗿𝗼𝗼𝗳 𝘁𝗲𝗿𝗺𝘀? Una zk-proof può far rispettare le stesse invarianti su cui normalmente ci si aspetterebbe che un operatore di scambio segua, ad esempio: ➤ Gli ordini sono stati abbinati solo quando i prezzi si incrociano (nessun riempimento impossibile). ➤ La sequenza di riempimento ha rispettato la regola di priorità del luogo (ad es., priorità prezzo-tempo, o qualunque cosa specifichi il luogo). ➤ I saldi/margini sono stati aggiornati correttamente (nessuna modifica nascosta del saldo). ➤ La radice di stato risultante è esattamente ciò che ottieni applicando le regole alla radice di stato precedente + il batch. Puoi mantenere i contenuti privati (ordini, dimensioni, posizioni) crittografando ciò che viene pubblicato al livello DA, mentre la prova convince tutti che l'aggiornamento crittografato è comunque una transizione di stato valida.

𝗥𝗼𝗯𝗼𝘁𝗶𝗰𝘀 𝘀𝗮𝗳𝗲𝘁𝘆 𝗿𝗲𝗴𝘂𝗹𝗮𝘁𝗶𝗼𝗻 𝘂𝗽𝗱𝗮𝘁𝗲𝘀 (𝗨𝗦/𝗘𝗨) Entro la fine del 2025, la storia normativa per i "robot negli spazi pubblici" appare diversa nell'UE rispetto agli Stati Uniti. Nell'UE, la direzione è verso un unico stack di conformità stratificato: ➤ sicurezza del prodotto (per la macchina fisica) ➤ cybersecurity (perché i robot sono connessi) ➤ e governance dell'AI (perché autonomia e percezione sono guidate dall'AI) I team hanno bisogno di documentazione, controlli del ciclo di vita e (in alcuni casi) flussi di lavoro per la classificazione del rischio dell'AI che operano in parallelo (regolamentazione classica per l'UE, molte limitazioni e burocrazia). Negli Stati Uniti, il quadro è più settoriale: i "aggiornamenti" federali più chiari riguardano l'autonomia su strada (reporting degli incidenti NHTSA e percorsi di distribuzione/esenzione) e i droni (applicazione del Remote ID FAA). Per i robot a terra sui marciapiedi e nei luoghi pubblici al chiuso, le regole rimangono più frammentate e spesso locali.

𝗧𝗿𝗮𝗰𝗸𝗶𝗻𝗴 𝗲 𝗱𝗲𝘁𝗲𝗰𝘇𝗶𝗼𝗻𝗲 𝗱𝗲𝗹𝗹'𝗼𝗯𝗷𝗲𝘁𝘁𝗼 𝗽𝗲𝗿 𝗿𝗼𝗯𝗼𝘁𝗶𝗰𝗵𝗲 Nella robotica, la rilevazione degli oggetti è uno scatto: “c'è una bottiglia a (x, y) in questo fotogramma.” Il tracciamento degli oggetti è la cosa più difficile e operativa: “questa è la stessa bottiglia di prima, si è mossa in questo modo, ed è ancora lì anche se non la vedo per 200 ms.” Immagina un manipolatore mobile su un piano di lavoro in cucina. Il compito è semplice sulla carta: prendere la bottiglia blu da un tavolo disordinato mentre una persona si muove nelle vicinanze. Il robot ha una telecamera (forse anche di profondità). Esegue un rilevatore di oggetti e ottiene un riquadro di delimitazione etichettato “bottiglia” con un punteggio di confidenza. Sembra percezione. Non lo è ancora. Nel fotogramma 1 il rilevatore vede la bottiglia. Nel fotogramma 2 il braccio della persona la occlude parzialmente, la confidenza scende e il riquadro scompare. Nel fotogramma 3 la bottiglia riappare ma il rilevatore sposta leggermente il riquadro. Dalla prospettiva del pianificatore, la bottiglia è scomparsa e si è teletrasportata. Nel disordine, si ottengono anche duplicati: il rilevatore potrebbe produrre due riquadri plausibili “bottiglia” per lo stesso oggetto. Se il robot reagisce direttamente alle rilevazioni per fotogramma, si vedono i classici comportamenti di fallimento: ➤ esita perché il bersaglio è “mancante” ogni pochi fotogrammi, ➤ ripianifica costantemente perché la posizione del bersaglio oscilla, ➤ si allunga verso l'oggetto sbagliato quando appaiono due oggetti simili, ➤ non può far rispettare in modo affidabile “non collidere con la persona” perché anche il riquadro della persona lampeggia. Ecco perché la percezione robotica raramente si ferma alla rilevazione. Ha bisogno di permanenza dell'oggetto: la capacità di dire “questa è ancora la stessa bottiglia, anche se perdo brevemente di vista.” Il tracciamento è ciò che trasforma le ipotesi fotogramma per fotogramma in un modello di mondo stabile. Un approccio tipico è “tracciamento per rilevazione”: esegui ancora un rilevatore ad ogni fotogramma, ma colleghi le rilevazioni a tracce persistenti (ID) nel tempo utilizzando previsione + associazione. Concretamente, il tracciatore fa tre cose: ➤ Prevede “dove dovrebbe essere ora la bottiglia?” ➤ Associa “quale rilevazione appartiene a quale traccia?” ➤ Mantiene l'identità sotto i cambiamenti Tornando alla nostra scena del tavolo: una volta che tracci, la bottiglia smette di lampeggiare. Ha un ID stabile, una stima della posizione smussata e spesso una stima della velocità. Ora il pianificatore può comportarsi come un adulto: può aspettare un breve cambiamento dell'ambiente, impegnarsi in un bersaglio e pianificare una traiettoria sicura attorno a una persona in movimento. Anche con il tracciamento, il robot non sa ancora cosa sta facendo in termini umani. Ha “Traccia #7” con un riquadro di delimitazione e forse un'etichetta di classe “bottiglia.” Non è sufficiente per compiti reali perché i compiti reali riguardano relazioni e intenzioni: ➤ “Prendi la bottiglia blu (non quella trasparente).” ➤ “Non allungarti oltre la persona.” ➤ “La bottiglia è dietro la tazza.” ➤ “Se la persona la sta raggiungendo, fermati.” È qui che gli LLM (spesso abbinati a VLM) possono aiutare ragionando su una rappresentazione strutturata della scena costruita a partire dalle tracce. La chiave è che l'LLM deve operare in uno stato stabile. Se gli fornisci rilevazioni grezze per fotogramma, otterrai un ragionamento scarso perché i suoi input lampeggiano. Il tracciamento rende il livello semantico coerente.