ASIK: Modular Interface to Blockchain

Abstract

ASIK (Application Specific Integrated Kernel) is a modular interface that provides a general-purpose solution for major business needs without developers having to understand blockchain. The ASIK is a collection of APIs for important use cases frequently executed on the blockchain. The APIs are synchronized with the business logic on the chaincode. The web service layer of the ASIK identifies business requirements and exposes Representational State Transfer (REST) APIs from bundles that may be required to perform tasks and operations. Specific transaction requests made by end users are executed by a general collection of predefined scenarios that are composed of the input data collected from the requests and converted into blockchain transactions by the chaincode. When the transaction is successfully executed on the blockchain, the response is returned to the user in the form of an executable output.

Description

Technical Field

[0001] This application is directed to an application-specific integration kernel (ASIK) that provides a general solution to business needs by providing a modular interface for blockchains, in particular, a set of application programming interfaces (APIs) synchronized with business logic on chaincode.

Background Art

[0002] Blockchain is closely related to the cryptocurrency invented in 2009. However, the birth of peer-to-peer money was also the invention of a completely new approach to distributed computing for other purposes. Various applications are being explored to utilize features such as guaranteed data availability, liberation from centralized management, and prevention of cryptographic tampering.

[0003] The current energy surrounding the adoption of blockchain is reminiscent of the early adoption of the Internet. As applications and systems mature, there is a possibility of repeating or avoiding the same mistakes that have become a burden on applications and systems in terms of logic management. Similar to early websites and applications, the use of blockchain for cryptocurrencies was characterized by relatively simple data structures and hard-coded business logic for managing them. However, the subsequent invention of "smart contracts" has opened the door to rules and data of any complexity.

[0004] Enterprise use cases such as supply chain logistics place an amount of information and logic on the blockchain comparable to conventional solutions, but there are no standardized data management tools. As a result, all programmers design their own set of logics within the application codebase, and the logic will then be tightly coupled to the program (smart contract) that describes it.

[0005] It should be noted that it is not necessary to use all the functions of the blockchain in enterprise applications. A common scenario is to utilize the blockchain platform as a convenient way to implement functions such as cryptographic tamper prevention and data replication. Also, enterprises may relax consensus rules or centralize the front-end as a first step towards more decentralized applications in the future, and implement the blockchain network under their full control. Furthermore, a highly reliable consortium that constructs a blockchain network with strict implementation of smart contracts for support staff may allow administrators and internal auditors to directly update blockchain data at their own discretion.

[0006] The transaction data and decisions stored in the smart contract have greater value in the application. The transaction data and node functions stored in the blockchain can be used subsequently by other functions and logic without being governed by consensus, thereby making the operations fast, efficient, and reliable. The necessary function is only the access right to utilize the data stored in the blockchain. The said data stored in the blockchain can be efficiently read and processed for purposes beyond what the original smart contract programmer envisioned, whether inside or outside the blockchain, by the application, node function, or system.

[0007] Considering the dynamic nature of product development, applications that focus on one-sided solutions are becoming obsolete. The cost of pausing and upgrading these applications may be too high for many companies. Frequent maintenance not only leads to a decrease in performance but also increases expenses. Changes to logic and product designs often alter the look & feel of the product, which ultimately affects the user experience. Developing products from emerging technologies such as blockchain is particularly cumbersome and may require a lot of resources. Platforms for distributed ledger technology provide strict data replication, rule enforcement, immutability, and auditability, but often require specialized skills in programming and operation.

[0008] The systems and methods described herein address the needs in the art by providing an Application Specific Integration Kernel (ASIK) that interfaces a client application to a blockchain platform that manages a blockchain. The ASIK includes an Application Programming Interface (API) layer that receives requests from the client application to execute transactions on the blockchain. The API layer formats data associated with the requests. The ASIK further includes a service layer that receives at least one command associated with the request and the formatted data, identifies the type of the request, and based on the type of the request, transfers the at least one command and the formatted data for execution on the blockchain and returns the processing result of the at least one command and the formatted data on the blockchain to the client application. The service layer further describes pre-set features and functions configured to interact with the blockchain platform according to a predetermined use case (e.g., business service) of the Application Specific Integration Kernel. The ASIK also includes a chain code that manages data operations for the pre-set features and functions that will interact with the blockchain platform for the predetermined use case, and the chain code converts at least one command into at least one transaction executable on the blockchain platform according to the pre-set features and functions for the predetermined use case, and interacts with the blockchain platform for the predetermined use case by returning the execution result of the at least one transaction on the blockchain platform and the formatted data to the service layer.

[0009] In the sample configuration, the API layer exposes APIs that the client application uses to access the pre - set features and functions so that the client application interacts with the blockchain platform according to the predetermined use cases of the application - specific integration kernel. The API layer may also provide a load - balanced Representational State Transfer (REST) API to the client application, and the REST API is adapted to interact with the blockchain platform. The API layer further validates requests from the client application, validates user details received in the request from the client application, checks for user permission to execute the request from the client application, prepares the request for submission to the blockchain platform, and can return a response from the blockchain platform to the client application.

[0010] In other sample configurations, the API layer, service layer, and chain code can be adapted to support a multi - tenant framework in which multiple client applications can create and manage data on the blockchain platform. The API layer, service layer, and chain code can also be adapted to support three roles: platform administrator, tenant, and core ASIK participant. The platform administrator may be in charge of the client's application. The tenant can have an ID and allocated resources that can be used to perform create, read, update, and delete operations on formatted data. The core ASIK participant can have its own ID that is used to initiate requests with the API layer. Also, a database is provided for each tenant, and each tenant can perform operations on its own database.

[0011] In a further sample configuration, the service layer can describe the preset features and functions by outlining semantics and syntax, as well as at least one command and formatted data that interact with the blockchain platform for the predetermined use case of the application-specific integration kernel. The service layer can further receive input from the API layer and convert the input into actions by invoking the chain code and the state database.

[0012] In a further sample configuration, the chain code can access the blockchain ledger and the smart contract of the blockchain platform to query or update the blockchain ledger. All operations of the client application are securely recorded in the blockchain ledger.

[0013] This specification further includes steps of receiving, by an application programming interface (API) layer, a request from a client application for executing a transaction on the blockchain; formatting, by the API layer, data associated with the request; receiving, by a service layer, at least one command and the formatted data associated with the request; identifying, by the service layer, the type of the request; transferring, by the service layer, the at least one command and the formatted data for execution on the blockchain based on the type of the request; managing data operations by converting, by a chain code, the at least one command into at least one transaction executable on the blockchain platform according to the preset features and functions to interact with the blockchain platform according to a predetermined use case (for example, as follows); and returning, to the client application, the execution result of the at least one transaction and the data formatted on the blockchain platform. A method for interfacing a client application with a blockchain platform for managing a blockchain by performing operations including the above steps is provided.

[0014] In the sample configuration, the method may further include the step of exposing an API to the client application that can be used by the client application to access the pre-set features and functions so that the client application interacts with the blockchain platform according to the predetermined use case. The method may further include the step of providing a load-balanced Representational State Transfer (REST) API to the client application, and the REST API is adapted to interact with the blockchain platform. The formatting of the data related to the request may include the steps of the API layer validating the request from the client application, validating the user details received in the request from the client application, checking the user's permission to execute the request from the client application, and preparing the request for submission to the blockchain platform.

[0015] In another sample configuration, the method may further include the step of using the API layer, service layer, and chain code to enable multiple client applications to create and manage data on the blockchain platform. The API layer, service layer, and chain code can also be adapted to support three roles: platform administrator, tenant, and core ASIK participant. The platform administrator registers the client application. The tenant performs create, read, update, and delete operations on the formatted data using an ID and the resources assigned to the tenant, and the core ASIK participant initiates a request to the API layer using its own ID. Each tenant can also perform operations on its own database.

[0016] In a further sample configuration, the method can further include the service layer describing pre-set features and functions by outlining semantics and syntax, and at least one interface for at least one command and formatted data to interact with the blockchain platform for a given use case. The method can also include the service layer receiving input from the API layer and converting the input into an action by calling the chain code and the state database.

[0017] In a further sample configuration, this method can include the chain code accessing the blockchain ledger and the smart contract of the blockchain platform to query or update the blockchain ledger and securely record all operations of the client application in the blockchain ledger.

[0018] This specification also includes a non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to implement a method for interfacing a client application to a blockchain platform that manages a blockchain. In a sample configuration, the instructions include an application programming interface (API) layer that receives requests from the client application to execute transactions on the blockchain and formats data associated with the requests, and a service layer that receives at least one command and the formatted data associated with the request, identifies the type of the request, and based on the type of the request, transfers at least one command and the formatted data for execution on the blockchain and returns the execution result of at least one command and the formatted data on the blockchain platform to the client application, and a chain code that manages data operations by converting at least one command into at least one transaction executable on the blockchain platform according to preset features and functions for interacting with the blockchain platform according to preset use cases.

