---
title: "Blockchain permissionless"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Blockchain permissionless
> 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
- [Full node](/it/crypto/full-node/)
- [Rete peer-to-peer](/it/crypto/peer-to-peer-network/)
- [Resistenza alla censura](/it/crypto/censorship-resistance/)
## Fonti
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - National Institute of Standards and Technology (consultato il 2026-08-13)
- [Nodes and clients](https://ethereum.org/developers/docs/nodes-and-clients/) - Ethereum.org (consultato il 2026-08-13)
- [Networking layer](https://ethereum.org/developers/docs/networking-layer/) - Ethereum.org (consultato il 2026-08-13)
- [Transactions](https://ethereum.org/developers/docs/transactions/) - Ethereum.org (consultato il 2026-08-13)
- [Introduction to smart contracts](https://ethereum.org/developers/docs/smart-contracts/) - Ethereum.org (consultato il 2026-08-13)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (consultato il 2026-08-13)
- [Maximal extractable value (MEV)](https://ethereum.org/developers/docs/mev/) - Ethereum.org (consultato il 2026-08-13)
- [Introduction to Ethereum governance](https://ethereum.org/governance/) - Ethereum.org (consultato il 2026-08-13)
Source: https://wiki.fcontext.com/it/crypto/permissionless-blockchain/index.mdx