Viaggio all’interno di uno Smart Contract in Universa

Nelle scorse settimane potresti aver letto gli articoli introduttivi a proposito di alcune architetture interne della Blockchain Universa e della revisione degli Smart Contracts. Come adesso sai, le transazioni non vengono aggiunte ad una catena di blocchi lineare, ma ogni transazione è una revisione di uno smart contract in uno sciame di Grafici Aciclici Diretti.

Ma cos’è in effetti uno smart contract, e come si presenta la sua architettura?

All’interno di uno Smart Contract

Innanzitutto, il termine “smart contract” è largamente usato ma spessissimo non applicato nel modo giusto. Suona come se fosse un complicato contratto che viene elaborato dalla blockchain in modo intelligente.

Nella Blockchain Universa ogni transazione è un nuovo smart contract. E può essere si, un contratto, ma anche un documento, un processo digitale o un accordo. Possiamo chiamare queste operazioni “smart documents”, “smart processes” o come vuoi.

Se diamo uno sguardo più da vicino ad uno smart contract nella Blockchain Universa, possiamo notare che ha tre sezioni:

  1. Definizione
  2. Stato
  3. Transazionale

Definizione

La prima parte della struttura contiene i dati che dovranno rimanere invariati in ogni revisione del contratto. Se una transazione viene processata, questo dato deve essere immutabile. La modifica non è possibile.

Se il dato viene modificato, i nodi Universa negano la registrazione della transazione. Alla fine, i nodi confrontano il dato della nuova revisione con il precedente.

Stato

Lo stato contiene dati che possono essere alterati nella revisione del contratto. I particolari dettagli di cosa e come può essere alterato, può essere specificato in definition.permissions. I parametri che sono inseriti nella definizione o nello stato sono cose come “creatore”, “emittente” o “proprietario”

Transazionale

La terza parte della struttura contiene dati che non verranno (necessariamente) conservati nel contratto, ma che sono legati solo alla specifica transazione. Per esempio: Se si paga un commerciante puoi inserire un record del motivo del pagamento/codice della fattura nei dati transazionali.

Queste sono le tre sezioni all’interno di uno smart contract che contiene tutti i dati relativi a una specifica transazione. Noi chiamiamo tutto questo “solo dati”, ma di cosa si potrebbe trattare?

Universa Token contract

Andiamo a prendere come esempio il contratto di origine degli Universa Token (UTN). Puoi controllarlo tu stesso su universaexplorer. Mostra dati/informazioni generali riguardo i ruoli e il proprietario.

Puoi anche leggere i dati di definizione (i quali dovranno rimanere invariati durante le revisioni). Non importa quale versione del contratto tu possieda,vedrai sempre questi dati allegati alla stessa

La seconda sezione è quella dei dati di stato, che mostra l’ammontare della disponibilità di UTN. Questo potrebbe confonderti, dato che potresti aspettarti che la disponibilità sia fisse o immutabile.

Comunque, una transazione (o la revisione di questo contratto iniziale) di un token, usa la funzione split-join. Questo è uno degli degli use case di uno smart contract. l’operazione split-join su un contratto è usata principalmente per contratti di moneta.

Per farla semplice, il contratto iniziale del token UTN ammonta ad un totale di 4 997 891 952 token.

Grazie alla possibilità flessibile e dinamica di scegliere l’ammontare di UTN-UTNP da swappare, Universa non ha il dettaglio esatto dei saldi e dell’ammontare di UTNP in circolazione. Potrebbe esserci la possibilità di calcolarla, ma al momento un tool in grado di farlo non è ancora stato realizzato.

Se da questo contratto viene eseguito un pagamento, questo importo verrà suddiviso, per esempio in 1 997 891 952 e 3 000 000 000. Questo è possibile perché questo ammontare è nello stato del contratto (quindi può essere modificato).