[0019] Embodiments described herein also include a computer system for implementing the methods described throughout this disclosure. For example, the systems and methods described herein can be implemented on a computing platform in the cloud to provide functions for accessing and storing data on a blockchain platform as described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The present disclosure is illustrated, but not limited to, the figures of the accompanying drawings:

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

DETAILED DESCRIPTION OF THE INVENTION

[0021] The following description with respect to FIGS. 1-6 fully discloses specific embodiments so that those skilled in the art can implement them. Other embodiments can incorporate structural, logical, process, and other changes. Parts and features of some embodiments may be included in or substituted for those of other embodiments. The embodiments described in the claims cover all available equivalents of those claims.

[0022] Blockchain: A continuously increasing list of records called blocks is linked and protected using cryptography. Each block typically contains the cryptographic hash of the previous block, a timestamp, and transaction data. The blockchain is designed to be essentially resistant to tampering of transaction data. When used as a distributed ledger, the blockchain is typically managed by a peer-to-peer network that collectively adheres to a protocol for validating new blocks. Once the data of a block is recorded, it cannot be changed retroactively without changing all subsequent blocks.

[0023] BNO: Blockchain Network Orchestrator (BNO) is a service used by the ASIK Track Application for the setup and management of the blockchain network. BNO helps users create Ethereum, Fabric network, and Element DB instances (Element DB is a licensee's product that provides the function for organizations and users to manage relational data on the blockchain).

[0024] Chaincode: Chaincode is a smart contract or software that represents business logic in a sample configuration for each client (organization) to read and update data on the blockchain ledger. In the ASIK Track Application, the chaincode is upgraded by the platform administrator.

[0025] Core ASIK Participants: Anyone who attempts to access the ASIK application via a client application is called a participant. Core ASIK participants have their own IDs, which are used by the ASIK to initiate requests at the API layer of the ASIK. For example, the following are different participants in the example of the ASIK Track described here. Supply Chain Administrator: The supply chain administrator is the administrator of the application. Different users / user groups, workflows, etc. can be created. The supply chain administrator can view all entities such as workflows and movable products, but cannot perform operations on those entities. Auditor: The auditor is an external participant who can view all data of movable products and can resolve disputes. Internal Auditor: The internal auditor is an internal participant who can view all data of movable products and can resolve disputes. User / Participant: The user has the right to create / transfer / receive movable products. Each user can belong to multiple user groups, and each user group can have multiple users who can transfer, receive, or reject child products associated with existing basic products and workflows.

[0026] CouchDB (registered trademark) is incorporated as an option for the world state database in Hyperledger (registered trademark) Fabric. CouchDB (registered trademark) supports rich queries when the data values of chaincode are modeled in JSON as the transaction data of the ASIK.

[0027] Dispute: When there is a discrepancy in the attributes of a product, it is called a dispute. A dispute can be anything that deviates from what all participants have agreed upon. A dispute can be created by a user at any time with respect to a movable product. The dispute is resolved by an auditor or a user.

[0028] Hyperledger (registered trademark) Fabric: An enterprise-grade permissioned distributed ledger platform with modularity and versatility to address a wide range of industry use cases.

[0029] Hyperledger (registered trademark) Fabric Certificate Authority: The Certificate Authority (CA) provides certificate services to blockchain users. Specifically, it provides services for user registration, transactions called on the blockchain, and connections between users or components of the blockchain protected by Transport Layer Security (TLS). The Enrollment Certificate Authority (ECA) enables new users to register with the blockchain network and registered users to request enrollment certificate pairs. One is a certificate for data signing and the other is a certificate for data encryption. These certificates are used to call chaincode transactions on the blockchain.

[0030] JSON: An abbreviation for JavaScript Object Notation, a lightweight, text-based, human-readable data exchange format.

[0031] Movable Product: A movable product is an actual product transferred from one node to another. Users can create, transfer, receive, update, and reject movable products.

[0032] Nest (NestJS): A framework for building efficient and scalable Node.js (registered trademark) server-side applications. NestJS uses progressive JavaScript, is built with TypeScript, and is fully supported (although developers can code in pure JavaScript). For more details on Nest.JS, see "About NestJS, Documentation and Foundation" (https: / / nestjs.com / ).

[0033] Node.js (Registered Trademark): A free and open-source server environment that executes JavaScript code outside of the browser. Node.js (Registered Trademark) is an asynchronous programming platform built on top of the JavaScript runtime of the Chrome browser. For details about Node.js (Registered Trademark), please refer to "About Node.js (Registered Trademark)". (Node.js, Node.js Foundation)

[0034] Platform Administrator: The platform administrator is registered at the time of product deployment. The role of the platform administrator, which is specially designed for this purpose, only has the authority to create and manage tenants within the ASIK.

[0035] Product: A product is the metadata of all movable products. Multiple movable products can be created for one product.

[0036] Smart Contract: A computer protocol that provides general-purpose computing performed on the blockchain or distributed ledger. Smart contract transactions can implement simple or advanced logic. The resulting transactions are usually transparent, traceable, and irreversible to ledger participants.

[0037] Tenant: A tenant is registered by the platform administrator of the ASIK. A tenant represents any client (organization) that uses the ASIK. The ASIK provides the function of allowing multiple clients to use one application, which is called multi-tenancy. A tenant has an ID and the resources assigned to it, and can be used to perform the necessary CRUD (Create, Read, Update, Delete) operations on any asset within the ASIK.

[0038] Tracker: For each movable product, one Tracker document is created. This document contains all the historical information of the movable product, including attribute updates and movements of the movable product.

[0039] Workflow: The workflow determines the order of user groups to which the product is transferred and the attributes associated with the base product.

[0040] In the design of computer applications, especially in large enterprise environments, there is an increasing case of incorporating existing distributed ledger technology (DLT) platforms into solutions. As described above, these platforms provide strict data replication, rule enforcement, immutability, and auditability, but often require specialized skills in programming and operation. As described herein, by abstracting the communication of adjacent DLT nodes (including writing both data and rules to that data) and combining a set of data and rule primitives that support a wide range of potential DLT applications within a category (e.g., a specific use case), it is possible to use a subsystem that enables the creation and operation of client applications by developers without specialized skills for the selected platform. Primitives are typically constructed so that application developers can adapt to specific use cases without requiring skills in the DLT platform and can be extended with attributes and additional data rules without losing the strict rule application provided by the DLT platform. Also, the interfaces for client application developers to design and utilize these primitives completely eliminate the need for technical understanding of the DLT platform.

[0041] Specific implementations are a dedicated subsystem for a single client application, a reusable component used in multiple client applications, or a service that provides application enablement to multiple client applications. Other implementations mediate communication with one or more adjacent DLT nodes, which are drawn from a single or multiple DLT networks.

[0042] This specification describes Hyperledger Fabric, but it will be understood by those skilled in the art that the techniques described herein can also be used in other blockchain networks such as AION, ArcBlock, EOS, NEO, Hyperledger Sawtooth, Nxt, QTUM, Quorum, Smilo, Tezos, TRON, Wachain, or Zilliqa. The terms used herein relate to the Hyperledger Fabric blockchain network. Corresponding terms are used in the context of other blockchain networks as mentioned.

[0043] The sample subsystem can enable the indirect use of the Hyperledger Fabric DLT platform for a wide range of categories or virtual workflows and information-sharing applications, and some operational real-world realizations of such client applications. To implement such a subsystem, there are three important requirements: 1) A set of extensible general-purpose data and action primitives represented on the distributed ledger, and 2) A set of rules operating on these primitives embedded in the distributed ledger, which enforces both the subsystem's proprietary data rules and the permitted extensions of these rules that may be provided by the client application, and 3) A programming interface that can be operated without knowledge of the blockchain platform. As a result, the subsystem provides a set of tools and libraries that enable general users with knowledge of a certain application category and / or skills in a certain blockchain platform to build a unique subsystem that supports the creation of client applications in that category. The resulting code is implemented as middleware between the API network and the blockchain protocol, allowing the user to consistently interface with the blockchain without extensive knowledge of the blockchain's operation. In such applications, business rules specific to the upper-layer use cases are described and enforceable on the blockchain. New business rules can be added at any time to update the workflow without interrupting the functions and controls of the blockchain.

