Delegare a un validatore espone a penalità e blocchi di fondi

Slashing nella proof of stake: quali comportamenti fanno scattare la penalità, chi la paga fra validatore e delegante e quanto restano fermi i fondi.

Corridoio di una sala macchine con armadi di server accesi e spie luminose allineate
BalticServers.com / CC BY-SA 3.0

L’interfaccia mostra un elenco di nomi, una percentuale accanto a ciascuno e un pulsante. Due tocchi e la delega è fatta. Nessuna schermata spiega che da quel momento una parte dei fondi risponde del comportamento di una macchina che non si controlla, e che riprenderseli non è un’operazione immediata.

Non è una critica alla delega, che è un meccanismo sensato e progettato per funzionare. È un’osservazione su quanto poco di questo meccanismo arriva a chi lo usa. Le due conseguenze che contano — la penalità per un errore altrui e l’indisponibilità dei fondi per un periodo stabilito dal protocollo — non compaiono quasi mai nella pagina in cui si sceglie.

Vale la pena guardarle da vicino, insieme alla distinzione che regge tutto il resto: delegare il diritto di validare non è la stessa cosa che consegnare le chiavi a qualcuno. Le due operazioni si somigliano nell’interfaccia e sono profondamente diverse in ciò che espongono.

Quello che cambia quando si delega

  • Le chiavi. Nella delega nativa restano al proprietario: il validatore ottiene il peso, non la facoltà di spendere.
  • La penalità. Se il validatore firma messaggi in conflitto, la riduzione colpisce l’intero insieme delegato, in proporzione.
  • Il tempo. Il ritiro non è istantaneo: esiste una finestra di sblocco durante la quale i fondi non si muovono e non maturano nulla.
  • La commissione. Si applica ai premi prima che arrivino, e in molte reti il validatore può modificarla entro limiti dichiarati.
  • Da evitare. Scegliere in base alla sola percentuale mostrata, concentrare tutto su un unico operatore, ignorare quale programma esegue.

Delega non è custodia, e la differenza è tecnica

Le reti a partecipazione non funzionano tutte allo stesso modo, e la parola delega copre situazioni diverse. In alcune è una funzione del protocollo: una transazione firmata associa il peso dei propri token a un validatore, i token restano nell’account di partenza e nessuna chiave viene mai trasmessa. In altre il protocollo non prevede nulla di simile, e chi non ha i requisiti per gestire un nodo proprio passa da un contratto o da un operatore che i fondi li riceve davvero.

La distinzione non è formale. Nel primo caso l’unico modo per perdere capitale è la penalità prevista dal protocollo, che ha regole scritte e verificabili. Nel secondo si aggiunge il rischio che chi detiene i fondi non li restituisca, per fallimento, per errore o per decisione propria: un rischio di controparte ordinario, che non ha niente a che vedere con il consenso della rete.

Quando i fondi passano a un terzo che ne conserva le chiavi si entra nel perimetro dei servizi di custodia, con gli obblighi che il quadro europeo impone ai prestatori autorizzati e con la vigilanza descritta dall’ESMA. Chi delega nel senso stretto del protocollo resta invece fuori da quel perimetro, perché non ha affidato niente a nessuno. Sono due posizioni giuridiche distinte, oltre che due architetture distinte.

Nell’interfaccia le due strade si somigliano al punto da risultare indistinguibili: stesso elenco, stessa percentuale, stesso pulsante. La differenza si legge in un solo posto, la transazione che si sta per firmare. Se il messaggio associa un peso all’indirizzo di un validatore i token non si spostano; se dispone un trasferimento verso un altro indirizzo, li si sta consegnando.

Che cosa fa scattare lo slashing nella proof of stake

La penalità severa non punisce l’incompetenza: punisce i comportamenti che minacciano la coerenza del registro. Il caso classico è l’equivocazione, cioè firmare due messaggi in conflitto per la stessa posizione nella catena. Un validatore onesto non lo fa mai, perché il protocollo gli chiede una sola firma per volta.

