3.4 Sistema Business oriented applicato ad 4RYA.

Nel definire e spiegare T.R.I.N.C.I. spesso parliamo di “tecnologia business oriented”, cioè di un sistema non solo costruito attorno all’utente business (B2B), ma anche per utenti consumer (B2C). Come 4RYA interviene in tutto questo?

4RYA è pensato per gestire tutta la catena della Certification Authority tramite l’utilizzo di certificati e di deleghe.




3.4.1 Certificati.

I certificati hanno pregi e difetti. Il primo pregio è che l’utente è in grado di produrre un documento che indipendentemente dal contesto (quindi anche offline) può dimostrare che una certa chiave pubblica, un certo soggetto ritenuto verosimilmente autorevole, ha certificato una serie di informazioni.

Per esempio, nel caso dell’identità digitale (carta d’identità), un Ente certifica le generalità di un cittadino (la data di nascita, la residenza, nome e cognome). Il problema è che questo documento ha valore solo se le informazioni fornite sono integrali. L’utente è quindi costretto a fornire tutte le informazioni del documento anche in contesti in cui una sua visione parziale sarebbe sufficiente all’ottenimento della verifica.

In T.R.I.N.C.I. abbiamo risolto questo problema costruendo certificati più sofisticati che fanno uso dei Merkle tree e tutta una serie di crittografie di ultima generazione dove si può produrre un sottoinsieme del certificato che ne mantiene la validità complessiva.

Esempio: se un Comunne certifica i dati per interi di un soggetto in un certificato, egli può estrarre da tale certificato un “sotto-certificato” che certifichi solamente la propria data di nascita; così il soggetto può spendere questo certificato (“sotto-certificato”) senza essere costretto a fornire la totalità dei propri dati (per esempio per proteggere la propria privacy).




3.4.2 Deleghe

Quando si affrontano seriamente le difficoltà di classe Enterprise, ponendosi nei panni delle aziende che devono utilizzare determinate tecnologie, balzano subito all’occhio una serie di problematiche:

  • Chi tiene la chiave privata dell’azienda;
  • Chi sono i responsabili dell’azienda;
  • Cosa possono fare;
  • Che mansioni hanno;
  • Che deleghe hanno;

In ambiente blockchain queste situazioni non sono mai state prese in considerazione. Semplicemente: “c’è un wallet, chi ha la chiave privata opera.”.

Nel mondo reale, in aziende reali (come la stessa Affidaty S.p.A) è molto difficile gestire tutto in questo modo.

  • Innanzitutto la chiave privata una volta che è stata conferita a qualcuno non può più essere chiesta indietro perché la persona potrebbe essersi creata una copia;
  • Inoltre, non si può cambiare la chiave privata: non è come una password che si può gestire e modificare facilmente. Se un’azienda affida ad un proprio dipendente la gestione di una chiave privata ed un domani quel dipendente se ne andasse per qualsiasi motivo, egli continuerà ad avere una copia della chiave privata; non potrebbe essergli chiesto di modificarla o di mostrare che l’abbia distrutta;

Chi ha la chiave privata, oggi, fa tutto. Diversamente, Affidaty ha costruito in T.R.I.N.C.I. un sistema di Deleghe in cui un account che ha la sua chiave privata può costruire delle deleghe specifiche per una serie di utenti in modo tale che:

  • se è l’Utente 1 ad utilizzare la delega per firmare quella transazione, rimarrà traccia nella blockchain che quel consenso è stato dato da lui. Non la chiave privata originale, ma quella delegata dell’Utente 1;
  • questa cosa non può esser fatta con il sistema classico, condividendo la chiave: l’azienda condivide la chiave con 5 soggetti, per la blockchain è sempre un soggetto unico che opera, quindi non si può distinguere se quell’azione l’abbia fatta uno piuttosto che un altro;
  • con le deleghe, invece, si inizia ad avere un’esperienza concreta nella distribuzione dei ruoli e dei compiti all’interno di uno smart contract;
  • inoltre, si possono confinare quelle che sono le attività possibili all’interno di una delega stessa. La delega è un certificato in cui può essere scritto che un Utente 1 delega un altro Utente 2 per effettuare trasferimento di denaro con determinati limiti ed in certe condizioni;
  • questa delega può essere persino revocata. In blockchain, paradossalmente, non si revoca nulla, non si distrugge nulla, neanche nella blockchain di T.R.I.N.C.I. è possibile farlo, ma si può aggiungere un’informazione che invalida l’informazione precedente;
  • quindi, tecnicamente, se un utente avesse fatto una delega ad un altro utente, colui che ha prodotto una delega può produrre una contro delega che va ad annullare quella precedente, per cui: nel momento in cui l’utente va a spendere la sua delega, c’è un sistema all’interno del core che controlla se qualcuno non l’abbia invalidata prima di spenderla;
  • ecco che si può costruire un sistema anche temporaneo per far sì che un’azienda possa delegare un dipendente o un reparto amministrativo per operare su un wallet.
  • in questo modo, se un dipendente va via dall’azienda (per qualsiasi motivo) il sistema: revoca la delega; - la chiave privata rimane sempre al suo posto; - viene prodotta una delega per un altro utente; - in questo modo il sistema continua a funzionare senza dover distruggere o conservare la chiave privata in modo fantasioso.