[0044] The ASIK (Application Specific Integrated Kernel) described in this book is a modular interface that provides a general solution for major business needs. As described in this specification, the ASIK is a collection of APIs synchronized with the business logic on the chaincode, giving it a "plug and play" nature and keeping things very simple. The web service layer of the ASIK exposes Representational State Transfer (REST) APIs from the bundles necessary to identify business requirements and execute tasks and operations. This feature makes the ASIK a general solution that can be implemented in almost any industry. As will be apparent from the following description, the ASIK is a multi-utility application that can be implemented in asset tracking, supply chain management, consent management, financial solutions, access control, product inventory, and many other applications.

[0045] Generally, the ASIK is a collection of APIs for the essential use cases that are frequently executed on the blockchain. Specific transaction requests made by end-users are executed by a general collection of predefined scenarios, which are composed of the input data collected from the requests. When the transaction is successfully executed on the blockchain, the response is returned to the user in the form of an executable output.

[0046] The value of the ASIK lies in its ease of use without the need to understand the blockchain. Furthermore, the ASIK provides a general-purpose solution that can meet all major business requirements. Since the ASIK is highly "pluggable and reusable", users can minimize the elements they need to configure to use the ASIK according to their requirements. As the ASIK provides a general-purpose solution, it evolves to meet the growth of the market and rapidly changing requirements. The ASIK can be integrated and used with multiple external applications and has become a multi-utility application. Also, the ASIK is constantly "evolving" and always has room for new features and upgrades, making it a fast and ultra-modern solution. The ASIK is a "black box for the blockchain" in that it is a reliable interface between the user and the blockchain. To enjoy the benefits provided by the ASIK, users do not need to understand the concept of the blockchain. Since the ASIK is easily accessible, it can be integrated with external systems without difficulty. The ASIK functions on almost all recognizable blockchain networks that support development. Also, since the ASIK is compatible with cloud-based platforms, it has high versatility and is easy to introduce and integrate.

[0047] The ASIK can be implemented in various applications as follows:

[0048] ASIK Track: A platform that supports organizations for constructing and deploying a sophisticated and autonomous fintech-enabled information supply chain with a marketplace for all participating organizations. An example of the implementation of ASIK Track will be described below.

[0049] ASIK Ecosystem: A platform that enables peer-to-peer banking transactions. Since it is built using distributed ledger technology, all transactions on the platform are 100% auditable, immutable, and visible only to authorized users.

[0050] ASIK Consent: A fully executable data consent management platform that defines a completely new way of data collection and notifies users every time their data is used.

[0051] Sample Embodiments of ASIK As described above, applications that focus only on one-sided solutions are becoming obsolete, and the process of pausing and upgrading simply leads to performance degradation and cost increases. There is a need for universal and very user-friendly business solutions that are rooted in new technologies such as blockchain. However, developing such products using influential technologies is cumbersome and requires a lot of resources. Shifting to another technology stack is a significant challenge and not the most feasible option for many companies.

[0052] The ASIK described in this specification addresses these needs in the art by providing a reusable and pluggable service that can be utilized not only in blockchain but also in non-blockchain applications. The ASIK described in this specification is designed to be implemented across various blockchain platforms and user programming languages. While some parts of the system may be customized, they follow a set of common specifications. In this description, one example of such an implementation based on the Hyperledger (registered trademark) Fabric platform and the Node.js (registered trademark) programming language is provided. However, it will be understood that the description provided herein can be readily extended by those skilled in the art to other platforms and languages.

[0053] A description of a set of specifications, interfaces, and core components for all implementations of ASIK is provided with respect to Figure 1.

[0054] Figure 1 is a general block diagram showing an overview of the specifications and components of ASIK (Application Specific Integrated Kernel) 100 in an exemplary embodiment. Figure 1 is a compliant component diagram showing the components and specifications of ASIK in a sample configuration. The common specifications are represented as components with a "specification" stereotype indicating abstract requirements. Specifications are aspects that are expected to be implemented in a common way across all ASIK implementations. The shown interfaces are also specifications common to all implementations.

[0055] In Figure 1, client applications 1101 - 110 N are applications that attempt to utilize the ASIK 100. The client applications 1101 - 110 N can be any third-party application, service, or tool. Multiple client applications 1101 - 110 that access the ASIK 100 NOr there may be a tenant. The client application 1101-110 N accesses the ASIK 100 via the ASIK Tenant Onboarding Service 120, processes multiple clients or tenants, and enables all tenants to efficiently use the ASIK 100. The ASIK Tenant Onboarding Service 120 interacts with the ASIK Web Service 130 via the ASIK Web Service Interface 125. The ASIK Web Service 130 is a component that receives commands from HTTP requests, communicates with the internal components of the ASIK 100, and generates desired results. The ASIK Web Service 130 provides a service that directly connects to the client application 1101-110 N and can transfer requests to other services in the service layer based on the request. Therefore, the ASIK Web Service 130 can be considered a master service that performs initial processing of data, identifies the type of request, transfers the request further based on the type to complete the processing, and returns the result (intermediate or final) to the client application 1101-110 N . The ASIK API Layer 140 processes the REST calls and is also implemented in the ASIK Web Service 130 to manipulate / format data and send the data to various other components.

[0056] The ASIK web service 130 interacts with the ASIK service layer 150 specific to the blockchain platform via the ASIK service layer interface 145. The blockchain platform ASIK service layer 150 is designed to operate in a blockchain system (Hyperledger Fabric in this example), accepts inputs from the ASIK API layer 140 via the ASIK web service layer 130, and executes business logic. The ASIK service layer 150 can include one or more interconnected services such as those available via the DLT library 155 and external services 160. The DLT library 155 and external services 160 communicate with each other using, for example, an Apache Kafka queue. The blockchain platform ASIK service layer 150 describes an interface and the functions supported in any implementation (use case) of the ASIK 100. The specification of the blockchain platform ASIK service layer 150 covers not only the entire interface but also a subset of the features and functions that can be implemented either in the blockchain platform ASIK service layer 150 or in the blockchain platform 180 itself.

[0057] The blockchain platform ASIK service layer 150 accepts inputs from the ASIK web service API layer 140 and executes the following steps: 1) Validate the received request and remove information that should be kept secret. 2) Verify the user and tenant details received in the request. 3) Check the user's permissions to execute the requested operation. 4) Prepare a transaction / request object to submit to the blockchain platform 180. 5) Submit the transaction to the blockchain platform 180. 6) Prepare a success / error response object based on the response returned from Process 5. 7) Return the response to the client. The blockchain platform ASIK service layer 150 is implemented in Node.js (registered trademark) in a sample configuration and is independent of the programming language, so it can be implemented in any language of the target blockchain platform 180. When the data is converted into the desired format, the blockchain platform ASIK service layer 150 calls the blockchain platform-specific ASIK chain code 170 via the interface 165. The blockchain platform-specific ASIK chain code 170 then calls the blockchain platform 180. Additional functions may target the blockchain platform 180 itself.

[0058] In a sample configuration, the data operations of the ASIK 100 are managed jointly by the ASIK chain code 170 and the blockchain platform 180. The exact division of labor depends on the capabilities of the blockchain platform 180. The required functions are provided by two sub-specifications. The transaction data 185 on the blockchain defines the supported standardized data representation (JSON schema) and data operations. The transaction data includes documents of types such as workflows, movable products, products, supply chain managers, auditors, internal auditors, trackers, users, user groups, disputes, etc. The ledger update 190 provides a transaction with a unique ID that is updated on the ledger that tracks all the transactions made by the enterprise each time a transaction is executed on the blockchain.

[0059] During the operation of the ASIK 100, the ASIK tenant onboarding service 120 supports multiple instances of software running on a single physical server and provides a multi-tenant framework that supports multiple users using a single application, such as a database or a specific microservice. As shown in Figure 1, multiple client applications (tenants) 1101-110 N may attempt to access the ASIK 100. The ASIK tenant onboarding service 120 processes so that these multiple tenants can all use the single ASIK 100. By incorporating the multi-tenant function, the ASIK 100 is cost-effective in terms of reducing system costs through resource sharing. Also, since all users access services from the same technology platform, it becomes easier to access automatic updates and frequent updates. The user does not need to pay for individual resource allocation. Hosting is also simplified and hardware-independent. Multi-tenancy provides the ability to reside in the same infrastructure and data center, and server and computing capacity can be easily added. Multi-tenancy also reduces the chance of being exposed to malicious software and provides hassle-free upgrades. Also, with the multi-tenant function, virtualization and remote access functions can be fully utilized within the enterprise.

[0060] The creation of the multi-tenant is directed by the allocation of resources of the blockchain platform 180 (such as Fabric), and this allocation can be dedicated or shared (depending on the client / user request). Multi-tenant creation may also be directed by channel creation, smart contract deployment, CouthDB (registered trademark) view creation, Kafka topic partition creation, and Elasticsearch index creation.

