Expressive Smart Contracts (ESC), developed in BPMN with a model-driven approach, are suitable for the automation and certification of the execution of collaboration processes involving two or more participants.
The following example shows an example of an ESC for a simplified process of an online order that involves four participants: a client, a retailer, a carrier and a manufacturer. The latter is involved only in case the reseller does not have enough material available.
The BPMN collaboration describes the rules that each participant must follow to produce the business result and consists of series of activities and interactions that must be performed with a certain sequence.
Shared has developed a series of technologies that allow the execution of ESCs so that the parties are bound to accept the effects that they produce caused by the activities and interactions performed. For this purpose, every activity and every interaction is stored in blockchain so that the execution flow and the information exchanged are non-repudiable and the whole process instance can be fully played back.
When participants agree on the smart contract, they sign it digitally making it ready for deployment. The ESC is then loaded onto the blockchain nodes dedicated to execution. Each participant owns its process instance and is able to inspect the individual execution steps of the other participants, while the overall execution takes place thanks to a distributed workflow engine that operates as a smart contract execution machine that, through a blockchain, keeps synchronized the various process instances. Since individual instances interact through exchanges of messages brokered by the blockchain, each step of the execution is notarized and the individual process instances can be completely reconstructed in terms of flows, execution times and data exchanged.
Participants interact with their instance via APIs so that the entire system is agnostic to the technology supporting the IT system of each actor.
CHESS GAME- AN EXAMPLE
To show how the system works we have created an ESC that implements a chess game moderated by a referee.
The system has three participants, two players and a referee who holds the time, determines if a move is valid and, at the end of the game, declares the winner.
The user interface of the players is a web application that allows to manage the board, receive and send the moves. The arbiter’s part is implemented in Javascript with Node.js and adopts the library chess.js to enforce the rules of the game.
In the following figures the executable ESC is shown:
Here the entire process is represented, three pools, one for each participant, White, Black and the Referee.
The Arbiter initiates the game and activates players’ process instances. Then White performs the move, sends it back to the Referee, who in turn passes the move to Black. Black receives the move, replies by sending its move to the Referee and so on.
Now, let us focus on the Referee.
The management task of the Referee is a subprocess, i.e. not a single diagram but a hierarchy of diagrams, in which the contents of subprocesses are detailed in separate child-level diagrams.
We can now expand it to understand the single steps of its execution and how it manages the status of the boards and the timer of the two players:
The Referee:
starts player’s timer
waits for the reception of player’s move
stops player’s timer and updates the clock
validates the received move and sends it to the other player
turns back and repeat this whole process from the beginning unless - the time has expired or - it declares player’s defeat
The game ends if one of the two players loses or the arbiter declares a checkmate, tie or time exhaustion situation of one of the two players.
This is just an example of how an ESC works from a technological point of view, in the next post we will go deeper, analyzing this type of smart contract in one of its possible fields of application.