Restaking in EigenLayer: AVS, operatori e secondo livello di slashing
Il restaking è un’estensione volontaria delle regole di staking: ETH già in staking, o LST, viene delegato ulteriormente a EigenLayer, così che la stessa garanzia protegga la sicurezza di più servizi.
L’errore principale è ridurre il restaking a “più rendimento”. Nel modello EigenLayer si aggiunge non solo una fonte di pagamenti, ma anche un livello separato di penalità: le condizioni di slashing non sono definite solo da Ethereum, ma anche da servizi esterni.
EigenLayer collega lo stake di Ethereum ai servizi esterni tramite gli AVS: il servizio paga gli operatori per l’esecuzione delle regole e ottiene un meccanismo di penalità, lo slashing, come garanzia criptoeconomica.
In una frase: il restaking in EigenLayer consiste nel collegare ETH già in staking, o LST, a servizi esterni (AVS) tramite operatori, così che la garanzia diventi slashable secondo le loro regole.
Mini-meccanica: il restaker delega la garanzia a un operatore → l’operatore serve l’AVS scelto → l’AVS paga una ricompensa → in caso di violazione delle regole l’AVS avvia lo slashing secondo una policy definita in anticipo.
Di seguito vengono spiegati i ruoli di restaker, operator e AVS, l’architettura di collegamento della garanzia (native ETH e LST), le fonti dei pagamenti (compensi degli AVS) e le fonti di rischio (policy di slashing degli AVS, scelta dell’operatore, guasti correlati).
Restaking: rende ETH una garanzia “riutilizzabile”: un solo stake protegge la sicurezza di Ethereum e degli AVS scelti, mentre il prezzo dei pagamenti è dato dalle regole di slashing degli AVS e dalla dipendenza dagli operatori.
Materiale aggiornato → focus rafforzato sull’architettura di EigenLayer (AVS/operatori) e sul secondo livello di slashing.
- Intersezioni separate → “che cos’è il restaking” è stato spostato nell’angolo “mercato della responsabilità / price of error”.
- Scenari RSFi chiariti → lo sconto dell’LRT è collegato al rischio AVS e agli eventi correlati.
Come funziona il protocollo EigenLayer nell’ecosistema Ethereum
EigenLayer è un protocollo di smart contract su Ethereum che permette di rendere slashable ETH già in staking, o LST, secondo le regole di servizi esterni (AVS) tramite delega agli operatori.
Flusso di base: la garanzia viene collegata a EigenLayer → viene delegata a un operatore → l’operatore serve gli AVS scelti → gli AVS pagano per il lavoro corretto → in caso di violazione delle regole dell’AVS viene applicata una penalità, slashing, alla garanzia allocata.
Ruoli in EigenLayer: restaker / operator / AVS
| Ruolo | Cosa fornisce | Cosa esegue | Dove nasce il rischio |
|---|---|---|---|
| Restaker | Garanzia (ETH/LST), delegata a un operatore | Scelta dell’operatore e dell’insieme di AVS da supportare | Slashing secondo le regole AVS + dipendenza dal comportamento dell’operatore |
| Operator | Infrastruttura e avvio dello stack AVS | Firme, prove, disponibilità secondo i requisiti dell’AVS | Penalità per violazione delle regole AVS; errore operativo |
| AVS | Regole di validazione e policy di slashing/ricompense | Verifica della correttezza delle azioni degli operatori, secondo la propria logica | Errori di design delle regole, bug nei contratti o nella verifica |
Collegamento della garanzia: native ETH e LST
- Native ETH: il validatore collega il withdrawal address all’indirizzo di EigenPod, così che lo stake venga considerato da EigenLayer e possa rientrare nelle regole AVS.
- LST: gli LST vengono depositati nelle strategie di EigenLayer e poi delegati a un operatore senza avviare un nodo proprio.
Slashing nel restaking: regole AVS e garanzia allocata
- Le condizioni sono definite dall’AVS: le violazioni vengono formulate a livello di servizio, per esempio firme errate, mancata esecuzione dei task o violazione dei requisiti di disponibilità.
- La penalità è collegata alla garanzia allocata: la sanzione viene applicata alla parte di stake delegato che partecipa al servizio di quello specifico AVS secondo le sue regole.
Filtro pratico del rischio: il profilo di rischio è determinato dall’insieme di AVS presso l’operatore, dalla loro policy di slashing e dalla capacità dell’operatore di gestire quell’insieme senza perdita di uptime e qualità di esecuzione.
EigenLayer collega lo stake delegato e i servizi esterni tramite gli operatori: l’AVS paga per l’esecuzione delle regole, e la violazione delle regole può portare allo slashing della garanzia allocata.
Esempi pratici di utilizzo di EigenLayer e del restaking
Gli AVS (Actively Validated Services) usano il restaking come meccanismo di responsabilità: l’operatore riceve un pagamento per eseguire le regole del servizio, e la violazione delle regole può portare allo slashing della garanzia allocata su Ethereum.
Schema AVS: il servizio definisce un obbligo → definisce una verifica, cioè come viene registrata la violazione → definisce una penalità, volume e condizioni → l’operatore risponde con la garanzia delegata.
Data Availability (EigenDA e analoghi)
I servizi DA rispondono alla domanda dell’ecosistema rollup: i dati necessari per verificare lo stato e ricostruire la cronologia sono disponibili?
- Cosa si impegna a fare l’operatore: conservare frammenti di dati (chunks — parti del set di dati) e fornirli secondo le regole del protocollo entro finestre temporali definite.
- Cosa viene considerato una violazione: indisponibilità dei dati, rifiuto di fornirli, conferma della disponibilità senza rilascio effettivo.
- Perché qui serve il restaking: la disponibilità dei dati diventa un obbligo penalizzabile, non una promessa del provider.
- Cosa ottiene il mercato: il layer DA viene scalato separatamente da L1, riducendo il carico su Ethereum senza affidarsi a una conservazione “trusted”.
Il restaking trasforma il DA in una
Oracoli e servizi di dati
Negli oracoli il valore del restaking sta nel “price of error”: dati scorretti attivano liquidazioni e modificano i parametri di rischio, quindi serve una penalità economica per la distorsione del flusso.
- Cosa si impegna a fare l’operatore: pubblicare dati corretti, per esempio il prezzo, secondo formato, frequenza e fonti concordate.
- Cosa viene considerato una violazione: manipolazione intenzionale, manipolazione coordinata, ritardo sistematico negli aggiornamenti (stale data — dati “obsoleti”).
- Perché qui serve il restaking: l’attacco ai dati deve costare più del potenziale vantaggio, altrimenti gli incentivi si rompono.
- Come di solito viene incorporata la responsabilità: l’AVS definisce regole di partecipazione e penalità; peso e quote possono tenere conto dello stake delegato, ma il rischio è definito dalle condizioni di slashing del servizio specifico.
Il restaking aumenta il
Restaked rollups e componenti L2
Una parte dell’infrastruttura L2 può essere spostata in un AVS e collegata a una responsabilità penalizzabile degli operatori, invece di costruire una propria “economia dei validatori”, cioè un insieme separato di partecipanti e incentivi di sicurezza.
- Cosa si impegna a fare l’operatore: eseguire le regole del componente L2, cioè ordine delle azioni, pubblicazioni e verifiche concordate, nelle condizioni previste.
- Cosa viene considerato una violazione: affermazioni conflittuali sullo stato, censura, rifiuto di servizio, violazione delle garanzie protocollari del servizio.
- Perché qui serve il restaking: una responsabilità penalizzabile riduce la dipendenza dalla buona fede di un insieme limitato di operatori.
- Cosa ottiene il mercato: avvio rapido dei servizi e meno incentivi a costruire un token separato solo per la sicurezza.
Il componente L2 può ottenere una
Calcoli e risultati verificabili
Negli AVS computazionali il compito viene formulato come un contratto sul risultato: il pagamento avviene per l’esecuzione secondo protocollo, mentre il sabotaggio diventa un rischio penalizzabile.
- Cosa si impegna a fare l’operatore: eseguire un calcolo o una procedura e fornire una conferma del risultato secondo le regole del servizio.
- Cosa viene considerato una violazione: alterazione del risultato, mancata esecuzione, non conformità al formato di verifica o prova.
- Perché qui serve il restaking: l’onestà di esecuzione viene spostata dalla fiducia nel provider alla responsabilità economica.
- Cosa ottiene il mercato: infrastruttura computazionale con costo dell’errore controllato e obblighi penalizzabili per i partecipanti.
Il restaking rende la qualità dell’esecuzione un
Categorie AVS: bridge e cross-chain messenger (bridged vs native stablecoin), moduli ZK (verifica di prove a conoscenza zero), reti DePIN (infrastruttura fisica decentralizzata) e servizi di coordinamento, dove è importante fissare la responsabilità economica degli operatori in caso di violazione delle regole.
Criterio di applicazione: il restaking viene usato dove serve un alto costo dell’errore: l’AVS paga per l’esecuzione delle regole; la violazione delle regole rende penalizzabile la garanzia allocata degli operatori.
Restaking come mercato della responsabilità: security budget e prezzo dell’errore
In EigenLayer i pagamenti non compaiono per il solo fatto dello stake, ma per l’assunzione di obblighi aggiuntivi: l’AVS acquista una correttezza di esecuzione penalizzabile, mentre il rischio è determinato dalla policy di slashing e dalla complessità operativa.
Quadro breve: il security budget è “quanto costa un attacco o un sabotaggio”. Il restaking aumenta il budget di sicurezza non con promesse, ma con il collegamento “regola verificabile → trigger formale della violazione → penalità sulla garanzia allocata”.
-
L’AVS acquista responsabilità, non liquidità.
- Senso dell’accordo: il servizio paga per l’esecuzione dei requisiti, firme, disponibilità e risultati corretti, e la violazione si trasforma in un danno misurabile tramite slashing.
- Cosa viene fissato: il prezzo dell’errore è definito dalle regole dell’AVS, non dalla reputazione del provider.
-
Il restaking riduce la debolezza iniziale dei nuovi protocolli.
- Problema: all’avvio l’insieme proprio dei validatori è piccolo, quindi il costo dell’attacco è spesso basso.
- Effetto pratico: il servizio ottiene accesso a un pool più ampio di stake delegato senza emettere un token separato per la sicurezza.
-
Il rendimento è il pagamento per il rischio e per la complessità dell’esecuzione.
- Fonte dei pagamenti: compensi degli AVS agli operatori, tenendo conto di commissioni e requisiti.
- Prezzo dei pagamenti: la probabilità di slashing cresce insieme al numero di AVS, alla complessità dello stack e alle correlazioni infrastrutturali.
Regola di mercato: il restaking è un mercato della sicurezza condivisa, dove il costo è definito dalla policy di slashing, dai caps sul danno e dalla qualità dell’esecuzione operativa, non dai rendimenti esposti in vetrina.
EigenLayer monetizza la sicurezza come servizio: l’AVS paga per regole e garanzie penalizzabili, mentre lo stake riceve un flusso aggiuntivo di pagamenti insieme a un livello aggiuntivo di slashing.
Vantaggi del restaking in EigenLayer per validatori e detentori di ETH
Il restaking aggiunge allo staking di ETH un secondo livello di responsabilità: i pagamenti arrivano dagli AVS, mentre il rischio è definito dalle loro regole di slashing e dalla qualità degli operatori.
Logica dei vantaggi: i pagamenti aggiuntivi compaiono solo dove lo stake accetta responsabilità aggiuntive. Nel restaking la responsabilità è definita dalla policy di slashing degli specifici AVS e dalla qualità di esecuzione degli operatori.
Vantaggi del restaking: fonte dei pagamenti e prezzo del rischio
-
Pagamenti sopra lo staking di base
Fonte: pagamento dell’AVS per il servizio delle regole del sistema, tramite l’operatore e la sua commissione.
Prezzo: slashing secondo le regole dell’AVS e dipendenza dall’affidabilità operativa dell’operatore.
-
Diversificazione dei flussi di pagamento
Fonte: insieme di AVS presso l’operatore, con modelli di pagamento e requisiti diversi.
Prezzo: intersezione dei rischi: un solo guasto dell’operatore può colpire più AVS contemporaneamente.
-
Partecipazione senza un nodo proprio tramite LST/LRT
Fonte: strutture liquide, LST, e livelli superiori, LRT, che uniscono ricompense di base e pagamenti AVS in un solo asset.
Prezzo: livelli di rischio aggiuntivi: smart contract, depeg/sconto, liquidità di uscita, condizioni del protocollo LRT.
-
Flessibilità nella distribuzione della responsabilità
Fonte: la delega a un operatore e la scelta degli AVS determinano quale parte dello stake rientra in quali regole.
Prezzo: la limitazione del rischio funziona solo tramite limiti formali e architettura delle strategie, non tramite intenzioni.
-
Domanda per lo stake di ETH come servizio di sicurezza
Fonte: gli AVS acquistano sicurezza dal mercato dello stake di Ethereum invece di emettere un token per i validatori.
Prezzo: la sicurezza diventa un mercato competitivo: cambiano condizioni di pagamento, insiemi di AVS e requisiti per gli operatori.
Esempio, senza numeri: la ricompensa base per lo staking su Ethereum resta, e sopra di essa può comparire il pagamento di uno o più AVS. Il risultato finale è determinato da due parametri: (1) somma dei pagamenti AVS; (2) profilo di rischio — policy di slashing e probabilità di errori operativi dell’operatore scelto.
Il restaking aumenta l’efficienza del capitale, cioè una sola garanzia sostiene più livelli di pagamenti e responsabilità, grazie ai pagamenti degli AVS, ma amplia il livello di slashing e rende la gestione del rischio una parte obbligatoria del modello.
Rischi del restaking: slashing, errori correlati e pressione su Ethereum
I pagamenti AVS sono il prezzo di una responsabilità aggiuntiva: allo slashing di Ethereum si aggiungono le regole di penalità dei servizi esterni, mentre i guasti correlati aumentano la probabilità di scenari a cascata.
Due livelli di penalità: Ethereum definisce lo slashing per il consenso L1, mentre il restaking aggiunge lo slashing secondo le regole degli AVS. Il rischio è determinato dalla policy di slashing degli AVS e dall’affidabilità operativa dell’operatore.
Slashing secondo le regole AVS
L’operatore accetta obblighi formali verso ciascun AVS, e la violazione delle regole comporta una penalità sulla garanzia allocata.
- Trigger: downtime, firme errate, gestione scorretta dei dati, azioni conflittuali, incompatibilità dopo un aggiornamento del client.
- Scala del danno: è definita dalla policy dell’AVS, dalle condizioni, dai limiti, dai livelli di violazione e dal volume di stake effettivamente utilizzato per quell’AVS.
- Fattori di contenimento: limiti di esposizione per AVS, distribuzione tra operatori, rinuncia agli AVS con policy di slashing poco definite o con alta complessità operativa.
Osservazione: più AVS ha un operatore, più punti di guasto indipendenti esistono e maggiore è la probabilità di penalità anche in caso di guasti ordinari.
Eventi correlati e penalità di massa
Una sola causa comune può colpire molti operatori contemporaneamente, compresi partecipanti onesti.
- Trigger: bug nella logica AVS, configurazione controversa, regole ambigue, aggiornamento errato simultaneo su molti operatori.
- Scala del danno: gli addebiti di massa provocano perdite simultanee e rafforzano il deflusso di stake dal servizio o dal protocollo.
- Fattori di contenimento: caps sulla penalità massima, limiti sulla quota di stake in un solo AVS, verifica indipendente, meccanismi assicurativi o di compensazione, se previsti dal design di mercato.
Osservazione: un bug comune o una configurazione controversa dell’AVS possono avviare penalità di massa nello stesso momento.
Indebolimento della disciplina dello stake in caso di danno elevato fuori da L1
Una forte penalità a livello AVS può ridurre bruscamente la posta economica del validatore, indebolendo il ruolo disciplinante della garanzia.
- Trigger: slashing profondo in un AVS o serie di penalità in più servizi a causa di un problema operativo comune.
- Scala del danno: la riduzione della garanzia abbassa il costo dell’errore per il partecipante e aumenta la propensione a decisioni rischiose.
- Fattori di contenimento: localizzazione dei casi controversi nel layer di restaking, limiti alla profondità delle penalità, procedure di risoluzione dei conflitti a livello di servizio, non a livello di consenso Ethereum.
Osservazione: è fondamentale che i casi di slashing controversi e soggettivi restino all’interno del layer di restaking.
Concentrazione attorno a un AVS dominante e pressione sistemica
L’aumento della quota di validatori legati a un solo AVS alza la probabilità che un conflitto locale diventi sistemico.
- Trigger: penalità controversa, guasto critico o aggiornamento conflittuale in un AVS dominante.
- Scala del danno: viene colpita una quota significativa di operatori e stake delegato, e diventa più difficile una risoluzione silenziosa del conflitto.
- Fattori di contenimento: diversificazione tra AVS, limiti di concentrazione, procedure di risoluzione dei conflitti a livello di servizio o di layer di restaking, e non a livello di Ethereum.
Osservazione: un’alta concentrazione attorno a un solo AVS rende più difficile isolare i conflitti senza effetti sistemici.
Il restaking aggiunge rischi che non esistono nello staking base di ETH: slashing AVS, guasti correlati e situazioni conflittuali attorno alle regole. La riduzione dell’esposizione di solito si basa su limiti della quota di stake, distribuzione tra operatori e revisione regolare dell’insieme di AVS e della loro policy di slashing. Una penalità può annullare completamente il profitto accumulato.
Condizione di stabilità: il restaking rafforza i rischi dello staking di ETH tramite slashing AVS ed eventi infrastrutturali correlati. Senza limiti di esposizione e senza comprensione della policy di slashing, il modello diventa più rapidamente una fonte di perdite che un flusso stabile di pagamenti.
Restaking, LST, delega e LRT: confini dei termini e punti di rischio
Il restaking aggiunge allo stake un secondo livello di regole: slashing secondo la policy dell’AVS. LST risolve il problema della liquidità dello stake. La delega definisce l’esecutore. LRT aggrega strategie di restaking in un solo token e trasferisce il rischio AVS nel prezzo.
Confine dei termini: LST = rappresentazione tokenizzata dello stake; delega = scelta dell’operatore o validatore; restaking = collegamento dello stake agli AVS con una policy di slashing separata; LRT = livello superiore che aggrega strategie di restaking in un solo token.
| Strumento | Cosa viene fissato | Da dove arrivano i pagamenti | Cosa diventa rischio |
|---|---|---|---|
| Delega | Chi esegue le regole della rete | Ricompense del consenso L1 | Guasti operativi dell’esecutore entro le regole di L1 |
| LST | Quota di stake tramite token liquido | Ricompense di staking + meccanica del protocollo LST | Rischi di smart contract, sconto o depeg, liquidità di uscita |
| Restaking | La garanzia diventa slashable secondo le regole dell’AVS | Pagamenti dagli AVS, tramite operatori | Slashing AVS, guasti correlati, dipendenza dall’insieme di AVS presso l’operatore |
| LRT | Pacchetto di strategie, LST + restaking, in un solo token | Ricompense di staking + pagamenti AVS | Eredità dello slashing AVS, rischi di strategia e contratti, sconto come prezzo del rischio AVS |
Composizione pratica: la catena “staking → LST → restaking → LRT” aggiunge livelli: prima la liquidità, LST, poi la responsabilità AVS, restaking, poi l’aggregazione delle strategie, LRT. Ogni livello successivo aggiunge regole proprie e propri punti di guasto.
Separazione dei ruoli: la delega sceglie l’esecutore, l’LST dà liquidità, il restaking aggiunge un secondo livello di slashing secondo le regole AVS, e l’LRT trasferisce il profilo di rischio AVS nel prezzo del token.
Restaking in DeFi: RSFi, LRT e trasferimento del rischio AVS nel prezzo della garanzia
Il restaking crea la base per RSFi, restaking finance: prodotti LRT, strategie di rendimento e schemi assicurativi contro lo slashing, ma la caratteristica chiave è il trasferimento del rischio AVS e delle correlazioni tra operatori nel prezzo degli LRT e nella qualità della garanzia.
Canale chiave di trasmissione del rischio: in RSFi lo stato del restaking si manifesta attraverso il prezzo dell’LRT. Lo sconto dell’LRT rispetto a ETH riflette non solo la liquidità di uscita, ma anche la rivalutazione della probabilità di slashing AVS e degli eventi infrastrutturali correlati; nel lending questo si manifesta più spesso tramite l’aumento dell’LTV effettivo e l’avvio delle liquidazioni.
-
L’LRT tokenizza un portafoglio di obblighi.
- Meccanica: le ricompense base dello staking vengono integrate con i pagamenti AVS, e la strategia viene tokenizzata in un LRT.
- Composizione del rischio: slashing AVS, rischio dell’operatore, guasti correlati nell’insieme degli AVS, rischio contrattuale e strategico del packaging.
-
L’LRT come garanzia rafforza la connessione tra scenari sistemici.
- Scenario: l’LRT viene usato nel lending, nei pool o nei derivati e resta legato al rischio del restaking.
- Conseguenza: lo stesso stake economico partecipa contemporaneamente ai livelli di Ethereum, AVS e posizioni DeFi.
-
Lo sconto dell’LRT accelera le liquidazioni tramite la qualità della garanzia.
- Trigger: aspettativa di slashing, aumento dell’incertezza operativa degli operatori, concentrazione attorno a un AVS dominante, aggiornamenti controversi o incidenti negli AVS.
- Trasmissione in DeFi: lo sconto peggiora la qualità della garanzia, alza l’LTV effettivo e accelera le liquidazioni nei protocolli collegati.
-
L’assicurazione contro lo slashing diventa un livello separato di design.
- Meccanica: una parte dei pagamenti AVS viene indirizzata a un pool assicurativo o a una riserva di compensazione.
- Struttura: i livelli conservativi ricevono pagamenti più bassi, ma hanno priorità di compensazione; quelli aggressivi accettano un rischio più alto.
Perché questo può diventare un rischio sistemico: il prezzo dell’LRT influenza contemporaneamente la garanzia in molti protocolli. Quando il rischio AVS viene rivalutato, lo sconto dell’LRT peggiora la qualità della garanzia e accelera le liquidazioni, rafforzando le vendite a cascata.
Esempio di scenario: ETH → LST → restaking → LRT → uso dell’LRT come garanzia per un prestito in stablecoin. In questa catena lo stesso stake protegge Ethereum, serve gli AVS e sostiene una posizione di credito, quindi lo sconto dell’LRT accelera il rischio di liquidazione.
Fonte delle cascade: RSFi si costruisce attorno agli LRT e ai pagamenti AVS, mentre il principale canale degli effetti sistemici è il trasferimento delle aspettative di slashing AVS e dei guasti correlati nel prezzo della garanzia e nella liquidità di uscita.
Futuro del restaking e modelli di sicurezza condivisa
Il restaking si muove verso un formato di sicurezza condivisa: i progetti si collegano a un livello di responsabilità di mercato, cioè pagamento per regole e penalità, invece di costruire una propria economia dei validatori.
Bivio principale della crescita: la scala del restaking è determinata dagli standard di integrazione, dal design dello slashing e dalle procedure di localizzazione degli incidenti, non solo dal numero di nuovi AVS.
| Cosa cambia | Perché serve | Cosa riduce |
|---|---|---|
| Standardizzazione delle interfacce AVS e dei profili di rischio | Comparabilità delle condizioni e riduzione del costo di integrazione della sicurezza | Frammentazione delle integrazioni ed errori causati da implementazioni uniche |
| Rigorosità formale, audit, verifica, post-mortem | Accesso a grandi stake solo per moduli maturi | Rischio di bug critici e scatole nere senza spiegazioni |
| Slashing ingegnerizzato, caps, livelli, trigger chiari | Costo dell’errore controllabile e prevedibilità del danno | Penalità di massa per eventi rari o controversi |
| Procedure per incidenti, resolver, arbitrato, compensazioni | Localizzazione dei conflitti all’interno del layer di restaking | Trasferimento delle dispute e della pressione sul layer base Ethereum |
Cosa diventerà la norma di mercato per gli operatori di sicurezza:
- Portafoglio AVS e limiti di esposizione. Insieme di servizi e limiti formali sulla quota di stake sotto ciascuna policy di slashing.
- Processi invece di promesse. Regole di aggiornamento, monitoraggio, risposta, test e registrazione degli incidenti.
- Trasparenza e reputazione. Cronologia di guasti e slashing, report pubblici, regole chiare per la gestione dei conflitti e delle compensazioni, se previste.
- Controllo delle correlazioni. Considerazione dei componenti comuni dello stack e dei rischi di un bug per tutti durante aggiornamenti di massa.
Fase di transizione: i primi grandi stress test sono quasi inevitabili: bug, penalità controverse, guasti correlati. La stabilità del modello è determinata dai caps sul danno, da procedure trasparenti di analisi e da meccanismi di localizzazione dei conflitti a livello di restaking, non a livello del consenso Ethereum.
Direzione: con una standardizzazione riuscita, la sicurezza può diventare un servizio infrastrutturale con garanzie criptoeconomiche, dove le condizioni di responsabilità si leggono con la stessa trasparenza di tariffe e SLA nei servizi infrastrutturali classici.
Fattore di successo: il futuro del restaking è determinato dall’ingegneria della responsabilità: standardizzazione degli AVS, slashing prevedibile e procedure di localizzazione degli incidenti senza cascade sistemiche.
FAQ su restaking e protocollo EigenLayer
Risposte brevi alle domande frequenti: che cos’è il restaking e cosa sono gli AVS, se servono 32 ETH, da dove arrivano i pagamenti e dove appare esattamente il rischio di slashing.
Che cos’è il restaking in parole semplici?
Che cos’è un AVS nel contesto di EigenLayer?
È necessario avere 32 ETH per partecipare al restaking?
Che rendimento può offrire il restaking?
In cosa il restaking si differenzia dal liquid staking, LST?
È possibile perdere capitale a causa del restaking?
Il restaking non indebolirà la sicurezza di Ethereum stesso?
Sintesi finale: restaking, LST, delega e LRT
Il restaking aggiunge allo staking di ETH un secondo livello di responsabilità: lo stake diventa slashable secondo le regole degli AVS. Questo crea un mercato della sicurezza condivisa e pagamenti per compiti infrastrutturali, ma amplia anche il livello di rischio per lo stake e per le catene DeFi attorno agli LRT.
Sintesi in una riga: EigenLayer collega lo stake di ETH ai servizi esterni e trasforma gli obblighi degli operatori verso gli AVS in responsabilità penalizzabile tramite slashing della garanzia allocata.
Dove appare il beneficio, cioè cosa acquista il mercato:
- Sicurezza come servizio. Gli AVS ottengono protezione basata sullo stake di Ethereum senza avviare una propria economia dei validatori.
- Avvio rapido dell’infrastruttura. I protocolli si collegano a un layer di responsabilità già pronto invece di creare un token per i validatori.
- Nuovi primitive per DeFi. I prodotti LRT e RSFi tokenizzano pagamenti e responsabilità, ma insieme a essi vengono tokenizzati anche i rischi.
Dove appare il rischio, cioè cosa diventa il prezzo dei pagamenti:
- Slashing AVS. Sopra le regole di Ethereum compaiono policy di slashing separate per ciascun servizio.
- Guasti correlati. Componenti comuni dello stack e aggiornamenti di massa possono portare a violazioni sincronizzate tra molti operatori.
- Cascade tramite il prezzo dell’LRT. Lo sconto dell’LRT peggiora la qualità della garanzia e accelera le liquidazioni nei protocolli di lending.
Essenza del modello: il restaking su EigenLayer non è un supplemento di rendimento, ma un modello con responsabilità ampliata. La sostenibilità si basa su limiti di esposizione, diversificazione tra operatori e AVS e disponibilità allo slashing e ai guasti correlati.
Condizione di standard: il restaking si affermerà come standard infrastrutturale se gli incidenti verranno localizzati all’interno del layer di restaking, con caps sul danno, procedure di analisi, riserve e compensazioni, e se il rischio verrà valutato con la stessa severità degli smart contract e delle garanzie in DeFi.