Supply chain Infinity War: e se l’alternativa fosse Scrypta?

Da Hyperledger a Scrypta: un nuovo modello di “privatizzazione”?

Qualche tempo fa in occasione della call for ideas indetta da CoopItalia e IBM per la riscrittura della supply chain delle uova che introducesse in seno al processo l’utilizzo della blockchain, avevamo prodotto il white paper al seguente link riassunto successivamente da questo post:

In occasione di questo specifico progetto avevamo analizzato l’intera filiera produttiva e rivisto il processo introducendo l’uso di Hyperledger Fabric, una blockchain permissioned o privata, che presenta built-in alcune caratteristiche specifiche per “la modellazione” di un rapporto cliente/fornitore, fornitore/fornitore e/o cliente/cliente:

  • Canali privati
  • Smart Contract per logiche di business e completa dematerializzazione del processo
  • Governance

Questi tre aspetti, riassumendo i risultati della nostra analisi, costituivano il fulcro per poter rendere la supply chain veramente trasparente, sia per i clienti finali che per i fornitori, tracciabile e collaborativa.

Questo finché la nostra attenzione non è stata successivamente attirata dal post di ScryptaChain

che introduceva una soluzione alternativa per il tracciamento delle filiere attraverso l’adozione della blockchain di Scrypta.

All'interno del post si legge:

“La blockchain di Scrypta permette di costruire supply chain pubbliche in cui tutti gli attori, …, possono fornire dati e informazioni e verificare tutti i dati forniti dagli altri partecipanti nella massima trasparenza.

…..

Scrypta garantisce un flusso chiaro di informazioni libero da irregolarità….

…Attraverso la registrazione automatica di informazioni nella rete è possibile creare la storia del prodotto e tracciare la sua catena produttiva. Ogni informazione acquisita è validata dalla rete di compagnie che costituiscono il consenso. Dopo che ogni blocco è stato validato, e quindi registrato, è aggiunto a una “catena” di transazioni diventando dunque un record permanente dell’intero processo.

E’ dunque possibile registrare continuamente tutti i dati relativi alla qualità di un lotto. Tali dati diventeranno record indelebili e non sarà possibile in seguito manipolarli o alterarli.”

A questo punto è d’obbligo chiedersi che fine avessero fatto i tre capisaldi evidenziati come risultato delle nostra precedente analisi. E cioè:

Come pensa Scrypta di affrontare gli aspetti relativi alle comunicazioni private, alla realizzazione delle logiche di business, dApps, e alla Governance dei processi?

Per quanto riguarda le comunicazioni private, quelli che avevamo precedentemente indicato come canali privati, Scrypta mette a disposizione nativamente un sistema di obfuscation che permette di criptare le informazioni scambiate e di consentirne dunque la lettura solo a chi in possesso della chiave.

Smarcato questo primo punto restano da chiarire gli altri due e per far ciò abbiamo chiesto supporto al Team di Scrypta attraverso il loro canale Discord. Qui di seguito l’estratto della conversazione nella forma domanda/risposta.

Come implementare su Scrypta la business logic relativa al processo? Dobbiamo tradurre tutti gli step in una logica L2 (Scrypta non ha Smart Contract), e chiedere alla dApps di gestirli?

Dipende dal target. Se hai la necessità di nascondere le informazioni, puoi semplicemente criptare tutto e fornire la chiave solo a una parte della chain. Se il risultato deve essere pubblico, puoi semplicemente scrivere in chiaro le informazioni sulla blockchain..O entrambe le cose.

Ricordiamo che le dApps girano su una logica L2, L1 è solo per i blocchi, le transazioni e gli indirizzi. Gli Smart Contract sono solo degli “API caller” attraverso la blockchain, attivati da oracoli esterni.

Tale risultato può essere raggiunto anche su Scrypta, ma il codice, a differenza di quello che accade su Ethereum e Tron, non gira “nativamente” sulla blockchain. Ma la logica è la stessa: c’è del codice -magari realmente decentralizzato ed che gira su un Arduino o simili- che mette a disposizione un API endpoint -come i nostri idA-Nodes- e che scrive sulla blockchain. Poi c’è dell’altro codice, ad esempio un website, che legge tali informazioni.

Con la stessa logica posso implementare una strato che gestisca i ruoli e i permessi. E’ così?

Certo, chiavi differenti “sbloccano” strati differenti. Oppure è possibile usare indirizzi diversi: uno può leggere e vedere tutto -ndr Admin- e altri solo determinate informazioni.

Usando gli idA-Nodes hai tre campi da poter utilizzare:

  1. data: qui puoi inserire del testo in chiaro o criptato
  2. collection: utile per identificare determinati contenuti. Questo campo è sempre in chiaro ed è utilizzabile per le query prima di decriptare i contenuti.
  3. refID: è il reference ID di uno specifico oggetto. Anche questo campo è sempre in chiaro.

Così facendo puoi chiamare l’endpoint di scrittura senza il flag per criptare i dati e criptarli/decriptarli successivamente sulla dApp.

Ricapitolando dunque le differenze tra gli aspetti chiave di Hyperledger e Scrypta:

  • Canali privati vs obfuscation
  • Smart Contract vs L2 logic (dApp level)
  • Governance built-in vs L2 access layer

E se a questo punto introducessimo le Trustlines di Scrypta? Giochiamo qui un pò il ruolo degli spoiler…Fonti certe e molto vicine al mondo di Scrypta ci hanno segnalato che a giorni verrà rilasciata una funzionalità davvero molto interessante che prende appunto il nome di Trustline(-s).

Con “Trustline” Scrypta definisce quel sistema di linee di fiducia volontarie, stabilite da due o più utenti, che gli permettono di scambiare informazioni e scrivere in blockchain dati. Le trustlines sono di fatto degli indirizzi della rete Scrypta che vengono generati dal consenso volontario di due o più indirizzi legacy. La creazione di un account detto “multi-signature” permetterà di creare transazioni di tipo comune, la cui trasmissione e validità avviene solo se entrambe le parti appongono volontariamente la propria firma digitale.

Una Trustline costituirà dunque un vero e proprio contratto digitale.

Uno dei principali impieghi di questa funzionalità sarà appunto il mondo delle supply chain: usando una Trustline cliente e fornitore instaureranno un vero e proprio canale commerciale certificato. In questo modo potrebbero subito regolamentare il rapporto sottoscrivendo un contratto, accettato dalle due parti, e da qui instaurare “digitalmente” tutti gli scambi del processo che una volta transiti e scritti su blockchain sarebbero immutabili e avrebbero a tutti gli effetti valenza legale.