Cosa sta succedendo con il restaking?

Analisi approfondita del percorso di restaking di EigenLayer: le difficoltà incontrate, i successi di EigenDA, tutto a preparare la strada per la nuova direzione di EigenCloud.

Autore: Kydo, Responsabile della narrazione di EigenCloud

Traduzione: Saoirse, Foresight News

Di tanto in tanto, gli amici mi inviano alcuni tweet ironici sul restaking, ma queste prese in giro non colgono mai il punto. Così ho deciso di scrivere io stesso un articolo di riflessione, in tono un po’ critico.

Forse penserai che sono troppo coinvolto per essere obiettivo; o che sono troppo orgoglioso per ammettere che “abbiamo sbagliato i calcoli”. Potresti pensare che, anche se tutti ormai danno per scontato che “il restaking sia fallito”, io scriverei comunque un lungo articolo per difenderlo, senza mai pronunciare la parola “fallimento”.

Queste opinioni sono tutte ragionevoli, e molte hanno un certo fondamento.

Ma questo articolo vuole solo presentare i fatti in modo oggettivo: cosa è successo, cosa è stato realizzato, cosa non è andato a buon fine e quali lezioni abbiamo imparato.

Spero che le esperienze raccontate possano essere di utilità generale e offrire spunti ad altri sviluppatori dell’ecosistema.

Dopo oltre due anni di integrazione di tutti i principali AVS (Autonomous Validation Services) su EigenLayer e di progettazione di EigenCloud, voglio fare un’analisi onesta: dove abbiamo sbagliato, dove abbiamo fatto bene e quale sarà la nostra prossima direzione.

Che cos’è davvero il restaking?

Se ancora oggi devo spiegare “cos’è il restaking”, ciò di per sé dimostra che, quando il restaking era al centro dell’attenzione del settore, non siamo riusciti a comunicarlo chiaramente. Questa è la “lezione zero”: concentrarsi su una narrazione centrale e ripeterla più volte.

L’obiettivo del team Eigen è sempre stato “facile a dirsi, difficile a farsi”: aumentare la verificabilità del calcolo off-chain, permettendo alle persone di costruire applicazioni on-chain in modo più sicuro.

Gli AVS sono stati il nostro primo tentativo concreto e deciso in questa direzione.

Gli AVS (Autonomous Validation Services) sono una rete proof-of-stake (PoS), in cui un gruppo di operatori decentralizzati esegue compiti off-chain. Il comportamento di questi operatori è monitorato e, in caso di violazione, il capitale messo in staking viene penalizzato. Per implementare un “meccanismo di penalizzazione”, è necessario avere un “capitale in staking” a supporto.

Ed è qui che risiede il valore del restaking: invece di costruire da zero un sistema di sicurezza per ogni AVS, il restaking consente di riutilizzare ETH già in staking per garantire la sicurezza di più AVS. Questo non solo riduce il costo del capitale, ma accelera anche l’avvio dell’ecosistema.

Quindi, il quadro concettuale del restaking può essere riassunto così:

• AVS: ovvero il “livello di servizio”, che ospita i nuovi sistemi di sicurezza cripto-economica PoS;
• Restaking: ovvero il “livello di capitale”, che fornisce sicurezza a questi sistemi riutilizzando asset già in staking.

Ritengo ancora che questa idea sia molto elegante, ma la realtà non è stata così ideale come nei diagrammi — molti risultati non hanno soddisfatto le aspettative.

Cose che non sono andate come previsto

1. Abbiamo scelto il mercato sbagliato: troppo di nicchia

Non volevamo “qualsiasi tipo di calcolo verificabile”, ma eravamo ossessionati da sistemi che fossero “decentralizzati, basati su meccanismi di penalizzazione e completamente sicuri dal punto di vista cripto-economico fin dal primo giorno”.

Volevamo che gli AVS diventassero “servizi infrastrutturali” — proprio come gli sviluppatori possono costruire SaaS (Software as a Service), chiunque potesse costruire AVS.

Questa posizione, apparentemente di principio, ha però drasticamente ridotto il bacino potenziale di sviluppatori.