Quindi adesso abbiamo due revisioni dello stesso contratto iniziale, entrambe aventi il proprio ammontare di token Per ogni pagamento o transazione con questo token, l’ammontare verrà diviso, inviato ed eventualmente unito (o collegato) alla parte del destinatario. Puoi avere maggiori dettagli a proposito di questo caso sulla KB.

Tra l’altro, L’ID Originaria (l’ID del contratto iniziale di un token) è la più importante nell’ideologia del token a disponibilità fissa.

Come dovresti sapere, nel mondo della blockchain i termini mutabile e immutabile sono davvero importanti. Pensa alla disponibilità massima, al proprietario e all’emittente di un contratto. Con entrambe le sezioni, definizione e stato, tutto questo può essere garantito per ogni particolare caso d’uso.

Autorizzazioni e Ruoli

Ci sono anche dei metodi per specificare esattamente chi detiene le autorizzazioni di un contratto. Ci può essere un SimpleRole(specificato con una solo chiave privata), un RoleLink(che si riferisce ad un altro ruolo, come ad esempio “proprietario”) oppure ListRole(che si riferisce ad una lista di altri ruoli ulteriori).

Questo in effetti è molto interessante. Perché ad esempio è possibile creare un ruolo tipo “una lista di 5 persone, e TUTTE devono firmare il documento”. O anche crearne uno tipo “una lista di 6 persone e UNO QUALUNQUE di loro deve firmare il documento”. E’ anche possibile creare un costrutto tipo “5 persone su 6 devono firmare il documento”. Questo fornisce sicurezza extra in operazioni come ad esempio il cold strorage o nei processi decisionali multipartitici.

Nell’uso pratico, oltre alla mera definizione di base del ruolo, ognuno di questi può contenere alcuni riferimenti atti a controllare ed aggiungere logiche di verifica personalizzate extra. Questi riferimenti possono essere definiti in una sezione qualsiasi tra Definizione, Stato o Transazionale. Ci può essere un riferimento ad un nome, un ID transazionale, a campi o a “firmato da” .

Ci sono molti modi per specificare dati, ruoli e autorizzazioni di uno smart contract. Una volta registrato, lo smart contract può essere usato/verificato/eseguito e viene revisionato per ogni transazione. Ciò si traduce in diversi Stati dell’Elemento per ogni revisione, che verranno aggiunti al DAG.

Stati dell’Elemento

Torniamo a prendere in esempio il contratto di UTN. Lo stato dell’elemento è UNDEFINED (indefinito).

Importante: questo perché è stata utilizzata la funzione split-join e non perché il token UTN “non funziona o non esiste più”.

Ci sono diversi stati per lo smart contract, che dipendono dal consensus della rete.

  1. APPROVED (approvato), il principale stato per un contratto “riuscito”.
  2. LOCKED (bloccato), il consensus sullo stato è già positivo, ma il contratto è ancora bloccato durante la preparazione per l’archiviazione.

E’ anche possibile che ci sia un consensus negativo a tra i nodi:

  1. DECLINED (rifiutato)
  2. REVOKED (revocato)

Per finire, ci sono quattro opzioni per cui uno smart contract (o transazione) non abbia trovato il consensus:

  1. UNDEFINED (indefinito), perché ad esempio era già stato revocato tempo addietro.
  2. PENDING (pendente)
  3. DISCARDED (scartato)
  4. LOCKED_FOR_CREATION (bloccato per creazione)

Puoi sapere di più su questi stati visitando la pagina della Knowledge Base. Nel prossimo articolo ci tufferemo più a fondo nei casi d’uso di questi smart documents. Resta sintonizzato. Tradotto da Marco Cominato

Help translating this post to Inglese Tedesco Francese Olandese Spagnolo Croato Russo. Contact @starnold to participate!

Related posts

Crittografia Asimmetrica nella Blockchain Universa

Arnold

The Digital Migration: Why Universa is the Rail Blazer

kobina

Alexander incontra Amsterdam 2020

Arnold

Leave a Comment