Blockchain Rules Engine
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-03-01
- Publication Date
- 2026-03-10
Smart Images
Figure 00000000_0000_ABST
Abstract
Description
[Technical field]
[0001] This application relates to a rules engine for implementing business processes on a blockchain, and in particular to a blockchain rules engine implemented as a pluggable service for use in blockchain and non-blockchain applications. [Background technology]
[0002] Rules play a vital and important role in any process or system. They are the foundation on which business processes evolve. Rules can have different origins, such as legal regulations, company policies, or organizations or groups that involve processes and people. Rules are typically implemented as logic that determines an outcome. Rules may be used to execute decisions or may be calculated based on events, priority scores, or other functions.
[0003] Rules have been a part of technology systems and applications since their inception. In first generation systems and applications, business rules comprised part of the system or application code base where all decisions, calculations, and conditions were executed. As rules became more complex and took up a large portion of the code base, rule engines were introduced in products from Pegasystems, Fair Isaac Corporation, and ILOG in the early 1990s. Rule engines are separate systems or applications that enable accurate decision making and are especially useful for complex dependencies where regulations or organizational rules change frequently, requiring changes to the logic. Separate rule engines provide an easy way to add new rules, edit rules, and disable rules.
[0004] Existing rule engine platforms have evolved from just rules to orchestrated rule engines that are easy and quick to manage and consume. Unfortunately, existing rule engines do not fit the blockchain paradigm, and rules and transactions from them can only be locked into the blockchain by the intent of the developer. Summary of the Invention
[0005] The systems and methods described herein address a need in the art by providing a blockchain rules engine as a pluggable service that depicts a real-world implementation of a rules engine that stores rules, transactions, and results on a blockchain for use by blockchain and non-blockchain applications. The blockchain rules engine manages rules implemented by client applications that interact with a blockchain platform that manages blockchains. The blockchain rules engine includes a language-specific software developer kit (SDK) that provides an interface to the client applications and exposes rule execution capabilities to the client applications, a rules engine application programming interface (API) layer that provides a rules engine API to the language-specific SDK and receives and processes commands from the language-specific SDK, and a blockchain platform-specific services layer that interacts with a blockchain platform and accepts input from the rules engine API layer to execute business logic implemented in the rules. Data operations are managed jointly by the blockchain platform-specific services layer and the blockchain platform.
[0006] In a sample configuration, the blockchain platform specific services layer includes a JavaScript Object Notation (JSON) condition parser that parses and evaluates conditions present on objects to which rules are applied. Each instance of each type of feature supported by the blockchain rules engine is represented by a JSON document in a standard blockchain rules engine format, and each JSON document is written to the blockchain using the same method and consensus as other blockchain transactions. Each modification or state change to each type of feature is represented by adding a complete updated version of the JSON document for the modified feature to the blockchain.
[0007] In another sample configuration, a language-specific SDK provides an interface that allows a client application to access rule execution functionality by a blockchain application developed in a programming language supported by the language-specific SDK. Additionally, the interface provided by a rules engine API layer supports multi-tenancy and multi-application for interfacing with the blockchain rules engine. The rules engine API layer further accepts rules syntax and logic commands for the blockchain rules engine from the language-specific SDK or via a user interface console. The rules engine API layer also converts syntax and logic commands into a format that can be passed to the blockchain platform-specific services layer via an interface to the blockchain platform-specific services layer implemented on the blockchain platform.
[0008] In yet another sample configuration, a blockchain platform specific services layer describes functionality in addition to interfaces to be supported in all realizations of said blockchain rules engine, including a subset of features and functions that may be implemented either in a blockchain platform specific services layer or on a blockchain platform, In the sample configuration, the functionality includes at least one of creating a function, updating a function, deleting a function, creating a rule, updating a rule, deleting a rule, activating and deactivating a rule, importing and exporting a rule, or rolling back a rule.
[0009] In a further sample configuration, a condition parser in the blockchain platform specific surface layer parses pre-processor functions and post-processor functions for execution and storage of processing results on the blockchain. The pre-processor functions and post-processor functions may be linked with rules to modify the behavior of the pre-processor functions and post-processor functions. The post-processor functions may include at least one of an on-pass post-processor function or an on-fail post-processor function that is executed after a rule is executed and a pass or fail result is generated by the executed rule.
[0010] In a further sample configuration, the blockchain platform, the blockchain platform specific services layer provides functionality implemented directly on the blockchain platform for rule-related functions used by smart contracts on the blockchain platform. Different rule execution functions may apply to different data objects, which may include at least one of a tenant, an application, a rule group, a function, or a rule. Each instance of each type of rule execution function may be represented by a JSON document in a format common to each type of rule execution function. Also, each JSON document may be written to the blockchain using the same method and consensus as other blockchain transactions. Each modification or state change to a rule execution function is represented by appending a complete updated version of a JSON document for the type of rule execution function to the blockchain.
[0011] In a further sample configuration, a blockchain rule engine specification is provided outlining syntax, interfaces, and requirements that enable dynamic creation, modification, and deletion of rules in applications leveraging the rule engine API in client applications, and outlining how the blockchain rule engine stores Rule Data on the blockchain. The blockchain rule engine specification may specify how the blockchain rule engine stores a set of instructions that are executed prior to rule execution on the blockchain. The blockchain rule engine specification may also implement multi-tenancy on the blockchain by allowing multiple tenants to create and manage rules and store credential data and rule functions on the blockchain. The blockchain rule engine specification may further incorporate multiple levels of access control, whereby to perform any operation on a rule, the client application provides the client application's credentials as well as the tenant's credentials. The blockchain rule engine specification may also provide an application level hierarchy supported by the blockchain rule engine to allow the client application to utilize rule execution functions that can use created rules and functions and store credentials and metadata on the blockchain. The blockchain rule engine specification may also implement plugins for communication between blockchain applications and the blockchain rule engine to establish inter-chain code communication and establish connections for non-blockchain applications. Further, the blockchain rule engine specification may provide the client application with the ability to execute created rules by providing functionality for creating a connection between the client application and the blockchain rule engine to perform rule execution.The blockchain rules engine specification may also consist of a set of function interfaces that define functions directly available to client application code, and function implementation code that implements the function interfaces by translating calls to the blockchain rules engine specification into calls to the rules engine API.
[0012] The embodiments described herein also encompass computer systems and computer readable media encoded with instructions for performing the methods described throughout this disclosure. For example, the systems and methods described herein are implemented on a computer platform in a cloud to provide functionality for accessing and storing data on a blockchain platform as described herein. [Brief description of the drawings]
[0013] The present disclosure is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings. [Figure 1] FIG. 1 is a general block diagram providing an overview of a blockchain rules engine in an illustrative example. [Diagram 2] Figure 2 is a detailed component diagram of a sample configuration implementation of a blockchain rules engine. [Diagram 3] FIG. 3 is a perspective view of the Rule Data system object of the blockchain rules engine in a sample implementation. [Figure 4] FIG. 4 illustrates a user application node that includes the interaction between the Fabric-Node.js SDK of the blockchain rules engine and a user application and the execution environment in which both are hosted. [Diagram 5]FIG. 5 is a block diagram of an exemplary general-purpose computer that may be programmed into a special-purpose computer suitable for implementing one or more embodiments of the blockchain rules engine disclosed herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0014] The following description of Figures 1-5 sufficiently illustrates certain embodiments to enable one of ordinary skill in the art to practice them. Other embodiments may incorporate structural, logical, process, and other changes. Portions and features of some embodiments may be included in or substituted for other embodiments. The embodiments set forth in the claims encompass all available equivalents of those claims.
[0015] Glossary Application: An application is a component (service, tool) that can connect to the Blockchain Rules Engine and utilize its functions. Applications are created and managed by tenants. Applications, like tenants, have their own ID and secret. To perform any operation on rules or functions, tenants also need to provide an application ID (not an application secret). This is because rules and functions do not belong directly to tenants, but to applications that are directly owned by tenants. The reason why CRUD (create, read, update, delete) operations on rules and functions do not use an application secret is because these operations are initiated by tenants, not by the application itself. However, rule execution is initiated directly by applications and requires an application secret.
[0016] Blockchain: A continually growing list of records, called blocks, are linked and secured using cryptography. Each block typically contains a cryptographic hash of the previous block, a timestamp, and the transaction data. Blockchains are designed to be inherently resistant to tampering with transaction data. When used as a distributed ledger, blockchains are typically managed by a peer-to-peer network that collectively adheres to a protocol for validating new blocks. Once recorded, the data in a block cannot be changed retroactively without changing all subsequent blocks.
[0017] Functions: A function is a set of instructions in JSON logical syntax present within a rule. While creating a rule, a tenant can either reference an already created function (created using a dedicated endpoint) in the rule body or write a function directly in the rule body. The purpose of a function can be better understood by learning about its types. There are two types of functions:
[0018] Preprocessor Functions: A rule's preprocessor function is a preprocessor before the transaction object is fed to a rule. It can be used in scenarios where a transaction object does not immediately have the data required for rule execution, but contains links to that data. In such cases, a preprocessor function can be used to convert the links to the data into actual data. The transaction object can then be fed to a rule.
[0019] Post-processor functions: A rule can have one on-path post-processor function and one on-fail post-processor function. These functions contain the instructions that are returned to the application after the rule is executed. When a transaction object is sent to the blockchain rule engine for rule execution, all rules with the same "transaction type" value as the transaction object are executed against it. If a rule fails, its failure post-processor is pushed as a response, if it passes, it is pushed to the pass post-processor. Once all the rules have been executed, a complete response object (containing the on-fail post-processor and the array response of the on-path post-processors) is returned to the consuming application.
[0020] Node.js®: A free, open-source server environment that runs Java Script code outside of the browser. Node.js® is an asynchronous programming platform built on the JavaScript runtime of the Chrome browser. For more information about Node.js®, see About Node.js (Node.js, Node.js Foundation). Node.js® and JSON are the technologies and standards involved in the blockchain aspects of the Blockchain Rules Engine. Node.js® is a free, open-source server environment that runs Java Script code outside of the browser. Node.js® is an asynchronous programming platform built on the JavaScript runtime of the Chrome browser.
[0021] Platform Administrator: A tenant of the blockchain rules engine must first be registered to create and manage applications, rules, and functions. The platform administrator role, specially designed for this purpose, only has the authority to create and manage tenants in the blockchain rules engine.
[0022] Rule: A rule is an object that contains certain conditions, functions, and transaction types. Tenants can create rules using endpoints provided by the Blockchain Rules Engine (through software development kits (SDKs)). Rules can be applied to transaction objects, where "applying" means matching said transaction objects with the conditions contained in said rule.
[0023] Smart Contract: A computer protocol that provides general-purpose computations that take place on the blockchain or distributed ledger. Smart contract transactions can be simple or implement sophisticated logic. The resulting transactions are typically transparent to ledger participants, traceable, and irreversible.
[0024] Tenant: A tenant represents any client (organization) using the Blockchain Rules Engine. A tenant has an ID and a secret, which are used for CRUD operations of applications, functions, and rules. Tenants are registered by the platform administrator in the Blockchain Rules Engine.
[0025] Transaction: A JavaScript object with a "transaction type" key that is used to determine which rules to apply. A transaction object contains the data on which rules are applied to produce a result. The data in the transaction object is first modified by a pre-processor function (contained in the rule) before the rule is executed. Transaction objects are so named because they are built around the concept that the blockchain rules engine maintains a hierarchy at the transaction level. A transaction object can have any data as long as it contains the "transaction type" key as a top-level property.
[0026] Transaction Types: A transaction type represents a grouping of multiple rules that are intended to be executed together for a transaction. The classification feature of transaction types makes the management of said rules in the database easier and more intuitive.
[0027] Designers of computer applications, especially in large enterprise environments, are increasingly incorporating existing distributed ledger technology (DLT) platforms into their solutions. These platforms offer strict data replication, rule enforcement, immutability and auditability, but often require specialized skills to program and operate. The abstraction of communication with nearby DLT nodes (including writing data and rules against that data), combined with a set of data and rule primitives that support a wide range of potential DLT applications in the category, allows for subsystems that enable the creation and operation of client applications by developers without specialized skills in the chosen platform. The primitives are typically built in such a way that application developers can adapt them to their specific use cases and extend them with attributes and additional data rules without requiring any technical knowledge of the DLT platform or losing the strict rule enforcement that the DLT platform provides. Additionally, the interfaces through which client application developers design and utilize these primitives must completely abstract away the need for any technical understanding of said DLT platform.
[0028] A specific implementation may be a dedicated subsystem of a single client application, a reusable component for use by multiple client applications, or a service providing application enablement for multiple client applications. Other implementations may mediate communication with one or more nearby DLT nodes, which may be drawn from a single or multiple DLT networks.
[0029] The example subsystem may enable indirect use of the Hyperledger Fabric DLT platform for a broad range of categories or hypothetical workflow and information sharing applications, and several operational real-world realizations of such client applications. There are three main requirements for implementing such a subsystem: 1. An extensible set of generic data and action primitives represented on a distributed ledger 2. A set of rules built into the distributed ledger that operates on these primitives and enforces both the subsystem's specific data rules and permissible extensions of these rules that may be provided by client applications. 3. Programming interface that can be operated without knowledge of the DLT platform This subsystem provides a set of tools and libraries that allow general users with knowledge of a given application category and skills in DLT platforms to build their own subsystems supporting the creation of client applications for that category. The resulting code is implemented as middleware between the API network and the blockchain protocol, allowing users to interface with the blockchain in a consistent manner without extensive knowledge of blockchain operations. In such applications, use-case specific business rules are written from a higher layer and are enforceable on the blockchain. New business rules need to be added from time to time to update the workflow without interrupting the functionality and control of the blockchain.
[0030] A rule engine provides an easy way to add new rules to such subsystems, and to edit or disable rules. The value of a rule engine is that it essentially decouples the rules from the application code. In addition to decoupling, a rule engine allows the rules to be easily configured without affecting the associated expert system.
[0031] Some of the principles that the rule engine adheres to are:
[0032] 1. The rule engine should be highly "pluggable and reusable" - that is, it can be integrated with any external application and used by multiple applications. Business logic can be shared across different processes and client applications.
[0033] 2. The rule engine should be "scalable", i.e., it should be possible to configure any number of rules of any kind of complexity.
[0034] 3. The rules engine must be highly "efficient" to facilitate quick, easy, and accurate rule changes. Make the rules engine cost-effective by allowing non-IT professionals to configure (add, edit, delete, disable) rules in a short time.
[0035] 4. The rule engine should act as the "source of truth". That is, all the business rules and logic of an application process or system should be kept in one central storage. The blockchain rule engine described below realizes all of these principles.
[0036] The current vigor around blockchain adoption is reminiscent of the early adoption of the internet. As applications and systems mature, they may repeat or avoid the same mistakes that burdened them with managing logic. Like early websites and applications, cryptocurrency's use of blockchain was characterized by relatively simple data structures and hard-coded business logic to manage them. But the subsequent invention of "smart contracts" opened the door to rules and data of arbitrary complexity.
[0037] Enterprise use cases like supply chain logistics are putting a comparable amount of information and logic on the blockchain to traditional solutions, yet there are no standardized data management tools. Every programmer designs their own set of logic within their application code base, and as a result, the logic is again tightly coupled to the programs (smart contracts) that write it. To reduce this coupling, a relational layer like the Blockchain Rules Engine described here is needed.
[0038] Those skilled in the art will recognize that not all features of blockchain need to be used in enterprise applications. A common scenario is to use a blockchain platform as a convenient way to achieve features like cryptographic tamper proofing or data replication. Enterprises may also choose to implement a blockchain network under their full control, relaxing the consensus rules and / or centralizing the front end. They may use a trusted consortium that builds the blockchain network with strict smart contract enforcement for support staff, allowing administrators and internal auditors to update the blockchain data directly with their own authority.
[0039] Transactional and decision data stored in a smart contract have greater value in applications. Rule results and functions stored in the blockchain can be subsequently used in other functions and logic without being governed by consensus, making operations fast, efficient, and reliable. The only requirement is access to use said rule results and functions stored in the blockchain. It will be appreciated that said rules and functions stored in the blockchain can be efficiently read and processed by applications, rules, functions, or systems, whether inside or outside the blockchain, for purposes beyond those envisioned by the original smart contract programmer. EXAMPLES
[0040] Blockchain Rules Engine Example The blockchain rules engine described herein is a pluggable service that stores rules, their transactions, and results on a blockchain and represents a real-world implementation of a rules engine that provides the benefits described above. Developed for a specific business realization, said blockchain rules engine is a pluggable service that can be leveraged for blockchain as well as non-blockchain applications.
[0041] With an SDK developed as a Node Package Manager (NPM) package, the sample configuration blockchain rules engine can be used with any Node.js application, resulting in a highly configurable rules engine that can be integrated with almost any application. The blockchain rules engine described herein is designed for implementation in a variety of platforms and languages. This application describes one such implementation based on Hyperledger Fabric and the Node.js programming language. As will be appreciated by those skilled in the art, Hyperledger Fabric is an enterprise-grade permissioned distributed ledger platform that offers modularity and versatility for a wide range of industry use cases.
[0042] The blockchain rules engine is described in terms of a set of specifications, interfaces, and core components intended to guide all implementations. Figure 1 is a general block diagram providing an overview of the blockchain rules engine in an illustrative example.
[0043] A blockchain rules engine can be implemented in a variety of user programming languages and blockchain platforms. Some parts of the system are common to all implementations, and some are customized, but they follow a set of common specifications. Figure 1 is a conformance component diagram showing these components and specifications. Common specifications are represented as components with a "specification" stereotype, which indicates an abstract requirement. Specifications are aspects that are expected to be implemented in a common way across all blockchain rules engine implementations. The interfaces shown are also specifications that are common to all implementations.
[0044] As shown in FIG. 1, the blockchain rules engine interacts with a client application 100 that wishes to utilize the blockchain rules engine. The client application 100 may be any third-party application, service, or tool. A language-specific SDK 110 provides an interface 115 for the client application 100 to connect to the blockchain rules engine's services. The main functionality exposed by the language-specific SDK 110 is the rule execution functionality. A blockchain rules engine API layer 120 provides a rules engine API 125 that receives and processes commands from the language-specific SDK 110 and communicates with internal components to generate desired results. A blockchain platform specific services layer 130 is designed to work with a blockchain system (Hyperledger Fabric in this example) and accepts input from the rules engine API layer 120 through the rules engine services layer interface 135 to execute business logic. To parse and evaluate the conditions present in the rule objects, the blockchain platform specific services layer 130 may utilize a module called a JSON condition parser 140.
[0045] Data operations in the system are managed jointly by the Blockchain Platform Specific Services Layer 130 and the Blockchain Platform 150. The exact division of labor depends on the capabilities of the Blockchain Platform 150. The required functionality is given in further detail by two sub-specifications: Rule Data on Blockchain 155 defines the standardized data representation (JSON Schema) and the data operations that must be supported, and Smart Contract Integration 160 specifies which Rule Data functions must be accessible from smart contracts.
[0046] Blockchain Rules Engine Language-specific SDK110 Each of the blockchain rule engine language-specific SDKs 110 provides an interface for any blockchain application developed in a programming language popular with blockchain application developers (Node.js) to access all functionality (rule execution functionality) of the blockchain rule engine. The blockchain rule engine language-specific SDKs 110 are Node Package Manager (NPM) packages that are imported by Node.js applications to establish an interface with the blockchain rule engine and initiate rule execution requests from the client applications 100 that are interfaced therewith.
[0047] Blockchain Rules Engine API Layer 120 and UI Console One of the core components of the blockchain rules engine is the blockchain rules engine API layer 120, which is used in all realizations of the blockchain rules engine. The blockchain rules engine API layer 120 provides an interactive and intuitive user interface to support multi-tenant and multi-application interfacing with the blockchain rules engine. The blockchain rules engine API layer 120 also provides compilation and summary of constructed rules through a user interface console (not shown). The blockchain rules engine API layer 120 also accepts blockchain rules engine rule syntax and logic commands through the blockchain rules engine API layer 120 originating from the language-specific SDKs 110 or through a user interface console. The blockchain rules engine API layer 120 converts these syntax and logic commands into a format that can be passed to the blockchain rules engine service layer interface 135 implemented on the blockchain platform 150.
[0048] Blockchain Rules Engine Multi-tenant functionality The Blockchain Rules Engine is multi-tenant in that it allows the same Blockchain Rules Engine instance to be used by multiple applications. This tool allows multiple applications within an enterprise or ecosystem to build the most complex and powerful rules, which allows the enterprise or ecosystem to enable business logic interactions within all applications that it interfaces with. The Blockchain Rules Engine's multi-tenant remote access and virtualization capabilities provide more control and flexibility to applications that use the Blockchain Rules Engine. The Blockchain Rules Engine's multi-tenant capabilities also allow virtualization and remote access capabilities to be fully used within an enterprise.
[0049] Blockchain Rules Engine Service Layer Specification 130 The blockchain rules engine service layer specification 130 describes the interfaces as well as the functionality supported in all realizations of the blockchain rules engine. In addition to covering the entire interface, this specification also covers a subset of features and functionality that may be implemented in either the blockchain rules engine service layer 130 or the blockchain platform 150 itself. These features include: Creating a function Function updates -Function deletion · Rule creation Rule Updates Delete a rule Enabling and disabling rules Import and export rules · Rule rollback
[0050] The blockchain rules engine services layer 130 is implemented in Node.js and is reusable regardless of the target SDK language or blockchain platform 150. Additional functionality may be targeted to the blockchain platform 150 itself, as described with respect to the blockchain platform specification below.
[0051] Store and use blockchain rules engine functionality The Blockchain Rules Engine further provides the ability to store functions inside the blockchain. These functions are of two types: pre-processor functions and post-processor functions. These functions are described using a special JSON format, which the Blockchain Rules Engine parses and executes.
[0052] These functions can be linked to a rule to modify its behavior: a linked pre-processor function can be used to modify the input (from the client) of said rule.
[0053] There are two types of post-processor functions: on-pass and on-fail. As the name suggests, these functions come into play after the rule has been executed and a result (pass or fail) has been generated. Depending on the result, the corresponding post-processor function is returned to the caller, who can then execute it at the end. Figure 2 below further explains these concepts. EXAMPLES
[0054] Example of a blockchain rules engine configuration in FABRIC / NODEJS Figure 2 is a detailed components diagram of an example implementation of a blockchain rules engine 200. Node.js is the SDK programming language used by the Language Specific SDK 110, and Hyperledger Fabric is the blockchain platform 150 used. The Figure 2 model of the blockchain rules engine 200 focuses on how a Fabric / Node.js implementation realizes the specifications outlined in Figure 1, along with some additional features.
[0055] A blockchain rules engine Node.js software developer kit (SDK) component 210 implements the user language specific functionality. The rules engine API layer 120, blockchain platform specific services layer 130, and interfaces 115, 125, 135 are the same as in FIG. 1 and are common to all implementations. Below that, the blockchain rules engine Node.js Fabric services layer 220 implements a facade for all platform operations. Directly supporting the blockchain rules engine Node.js Fabric services layer 220 through its reliance on the blockchain platform specification 150 is a Fabric CouchDB Implementation 230, which is directly accessed for certain indexing functions. In a Fabric implementation, schema index changes and user permissions are partially implemented in the blockchain rules engine Node.js Fabric services layer 220, which directly calls the Fabric CouchDB Implementation 230.
[0056] Fabric Peer240 hosts the ledger and smart contract instances for the blockchain network. The ledger immutably records all transactions generated by smart contracts (which in Hyperledger Fabric are called chaincodes or smart contracts, pieces of code that access the ledger and are written in a supported programming language). Smart contracts and ledgers are used to encapsulate shared processes and information in the network, respectively. Through Fabric Peer240, applications can run chaincodes and query and update the ledger.
[0057] Blockchain Rules Engine Blockchain Platform Specification 150 The Blockchain Rules Engine Blockchain Platform Specification 150 describes the functionality that must be implemented directly on a blockchain platform to enable rule-related functionality to be used by smart contracts on that blockchain platform. Like the blockchain platforms themselves, these implementations vary widely in approach. These specifications define commonalities such as a common JSON-based data format for condition data and schemas. The specifications are split into two categories: Rule Data on the blockchain and the integration of smart contracts.
[0058] The main assets of the blockchain rules engine 200 are its rules. The blockchain rules engine 200 employs a certain number of abstractions within the data to realize its stated functionality. These abstractions are defined as objects including tenants, applications, rule groups, functions, and rules. Different blockchain platforms vary greatly in how they implement these concepts, but the following is true across platforms: -Each instance of the five function types is represented as an independent JSON document in a standard Blockchain Rules Engine format that is common to each function type. -These documents are written to the blockchain using the same methods and consensus as other blockchain transactions. -Any modification or state change to one of these elements is represented by adding a complete updated JSON document to the blockchain. The blockchain rules engine 200 design formally specifies in detail the JSON Schema definitions of five types of objects:
[0059] Smart Contract Integration Specification 160 An important aspect of the blockchain rules engine 200 is that most of the rule functionality (mainly CRUD operations on the objects mentioned above) can be accessed directly from smart contracts. Similar to the SDK, a formal specification enumerates the functionality that must be supported and provides the preferred format, naming, and semantics to maximize consistency between blockchain platform implementations. In other words, access to the blockchain rules engine 200 from smart contracts will be as consistent as possible between different blockchain platform implementations.
[0060] Blockchain Rules Engine Node.js SDK210 The blockchain rules engine Node.js software development kit (SDK) 210 outlines syntax, interfaces, and requirements that enable applications leveraging APIs exposed by the blockchain rules engine to dynamically create rules that are consistent across all blockchain platforms, with semantics and syntax that is familiar to non-blockchain programmers. The blockchain rules engine Node.js SDK 210 further enables dynamic modification and deletion of rules in applications that interface with the blockchain rules engine API.
[0061] The blockchain rule engine Node.js SDK 210 outlines how the blockchain rule engine 200 stores Rule Data on the blockchain. Rules, their execution results (success / error), and resulting transactions (post-processor functions) are all stored on the blockchain. Modifications made to the rules (versioning) are also placed on the blockchain. The blockchain rule engine Node.js SDK 210 further specifies how the blockchain rule engine 200 stores pre-processor functions (set of instructions executed before rule execution) in a blockchain storage device. The blockchain rule engine Node.js SDK 210 further implements multi-tenancy on the blockchain by allowing multiple tenants to create and manage rules on the blockchain. Tenants also store credential data and rule functions on the blockchain. In addition to multi-tenancy, the blockchain rule engine Node.js SDK 210 provides an application level hierarchy supported by the blockchain rule engine to utilize rule execution capabilities. Applications can use the rules and functions created and can also store credentials and metadata on the blockchain. In addition to storing the rules on the blockchain, all operations related to tenants, applications, functions and rules are securely recorded on the blockchain.
[0062] The blockchain rules engine Node.js SDK 210 further defines the ability to create categories of rules based on transaction types. The blockchain rules engine Node.js SDK 210 further supports creation of transaction types for the application through API calls, and once transaction types are registered, users of the application create rules. The blockchain rules engine Node.js SDK 210 also implements a plugin for communication between the blockchain rules engine 200 and blockchain applications that establishes inter-chain code communication. Additionally, the plugin can also establish connections for non-blockchain applications.
[0063] Blockchain Rules Engine on Fabric with Node.js SDK Based on the above specification of the blockchain rules engine 200, the blockchain rules engine 200 can be implemented in a sample configuration using an SDK for Node.js applications and Hyperledger Fabric for the blockchain platform. To enable smart contracts on the blockchain platform to utilize Rule Data functionality, it was necessary to implement the complete blockchain rules engine 200 using smart contracts. The blockchain rules engine 200 further implements logical data separation between tenants and applications and tight integration with the blockchain platform.
[0064] In a sample configuration, the blockchain rules engine 200 is implemented using Node.js, Hyperledger Fabric, and Apache Couch DB. Node.js is currently the world's most popular framework for web server-side development, and Hyperledger Fabric has an architecture that partially meets many of the requirements of the blockchain rules engine. Apache CouchDB® is built into Hyperledger Fabric as a world state database option. CouchDB® supports rich queries when chaincode data values are modeled as JSON as the blockchain rules engine's Rule Data.
[0065] Blockchain Rules Engine Fabric Implementation FIG. 3 provides a schematic view of the Blockchain Rules Engine Rule Data system object in realization 300. The realization of Blockchain Rules Engine Rule Data on Fabric involves a total of three roles: Platform Administrator 310, Tenant 320, and Application 330. The Platform Administrator 310 is registered during the deployment of the product. This role is responsible for registering Tenants 320 with the system 300. Tenants 320 have an ID and secret that can be used to create / read / update / delete rules 340 and functions 350. Tenants 320 are also responsible for creating Applications 330. Applications 330 have their own ID and secret that are required by the SDK to initiate rule execution requests at the API layer of the product. Transaction types 360 can group multiple rules 340 that are intended to be executed together for a transaction.
[0066] FIG. 3 is a diagram illustrating the relationships between various database entities of the blockchain rules engine 200. The numbers on either end of the connecting links represent the relationships between the entities numerically. For example, in FIG. 3, the platform administrator 310 is shown as "1" and the tenants 320 are shown as "0**1", which means that one tenant 320 can only be associated with one platform administrator 310, but one platform administrator 310 can be associated with any number of tenants 320 starting from 0.
[0067] The blockchain rules engine 200 is a multi-tenant system, so multiple levels of access control are built in. To perform any operation on a rule (read or write), the caller must provide tenant credentials and application credentials. The hierarchy of the blockchain rules engine 200 body is as follows: Platform Admin > Tenant > Applications > Features and Rules Furthermore, tenants 320 can only be created by the platform administrator 310 and applications 330 can only be created by tenants 320 .
[0068] Blockchain Rules Engine Smart Contract Integration The implementation of the blockchain rules engine on Hyperledger Fabric allows smart contracts 160 to be installed on the blockchain platform. In this way, the business logic is split between the blockchain rules engine Node.js layer 220 and the blockchain platform 150 itself.
[0069] Blockchain Rules Engine Fabric Services Layer The blockchain rules engine Node.js layer 220 accepts inputs from the API layer / SDK and translates them into actions by invoking blockchain rules engine chaincode, and the CouchDB world state database 230.
[0070] Blockchain Rules Engine Node.js SDK The blockchain rule engine Node.js SDK 210 provides the functionality for executing the created rules to the client application 100. Specifically, the blockchain rule engine Node.js SDK 210 provides the ability to create a connection with the blockchain rule engine 200 and perform rule execution.
[0071] Blockchain Rules Engine Fabric - Node.js SDK Figure 4 illustrates the interaction of the Blockchain Rules Engine Fabric - Node.js SDK 430 with the user's application 420 and the execution environment in which both are hosted, the User Application Node 400, as shown in the top level detail of the model in Figure 4. The User Application Node 400 covers a wide range of potential implementations, constrained by its support for Node.js and its ability to be configured to communicate with a running instance of the Blockchain Rules Engine Web Service (API Layer) 410 via web sockets in the Blockchain Rules Engine API 1255.
[0072] Drilling down to the user application node 400, a Node.js 420 user application is modeled as a component that depends on a Fabric / Node.js blockchain rules engine SDK 430. Drilling down further, the Fabric / Node.js blockchain rules engine SDK 430 is modeled in two parts. A set of Node.js wrapper function interfaces 440 define functions that are directly available to the user application code. The Node.js wrapper function interfaces 440 generally conform to the language-specific SDK "specification" 110 introduced in FIG. 1. Node.js wrapper function implementation code 450 implements the interfaces and translates calls to Fabric / Node.js blockchain rules engine SDK 430 into calls to the blockchain rules engine API 125.
[0073] Beyond the functionality required by the blockchain rules engine specification, the Fabric / Node.js implementation includes rule execution capabilities. In addition to the blockchain rules engine 200 functionality described above, the Fabric / Node.js version of FIG. 4 implements Rule Data on the blockchain with a tenant-application hierarchy and a programmer-friendly SDK that provides functionality such as rule execution to client applications.
[0074] Although described herein with respect to Hyperledger® Fabric, one skilled in the art will appreciate that the techniques described herein may also be used with other blockchain networks, such as AION, ArcBlock, EOS, NEO, Hyperledger® Sawtooth, NxT, QTUM, Quorum, Smilo, Tezos, TRON, Wanchain, or Zilliqa. Terms used herein relate to the Hyperledger® Fabric blockchain network. Corresponding terms are used in the context of other blockchain networks, as noted.
[0075] Computer embodiment FIG. 5 is a block diagram of an exemplary general-purpose computer 500 that may be programmed into a special-purpose computer suitable for implementing one or more embodiments of the blockchain rules engine 200 disclosed herein. The blockchain rules engine 200 described above may be implemented on any general-purpose processing component, such as a computer, having sufficient processing power, memory resources, and communication throughput capabilities to handle the necessary workload imposed upon it. The computer 500 includes a processor 502 (sometimes referred to as a central processor unit or CPU) in communication with memory devices including secondary storage 504, read-only memory (ROM) 506, random access memory (RAM) 508, input / output (I / O) devices 510, and network connection devices 512. The processor 502 may be implemented as one or more CPU chips or may be part of one or more application specific integrated circuits (ASICs).
[0076] The secondary storage 504 typically comprises one or more disk drives or tape drives and is used for non-volatile storage of data and as overflow data storage in case the RAM 508 is not large enough to hold all working data. The secondary storage 504 may be used to store programs loaded into the RAM 508 when the programs are selected for execution. The ROM 506 is used to store instructions and possibly data that are read during the execution of a program. The ROM 506 is a non-volatile memory device and typically has a small memory capacity relative to the large memory capacity of the secondary storage 504. The RAM 5088 is used to store volatile data and possibly instructions. Access to both the ROM 506 and the RAM 508 is typically faster than access to the secondary storage 504.
[0077] The apparatus described herein includes a computer-readable non-transitory medium having computer-readable instructions stored thereon and one or more processors coupled to a memory that, when executed, can configure the computer 500 to perform the method steps and operations described above with reference to Figures 1-4. The computer-readable non-transitory medium can include any type of computer-readable medium, including magnetic storage media, optical storage media, flash media, and solid-state storage media.
[0078] It should be understood that software including one or more computer executable instructions facilitating the processes and operations as described above with reference to any one or all of the steps of the present disclosure may further be installed on and sold with one or more servers and / or one or more routers and / or one or more devices in a consumer and / or producer domain consistent with the present disclosure. Alternatively, the software may be obtained and loaded onto one or more servers and / or one or more routers and / or one or more devices in a consumer and / or producer domain consistent with the present disclosure, including, for example, obtaining the software through a physical medium or distribution system, including from a server owned by the software creator or from a server not owned but used by the software developer. The software may be stored on a server for distribution over the Internet, for example.
[0079] Moreover, those skilled in the art will appreciate that the present disclosure is not limited in its application to the details of construction and the arrangement of components described herein or illustrated in the drawings. The embodiments herein are capable of other embodiments and can be practiced or carried out in various ways. It will also be understood that the phrases and terms used herein are for purposes of explanation and should not be considered limiting. The use of "including," "comprising," or "having," and variations thereof herein are meant to encompass the items listed thereafter and equivalents thereof, as well as additional items. Unless otherwise limited, the terms "coupled," "coupled," "attached," and variations thereof herein are used broadly to encompass direct and indirect coupling, coupling, and attachment. Furthermore, the terms "coupled" and "attached," and variations thereof, are not limited to physical or mechanical coupling or attachment. Furthermore, terms such as top, bottom, top, and the like are relative and are employed to aid in the description, but are not limiting.
[0080] Components of the example devices, systems, and methods employed in accordance with the illustrated embodiments may be implemented at least in part in digital or analog electronic circuitry, or in computer hardware, firmware, software, or combinations thereof. These components may be implemented as a computer program product, such as a computer program, program code, or computer instructions embodied in an information carrier or machine-readable storage device for execution by, or to control the operation of, a data processing device, such as a programmable processor, a computer, or multiple computers.
[0081] The computer program may be written in any form of programming language, including compiled or interpreted languages, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. The computer program may be executed on one computer, on multiple computers at one site, or distributed across multiple sites and interconnected by a communication network. Also, functional programs, codes, and code segments for achieving the techniques described herein may be readily interpreted by a programmer of ordinary skill in the art as being within the scope of the present disclosure. Method steps associated with the exemplary embodiments may be performed by one or more programmable processors executing computer programs, codes, or instructions to perform functions (e.g., by operating on input data and / or generating output). Method steps may also be performed by special purpose logic circuitry, such as, for example, a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), and an apparatus may be implemented as special purpose logic circuitry.
[0082] The various example logic blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an ASIC, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in combination with a DSP core, or any other such configuration.
[0083] Processors suitable for executing computer programs include, by way of example, general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, a processor receives instructions and data from a read-only memory or a random access memory, or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer is also operatively coupled to receive data from, or transfer data to, one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, optical disks, and the like. Information carriers suitable for embodying computer program instructions and data include, by way of example, semiconductor memory devices, such as electrically programmable read-only memories or ROMs (EPRPMs), electrically erasable programmable ROMs (EEPROMs), flash memory devices, and all forms of non-volatile memory, including data storage disks (e.g., magnetic disks, internal hard disks, or removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks). The processor and memory may be supplemented by, or incorporated in, special purpose logic circuitry.
[0084] Those skilled in the art will appreciate that information and signals may be represented using any of a variety of different technologies and techniques. For example, the data, instructions, commands, information, signals, bits, symbols, and chips referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
[0085] Those skilled in the art will further appreciate that the various exemplary logic blocks, modules, circuits, and algorithmic steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, the various exemplary components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in various ways for each particular application, and such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure. The software modules may reside in random access memory (RAM), flash memory, ROM, EPROM, EEPROM, registers, a hard disk, a removable disk, a CD-ROM, or other forms of storage media known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from and write information to the storage medium. Alternatively, the storage medium may be integral to the processor. That is, the processor and the storage medium may reside on an integrated circuit or may be implemented as discrete components.
[0086] As used herein, "machine-readable medium" means a device capable of storing instructions and data temporarily or permanently, including, but not limited to, random access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, other types of storage devices (e.g., erasable programmable read-only memory (EEPROM)), and / or any suitable combination thereof. The term "machine-readable medium" should be considered to include a single medium or multiple media capable of storing processor instructions (e.g., a centralized or distributed database, or associated caches and servers). The term "machine-readable medium" should also be considered to include any medium, or combination of multiple media, capable of storing instructions for execution by one or more processors, such that, when executed by the one or more processors, the instructions cause the one or more processors to perform any one or more of the methodologies described herein. Thus, "machine-readable medium" refers to a single storage device or device, as well as a "cloud-based" storage system or storage network including multiple storage devices or devices. As used herein, the term "machine-readable medium" excludes signals per se.
[0087] The foregoing description and illustrations are intended to be illustrative only and are not intended to limit the exemplary embodiments in any manner, except as set forth in the appended claims. It should be noted that the various technical aspects of the various elements of the various exemplary embodiments described above can be combined in numerous other ways, all of which are considered to be within the scope of the present disclosure.
[0088] Thus, while exemplary embodiments have been disclosed for illustrative purposes, those skilled in the art will recognize that various modifications, additions, and substitutions are possible. Accordingly, the present disclosure is not limited to the above-described embodiments, but can be modified within the scope of the appended claims, along with their full scope of equivalents.
Claims
1. A blockchain rules engine for managing rules implemented by a client application interacting with a blockchain platform for managing a blockchain, comprising: a language-specific software developer kit (SDK) that provides an interface to the client application and exposes rule execution functionality to the client application; a rule engine application programming interface (API) layer that provides a rule engine API to the language-specific SDKs and receives and processes commands from the language-specific SDKs; a blockchain platform specific services layer that interacts with the blockchain platform and accepts input from the rule engine API layer to execute business logic implemented in the rules, where data operations are managed by the blockchain platform specific services layer and the blockchain platform together; A blockchain rules engine having
2. 2. The blockchain rules engine of claim 1, wherein the blockchain platform specific services layer includes a JSON (JavaScript Object Notation) condition parser that parses and evaluates conditions present on objects to which rules are applied.
3. 3. The blockchain rules engine of claim 2, wherein each instance of each type of function supported by the blockchain rules engine is represented by a JSON document in a standard blockchain rules engine format, and each JSON document is written to the blockchain using the same method and consensus as other blockchain transactions.
4. 4. The blockchain rules engine of claim 3, wherein each modification or state change for each type of function is represented by adding a complete updated version of the JSON document for the changed function to the blockchain.
5. 2. The blockchain rule engine of claim 1, wherein the language-specific SDK provides an interface that enables the client application to access rule execution functionality with blockchain applications developed in a programming language supported by the language-specific SDK.
6. 2. The blockchain rule engine of claim 1, wherein the interface provided by the rule engine API layer supports multi-tenant and multi-application for interfacing with the blockchain rule engine.
7. 7. The blockchain rules engine of claim 6, wherein the rules engine API layer accepts the blockchain rules engine rule syntax and logic commands from the language specific SDK or via a user interface console, and the rules engine API layer converts the syntax and logic commands into a format that can be passed to a blockchain platform specific services layer via an interface to the blockchain platform specific services layer implemented on the blockchain platform.
8. 2. The blockchain rules engine of claim 1 , wherein the blockchain platform specific services layer describes functionality as well as interfaces to be supported in all realizations of the blockchain rules engine, including a subset of features and functions that may be implemented either in the blockchain platform specific services layer or on the blockchain platform.
9. 10. The blockchain rules engine of claim 8, wherein the functions include at least one of creating a function, updating a function, deleting a function, creating a rule, updating a rule, deleting a rule, activating and deactivating a rule, importing and exporting a rule, or rolling back a rule.
10. 2. The blockchain rules engine of claim 1, wherein the blockchain platform specific surface layer includes a condition parser that parses pre-processor and post-processor functions for execution and storage of processing results on the blockchain.
11. 11. The blockchain rules engine of claim 10, wherein the pre-processor functions and post-processor functions are linked with rules for modifying the operation of the pre-processor functions and post-processor functions.
12. 11. The blockchain rules engine of claim 10, wherein the post-processor function includes at least one of an on-path post-processor function or an on-fail post-processor function that is executed after a rule is executed and a pass or fail result is produced by the executed rule.
13. 2. The blockchain rules engine of claim 1, wherein the blockchain platform specific services layer provides functionality implemented directly on the blockchain platform for rule-related functions used by smart contracts on the blockchain platform.
14. 2. The blockchain rules engine of claim 1, wherein different rule execution functions are applied to different data objects, the data objects including at least one of a tenant, an application, a rule group, a function, or a rule.
15. 15. The blockchain rules engine of claim 14, wherein each instance of each type of rule execution function is represented by a JSON document in a format common to each type of rule execution function, and each JSON document is written to the blockchain using the same method and consensus as other blockchain transactions.
16. 16. The blockchain rule engine of claim 15, wherein each modification or state change to a rule execution function is represented by adding a complete updated version of a JSON document corresponding to the rule execution function's war record type to the blockchain.
17. 15. The blockchain rules engine of claim 14, wherein the rule execution functionality is directly accessible from a smart contract.
18. The blockchain rules engine of claim 1, further comprising:
1. A blockchain rules engine having a blockchain rules engine specification outlining syntax, interfaces and requirements to enable dynamic rule creation, dynamic rule modification, and dynamic deletion of rules in applications utilizing the rules engine API of the client application and outlining how the blockchain rules engine stores rule data on the blockchain.
19. 20. The blockchain rules engine of claim 18, wherein the blockchain rules engine specification specifies how to store a set of instructions to be executed before the blockchain rules engine executes a rule on the blockchain.
20. 20. The blockchain rules engine of claim 18, wherein the blockchain rules engine specification implements multi-tenancy on the blockchain by allowing multiple tenants to create and manage rules and store credential data and rule functions on the blockchain.
21. 21. The blockchain rules engine of claim 20, wherein the blockchain rules engine specification incorporates multiple levels of access control, and to execute operations of rules, the client application provides tenant credentials and client application credentials.
22. 20. The blockchain rules engine of claim 18, wherein the blockchain rules engine specification provides an application level hierarchy supported by the blockchain rules engine, and the rule execution functionality enables the client applications to use authored rules and functions and store authentication information and metadata on the blockchain.
23. 20. The blockchain rule engine of claim 18, wherein the blockchain rule engine specification implements plug-ins for communication between blockchain applications and the blockchain rule engine to establish inter-chain code communication and to establish connectivity for non-blockchain applications.
24. 20. The blockchain rules engine of claim 18, wherein the blockchain rules engine specification provides the client application with the ability to execute created rules by providing functionality to create a connection between the client application and the blockchain rules engine to perform rule execution.
25. 20. The blockchain rule engine of claim 18, wherein the blockchain rule engine specification comprises a set of function interfaces that define functions directly available to the client application code, and function implementation code that implements the function interfaces by translating calls to the blockchain rule engine specification into calls to the rule engine API.