[0061] As described above with respect to FIG. 1, one of the main components of the ASIK 100 is the ASIK web service 130 that is used in all implementations of the ASIK 100. The ASIK web service 130 functions as an interface between the client applications 1101-110 N and the ASIK 100. A user can make requests via a software development kit (SDK) or an interface to an application, or via an HTTPS request (or a request from a RESTful API). All of these requests may be received, processed, and forwarded (to other components) via sub-components of the ASIK web service 130. One such sub-component is the ASIK API layer 140, which accepts inputs in an acceptable syntax format. Middleware (FIGS. 4-5) performs the heavy task of parsing, validating, and formatting these syntaxes to ensure that all parameters are in line with business requirements, and then routes the syntaxes to the ASIK service layer 150 and other subsequent components.

[0062] According to business needs, appropriate functions to meet the requirements are selected by the ASIK 100, and the service layer provides those functions. Since the ASIK service layer 150 specific to the blockchain platform is independent of programming languages, it can be implemented in any language. The service is developed using Node.js (registered trademark) and NestJS. The ASIK service layer 150 specific to the blockchain platform is reusable and does not depend on the blockchain framework. The specifications of the ASIK service layer 150 specific to the blockchain platform describe the interfaces and functions that need to be supported in all implementations of the ASIK 100. The ASIK service layer 150 specific to the blockchain platform can include a plurality of sub-services interconnected via http requests, kafka, or other protocols. Furthermore, a plurality of DLT libraries 155 (e.g., dlt-kafka) can also be implemented in the ASIK service layer 150 specific to the blockchain platform of the ASIK 100 to achieve high reusability of existing functions. For example, dlt-kafka provides a mechanism to connect to kafka and exposes it so that functions such as produce / consume can be used by any service. Connections to external services 160 such as redis, elasticsearch, CouchDB (registered trademark), etc. can all be established in the ASIK service layer 150 specific to the blockchain platform itself.

[0063] The request function of the ASIK service layer 150 specific to the blockchain platform then triggers a similar function of the ASIK chain code 170. This function serves as a modulator that converts the input request into a transaction executable on the blockchain platform 180 via the ASIK chain code 170. This business problem is solved in the ASIK chain code 170 that is responsible for all interactions with the blockchain platform 180.

[0064] Similar to the platform itself, the implementation of functions directly implemented on the blockchain platform 180 also has a significantly different approach. The corresponding specifications still define something common regardless of the blockchain platform 180 used. Each time a transaction is executed on the blockchain platform 180, a transaction with a unique ID is updated on a ledger 190 that tracks all transactions made by enterprises, regardless of whether the status of the transaction, i.e., success or failure. The smart contract and / or chain code 170 can be customized by the ASIK 100 and can further enhance the transaction report. When a business operation is completed (success scenario), the state of the transaction is updated on a pre-configured state database that holds the current state of the data. The ASIK 100 can use CouchDB (registered trademark) as the state database, enabling the storage of data in JSON format, the issuance of JSON queries against the data, and the use of indexes to support the queries. On the other hand, each time a transaction fails, the error handling system can appropriately assign the transaction to the ASIK 100.

[0065] In the sample configuration shown in FIG. 2, the configuration of the ASIK 100 is implemented using Node.js (registered trademark), the Hyperledger (registered trademark) Fabric blockchain platform based on the Node.js (registered trademark) SDK, and Apach CouchDB (registered trademark). Node.js (registered trademark) is currently the most popular framework in the world for web server-side development, and Hyperledger (registered trademark) Fabric has an architecture that partially meets many requirements of the ASIK 100. Apach CouchDB (registered trademark) is incorporated into Hyperledger (registered trademark) Fabric as an option for the world state database. CouchDB (registered trademark) supports rich queries when the data values of the chaincode are modeled in JSON as ASIK data.

[0066] As described above, the ASIK 100 is a "plug and play" solution with pre-set scenarios. Requests are supplied to the ASIK web service 130 from the client applications 1101-110 N using conventional user interface (UI) methods or HTTP requests. To enable the transaction data function, smart contracts are also implemented on the blockchain platform 180. Hyperledger (registered trademark) Fabric is an implementation of blockchain technology and is jointly developed under the Linux Foundation. The Hyperledger (registered trademark) Fabric blockchain platform meets all the specification requirements as described above and is suitable for providing better performance, logical data separation between tenants and applications, and tight integration with the blockchain platform 180.

[0067] Figure 2 is a detailed component diagram of the Fabric / Node.js (registered trademark) implementation 200 of the ASIK 100 in the sample configuration. Figure 2 illustrates the implementation of the ASIK Track configuration 200 where Node.js (registered trademark) is the programming language and Hyperledger (registered trademark) Fabric is the blockchain platform used. Figure 2 shows how the Fabric / Node.js (registered trademark) implementation realizes the specifications outlined in Figure 1, along with some additional features. From Figure 2, it will be understood that the realization of ASIK data on Fabric involves providing a total of three roles in the ASIK implementation 200: platform administrator, tenant, and core ASIK participant. The platform administrator is registered at the time of product deployment. This role is responsible for registering tenants to the system. Tenants have an ID and the resources assigned to them, and can use them to perform the necessary CRUD operations on any asset of the ASIK implementation 200. Core ASIK participants have their own ID, which is used by the ASIK 100 to initiate requests with the API layer 140 of ASIK. For example, in the ASIK Track configuration, there can be at least four different participants: supply chain administrator, auditor, internal auditor, user / participant, etc.

[0068] The ASIK Track application 110 considers a multi-tenant system with the help of the ASIK Track tenant onboarding service 120, which includes the ASIK Track tenant onboarding service code and data 120' accessed via the ASIK onboarding service API interface 210. The ASIK onboarding service 210 enables multiple clients (tenants) to use a single application without the service operations being known to the tenant. Internally, the ASIK Track tenant onboarding service 120 creates a different database for each tenant to distinguish tenant details. Each tenant executes its own operations on its own database without being aware of it. By using multi-tenancy, one application can be created and then deployed to as many customers as desired so that there is no need to recreate individual solutions for each end-user. Thus, for the tenant, the application is a single unit and all internal partitions are black boxes.

[0069] Since the ASIK web service API layer 130 is the service that clients interact with directly, it is an important part of the product. With the help of the REST API, the ASIK web service API layer 130 receives requests and uses a Node Package Manager (NPM) module for JavaScript execution environment Node.js® like express-validator to perform validation / removal of information to be kept secret. The NPM module is imported by the Node.js® application, establishes an interface connection with the ASIK web service API layer 130, and initiates rule execution requests from the interface-connected client application 110.

[0070] Once the data is formatted, the data is transferred to the next layer, which is the ASIK web service API layer 140. The ASIK web service API layer 140 is referred to herein as the services within the ASIK Track web service and external ASIK Track services (services outside the web service). It is the job of the ASIK web service API layer 140 to identify the type of request and transfer it to the appropriate service. Some of the requests are fully processed by the ASIK web service API layer 140, while for other processing, it relies on the help of other ASIK Track services such as the batch composer service and the aggregation engine service below the ASIK web service API layer 140. Such services are not web services but are called through the web service in response to requests.

[0071] For example, since only the web service is required to create a workflow (an entity of ASIK Track), the call is easy. However, to execute an aggregation (an operation of ASIK Track), the ASIK Track web service performs the necessary request verification. Upon successful verification, it transfers the request to the aggregation engine service of Track to execute the aggregation functions (count, max, min, average, sum). The services of the ASIK web service API layer 130 are interconnected using REST API or Apache Kafka. Each service is assigned a part of the job, and the service completes it and further sends the request to complete the remaining part of the job.

[0072] The above-mentioned ASIK Tenant Onboard Service 120, ASIK Web Service API Layer 130, ASIK Web Service API Layer 140, Blockchain Platform-Specific ASIK Service Layer 150, ASIK Chaincode 170, and Blockchain Platform 180, as well as the interfaces 125, 145, and 165, are common to all implementations and are the same as those in FIG. 1. The Blockchain Platform-Specific Node.js (registered trademark) Fabric Service Layer 150' below it realizes a facade for all platform operations. It is the Fabric CouchDB implementation 220 that is directly accessed for specific indexing functions and directly supports the Blockchain Platform-Specific Node.js (registered trademark) Fabric Service Layer 150' through the dependence on the Blockchain Platform Specification 180. In the implementation of Fabric, the changes to the schema index and user permissions are partially implemented in the Blockchain Platform-Specific Node.js (registered trademark) Fabric Service Layer 150', which directly calls the Fabric CouchDB (registered trademark) implementation 220.

