Vai al contenuto
Financial Context Wiki

Code di uscita e prelievo dei validatori

Una richiesta di uscita del validatore, la coda di capacità di uscita, il ritardo di responsabilità, la liquidazione o il reclamo del prelievo e il riscatto del fornitore sono fasi diverse. Ricostruire esattamente la macchina a stati del protocollo, l'autorità, il rendimento, la punibilità e il percorso degli asset prima di stimare quando i fondi saranno spendibili.

Aggiornato

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

Risposta diretta

Una coda di uscita dei validatori limita la velocità con cui il peso del consenso può lasciare un insieme di validatori attivi. Non è necessariamente lo stesso meccanismo di una coda di richiesta di prelievo, di un periodo di disimpegno o di responsabilità, di una raccolta automatica dei saldi idonei, di una richiesta avviata dall’utente o della coda di riscatto di un fornitore di staking. La domanda utile non è “quanto è lunga la coda?” ma “in quale stato si trova questa posizione, quale transizione è successiva e quale condizione rende l’asset spendibile dal suo proprietario?”

Separare queste fasi e affermazioni:

  • Accettazione della richiesta: un messaggio firmato, transazione, chiamata di contratto o istruzione del provider è validamente incluso e attribuito al validatore, account o posizione corretti.
  • Capacità di uscita o disattivazione: un protocollo limita quanto il numero di validatori o il peso effettivo può smettere di partecipare per epoca, sessione o altro intervallo.
  • Responsabilità o ritardo di sblocco: una posizione uscita o non delegata rimane bloccata e può rimanere esposta a penalità per comportamenti precedenti attribuibili.
  • Elaborazione del prelievo: un saldo idoneo viene spinto da una pulizia del protocollo, estratto da una transazione di richiesta, rilasciato da un conto di stake o trasferito quando viene elaborata una coda di maturità.
  • Riscatto del fornitore: un custode, pool, token di liquid-staking o contratto di restaking applica i propri raggruppamenti, liquidità, commissioni, tasso di cambio, permessi e ritardi intorno al protocollo base.

Ethereum illustra perché le distinzioni sono importanti. Una completa uscita del validatore può essere avviata con la chiave di firma del validatore o, secondo le regole attuali, dal livello di esecuzione dall’autorità di prelievo. Dopo la programmazione dell’uscita e lo stato successivamente prelevabile, un prelievo completo idoneo con credenziali di prelievo di esecuzione viene effettuato automaticamente. I validatori legacy Type 1 e i validatori composti Type 2 hanno comportamenti diversi per i prelievi parziali. Una transazione di richiesta, un’uscita dal consenso, un’epoca prelevabile e un prelievo automatico sono quindi osservazioni separate.

Quei label Ethereum non sono universali. In una catena Cosmos SDK, la non delegazione di un delegatore crea una voce di sblocco con un tempo di completamento configurato dalla catena, e i moduli esterni possono sospendere uno sblocco. In Solana, un’autorità di conto di stake disattiva una delegazione, lo stake si raffredda attraverso i confini di epoca, e l’autorità di prelievo può prelevare lo stake inattivo soggetto a qualsiasi vincolo. I contratti di restaking possono aggiungere un altro prelievo in coda e una finestra soggetta a penalità. È sempre necessario ispezionare esattamente la rete, la versione, il modulo, il contratto e i termini del servizio.

Come analizzare il tempismo di uscita e ritiro

1. Definisci la posizione e il regolamento

Registra lo network, chain ID, il fork o runtime attivo, il blocco o l’epoca, la versione del client/specification, il modulo di staking o i contratti e i termini di servizio. Identifica se l’oggetto è un’identità del validatore, auto-stake, quote delegate, un conto di stake, reclamo pooling, token di liquid-staking o allocazione restaked. Non applicare una regola di uscita del validatore al riscatto di un delegante o alla responsabilità off-chain di un provider.

2. Verifica l’autorità e richiedi l’accettazione

