Permissionless e permissioned non significano automaticamente decentralizzata e centralizzata. Ecco le differenze davvero rilevanti, sul piano tecnico, operativo e regolamentare.
Quando si cerca di capire cos’è una blockchain e quale sia il suo significato nei contesti finanziari, una delle distinzioni più importanti riguarda il modello di accesso alla rete: blockchain permissioned e permissionless.
Negli ultimi anni, nel mercato delle soluzioni DLT e della tecnologia blockchain, questa distinzione è diventata sempre più rilevante. Non solo per chi lavora su crypto-asset, smart contract o applicazioni decentralizzate, ma anche per banche, imprese, infrastrutture di mercato e operatori che guardano alla tokenizzazione degli strumenti finanziari.
La semplificazione più comune è anche la meno utile: da una parte la blockchain “aperta”, pubblica e decentralizzata; dall’altra quella “chiusa”, privata e quindi, per definizione, più centralizzata.
In realtà, la differenza tra permissioned vs permissionless blockchain è più profonda. Riguarda chi può accedere alla rete, chi può validare le transazioni, come viene gestita la governance, quale livello di privacy è possibile garantire, come funziona il consenso e quali controlli possono essere integrati nell’infrastruttura.
E soprattutto: permissioned non significa automaticamente centralizzata, così come permissionless non significa automaticamente decentralizzata.
Per capirci: una blockchain permissionless può essere aperta all’ingresso ma risultare, di fatto, concentrata in pochi operatori rilevanti, per esempio sul piano della validazione, del software, dell’infrastruttura o della governance del protocollo. Al contrario, una blockchain permissioned può essere distribuita tra più organizzazioni indipendenti, con nodi replicati, ruoli definiti, regole di accesso formalizzate e responsabilità chiaramente assegnate.
Questa distinzione è particolarmente importante quando si parla di tokenizzazione, di mercati privati e di strumenti finanziari digitali. Per capire meglio il rapporto tra l’infrastruttura blockchain e la rappresentazione digitale dell’asset, può essere utile leggere anche il nostro approfondimento su cosa sono i token e quali tipologie esistono.
La distinzione utile, quindi, non è ideologica. È architetturale. E riguarda almeno sei livelli: chi può entrare, chi può validare, chi vede cosa, chi aggiorna le regole, come viene finanziata la sicurezza della rete e chi risponde, anche legalmente, per i guasti o le eccezioni operative.
Una blockchain è un registro digitale condiviso, aggiornato secondo regole di consenso e progettato per rendere verificabili le informazioni registrate. A seconda del modello scelto, però, questa infrastruttura può funzionare in modi molto diversi.
La distinzione tra blockchain permissioned e blockchain permissionless riguarda soprattutto il modo in cui una rete gestisce l'accesso, la validazione e la governance.
In una blockchain permissionless, la partecipazione alla rete è aperta. In linea di principio, chiunque può interagire con il protocollo, inviare transazioni, eseguire un nodo o partecipare al consenso, a seconda delle regole specifiche della rete.
In una blockchain permissioned, invece, alcune funzioni sono riservate a soggetti autorizzati. L’accesso alla rete, la validazione delle transazioni, la visibilità dei dati o la possibilità di modificare determinate regole possono dipendere da policy, ruoli e permessi definiti in anticipo.
È proprio qui che nasce la differenza più importante: una blockchain permissionless tende a massimizzare l'apertura e l'accessibilità; una blockchain permissioned tende a massimizzare il controllo, l'identificabilità e la governance operativa.
Quando si parla di blockchain pubbliche e private, spesso si tende a sovrapporre questa distinzione a quella tra permissionless e permissioned. In realtà, i due concetti non coincidono perfettamente.
Una blockchain pubblica è una rete in cui il ledger è generalmente accessibile e verificabile da un numero ampio di partecipanti. Molte blockchain pubbliche sono anche permissionless, perché consentono a chiunque di interagire con la rete senza previa autorizzazione.
Una blockchain privata, invece, è normalmente progettata per un perimetro più ristretto: imprese, consorzi, istituzioni o gruppi di soggetti identificati. In molti casi è anche permissioned, perché l’accesso, la validazione e la visibilità dei dati sono regolati da policy specifiche.
Ma la distinzione non è sempre binaria. Esistono blockchain pubbliche con controlli applicativi molto rigorosi, così come reti permissioned distribuite tra molte organizzazioni indipendenti.
Per questo, quando si confrontano le blockchain permissioned e permissionless, non basta chiedersi se una rete sia pubblica o privata. Bisogna capire come sono distribuiti l'accesso, il consenso, la governance, la privacy e le responsabilità operative.
Una blockchain permissionless è una rete in cui non è necessaria un’autorizzazione preventiva per partecipare ad alcune funzioni fondamentali del sistema. A seconda del protocollo, questo può significare leggere il ledger, inviare transazioni, eseguire un nodo o partecipare ai meccanismi di consenso.
Questo modello è stato pensato per funzionare in ambienti aperti, dove i partecipanti non sono necessariamente noti o affidabili tra loro. Di conseguenza, una blockchain permissionless deve difendersi da comportamenti opportunistici senza poter contare sull’identità giuridica dei partecipanti come principale meccanismo di controllo.
È qui che entrano in gioco meccanismi di consenso come Proof of Work e Proof of Stake.
Bitcoin è l’esempio più noto di una blockchain permissionless basata su Proof of Work.
In questo modello, le transazioni vengono aggregate in blocchi e i miner competono per aggiungerli alla catena. La catena considerata valida è quella con il lavoro computazionale cumulato maggiore.
La finalità delle transazioni è probabilistica: più conferme si accumulano, più diventa costoso riscrivere la storia delle transazioni.
Il punto centrale è che la fiducia non viene affidata a un membro noto della rete, ma a una combinazione di crittografia, incentivo economico e costo energetico.
Ethereum, nel suo assetto attuale, utilizza invece un modello Proof of Stake.
In questo caso, i validatori mettono in staking una quantità di ETH, attestano i blocchi e partecipano a un meccanismo di finalizzazione basato su supermaggioranze. Il comportamento scorretto può essere penalizzato tramite lo slashing, ossia la perdita di una parte dello stake.
Rispetto al Proof of Work, il Proof of Stake riduce il consumo energetico e sostituisce il costo computazionale con un costo economico. La sicurezza della rete dipende quindi dalla quantità di capitale messo a garanzia e dagli incentivi che rendono sconveniente manipolare il sistema.
Le blockchain permissionless sono particolarmente efficaci quando l’obiettivo è creare infrastrutture aperte, accessibili e interoperabili.
I principali vantaggi sono:
accesso aperto;
maggiore neutralità dell’infrastruttura;
possibilità di partecipazione globale;
forte composability con applicazioni e protocolli esistenti;
ampia verificabilità pubblica;
integrazione naturale con wallet, stablecoin, smart contract e applicazioni decentralizzate.
Il loro punto di forza è proprio l’apertura. Chi sviluppa un’applicazione può costruire su un’infrastruttura già esistente, interagire con altri protocolli e beneficiare di network effects a livello globale.
I limiti riguardano soprattutto la governance, la privacy, i costi, le finalità e la compliance.
In una rete aperta, infatti, la sicurezza deve essere prodotta attraverso incentivi economici e meccanismi di consenso capaci di funzionare tra soggetti sconosciuti. Questo può rendere il sistema più costoso, più complesso e meno prevedibile rispetto a una rete con partecipanti identificati.
Inoltre, nei contesti regolamentati, molti controlli, KYC, AML, restrizioni ai trasferimenti, identificazione degli investitori, gestione degli errori o delle operazioni non conformi, devono essere implementati sulla blockchain, a livello applicativo.
Una blockchain permissionless, quindi, può essere molto potente come infrastruttura aperta. Ma non sempre è sufficiente, da sola, per gestire asset regolati, dati sensibili o processi finanziari complessi.
Una blockchain permissioned introduce un livello di controllo degli accessi.
Questo non significa necessariamente che la rete abbia un solo proprietario o che il sistema sia chiuso in modo assoluto. Significa piuttosto che alcune funzioni, come l’accesso, la scrittura, la validazione, la lettura di determinati dati, l’esecuzione di smart contract, la modifica delle policy e l’onboarding di nuovi partecipanti, sono riservate a soggetti identificati e autorizzati.
In questo modello, la sicurezza non deriva solo dalla crittografia e dal consenso, ma anche da:
identità note;
contratti;
policy di governance;
accountability organizzativa;
responsabilità legale esplicita tra i membri del network.
È il caso tipico delle reti enterprise, dei consorzi istituzionali e dei contesti regolamentati.
Hyperledger Fabric è uno degli esempi più noti di blockchain permissioned.
I partecipanti sono autenticati tramite sistemi di membership, le transazioni vengono approvate secondo policy che stabiliscono quali organizzazioni debbano validarle e un ordering service si occupa di ordinarle e impacchettarle in blocchi.
Il risultato è una struttura in cui identità, approvazione, ordering e commit sono esplicitamente separati.
Questo tipo di architettura è particolarmente utile quando il problema non è “come ottengo consenso tra sconosciuti in un ambiente aperto?”, ma “come coordino in modo affidabile, auditabile e condiviso soggetti conosciuti che non vogliono dipendere da un unico database controllato da uno solo?”.
È anche una delle ragioni per cui le blockchain permissioned sono spesso utilizzate in ambito enterprise, finanziario e istituzionale.
Le reti permissioned possono adottare modelli di consenso diversi rispetto alle reti permissionless.
In alcuni casi si utilizzano modelli Proof of Authority, in cui i validatori sono soggetti autorizzati e riconosciuti. In altri casi si usano protocolli BFT o CFT, progettati per raggiungere il consenso tra partecipanti noti, anche in presenza di errori o comportamenti anomali.
Il vantaggio principale è la prevedibilità operativa. Quando i validatori sono identificati e il perimetro della rete è controllato, il consenso può essere più rapido, più efficiente e più adatto a processi che richiedono finalità forte.
Questo è particolarmente rilevante nei mercati finanziari, dove non basta registrare una transazione: serve sapere quando tale transazione può essere considerata definitiva, opponibile e operativamente affidabile.
Le blockchain permissioned sono particolarmente efficaci quando il problema principale non è consentire a chiunque di partecipare, ma coordinare soggetti identificati in modo sicuro, tracciabile e verificabile.
I principali vantaggi sono:
maggiore controllo sugli accessi;
identità dei partecipanti nota o verificabile;
finalità transazionale più prevedibile;
governance più esplicita;
migliore gestione della privacy;
maggiore compatibilità con contesti regolamentati;
integrazione più semplice con processi enterprise, legali e di compliance.
In questi casi, la blockchain non serve a eliminare ogni forma di governance. Serve piuttosto a rendere la governance più tracciabile, automatizzabile e condivisa tra più soggetti.
Il limite principale è che l’apertura della rete è più ridotta.
Una blockchain permissioned può essere molto efficiente e ben distribuita, ma il suo grado effettivo di decentralizzazione dipende da come vengono gestiti i nodi, le policy, l'onboarding e la governance.
Se questi elementi restano concentrati in pochi soggetti, la rete rischia di essere distribuita solo a livello tecnico, e non davvero sul piano del potere operativo.
Per questo è importante evitare un altro equivoco: una blockchain permissioned non è automaticamente più affidabile, più sicura o più adatta a ogni caso d’uso. Lo diventa solo se la sua architettura è coerente con il problema da risolvere.
Uno dei falsi miti più diffusi è che una blockchain permissioned sia, per definizione, centralizzata.
Non è necessariamente così.
Una rete permissioned può essere organizzata come forma di sovranità condivisa tra soggetti noti. È il caso di infrastrutture in cui più istituzioni controllano nodi distinti, condividono il consenso, partecipano alle modifiche di governance e operano su una base contrattuale o regolamentare comune.
In questi casi, il punto non è l’assenza totale di controllo. Il punto è la distribuzione del controllo tra soggetti identificati.
Tuttavia, serve una precisazione importante: anche una permissioned può essere decentralizzata solo nominalmente se:
l’onboarding resta in mano a pochi sponsor;
le policy principali sono controllate da un centro unico;
l’infrastruttura cloud è fortemente concentrata;
l’evoluzione tecnica dipende da pochi attori chiave.
Per questo è più corretto parlare di governance distribuita, di federalizzazione controllata o di sovranità condivisa, a seconda dei casi.
Allo stesso modo, una blockchain permissionless non è automaticamente decentralizzata in senso stretto.
L’accesso aperto riduce le barriere all’ingresso, ma non elimina le dinamiche di concentrazione. Il potere può concentrarsi in mining pool, provider di staking, software client dominanti, infrastrutture cloud, builder, relay, custodian, issuer o layer applicativi.
La decentralizzazione, quindi, non è una proprietà binaria. Va letta su più assi:
accesso alla rete;
distribuzione del consenso;
governance degli upgrade;
dipendenza da infrastrutture critiche;
concentrazione economica degli incentivi;
controllo degli access point applicativi.
Ecco perché la domanda corretta non è solo “questa blockchain è aperta?”, ma “come si distribuisce davvero il potere all'interno di questa infrastruttura?”.
Le differenze tra blockchain permissioned e permissionless possono essere lette su diversi livelli.
In una blockchain permissionless, l’accesso è aperto e non richiede autorizzazioni preventive.
In una blockchain permissioned, invece, l’accesso è regolato da policy. Solo soggetti autorizzati possono svolgere determinate funzioni.
Nelle reti permissionless, l’identità legale dei partecipanti non è di norma una precondizione del layer base. Ciò che conta è la validità crittografica delle chiavi e il rispetto delle regole del protocollo.
Nelle reti permissioned, l’identità è parte integrante dell’architettura. Questo rende più semplice definire ruoli, diritti, responsabilità, audit trail e controlli di accesso.
Le reti permissionless devono resistere agli attacchi Sybil in ambienti aperti. Per questo adottano meccanismi come il Proof of Work o il Proof of Stake.
Le reti permissioned, potendo contare su validatori noti, possono usare modelli BFT, CFT o Proof of Authority più leggeri e prevedibili.
Nelle reti permissionless, la finalità può essere probabilistica o economica, a seconda del protocollo.
Nelle reti permissioned, la finalità è spesso più rapida o più prevedibile, perché il consenso avviene tra partecipanti identificati.
Per i workflow regolati, post-trade, di settlement e di gestione di strumenti finanziari digitali, questa differenza pesa molto.
Le blockchain permissionless tendono ad avere ledger ampiamente osservabili. Questo favorisce trasparenza e verificabilità pubblica, ma può creare problemi sulla confidenzialità, sulla data minimization e sulla protezione dei dati.
Le blockchain permissioned possono integrare la privacy in modo più granulare, attraverso canali, ruoli, permessi e architetture off-ledger.
Attenzione, però: una blockchain permissioned non è automaticamente conforme al GDPR o ad altri requisiti di protezione dei dati. Serve comunque progettare correttamente ruoli, dati, accessi e storage.
Nelle permissionless, la governance è spesso più aperta ma anche più complessa, perché dipende da comunità, sviluppatori, client software, operatori economici e dinamiche di adozione.
Nelle permissioned, la governance è normalmente più esplicita: chi può cambiare le regole, approvare modifiche, ammettere membri o intervenire sul sistema è stabilito da policy o accordi di consorzio.
Nelle permissionless, la sicurezza è finanziata principalmente attraverso incentivi interni al protocollo: token issuance, transaction fees, staking rewards, slashing e penalità.
Nelle permissioned, gli incentivi sono più spesso esterni al protocollo: service fees, budget di governance, accordi contrattuali, interesse commerciale dei membri a mantenere operativa l’infrastruttura.
Questa differenza è importante perché mostra due modi diversi di produrre sicurezza: un mercato aperto della validazione, da un lato; un’infrastruttura condivisa con una governance economica esplicita, dall’altro.
La distinzione tra blockchain permissioned e permissionless diventa particolarmente rilevante quando si parla di smart contract e tokenizzazione degli strumenti finanziari.
In un contesto puramente crypto-native, la priorità può essere massimizzare l'apertura, la liquidità e la composability. Ma quando il token rappresenta un diritto, una quota, un’obbligazione o uno strumento finanziario digitale, entrano in gioco requisiti diversi:
identificazione degli investitori;
controlli sui trasferimenti;
diritti incorporati;
governance;
auditabilità;
compliance;
gestione del ciclo di vita dell’asset.
Qui la tecnologia blockchain non serve solo a registrare una transazione. Serve a rendere operativo un sistema di diritti, vincoli e responsabilità.
È per questo che, nei mercati regolamentati, la domanda non è solo “quale blockchain usare?”, ma quale infrastruttura consenta di combinare sicurezza, governance, privacy, interoperabilità e compliance.
In questo scenario, i modelli permissioned o ibridi risultano particolarmente rilevanti. Non perché siano “migliori” in assoluto, ma perché permettono di integrare controlli, identità e responsabilità in modo più coerente con le esigenze di strumenti finanziari digitali e mercati privati.
Per approfondire il tema della rappresentazione digitale degli asset, leggi anche il nostro articolo su cosa sono i token e quali tipologie esistono.
Nei contesti regolati, il problema non è solo registrare un trasferimento su DLT.
Il problema è poter dimostrare:
chi opera;
con quali permessi;
su quale infrastruttura;
con quali nodi;
con quale osservabilità;
con quale capacità di intervento in caso di errore, blocco, freeze o trasferimento non conforme.
Autorità e standard setter non ragionano più in termini semplici di “pubblico cattivo” e “privato buono”. La tecnologia non esonera da AML/CFT, investor protection, operational resilience, governance e data protection.
La differenza pratica è che le reti permissioned rendono più semplice costruire:
confini di responsabilità;
whitelisting;
auditabilità;
registered wallets;
controlli di trasferimento;
gestione di eccezioni operative.
Le reti permissionless, invece, possono operare in contesti regolati, soprattutto quando il layer applicativo incorpora tali controlli.
Ed è qui che sta uno dei messaggi più importanti dell’intero confronto: oggi la vera linea di divisione non è più soltanto tra blockchain pubblica e blockchain privata, ma tra sistemi che incorporano controlli istituzionali efficaci e sistemi che non li incorporano.
No.
Le blockchain pubbliche non sono necessariamente incompatibili con i contesti regolati. In diversi casi, asset digitali, stablecoin o strumenti tokenizzati vengono emessi o gestiti su infrastrutture pubbliche, pur con forti controlli a livello applicativo.
Questo significa che la chain può essere pubblica, ma l’accesso economico al token, il trasferimento, l’onboarding degli investitori o la gestione dei diritti possono essere disciplinati da regole aggiuntive.
Il punto, quindi, non è che le blockchain pubbliche siano inutilizzabili. Il punto è che, nei casi regolati, non vengono normalmente usate in forma “pura”: vengono affiancate da controlli applicativi, onboarding regolato, wallet registrati, restrizioni sui trasferimenti e meccanismi di gestione delle eccezioni.
In pratica, diventano sistemi ibridi.
Sempre più spesso, sì.
Molte organizzazioni vogliono i vantaggi delle blockchain permissioned:
identità note;
controlli;
privacy;
governance;
compatibilità regolamentare.
Ma non vogliono rinunciare del tutto ai vantaggi delle blockchain permissionless:
interoperabilità;
distribuzione;
liquidità;
accesso a ecosistemi più ampi;
composability.
È qui che entra in gioco il modello ibrido: infrastrutture permissioned per garantire controllo, compliance e governance; connessioni verso ambienti più aperti per abilitare interoperabilità, distribuzione e nuovi casi d’uso.
Questo è probabilmente il punto più interessante per chi guarda ai mercati privati e alle infrastrutture regolamentate: non la vittoria ideologica di un modello sull’altro, ma la loro ricombinazione architetturale.
La risposta corretta è meno spettacolare ma molto più utile: dipende dal problema che si vuole risolvere.
Se l’obiettivo primario è massimizzare:
network effects;
accesso globale;
composability;
integrazione con wallet, stablecoin e protocolli esistenti;
Allora la scelta naturale tende verso una rete permissionless.
Se invece l’obiettivo primario è:
condividere stato e workflow tra attori identificati;
avere policy esplicite;
gestire dati sensibili;
presidiare privacy e auditabilità;
garantire finalità forte;
integrare controlli regolatori e responsabilità operative;
allora una rete permissioned è spesso più adatta.
Per banche, market infrastructures, private markets e strumenti finanziari regolati, la soluzione oggi più robusta è spesso permissioned o ibrida.
Non perché la permissioned sia “migliore” in senso assoluto. Ma perché, in questi contesti, l’infrastruttura deve poter incorporare governance, responsabilità, controlli e continuità operativa.
In altre parole: la vera domanda non è quale blockchain sia più “autentica”.
La vera domanda è quale infrastruttura consenta a quel caso d’uso di funzionare davvero.
E quando si entra nei mercati privati, nella gestione di strumenti finanziari, nella governance societaria e nei perimetri regolamentati, questo cambia tutto.
Una blockchain permissionless consente la partecipazione senza autorizzazione preventiva, mentre una blockchain permissioned limita l'accesso, la validazione o la visibilità dei dati a soggetti identificati e autorizzati.
No. Una blockchain permissioned può essere distribuita tra più organizzazioni indipendenti. Tuttavia, il suo grado reale di decentralizzazione dipende da come sono gestiti i nodi, la governance, l'onboarding e il controllo delle policy.
No. Una blockchain permissionless è aperta all’accesso, ma il potere può comunque concentrarsi in mining pool, provider di staking, software client, infrastrutture cloud, builder o altri attori rilevanti.
Nei mercati regolamentati sono spesso più adatte le architetture permissioned o ibride, perché consentono di integrare l'identificazione degli attori, i controlli di accesso, l'auditabilità, la privacy e la compliance.
Gli smart contract permettono di automatizzare regole, vincoli e processi collegati a un asset digitale. Nella tokenizzazione degli strumenti finanziari, possono supportare trasferimenti, diritti, restrizioni e gestione del ciclo di vita dello strumento.