[0073] The Fabric CouchDB (registered trademark) function 220 directly supports the blockchain platform specific service layer 150 through its dependence on the blockchain platform 180. The Fabric CouchDB (registered trademark) function 220 is used to directly access specific indexing functions. Through its dependence on the blockchain platform 180, the blockchain platform specific service layer 150' can make GET calls to CouchDB (registered trademark) 220 (through the internal cache service), but POST calls or data operations on the blockchain are only executed by the ASIK Track chain code 170. Different types of users can access different types of data operations. These users can register with the ASIK Track chain code platform 180 using the Hyperledger (registered trademark) Fabric certificate authority. Also, the implementation of the ASIK 100 on Hyperledger (registered trademark) Fabric may enable the installation of smart contracts on the blockchain platform 180. In this way, the business logic is split between the blockchain platform specific Node.js (registered trademark) Fabric service layer 150' and the blockchain platform 180 itself.

[0074] The ASIK Track service invokes the ASIK Track chaincode 170 through the Fabric peer connection 230 that hosts the ledger and smart contract required for the chaincode 170 to update the said ledger 190. The Fabric peer 230 hosts an instance of the ledger and smart contract for the blockchain network. The ledger immutably records all transactions generated by a smart contract (a part of the code that accesses the ledger described in a supported programming language included in the chaincode 170 or smart contract in Hyperledger (registered trademark) Fabric). The smart contract and the ledger are each used to encapsulate shared processes and shared information within the network. Through the Fabric peer 230, an application can execute the chaincode and query or update the ledger.

[0075] The actual invocation to the blockchain platform 180 is made through the ASIK Track chaincode 170. When the ASIK Track chaincode 170 makes a call to update the ledger 190, its response (success / failure) is sent back to the blockchain platform specific service layer 150 or the ASIK web service API layer 130. After invoking the ASIK Track chaincode 170, the blockchain platform specific service layer 150 sends the response back to the ASIK web service API layer 130, and the ASIK web service API layer 130 sends the response back to the client application 110.

[0076] Since the ASIK Track configuration 200 is a multi-tenant system, it incorporates multiple levels of access control. To perform operations (read or write) on transaction data, the caller provides the tenant ID as well as the ID of the core ASIK participant. The hierarchy of the body of the ASIK 100 can be represented as follows for the platform administrator, tenant administrator, and core ASIK participants: Platform administrator > Tenant administrator > Core ASIK participant > ASIK specific data

[0077] Figure 3 is a perspective view 300 of the ASIK Track system object for the implementation of the ASIK Track application in a sample configuration. In particular, Figure 3 illustrates the relationships between the various database entities of the ASIK Track configuration 200. The data realization of the ASIK 100 on the Fabric includes four roles: platform administrator 302, tenant administrator 304, supply chain administrator 306, auditor / internal auditor 308. The platform administrator 302 is registered at the time of product deployment. This role is responsible for registering tenants with the system 300. A tenant has an ID and a secret, which can be used to create / read / update / delete rules and functions. The tenant is also responsible for creating the application 110. The application 110 has its own ID and secret, which are used to initiate rule execution requests at the API layer of the product. Multiple rules intended to be executed together for a transaction can be grouped.

[0078] In Figure 3, the numbers at both ends of the connection links represent the relationships between the entities by numbers. For example, in Figure 3, the participant 310 is shown as "1" and the movable product 320 is shown as "1*", which means that one movable product 320 can be related to only one participant 320, but one participant 310 can be related to any number of movable products 320. Figure 3 shows, for example, ASIK Track: Platform Administrator > Tenant Administrator > Supply Chain Administrator > ASIK Specific Data Platform Administrator > Tenant Administrator > Supply Chain Administrator > Auditor / Internal Auditor > ASIK Specific Data Platform Administrator > Tenant Administrator > Supply Chain Administrator > User > Transaction Data Related to ASIK Users or User Groups

[0079] The implementation of the ASIK into Hyperledger (registered trademark) Fabric enables the installation of smart contracts / chain codes onto the blockchain platform 180. The ASICK chain code 170 includes the core functions of ASIK. In the ASIK Track configuration, the ASICK chain code 170 has the function of creating all kinds of transaction data on Hyperledger (registered trademark) Fabric, including the creation of participants 310, movable products 320, products 330, workflows 340, user groups 350, supply chain administrators 306, trackers 360, etc.

[0080] The blockchain platform specific service layer 150´ accepts the input from the ASIK web service API layer 130 and converts the input into actions by calling the ASICK chain code 170 and the Fabric CouchDB (registered trademark) world state database 220. The blockchain platform specific service layer 150´ interacts with the Hyperledger (registered trademark) Fabric certificate authority and generates certificates for all roles involved in the ASIK 100. In the case of ASIK Track200, the Hyperledger (registered trademark) Fabric certificate authority registers users (participants, supply chain administrators, auditors, internal auditors) and generates certificates. These certificates are used when the user makes a request on the ASIK 100 using the ASIK web service API layer 130 to verify the user on the Hyperledger (registered trademark) Fabric network.

[0081] The ASIK tenant onboarding service 120 implements various phases during tenant creation. For example, in the fabric resource allocation phase, dedicated or shared resources may be allocated (in response to client / user requests), and resources may be created on-the-fly according to the requirements for the BNO service for the blockchain network used by the ASIK 100. In the channel creation and smart contract deployment phase, a tenant-specific channel may be created, and the chaincode 170 may be installed and initialized in that channel. In a sample configuration, the channel is a communication channel between two or more nodes of the network for use in conducting confidential transactions. In the CouchDB (registered trademark) view creation phase, after deploying the smart contract or chaincode 170, a dedicated database within the CouchDB (registered trademark) node may be created. For the data search process, view documents may also be created in the tenant-specific CouchDB (registered trademark) 220. In the Kafka topic partition creation phase, a configurable number of tenant-specific partitions may be added to ensure faster processing. Finally, in the Elasticsearch index creation phase, the blockchain platform-specific service layer 150 may use Elasticsearch to create tenant-specific indexes for faster data search.

[0082] The ASIK web service API layer 130 exposes APIs for use by the client application 110. In the ASIK Track configuration, there is a set of APIs exposed to the client application 110 that cover the functions of ASIK Track. Sample APIs for ASIK Track are shown in Table 1 below:

[0083]

Table 1

[0084] Table 1 shows different types of tags and the APIs or functions associated with them. These REST APIs are exposed to the client application and are responsible for performing specific functions to meet the requirements of the client application 110. For example, the tag "USER" has a "Create User" API that provides the client application 110 with a way to create a user who can create / transfer / receive movable products.

[0085] The blockchain platform-specific service layer 150 can cover the request-response cycle. Table 1 shows the functions of ASIK Track in a sample configuration. Individual services may be created for each tag in Table 1. The structure of this layer is shown as an example in FIG. 4.

[0086] FIG. 4 is a flowchart 400 showing the control flow of a sample configuration of ASIK Track. FIG. 4 shows the interaction of different components of ASIK Track and completes the control flow from and back to the client application 110. The client application 110 connects to ASIK Track 200, and ASIK Track 200 connects to external services 410 such as Redis, PostgreSQL, and Elasticsearch via a client connector 415 to realize the desired functions.

[0087] The ASIK web service API layer 130 directly receives commands from the client application 110. The ASIK web service API layer 130 is also the layer that returns the response (success or failure) to the client application 110 after request processing (425). The ASIK web service API layer 130 transfers the request to the ASIK Track middleware 420 to remove information that should be kept secret in the input. The ASIK Track middleware 420 validates the input from the ASIK web service API layer 130 and confirms that the request conforms to a pre-defined schema. Also, the ASIK Track middleware 420 removes information that should be kept secret in the input and converts it into the format required for the blockchain platform specific service layer 150 to process the input (430). At any point, if the request does not match the pre-defined schema, the request is rejected and returned to the ASIK web service API layer 130 (435). After verification, the request is transferred to the blockchain platform specific service layer 150.

[0088] In the sample configuration, the ASIK Track service layer 150 is a group of one or more ASIK Track services. Each service is responsible for performing the functions assigned to it and returning responses to the next / previous services. Client connections or connectors 415 to external services 410 such as Redis, Kafka, PostgreSQL, Elasticsearch, CouchDB® are also established in the ASIK Track service layer 150. The client connections or connectors 415 provide a layer through which the ASIK Track service layer 150 interacts with the external services 410 (440). The ASIK Track service layer 150 is responsible for processing each functional part of ASIK Track. To be responsible for processing each functional part of ASIK Track, individual service files are created (445). The ASIK Track service layer 150 determines to call the next service based on the received request. Data received from the external service 440 can be returned to the respective services (450). In the blockchain platform specific service layer 150´, the ASIK Track service may communicate with the Hyper Fabric network (455).