Mappa la chiave di firma del validatore, le credenziali di prelievo o autorità, l’autorità di stake, il proprietario del conto, il chiamante del contratto, il beneficiario e il pagatore delle commissioni. Riproduci i campi del messaggio richiesti, il dominio della firma, l’indice del validatore o la chiave pubblica, l’importo, il nonce, la destinazione e la commissione. Conferma l’inclusione finalizzata e lo stato risultante; un file firmato localmente, una transazione inviata, un ticket del provider o una simulazione riuscita non costituiscono prova che il protocollo abbia accettato la richiesta.

3. Ricostruire la macchina a stati

Scrivi ogni stato e transizione piuttosto che una data stimata. Un percorso illustrativo del validatore è active -> exit_requested -> exit_scheduled -> exited -> withdrawable -> withdrawal_processed -> wallet_credited. Un delegatore può invece muoversi attraverso bonded -> unbonding -> matured -> transferred, mentre un conto stake può essere active -> deactivating -> inactive -> withdrawn. Registra quali transizioni sono automatiche e quali richiedono un’altra transazione o un’azione di servizio.

4. Quantifica ogni collo di bottiglia

Limiti di ingresso delle richieste separati, turbolenza di uscita dei validatori, ritardi fissi, capacità di prelievo, code di contratti, raggruppamento dei fornitori e finalità o conferma. Determinare se la capacità è misurata dai record dei validatori, dallo stake effettivo, dal saldo, dalle richieste, dal gas o dal tempo trascorso. Interrogare queue_ahead, capacity_per_interval, dimensione o saldo del set attivo e qualsiasi limite nello stesso punto di osservazione finalizzato. Una stima semplice ceil((work_ahead + own_work) / capacity) è valida solo quando le assunzioni sull’ordinamento e sulla capacità sono rispettate.

5. Individua i doveri, le ricompense e la possibilità di slash

Trova l’epoca, l’altezza o lo stato esatto in cui terminano i compiti di proposta e voto, quando si interrompono le ricompense ordinarie, quando le penalità possono ancora essere applicate e quando il saldo smette di essere soggetto a taglio. Questi momenti non devono coincidere. Mantieni il validatore online e correttamente configurato finché lo stato del protocollo non indica che i suoi compiti sono terminati; una richiesta di uscita trasmessa o lo stato del front-end non costituiscono autorità sufficiente per spegnerlo.

6. Traccia i livelli di asset e di rivendicazione

Segui le unità native dalla contabilità vincolata o attiva attraverso pending, unbonding, ritirabile, contratto escrow, custodia del fornitore e conto di destinazione. Valuta separatamente le azioni, i token di ricevuta o i token di liquid-staking utilizzando il loro tasso di cambio e il prezzo di mercato. Ricongiungi ricompense del protocollo, penalità, slashing, commissioni, tasse di riscatto, gas, costi di bridge e arrotondamenti. La vendita di un diritto trasferisce il rischio di liquidità a un acquirente; non accelera la transizione del protocollo base.

7. Verifica il completamento e pianifica la liquidità

Usa lo stato finalizzato, gli eventi del protocollo, le registrazioni della coda, gli oggetti di prelievo, i saldi dei conti di destinazione e le passività del fornitore per dimostrare ogni transizione. Salva gli identificatori delle richieste e lo snapshot dei parametri utilizzato per la stima. Costruisci piani di cassa con un intervallo e un margine di contingenza piuttosto che una singola data, e definisci l’escalation per sweep mancanti, contratti in pausa, credenziali errate, insolvenza del fornitore o un saldo che differisce dalla riconciliazione prevista.

Esempi svolti

Calcolo del tempo a più stadi

Considera un protocollo illustrativo con block_time = 12 seconds e epoch = 30 blocks = 6 minutes. Una richiesta impiega 4 blocks per raggiungere il punto di conferma scelto, attende 72 epochs per la capacità di uscita, quindi ha un ritardo di responsabilità 8 epochs e un 12 blocks previsto fino all’elaborazione del trasferimento:

4 * 12 = 48 seconds.

72 * 6 = 432 minutes.

