Vai al contenuto
Financial Context Wiki

Proof of Stake

Proof of Stake è una famiglia di design di consenso blockchain che assegna potere di proposta o di voto utilizzando lo stake posto a rischio economico. La sicurezza dipende dall'intero protocollo, dalla distribuzione dei validatori, dalle regole di finalità, dalle regole di slashing e dalle assunzioni di recupero, non solo dallo stake.

Aggiornato

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

Risposta diretta

Proof of Stake (PoS) è una famiglia di design di consenso in cui i validatori pongono a rischio economico un asset definito dal protocollo e ricevono peso di proposta o di voto secondo le regole della rete. I validatori onesti propongono blocchi, verificano le transizioni di stato e votano sulla storia della blockchain. Messaggi dimostrabilmente in conflitto possono attivare la penalizzazione (slashing) nei protocolli che la implementano, mentre i doveri mancati di solito causano penalità minori o ricompense non percepite. Lo stake è una risorsa resistente a Sybil: rende costoso acquisire influenza, ma non rende valida una transazione invalida.

PoS non è un unico algoritmo. I sistemi a catena, tolleranti ai guasti bizantini, delegati e nominati differiscono nell’ammissione dei validatori, nella selezione del leader, nella scelta delle fork, nella finalità, nella delega, nello sblocco e nella punizione. Valori specifici di Ethereum come un saldo di attivazione 32 ETH, slot di 12 secondi e voti di checkpoint dei due terzi non sono proprietà universali di PoS. Qualsiasi analisi deve indicare la rete e la versione del protocollo.

L’affermazione sulla sicurezza richiede anche più di “molto in gioco.” Dipende da chi può controllare o coordinare quel rischio, dalla frazione necessaria per fermare o violare il consenso, dalle assunzioni sui tempi della rete, dalla diversità dei client, dalla sicurezza delle chiavi, dalle regole di checkpoint e recupero e dal fatto se le penalità possano effettivamente essere imposte. La delega concentrata o un servizio comune possono fare in modo che migliaia di validatori nominali si comportino come un unico operatore.

Le ricompense dello staking sono una compensazione per il capitale, il lavoro operativo e il rischio del protocollo, non un interesse garantito. Una scomposizione utile è:

Tasso lordo di staking = ricompense annuali del protocollo / stake medio attivo

Rendimento netto dell’operatore = premi + commissioni allocate e MEV - penalità - commissioni di servizio - costi operativi

Il rendimento misurato nel token messo in staking è separato dal rendimento di mercato del token. Code di ingresso e uscita, periodi di sblocco, esposizione a slashing, tasse, sconti sul token di liquid staking e rischio di controparte possono modificare materialmente il risultato realizzato dall’investitore.

Sotto soglia
25%
Quota contraddittoria
25%
Margine alla soglia
8,4%

I risultati sono approssimazioni didattiche. Escludono regole della sede, tasse, latenza, comportamento degli oracoli e altri parametri specifici del protocollo se non indicati.

Come funziona