Il risultato finale è stato che ci siamo trovati di fronte a un mercato “piccolo, lento, con barriere elevate”: pochi utenti potenziali, costi di implementazione alti, cicli di sviluppo lunghi sia per il team che per gli sviluppatori. Sia l’infrastruttura di EigenLayer, sia gli strumenti di sviluppo, sia ogni singolo AVS richiedevano mesi o addirittura anni per essere costruiti.

Facendo un salto avanti di quasi tre anni: oggi abbiamo solo due AVS principali in produzione — DIN (Decentralized Infrastructure Network) di Infura e EigenZero di LayerZero. Un “tasso di adozione” che non può certo definirsi “ampio”.

Ad essere onesti, lo scenario che avevamo progettato era “team che vogliono sicurezza cripto-economica e operatori decentralizzati fin dal primo giorno”, ma la domanda reale del mercato era per soluzioni “più graduali e più orientate alle applicazioni”.

2. Limitati dall’ambiente normativo, siamo stati costretti al “silenzio”

Quando abbiamo lanciato il progetto, eravamo nel pieno dell’“era Gary Gensler” (nota: Gary Gensler è il presidente della SEC statunitense, noto per il suo approccio rigoroso alla regolamentazione del settore crypto). All’epoca, molte società di staking erano sotto indagine e coinvolte in cause legali.

Come “progetto di restaking”, quasi ogni nostra dichiarazione pubblica poteva essere interpretata come una “promessa di investimento” o “pubblicità di rendimenti”, e poteva persino attirare un mandato di comparizione.

Questa incertezza normativa ha determinato il nostro modo di comunicare: non potevamo esprimerci liberamente, e anche di fronte a una valanga di notizie negative, a partner che ci scaricavano o ad attacchi mediatici, non potevamo chiarire i malintesi in tempo reale.

Non potevamo nemmeno dire liberamente “le cose non stanno così” — perché dovevamo prima valutare i rischi legali.

Il risultato è stato che, in assenza di una comunicazione adeguata, abbiamo lanciato token con lock-up. Ripensandoci ora, è stata una mossa piuttosto rischiosa.

Se hai mai pensato che “il team Eigen sia evasivo o insolitamente silenzioso su certe questioni”, probabilmente è stato proprio a causa di questo ambiente normativo — anche un singolo tweet sbagliato poteva comportare rischi non trascurabili.

3. Gli AVS iniziali hanno diluito il valore del brand

L’influenza iniziale del brand Eigen derivava in gran parte da Sreeram (membro chiave del team): la sua energia, il suo ottimismo e la convinzione che “sia i sistemi che le persone possano migliorare” hanno generato molta simpatia attorno al team.

Decine di miliardi di capitale in staking hanno ulteriormente rafforzato questa fiducia.

Tuttavia, la promozione congiunta dei primi AVS non è stata all’altezza di questo “livello di brand”. Molti AVS iniziali facevano molto rumore, ma inseguivano solo le mode del settore, senza essere esempi di AVS “tecnologicamente più forti” o “più affidabili”.

Col tempo, la gente ha iniziato ad associare “EigenLayer” a “nuovo yield farming, airdrop”. I dubbi, la stanchezza e persino l’avversione che affrontiamo oggi derivano in gran parte da questa fase.

Se potessi tornare indietro, vorrei partire da “meno AVS, ma di qualità superiore”, essere più selettivo sui partner che possono ricevere il nostro endorsement e accettare una promozione “più lenta e meno rumorosa”.

4. Un eccesso di ricerca della “minimizzazione della fiducia” ha portato a una progettazione ridondante

Abbiamo cercato di costruire un “sistema di penalizzazione universale perfetto”: doveva essere generico, flessibile e coprire tutti gli scenari di penalizzazione, per raggiungere la “minimizzazione della fiducia”.

Ma nella pratica, ciò ha rallentato l’iterazione del prodotto e ci ha costretto a spendere molto tempo a spiegare un meccanismo che “la maggior parte delle persone non era ancora pronta a comprendere”. Ancora oggi, dobbiamo continuare a fare divulgazione sul sistema di penalizzazione lanciato quasi un anno fa.

Col senno di poi, un percorso più ragionevole sarebbe stato: lanciare prima una soluzione di penalizzazione semplice, lasciare che i diversi AVS sperimentassero modelli più mirati e poi aumentare gradualmente la complessità del sistema. Invece, abbiamo messo la “progettazione complessa” davanti, pagando il prezzo in termini di “velocità” e “chiarezza”.