Il secondo caso riguarda i voti che si contraddicono nel tempo, quando un validatore attesta una versione della storia e poi ne attesta un’altra incompatibile. Anche qui la prova è oggettiva: le due firme esistono, chiunque può verificarle e chiunque può presentarle alla rete, di solito ottenendo una parte della somma sottratta come compenso per la segnalazione.

La causa più frequente non è la malafede, ed è utile saperlo prima di scegliere. È la duplicazione: la stessa chiave di firma attiva su due macchine contemporaneamente, perché un ripristino è andato storto, perché una migrazione è stata fatta senza spegnere l’originale, perché un sistema di alta disponibilità ha creduto di dover intervenire. Il protocollo non distingue l’errore dall’attacco, e non ha modo di farlo: vede due firme in conflitto e applica la regola.

Gli operatori attenti affrontano il problema separando la chiave dal nodo: la firma avviene su un componente dedicato che tiene memoria dell’ultimo messaggio firmato e rifiuta qualunque messaggio lo contraddica. È una difesa che agisce esattamente nel punto in cui l’errore diventa irreversibile, e chiedere se sia in uso è una domanda legittima da porre a chiunque proponga la propria delega.

Inattività e penalizzazione seguono regole diverse

Un validatore spento non produce firme in conflitto, quindi non innesca la penalità severa. Produce però un’assenza, e le reti la trattano in modi che vanno distinti con attenzione perché l’effetto sui fondi cambia molto.

Il trattamento più diffuso è la mancata maturazione: chi non partecipa non riceve premi, e basta. Diverse reti aggiungono un’esclusione temporanea dall’insieme attivo dopo un numero definito di blocchi mancati, con una riduzione contenuta e la necessità di una transazione esplicita per rientrare. Alcune prevedono, in condizioni di malfunzionamento diffuso, una riduzione progressiva a carico di chi resta assente mentre la rete fatica a chiudere i blocchi.

C’è poi una regola che sfugge quasi sempre e che pesa nella scelta dell’operatore. Dove esiste, la penalità cresce con quanto peso viene colpito nello stesso intervallo di tempo: un incidente isolato costa poco, lo stesso incidente che coinvolge simultaneamente una quota consistente della rete costa molto di più a ciascuno. È un disincentivo deliberato alla concentrazione, scritto nel protocollo e non nelle raccomandazioni.

Quando paga il validatore e quando paga il delegante

La domanda ha una risposta netta e poco gradita: nella delega nativa la riduzione si applica al peso complessivo, quindi anche alla quota delegata. Il delegante non ha commesso l’infrazione e ne subisce comunque l’effetto, in proporzione a quanto ha delegato.

Il validatore perde di più in termini relativi, perché al capitale proprio si aggiunge la reputazione e quindi la delega futura, ma questo non restituisce niente a chi lo aveva scelto. Alcuni operatori dichiarano di coprire volontariamente le perdite dei deleganti con fondi propri o con una copertura assicurativa: è un impegno contrattuale privato, non una regola del protocollo, e va letto per quello che è, verificandone i limiti e le esclusioni.

La conseguenza pratica è che la selezione dell’operatore non è una formalità. Un errore di configurazione altrui produce una perdita che nessuna transazione può annullare, e la catena non prevede reclami. Chi arriva a queste reti dopo aver seguito la variabilità dei mercati digitali tende a sottovalutare proprio questa componente, che con i movimenti di prezzo non ha alcun rapporto.

Anche il momento in cui la penalità si manifesta merita attenzione. In alcune reti la riduzione è immediata e compare subito nel saldo vincolato, in altre viene applicata in più fasi o soltanto all’uscita, e nell’intervallo l’interfaccia continua a mostrare un valore che non corrisponde più a quello effettivo. Controllare il saldo su un esploratore, e non solo nell’applicazione, è l’unico modo per accorgersene per tempo.

Il periodo di sblocco e la coda di uscita

Clessidra di vetro con la sabbia che scende appoggiata su un ripiano di legno scuro
TOMUWN 2sreimoa HUNGAI / CC BY-SA 4.0

Chiudere una delega non libera i fondi. Comincia una finestra, definita dal protocollo, durante la quale i token non sono trasferibili e non maturano nulla. La durata varia sensibilmente da rete a rete, da pochi giorni a diverse settimane, ed è un parametro pubblico che va letto prima e non dopo.

