Mosaique: Decentralized Workflows

Innovation Tagline:  Decentralized business processes with built-in governance

Project Keywords:  #decentralizedworkflows #decentralizedprocesses #decentralizedgovernance #datadrivenchaincode #hyperledgerfabric #hyperledgeraries

Project Members

Name

Role

Technical Lead

  2. Dr. Atefeh Mashatan

Project Advisor

  3. Volodymyr Tanczak volodyatan@yahoo.ca

Lead Developer

  4. Aleksej Zabijakin Aleksej Zabijakin

Developer

  5. Dawson Brown

Blockchain Developer

  6. Matthew Bush

Developer

  7. Annegret Henninger

Research and Documentation

  8. Tamim Rahman

Developer

  9. Saleh Al-Sailani

Developer

 10. Manpreet Rajpal

UI Developer

 11. Adam McLennanProduct Manager
 12. Andrew LeProduct Manager
 13. Taimoor AhmadDeveloper

Project Description (no more than 1,000 words including graphics)

The goal of this project is to build a decentralized blockchain platform to support governance controlled workflows.   Blockchain technology is single transaction oriented.  This project involves demonstrating a method to provide easily designed and maintained decentralized workflows.  The workflows can represent any business process including the governance processes required to communally design and maintain the workflows themselves.  Our approach is to treat the workflows as state machines.  We will encode the state machines as a data template.  The concept is to provide workflows that can easily be changed without having to redevelop and deploy chaincode for every change in the business use case.  All that will be required is to change the data in the workflow template.  By using a state machine, we can represent each step of the workflow as a state in the state machine.  

When a workflow is being undertaken, a new state document is created to represent it.  The id for that document can be shared with other users of that instance.  For example if the workflow represents the creation, development and signing of a legal contract document, the id would be the unique identifier for that contract, and the contract data would be stored as the state data related to the workflow id.  As the workflow is progressed by the users from the start state to an end state, data is gathered and used to determine if the state machine is ready to transition from one state to another.  

The workflow template will be stored as a hierarchical JSON data structure.  The top level will represent the workflow itself and will indicate the starting state for new instances.  Each state will have:

  • State number to represent what step this is in the workflow
  • State data, that represents the data that has been input or generated 
  • Actions that are functions that are used to input or generate state data
  • Transitions that are used to determine if an action has caused a transition
  • Display objects that show state data and actions that can be interpreted as text, images, or controls
  • Roles to place restrictions on who can call the actions and what display objects they can see

Additionally, there will be a set of context data that will be used to provide specifics to the instance of a template.  Templates can be reused, so the context data can provide the specific text and images to be used for displays.  The context data can also be used for internationalization support, allowing templates to be rendered in multiple languages.

There will be two chaincode contracts.  The Template Manager for managing the templates and context data.  The State Renderer for interpreting the templates and maintaining the instances.  

Each organization that is part of the decentralized workflow process, will be required to join the Hyperledger Fabric network and be invited to the workflow channel.  They will use the Fabric SDK to integrate to the chaincode and they will provide their own UI implementation that renders the display objects into a user interface that their users can interact with.

The State Renderer will be able to call that Template Manager to have the template data changed.  This is a reflective programming way that allows the templates to be used to modify the templates.  This is handled by governance templates.  In effect, this is very similar to the chaincode lifecycle step of approval.  The difference is that it can happen at a user interface level, by business people instead of at the command line by blockchain administrators.  The governance process is encoded in workflow templates and approval to change the governance process is granted by the governance workflow templates to update the governance workflow templates.

To assist the business people who are participating in governance of the workflow, we will develop a visual template editor.  This visual editor will allow people to retrieve templates from the blockchain, review them and to suggest changes into the governance workflows.  In the governance workflow, people will be able to visually inspect the changes as a workflow diagram, before approving or rejecting the changes.  The governance rules can request a certain number of signatures to approve changes.  If they are approved, the signatures are used on the transaction to update the template data.  It will provide a permanent transparent record of when, by whom and what changes have been made to the workflows.