Cose che abbiamo davvero realizzato

La gente tende a etichettare subito le cose come “fallimento”, ma questo approccio è troppo superficiale.

Nella storia del “restaking” ci sono molte cose che sono state fatte molto bene, e questi risultati sono fondamentali per la nostra direzione futura.

1. Abbiamo dimostrato di poter vincere in mercati altamente competitivi

Preferiamo le situazioni “win-win”, ma non temiamo la concorrenza — se decidiamo di entrare in un mercato, vogliamo essere leader.

Nell’ambito del restaking, Paradigm e Lido hanno sostenuto insieme un nostro diretto concorrente. All’epoca, il TVL (valore totale bloccato) di EigenLayer era inferiore a 1.1 billions.

I concorrenti avevano vantaggi narrativi, risorse di canale, supporto di capitale e una “fiducia predefinita”. Molti mi dicevano: “La loro combinazione sarà più efficiente di voi e vi schiaccerà”. Ma la realtà è stata diversa — oggi deteniamo il 95% della quota di mercato del capitale di restaking e abbiamo attratto il 100% degli sviluppatori di primo livello.

Nell’ambito della “data availability (DA)”, siamo partiti più tardi, con un team più piccolo e meno fondi, mentre i pionieri del settore avevano già un vantaggio e un forte sistema di marketing. Ma oggi, secondo qualsiasi indicatore chiave, EigenDA (la soluzione di data availability di Eigen) detiene una grande quota del mercato DA; con il lancio completo dei principali partner, questa quota crescerà esponenzialmente.

Entrambi questi mercati sono estremamente competitivi, ma alla fine ci siamo distinti.

2. EigenDA è diventato un prodotto maturo che “cambia l’ecosistema”

Lanciare EigenDA sopra l’infrastruttura EigenLayer è stata una grande sorpresa.

È diventato la pietra angolare di EigenCloud e ha portato a Ethereum qualcosa di molto necessario — un canale DA su larga scala. Grazie a questo, i Rollup possono mantenere alte prestazioni senza dover abbandonare l’ecosistema Ethereum per “velocità”, scegliendo altre nuove chain.

MegaETH è stato lanciato proprio perché il team credeva che Sreeram potesse aiutarli a superare il collo di bottiglia della DA; anche Mantle, quando propose a BitDAO di costruire una L2, lo fece per la stessa fiducia.

EigenDA è diventato anche lo “scudo difensivo” di Ethereum: quando l’ecosistema Ethereum dispone di una soluzione DA nativa ad alta capacità, le chain esterne avranno più difficoltà a “catturare l’attenzione sfruttando la narrazione Ethereum e a drenare valore dall’ecosistema”.

3. Promozione dello sviluppo del mercato delle pre-conferme

Uno dei temi centrali di EigenLayer nelle fasi iniziali era come sbloccare la funzione di pre-conferma di Ethereum tramite EigenLayer.

Da allora, le pre-conferme hanno ricevuto molta attenzione grazie alla rete Base, ma la loro implementazione pratica resta una sfida.

Per promuovere lo sviluppo dell’ecosistema, abbiamo anche lanciato il programma Commit-Boost — volto a risolvere l’“effetto lock-in” dei client di pre-conferma, costruendo una piattaforma neutrale che consenta a chiunque di innovare tramite l’impegno dei validatori.

Oggi, decine di miliardi di dollari sono stati movimentati tramite Commit-Boost, e oltre il 35% dei validatori ha aderito al programma. Con il lancio dei principali servizi di pre-conferma nei prossimi mesi, questa percentuale crescerà ulteriormente.

Ciò è fondamentale per la “antifragilità” dell’ecosistema Ethereum e pone le basi per l’innovazione continua nel mercato delle pre-conferme.

4. Abbiamo sempre garantito la sicurezza degli asset

Negli anni, abbiamo garantito la sicurezza di decine di miliardi di dollari di asset.