La finestra esiste per una ragione precisa: senza di essa un validatore disonesto potrebbe firmare messaggi in conflitto e ritirare tutto prima che la prova venga presentata alla rete. Per questo, in molte implementazioni, la penalità resta applicabile anche ai fondi già in uscita, se l’infrazione è avvenuta mentre erano ancora vincolati. Uscire prima che il problema emerga non mette al riparo.

A questa attesa se ne somma spesso un’altra, meno documentata. Diverse reti limitano quanti validatori possono entrare o uscire in ciascun intervallo, per non alterare troppo rapidamente la composizione dell’insieme attivo. Quando molti si muovono nella stessa direzione si forma una coda, e il tempo effettivo di uscita diventa la somma fra la finestra di sblocco e l’attesa in coda. Nei momenti di tensione le due cose si sovrappongono proprio quando la fretta è massima.

Tre modelli a confronto

Le tre strade più comuni espongono a rischi diversi. La tabella mette in fila ciò che cambia davvero.

Modello Chi detiene le chiavi Chi subisce la penalità Rischio aggiuntivo
Delega nativa Il proprietario dei token Validatore e deleganti, in proporzione Nessun terzo custode, solo la scelta dell’operatore
Servizio con custodia Il prestatore del servizio Il prestatore, che ribalta l’effetto per contratto Insolvenza e inadempimento del prestatore
Token di ricevuta Un contratto, con un insieme di operatori L’insieme dei detentori della ricevuta Difetti del contratto e scostamento del prezzo di scambio

Il terzo modello merita una nota. La ricevuta è negoziabile, quindi il vincolo temporale sembra sparire, ma non sparisce: si trasforma nella possibilità di scambiarla sul mercato secondario a un prezzo che nei momenti di tensione può allontanarsi dal valore sottostante, proprio perché il riscatto diretto richiede comunque l’attesa. È un tema di finanza decentralizzata più che di consenso, e va valutato con gli strumenti di quella disciplina.

La commissione del validatore e le voci che nessuno legge

La percentuale mostrata accanto a ogni nome è la quota trattenuta sui premi prima che vengano distribuiti. Non incide sul capitale delegato e non è un costo di ingresso: è un prelievo sul flusso.

Due dettagli contano più della cifra. Il primo è se il valore può cambiare: molte reti permettono al validatore di modificarlo, spesso entro un massimo dichiarato al momento della creazione e con un limite alla variazione consentita in ciascun intervallo. Una commissione bassissima appena impostata può essere una scelta commerciale temporanea, e il parametro che conta è il massimo, non il valore corrente.

Il secondo riguarda la periodicità della distribuzione e le operazioni necessarie per raccogliere quanto maturato. In alcune reti serve una transazione esplicita, con la relativa commissione di rete, e su importi contenuti quel costo può assorbire buona parte di ciò che si stava raccogliendo. È una voce che le tabelle comparative non riportano quasi mai, e che va calcolata sul proprio caso e non in astratto.

Concentrazione: il validatore più grande non è la scelta neutra

Cavi di rete colorati collegati alle porte di uno switch dentro un armadio tecnico
ProjectManhattan / CC BY-SA 3.0

Selezionare l’operatore con più peso sembra prudente: se è grande, funziona. Il ragionamento ignora che le penalità correlate esistono proprio per rendere costosa questa scelta collettiva, e che un guasto sul grande operatore colpisce molti contemporaneamente.

La correlazione ha inoltre cause tecniche indipendenti dalla volontà di chiunque. Se una quota rilevante della rete esegue la stessa implementazione del programma di consenso, un difetto in quel programma produce un errore simultaneo su tutti i nodi che lo usano. Lo stesso vale per la concentrazione su un unico fornitore di infrastruttura o su una sola area geografica: un’interruzione di servizio diventa un evento di rete, non un incidente locale.

Le domande utili prima di scegliere sono quindi diverse da quelle che l’interfaccia suggerisce. Quale programma esegue il validatore, dove sono le macchine, esiste una procedura documentata contro la doppia firma, quanto peso controlla già l’operatore e quanto pesa nelle decisioni di governance della rete. Nessuna di queste informazioni compare accanto alla percentuale.

