{"id":245,"date":"2026-08-06T22:35:19","date_gmt":"2026-08-06T22:35:19","guid":{"rendered":"https:\/\/hoge.gg\/it\/ritual-chain-blockchain-ai-native-agenti-onchain\/"},"modified":"2026-08-06T22:35:19","modified_gmt":"2026-08-06T22:35:19","slug":"ritual-chain-blockchain-ai-native-agenti-onchain","status":"publish","type":"post","link":"https:\/\/hoge.gg\/it\/ritual-chain-blockchain-ai-native-agenti-onchain\/","title":{"rendered":"Ritual Chain: la blockchain AI-native per gli agenti on-chain"},"content":{"rendered":"

Per anni la promessa dell’intelligenza artificiale on-chain si \u00e8 scontrata con un limite tecnico tanto banale quanto insormontabile: una blockchain \u00e8 deterministica, un modello di machine learning quasi mai. Ogni validatore deve poter rieseguire la stessa transazione e ottenere, bit per bit, lo stesso risultato; l’inferenza di un large language model, invece, gira su GPU diverse, dipende dalle versioni delle librerie e a volte da un margine di casualit\u00e0. \u00c8 il motivo per cui, fino a poco tempo fa, \u00abAI e blockchain\u00bb ha significato quasi sempre un token con un chatbot attaccato sopra, non un modello che gira davvero dentro la logica di uno smart contract.<\/p>

Ritual nasce per sciogliere quel nodo, e a giugno 2026 ha portato la propria tesi al banco di prova pi\u00f9 concreto: un testnet pubblico in cui l’inferenza non \u00e8 un servizio esterno chiamato via API, ma una primitiva della catena, un opcode al pari di un’addizione o di un trasferimento. Il progetto \u00e8 passato in tre anni da semplice oracolo (Infernet) a Layer 1 sovrana, Ritual Chain, disegnata dalla base attorno a un’idea precisa: gli agenti AI devono poter vivere sulla catena, svegliarsi da soli, pagare il proprio calcolo e lasciare una prova verificabile di ci\u00f2 che hanno eseguito.<\/p>

Questa guida spiega come funziona quel disegno, cosa distingue Ritual da Bittensor, Gensyn e Akash, perch\u00e9 la questione del token \u00e8 pi\u00f9 delicata di quanto lascino intendere i canali Discord, e dove si colloca un’infrastruttura del genere per chi, in Italia, la guarda da sviluppatore o da investitore, tra AI Act europeo, MiCA e vigilanza Consob.<\/p>

Che cos’\u00e8 Ritual e quale problema prova a risolvere<\/h2>

Ritual \u00e8 un’infrastruttura crypto-AI che punta a rendere l’inferenza dei modelli verificabile e componibile dentro gli smart contract. Detta cos\u00ec suona astratta, ma il problema di partenza \u00e8 molto concreto e, secondo i fondatori, prima politico che tecnico: l’AI di frontiera \u00e8 concentrata in poche aziende che controllano contemporaneamente i modelli, i dati di addestramento e la capacit\u00e0 di calcolo.<\/p>

\u00abLa concentrazione dell’AI in un piccolo gruppo di aziende potenti rappresenta una minaccia significativa per il futuro della tecnologia\u00bb, ha dichiarato il co-fondatore Niraj Pant nel novembre 2023, spiegando di aver fondato Ritual \u00abper porre fine alla dipendenza dell’ecosistema da pochi\u00bb e per aprire l’accesso a un’infrastruttura critica, come riportato da CoinDesk<\/a>. La tesi, in sintesi: se i modelli restano scatole nere ospitate su server privati, non c’\u00e8 modo di verificare che l’output non sia stato manipolato, censurato o semplicemente sbagliato. La stessa idea, letta in chiave di potere industriale pi\u00f9 che di codice, era gi\u00e0 al centro del ritratto che Forbes<\/a> dedicava al progetto al momento del lancio.<\/p>

Sul piano ingegneristico, per\u00f2, il vero ostacolo \u00e8 il determinismo. Una rete come Ethereum funziona perch\u00e9 migliaia di nodi rieseguono ogni transazione e devono arrivare allo stesso identico stato finale; se anche un solo bit differisse, la rete non troverebbe consenso. L’inferenza di un modello moderno viola questa regola per costruzione: produce risultati che cambiano a seconda dell’hardware, della precisione numerica, dell’ordine delle operazioni. Mettere un LLM \u00abdentro\u00bb un blocco, in modo ingenuo, significherebbe rompere il consenso.<\/p>

La risposta di Ritual \u00e8 ribaltare il problema: invece di far rieseguire il modello a tutti, lo si esegue una volta sola e si ancora il risultato con una prova che chiunque pu\u00f2 controllare a basso costo. \u00c8 la stessa intuizione che rende oggi l’inferenza verificabile un tema centrale per gli agenti autonomi, i software che firmano transazioni per conto dell’utente e che quindi hanno bisogno di fidarsi dell’output di un modello prima di muovere fondi; un tema che abbiamo approfondito spiegando perch\u00e9 sono proprio gli agenti AI a comprare inferenza decentralizzata<\/a>.<\/p>

Dai fondi di Polychain al testnet pubblico: la parabola di Ritual<\/h2>

Dietro Ritual ci sono due nomi che arrivano dal cuore del venture crypto. Niraj Pant e Akilesh Potti hanno lavorato insieme per tre anni a Polychain Capital prima di fondare la societ\u00e0 a New York nel 2023. Pant con un passato da investitore in progetti come EigenLayer e Solana; Potti come ricercatore di machine learning ed ex quant di Palantir. Una combinazione, mercato dei capitali crypto pi\u00f9 competenze di ML, che spiega bene la traiettoria del progetto.<\/p>

Il debutto pubblico \u00e8 del novembre 2023: un round seed da 25 milioni di dollari (all’incirca 22 milioni di euro) guidato da Archetype<\/a>, con la partecipazione di Accomplice e Robot Ventures, come confermato all’epoca da Blockworks<\/a> e dalla stessa CoinDesk. Un anno dopo, al lancio del primo testnet, The Block<\/a> indicava un totale raccolto di oltre 30 milioni di dollari.<\/p>

Il vero salto concettuale arriva nel novembre 2024, quando Ritual annuncia il testnet della propria catena e istituisce la Ritual Foundation, l’ente indipendente incaricato di promuovere l’adozione attraverso grant, formazione e programmi per la community. \u00abIl testnet di Ritual Chain abilita comportamenti completamente nuovi, che oggi nessun altro sistema rende possibili nell’interazione con l’AI\u00bb, dichiarava allora Akilesh Potti. A febbraio 2025 la fondazione pubblica il documento Unveiling Ritual<\/a>, che per la prima volta mette nero su bianco l’architettura EVM++. La tappa pi\u00f9 recente \u00e8 l’apertura del testnet pubblico, nell’estate del 2026.<\/p>

Data<\/th>Tappa<\/th><\/tr><\/thead>
2023<\/td>Fondazione a New York (Niraj Pant e Akilesh Potti)<\/td><\/tr>
Novembre 2023<\/td>Round seed da 25 milioni di dollari guidato da Archetype<\/td><\/tr>
Novembre 2024<\/td>Testnet di Ritual Chain e nascita della Ritual Foundation<\/td><\/tr>
Febbraio 2025<\/td>Pubblicazione di Unveiling Ritual e dell’architettura EVM++<\/td><\/tr>
Estate 2026<\/td>Apertura del testnet pubblico, orientato agli agenti AI<\/td><\/tr><\/tbody><\/table><\/figure>

Infernet, l’oracolo che ha aperto la strada<\/h2>

Prima della catena c’\u00e8 Infernet, il primo prodotto di Ritual e ancora oggi la porta d’ingresso pi\u00f9 semplice. Infernet \u00e8 una rete di oracoli decentralizzata (in gergo, un decentralized oracle network) pensata per un compito specifico: permettere a uno smart contract, su qualunque blockchain compatibile con l’EVM, di ottenere l’output di un modello AI. Un contratto su Ethereum, Base o Arbitrum pu\u00f2 inviare una richiesta di inferenza alla rete Infernet, che la esegue su nodi di calcolo distribuiti e restituisce il risultato, on-chain oppure off-chain con verifica crittografica.<\/p>

Il valore, per uno sviluppatore, \u00e8 la sostituzione di un anello di fiducia. Senza una rete come questa, chi vuole usare l’output di un modello dentro un contratto deve appoggiarsi a un servizio centralizzato e fidarsi che non menta. Come nota l’analista Neeraja Tokekar in una ricognizione dei progetti AI-crypto pubblicata a maggio 2026, chi costruisce prodotti DeFi che devono prendere decisioni basate sull’AI dentro il contratto \u00abpu\u00f2 usare Ritual invece di fidarsi di un oracolo off-chain centralizzato\u00bb, e cita Ritual tra i pochi progetti che stanno facendo \u00abqualcosa di genuinamente nuovo\u00bb (fonte Ancilar<\/a>). Infernet mette a disposizione un SDK per integrare l’inferenza nelle dApp e, nel disegno complessivo, funziona da tessuto connettivo tra il resto del Web3 e la nuova Ritual Chain.<\/p>

La verifica \u00e8 il punto delicato. Un output AI vale poco se non si pu\u00f2 dimostrare che provenga davvero dal modello richiesto e non sia stato alterato lungo il tragitto. Qui Ritual adotta un approccio modulare, che va dalle prove a conoscenza zero agli ambienti di esecuzione fidati (TEE), lo stesso ventaglio di tecniche che rende possibile la fiducia tra agenti software e che sta dietro a standard emergenti come quelli descritti nel nostro articolo su verifiable compute ed ERC-8004<\/a>.<\/p>

Ritual Chain: una Layer 1 sovrana costruita attorno all’AI<\/h2>

Infernet risolve il \u00abcome chiamo un modello da un contratto\u00bb. Ritual Chain risponde a una domanda pi\u00f9 ambiziosa: e se l’intera catena fosse progettata perch\u00e9 l’AI sia un cittadino di prima classe, e non un ospite? Ritual Chain \u00e8 una Layer 1 sovrana, cio\u00e8 con un proprio meccanismo di consenso e una propria sicurezza, ma resta compatibile con l’ecosistema Ethereum grazie a un’estensione della macchina virtuale battezzata EVM++. Secondo la documentazione ufficiale, il testnet pubblico gira con chain ID 1979, tempi di blocco intorno ai 350 millisecondi e un token di gas denominato RITUAL, con il consueto set di strumenti per sviluppatori (Foundry, Hardhat, viem, wagmi) gi\u00e0 supportato (fonte documentazione Ritual<\/a>).<\/p>

La scelta di una catena sovrana, invece di restare un semplice oracolo sopra Ethereum, ha una logica precisa: solo controllando l’esecuzione a livello di protocollo si pu\u00f2 trasformare l’inferenza in una primitiva nativa, con costi prevedibili e garanzie integrate, invece di appenderla al di fuori come un servizio di terze parti. La retrocompatibilit\u00e0 con l’EVM serve ad abbassare la barriera: uno sviluppatore Solidity pu\u00f2 portare i propri contratti quasi senza riscritture e, solo dove serve, chiamare le nuove funzionalit\u00e0 AI.<\/p>

Perch\u00e9 non un semplice rollup o una appchain sopra Ethereum, allora? La risposta di Ritual \u00e8 che alcune primitive, in particolare l’inferenza come opcode e la programmazione nativa nel tempo, richiedono modifiche al livello di esecuzione e di consenso che un rollup, vincolato al modello di sicurezza della catena madre, non pu\u00f2 introdurre liberamente. Una L1 sovrana paga questa libert\u00e0 con l’onere di costruirsi da zero la propria sicurezza economica, il tallone d’Achille storico di ogni nuova catena; \u00e8 il classico compromesso tra controllo del design e costo del bootstrap, e sar\u00e0 uno dei nodi da sciogliere nel passaggio dal testnet alla produzione.<\/p>

EVM++: quando l’inferenza diventa un opcode<\/h2>

EVM++ \u00e8 il cuore tecnico del progetto: un’estensione retrocompatibile della macchina virtuale di Ethereum che aggiunge quattro famiglie di capacit\u00e0. La prima sono i compute precompile, funzioni a basso livello che espongono operazioni pesanti (a partire dall’inferenza) come se fossero istruzioni native. La seconda \u00e8 la native scheduling, cio\u00e8 la possibilit\u00e0 per un contratto di programmarsi da solo nel tempo. La terza sono gli enshrined oracle, oracoli integrati nel protocollo anzich\u00e9 aggiunti sopra. La quarta \u00e8 l’account abstraction nativa, che semplifica il modo in cui gli account firmano e pagano.<\/p>

I precompile sono la parte pi\u00f9 vistosa. La documentazione ne elenca sedici, raggruppati per funzione: l’inferenza di un LLM \u00e8 esposta a un indirizzo dedicato (0x0802), i modelli classici in formato ONNX a un altro (0x0800), e poi ancora inferenza in cifratura omomorfica (FHE), verifica di prove a conoscenza zero, generazione multimodale di immagini, audio e video. Accanto ci sono precompile per la connettivit\u00e0 con il mondo reale (chiamate HTTP, anche di lunga durata, e query sui dati in stile jq) e precompile pensati specificamente per gli agenti. In pratica, dal punto di vista di un contratto, chiedere a un modello di generare un testo diventa un’operazione elementare quanto sommare due numeri.<\/p>

Categoria<\/th>Cosa fa<\/th>Esempio d’uso<\/th><\/tr><\/thead>
Inferenza AI<\/td>LLM, modelli classici ONNX, generazione multimodale, inferenza in FHE<\/td>Un contratto che valuta il rischio di un prestito con un modello on-chain<\/td><\/tr>
Prove e crittografia<\/td>Verifica di prove a conoscenza zero, firme Ed25519, derivazione di chiavi<\/td>Ancorare un output off-chain con una prova verificabile<\/td><\/tr>
Connettivit\u00e0<\/td>Chiamate HTTP standard e di lunga durata, query sui dati in stile jq<\/td>Leggere un prezzo o un dato esterno senza oracolo di terze parti<\/td><\/tr>
Agenti<\/td>Agenti persistenti (con memoria e \u00abrisveglio\u00bb), agenti sovrani con esecuzione via CLI<\/td>Un agente che gira in autonomia e sopravvive nel tempo<\/td><\/tr><\/tbody><\/table><\/figure>

Esecuzione replicata contro esecuzione delegata<\/h2>

La soluzione al problema del determinismo sta in una scelta architetturale elegante: Ritual Chain fa girare due percorsi di esecuzione sullo stesso stato. Il primo \u00e8 l’esecuzione replicata, quella classica: operazioni deterministiche come i trasferimenti di token o le letture di memoria vengono rieseguite da ogni validatore, esattamente come su Ethereum. Il secondo \u00e8 l’esecuzione delegata, riservata a tutto ci\u00f2 che deterministico non \u00e8: l’inferenza di un LLM, una chiamata HTTP, un calcolo pesante.<\/p>

Quando un contratto invoca un precompile come quello dell’inferenza o dell’HTTP, il lavoro vero non avviene in modo replicato su ogni nodo, ma off-chain, all’interno di un ambiente di esecuzione fidato (TEE, Trusted Execution Environment). Il punto cruciale \u00e8 che ogni risposta viene legata crittograficamente alla richiesta esatta che l’ha generata: il validatore non deve rifare l’inferenza, gli basta verificare che quella risposta corrisponda a quella richiesta e provenga da un ambiente attestato. \u00c8 cos\u00ec che un’operazione non deterministica pu\u00f2 entrare in un blocco senza rompere il consenso.<\/p>

Un esempio rende l’idea. Immaginiamo un contratto che deve decidere se approvare un piccolo prestito leggendo un documento. Il contratto chiama il precompile dell’inferenza; il modello gira in un TEE fuori dalla catena e restituisce l’esito insieme a un’attestazione. I validatori non rileggono il documento n\u00e9 rieseguono il modello: verificano che l’attestazione corrisponda alla richiesta e registrano il risultato. Il costo on-chain resta quello di una verifica, non di un’inferenza, ed \u00e8 ci\u00f2 che rende l’operazione sostenibile.<\/p>

Questa separazione \u00e8 la ragione per cui Ritual pu\u00f2 promettere inferenza \u00abon-chain\u00bb senza chiedere a migliaia di nodi di possedere GPU identiche. Ha per\u00f2 un prezzo in termini di assunzioni di fiducia, su cui torneremo: affidarsi ai TEE significa fidarsi, in ultima istanza, anche del produttore del chip che li implementa.<\/p>

Lo scheduler e gli agenti che si \u00absvegliano\u00bb da soli<\/h2>

Se c’\u00e8 una funzione che spiega perch\u00e9 Ritual parla di catena \u00abper gli agenti AI\u00bb e non semplicemente \u00abcon l’AI\u00bb, \u00e8 lo scheduler. Su una blockchain tradizionale un contratto \u00e8 passivo: fa qualcosa solo quando qualcuno gli invia una transazione. Ritual Chain introduce le scheduled transaction, transazioni programmate che si eseguono in modo non interattivo al verificarsi di condizioni definite dall’utente. In pratica uno sviluppatore pu\u00f2 registrare una frequenza di callback e il proprio contratto verr\u00e0 \u00abrisvegliato\u00bb dalla catena stessa, senza bisogno di un bot esterno o di un servizio cron centralizzato.<\/p>

Su questa base poggiano i precompile per gli agenti. La documentazione descrive agenti persistenti, dotati di memoria e di un meccanismo di \u00abresurrezione\u00bb che li mantiene in vita, con tanto di heartbeat integrato, e agenti sovrani capaci di eseguire istruzioni via linea di comando. A completare il quadro ci sono un AsyncJobTracker che gestisce il ciclo di vita dei lavori asincroni e un RitualWallet che prepaga le commissioni per le operazioni asincrone. Messi insieme, questi pezzi descrivono qualcosa di inedito: un agente che vive interamente sulla catena, si sveglia da solo a intervalli regolari, chiama un modello per decidere cosa fare, paga di tasca propria l’inferenza e agisce, senza che nessun processo off-chain lo tenga in piedi.<\/p>

\u00c8 esattamente il tipo di autonomia che sta spingendo la domanda di inferenza decentralizzata e che rende gli agenti i clienti naturali di reti come questa. Il rovescio della medaglia, ovviamente, \u00e8 che un agente che muove fondi in autonomia \u00e8 tanto utile quanto pericoloso se l’output del modello che lo guida non \u00e8 verificabile: da qui, di nuovo, l’ossessione di Ritual per le prove.<\/p>

Resonance e Symphony: prezzare e verificare il calcolo eterogeneo<\/h2>

Una catena in cui alcuni nodi eseguono trasferimenti e altri fanno girare LLM su GPU costose ha due problemi che una blockchain normale non ha. Il primo \u00e8 il prezzo: come si stabilisce quanto costa un’operazione se l’hardware che la esegue \u00e8 profondamente diverso? La risposta di Ritual \u00e8 Resonance, un meccanismo di commissioni descritto come un mercato a due lati, che fa incontrare domanda e offerta di calcolo e prezza le transazioni in modo coerente su hardware eterogeneo, unificando tipi di computazione altrimenti incomparabili.<\/p>

Il secondo problema \u00e8 la verifica su scala. Rieseguire tutto ovunque, il modello classico delle blockchain, \u00e8 impensabile per l’inferenza. Qui entra Symphony, l’approccio al consenso che Ritual descrive come \u00abExecute-Once-Verify-Many-Times\u00bb: alcuni nodi selezionati eseguono il carico di lavoro e generano prove sintetiche, che tutti gli altri possono verificare senza replicare il calcolo. A monte c’\u00e8 la specializzazione dei nodi: ciascuno sceglie i carichi adatti alle proprie capacit\u00e0 (chi ha GPU potenti fa inferenza, chi no si concentra su compiti pi\u00f9 leggeri) e viene remunerato di conseguenza, cos\u00ec che anche partecipanti con risorse modeste abbiano un ruolo. La descrizione completa di questi meccanismi \u00e8 nel documento Unveiling Ritual<\/a>.<\/p>

Vale la pena notare quanto sia ambizioso, e non ancora provato su larga scala, l’insieme di questi meccanismi. Un mercato a due lati che prezza in modo equo hardware disomogeneo e uno schema che genera prove sintetiche affidabili per carichi pesanti sono problemi di ricerca aperti, non ingegneria di routine. \u00c8 qui che si gioca la differenza tra una demo suggestiva e una rete che regge traffico reale, ed \u00e8 per questo che i benchmark del testnet pubblico contano pi\u00f9 di qualunque presentazione.<\/p>

Come si verifica un’inferenza: zkML, TEE e opML a confronto<\/h2>

Il cuore filosofico di Ritual \u00e8 l’integrit\u00e0 computazionale modulare: non un’unica tecnica di verifica imposta a tutti, ma un ventaglio di opzioni tra cui scegliere in base al compromesso desiderato tra costo, velocit\u00e0 e garanzie. Le quattro grandi famiglie sono le prove a conoscenza zero applicate al machine learning (zkML), gli ambienti di esecuzione fidati (TEE), il machine learning ottimistico (opML) e gli approcci probabilistici. Nessuna \u00e8 perfetta, e la scelta dipende molto dal caso d’uso.<\/p>

Approccio<\/th>Come garantisce<\/th>Compromesso<\/th><\/tr><\/thead>
zkML<\/td>Una prova crittografica dimostra che l’inferenza \u00e8 corretta, senza rivelare il modello<\/td>Massime garanzie, ma costoso e lento da generare<\/td><\/tr>
TEE<\/td>L’inferenza gira in un enclave hardware attestato; si verifica l’attestazione, non il calcolo<\/td>Veloce ed economico, ma richiede fiducia nel produttore del chip<\/td><\/tr>
opML<\/td>Il risultato si assume corretto per default; una finestra di contestazione permette di sfidarlo<\/td>Poco oneroso, ma introduce un ritardo per la finalit\u00e0<\/td><\/tr>
Probabilistico<\/td>Controlli a campione rendono la frode statisticamente improbabile<\/td>Leggero, ma offre garanzie statistiche, non assolute<\/td><\/tr><\/tbody><\/table><\/figure>

Nella pratica, il testnet pubblico si appoggia soprattutto ai TEE per l’esecuzione delegata, la scelta pi\u00f9 pragmatica per far girare LLM di grandi dimensioni a costi ragionevoli. \u00c8 una decisione sensata dal punto di vista ingegneristico, ma sposta il baricentro della fiducia: un TEE \u00e8 sicuro quanto lo \u00e8 l’hardware che lo implementa, e la storia recente della sicurezza dei chip suggerisce di non considerarlo mai infallibile. Il valore dell’impostazione modulare \u00e8 che, man mano che lo zkML matura e diventa meno costoso, gli stessi contratti potranno alzare l’asticella delle garanzie senza cambiare catena.<\/p>

Casi d’uso: cosa si pu\u00f2 davvero costruire<\/h2>

Tutta questa infrastruttura ha senso solo se abilita applicazioni che prima erano impossibili o scomode. Gli esempi pi\u00f9 citati ruotano attorno a tre idee: portare il giudizio di un modello dentro la logica finanziaria, dare agli agenti una casa dove operare senza intermediari, e rendere verificabile la provenienza di ci\u00f2 che un modello produce.<\/p>