IT201900008991A1 - Metodo di esecuzione di uno smart contract - Google Patents

Description

DESCRIZIONE

CAMPO TECNICO

La presente invenzione si riferisce ad un metodo per implementare una funzione in una transazione blockchain.

STATO DELL'ARTE

Un database o una struttura di dati blockchain è un database transazionale sequenziale che può essere distribuito ed è collegato in modo comunicativo a una rete. Per comodità, un database di questo tipo viene qui definito come blockchain sebbene altri database, strutture di dati o meccanismi adatti che possiedono le caratteristiche di un database transazionale sequenziale possano essere trattati in modo simile. Una blockchain fornisce una catena distribuita di strutture di dati a blocchi a cui accede una rete di nodi nota come rete di minatori. Ogni blocco nella blockchain include una o più strutture di dati di transazione. In alcune blockchain, come la blockchain BitCoin, la blockchain include un albero Merkle di valori hash o digest per le transazioni incluse nel blocco per arrivare a un valore hash per il blocco, che è esso stesso combinato con un valore hash per un blocco precedente per generare una catena di blocchi (blockchain). Un nuovo blocco di transazioni viene aggiunto alla blockchain da software, hardware, firmware di minatori o componenti di combinazione nella rete di minatori. I minatori sono collegati in modo comunicativo a fonti di transazioni e accedono o copiano la blockchain. Un minatore intraprende la convalida di un contenuto sostanziale di una transazione (come criteri e / o codice eseguibile ivi inclusi) e aggiunge un blocco di nuove transazioni alla blockchain quando viene soddisfatta una sfida, in genere tale sfida che coinvolge una combinazione di hash o digest per un potenziale nuovo blocco e un blocco precedente nella blockchain e alcuni criteri di sfida. Pertanto, i minatori nella rete dei minatori possono ciascuno generare nuovi potenziali blocchi da aggiungere alla blockchain. Laddove un minatore soddisfi o risolva la sfida e convalidi le transazioni in un potenziale nuovo blocco, tale nuovo blocco viene aggiunto alla blockchain. Di conseguenza, la blockchain fornisce un meccanismo distribuito per verificare in modo affidabile un'entità di dati come un'entità che costituisce o rappresenta il potenziale di consumare una risorsa.

La tecnologia blockchain può essere applicata a un'ampia varietà di transazioni. Questi possono essere trasferimenti monetari, come in Bitcoin, o transizioni molto più complesse, in particolare transizioni di stato, gestite all'interno di una sorta di computer mondiale, come nel caso di Ethereum. In quest'ultimo caso, le strutture di dati che formano lo stato di un contratto, ovvero un insieme predefinito di transizioni, sono gestite in blockchain in versioni successive, memorizzate dopo ogni transazione. In entrambi i casi, le transazioni sono programmate in un linguaggio di programmazione che specifica i loro prerequisiti e risultati.

Ad esempio, Solidity è l'attuale linguaggio di programmazione di riferimento per Ethereum, incentrato su contratti intelligenti. Questi ultimi sono oggetti nella blockchain e incorporano protocolli che specificano le fasi di funzionamento di una transazione blockchain e possono essere applicati a molto più di un trasferimento monetario. La loro esecuzione richiede il pagamento di una somma di denaro (gas) proporzionale al numero di passaggi che eseguiranno.

In particolare, secondo Solidity, lo stato dei contratti viene archiviato (è persistente) nella blockchain (archiviazione). In generale, l'assegnazione di una variabile ha una semantica per valore sull'archiviazione e una semantica per riferimento e un costo più economico sui dati allocati nella RAM (memoria). In particolare, la classificazione in archiviazione e memoria dipende dalla variabile, ad es. le variabili locali tendono a vivere in archiviazione, mentre le variabili dei campi di contratto, come i valori dei suoi campi e gli oggetti raggiungibili da essi, tendono a vivere in memoria. Inoltre, la classificazione è influenzata anche dalla dimensione dei dati, ad es. le variabili locali più grandi vengono mantenute in archiviazione e sul modificatore di memoria esplicito. Tutto quanto sopra tende a confondere il programmatore medio e richiede un debug piuttosto lungo in termini di tempo di uno smart contract prima dell'esecuzione. Inoltre, la semantica per valore introduce inefficienze.

