British Standard Institution: in consultazione le regole tecniche PAS 333 per gli smart contract

di Daria Alessi, avvocato e componente Blockchain Ladies e Massimiliano Nicotra, avvocato e senior partner di Qubit Law Firm, docente Università di Roma Tor Vergata

Premessa

Con la pubblicazione del documento “Publicly Available Specification (PAS) 333” che avvia una proposta di consultazione per la definizione di standard applicabili agli smart legal contract, la British Standards Institution (BSI) conferma il suo ruolo di impulso al processo di normazione in ambito di sviluppo e innovazione.

La  portata dell’iniziativa è maggiormente apprezzabile se si considera il contesto di riferimento. L’opportunità di individuare delle regole tecniche uniformi per la disciplina degli smart contract è, da tempo, avvertita e fortemente auspicata da più parti. Tuttavia, le ipotesi attuative formulate in materia – per lo più a livello dottrinale – non avevano fornito, fino a questo momento, soluzioni definitive per superare l’intrinseca difficoltà di integrazione tra le specificità dell’ambito giuridico e quelle dell’ambito tecnologico. Non può, dunque, che tributarsi merito a questa iniziativa che, ancora una volta, proviene da un’organizzazione leader nella standardizzazione a livello internazionale. Fondata nel 1901 e più antico ente normativo nazionale al mondo, la British Standards Institution, infatti, ha sempre svolto una funzione determinante, ben oltre i soli confini britannici, tanto da vantare membership nella Organizzazione mondiale per la normazione (ISO) e collaborazioni con le più importanti organizzazioni del settore (IEC, CEN, CENELEC ed ETSI). La copiosa produzione di standard, norme e best practice a sostegno dell’innovazione delle attività produttive nazionali ha reso la BSI punto di riferimento per i principali processi di standardizzazione di rilevanza internazionale. Tra questi, per esempio, il BS7799 (part 2) poi quasi interamente recepito nello standard ISO / IEC 27001, il più diffuso in ambito di Information Security Management System.

Il draft PAS 333, pur non potendosi definire un documento esaustivo per le ragioni che infra verranno precisate, può rappresentare un ottimo punto di partenza e di impulso per tutti gli altri enti europei e nazionali che devono affrontare la sfida di predisporre delle regole tecniche relativamente a queste tecnologie per favorirne ed incentivarne la diffusione.

 Scopo delle regole tecniche PAS 333

Come esposto all’interno del documento, l’obiettivo della PAS 333 è quello di enucleare una serie di caratteristiche e specifiche tecniche da porre alla base del processo di creazione degli smart contract. Il raggiungimento di tale scopo, infatti, è considerato essenziale, da un lato, per determinare la sincronica leggibilità dei suddetti contratti sia dall’uomo che dalle macchine e, dall’altro, per fornire una base tecnica e tecnologica uniforme per lo sviluppo di software dedicati. Da ciò discende, secondo quanto rilevato dal draft, l’ulteriore obiettivo di predisporre, in favore dei settori produttivi interessati, un quadro di riferimento all’interno del quale i contratti nuovi o esistenti possano essere digitalizzati e collegati a sistemi IT e servizi.

Gli standard, inoltre, sono ritenuti un passo fondamentale nella creazione di una rappresentazione comune di smart contract indipendente dalla tecnologia sottostante ed abbastanza flessibile da essere applicabile non solo alle DLT. La formalizzazione del processo di creazione degli smart contract, come descritto di seguito, è la risultante di tre modelli comuni:

• template grammar,
• template logic
• template model

La combinazione dei tre modelli è necessaria per la modifica, l’analisi e l’esecuzione degli smart contract.

Rimangono invece esclusi dagli standard, stante il carattere tecnico del documento, gli aspetti correlati ai requisiti di validità del contratto, i quali sono disciplinati dai rispettivi ordinamenti giuridici.

L’impostazione generale

Le regole tecniche emanate dalla BSI introducono la definizione di smart contract, stabilendo che lo stesso è un codice per computer, eseguito sui nodi di una DL (distributed ledger) o una blockchain, il quale aggiorna la DL in risposta ai dati in entrata (transazioni).

Da tale ampia categoria discendono quelli che sono definiti “Smart legal contract”, ossia accordi nativamente digitali tra le parti che creano obbligazioni giuridiche espressi in linguaggio naturale e supportati da uno schema logico che li rende computabili dai sistemi informatici su cui possono essere distribuiti.