The reality of decentralized systems for workflows is that each party that is involved will need to integrate the workflows into their legacy systems.  They need to do that while at the same time be able to flexibly handle changes that may be made to the workflows.  This is why the State Renderer returns display objects to the caller.  It can tell that legacy system what to display, but it is agnostic to how it is displayed.  It may be in a desktop, web or mobile interface.  The display objects will return things like titles, text, lists, buttons and images.  It is up to the legacy system to render it with their own branded design elements, their own tech stack and the layout that matches their design standards.  As a reference, we will be providing several example display object renderers that will cover web and mobile interfaces.

A new implementation of the system will come with several sets of predefined templates.  

  • Test templates - templates used to test system functionality
  • Common governance - templates that provide options for common governance patterns

Problem

a. Describe the problem

Blockchain smart contracts and the decentralized systems built on them are very good at handling atomic transactions.  Where they do not provide support is in developing a workflow with a series of transactions.  A workflow needs to progress over a set of steps using rules that determine if you can change steps and to which step.  In centralized systems, this is not a problem.  You code up each step as a call and your user interface enforces the order.  In a decentralized system, you can't stop people from making the calls out of order, or force them to provide a user interface that imposes the order. 

b. Explain why existing solutions are inadequate

Existing implementations or investigations into decentralized workflows take a different approach than we have outlined here.  They are coming from existing ideas on how to manage data and services in a centralized system.  There are three approaches that we are seeing:

  1. Decentralized data access control: using a centralized interface over decentralized data to provide data orchestration between parties.  This is only partially decentralized and has no governance mechanism.
  2. Decentralized workflows using microservices: using microservices as building blocks to build up processes instead of monolithic code.  This is not decentralization in the same way that blockchain provides decentralization.
  3. Decentralized workflows using edge computing: using edge devices and services to build up workflows.  This is similar to the microservices approach but with edge services.

c. Describe the competitive landscape

There are no direct competing projects in the blockchain decentralized workflow space.  However there are other projects that have helped inform our work.

  1. Business Process Modeling Language (BPML): a way to codify business processes for visual inspection and code creation.  https://en.wikipedia.org/wiki/Business_Process_Modeling_Language
  2. Satori Decentralized Data Access Workflows: a decentralized approach to data orchestration. https://satoricyber.com/decentralized-data-access-workflows/
  3. Example Academic papers:  https://www.sciencedirect.com/science/article/pii/S1389128621005363?via%3Dihub  https://ieeexplore.ieee.org/document/8397424

Solution

a. Describe the solution

To provide decentralized workflows, we need four things.  

  1. A method for ensuring that the rules of the workflow steps are enforced.
  2. A way for users in decentralized systems to be able to follow the workflow steps in a user interface.
  3. A decentralized governance system to adopt and enhance the workflow.
  4. Decentralized identity to ensure that subjects match their roles in the workflow

Our proposed solution uses a state machine to represent the workflow.  The state machine will be stored as a template in JSON notation.  The JSON data will be stored as immutable state data in a Hyperledger Fabric document.  The system will use chaincode to read the template, interpret the current state and user role, and render the display objects to pass to the user.  The display objects will be in a JSON format and will be treated as display content without stipulating a display layout.  The resulting layout, for users, is up to the systems that the various software architects design when integrating to the workflow.  The control over changes to the workflow templates will be enforced by decentralized governance.  The decentralized governance will use the system's workflow templates to debate and authorize changes to all templates, including the governance templates.  In effect, the governance is bootstrapped using the workflow templates.  We will integrate verifiable credentials using Hyperledger Aries and Hyperledger Indy to ensure that onboarded users are eligible for the roles they are assigned.

b. Explain why your solution is better than current state-of-the-art or existing solutions

