by Debora Elia
In this article we introduce our approach to smart legal contract [1] that we call Expressive Smart Contract.
This is a new way of writing and executing smart legal contracts that enables people with basic IT background to understand, maintain and implement smart contracts.
OUR APPROACH
Our approach relies on smart contracts based on process collaboration diagrams in BPMN 2.0 standard.
We have chosen BPMN (Business Process Model and Notation), that is a graphical language as our lingua fanca, to facilitate readability and understandability, in order to fill the gap between lawyers, business users and developers.
Following BPMN standard 2 specifications, we have chosen a two-level approach, descriptive and executable, so that the business user (or just non-developer) can design the descriptive and, with adequate training, the executable parts of an ESC.
EXPRESSIVE SMART CONTRACT
Let’s explore some features of ESC, represented as BPMN model:
it can regulate the execution of all contractual obligations, as if it were an “operational copy” of the text of the contract, to be attached to and signed with the traditional contract. In this way we embed, in a single framework, actions (obligations) that can be executed by code and those that must necessarily be carried by humans;
it allows a great flexibility. In fact, if the parties had to update operational parts or the process that regulates the obligations execution, it would be possible to create a new, versionable ESC, avoiding the involvement of lawyers as it would have happened for traditional contracts;
it is self-documenting and self-consistent. Every step in the process can be documented in order to explain in plain text and in detail the execution agreed by parties.
We work using collaboration processes, that make explicit the role of participants and their interactions. In this framework, each party of the contract is responsible for executing its own part of the process, and the parties communicate via messages.
AN ESC IN PRACTICE
Below we have a simplified example of an e-commerce operation designed as an ESC, where the two parties are the customer and the retailer:
This is a high-level description, where exceptions are not included, and it does not provide any information on how the messages are exchanged.
This is a typical BPMN collaboration made by tasks (rectangles) and interactions ( dashed lines).
Message flows among participants show their interactions. In this example, the customer sends an order to the retailer, that starts its management process upon the reception of the message.
Interactions and tasks describe the execution of the obligations deriving from the traditional contract.
All the activities and the messages that must be executed are agreed upon between parties as shown by a signed contract and deployed on a workflow engine for the execution.
ESC IN A MULTIPLAYER ENVIRONMENT
In the previous example, the ESC contains two actors. We can now add other parties interested in this process such as a manufacturer and a carrier. As an example, we assume that the buyer, before receiving the package, receives a confirmation message from the carrier who takes care of the shipment, with the notification of the delivery.
In this case, the ESC can involve a number of actors, in a multiplayer environment.
In this case, there are two more pools, one for the manufacturer and one for the carrier.
Once the process “online order” is complete, the ESC regulates in a synchronized way the execution of the obligations arising from three different legal transactions, in a perspective of economy and efficiency of the business operation.
In our example ESC relies on 3 different contracts:
Sale of goods, between Customer and Retailer
Supply of goods, between Retailer and Manufacturer
Shipping, between Retailer and Carrier.
The obligations deriving from these agreements are collected in a single smart contract involving all the parties where obligations are disclosed among them in a transparent way.
BPMN process execution must support a detailed play back in a not repudiable way. In this way, disagreements can be efficiently solved with human or machine intervention. The goal is reached by associating the workflow engine execution with a blockchain that stores and certifies the execution of various process steps.
Each message, completed task or executed event is recorded on the blockchain with a time-stamp. The result is a decentralized (parties are peers), certified (notarized execution), distributed (multi node executions) workflow engine.
When known in advance, exceptions are included in the workflow, while when an unexpected one appears, we embed the role of human arbitrators in the workflow, so that they can intervene transparently in the process and handle any exception in order to solve contract breaches.
In case an exception arises, thanks to the rollback feature, arbitrators will find easier to agree on the handling of the exception or to assign responsibilities, based on an incontrovertible manifestation of the reality of the facts..
STRENGHTS AND LIMITS
The expressiveness of this language is its strength and limit. As a matter of fact, with such a graphical and clear language, in the event that exceptions occur, language economy compared to other programming languages can be lost (the ESC equivalent of what could be written in Python in a few lines could result graphically complex).
Following this high-level overview of the platform, we will describe in another post the technology of ESC.
[1] C.D.Clack, V.A.Bakshi and L.Braine, 2016/08/02, Smart Contract Templates: foundations, design landscape and research directions,. Arxiv:1608.00771. 2016 https://www.researchgate.net/publication/305779577_Smart_Contract_Templates_foundations_design_landscape_and_research_directions_CDClack_VABakshi_and_LBraine_arxiv160800771_2016
Comments