Da questa definizione discende il processo individuato dalla BSI per la corretta implementazione degli smart contract.

Tale processo prevede la necessaria creazione di tre schemi:

• lo schema lessicale (template grammar) a livello di linguaggio naturale
• lo schema logico (template logic) relativo al software che lo implementa (il flowchart ed il codice vero e proprio dello smart contract)
• lo schema dei dati, ossia la definizione delle variabili, stati, input ed output del contratto.

Secondo le regole in esame, i tre schemi costituiscono, in una metafora architettonica, le fondamenta, lo scheletro ed i rivestimenti della costruzione, necessari tutti per la corretta implementazione di uno smart contract.

E’ importante chiarire, e lo specifichiamo soprattutto per chi non ha confidenza con i metodi di programmazione, che lo schema di smart contract a cui la BSI si riferisce è un “modello” di contratto, ossia un costrutto che ha la caratteristica di essere riutilizzabile più volte al fine di poter creare dei documenti contrattuali che disciplinano le singole situazioni specifiche. Ciò significa che ogni “smart legal contract” è in realtà un’istanza dello smart contract principale; in tal senso, uno smart contract (ossia lo schema generale) potrebbe essere relativo anche ad una singola clausola contrattuale (con la possibilità, quindi, di istanziare clausole diverse per comporre un contratto) oppure ad un intero contratto.

Lo schema lessicale

Per un giurista, questa è la parte più interessante dello smart contract, in quanto è la componente testuale, scritta in linguaggio naturale, spesso derivata da un contratto già esistente. Nello schema testuale sono inserite le variabili che sono definite nello schema dei dati – analizzato più avanti in questo scritto – in modo da poter essere poi valorizzati con i dati relativi allo specifico smart legal contract da porre in essere.

L’Allegato B degli standard proposti dalla BSI disciplinano nel dettaglio la costruzione di tale componente, la quale deve supportare le variabili definite nello schema dei dati. In particolare, lo schema lessicale provvede ad incorporare nello smart contract le variabili attraverso le “etichette” del linguaggio di marcatura scelto dalle parti, nel rispetto delle specifiche stabilite negli standard IETF BCP 47, o nei BS ISO 639, ISO 15924, e BS EN ISO 3166-1

Per comprendere il funzionamento di tale sistema è utile riportare un esempio. Ipotizziamo una clausola del genere:

Alpha S.p.A. e Beta S.p.A. concordano che, in caso di ritardo nel pagamento del prezzo di vendita rispetto al termine indicato al precedente art. 5 (fatta salva una franchigia di quindici giorni), Alpha S.p.A. dovrà corrispondere a Beta S.p.A., ai sensi e per gli effetti di cui all’art. 1382 c.c., una somma pari ad Euro 200,00 per ogni 1 giorno di ritardo, salvo comunque il diritto di Beta S.p.A. di richiedere il risarcimento del maggior danno eventualmente subito.

Le parti variabili di questa clausola sono state evidenziate in grassetto. In un’ipotetica definizione dello schema lessicale potrebbero essere rappresentate dalle seguenti variabili (che trovano poi una loro corrispondenza nello schema dei dati):

Alpha S.p.A. = compratore

Beta S.p.A. = venditore

quindici giorni = periodo_franchigia

Euro 200,00 = importo_penale

1 giorno = periodo_penale

Nello schema lessicale, pertanto, la clausola dello smart contract sarà così redatta:

[{compratore}] e [{venditore}] concordano che, in caso di ritardo nel pagamento del prezzo di vendita rispetto al termine indicato al precedente art. 5 (fatta salva una franchigia di [{periodo_franchigia}], [{compratore}] dovrà corrispondere a [{venditore}], ai sensi e per gli effetti di cui all’art. 1382 c.c., una somma pari ad [{importo_penale}]  per ogni [{periodo_penale}] di ritardo, salvo comunque il diritto di [{venditore}] di richiedere il risarcimento del maggior danno eventualmente subito.

Questa clausola verrà di volta in volta istanziata, ossia “riempita” dei dati relativi allo specifico contratto che regola le obbligazioni delle parti nel caso concreto. Per comprendere le potenzialità di questi sistemi basti riflettere sulla circostanza che tali dati potranno provenire dalle più svariati fonti, come ad esempio i sistemi gestionali interni dei contraenti, un sito di e-commerce, o un marketplace di servizi.

Lo schema dei dati

Chiarita con l’analisi dello schema lessicale l’importanza della definizione delle variabili che compongono lo smart contract, è opportuno esaminare brevemente quello che dovrebbe essere il contenuto dello schema dei dati, il vero “cuore” dello smart contract secondo il documento PAS 333 in esame.

Questo schema ha il compito di “definire” il set di dati che lo smart contract deve essere in grado di elaborare e si compone, a sua volta, di tre sotto-schemi:

1) quello degli eventi che determinano l’input e l’output dei dati;