In this solution, we enable workflows that can be represented visually.  Visual representation allows for deeper engagement in understanding the workflow automation by the governance members.  No programming skills will be required to interpret and modify workflows.  It allows each participating organization in the workflow to integrate it into their own user interfaces, and it provides a tightly bound governance workflow that controls the workflows being governed. 

Our system is built on the ideal of full decentralization.  Once a decentralized governance organization selects our system and forks and sets up the open-source code, they are no longer reliant on us.  There is no central point of failure.  All control happens through the decentralized workflows of the decentralized governance organization.  No other projects have adopted this approach, probably since this is first time decentralized blockchain workflows have been available for it to work.

c. Define the minimum viable product and what you anticipate will be developed during the prototype phase

A completed system will provide:

  • Workflow template examples
  • A visual editor for creating and modifying templates
  • Chaincode to interpret and enforce the workflow templates
  • Sample rendering modules that can be used for various popular platforms for web and mobile development
  • Several sets of governance templates based on common governance models that can be used as the starting point for any new decentralized workflow system.
  • Ability to use verifiable credentials to ensure that people, organizations or devices match the roles that they would like to engage in the workflow.

For the prototype phase we would like to accomplish:

  • Workflow template examples
  • A visual editor for creating and modifying templates
  • Javascript engine to interpret and enforce the workflow templates
  • Sample rendering modules for React.js and React Native.

Accomplishment and Team

a. Brag about your team

Dave McKay is the Technical Lead at the Cybersecurity Research Lab (CRL) at Ryerson University. Lab. He brings 35 years of software development management to his role with CRL. He is the lead on all development and technical aspects of the research project. Additionally, he is a professor for the Blockchain Development Program at George Brown College. He has held several Fractional CTO positions for companies in the blockchain and healthcare sectors. Dave has made contributions to the technology and adoption of Self-sovereign Identity systems. He is the Co-chair of the Innovation Experts Committee of the Digital Identity and Authentication Council of Canada (DIACC) and sits on the Technology Stack Working Group and the Utility Foundry Working Group of the Trust Over IP Foundation (ToIP). Dave is a reviewer for the CIO Strategy Council of Canada and reviews and comments on specifications surrounding healthcare, identity, and verifiable credentials.

Dr. Atefeh (Atty) Mashatan is the founder and director of the Cybersecurity Research Lab (CRL) at Ryerson University and recognized as a leading expert in cryptography, blockchain technology, quantum-resistant solutions, enterprise security architecture and Internet-of-Things (IoT) security. Professor Mashatan is holding a Canada Research Chair (Tier II) in Quality of Security (QoS) Framework for Internet-of-Things (IoT). She will address new threats that have arisen with the widespread adoption of IoT, create new security systems for these networks, and recommend best practices for users, technical audiences and policy-makers. Mashatan’s expertise at the frontlines of the global cybersecurity field was recognized by SC Magazine in 2019, when she was named one of the top five Women of Influence in Security. She was recognized as one of Canada’s Top 19 of 2019 Tech Titans at IBM CASCON Evoke conference for her efforts in developing emerging technological solutions to address timely societal needs. In 2020, she received the Enterprise Blockchain Award in the category of New Frontiers in Blockchain Academic Research by Blockchain Research Institute for developing the Mosaïque Digital Wallet, which is a fully decentralized identity management system for business environments. Most recently, she received the recognition of Top Women in Cybersecurity in Canada for her efforts in advancing cybersecurity research and training highly qualified personnel in the field. Dr. Mashatan has an Erdős Number of 2! This is the best a researcher can achieve since 1996 when Paul Erdős passed away.

b. Identify talent/resource gaps and needs (Do you need more support developing the blockchain solution? Do you need support with front end development? Do you need support developing the business model?)

To fully realize the potential of this project, we will need to bring on subject matter experts who have designed workflows and organizational processes for industries that are suitable for blockchain solutions.  This could be real estate, insurance, finance, supply chain, or trade.

Project Plan

a. Define the goals for prototype and launch phases and a one-year goal

