Vai al contenuto
Financial Context Wiki

Nothing at Stake: equivoco, slashing, finalità e rischio delle vecchie chiavi

Nothing at Stake è il problema di incentivi della proof of stake in cui sostenere storie concorrenti può avere un basso costo marginale. Analizza separatamente messaggi punibili, rendimento atteso, intersezione dei quorum, esecuzione delle prove, fork choice e ipotesi di soggettività debole.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

Nothing at Stake è un problema di incentivi della proof of stake: se produrre una firma aggiuntiva costa poco e il protocollo non impone un costo effettivo per un sostegno incompatibile, un validatore può guadagnare di più aiutando ogni storia concorrente invece di sceglierne una. Se molti validatori seguono questo incentivo privato, i fork possono conservare sostegno, la convergenza può indebolirsi e un attaccante può ottenere firme che nella proof of work sarebbero costose da riprodurre.

L’espressione non significa che ogni sistema proof of stake sia privo di budget di sicurezza o che ogni voto su un fork perdente sia illecito. Capitale vincolato, ricompense perse, slashing, prelievi ritardati, regole di fork choice e finalità possono modificare il rendimento. I messaggi firmati e i conflitti punibili dipendono dal protocollo e dalla versione; un normale aggiornamento del voto, un messaggio in ritardo o un fork onesto temporaneo possono essere ammessi.

Tre domande devono rimanere separate. Primo: un validatore attualmente vincolato può equivocare a basso costo tra rami recenti? Secondo: un peso di voto indisponibile o avversario può arrestare il progresso senza creare due storie finalizzate? Terzo: vecchie chiavi possono fabbricare una lunga storia alternativa dopo che lo stake è prelevabile? Sono rischi collegati di incentivo e consenso, ma hanno prove, soglie e difese diverse.

Ethereum è un esempio utile, non un modello universale. Le sue specifiche di consenso rendono punibili due proposte distinte per lo stesso slot e le attestazioni che costituiscono doppio voto o surround vote. La fork choice può ignorare l’influenza di chi equivoca, mentre la finalità usa voti a supermaggioranza e penalità. Altre famiglie proof of stake adottano diversa selezione dei leader, scelta della catena, checkpoint, ipotesi di disponibilità o modelli formali di sicurezza.

Come analizzare Nothing at Stake

  1. Fissa il contesto del protocollo. Registra protocol, version, network, epoch, slot, validator set e l’ora di osservazione. Individua fork choice, finality gadget, reward rule, penalty rule e withdrawal delay attivi; l’etichetta “PoS” non determina nessuno di questi elementi.
  2. Definisci le azioni firmate. Elenca proposte di blocco, attestazioni, prevote, precommit, certificati o altri messaggi e i rispettivi domini. Distingui due messaggi che si limitano a favorire discendenti diversi da un double proposal, double vote o surround vote formalmente punibile secondo le regole citate.
  3. Modella il rendimento senza penalità. Stima probabilità dei rami, ricompense del ramo canonico, costi aggiuntivi di firma e propagazione, tangenti, opportunità perse e ricompense per messaggi contrastanti. Confronta EV(honest) con EV(equivocate) invece di presumere che il basso consumo elettrico dimostri la redditività della deviazione.
  4. Modella la perdita esigibile. Individua saldo vincolato, probabilità di rilevamento, finestra di validità delle prove, percorso di segnalazione, rischio di inclusione e censura, penalità iniziale, penalità correlata, espulsione, tempistica del prelievo e reddito futuro perso. Una penalità scritta nella documentazione non equivale all’esecuzione affidabile di slashing evidence.
  5. Separa fork choice e finalità. Ricostruisci come voti più recenti, equivoci e tempistica dei messaggi influenzino la testa, quindi calcola il peso necessario per giustificare o finalizzare i checkpoint. Analizza separatamente safety threshold e liveness threshold: trattenere voti può fermare la finalità senza produrre finalità contrastante.
  6. Verifica le ipotesi su vecchie chiavi e sincronizzazione. Determina quando lo stake ritirato non è più punibile, quale storia finalizzata rifiuterà un nodo online, come un nodo nuovo o rimasto a lungo offline ottiene un weak-subjectivity checkpoint e come ne verifica attualità e provenienza. Questo è il problema long-range, non soltanto un doppio voto recente.
  7. Sottoponi operazioni e controllo a stress test. Verifica chiavi duplicate, nodi di failover, firmatari remoti, rollback del database, bug dei client, hosting correlato, staking pool, custodia delegata, partizioni, attacchi eclipse e censura delle prove. Conta percorsi indipendenti di controllo e software, non solo identificativi dei validatori.