8 * 6 = 48 minutes.

12 * 12 = 144 seconds = 2.4 minutes.

Il tempo totale illustrativo è 48 seconds + 432 minutes + 48 minutes + 2.4 minutes = 483.2 minutes = 8.0533 hours. Le fasi si sommano perché sono sequenziali. Questo non è un forecast Ethereum: le regole reali possono usare intervalli diversi, churn dipendente dallo stato, ritardi minimi, algoritmi di scansione e assunzioni di finalità.

Coda basata sul peso con capacità variabile

Supponiamo unità effettive work_ahead = 50,000, questa uscita rappresenta own_work = 320, e iniziale capacity_per_epoch = 640. Con capacità costante:

ceil((50,000 + 320) / 640) = ceil(78.625) = 79 epochs.

A 6 minutes per epoca, cioè 79 * 6 = 474 minutes = 7.9 hours. Ma si assume che la capacità scenda a 512 dopo l’epoca 30. Le prime 30 epoche elaborano 30 * 640 = 19,200, lasciando 50,320 - 19,200 = 31,120. Il resto richiede ceil(31,120 / 512) = 61 epochs, quindi il totale rivisto è 30 + 61 = 91 epochs = 9.1 hours. Una stima in tempo reale deve ricalcolare capacità e ordinamento piuttosto che congelare un tasso su un cruscotto.

Riconciliazione del saldo tramite uscita

Un validatore illustrativo inizia con unità 32, guadagna 0.40 prima della fine dei doveri, sostiene 0.05 di penalità ordinarie e successivamente riceve un taglio 1.20 attribuibile sotto la finestra di esposizione del protocollo. L’importo disponibile prima di qualsiasi commissione del fornitore o tassa è:

32 + 0.40 - 0.05 - 1.20 = 31.15 units.

La richiesta non ha bloccato un pagamento in unità 32. Le variazioni del saldo del protocollo, la contabilità del fornitore e le variazioni del prezzo di mercato sono registri separati. Se la destinazione riceve 31.15, questo riconcilia il percorso in unità native ma non dice nulla sul valore in valuta fiat o sui diritti di rimborso.

Richiesta di liquidità contro riscatto in coda

Supponiamo che i token di liquid-staking 100 possano essere venduti ora a 0.965 unità native ciascuno, producendo:

100 * 0.965 = 96.5 units.

Un fornitore invece quota il riscatto a un’unità nativa per token dopo una coda con una commissione 0.2%, o 100 * (1 - 0.002) = 99.8 units. La differenza è 99.8 - 96.5 = 3.3 units, e lo sconto per vendita immediata rispetto agli introiti in coda quotati è 3.3 / 99.8 = 3.3066%. Lo spread di 3.3 unità compensa solo il tempo, l’incertezza e la liquidità in questo istante; le decurtazioni, le variazioni del tasso di cambio, la perdita del contratto o una coda sospesa possono modificare gli introiti successivi.