Phase

Goal

Description

Prototype

Template format

A defined JSON data structure that will hold the workflow, state, role, transition, state data, and display object definitions


Instance data format

A defined JSON data structure that will hold instance and language specific data


Template parser

A Node.js parser that translates the template and instance data for a specific state, role, and  instance into display objects.


Basic display objects

A basic set of display objects including: header, title, text, body, list, action button, image, notification.


Display render Node.js/React.js

A simple module to interact with a workflow instance and render display objects in a React.js web application.


Test templates

A set of templates and associated instance data to test out display objects and transition logic,

Launch

Visual template builder

A browser-based visual editor for creating workflows that are translated into JSON structures.


Blockchain parser

Move the parser from Node.js to Hyperledger Fabric chaincode


React Native render

A simple module to interact with a workflow instance and render display objects in a React Native mobile application.


Governance templates

A set of templates for a simple governance workflow to act as a starting point to the decentralized governance of new workflows


More display objects

Addition of unforeseen display objects that are required to implement the governance templates

One-year

Three governance template sets

Three different governance models, represented in sets of workflow templates, that can be used to start a decentralized governance organization


Two industry workflow sets

Two industry use cases with a set of templates that encompass decentralized governed decentralized workflows


SSI for role verification

Integrate Hyperledger Aries to handle decentralized role verification

b. Provide a high level plan to meet your goals

Our goals are based on the dependencies within this technological approach.  We need the templates before we can parse them, we need to parse before we can render.  We will build simple templates to start and add new capabilities as our use cases demand them.  As the templates become more complicated, we will introduce a visual editor to manage them.  The visual editor will allow for non-developers to be able to contribute directly to the development of the system. The visual editor will be integrated directly to the template governance workflow.

Every part of this system is integrated to the others and the dependencies become the strength of this self-reflective system.  To meet our goals, we have set a critical path that gets us to the simplest version of a fully working system.  Then we add new features to it based on the business requirements from the workflows we will be modeling.  We are basically boot-strapping the system up from a basic set of hand-coded templates.

c. Describe development risks and mitigation strategies

Risks and Mitigation Strategies

Visual editor tools

We would like to build an open source visual editor that can be used by participants in the workflow governance organization to visually create and inspect changes to workflows.  This requires an open source flowchart editor that can be used to integrate to our system.  We have taken a preliminary look at some existing projects under React.js.  They look like they could work for us.  However, if they don't then we will have to look at Angular, Vue.js, and plain Javascript open-source projects to build the editor.  Another option would be to create a desktop version.  Without the visual editor, large templates will become very cumbersome to work with. 

Blockchain complexity

We have selected Hyperledger Fabric as our first blockchain to work with.  Fabric is a very sophisticated enterprise grade blockchain.  To test smart contracts on it, one is required to package them up, install the package, approve it across a majority of the anchor peer nodes, and then instantiate it.  This multistep process slows down initial chaincode development.  

Our approach will be to develop the renderer code off-chain in a stand alone Node.js environment using a NoSQL database to represent the ledger.  Once we have worked out all of the logic of the renderer, we can move it into chaincode and work out the issues related to reading and writing within the blockchain environment.

SSI integration

Our workflows support roles in the state machine to determine who can invoke actions that may trigger a transition.  Since the system is decentralized, roles need to be assigned by the different organizations participating in the channel.  To ensure that the rules around role eligibility are enforced across the organizations, we have selected Hyperledger Aries and its support of verifiable credentials as a way of ensuring trust in role participation.  The risk here is that from a cursory search, we have not found any projects that use VCs with chaincode.  We suspect that there is not a simple way, outside of an oracle, to have the chaincode be able to continuously verify if a credential has been revoked.  A mitigation to this possible problem is to require re-authentication at regular intervals.  We see this as providing a poor user experience and could complicate existing workflow processes.  We will reach out to the new discord channels to see if there are others who are approaching this problem.