[0089] In the sample configuration of ASIK Track, pre-set scenarios and business rules are used to aggregate transactions of one attribute in order to commit the same thing on the blockchain to ensure the results and then provide the cumulative results. In the configuration of ASIK Track, several nodes are added for business functions. Each node contains a series of instructions given from the client application 110 in the form of JavaScript functions (script nodes, transition nodes, workflow trigger nodes) or third-party API executions (service nodes) to perform several operations related to ASIK Track. In one example, the nodes can include script nodes, service nodes, transition nodes, and workflow trigger nodes.

[0090] A script node cannot be the first node of the workflow. An example of a declaration is shown below: {{foo}} = {{bar}} + 10;}. Two or more script nodes can be consecutive. The script node does not belong to the user group node mapping, but may belong to the node ID transfer sequence. When an instance moves and follows a path through the script node, the script described in the script node is executed. The attribute value set for the script node is set by an attribute and may be visualized in the next group node of the script node. If any failure occurs in the script / service node, the instance remains in the previous group node. For example, in the case of a workflow: user group node 1 > script node 1 > user group node 2, when the attribute value of ABC is set to 123 in the script node, the attribute value of ABC is displayed as 123 in user group node 2.

[0091] Also, a service node cannot be the first node of the workflow. Two or more service nodes can be consecutive. The service node does not belong to the user group node mapping, but may belong to the node ID transfer sequence. When an instance moves and follows a path through the service node, the service node may be executed by calling a third-party API. The service node waits for a response from the third-party API until a set timeout. The service node can attempt to retry according to a set retry value time.

[0092] A transition node cannot be the first node. The transition node does not belong to the user group node mapping, but may belong to the node ID transfer sequence. When an instance moves, if the instance follows a path through the script node, the script mentioned in the transition node is executed, and the transition node returns "to_node_id".

[0093] The workflow trigger node cannot be the first node of the workflow. Also, the workflow trigger node does not belong to the user group node mapping, but can belong to the node ID transfer sequence. When an instance moves, if the instance follows a path through the workflow trigger node, the batch composer service (BCS) is called to generate a batch, and the generated batch ID is returned to the client application 110. For example, the following is an example declaration of a workflow trigger node:

[0094]

Number

[0095] In a sample configuration, the following services are included in the ASIK Track application.

[0096] A batch composer service (BCS) may be provided to play a role in generating batches of the movable product related transactions such as transfer, reception, update, final node execution, etc. The BCS returns the generated batch ID to the ASIK Track service, sends the generated batch ID to the Kafka queue for aggregation. The transaction may be part of the same batch until the condition of the aggregation setting given by the client application 110 is false. When the condition becomes true, the batch is completed.

[0097] The Aggregation Engine Service is responsible for executing the aggregation and post-aggregation processes. The said aggregation may be executed on the mobile product attribute values. For example, SUM, MIN, MAX, COUNT, and AVG aggregation functions may be supported. There may be implemented two types of aggregations: Eager Aggregation, which is a runtime aggregation executed simultaneously when the transaction / request is received, and Lazy Aggregation, which executes the aggregation when the batch is completed. Post-aggregation is executed after the said aggregation is completed. Post-aggregation is usually used to change the attribute values according to the script defined in the workflow trigger node.

[0098] After the said workflow trigger node, there may be provided a mobile product worker service that plays a role in completing the next flow of the defined workflow. For example, in the case of the Workflow1 example: User Group Node 1 > Workflow Trigger Node 1 > User Group Node 2, when the aggregation and post-aggregation are completed, a request comes to the mobile product worker service via the Kafka queue. The said mobile product worker service checks whether the next node is a group node and executes the transfer function at User Group Node 2. On the other hand, in the case of the Workflow2 example: User Group Node 1 > Workflow Trigger Node 1 > Workflow Trigger Node 2 > User Group Node 2 > wtn1 > wtn2 > Group 2, when the aggregation and post-aggregation of the Workflow Trigger Node 1 are completed, a request comes to the mobile product worker service via the Kafka queue. The said mobile product worker service checks whether the next node is a workflow trigger node. If so, the said mobile product worker service calls the batch composer service for the processing of the Workflow Trigger Node 2. When the processing of the Workflow Trigger Node 2 is completed, the said mobile product worker service can execute the transfer function for User Group Node 2.

[0099] The movable product trace data handler service is used to manage the trace details of the movable product. The movable product trace data handler service has a background job to load trace information into a persistent environment (Postgres) based on defined business rules. Also, the movable product trace data handler service has an API for viewing the trace details of the provided movable product. By using the movable product trace data handler service, a user / client can trace a list of all key attributes (or) aggregated instances with a movable product ID.

[0100] A scheduling composer service may be provided to create a scheduling job for the workflow trigger node. The settings of the scheduling job are input as follows when the client application 110 creates a workflow:

[0101]

Number

[0102] This scheduling job may trigger a request to execute the aggregation of the saved workflow details and the batch ID. The scheduler composer service may receive a request when the client application 110 creates a workflow with scheduler settings.

[0103] As described above, the blockchain platform specific service layer 150' communicates with the Hyperledger (registered trademark) Fabric (blockchain) network. The blockchain platform specific service layer 150' holds the main business logic, manages data operations, and invokes the blockchain platform 180. The blockchain platform specific service layer 150' accepts the input from the ASIK track service layer 150 and creates the request in a format that invokes the ASIK chain code 170. The ASIK chain code 170 is the layer where the ASIK 100 submits the request to the blockchain platform 180 and inserts data into the ledger and the state database (e.g., CouchDB (registered trademark)). The blockchain platform specific service layer 150' also interacts with the Hyperledger (registered trademark) Fabric certificate authority to generate certificates for all roles involved with the ASIK 100. In the case of the ASIK Track configuration, the Hyperledger (registered trademark) Fabric certificate authority can register users (participants, supply chain administrators, auditors, internal auditors) and generate certificates. These certificates are used when the user makes any request on the ASIK 100 using the ASIK web service API layer 130 and can be used to verify the user on the blockchain platform 180.

[0104] Table 2 below is a sample list of the various microservices created by ASIK Track to support various functions and business requirements.

[0105]

Table 2

[0106] Each service described in Table 2 may include a plurality of APIs that are exposed to the client application 110 to which the ASIK platform interfaces. For example, the service "Movable Product Trace Data Handler and Tracking Service" is responsible for storing snapshots of the movable product and traces of its attributes.

[0107] Figure 5 is a flowchart 500 showing the operation of the ASIK 100 with a general configuration.

[0108] As shown in Figure 5, the starting point of the ASIK 100 is an enterprise-level user who handles the front end of the distributed ledger product. The process starts with a user request or input at 510. The data provided by the user is a request to execute some transaction 185 on the blockchain network. This request can be made by the user from the user interface 520, by an HTTPS request, or by a request from the Restful API 140.

[0109] Normally, the request is transferred from the responsive user interface 520 of the front end of the distributed ledger product, an HTTPS request, or the RESTful API 140. These requests are routed from the endpoint (API) in the form of a function [f(x) Webservice] to the ASIK web service layer 150. The nature of the request determines the necessary function to be called in the ASIK web service layer 150 and leads to the business logic identified in this process.

[0110] Before the package is routed to the ASIK web service layer 150, the request may be verified by the middleware 420. The middleware 420 checks whether the provided request has all the parameters according to the business requirements. The middleware 420 also processes certain special functions, such as case sensitivity of parameters and input variable names, and similar functions.

[0111] According to the business requirements, the appropriate functions corresponding to these requirements are selected by the web service function [f(x)Webservice] of the ASIK 100. The request function then triggers a similar function [f(x)Chaincode] of the chaincode 170. These functions function as modulators that convert the input request into a transaction executable on the blockchain platform 180 via the chaincode 170. Therefore, for all request functions, there are similar response functions that convert the information in a format interpreted by the blockchain platform 180. Business problems are solved at the chaincode layer 170, and the chaincode layer 170 is responsible for all interactions with the blockchain platform 180.

[0112] When the transaction 185 is executed on the blockchain platform 180, the business is completed. Thereafter, the state of the transaction 185 is updated on a pre-set state database (e.g., CouchDB (registered trademark)) 220 that tracks all the transactions 185 made by the enterprise. All transactions within the ASIK 100 may be executed according to a security protocol (e.g., Transport Layer Security (TLS) 1.0) so that internal and external transactions 185 are sent via a secure channel.