Rischi e fallimenti della revisione

  • Coda sbagliata: Le code di uscita del validatore, ingresso delle richieste di prelievo, unbonding, sweep, contratto e riscatto del fornitore hanno stati e capacità diversi.
  • Regole sbagliate: Un’altra chain, fork, runtime, versione del modulo, testnet o distribuzione del contratto può usare transizioni differenti.
  • Parametri obsoleti: Il tasso di uscita, i ritardi fissi, i limiti di sweep, le commissioni, i lockup e le condizioni del fornitore possono cambiare dopo la stima.
  • Richiesta non accettata: Firmare, trasmettere, simulare o aprire un ticket non prova l’accettazione definitiva da parte del protocollo.
  • Confusione di autorità: Le chiavi del validatore, del prelievo, dello stake, del proprietario, del custode e dell’amministratore del contratto possono autorizzare azioni diverse.
  • Errore di credenziali o destinazione: Una conversione irreversibile delle credenziali o un indirizzo di prelievo errato può trasferire permanentemente il controllo.
  • Arresto prematuro: Interrompere i compiti prima dello stato di uscita registrato può far perdere ricompense o comportare penalità.
  • Errore nel termine delle ricompense: Richiesta, uscita programmata, uscita effettiva, prelevabilità e trasferimento possono seguire regole di maturazione diverse.
  • Rischio residuo di slashing: I fondi usciti, in unbonding o in coda possono restare esposti a infrazioni precedenti attribuibili.
  • Discrepanza tra conteggio e peso: Una coda espressa come numero di validatori può non riflettere la capacità applicata per saldo effettivo o quote.
  • Errore di coda dinamica: Modifiche successive dei parametri o dell’insieme attivo possono alterare il throughput anche se le richieste successive non possono superare le precedenti.
  • Confusione tra sweep e richiesta: L’idoneità può attivare un invio automatico, richiedere un’operazione dell’utente o lasciare in attesa di uno sweep circolare.
  • Confusione tra parziale e totale: Il prelievo del saldo eccedente, l’undelegation parziale e l’uscita completa del validatore non sono equivalenti.
  • Lockup e sospensioni: I blocchi del conto, i controlli di governance, le pause di sicurezza o le sospensioni di moduli esterni possono superare la scadenza nominale.
  • Disallineamento del fornitore: Un servizio può ritardare, raggruppare, limitare, compensare o rifiutare il riscatto anche dopo il completamento del protocollo di base.
  • Sovrapposizione del restaking: L’uscita dalla chain di base può non liberare lo stake assegnato a un altro servizio né terminare la relativa finestra di penalità.
  • Rischio di base del diritto liquido: Un token di liquid staking può essere scambiato sotto il valore del diritto o perdere convertibilità sotto stress.
  • Commissioni e perdite di arrotondamento: Gas, commissioni dinamiche, conversione delle quote, costi di bridge e modifiche dei decimali incidono sull’importo ricevuto.
  • Guasto di custodia o contratto: Chiavi compromesse, insolvenza, autorità di aggiornamento, bug o guasti del bridge possono bloccare o deviare gli asset.
  • Errore di osservabilità e finalità: I dashboard possono essere in ritardo, omettere voci trattenute, confondere stati stimati e finalizzati o mostrare un evento poi riorganizzato.

Comuni idee sbagliate

Presentare una richiesta di uscita significa che i compiti del validatore cessano immediatamente?

No. La richiesta di inclusione, la pianificazione dell’uscita e lo stato in cui i doveri terminano sono separati. Continua a operare secondo il protocollo fino a quando lo stato finale non conferma che il validatore non è più necessario partecipare.

Withdrawable significa che il portafoglio di destinazione è stato accreditato?

No. withdrawable di solito descrive l’idoneità. Il protocollo potrebbe comunque dover eseguire la scansione del validatore, un utente potrebbe dover reclamare, un account potrebbe aver bisogno di un prelievo esplicito, o un fornitore potrebbe dover rilasciare la propria responsabilità. Verifica il saldo di destinazione.

La lunghezza della coda divisa per il tasso di oggi può dare una data esatta?

No. Il display può contare l’unità sbagliata, la capacità può dipendere dallo stato, possono seguire ritardi fissi e tempi di scansione, e le fasi del fornitore possono essere omesse. Indicare tutte le assunzioni e calcolare un intervallo.

La vendita di un token di liquid-staking bypassa la coda di uscita?

Fornisce al venditore liquidità immediata sul mercato se esiste un acquirente. La quota sottostante o il diritto di riscatto di un altro detentore seguono ancora il protocollo e le regole del fornitore, mentre il venditore accetta il prezzo di mercato e i costi di negoziazione.

Un periodo di sblocco o di prelievo pubblicizzato è un massimo garantito?

No. Potrebbe essere un ritardo minimo o previsto che esclude l’inclusione della richiesta, la congestione, la finalità, le spazzolate, le sospensioni, le pause contrattuali, il raggruppamento del fornitore o la risposta agli incidenti. Solo le regole attive e lo stato osservato definiscono il completamento.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...