2) quello relativo agli stati dello smart contract, relativo ai dati persistenti richiesti dal modello contrattuale (contatori, etc.);

3) quello relativo alle obbligazioni contenute nel contratto, in cui si definiscono appunto le variabili che abbiamo descritto precedentemente e che sono relative agli obblighi che il contratto impone alle parti, eventualmente correlati agli eventi indicati nei sotto-schemi 1) e 2).

Lo schema logico

Si tratta del vero e proprio codice informatico con cui è scritto lo smart contract, in cui sono inserite le funzioni e procedure per l’esecuzione delle clausole previste dalle parti, redatto in maniera da poter elaborare i dati stabiliti nell’apposito schema e le variabili individuate nello  schema lessicale.

Il documento della BSI precisa che dovrebbe poter essere utilizzato un qualsiasi linguaggio di programmazione, anche come combinazione di più linguaggi diversi, assicurando comunque l’esecuzione sicura del contratto. E’ inoltre previsto che lo sviluppatore del programma debba necessariamente valutare insieme ad un giurista come descrivere formalmente la logica di fondo del modello contrattuale affinché possa essere eseguita in modo inequivocabile da un computer. Tale analisi congiunta è volta, in particolar modo, alla valutazione degli input che devono essere ricevuti dallo smart contract, della conseguente esecuzione del codice in esso formalizzato e dei relativi output.

Il processo di implementazione

Secondo il documento pubblicato dalla BSI la realizzazione di uno smart contract deve seguire alcune specifiche fasi, ossia: a) la progettazione, quale analisi del testo contrattuale e della logica sottostante; b) l’implementazione, relativa alla costruzione degli schemi di cui abbiamo parlato nei paragrafi precedenti; c) una fase di test dello smart contract; d) la creazione di un’istanza dello smart contract, che genera quindi lo smart legal contract; e) l’accordo delle parti sullo stesso prima di porlo in esecuzione; f) la sottoscrizione tramite firma elettronica; g) il rilascio dello smart legal contract sulla piattaforma; h) l’integrazione con sistemi esterni (fonti di dati ed API); i) il monitoraggio dell’esecuzione dello smart legal contract; j) l’eventuale sua revisione, tramite aggiornamento del modello o sostituzione dell’istanza; k) la cessazione – intesa quale interruzione della sua esecuzione – in seguito all’accordo delle parti o in base a condizioni già predefinite ed inserite nello schema logico.

Le due fasi che, a chi scrive, appaiono di maggior interesse sono quella della sottoscrizione e rilascio del contratto e quella della sua eventuale revisione.

Per la prima ipotesi, le norme tecniche prevedono che lo smart legal contract debba essere sottoscritto con una firma elettronica, in base alla legge applicabile al contratto, secondo i criteri di individuazione della stessa esistenti nei vari ordinamenti. Ciò significa, ad esempio, che in Italia troverebbero applicazione le norme del regolamento (UE) n. 910/2014 (eIDAS), quelle del Codice dell’Amministrazione Digitale (D.l.vo n. 82/2005) nonchè la previsione di cui all’art. 8 ter della l. n. 12/2019.

Ulteriore requisito è che lo smart legal contract debba essere rilasciato su una piattaforma che ne assicuri l’immodificabilità, salvo diverso accordo tra le parti, al fine di garantire che nessuna delle stesse possa modificare lo schema logico unilateralmente.

In verità, a parere di chi scrive, questa parte delle regole tecniche sembrerebbe contenere una contraddizione, in quanto include tra le piattaforme su cui potrebbe essere rilasciato lo smart contract anche sistemi cloud, on-premise, peer-to-peer o macchine virtuali, mentre la definizione di smart contract sembrerebbe richiedere che lo stesso sia necessariamente rilasciato su una tecnologia a registro distribuito o una blockchain.