SCOPI E RIASSUNTO DELL'INVENZIONE

Lo scopo della presente invenzione è di fornire un metodo per far funzionare un contratto intelligente in grado di evitare almeno in parte i problemi sopra menzionati e in particolare di ridurre la complessità e le dimensioni delle variabili memorizzate all'interno di una blockchain.

Lo scopo della presente invenzione è raggiunto fornendo un metodo implementato da computer per la serializzazione di oggetti differenziali al termine di una transazione blockchain / smart contract. Per ogni transazione vengono eseguite le seguenti operazioni:

- de-serializzare un oggetto precedentemente serializzato in una blockchain, in modo tale che la descrizione dell'oggetto nella blockchain venga trasformata in un oggetto in una memoria;

- eseguire una transazione blockchain dell'oggetto de-serializzato;

- Identificare delle differenze / modifiche negli oggetti non serializzati nella memoria avvenute durante la transazione blockchain, ovvero prima e dopo la transazione, che includono la modifica di una variabile a causa della transazione o l'aggiunta di una nuova variabile come modifica avvenuta a causa della transazione;

- Serializzare le differenze / modifiche nella blockchain emesse dalla fase di identificazione.

Il fatto di archiviare le differenze / modifiche, anziché l'intero oggetto in una determinata fase di esecuzione della transazione, semplifica notevolmente l'esecuzione complessiva dello smart contract e, in particolare, riduce la quantità di memoria coinvolta.

Inoltre, la serializzazione è intesa come il processo di conversione di un oggetto in un flusso di byte per archiviare l'oggetto o trasmetterlo alla memoria, a un database o a un file. Il suo scopo principale è quello di salvare lo stato di un oggetto per poterlo ricreare quando necessario. Il processo inverso si chiama deserializzazione.

BREVE DESCRIZIONE DEI DISEGNI

L'invenzione è descritta di seguito sulla base di esempi non limitativi mostrati a scopo di spiegazione nei disegni allegati, che si riferiscono rispettivamente a uno schizzo di una serializzazione secondo il metodo della presente invenzione.

DESCRIZIONE DETTAGLIATA DELL’INVENZIONE

La presente invenzione è un framework per la programmazione di contratti intelligenti. Attualmente, una serie di blockchain, come Ethereum, fornisce un linguaggio di programmazione completo di Turing per consentire l'esecuzione di applicazioni arbitrarie denominate smart contract sulla blockchain. Ad esempio, una versione di base di Namecoin per la blockchain di Ethereum può essere scritta con poche righe di codice. Inoltre, utilizzando il concetto di contratti intelligenti, la creazione di sub-valute richiede solo uno sforzo di programmazione minimo. Un altro caso d'uso concreto di Ethereum è la creazione di organizzazioni autonome decentralizzate (DAO). L'articolo "Ethereum: un registro di transazioni generalizzato sicuro decentralizzato" (Wood, Ethereum, 2014) fornisce una definizione formale di una macchina a stati generalizzata basata su transazioni che utilizza una blockchain come sistema di trasferimento di valore decentralizzato.

