Blockchain: Permissionless vs Permissioned
A partire dall’idea innovativa documentata nel whitepaper “Bitcoin: A Peer-to-Peer Electronic Cash System” (2008) del sì celeberrimo ma fisicamente ignoto Satoshi Nakamoto, la Blockchain si è sviluppata negli anni come un paradigma tecnologico applicabile in contesti non più esclusivamente correlati alle criptovalute. Se Bitcoin ne è stata la prima reale declinazione su larga scala, ad oggi se ne ritrova ampio margine di crescita nel contesto degli Smart Contracts/Chaincode, della notarizzazione dei processi, della diffusione di una cultura informativa digitale che sta virando con sempre maggior decisione su concetti innovativi come la decentralizzazione e distribuzione del consenso.
Due delle più diffuse e mature tecnologie Blockchain sono Ethereum e Hyperledger, e spesso per semplificarne i tratti essenziali e per agevolare la scelta su quale delle due preferire per il proprio modello, si è soliti focalizzare la distinzione in termini di <open + public + Permissionless (Ethereum)>, piuttosto che <closed + private + Permissioned (Hyperledger)>.
Possession e Ownership
Premessa doverosa è comprendere la distinzione di base che vi è tra possession e ownership, e come essa si applichi al contesto Blockchain: nel caso del primo termine, traducibile in italiano come “possesso”, si fa riferimento a un aspetto correlato al controllo fisico di un oggetto o di una entità, per cui il possessore ha più diritto di qualunque altro di reclamarne la proprietà. Nel caso della ownership, traducibile appunto in italiano come “proprietà”, il riferimento è all’acquisizione (o concessione) di diritti nei confronti di qualunque altra entità di utilizzare, disporne, distruggerlo, secondo una scala di possesso definita/indefinita su base temporale.
Come si declini tale concetto – applicato al paradigma Blockchain – anche in termini prettamente legali è tutt’ora materia di studio di (poche e selezionate) figure specialistiche in giurisprudenza, ma se rapportiamo il tutto nel contesto di una rete decentralizzata basata sul consenso distribuito è senza dubbio corretto affermare che il concetto di ownership sia preponderante rispetto a quello di possession: con tale termine si definisce nel paradigma stesso l’immutabilità della proprietà, se non fino a quando l’effettivo proprietario non verifichi una modifica alla ownership stessa. Il mondo degli NFT (non-fungible tokens), spesso luogo di fraintendimenti e banalizzazioni concettuali proprio causati da una certa complessità della basi teoriche su cui si fonda, propone un’ottima concretizzazione del concetto, codificando la proprietà nella Blockchain come un record (crittografato) e riferito a un oggetto dotato di una qualche caratteristica unica.
In un contesto Blockchain, la semantica della ownership può assumere particolarità specifiche a seconda della tipologia di rete che è stata realizzata, sulla base di criteri di accesso, visibilità, restrizione, validazione del consenso.
Permissionless vs Permissioned
Alla base, la distinzione sottesa dai due termini è correlata al modo con cui la rete viene realizzata by design: Permissionless implica la partecipazione aperta, Permissioned implica la restrizione della partecipazione ad alcuni partecipanti selezionati in base a determinati criteri. L’ambito di applicabilità dell’apertura al mondo piuttosto che di una selettiva (elitaria) restrizione è correlato all’interazione con la rete Blockchain e in particolare alla partecipazione al processo di validazione del consenso.
Public Permissionless vs Public Permissioned vs Private Permissionless vs Private Permissioned
Tradizionalmente, le reti Blockchain sono suddivise in Permissionless e Permissioned, come esplicitato nel paragrafo precedente, ma le recenti declinazioni del paradigma in termini di nuove tecnologie e particolarità nell’ambito degli Smart Contracts, hanno richiesto un ulteriore livello di raffinamento nella definizione della tassonomia di una rete.
Ecco, dunque, l’introduzione di due ulteriori discriminanti, public e private, qualificatori che in verità sono già ben noti ad analisti e sviluppatori software, seppur secondo semantiche differente: è proprio su una presunta assonanza di significato che può nascere una errata interpretazione. Proviamo a chiarire.
In una Blockchain pubblica, chiunque è libero di unirsi e partecipare alle attività principali della rete, operando in base a uno schema incentivante che incoraggia i nuovi partecipanti a aderire e mantenere agile la rete. Le Blockchain pubbliche offrono una soluzione particolarmente efficace dal punto di vista di una architettura veramente decentralizzata, democratizzata e priva di autorità. Non esistono entità con autorità sul sistema complessivo.
Una Blockchain privata consente solo l’ingresso selezionato di partecipanti verificati, ovvero che abbiano passato un predeterminato processo di controllo basato su algoritmica specifica; l’operatore di rete (in altri contesti, l’admin) ha il diritto di convalidare, sovrascrivere, modificare o eliminare le entità attestate sulla rete. E dunque presenta almeno una autorità centrale dotata di alto livello di privilegio.
La distinzione principale tra Blockchain pubbliche e private consiste nel controllo di chi è autorizzato a partecipare alla rete: le reti private eseguono un protocollo di consenso che decide i diritti di mining e le ricompense e mantengono il registro condiviso (distribuited ledger). Una Blockchain privata dunque non è realmente decentralizzata ed è rappresentabile come un registro distribuito che opera nello stesso modo di un database chiuso e sicuro, basato by design su tecniche di crittografia.
Ora: che senso può avere dunque parlare di Public Permissioned o Private Permissionless Blockchain? I qualificatori sembrerebbero in antitesi! La chiave di lettura di tali tipologie di reti, ad oggi in rapida diffusione, è da ricercarsi nella necessità di colmare la necessità di reti che posseggano caratteristiche derivate da entrambe le accezioni, Permissioned e Permissionless. Una soluzione possibile è rintracciabile nelle Consortium Blockchain (dette anche “Federated” o “Consorzi”), ottimali in contesti in cui è necessaria una collaborazione a livello dell’intera organizzazione, con una forte richiesta di scalabilità architetturale e sicurezza.
Le Public Permissioned sono di fatto una particolarità dei cosiddetti Consorzi: consentono a chiunque di unirsi alla rete autorizzata previa un’adeguata verifica della propria identità, nonché l’assegnazione di autorizzazioni selezionate e designate per eseguire esclusivamente determinate attività sulla rete. Ad esempio, Ripple, una delle più grandi criptovalute diffuse al 2022, supporta proprio i ruoli basati sulle autorizzazioni per i partecipanti.
Al contrario, una Private Permissionless Blockchain rappresenta una particolarità che recentemente si sta diffondendo come ottimale per applicazioni di tipo Smart Contracts: in modo simile alle reti Public Permissionless, chiunque può partecipare alla costruzione di un nodo in una rete Private Permissionless. Tuttavia, a differenza della Blockchain pubblica, gli altri nodi ne riconosceranno l’esistenza ma non condivideranno alcun dato, in coerenza con la natura di privata della rete. Gli Smart art Contracts su queste reti private non solo definiscono chi è autorizzato ad eseguire azioni contrattuali, ma anche chi è autorizzato a leggere il contratto e tutti i dati relativi. Per ottenere ciò, le soluzioni Private Permissionless non creano un’unica catena condivisa da tutti, ma ogni istanza di un contratto intelligente ha la sua catena ad hoc. In altre parole: distribuzione di uno Smart Contract su una rete Private Permissionless crea automaticamente una catena (laterale) privata associata a quel contratto.
Questa ultima accezione è senza dubbio l’evoluzione più significativa del paradigma Blockchain, soprattutto se si rapporta il tutto a tematiche prettamente giuridiche: in che modo uno Smart Contract basato su Private Permissionless può riflettere 1:1 la contrattualistica attuale?
The bottom line
Basare la scelta della tipologia di Blockchain da realizzare sulla relativamente semplice distinzione tra pubblica o privata ha rappresentato, per diversi anni, il criterio preponderante durante la fase di analisi e di progettazione architetturale astratta del modello di sviluppo.
Le ampie possibilità offerte dalla tecnologia di ambienti come HyperLedger, soprattutto se correlate alla diffusione degli applicativi di Smart Contracts, hanno portato gli analisti a perfezionare la tassonomia di Blockchain di tipo Permissioned: esse sono infatti in grado di offrire un buon compromesso tra la rigidità paradigmatica della Blockchain stessa e le varie necessità applicative, configurare un ambiente sicuro, perimetrato e accessibile anche da entità esterne alla Blockchain stessa.
Articolo a cura di Igor Serraino
Igor Serraino è professionista IT.
Opera come analista infrastrutturale e di Open Innovation nel contesto di Impresa 4.0 fin dal 2017, in qualità di Technology Expert per una importante società di settore attiva in ambiti aziendali eterogenei e sfidanti.
Il suo portfolio professionale senior-level si consolida attraverso una decennale esperienza da analista e sviluppatore hard-skills in ambienti Java-based, con particolare riferimento alla coprogettazione e sviluppo di applicativi per la gestione finanziaria commercializzati nel mondo della Pubblica Amministrazione.
Ha all’attivo numerose attività di formazione aziendale, workshops e pubblicazioni nei contesti di Cyber Security (GDPR e ISO27001), Legal-Tech, BlockChain Architect.