[0113] Each time transaction 185 is executed on the blockchain platform 180, the process of updating the ledger 190 is sequentially performed. Regardless of the status of the transaction, i.e., success (530) or failure (540), the transaction 185 with a unique ID is updated on the ledger 190. The smart contract / chain code 170 may be customized by the ASIK 100 to further enhance the transaction report.

[0114] Each time the transaction 185 fails (540), an error handling system such as the technical error reprocessing 550 assigns the transaction 185 to the ASIK 100. The ASIK 100 identifies the nature of the error and re-executes the transaction 185 from the appropriate starting point.

[0115] After the business operation, the request is completed and the response propagates to the ASIK web service layer 150 via the chain code 170. The response can then be displayed as the desired output via the user interface dashboard on the user interface 520. Thus, the life cycle of the request function starting from the ASIK web service layer 150 ends at the same location in the form of a response.

[0116] One skilled in the art would understand that the ASIK 100 implemented in Fabric / Node.js (registered trademark) has the advantages of decentralization, secure data encryption, ease of implementation, and high fraud prevention. The ASIK 100 retains the core functions of the blockchain and conveys them to users without interrupting the functions and content of the blockchain. The ASIK 100 also provides a "plug-and-play" solution with pre-set scenarios. Users send requests to the ASIK web service layer 150 using conventional user interface methods or HTTPS requests, and the ASIK 100 processes the rest. The elements that users need to set up to use the ASIK 100 are minimal. The business logic is precisely constructed, deployed to peers within the channel, and the business logic is executed on the blockchain. Due to its modular nature, the execution operation of transactions on the blockchain adapted to specific use cases that abstract the need for technical understanding of the blockchain is simplified, thereby making the blockchain application rather user-friendly. Also, the most sought-after business utilities and functions are pre-configured as reusable via rules through a programming interface, ensuring that enterprises can use the same solution for various complexities. It will be further understood that the blockchain rule engine described in U.S. Patent Application No. 17 / 653,085 is not only used to implement business rules by the ASIK 100 but may also be used to enable the creation of new rules without entering the user application for that purpose. The content of U.S. Patent Application No. 17 / 653,085 is hereby incorporated by reference in its entirety.

[0117] The ASIK 100 also provides a reliable and backward-compatible interface between the user and the blockchain. Since the ASIK 100 manages all operations on the blockchain, users can enjoy the benefits of the ASIK 100 without understanding the blockchain. In addition, since the ASIK 100 provides a set of APIs that are published to meet specific business requirements, the ASIK 100 can be used in conjunction with any technology stack that is very similar to the API compatibility. The ASIK 100 also operates on both chaincode and smart contracts and operates on multiple blockchain networks such as Ethereum and Hyperledger (registered trademark) Fabric, so it is not restricted by the blockchain. The ASIK 100 also operates across all major technology stacks and programming languages and interacts with various compatible blockchains and cloud networks via a load-balanced REST API.

[0118] Since the ASIK 100 outlines the semantics, syntax, interfaces, and requirements that enable it to operate across all major technology stacks and programming languages, the business service layer can be developed with different technologies. New developments can be carried out using the latest technology frameworks, leveraging technical advantages. The ASIK 100 provides semantics and syntax already familiar to non-blockchain programmers and is identical across all blockchain platforms, enabling rapid application development. The ASIK 100 further provides a pluggable platform that can interact with multiple client applications by simply changing the settings. Using a powerful load-balanced REST API, communication with various blockchain frameworks can be achieved relatively easily. As a result, the framework facilitates the upgrade and release of the blockchain. Additionally, by implementing multi-tenancy on the blockchain, multiple tenants can create and manage data on the blockchain, and the data of each tenant can be physically separated. All operations related to tenants and core participants of the ASIK are securely recorded on the blockchain within the multi-tenancy framework. Finally, with a modular framework of pre-set functions and features, the ASIK 100 can provide a platform that easily realizes multiple business use cases.

[0119] These and other advantages will be apparent to those skilled in the art from the foregoing description.

[0120] Computer Embodiments FIG. 6 is a block diagram of a typical general-purpose computer 600 that can be programmed on a special-purpose computer suitable for implementing one or more embodiments of the ASIK 100 disclosed herein. The above-described ASIK 100 can be implemented on any general-purpose processing component such as a computer having sufficient processing power, memory resources, and communication throughput capacity to handle the required workload. The computer 600 includes a processor 602 (which may be referred to as a central processing unit or CPU) that communicates with a memory device including a secondary storage device 604, a read-only memory (ROM) 606, a random access memory (RAM) 608, an input / output (I / O) device 610, and a network connection device 612. The processor 602 may be implemented as one or more CPU chips or may be part of one or more application-specific integrated circuits (ASICs).

[0121] The secondary storage device 604 typically consists of one or more disk drives or tape drives and is used for non-volatile storage of data and as an overflow data storage device when the RAM 608 is not large enough to hold all the working data. The secondary storage device 604 can be used to store a program when that program is selected for execution and loaded into the RAM 608. The ROM 606 is used to store instructions and possibly data that are read during program execution. The ROM 606 is a non-volatile memory device and typically has a smaller memory capacity compared to the large memory capacity of the secondary storage device 604. The RAM 608 stores volatile data and possibly instructions. Access to both the ROM 606 and the RAM 608 is typically faster than access to the secondary storage device 604.

[0122] The apparatus described in this specification includes a computer-readable non-transitory medium storing computer-readable instructions and one or more processors coupled to the memory. When the computer-readable instructions are executed, the computer 600 can be configured to perform the method steps and operations described above with reference to FIGS. 1 through 5. The computer-readable non-transitory medium includes any type of computer-readable medium including magnetic storage media, optical storage media, flash media, and solid state storage media.

[0123] Software including one or more computer-executable instructions that facilitate 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 within the consumer and / or producer domain consistent with the present disclosure. Alternatively, the software may be obtained and loaded on one or more servers and / or one or more routers and / or one or more devices within the consumer and / or producer domain consistent with the present disclosure, including, for example, through a physical medium or distribution system from a server owned by the software creator or from a server not owned but used by the software creator. The software can be stored on a server, for example, for distribution over the Internet.

[0124] Moreover, those skilled in the art will understand that the present disclosure is not limited in its application to the details of the structures and the arrangements of the components described in this specification or illustrated in the drawings. Embodiments in this specification are capable of other embodiments and can be implemented or carried out in various ways. Also, it should be understood that the phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting. The use of "including", "comprising", or "having" and their variations herein means including the items listed hereinafter and their equivalents, as well as additional items. Unless otherwise limited, the terms "connected", "coupled", "attached", and their variations used herein are used in a broad sense and include direct and indirect connections, couplings, and attachments. Further, the terms "connected" and "coupled" and their variations are not limited to physical or mechanical connections or couplings. Furthermore, terms such as up, down, bottom, top, etc. are relative and are adopted for the purpose of assisting the description but are not limiting.

[0125] The components of the exemplary devices, systems, and methods employed in accordance with the illustrated embodiments may be implemented, at least in part, in digital electronic circuitry, analog electronic circuitry, or computer hardware, firmware, software, or combinations thereof. These components can be implemented as a computer program product, such as a computer program, program code, or computer instructions embodied in an information carrier or a machine-readable storage device for execution by, or to control the operation of, a data processing apparatus, such as a programmable processor, a computer, or multiple computers.

[0126] A computer program can be described in any form of programming language, including compiled languages and interpreted languages, and can be deployed in any form, such as 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 deployed to be executed on one computer, or may be deployed to be executed on multiple computers at one site, or may be distributed across multiple sites and interconnected by a communication network. Also, functional programs, code, and code segments for achieving the techniques described herein can be readily interpreted by a programmer skilled in the art as being within the scope of the present disclosure. The method steps associated with the exemplary embodiments are executed by one or more programmable processors that execute the computer program, code, or instructions and can perform functions (e.g., by operating on input data and / or by generating output). The method steps may also be executed by special-purpose logic circuits such as, for example, FPGAs (Field Programmable Gate Arrays) or ASICs (Application Specific Integrated Circuits), and the apparatus may be implemented as special-purpose logic circuits.

