Vai al contenuto
Financial Context Wiki

Light client

Guida sensibile ai fork su bootstrap dei light client di consenso, sync committee, checkpoint di weak subjectivity, header ottimistici e finalizzati, prove dello stato di esecuzione, provider RPC, disponibilità dei dati e privacy.

Aggiornato

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

Risposta diretta

Un light client è un software di verifica che segue una blockchain con meno esecuzione, stato e cronologia locali rispetto a un full node. Un nodo leggero è un dispositivo o processo che esegue tale software. Su Ethereum proof-of-stake, un light client di consenso esegue il bootstrap da un checkpoint finalizzato recente e fidato e verifica gli aggiornamenti delle sync committee tenendo conto dei fork, così da mantenere header ottimistici e finalizzati. Non riesegue ogni transazione EVM.

Questa vista di consenso verificata è solo il primo punto di ancoraggio della fiducia. Per verificare il valore di un account o dello storage di un contratto, il client deve collegare l’header beacon autenticato all’header dell’execution payload, selezionarne lo stateRoot e verificare rispetto a tale radice una prova dell’account o dello storage. Una normale risposta RPC priva della prova richiesta resta un’affermazione del provider. Le firme di consenso non provano automaticamente cronologia delle transazioni, receipt, trace, disponibilità dei dati, comportamento delle applicazioni o reperibilità a lungo termine.

Come funziona

  1. Fissare rete e radici di fiducia: identità della chain, genesis validators root e ora di genesi, calendario dei fork e preset, orologio corrente, versione del client e un checkpoint di weak subjectivity finalizzato, recente e fidato. Confrontare il checkpoint tramite fonti autenticate indipendenti; l’accordo tra peer non può correggere una radice iniziale malevola.
  2. Ottenere un LightClientBootstrap per la radice del blocco fidato. Verificare l’header di bootstrap, la sync committee corrente e il relativo ramo di Merkle, quindi inizializzare il LightClientStore. Rifiutare chain, fork digest, indice generalizzato o schema di serializzazione non corrispondenti al fork configurato.
  3. Elaborare gli oggetti LightClientUpdate per periodo della sync committee. Prima di ruotare le committee, verificare slot, bit di partecipazione, firma BLS aggregata e dominio, rami della committee corrente e successiva, ramo di finalità e monotonicità. Gli upgrade dei fork possono modificare campi degli oggetti e indici generalizzati; le costanti di Altair non sono valori universali permanenti.
  4. Mantenere policy distinte per optimistic_header e finalized_header. Un aggiornamento ottimistico può fornire informazioni più recenti con maggiore esposizione a riorganizzazione o mancata pubblicazione; un aggiornamento finalizzato presenta uno stato di consenso più forte ma può essere in ritardo. Le applicazioni devono selezionare esplicitamente l’header appropriato anziché rinominare come finale la risposta più recente.
  5. Ancorare i dati di esecuzione. Verificare l’header dell’execution payload e il ramo contenuti nell’header autenticato del light client, quindi vincolare ogni query su account o storage allo stateRoot, all’hash del blocco e allo stato di finalità dell’esecuzione. Su Ethereum, eth_getProof può restituire una prova dell’account e le prove dello storage richieste; nodi, percorsi, valori e inesistenza vanno verificati localmente.
  6. Inventariare ogni superficie non verificata. Una prova del saldo non autentica receipt di transazioni, query di log, trace, simulazioni di chiamata, mempool, etichette di token, oracoli, blob, intervalli storici né l’affermazione del provider di non avere omesso risultati. Per ogni oggetto richiesto, definire una prova, una ricostruzione indipendente, un fallback su full node o un’esplicita ipotesi di fiducia.
  7. Operare in modalità fail-closed. Registrare checkpoint, fork, radici ottimistica e finalizzata, blocco e state root di esecuzione, nodi della prova, provider e timestamp. Imporre una soglia massima di obsolescenza, diversificare provider e percorsi di rete, proteggere la privacy delle query, testare il recupero da attacchi eclipse e interruzioni e usare un full node o altro sistema di verifica quando la superficie di prova del light client non basta.