In merito alla revisione dello smart legal contract, ossia dell’istanza del modello di smart contract, le regole tecniche non sembrano fornire precise indicazioni. Esse, infatti, si limitano a precisare che nel caso in cui sia necessario procedere ad aggiornamenti dello smart legal contract, derivanti da nuovi accordi tra le parti, errori, modifiche o simili, lo stesso dovrebbe essere sostituito da una nuova istanza del modello contenente le opportune modifiche, mentre in particolari circostanze si potrebbe tornare ad adempiere manualmente agli obblighi contrattuali.

L’indicazione, nella sua estrema concisione, non offre elementi utili per comprendere come possa avvenire tale “sostituzione” dello smart legal contract nell’ambito di una tecnologia a registro distribuito tendenzialmente immodificabile, soprattutto in relazione al destino dell’istanza che viene sostituita dalla successiva, che, tendenzialmente, potrà continuare ad essere eseguito sul network qualora non vengano inserite apposite istruzioni di “exit” per determinarne l’interruzione.

E’ opportuno sottolineare che si tratta di uno dei profili più rilevanti della disciplina degli smart contract in generale, sul quale non vengono fornite precise indicazioni. La previsione, nell’ambito delle specifiche tecniche in commento,  di una collaborazione congiunta tra tecnici e giuristi nel processo di implementazione di uno smart contract potrà però sicuramente essere utile ad individuare strumenti concordati tra le parti per porre rimedio a situazioni patologiche dello smart contract, eventualmente attivabili in presenza di determinati presupposti.

La gestione dello smart contract

Il draft delle regole tecniche include anche gli aspetti organizzativi inerenti al processo di implementazione degli smart contract, individuando specifiche figure e delineandone ruoli e funzioni.

Sono definiti, quindi, i soggetti che forniscono i software ed hanno la responsabilità di implementare le piattaforme su cui saranno creati e rilasciati gli smart contract (e tale indicazione pone dei dubbi in merito all’individuazione di dette figure nel contesto di blockchain permissionless).

Ovviamente vengono individuate le parti contrattuali come attori del processo di implementazione e gestione, nonché l’autore del modello di smart contract, figura che può coincidere con una parte contrattuale o con lo sviluppatore del codice informatico del contratto.

Vengono poi individuate le figure del “Commercial Manager” e del “Contract manager”, chiarendo che le stesse potrebbero anche essere ricoperte dalla stessa persona. Questi soggetti sono coloro che, collaborando con le parti ed i giuristi, redigono lo schema letterale del contratto, decidono quali devono essere i parametri da utilizzare nelle clausole e quali delle previsioni contrattuali dovrebbero essere automatizzate. Essi provvedono al monitoraggio dello smart legal contract una volta rilasciato, effettuano le operazioni manuali eventualmente in esso previste (pagamenti o comunicazioni) e si occupano di provocare la cessazione di efficacia del contratto nei casi stabiliti dallo stesso (o quando necessario).

Infine, un ruolo importante è ovviamente quello dello sviluppatore del codice dello smart contract, che ha la responsabilità di assicurare la regolarità degli input ed output ed in generale la corrispondenza dello stesso allo schema logico ed a quello dei dati, schemi che deve appunto seguire nella realizzazione del codice.

Esempi di utilizzo

Per agevolare la comprensione degli standard, vengono individuati, all’interno dell’Allegato A, sei casi d’uso esemplificativi.