Ethereum fornisce una piattaforma distribuita per il calcolo generale tramite smart contract. Uno smart contract è un pezzo di programma quasi completo di Turing nel codice Ethereum Virtual Machine (EVM). Il contratto viene distribuito e replicato sui nodi Ethereum attraverso transazioni (blockchain). Durante la creazione del contratto, un nuovo account è associato al codice del contratto e inizializzato con la memoria interna; gli importi della sua valuta virtuale sono in Ether. Quando una transazione viene inviata all'account del contratto, i nodi eseguiranno il contratto nell'EVM locale, che è una macchina virtuale basata su stack. L'esecuzione è guidata dal Gas, che definisce il costo di esecuzione di ciascuna istruzione sulla blockchain. Se si è verificata un'eccezione (inclusa l'eccezione di gas esaurito), lo stato del contratto viene ripristinato.

Secondo una forma di realizzazione con Java, la presente invenzione include classi per l'archiviazione e i contratti. Utilizza inoltre metodi deterministici whitelisted.

Lo stato di uno smart contract è costituito dai valori dei suoi campi e degli oggetti raggiungibili da essi, in modo ricorsivo. Tale stato è inglobato nella blockchain, dopo la creazione del contratto e dopo l'esecuzione di una transazione del contratto, cioè dopo l'esecuzione di un costruttore o metodo pubblico di un contratto.

Secondo un aspetto dell'invenzione, per efficienza viene mantenuta solo la parte aggiornata dello stato, non lo stato completo.

Inoltre, contratti distinti possono condividere parte del loro stato, quindi una transazione su un contratto può modificare oggetti visibili o utilizzati da un altro contratto. Questo può essere usato come una forma di comunicazione tra contratti su blockchain.

Gli stati di tutti i contratti installati su blockchain formano una struttura heap, inglobata in blockchain, chiamata archiviazione. I riferimenti tra oggetti di archiviazione sono chiamati riferimenti di archiviazione e hanno la forma:

<numero blocco, numero transazione, progressivo>,

che significa che si riferisce all'oggetto progressivo n-esimo istanziato durante l'esecuzione della transazione nome_ transazione n-esima all'interno del blocco numero-blocco-n.

Secondo una forma di realizzazione non limitativa eseguita in Java, una transazione richiede il riferimento blockchain *j a un file jar, che fornisce il percorso di classe per la sua esecuzione e un valore booleano che specifica se le dipendenze di questo jar devono essere incluse. Inoltre, ha bisogno della firma sig della funzione e dei suoi parametri effettivi pars, incluso il ricevitore per i metodi. Quindi, un client riceve la richiesta di una transazione come tupla <*j, t, sig, pars>.

I parametri possono essere valori primitivi o riferimenti di archiviazione agli oggetti di archiviazione. L'esecuzione della transazione comporta aggiornamenti di stato su oggetti raggiungibili, inclusi, per le funzioni di costruzione, quelli sull'oggetto nuovo. Alla fine, la transazione memorizza in blockchain una tupla <*j, t, sig, pars, risultato, aggiornamenti>, dove risultato è il risultato per metodi non nulli nel caso, ad es. un calcolo o un oggetto nuovo per le funzioni di costruzione. Se la transazione termina in eccezione, il risultato è una descrizione di tale eccezione.

Quando viene eseguita una transazione di contratto, lo stato degli oggetti coinvolti, come il contratto di destinazione stesso, viene caricato, in una RAM o in un'altra memoria veloce o di lavoro, con campi che contengono valori che riflettono i loro valori inglobati. Pertanto il metodo comprende le fasi di leggere l'oggetto serializzato dalla blockchain e di creare un oggetto de-serializzato nella RAM; ciò mira ad estrarre la variabile dalla blockchain in modo che la transazione possa essere eseguita.

Più in dettaglio quando si usa Java, la figura mostra come un oggetto di classe C viene deserializzato dalla blockchain, dato il suo riferimento di memoria r.

Secondo la presente invenzione, in una determinata fase di una configurazione blockchain secondo il presente metodo, la de-serializzazione di un oggetto blockchain serializzato in precedenza comprende la fase 100 di ricerca dell'ultimo aggiornamento di una classe © pseudofield, tenuta in blockchain come una tripla <r, © class, C> che riporta il nome della classe C dell'oggetto e il riferimento di memorizzazione r. Tale tripla è tenuta in blockchain a seguito dell'applicazione del metodo dell'invenzione alla configurazione originale della blockchain.

L'ulteriore fase 110 è l'istanza nella RAM di un nuovo oggetto di classe C che corrisponde a un oggetto serializzato in blockchain al riferimento di memorizzazione r. Quindi il suo campo inStorage è vero e il suo campo storageReference è r.

Quindi il metodo comprende la fase 120 di cerca gli ultimi aggiornamenti dei campi di C. La figura presuppone che ce ne siano due: f1 di tipo di riferimento e f2 di tipo primitivo. Tali aggiornamenti vengono trattati in modo diverso in modo che il metodo comprenda la fase di riconoscimento di una classe di elementi o di tipi influenzati da un aggiornamento.

In particolare, il valore dei campi primitivi, come f2, si riflette immediatamente nella RAM nell'oggetto deserializzato. Si noti che, nella figura, sono presenti due aggiornamenti per il campo f2 di r, che riflette la cronologia dell'oggetto ma viene utilizzato solo l'ultimo aggiornamento <r, f2, 42>.

I campi di riferimento, come f1, vengono invece caricati lentamente. Quindi, inizialmente f1 è nullo nella RAM. Man mano che la transazione procede nella RAM e non appena il calcolo richiede f1, viene assegnato un riferimento heap h' corrispondente al riferimento di archiviazione r', poiché la tripla <r, f1, r'> è l'ultimo aggiornamento in blockchain per f1. Per implementare questo meccanismo di caricamento lento, il metodo secondo l'invenzione utilizza un campo booleano f1AlreadyLoaded. La figura presuppone che l'esecuzione della transazione abbia aggiornato f1 con un riferimento heap h" e che non vi siano effetti della transazione per f2. Alla fine della sua esecuzione, tutti gli aggiornamenti heap sullo stato degli oggetti nella RAM vengono mantenuti inglobati alla blockchain, ovvero sono serializzati per essere inglobati nella blockchain. Preferibilmente, ciò viene gestito in modo automatico, completamente trasparente per il programmatore. Nella figura, il campo f2 contiene ancora 42 ma il campo f1 è stato aggiornato a h". Una funzione extractUpdates che funziona tra RAM e blockchain, controlla le differenze dopo la transazione tra gli oggetti de-serializzati prima e dopo l'esecuzione e serializza (fase 130) l'aggiornamento a f1 nella blockchain, in una tripla <r, f1, r"> dove r" è il riferimento di memoria corrispondente al riferimento heap h". Infatti f1 è l'unico oggetto interessato dalla transazione nella figura.

I campi inStorage, storageReference, oldF1, oldF2 e f1AlreadyLoaded non vengono scritti dal programmatore e definiscono una struttura predefinita dell'oggetto de-serializzato nella RAM. Invece, la procedura secondo l’invenzione strumenta le classi di archiviazione (e quindi i contratti) in modo che possano essere inglobati nella blockchain e avere la capacità di identificare gli aggiornamenti ai loro campi, in modo efficiente, come verrà spiegato in maggior dettaglio di seguito. Per questo, il presente metodo richiede che le classi di archiviazione abbiano un’estensione a una classe predefinita, ad esempio chiamata qui Storage: solo tali classi sono strumentate e le loro istanze inglobate. Tutti gli aggiornamenti sono archiviati in blockchain come aggiornamenti di archiviazione, ovvero triple <r, f, new_value>, il che significa che il campo con firma f dell'oggetto il cui riferimento di archiviazione è r è stato aggiornato al valore new_. Quest'ultimo può essere un valore primitivo o un riferimento di archiviazione, per i campi di riferimento. Gli aggiornamenti possono essere compattati, per ridurne le dimensioni in memoria. Vale a dire, gli aggiornamenti a più campi dello stesso oggetto potrebbero utilizzare una singola voce di aggiornamento, facendo riferimento a più campi e riportando un nuovo valore per ciascun campo.

Per supportare una forma di realizzazione della serializzazione, ovvero i meccanismi per inglobare, i clients devono esporre la blockchain come oggetto accessibile come Blockchain.getInstance(), con le seguenti funzioni:

getCurrentTransaction() restituisce la transazione corrente in esecuzione. getTopmostBlock() restituisce il blocco più in alto della blockchain. deserialize(r) restituisce un oggetto o che è la deserializzazione dalla blockchain del riferimento di memorizzazione r in una memoria di lavoro per ulteriori elaborazioni, come segue:

- se r è null, questa funzione restituisce null;

- altrimenti, cerca nella blockchain l'ultimo aggiornamento di una classe © pseudofield per r con un nome di classe C. Se non viene trovato, viene generata un'eccezione;

- cerca gli aggiornamenti più recenti dei campi primitivi non transitori definiti da C e dalle sue superclassi. Siano f1, ..., fn i loro valori (ordinati posizionando prima i valori dei campi delle superclassi). Se non viene trovato l'ultimo valore di uno di questi campi, viene generata un'eccezione;

- produce una nuova struttura di dati C (r, f1,…, fn).

La funzione di costruzione invocata nell'ultima fase sopra non è preferibilmente scritta dal programmatore ed è strumentata in codice come parte della nostra soluzione. Come verrà spiegato di seguito, viene strumentata dopo la compilazione e inizializza tutti i campi primitivi di o. I campi di tipo di riferimento, invece, vengono inizializzati in seguito, su richiesta.

deserializeLastUpdateFor (r, "C. f: D") restituisce l'oggetto o’ tenuto all'interno del campo di riferimento (pienamente qualificato) C.f:D (cioè campo f definito in classe C e con tipo di riferimento D) di un oggetto contenitore il cui riferimento di archiviazione è r, come segue:

- verifica che C sia una classe di archiviazione e genera un'eccezione in caso contrario;

- cerca nella blockchain l'ultimo aggiornamento di una classe © pseudofield per r con un nome di classe E. Quella classe deve coincidere con C o essere un sottotipo di C; in caso contrario viene generata un'eccezione;

- cerca l'ultimo aggiornamento del campo C.f:D per r ad un riferimento di archiviazione r'; se non viene trovato, viene generata un'eccezione;

- restituisce deserialize(r ').

Pertanto, secondo una forma di realizzazione preferita, sia il riferimento di archiviazione r e un oggetto contenitore di riferimento r possono essere deserializzati, cioè resi disponibili per operazioni successive in una memoria di lavoro dalla blockchain.

Le classi di archiviazione estendono la classe Storage. Dal momento che solo tali classi possono essere inglobate in blockchain, ne consegue che i loro campi di istanza devono essere primitivi o avere una classe di memoria, ricorsivamente. La classe Storage implementa i meccanismi di base per tenere traccia del riferimento di archiviazione delle sue istanze. Vale a dire, un oggetto di archiviazione o, quando si trova nella RAM, può essere la deserializzazione di un oggetto o' già inglobato nella blockchain, nel qual caso il suo campo onStorage è vero e il suo campo storageReference contiene il riferimento di archiviazione a o' (Fig. 1). Ma potrebbe invece essere un oggetto di archiviazione nuovo, istanziato durante la transazione in esecuzione ed essere inglobato nella blockchain dopo tale esecuzione, se raggiungibile. In tal caso, inStorage è falso e storageReference è il riferimento di archiviazione che verrebbe utilizzato per esso, se fosse mai inglobato nella blockchain. Quindi, Storage ha due costruttori, per quelle due alternative:

public abstract class Storage {

protected final StorageReference storageReference;

protected final boolean inStorage;

protected final static Blockchain blockchain = Blockchain.getlnstance(); private static long nextProgressive;

// costruttore utilizzato dal programmatore per creare oggetti non ancora archiviati

protected C(){

this.inStorage = false;

this.storageReference = new StorageReference( blockchain.getTopmostBlock().getNumber(), blockchain.getCurrentTransaction().getNumber(), nextProgressive++);

> //

costruttore utilizzato per la deserializzazione dalla blockchain protected C(StorageReference storageReference)

this.inStorage = true;

this.StorageReference = storageReference;

> // questo raccoglie gli aggiornamenti di questo oggetto;

// restituisce il riferimento di archiviazione utilizzato per questo oggetto nella blockchain

protected StorageReference extractUpdates(Updates updates){

if (!inStorage)

updates.add(<storageReference, "()class", getClass() ,getName()>); [*] // le sottoclassi sostituiranno e aggiungeranno aggiornamenti ai loro campi di istanza

return storageReference;

} // metodo operativo che verrà utilizzato nelle sottoclassi per implementare

/ / il metodo extractUpdates su campi di tipo di riferimento storageReference finale protetto recursiveExtract (oggetti, aggiornamenti aggiornamenti) {

if (s == null)

return null;

else if (s instanceof Storage)

return s.extractUpdates(updates);

else

throw new RuntimeExceptionC'storage objects must implement Storage");

>

>

Il metodo prevede di chiamare o.extractUpdates(updates) al termine di una transazione di contratto, su tutti gli oggetti raggiungibili dal contratto o dai parametri della transazione. Raccoglie negli aggiornamenti gli aggiornamenti a o che devono essere mantenuti nella blockchain e produce il riferimento di archiviazione utilizzato per o nella blockchain.

La classe Storage non definisce i campi che appartengono allo stato di un oggetto di archiviazione: le sottoclassi ridefiniranno (automaticamente) extractUpdates per creare i loro aggiornamenti. Invece, la superclasse memorizza solo il tag di classe dell'oggetto, se non è ancora in memoria (vedere * sopra). Questo tag di classe verrà utilizzato in seguito, se l'oggetto verrà mai deserializzato.

I programmatori scrivono le classi di archiviazione come classi perfettamente normali che estendono Storage. Ma il codice di tali classi subisce una strumentazione di programma automatica prima dell'esecuzione, per consentire:

- la generazione di aggiornamenti al termine di una transazione: gli oggetti di archiviazione hanno campi strumentati che consentono l'identificazione della parte aggiornata del loro stato;

- la deserializzazione su richiesta di oggetti di archiviazione a cui si accede durante una transazione. Vale a dire, teoricamente è possibile caricare in RAM l'intero stato di un contratto, ricorsivamente, prima di una transazione. Ma sarebbe impraticabile e lento, dal momento che potrebbe essere molto grande.

Nella misura in cui le forme di realizzazione dell'invenzione descritte sono implementabili, almeno in parte, utilizzando un dispositivo di elaborazione programmabile controllato da software, come un microprocessore, un elaboratore di segnali digitali o un altro dispositivo di elaborazione, un apparato o un sistema di elaborazione dei dati, si apprezzerà che un computer un programma per la configurazione di un dispositivo programmabile, un apparato o un sistema per implementare i suddetti metodi descritti è previsto come un aspetto della presente invenzione. Il programma per computer può essere incorporato come codice sorgente o essere sottoposto a compilazione per l'implementazione su un dispositivo, apparato o sistema di elaborazione o può essere incorporato come codice oggetto, per esempio.

Opportunamente, il programma per computer è memorizzato su un supporto di supporto in forma leggibile da macchina o dispositivo, ad esempio in memoria a stato solido, memoria magnetica come disco o nastro, memoria leggibile otticamente o magneto-otticamente come disco compatto o disco digitale versatile ecc. e il dispositivo di elaborazione utilizza il programma o parte di esso per configurarlo per il funzionamento. Il programma per computer può essere fornito da una sorgente remota incorporata in un mezzo di comunicazione come un segnale elettronico, un'onda portante a radiofrequenza o un'onda portante ottica. Tali mezzi di supporto sono anche previsti come aspetti della presente invenzione.

Gli esperti del ramo comprenderanno che, sebbene la presente invenzione sia stata descritta in relazione alle forme di realizzazione di esempio sopra descritte, l'invenzione non è limitata a ciò e che vi sono molte possibili variazioni e modifiche che rientrano nell'ambito dell’invenzione.

L'ambito della presente invenzione include qualsiasi nuova caratteristica o combinazione di caratteristiche descritte nel presente documento. Con la presente, il richiedente comunica che è possibile formulare nuove pretese su tali funzionalità o combinazione di funzionalità durante il perseguimento di questa domanda o di qualsiasi altra richiesta derivata da essa. In particolare, con riferimento alle rivendicazioni allegate, le caratteristiche delle rivendicazioni dipendenti possono essere combinate con quelle delle rivendicazioni indipendenti e le caratteristiche delle rispettive rivendicazioni indipendenti possono essere combinate in qualsiasi modo appropriato e non semplicemente nelle combinazioni specifiche elencate nelle rivendicazioni.

Claims (5)

1. RIVENDICAZIONI 1. Metodo implementato da un computer per l'esecuzione di una transazione di uno smart contract, comprendente le fasi di: - Identificare un oggetto in una blockchain; - Eseguire una transazione blockchain che coinvolge l'oggetto e causare almeno una differenza / modifica dell'oggetto; - Individuare almeno una differenza / modifica; - Memorizzare almeno una differenza / modifica nella blockchain.
2. 2. Metodo secondo la rivendicazione 1, comprendente inoltre la fase di deserializzare l'oggetto generando un flusso di byte prima della fase di esecuzione e la fase di serializzazione dell'oggetto diverso / modificato prima della fase di memorizzazione e in cui la fase di eseguire coinvolge il flusso deserializzato di byte.
3. 3. Metodo secondo la rivendicazione 2, comprendente inoltre la fase di archiviare in una memoria il flusso di byte.
4. 4. Metodo secondo la rivendicazione 3, in cui la memoria è una memoria di lavoro.
5. 5. Metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui la fase di identificare l’ameno una differenza / modifica comprende l'ulteriore fase di identificare, per un dato smart contract, valori (oldF1) di oggetti che non sono raggiungibili durante l'attuale esecuzione della transazione del contratto dato.