Vai al contenuto
Financial Context Wiki

Blockchain permissionless

Una blockchain permissionless elimina l’approvazione preventiva dell’identità per specifiche azioni del protocollo, ma idoneità, accesso pratico, influenza, privacy e governance applicativa devono essere valutati separatamente.

Aggiornato

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

Risposta diretta

Una blockchain permissionless consente a un attore di compiere specifiche azioni del protocollo senza approvazione preventiva dell’identità da parte di un amministratore o consorzio. L’etichetta deve indicare l’azione: leggere lo stato pubblico, inviare una transazione, gestire un nodo che valida autonomamente, scoprire peer, proporre un blocco, attivare stake, distribuire codice, presentare una prova o contestazione e modificare la governance possono avere regole diverse.

L’idoneità permissionless non significa accesso gratuito, anonimo, di pari influenza o garantito. Commissioni, saldi, stake, bond, hardware, banda, dati, disponibilità, competenze, code di attivazione e scadenze sono condizioni operative o del protocollo, non allowlist di identità. Servizi RPC, frontend, builder, relay, staking pool, sequencer, bridge, oracoli, amministratori di contratti e governance possono ancora creare barriere pratiche o esplicite.

Come funziona

  1. Fissare chain, rete, fork, deployment, versione, attore e azione. Costruire una matrice dei permessi per lettura, invio di transazioni, validazione locale, peer discovery, proposta di blocchi, staking o mining, prova o contestazione, distribuzione di codice e governance degli upgrade.
  2. Verificare percorso di lettura e validazione. Distinguere client full o light da RPC o indexer, stato corrente da storico d’archivio e disponibilità del protocollo da conservazione, autenticazione, rate limit e privacy del provider.
  3. Tracciare l’accesso della transazione da firma, fondi, nonce, gas e massimali delle commissioni fino ad ammissione locale, relay, selezione di builder o proposer, inclusione, esecuzione, fork choice, giustificazione e finalità. Validità o conferma di un RPC non garantiscono alcuno stato successivo.
  4. Separare gestione del nodo e influenza sul consenso. Mappare client di esecuzione e consenso, sincronizzazione, storage, banda, peer discovery e resistenza all’eclipse; quindi mappare lavoro, stake, attivazione, chiavi, disponibilità e condizioni di slashing specifiche per produrre blocchi.
  5. Misurare la concentrazione pratica fra pool di mining o staking, operatori, client, cloud, RPC, builder, relay e percorsi privati di order flow. La resistenza Sybil lega l’influenza a una risorsa scarsa; non impedisce di creare identità di rete a basso costo.
  6. Verificare separatamente ogni applicazione e dipendenza di scalabilità. La distribuzione permissionless di contratti non elimina owner, proxy, ruoli, pause o allowlist. Prove, contestazioni, sequencer, data availability, bridge e oracoli possono avere bond, finestre, chiavi o attori autorizzati.
  7. Mappare governance di protocollo, client e applicazione, poteri d’emergenza e adozione degli upgrade. Monitorare inclusione, finalità, concentrazione, guasti di accesso e perdita di privacy; mantenere percorsi self-hosted o diversificati quando pratico, senza dichiararli gratuiti o immuni alla censura.

Usare la matrice dei permessi, non un’etichetta binaria. Una rete può esporre stato pubblico e accettare transazioni firmate limitando la produzione di blocchi; un layer base permissionless può ospitare un’applicazione con allowlist e amministratore degli upgrade. Al contrario, una rete permissioned può pubblicare dati verificabili senza aprire adesione o produzione.

Pubblico non significa privato. Gli indirizzi sono pseudonimi, mentre ledger, query RPC, connessioni peer, IP, tempistiche e percorsi dei fondi possono collegare le attività. La validazione open source non crea accordo istantaneo: accettazione locale, propagazione, inclusione, esecuzione riuscita, fork choice canonico e finalità restano distinti.