1. Assicurazioni. Una Compagnia di assicurazione che offre un contratto per un impianto eolico con la previsione del pagamento di un indennizzo a seconda di alcuni parametri prefissati, eventualmente collegati alle condizioni atmosferiche. Un ipotetico smart contract potrebbe provvedere a disporre automaticamente il pagamento al verificarsi dell’evento naturale che incide sul parametro prefissato.
2. Navigazione marittima. Il caso di una società di trasporto di merci deperibili all’interno di container con sensori che rilevano temperatura ed umidità. Con uno smart contract, al rilevamento di variazioni delle condizioni originarie,  potrebbero automaticamente applicarsi i conseguenti adeguamenti o riduzioni di prezzo.
3. Servizi di consegna merci. Una società che applica degli sconti sulla merce consegnata in ritardo o danneggiata. Alla consegna, il cliente verifica lo stato dei prodotti e comunica un feedback attraverso una app. La ricezione o il reso della merce unitamente al tempo impiegato per la consegna possono essere elaborate dallo smart legal contract per automatizzare un pagamento.
4. Noleggio auto.Una società di noleggio auto che stabilisce il prezzo del servizio in base al chilometraggio, con agevolazioni per i clienti abituali. Attraverso uno smart contract che combina la lettura del contachilometri con i dati del noleggiatore possono essere emessi in modo automatizzato gli sconti o addebiti previsti.
5. Una società di SaaS che garantisce un livello di  disponibilità del servizio (uptime) verificato da un sistema automatizzato. Se il livello non viene garantito, lo smart contract può inviare automaticamente un reclamo per inadempimento del fornitore.
6. Attraverso uno smart contract, acquirente e venditore possono automatizzare il contratto che preveda il pagamento a rate del prezzo del prodotto con notifica automatizzata al versamento di ogni rata.

Conclusioni

E’ utile in conclusione evidenziare l’approccio, a nostro parere corretto, seguito dalla BSI: il documento non entra nel merito rispetto ai requisiti giuridici di validità dello smart contract, probabilmente riconoscendo che il ruolo di uno standard del tipo di quello in esame è solo definire tecnicamente le caratteristiche e le specifiche affinché possano essere implementati tali categorie di oggetti.

La validità del contratto rimane disciplinata dalle regole dell’ordinamento al quale esso è sottoposto, con ciò chiarendo che, in verità, uno smart contract non è altro che la trasposizione di detto contratto in un codice software che consente l’automatica eseguibilità delle pattuizioni ed obbligazioni che le parti intendono tra di loro assumere.

L’individuazione degli schemi su cui esso deve basarsi è il maggior merito di queste regole tecniche, le quali formalizzano un processo di creazione degli smart contract che consente di salvaguardare la leggibilità in linguaggio naturale del contratto e la sua automatica eseguibilità – sulla base di input che vengono prestabiliti tra le parti – da parte delle piattaforme su cui è rilasciato.

Pur essendo presenti alcuni aspetti non chiari, ma ricordiamo che si tratta di un documento ancora sottoposto a consultazione pubblica, queste regole tecniche hanno il merito di conciliare gli aspetti più strettamente tecnici con le esigenze dei giuristi  e delle parti contrattuali, per le quali è necessario e fondamentale poter esaminare un testo di contratto in linguaggio naturale al fine di comprenderne pienamente le previsioni e le conseguenze delle obbligazioni che si intendono assumere. Da tale punto di vista, può affermarsi che la bozza di regole tecniche della British Standard Institution e l’approccio, in essa adottato, possono sicuramente essere un tassello aggiuntivo in favore della diffusione ed utilizzo degli smart contract.

Per concludere, non possiamo dimenticare che, com’è noto, in Italia sono stati definiti da tempo, a livello di normativa primaria, gli effetti degli smart contract tramite la previsione di cui all’art. 8, ter, 2° comma, della l. n. 12/2019. La disposizione, oltre ad averne inserito la definizione nel nostro ordinamento, ha altresì statuito che i medesimi soddisfano i requisiti della forma scritta in seguito all’identificazione delle parti contraenti attraverso un processo la cui individuazione è stata demandata all’Agenzia per l’Italia Digitale che dovrebbe emanare apposite regole tecniche.

Alla data in cui scriviamo, AgID non ha provveduto a detta emanazione né a porre in consultazione alcuno schema riferito alle regole tecniche sopra citate, le quali, è opportuno precisare, in verità dovrebbero riguardare il solo processo di identificazione informatica delle parti vincolate dallo smart contract.

L’auspicio è che la nostra Autorità, nel processo di definizione delle regole tecniche attuative dell’art. 8 ter, 2° comma, della l. 12/2019, prenda spunto dalle specifiche PAS 333 della BSI esaminate in questo scritto, attraverso la definizione di un processo che non introduca requisiti aggiuntivi rispetto a quelli stabiliti dall’ordinamento ai fini della validità ed efficacia degli smart contract, consentendo alla libera determinazione delle parti di procedere, secondo una base tecnica ben definita, a disciplinare le reciproche obbligazioni secondo i termini e le modalità che sono loro più confacenti, nel rispetto del principio di autonomia contrattuale e di gerarchia delle fonti normative.

Immagine fornita da Shutterstock.