Esempi svolti

  • Soglia intera della sync committee. Per una committee di 512 membri, il test di supermaggioranza della specifica è participants * 3 >= 512 * 2. Con 341 partecipanti, 341 / 512 = 66.6015625% e 1,023 < 1,024, quindi il test fallisce. Con 342, 342 / 512 = 66.796875% e 1,026 >= 1,024, quindi viene superato. Ciò verifica la regola configurata per l’aggiornamento; non prova che ogni membro della committee o implementazione sia onesto.
  • Tempi degli header. Un checkpoint didattico si trova allo slot 10,000, un header attestato allo slot 10,064 e il relativo header finalizzato allo slot 10,032. A 12 seconds/slot, l’header attestato è 64 * 12 = 768 seconds = 12 minutes 48 seconds dopo il checkpoint, mentre la finalità è 32 * 12 = 384 seconds = 6 minutes 24 seconds dietro l’header attestato. La scansione temporale degli slot non garantisce consegna di rete o finalità secondo uno SLA fisso di tempo reale.
  • Ramo compatto, affermazione limitata. In un albero ideale bilanciato con 2^20 foglie, il ramo di una singola foglia contiene 20 hash fratelli. A 32 bytes/hash, sono 640 bytes; rispetto a un oggetto di 8 MiB = 8,388,608 bytes, il ramo rappresenta lo 0.00762939453125% della dimensione, una riduzione del 99.99237060546875%. Il ramo dimostra soltanto la relazione tra foglia e radice, non la disponibilità degli altri byte.
  • Prova rispetto a RPC senza prova. In corrispondenza di uno stateRoot di esecuzione finalizzato, una prova verificata dell’account restituisce 3.25 ETH, mentre una risposta RPC priva di prova indica 3.30 ETH. La differenza è 0.05 ETH e la risposta non provata è superiore del 0.05 / 3.30 = 1.5151515152%. Accettare il valore provato rispetto alla radice selezionata, senza dedurne un saldo successivo, una receipt, un risultato storico o l’identità del token.

Rischi

  • Configurare chain, genesis validators root, ora di genesi o preset errati.
  • Avviare il bootstrap da un checkpoint malevolo, obsoleto o non finalizzato.
  • Usare una sola fonte non autenticata del checkpoint o accettare un fork a lungo raggio.
  • Lasciare che la deriva dell’orologio locale determini slot, periodi, domini o obsolescenza errati.
  • Eseguire un calendario dei fork, schema degli oggetti o indice generalizzato obsoleto.
  • Non validare partecipazione della sync committee, firme BLS o domini.
  • Mancare la rotazione della committee o accettare una committee corrente o successiva non valida.
  • Trattare l’header ottimistico come header finalizzato.
  • Collegare header beacon, execution payload o hash del blocco di esecuzione errati.
  • Verificare una prova di account o storage rispetto allo stateRoot errato.
  • Accettare nodi del trie, percorsi, codifiche o prove di inesistenza malformati.
  • Trattare come verificato un metodo RPC non supportato o privo di prova.
  • Ricevere dal provider risposte obsolete, censurate, incomplete o inventate.
  • Subire un attacco eclipse, Sybil o un guasto da controllo comune tra provider apparentemente diversi.
  • Perdere disponibilità quando i full node che forniscono prove eliminano o smettono di servire dati.
  • Confondere validità del consenso con riesecuzione o correttezza dell’applicazione.
  • Confondere una prova valida con disponibilità dei dati o reperibilità permanente.
  • Non disporre di receipt, log, trace, corpi o cronologia necessari all’applicazione.
  • Guasto dell’implementazione, dipendenza, binario o aggiornamento del fork del client.
  • Esposizione di query, IP, account e transazioni a provider o peer.

Errori comuni

  • Un light client è semplicemente un full node più piccolo o un endpoint RPC remoto rinominato.
  • Un header verificato dalla sync committee rende affidabile ogni risposta RPC.
  • L’header ottimistico più recente equivale a un header finalizzato.
  • Una prova di Merkle o firma di consenso dimostra disponibilità dei dati e cronologia completa.
  • L’uso di un light client offre automaticamente privacy, disponibilità e resistenza alla censura di un full node.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...