Execute-order-validate architecture for SmartContracts on top of the Tendermint consensus engine
Matteo Venditto
Con questo progetto si vuole esplorare la possibilità di realizzare una piattaforma per l'esecuzione di smart-contract, basata su un architettura execute-order-validate ispirata a quella adottata in Hyperledger Fabric, ma nella quale ordinamento e consenso sono gestiti da Tendermint. Gli smart-contract in questione devono essere implementabili in un linguaggio di programmazione general-purpose.Goal
- order-execute
- Molte piattaforme blockchain si basano su un architettura di tipo order-execute, dove il ciclo di vita delle transazioni prevede una prima fase in cui vengono ordinate, aggiunte al ledger e poi diffuse a tutti peer che, in una seconda fase, le eseguono sequenzialmente.
- limitazioni principali
- è necessario determinismo nell'esecuzione delle transazioni
- difficile/impossibile da imporre in linguaggi general-purpose
- vengono adotatti linguaggi / DSL ad-hoc
- limita di fatto ciò che può essere implementato da uno smart-contract
- difficile/impossibile da imporre in linguaggi general-purpose
- le fasi di esecuzione e update della blockchain sono 'sovrapposte':
- tutti i peer devono validare ed eseguire tutte le transazioni
- le transazioni devono essere eseguite in sequenza per rispettare l'ordinamento
- possibile limite al throughput
- è necessario determinismo nell'esecuzione delle transazioni
- execute-order-validate
- Una possibile soluzione per eliminare alcune limitazioni della modalità order-execute è l'architettura execute-order-validate adottata ad esempio in Hyperledger Fabric. Una caratteristica importante è che, contrariamente a ciò che accade in un architettura order-execute, le fasi di esecuzione e validazione sono disaccoppiate. Un'altro meccanismo fondamentale è quello dell'endorsement, che permetta ai peer di concordare esplicitamente il risultato di una transazione prima della fase di validazione. Alcune consegunze di queste caratteristiche sono:
- supporto a logica non deterministica negli smart-contract
- grazie al meccanismo di endorsement il risultato di una transazione è concordato esplicitamente prima della fase di validazione e non è quindi necessario imporre il determinismo per garantire che tutti i peer siano in accordo sul risultato prodotto.
- essendo le fasi di esecuzione e validatione separate è possibile decidere quali peer devono partecipare a execution e endorsement (confidentiality).
- la possibilià di eseguire le transazione (e.g invocazione di smart-contracts) in parallelo, questo perchè la fase di esecuzione avviene prima dell'ordinamento e non è necessario forzare un esecuzione sequenziale.
- l'esecuzione degli smart-contract può avvenire in un container isolato dal peer, che ne può controllare l'esecuzione, ad esempio interrompendola se la computazione impiega troppo tempo a terminare.
- :exclamation: in order-execute, dove l'esecuzione è sequenziale, una computazione molto lunga / infinita, impossibile da individuare a priori, avrebbe un grave impatto sulle prestazioni, causando di fatto un Denial of Service.
- supporto a logica non deterministica negli smart-contract
Lo scopo è quello di esplorare le possibilità per la realizzazione un sistema con le seguenti caratteristiche:Requirements
- architettura execute-order-validate
- separare esecuzione e validazione delle transazioni
- consenso realizzato da Tendermint 3. supporto all'esecuzione di smart-contract..
- in grado di implementare logica non banale
- implementati in Prolog
- dei quali devono poter essere effettuati deployment e invocazione da parte dell'utente
Design & Implementation
- World State
- Ispirandosi ad alcune caratteristiche dell'architettura adottata in Hyperledger Fabric, lo stato potrebbe essere modellato come un key-value storage (mantenendo anche un informazione relativa alla versione delle chiavi). Lo stato verrebbe poi aggiornato in fase di validazione quando, se una transazione è accettata, vengono rese permanenti le modifiche contenute nel corrispondente write-set.
- Smart Contracts
- Come già definito gli smart contracts saranno implementati in Prolog. In particolare l'idea è quella di utilizzare tuProlog e sfruttarne l'interoperabilità con Java. Sarà permesso agli smart-contract di interagire con lo stato attraverso delle API, nello specifico get(key), put(key,value), del(key). Per permettere un certo livello di incapsulamento ed evitare conflitti nei nomi delle chiavi, internamente verranno combinate con un namespace che corrisponde al nome dello SC in questione. Si pensava di esporre questi metodi all'engine TuProlog tramite un oggetto java oppurtunamente registrato. La chiamata di questi metodi non deve modificare direttamente lo stato, ma generare read-set e write-set. La logica implementata da uno SC è definita da un predicato receive(Message, Response).
- limitazioni: una semantica del tipo "read your writes" non sarebbe supportata.
init(Value) :- state <- put('counter', Value). destroy() :- state <- del('counter').
add(Amount) :- state <- get('counter') returns Value, NewValue is Value + Amount, state <- put('counter', NewValue).
get(Value) :- state <- get('counter') returns Valuee, Value is Valuee.
receive(Message, Response) :- Message = [[invoke('inc')]], add(1), write('inc'), nl, ! ;
Message = [[invoke('add'), amount(Amount)]], add(Amount), print('add: '), write(Amount), nl, ! ;
Message = [[invoke('get')]], get(Value), Response = success(Value). % failure(Reason)
add(Amount) :- state <- get('counter') returns Value, NewValue is Value + Amount, state <- put('counter', NewValue).
get(Value) :- state <- get('counter') returns Valuee, Value is Valuee.
receive(Message, Response) :- Message = [[invoke('inc')]], add(1), write('inc'), nl, ! ;
Message = [[invoke('add'), amount(Amount)]], add(Amount), print('add: '), write(Amount), nl, ! ;
Message = [[invoke('get')]], get(Value), Response = success(Value). % failure(Reason)