Questa frase può sembrare banale, persino “noiosa” — ma basta pensare a quante infrastrutture crypto sono “crollate” in vari modi per capire quanto sia preziosa questa “normalità”. Per evitare rischi, abbiamo costruito un solido sistema di sicurezza operativa, reclutato e formato un team di sicurezza di livello mondiale e integrato una “mentalità avversariale” nella cultura del team.

Questa cultura è fondamentale per qualsiasi attività che coinvolga fondi degli utenti, AI o sistemi reali, e “non può essere aggiunta in seguito” — bisogna costruirla fin dall’inizio.

5. Abbiamo impedito a Lido di mantenere a lungo una quota di staking superiore al 33%

L’era del restaking ha avuto un impatto sottovalutato: una grande quantità di ETH è confluita nei fornitori di LRT, evitando che la quota di staking di Lido rimanesse stabilmente ben oltre il 33%.

Questo è di grande importanza per “l’equilibrio sociale” di Ethereum. Se Lido avesse mantenuto a lungo una quota di staking superiore al 33% senza alternative affidabili, si sarebbero inevitabilmente scatenate enormi controversie di governance e conflitti interni.

Il restaking e le LRT non hanno “miracolosamente raggiunto la completa decentralizzazione”, ma hanno effettivamente cambiato la tendenza alla concentrazione dello staking — un risultato tutt’altro che trascurabile.

6. Abbiamo chiarito dove si trova la “vera frontiera”

Il più grande “guadagno” è stato in termini di visione: abbiamo confermato il punto centrale che “il mondo ha bisogno di più sistemi verificabili”, ma abbiamo anche capito che la “strada per realizzarli” era sbagliata.

La strada giusta non è “partire dalla sicurezza cripto-economica generica, insistere nel costruire un sistema di operatori completamente decentralizzato fin dal primo giorno e poi aspettare che tutte le attività si colleghino a questo livello”.

Il modo davvero efficace per accelerare la “frontiera” è: fornire strumenti diretti agli sviluppatori, permettendo loro di implementare la verificabilità per le proprie applicazioni specifiche e abbinare a questi strumenti primitive di verifica adeguate. Dobbiamo “avvicinarci attivamente alle esigenze degli sviluppatori”, invece di chiedere loro di diventare “progettisti di protocolli” fin dal primo giorno.

Per questo, abbiamo già iniziato a costruire servizi modulari interni — EigenCompute (servizio di calcolo verificabile) ed EigenAI (servizio AI verificabile). Alcune funzionalità che altri team realizzerebbero solo dopo aver raccolto centinaia di milioni di dollari e anni di lavoro, noi possiamo lanciarle in pochi mesi.

La direzione futura

Di fronte a queste esperienze — tempismo, successi, lezioni apprese, “cicatrici” del brand — come dobbiamo reagire?

Ecco una breve panoramica dei nostri prossimi passi e della logica che li guida:

1. Rendere il token EIGEN il cuore del sistema

In futuro, l’intero EigenCloud e tutti i prodotti che costruiremo attorno ad esso ruoteranno attorno al token EIGEN.

Il ruolo del token EIGEN sarà:

• Motore centrale della sicurezza economica di EigenCloud;
• Asset che garantisce i vari rischi assunti dalla piattaforma;
• Strumento centrale per la cattura del valore di tutti i flussi di commissioni e attività economiche della piattaforma.

In passato, molti avevano aspettative su “quale valore potesse catturare il token EIGEN” che non coincidevano con il “meccanismo reale” — il che ha generato confusione. Nella prossima fase, colmeremo questo divario con design concreti e sistemi implementati. Maggiori dettagli saranno annunciati in seguito.

2. Consentire agli sviluppatori di costruire “applicazioni verificabili”, non solo AVS

Il nostro punto centrale resta invariato: aumentare la verificabilità del calcolo off-chain per consentire la costruzione sicura di applicazioni on-chain. Ma gli strumenti per realizzare la “verificabilità” non saranno più limitati a uno solo.

A volte sarà la sicurezza cripto-economica; altre volte, le ZK proof, i TEE (Trusted Execution Environment) o soluzioni ibride. La chiave non è “promuovere una tecnologia specifica”, ma rendere la “verificabilità” una primitiva standard direttamente accessibile nello stack tecnologico degli sviluppatori.

Il nostro obiettivo è ridurre la distanza tra “ho un’applicazione” e “ho un’applicazione che utenti, partner o enti regolatori possono verificare”.