Un protocollo PoS completo combina un registro delle partecipazioni, i compiti dei validatori, una regola di scelta del fork, una regola di finalità o conferma, incentivi e procedure di recupero. I nomi e le soglie variano, ma una revisione può seguire sette passaggi:

  1. Definire il confine della quota e del validatore. Identificare l’asset a rischio, il saldo minimo o effettivo, le regole di ammissione del validatore, il modello di delega, la coda di attivazione, le credenziali di prelievo e le entità che controllano effettivamente le chiavi di firma.
  2. Seleziona i compiti sotto la casualità del protocollo. Il protocollo assegna proposte di blocco, attestazioni, voti o lavori del comitato. La selezione può essere ponderata in base alla partecipazione, limitata per validatore o mediata da un insieme di delegati; la quota di partecipazione pubblicata non corrisponde sempre al peso effettivo del voto.
  3. Verifica le transizioni di stato proposte. I nodi completi verificano in modo indipendente firme, saldi, esecuzione e regole di consenso. La quota di un validatore o il voto della maggioranza non possono autorizzare una transazione che violi le regole di validità deterministica.
  4. Vota e applica la scelta della fork. I validatori firmano messaggi di protocollo riguardanti blocchi o checkpoint. Quando esistono storie valide concorrenti, la regola di scelta del fork utilizza i messaggi idonei e i loro pesi per scegliere la testa; i ritardi della rete possono temporaneamente produrre viste locali differenti.
  5. Raggiungere conferma o finalità. Alcuni sistemi offrono finalità economica esplicita dopo un voto di supermaggioranza, mentre altri forniscono una crescente fiducia con la profondità. La sicurezza chiede se i nodi onesti possono finalizzare storie in conflitto; la vivacità chiede se la catena può continuare a finalizzare.
  6. Applica ricompense, penalità e slashing. Doveri corretti e tempestivi possono guadagnare emissioni, commissioni o altre ricompense. L’inattività può far perdere ricompense o comportare penalità. L’equivocazione o altre violazioni dimostrabili possono causare l’espulsione e la distruzione della partecipazione, ma le condizioni e gli importi sono specifici del protocollo.
  7. Esci, ritirati e recupera. I validatori possono affrontare code di uscita, ritardi nel disimpegno o finestre di sanzionabilità post-uscita prima che i fondi diventino trasferibili. Anche i client necessitano di checkpoint fidati o altre procedure di recupero quando si applicano soggettività debole, storie a lungo termine o guasti eccezionali del consenso.

PoS e Proof of Work utilizzano entrambi risorse scarse per rendere costosi gli attacchi al consenso, ma le risorse e i modelli di recupero differiscono. PoW spende continuamente energia e capacità hardware e solitamente fornisce una risoluzione probabilistica. PoS blocca capitale soggetto a penali, può fornire finalità economica esplicita e utilizza molta meno elaborazione continua, ma introduce assunzioni relative a chiavi dei validatori, concentrazione delle stake, attacchi a lungo raggio e checkpoint. Nessun meccanismo garantisce da solo decentralizzazione, resistenza alla censura, basse commissioni o corrette applicazioni.

Ethereum illustra una implementazione, non la definizione. I suoi validatori attestano blocchi e checkpoint, LMD-GHOST seleziona il head, Casper FFG finalizza i checkpoint con voti che rappresentano almeno due terzi dello stake attivo, e i checkpoint di debole soggettività aiutano un nodo nuovo o offline da tempo ad ancorarsi a uno stato canonico recente. Altre reti PoS possono usare diversi progetti di comitato, delega e finalità.

Esempi svolti

La selezione ponderata per stake è un’aspettativa, non un programma

Si supponga che un protocollo illustrativo selezioni ogni proponente in proporzione allo stake effettivo e abbia 720 opportunità di proposta al giorno. Un operatore con 2.000 unità su 1.000.000 ha una quota di 2.000 / 1.000.000 = 0,2%. Le sue proposte attese sono 720 x 0,2% = 1,44 al giorno. L’operatore può ricevere zero, una o più assegnazioni in un determinato giorno perché la selezione è casuale; la formula non garantisce una proposta ogni 16,7 ore.

I premi lordi non sono il rendimento netto

Una posizione in pool rappresenta 32 token. Durante un anno riceve 1,28 token di ricompense del protocollo e 0,20 token di commissioni allocate, ma perde 0,08 token per inattività. Il servizio addebita il 10% delle ricompense positive: (1,28 + 0,20) x 10% = 0,148 token. Le ricompense nette sono 1,28 + 0,20 - 0,08 - 0,148 = 1,252 token, o 1,252 / 32 = 3,9125%, prima di hardware, imposte e variazioni del prezzo del token. Pubblicizzare solo il tasso di emissione del protocollo del 4% sovrastimerebbe il risultato dell’utente.

La produzione di blocchi può continuare mentre la finalità si blocca

Considera una regola di finalità in stile Ethereum che richiede voti superiori ai due terzi di 1.000.000 di unità di stake attivo: devono quindi concordare più di circa 666.667 unità. Se i validatori che rappresentano 340.000 unità vanno offline insieme, ne rimangono disponibili al massimo 660.000. I blocchi possono comunque essere proposti, ma manca la supermaggioranza necessaria per la finalità. Un meccanismo di inattività specifico del protocollo può ridurre il peso inattivo nel tempo; non elimina il fallimento iniziale della finalità.