Esempi

  • L’accesso alle transazioni ha comunque una barriera di commissione. Per gasUsed = 21,000, baseFee = 20 gwei, priorityFee = 2 gwei e maxFee = 30 gwei, il prezzo effettivo è min(30, 20 + 2) = 22 gwei. La commissione è 21,000 * 22 = 462,000 gwei = 0.000462 ETH. A 3,000 USD/ETH, equivale a 1.386 USD. Non serve approvazione dell’identità, ma fondi e ammissione locale contano.
  • Validare non consente di proporre blocchi a richiesta. In un modello proporzionale didattico con 3,200 ETH di stake effettivo attivo, un operatore con 64 ETH ha quota 64 / 3,200 = 2%. In 10,000 slots, le proposte attese sono 10,000 * 2% = 200; un full node senza validator attivato ha peso di proposta 0. Selezione e ricompense reali seguono il protocollo implementato.
  • Diversi URL possono condividere un dominio di guasto. Un frontend elenca 4 RPC URLs, ma 3 appartengono a un operatore e 1 è indipendente. Le quote sono 75% e 25%; l’indice Herfindahl-Hirschman è 0.75^2 + 0.25^2 = 0.625 = 6,250. L’accesso al protocollo può essere aperto mentre l’ingresso applicativo è concentrato.
  • Le identità Sybil non creano peso di consenso gratis. Creare 1,000 P2P identities può essere economico. Attivare 1,000 Ethereum validator keys al minimo indicato di 32 ETH ciascuna richiede 1,000 * 32 = 32,000 ETH, prima di code, hardware e operatività. Il numero di nodi non sostituisce peso dello stake o controllo indipendente.

Rischi

  • Applicare una sola etichetta permissionless a ogni azione.
  • Chain, rete, fork, deployment o regole errati.
  • Autenticazione, rate limit, censura, guasto o stato obsoleto dell’RPC.
  • Gatekeeping di frontend, dominio, wallet, app store o area geografica.
  • Policy locale del mempool rifiuta o espelle una transazione valida.
  • Massimale della commissione, saldo, nonce, gas o calldata bloccano l’invio.
  • Censura, potere di ordinamento e MEV di builder o proposer.
  • Concentrazione o guasto di relay, builder o order flow privato.
  • Barriere di capitale, attivazione, hardware e operatività per validator.
  • Concentrazione di pool di mining o staking, custode e operatore.
  • Monocultura dei client e bug correlati.
  • Barriere di storage, banda, sincronizzazione, storico e accesso ai dati.
  • Bootnode, DNS, NAT, peer scoring, eclipse, Sybil e DoS di risorse.
  • Deanonimizzazione tramite ledger, RPC, IP, tempistiche, fondi e grafo.
  • Controlli di owner, proxy, ruolo, pausa o allowlist del contratto.
  • Dipendenze da oracolo, sequencer, bridge, data availability o multisig.
  • Guasto di bond, finestra, dati, calcolo o permesso di prova o contestazione.
  • Confondere accettazione, propagazione, inclusione, validità e finalità.
  • Mescolare governance del protocollo, adozione dei client e governance applicativa.
  • Restrizioni legali, geografiche, ISP, cloud e di fornitura hardware.

Idee errate comuni

  • Permissionless significa gratuito, immediato e inclusione garantita. Elimina una specifica approvazione; restano vincoli economici, tecnici e di ordinamento.
  • Chi può gestire un nodo può proporre blocchi a volontà. Validazione indipendente e selezione dell’autore nel consenso sono ruoli separati.
  • Idoneità significa partecipazione facile e pari influenza. Costi delle risorse e influenza ponderata possono differire nettamente.
  • Pubblico o pseudonimo significa privato o anonimo. Metadati onchain e infrastrutturali possono identificare schemi e attori.
  • Un layer base permissionless rende permissionless ogni applicazione. Contratti, rollup, bridge, frontend e governance mantengono controlli propri.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...