La reinterpretazione dei diritti e principi progettuali in

Alla luce di quanto detto, occorre reinterpretare i diritti proprietari e i principi progettuali elaborati da Ostrom per una gestione efficiente della risorsa, in ragione delle specificità dell’ecosistema DLT. Con riferimento ai diritti, si consideri quanto segue (cfr. tab 5).

(1) L’accesso e lo sfruttamento della risorsa coincidono con la possibilità di beneficiare di quell’utilità offerta dal sistema blockchain stesso e sono in generale collegati nell’ambito di una organizzazione decentralizzata proprio alla disponibilità di token: l’accesso, infatti, avviene per il tramite dell’acquisto a titolo originario o derivato dei

token; lo sfruttamento si estrinseca nel potere di disposizione esclusiva

sui token nella propria disponibilità. Così, ad esempio, in Dash solo la titolarità dei token dà diritto a trasferirli o negoziarli su una sede di negoziazione. Similmente, nell’organizzazione TheDAO, solamente la detenzione di token dava diritto agli utili derivanti dalle attività di investimento coordinato nell’organizzazione. E all’interno di Colony, solo chi è titolare di token può dare alla luce una colonia per lo svolgimento dei più svariati compiti.

(2) L’esercizio dei diritti di management – inteso quale diritto di modificare le specifiche tecniche (e.g. la grandezza dei blocchi o le specifiche di crittografia) o economiche (e.g. le regole di emissione di nuovi token) del sistema – talvolta è collegato alla titolarità di token, talaltra avviene in via informale. Così, ad esempio in Dash chiunque assuma il ruolo di masternode può votare per decidere l’implementazione delle specifiche tecniche sistema.

(3) Il diritto di esclusione è invece difficilmente configurabile. Infatti, in ragione del fatto che le organizzazioni decentralizzate sono basate su protocolli open source e che l’utilità della risorsa è riconnessa alla titolarità dei token – i quali, tendenzialmente, sono liberamente acquistabili da chiunque – nessuno ha il potere di limitare l’accesso alla risorsa, al contempo conservandola così come tale.

(4) Quanto, infine, al diritto di alienazione, se al token sono collegati diritti di management, questi di regola traslano con il

Tesi soggetta a copyright. Non riproducibile, in tutto o in parte, se non con il consenso scritto dell’autore.

110

trasferimento del token. Laddove invece nel token non confluisca alcun diritto partecipativo non si configura alcun potere dispositivo. Tab. 5. Blockchain e diritti proprietari

Property rights Description

Accesso ^{diritto di accedere alle utilità derivanti dal sistema blokchain}

attraverso l’acquisto di token

Sfruttamento diritto di trasferire i token all’interno del sistema

Conduzione diritto di modificare le specifiche tecniche del sistema

Esclusione diritto di dar luogo a fork del sistema

Alienazione ^{diritto di trasferire diritti di conduzione attraverso} l’alienazione dei token

Passando all’analisi dei principi istituzionali, possono valere le seguenti considerazioni in relazione ad alcuni principi che appaiono particolarmente rilevanti (cfr, tab. 6).

(1) Il primo principio progettuale (Well-defined Boundaries), si ribadisce, impone l’esistenza di confini ben precisi in relazione a chi può beneficiare della risorsa e una ripartizione chiara dei diritti e dei privilegi dei membri del sistema. Trattandosi di sistemi aperti, è superfluo affermare che in questi casi chiunque possa prendere parte all’organizzazione. Tale aspetto – unitamente alla possibilità per chiunque di dar luogo a scissioni, di acquistare token e di partecipare alla gestione nei casi di sistemi di governance formali – parrebbe rendere l’organizzazione un organismo tendenzialmente fluido, in grado di espandersi e contrarsi in continuazione. Sicché tale regola dovrebbe reinterpretarsi nel senso dell’esistenza di precise indicazioni circa le modalità di acquisto dello status di membro, la ripartizione di ruoli interni al sistema, le modalità di trasferimento dei token e le condizioni in cui possa avvenire un fork.

(2) Il terzo principio progettuale (Collective Choice

Arrangements), che riguarda l’esistenza di meccanismi partecipativi in

relazione alla formulazione e adozione delle regole, risulta particolarmente problematico in tutti quei casi in cui non siano previsti meccanismi di governance on-chain. Infatti, la potenziale espansibilità senza limiti del network renderebbe di fatto impensabile una qualsiasi modalità di partecipazione alle scelte che non passi per un sistema di votazione e decisione interno al sistema. Tale principio deve pertanto reinterpretarsi nel senso della necessaria esistenza di

Tesi soggetta a copyright. Non riproducibile, in tutto o in parte, se non con il consenso scritto dell’autore.

111

meccanismi decisionali trasparenti, aperti e partecipati integrati nell’infrastruttura.

(3) Quarto, quinto e sesto principio possono trattarsi unitamente, attenendo alla fase dei controlli (monitoring), sanzionatoria (graduated sanctions) e contenziosa (conflict resolution mechanisms) della gestione del sistema. In breve, all’enforcement delle regole.

