Vai al contenuto
Financial Context Wiki

resistenza alla censura

La resistenza alla censura è un concetto importante nei concetti di base e nei confini istituzionali della criptovaluta. Questo articolo ne spiega la definizione, i principi operativi, le formule fondamentali, i casi reali, i limiti di rischio e i malintesi comuni per aiutare gli utenti a comprendere il meccanismo on-chain invece di limitarsi a memorizzare i termini.

Aggiornato

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

Risposta diretta

La resistenza alla censura è la capacità di una rete di mantenere una transazione valida raggiungibile e idonea per un’eventuale inclusione anche quando particolari gateway, peer, costruttori o produttori di blocchi la rifiutano. Si tratta di un grado di resilienza, non di una promessa che ogni transazione entri nel blocco successivo o che ogni fornitore di accesso debba servire ogni utente.

L’attestazione deve nominare il livello, l’attore e la finestra temporale. Una catena di base può resistere alla censura prolungata delle transazioni mentre un portafoglio, un frontend, un endpoint RPC, un exchange o un sequenziatore di rollup bloccano immediatamente l’accesso. Una transazione può anche essere ritardata per motivi non di censura, come una firma non valida, un nonce errato, un saldo insufficiente, una commissione inferiore alla politica di inoltro locale o concorrenza per uno spazio di blocco limitato.

Come funziona

Segui una transazione firmata attraverso fasi distinte:

  1. Creazione e invio. Il portafoglio costruisce e firma una transazione, quindi la invia tramite un provider RPC, un percorso privato o la rete peer-to-peer. Un gateway può rifiutarlo senza modificare il protocollo di base.
  2. Ammissione e propagazione. I nodi controllano la validità del consenso e il proprio mempool o politica di inoltro. Una transazione può essere valida per il consenso ma non inoltrata da un particolare nodo. Numerosi peer indipendenti e percorsi di invio riducono la dipendenza da un unico gatekeeper.
  3. Costruzione e proposta di blocchi. Un minatore, validatore, sequenziatore o costruttore esterno sceglie le transazioni e il loro ordine. I produttori a rotazione rendono temporaneo il rifiuto di un attore solo se una quota significativa di produttori successivi può vedere e includere la transazione.
  4. Validazione e scelta del fork. Altri nodi rifiutano i blocchi non validi e decidono quale ramo valido è canonico. La convalida indipendente impedisce a un produttore di rendere valida una transazione non valida, ma normalmente non obbliga quel produttore a includere una particolare transazione valida.
  5. Conferma o definitività. L’inclusione non equivale a una transazione durevole. Le riorganizzazioni possono rimuovere un’inclusione recente; la relativa regola di conferma o definitività è specifica della catena.

Misurare i risultati invece di assegnare un’etichetta binaria. Per una transazione inizialmente disponibile a livello generale su t_seen e inclusa su t_included:

inclusion delay = t_included - t_seen

Confrontate questo ritardo con transazioni di prezzo simile e di complessità simile nella stessa finestra di congestione. Un’altra misura utile è:

eligible inclusion rate = included eligible transactions / observed eligible transactions

“Idoneo” deve indicare validità, nonce, saldo, tariffa, gas o peso, tempistiche e regole di capacità. In caso contrario, la selezione tariffaria ordinaria o la congestione potrebbero essere scambiate per censura selettiva.

La resistenza dipende dalla diversità tra i domini di errore: peer, RPC, operatori autonomi, pool, client, costruttori, relè, sequenziatori, provider di hosting e giurisdizioni. I conteggi dei nodi non elaborati possono essere fuorvianti perché molti nodi o chiavi di convalida possono condividere un controller. I percorsi di inclusione forzata o gli elenchi di inclusione possono rafforzare le garanzie, ma il loro stato e le condizioni di implementazione contano. EIP-7805, ad esempio, è una proposta e non è una garanzia Ethereum attualmente utilizzata.

Esempio

Supponiamo che una transazione valida raggiunga la rete pubblica all’altezza del blocco 840,000. Offre una tariffa competitiva, si inserisce in ogni blocco successivo e rimane valido. Tre produttori lo omettono; il quarto lo comprende alla quota 840,004.

  • Il ritardo osservato è 4 blocks dal punto di partenza indicato.
  • Tre omissioni non bastano a dimostrare il coordinamento; l’ordinazione, la propagazione e la politica del produttore richiedono un’indagine.
  • L’inclusione di un quarto produttore indipendente dimostra che i primi produttori non avevano un diritto di veto completo.
  • Se i produttori che controllano 90% di opportunità applicano lo stesso filtro, un modello semplificato di slot indipendenti fornisce la probabilità di inclusione per slot 1 - 0.90 = 10% e l’attesa prevista 1 / 0.10 = 10 slots. Il controllo correlato e le regole di selezione reale possono invalidare questo modello.

Per documentare la sospetta censura, preservare la transazione o l’identificatore firmato, le osservazioni visualizzate per la prima volta da nodi indipendenti, controlli di tariffe e validità, politiche di mempool, contenuti del blocco, attribuzione del produttore e transazioni comparabili. Un errore RPC o una voce Explorer mancante non sono sufficienti.

Rischi

  • Falsi positivi: invalidità, nonce stantio, fondi insufficienti, politica tariffaria, capacità o scarsa propagazione possono sembrare censura.
  • Ordinamento concentrato: un pool, builder, relè o sequenziatore dominante può trasformare il filtraggio selettivo in lunghi ritardi.
  • Censura a livello di accesso: domini, app store, frontend, portafogli e provider RPC possono bloccare l’accesso pratico mentre rimane possibile l’accesso diretto al protocollo.
  • Infrastruttura correlata: gli endpoint dall’aspetto separato possono condividere un operatore, un cloud, un client, un relè o un’esposizione legale.
  • Perdita di privacy: la ritrasmissione attraverso molti servizi può migliorare la portata esponendo IP, tempistica e collegamento delle transazioni.
  • Percorsi di fuga deboli: l’inclusione forzata può comportare commissioni, vincoli, ritardi, finestre, requisiti di dati o controlli privilegiati.
  • Rischio di riorganizzazione e governance: l’inclusione potrebbe non essere definitiva e aggiornamenti o poteri di emergenza possono alterare le ipotesi.

Utilizzare percorsi genuinamente indipendenti ove possibile. Non condividere mai frasi seed o chiavi private con un servizio RPC, di inoltro o “anti-censura” e non sostituire o ritrasmettere una transazione senza comprendere le regole sul nonce e sulle tariffe.

Idee sbagliate comuni

  • “Valido significa inclusione garantita”. La validità crea idoneità; i produttori continuano a selezionare le transazioni a meno che non si applichi una regola più forte.
  • “Decentralizzato significa incensurabile”. La concentrazione può rimanere nella produzione, nei builder, nei relè, negli RPC, nei frontend o nella governance.
  • “Un ​​RPC bloccato dimostra la censura a catena.” Dimostra che un percorso di accesso non è riuscito o ha rifiutato la richiesta, non un veto a livello di rete.
  • “Una tariffa elevata supera ogni filtro”. Una tariffa competitiva risponde all’ordinamento economico, non a un filtro esplicito.
  • “L’eventuale inclusione è sufficiente”. L’inclusione dopo un termine operativo può essere inutile; la finestra temporale appartiene alla richiesta.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...