11.1 Architettura del Core

11.1.1 - Preambolo

L'ambizione di T.R.I.N.C.I. è quella di fornire un framework blockchain flessibile ma efficiente per costruire un nodo in grado di eseguire qualsiasi applicazione specifica per le logiche di business.

È un progetto ambizioso perché:

  • è stato sviluppato da zero;
  • introduce alcune caratteristiche innovative non riscontrabili in nessun grande progetto;
  • fornisce un meccanismo di consenso flessibile e un ambiente di smart contracts.

11.1.2 - Componenti del Core

  • Archiviazione: archiviazione blockchain persistente che utilizza l'archiviazione chiave-valore orientata alle prestazioni.
  • Comunicazione: comunicazione tra nodi tramite protocollo p2p, pub/sub, req/res e gossip.
  • Consenso: flessibile e specifico per ambito (PoA o PoW).
  • Ancoraggio: servizio opzionale per eseguire ancoraggi su altre catene stabili.
  • Smart Contracts Execution: sandbox a prova di errore per eseguire smart-contract molto specializzati e capacità di implementare librerie condivise.
  • SDK: librerie per consentire l'implementazione di smart contract utilizzando i linguaggi di programmazione più diffusi.
  • Canali di comunicazione flessibili: lato client può comunicare con la blockchain utilizzando diversi canali di comunicazione (http-rest, socket tcp raw, custom).

11.1.3 - Struttura dei Blocchi

Un blocco viene notarizzato nel libro mastro della blockchain in modo molto efficiente e compatto al fine di ottimizzare lo storage e il traffico di rete.

Un blocco riassume:

  • Transazioni contenute all'interno del blocco.
  • Incassi generati dalle transazioni del blocco.
  • Stato Account utente dopo l'esecuzione di transazioni di blocco.
  • Hash blocco precedente.

Le strutture consentono di generare in modo efficiente prove di presenza sia per le transazioni che per gli incassi.

11.1.4 - Dalle Transazioni ai Blocchi

Innanzitutto è importante chiarire che dal punto di vista applicativo la blockchain rappresenta un archivio chiave-valore.

Tutte le complessità e i meccanismi interni sono opachi rispetto l'esperienza dell'utente.

L'unica differenza tra un normale database e la blockchain è che l'esecuzione degli smart contract evocati dalle transazioni, che causano la variazione dei valori del database, è asincrona e l'algoritmo di consenso alla base del sistema gestisce la validazioni delle transazioni stesse.

Pertanto, al momento dell'invio della transazione, l'utente può solo sapere se la transazione è stata accettata dalla blockchain per l'esecuzione (transazione non confermata) ma l'esecuzione delle azioni viene posticipata sino alla costruzione di un blocco che contiene la transazione in questione..

11.1.4.1 Transazioni

Una transazione esprime la volontà del suo mittente di eseguire un'azione su uno o più account.

Una transazione, quando eseguita, evoca una delle funzionalità di uno smart contract, .Lo smart contract è un modulo aggiuntivo alla blockchain, sviluppato per estendere le sue funzionalità, in base ai requisiti di progetti esterni che ne sfruttano l’infrastruttura..

Le transazioni vengono eseguite in modo asincrono e il ritardo di compensazione, ovvero l'intervallo tra la generazione della transazione e la sua inclusione in un blocco, dipende da come viene costruito un blocco, quindi dall’algoritmo di consenso usato..

Il core blockchain è indipendente dalla logica aziendale specifica dell'applicazione e le sue azioni sono limitate ai controlli di integrità del formato delle transazioni, alla verifica della firma digitale del mittente e alla propagazione nella rete.

11.1.4.1 Blocchi

Un blocco è una sequenza di transazioni che devono essere eseguite nello stesso ordine dai nodi che fanno parte della blockchain. Un blocco modifica la memoria del database chiave-valore.

Dal punto di vista dell'utente, un blocco può essere pensato come una patch atomica che dovrebbe essere applicata all'archiviazione del database chiave-valore.

Le transazioni all'interno di un blocco vengono ordinate e verificate prima di essere aggiunte ad un blocco.

Le transazioni ritenute valide dal core, ma che per alcuni motivi vengono rifiutate dallo smart contract, rientrano comunque nel blocco. Le loro azioni (cioè le modifiche al database) non vengono confermate ma viene generata una ricevuta con la causa dell'errore.

11.1.4.2 La vita della Transazione dalla genesi al blocco

  • Una transazione viene costruita e firmata dall'applicazione utente.
  • La transazione viene ricevuta dal nodo tramite uno dei canali di input blockchain esposti (es. servizio REST).
  • Viene verificata la validità di una transazione: formato del messaggio, verifica della firma digitale e protezione anti-riproduzione.
  • Un feedback viene immediatamente restituito al mittente. In caso di successo viene effettuato l’hash della transazione. In caso di errore, viene veicolato un messaggio con il motivo dell'errore.
  • In caso di fallimento, il viaggio della transazione si ferma qui.
  • Una transazione ricevuta da un nodo viene propagata a tutti i nodi di rete tramite protocollo gossip.
  • Le transazioni non confermate vengono mantenute nell’apposita coda in attesa di essere incluse in un nuovo blocco.
  • Viene creato e proposto un nuovo blocco dal leader scelto tramite algoritmo di consenso se una di queste due condizioni è soddisfatta:
    • viene raggiunta la soglia di transazioni per blocco,
    • scatta il timeout del blocco.
  • Quando un nodo riceve un blocco se questo non è il blocco previsto inizia la procedura di allineamento.
  • Quando le transazioni all'interno di un blocco vengono confermate, il blocco viene inserito all'interno della blockchain e le modifiche vengono applicate atomicamente.

11.1.4.3 Risultati Asincroni

Le transazioni sono asincrone, il che significa che al mittente della transazione non viene fornita una risposta immediata come risultato dell'esecuzione della transazione. La notifica sincrona è impossibile a causa del funzionamento del consenso nelle blockchain.

Una volta che una transazione è stata inviata con successo, l'utente possiede quello che viene comunemente chiamato ticket (cioè l'hash della transazione).

Il mittente può recuperare lo stato di esecuzione utilizzando due metodi: basato su interrupt o su polling.

  • interrupt: il nodo dà all'applicazione la possibilità di sottoscriversi ad eventi di interesse. In particolare, l'applicazione può sottoscrivere eventi che indicano la creazione di nuovi blocchi. Una volta ricevuto un evento di creazione di un blocco, il mittente può verificare se la transazione che stava aspettando è stata inclusa in quel blocco utilizzando il ticket di transazione.
  • polling: l'applicazione esegue il polling sul nodo utilizzando il ticket di transazione chiedendo in risposta la ricevuta. I tempi di polling dipendono dalla configurazione del nodo, ma in genere sono una questione di secondi.

11.1.4.4 Transazioni Fallite

L'esecuzione di contratti intelligenti potrebbe non riuscire. Il formato degli errori è definito dallo smart contract stesso (specifico dell'applicazione). Il DB contiene sia le transazioni riuscite che quelle non andate a buon fine a condizione che i validatori siano d'accordo sullo stesso risultato.

La registrazione viene fornita per consentire a client leggeri di verificare lo stato di esecuzione.

A livello di smart contract ci sono due categorie di registrazione:

  • log locali: inoltrati al node logger,
  • emit events: inoltrato al servizio bridge per essere eventualmente inoltrato a componenti esterni (es. applicazione utente).