[0127] The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein can be implemented or executed in any combination of a general purpose processor, digital signal processor (DSP), ASIC, 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 in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0128] Processors suitable for the execution of a computer program include, by way of example, general and special purpose microprocessors, and any one or more processors of any kind of digital computer. In general, a processor receives instructions and data from a read only memory or a random access memory or both. Essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. In general, a computer is 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, etc. Information carriers suitable for embodying computer program instructions and data include, by way of example, semiconductor memory devices, such as electrically programmable read only memory or ROM (EPRPM), electrically erasable programmable ROM (EEPROM), flash memory devices, and data storage disks (such as magnetic disks, built-in hard disks, or removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks), including any form of non-volatile memory. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0129] Those of ordinary skill in the art will appreciate that information and signals can be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips referred to in the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0130] Those skilled in the art will further understand that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and processes have been generally described above from the perspective of their functions. Whether such functions are implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. A person skilled in the art can implement the functions described in various ways for each particular application, but such implementation decisions should not be construed as causing a departure from the scope of the present disclosure. Software modules can reside in random access memory (RAM), flash memory, ROM, EPROM, EEPROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium 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. In another way, the storage medium may be integral with the processor. That is, the processor and the storage medium may be present within an integrated circuit or implemented as discrete components.

[0131] As used herein, "machine-readable medium" means an apparatus that can temporarily or permanently store instructions and data, 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., EEPROM (Electrically Erasable Programmable Read-Only Memory)), and / or any suitable combination thereof. The term "machine-readable medium" should be considered to include a single medium or multiple media (e.g., a centralized database or a distributed database, or associated caches and servers) that can store processor instructions. Also, the term "machine-readable medium" should be considered to include any medium, or combination of multiple media, that can store instructions for execution by one or more processors, and when those instructions are executed by one or more processors, 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 apparatus, and "cloud-based" storage systems or storage networks that include multiple storage devices or apparatuses. The term "machine-readable medium" as used herein excludes the signal itself.

[0132] The foregoing description and drawings are intended only as examples and are not intended to limit the exemplary embodiments in any way except as set forth in the appended claims. Note that the various technical aspects of the various elements of the various exemplary embodiments described above can be combined in many other ways, all of which are considered to be within the scope of the present disclosure.

[0133] Accordingly, while exemplary embodiments have been disclosed for illustrative purposes, those skilled in the art will appreciate that various changes, additions, and substitutions are possible. Accordingly, the present disclosure is not limited to the above-described embodiments and may be modified within the scope of the appended claims, along with the full scope of their equivalents.

Claims

1. An application-specific integration kernel that interfaces a client application with a blockchain platform for managing a blockchain, An application programming interface (API) layer that receives a request from the client application to execute a transaction on the blockchain, the API layer formatting data related to the request, the application programming interface (API) layer, Receiving at least one command associated with the request and the formatted data, identifying the type of the request, and based on the type of the request, transferring the at least one command and the formatted data for execution on the blockchain, and returning a processing result of the at least one command and the formatted data on the blockchain to the client application. The service layer further describes pre-set features and functions for interacting with the blockchain platform according to a predetermined use case of the application-specific integration kernel. The service layer, Converting the at least one command into at least one transaction executable on the blockchain platform according to the pre-set features and functions for the predetermined use case, and returning the execution result of the at least one transaction and the formatted data on the blockchain platform to the service layer, thereby managing data operations for the pre-set features and functions for interacting with the blockchain platform for the predetermined use case. A chain code and An application-specific integration kernel having.

2. The application-specific integration kernel according to claim 1, wherein the API layer exposes an API used by the client application to access the pre-set features and functions so that the client application interacts with the blockchain platform according to the predetermined use case of the application-specific integration kernel. An application-specific integration kernel.

3. In the application-specific integration kernel according to claim 1, the API layer provides a load-balanced Representational State Transfer (REST) API to the client application, and the REST API is adapted to interact with the blockchain platform, which is an application-specific integration kernel.

4. In the application-specific integration kernel according to claim 1, the API layer, service layer, and chain code are adapted to support a multi-tenant framework in which multiple client applications can create and manage data on the blockchain platform, which is an application-specific integration kernel.

5. In the application-specific integration kernel according to claim 1, the API layer validates the request from the client application, validates the user details received in the request from the client application, checks the user's permission to execute the request from the client application, prepares the request for submission to the blockchain platform, and returns a response from the blockchain platform to the client application, which is an application-specific integration kernel.

6. In the application-specific integration kernel according to claim 1, the API layer, service layer, and chain code are adapted to support three roles: platform administrator, tenant, and core ASIK participant. The platform administrator is responsible for registering client applications. The tenant has an ID and allocated resources that can be used to perform create, read, update, and delete operations on the formatted data. The core ASIK participant has a unique ID used to initiate requests with the API layer, which is an application-specific integration kernel.

7. In the application-specific integration kernel according to claim 6, further, it has a database for each tenant in which each tenant operates in its own database, which is an application-specific integration kernel.

8. In the application-specific integrated kernel according to claim 1, the service layer describes the preset features and functions by outlining at least one interface through which semantics and syntax, and at least one command and formatted data interact with the blockchain platform for the predetermined use case of the application-specific integrated kernel. An application-specific integrated kernel.

9. In the application-specific integrated kernel according to claim 1, the predetermined use case of the application-specific integrated kernel corresponds to a business service executed on the blockchain. An application-specific integrated kernel.

10. In the application-specific integrated kernel according to claim 1, the chain code accesses the blockchain ledger and the smart contract of the blockchain platform to query or update the blockchain ledger. An application-specific integrated kernel.

11. In the application-specific integrated kernel according to claim 10, all operations of the client application are securely recorded in the blockchain ledger. An application-specific integrated kernel.

12. In the application-specific integrated kernel according to claim 1, further having a state database, wherein the service layer receives an input from the API layer and converts the input into an action by calling the chain code and the state database. An application-specific integrated kernel.

13. A method for interfacing a client application with a blockchain platform for managing a blockchain, Receiving, by an application programming interface (API) layer, a request from the client application for executing a transaction on the blockchain; Formatting, by the API layer, data associated with the request; Receiving, by a service layer, at least one command and formatted data associated with the request; The step of identifying the type of the request by the service layer; The step of transferring, by the service layer, the at least one command and formatted data for execution on the blockchain based on the type of the request; The step of managing data operations by converting, by a chain code, the at least one command into at least one transaction executable on the blockchain platform according to features and functions preset to interact with the blockchain platform according to a predetermined use case; The step of returning the execution result and formatted data of the at least one transaction on the blockchain platform to the client application; A method comprising.

14. The method according to claim 13, further comprising the step of exposing, to the client application, an API that can be used to access the preset features and functions for the client application to interact with the blockchain platform according to the preset use case.

15. The method according to claim 13, further comprising the step of providing a load-balanced Representational State Transfer (REST) API to the client application, wherein the REST API is adapted to interact with the blockchain platform.

16. The method according to claim 13, further comprising The step of enabling a plurality of client applications to create and manage data on the blockchain platform using the API layer, service layer, and chain code.

17. In the method according to claim 13, the step of formatting the data related to the request includes the step of the API layer validating the request from the client application, the step of validating the user details received in the request from the client application, the step of checking the permission of the user to execute the request from the client application, and the step of preparing to submit the request to the blockchain platform.

18. In the method according to claim 13, the API layer, service layer, and chain code are adapted to support three roles including a platform administrator, a tenant, and a core ASIK participant. Further, the platform administrator registers a client application, the tenant performs create, read, update, and delete operations on the formatted data using the ID and resources assigned to the tenant, and the core ASIK participant starts a request with the API layer using its own ID.

19. In the method according to claim 18, each tenant has a database, and further includes the step of each tenant performing operations on its own database.

20. In the method according to claim 13, further, the service layer describes the preset features and functions by outlining semantics and syntax, and at least one interface where at least one command and the formatted data interact with the blockchain platform for the predetermined use case.

21. In the method according to claim 13, the predetermined use case corresponds to a business service executed on the blockchain.

22. In the method according to claim 13, further, the chain code accesses the blockchain ledger and the smart contract of the blockchain platform to query or update the blockchain ledger.

23. In the method according to claim 22, further, A method having a step of securely recording all operations of the client application in the blockchain ledger.

24. In the method according to claim 22, further, A method having a step in which the service layer receives an input from the API layer and a step in which the chain code and the state database are called to convert the input into an action.

25. A non-transitory computer-readable medium storing instructions for implementing a method for interfacing a client application to a blockchain platform that manages a blockchain by one or more processors, the instructions comprising: An application programming interface (API) layer that receives a request for executing a transaction on the blockchain from the client application and formats data related to the request, A service layer that receives at least one command and the formatted data associated with the request, identifies the type of the request, transfers the at least one command and the formatted data for execution on the blockchain based on the type of the request, and returns an execution result of the at least one command and the formatted data on the blockchain platform to the client application, And a chain code that manages data operations by converting at least one command into at least one transaction executable on the blockchain platform according to features and functions preset to interact with the blockchain platform according to a predetermined use case A non-transitory computer-readable medium having.

Images