Il risultato deve essere una valutazione di incentivi e consenso con versione esplicita, non un verdetto basato sul termine. Mostra i messaggi esatti che una chiave può firmare, quali prove contrastanti sono verificabili oggettivamente, fino a quando la garanzia è raggiungibile, quale soglia protegge la sicurezza, quale permette il progresso e quale stato fidato serve a un nodo in sincronizzazione.

Esempi calcolati

1. Una strategia senza penalità può favorire entrambi i rami

Supponiamo che uno solo di due rami diventi canonico: il ramo A con probabilità 0.55 e il ramo B con 0.45. Una firma sul ramo canonico guadagna 1.00 unit, mentre una firma sul ramo perdente non guadagna nulla. Ignorando tutte le penalità e i costi operativi aggiuntivi, firmare solo A produce EV(A only) = 0.55 * 1.00 = 0.55 units. Firmare entrambi produce EV(sign both) = (0.55 + 0.45) * 1.00 = 1.00 unit.

Il calcolo illustra il problema di incentivi; non è una previsione del rendimento dello staking. Presuppone che la firma sul ramo canonico sia ricompensata qualunque ramo vinca, che le azioni siano permesse o non sanzionate, che gli esiti dei rami si escludano a vicenda e che il validatore non subisca perdite di prezzo, reputazione, latenza o reddito futuro.

2. Lo slashing esigibile può invertire il rendimento

Mantieni la ricompensa lorda canonica di 1.00 unit e aggiungi una tangente di 0.02 unit per l’equivoco. Supponi che prove valide raggiungano il meccanismo di penalità con probabilità 0.80 e che la perdita totale attribuibile sia 5.00 units. Il rendimento semplificato è EV(equivocate) = 1.00 + 0.02 - (0.80 * 5.00) = -2.98 units, inferiore a 0.55 units ottenute firmando solo A.

Il risultato cambia se rilevamento, inclusione, garanzia esigibile o reddito futuro sono diversi. Le penalità reali possono dipendere dal saldo effettivo, dalle violazioni correlate, dal tempo e dallo stato del protocollo. Gli operatori devono modellare una distribuzione degli esiti e verificare il percorso di implementazione; moltiplicare tre numeri scelti non dimostra che un sistema distribuito sia compatibile con gli incentivi.

3. L’intersezione dei quorum protegge la sicurezza ma può esporre la liveness

Considera 100 stake units e una regola che richiede almeno 67 units per un voto di finalità. Due quorum simili si sovrappongono per almeno 67 + 67 - 100 = 34 units. Pertanto due finalizzazioni contrastanti richiedono che almeno 34 unità partecipino a entrambi i certificati di quorum; un protocollo responsabilizzabile può rendere tale intersezione dimostrabilmente punibile.

La stessa soglia ha un’implicazione diversa per la liveness. Se 34 units trattengono voti validi, ne rimangono solo 66 units, meno di 67, e la finalità può arrestarsi. Quelle 34 unità non finalizzano da sole due rami. Fallimento della sicurezza, prova attribuibile e mancato progresso non devono essere descritti come lo stesso evento.

4. Le vecchie chiavi creano un diverso problema di sincronizzazione

Supponiamo che un nodo online abbia finalizzato il checkpoint epoch 39,900, mentre un nuovo nodo non dispone di uno stato fidato. Un attaccante ottiene chiavi che controllavano stake sufficiente intorno a epoch 10,000, dopo l’uscita di quei validatori e quando la loro garanzia non è più raggiungibile, e fabbrica una storia alternativa fino a epoch 40,000. Le firme storiche economiche sono rilevanti, ma lo slashing dei validatori recenti potrebbe non scoraggiare più quelle vecchie chiavi.