Uno sconto sul liquid staking non è automaticamente una penalità

Un investitore detiene 100 unità di un token di staking liquido che rappresenta un diritto su asset messi in staking. Durante uno shock di liquidità, il token viene scambiato a 0,96 unità dell’asset di base. Vendere immediatamente restituisce 100 x 0,96 = 96 unità, con uno sconto di 4 unità, ossia del 4%. Tale sconto di mercato può riflettere ritardi nell’uscita, scarsa liquidità o timori sulla controparte, anche se nessun validatore ha subito slashing e la contabilità sottostante rimane integralmente coperta.

Rischi e controlli

Sicurezza e vivacità del consenso

  • Controllo efficace concentrato: Gli exchange, i pool o i delegati possono coordinare più stake di quanto suggeriscano i numeri dei validatori. Misura il controllo per operatore, chiavi, governance e infrastruttura, non solo per indirizzi.
  • Fallimento della finalità o partizione: La messa in stake offline, i bug del client o le divisioni della rete possono fermare la finalità della supermaggioranza mentre i blocchi continuano. Monitora i checkpoint finalizzati e la salute del protocollo, non solo l’altezza del blocco.
  • Rischio di lunga portata e di soggettività debole: Gli ex validatori possono costruire storie passate alternative dopo che la loro quota è prelevabile. Avviare dai checkpoint recenti ottenuti tramite canali fidati indipendenti quando il protocollo li richiede.
  • Errore di soglia specifico del protocollo: Un terzo, un mezzo e due terzi hanno significati diversi a seconda dei protocolli. Leggere la specifica effettiva di fork-choice, sicurezza e vivacità prima di applicare una soglia.

Operazioni e chiavi del validatore

  • Doppia firma durante la migrazione: Eseguire chiavi di firma copiate su due macchine può creare voti in conflitto. Utilizzare database di protezione contro lo slashing, un firmatario attivo e una procedura di migrazione controllata.
  • Compromissione della chiave di firma: Un aggressore può firmare messaggi suscettibili di penalità, censurare o reindirizzare i compiti. Isolare le chiavi del validatore, limitare l’accesso, monitorare i messaggi e mantenere separata l’autorità di prelievo dove supportato.
  • Tempi di inattività e interruzioni correlate: Guasti di alimentazione, rete, cloud, client o configurazione comportano la perdita di ricompense e possono innescare penalità di inattività maggiori. Diversificate client e infrastruttura e testate il failover senza duplicare i firmatari.
  • Errore di credenziali di prelievo: Chiavi di prelievo perse, errate o controllate dal fornitore possono bloccare il recupero anche quando il validatore funziona correttamente. Verifica le credenziali prima del deposito e mantieni backup testati e procedure di successione.

Ricompense, capitale ed economia dell’uscita

  • Tasso di ricompensa variabile: Formule di emissione, partecipazione attiva, espletamento dei doveri, commissioni eMEVcambiare nel tempo. Modella una gamma di rendimenti lordi e netti piuttosto che trattare l’APY visualizzata come fissa.
  • Rischio di prezzo del token e diluizione: Più token in staking non garantiscono un maggiore potere di acquisto in valuta fiat, e l’emissione può diluire i non staker o tutti i detentori. Separare il rendimento denominato in token dal ritorno totale del mercato.
  • Attivazione, uscita e ritardo di disimpegno: La crescita della coda può lasciare il capitale inattivo all’ingresso o non disponibile durante lo stress. Misurare ogni fase del ciclo di vita ed evitare di presumere il riscatto immediato.
  • Incertezza sulle penalità e sullo slashing: La perdita dipende dall’infrazione, dalla versione del protocollo e dal comportamento correlato. Rivedere l’esposizione massima e le regole di allocazione del fornitore invece di assumere che solo le ricompense siano variabili.