Considerando lo stato attuale del settore, “cripto-economia + TEE” è senza dubbio la scelta migliore — offre il miglior equilibrio tra “programmabilità per gli sviluppatori” (cosa possono costruire) e “sicurezza” (non solo teorica, ma realmente implementabile).

In futuro, quando le ZK proof e altri meccanismi di verifica saranno abbastanza maturi da soddisfare le esigenze degli sviluppatori, li integreremo anche in EigenCloud.

3. Approfondire la presenza nel settore AI

La più grande rivoluzione attuale nel campo del calcolo globale è l’AI — in particolare gli AI Agents. Anche il settore crypto non può restarne fuori.

Gli AI Agents sono essenzialmente “modelli linguistici avvolti da strumenti che eseguono operazioni in ambienti specifici”.

Oggi, non solo i modelli linguistici sono “black box”, ma anche la logica operativa degli AI Agents non è trasparente — proprio per questo si sono già verificati attacchi hacker dovuti alla “necessità di fidarsi degli sviluppatori”.

Ma se gli AI Agents fossero “verificabili”, non sarebbe più necessario affidarsi alla fiducia negli sviluppatori.

Per rendere verificabili gli AI Agents, servono tre condizioni: la verificabilità del processo di inferenza del LLM (Large Language Model), la verificabilità dell’ambiente di calcolo in cui vengono eseguite le operazioni e la verificabilità del livello dati che consente di archiviare, recuperare e comprendere il contesto.

EigenCloud è stato progettato proprio per questi scenari:

• EigenAI: fornisce servizi di inferenza LLM deterministici e verificabili;
• EigenCompute: offre ambienti di esecuzione operativa verificabili;
• EigenDA: fornisce servizi di archiviazione e recupero dati verificabili.

Siamo convinti che “AI Agents verificabili” siano uno degli scenari applicativi più competitivi dei nostri “servizi cloud verificabili” — per questo abbiamo già formato un team dedicato a questo settore.

4. Ridefinire la narrazione di “staking e rendimento”

Per ottenere rendimenti reali, bisogna assumersi rischi reali.

Stiamo esplorando scenari di “staking” più ampi, affinché il capitale in staking possa coprire i seguenti rischi:

• Rischio degli smart contract;
• Rischi di diversi tipi di calcolo;
• Rischi chiaramente descrivibili e quantificabili in termini di prezzo.

I rendimenti futuri rifletteranno realmente “i rischi trasparenti e comprensibili assunti”, invece di inseguire semplicemente “le attuali mode del liquidity mining”.

Questa logica sarà naturalmente integrata negli scenari d’uso del token EIGEN, nell’ambito delle sue garanzie e nei meccanismi di trasferimento del valore.

Considerazioni finali

Il restaking non è diventato il “livello universale” che io (e altri) ci aspettavamo, ma non è nemmeno scomparso. Nel lungo percorso di sviluppo, è diventato ciò che sono la maggior parte dei “prodotti di prima generazione”:

Un capitolo importante, una serie di lezioni difficili da imparare e un’infrastruttura che ora sostiene attività più ampie.

Continuiamo a mantenere le attività legate al restaking e le consideriamo ancora importanti — semplicemente non vogliamo più essere limitati dalla narrazione iniziale.

Se sei un membro della community, uno sviluppatore AVS o un investitore che ancora associa Eigen a “quel progetto di restaking”, spero che questo articolo ti aiuti a capire meglio “cosa è successo in passato” e “dove stiamo andando ora”.

Oggi stiamo entrando in un’area con un “Total Addressable Market (TAM)” molto più ampio: da un lato i servizi cloud, dall’altro le esigenze applicative rivolte direttamente agli sviluppatori. Stiamo anche esplorando la “corsa all’AI ancora poco sviluppata”, e continueremo a perseguire queste direzioni con la nostra consueta forza esecutiva.

Il team è ancora pieno di energia, e non vedo l’ora di dimostrare a tutti gli scettici che — ce la possiamo fare.

Non ho mai creduto tanto in Eigen come ora, continuo ad accumulare token EIGEN e continuerò a farlo anche in futuro.

Siamo ancora solo all’inizio.