Sette controlli prima di delegare

  1. Verificare il modello. Stabilire se si tratta di delega nativa, di servizio con custodia o di token di ricevuta: cambia chi tiene le chiavi.
  2. Leggere la durata dello sblocco. È un parametro pubblico del protocollo, non una condizione dell’operatore.
  3. Controllare la commissione massima. Non quella corrente, ma il tetto dichiarato e la variazione consentita per intervallo.
  4. Chiedere quale programma esegue. La diversità delle implementazioni riduce il rischio di guasto simultaneo.
  5. Guardare la storia del validatore. Blocchi mancati, esclusioni temporanee, penalità già subite: sono dati pubblici e consultabili.
  6. Frazionare fra operatori indipendenti. Diversi per gestore, per programma e per infrastruttura, non solo per nome.
  7. Documentare tutto dall’inizio. Date, importi, premi raccolti e commissioni: i premi hanno rilevanza fiscale e ricostruirli a posteriori è molto più faticoso.

Un chiarimento sul perimetro: questo testo descrive un meccanismo e i rischi che comporta, non suggerisce di delegare né di astenersi, e non contiene alcuna indicazione operativa. Gli obblighi dichiarativi e il trattamento fiscale dei premi seguono la disciplina italiana delle cripto-attività e vanno verificati sul proprio caso, come ricorda anche il quadro della regolamentazione applicabile in Italia.

Domande frequenti

Delegando consegno i miei token al validatore?

Nella delega prevista dal protocollo no: i token restano nell’account di partenza e il validatore ottiene soltanto il peso corrispondente, senza alcuna facoltà di spesa. Se invece il servizio richiede un trasferimento verso un indirizzo altrui o verso un contratto, l’operazione è diversa e comporta un rischio di controparte che va valutato a parte.

Posso cambiare validatore senza aspettare?

Diverse reti prevedono uno spostamento diretto verso un altro operatore senza passare dalla finestra di sblocco, spesso con limiti sul numero di spostamenti consecutivi. Dove questa funzione non esiste, l’unico percorso è chiudere la delega, attendere e ricominciare. È un parametro da verificare prima di scegliere, non dopo.

Se il validatore viene penalizzato perdo tutto?

No. Le riduzioni previste dai protocolli colpiscono una frazione del peso vincolato, non la totalità, e l’entità dipende dal tipo di infrazione e da quanta parte della rete è coinvolta nello stesso intervallo. Resta una perdita definitiva sul capitale delegato, senza possibilità di ricorso.

Perché alcune reti puniscono l’inattività e altre no?

Perché rispondono a due scelte di progettazione diverse. Dove la sicurezza dipende dalla partecipazione continua di una maggioranza, l’assenza è un problema attivo e viene sanzionata. Dove la rete tollera un tasso di assenza più alto senza degradare, l’unica conseguenza è la mancata maturazione dei premi. La regola è scritta nella specifica della rete e va letta lì.

La ricevuta di uno staking liquido elimina il periodo di attesa?

Lo sposta. Il vincolo del protocollo continua a valere per i token sottostanti, e la ricevuta permette solo di cederla a qualcun altro sul mercato secondario. Quando molti provano a farlo contemporaneamente, il prezzo della ricevuta può discostarsi dal valore di ciò che rappresenta, ed è proprio quella la manifestazione del vincolo che sembrava sparito.

Dove trovo le regole esatte di una rete?

Nelle specifiche pubblicate dal progetto e, per l’ecosistema di Ethereum, nella raccolta delle proposte di miglioramento, dove le modifiche al consenso sono descritte con i parametri numerici. È il riferimento da citare quando due strumenti mostrano condizioni diverse per la stessa operazione.

Prima di scegliere un nome da un elenco conviene sapere due cose: quanto tempo serve per tornare indietro e che cosa succede al proprio capitale se quella macchina, una notte, firma due volte.

Ingegnere del software, lavora su sistemi distribuiti e legge codice prima di leggere i comunicati. Segue da vicino i livelli due, i meccanismi di consenso e gli incidenti tecnici documentati. Spiega come funziona un sistema, non quanto potrebbe valere.
2