Sul punto, occorre notare come la retorica della riduzione dei costi di transazione, in forza dell’esistenza di un sistema informatico che sembra marginalizzare l’attività esecutiva discrezionale umana, raramente porti all’implementazione di controlli, sanzioni e meccanismi interni di risoluzione delle controversie ex post301. Eppure, come è stato correttamente osservato, l’enforcement automatico del contratto è controbilanciato dai costi della «inflessibilità» del codice di programmazione, che non consente, ad esempio, la previsione di clausole generali o di porre rimedio all’errore, nell’assenza di cooperazione della controparte transattiva302. Si pensi, ad esempio, a un soggetto che per errore invii a un indirizzo 10.000 Dash invece che 1000. In questo caso, la previsione di controlli e sanzioni risulterebbe necessaria onde evitare comportamenti opportunistici. In altri casi, invece, la necessità di controlli attiene alla natura dell’attività che per il tramite dell’organizzazione decentralizzata si intende svolgere. In Colony, ad esempio, lo svolgimento di un task all’interno dell’organizzazione di regola richiede la prestazione dell’opera professionale di una persona fisica, sulla cui bontà potrebbe insorgere un giorno una controversia. Allo stesso modo, in TheDAO, il contractor incaricato di svolgere un investimento potrebbe indebitamente sottrarre i token ricevuti, come

301 In via generale, è stato sottlineato come una caratteristica comune alle moderne tecnologie sia proprio l’eliminazione dell’enforcement ex post della regola, in forza dell’anticipazione ex ante dei controlli attraverso il loro inserimento all’interno dell’artefatto tecnologico stesso. Si veda, ad esempio, D. BURK, DNA Rules. Legal and Conceptual Implications of Biological “Lock-Out” Systems, in California Law Review, 2004, pp. 1553-1587.

302 Per un inquadramento, si veda J. SKLAROFF, Smart Contracts and the Cost of Inflexibility, in Prize Winning Papers, 2018. In via generale, basti pensare che è impossibile programmare nel codice di uno smart contract il concetto di “buona fede” contrattuale. Inoltre, l’irreversibilità delle transazioni in blockchain rende particolarmente arduo, nell’assenza di cooperazione della controparte, ripristinare lo status quo ante quando si verifica, ad esempio, un errore materiale nella digitazione dell’indirizzo cui inviare token. Infine, anche il rischio di perdere le chiavi del proprio wallet che consentono di disporre dei token costituisce un ulteriore costo.

Tesi soggetta a copyright. Non riproducibile, in tutto o in parte, se non con il consenso scritto dell’autore.

112

di fatto avvenuto nel 2017. In questi casi, da un lato, i controlli dovrebbero essere svolti da soggetti a ciò incaricati dalla collettività, secondo procedure trasparenti e tendenzialmente partecipate; dall’altro lato, in capo a tali soggetti dovrebbe essere configurata una responsabilità verso l’intera collettività per i servizi fiduciari svolti. La sanzione, infine, dovrebbe innanzitutto svolgere una funzione ripristinatoria, permettendo l’annullamento di transazioni già eseguite.

Tab. 6. Blockchain e principi progettuali

Design Principle Descrizione

1. Well-defined boundaries

Precise indicazioni circa le modalità di acquisto dello status di membro, la ripartizione di ruoli interni al sistema, le modalità di trasferimento dei token e le condizioni in cui possa avvenire un fork.

2. Proportionality between benefits and

costs

-

3. Collective Choice Arrangements

Esistenza di meccanismi decisionali trasparenti, aperti e partecipati integrati nell’infrastruttura e aventi a oggetto le specifiche del protocollo.

4. Monitoring

Esistenza di controlli costanti da parte di soggetti scelti con procedure partecipate dalla comunità stessa e nei confronti di questa responsabili per i servizi fiduciari svolti

5. Graduated sanctions ^{Possibilità di modificare una transazione registrata}

ripristinando lo status quo ante

6. Conflict resolution mechanisms

Esistenza di controlli terzi e imparziali da parte di soggetti scelti con procedure partecipate dalla comunità stessa e nei confronti di questa responsabili per i servizi fiduciari svolti

Tesi soggetta a copyright. Non riproducibile, in tutto o in parte, se non con il consenso scritto dell’autore.

113

Calando quanto detto nell’esame degli esempi di organizzazione menzionati, possono darsi i seguenti risultati (cfr. tab 7).

Tab. 7. Organizzazioni decentralizzate e principi progettuali

Rules Dash TheDAO 0x Colony Bitcoin

1. Regole di accesso e di trasferimento dei token chiare. Ruoli interni chiari. Nessuna regola sui fork. Regole di accesso e di trasferimento dei token chiare. Ruoli interni chiari. Nessuna regola sui fork. Regole di accesso e trasferimento dei token chiare. Ruoli interni chiari. Nessuna regola sui fork. Regole di accesso e trasferiment o dei token chiare. Regole di accesso e di trasferime nto chiare. Nessuna chiarezza sui ruoli interni. Nessuna regola sui fork. 2. - - - - - 3. Decidono i master-nodes e chiunque può diventarlo secondo meccanismi di voto integrati nel sistema Decide il solo team di sviluppo. Nessun meccanismo decisionale integrato nel sistema. Decide chi detiene protocol tokens Meccanismi decisionali basati sulla reputazione Decidono solo i core developers 4. No No No No No 5. No No No No No 6. No No No Yes No

Tesi soggetta a copyright. Non riproducibile, in tutto o in parte, se non con il consenso scritto dell’autore.

114

6. Organizzazione decentralizzata e questioni aperte. Il deficit di