Delegazione, custodia e staking liquido

  • Inadempienza del custode o dell’operatore: Un servizio può perdere chiavi, usare fondi in modo improprio, interrompere i prelievi o fallire operativamente. Determina chi detiene l’autorità di firma e prelievo e se i crediti sono segregati in caso di insolvenza.
  • Rischio dei smart contract della pool: I depositi, la contabilità, gli aggiornamenti e le code di prelievo possono dipendere da contratti al di là dello staking nativo. Rivedere le autorizzazioni, gli audit, i controlli di emergenza e le dipendenze del protocollo.
  • Sconto sul token di staking liquido: Un token di ricevuta può essere scambiato al di sotto del suo valore di rimborso a causa di problemi di liquidità, durata, penalità o preoccupazioni sull’emittente. Evidenziare separatamente il prezzo di uscita dal mercato dall’eventuale riscossione tramite protocollo.
  • Concentrazione della delega: Gli utenti di mantengono l’esposizione economica mentre un piccolo gruppo di operatori acquisisce influenza nel consenso. Monitora la distribuzione delle partecipazioni, i limiti degli operatori, le modifiche dei delegati e il potere di governance.

Censura, implementazione e misurazione

  • Censura e concentrazione MEV: Grandi operatori o relè comuni possono escludere o riordinare le transazioni. Monitorare il comportamento di inclusione e la dipendenza da costruttori, relè e intermediari di policy.
  • Monocultura di client e implementazione: Un bug condiviso può correlare fallimenti tra validatori altrimenti indipendenti. Utilizza client diversi e mantenuti e comprendi le conseguenze del fallimento della maggioranza dei client.
  • Metriche di decentralizzazione fuorvianti: Il conteggio dei validatori, il conteggio degli indirizzi e lo stake totale possono nascondere la proprietà comune o l’hosting. Combina attribuzione dell’entità, misure geografiche, del cliente, del cloud e di governance.
  • Rischio di governance e recupero sociale: Il coordinamento delle emergenze può essere necessario dopo un guasto grave, ma chi definisce il recupero canonico può essere oggetto di disputa. Comprendere il controllo degli aggiornamenti, le fonti dei checkpoint e il precedente del recupero.

Comuni idee sbagliate

Ogni detentore di token convalida automaticamente in Proof of Stake

Possedere l’asset non è lo stesso che gestire un validatore. L’ammissione al protocollo, le chiavi, il software, i tempi di attività e i doveri continuano ad applicarsi. I deleganti o i possessori di token di liquid staking possono trasferire il controllo di voto o operativo a un’altra entità e assumersi rischi aggiuntivi di contratto o di controparte.

Un totale maggiore di stake significa sempre che la rete è più sicura

Il costo dell’attacco può aumentare con una posta in gioco preziosa, ma la sicurezza dipende anche da concentrazione, liquidità, prestito e delega, diversità dei clienti, soglie e regole di recupero. Dieci milioni di unità controllate in modo indipendente sono diverse dalla stessa quantità controllata attraverso un unico operatore.

Il rendimento dello staking è interesse privo di rischio

Le ricompense compensano il blocco del capitale, le operazioni e l’esposizione al protocollo. Penalità, slashing, commissioni, code, perdite sul prezzo dei token, guasti dei contratti intelligenti e rischi di custodia possono superare le ricompense. Un APY mostrato non è né garantito né direttamente comparabile a un tasso di interesse privo di rischio.

I validatori vengono puniti ogni volta che vanno offline

Molti protocolli distinguono l’inattività ordinaria dal comportamento provabilmente conflittuale. Su Ethereum, i doveri mancati generalmente comportano la perdita di ricompense o l’imposizione di penalità, mentre doppie proposte e attestazioni punibili possono causare slashing ed espulsione. Altre reti definiscono reati e importi diversi.

Proof of Stake rende le transazioni economiche e immediatamente definitive

Il consenso determina l’accordo sulla storia valida; la capacità di esecuzione e i mercati delle commissioni determinano il costo delle transazioni. La finalità richiede ancora voti e tempo definiti dal protocollo e può bloccarsi durante una partecipazione insufficiente o guasti di rete anche se i blocchi continuano a comparire.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...