D1. Per i lettori che potrebbero conoscere TEN solo dai recenti titoli, come spiegheresti la missione centrale di TEN Protocol e il problema che è fondamentalmente progettato per risolvere all'interno del panorama di esecuzione di Ethereum?
Ethereum ha fatto qualcosa di radicale: ha reso il calcolo verificabile a livello globale rendendo tutto pubblico. Questo compromesso ha sbloccato la finanza trustless – ma ha anche, silenziosamente, compromesso una vasta classe di applicazioni reali.
Oggi, quando utilizzi la maggior parte degli L2 di Ethereum, non stai solo eseguendo una transazione. Stai trasmettendo la tua intenzione, la tua strategia, il tuo tempismo e spesso il tuo ragionamento economico a ogni bot, concorrente e avversario che osserva la chain. Questa visibilità permette la verifica – ma permette anche il front-running, l’estrazione di strategie, la sorveglianza comportamentale e interi mercati di attacco basati sul copiare intenzioni più velocemente di quanto un umano possa reagire.
TEN esiste per rompere questo falso binario.
La nostra missione è semplice da dichiarare ma difficile da realizzare: permettere alle persone di usare applicazioni Ethereum senza rivelare cosa stanno cercando di fare, pur preservando la verificabilità di livello Ethereum. Con la crittografia e il modello di esecuzione appropriati, puoi provare che il calcolo è stato corretto senza rivelare gli input, i passaggi intermedi o la logica privata sottostante.
In pratica, questo cambia tutto. Gli operatori dei nodi non possono fare front-running. Gli agenti AI possono mantenere segreti in sicurezza. I giochi possono esistere on-chain senza esporre lo stato nascosto. Le offerte non vengono copiate. Le applicazioni non devono perdere informazioni sensibili solo per essere dimostrabili.
TEN riguarda il ripristinare qualcosa che le blockchain hanno accidentalmente rimosso: la capacità di calcolare in sicurezza.
D2. TEN definisce "compute in confidence" come un elemento mancante nello stack blockchain odierno. Perché la riservatezza selettiva è sempre più necessaria per i casi d'uso reali in DeFi, AI, gaming ed enterprise?
Ogni sistema software di successo al mondo si basa sul controllo degli accessi. Su Facebook, non vedi ogni post – solo quello che ti è consentito vedere. In banca, il tuo saldo non è pubblico. Nei giochi, gli avversari non vedono la tua mano. Nelle aziende, la logica interna e i dati sono custoditi perché l’esposizione distrugge valore.
Le blockchain hanno invertito questo modello. Hanno reso la trasparenza totale il default – il che è ottimo per l’auditabilità, ma catastrofico per molte applicazioni reali.
In DeFi, gli utenti rivelano strategie e diventano prede prevedibili. Nel gaming, informazioni nascoste, casualità e fair play sono impossibili da implementare correttamente. In AI e enterprise, esporre dati, modelli o logiche decisionali interne viola la normativa o elimina completamente il vantaggio competitivo.
Ciò che manca non è la fiducia – è la riservatezza programmabile con garanzie crittografiche. Non privacy aggiunta tramite server centralizzati o promesse legali, ma controllo degli accessi imposto direttamente dal protocollo.
Questo è ciò che “compute in confidence” ripristina: la capacità di decidere chi può vedere cosa, mantenendo il sistema verificabile.
D3. La vostra architettura si basa su Trusted Execution Environments invece che su approcci ZK-only o MPC. Quali compromessi avete fatto scegliendo questo design e come mitigare le assunzioni di fiducia associate?
Fin dal primo giorno, il nostro vincolo era chiaro: i builder dovrebbero poter distribuire vere applicazioni EVM senza dover riscrivere tutto da capo.
Eseguire l’intera EVM all’interno di un Trusted Execution Environment permette agli sviluppatori di usare gli stessi linguaggi, strumenti e modelli mentali che già conoscono – ottenendo allo stesso tempo la riservatezza selettiva. Settlement, liquidità e composabilità rimangono ancorati a Ethereum.
Gli approcci ZK e MPC sono potenti e stanno migliorando rapidamente, ma oggi spesso impongono compromessi seri: complessità dei circuiti, colli di bottiglia nelle prestazioni, programmabilità limitata o overhead operativo che rende difficile costruire e scalare app generaliste.
L’uso dei TEE introduce una fiducia radicata nell’hardware – e lo dichiariamo esplicitamente. TEN la mitiga tramite un design a livelli: hosting solo su cloud per ridurre i vettori di attacco fisici, attestazione remota obbligatoria, ridondanza, vincoli di governance e ingegneria della sicurezza rigorosa.
Il risultato è un modello ibrido. Pubblico dove deve essere pubblico – settlement, auditabilità, risultati. Riservato dove deve esserlo – input, flusso degli ordini, stato sensibile. Non è purezza ideologica; è pragmatismo ingegneristico.
D4. Come fa TEN a preservare la verificabilità e la composabilità di livello Ethereum permettendo che parti dell’esecuzione, come input, flusso degli ordini o strategie, restino confidenziali?
TEN separa ciò che deve essere dimostrabile da ciò che deve essere visibile.
Le regole degli smart contract restano pubbliche. Chiunque può ispezionarle. L’esecuzione avviene in un TEE attestato, e la rete può verificare crittograficamente che il codice corretto sia stato eseguito su input validi – anche se questi input erano criptati.
Come Layer 2, TEN pubblica comunque rollup e transizioni di stato su Ethereum. Finalità, settlement e composabilità restano esattamente dove gli utenti se li aspettano.
Ciò che scompare è l’esposizione non necessaria. Strategie intermedie, soglie private e logiche sensibili non devono essere svelate solo per provare la correttezza.
La riservatezza diventa una capacità di prima classe, non un escamotage.
D5. Dal punto di vista dell’esperienza utente, come differisce l’interazione con un’applicazione alimentata da TEN rispetto a un tipico L2 di Ethereum oggi?
La differenza più grande è psicologica – ed è immediata.
Gli utenti non si sentono più osservati. Non c’è più ansia da mempool, né impostazioni di slippage difensive, né acrobazie RPC private solo per evitare di essere sfruttati. L’intenzione è privata di default.
Invii un’offerta, una strategia o una mossa assumendo che non verrà copiata in tempo reale – perché non lo sarà. Questo singolo cambiamento fa sentire il Web3 più vicino a come si comporta il software normale.
La privacy smette di essere una funzione avanzata per utenti esperti e diventa una proprietà invisibile dell’applicazione stessa.
D6. Una delle narrazioni di punta di TEN è la riduzione di MEV e dello sfruttamento di mercato. Come funzionano in pratica meccanismi come offerte sigillate, flusso degli ordini nascosto o routing privato, e quali miglioramenti misurabili abilitano?
TEN cambia ciò che è visibile durante l’esecuzione.
In un’asta a offerte sigillate, le offerte sono criptate ed elaborate all’interno di un TEE. Nessuno vede le offerte individuali in tempo reale. A seconda del design, le offerte potrebbero non essere mai rivelate – solo l’esito finale.
Il flusso degli ordini nascosto segue lo stesso principio. Le strategie non vengono trasmesse al mondo, quindi non c’è nulla da copiare, simulare o incastrare. Il MEV non deve essere “combattuto” – semplicemente non ha nulla da cui trarre nutrimento.
Fondamentalmente, questo non sacrifica la fiducia. Le regole sono pubbliche, l’esecuzione è attestata e i risultati sono verificabili. Puoi provare l’equità senza svelare l’intenzione.
D7. TEN ha evidenziato casi d’uso come agenti AI verificabili e iGaming provabilmente equo. Quali di questi vedi come primi driver di adozione reale e perché sono meglio adattati a TEN rispetto a chain trasparenti di default?
Il gaming con denaro reale è la corrispondenza più chiara a breve termine.
Il gaming richiede informazioni nascoste, casualità veloce e bassa latenza. Le chain trasparenti rompono queste assunzioni. Sulla testnet di TEN, abbiamo visto decine di migliaia di wallet unici e oltre un milione di scommesse – ordini di grandezza in più rispetto alle testnet tipiche.
House of TEN, una prima mondiale con poker onchain giocato da agenti AI, si è rivelata un enorme successo durante il periodo di rilascio beta.
Gli agenti AI verificabili sono altrettanto trasformativi ma con tempi leggermente più lunghi. Permettono gestione confidenziale del tesoro, decisioni private e sistemi AI che possono dimostrare il rispetto delle regole senza esporre modelli o dati proprietari.
Entrambe le categorie beneficiano direttamente della riservatezza selettiva – ed entrambe sono impossibili da realizzare correttamente su chain trasparenti di default.
D8. L’hardware trusted introduce una diversa classe di rischio operativo. Come è progettato TEN per garantire che i guasti siano rilevabili, contenuti e recuperabili invece che sistemici?
L’hardware trusted cambia la modalità di guasto – non la elimina.
TEN assume che le cose possano andare storte e progetta per la rilevazione e il contenimento. L’attestazione remota assicura che esecuzioni scorrette siano osservabili. Operator ridondanti impediscono che guasti di un singolo nodo diventino sistemici. I meccanismi di governance permettono di isolare o sostituire componenti compromessi.
L’obiettivo non è la fiducia cieca – è una fiducia delimitata con forti garanzie.
D9. Passando brevemente alle operazioni di rete: come appare l’attuale modello di operator e come la roadmap si muove da una fase di bootstrap verso maggiore decentralizzazione e resilienza?
TEN inizia con un insieme di operator limitato per garantire sicurezza e prestazioni, poi espande progressivamente la partecipazione man mano che strumenti, monitoraggio e governance maturano.
La decentralizzazione non è una casella da spuntare – è una sequenza. Ogni fase aumenta la resilienza senza compromettere le garanzie di riservatezza.
D10. I lanci di token sono spesso confusi con la prontezza del prodotto. Come separate internamente gli eventi di mercato dallo sviluppo del protocollo e quali milestone contano di più per valutare i progressi tecnici di TEN nei prossimi 6-12 mesi?
In modo molto deliberato.
Gli eventi token non definiscono la prontezza. La delivery sì.
Internamente, il progresso si misura con release sottoposte ad audit, applicazioni live, espansione degli operator, attività degli sviluppatori e casi d’uso reali che richiedono riservatezza.
Nei prossimi 6-12 mesi, il successo riguarda le capacità consegnate – non le narrazioni mantenute.
D11. Guardando indietro, quali lezioni operative il team ha tratto dal lancio di un protocollo infrastrutturale complesso in un mercato altamente riflessivo?
Che la tecnologia da sola non basta.
Esecuzione, comunicazione e tempismo si rafforzano a vicenda – soprattutto nei mercati in cui la percezione si riflette direttamente nella realtà. Anche i sistemi forti soffrono se le aspettative non sono allineate.
La lezione è semplice ma implacabile: la fiducia si ricostruisce con la delivery, non con le spiegazioni. L’infrastruttura funzionante batte sempre la messaggistica perfetta.
D12. Guardando avanti, come sarebbe il successo per TEN tra un anno in termini di capacità rilasciate, adozione degli sviluppatori e applicazioni reali in produzione?
Il successo significa applicazioni in produzione che semplicemente non potrebbero esistere su chain trasparenti.
iGaming live. Workflow DeFi protetti. Agenti AI verificabili che gestiscono valore reale. Sviluppatori che usano la riservatezza come primitivo di design, non come ripensamento.
A quel punto, TEN non sarà “un progetto sulla privacy”. Sarà infrastruttura fondamentale – lo strato mancante che permette a Ethereum di supportare finalmente l’intero spettro di applicazioni reali.