Il nodo online rifiuta una storia in conflitto con la sua vista finalizzata. Il nuovo nodo necessita di un checkpoint recente autenticato o di una regola di protocollo equivalente per distinguere le storie prima di proseguire con la verifica oggettiva. Per questo soggettività debole e tempistica dei prelievi appartengono alla revisione, pur restando analiticamente distinte dall’equivoco in tempo reale dei validatori vincolati.

Rischi ed errori di revisione

Errori di protocollo e prove

  • Definire punibile ogni voto su un fork non canonico senza verificare campi firmati e domini esatti.
  • Trattare fork, riorganizzazione, proposta mancata, voto tardivo ed equivoco dimostrabile come eventi intercambiabili.
  • Applicare le condizioni per proposer e attester di Ethereum a un protocollo con messaggi o regole di finalità differenti.
  • Omettere identità della catena, versione del fork, epoch o slot confrontando firme asseritamente contrastanti.
  • Presumere che due firme da sole provino un illecito senza identità del validatore, domini, ascendenza e crittografia valida.
  • Confondere influenza sulla fork choice con giustificazione, finalizzazione o regolamento a livello applicativo.
  • Leggere un teorema di sicurezza senza le sue ipotesi di sincronia, onestà, disponibilità e avversario.

Errori di incentivo ed esecuzione

  • Dire che le firme sono economiche senza prezzare perdita vincolata, ricompense mancate e reddito futuro.
  • Trattare lo slashing nominale massimo come perdita attesa esigibile in ogni stato.
  • Presumere che le prove siano sempre osservate, propagate, incluse ed elaborate prima del prelievo.
  • Ignorare censura del proposer, partizioni di rete, isolamento eclipse e scadenza della finestra delle prove.
  • Usare un valore atteso illustrativo come prova quando probabilità, tangenti e perdite non sono misurate.
  • Ignorare penalità correlate, movimenti del prezzo del token, coperture, tangenti esterne e guadagni dell’attacco.
  • Presumere che la vecchia chiave di un validatore uscito sia ancora garantita da collaterale attualmente punibile.

Errori operativi, di concentrazione e recupero

  • Eseguire la stessa chiave di firma su nodi di failover senza una protezione dallo slashing durevole e condivisa.
  • Ripristinare il firmatario o il database di slashing da backup obsoleti e ricreare conflitti già firmati.
  • Contare le chiavi dei validatori come operatori indipendenti nonostante custodia, client, cloud o controllo di governance condivisi.
  • Presumere che chi delega lo stake non subisca perdite causate da un operatore, pool o dipendenza di restaking.
  • Fidarsi di un solo explorer, provider o checkpoint incluso recuperando un nodo rimasto a lungo offline.
  • Affermare che un’elevata partecipazione allo staking dimostri sicurezza senza analizzare distribuzione, soglia e controllo dello stake.

Idee sbagliate comuni

  • Nella proof of stake non c’è letteralmente nulla a rischio. Sistemi ben progettati possono esporre a perdita capitale vincolato, ricompense e partecipazione futura; la questione è se tali costi siano sufficienti ed esigibili per la deviazione rilevante.
  • Ogni messaggio di un validatore su due fork è un doppio voto. La punibilità dipende da campi, domini e regole di conflitto del protocollo; gli aggiornamenti onesti della fork choice necessitano di margine.
  • Lo slashing garantisce il consenso. Fornisce responsabilità e incentivi, ma sicurezza e liveness dipendono anche da soglie, rete, implementazioni, sicurezza delle chiavi e ipotesi di comportamento onesto.
  • Un terzo dello stake può finalizzare da solo due rami. In un modello di finalità a due terzi, circa un terzo può spesso bloccare il progresso; la finalità contrastante richiede supermaggioranze sovrapposte e partecipazione punibile nella loro intersezione.
  • Nothing at Stake e attacchi long-range sono identici. Entrambi sfruttano firme economiche, ma uno riguarda il sostegno in tempo reale a rami concorrenti, mentre l’altro può usare chiavi storiche contro nodi privi di uno stato fidato recente.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...